How to install the Kaseya VSA Agent on a non-persistent machine

Deploying Kaseya VSA agents to provisioned workstations and servers from a standard image can be a challenge. Using the typical methods result in duplicate GUID’s due to the nature of the technology making it impossible to accurately monitor and report on these types of machines.

The following procedure has been tried a tested (successfully) numerous times on Citrix VDI/SBC environments leveraging Provisioning Server and Machine Creation Services. That being said, the process should work on other systems that are non-persistent providing they have a persistent volume where the application files can be placed.

The term ‘Target Devices’ used throughout this process is what provisioned desktops and servers are called in Citrix Provisioning server. If you are not familiar with Citrix Provisioning server, think of these as being your non-persistent machines that the image is being delivered to.

  1. The first thing we want to do is create an Organisational Unit (OU) where your update / maintenance target device(s) will live.
  2. Apply a GPO to the maintenance Organisational Unit (OU) which will stop Kaseya communicating with the master server.
  3. Create a new agent package configured to install the agent on the persistent drive, typically, the ‘writecache’.
  4. Create a new version and open the master image / vDisk in maintenance mode (read/write)
  5. Manually install the package onto the new version making sure the GPO is working which prevents communication with Kaseya (Stopping the agent from connecting to the Kaseya master server which in turn updates the KaseyaD.ini file)
  6. Once installed, go into the install location on the persistent drive and scoop out a copy of the folder labelled with the agent ID, this is typically found inside ‘Program Files (x86)\Kaseya’ (You will need this for later)
  7. Stop the Kaseya services.
  8. Delete the following 3 registry keys:
    Kaseya-Agent-PVS
  9. Perform typical cleanup tasks and shutdown the machine.
  10. Promote new version to Test/Production.
  11. Place the folder that was copied in step 3 into the persistent drive on all target devices that are provisioned from the master image / vDisk (This should be placed in the directory Kaseya expects to find it as configured in step 1 (Regedit can be used to confirm this)
  12. Reboot your target devices.

That’s it… you’re done. Provisioned / non-persistent machines should now report into the Kaseya master server with a unique GUID as do standard machines.

If Kaseya services fail to start on target devices it’s likely due to the application files being in the wrong path on the persistent drive. Confirm the application files are where the should be according to the registry.

Very keen to hear how you go. Feedback welcome, thanks

 

 

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Website Powered by WordPress.com.

Up ↑

#DAASLIKEAPRO

Passionate about End User Computing

Citrix Blogs

Virtualisation | Application Delivery | EUC | Cloud Computing

BrianMadden.com

Virtualisation | Application Delivery | EUC | Cloud Computing

xenappblog

Virtualisation | Application Delivery | EUC | Cloud Computing

leeejeffries.com

Virtualisation | Application Delivery | EUC | Cloud Computing

%d bloggers like this: