patters

Hi all, Thought I'd share my build script for automating the creation and maintenance of PE 4.0 builds. It works using only the official Microsoft Windows ADK for Windows 8. It can use the x86 or AMD64 versions of ADK, and will build x86 or AMD64 versions of Windows PE 4.0, with drivers, additional components and scripts. It's a batch script that's easy to understand and edit, and it will create ISOs (with BIOS and EFI support), will automatically upload/freshen boot images on the WDS server(s), and will give you an onscreen prompt how to make a bootable USB key: http://pcloadletter.co.uk/2012/09/05/windows-pe-4-0-builder/ Enjoy, Patters

I forgot all about my earlier post in this thread. I did get VMware EFI PXE booting with WDS working. Here's an update which may help someone. VMware Support's testing made clear to me that the EFI PXE bootrom in vSphere 5.0 does definitely work, so I went back to my WDS server in more detail. The Microsoft KB (http://support.microsoft.com/kb/2012858) which comes up while researching this issue is a bit misleading. It suggested that in case of problems, an EFI PXE client should be hard-configured in WDS/DHCP to boot the boot loader boot\x64\Bootmgfw.efi In my infrastructure the WDS server is also a DHCP server. There are several workarounds for this since port 67 is used for both services. The first Microsoft-recommended method is to tick the boxes in the screenshot below: The downside of this method is that if DHCP option 60 is configured, Windows puts this in for *all* DHCP scopes on the server. With DHCP option 60, DHCP option 67 (Boot File Name) is ignored. This is not ideal because you may need to have different PXE settings for different subnets, say if you had Linux clients, or wanted to use VMware Auto-Deploy for instance. So, until now in my environment I had ticked the "Do not use port 67" option in that screenshot, but *not* the DHCP option 60. When this is the case, you need to define DHCP option 67 (Boot File Name). This had been set to boot\x86\wdsnbp.com so as to list all boot images on the WDS server as appropriate for both x86 and x64 clients. It worked fine like this for several years. When I was initially testing EFI PXE I consulted Microsoft KB2012858 and saw that I needed the loader boot\x64\bootmgfw.efi instead. But setting it to point to that file was crashing the VM. It transpires that the *only* way to get EFI PXE working with WDS when that same server is also a DHCP server is in fact to use the DHCP option 60 in that screenshot. I haven't carried out a packet trace, but I can see from the WDS logs that it's a whole lot more complex than just handing the PXE client the bootmgfw.efi loader. What it seems actually happens is that a temporary BCD boot menu is built on the WDS server (the client downloaded \Tmp\x64{25986027-7DF6-4A64-8133-BCE5DCCF5542}.bcd) and the whole thing behaves just like Windows Vista/7/2008's own proper boot loader, with Boot.sdi, and the various fonts being downloaded individually too. Perhaps there's dynamically generated stuff being sent to the client. If it isn't done exactly in the prescribed way, it fails. So really I think this ought to be made clearer in that Microsoft KB.

VMware ESXi 5.0 offers EFI firmware support, including PXE. I've been looking at this just recently because I want to make sure all servers built from now on are legacy free. The EFI firmware correctly IDs itself from what I can see, because I can see from the WDS events that it does successfully TFTP download the file boot\x64\Bootmgfw.efi However, it crashes and powers off the VM when it is executed, even though I'm on the latest ESXi (5.0U1). I followed the tips here: http://support.microsoft.com/kb/2012858 I have been able to work around this for now using a WinPE ISO image with EFI support, while VMware support look into the issue for me. To do this I updated my unified Windows PE build script to support EFI. This single batch script will build x86 and/or x64 versions, will ingest drivers, supports wifi, builds ISOs, and will automatically freshen the WDS boot images when complete. It does not use any third party tools - only Microsoft's WAIK: http://pcloadletter.co.uk/2011/12/03/windows-pe-builder-script-for-waik-including-wifi-support/

I got wifi working without using a third-party PE builder and wrote it up on my blog. My batch script uses the normal WAIK tools and will build both x86 and x64 versions. http://pcloadletter.co.uk/2011/12/03/windows-pe-builder-script-for-waik-including-wifi-support/

I think I've found the answer to my problem now that I'm aware of the log at %systemroot%\panther\setupact.log. I see: PnPIBS: Finished reading driver paths from unattend.xml. PnPIBS: Connecting to driver path \\myserver\UNATTENDED\drivers\7-x64\Dell745.drivers using credentials provided ... PnPIBS: Error 0x4C3 occurred while connecting to driver path \\myserver\UNATTENDED\drivers\7-x64\Dell745.drivers. [gle=0x000004c3] PnPIBS: WARNING: Could not access path \\myserver\UNATTENDED\drivers\7-x64\Dell745.drivers. Error 0x4C3 (67 in decimal) is when you try to connect multiple times to shared resources on the same server from a single user context with multiple sets of credentials. It's strange to see that because I'm using the same UPN login (user@domain) both for connecting to my unattended share (in my PE-based vbscript), and for adding into the XML so I don't really understand why it should fail. I can get around the problem by using the FQDN of the server in the autounattend.xml, thereby having Windows PE believe it's dealing with another distinct host. ...And I've verified that the offlineServicing pass now adds the drivers successfully!

Ok, a lot of reading and futile testing later, and I see that the guy who re-wrote ZTIDrivers.wsf for MDT2010 got it to copy the drivers locally, then add a devicepath, then invoke Sysprep. http://deployment.xtremeconsulting.com/2009/10/28/how-to-debug-mdt-litetouchdriver-problems/ That to me would tend to imply that the offlineServicing pass doesn't work otherwise surely he would have used it. EDIT - this Technet article seems to say that for a driver to be applied in offlineServicing, it first needs to be in the WinPE driver store. It then gets copied across from there. More testing in the morning...

Hi, I have adapted my existing vbscript 2003/XP unattended install to Windows 7/2008R2. Using XMLDOM my script edits a template autounattend.xml file and injects some entries (like hostname from the host database), then starts setup. I have the entire install working nicely but, like the thread starter, I can't get drivers integrated the 'old-fashioned' way (i.e. not using DISM). I support too many hardware configs to inject all the drivers into the base image, I don't want multiple OS images because frankly there's no point, and I'd rather not use the AuditSystem pass and Sysprep if I can help it. They add plenty of additional complexity, and again are not really needed in my case. As I understand it, I should be able simply to place some valid driver paths with credentials in OfflineServicing like so (I copied this from IE's XML viewer, so it's not the actual XML) and they should be soaked up into the machine's local driver store: - <settings pass="offlineServicing"> - <component name="Microsoft-Windows-PnpCustomizationsNonWinPE" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> - <DriverPaths> - <PathAndCredentials wcm:action="add" wcm:keyValue="2"> - <Credentials> <Domain>mydomain.local</Domain> <Password>mypassword</Password> <Username>unattendeduser</Username> </Credentials> <Path>\\fileserver\drivers</Path> </PathAndCredentials> - <PathAndCredentials wcm:action="add" wcm:keyValue="3"> - <Credentials> <Domain>mydomain.local</Domain> <Password>mypassword</Password> <Username>unattendeduser</Username> </Credentials> <Path>\\fileserver\drivers</Path> </PathAndCredentials> </DriverPaths> </component> </settings> I thought this would have broadly the same effect as OEMPnpDriverPaths in XP/2003 (i.e. it would integrate my drivers in the offlineServicing pass) but it appears not. The drivers do not get installed. I tried using local paths without credentials too (and putting the drivers in $OEM$\$1) to no avail. If I later manually click Update Driver and browse to the driver path in specified above, the driver installs. Reading about how MDT works on this problem seems to suggest my idea about how it should work is correct: http://exec.typepad.com/airdesk/2009/10/windows-7-deployment-part-6.html According to that post, the offlineServicing pass is indeed supposed to add any drivers that are found in the specified paths into the local driver store. Has anyone got this to work? I have noticed that you can add an additional devicepath in the registry (http://technet.microsoft.com/en-us/library/dd919224(WS.10).aspx) but this doesn't solve my problem. Many integrated video cards for instance have Microsoft supplied drivers in Windows 7 which are old. Adding a devicepath to the registry after the machine is built won't cause them to be updated without manual intervention. My final autounattend.xml (after editing by script) passes validation in WSIM so I don't think it's a syntax problem. I think I'm just not understanding the mechanisms properly. In case it's relevant - the driver I'm testing with is a signed Intel Q965 display driver, and a SoundMax HD Audio (both for Dell Optiplex 745). Each time I test the build it is ignored and the standard Windows drivers are installed instead. Manually browse to those drivers after the machine is built and they are preferred over the Windows ones. It's as if offlineServicing never runs. Is that because I'm launching from my own Windows PE 3.0, and not Boot.wim? Is there any logging I can check? Furthermore, I've compared my XML to this example autounattend.xml for offlineServicing and I still can't get any joy: http://support.microsoft.com/kb/978226

As per thread title really. My unattended installs to a domain, and I set the Administrator password in the XML too. I can't really see why it's prompting me. I don't want any local accounts at all apart from the Administrator one. Everything else goes through ok. It prompts quite far into the install. Does anyone know how to suppress this? Have I missed something?

Pixieboots - I've just wasted most of my morning screwing around with bcdedit, and it turned out that like you I was using the version on Vista RC2. Very frustrating. Even worse, I didn't check this forum! One problem - presumably this means you can actually only have a single PE 2.0 image if you do it this way, because it will always try to load the bootfiles from tftproot/boot. I'm using 2003 RIS to serve the image. I can only seem to find the BDD 2007 beta, even though I'm a volume licence customer. I rang MS today and they had no idea where I could get it. The beta version seems to be missing WDS and it doesn't have that documentation about booting via a PXE server. Where did you get yours?

No 64bit compile then I need to run WinPE X64 to unattended install the 64Bit OSes.

Got it fixed. Look here: http://www.911cd.net/forums//index.php?sho...&st=20&p=76574&

I've got this problem too. It did used to work ok a long time ago. You could have the X: drive and the normal network card drivers running at the same time. Something in BartPE has changed and broken this.

Having problems with this. I've used this useful HP utility to make a USB key bootable: http://h18007.www1.hp.com/support/files/hp...load/20306.html I developed an unattended install system for work which I boot via PXE using RIS. I use the system at home occasionally, and I have a laptop which I was trying to install using a USB key. The laptop is an HP which can only boot USB devices as if they're hard disks. Consequently it starts as the C: when booting from it, with the real HD as D: The problem is that despite me setting the D: drive as the temp location in my WINNT.EXE command line, WINNT uses the memory stick (c:) as the Temp drive and copies all the windows files here first before trying to move them and expand the filenames on the D: drive. The other big problem is that you then can't remove the USB key after the first reboot because it has treated it as the System partition (Microsoft terminology). The bootsector, NTLDR and NTDETECT all end up there. Is there any way to prevent this happening if the laptop won't mount the USB key as a floppy drive? I can't set the USB key to read only in the BIOS either. It's not a huge problem in that I can always use the floppy drive for the laptop but I had left it at work. And I'm not going to set up a domain with a RIS server at home...

No, that just enables automatic updates on the machine once it's built. Normally you get a speech bubble in the taskbar not long after the install finishes asking you about this and it's not enabled by default. It's a new setting with XP SP2: link So you've had this too then?

The ExtendOEMPartition is really a legacy setting from the old NT unattended method. Because you had no FAT32, and you had to use FAT16 to get the files onto the machine at the filecopy stage because you were using DOS, you had to stretch the partition out from its 4GB maximum to fill the disk during the conversion to NTFS.