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 http://xable.net/xp-sp3-update-pack-download.html 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.
Best Answer
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.