I know this has been discussed a few times before, but I haven't found a conclusive answer or solution yet.
I have been thinking on how it would be possible to monitor a Citrix Provisioning Server.
The obvious problem is if you deploy the server 5 times you have 5 agents checking in to the same agent on the Kaseya server.
I found that the agents stores its settings in the file KaseyaD.ini. There you can find the agent guid and the user name.
I then did some testing.
I deployed two servers, kastest1 and kastest2 and installed the agents on them. After that, I shut down the agent service on both servers, and changed the guid and user name at kastest2, for the values I found at kastest1. After that I restarted the agent service, and noticed the agent was checking as kastest1, but from the machine kastest2.
The following test I did was to create an agent on the Kaseya server (kastest3), wrote down its GUID and agent name. I then cloned kastest2, and after cloning the server, I changed the parameters in the KaseyaD.ini file. After that the agent checked in as kastest3.
I'm thinking this might be a solution to the CTX PVS issue. Does anyone have any experience with this?
its interesting you raised this we had an issue today where we have a vmware view deployment with linked clones they all check in as the same agent even though they all are different computer names issue is the agent guid is the same.
We are looking for a way (automated ) to get around this - I wonder if you had some way to generate a new agentguid would that work, you might have to put it in a loginscript or something though sort of like the SID walker for windows.
Hmm, can you test what happens if you change the GUID on an agent to a random value? Does a new agent at the K-server check in?
My collegue has another issue on citrix PVS. To solve this problem, he schedules a script to run after booting, which checks the servername, and changes the content of a file accordingly. Maybe this will be the solution to our problem.
I should do some further testing on this, but can't do it right now since I'm busy doing disaster recovery tests.
I'll keep you posted.
Can you try just not installing the agent, and dropping the agent installer on the system and adding a reference to it in the registry's HKLM 'runonce' auto startup hive?
I have a batch script that can give an existing agent a new identity (modification of kaseyad.ini as well as registry keys) that I can dig up if need be, something you'd run at startup, but it seems that is almost the equivalent of just running an agent install at startup like I mentioned above.