SQL Server will [...]]]> I recently had a SQL server where the SQL instance had a different name than the hostname. Not having rights to connect to SQL, I wasn’t aware of that. So, I registered the SPNs as they should have been registered, and it was still falling back to NTLM (see: failing).

SQL Server will register its own SPNs at startup – assuming the service account has rights to set its own SPN. To give the service account rights to self-register SPN (assuming you’re using a domain service account and not Network Service/Local System), you need to grant the service account rights to “Write Public Information” on itself in Active Directory.

1) Launch Active Directory Users and Computers
2) Find your service account and hit the Security tab
3) Select “SELF” in the “Groups or user names” listbox
4) Find “Write public information” in the “Permissions for SELF” listbox and check “Allow”
5) Click OK

After, you’ll need to restart SQL Server for the SPN to register. Use setspn -l domain\account to verify that the account has properly registered.

If you do happen to be using Network Service or Local System, shame on you. That said you’ll just need to verify on the computer account in AD that SELF has “Validated write to service principal name” set to Allow. But, seriously, stop using Network Service or Local System (ESPECIALLY THAT!) and start using a domain account…or at the very least a local account.

There were two hops here. From the user -> IIS server and from IIS Server -> SQL Server, but the application in IIS would [...]]]> Recently, some of our developers were writing an app that required impersonation from the web service, as the user, to the database. Admittedly, Kerberos isn’t one of my strong points.

There were two hops here. From the user -> IIS server and from IIS Server -> SQL Server, but the application in IIS would impersonate the user when authenticating with the SQL server.

So, the idea here is that from the user to the IIS server, we know Kerberos will work. The user passes its ticket to the web service. Nothing unusual. From there, the web app, running as a custom app pool ID, needs to pretend (delegate) to be the user when it authenticates to the SQL server.

There are a few requirements.
1) Your application in IIS should be running under a custom identity – domain\MyAppService
2) SQL Server needs to be running under a domain service account – domain\MySQLService
3) IIS needs to use Negotiate instead of NTLM for that application. It should do this by default, then fall back to NTLM. For whatever reason, my app was using NTLM. IIS should also have Windows Authentication enabled.
4) Change your connection string to impersonate the site user

Step 1 – Set the SPN on your app pool ID for the site, for the hostname and FQDN.
setspn -a http/mysite domain\MyAppService
setspn -a http/mysite.domain.com domain\MyAppService

Step 2 – Set the SPN for the SQL service on your SQL service account – assuming you use the default SQL port
setspn -a MSSQLSvc/hostname domain\MySQLService
setspn -a MSSQLSvc/hostname.domain.com domain/MySQLService
setspn -a MSSQLSvc/hostname:1433 domain\MySQLService
setspn -a MSSQLSvc/hostname.domain.com:1433 domain/MySQLService
Restart SQL

Step 3 – In Active Directory Users and Computers, find the service account, click the delegation tab, and trust it for delegation. You can set it for delegation to anywhere, or constrained delegation to the SPNs you’ll set for the SQL service account.

Step 4 – Force your site or application to use Negotiate. This won’t work with NTLM, so we’ll remove it. (Note: This is for IIS7/7.5)
- Find and open your applicationHost.config. It’s probably under c:\windows\system32\inetsrv\config. You can also set this in the system.webServer section of the web.config for the application.

- Scroll to the bottom and above /configuration copy this in:

   <location path="SitePath">
        <system.webServer>
            <security>
                <authentication>
                    <windowsAuthentication>
                        <providers>
                            <add value="Negotiate" />
                            <remove value="NTLM" />
                        </providers>
                    </windowsAuthentication>
                </authentication>
            </security>
        </system.webServer>
    </location>

If you get a 500 error after adding the above XML, it’s probably because Negotiate is already added elsewhere. Just remove the line that says add value=”Negotiate” and leave the remove NTLM line.

Reference: This post was extremely helpful in solving my problem – http://blogs.technet.com/askds/archive/2008/06/13/understanding-kerberos-double-hop.aspx – in the end, I did pretty much everything in that post, and still had the IIS server passing anonymous to SQL, which is what tipped me off that it was using NTLM and not Negotiate.

Well, finally a post after the chaos that was the holidays. I was on vacation for 12 days and accomplished…nothing. Except for a lot of Counterstrike. And Team Fortress 2.

If you’re running SCOM 2007 and BizTalk 2006 (and have the SQL agent jobs properly configured) you may notice a warning [...]]]>

Well, finally a post after the chaos that was the holidays. I was on vacation for 12 days and accomplished…nothing. Except for a lot of Counterstrike. And Team Fortress 2.

If you’re running SCOM 2007 and BizTalk 2006 (and have the SQL agent jobs properly configured) you may notice a warning in SCOM that says there are long running jobs. Upon inspection, you’ll discover that a single job (ManageRefCountLog) has been running since the SQL Agent last started (or the minute immediately following). I ignored this for quite some time, leaving the alert ACK’d the whole time because I couldn’t figure out why the job was running forever…that, and everything was working fine. I finally got fed up with it today and did a little digging. The error looks like this:

There are long running jobs on SQL instance MSSQLSERVER on computer SERVER.FOO.BAR.COM. This may indicate an issue with one or more jobs.

The ManageRefCountLog job has only one step that runs a stored proc on BizTalkMsgBoxDB called bts_ManageMessageRefCountLog. If you look at the store procedure itself, you’ll see:


WHILE (1 = 1)
BEGIN


So, the job is supposed to run forever…or until 1 != 1. Whichever comes first.I never would have noticed this job running forever, if not for SCOM2007 + the SQL 2005 management pack. Now I just need to add an exception. I’ll do that tomorrow…

In the event of a disaster, we could just fail over to the [...]]]> So, for whatever reason you need to move your BizTalk databases from one SQL server to another. In my case, I was moving from a hostname to a CNAME, for DR purposes (failover server is in another DC, and not clustered).

In the event of a disaster, we could just fail over to the other database server, change the CNAME to point to the “failover” server, and we should be back up and running. The problem, I found, was changing from DC1BTSQL1 to the CNAME (we’ll call it BTSQL1). After searching for a while (maybe I’m an idiot, but all of these things were classified as “backup and restore methods” not “I’m changing server name” methods or anything like that) I found two scripts and an xml file.

Under %systemdrive%\Program Files\Microsoft Biztalk Server 2006\Schema\Restore are two VBS scripts. UpdateDatabase.vbs and UpdateRegistry.vbs. There’s also an XML file called “SampleUpdateInfo.xml.” Below is the procedure for changing the SQL server name. You can even change the names of the DBs. This procudure assumes you’ve backed up and restored, or attached, the DBs to the “new” server already.

1) Stop BizTalk Service on BizTalk Server
2) Stop Enterprise SSO Service on BizTalk Server
3) Edit C:\Program Files\Microsoft BizTalk Server 2006\Schema\Restore\SampleUpdateInfo.xml
     a. Do a “Replace All” and change SourceServer to DC1BTSQL1
     b. Do a “Replace All” and change DestinationServer to BTSQL1
     c. Uncomment the ruleenginedb node
     d. Uncomment the HWS Administration DB node
     e. Save it.
4) Drop to a command prompt and go to C:\Program Files\Microsoft BizTalk Server 2006\Schema\Restore
     a. Run cscript UpdateDatabase.vbs SampleUpdateInfo.xml
     b. Run cscript UpdateRegistry.vbs SampleUpdateInfo.xml
5) Restart Enterprise SSO Service
6) Restart BizTalk Service
7) Check BizTalk Configuration to verify that the database server is set to BTSQL1 for all configured options.
8 ) Rejoice.