Endpoint Protection

Hello,

I want to add Symantec endpoint protection maanger in AD and Syn.

so any configuration require in Domain controller for like Firewall Port for Syn. etc..

 

Please share.

 

Thanks in advaince for help.

 

Regards,

D.Chouhan

 

Steps should be here:

Upgrade or migrate to Symantec Endpoint Protection 12.1.6 or 12.1.6.1

No. You would need to do a manual discovery.

Hello,

 

I am new for SEPM ,

 

And i want to install SEPM in Member server 2012 , so can you guide me that SEPM Computer AD user any group member require .

 

Exp: Domain Admin, Enterprise admin,Schema Admin etc.

 

Regards,

D.Chouhan

if one user is added to AD and then sepm 12.1.5 is automatically find the user and push the agent??is it possible??

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

@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...)

Jeff,

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

Thanks for sharing.

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.

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...

it truly helps me!

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.