Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We're working on a deployment system that uses iPXE to boot a LiteTouch PE image created by Microsoft Deployment Toolkit (MDT) 2010, which then deploys Windows XP or Windows 7 to the clients. No problems with Windows 7, but XP is causing us headaches.

Due to decisions beyond my control, our network enforces NTLMv2 at a minimum for connections from machines not joined to the domain (which would use Kerberos, I believe).

This shouldn't be a problem, except that the Windows XP image that we have to deploy is a Dell OEM version, because we don't want to have to enter serial numbers into the installer (and 99.5% of all PCs on campus are Dell machines with legal XP Pro OEM licenses). The Dell XP Pro SP3 OEM disks don't seem to work on a lot of our machines, dying out with strange driver issues during the text-mode portion of the install, which we haven't been able to troubleshoot.

Instead, we've had some luck with the Dell XP Pro SP2 OEM disks, which we can slipstream to SP3 and integrate hotfix packs with (the xable one from works well). So, we end up with an XP image that's mostly SP3, plus all the important updates as of April. Should be good enough, right?

Now, what happens is that Windows XP gets installed to the point where it first boots, which is good, but then MDT is supposed to begin its Task Sequences. These are run by the client connecting to the MDT server's deployment share to download the order of the task sequence.

Unfortunately, NTLMv2 is turned off on these client installs, probably due to them being from an SP2 -> SP3 source (as SP3 has this on by default otherwise), so connections to the share are denied, and the MDT task sequence stops, waiting for the problem to be fixed so it can resume. A simple registry change ("lmcompatibilitylevel") fixes the problem nearly instantly with no reboot required.

So, all we need to do is to get this registry change implemented before MDT runs its task sequences, and we're golden. That means that we can't actually use an MDT task sequence step to do this, because of the catch-22 with that approach.

So far, we've tried using nLite to put a "registry_addreg" tweak in, but I think that MDT overrides anything nLite wishes to execute post-install, and that these steps aren't running at all. I need to investigate that more, to ensure that our nLite XP image installs and runs the tweak in a non-MDT situation, but we did that by the book so I believe it should work.

We've also tried adjusting the GPOs that apply to the MDT server itself to drop its requirements down to NTLMv1, but it doesn't seem to help at all, and the same client change up to NTLMv2 still fixes the problem. It's possible I haven't gotten all of the policy settings for this change - we're changing the server's policy to:

"Network Security: LAN Manager authentication level":"Send LM and NTLM - use NTLMv2 session security if negotiated".

If there's another setting or two that needs to be changed to make the server more lenient, lay it on me. Clearly this one ain't enough.

Otherwise, perhaps there's a way to take a vanilla XP Pro SP3 CD and convert it to be effectively the same as the Dell OEM one in regards to serial-free installation? I don't have the key(s) that Dell uses, though of course there are plenty on the sides of machines we could use.

I'm willing to try just about anything at this point, so, lay your weird ideas on me and I'll give them a shot.

share|improve this question

Just to sidestep the whole issue, I would just use a vanilla XP Pro SP3 image, as SP3 does not require a serial on installation, just like Vista onwards. You do not need to use the Dell image for the serial-less installation.

share|improve this answer
Are you sure? That's news to me. Will it still want the serial number later, upon activation? That would suck as it would then not be an unattended installation the way we'd like (i.e. PXE boot -> installed machine with applications with minimal hands on if any). – Mike Sol May 12 '11 at 16:48
@Mike: You can also activate XP SP3 without a serial number. The behaviour is the same as Vista onwards (you may want to double check on this though). – paradroid May 12 '11 at 16:52

You can use use mdt. You just need to mount the hive and make the edit via script, after the install operating system step, but before the reboot.

Just use a vbscript to mount the system hive from c: and make your edit, but don't forget to unmount the hive.

share|improve this answer
Whats mdt? And do you have a sample script? – Simon Sheehan Nov 30 '11 at 20:29
@SimonSheehan: That is a question best left for chat, not comments. – surfasb Nov 30 '11 at 20:35
@surfasb no - I'm asking for clarification on what hes talking about. – Simon Sheehan Nov 30 '11 at 20:47
Ahh, I didn't read his answer. I believe his first sentence should of read "You can still use MDT." – surfasb Nov 30 '11 at 22:01

Rather than messing with w/ WinXP SP2, Build your WinXP Ref. Image in a VM, that should get you passed these driver problems.

It really does sound like you're stuck between a rock and a hard place, I would highly recomend not using XP anymore. I never had much luck with it and MDT, MDT and Win7 play quite well together.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .