Kaseya Community

Wrong machines, wrong data, Kaseya confused

  • So, I'm a little new to Kasyea, but I have managed to get my first installation of Kaseya completely confused.  Maybe someone can help me out.

    Starting at the beginning:  I started with a single Win7 Dell box, configured it as I wanted, then cloned the hard disk to multiple others.  On each, I changed the machine name and reinstalled the Kaseya agent so it would properly pick up the machine name and check in properly.  Now, I'm using (with permission of course) our "service providers" installation of Kaseya  so presumably I should not be emailing Kasyea for direct support.  

    Before I shipped the PC's off to the overseas factory, I had only had a few of them "on" and conneted to the network at a time.  Everything worked well.  However, when they are all turned on now in the factory something strange happens.  Let's call them N1, N2, etc. for simplicity.  I shipped N1, N2, N3, N4 to the factory as well as N7 as a "Cold Spare".  N4 failed so N7 has been substituted (sorry for all the details).  Now N2 and N3 seem to check in just fine and I can connect and do what I want.  N1 sometimes shows up on the "Agent Status" page, but other times is not present even though it is on.  N7 sometimes shows up on the Agent status page but othertimes it is not present.  The two of them seem to be mutually exclusive: one or the other. 

    Further making things interesting is sometimes I will ask Kaseya to remote desktop to N7, but I end up connecting to N1.  

    Even more fun is I get mixed data on the agents list.  I might show N7 there but with the wrong hardware, wrong IP address, wrong mac address.  Or maybe N1 will do the same.

    Similar things happen to N5, which sits on my desk as another 'cold spare' and a way to test MS and other patches before they are deployed to the end-user's site overseas.  N5 comes and goes.  If N5 is present, N1 and N7 are nowhere to be seen even if they were there a moment ago.  Just now I see that it appeared, but is showing with an IP address that is overseas and not the right one.

    Someone suggested I should run Sysprep to clear the unique identifiers.  I am not intimate with Sysprep but experimenting with this has not helped. 

    Anyone run into this? Any suggestions on how to simply fix this, remembering that I cannot gain easy physical access (without jumping on a plane to go 1/2 way around the world!).


  • It sounds you like installed the Kaseya agent and allowed it to check in before you made your image. Is that accurate? It sounds that way. I'll proceed under this assumption.

    The problem is that your Kaseya agents have the same GUID. A GUID gets assigned the first time a machine checks in, and it always stays constant even if the machine name changes. In your case, you have multiple machines all reporting in under the same GUID and so the data in the database is constantly changing. N1 and N7 are both fighting over the same GUID.

    The correct procedure when imaging is to disconnect the machine from the network before installing the agent so that the agent never checks in. You install an agent, and then shutdown and image. Then as you roll out your images, each new machine will come online and check into the Kaseya server for the first time as a new agent.

    If you look in the Kaseya installation directory you will fine a file called KaseyaD.ini where the GUID (and other configuration info) is stored.

    I am 90% positive that if you delete the KaseyaD.ini file on a machine that it will recreate itself the next time the Kaseya Agent service is restarted. I would test this of course... but If I'm right then you could likely write an Agent Procedure that would nuke this file and then restart the Kaseya Agent service.

    I 'think' this will work.

    1) Create an agent procedure that deletes the KaseyaD.ini file and then restarts the Kaseya Agent service.

    2) Assign the procedure to any of your problem agents and schedule it to run every 10 minutes.

    3) Let it run until the problem agents show as permanently offline.

    Theoretically, each problem agent should run the script and then check in as a fresh agent afterwards. This would leave you with a whole bunch of new agents in Kaseya and eventually it would leave your problem agent offline permanently.

    Obviously I'd test this :P

  • Alright, nuking the file doesn't fix the issue. I think it used to but they must have changed something because the file is recreated and contains the same information as before.

    I have an idea or two which I'll test out and reply shortly..

  • Thanks so much for your attention to this matter.  

    Yes, you were correct in your assumptions, it did check in prior to being cloned.

    I tried killing it off on one machine (N5 on my desk), but did not work.  It seemed to recreate the file immediately and same symptoms exist.  I would try compltely uninstlaling the agent and trying again if I thought that might work, but I think it might be picking up something within windows, maybe Activation data or some such.

  • Yeah, I guess I can't recommend a quick fix and I'm out of time to look at this.

    If you can uninstall and reinstall the agents then that will obviously work. Outside of that, I'm guessing that someone here might have a solution or Kaseya support might know how to orphan the agents for you.

  • Ohhh... maybe.... Lucky my VPN is working and I could work using RDP for this, but it may be that a full uninstall and reinstall may be working OK.... I'll know soon.  I knew that "installing over top" of the existing agent would make it pick up the correct machine-name, but apparently does not give it a new GUID.   This uninstall/reinstall may be just working!   Will check back when I can confirm and apply to all machines.