I will try this, see if it works... I hope this is not going to be a problem... if so I'll just install an older version of the agent on our images and let them upgrade once they check in... I do not know if that will work though....
Thanks for keeping us up on your progress. So far I've had pretty good luck with this work around. However, I do hope a fix comes along so I dont have to Fuss with that registry Key on every workstation I build or rebuild.
you guys are right , post CMA 3.5, the guid is sticky this is by design and wont be changed,
the product guide details about deleting the guid key before preparing an image ,
the agent will recreate the guid on svc startup if it is missing,
this is to prevent the old problem of the machine creating duplicate entries it would create a guid based on one mac address, and so create an entry in the epo dir, then connect using a dialup modem ( fr example that has a different mac ) and create itself a new guid, and therefore there would be 2x entries for the same machine in epo
Now our imaged PC seems to be getting updates with little problem, even if they are not showing up in the ip groups they should be.
Now, are those PCs still getting the correct policies associated with their IP range, or do the policies to a group only effect the workstations shown in the directory (the ones with good clean GUIDs). Its been something i haven't been able to determine, since it appears they are still doing timed scans, at least some of them are(by looking at the infection log)
the ip management rules only effect new machines joining epo, its how they are sorted initially. - you can move machines out of the initial groups and epo wont complain ( if i recall correctly)
it is the group that defines the policies and tasks recieved by an agent, but the identifier epo uses to reference the machines is the guid, it doesnt really care about anything else,
if you are in any doubt that you might have more than one machine with the same guid, then delete the guid key just in case, otherwise the node will simply swap names based on which instance of the same guid is contacting at that time
does that make sense ? - am i answering your question ?