Endpoint Protection

I have cloned one laptop's hard disk to another and they both have SEP client running. Only second one appears in the clients list in SEPM. Is SEP identifying clients by Windows SID? Or is there another ID key which i can change in the registry or elsewhere?

SEPM uses a hardware ID that is different for every machine.

Please check my post in the link below for more information on the same.

https://www-secure.symantec.com/connect/forums/enpoint-protection-1105002333-issue-active-directory-integration-clients#comment-3390551

Aniket

Title: 'Configuring Symantec Endpoint Protection client for deployment as part of a drive image'
Document ID: 2007110510364248
> Web URL: http://service1.symantec.com/support/ent-security.nsf/docid/2007110510364248?Open&seg=ent

I have imaged a lot of computers with sep installed. The only thing you have to remember is to delete the Computer ID and HardwareID that are found under HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\SYLINK
 just do this right before you reboot to begin you imaging process.

 Windows SID does matter, especially if you are using AD import.

Just keep in mind the different versions of SEP identified clients in different ways.  Search the forum for the version you're using.

If you working with an MR5 client, it now uses an XML file to store the HardwareID. Also new for MR5, the HardwareID in no longer based on the MAC addresses of the computer.
The XML file is located at %ProgramFiles%\Common Files\Symantec Shared\HWID\sephwid.xml
If you know you are going to image your machines, my advise is to delete this file before you image the machine. If you're seeing an issue, you may want to try deleting stoping SEP and deleting thte sephwid.xml file.

Note, this all applies to MR5 clients and later. MR4 clients and earlier stored the HardwareID key in the registry which was based on the MAC address(es) of the computer.

Prachand's link was the solution. Thanks.

compguywill, Ghent - just a correction, with MR5 it is not sufficient to just delete registry key or xml file. If i only delete registry key and restart a computer, when it will copy ID from the xml file to the registry. Same with deletion of just a xml file. Only when registry key and xml are both deleted, SEP will generate new ID upon restart.

Jeremy Dundon, can you give more details when SID matters? Do you mean if i install new SEPM and then import computers from AD, then it won't show computers with the same computers' SIDs? Maybe SEP should identify them by Domain Computer SID instead, which should be unique no matter what local computer SID is. We are capturing image prior to joining domain.

Anyway, i have checked all critical places (Domain joining, SEP, WSUS) and i think we are going to skip local SID regeneration with NewSID after we clone a computer from image.

Have a look at this link about the retiring of NewSID.  I'm still not sure that duplicate SIDs are ok, but apparantly Microsoft (or at least the Sysinternals guys) think they're ok now.  blogs.technet.com/markrussinovich/archive/2009/11/03/3291024.aspx

Yes. My research was based on that Mark's blogpost. So far we don't see any problems with duplicate local SIDs. Computers are joining domain, WSUS and now SEP and everything seems fine so far. Of course, we can still encounter some software counting on unique local SIDs in the future.

RU5 has a new design.

With this new design, the Hardware Key is now stored in %programfiles%\Common Files\Symantec Shared\HWID\sephwid.xml. This allows for easier remediation in the following situations:

1) A client is generating new Hardware Keys on startup which could potentially conflict with another SEP client or for preparing a machine
a. Move, rename, or remove the Hardware Key config XML file found in the Symantec common area.
b. Remove the “HardwareID” registry value located in HKLM\Software\Symantec\Symantec Endpoint Protection\SMC\Sylink\Sylink\
c. Restart the client.. New Hardware Key information will be generated in this case.


2) Every time I install the client on a clean VM or Ghost image using the same hardware, the Hardware Key is different.
a. Since the new algorithm generates random IDs, any install on a clean machine will result in a new ID being generated. However, if the client is uninstalled and reinstalled, the ID should not change, since it is persisted in an XML file located in the Symantec Common area. i.e %programfiles%\Common Files\Symantec Shared.


In order to maintain the same ID when an image is restored, the customer should install SEP first before taking the image. Alternatively, the customer may also drop a saved sephwid.xml file and force that Hardware Key to be used by setting HKLM\Software\Symantec\Symantec Endpoint Protection\SMC\Sylink\Sylink\ForceHardwareKey in the registry to 1 (true).

How to fix RU5 clients that have been misconfigured and already rolled out to production (For each client:)
Delete %programfiles%\Common Files\Symantec Shared\HWID\sephwid.xml
Open the registry and navigate to HKLM\Software\Symantec\Symantec Endpoint Protection\SMC\Sylink\Sylnk
Edit the "HardwareID" value data to be blank
Restart the Symantec Management Client (SMC) service in the services snap-in.

Clients should now generate unique HardwareID's and sephwid.xml's.

Is there a recommended way to automatically fix the cloned HardwareID issue? We have as many as 100 clients who were deployed with an image that didn't have the HardwareID values cleared. So the clients GUI shows as managed, but they are playing hide-and-seek with the SEP console. Manually following the instructions to clear the reg value, delete the XML file and restart the service does work...but I don't want to have to touch the other 99 machines :-).

I've been tinkering with some VBscript to see if that is a way we can clear the reg key, rename the 'sephwid.xml' file, and restart the SMC.exe service. Am I reinventing the wheel - does Symantec have a tool that I can run that will do this for me? 

Jon Cutler, CISSP
Information Security Office
Marshall University

First, would you mind sending me several of your sephwid.xml files from several of your clients that have the same ID? We may be able to use them to 'tune' this process so this issue doesn't happen in future releases. The more you send me the better! Even if it's all 100. But about 5 should do. :)

Next, when you tried to clear the key, did you stop the service first?
My recommended steps for a script would be.
Run smc -stop
Delete Registry key
Delete XML file
Run smc -start

You should be able to check the registry and/or the sephwid.xml file shortly after the service starts to verify if the ID changed.
Those are the only 2 places the client has it's key. I doubt it makes a difference, but all your clones don't have the same exact Hostname, do they?

Alternatively, you could just update the HW key directly. Both the sephwid.xml file and the registry key contain a 32 digit hex number. If you used a script to stop the service and then generate a new 32 digit hex number for both the registry and the sephwid.xml file, you've got a new key. In fact, you can just delete the xml file and update the registry.

And finally, you could change the values inside the sephwid.xml file. If you open the sephwid.xml file you will see a list of ID="data_here". If enough of that data changes, then the client is suppose to generate a new HW ID. So you could make a script that stops the client and then changes all the "ID" values. Vula you have a new key. At least, that's my theory... I haven't tried it :)