Sluggish Windows 7/2008 - XenServer 6.1

Please check out www.kaztechsolutions.co.uk for more of my technical posts, alternately please call us on 01932 268289. 

If you get any issues with sluggish Windows 7 VM’s on XenServer 6.1 ensure you have the following hotfixes applied to the XenHost and then upgrade the XenTools on all VM’s after the Hotfixes have been applied.

XS61E003

XS61E004

XS61E006

XS61E008

XS61E009

XS61E010

Also other possible MS issue could be related to the following - http://support.microsoft.com/kb/2617858

KMS with VDI

Please check out www.kaztechsolutions.co.uk for more of my technical posts, alternately please call us on 01932 268289. 

Anyone doing VDI at somepoint will have to deal with MS licensing and the joys of KMS!  Now if you haven't done it before and you start to read about it on the Technet and what not apparently its really easy to setup and all you need is 25 unique connections to the KMS host to start activating Windows 7 and 5 unique connections for office 2010.  RUBBISH - there's loads of little "gotcha's" that both MS and Citrix don't make you aware of.  

Hopefully this will help a few people out with the pain that is KMS...!

Setting up the KMS Host

NOTE: Always run a CMD in elevated mode.

• Designate a KMS host – has to be 2008 R2 or Windows 7. (You can use 2003... If you have too.)
• Get KMS host key from your MS volume licensing site. DO NOT USE THE KMS CLIENT KEY!
• Run a cscript slmgr.vbs /dlv and you'll see that the KMS Host is currently using a KMS Client key.
• Run cscript slmgr.vbs /ipk XXXXX-KMS-host-key-XXXXX.  This changes the licensing mode to be a KMS Host instead of a KMS Client.
• cscript slmgr.vbs /ato to activate your KMS Host against your MS volume licensing.
• After activating the KMS key, restart the Software Protection Service.
• Re-run a cscript slmgr.vbs /dlv to see the current KMS count is 0 and you'll also notice that the licensing has changes to a KMS Host.

Setting up a KMS Client

• On the golden image if you have changed the license key to a MAK change back to a KMS client key.  Windows automatically comes using a KMS client Key but if you need to change it back use the key from the KMS Client Key website.  DO NOT ENTER THE KMS HOST KEY IN TO A CLIENT!
• On the golden image type the following command to verify the DNS SRV Record: nslookup –type= srv_vlmcs._tcp
• Check that you can ping the KMS host.
• Attempt Windows 7 KMS Client activation using the following command: slmgr.vbs /ato
• The activation attempt will fail with an error that the activation count is insufficient, this is fine but check on the KMS Host that it has received the request by running a cscript slmgr.vbs /dlv on the designated KMKS Host and the count should be 1.
• Since KMS requires 25 unique activation requests to activate the clients spin up 25 desktops.
• VDI-in-a-Box ensure that the activation timer is enabled within the template and for XenDesktop PVS install ensure that the vDisk is set to KMS.

• Now a KMS client will automatically try to register against the KMS host using the DNS SRV record but you can speed this process up by using the VAMT 2.0 to force the activation.   Select 25 or more VM’s and choose to active via KMS.

• Run a cscript slmgr.vbs /dlv to see the current KMS count should be above 25, all other windows 7 VM’s will now rergister.

Setting up Office 2010

• For office make sure that the KMS host has the Microsoft Office 2010 KMS Host License Pack installed along with the KMS Host Office 2010 key from the your MS volume licensing site.
• On the golden image make sure that the Office 2010 installation have the KMS client key and like Windows 7 Office 2010 comes with a KMS Client key.
• From a CMD run a cscript ospp.vbs /dcmid from C:\Program Files (x86)\Microsoft Office\Office14 to see the CMID.
• Start a new CMD and run the following command to allow access to run the Office rearm correctly - icacls C:\ProgramData\Microsoft\OfficeSoftwareProtectionPlatform /grant "Network Service:(OI)(CI)(R,W,D)" /t.
• Start a CMD and run a OSPPREARM.EXE from C:\Program Files (x86)\Common Files\microsoft shared\OfficeSoftwareProtectionPlatform and this will clear the CMID.
• Rerun a cscript ospp.vbs /dcmid and you'll see the CMID is now cleared.
• Save and/or publish image so that it is now live, if you are using VDI-in-a-Box make sure you tick the "reset activation timer" in the template.
• Activate Office 2010 on 5 desktops by running a CMD from  %programfiles(x86)%\microsoft office\office14\cscript ospp.vbs /act (note: activation will fail for the first 5 desktops and you can also use VAMT 2.0 to do this.)
• Veryify that unique CMIDs are created for each desktop by running %programfiles(x86)%\microsoft office\office14\cscript ospp.vbs /dcmid
• On desktop number 6, KMS activation should work without errors.

I hope this help a few people out and if i get some time I'll put some screenshots of the commands being run just to give a little bit more help.

Troubleshooting Tips
if you have to re-enter a office KMS key as you are currently using a MAK use the following command from %programfiles%\Microsoft Office\Office14.

 cscript ospp.vbs /inpkey:

Thanks

Citrix Access Gateway - Recovery Mode

Please check out www.kaztechsolutions.co.uk for more of my technical posts, alternately please call us on 01932 268289. 

I had an issue this week where I'd setup a XenDesktop environment and everything was looking good and internal testing showed everything was working as it should be.  I moved on to the configuration of the CAG VPX and after configuring just the hostname, Licensing, STA, Access List, Logon Points and the Date and time the CAG would restart it self over and over again until it went in to Recovery Mode.

Upon troubleshooting I started to configure the CAG bit by bit and I found that once I configured the STA the CAG would then restart - very strange.

So I enabled logging on the DDC using the Log EnablerV3 and I could see that I was getting STA error's logged in the broker log, so i started to think that this must have been a dodgy install even though XD installer didn't highlight anything once it had finshed.

So I had a quick peek in the registry and i could see under the following key that the STA identifier wasn't created correctly.

HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\DesktopServer

So I re-ran the Broker_Service_x64.msi from the XD iso and then refreshed the registry and I could now see that the STA identifier was now correctly configured in the registry.

Hope this helps someone out.

1030 Connection Error - VDI-in-a-Box

Please check out www.kaztechsolutions.co.uk for more of my technical posts, alternately please call us on 01932 268289. 

Had an issue the other day on VDI-in-a-Box 5.1.1 where remote access was through a CAG 5.04 and i was getting the dreaded 1030 error!

Checked all the usual places to check for a 1030 error.

• Is the STA generated from the vdiMrg in the CAG.
• Used an SSL checker to see if the SSL was created correctly.
• Checked that the vDesktop DHCP range is in the ICA access control list on the CAG.
• CHecked that the correct ports are opened up on the firewall.

just to name a few.

If you log in to the vdiMgr console and go to advance properties and look under gateways ensure that you have specified the "Internal HDX gateway IP Addresses" which HAS TO point to the internal IP address of the CAG.

A way you can test if you 1030 error is because the "Internal HDX gateway IP Addresses" is wrong is by downloaded and saving the ICA file and seeing if it has been marked with the internal IP address of the vDesktops rather than with the STA.

VDI-in-a-Box - Best Practices

Best Practices: Scale One by One

Creating the VDI-in-a-Box Grid

• Start with one server then expand, or one image then expand
• Scale the grid one server at a time
• Keep host versions consistent
• Assign static IP addresses to servers
• Use of thin provisioning to cut down dramatically on disk space
• Size your server using recommended best practice
• Ensure that you can generate desktops and users can log on before adding a second or third or fourth server to the grid.

Joining servers to the Grid

• Do not join multiple servers at the same time
• Let the second server join, receive images, provision desktops before joining the third

Use IP addresses instead of DNS names

• To remove the dependency on DNS
• For setting up the hypervisor connection
• For the vdiManager console when configuring the Grid
• For the Active Directory User database connection

Create a base image

• Start with an ISO to create a base published image
• Test this base image first and use this to make additional copies for production
• Keep image sizes small (20-30GB). Less storage space consumed
• Create one domain administrator account for both user authentication (Active Directory) and for image syspreps
• Minimize password changes to accounts. You can do this by creating special “Citrix” accounts

Ports

• vdiManager <> Hypervisor | HTTP over SSL/TLS (HTTPS):443
• vdiManager <> Active Directory | LDAP:389 | LDAP over SSL/TLS (LDAPS):636
• Endpoint <> vdiManager | HTTP over SSL/TLS (HTTPS):443
• Endpoint <> Secure Remote Access (CAG VPX) |HTTP over SSL/TLS (HTTPS):443
• Desktop Receiver <> Virtual Desktop | ICA:1494 or 2598 RDP:3389

Logins and username and passwords

• Management COnsole https://vdiMgrIPaddress/admin - Account: vdiadmin/kaviza
• VDI-in-a-Box appliance logon (vdiMgrIPaddress) - User: kvm/kaviza123|User: root/kaviza123
• User logon from a web browser https://vdiMgrIPaddres
• User logon from the Java Client http://vdiMgrIPaddres/dt/vdiclient.jnlp
• User logon from mobile devices http://vdiMgrIPaddres/dt/PNAgent/config.xml