Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a development server with 3 instances: Default, A and B. It is a physical server, non clustered. Whenever the syspolicy_purge_history job runs at 2 am, I get failed login alerts. Looking at the job steps, all are successfully completed. It appears that some point during the step "Erase Phantom System Health Records" is when the failed logins occur.

syspolicy_purge_history on instance B works OK.

syspolicy_purge_history on the Default instance seems to want to connect to instance B, resulting in:

Error: 18456, Severity: 14, State: 11. Login failed for user 
'Machinename\sqlsvc-B'. Reason: Token-based server access validation 
failed with an infrastructure error. Check for previous errors. 
[CLIENT: <local machine>] . 

No errors are reported by Powershell.

syspolicy_purge_history on the A instance seems to want to connect to the Default instance resulting in

Error: 18456, Severity: 14, State: 11. Login failed for user 
'Machinename\sqlsvc-Default'. Reason: Token-based server access 
validation failed with an infrastructure error. Check for previous 
errors. [CLIENT: <local machine>] . 

Then it tries to connect to the B instance, resulting in

Error: 18456, Severity: 14, State: 11. Login failed for user 
'Machinename\sqlsvc-B'. Reason: Token-based server access validation 
failed with an infrastructure error. Check for previous errors. 
[CLIENT: <local machine>] . 

No errors are reported by Powershell.

I tried the steps posted here hoping they would fix it. http://support.microsoft.com/kb/955726 But again, this is not a virtual server nor is it in a cluster. Do you have any suggestions? Thanks.

share|improve this question
    
Looks like an OS issue related to the UAC. What OS? –  Nick Kavadias Dec 11 '10 at 10:33

3 Answers 3

I ran into this issue a few weeks ago.

What was the result after performing Method 2 (Re-create the syspolicy_purge_history job)?

With respect to your comment "syspolicy_purge_history on the Default instance seems to want to connect to instance B", did you modify step 3 (Erase Phantom System Health Records) so that it is connecting to the DEFAULT instance and not the B instance?

share|improve this answer

This is on Windows Server 2008. After doing Method 2, it was the same errors. Step 3 is showing to connect to the respective instnace.

Default Instance

SQLSERVER:\SQLPolicy\TEST\DEFAULT).EraseSystemHealthPhantomRecords()

Instance A

SQLSERVER:\SQLPolicy\TEST\A).EraseSystemHealthPhantomRecords()

Instance B

SQLSERVER:\SQLPolicy\TEST\B).EraseSystemHealthPhantomRecords()
share|improve this answer

I have two 2005 instances and two 2008R2 instances on one server. They have all been using NETWORK SERVICE for all services. I changed the SQL Server Agent service on one of the 2008R2 instances to use a new domain account set up specifically for that purpose. Since then, at around 2:00 AM every night, I get logon failures on the other three instances for that new service account. I have never done anything with Policy Based Management.

The workaround I found here seems to be to add a logon for that new domain account to the other three instances. The true fix would seem to be for Microsoft to add an option to the proc that is being called by the syspolicy_purge_history job to limit its scope to the current instance only, make that the default, and document all this somewhere other than Connect.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.