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

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)

or

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)