Sign up for Office 365
Learn more about Office 365
Brand new installation of AD FS 2.0 on Windows Server 2008. Installation completed successfully, all services are running, but I keep receiving the following error every minute on the ADFS server:
Log Name: Application Source: MSSQL$MICROSOFT##SSEE Date: 8/5/2012 7:21:51 PM Event ID: 28005 Task Category: (2) Level: Error Keywords: Classic User: N/A Computer: server.domain.local Description: An exception occurred while enqueueing a message in the target queue. Error: 15404, State: 19. Could not obtain information about Windows NT group/user 'domain\ADFS2SVC', error code 0x5.
While trying to set up a trust using the Microsoft Online Services Module, I keep getting invalid username/password when entering the command Set-MsolAdfscontext -Computer <AD FS 2.0 primary server> (where the primary server is the internal FQDN of my ADFS server). I have a feeling this database error is why my credentials fail to validate.
Set-MsolAdfscontext -Computer <AD FS 2.0 primary server>
I saw one other post in the forum on this topic, but it was no help. Any suggestions would be appreciated.
So, checking around the Windows Logs some more, saw this in the Security log:
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 8/6/2012 10:20:19 AM
Event ID: 4625
Task Category: Logon
Level: Information
Keywords: Audit Failure
User: N/A
Computer: computerName.domainName.local
Description:
An account failed to log on.
Subject:
Security ID: NETWORK SERVICE
Account Name: COMPUTER$
Account Domain: domainName
Logon ID: 0x3e4
Logon Type: 3
Account For Which Logon Failed:
Security ID: NULL SID
Account Name:
Account Domain:
Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xc000006d
Sub Status: 0xc0000064
Process Information:
Caller Process ID: 0x640
Caller Process Name: C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\Binn\sqlservr.exe
Network Information:
Workstation Name: COMPUTER
Source Network Address: -
Source Port: -
Detailed Authentication Information:
Logon Process: Authz
Authentication Package: Kerberos
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
Checked the list of services on the machine that were using the "Network Service" account to log in, and "Windows Internal Database (MICROSOFT##SSEE)" was one of them. Changed the account for this service from Network Service to my ADFS service account and restarted the service. Also went into the local security groups on the machine and checked the "SQLServer2005MSSQLUser$COMPUTER$MICROSOFT##SSEE" group. This group only had the "Network Service" account listed, so I added my ADFS service account. Restarted ADFS service (and WID service again for good measure) and error messages are gone. Hope this helps anyone else having the same issue.
Hi Shaunm001,
According to the error message you provided, you most likely have connectivity issues to your Active Directory server - and the identity of the owner of your databases (dbo) is on that Active directory server. The SQL Service Broker is causing this exception. If this is not a resolvable issue condition, then you can change the owner to a SQL login (e.g. sa) and this will resolve the exception.
You can do this with the following command on each database that has the wrong owner: sp_changedbowner 'sa'
Thanks, Kent Gu
Please check following links:
I hope these links will help.
Cheers,
Te-Amo
What kind of connectivity issues would I be having? ADFS server is on the same network as the domain controller (no firewalls or anything else that would be blocking communications). I tried running the command "runas /user:Contoso\serviceadfs cmd" on the ADFS server as suggested in another post here for testing connectivity to the DC, and the command works without any error.
And how do I connect to the WID to make the changes in ownership? I've installed SQL Server Mgmt Studio Express and try to connect to SERVER\MICROSOFT##SSEE using Windows Authentication, but it will not accept the domain admin credentials or the ADFS service account credentials.
Thanks man, I have got the same issue. and assigning the local service to Windows Internal DB seems to have done it.