Video Screencast Help

Can't deploy SEP to client

Created: 22 Feb 2013 | 7 comments
k-h's picture

I have just been landed with managing a working SEPM system on a number of clients.  I can't deploy SEP onto a new client.  It asks me for a "local administrator account" then gives me a dialog with spaces for a user, password and domain.  How can a local account have a domain?  I can't get it to work using any of the normal domain accounts.  Is this some special SEPM thing?  How do I find the account and password?

Operating Systems:

Comments 7 CommentsJump to latest comment

ᗺrian's picture

You need to use an account that has admin privileges. I believe this is a little misleading. The local admin account in this case would be your domain account (which needs admin privs).

If they were in a workgroup, you would use the local admin credentials of the PC you're pushing to.

Are you on SEP 12.1?

This document outlines what is needed

Steps to prepare computers to install Symantec Endpoint Protection 12.1 client

padding: 1px;padding-bottom: 3px ;font: 12px Arial; text-align: left;">Article:TECH163112 padding: 1px;font: 12px Arial; text-align: left;"> |  padding: 0px;font: 12px Arial; text-align: left;">Created: 2011-06-23 padding: 1px;font: 12px Arial; text-align: left;"> |  padding: 1px;font: 12px Arial; text-align: left;">Updated: 2012-01-17 padding: 1px;font: 12px Arial; text-align: left;"> |  padding: 1px;font: 12px Arial; text-align: left;">Article URL

Set administrative rights to your client computers

To install the client software, you need administrative rights to the computer or to the Windows domain. If you do not want to provide users with administrative rights to their computers, use Remote Push Installation to remotely install the client software. Remote Push Installation requires you to have local administrative rights to the computers.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

Rafeeq's picture

if you want to use local admin ID and password

in the dialog box type

.\localadmin ID

and password

Ashish-Sharma's picture

Account Privileges

Please ensure the account being used to deploy the SEP client has sufficient privileges and is not a restricted account. In most situations, it is most appropriate to use a domain administrator account. If this is not possible, use a local administrative account for the remote computer, but be aware of the UAC restriction (above).

Remote deployment of SEP 11 clients from the SEPM to other domain member computers may fail due to Microsoft changes in the networking defaults of Windows 7 and above. When the local system account connects to other computers that are not in the same domain it uses a NULL session (which allows SEP client deployment).  When local system connects to other computers that are in the same domain it tries to use the computer name to authenticate. In older Windows versions this connection could by default fallback to a NULL session. In Windows 7 and above the default behavior does NOT allow this fallback. The solution is to updgrade the SEPM to SEP 12.1; a workaround for SEP 11 is to run the SEPM service as domain administrator or add the SEPM's Active Directory computer account to an Administrative Group.

Thanks In Advance

Ashish Sharma

rs_cert's picture

Hopefull your Login ID Password has no admin access to install the application on any clients and may be that clients where are deploying the package that are not in your domain/no trust relationship b/w network.

That are the reason to popup this dialog box.

Seyad's picture

What error do you get when you try to authenticate?

Is it "Access is Denied" or "No network provider accepted given network path" or something else?

k-h's picture

>What error do you get when you try to authenticate?

Can't log in.  Even though I'm using a domain administrator account and one which I can see the c$ share.

I discovered an account which does work finally. A normal account in the Domain Administrators group.  I'm still not sure why one account seems to work and another doesn't.