Kind of, My question is not really about the IP management, more about the Policies and with our current image, it not creating a workstation object.
Example. Say we image a computer lab in a building with the current NON-fixed (with the agent key still intact) image. Now this lab will contact the EPO server, will get dat updates/engine updates and client updates.
However, will the policies like Scan at 12am take on this newly imaged PC that does not have a workstation object in the Directory? Our current problem is that we released a new image with the agentID attached to the image a few weeks ago, and now 3-4 of our PC labs are not showing in the directory at all (due to the problem above i expect). Now are these out of directory PCs, getting the correct polices for their IP range, even though the are not in the directory as workstations.
I encountered this same thing. Seems like the multiple PCs with same GUIDs were stepping all over each other in the directory. I finally was able to resolve by deleting not just the GUID registry key, but also the computer name, IP, and MAC address keys. And I also deleted the computer account entries out of ePO so they'd be forced to recreate. Probably overkill, but it sure seemed to work.
After I bring an imaged PC on line for the first time, it would Re-Generate its GUID and properly fall into its designated group. However, on some occations a PC will show up in an odd group and Ill have to move it to its correct group. This doesnt hurt anything and it does seem to get its proper policy inforcments.
Before I imaged the base user PC I disconnected the PC form the network so it didnt communicate with the EPO server. I then removed the GUID key from the registry, run sysprep and then create the image or "Clone" as I like to call it. When I go to set up a new machine, I relaod that image and bring the PC online, personalize it for the user, and give it a unique network name. Then it regenerates the new GUID for the agent.
right, i follow - 20 + machines are represented in ePO as one machine.
then they are effectively glued together in terms of what you can do with them, the policy set at one node, is actually 20+ nodes, and any reporting you do will make no sense,
if you use rsd , most of these machines will chow up as rogue, as they are not listed individually in the epo directory.
fi you are handy with sql you can see what is going on like this,
select * from leafnode where agentGUID = 'insertguidhere'
re run this query every few mins, the nodename will change as each machine checks in with epo on its hourly ASCI and updates the db with the computers new name eg, any one of 20 names from your pc lab
you can fix this by doing "send agent install" to the pc lab in question - this installs the agent with a /forceinstall switch which will force recreation of the agent guid, so 20 guids will be created, instead of them all sharing 1
I've just realised i have this problem on some of my lab machines that were ghosted. (Although the images were not supposed to have any AV s/w on them) Anyway, i deleted the agent key and reinstalled the framepkg, which did indeed recreate a new GUID.
However, for that machine in the directory, the properties for the agent only now show: Installed path, plugin version and language.
After reboots and collect and send props from my machine the rest of the agent properties do not appear. Is this the same as what others have?