Archon Team

Installing the IPv6 interface in Win2k3 SP1 WinPE

Archon Team — Thu, 22 Sep 2005 01:36:00 GMT

Installing a dual-stack networking interface to allow both IPv4 and IPv6 clients is possible very easily on the full version of Win2k3 SP1 and WinXP SP2, it is a simple matter of running the following command line:

netsh interface ipv6 install

If you run ipconfig after running this install, you should see a series of lines similar to this along with your traditional IPv4 address:

IP Address. . . . . . . . . . . . : 3ffe:8312:ffff:b1a1:6c90:9e5e:95fa:828e

It’s a little more complicated on WinPE as there’s a number of dependencies that aren’t available in the default install. Here’s a listing of them, this will also get netsh.exe working for most cases.

inf\netip6.inf

This is the main interface installation inf. This will actually need to be hand modified from the default found in the Win2k3 SP1 full build. The main difference is the smb service needs to be enabled to allow file sharing to work properly. Generally this is located in the file nettcpip.inf in the full os, but this has been stripped out for some reason in the default winpe nettcpip.inf file. You can choose to re-add this into the original file or (like I've done here) add the missing .inf parts into the netip6.inf file. Here's the appropriate changes that need to be made to the netip.inf file. New items are in bold. There's a lot of unchanged code in between, look for the .inf header sections to make sure you put the pieces in the correct place.

[Msft.NTx86]
    %MS_TCPIP6.DisplayName% = MS_TCPIP6.Install, MS_TCPIP6
    %MS_NETBT_SMB.DisplayName% = MS_NETBT_SMB.PrimaryInstall, MS_NETBT_SMB   ;NETBT_SMB
    %MS_SMB.DisplayName%        = MS_SMB.Install, MS_SMB

;**********************************************************
; NETBT_SMB section
;**********************************************************
[MS_NETBT_SMB.PrimaryInstall]
Characteristics = 0x38 ; NCF_HIDDEN|NCF_NO_SERVICE|NCF_NOT_USER_REMOVABLE
AddReg = Registry.MS_NETBT_SMB.PrimaryInstall

[Registry.MS_NETBT_SMB.PrimaryInstall]
HKR, Ndi,            BindForm,      0,          "NetbiosSmb"
HKR, Ndi,            HelpText,      0,          %MS_NETBT_SMB.HelpText%
HKR, Ndi\Interfaces, UpperRange,    0,          "netbios_smb"
HKR, Ndi\Interfaces, LowerRange,    0,          "nolower"

;=====================================
; Microsoft SMB Interface and Service Install
;=====================================
[MS_SMB.Install]
Characteristics = 0x28 ; NCF_NOT_USER_REMOVABLE | NCF_HIDDEN
AddReg = Registry.MS_SMB.Install

[Registry.MS_SMB.Install]
; Class Information
HKR, Ndi, Service, 0, "Smb"
; HKR, Ndi, HelpText, 0, %MS_SMB.HelpText%

; Interfaces
HKR,Ndi\Interfaces,UpperRange,0,"netbios_smb"
HKR,Ndi\Interfaces,LowerRange,,"tdi"

; Service install
[MS_SMB.Install.Services]
AddService = Smb, 0, Install.AddService.Smb, NetEventLog

; Install Smb service
[Install.AddService.Smb]
    DisplayName     = %MS_SMB.Smb.DisplayName%
    ServiceType     = 1 ;SERVICE_KERNEL_DRIVER
    StartType       = 1 ;SERVICE_SYSTEM_START
    ErrorControl    = 1 ;SERVICE_ERROR_NORMAL
    ServiceBinary   = %12%\smb.sys
    LoadOrderGroup = PNP_TDI
    Dependencies    = Tcpip, Tcpip6
    AddReg          = Registry.Service.Smb
    Description     = %MS_SMB.Smb.ServiceDescription%

[Registry.Service.Smb]
; HKLM,System\CurrentControlSet\Services\NetBT\Parameters,UseNewSmb,%FLG_ADDREG_TYPE_DWORD%,0
; HKR,Parameters,DebugFlag,%FLG_ADDREG_DWORD_NO_CLOBBER%,0x0

[Registry.Service.Smb.DelReg]
; HKLM,System\CurrentControlSet\Services\NetBT\Parameters,UseNewSmb

;====================================
; SMB Interface and Service Remove
;====================================
[MS_SMB.Install.Remove]
DelReg = Registry.Service.Smb.DelReg

[MS_SMB.Install.Remove.Services]
DelService = Smb
[Strings]
; NETBT_SMB
MS_NETBT_SMB.DisplayName = "Message-oriented TCP/IP Protocol (SMB session)"
MS_NETBT_SMB.HelpText = "A protocol layered on TCP/IP which preserves message boundaries. This instance of the protocol is for use by the file sharing protocol."

MS_SMB.DisplayName = "Microsoft NetbiosSmb"
MS_SMB.HelpText = "A protocol layered on TCP/IP or TCP/IPv6 which preserves message boundaries. This instance of the protocol is for use by the file sharing protocol."
MS_SMB.Smb.DisplayName = "Message-oriented TCP/IP and TCP/IPv6 Protocol (SMB session)"
MS_SMB.Smb.ServiceDescription = "Microsoft NetbiosSmb Device Driver"

system32\6to4svc.dll
system32\wship6.dll
system32\drivers\ip6fw.sys
system32\drivers\tcpip6.sys
system32\drivers\tunmp.sys

The files listed above are specific requirements for the IPv6 interface.

system32\drivers\smb.sys

The files listed above are specific requirements for the smb interface that's been added to the netip6.inf file.

system32\aaaamon.dll
system32\dhcpmon.dll
system32\fwcfg.dll
system32\hnetmon.dll
system32\ifmon.dll
system32\ipmontr.dll
system32\ippromon.dll
system32\ipv6mon.dll
system32\ipxsap.dll
system32\msctf.dll
system32\netsh.exe
system32\nshipsec.dll
system32\ntdsapi.dll
system32\rasmontr.dll
system32\rpcns4.dll
system32\wshisn.dll
system32\wshnetbs.dll
system32\wshqos.dll
system32\wshtcpip.dll

The files listed above are requirements for netsh.exe to run.

It may be possible to strip down the dependencies required significantly here, but I felt that enabling as much of netsh.exe as possible can only be a good thing. The files *mon.dll seem to be specific to the netsh program, which is why the ipv6mon.dll is in the second group. You may also be able to install the IPv6 interface using netcfg rather than the full blown network shell.

- mike (Michael Warmington, mwarm@microsoft.com)

Adding Mass Storage (and other) Drivers to a WinPE Image

Archon Team — Thu, 10 Feb 2005 01:42:00 GMT

Working in the Windows Setup team means we have to support a massive amount of hardware, which can vary tremendously across the company. This includes brand new machines that don’t have in box drivers or beta hardware that might have custom drivers. We use WinPE as our safe OS for automating Windows Setup installations so we must be able to update our images for widespread support. Installing a mass storage driver in WinPE is a little different to installing a regular driver, although no more difficult if you know what to do.

First thing is to locate the driver. Make sure you have the correct architecture driver for this, and that it contains a txtsetup.oem file in the top level directory. Make sure you keep the directory structure of the driver as the txtsetup file references this. You can make sure the directories are correct by taking a look inside the txtsetup.oem file:

[Disks]

d1 = "Promise FastTrak 378/TX4000/S150 TX Series Driver Diskette", \fasttx2k, \

d2 = "Promise FastTrak 378/TX4000/S150 TX Series Driver Diskette", \fasttx2k, \AMD64

As you can see here, the files should be located in the \AMD64 directory off the root location where the txtsetup.oem file should live.

Next, create a directory under the system32 directory to contain the driver files. This can be named pretty much anything you want, although I haven’t tested this with names longer than 8 characters. Put the txtsetup.oem file and all other driver files in this directory, making sure the directory structure of the driver is maintained.

The next step is to modify the winpeoem.sif file located in the system32 directory. Add your newly created directory to the OemDriverParams section as follows:

[OemDriverParams]

OemDriverRoot=""

OemDriverDirs=adaptec320, nv1, nv2, <YourDirectoryName>

If there’s other directories there, just add it as shown separated by commas. There’s one special case for a particular mass storage driver – the NVIDIA NForce Storage Controller requires the following addition:

[massstoragedrivers.append]

nvfix = classpnp.sys

Other than that, you’re done. Burn or lay the WinPE image down and boot from it – a little bit of luck never goes astray here either!

As for adding traditional drivers such as network cards to WinPE, this is as simple as putting the files in the appropriate spots – generally, *.inf files go into the I386\Inf or minint\Inf directories, *.sys files go in the system32\drivers directory, *.cat and any remaining files should go directly into the system32 directory. That’s it!

- mike (Michael Warmington, mwarm@microsoft.com)

Multi Boot Partition Tricks with the Windows Bootloaders

Archon Team — Fri, 04 Feb 2005 02:44:00 GMT

Fooling Windows Setup and Getting Away with It.

Say you’re wanting to run multiple installs of windows on multiple partitions, but you want to make sure that one install of windows doesn’t affect the other in any way. Why would you want to do this? The perfect example is if you’ve got a new version of windows currently installed and you want to dual boot an older one. Another reason to do this is to enable proper testing of a OS in an automated scenario.

A quick disclaimer – all the next info is specifically to do with x86 and x64 systems – ia64 is a completely different kettle of fish and deserves it’s own post at a later date.

If you install an OS that’s older than the currently running OS in a dual boot scenario, Windows Setup will overwrite the boot files from the newer OS with the older OS files. Generally, Windows bootloaders are backwards compatible but not forward compatible, so if you want to be able to boot back in to your original OS you’re pretty much hosed. For instance, if I’m running Windows 2003 Server SP1 and I run an install of Windows XP RTM, the boot files on my current system will be overwritten with the XP RTM versions. Even though the boot.ini file will be updated to contain links to both OSs, attempting to boot into Win2k3 will fail as the bootloader files are much older than the operating system files. Most of the time this is only an issue with major OS releases, servicepack releases will generally be compatible with other releases of the same OS.

There’s a couple of interesting things about the bootloaders and the basic sequence that happens when you turn on a machine. I’ll just quickly run through a functional sequence here:

1) Computer turns on and runs BIOS checks, determining which hard drive it has set to be the primary

2) BIOS checks this primary hard drive’s partition table, looking for the partition that is currently marked as the active partition

3) If the active partition is located, the loader is looked for in the root of that drive. The loader may or may not be a windows loader, so this is where the windows specific stuff comes in. If it’s a windows loader (for NT this is the hidden, system, readonly file ntldr) then the loader will typically (at least for a full OS, WinPE is a slightly different story I’ll talk about later) look for a file called boot.ini also located on the root of the drive.

4) The boot.ini file shows the partition that actually contains the windows version to boot. The loader will go to this partition and search for the directory listed in the boot.ini for the Windows loaders and proceed with them.

This sequence is interesting from a dual boot scenario because the bootstrappers rely on a single partition (the active one) to boot multiple OSs. This can cause a number of problems, specifically:

1) The older OS overwriting the newer OS’s boot files as described above.

2) If you’re testing a new OS by installing it from a known good older OS (what we call the “Safe OS”) and the new OS setup overwrites your Safe OS’s bootloaders, you’re relying on a potentially untested operating systems’ ability to successfully install and not have a buggy loader. This can be a very bad assumption to make, especially when restoring the original Safe OS configuration can take upwards of 40 minutes.

3) If you’re testing or using WinPE as a Safe OS, the current WinPE bootloader does not give you the ability to use a boot.ini file so there’s actually no way this will work.

So, having said all this, what’s a good solution? Well, the best way to do this is to make sure the test OS never overwrites the safe OS’s boot files. Before initiating an install, we make sure the Active partition is changed to the partition we’re planning on installing to.

How is this accomplished? Through the magic of diskpart. This is a fully scriptable command line disk and partition management tool that is included in Microsoft operating systems from Win2k up, including WinPE. To script diskpart, create a text file with one command per line and pass it in with the /s parameter. One tip – you only need to use the first three letters of any diskpart command, so for instance “select disk 0” can be abbreviated to “sel dis 0” - just a quick hint for those wanting to save some keyboard time. To activate Partition 2 on Disk 0, the diskpart script would be:

Select disk 0

Select partition 2

Active

It’s that simple. One fun thing to be aware of is that the disk numbers are generally zero based, but the partition numbers are generally one based. Also, volume numbers (which generally correspond to partitions) are zero based, so it can be very easy to get confused.

Once the partition is marked active, it’s time to fire off the Windows install. There’s a problem though – winnt32.exe (the windows setup executable) tends to freak out when you’ve changed the active system partition from underneath it. Here’s where some extra command line parameters come in handy. Call winnt32.exe with the syspart parameter as follows:

winnt32.exe /syspart:d:

This will let Windows setup know exactly where it should put the system files.

Booting back and forth with this configuration

This config is only really useful if you’re running beta versions of Windows, or you really don’t want installs screwing around with your boot files. The main issue is that you need to change active partitions to boot between operating systems which can be a major pain. If you’re using WinPE, however, this issue is a given. If you’re not, you can manually modify your boot.ini to allow an easy boot back and forth. (If you’d have installed your 2 windows in the correct order originally, ie. oldest version first, without using the active partition trick setup does this next part for you.)

A typical boot.ini file looks like this:

[boot loader]

timeout=30

default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS

[operating systems]

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect

Just modify this by adding in another entry under the Operating Systems heading, as so:

[boot loader]

timeout=30

default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS

[operating systems]

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect

multi(0)disk(0)rdisk(0)partition(2)\WINNT="Microsoft Windows 2000 Professional" /noexecute=optin /fastdetect

If there’s more than one entry in the OS section the bootloader will display a menu, then after the timeout time (in this case 30) will boot the default entry (in this case XP).

- mike (Michael Warmington, mwarm@microsoft.com)