More Fun with SEP GUIDs.

After fighting with duplicate hardware IDs in Symantec Endpoint Protection not that long ago, it was surprising to find the problem back again.   Were these left over from the original problem, or was this a return engagement.   And if it was a problem cropping up again, was it caused by someone forgetting to do the ghost load correctly or something else?

Symantec Endpoint Encryption uses a hardware ID as a GUID to differentiate clients.   If a GUID is cloned to multiple computers your reporting and policies are affected.   We tend not to find these problems until we move a client to a new group and find other computers showing up in the new group instead.

It turns out the old SEP 11 instructions for preparing to clone a image don’t quite work with 12.1.     With SEP12.1 on Windows 7 64 bit, we found an additional copy of sephwid.xml in C:\ProgramData\Symantec\Symantec Endpoint Protection\PersistedData\sephwid.xml.   It wasn’t mentioned in the SEP11 instructions, and every machine from the image ended up with the same hardware ID.   If you are manually fixing duplicate GUIDs keep that in mind.

It turns out there are instructions specifically for SEP12.1.

How to prepare a Symantec Endpoint Protection 12.1 client for cloning – http://www.symantec.com/docs/HOWTO54706

How to repair duplicate IDs on cloned Symantec Endpoint Protection 12.1 clients  – http://www.symantec.com/docs/TECH163349

 They don’t give manual instructions (at the time of this writing) on removing the hardware ID in 12.1, but they do provide a executable for the job.   I haven’t tested this exe out, but one thing bothers me.   The instructions say if you use tamper protection you must disable this.   If you require a password to stop the smc service you must disable that.    We don’t use tamper protection, but we do require a password to stop the smc service using the smc -stop command.  I wish they would allow me to provide the password at the command line as the sylink dropper tool can do.   The good news is that by setting up a separate policy for these clients in order to disable the password requirement to stop the SMC, you can then identify the remnant accounts based on the duplicate hardware ID that could be deleted.

2 Comments

  1. Hi Roger, I work in the SEP PM group here at Symantec, thanks for your blog. You are correct, with the SEP12.1 release there are multiple copies of sylink.xml on the system. This was something that we picked up during our beta, but it was a little too complicated to change in time for the release. We didn’t want customers to get confused with the multiple files, so thought that a utility was the best route forward in the short term. Thats what we shipped with SEP12 and we are planning to fix this up in the next release of SEP12, which is due in early November. The best route forward for now though is to follow the KB’s and use the steps you also outline, to put the imaging client into a group that doesn’t require a password to stop SMC. Once you do that, the procedure should work just fine.

    thanks!

    paul

  2. Does any one have a good idea on how to audit this? I just found three computers that show up as the same Symantec Client, depending on check in time, the computer appears to one of the three in SEPM. I can deal with fixing a few problem computers, but not knowing how big or common the problem is, is worry-some. I have a mixture of 12.1.671.4971, 11.0.6100.645, 11.0.6300.803, and 12.1.1000.157 clients. The majority are SEP 12.1.671.4971. Where is a good place to scrape the hardware GUID from the PC via a script?

    JW

Comments are closed.