Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.

Best Practices for AD Integration with SEPM

Created: 26 Jun 2009 • Updated: 29 Jun 2009 | 7 comments
Language Translations
Prashant Bharadwaj's picture
+2 2 Votes
Login to vote

To have a good experience with AD integration, I have collected a few best practices that you can do,

1. Create a new user account exclusively for SEPM in AD. Ensure that password never expires and also enable User cannot change password.

imagebrowser image

2. In the Admin Tab, right-click on the server, click Edit Server Properties. In the Directory Servers Tab, click Add.
Fill in the General information

imagebrowser image

Use of Secure Connection is more recommended if the SEPM is installed in a different server from the Domain Controller. Please note, you need to turn on this feature in the Domain Controller too.

3. In the Replication Servers tab, add the replicating Domain Controllers, if any.

imagebrowser image

4. Change the synchronization to a number between 2 to 8 hours. Minimum the syncopation interval, the data in SEP-Manager remains intact more.

imagebrowser image

4. In the Clients Section of the manager, select My Company and click on Import Organizational unit or container. Select the OU to be sync and push OK.

imagebrowser image

See your manager synchronizing with the AD like a charm!!

Comments 7 CommentsJump to latest comment

JRV's picture

Suggestion: DCs come and go, but the domain is forever.

So, instead of specifying the name or IP address of a Domain Controller, use the FQDN of the domain. (In BharRie's case, probably "geekghandi.local".) This way, you won't have to coordinate SEPM when you replace a DC (or if a DC goes offline for any reason). SEPM will just choose a surviving DC the same way Windows clients do.

Also beware the duplicate client bug, still present as of SEP 11.0 MR4 MP2, albeit with a new workaround (in the README), and discussed at length in the Forums. But be careful: The workaround won't help you if you import user OUs along with your computer OUs. So a best practice for now would be to import OUs that only contain computers; not the entire OU tree. You'll have to dispense with user settings if you do that.

+2
Login to vote
Kadoneng's picture

it truly helps me!

+1
Login to vote
Nel Ramos's picture

This is very interesting...
@:Jeff Vandervoort: How do you use the FQDN of the domain?
I am very interested..
thanks..

Hope you could also provide KBs or links..
thanks again...

Nel Ramos

0
Login to vote
Prashant Bharadwaj's picture

Jeff,

I am wondering if SEPM works that way you suggested. As far as to my best knowledge, SEPM takes only the IP address or the name of the server. For a better redundancy, Replicating DC shall be used as I suggested in the article.

Prashant Bharadwaj, CEH, MCTS Windows Server 2008 Active Directory, Configuration, SCS Symantec Endpoint Protection 11.0

0
Login to vote
JRV's picture

@Nel: If your domain name is domainname.local, type domainname.local where BharRie typed 192.168.10.11.

@BharRie: I'm not in a position to tell Symantec what's supported or how SEPM is designed...but empirically, it works like a champ, here.

The domain name DOES resolve to the name of a DC. Actually, it resolves to the domain name of ALL of your DCs, but the Windows DNS client will choose a DC on the same subnet if possible. Try it:

NSLOOKUP domainname.local

--returns IPs of all DCs in domainname.local.

PING domainname.local

--chooses one DC on the same subnet (assuming one is available) and pings it.

That's just normal TCP/IP behavior we're leveraging for SEPM. We use this for lots of things that need DCs for authentication, like network scanners, KVM-over-IP's, SEPM's AD authentication feature, specifying GUPs for SEP clients, etc. Works every time.

What I don't know is if SEPM is designed to failover to another DC. My guess is that it's not (though my opinion is that it should, and I will probably submit this shortly in the Ideas section!) It will find a new DC when SEPM is restarted. It DEFINITELY will find a new DC if a DC is demoted in favor of a replacement, because the old one will be removed from DNS.

Here's another way to look at it, since I can't prove it will work in all scenarios:

If it does fail over, then what I've said is true: Configuring SEPM in this way allows SEPM to choose another DC, if only after restarting SEPM.

If it doesn't fail over, then you're no worse off...you'll have to remember to reconfigure SEPM if the DC you've chosen goes away.

And if you have a problem, or on direction of Symantec Support for troubleshooting purposes, change the setting to the name or IP of a specific DC and see if the behavior changes. (But I've never had to do that...)

0
Login to vote
Prashant Bharadwaj's picture

Jeff,

This is surely interesting. I will surely try if this works. I appreciate your knowledge. :)

Thanks for sharing.

Prashant Bharadwaj, CEH, MCTS Windows Server 2008 Active Directory, Configuration, SCS Symantec Endpoint Protection 11.0

0
Login to vote
Erik Kuipers's picture

we are using FQDN for all our SEPM implementations since our first installation and it works like a charm. If you have redundant DC's this allows automatic fail over in case a DC becomes unavailable.

Also we use a DNS alias for our SQL server which prevent reconfiguring our SEPM in case of a Database server failure and the need to fail-over to our DR server.

Erik

0
Login to vote