Happy New Year!

Last post for this FY, so I’m going to make it as content-free as I possibly can, for your visual digestive pleasure.

For those of you in business, may your profits be obscene.

For individuals, may your tax rebate be bountiful.

For small furry creatures from Alpha Centauri – yes, you know who you are – may your gronglefoz be fruupish and mjeard.

See y’all next year…

KDC_ERR_BADOPTION when attempting constrained delegation

Hit this earlier while working with someone else on a Kerberos delegation problem.

All the SPNs looked right and were registered against the right accounts; all the App Pools were Network Service; from what I’d been told, everything should have been working… but wasn’t. More troublingly, it had been working at one point. But why!?

We checked that Kerb was working from the client to the first tier, then grabbed a network capture from the web server while trying to reproduce the problem.

The trace showed us a KDC_ERR_BADOPTION in response to a TGS request for http/targetserver.example.com , but looking it up didn’t yield any likely results (until after we knew where to look).

In short – if everything else is right, chances are this error means that the middle tier (or however far you’ve got – whatever machine is acting as the KDC client at this point) isn’t able to delegate.

We checked delegation options for the middle tier account, quickly popped them into “Trusted for delegation”, and whop, it was working. Now we have a working baseline, confidence is restored, and they’re going to implement constrained delegation later. The reason it worked once before: ticking “trusted for delegation” was one of a batch of changes implemented and rolled back during troubleshooting.

I updated my wiki with a useful* batch file that searches msds-allowedtodelegateto attributes as well as serviceprincipalname attributes.

It’s documented in Technet already, but the search excerpt I got put me off initially:


The SPN to which the client is attempting to delegate credentials is not in its Allowed-to-delegate-to list.


1.Use Network Monitor to determine the SPN to which the client is attempting to delegate credentials. You will need this information in a later step.

2.Click Start, click Run, and then open Active Directory Users and Computers by typing the following:


3.Right-click the user or service account that has problems authenticating, and then click Properties.

4.Click the Delegation tab.

5.The Allowed-to-delegate-to list is the list of servers shown under the heading, Services to which this account can present delegated credentials.

6.Add the SPN the client is attempting to delegate to (information from the captured data you obtained in Step 1) to the Allowed-to-delegate-to list for that client. This will tell the KDC that this client is indeed allowed to authenticate to this service. The KDC will then grant the client the appropriate ticket.

For information about setting up service accounts for delegation, see “HOW TO: Configure Computer Accounts and User Accounts So That They Are Trusted for Delegation in Windows Server 2003 Enterprise Edition” in the Microsoft Knowledge Base at http://go.microsoft.com/fwlink/?LinkId=23067.


• The server does not support constrained delegation or protocol transition. (Windows 2000 does not support constrained delegation or protocol transition.)

Two New Updates for Aussie Windows Vista Media Centre Owners

The Media Center dev team have been working to address a couple of problems that have particularly affected some Australian Media Centre users, and we now have updates available from Product Support.

While the fixes are available, the KB articles documenting them aren’t yet published (at the time of writing), but we’re working on getting them out as soon as we can.

In Australia, you can call Support on 13 20 58 (1,4) or use a pre-existing support arrangement (Partner, Premier, etc) to obtain either hotfix directly from Microsoft PSS.

If there’s a problem getting them sent to you, you may need to explain that the articles are still in production, but the fixes are ready and available from the hotfix site.

As with all hotfixes, our recommendation is that if you aren’t affected by the problem directly, you should wait for a future public update or service pack containing the updates.

Media Center is available in the Windows Vista Home Premium and Ultimate editions.

First, there’s an update that provides a more reliable way of keeping custom Guide data in the registry, without having to adjust windows services (for example, KeepKey), registry scripts, scheduled tasks or registry permissions.

935685 – MCUpdate Crash when disableUpdateDiscSvc is enabled * – KB article being finalized. When published: http://support.microsoft.com/kb/935685

In short: the update allows Guide providers to set the disableUpdateDiscSvc registry value to 1 without crashing the MCUpdate process when it runs, to retain their custom guide data registry key.

I would expect that you’ll likely be directed to install the hotfix by your EPG provider, and they will set the registry key with their installation/uninstallation, but check with them!

In case technical details are wanted:

Registry location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Media Center\Service\EPG
Value: disableUpdateDiscSvc : DWORD : 1

Removing the value or setting to zero should return to normal behaviour (the discsvc key will be overwritten when MCUpdate runs, returning the guide to its default setting).

This next problem seemed to crop up fairly recently on my installation: when channels retitled themselves (as often happened with Channel 7 during a special event or similar), MCE (or rather VMC as folk are calling it now) would sometimes assume it had found a new replacement channel, and forget about the old channel on the same frequency. This led to a loss of Guide data on an occasional basis (and scheduled recordings would often not work on the new channel), It affects Terrestrial Digital TV stations only, far as I know.

938927 – Opportunistic Scanning causes loss of EPG/Guide data * – KB article being written. When published: http://support.microsoft.com/kb/938927

Once the hotfix is installed, opportunistic scanning can be disabled by setting a specific registry value:

Registry location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\ CurrentVersion\Media Center\Service\GLID
Value: DisableActualStreamOpportunisticScanning : DWORD : 1

This one you’ll need to install and enable yourself (unless the guide provider does the registry key for you – they’re generally very nice people, so expect to see a tickbox in their programs in the future).

We’ve had good results in testing, but you might want to consider rerunning Media Center setup after installing the hotfix to rescan all your channels from scratch – if the channels are already weird when you install and enable, they might stay that way.

Again – neither KB is done yet, but we’re working hard on them. In the meantime, contact Support to get the updates directly from us.

See also Mike Hayton’s post in the XPMediaCentre.com.au forums.

This post is provided “AS IS” and confers no warranty.

Can I use SQL Server 2005 as the Biztalk Server 2004 database?

No – SQL 2005 and Biztalk 2004 aren’t currently supported together, except with an “arm’s length” SQL data adapter.

The primary BTS2004 database still has to be SQL 2000.


915919    Microsoft SQL Server 2005 is not currently supported for Microsoft BizTalk Server 2004 databases

926628    Summary of operating systems and SQL Server versions supported by different versions of BizTalk Server