Server Core Edition is very lightweight, needs less Windows Updates, less disk space, and should be used whenever possible. Basic features like AD DS, DNS, DHCP, or IIS are supported on Server Core. Administering is also very easy once it is a member of the domain because it can be added to Server Manager on a server with GUI. We are installing AD DS in this article.
You can relatively easily change system settings on Server Core with the sconfig cmd tool.
sconfig
First change the server’s name (Option 2).
Afterwards set the IP address to a static one along with DNS servers (option 8).
Return to the main menu and perform the Domain Join (option 1).
We don’t need to change the computer name. The server will be then rebooted.
From now on, the fastest and simplest approach of administering your Windows Server Core is through Server Manager on a Server with GUI.
So here is a challenge I had to face today: I created a virtual machine (VM) in Azure from a custom image that was previously Sysprep’d by me. The image contained several applications intended to run on a RDSH (Remote Desktop Session Host) for Citrix Virtual Apps and Desktops (former XenApp), so the RDS role was also installed. The VM was not part of the domain, it was in a Workgroup and it could not reach the RDS license server. Which meant: I could not RDP into the machine to perform Domain Join. And if you already have some experience with Microsoft Azure, you will know that there is no Remote Console like in VMware or Hyper-V.
The VM was still reachable over the network. So here are four PowerShell commands that allowed me to remotely perform a Domain Join on that particular machine. Nothing fancy, but it might come in handy.
This credential variable stores the local username and password of the computer. Something like computername\admin along with the password.
$Cred = Get-Credential
Add-Computer -DomainName “ajni.lab” -Restart
After executing the last command you will be prompted to insert domain credentials. The user obviously must have the right to create computers in the domain.
What do we need for a Citrix Virtual Apps and Desktops (XenApp and XenDesktop) deployment?
Active Directory
Citrix Delivery Controller
Citrix Storefront
One Citrix Virtual Delivery Agent (VDA)
Citrix License Server
A Database Server (SQL Server)
I will be consolidating Citrix Delivery Controller, Storefront, and License Server into one VM since this is a lab environment. In a production environment, you would use 2 VMs for Citrix Delivery Controller (for High Availability – HA), two for Citrix Storefront, and one for the License Server. The VDA count depends on user size.
Using the same two VMs for Delivery Controller and Storefront is also viable.
In my lab, all the servers are housing Windows Server 2019 Datacenter.
First, download the ISO on citrix.com. You will need an account and if you don’t have any partnership with Citrix, it is very difficult to get those files. There is a form you can fill and all you can do afterward is hope that they give you the files. Otherwise, there is no way of getting them publicly.
After mounting the ISO Autoselect.exe can be run.
Select Virtual Apps and Desktops. Virtuals Apps would just publish single programs as apps.
Start by installing Delivery Controller and other components.
Just in case you are wondering: Some obvious steps will not be shown.
We are installing all the features on the same server. Like I said, Delivery Controller and Director should be on one server, License Server on another, and Storefront on another. Storefront and Delivery Controller should have 2 VMs each for High Availability.
I am also using SQL Express on the same server. Normally you would use a dedicated instance on a separate database server.
The server will be restarted. You will need to mount the ISO again and select the target folder:
And after some time…
Our main tool is going to be Citrix Studio.
Make sure you a logged in with a domain user. Local users are not supported.
Configuring a new site.
These parameters will be automatically populated if SQL Express is being used. If using a separate database server a script can be generated to create the databases and tables.
My license server is hosted on the same server.
A connection to VMware or Hyper-V can be made. I am using Azure.
I will select “Other Tools” this time, I’ll make a post about Citrix MCS another time.
Enter your Azure Subscription ID and any name and then select “Create New”.
You will log in to Azure AD. This process creates a new Service Principal in Azure AD that allows Citrix to start, stop, create, and delete VMs in Azure.
In your Subscription under Access control (IAM) you will see a new App Principal as a Contributor.
App-V and AppDNA is not our focus right now.
Here is the summary of my settings.
To deliver a desktop we need at least one server to connect to.
Create a new VM, join it to the domain, and install the Virtual Delivery Agent (VDA).
Run autoselect.exe inside the ISO again.
We are not creating a Master Image for MCS. The Delivery Group will have a catalog of one machine.
Citrix Workspace App is not needed. You can de-select it.
I did not select any additional components.
Add the Delivery Controller.
Enable both features
Leave Firewall Rules to automatic.
Prerequisites will be installed.
Server will restart twice.
Create a Machine Catalog containing the Remote Desktop Session Host.
This is a server with multiple users connecting to it.
Select the VM and the computer account.
Give it a name.
Create a Delivery Group.
Select the Machine Catalog we just created
You should probably create a custom group to limit the users.
Add a new desktop and give it a name. I use “TreatAsApp” to show both Desktops and Apps in one tab.
Under Search, we can see if the server has successfully registered with the Delivery Controller.
Create a self-signed certificate (I do not have Active Directory Certificate Services on my lab environment). I might do a post about that in the future.
Run through the wizard (easy).
Make sure you select the personal certificate store.
Add a new Binding on port 443.
Select the certificate you just signed.
Now both 80 and 443 are active:
Change the Base URL to HTTPS
Now HTTPS is being shown:
Configure Passthrough authentication
The storefront URL should be added to the Trusted Sites for pass-through authentication to function properly. Make sure to change “User Authentication” to “Automatic logon with current username and password”. The default setting is “Automatic logon only in Intranet Zone”
Also, configure pass-through authentication for Receiver for Web Sites.
Change loopback communication to OnUsingHttp:
Change “Enable loopback communication” to OnUsingHttp
Set this Site as default in IIS:
Configure Delivery Controller to use SSL
Storefront does not accept self-signed certificates, so an internal Certificate Authority is needed for SSL communication between Storefront and Delivery Controller.
That’s it! It was a long but very interesting post.
What is DNS over HTTPS ? Well it’s basically an encrypted way of querying DNS. Normally DNS uses port 53 to communicate with the server and query the name we want. But all of that traffic is in plain-text and thus it is very easy to poison that communication. DNS over HTTPS is secure because it uses certificates to encrypt traffic (just like HTTPS websites).
Mozilla Firefox makes it very easy to enable this feature. Just open the settings and search for “DNS over HTTPS”:
