Endpoint Protection

I know the title is a bit odd, but really not sure how to sum up my issue.  I've got AD integrated into SEP by way of location.  One SEP group with an OU integrated into it, and so on for each location within our company (about 50 sep groups, with at least 2 ou's per sep group).  My issue seems to be with systems leaving thier OU and reporting that they are in the default group.  I've been working with tech support on this for quite some time with the end result being that they want to look at my database to see whats happening...This has been going on forever though and It's really starting to get on my nerves.

Has anyone had this issue happening at thier locations?  we're running a combo of MR4 and MR4 with MP1a.  I've got 2 failover servers running endpoint and the database is in SQL.  There is also a replication partner over in Germany that handles our overseas clients.

Typically we will install all computers with SEP to report to the default group, then AD sync's and moves the systems from the default group and shows them as reporting from thier OU group.  If a system for some reason should decide that it wants to move back to the default group I have been unable to move it back.  Sylink drop doesn't work, reinstalls don't seem to work either.  any ideas?

Not seen the exact issue, but one like it.

First check to see if the machine really is moving in AD.  If it gets into an AD OU that is not syncronized with SEP, it will end up in the default container.  From your example it sems you are picking and choosing OUs, not importing from the root of your AD, so this could be it.

Make sure your AD is only sync-ing from one site, not both replication partners.

Make sure there is no way the clients are load balanced across the replication parnters. (failover is ok, load balanced across replication partners will create multiple entries for each client in the DB, ultimately driving you insane)

Do you have duplicate clients listed in the Clients tab?  Do you have duplicate clients listed in the Monitors->Logs? (advanced search, enter client name in computer name field)

Hi, please see the following articles:

http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/5a0992e52987d237882575a600685eda?OpenDocument 

This one I dealt with personally as clients moved from the SEP groups I defined back to the default group:

http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/d84071c5137d6d318825738a00663b8d?OpenDocument

RickJDS:

Unfortunatly I've tried both of these options, with no luck.

RWessen:

The systems are not moving within ad, some of them are servers that have been in the same OU's for years.  In the case of some of the PC's that are moving I could see that for some of them, but alot of these are people who have worked at the same location for years.  Pretty sure it's not an issue of the computer being moved to a new OU.

I did verify that we are only syncing from one replication parter.

For the replciation partners we have failover, but not load balance. (the US servers and the German server).

There is only 1 entry for the systems in question (I just did a minor search, but they turned up with only one entry for each).

wow, ok if there is only one entry per problem machine in both Clients + Monitors its not the same issue I was seeing.

So basically the machine no longer shows up in the imported OU at all?  It only shows up in the Default Group?  What happens if you force a sync on the OU in SEP where it should be located (ie where it is in AD)?  Almost sounds like the AD sync is missing them (AD perms on those machines non-standard?)

Are there any LDAP errors in your logs anywhere?  scm.log?

%\Program Files%\Symantec\Symantec Endpoint Protection Manager\tomcat\logs\server-scm-0.log

I'm sorry, Yes, the machine shows up in Defualt Groups and in the imported OU.  In the Monitors > Logs, there is only 1 entry.  The system shows up in the imported OU, but there is no connection there (no green dot), if I look for the system in the default group it is there with the green dot.  If I log into that system and check its client it shows as reporting to the default group.  If I force a sync it disappears for a few moments, then reappears back int he default group.  In the SCM-Server-0.log I have several entries for the following: "2009-05-13 15:30:57.554 INFO: PackageTask.publishGroup(): returnCode = 0(Unknown Error Code) errBuf = success" dates and times being different for each, of course.

heres the lines surrounding the error.

2009-05-13 15:38:17.338 INFO: Delta generation request received(DeltaContentTask): {E5A3EBEE-D580-421e-86DF-54C0B3739522},90512037,90513018
2009-05-13 15:38:17.338 FINE: The request for GenerateDelta delta has been processed. Moniker {E5A3EBEE-D580-421e-86DF-54C0B3739522} SrcSeq 90512037 DstSeq 90513018
2009-05-13 15:38:17.369 INFO: PackageTask.publishGroup(): returnCode = 0(Unknown Error Code) errBuf = success
2009-05-13 15:38:17.369 INFO: PackageTask.publishGroup(): success
2009-05-13 15:38:17.369 INFO: Delta generation request received(DeltaContentTask): {C60DC234-65F9-4674-94AE-62158EFCA433},90512053,90513003
2009-05-13 15:38:17.369 FINE: The request for GenerateDelta delta has been processed. Moniker {C60DC234-65F9-4674-94AE-62158EFCA433} SrcSeq 90512053 DstSeq 90513003
2009-05-13 15:38:17.384 INFO: Delta generation request received(DeltaContentTask): {812CD25E-1049-4086-9DDD-A4FAE649FBDF},90512037,90513018
2009-05-13 15:38:17.384 FINE: The request for GenerateDelta delta has been processed. Moniker {812CD25E-1049-4086-9DDD-A4FAE649FBDF} SrcSeq 90512037 DstSeq 90513018

ok, if you are seeing the machine in two locations on the Clients tab your DB has two entries for the same machine and only one of the entries matches the internal Computer ID + Hardware ID of the machine.  Why this is happening is a better question.

You can grab the Computer ID + HardwareID from the registry on a problem machine.  These will match the "Default Group" entries in your DB.  The problem is, initially these were set to the AD OU entry values.  Something changed and your SEPM now thinks this is a new machine, different from the client record in the DB that matches with AD.

HKLM\Software\Symantec\Symantec Endpoint Protection\SMC\SYLINK\Sylink

You can also grab the Unique ID from the console for the same machines in the Clients tab (right click on machine->edit properties->Unique ID)

I can't remember the exact tables in the DB you have to find, but you can dive into the DB with SQL Management Studio and dig out the client tables with these same values, because there is yet another internal DB GUID that is used to reference each machine, which is nether the HardwareID nor the ComputerID and not found on the clients anywhere.


Below is totally unsupported and a I take no responsibility for what happens :) with that said....backup the registry before proceding.

a workaround should be to change the registry keys on the problem machines to match the ComputerID + HardwareID of the "correct" AD client records in your DB.  This will not uncover your root cause, but will get the correct policy re-applied.  You can then delete the extraneous client from "Default Group".  This should not be happening though, so something else is wrong here, I'd keep going with support on that front.

Solution:
Active Directory Integration

Overview
As an optional feature, the Symantec Endpoint Protection Manager can be integrated with the Active Directory. The Symantec Endpoint Protection Manager can import the organizational unit and the account data and synchronize that data with the Active Directory automatically. The administrator can then use the existing organizational unit as a unit to assign the group policy to, just as with a group.

An Organizational Unit is treated as a special type of group because the imported organizational unit and the accounts in that unit cannot be modified. However, the organizational unit along with its data can be deleted as a whole by the administrator. Groups cannot be created under the Organizational Unit. The parent of an Organizational Unit can be the Group or the Organizational Unit. The administrator can select accounts from an Organizational Unit and move them to a specified group, for example, the administrator can create a group for remote users, move all of the remote users from their current organizational unit to a newly created group and assign a group policy that is tailored for the remote users in that group.

Note: The same user may exist in both the group and the organizational unit. In this situation, the priority of the group is higher than that of the organizational unit. For example, assuming both a remote group and an engineering organizational unit contain the “james” user account, then, the “james” user account will use the group policy of the remote group.

Synchronization with Active Directory
Imported Organizational Units are read only. Data in the Organizational Unit cannot be changed manually. The sub Organizational Units cannot be deleted. However, the Organizational Unit root as a whole can be deleted from the system manually because this does not take place when synchronized. The administrator must decide which Organizational Units are imported and if any of the existing Organizational Units need to be deleted. Only the Organizational Unit's data is synchronized with Active Directory. The interval time of synchronization is set in the server panel. For example, if an Organizational Unit or user is deleted from the HQ Organizational Unit, then that unit will not be deleted during a synchronization. However, that user will be deleted from their imported Organizational Unit in the Symantec Endpoint Protection Manager after a while. The latency is dependant on the interval time of synchronization. Users in the group that were copied from the Organizational Unit will not be synchronized automatically. For example, a user "james" is in the Engineering Organizational Unit and is copied into the Remote Users group. If "james" is removed from the Active Directory server, then the user "james" in the imported Organizational Unit will also be deleted, but it will not be deleted from the Remote Users group automatically. In some instances, when the clients register before an Active Directory synchronization takes place, they will register to the temporary group. During the process of Active Directory synchronization, the clients will need to be moved to the correct group.

Adding Organizational Units into Symantec Endpoint Protection Manager

Before an Organizational Unit can be imported, a Directory Server in "Server Properties" must be added:
If there are child domains and nested child domains a Directory Server for each of those domains will need to be added as well.

Solution:
Active Directory Integration

Overview
As an optional feature, the Symantec Endpoint Protection Manager can be integrated with the Active Directory. The Symantec Endpoint Protection Manager can import the organizational unit and the account data and synchronize that data with the Active Directory automatically. The administrator can then use the existing organizational unit as a unit to assign the group policy to, just as with a group.

An Organizational Unit is treated as a special type of group because the imported organizational unit and the accounts in that unit cannot be modified. However, the organizational unit along with its data can be deleted as a whole by the administrator. Groups cannot be created under the Organizational Unit. The parent of an Organizational Unit can be the Group or the Organizational Unit. The administrator can select accounts from an Organizational Unit and move them to a specified group, for example, the administrator can create a group for remote users, move all of the remote users from their current organizational unit to a newly created group and assign a group policy that is tailored for the remote users in that group.

Note: The same user may exist in both the group and the organizational unit. In this situation, the priority of the group is higher than that of the organizational unit. For example, assuming both a remote group and an engineering organizational unit contain the “james” user account, then, the “james” user account will use the group policy of the remote group.

Synchronization with Active Directory
Imported Organizational Units are read only. Data in the Organizational Unit cannot be changed manually. The sub Organizational Units cannot be deleted. However, the Organizational Unit root as a whole can be deleted from the system manually because this does not take place when synchronized. The administrator must decide which Organizational Units are imported and if any of the existing Organizational Units need to be deleted. Only the Organizational Unit's data is synchronized with Active Directory. The interval time of synchronization is set in the server panel. For example, if an Organizational Unit or user is deleted from the HQ Organizational Unit, then that unit will not be deleted during a synchronization. However, that user will be deleted from their imported Organizational Unit in the Symantec Endpoint Protection Manager after a while. The latency is dependant on the interval time of synchronization. Users in the group that were copied from the Organizational Unit will not be synchronized automatically. For example, a user "james" is in the Engineering Organizational Unit and is copied into the Remote Users group. If "james" is removed from the Active Directory server, then the user "james" in the imported Organizational Unit will also be deleted, but it will not be deleted from the Remote Users group automatically. In some instances, when the clients register before an Active Directory synchronization takes place, they will register to the temporary group. During the process of Active Directory synchronization, the clients will need to be moved to the correct group.

Adding Organizational Units into Symantec Endpoint Protection Manager

Before an Organizational Unit can be imported, a Directory Server in "Server Properties" must be added:
If there are child domains and nested child domains a Directory Server for each of those domains will need to be added as well.

I think we had the same problem. MR4 MP1A throughout (at least at the end).

In our case, the problem was triggered by "duplicate" clients. When you uninstall/reinstall SEP, or re-image a machine and give it the same name as it had before (or several other common scenarios, some of which are documented in one of the KB articles cited previously), the SEP client gets a new Unique ID. But once an AD computer object has a UID in SEPM, SEPM never lets go of that UID.

You didn't mention this, so maybe it's not the same problem. But we'd see a computer object in the original Group with an obsolete UID, and another with the same name in Default Group with the new UID. The ones in Default Group would come and go, as would the green dots on the clients.

I worked with Symantec for 2.5 months. Sent them many MB of database copies, logs, and everything imaginable. They even wanted me to give them a copy of the machine as a VMware file. (Didn't do that because there's confidential data on the server.) Made NO progress.

Finally, backed up Policies and PKI, uninstalled SEPM, deleted the database, and reinstalled SEPM with a new database. Imported OUs, applied Policies and restored the PKI. Clients checked in, but as soon as I uninstalled/reinstalled SEP, I repro'd the problem. Everything I've seen has convinced me that this feature in SEPM is just plain broken.

So I cut my losses. Pulled the plug on OU integration and fell back to the way we used to "integrate" OUs with SAV: Create a GPO with a Startup Script that runs SylinkDropper to drop the appropriate Sylink.xml. Install the clients as unmanaged (in our case, also by GPO) and let SylinkDropper convert them to managed, and put them in the right non-AD Group. Works great.

Only thing SAV could do better was that dropping a GRC.DAT let you move a client after it was already in a Group. SylinkDropper can't. But Paul Murgatroyd says that's coming: www-secure.symantec.com/connect/forums/move-client-new-group-startup-script

I'd still like to use OU Groups. It's self-documenting and much less fussy than Startup Scripts. and maybe I'll be able to someday. In his last e-mail to me when we closed the support case, the tech said, "Keep an eye out for MR5, Active Directory Synchronization should be greatly improved thanks to the changes in Hardware ID handling."

I certainly hope so.

Jeff, I think you've hit it right on the head, this feature (integrating AD) just isn't quite ready yet I'm thinking.  I could see my user's computers moving around due to rebuilds, reinstalls, or just oddities with using VPN to access the network, but I've got servers in there that don't get touched by humans but once in  a blue moon.  Thats the frustrating part.  But, at least we have our location awareness setup so that they clients still pull from thier local GUP's no matter what group they put themselves into...servers that wind up in the default group end up pulling updates from the main console, but there are thankfully few of those that have been affected as of yet.

Jeff,

We don’t use AD integration and still had problems with computers moving back to the default group. We also had incorrect data displayed in the SEPM console (many definition/scan/IPS failures, etc). I too worked with Symantec for over two months trying everything to resolve this. We too had to bite the bullet and uninstall / reinstall all SEPM’s and blow away the embedded database (oh, how fun!!!) and use the disaster recovery techniques to get things working again.

As you mentioned, the computers moving groups was directly related to the UID and given the fact that we deploy and rebuild computers (quite often) from a Ghost image with SEP already installed, I created an SMS job to delete the registry entry for the UID and pushed it out to all computers including new ones we’re building (too many Ghost images to strip out the UID key, so it was easier to push out to all computers). I was fine with this as I tested many computers first and definition/policy updates were not affected by this if the computer did not reboot right away (several days) to regenerate the UID.

I now have absolutely no problems with incorrect data in the SEPM console or computers moving groups any more.

RickJDS, thanks, but that is dangerous advice for users with OU groups. Lurkers, beware!

If you use OU integration and delete client UIDs so they will be regenerated, you will cause duplicate client problems for every client for which you do this, and they will all land in Default Group. (Well, we had a couple land in My Company.)

Rick, your problem sounds like it may be what my tech was talking about to me at one point...IIRC, it was MR2-created databases had this problem. The problem the OP and I have is a different problem with similar symptoms. My database started out life as an MR2 database, and for a while, we were approaching it as though that was the root cause. But it wasn't.

And since I've created a new (MR4 MP1A) database with non-OU Groups, I've also not had the problem.

The problem with OU imports is that once an AD computer object is assigned a SEP UID, SEPM will never allow the UID to be changed. Ever. The UID is permanent. And you can't delete the computer objects (through the UI...you can delete them with SQL commands) so SEPM never "forgets" the old UID. The only way you can delete them in the UI is to delete the entire OU that contains them, re-import the OU from AD, and reconfigure its Policies. SEPM won't allow the new client to occupy the same OU as its predecessor, and drops it in Default Group.

Even if you create a non-AD Group and move the Client to it, it eventually goes back to Default Group.

BTW, another fun angle on the same OU Group problem I'll document for lurkers that may be seeing this behavior: I discovered that if you import user OUs as well as computer OUs (for example, by importing all OUs in AD), and there is a computer with an obsolete UID in the computer OU, the computer will land in whatever OU the logged on user is a member of instead of Default Group. Never a dull moment with OU Groups!

Slow down there red riding hood!  Jeff, if you didn't notice, I specifically addressed your name in my post - you should re-read it, (if its not apparent to you, please let me know and I'll suggest it for improvements).  I posted this as a discussion for you since you converted to non-AD integration as an FYI for your deployment.  I also clearly stated that we did not use AD integration (re-read if you will and let me know how else to make it more clear).  I'll be sure to clearly state my intentions to you in future posts (if there are any) so we don't create a panic, LOL. 

If you have suggestions to make it more clear that someone replies to your specific post in the future, please make them known.  I'm sorry you felt that I was offering this solution to the orignal poster as this was not my intention.

Just to clarify even further for any *lurkers* out there that Jeff identified, when I referred to the UID that was mentioned earlier, I really meant the HardwareID key in the registry to the second link I posted earlier.  The term UID is not defined by Symantec SEP (I could be wrong and I'm sure someone will correct me), but is found in BackupExec and SEP uses the HardwareID key in the registry.. 

Hardware ID's stay with the client even if you're rolling out computers using Ghost or other imaging software that had the SEP client installed before taking the image and this is not dependant on integrating Active Directory OU's.  This is the reason Symantec posted the KB article about it (posted above) and am why I'm posting this respone.  Using imaging software and not deleting registry keys defined in my earlier post before imaging (second link from Symantec), will result in client computers moving groups back to the default group that was defined in the install package used to install a client (this is my experience, FOR NON AD INTEGRATED OU's).  Jeff, I hope this is clear for you now.  If anyone needs more clarification, please PM me.

Rick, no offense intended then, or now, and thank you for clarifying that your advice does not relate to OU-enabled Groups. Had I not had experience with OU-enabled Groups, I would not have known that the article does not apply, and I might well have posted it without caveats, too. And it should also be clarified by Symantec in the KB article until the OU-enabled Groups issue is resolved, because they know they have a problem with this.

Regarding the term UID (you used it as well, of course), it is displayed in SEPM in the Client properties:



Signature of the problem in an OU Group setup, (at least here; as yet unconfirmed by OP), is that 2 clients have the same name, but different UIDs.

I now see that the UID is different from the Hardware ID, and, indeed, all the IDs in the Sylink registry node. If I had to guess (and I do), I suspect a UID is generated by SEPM for each Hardware ID. Or generation of the UID may well be more involved than that; there is no shortage of IDs in the Sylink registry branch from which to derive it! However it's generated, the UID is then used to reference the SEP client within the SEPM database.

But the result is the same: When the Hardware ID and/or some other client-side ID data changes, SEPM is not associating the new ID data with the old UID in its database. So a new Client, with a new UID, but with the same name as the old Client, is born. And with no corresponding AD object to indicate in which OU to place the new Client, it lands in Default Group, and has intermittent communication problems with SEPM.

Hi All,

Recently I had a cllient with a dead NIC, im using AD intergrated computer groups.

One problem I have recently encountered is a PC with a dead NIC, the current PC in the AD group no longer connects and is showing as having old def's/policy which messes a little with stats. From time to time this computer POPS up in the default group where it shows as being up to date with a different client UID .
 
I also have a laptop which is doing the same, the issue I think is down to the fact that the initial installation was performed whilst the laptop was connected via the ethernet NIC, however the user in question uses his wireless pretty much all the time and not the ethernet cable due to the fact that he is always moving around the building whilst performing his job.

Fortunately the clients seem to be collecting the correct policy for the AD group they would be in and getting def's from the correct GUP.

Is there a proposed fix for this in that future builds or is there an easy fix I can implement now? 

If not im happy to leave these two clients alone. However this will become more and more of an issue over time due to rebuilds and hardware changes.

NIC change or wireless vs. wired sounds like they would be triggers, all right.

Until someone official chimes in with something authoritative, here's what I've been told by my tech (who also steered me wrong on other issues, so consider the source): Symantec tells me to expect that the database for AD Groups will be significantly redesigned in MR5.  Symantec knows they have this problem. Whether this problem is related to the database design or programming bugs, or whether they've traced the cause, I do not know. I asked when they expected to release MR5 and was told there would be at least an MR4 MP2 and maybe an MP3 before MR5. So...late summer or fall, maybe?

The more people who report it, the more attention it will get from Symantec, so lurkers, please post your problem!

My speculation: If it's database design, it will be fixed in MR5. If it's a bug, it could be fixed in any release. I haven't seen the MR4 MP2 Release Notes yet but I doubt it's in there...they were still clearly in information-gathering mode during my recent service ticket. My hunch is that it's a bug.

I was given SQL commands by Symantec to delete the problem clients to let them re-enroll, but I don't have the procedure, and we never actually did it. What we did, because the database format inherited from MR2 was suspected. was export Policies and PKI, delete the entire database, then create a new database, import OUs, import and apply Policies to them, import PKI, and let the SEP clients re-register. But I wouldn't call that an easy workaround!

Just reading the release notes for the latest version and saw the following.

---------------------------------------------------------------------
Hardware changes might create duplicate clients in the Default group
---------------------------------------------------------------------
Making hardware changes to a client computer that is in a group synchronized with Active Directory might cause the client to be duplicated and registered to the Default group. To fix the problem, enter the following URL in a browser on the computer running Symantec Endpoint Protection Manager:

http://127.0.0.1:9090/servlet/ConsoleServlet?ActionType=ConfigServer&action=CleanClients

Entering the URL runs a program that deletes all duplicate clients from the Default group and sets the hardware keys of the clients in the OU group to NULL so they automatically re-register to their former Active Directory groups.

Not tried it yet but hopefully this will apply to the fault I am experiencing, will give it a go when a moment of bravery takes me, and I perform the upgrade ;o)

Good catch, JimmyR! Sounds like it's exactly the workaround we're looking for.

As it happens, I just induced this problem by re-imaging a machine at another site where we are still on AD Groups. So I'll give it a shot, too after I get a chance to do the MR4 MP2 upgrade. Hope it works...I'd much prefer to use AD Groups than the home-brew AD integration via SylinkDropper & Startup Scripts I've described elsewhere in this thread.

It's also means that they've identified the cause and can (presumably) prevent the problem in a future MP/MR instead of providing an after-the-fact workaround.

Wonder if I can set up a Notification Condition for when clients join Default Group...hmmm...

[Edit]Yep. A Client List Change report filtered for My Company\Default Group. Done.

This isn't a solution for the Default Group OU issue, but it's a pretty handy trick in its own right to simplify your SEPM config, and it would work around your Default Group GUP issue--

If you have at least one DC on each subnet capable of serving as a GUP, use the FQDN of your domain (domainname.local) as the GUP. DNS will resolve it to the closest DC automatically, you won't ever have to think about setting up a GUP again, and there's no fussing with Locations and multiple LiveUpdate Policies (unless you have other needs for them).

If you don't have a DC at each site, you can still use DNS; it just requires a little more work. Create A records named "GUP" with the (static) IPs of all your GUPs, and set the GUP to gup.domain.local. The DNS client will choose the closest one.

If no DCs or GUPs are local, it's probably a really small site, and the additional bandwidth used may not matter.

Apply this at the My Company level (and to any Groups in which inheritance is disabled) and  all of your clients, including those in Default Group, will find the right GUP.

[Edit] This works for the clients, but does not enable the GUPs themselves. See https://www-secure.symantec.com/connect/forums/managing-hundres-gups#comment-2511411 for additional instructions.

Hi All,

I have updated SEPM and my clients to the latest version 11.0.4202.75 and can confirm that the fix I have listed two posts up from this one works.

I waited for the clients to randomly appear in the default group, then opened my browser on the SEPM and entered

http://127.0.0.1:9090/servlet/ConsoleServlet?ActionType=ConfigServer&action=CleanClients

The clients in question took a bit of time, but then corrected themselves in the AD group to show they had the latest version and virus defs!

Hope this works ok for everyone!

Jamie

Just what I was looking for!
Thanks, I will try it ;)

BTW, there's a workaround on another post that worked very well: www-secure.symantec.com/connect/forums/move-client-group-active-directory

A new problem now =/

I'm seeing 2 computers with the same name within the same OU (not one on the OU and another at the Default Group).
The second computer is a clone of the first one.

Does anyone knows if the solution posted above will work for computers outside the Default Group?

Hmmmm....do you have users & computers in the same OU?

Unfornuatly I've tried the clean clients command and it has not cleared up the issue for us.  I've still got about 90 clients stuck in the 'default group'. 

Eduardo, I don't believe that the solution will work for you in that case, what I would recommened is deleteing that OU from within Endpoint and then readding it.  It should straighten things out again for you.

Jeff, only computer accounts

Mike, I'm afraid to try it and loose communication with the clients. But I think I'll try it one day, or, as a last try, reconstruct the whole server and reestablish the communication. A bit aggressive, but actually it seems to be the faster way...

Deleting the OU from SEPM and then deleting any rogue machines from the Default Group (if you have any there) and then reimporting the OU from AD seemed to work for me in both regards i.e

1) With having clients in both the OU and the Default Group but only registering a green dot in the Default Group
2) Having the same PC listed twice in the OU Group.

Once i'd deleted and readded the OU's the clients didn't take long to check back in and (so far) i haven't had any report back to the Default Group either.

And if i've read correclty from the above material MR5 should hopefully sort out some of these AD issues.
Hope this helps.
Rob

I'm afraid that I've tried that as well.  After a day or so everything migrated back to the default group.  Symantec Support has given me a new tool that will go thru and clean everything up and delete any duplicates, but that would do more damage than good since I've got alot of systems copied out of thier OU groups and into SEPM groups so that I can apply different policies to them....to have them go back to thier OU group and have those policies applied would be very bad for some of our systems....

Looks like I'm pretty much back to waiting for the next release....because of course that will fix this!

Hey Mike,
 
i've just had to setup a different OU for clients that are going to be away from the office for a while to allow them to get update from the Symantec site rather than a management server.

Could you do something similar rather than creating other SEPM groups? Or is it not that simple?
Cheers,
Rob

Look in to the Locations feature.

Yeah, the Locations feture works very well. For me is one of the best SEP features.

Here we created two locations, and for each one we attached a different LU policy: one to download from SEPM, and the other to allow manual LiveUpdate from the client.
The locations were configured to change if the client can find our DNS and gateways.

Meant to include this in my reply: https://www-secure.symantec.com/connect/articles/locations-based-rules-and-what-are-they-good

I've actually created about 70 locations, based on DHCP server to allow our clients to wander amongst all of our offices and pull updates from thier local office...we had a case of a dozen or so engineers going into a small remote office and then pulling updates....it just about killed the wan connection for that location to have them all pulling updates at the same time.  Since then we've been doing location awareness.

As far as creating a new OU for people that are going to be wandering, thats not really a good choice for us based on the size of our company...I never know who is going to be where/when.

Getting way, way, way off-topic, here, but pretending that doesn't matter...<g>

"I never know who is going to be where/when."

Unless I'm misunderstanding, that sounds like the BEST reason to use Locations to me! It's the only way you'll ensure that SEP clients can always get content updates. But if you don't want to do that, then, yes, creating online and offline OUs and manually moving clients among them is your only choice.

Personally, I would not use Locations for finding GUPs...way too error-prone, fussy and complicated in SEPM (except that you've evidently already done it!). I'd let DNS do the heavy lifting:

If all your sites have DCs (per best AD practice) and always will, make each DC a GUP. Then, in your LiveUpdate policy, tell Clients to use "domainname.local" as the GUP name and they will choose the nearest GUP. A zero-maintenance solution.

If you don't want to use DCs as GUPs for some reason, or don't have them at all sites, it gets only slightly more complicated. Assuming you have at least a server at each site with a static IP, create A records in DNS for your GUPs, all named "gup.domainname.local", and enter that in your SEPM LU Policy. Again, SEP will automagically choose the nearest GUP. Still simpler than fussing with Location policies.

Leveraging DNS for locating GUPs will GREATLY simplify your SEPM config. And you won't need to complicate your OU tree just to accomodate offline SEP clients.

One more problem to the list.
There are the computer accounts that go to Deafult Group, the computer accounts that appears twice on the same OU, and now a computer account that was moved on AD but does not change on SEPM

Let me explain: I have an OU with hundreds of computers, and an empty sub-OU that is used for tests. On the AD I've moved one computer account from the parent OU to the sub-OU. But now SEPM is showing me the same computer account on both OUs. Even worse, only the computer account on the wrong OU shows the online indicator (green dot), while the one on the sub-OU is always offline. The computer itselfs is receiving the wrong policies.

This problem persists since yesterday. I tried a lot of things: SylinkDrop, SylinkReplacer, restart the computer, forced SEPM-AD synchronization billions of times, reinstalled SEP on the client, deployed a new packge directed to the sub-OU... nothing helped.

Please Symantec, would you fix these silly AD sync problems on MR5? This feature is very important, but never worked well, since pre-MR1 releases!

if your rigth click on default group
click on properties
check the option block new clients
does your AD clients , still go to default group?

I can't do that =/
Some computers (very few) are not members of the domain. When one of those computers joins the network, the Default group is the only place where I can see the new clients.

By right-clicking on the My_Company group.

Move your non-AD computers into that group and then you can test the way that was suggested. 

But my problem is when new non-AD clients communicate with SEPM. How will I know when this kind of computer appears?

Anyway, I can at least test this, but even if it works the big problems won't be solved (duplicated computers accounts inside the OUs, out-of-sync SEPM-AD)

Eduardo, sounds like you have a big enough problem that if you can't hang in there until MR5 (AKA RU5), supposedly next month, which supposedly includes a rewrite of the OU-enabled SEPM database, that you might want to dispense with importing OU Groups altogether and use SEPM groups. In my system, it was not a big project, and it all works smoothly...YMMV.

The big plus is that you don't actually lose AD integration altogether...you just provide it outside of SEPM. I documented what I did here--

https://www-secure.symantec.com/connect/articles/startup-scripts-and-sylinkdrop-better-together

HTH

and has great information for people who may or may not need AD sync in their environment.

I take calls fairly frequently from customers whose AD isnt setup the way they want the SEP environment setup anyway and most are very willing to do what Jeff describes in his article.

Thanks for the tip, Jeff. I liked it too.

I think I'll wait for RU5. I'm really willing that those AD sync problems get solved by it.

I also hope they're solved in the next release, and plan to return to OU-imported Groups at some point. But like you, Eduardo, I got burned pretty badly by OU Groups, and I'll likely leave it like it is for a while, watch this board, see if it's really fixed, and that it doesn't contain new unpleasant surprises.

Thanks, Jeremy!

So are these issues fixed with RU5?  If they are...is it the SEPM, client, or the combonation of both that need to be at RU5 to fix the issues?  Thanks

yes ... we had the same issues pretty much and they were all fixed as soon as the latest ver of SEPM was installed.  The OUs were all cleaned up by the time I signed to check.


cheers,
Chad

I'm deffinetely still seeing some similar issues but the server was upgraded a few weeks ago to RU5...the clients are a mixture of MR3 and MR4.

I think it was finally fixed.
Just a few machines that insist on appearing on the Default group, but after reinstalling SEP on them, their accounts go to the right OU.

I´d like to run the http://127.0.0.1:9090/servlet/ConsoleServlet?ActionType=ConfigServer&action=CleanClients functionality as a scheduled task, is there maybe an executable for the action available ?
Thanks
Andy