Better Active Directory computer accounts synchronization
The Active Directory synchronization feature of SEPM is very import to us. It was one of the main reasons why we choose Symantec as our security solution.
We have decided to import the OUs where the computer accounts are located. But ever since its implementation we have been facing problems with it. Every time a computer is renamed, or something goes wrong on a machine and it needs to be re-joined to the domain, the old computer account still remains on SEPM, on the same OU. After some years and 4 migrations (MR1 -> MR2 -> MR3 -> MR4), you can imagine how messed up the computer accounts are on the server.
After reading the forums and some articles, I found that computer accounts are identified by unique IDs, and that the older ones are never removed from the server. If a machine is renamed, two IDs for the same computer are set on SEPM database, and sometimes the older machine name appears as online, while in fact it doesn't exist on the AD anymore. The reports get messed up to due to this situation. This uncontrolled situation has made the Quality department warn us several times.
So, I'd like Symantec to work more on Active Directory synchronization, to make it better. I'd like that SEPM shows the "real situation" of my environment.
I read on the Release Notes of MR4 MP2 that there's a new tool to remove those duplicated computer accounts, but it seems to only work with those ones that appear on the Default Group. My problem is not there, but is inside the OUs.
Thanks in advance,
Eduardo Nazato
Comments
AD clients are not deleted from reports
We have a client that was physically damaged so that we cannot uninstall the SEP and it still appears on the reports even though we have deleted it from the actual AD.
We see the occasional
We see the occasional database issue where we have one active client that ends up in the root My Company or Default group and a duplicate of the same client in a synchronized AD group that appears not to have a client. No idea why that happens but it would be nice to have a tool that would enable the merging or association of those two clients so that I didn't have to go in and fiddle with the SQL table.
We have found some
We have found some undesirable behaviour in the SEPM console when re-imaging a workstation and then re-installing the SEP client. In brief, once the client is installed we get a duplicate entry in the SEPM console (one appears in the Default Group and the other in the AD synced OU). In addition to the duplication, the client will appear in the console as unmanaged.
The response from the support rep is that this is expected behaviour and that we should try uninstalling the SEP client before re-imaging the machine. You can appreciate that in a corporate environment it is not practical to have to implement this additional step and is not even possible in some circumstances.
similar here, without AD!
We don't use the AD integration with SEP, as it would unnecessarily complicate matters in SEP. We started out with SEP 11.5002.333 in March 2010, which i believe is R5. We're still rolling out SEP company-wide, and at this point we only have it on about 9000 computers, but expect to have it on the rest by the end of May.
That said, any time a machine is reimaged (physical repairs, corrupted by virus/trojan/Lusers, etc) it creates a new duplicate entry in SEP. In pretty much 99% of these cases there's no reason to waste time trying to uninstall SEP, and in 99% of those cases it's impossible - you can't even boot to windows.
Sure, the best practices might be to try and do things nice and pretty like that, but here in the real world, that's just not possible. We have only 15 people to service 26,000 (yes, twenty-six thousand) computers in our organization. This summer, we're opening 3 new campuses which will add another 2000 or so computers... and no new techs. And even if we did have time, when hardware fails or the OS is completely trashed, there's no possible way to uninstall the product. Not only that, we don't want that many people to have access to the SEPM console.
There has GOT to be a better way to handle this. unique IDs are nifty, but they only seem to be causing problems here. can we simplify it and have it just look at the first MAC address of a machine or even the computer name rather than unique IDs randomly generated each time the product is installed? yes i realize that won't cure 100% of the duplicates, but it sure would cut down on them immensely - the majorty of our reimages are done due to software corruption and hard disk failure. the way i understand it, the unique ID shouldn't change if none of the hardware in the PC changed. System board (and thus integrated nic) replacement aren't near as common, so creation of dupes would be minimal and manageable.
Maybe talk to the altiris guys and see how they handle it, now that symantec owns altiris.
If a Connect post helped you out, be sure to click "Mark As Solution" or the "Thumbs Up" button to let other users know about it.
I can see what Symantec are
I can see what Symantec are doing here, they are applying a Microsoft best practice to SEPM however as with a lot of Microsoft best practices... the real world is very different. All companies are now constrained by costs (especially in the current economic climate). If Symantec and Microsoft adopt a best practice which adds to the over all resource effort in doing something then they are contributing to costs - not removing them which is bad! Symantec need to see sense and listen to the people on the ground dealing with this stuff on a daily basis...!
Also, AD causes issues with
Also, AD causes issues with the 15 character NetBIOS limitation. When AD syncs to SEPM, the machine name gets truncated at 15 chars. This client shows in SEPM in the correct group, but gives no client details and appears unmanaged. Then the full/correct client name appears in the 'Default Group' and appears to be managed. So basically, the same client appears twice in two different places and states. This skews reporting badly.
Would you like to reply?
Login or Register to post your comment.