[Falkoner]

I posted this on reboot.pro, but I figured I should go ahead and submit it to you guys for analysis as well. This topic could probably be split into several, but I think they're somewhat common questions, that don't need their own thread.

To begin, I'd like to let anyone trying to answer know that although I spent a few hours on each question searching for answers, I'm certain I missed topics, so if you know of a topic that seems to answer my question, feel free to just link me to it, although a nice summary would be appreciated as well

Currently I have a working PXE server, its set up is as follows:

• Built on OpenSUSE 11.4
  
• Using Advanced TFTP (atftpd) for PXE with pxelinux
  
• Using a Samba Share for post-boot files
  
• Entire shop is gigabit ethernet
  
• DHCP Server for the shop
  
• Performs NAT for all computers

The entire setup process for Vista/7 (my main focus) goes fairly smoothly, first the client computer boots into PXE and selects the installation (Win7/Vista, x86/x64) from the menus. Depending on your selection, a different WinPE 3.0 boots, they're simply variants of 64 and 32 bit versions with different startnet.cmd files for the commands. Once WinPE has loaded over PXE(takes a while), it proceeds to mount the Samba share from the server and runs the setup with a switch linking to the correct unattend.xml file(also on the share).
The setup is entirely unattended except for Windows version(Ultimate, Home Premium, etc.), product key, and partitioning, since these are not corporate computers, but random customers. Once the install is finished, the computer reboots, loads into Windows, and from there technicians use DriverPack Solution to install drivers, then they install basic software off the network share using a batch file which runs through various AutoIt scripts and batch files for silent installs.

Yes, it works, and I'm quite happy with it so far, but it doesn't quite meet my high expectations, and I would like to have the optimum solution. So, here's what I need help with fixing, and ideas that I've had which I just need some clarification on:

1. Smaller PE
As of right now, my WinPE 3.0 is just below 200 MB in size, and sending that much data over TFTP is horrendously slow, even on gigabit Ethernet, I'm totally fine with moving away from WinPE, as long as the switch can fulfill my needs. I looked into MicroPE but all the links to download it are down, so if anyone has other suggestions I'm open. The requirements of the PE are:
- Must boot from syslinux/pxelinux and run from RAM.
- Must have network(not necessarily WLAN) and mass storage drivers for virtually every machine, display only needs to be basic, this is going to be used on random customer machines, so I can't make machine-specific driverpacks. Unfortunately this does make the smaller drivers difficult.
- Be capable of installing Windows Vista/7 32 and 64 bit
- Doesn't need a GUI, just a commandline from which I can autorun scripts and mount network drives
- All of this must be able to be done unattended.

If you think you've got the solution for me, I'd be glad to see it, even if it takes lots of testing, I'm willing and able, or if there's some specific settings for WinBuilder, point them out to me. For now I'm likely going to use the miniXP that comes with Hiren's Boot CD, if I remove the programs I think I can cut it down to around 80 MB, maybe a bit less, if you have something that beats that, let me know.

2. Faster Winstall
I've been looking into programs like WinNTSetup and NT 6.x Fast Installer to speed up my installations, but I'm not certain they can do everything I need, such as:
- Prompting the technician for product key, Windows package(Ultimate, Home Premium, Business, etc), and partitioning setup before beginning
- Automating the install from thereon out, preferably with the use of an unattend.xml file, including running scripts post-install
- Being reasonably user-friendly, at least on the prompts, my technicians aren't all too bright
I believe I'll probably end up using WinNTSetup, because from what I can tell it meets my needs and is compatible with any PE I could throw at it, but if you have better suggestions I'm open to them.

3. Post-Install Drivers
While popping in DriverPack Solution and running it for most drivers works well enough, I'd prefer a faster automated solution that can be automatically run once the install is completed. I think the DPsFinisher might be what I'm looking for, but I can't find a page that describes how to use it well. Essentially, I need a solution that can:
- Add all network drivers to the Windows Installation pre-install (once again, this is for any machine, not a set group)
- OR copy the drivers and an installer for them to the HDD from PE(while we still have network support) after the installation has completed
- Once the network drivers are installed, it needs to pull all necessary drivers for the specific computer from the network share and install them automatically
I'll most likely be using the drivers from DriverPacks.net, since they've managed to cover pretty much anything I've come across, at least network-wise.

4. Speed Up Windows Updates
For now my plan is to put Squid on the server, since all network traffic is routed through it, in order to cache the Windows Updates and speed them up that way, but I'd like to find a solution like AutoUpdater with APUP that's easy to update and local. The only issue I've had with APUP is that it always has to verify the update integrity, and that takes a ridiculous amount of time, if anyone knows a way of disabling that "feature" I'd greatly appreciate it.

5. Software Installation
I've mostly got the software installs working, but I just have a couple quick questions I think you guys should be able to answer fairly easily, if not I just have to do some digging to find them myself:
- Is there a method that works for both Vista and 7 that allows you to add a post-install script to the installation? In other words, I want to be able to run a script after the first login. I know it exists, I just need the exact method of using it. Preferably one that will work with multiple installs in a single WIM file.

5. Windows XP
Anyone know any quick easy tutorial for PXE booting an XP installation? I don't even care if it's automated, I just want the option there.

6. Should I Try Imaging?
I've always felt that imaging installations is one of the best methods for automating installations, but XP has always had issues with it when trying to apply it to a wide variety of machines, have Vista and 7 solved this problem?


I know it's a lot, and I really appreciate all of you who didn't TL;DR this post, if I complete this project, I'd love to put together a nice tutorial which engulfs every piece necessary to recreate a system just like the one above, so your help is greatly appreciated and I hope to somewhat repay it.

[allen2]

The best solution to speed up windows updates is to use a wsus server.

[jaclaz]

Just for the record, and to help mantaining the interconnectedness of all things, the thread on reboot.pro is this one:
http://reboot.pro/15722/

jaclaz

[Falkoner]

allen2, on 31 October 2011 - 11:31 AM, said:

The best solution to speed up windows updates is to use a wsus server.

When researching this is the first thing I came across, my only issue is that my server is running OpenSUSE, and I haven't seen any good methods of running a WSUS server on Linux. I'm open to using virtual machines to run it, but would the server's active directory setup work properly when it's not the main server, but a secondary one?

EDIT: Looks like I may also be able to use a second computer, either way, is there any special configuration that needs to be done to client computers for them to use WSUS, or will they detect it straight out of the box as long as it's on the same network?

This post has been edited by Falkoner: 31 October 2011 - 03:08 PM

[allen2]

To run a wsus server, you don't need AD at all, you just need a computer (VM or physical). Then to have the client computer to register on the wsus, you need to set them up with policies (or reg entries):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"="http://wsus"
"WUStatusServer"="http://wsus"

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"UseWUServer"=dword:00000001
"RescheduleWaitTimeEnabled"=dword:00000001
"RescheduleWaitTime"=dword:00000001
"DetectionFrequencyEnabled"=dword:00000001
"DetectionFrequency"=dword:00000016
"RebootRelaunchTimeoutEnabled"=dword:00000001
"RebootRelaunchTimeout"=dword:0000000a
"RebootWarningTimeoutEnabled"=dword:00000001
"RebootWarningTimeout"=dword:0000000a
"NoAutoUpdate"=dword:00000000
"AUOptions"=dword:00000004
"ScheduledInstallDay"=dword:00000000
"ScheduledInstallTime"=dword:00000016

You just need to replace "http://wsus" with "http://ip_of_your_wsus_server".
You'll have to set up a rule for automatic approval and set a due date (if you the updates to apply for sure). You can also trigger the detection on the client using wuauclt /detectnow.

[Tripredacus]

allen2, on 31 October 2011 - 11:31 AM, said:

The best solution to speed up windows updates is to use a wsus server.

WSUS can only be used in the enterprise. If the OP is a reseller or some other entity that sells these PCs, WSUS shouldn't be used. Also, one possible issue with using WSUS in this type of environment is that the PCs won't be able to update after leaving the network where the WSUS Server resides, unless you can reset the update server info in the OS so it looks to Microsoft's website again.

[allen2]

Sorry to disagree there but Microsoft didn't release for enterprise only. Also the OP is implementing its solution for his enterprise so what's wrong there ?
And of course the reg entries (for wsus) should be removed after installing all updates.
And just for the record, those reg entries don't block windows update access using IE and that's what most people use to update their computer (when not in an enterprise).

[Tripredacus]

Falkoner, on 31 October 2011 - 10:23 AM, said:

If you think you've got the solution for me, I'd be glad to see it, even if it takes lots of testing, I'm willing and able, or if there's some specific settings for WinBuilder, point them out to me. For now I'm likely going to use the miniXP that comes with Hiren's Boot CD, if I remove the programs I think I can cut it down to around 80 MB, maybe a bit less, if you have something that beats that, let me know.

miniXP and Hiren's are Warez. We cannot help you with those programs. Discussion of it is against the forum rules.

allen2, on 01 November 2011 - 09:14 AM, said:

Sorry to disagree there but Microsoft didn't release for enterprise only. Also the OP is implementing its solution for his enterprise so what's wrong there ?
And of course the reg entries (for wsus) should be removed after installing all updates.
And just for the record, those reg entries don't block windows update access using IE and that's what most people use to update their computer (when not in an enterprise).

It appears that none of us fully read that post entirely since no one noticed the above quote. I hadn't noticed anything in the first post regarding what these computers were to be used for, so my post was a neutral statement. As far as where WSUS can be used, the only reason I know it can't be used on PCs that are to be resold is because MS sent me an email a few years ago saying I wasn't allowed to use it...

Anyways, good to know about those registry entries.

[Falkoner]

allen2, on 31 October 2011 - 07:30 PM, said:

To run a wsus server, you don't need AD at all, you just need a computer (VM or physical). Then to have the client computer to register on the wsus, you need to set them up with policies (or reg entries):

Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]"WUServer"="http://wsus""WUStatusServer"="http://wsus"[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]"UseWUServer"=dword:00000001"RescheduleWaitTimeEnabled"=dword:00000001"RescheduleWaitTime"=dword:00000001"DetectionFrequencyEnabled"=dword:00000001"DetectionFrequency"=dword:00000016"RebootRelaunchTimeoutEnabled"=dword:00000001"RebootRelaunchTimeout"=dword:0000000a"RebootWarningTimeoutEnabled"=dword:00000001"RebootWarningTimeout"=dword:0000000a"NoAutoUpdate"=dword:00000000"AUOptions"=dword:00000004"ScheduledInstallDay"=dword:00000000"ScheduledInstallTime"=dword:00000016

You just need to replace "http://wsus" with "http://ip_of_your_wsus_server".You'll have to set up a rule for automatic approval and set a due date (if you the updates to apply for sure). You can also trigger the detection on the client using wuauclt /detectnow.

That was what I was afraid of, that it would have to be set up on each client computer separately

allen2, on 01 November 2011 - 09:14 AM, said:

Sorry to disagree there but Microsoft didn't release for enterprise only. Also the OP is implementing its solution for his enterprise so what's wrong there ?And of course the reg entries (for wsus) should be removed after installing all updates.And just for the record, those reg entries don't block windows update access using IE and that's what most people use to update their computer (when not in an enterprise).

I was actually thinking I would do that before I saw this post Even though, Tripredacus is correct that I am using this on client machines:

Quote

The setup is entirely unattended except for Windows version(Ultimate, Home Premium, etc.), product key, and partitioning, since these are not corporate computers, but random customers.

However, if the legality of it as stated below is true:

Tripredacus, on 02 November 2011 - 08:38 AM, said:

It appears that none of us fully read that post entirely since no one noticed the above quote. I hadn't noticed anything in the first post regarding what these computers were to be used for, so my post was a neutral statement. As far as where WSUS can be used, the only reason I know it can't be used on PCs that are to be resold is because MS sent me an email a few years ago saying I wasn't allowed to use it... :angelAnyways, good to know about those registry entries.

Then I'd prefer to avoid it, I'm trying to keep this at a pretty legal standard, maybe removing all but the necessary updates from AutoPatcher could work almost as well.(continue reading before you call me contradictory over Hiren's).

Tripredacus, on 02 November 2011 - 08:38 AM, said:

Falkoner, on 31 October 2011 - 10:23 AM, said:

If you think you've got the solution for me, I'd be glad to see it, even if it takes lots of testing, I'm willing and able, or if there's some specific settings for WinBuilder, point them out to me. For now I'm likely going to use the miniXP that comes with Hiren's Boot CD, if I remove the programs I think I can cut it down to around 80 MB, maybe a bit less, if you have something that beats that, let me know.

miniXP and Hiren's are Warez. We cannot help you with those programs. Discussion of it is against the forum rules.

Understandable, although if I may, I'd like to point out that as of nearly six months ago, the only warez still in Hiren's is the miniXP itself and DOS, and since my company owns several extra keys for XP, and since Hiren's is only ever used on one or two machines simultaneously, it seems reasonably legal to me, however, I don't expect the forum rules to change over this, if I need to remove that sentence, let me know, I didn't request help with it though, I only put it out as a standard to measure possible solutions against. :/

Most of my questions have either been answered or I've figured something out myself, however, I'm still having issues with:
1. Specifics on what line to add to the Unattend.xml to add a command to run on first login, or just post-install.
2. Adding drivers to the installation. My current plan is to copy the DriverPack's LAN driver folder to the HDD while still in the PE, and then using the Unattend.xml to scan that folder and install the correct LAN driver, then scan a network share which has all the other drivers for everything else, if you have a better solution, or you can point me to the specific lines necessary to add to the Unattend.xml, I'd really appreciate it.

This post has been edited by Falkoner: 02 November 2011 - 11:15 AM

[ndog]

I am in a similar situation as you, so I came up with my own solution and programmed something in autoit.

• pxeboot client machine. Call ipxe -> pxelinux.0 (ipxe speeds things up a lot)
  
• Have a menu choice of either BartPE, WinPE3.1 x86, or WinPE3.1 x64. Depending on the RAM and CPU type you will boot the appropriate PE environment. BartPE requiring 386MB+ RAM, still I would like it to be smaller...
  
• the PE environment startup script points to the server and launches the application
  
• In the application you choose a preped wim file, select the NT5/NT6 (named to Windows XP and Windows 7 for other techs) and chose the architecture
  
• type in the cd keys of windows and office if it is selected
  
• type in some admin users and limited users, change the picture if you want
  
• select some software to be installed
  
• type any wireless settings
  
• type a computer name in

The GUI runs another program which runs CPUz and determines the manufacturer and model of the machine. If you have previously backed up drivers for that model operating system and architecture the status light will change and give a little popup which says drivers backed up or not etc. These will be used and copied to c:\drivers. If you install windows xp the program uses peimg to pre inject the drivers, otherwise windows 7 it will use dism to inject the drivers. If no drivers are previously backed up or the DP box is ticked then it will use yet another autoit script to scan through the driverpacks repo and either peimg/dism inject ones that correspond to the system. note however this only applies to the current PE environment eg only bartPE can be used to peimg inject xp drivers, winPE3.1 x86 can only be used to dism inject win7 x86 drivers etc. Another option I will include later will be to simply copy the entire driver repository and run a post os install driver install. All driver bases covered..

After pressing OK it does some syntax checking eg properly formatted computer name or user name etc and then generates a batch file which does all the work of

• prepare the drive, eg format, make active, install a bootloader
  
• apply a wim file to that drive
  
• copy the drivers to c:\drivers
  
• if windows xp use fix_hdc to apply mass storage drivers, if windows 7 use fix_hdc_7.vbs to apply correct mass storage drivers
  
• if windows xp use anoter autoit program (CPUZ based) to detect CPU and install correct HAL
  
• copy all the install programs and related scripts into place
  
• reboot

The wim files all need to be prepared in a way that will go and go and run the scripts that get copied into place, this differs with each one. With the windows 7 images I have a code in the unattend.xml which create the admin user and then runs a script which creates something under startup on the startmenu which in turn runs the main script... Same kind of concept with windows xp image.

I do not have plans to share code right now as it is messy..., however it may inspire you.
Good luck on your project. Feel free to ask any questions

Attached File(s)

•  GUI.PNG (47.93K)
  Number of downloads: 40
•  runpeWIN7.cmd (2.04K)
  Number of downloads: 10
•  runpeXP.cmd (1.82K)
  Number of downloads: 9