This content has been marked as final. Show 11 replies
Also had the same error recently. After some random debuging it seems that that obscure error -14 is caused by GUID duplications.
Solved it by deleting the Agent GUID entry and rebooting or restarting the Framework service in case you allow Mcaffe services to be stopped in your Access Protection policies.
The registry key is:
HKLM\software\network associates\epolicy orchestrator\agent\AgentGUID
Hope it helps.
In order to make the registry changes, however, you may need to stop certain McAfee services First.
net stop McAfeeFramework /yes
net stop McShield /yes
net stop McTaskManager /yes
This may not be allowed easily in VSE v8.7i if the defaults are in place for disallowing the stopping of McAfee services. This must first be unchecked (meaning, Allowing) so that the services can be manually stopped and the registry entries changed.
Make the regedit changes, then
net start McTaskManager /yes >nul
net start McShield /yes >nul
net start McAfeeFramework /yes >nul
And remember to reset the changed settings mentioned above.
I just had by DBA run a report and uncovered over a hundred duplicate GUIDs. I obviously need to have a talk with my desktop team to fix the images, but does anyone have advice on how to better automate the GUID fix that's mentioned above?
I'm thinking of a program where I could reference a .txt file with all the troubled computers listed and then have a batch file execute to fix the GUIDs. I already have a batch file but in order to execute it I have to remotely login to each machine, which is very time consuming so I'm looking for a more automated process.
Any help would be appreciated.
Thanks for the replies. I thought that if you simply deleted the guids however it would not generate a new one. I thought only if the name changed would a new one be generated. I always had to delete the guids and then reinstall the framepkg.exe file. Am I thinking wrong or did this change in the newer versions of the agent?
Just ran into this problem my self, migrating clients from ePO 3.6 to ePO 4.0 using SMS for distribution of the framepkg.exe. It appears that using that method, the Agent GUID is retained and prevent the net agent from connecting to the new server.
I don't think in this case it's related to duplicate AGUID, but still, deleting it and restarting the framework service does immediately resolve the connection issue.
In my case I am not quite sure if they are duplicate guids or not as when I query the systems they all appear to be unique guids. I have been looking for a SQL script that will identify duplicate guids in the EPO database. Seen any scripts to do this?
Which version of ePO are you running?
If 3.6.x, in the Search function you can select "Duplicates".
If 4.0, there's a query to show duplicate systems also.
Now, for systems with different names and duplicate GUID, that's another story... From what I heard, 4.0 should never allow duplicate GUIDs. It does seem to be the case as a system with a duplicate GUID doesn't seem to be able to connect. Also, in 4.0, if I remember correctly, the GUID is built based on some system criteria such as the MAC, etc. that would/should always make it unique.
Thanks for the pointer. I tested it out and it looks like it works on the EPO 3.6 database but not the 4.0. i will look around and see if there is something out there. Thanks again for the feedback