Unable to deploy from SEPM 11.0.6100.645 to Win7 machines
I'm sure this is an issue with group policy in this environment; however I have been unable to track this down over the last week.
This is the first Symantec Endpoint Protection Manager installed in this environment. Domain & Forest functionality level is Windows Server 2003. So far, all of the desktops have been using SEP as an unmanaged client. There is a GPO that disables Windows Firewall, however most all of the desktops have a full installation of SEP (either 11.0.5 or 11.0.6) with firewall installed.
I've tried manually disabling SEP and that hasn't made any effect on the failure below. In fact on new systems with no antivirus installed, the same errors occur on those systems. The OS is always Windows 7 Enterprise 64-bit. Doesn't matter if I'm doing this on a VM or real hardware; the problem is always the same - which is leading me to believe it's a GPO somewhere. The SEPM server is joined to the same domain as the clients (i.e. single domain & forest).
NT AUTHORITY\NETWORK SERVICE has the following privileges in AD: Adjust memory quotas for a process, generate security audits, log on as a service, replace a process level token.
The process to reproduce the error: Go to Find Unmanaged Computers, and specify a valid computer & domain admin account, the target computer is properly found. I choose the 11.0.6100.645 package for Win64bit (target systems are all Windows 7 Enterprise 64-bit, all in the same Desktops OU in AD) & select features "Only Antivirus and Antispyware", then Start Installation.
The progress bar opens and takes a minute or two, then ultimately comes back with "Failed" deployment status. On every desktop I see no problems in the event log under applications or system; however under security I find two series of failure audits, both sets have the same sequence of errors:
Log Name: Security
Source: Microsoft Windows security
Event ID: 4776
Level: Information
User: N/A
OpCode: Info
Logged: 10/1/2010 11:09:59 AM
Task Category: Credential Validation
Keywords: Audit Failure
Computer: xxx.xxx.corp
General Tab
The computer attempted to validate the credentials for an account.
Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon Account: NT AUTHORITY\NETWORK SERVICE
Source Workstation: ACSEM01
Error Code: 0xc0000064
Log Name: Security
Source: Microsoft Windows security
Event ID: 4625
Level: Information
User: N/A
OpCode: Info
Logged: 10/1/2010 11:09:59 AM
Task Category: Logon
Keywords: Audit Failure
Computer: xxx.xxx.corp
General Tab
An account failed to log on.
Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0
Logon Type: 3
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: NT AUTHORITY\NETWORK SERVICE
Account Domain: ACSEM01
Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xc000006d
Sub Status: 0xc0000064
Process Information:
Caller Process ID: 0x0
Caller Process Name: -
Network Information:
Workstation Name: ACSEM01
Source Network Address: 10.18.10.248
Source Port: 49514
Detailed Authentication Information:
Logon Process: NtLmSsp
Authentication Package: NTLM
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
This event is generated when a logon request fails. It is generated on the computer where access was attempted.
The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).
The Process Information fields indicate which account and process on the system requested the logon.
The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.
The authentication information fields provide detailed information about this specific logon request.
- Transited services indicate which intermediate services have participated in this logon request.
- Package name indicates which sub-protocol was used among the NTLM protocols.
- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
ddddfal;sdkjf
Comments
Are you deploying using Find
Are you deploying using Find Unmanaged Computer or Migration and Deployment wizard ?
Try deploying using Deployment wiz.
On the Client make sure \\C$ is shared.
Check this
https://www-secure.symantec.com/connect/forums/configuring-and-deploying-client-software-windows-vista-and-windows-server-2008-have-addition#comment-2572181
VMWARE-- SEP 12.1 vs McAfee vs Trend Micro
I'm using Find Unmanaged
I'm using Find Unmanaged Computers to deploy. \\c$ is available on all computers - and I have setup everything in accordance to the document you linked to. I failed to mention that before.
I've been digging deeper into Active Directory (where I think the problem lies) and think it may have something to do with the SEPM server being Windows 2008 R2 and having enhanced security - same as Windows 7. Came across this article:
http://social.technet.microsoft.com/Forums/en-US/windowsserver2008r2general/thread/f79a7c6e-00d0-466f-9889-3e333aa29a41
...and I'm waiting for the DCs to all apply a change in LAN Mangager policy. It was set to LM only in this environment. The problems in the technet forum match the issue I'm experiencing exactly. Same server OS, same problem (different application), identical error in the Event Viewer.
Will know more probably Tuesday.
UAC
UAC enabled on your Windows 7 machines. As much as this is a great tool, it can get in the way of installations.
If you have a logged in user, trying to install software without rights to do so, it will be outright denied.
IF on the other hand, you have an administrator logged in, you will be prompted for confirmation, Unless, you right click and indicate "Run as Administrator".
The limitation you are receiving I believe is exactly there in.
Do you have a test machine? If so, turn off UAC and log in with a "regular domain account". One, one of your users would be logged in with. No admin or install priviledges and try deployment again.
This time, you should be able to install "successfully".
* * * * *
Now, your ADC is Windows 2003 Server. So you will not have the required GPO policies to do what you need to get done, via GPO in order to remove the "prompt for elevated privileges".
* * * * * * * *
What you can do, for these machines is modify the "Local security policies".
Change the elevation prompt behavior
To change the elevation prompt behavior for administrators
Click Start, click Accessories, click Run, type secpol.msc in the Open box, and then click OK.
From the Local Security Settings console tree, click Local Policies, and then Security Options.
Scroll down to and double-click User Account Control: Behavior of the elevation prompt for administrators.
From the drop-down menu, select one of the following settings:
Click OK.
Close the Local Security Settings window.
* * * * * * * * *
The above was extracted from the following Microsoft Article:
http://technet.microsoft.com/en-us/library/cc709691(WS.10).aspx#BKMK_S3
- Scenario 3 : Configure User Account Control
-- Part 4 : Change the elevation prompt behavior
And the instructions listed herein.
Hope that helps.
This is already active in our
This is already active in our environment. The settings in the domain for UAC-enabled systems, do not prompt users with UAC prompts, and admin users (which is effectively every domain user) are automatically elevated via GPO settings.
Have a look at this KB About
Have a look at this KB
About preparing computers for remote deployment
Do you missed something?
Please don't forget to mark your thread solved with whatever answer helped you : ) Thanks & Regards Aravind
This is also active in our
This is also active in our environment. GPOs set this for us. I have confirmed with rsop.msc as well as a visual check to ensure these settings are deployed & enforced.
This thread is included in the "King for a Week" contest
Hi all,
This thread is now included in the Security Solutions Contest. Simply solve this thread, or any thread included in the contest, and you could be crowned "King for a week" and win a weekly prize. Read more here: https://www-secure.symantec.com/connect/blogs/security-solutions-contest-be-king-week
Good luck!
Eric
Subscribe to the upcoming Security Newsletter - Log in, visit your profile, and click on "Newsletter Subscriptions!"
please try to create a
please try to create a package with a silent installation option
What I see is the client
What I see is the client creating the C:\TEMP\clt-inst folder, dropping the vpxinstall.exe app there, but the file never executes. Instead I get the aforementioned error at the top of this post where NETWORK SERVICE is denied access.
So the rundown:
1) Windows firewall is disabled via GPO
2) UAC is disabled via GPO
3) File & Print Sharing is enabled via GPO
4) Simple File Sharing is disabled
5) Symantec Endpoint Protection is *not* installed on the target
6) NTLMv2, NTLM & LM auth is enabled via GPO
However, I'm still getting the Access Denied messages above.
so did you create a silent
so did you create a silent installation?
Yes I have a silent package
Yes I have a silent package built - but that is 100% not the issue. The issue is with security authentication between the server (Windows 2008 R2 x64) and every client (mostly Windows 7 Enterprise x64).
To illustrate my point, I brought up a second server, this time Windows Server 2003 R2 SP2 x64. All of the exact same GPOs & configuration apply to that server. See above for what those are. I built the 2003 SEPM server identially to the 2008 SEPM server. This time, when I go to "Find Unmanaged Computers" it works perfectly. I am able to install and distribute the client to anyone.
I know this is a problem related to Active Directory and that's where I need additional expertise from this forum. Unfortunately this "resolution" doesn't fix the security issue described herein. My best guess at this point after hours of reserarch may be due to when installing SEPM on a 2008 R2 server, *if* the domain/forest functional level is < 2008 (the functional level here is 2003), then the server may not be able to authenticate against clients supported in higher functional levels (read: vista & 7). Unfortunately I don't have the time to test or prove that.
Again, any insight is helpful.
UPDATE: Have a second client who has the same setup; Server 2008 R2 x64 with SEPM 11.0.6 MP1 installed, Server 2008 R2 domain/forest functional level. Exact same error on all client systems in the event log. NT AUTHORITY\NETWORK SERVICE - Unknown user name or bad password. This is definitely Server 2008 R2 related as opposed to domain functional level as I hypothesized. The client attempted to work around it by adding "log on as a service" rights in default domain policy but it didn't help.
Add your user as a member of
Add your user as a member of local admin group of target client and try.If not helps run Symantec Endpoint Protection Support Tool in SEPM and in the target client and see any error is present.....For more information regarding this tool refer this KB
About the Symantec Endpoint Protection Support Tool
Please don't forget to mark your thread solved with whatever answer helped you : ) Thanks & Regards Aravind
1) Domain Administrators are
1) Domain Administrators are added to all local machines (via GPO)
About the troubleshooter....
So, I ran it on both the 2008R2 & 2003R2 boxes. The only thing that came up on 2008R2 was something about the DefaultAppPool Identity not set to NetworkService; it was set to ApplicationPoolIdentitiy. So I changed to NetworkService per its recommendation and rebooted. Upon the server coming back up the exact same error in the client logs still exists, and deployment via "Find Unmanaged Computers" fails. The 2003R2 box had no configuration issues and has been working properly out-of-the-gate.
Thanks for the suggestion there. However I believe at this juncture there is an inherent problem between SEPM 11.0.6100.645 and Windows Server 2008 R2 x64. Server 2003 R2 SP2 works just fine, no errors. And now that I have two different clients, both having idential issues trying to deploy SEPM on 2008R2 with very similar setups that Symantec has a problem they need to fix. I'd set it up in a test domain if I had the time to test (but that's where I believe Symantec should do some research).
This problem is only resolved as far as I'm concerned by virutue of using an older OS.
You also need to know that
You also need to know that the local admin account is not disabled, and the password is not blank.
Ensure remote registry is running too.
MCSA 2003. MCP.MCTS.MCITP. Symantec Certified Specialist.
1) Local Admin Accounts are
1) Local Admin Accounts are enabled on all machines (via GPO)
2) Local Admin Passwords are all set with a .vbs (via GPO)
3) Remote Registry service is enabled (via GPO)
Thanks for the suggestions, but all of that is already in our domain GPOs.
did you try running the SEP
did you try running the SEP support tool , any error message?
Cheers!
Pete
Help Link: http://www.symantec.com/business/support/overview.jsp?pid=54619
Hello
I just wanted to add my two cents and also say that I experience this issue too when attempting to deploy to Windows 7 64bit computers. I am a Domain Admin and have not had an issue deploying to Windows XP or Windows 7 32bit computer but for some reason my installations also fail when deploying Win7 64bit computers.
I am able to manually install the exported SEP package for 64bit which doesn't seem to have any issues... We don't run a lot of Win 7 64bit so it's not a major pain for us but is inconvenient none the less...
Thanks!
Ryan
Hi, I fear this issue is not
Hi, I fear this issue is not only present for 7 x64 clients, I'm presently facing the same issue trying to install a RU6 MP1 client on a WS 2008 SP2 32 bit server from a SEPM on a WS 2008 R2 server.
I get the same NT AUTHORITY\NETWORK SERVICE error as the original poster.
At SEPM RU6 there was no problems installing clients...
Older clients does not get installed either, I just tried to install a RU6 client, and got the same error.
/Michael
MCP/MCTS/MCSA - www.compugame.dk
An update to the above
An update to the above post:
Even though the install does not start, 2 files are however copied to c:\temp\clt-inst\ the 2 files are vpremote.dat and vpremote.exe
WORKAROUND: After trying to create an export of the client package and doing a push install through clientremote.exe everything went perfectly!
I'm not sure if this will work on win 7 x64 too, but on WS 2008 SP2 32 bit it certaintly did.
/Michael
MCP/MCTS/MCSA - www.compugame.dk
OK, I just deployed a RU6
OK, I just deployed a RU6 MP1 client to a WS 2008 R2 x64 bit via clientremote.exe and an exported client package.
I suspect it would also work flawlessly on a win 7 x64 bit client...
/Michael
MCP/MCTS/MCSA - www.compugame.dk
Check these permissions
Check these permissions once
Troubleshooting Symantec AntiVirus Corporate Edition and Symantec Endpoint Protection installations: Checking rights and permissions
Please don't forget to mark your thread solved with whatever answer helped you : ) Thanks & Regards Aravind
SOLUTION: I've just been able
SOLUTION:
I've just been able to deploy a RU6 MP1 client to a WS 2008 R2 x64 server.
By default the SEPM service is installed to logon with the LOCAL SYSTEM user.
I change this to our domain admin account and voila everything got deployed perfectly!!
I know this is far from best practice, but for now it's either that or use the old clientremote.exe tool to do remote deployment the Symantec way.
I hope this helps :)
/Michael
MCP/MCTS/MCSA - www.compugame.dk
Yes, I agree with you
Yes, I agree with you Michael, it does make sense.
/* Infrastructure Support Engineer */
I'm not sure as these are
I'm not sure as these are unmanaged clients, but you might be able to use the tool SylinkReplacer. You can export the communication file (sylink.xml) from the SEPM, and run the tool. SylinkReplacer allows you to add an IP address range, and it will automaticly replace the sylink.xml for all the clients that it finds in that IP address range.
To export the sylink.xml file:
SEPM>Right Click Group>Export Communication Settings
SylinkReplacer:
https://www-secure.symantec.com/connect/downloads/...
other thoughts
One or two thoughts.
1. I never recommend turning off UAC. Its too powerful a option for protecting the machine
2. Does it work if you deploy it via something like SCCM
3. what happens if you try and upgrade existing clients via a package in SEPM
I am getting ready to an upgrade to RU6 mp1
One other thing we have bought was a product called privilage guard so we can delegate out admin rights to only specific programs. They are not too expencive for what they buy youl.
Can confirm Michael Putz
Can confirm Michael Putz Hansen if SEPM runs under administrative account (domain admin) install is ok.
Our envoiment.
Server 1 Windows 200 Server SEPM - runs with local system account - install OK
Server 2 Windows 2008R2 64bit Server SEPM - runs with local system account - installation failed (same as above, Client gets only vpremote.exe and vpremote.dat)
Server 2 Windows 2008R2 64bit Server SEPM - runs with domain admin account - installation is OK
Client: Windws 2007 Enterprise
Server and Client in same domain.
try this.
Copy the setup files for SEP client from CD or the downloaded setup. SEPWIN64 for 64 bit. Install Liveupdate first and then try installing SEP unmanaged client. If this goes well, try the below solution.
Rename lusetup.exe to setup.exe and run the Migration and Deployment wizard to push the renamed setup.exe (lusetup.exe). then, push the SEP client package (if you don't have a package created, create one).
Cheers!!
---------------------------------
Vikas
--
Don't forget to mark your thread as 'solved' with the answer that best helped you!
Try running the SEPM under a
Try running the SEPM under a different account. In the past I've always created a special service account for each application and had it run with that account instead of with a default account like Network_Service.
As the default accounts are local accounts when you attempt to roll out a package, it cannot access the Win7/Server 08 systems because of the UAC. Run it under its own account that is a domain account and has local admin privs on each workstation. See what happens.
Would you like to reply?
Login or Register to post your comment.