Windows XP in Emulab

Table of Contents:

  1. Overview
  2. Differences from FreeBSD and Linux in Emulab
  3. Cygwin
  4. NtEmacs
  5. Microsoft .Net Runtime
  6. Change Log <NEW>
  7. Future Work


Microsoft Windows XP is now supported as one of the operating system types for experiment nodes in Emulab, in addition to FreeBSD and Linux. Windows 2000 is not supported.

As much as possible, we have left Windows XP "stock". Some Windows services are shut down: Messenger, SSDP Discovery Service, Universal Plug and Play Device Host, and Remote Registry. Other setting changes are described under Network config and Routing below.

Before booting the node at swap-in time, Emulab loads a fresh image of Windows XP onto the experiment nodes in parallel, using our frisbee service. Emulab software automatically configures each Windows XP node, providing the expected experiment user environment including: user accounts and Emulab SSH keys; remote home, project, and shared directories; and network connections. All of the Emulab experiment automation and monitoring services have been ported to run on Windows.

The Cygwin GNU environment is provided, including Bash and TCSH shells, the C/C++, Perl and Python programming languages, and several editors including Emacs, vim, nano and ed.

The Emulab web interface manages a separate Windows password in the user profile, as well as making login connections to the experiment nodes. Remote Desktop Protocol service supports Windows Desktop logins from the user's workstation screen to the experiment node. SSH and Serial Console command-line connections are also supported.

Windows XP installations are more hardware dependent than Linux or FreeBSD. At present, this Windows XP image only runs on the Emulab pc850 and pc3000 node types.

Differences from FreeBSD and Linux in Emulab

The biggest difference of course, is that this is Windows (!), with Cygwin layered on top, and Emulab management services added. In particular, this is Windows XP (NT 5.1), with various levels of service packs and updates (see below.)

The second-biggest difference is that shared directories are provided not by the NFS (Network File System) protocol, but instead by the SMB (Server Message Block) protocol, otherwise known as Windows File Sharing. The Client for Microsoft Networks software contacts the SMB server, in this case Samba running on the file server known as Fs (an alias for Users.) The SMB protocol authenticates using a plain-text user name and password, encrypted as they go across the network. (These Windows Shares are then accessed by UNC paths under Cygwin mounts, described below.)

Windows Passwords

A separate Windows password is kept for use only with experiment nodes running Windows. It is presented behind-the-scenes to rdesktop for RDP logins by our Web interface under Unix, and for the Samba mount of shared directories like your home directory under an ssh login, so you don't have to type it in those cases. You will have to type it each time if you use the Microsoft RDC (Remote Desktop Connector) client program from a Windows machine.

The default Windows password is randomly generated. It's easy to change it to something easier to remember.

To see or edit your Windows password, log in to Emulab, and click Manage User Profile and then Edit Profile under User Options. You will see Windows Password fields in addition to the regular Emulab Password fields.

When you change your Windows password, you will also have to re-type it as a check. The new Windows password should propagate to the Samba server on Fs instantly, so you can swap in an experiment and log in to its Windows nodes with the new password.

If you have already swapped-in experiment nodes and change your Windows password, the account information including passwords will be updated at the next Emulab watchdog daemon isalive interval. This should be in 3 to 6 minutes.

Experiment setup for Windows nodes

All you have to do is put a line specifying a WINXP OS image in your experiment .ns file, like this:
    tb-set-node-os $node WINXP-UPDATE
    tb-set-hardware $node pc850
Notice that the above image only runs on the pc850 Emulab node type. At present, you have to explicitly specify a different image name and hardware type to run on the pc3000's . For example:
    tb-set-node-os $node WINXP-UPDATE-pc3000
    tb-set-hardware $node pc3000
Currently available Windows XP images are:

Network config

Some default Windows networking features are disabled. NetBT (NetBios over TCP) ( NetbiosOptions=2 ) and DNS auto-registration ( DisableDynamicUpdate=1 ) are disabled to allow network idle detection by the slothd service. TCP/IP address autoconfiguration is disabled ( IPAutoconfigurationEnabled=0 ) so that unswitched interfaces like the sixth NICs on the pc3000's don't get bogus Microsoft class B network addresses assigned.

The Emulab pc850 node type has five network interfaces, and the pc3000 has six. However, the Windows ipconfig /all command only shows the configuration information for the enabled network interfaces. There will always be one enabled control net interface on the 155.98.36 network. The others are disabled if not used in your experiment.

If you specified links or LANs in your experiment network topology , other interfaces will be enabled, with an IP address, subnet mask, and gateway that you can specify in the NS file. Notice that the Windows names of the interfaces start with Local Area Connection and have a number appended. You can't count on what this number is, since it depends on the order the NIC's are probed as Windows boots.

NOTE: Sometimes we have seen ipconfig report an ip address and mask of, while the TCP/IP properties dialog boxes show the proper values. ipconfig is wrong.


Full-blown router nodes can not run Windows, i.e. rtproto Session is not supported. However, basic routing between connected network components of your experiment topology works. The Windows command to see the routing tables is route print. The IPEnableRouter=1 registry key is set on multi-homed hosts in the experiment network, before they are rebooted to change the hostname.

rtproto Static is supported in all recent WINXP images, but not in WINXP-02-16 or before.

rtproto Static-old or rtproto Manual will work in any image.

There is more information on routing in the Routing Section of the Emulab Tutorial.

Firewalls is outside the University of Utah firewall, with only a minimal outer firewall , to allow free network experimentation. Even though we have closed most low-numbered ports, your Windows XP experiment nodes are still exposed to the wider Internet on higher port numbers.

If your experiment does not require that full freedom, consider adding a control net firewall node statement to your experiment ns file. This allows you to control the security level of your connection to the Internet by a style keyword , for example:

    set fw [new Firewall $ns]
    $fw set-type ipfw2-vlan
    $fw set-style basic
NOTE: There is currently a problem which makes swapping-in Windows nodes behind a control-net firewall take longer or fail, especially on the pc850's.

Details: DHCP packets aren't passed until the firewall node is loaded with FreeBSD and started up. That takes 3-4 minutes on a pc850 and leaves the Windows nodes in the FreeBSD PXE-loader image waiting for DHCP. Periodically, they time-out and reload the PXE-loader, which adds up to another minute after the firewall node is up, if you're unlucky.

After 10 minutes in the reloading state, Emulab gives up and reboots the node to try again, even if Frisbee is working hard and nearly done. 5-6 minutes is hardly enough time to Frisbee a WINXP image into a pc850. Either the image load time-out needs to be extended in experiments that have a firewall configured, or the load timer shouldn't start ticking until the firewall is up.

The Windows Firewall software is installed in WINXP-SP2 and WINXP-UPDATE images, but disabled to allow RDP and SSH access to Windows nodes.

Windows nodes boot twice

Notice that Windows reboots an extra time after being loaded onto a node during swap-in. It has to reboot after changing the node name to set up the network stack properly. Be patient, Windows doesn't boot fast.

It's best not to log in to the nodes until the experiment is fully swapped-in. (You may be able to log in briefly between the first two reboots; if you see the wrong pcXXX name, you'll know that a reboot is imminent.) You can know that the swap-in process is finished by any of these methods:

NOTE: Sometimes we have seen Windows XP fail to do the second reboot. We're working on it. If you try to login after swap-in and your Windows password isn't honored, use this command on Ops to remotely reboot the node:
    node_reboot pcxxx
If you are able to log in but your remote home directory isn't mounted, you have the additional option of executing this command on the node itself:
The EmulabStartup service runs /usr/local/etc/emulab/rc/rc.bootsetup, logging output to /var/log/bootsetup.log. If you're having swap-in problems and rc.bootsetup doesn't finish sending ISUP to Emulab within 10 minutes, the node will be rebooted. After a couple of reboot cycles without a ISUP, Emulab gives up on the node.

If you want to prevent swap-in failure, whether to diagnose the problem or to continue manually, you may add this line to your ns file for each Windows node:
        tb-set-node-failure-action $node "nonfatal"
(where $node is replaced with the node variable, of course.)

It will still complain if it doesn't get the ISUP signal at the end of rc.bootsetup, but the swap-in will proceed and allow you to figure out what's happening.

Login connections to Windows

You can manually start up the SSH or RDP client programs to connect and log in to nodes in your experiment, or use the console command on Ops. You will have to type your Windows Password when logging in, except for SSH when you have ssh-agent keys loaded.

Or you can set up your browser to automatically connect in one click from the Emulab web interface and pop up a connection window. Once you start swapping in an experiment, the Emulab Experiment Information page contains a table of the physical node ID and logical node name, status, and connection buttons. The captions at the top of the button columns link to pages explaining how to set up up mime-types in your browser to make the buttons work, from FreeBSD, Linux, and Windows workstations:

NOTE: If you import dot-files into Emulab that replace the system execution search path rather than add to it, you will have a problem running Windows system commands in shells. Fix this by adding /cygdrive/c/WINDOWS/system32 and /cygdrive/c/WINDOWS to your $PATH in ~/.cshrc and either ~/.bash_profile or ~/.profile. Don't worry about your home directory dot-files being shared among Windows, FreeBSD, and Linux nodes; non-existent directories in the $PATH are ignored by shells.

When new Emulab user accounts are created, the default CSH and Bash dotfiles are copied from the FreeBSD /usr/share/skel. They replace the whole $PATH rather than add to it. Then we append an Emulab-specific part that takes care of the path, conditionally adding the Windows directories on Cygwin.

NOTE: The Windows ping program has completely different option args from the Linux and FreeBSD ones, and they differ widely from each other. There is a ping package in Cygwin that is a port of the 4.3bsd ping. Its options are close to a common subset of the Linux and FreeBSD options, so it will be included in future WINXP images:
 ping [ -dfqrv ] host [ packetsize [count [ preload]]] 

You can load it yourself now using Cygwin Setup .

NOTE: There are no Cygwin ports of some other useful networking commands, such as traceroute and ifconfig -a. The Windows system equivalents are tracert and ipconfig /all.

RDP details

Here are some fine points and hints for RDP logins to remote Windows desktops:

Making custom Windows OS images

Making custom Windows images is similar to doing it on the other Emulab operating systems, except that you must do a little more work to run the prepare script as user root since there are no su or sudo commands on Windows. This is optional on the other OS types, but on Windows, proper TCP/IP network setup depends on prepare being run.


Cygwin is GNU + Cygnus + Windows , providing Linux-like functionality at the API, command-line, and package installation levels.

Cygwin documentation

Cygwin is well documented. Here are some links to get you started:

Cygwin packages

A number of optional Cygwin packages are installed in the image due to our building and running the Emulab client software, plus some editors for convenience. These packages are currently agetty, bison, cvs, cygrunsrv, ed, file, flex, gcc, gdb, inetutils, make, minires-devel, more, nano, openssh, openssl-devel, patch, perl, perl-libwin32, psmisc, python, rpm, rsync, shutdown, sysvinit, tcsh, vim, wget, and zip.

The Cygwin command cygcheck -c lists the packages that are installed, and their current version number and status. Package-specific notes and/or documentation for installed packages are in /usr{,/share}/doc/Cygwin/*.README and /usr/share/doc/*/README files. The Cygwin package site lists the available pre-compiled packages and provides a search engine.

If you want to install more Cygwin pre-compiled packages, run the graphical installer:


The Cygwin command cygcheck -l package-name lists the contents of an installed package, which may help you to make a tarfile or rpm from a package you have installed. You can then cause it to be installed automatically by Emulab into all of the nodes of your experiment. See the Tutorial for more information about installing RPM's and tarballs.

Watch out for post-install scripts in:


Many packages not in the Cygwin package site have also been ported to Cygwin already. Download the sources to an experiment node and try

    make install
as usual.

SMB mounts and Samba

User home directories and other shared directories are served by fs, another alias for Ops/Users, via the SMB protocol (Server Message Block, also known as Windows File Sharing) with the Windows Client connecting to the Samba server.

UNC paths with leading double-slashes //fs are used to access the SMB Shares under Cygwin. They are then further mounted to the usual Unix paths for the shared directories: /users/<username>, /proj/<pid>, /group/<pid>/<gid>, and /share.

The Cygwin mount command lists what you could access on the Samba server, with the UNC path in the first column. Unix file permissions may further limit your access on the Samba server. Log in to Ops to investigate.

/share/windows contains Windows software. See /share/windows/README.bin for descriptions of binary packages available for installation.

In Windows GUI programs, you can just type the UNC path into the Address bar or a file-open dialog with backslashes, e.g. \\fs\share or \\fs\<username>. User and project shares are marked "not browsable", so just \\fs shows only share.

Windows limitation: There is only one protection mask for everything in a whole mount/share under SMB. It's set in the "share properties" on the server (Samba config file in this case) so chmod will do you no good across SMB.

Cygwin arcana


We don't include the Cygwin X server in our XP images to keep the bulk and complexity down. So NtEmacs 21.3 is provided instead of the Cygwin X Emacs. NtEmacs "frames" are windows on the Windows Desktop, e.g. ^X-5-2 makes another one.

The /usr/local/bin/emacs executable is a symlink to /cygdrive/c/emacs-21.3/bin/runemacs.exe, which starts up an Emacs on the desktop. This only works under RDP, since SSH logins have a null desktop.

There is also a /usr/local/bin/emacs-exe executable, a symlink to /cygdrive/c/emacs-21.3/bin/emacs.exe, which is only useful as an Emacs compiler. It could be used to run Emacs in an SSH or Serial Console login window with the -nw (no windows) flag, except that it exits with emacs: standard input is not a tty. Another thing not to try is running emacs-exe -nw in a Bash or TCSH shell on the RDP desktop. It crashed Windows XP when I tried it.

Microsoft .Net Runtime

We have not included the Microsoft .NET Framework runtime in the standard WINXP images in an attempt to keep the image size down. If you need it, it's easy to install.

The installer for the Microsoft Framework Version 1.1 Redistributable Package is downloaded to /share/windows/dotnetfx.exe. Run it to download the runtime, agreeing to the EULA. It takes a few minutes, and uses 104 meg of disk.

If you want to develop .NET code as well as run it, you will need to install the .NET Framework SDK Version 1.1 .

Change Log

2006-02-14 2005-11-22 2005-10-28 2005-9-29 2005-8-22

Future Work

There are still some things undone: