Wednesday, 9 December 2009

Fun with msdeploy, Extended Protection and Windows Authentication

Trying to push a change to our live servers today, we got this wonderful message from msdeploy:

Error: (09/12/2009 16:10:21) An error occurred when the request was processed on the remote computer.

Error: Child object 'extendedProtection' cannot be added to object 'windowsAuthentication'. The 'windowsAuthentication' provider may not support this deployment.

Error count: 1.

We do this several times a day… it worked yesterday, nobody changed anything, and suddenly today it doesn’t work. (Don’t you just love it when that happens?)

Now, msdeploy is wonderful, but has practically no documentation – which means when an error like this happens, you’re on your own.

A bit of Googling and a couple of lucky guesses later, and we worked out what was causing it. “Extended Protection” is apparently some of new fangled security framework that’s included in recent Windows Updates. Our internal servers install Windows updates automatically; our live servers don’t.

In other words – our staging server had quietly upgraded itself in the night to support extended authentication, and was now trying to push that configuration to the live server, which had absolutely no idea what was going on.

Logging on to the live server and installing the outstanding Windows security updates seems to have fixed it.


Edward Manning said...

Dylan - Having a bunch of spammy comments on your blog doesn't do your credibility any favours.


My question is: Why do your internal servers work differently from your live servers? You're just asking for trouble. Presumably you're internal servers are configured to download and install automatically. So how could you ever validate that what you test will ever work in prod?

You got burnt this time, but it's only luck you don't get burned more often...

Dylan Beattie said...

Edward - thanks for the feedback, and you're absolutely right. Internal servers are no longer running automatic Windows Updates - we now update them manually as part of the roll-out process, giving us the chance to test our own code against Windows updates first, before deploying code and updates to the live servers.