Jump to content

Unattended XP over network

Recommended Posts

Hey all-

I wanted to see how you guys who install XP over a network do it.

I started looking into RIS, but our university's domain (I work for the IT group) doesn't use AD, so that got scrapped pretty quickly. Switched to Unattended and got that working, but I've been finding it less-than-satisfactory lately.

Unattended installs Windows, and then maps a network drive to the install share to install all the apps and do all the post-install configs. The problem is that we support a wide range of computers, and the NIC driver is not always detected (even with BTS DPs).

So I decided one day that I wanted to rework the way Unattended works to avoid the problem. The simplest solution would be to put all the apps and such into the $OEM$ production folder, but we have a large set of site-licensed software (around 25 gigs worth), so that's out the window, because the server could not handle copying 26 gigs of data for each XP install.

The problem is such: I want ONLY the necessary applications put into the production folders, so that Windows will copy them over before the install starts (thus cutting the dependence on the NIC driver working), but without copying any extraneous apps.

I'm currently accomplishing this by customizing Unattended somewhat. I set up Apache on the Unattended server, and programmed a basic PHP interface. A person signs on, gives the install a "session name" and selects the applications he wants to install. The server then creates a new XP folder and uses junctions and hard links (junctions and hard links are like symlinks in Linux) to "copy" the XP install files to the new folder, and then I use more junctions to "copy" the apps into the production folders.

So, basically, there's a new XP folder on the computer named after the provided session name, but it's all symlinks, instead of being actual files, so it takes up almost no space on the drive. The person then goes in through the Unattended boot and chooses to install XP from the folder. Text-mode setup copies the production folders over, and XP and all apps install from the hard drive after that.

I then just rigged a cleanup script to run every night and cleanup all the sessions.

Junctions can be created with Sysinternals' Junction tool: web site

Example script to create the symlinked dir (called "TestSP2" in the script) from a regular windows install dir (called "XPSP2")...I subsituted %1 for TestSP2 in the real script to make it callable w/ parameters.

:: CreateDir.cmd

mkdir D:\install\os\TestSP2
mkdir D:\install\os\TestSP2\i386
mkdir D:\install\os\TestSP2\i386\$OEM$
mkdir D:\install\os\TestSP2\i386\$OEM$\$1
mkdir D:\install\os\TestSP2\i386\$OEM$\$1\Install

junction D:\install\os\TestSP2\i386\$OEM$\$1\Tools D:\install\packages\Tools
junction D:\install\os\TestSP2\i386\$OEM$\$1\D D:\install\os\XPSP2\i386\$OEM$\$1\D
junction D:\install\os\TestSP2\i386\$OEM$\$$ D:\install\os\XPSP2\i386\$OEM$\$$
junction D:\install\os\TestSP2\i386\ASMS D:\install\os\XPSP2\i386\ASMS
junction D:\install\os\TestSP2\i386\COMPDATA D:\install\os\XPSP2\i386\COMPDATA
junction D:\install\os\TestSP2\i386\DRW D:\install\os\XPSP2\i386\DRW
junction D:\install\os\TestSP2\i386\LANG D:\install\os\XPSP2\i386\LANG
junction D:\install\os\TestSP2\i386\SYSTEM32 D:\install\os\XPSP2\i386\SYSTEM32
junction D:\install\os\TestSP2\i386\WIN9XMIG D:\install\os\XPSP2\i386\WIN9XMIG
junction D:\install\os\TestSP2\i386\WIN9XUPG D:\install\os\XPSP2\i386\WIN9XUPG
junction D:\install\os\TestSP2\i386\WINNTUPG D:\install\os\XPSP2\i386\WINNTUPG
junction D:\install\os\TestSP2\cmpnents D:\install\os\XPSP2\cmpnents
junction D:\install\os\TestSP2\docs D:\install\os\XPSP2\docs
junction D:\install\os\TestSP2\support D:\install\os\XPSP2\support
junction D:\install\os\TestSP2\valueadd D:\install\os\XPSP2\valueadd

fsutil hardlink create D:\install\os\TestSP2\i386\$OEM$\$1\Install\start.cmd D:\install\packages\start\start.cmd

The software packages are all located (for me) in D:\install\packages, so I basically have a batch file like so: (LinkPackage.cmd)

:: LinkPackage.cmd

junction D:\install\os\TestSP2\i386\$OEM$\$1\Install\%1 D:\install\packages\%1

And then I need to hard link the files individually from XPSP2\i386 to TestSP2\i386. We cannot just junction the i386 folders together because we need to put a "custom" $OEM$ in TestSP2\i386, and if we just junctioned them, when you then made $OEM$ in TestSP2\i386, it would also be created in XPSP2\i386, and that's wrong.

So I made an AutoIt script to pull a directory list and run "fsutil hardlink create" for each one. This duplicates the contents of the i386 folder, but leaves me free to modify the TestSP2 one all I want.

It's not as convoluted as it sounds, but I figured I'd ask and see if anybody has any suggestions/ideas for improvement. Maybe somebody can improve on it...I think this way works MUCH better than the original Unattended for widespread use (I've had too many Unattended installs crash because the NIC driver couldn't be found). LMK what you think!

Link to comment
Share on other sites

Although scrapped, AD is still the way to go for unattended installs. Perhaps you should outline the benefits / cost savings in money and manpower to whoever handles your budgets.

If anything, you can set up a single server running AD to push images to the clients and just tell them in the .sif file not to join the domain. You could set this up for under a grand =]

Link to comment
Share on other sites

I'm just a student employee though, so I have basically no say in the matter of AD. Besides, I'm actually pretty happy with how the modified Unattended has turned out. Because of the 8.3 filename limitation, I wound up changing it more (testing it out this week) to 7zip all the packages into their own zips and extracting them after the network copy to preserve non-8.3 limitations. Just more batch file making, etc...nothing too bad.

Link to comment
Share on other sites

You could take a look at Microsoft's Business Desktop Deployment or BDD.

We have adopted this method and have succesfully remotely upgraded 500 Win2k PCs in our own organization, 250 "bare-metal" installs for another customer and are preparing to remotely upgrade 9000 NT PC for yet another customer.

3 prepared images per customer (ACPI, AACPI and MACPI HAL types) cover all current makes and models.

Enterprise edition is designed around using SMS but the Standard edition can be used with Ghost or similar imaging products.

All drivers are included in the $OEM$ structure. The base PC is booted up using WinPE, connects to the server, downloads XP with all hotfixes, drivers, hardware apps (Roxio, ATI, HP stuff). The PC reboots, installs XP and once GUI, it then installs base apps such as Office, Virusscanner, Media Player, Codecs, Adobe Reader and WinZip from the network. Then the image is syspreped and captured.

Using SMS or Ghost or whatever, you then deliver the image to the PCs. The PCs once rebooted go through minisetup and install all the drivers and startup batch file checks the hardware and installs whatever hardware apps are needed for that particular PC.

During an upgrade using SMS, all the user's stuff is protected under a single folder, the remainder of the HD is wiped clean and the new OS is installed. During startup, the user's stuff is returned to their new profile that is created on the PC. Any additional applications that they require (that were not included as part of the base image) are delivered via Add-Remove programs using either AD or SMS.

It works very slick and using SMS it really is "Zero-Touch" without having to visit the client's location.


Link to comment
Share on other sites

Using SMS or Ghost or whatever, you then deliver the image to the PCs. The PCs once rebooted go through minisetup and install all the drivers and startup batch file checks the hardware and installs whatever hardware apps are needed for that particular PC.

Can you please tell me the configuration or setup that is required to install the drivers first?


Link to comment
Share on other sites

Sounds like a slick system, but if you go to the trouble of selecting for each install, why not use something like W.A.I.T or XPlode or WPI but have it run from the server instead of the local workstation, IE

(1) Dosboot to server - get XP install started on pc

(2) once installed - auto admin login and script checks for network share if available it kicks off WPI/WAIT/XPlode frontend for selection of apps to install, or it pops a window on screen saying please install network drivers.

(you can evan have base apps install first time and then extra apps after a reboot)

it "sounds" like you've re-invented the wheel so to speak, a **** fine way to get things going but some guys on this board alread have some great lookin and very useful tools to do exactly this stuff, paired with an Administrative share and you've got what you want without the apache server and all the scripts. I'd evan suggest looking at AutoIT v3 for automatinmg your installations, with a little bit of work you'd practically have a full CCM setup (FYI CCM became PowerQuest DeployCenter).

Kudos non the less, getting your work as a community project on here might be a good way to improve on things!


Link to comment
Share on other sites

See, you're missing the point. The method you just described is dependent on the NIC driver working--in a varied environment, it's not really possible for that to happen. I already got Unattended working in a similar way, but it fails pretty horribly if the NIC isn't detected.

The way I've reworked it, all the necessary files will get copied over during text-mode setup, so they won't be dependent on a NIC working post-install.

Thanks for the suggestions--I've already used AutoIT to make a selection system similar to kTool (but with treed checkboxes) that will configure user accounts and set up Outlook automatically. :)

Link to comment
Share on other sites

Sorry, I dont see the reason why to do it this way :(

RIS is just PXE implementation - you can use another PXE server, that is not dependent on AD, for example tftpd32...

I am using $OEM$ just for necessary files like drivers etc.. Apps/Software are installed after OS.

BTW maybe you should also check out SDS, you could be interested in it.

Link to comment
Share on other sites


I use the following procedure to automatically setup machines:

1. Boot BartPE ISO via PXE/TFTP

2. Autostart a script that:

- runs diskpart and format

- runs a little vb app that asks for computername, admin password etc.

- runs WPI (patched) to select software to be installed later

- writes info to hard disk

- runs winnt32.exe from network share to start installation

3. When setup is finished the previously selected software is installed from

a network share

Right now I'm planning to write a web interface similar to yours to

be able to install remote computers fully unattended:

1. Ask for MAC Address, Computername, software to be installed, etc.

2. Write that info to a file named <MAC>.txt on server share to be later read by

a script running on the client before starting winnt32.exe

3. Create a PXELinux config file with appropiate options

(This makes it possible to have the PXE boot rom enabled on all machines by

default. PXELinux will only boot from network if a config file named after

the mac of the computer to be installed is present on the server.)

If you're not sure if the NIC is detected later when windows is installed

you could also copy the apps to hdd before starting winnt32.exe.

The advantage of the WinPE method is that you have a 'real' windows

system running before installation. No 8.3 problems, no 2/4GB FAT16 limitation,

full ntfs write access, etc. etc...

Since I'm fairly new to this (I started about 6 weeks ago) I would

also like to hear your suggestions...

Link to comment
Share on other sites

I did understand your reasoning, which is why i said check for network connectivity if none then wait for drivers to be installed, my reasoning was if you get a system setup that doesn't require a lot of maintenance, you can focus on adding the necessary drivers to the admin share over time and once the admin share is caught up with all the old hardware any new hardware that comes in you can just add the correct drivers to the admin share before deployment, it's relatively easy to add nic drivers to an admin share so building up the library in the admin share will benefit you in the long run. ( sorry i kinda think long term with this stuff, especially in large networks where techs are usually outnumbered by user's without an understanding of why it's not a good idea to install AOL on your computer! )

your solution also works ( obviuosly! ;-) ) you may want to think about the DOS ntfs drivers for your boot disk, that way you can beat the 8.3 namimg prob.

My thinking with this stuff is eliminate as much extras as possible ( ie apache server ) the less links in the chain the easier it is to troubleshoot when things don't play nicely, i've been in far too many XP deployments in the last 3+ yrs and have become a little jaded because of it, you'd be very amazed at how badly XP can be pushed to a pc, i've actually seen people still using ghost to install a full XP image with no sysprep of the image, i still shudder to think how much that deployment is screwed!

Sounds like you got a lot of toys you've created for deployment needs, goodluck an all.


Link to comment
Share on other sites

I've spent a great deal of time modifying existing products to do exactly what you are talking about. I'm a VAR and I've installed thousands of completelly different PC's (depending on the customers order) using my setup (any OS I want.) I'll try to break down what I do, but I have to warn, I've modified some of these programs so heavilly that there barelly recognizable from the original versions. In many cases, requiring assembly or disassembly.

How it works (Programs I use are listed below):

First boots up using a bootp server and launches DOS


- Detects NIC and loads appropriate DOS NIC driver

- Creates a new PC installation request on the server via Network. Administrator see's this on the server and tells it what OS, and Computername we want for this PC. Then it's automated from here...

- System creates a 5GB FAT32 Partition and formats it (and a status partition just to hold a variable for me in the MBR)

- Detects the type of motherboard and flashes the latest BIOS and then Programs BIOS settings using iToolkit.exe It even programs the system serial number and Chassis version into the BIOS for me for that particular system (Intel boards only for that last part)

- Detects all peripherals and copies drivers to C:\TEMP\xxxx folders for that OS. This is why I start in DOS. It's pretty easy to detect hardware here.

- Runs BootPrep to give us a bootsector

- Unzip's a 41MB zip file containing everything you need for a mini WinPE OS.

- Launches a Diagnostic utility who's results are recorded for later (Quicktech Pro)

- Reboots to HDD now and launches WinPE

- WinPE connects to server and launches Winnt32.exe over network for appropriate OS

- WinPE reboots then system boots into File Copy Mode Phaze of Windows Install

- After another Reboot Windows Install converts Filesystem from FAT32 to NTFS and expands it to full size of HDD.

- Windows install now finishes up, using unattend.txt of coarse.

- First boot starts installing some small apps and windows updates that could not be slipstreamed for whatever reason.

- Second reboot the system starts installing software over the network. The software packages to install are determined by variables, which in this case are parsed out of the "Computername" we specified originally, using a small simple program I wrote in ASM.

- Third reboot the system executes a diagnostic (Stresstest) which runs indefinatelly until I stop it. The results are again logged for our records.

- Also a selectable program installer is launched, so if you missed any software, you can simply check off the checkboxes of software you want and 1 click to install it.

At this point windows is installed w/ all appropriate drivers and software and I've only made 6 clicks of the mouse. (OK I know it's lame I counted)

Here is a culmination of the base programs I use to accomplish this (Hope I'm not forgetting anything):

- BOOTP Server - I use Win2K for BootP

- TFTP Program - I use Kiwi Cat Tools. Simple and free. (If anyone know's how to get Win2K to do this, I'de like to know)

- Bootmanage Administrator - http://www.bootix.com . I've spent a rediculous amount of time modifying the default version of this to get where I'm at now, but it was worth it. I can do anything fully automated for thousands of different hardware configurations of PC's and OS's and software. Absolutelly no images here. This is what takes care of detecting the peripherals in DOS and copying the appropriate drivers.

- UMBPCI.SYS for a high memory driver

- FDISK.COM and FORMAT.EXE - from http://www.freedos.org The switches available in these 2 versions of the classics are great for 100% unattended creation of partitions.

- BOOTPREP.EXE - To give us a windows boot sector

- WINPE - a Striped down version of WinPE. As small as you can get it. I am around 41MB Compressed

- INSTALLS.EXE - Search around for this. It's a pretty decent selectable program installation utility. Simple to use and configure.

- SYSPREP - Obviouse I think. Before my machines are syspreped, I use WMIC and sysinfo to gather as much information about the system as possible which I record in a log file for our records.


Link to comment
Share on other sites

  • 2 weeks later...

um if you dont have permission to do allot of stuff like you say why not use unatended. You can think of it as an open source ris server.


this all seems like so much wasted effort. I do mine completely different mind you as I use the same cd's to install as I hand out to the customer so my install is not exactly unatended (so that recovery mode works also) but I do have all my software and whatnot install durring t-13. If done correctly there is only one chipset you will have issues with(nvidias) since the way they load their drivers is non-standard.

Link to comment
Share on other sites

Why do you call unattended "open source"? Unattend.txt files use a syntax designed and documented by Microsoft, and built into Windows setup... Calling it open source is a misnomer at best. Add to that fact that RIS flat installs use RISTNDRD.SIF files that are unattend.txt files with a different name and a handful of different entries (but can otherwise be customized exactly like unattended setup files). RIS IS unattended setup, and unattended setup isn't open source.

Edited by getwired
Link to comment
Share on other sites

Because the project I gave the link to above calls themselves unatended. It is an opensource project that replaces a ris server. It allows you to do full unatended installs over a newtwork using a setup simillar to ris.

Why don't you check out the link and see for yourself.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...