Endpoint Protection

At this site, SEPM Groups are imported from AD. I've imported ALL of AD, not just OUs containing computer objects, so I'm susceptible to the variation on the duplicate client bug where the duplicates appear as Users in user OUs who have logged on to a computer affected by the duplicate client bug.

In MR4 MP2, I had 2 User objects in SEPM that shouldn't exist that were created by the duplicate client bug. In this case, it was triggered by a NIC change and a bare metal Windows reinstall while MR4 MP2 was installed on SEPM and client. Now, after upgrade to RU5 on both SEPM and problem client, the duplicates are still there.

On the advice of a poster in another thread, I ran the script that's supposed to remove dupes. But, as I expected, it didn't work, because the documentation still says the script only works when the duplicates are in Default Group. In my scenario, they are in a user OU. And, unfortunately, one still can't delete SEPM objects when they're imported from AD.

1. Is there a way to surgically remove these duplicates? Or do I need to delete the AD-imported SEPM Groups, re-import them, and re-assign Policies to the newly-imported Groups?
2. As far as Symantec or any users with relevant experience with AD-imported Groups knows, is the duplicate client bug with AD-imported Groups really, really fixed in RU5?
    

TIA

not sure, if i have read it correctly, the client also needs to be upgraded to RU5 and the entry needs to be deleted once from SEPM

Client is updated to RU5.

How do I delete the entry (2 extra entries for the same computer, actually)? The script doesn't work, and you can't delete SEPM objects when they're imported from AD. At least not from the SEPM Console.

Unfortunately, I can confirm that another aspect of the duplicate client bug is **NOT** fixed in RU5.

Just uninstalled SEP MR4 MP2 on a client whose RU5 in-place install was failing with a 1603 error, rebooted, and then installed RU5 interactively. SEPM added an object for the user account that I first logged on to the new RU5 client with to the SEPM Group whose OU contains the AD user object.

I still don't know what would happen if I uninstalled RU5 and then reinstalled RU5. Haven't tried that. I guess I should. Maybe tomorrow because it's too late tonight.

But this is NOT a good sign. I still don't feel like I can trust SEPM's AD integration.

I have now uninstalled and reinstalled two RU5 clients. No SEPM duplicates were created. So I'm cautiously hoping the dupe problem is fixed when both SEPM and clients are at RU5. Hope I don't have to return to modify this post.

But if you have pre-RU5 clients, expect the same old duplicate hassles until you upgrade them. I believe the documentation should reflect that.

I'm a little dismayed that no Symantec techs have contributed anything official from their side. But maybe they were waiting for me to make it official since I've been whining about this for so long<g>.

Beware, AD users. There's still a problem.

I spoke too soon in my prior message.

SEP RU5 now installed throughout the system. Took an existing Vista client (and domain member) on which SEP RU5 was installed, and did a bare-metal install of Windows 7. Instead of resetting its computer account in AD, I deleted it and let SBS Connect wizard create a new one. This action created a duplicate client in SEPM upon installation of SEP.

In the interim, I've redesigned my OU imports so I no longer have user OUs in SEPM. This at least landed the duplicate in Default Group, within reach of the http://127.0.0.1:9090/servlet/ConsoleServlet?ActionType=ConfigServer&action=CleanClients script workaround, which now, finally, helps.

So maybe the problem is better, maybe not...BUT IT STILL ISN'T FIXED.