Author: siteadmin

Posted on

Workspace Manager, Aero Basic Theme and Mandatory Profiles

For those of you that have attempted to deploy RES Workspace Manager 2011 (or RES PowerFuse 2010) on Windows 7 and wanted to use Mandatory Profiles with the Windows Aero Basic experience, you might have come across this issue. If you utilise the standard .Default user profile as your starting point for the Mandatory profile, you may discover that users do not have the Aero theme enabled as expected. The user experience either on traditional physical or hosted virtual desktops may look something like this:

image

Note: This typically happens if you enable the “Disable Active Setup (skip first-time shell init)” option in Composition > Desktop > Lockdown and Behaviour section of the RES Workspace Manager management console. This presumably because by the time User Settings are loaded by RES Workspace Manager, the Themes service has already processed the required registry keys loading the (mandatory) profile.

The resolution to this is to enable the Aero theme when utilising the Mandatory profile and export the HKCU\Software\Microsoft\Windows\CurrentVersion\Themes and the HKCU\Software\Microsoft\Windows\CurrentVersion\ThemeManager registry keys. These can then be merged into the existing NTUSER.MAN registry hive to enable the Aero theme by default (see the Updating Mandatory Profiles post for further information on how to do this).

When you update the Mandatory profile with the Themes/ThemeManager settings you’ll end up with something like this:

image

Note: This process is also applicable for Windows 2008/R2 RDS servers with the Desktop Experience feature installed.

Easy when you know how! Iain

Posted on

Updating Mandatory Profiles

[UPDATE 17/01/2012 – The process detailed in this post has been simplied in the Updating Mandatory Profiles Part 2 post]

In a RES Workspace Manager environment it’s is typical (although not required) to store Mandatory profiles within the RES Workspace Manager Custom Resources. By doing this, we remove any reliance on the network, avoid the typical profile error messages when logging on to laptops offline and reduce the network load on RDS/XenApp servers. Every once in a while there will be the need to update the NTUSER.MAN file with additional settings, e.g. the ActiveSetup keys when software is added to the RDS/XenApp servers.

In this example we will update the Mandatory profile with the ActiveSetup keys from our desktop image. We accomplish this by logging on to the desktop with our standard Mandatory profile (the Workspace Composer should not active at this point!). All being well, the ActiveSetup components should run on log in, populating the ActiveSetup registry keys.

After ActiveSetup has run we can launch REGEDIT from within the user session and export the required key(s) to a .REG file that we can import into the Mandatory profile later. To do this, navigate to HKCU\Software\Microsoft\ActiveSetup\InstalledComponents registry key and export to a .REG file.

image

In our example I’ve saved the file as ActiveSetup.REG. If we edit this file with Notepad we can see all the references point to HKEY_CURRENT_USER. Before we load the NTUSER.MAN registry hive, we need replace the HKEY_CURRENT_USER references with the hive name that we will mount it as with in REGEDIT. In our example, we’ll replace all references with HKEY_USERS\MANDATORY using Notepad’s “Find & Replace” functionality.

image

Once updated, we can save the ActiveSetup.REG file and launch REGEDIT once again. The Mandatory profile NTUSER.MAN hive can be loaded by clicking the HKEY_USERS hive and then clicking the File > Load Hive menu option.

image

Navigate to the Mandatory profile NTUSER.MAN file and when prompted for the Key Name we need to enter the same key we used in the File and Replace option earlier. In our instance, this needs to be MANDATORY, hence the HKEY_USERS\MANDATORY reference.

image

Once the hive is loaded we can import our modified ActiveSetup.REG file into the NTUSER.MAN hive. Once the import is complete you can confirm that the settings have been imported into the correct location:

image

Be sure to unload the registry hive by clicking the HKEY_USERS\MANDATORY key and then clicking File > Unload Hive. When prompted to save the changes make sure to click Yes. When you log off and back on again the ActiveSetup components should not run again. Note: if you install additional software on to the desktop image and it utilises ActiveSetup, you will need to perform this process again (unless you utilise the RES Workspace Manager “Disable Active Setup (skips first-time shell init)” option).

Good luck! Iain

Posted on

Automation Manager Dispatcher Discovery and WoL

RES Automation Manager agents are configured to auto discover an available Dispatcher by default, but this will cause issues when the Dispatchers are located on another LAN segment or VLAN. In addition, the Wake on LAN (WoL) packets won’t generally be forwarded by switches/routers by default either. Therefore, how do we resolve this little conundrum?

Now I’m not a network engineer. I can configure basic switch ports and VLANs on HP/Cisco switches, but I couldn’t tell you how BGP works its magic to keep the internet running. I know what it does, but I’ve no idea how it does it. When requesting network infrastructure changes to support the Dispatcher discovery process and WoL on a customer’s site, the network engineer typically wants to know exactly what needs configuring. By simply saying, “enable Multicast for discovery and Broadcast for WoL throughout the network” generally puts a network engineers in a panic and they break out in a cold sweat! So what are these “exact requirements” that network engineers speak of?

Dispatcher Discovery

The RES Automation Manager dispatcher discovery process utilises Multicast. In its simplest form, there are devices on the network that subscribe/listen to a multicast address. When packets are sent to this multicast address, they are forwarded to devices that are actively listening or are members of the group. This process eliminates broadcast storms on the network that could otherwise exist by being selective about whom receives the packets.

In RES AM terminology, when a Dispatcher comes online it will attempt to register to receive UDP packets on the 224.1.1.150 Multicast address on UDP/3163. When a RES AM Agent comes online, it broadcasts via UDP on port 3163 to the multicast group, address 224.1.1.150. Hopefully the dispatchers receive the request, and one responds. Therefore, when speaking to network administrators, you need to ensure that IGMP/PIM is enabled on all network equipment that RES AM Dispatchers and Agents are connected to and that the Multicast 224.1.1.150 address is permitted.

WoL

The WoL process works completely differently in that the “magic packet” needs to be broadcast on the LAN segment that the targeted machine is connected to. In RES Wisdom 2009 (and prior) global broadcast packets to 255.255.255.255 needed to be permitted from all RES Wisdom Dispatchers to all LAN segments that client machines were connected to. Needless to say that this is inefficient and network admins are generally reluctant to enable it.

In RES Automation Manager 2011 we’ve got a shiny new Global Option available to us:

image

This option will use Subnet Directed Broadcasts (SDB) for all WoL packets. The last network hop will broadcast on the targeted subnet without flooding network (unlike the global broadcast address). Like the Discovery process this requires Layer 3 network switches to be implemented and SDB enabled. Note: care needs to be taken when implementing as this could enable DDoS attacks. Remember to limit the origin of the SDB packets to only RES Automation Manager Dispatchers from UDP/3163 (by default) to the subnets that each Dispatcher needs to broadcast to.

If anyone knows the specific Cisco/HP terminology that needs to be used to avoid ambiguity then please let me know and I’ll update the post. Thanks, Iain

Posted on

Assigning static IP addresses when using XenApp and Provisioning Server

Ok so you’ve now decided what a really cool product Citrix Provisioning Server (PVS) is and have decided to use it to stream the OS to your XenApp servers. I’m assuming here you already have the PVS infrastructure in place and have created the image of your XenApp server onto a vDisk.

Now when using PVS inconjuction with a virtual desktop solution it’s well documented that you can use DHCP scope options 66 and 67 to locate the relevant Provisioning Sever and bootstrap file; which will allow PVS to stream the image; where the virtual desktops are allocated a dynamic IP address from DHCP.

Great we say now let’s use this technique for our XenApp servers…..mmm but we want our XenApp server to have static IP address; not one dynamically assigned from DHCP.

From what I’ve seen this isn’t very well documented but is a very real life example of how organisations do things.

One way of doing this that first springs to mind would be to create a bootable PVS ISO that contains the IP address of the XenApp server etc. I’m not a fan of this because you would need an ISO per XenApp server amongst other things.

The best, most controlled and visible method to do this would be to use reservations in DHCP based on a specified MAC address i.e. the one used in the PVS target device properties.

The basic steps to achieve this are:

  1. Create a DHCP scope limiting the range to the IP address of your XenApp servers i.e. 192.168.0.1 – 192.168.0.20 if you don’t already have one.
  2. Be sure to set the DHCP scope options required by PVS i.e. 66 and 67, if they haven’t already been set at the server level.
  3. Set the lease to be unlimited as they are reserved by the MAC address.
  4. Once you have created the scope then add the reservations entering the Reservation name (XenApp server name), MAC, IP and Description.

 You might think about duplicating the same scope on another DHCP server for fault tolerance remembering to add in the reservations and deactivating the scope otherwise you will get conflict errors. Only activate the scope should your other DHCP server fail; after this you are good to go.

Posted on

Migrating GPOs to RES Workspace Manager (Part 6)

Taking the Merging ADM files (Migrating GPOs to RES Workspace Manager – Part 5) blog post to the extreme, here is a demonstration of merging all the default Windows 7/2008 group policy ADMX files. By default there are 148 separate ADMX files that make up the “default” GPO settings available within the Group Policy Management Console (on Windows 7). If we needed to recreate these in RES Workspace Manager we would need 148 separate Registry Policy objects . Each Registry Policy object within the RES Workspace Management Console can only be based on a single ADMX file. Believe me, this is not pretty. Note: It’s not recommended that you do this and this example is for demonstration purposes only. Only merge the ADMX files that contain the options you need to set!

What follows is how we can create one (albeit very big) ADMX/L file that can be uploaded into RES Workspace Manager.

  1. Open the Virtual Engine Toolkit.
  2. Select the “Merge ADMXs” tab.
  3. Drag’n’drop all the ADMX files in the default “C:\Windows\PolicyDefinitions\” folder (when run on a Windows Vista or later computer) into the top window.
  4. Specify the output location directory.
  5. Specify the output filename (the ADMX and ADML file extensions will automagically be added).
  6. Click the green “Toolkit” button (and wait!).

image

On my laptop this took approximately 30 seconds and resulted in a combined 4.27MB “Win7_Defaults.ADMX/L” files. Load this into the RES Workspace Manager Management Console (it takes a little while!) and it looks like this:

image

Simple! And there’s more to follow…

Posted on

Migrating GPOs to RES Workspace Manager (Part 5)

Deploying new GPOs via RES Workspace Manager is incredibly simple. Unfortunately, as was highlighted in Migrating GPOs to RES PowerFuse (Part 1), it can be messy due to each RES Workspace Manager registry policy can only being based on a single ADM or ADMX/ADML file. A single Office GPO (if implemented via RES Workspace Manager registry policies) could look like this:

image

Opening the ACCESS14.ADM policy within the RES Workspace Manager Management Console only provides us with the ability to control the Access 2010 settings, e.g.

image

If we need to apply different settings for different users then we have to duplicate the required ADM/X policies and assign the access control as required. Over time this becomes increasingly hard to manage. With the updated Beta 2 release of the Virtual Engine Toolkit (VET) we can merge ADM files or ADMX/L files into a single file. This enables more effective use of RES Workspace Manager registry policies rather than having lots and lots individual policies. This in turn means a more simple model of administration and control. Note: it is still recommended that registry policies be applied at the application level rather than globally. The example used here is for demonstration only!

The Virtual Engine Toolkit will only extract and merge the “USER CLASS” and “[Strings]” entries within the ADM files. It does not merge the “CLASS MACHINE” entries in any way. Once you’ve downloaded the Virtual Engine Toolkit (registration is required), fire it up and navigate to the “Merge ADMs” tab.

image

Once you have the “Merge ADMs” tab open, perform the following:

  1. Drag’n’drop all the required ADM files into the top box.
  2. Select your file output location.
  3. Specify the filename (no need to append .ADM as the Toolkit will do this for you).
  4. Click the Toolkit button in the bottom right.

image

If all goes well then you should see something like this signifying that everything worked OK:

image

The “Merged_ADMs.adm” file can now be uploaded into RES Workspace Manager directly (it might have been better to call the merged ADM something like “Office2010.adm”!)

Now when we edit the the Merged_ADMs.adm registry policy it should look a little more intuitive! It’s a lot easier to manage settings for various groups of users when all settings are in one place. Remember that we can also do this with ADMX/L files too (in Part 6).

In the RES Workspace Manager Management Console all the settings are in one place and now look like this:

image

Posted on

Migrating GPOs to RES Workspace Manager (Part 4)

Here is the story thus far. In Part 1 we discussed the issues with the RES Workspace Manager implementation of ADM/X templates and whether this is a good or a bad thing. The answer is, “it depends!” Part 2 detailed the locations of the existing Group Policy Objects (GPOs) and the REGISTRY.POL files. The last post (Part 3) we explored the REGISTRY.POL file format and the available options for extracting the resulting registry settings stored within.

Hail the release of the updated/new Virtual Engine Toolkit BETA 2 (registration required)! This update now incorporates the ability to create a .REG file from the GPO REGISTRY.POL file that we can import directly into RES Workspace Manager. We lose the ability to browse the ADM/ADMX structure hierarchy and view the explanations, but we do now have the ability to import existing GPOs without having to manually transition the settings!

Note: This is still a Beta product so please be careful and test, test and test again! If you have any issues please use the contact form on the website.

To migrate a GPO you will need to know where it is located and which REGISTRY.POL file to use and to add to the confusion all GPOs have a REGISTRY.POL file. To locate the correct REGISTRY.POL to import we  first need to find the GUID of the existing GPO:

  1. Open the Group Policy Management Console.
  2. Locate and edit the GPO we wish to migrate.
  3. Right click the <GPO NAME> in the left hand pane and select Properties from the resulting context menu.
  4. The GPO’s GUID will be displayed next the Unique Name entry (highlighted below).

image

Now we have the GPO’s GUID we can locate the correct REGISTRY.POL by performing the following:

  1. Launch the Virtual Engine Toolkit and select the “Convert POLs” tab.
  2. Click the ‘…’ button to browse for the REGISTRY.POL file (next to the .POL File Location text box).
  3. Open the ‘\\<DOMAIN FQDN>\SYSVOL\<DOMAIN FQDN>\Policies’ folder.
  4. Select the folder that matches the GPO GUID found earlier.
  5. Open the ‘User’ folder (this contains the User Configuration settings of the GPO).
  6. Select the ‘REGISTRY.POL’ file.
  7. Select an output location to save the .REG file in the ‘REG File Output Location’ text box.
  8. Give the file a name in the ‘REG Output Filename’ text box (the .REG extension will be added automagically).

It might look a little like this:

image

Note: It is possible to import the Machine (Computer Configuration container) REGISTRY.POL file and there are no checks enforced to stop you doing this. Within the REGISTRY.POL file is nothing to define whether the registry settings are User or Machine based, i.e. no HKLM or HKCU differentiators. The Virtual Engine Toolkit assumes that they’re User based and adds the HKCU text to the resulting .REG file manually.

Click the green “Toolkit” icon to create the .REG file. If all is well you should see something like this:

image

Now we can create a new Registry configuration object and import our .REG file into the RES Workspace Manager Management Console. If you browse the registry settings you should see that the resulting GPO settings have been migrated, in place exactly as they where configured in the GPO!

image

Posted on

Virtual Engine Toolkit BETA 2 Released

The Virtual Engine Toolkit BETA 2 (VET) has been released and can be downloaded from the web site here. This tool is free and will always be free although registration is required. At present there is currently no help available within the BETA 2 download so there will be a lot of blog posts to explain how all the features work to allow you to get you up to speed promptly.

So what does the Virtual Engine Toolkit do and what is its purpose?

The Virtual Engine Toolkit was originally developed (as the Building Block Spinner) to help automate the process of moving RES Workspace Manager Building Blocks between two domain environments. For example, you may have a development or test infrastructure that the RES Workspace Manager configurations are built/tested in and a live/production environment that is servicing your users. If our test and live databases are configured against the same Active Directory domain then they can typically be imported directly into the second environment. This scenario is covered in more detail in the Building Block Spinner (BETA 1) post.

This tool has since been extended to help with migrating and implementing Group Policy Objects within the RES Workspace Manager Management Console. The development won’t stop here so keep an eye out for future releases and future blog posts!

How can the Virtual Engine Toolkit help me?

The Virtual Engine Toolkit allows an administrator to specify different domain names for each of the two environments and select multiple Building Block files. When run it will create two sets of Building Blocks; one for the test environment and one for the live environment. Once the process is complete the Building Blocks can be loaded straight into the RES Workspace Manager Management Console. This saves you from having to perform a find and replace on each individual Building Block file which is both time consuming and error prone.

Existing Group Policy Objects (GPOs) can be converted in to .REG files for importation into RES Workspace Manager. This functionality mitigates the requirement of having to manually recreate existing GPOs within the RES Workspace Manager console.

Group Policy definition (both ADM and ADMX) files can be merged into a single file for more simple, logical management within RES Workspace Manager.

What next?

There are some additional use case scenarios for all you RES Workspace Manager consultants out there but we’ll save them for a future post. If you have any feedback, have found a bug or would like to see additional functionality put into the product then please Contact Us via the web site.

Posted on

Remote Assistance Troubleshooting

With any VDI technology that leverages Microsoft’s RDP (Quest’s vWorkspace and VMware’s View) deploying Microsoft’s Remote Assistance (RA) is a requirement for support as the typical remote console solutions do not work as originally intended. RES integrated the Remote Assistance technologies with the release of RES PowerFuse 2010 (Service Release 1?) and as a result we’re seeing more people attempting to integrate Remote Assistance with their VDI deployments. There are few things that can, and do go wrong.

RES Workspace Manager will configure the Remote Assistance registry settings on the local computer via the RES Workspace Manager agent without requiring Group Policy Objects or manual configuration of the registry. This includes ensuring that RA is enabled, the firewall ports are open and the RA Helper Active Directory accounts are populated with the specified groups. Once a Remote Assistance session is offered by the administrator via the RES Workspace Management console, this is handed off to the underlying infrastructure and RES Workspace Manager has nothing more to do with the remote session. If you’re having problems with Remote Assistance you might want to double check the following.

Local Helper Account

Ensure that the local HelpAssistant account is not disabled (on Windows XP). This account needs to be enabled on both the machine offering the Remote Assistance session and the target machine. If this is not enabled on the source computer, you may receive the “There is a problem with the invitation and it cannot be opened. To use Remote Assistance, the sender of this invitation will have to send you a new invitation.”

Remote Assistance HelpAssistant Error

Windows XP Help and Support Service

Double check that the “Help and Support” Service is enabled on Windows XP machines. There may be an old Group Policy Object somewhere that has disabled this and without this running, Remote Assistance is not going to be going anywhere! This service has been deprecated with Windows Vista and Windows 7.

DNS

The standard name resolution process is used to contact the destination computer when a Remote Assistance session is initialised. We have seen issues in VDI environments where the DNS records for desktops become stale. Here is a particular example:

  • VMware View is deployed with linked clone technology.
  • As VDI is booted it registers in DNS for the first time.
  • When the VM is recomposed it ends up with a new computer SID/MAC address but the same hostname.
  • The VDI attempts to update the DNS record but can’t because the SID associated with the DNS entry is incorrect.
  • If the RES PowerFuse console is located on a different subnet to the destination computer, Remote Assistance fails.

To ensure this isn’t a problem, make sure the computers are shutdown cleanly (and double-check their DNS entries are removed) before recomposing!

Virtual Engine Limited
450 Brook Drive, Green Park, Reading RG2 6UU