After further testing today, it appears setting KMS via the Imaging Wizard resolves the duplicate CMID issue. Here’s the method we used to capture the initial vDisk (assuming XenApp 6.5 is installed – mentioning this as it referenced later – on the golden image VM as well as the PVS 7.6 target device software):
· Run the Imaging Wizard on the golden image VM
§ Enter the appropriate server address and credentials
§ Create new vDisk
§ Enter a name for the vDisk and select vDisk type (we use dynamic – 2MB block size)
§ Select “Key Management Service (KMS)” at the Microsoft Volume Licensing screen – This appears to be what fixed our issue, we had been choosing “None” here
§ Ensure that the appropriate drive is selected under Source Volume – likely the C: drive
§ Enter a name for the target device, choose the appropriate NIC/MAC and Collection (this is populated if previously entered)
§ Click “Optimize for Provisioning Services”, OK
§ Finish when done and reboot (ensuring network – or CDROM if using a BDM image – is configured as the first boot device for the golden image VM prior to reboot)
· Once the golden image VM has booted back up, log in with the same user account used to run the Imaging Wizard
· Image capture begins – Finish when down
· Shutdown the golden image VM
We create a “maintenance” target device that we use for vDisk maintenance (i.e. making changes to vDisk versions, etc). This is just a VM has the same vCPU/RAM config as the target devices we’ll be using/creating to boot from the newly captured vDisk. We add a write shutItDown Gold 2 with Product activator cache drive to this VM. We create a device in PVS with this VM’s MAC address and add the newly created vDisk to this device. The remainder of these steps shutItDown Gold 2 with Product activator assume you have a “maintenance” target device configured to boot from the newly created vDisk and are only interested in Windows activation via KMS. In the PVS console, the newly captured vDisk should still be in private mode and KMS selected on the Microsoft Volume Licensing tab. There is no need to check the vDisk in PVS to confirm this – just added this for completeness sake.
· Boot your maintenance target device
· Log in and run cscript.exe slmgr.vbs –rearm from an elevated command prompt (may need to navigate to C:\windows\system32 prior to running this command)
· DO NOT REBOOT when prompted
· Run the XenApp Server Role Manager and select Edit Configuration
· Choose Prepare this server for imaging and provisioning
· Select the appropriate provisioning options – we choose Remove this current server instance from the farm
· Apply - Finish
· Shutdown the maintenance VM – DO NOT REBOOT
In the PVS console change the Access mode to Standard Image and choose the appropriate Cache type (we use Cache in device RAM with overflow on hard drive) and select OK (again KMS should already be selected on the Microsoft Volume Licensing tab as it was selected during the Imaging Wizard process).
After completing the process above, we now see unique CMIDs for all target devices whether they’re booted from the original base vDisk, subsequent version vDisks or merged bases. During our testing we manually activated Windows (slmgr /ato) while our “maintenance” target was booted from a vDisk version – obviously, this was after the steps above. We did this to ensure that PVS was handling whatever it needs to handle when activation occurs during maintenance. Hopefully that makes sense.
Assuming that the CMIDs remain unique for future vDisk versions and merged bases, this is an acceptable workaround.
That being said, we can reproduce, consistently, the duplicate CMID issue by selecting “None” at the Microsoft Volume Licensing screen when running the Imaging Wizard and following scenario 1 in CTX128276. Unless we’re completely misunderstanding that article, the process we were using previously is acceptable and supported. However, our direct experience suggests all that leads to is duplicate CMIDs and a whole lot of heartache down the road.
I’ll post back if we hear something worth posting from our service request (i.e. if this is a bug, etc.).