Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

SEP Clients unexpected behavior in SEPM

Created: 10 Jan 2013 • Updated: 10 Apr 2013 | 18 comments
This issue has been solved. See solution.

Greetings to All,

Im using SEPM and SEP 12.1.1000.157 RU1 in the corporate environment.

All clients are managed and in compter mode, 1 domain, replication site 1.

Im facing several weird issues with Symantec Endpoint Manager with the Clients.

1.After deployment, clients shows up in wrong container despite the installer was export from the correct container.

2.After the client restart, the client went missing from the SEPM container.

  If the client is not missing,I noticed that the names of the client change randomly including the logon user from time to time which makes it difficult for me to track and diagnose the issue.

3. The missing client from the container still recieves the latest policy I have changed. (I tried to check is it in user mode view, but unfortuately that's not the case)

I have tried importing the Sylink into the client, but it points to the wrong container or simply just won't show up in the SEPM. Client shows connected to the server.

Test connecting using the secars test string it returns with the value "which looks like upper LL and inverted LL" , I don't understand.

I am not sure whether any settings or policies will cause such an issue describe above.

Thank you

Regards,

Yap

Comments 18 CommentsJump to latest comment

Ashish-Sharma's picture

HI,

Are you using Clone Image ?

Thanks In Advance

Ashish Sharma

pete_4u2002's picture

check these links

SEP 12.1: How to prepare a Symantec Endpoint Protection 12.1 client for cloning (image)

http://www.symantec.com/business/support/index?page=content&id=HOWTO54706

  How to repair duplicate IDs on cloned Symantec Endpoint Protection 12.1 clients

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

yapxk's picture

@Ashish Sharma.

Yes we are using an image for mass cloning.

pete_4u2002's picture

SEP 12.1: How to prepare a Symantec Endpoint Protection 12.1 client for cloning (image)

http://www.symantec.com/business/support/index?page=content&id=HOWTO54706

  How to repair duplicate IDs on cloned Symantec Endpoint Protection 12.1 clients

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

SebastianZ's picture

You have mentioned that the nams of the clent changes randomly to the name of the logon user - this would mean some of the clients are in the "user mode" - please have a look at the following KB:

http://www.symantec.com/docs/TECH147033

yapxk's picture

Hi,

 There are no duplicates. The client is just missing or changed to another name randomly at intervals.

  The ClientsideClonePreptool is trying to disable the SMC.exe but apparently it fails. Is there a need to disable SMC.exe ?

After running the preptool. It shows up in a correct name but wrong container.

Need to test more.

Thanks and Regards 

yapxk's picture

@SebastianZ

I have confirmed that the packaged i exported uses PreferredMode=1 (computer mode)

I am wondering does this have to do with the reconnection preferences ?

Thanks and Regards.

SMLatCST's picture

I'd highly recommend you read the earlier linked articles about cloned clients.

Essentially, SEP uses it's own proprietry form or client identification called the HWID (hardware ID).  This is generated when a client first contacts the SEPM and is stored in the registry and in a local file.

When imaging, unless you follow the steps in the linked articles, the HWID from your golden image is also cloned.  Therefore, all new machines built using this golden image share the same HWID.  This causes the SEPM to link all of the imaged clients to the same client record.  This is what generates the behaviour of a client changing it's name, as well as a client appearing in the wrong group, and all sorts of weird and wonderfully odd things.

"Thumbs Up" to Pete, his second article should sort you out.

SMLatCST's picture

Oh yeah, regarding the group specified in the installation package.

This is only ever a preferred group, and is used when a client first contacts the SEPM, i.e.:

When a client checks in, if the SEPM doesn't already have an idea of where the client should be, it will use this preferred group.  If the SEPM already has a record that matches the client's HWID or hostname however, it will not move this existing record, and just link it to the client.

This is allowed so that administrators may use a generic client installation package for all machines, but customise the policies after clients check in as per:

http://www.symantec.com/docs/HOWTO80732

yapxk's picture

Hi SMLactCST,

Interesting point but it could be time consuming if it there thousands of clients.

Won't it be better to export an installer with a preferred group ?

Cheers

SMLatCST's picture

It really depends on your environment.  Like yourself, most of our customers prefer to create separate client install packages for each group and deploy these to specific client types.

While this works great, the packages are generally larger (as they contain the policies for that group as well).  By using the method in the article I posted, you can create a client package with no policies and no content (making it the smallest size possible).  Then leave it to the precreated records to provide the clients with their policies and content.  It's all down to when you want that increased network load to happen, as clearly the client must download the policies and content at some point.  It's just one of the various options offered by SEP to help you manage that.

Obviously this is a little off topic though.  How goes the clearing of HWIDs?  Just to confirm your earlier post, the process to remove the HWID from a cloned machine does require the SMC be stopped (while running it locks the files and reg keys holding the HWID).

The second article linked by Pete shows how you might use the Client Deployment Wizard to push out the RepairClonedImage tool (of course this is reliant upon the endpoints meeting the requirements for the CDW as below)

http://www.symantec.com/docs/TECH165133
http://www.symantec.com/docs/TECH163112

A. Wesker's picture

Hi,

For sure if you noticed that the clients are not all displayed and some of them are switching on the SEPM Console, that's an expected behavior if the clone image has not been prepared correctly.

Your SEP clients gonna have the same hardware ID.

In this situation, for example let's say you have 15 SEP clients with the same hardware ID, you will see only one displayed on the SEPM Console and online.

And the 15 SEP clients gonna be displayed randomly during the day when they are updating from the SEPM server.

SEP 1 updading and displayed on the SEPM Console. The 14 other SEP clients are not displayed.

An hour later, SEP 2 displayed on the SEPM Console, The 14 other SEP clients including SEP 1 not displayed anymore.

Etc etc ^^

To check if there are duplicated, just give a look on the ersecreg and secars log on the SEPM side.

You will see all your clients registering to your SEPM.

You could perform research by taking one of the Hardware ID and see if you noticed that one with different IP address. If so, you have some duplicates.

You should be aware as well about the SEP Client registration work flow and then I think you will understand better why this unexpected behavior occurs.

Keep in mind that it's the information of the SEPM database that has priority on everything, no matter if you re-deploy SEP install machine on clients with remove all previous logs, policy and reset of the communication.

Work flow chart of SEP client registration to SEPM => http://www.symantec.com/docs/TECH91587

Kind Regards,

A. Wesker

SOLUTION
yapxk's picture

Hi Wesker,

Im still in the mid of testing with the ClientSideClonePrepTool, clients seem to be much more stable.

The last issue I have is to check why it keep going to the wrong container, before I start rebuilding the image.

You mentioned the database has priority over everything, hence I have to purge the record of the machine in the database to fully solve this issue ?

Thanks and Regards.

SMLatCST's picture

Yes, the client record in the SEPM takes precedence over the preferred group chosen in the client package.  As I mentioned, if client records already exist (in the wrong groups) then the clients will link to these records.

I'm afraid you are going to have to purge any client records that exist in the wrong group.  Perhaps this old article will explain it better:

http://www.symantec.com/docs/TECH105886

yapxk's picture

Thank you all for your kind assistance. I will try again and update once I iron out the issues..

SMLatCST's picture

Hopefully our posts can help you sort out your issus.

As always, it'd be appreciated if you could mark any posts you find useful with a "Thumbs Up", or (if you find one) as the Solution wink