A warning about Citrix SmartAuditor and Provisioning: if you have multiple Provisioned XenApp servers running the Agent, you are likely to run into recording issues--segments will be periodically dropped making some recordings seem to be "Live" forever, others will stop in the prematurely, and yet others will simply not play at all. The result depends on which part of the recording is dropped.
We are working on extending the XenApp Prep tool to take care of this.
The issue stems from the fact that the unique identifier for the Message Queuing Service on each Provisioned XenSpp Server is being duplicated --something which Microsoft has indicated is a "no-no." Since there are many servers with the same ID, when the MSMQ on the SmartAuditor Server-side performs a routine clean-up of its cache, what are actually new recording segments will be interpreted as older segments (because all segments bear the same MSMQ ID from the Provisioned XenApp servers, but their counters will be out of order) and will simply discard them.
The workaround is to perform the following steps (and this must be done on the XenApp master image each time before the image is switched back into Standard Image Mode):
On XenApp
1) In Private Image Mode, perform whatever changes to the master image.
2) Before shutting down, stop both the SmartAuditor Agent Service and Message Queuing.
3) Go to HKLM\SOFTWARE\Microsoft\MSMQ\Parameters\Machine Cache and delete the REG_BINARY value QMId.
4) Move up to HKLM\SOFTWARE\Microsoft\MSMQ\Parameters and create a DWORD value called SysPrep and set this value to 1.
5) Shutdown and Switch to Standard Image Mode.
Source: http://blogs.msdn.com/johnbreakwell/archive/2007/02/06/msmq-prefers-to-be-unique.aspx
The SysPrep flag will trigger a regeneration of the QMId REG_BINARY value just before the service starts. This regeneration takes place on start-up across all of the target hosts using the same vDisk thus allowing them to each have their own unique identifier for MSMQ.
The QMId will be different upon each reboot--even for the same target server. If you are just using SmartAuditor, this will NOT be a problem. However, if you are using some other software that utilizes MSMQ that is dependent for some reason on HOST-A and HOST-B having consistent QMId values, then this will present a problem. In which case, I'd wait for the XenApp Prep tool.
For those not using Citrix SmartAuditor or XenApp, but provision Windows member servers which use MSMQ, the solution will be a bit more complicated.
Note: before implementing any solution discussed here, consult the application vendor. The following depicted here is merely a suggestion and Citrix makes no guarantees, warrantees, and so on and so forth... TEST TEST TEST before doing anything to Production!
In Private Image Mode, before shutting down, set the Message Queuing service to Manual. Then deploy a script (via a Local Policy for the Computer or maybe as a GPO in an OU) that does the following:
1) Uses WMI to query for the computer's UUID.
2) Convert the return value to a string while stripping out the dashes "-."
3) Check the Registry for the presence of the QMId value. If it exists, delete it and move on...
4) Create the QMId REG_BINARY value and pass the modified UUID value to it.
5) Start MSMQ
We implemented this workaround using VBScript and it works well. There may be some delays if WMI has issues on start-up. As long as the value put into the QMId REG_BINARY conforms with being a 32-bit hex value, it should work. The result will be that each target device will have a unique but static QMId because whether the target is hardware of a Virtual Machine, the UUID for that host will always remain the same (unless you swap out the CPU of a hardware machine).
http://forums.citrix.com/thread.jspa?threadID=254805
