When connecting to Biztalk Server 2010 via WMI.NET, I am able to successfully peruse any number of class types, but none of the Biztalk classes. Each of those throw the following exception verbiage:
BizTalk Server cannot access SQL server. This could be due to one of the following reasons:
1. Access permissions have been denied to the current user. Either log on as a user that has been granted permissions to SQL and try again, or grant the current user permission to access SQL Server.
2. The SQL Server does not exist or an invalid database name has been specified. Check the name entered for the SQL Server and database to make sure they are correct as provided during SQL Server installation.
3. The SQL Server exists, but is not currently running. Use the Windows Service Control Manager or SQL Enterprise Manager to start SQL Server, and try again.
4. A SQL database file with the same name as the specified database already exists in the Microsoft SQL Server data folder.
Internal error from OLEDB provider: "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'."
The test code (without security info):
ConnectionOptions options;
options = new ConnectionOptions();
options.Username = @"myusername";
options.Password = @"mypassword";
options.Authority = @"ntlmdomain:mydomain";
ManagementScope scope;
scope = new ManagementScope(@"\\BIZSERVERNAME\root\MicrosoftBizTalkServer", options);
scope.Connect();
ObjectQuery query = new ObjectQuery("SELECT * FROM MSBTS_Setting");
ManagementObjectSearcher searcher = new ManagementObjectSearcher(scope,query);
var i = 0;
foreach (ManagementObject key in searcher.Get())
{
listBox1.Items.Add(key.ToString());
i++;
if (i > 100) break;
}
Change MSBTS_Setting to any Biztalk class and get the same exception. Change it to a non-biztalk class and it walks it just fine. Ex: CIM_Setting.
I think this might be because the account you are using to access the WMI objects is not a member of the "SSO Administrators" group.
I had a very similar problem (BizTalk WMI access issues) and came across this post. Adding the account to the "SSO Administrators" group worked for me.
You're running into what's called a "Double Hop" issue. (this is actually not a WMI/BT specific issue, it's also a common issue with IIS and Sql Server using windows authentication)
When using 'BizTalk-WMI' basicly this is happening (assuming Client, BT-Server and BT-Management-DB are in the same domain but on different machines):
Client credentials are sent to the BT-server/WMI provider. The BT-Server in its turn should transmit the credentials to the Sql-Server, but this isn't allowed (by default) by kerberos.
Also see this technet articles:
Basicly you have 3 options for using 'BT-WMI':