Video Screencast Help

Finding duplicate clients that have the same HardwareID

Created: 18 May 2010 | 10 comments
Eitan Caspi's picture
5 Agree
1 Disagree
+4 6 Votes
Login to vote

Hello,

Following KB article "Duplicate Hardware IDs result in only one client showing up in the Symantec Endpoint Protection Manager for two systems" (http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/53335748be27a4808825767400745f96?OpenDocument) - It will be very good if you will give us the option to run a query and a scheduled report that will show us which machines have the same HardwareID registry value plus any operational identification so we can find this machines (IP addresses, host name, etc...).

This will help us separate machines into unique identity and turn them from some-unmanaged to fully managed.

I also guess this should not be hard to do since it is only a SQL query to find duplicate values in one db field.

Thanks.

Comments 10 CommentsJump to latest comment

Scuba Steve's picture

This was a product issue. There should never be any clients with duplicate hardware ids.

+1
Login to vote
Eitan Caspi's picture

It happens because from time to time the PC technicains and/or system administrator duplicate images of PCs/Servers (with the same HardwareID) and thus create this situation - and so we, as the security admins, need to locate such events and ask this people to correct this.

+1
Login to vote
Burnsen's picture

Hello,
if you clone machines or install from a slipstreamed image which was taken on a machine that had SEP installed, you need to make sure to remove the HW Key info from the machine before creating the image. Otherwise you would see exactly the behaviour that you describe. This is working as expected and not a bug.

If this already happened and you want to find out which machines have the same hwid, connect to you DB and run the following query:

  • SELECT * FROM SEM_CLIENT WHERE HARDWARE_KEY IN ( SELECT HARDWARE_KEY  FROM SEM_CLIENT GROUP BY HARDWARE_KEY HAVING COUNT(HARDWARE_KEY) > 1)  AND HARDWARE_KEY != '' ORDER BY HARDWARE_KEY;

This will show all machines where more than one hardware key is present in the database.

To fix it, you have to do the following steps:

  1. Stop SMC service on the affected machine (Start -> run -> SMC -stop)
  2. Empty the value of the following reg key: HKLM\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\SYLINK\SyLink\HardwareID.
  3. Delete the file %programfiles%\Common Files\Symantec Shared\HWID\sephwid.xml.
  4. Start the SMC service again (Start -> run -> SMC -stop)

+3
Login to vote
Eitan Caspi's picture

Hello Burnsen,
Thanks for the detailed reply.

The SQL query you added looks useful and I will try it.

Regarding the link and the fix procedure - I know them.
I just wish for Symantec to:
1. Prevent this from happening.
2. If it happened - to enable me to find this easily (preferred as both query and report with email alert) as part of a good maintenance of the product, so I can fix it. you can't fix what you don't know is broken.

Thanks.

+1
Login to vote
InfoSecGuy006's picture

I am having the exact same problem and being the SEP admin for a large enterpise with SEP clients geographly disbursed throughout the world this is a major issue.  I echo Eitan's comments in that I wish for Symantec to provide a way to fix this issue as it's clearly a one that many admins such as myself have run into.  Symantec should provide a way for admins to be alerted when duplicate HW Ids are in the SEPM DB and provide an automated way to remediate this issue both within the SEPM DB and the SEP clients. I again echo Eitan's comment in that I can't fix what I dont know is broken and took several months before this issue was discovered, but now that I know there is an issue I'm frustrated that Symantec has not come up with a tool or even a batch file or script to help admins such as myself resolve this issue.  It is my hope that issues such as this will be looked at in future revisions of SEP and that Symantec will have tools in place to resolve issues such as these.

+1
Login to vote
Ian_C.'s picture

1. Prevent this from happening.

Is this HW ID not supposed to be unique? Having duplicates in the DB certainly is not unique. The client must confirm if it's ID is unique within the DB.

2. If it happened - to enable me to find this easily (preferred as both query and report with email alert) as part of a good maintenance of the product, so I can fix it. you can't fix what you don't know is broken.

This should NEVER happen. What other value in the DB is there to uniquely identify the record?

Because it can happen, at the very least, there should be a report similar to the SQL query above. Preferably there should be a pro-active alerting mechanism to resolve this glaring admin & security problem.

Please mark the post that best solves your problem as the answer to this thread.
0
Login to vote
Ian_C.'s picture

You are correct, the steps you mention can prevent the issue from occurring.

Unfortunately, not all places have got the processes & procedures in place to do so. Symantec, from a compliance point of view has to be aware of this and prevent it.

Please mark the post that best solves your problem as the answer to this thread.
0
Login to vote
John Cooperfield's picture

Thank you for the SQL query!!

There is a method to combine two log files from the SEPM and fuss with Excel a while ... but luckily I found this today.

John

 

 

0
Login to vote
John Cooperfield's picture

 

Yes it should never happen, but sometimes people decide they need to clone a server to get more of the same, and they assume if they run Newsid everything will be fine.

Our main crews of server builders have been trained (again)  to clear the SEPHWID but in the real world, things happen.

 

Thanks

0
Login to vote
John Cooperfield's picture

 

By the way for SEP 12 there is a new way to create a list of mis-cloned clients (duplicate hardware IDs) in Tech note 166349

in http://www.symantec.com/docs/TECH163349

at Step 1: Identify the clients

 

The old way for SEP 11 way is documented elsewhere.

0
Login to vote