Introduction
When implementing software, an organization usually wants to go for the DTAP approach (Development, Testing, Acceptance and Production). An application gets developed for the specific organization in the Development environment. The version is then tested in the Testing environment. After that de customer/(key-)users can approve of it in the Acceptance environment and when successful it can be deployed in de Production environment.
This method defines specific steps in the development of a new application or an update of a current one. It also reduces the risk of downtime when developing or testing the new application.
Can you use this approach in combination with RES ONE Workspace?
RES ONE Workspace with DTAP
RES ONE Workspace (ROW from here on) of course has the very useful Workspace Containers. You could create a DTAP setup on that level. This should suit you for about 90% of all your workspace related changes.
But what if you want to test a new ROW Service Release? Or even an upgrade to a complete new version? While I have RES in really high regard, most new versions do usually have some quirks in them and because of this, testing is in order.
So how would you use the DTAP approach in this situation? Sometimes when you upgrade the database also gets an update. The DTAP approach on the Workspace Container level doesn’t work in these situations since the update is on a higher level.
The only viable solution to use DTAP is on the database level. That means a dedicated ROW database for each environment. This way, you can perform the upgrades in DTAP order and remove the risk of downtime on the production environment.
Solution
But how do you control which machines connect to which database? You don’t want to create different images for each database and you probably don’t want to change it manually whenever you boot your machines. Also, when you create a new image for your virtual desktop you might want to put that through the DTAP process as well.
While this approach sounds a bit obscure, I’m writing about it because a customer has this exact approach and with the right amount of discipline it can work very well (The discipline to keep the databases in sync with each other, which is harder than you might think).
But back to business, how to control de database connection. The solution is pretty simple, but it does requires some common sense. For the customer we used three databases (Development, Acceptance and Production) instead of four (Development is also used for testing). We created three Group Policy Objects that are each linked to the matching Active Directory Organizational Unit (one for each environment).
Now what should you put in these GPO’s. Actually just the registry settings.
ROW puts the database connection information in the registry under the following key:
HKEY_LOCAL_MACHINE\Software\RES\Workspace Manager (32-bit)
or
HKEY_LOCAL_MACHINE\SoftwareWow6432Node\RES\Workspace Manager (64-bit)
All values that start with the letters DB are needed for the database connection. These need to be added for each database to the corresponding GPO.
You can do this in the GPO under Computer Configuration -> Preferences -> Windows Settings -> Registry. The easiest approach is to use the Registry Wizard. With it you can connect to a machine that is connected to the specific database and copy the registry values from there.
Seems easy enough, doesn’t it?
However, when a Windows machine boots the RES ONE Workspace Agent service starts at about the same time as when the GPO is applied. So when the service starts the registry settings might not be there yet. To work around this you need to change the startup type of the RES ONE Workspace Agent service to Automatic (Delayed Start).
You could include this in the same policy, but the machine would require an extra reboot for the service to actually start in a ‘delayed’ manner. You would set this in the GPO under Computer Configuration -> Preferences -> Control Panel Settings -> Services.
When using Citrix XenDesktop (Machine Creation Services or Provisioning Services) for your image deployment, it wouldn’t be an option to go down the GPO road for the service. Because after each reboot the setting would be back to default. In this case you should alter the service in the Master VM (MCS) or vDisk (PVS).
Or, better yet, add it to your Master VM/vDisk creation process (assuming you have such a thing in place, but you know you should).
Keep in mind though, that you might want to change the startup type of your ‘virtual desktop’ service to ‘delayed start’ also. This is to solve the problem of your users connecting to the desktop when the ROW service is not running yet. So with XenDesktop 7.x for example this would be the ‘Citrix Desktop Service‘-service.
Summary
1. Create a GPO for each environment
2. Link these GPO’s to the corresponding Active Directory Organizational Units
3. Import the values starting with DB from the key mentioned earlier
4. Change the startup type of the RES ONE Workspace Agent service to Automatic (Delayed Start) (through GPO or in your image)
5. (Optional) Change the startup type of your Virtual Desktop service to Automatic (Delayed Start)
That’s it. It might not be the most elegant approach but it does the job. If anyone has a better idea to implement DTAP in combination with RES ONE Workspace, let me know. I am very interested in other ways to accomplish this.
Now to find that discipline to keep the datastores in sync…
Edit:
Unfortunately, I forgot to add something. When de RES ONE Workspace agent is already configured on the machine that will receive the GPO, you need to remove the following specific key to make sure the ROW agent will connect correctly to the other database.
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\RES\Workspace Manager\UpdateGUIDs
This will clear any registry information from the previous connected database.
If you use a script to ‘seal’ your image, you might want to add something to it along the lines of:
REG DELETE “HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\RES\Workspace Manager\UpdateGUIDs” /f
Or do it in another way more to your liking.
