I'm using SCE 2010, but this is an SCOM related issue. I have 20+ working agents. Now I tried to install it on an older laptop, but it stays in the pending install state. I'm getting 20002's on the server ("attempted to connect but could not be authenticated, and was rejected.") and 20070's on the client ("but the connection was closed immediately after authentication occurred."). I read the forums, found a lot of topics about these events, but none solved my problem. I found something strange. Every single time I get a 20002 on the server, there's also a logon (4624) and logoff (4634) event in the security log with a domain user account, call him DOMAIN\john.doe. On the client, there's a 4648: A logon was attempted using explicit credentials. Subject: Security ID: SYSTEM Account Name: LAPTOP$ Account Domain: DOMAIN Logon ID: 0x3e7 Logon GUID: {00000000-0000-0000-0000-000000000000} Account Whose Credentials Were Used: Account Name: john.doe Account Domain: DOMAIN.COM Logon GUID: {00000000-0000-0000-0000-000000000000} Target Server: Target Server Name: MGMT.DOMAIN.COM Additional Information: MSOMHSvc/MGMT.DOMAIN.COM Process Information: Process ID: 0x5d0 Process Name: C:\Program Files\System Center Operations Manager 2007\HealthService.exe So, apparently, instead of LAPTOP$, the agent is connecting as a user account. Ok, this must be the problem then. But how is that possible? I NEVER configured either the server or the client to use that account. This isn't my account, I don't even know the password for it. This user has been abroad for the last 3 weeks, and I installed SCE 2 weeks ago. So there's absolutely no way that this user typed his password anywhere near the SCE server or the SCOM agent. I set the cached domain logon count to 0 on the client, there are NO cached logons whatsoever. On the client, if I impersonate the system account, and execute klist, I find two ticket2: client is john.doe@domain.com in both of them, one server is krbtgt/domain.com@domain.com and the other is msomhsvc/mgmt.domain.com@domain.com. Even after klist purge and rebooting, the tickets reappear. I even tried explicitly installing the agent to run as the action account and it didn't help. The health service is installed as local system, there isn't even a way to change that. So, apparently, the password of this user is stored somewhere on this laptop, and healthservice is using it. How? Why? How do I tell healthservice to logon as laptop$?

Agents log in with the run-as account that they are configured with. You seem to be having two issues. First your agent is not authenticated to the MG - which is a setting in the MG, you probably have it set to auto reject. Second, whomever installed the agent gave it a run-as account that it no longer has credentials to activate. You can try uninstalling the agent and pushing it again, or going into service control manager on that out of office users computer and change the run-as account setting.Microsoft Corporation

SCE is NOT set to auto-reject. No problem there. I installed the agent manually about 5 times. I also pushed the agent by SCE about 5 times. After each try, I uninstalled, sometimes even did a system restore. All along john.doe was nowhere near the company. The service is set to run as local system. If I change it to anything else, it won't run. The run as account is the domain administrator account. It is what's configured in SCE, and all other agents. After I wrote my post, I deleted john.doe's files from the system, some LSA secrets associated with his SID in the registry, and still, health service is asking for and receiving kerberos tickets for john.doe and using that to communicate with the management group server. I wonder how a local system account can get a kerberos ticket for a user if it doesn't know his password?

Hi, In Ops Mgr resouce kit there is a cleanup tool that will remove all kind of settings that the agent writes. That could help.Anders Bengtsson | Microsoft PFE | blog at http://www.contoso.se