VDI Duplicating agents (VMware)

VMware View Instant Clones (IC) feature generates an intermediate template machine between the golden image and the production machines.

Due to the agent services in the template machine starting as soon as the machine is being spun up the agent on the template machine becomes the first machine to check-in and subsequent machines all have the same GUID and re-use/compete for the one agent record.

In order to correct this we can perform the following:

Pre-requisites to setup a GoldImage for a VDI aware VSA Agent

1. Install VSA Agent on GoldImage
2. Locate new Agent in VSA, Managed Agent, VDI Configuration, Match on Machine name
   
   
3. On the Golden Image, modify Kaseya Agent Service to have a Delayed Start on windows
   - Open Windows Services and locate the Agent services
   - Right click on services > properties
   - Modify Startup Type to Automatic (Delayed Start)
   
   
4. Recompose the Gold Image to commit changes

Alternatively, you might chose the following method to disable the VSA Service on the temp agent during the recompose,  then start these Service on your virtual desktops when the user logs in.

1. Install VSA Agent on GoldImage
2. Locate new Agent in VSA, Managed Agent, Manage, Match on Machine name
3. modify Kaseya Agent Service to have a Manual Start on windows, similar to what was explained above.
4. Recompose the GI.
5. Setup a Group Policy Login Script that will be executed on all Virtual Desktops when the user logs in and instantiates the vm, to start the VSA Agent Services using CMD line or Powershell.
   1. CMD line method is -  net start ServiceName
   2. Powershell Command is - Start-Service -Name "ServiceName"

_________________________________________________________________________________________
 
Workflow explanation
 
Steps with * are actions... italics are reactions.
 

1. *Install an Agent on the GoldImage (GI)
2. *Flag the new Agent as a GI through the VSA UI, by Machine Name.
3. the GI gets a new kaseyaD.ini, which contains a VDI flag that identifies it as a GI
4. *Modify the Startup type for the VSA Services to be "Delayed start"
5. GI goes through its Commit Process, TemplateClone is created but maintains the AgentIdentity of the GI
6. TemplateClone, with the ID of GI,  now ready to Clone
7. *User logs in, New Clone gets instantiated for the first time
8. New Clone is created with the SAME kaseyaD.ini as the GI
9. New Clone checks into the VSA... VSA sees the AgentGUID of the GI and the VDI Flag, so it checks the Machine Name.
10. The machineName is Different, so it checks the VDITable for that AgentGUID + machineName record... DOES NOT EXIST
11. Adds a new record to VDITable that includes GIAgentGUID, machinesName, NEW agentGUID for Clone
12. Clone gets updated with a new kaseyaD.ini that contains its newly ASSIGNED AGENTguid...From this point forward it operates as a normal Agent for the life of the session.
13. Next time this clone is created, there is a match in VDITable for that GIAgentGUID, CloneMachineName, clonesAgentGUID, so its kaseyaD.ini is updated and the clone assumes its assigned identity.