Quick Tip – Change SQL Server Collation

I recently needed to change the SQL Collation to allow for a System Center Configuration Manager install, but I forgot to do this when I built the SQL Server. To change this after installing SQL, run the following command:

setup.exe /q /action=rebuilddatabase /instancename=mssqlserver /sapwd=yourpassword /sqlcollation=SQL_Latin1_General_CP1_CI_AS /sqlsysadminaccounts=domain\administrator

Note: if you need to see the command output, remove the /q. Also – use with caution, I ran this on an empty SQL Server with no databases on it.

For further information see: https://msdn.microsoft.com/en-gb/library/ms179254.aspx

XenDesktop 7.11 – Zones


Many XenApp administrators will remember the Zone Preference Failover (ZPF) features available in previous versions. For those unaware, this allows resources to be served from Hosts within a logical group (a Zone), unless a failure/maintenance condition exists, in which case resources are served from a Secondary Zone.

Using Zones we can provide applications from a single Zone, with failover to another Zone in the event of an issue. This is useful for a great many reasons:

  • Automatic failover to a DR site if there are issues with the Primary Zone’s Session Hosts
  • Automatic placement of users into a Zone that is nearest their location – useful for those with geographically disparate environments.
  • Capacity management – we can seamlessly “spill” users across to a secondary zone in the event that the primary zone reaches capacity.


Zones are configured using the Zones option, under Configuration, within Citrix Studio:


Lab Environment

For the purposes of this demonstration, I have considered a fictional environment shown below. We have two Geographical sites, linked via a wide area network. We have Active Directory Services across both sites, and a replicated SQL Environment. XenDesktop has been configured as a single site, with two Delivery Controllers, and two Session Hosts.



For this demonstration I will show how user preferences can be assigned to resources in a zone, and then seamlessly failed over in the event of a fault or issue.


Creation of Zones

We begin with two Delivery Controllers configured for this farm – obviously in a production environment we would be working with N+1, so at least two Controllers per Zone.


We can then create the Zone Configuration – this is done using the Zones pane in Citrix Studio:


As you can see, the default configuration places all controllers in the Primary Zone (the only zone within the Farm):


To begin, I will create a secondary zone called “Zone 2” and also rename “Primary” to “Zone 1” – in a production environment these could be physical locations, or different Data Centers. To create a new Zone, click on the “Create Zone” within the Actions pane:


You will then be presented with a new window which can be name as required. Note – I have selected my Zone 2 Delivery Controller (Z2XD01) to be added to this Zone:


When the details have been populated and Controllers selected, click on “Save”. The new Zone is then created:


After this I updated the Primary zone by right clicking on the Zone and selecting “Edit Zone”:


My Zone configuration is now as follows:


Machine Catalogue Setup

Next I will create two new machine catalogues, each with a single session host, and assign these machine catalogues to Zone 1 and 2. The creation of these is done as you would any other machine catalogue – except we can now select a zone to add the machines to:


I’ve created two catalogues now – one for Zone 1 and one for Zone 2:


Now we will create a single Delivery Group – in this scenario, the Delivery Group spans across the Zones, and contains machines from both Zones:


Note: Create the Delivery Group with machines from one Zone first, and then add in the machines from the 2nd Machine Catalogue after.

Zone Configuration

Before we can assign users to a Zone, we need two new AD Groups to define the users home Zone:


Next – we can assign these Groups to Zones within the Console. We do this with the “Add Users to Zone” option:


Adding a user Group to a Zone:


Now – we can see the user configuration for each Zone:




To test this setup I created 5 Test User accounts, and added them all to the Users_Zone_1 AD Group. This will mean that when these users launch a session from our Delivery Group, it will be served by Session Hosts in Zone 1 (as we have associated these users to that Zone). I logged all of the users into StoreFront and launched a session – the result was all users launched desktops from Zone 1 Resources:


Next – I will remove Test User 5 from Zone 1, and place them into a Zone 2 Group. Then I will log them off and back on. The result is shown below – note how a change in the Zone Assignment changes the Session Host used:


Practical Use – Failover!

Having users log into different Session Hosts based on an AD Group is all well and good – but this is not unique to Zone Configuration. What’s great about the Zoning in XenDesktop is that we can automatically fail over between the zones. In the example below, all 5 Users are assigned, by AD Group, to Zone 1.

But – if there’s an issue with the Session Hosts in Zone 1, perhaps a failure or outage, we don’t want to manually have to fail this over. When setting up the Delivery Group, this option was not selected:


This means that because both Machine Catalogues (in each Zone) are members of the same Delivery Group (which spans the Zone), we can have user sessions automatically launch in Secondary Zone for the Users. To test this, I placed all Machines in Zone 1 into Maintenance Mode, and then logged on all 5 Test Users. The result – Users are logged onto Machines in Zone 2:


Essentially, we now have a solution that automatically connects users into their primary resource, based on Zone Assignment, but in the event of an issue with that Zone, connects them into resources in a Secondary Zone.

Obviously there many other elements to consider with a design like this – particularly around the SQL, StoreFront, and NetScaler infrastructure. But for a simple and automatic failover solution – this works really well.

Citrix Self Service Password Reset – Setup


Self Service Password Reset (SSPR) is a technology that allows users to enroll and answer a series of questions, which then allows them to reset their password later on should they forget it.

Before setting up SSPR you need to have Citrix StoreFront setup and secured with an SSL Certificate, and an SSL certificate available to use for the SSPR server. You also need to have Platinum XenDesktop licensing to use this feature. I also have a small XenDesktop 7.11 environment setup so that I can test successful launching of applications after a password reset.

Environment Overview

Below is a diagram of the virtual environment I have created for this lab:


Not too much to setup for this – this lab was created in a virtual environment, utilising PFSense as the gateway. I also have a client machine, and a XenDesktop infrastructure setup which aren’t in the picture. All VMs are running Windows Server 2012R2, and are 1vCPU and 4GB RAM. All storage is across SDDs local to the VMware host.

SSPR Setup:

The installation media for Self Service Password Reset is included on the XenDesktop 7.11 Media:


Installation is fairly straightforward – the next few screenshots cover the install process:








Installation of SSPR is now completed – and we can start configuring everything.

IIS Changes

We need to configure a few basic IIS settings on the SSPR Server – these are detailed below:

Install an SSL Certificate:

Firstly, we need to open the IIS Management console, and open Server Certificates:


You will need to specify a certificate for use with the service, and then bind that to the default website. In my case I have used a self signed certificate, which I have installed on both the SSPR and StoreFront servers in this lab:


Bindings adjusted as per the below screenshot:


Adjust the Authentication Settings:

As per the Citrix article https://docs.citrix.com/en-us/self-service-password-reset/1-0/secure.html you will need to adjust the authentication settings for the MPMService website. Open the MPMService Website in the IIS Management Console:


Click on Authentication, then Windows Authentication, and then Advanced Settings:


Un-tick “Enable Kernel-mode authentication”:


Click “OK” and then click on “Providers”:


Add “Negotiate:Kerberos” and remove all other Providers:


Click OK. Then browse back to the MPMService Website in the IIS Management Console, and ensure that under SSL Settings, “Require SSL” is selected:


Click “Apply” and then close the IIS Management Console.

Setting up the Self Service Password Reset Server

Before running the setup of SSPR, you’ll need two service accounts ready for use. I’ll cover off the permissions needed for each account later on in this post:

Account Name Usage Function
svc-ssprdataprox Data Proxy Account Reads and Writes data to the Store.
svc-ssprselfservice Self-Service Account Unlocks accounts and resets passwords on user AD Objects.



To start the SSPR setup process, log onto the server running SSPR and click on “Citrix Self-Service Password Reset Configuration”:


The console then loads are you are presented with the following:


Before any configuration, we need to create a central store, as per the Citrix Article http://docs.citrix.com/en-us/self-service-password-reset/1-0/install-configure.html

To do this, use the Server Manager console, and then click on “File and Storage Services”, and then “Shares”:


Click on “Tasks” and then “New Share…”


Continue with the “SMB Share – Quick” option:


Select “Type a custom path”:


Then create a new folder – mines call “SSPRShare” below and click “Select Folder”:


Click Next, and then type the share name as “CITRIXSYNC$” and click Next:


Select “Access Based Enumeration”, uncheck “Allow caching of share”,  and select “Encrypt data access”:


Click Next and then “Customise Permissions”, and then “Disable Inheritance”:


Select “Convert inherited…”, and then remove all users except for CREATOR OWNER, SYSTEM, and the Local Administrators Group:


We then need to modify the permissions assigned to creator owner, so that the permissions are as follows:


We also then need to add the Data Proxy Account we created earlier with Full Control of the Share. And Also the NETWORK SERVICE account with Read Permission:


Once this is done, we create two subfolders “CentralStoreRoot” and “People”. The Data Proxy Accounts requires full control of these folders:


Once this is done, we can go back to the SSPR Setup Console:


Click on “Service Configuration”, and then on “New Service Configuration” on the right hand side:


We have already setup the Central Store, and installed an SSL Certificate – so we can press next, and enter the UNC path to our Central Store:


Press “Next” and then tick the correct Domain, and select “Properties” – for this guide I will be configuring a single domain only for SSPR. Then we need to enter the details of the Service Accounts we created:


Enter the Account Details and press OK, and then press Next. The SSPR Password Reset service is then created:


Click on Finish, and then we are taken back to the Console. Next we need to create the user configuration, by selecting the User Configuration pane, and then clicking “New User Configuration” on the right hand side. We can now choose an LDAP Path or an AD Group for the users eligible for Self Service Password Reset – I’m choosing an AD group 🙂


Click on Next, and enter the License Server Name:


We can now configure the options users will have when using the service – either a password reset, and/or the ability to unlock their account. I’m going to allow them to use both. Also, we need to enter the URL to the SSPR Service, which in my case, is the server name:


Then we can click “Create” and the User Configuration is created. Next we move into Identity Verification – this is where the questions come in!

Back in the main console, click on “Identity Verification”, and then “Manage Questions” on the right hand side. We then need to select the Default Language, and choose whether to mask answers. I’m going to use English and choose not to mask answers for this Lab Setup:


After clicking “Next”, we can customise the questions and add more or create a new Group of questions. I’ve customised a couple of the default questions for demonstration purposes:


Once you are happy with the questions created, click “Next”, and the ordering of questions can be adjusted. Once happy – click Finish, and the configuration is completed.

Delegation of Active Directory Rights for the Self Service Account

Before we can setup StoreFront to use the SSPR Service, we need to delegate permissions to the AD Account used for Password resets and account unlocking – the Self Service Account. We will do this in Active Directory with the Delegation of Control Wizard. Note: you will need to delegate to control to all OUs where users of the SSPR system reside.


First, we select the Self Service account we have created:


And then click “Next”:


Select “Create a custom task to delegate”. Then select “Only the following objects in the folder” and select “User objects”:


In the next window select “General” and “Property Specific”:


Ensure that the following permissions are checked, and then press next:

  • Read lockoutTime
  • Write lockoutTime
  • Reset Password
  • Change Password
  • Read userAccountControl
  • Write userAccountControl
  • ReadpwdLastSet
  • WritepwdLastSet


Click “Finish” and then the delegation has been setup for the Self Service Account. We can now move on and configure Citrix StoreFront.

Configuring Citrix StoreFront for Password Self Service

To begin, open the StoreFront Console, and visit the Store you wish to add the SSPR Site to:


Then click on “Manage Authentication” on the right hand side:


Click on the settings option next to “User name and password”, and then select “Configure Account Self-Service”:


Next, choose “Citrix SSPR” from the drop down list:


And then press “Configure”. Then tick the boxes for “Enable password reset” and “Allow account unlock”, and then enter the URL to the SSPR Server:


Click OK 3 times, until you are back to the main StoreFront Console.

SSPR is now setup – and we can test with a user!

SSPR Signup Process and Testing

Now we have SSPR setup – we can begin the signup process and start testing. To do this, log into StoreFront with a user account that is a member of the AD Group we assigned in the SSPR Console (SSPR_Users in my case). You will then see the following extra “Tasks” option when you are logged in:


When we click on tasks, we can enroll in the Self Service Password Reset system:


Click on “Manage Security Questions” – before we can proceed we are required to authenticate again:


We will now see the security questions we defined earlier – and can provide answers:


Once these have been completed – we are presented with the following screen:


This means that the user is now enrolled and can use the Self Service Password Reset system.

Testing Self Service Password Reset:

Now that we have enrolled – we can make use of the SSPR System. If we visit the StoreFront website we also see an additional section of the login screen, labelled as “Account Self-Service”:


When a user who has forgotten their password visits the site, they can click on “Account Self-Service” to start the password reset process. For this test I will assume the role of a user who has forgotten their password. So I clicked on “Account Self-Service” then then selected the “Reset password” option:


After Clicking “Next” I am presented with the following screen, where I enter my username in the format domain\username, and then click “Next”:


After this, I am presented with the Questions that we previously setup, and answered for this test user:


After answering all 4 questions, I am presented with a change password dialogue:


A new password can be entered and “Reset” pressed:


The user’s password has now been changed, and we can login to our published resources – all without the need for any helpdesk calls.