This is a known problem right now. To get past this you need to change the process used a little bit. The documentation for Windows 7 deployment (as of today, 3-17-2010) says to run sysprep with the options of -audit and -specialize. As you've shown in your snippet of the xml document we then run sysprep again to get from the audit pass to the oobe pass. This removes us from the domain.
Here is the working solution:
Run sysprep on your base machine using -audit, but NOT -specialize. Then manually edit the xml file and add the /specialize parameter to the line that you already have displayed in this string. The audit section will pass and inject drivers (if HII is being used) and then sysprep will move from the audit pass to the specialize/oobe passes. At this point the domain join action will happen, and since there is no additional sysprep activity it will remain joined.
A patch is being developed and our documentation is being updated to make this behavior the regular behavior without any need for advanced editing of the unattend.xml file. You will need to recapture your base image after running sysprep with no specialize option.
Thank you very much Mach
I spent a few hours unsuccessfully solve this problem. Nowhere any mention about this problem, I thought that I am doing something wrong.
Your reply helped very , only one word you confused I think, instead "specialize" you thought "generalize". Sysprep command works with /audit /generalize parameters.
I carefully have read sysprep documentation and there is one important thing that /generalize options ensure that at first windows startup is executing specialize configuration pass.If image is syspreped without generalize specialize pass will skip in this moment. This means that captured image which was syspreped with "generalize" options first will join PC domain. You are rigt there was problem.
Therefore now until some patch will be released base image is needed syspreped without "generalize" options a then add to *.xml file "generalize" options in line :
<Path>c:\windows\System32\sysprep\sysprep.exe /oobe /generalize /reboot </Path>
Thank you again
You are right. I mistyped. It should say that our instructions our to run sysprep /audit /generalize, but in reality we don't want /generalize at that point, we want it in the unattend.xml file. Thanks for catching that.
I'm glad to hear it seems to have worked. Also, there is a patch that has been developed and is going through internal testing. So far it seems to resolve the problem, and since the nature of the patch is to simply change one line in the unattend file I expect it to be released very soon. Our documentation will also be updated to reflect the correct sysprep options to successfully deploy a machine.
...one more notice yet.
If PC is joined to domain in specialize pass next autologon does not work until to xml file in section autologon is not inserted line :
because default it try logon with account mydomain\Administrator and it is wrong
Default created xml file by OSD procedure miss out this parameter
Thanks for the update on that. I will pass that information on to our developers. I have been working closely with them to get this process smoothed out, but that is one I hadn't noticed.
I have a possible issue with this process. I've had a working Windows 7 HII Provisioning process pretty much done and dusted. The only thing it wasn't able to do was join the domain during sysprep (I had it as a seperate Provisioning action). So I re-visited the process to try and correct this using the method described here.
I understand that by removing the generalize switch during the image prep stage you prevent the specialize phase from running (where the domain is joined) before sysprep is then run again to put the machine into OOBE. This therefore prevents the situation whereby the domain is joined in the specialize phase before being removed again in the audit phase.
My issue is that by removing the generalize switch from the initial running of sysprep, you're removing the very thing that makes an image suitable for installing on different hardware. It prevents me from being able to push that image to any other model of hardware except the one that was used to create the image. This is presumably because its trying to load the wrong drivers for hardware that has now changed unexpectedly - something that the generalize switch would solve. So how can you follow this process while at the same time making the image hardware independent?
Hope this makes sense - I've looked at this from several angles but can't quite get round the fact that what you are, in effect, doing here is pushing an OS that can only work on one type of hardware.
Have you tried the process or are you just going based on conjecture? It does work with HII, in fact it's the only way for the LANDesk generated scripts, etc. to work at this point in time (9.0 SP1). What happens when you try it?
Keep in mind that the patches listed here (or SP1) definitely need to be applied to the core and all remote consoles:
I have tried it and I get BSOD's on anything other that the original model. It just tries to boot straight into audit mode and doesn't get there. I must admit I have not applied SP1, nor the latest patch (I have the older patch from earlier in the year though). Correct me if I'm wrong but I thought the later patch thats included in SP1 only changes the way the unattend.xml file is written - something that shouldn't affect me since I've created my own unattend file from scratch - I just added the generalize switch during the sysprep run in audit mode and added the PNPSysprep component to the generalize phase to duplicate changes that the patch makes. Are there any other changes that I should know about introduced by this patch?
Another thing I forgot to mention - if I boot my reference PC into audit mode, reboot to WinPE, capture it and then deploy to another model but don't use a sysprep file at all - it still BSOD's. This is why I started questioning the fundamentals of what I'm doing - if my base image can't even boot to the point where the unattend file comes into play, it doesn't matter whats in said answer file - the problem is with the base image. Yet following the BKM on Windows 7 thats what I'm left with...