Personal tools
You are here: Home / Wiki / Windows


Windows in Emulab

Windows in Emulab

NOTE: This page describes using an existing "managed" Windows image in an Emulab testbed, and making user-customized derivatives which contain additional software and configuration changes. If you are a testbed administrator who wants to make a new Windows image from scratch, you will have a copy of the Emulab sources, and will need to consult the process documented here.

Note: Microsoft Windows 7 32-bit Professional Edition is currently the only supported Windows operating system flavor for experiment nodes in Emulab.

As much as possible, we have left Windows "stock", but some changes were deemed necessary or beneficial for use in Emulab. Please see the section OS Modifications below for details.

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

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.

All of the Emulab experiment automation and monitoring services have been ported to run on Windows/Cygwin. Sometimes the Emulab documentation shows explicit command paths, such as /usr/testbed/bin/emulab-sync. Cygwin handles both Unix and Windows-style command paths, as described below .

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 is not supported on all hardware types. Please see the Experiment Setup section for specifics.

Using Windows with Emulab

The Emulab Microsoft Windows offering provides various flavors of Windows (currently only one!), with Cygwin layered on top, Emulab management services added, and some OS tweaks (see OS Modifications below). Service packs and updates are tracked as they are released in the WIN*-STD images (Note: Windows XP is completely deprecated as of Spring 2013).

File Sharing

Under Windows, network shared directories are provided not by the NFS (Network File System) protocol, but instead via CIFS shares over the SMB (Server Message Block) protocol.

The "Client for Microsoft Networks" software contacts the CIFS 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.)

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. Under Cygwin shells, replace the backslashes with forward slashes, e.g.: //fs/share

WINXP: If you want to serve files from one of your experiment nodes to others, see the section on The netbt command .

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.

Each user's 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.

N.B.: Your Emulab Windows password must be explicitly set!

If you haven't ever done this, please go do it now!  Otherwise, you will not have a valid Samba account mapping, and many things - like home directory access on the nodes - won't work.

Experiment setup for Windows nodes

All you have to do is put a line specifying a Windows OS image in your experiment .ns file, like this:

    tb-set-node-os $node WIN7-STD

The Emulab Windows images are not specific to a particular hardware type, but there are restrictions (see below). You may explicitly specify the hardware type to run on if you wish, for example:

    tb-set-hardware $node d710

See the note below on using the tb-set-node-failure-action command for experiments with a large number of Windows nodes. This can save a swap-in with a large number of Windows nodes, or prevent a single node boot failure on a swapmod from swapping-out the whole experiment.

If you use these commands: tb-set-node-startcmd, tb-set-node-tarfiles, or tb-set-node-rpms you should read the sections on Permissions and Windows GUI programs below.

Available Windows images:

Click on an image name to jump to the image-id page with information on supported hardware types.

  • WIN7-STD - Windows 7 with up-to-date service packs and patches. NOTE: This image is updated periodically via Windows Update, typically after a Microsoft "Patch Tuesday", the second Tuesday of each month. All critical and security fixes are installed, up through the date we pull the image file. (See the date created field on the individual Windows Image ID's ).

Network config

The Windows ipconfig /all command only shows configuration information for enabled network interfaces. There will always be one enabled control net interface. The others are disabled if not used in your experiment. (See file /var/emulab/boot/ipconfig-cache for a full listing from boot time, including the disabled/unused interfaces.)

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: 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:

   ping [ -dfqrv ] host [ packetsize [count [ preload]]]

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.


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.

rtproto Static is supported by all available Windows images.

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 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 iptables-vlan
    $fw set-style basic

Windows nodes boot twice

Notice that Windows reboots an extra time after being loaded onto a node during swap-in. The first boot invokes Windows mini-setup, which binds the OS to the hardware it is running on and performs other setup actions, after which it must reboot. Be patient, Windows doesn't boot quickly. BIOS POST times vary by node as well, which can draw out setup time as well. As a data point: A full swapin of a Windows 7 experiment takes about 20 minutes on the Utah Emulab d710 hardware. It's best not to log in to the nodes until the experiment is fully swapped-in.

Windows, particularly Windows XP, can be finicky when it comes to setting up properly. If swapin failure is a problem for you, consider using the following command to make node failure non-fatal to experiment setup:

 tb-set-node-failure-action $your_node_name_here "nonfatal"

Emulab will still complain if it doesn't get the ISUP signal at the end of rc.bootsetup, but the swap-in or swapmod will proceed and allow you to figure out what's happening. Then you will probably have to manually reboot the failed Windows node to make it available to your experiment.

If you try to login to a node after swap-in to diagnose the problem 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, this is another symptom of a partial set-up. You have the additional option of executing this command on the node itself:


This gives Windows another chance to get it right.

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:

  • SSH (setup) - The SSH connection button gives a Bash or TCSH shell, as usual. Your Emulab ssh keys are installed on the node in a /sshkeys subdirectory.
  • Console (setup) - The serial console is supported for Cygwin shell logins using the agetty and sysvinit packages. This is the only way in when network connections are closed down! You can also monitor the Frisbee loading and booting of the Windows image on the console.
  • RDP (setup) - The RDP button starts up a Remote Desktop Protocol connection, giving a Windows Desktop login from the user's workstation screen to the experiment node.
    • The rdesktop client software is used from Linux and Unix client workstations.
    • A Microsoft RDC (Remote Desktop Connector) client program is included in Windows XP, and may be installed onto other versions of Windows as well. Unfortunately, we have no way to present your Emulab Windows password to RDC, so you'll have to type it on each login.

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.

RDP details

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

  • Microsoft allows only one desktop login at a time to Windows XP, although this is the same Citrix Hydra technology that supports many concurrent logins. The Fast User Switching option is turned on, so a second RDP connection disconnects a previous one rather than killing it. Similarly, just closing your RDP client window disconnects your Windows Login session rather than killing it. You can reconnect later on without losing anything. SSH doesn't count as a desktop, so you can ssh in and use this command: qwinsta (Query WINdows STAtion) to show existing winstation sessions and their session ID's, and this one to reset (kill) a session by ID: rwinsta

"Customize Desktop..." to get the "Desktop Items" dialog. Turn on the My Computer checkbox, then click "OK" twice.

  • There are several Desktop icons (i.e. "shortcuts") installed by default in the Windows images: Bash and TCSH shells, and NtEmacs. You will notice two icons on the desktop for invoking the Cygwin shell, labeled rxvt or rxvt-native and Cygwin or Cygwin Terminal.
    • The rxvt shells run in windows with X-like cut-and-paste mouse clicks:
      • Left-click starts a selection,
      • Right-click extends it, and
      • middle-click pastes. These are the ones to use if you're connecting from an X workstation.
    • The Cygwin shells run in a Windows Terminal window, just as the Windows cmd.exe does. These are the ones to use if you're connecting from a Windows workstation.
  • On the first login by a user, Windows creates the user's Windows profile directory under C:\Documents and Settings, and creates the registry hive for persistent settings for that user on the local node.
    • Your Windows home directory when logging in via RDP is not the same as your Emulab network-mounted home directory (from The latter is located under /user/<username>, and is what you get when working inside a Cygwin shell.
    • User "root" is special, and has a local home directory under /home.

The netbt command (Windows XP only)

The NetBT (Netbios over TCP) protocol is used to announce shared directories (folders) from one Windows machine to others. (See the Name and Session services in

The SMB (Server Message Block) protocol is used to actually serve files. (See

In Emulab, we normally disable NetBT on experiment nodes, because it chatters and messes up slothd network idle detection, and is not needed for the usual SMB mounts of /users, /proj, and /share dirs, which are served from a Samba service on fs.

However, NetBT does have to be enabled on the experiment nodes if you want to make Windows file shares between them. The netbt script sets the registry keys on the Windows network interface objects. Run it on the server nodes (the ones containing directories which you want to share) and reboot them afterwards to activate. There is an optional -r argument to reboot the node.

    Usage: netbt [-r] off|on

If you use netbt to turn on NetBT, it persists across reboots.

No reboot is necessary if you use Network Connections in the Control Panel to turn on NetBT. It takes effect immediately, but is turned off at reboot unless you do netbt on afterward as well.

  • Right-click Local Area Connection (or the name of another connection, if appropriate), click Properties, click Internet Protocol (TCP/IP), and then click the Properties button.
  • On the Internet Protocol (TCP/IP) Properties page, click the Advanced button, and click the WINS tab.
  • Select Enable or Disable NetBIOS over TCP/IP.

ipconfig /all reports "NetBIOS over Tcpip . . . : Disabled" on interfaces where NetBT is disabled, and says nothing where NetBT is enabled.

To start sharing a directory, on the node, use the net share command, or turn on network sharing on the Sharing tab of the Properties of a directory (folder.)

  • On XP-SP2 or above, when you first do this, the "Network sharing and security" subdialog says:
          As a security measure, Windows has disabled remote access to this
          computer.  However, you can enable remote access and safely share files by
          running the _Network_Setup_Wizard_.
  • Skip the wizard and click the latter ("I understand") link. Then click "Just enable file sharing", and "OK".
  • Then you finally get the click-box to "Share this folder on the network".

The machine names for UNC paths sharing are the same as in shell prompts: pcXXX, where XXX is the machine number. These will show up in My Network Places / Entire Network / Microsoft Windows Network / Emulab once you have used them.

IP addresses can also be used in UNC paths, giving you a way to share files across experiment network links rather than the control network.

Making custom Windows OS images

NOTE: Microsoft Windows is licensed, commercial software. Do not copy custom Windows images offsite.

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.

  • Log in to the node where you want to save a custom image. Give the shell command to change the root password. Pick a password string you can remember, typing it twice as prompted:
             % passwd root
             Enter the new password (minimum of 5, maximum of 8 characters).
             Please use a combination of upper and lower case letters and numbers.
             New password:
             Re-enter new password:
    This works because you are part of the Windows Administrators group. Otherwise you would have to already know the root password to change it. NOTE: If you change the root password and reboot Windows before running prepare below, the root password will not match the definitions of the Emulab Windows services (daemons) that run as root, so they will not start up.
  • Log out all sessions by users other than root, because prepare will be unable to remove their login profile directories if they are logged in. (See QWINSTA.)
  • Log in to the node as user root through the Console or SSH, using the password you set above, then run the prepare command. (It will print "Must be root to run this script!" and do nothing if not run as root.)
    If run without option arguments, prepare will ask for the root password you want to use in your new image, prompting twice as the passwd command did above. It needs this to redefine the Emulab Windows services (daemons) that run as root. This password needs to be the same as the root password you previously set and then logged in with.
    • You can give the -p option to specify the root password on the command line:
          	   /usr/local/etc/emulab/prepare -p myRootPwd
    • The -n option says not to change the passwords at all, and the Emulab Windows services are not redefined.
          	   /usr/local/etc/emulab/prepare -n
  • Making a hardware-independent disk image
    • The -s option is used to make hardware-independent images using the Windows Sysprep deploy tool.
          	   /usr/local/etc/emulab/prepare -s -p myRootPwd
      • WIN7 sysprep notes
        • As you create your Image Descriptor, set the reboot wait-time to 1200 rather than 240 so that swap-ins don't time out.
      • WINXP sysprep notes
        • If you use the -s with the -n option instead of giving a password, it assumes that you separately blank the Administrator password, or edit your Administrator password into the [GuiUnattended]AdminPassword entry of the sysprep.inf file.
        • This must be done from a login on the serial console, because Sysprep shuts down the network. prepare -s refuses to run from an SSH or RDP login.
        • Currently, hardware-independent images must be made on a pc850, and will then run on the pc600, pc3000, and pc3000w as well. There is an unresolved boot-time problem going the other direction, from the pc3000 to a pc850 or pc600.
          Windows normally casts some aspects of the NT image into concrete at the first boot after installation, including the specific boot disk driver to be used by the NT loader (IDE, SCSI, or SATA.) Sysprep is used by PC hardware manufacturers as they make XP installation disks with their own drivers installed. The Sysprep option to run an unattended Mini-Setup at first boot instead of the normal "Out Of the Box Experience" is used in some large corporate roll-outs. We do both. The Emulab /share/windows/sysprep directory contains several versions of the XP deploy tools matched to the XP service pack level, appropriate device driver directories, and a draft sysprep.inf file to direct the automated install process.
        • As you create your Image Descriptor, set the reboot wait-time to 360 rather than 240 so that swap-ins don't time out.
  • Finally, log out and create your custom image.
    • Windows is too big to fit in the partitioning scheme used by FreeBSD and Linux, so it's necessary when making a Windows custom image to specify Partition 1, and click Whole Disk Image.
    • When you're testing your custom image, it's a good idea to set the tb-set-node-failure-action to "nonfatal" in the ns file so you get a chance to examine an image that hasn't completed the set-up process. See the note below for other useful ideas.

Windows OS modifications

While we strive to provide a default OS configuration for Windows under Emulab, we have made changes to the OS environment to allow for ease of use, minimize surprises, and to make some Emulab client-side features work as expected. Microsoft goes to a lot of trouble to try and protect users from themselves and from malicious attacks (local and remote), and we disable a lot of these safeguards as they tend to make running privileged commands, setting up daemons, and automation difficult.

Windows 7

The following Windows facilities/services are disabled (reason follows):

  • Windows Firewall: Many exceptions would be required for Emulab control plane traffic, and also a barrier to experimenters utilizing the network.
  • Windows Defender: Could unexpectedly prevent custom applications from running (on false positive).
  • Automatic Updates: These would simply be thrown away on swapout, and could perturb experimentation. Updates are tracked by the WIN*-STD images.
  • Action Center Alerts: Consumer feature - we deem this a noisy, unnecessary distraction.
  • Windows Error Reporting: Consumer feature - not well suited for Emulab environment.
  • User Access Controls: Consumer feature - most Emulab users will need elevated privileges. Interferes with Emulab control plane automation as well.
  • Link Layer Discovery, SSDP, UPNP, and WS-Discovery: These are chatty protocols that perturb node idle detection. Nodes should also not be attempting to discover one another across the Emulab control network.
  • Computer Browser Service: Nodes should not be keeping a computer browse list to hand off to requesting nodes.
  • Scheduled Disk Defragmentation: Provides no benefit in Emulab environment, and could perturb experiments
  • Hibernate: Disabled to save space on disk, and deemed generally not useful to experimenters.
  • IPv6: Not yet directly managed in Emulab. Experimental interfaces without administered IPv6 addresses are chatty, which perturbs idle detection.
  • TCP Chimney offload: Causes TCP streams to be handled by the network card. This will frustrate and confuse people trying to sniff traffic.

The following OS settings/services are enabled or configured away from defaults (aside from obvious things like network addresses and routing):

  • CMOS clock set to GMT: By default Windows assumes that the BIOS clock should be set to the local time, and will adjust it if it doesn't agree with the time set in the OS. This interacts poorly with UNIX OSes that also use the same nodes, which assume the BIOS clock is set to GMT.
  • Enable RDP service: For obvious reasons.
  • Windows clock set to use SNTP and pointed at Emulab clock source
  • Global IP Forwarding enabled: Required for Static routing.
  • Powershell script execution policy set to "Unrestricted": Required by Emulab client-side, and generally useful for users.
  • Load Average perfmon counter setup: Supports idle detection.

Windows XP

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.

Put more stuff here... Or don't: WINXP is dead.


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#TARBALLS 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 and a server name, e.g. //fs, are used to access the SMB Shares under Cygwin. Emulab then uses the Cygwin mount command to make them appear on the usual Unix paths for the Emulab 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.

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 limitation: There is a hard-coded limit for the number of simultaneous mounts in Cygwin. This is 30 in Cygwin 1.5 under WINXP and 64 in Cygwin 1.7 under WIN7. Cygwin uses 4 of these, and Emulab uses another 3 or 4. So some of your /users mounts will fail on Windows startup if you have enough members in your project (unless they are grouped into smaller subgroups). The impacted users can still login via RDP or ssh, but will not have a mounted home directory from in the Cygwin environment.

Cygwin arcana

  • File paths Cygwin accepts either flavor of slashes in paths, Unix/POSIX-style forward-slashes, or Windows-style back-slashes. In Unix shell commands, backslashes need to be quoted. Single-quotes work best. Doubling each backslash also works. This must also be done inside double-quotes. Examples: '\single\quoted', "\\double\\quoted", \\un\\quoted. (The difference between double and single quotes is that $variable references and back-quoted command execution are expanded in double-quotes.) When you invoke Windows (as opposed to Cygwin) commands, for example net use, they will know nothing about Unix-style paths in their arguments. The cygpath utility is an aid to converting paths between the Unix and Windows conventions. cygpath -w converts its arguments to Windows format, and cygpath -u converts its arguments to Unix format, e.g.
      	 $ cygpath -w /cygdrive/c/WINDOWS
      	 $ cygpath -u 'c:\WINDOWS'
  • Mount points Cygwin mount points are shown by the mount and df commands. They also show up in /etc/fstab in WIN7 (Cygwin 1.7). See the discussion of mount points and UNC //machine paths to SMB shares above . Another special case is the Unix root, "/". It's mounted to C:\cygwin in the Windows filesystem.
  • Drive letter mounts Cygwin knows about drive letter prefixes like C:Â , which are equivalent to /cygdrive/<drive-letter>Â . Some Windows software requires drive-letter mounts to be created for its use. You can use the Windows net use command to associate drive letters with UNC paths to SMB shares, e.g.
      net use W: '\\fs\share\windows'
    You can use the Windows subst command to associate drive letters with local paths, e.g.
      subst T: 'C:\Temp'
    Filename completion in Cygwin shells with <Tab> doesn't work following a drive-letter prefix, but it works normally after a /cygdrive/ prefix. Also, filename completion is case-sensitive, although the underlying Windows is case-insensitive, so a filename in the wrong case is still opened properly.
  • NTSEC Cygwin is running in NTSEC (NT Security) mode, so /etc/passwd and /etc/group contain Windows SID's as user and group ID's. Your Windows UID is the computer SID with a user number appended, something like S-1-5-21-2000478354-436374069-1060284298-1334. Cygwin commands, such as id, ls -ln, and chown/chgrp, use the numeric suffix as the uid, e.g. 1334. This is different from your normal Emulab Unix user ID number, and the Samba server takes care of the difference. The id command reports your user id and group memberships. Note that all users are in group None on XP. Contrary to the name, this is a group that contains all users. It was named Everybody on Windows 2000, which was a better name.
  • setuid There is no direct equivalent of the Unix setuid programs under Windows, and hence no su or sudo commands. The Windows equivalent to running a Unix command as root is membership in the Windows Administrators group. Emulab project members who have either local_root or group_root privileges are put in group wheel, another alias for Administrators. Project members with user privileges are not members of the wheel group. You can ssh a command to the node as the target user, as long as you arrange for the proper authentication. For C/C++ code, there is a setuid() function in the Cygwin library, which "impersonates" the user if proper setup is done first.
  • root There is not normally a Windows account named root. root on XP is just another user who is a member of the Administrators group, see below. We create a root account as part of the Emulab setup to own installed software, and to run services and Unix scripts that check that they're running with root privileges. You can log in as root via RDP, ssh, or the serial console if you change the root password as described in the custom Windows OS images section. The root user does not have any Samba privileges to access Samba shared mounts, including the /proj, /groups, and /users.
  • Administrators group All users are members of the Windows Administrators group. (The Emulab non-local-root user property is not implemented on Windows.) Membership in the Windows Administrators group is very different from being root on Unix, and is also different from being logged in as Administrator. Administrators group membership on Windows only means you can set the ownership, group, and permissions on any file using the Cygwin chown, chgrp, chmod, or their Windows equivalents. Until you have done that, you can be completely locked out by read, write, or execute/open permissions of the directory or files. Another subtlety is that the group called None on XP is what used to be named Everybody on Windows 2000. All users are automatically in group None, so in practice setting group None permissions is no different from setting public access permissions.
  • Permissions Cygwin does a pretty good job of mapping Unix user-group-other file permissions to Windows NT security ACLs. On Windows, unlike Unix, file and directory permissions can lock out root, Administrator, or SYSTEM user access. Many Unix scripts don't bother with permissions if they're running as root, and hence need modification to run on Cygwin. This creates a potential problem with the tb-set-node-tarfiles and tb-set-node-rpms commands. The tb-set-node-tarfiles page says "Notes: 1. ... the files are installed as root". So you can easily install files that your login doesn't have permission to access. The solution is to chmod the files before making the tarball or rpm file to grant appropriate access permissions.
  • Executables Cygwin tries to treat .exe files the same as executable files without the .exe suffix, but with execute permissions turned on. (See the Cygwin Users Guide .) This breaks down in Makefile actions and scripts, where rm, ls -l, and install commands may need an explicit .exe added.
  • Windows GUI programs You cannot run Windows GUI (Graphical User Interface) programs under ssh, on the serial console, or by tb-set-node-startcmd. There is no user login graphics context until you log in via RDP. However, you can use a startcmd to set a Windows registry key that causes a GUI program to be run automatically for all users when they log in to the node via RDP, if that's what you want. The program can be one that is installed by tb-set-node-tarfiles. You can pick any regkey name you want and put it in the Run registry folder. It's good not to step on the ones already there, so choose a name specific to your program. Put the following in your startcmd script:
             regtool -s set /HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Run/mypgm 'C:\mypgm\mypgm.exe'
    (where mypgm is the name of your program, of course.)
  • Some Windows Console programs interact poorly with the Cygwin environment. Notably, Powershell cannot take input when run from a Cygwin shell prompt. These programs are generally making direct calls to the Windows Console read and write API functions.
  • Many Windows programs emit UTF-16 encoded text (powershell among them by default). Most Cygwin programs will mishandle text encoded in this way, with the exception of cat. The iconv tool can be used in a pipeline to convert UTF-16 to ASCII
             powershell ./some_script_that_produces_output.ps1 | iconv -f UTF-16 -t ASCII | grep ...


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/ntemacs executable is a symlink to /cygdrive/c/ntemacs/bin/runemacs.exe, which starts up an Emacs on the desktop. This only works under RDP, since SSH logins have a null desktop. A non-X version of Emacs is available under Cygwin by just typing "emacs". The latter emacs works fine in an ssh session or rxvt/Cygwin shell.

  • Can drag-and-drop files from Windows Explorer to NtEmacs windows.
  • cygwin-mount.el in c:/ntemacs/site-lisp/ makes Cygwin mounts visible within NtEmacs. It doesn't do Cygwin symlinks yet.

Known Issues and Caveats


  • Windows does not setup Samba credentials for users automatically upon account creation.

Even though a random string may appear for your Windows password when you view your account profile, this isn't actually pushed to the samba configuration on the 'fs' server.  You MUST explicitly set your Windows password in order for Emulab to push the change to Samba so that you can access your centralized home, project, and the 'share' remote file spaces via CIFS on experimental nodes running Windows.  See the beginning of this doc for instructions on how to do this.

Windows 7

  • Serial console issues: The agetty process does not currently setup the serial console in an ideal way. The output stair-steps, and 'enter' must be emulated with "Ctrl-J'
  • Cygwin mount limitation: See section above on SMB mounts.
  • Windows will fail during mini-setup (sysprep 'Specialize' phase) on Emulab TPM-enabled d710 nodes. These are automatically excluded from consideration for mapping.
  • Consider and research network optimizations: Windows 7 includes and enables several network optimizations by default: NetDMA, TCP Chimney Offload, and Receive Side Scaling. We have disabled TCP Chimney Offload as mentioned in OS Modifications. Read more about these here:

Change Log


  • Windows XP completely deprecated (broken).

2012-08-17 Introduction of Win7

  • Windows 7 released into the wilds of Emulab!
  • Documentation updated for newly introduced Windows 7 image.
  • Windows XP deprecated.

2006-11-16 Emulab client-side update

  • Updated the Emulab software to the latest versions, including:
    • Linktest: efficiency improvements and fix for intermittent one-way loss bug.
    • Event system improvements.
  • Additional minor stuff
    • Increased C: drive space from 4 gig to 8 gig.
    • Windows Update through the 11/14/2006 Patch Tuesday, on the UPDATE image only. Not installing IE 7.0 yet.


  • Updated the Cygwin and Emulab software to the latest versions, including:
    • A new version of the Emulab Linktest program. It does a better job of finishing-up, so the last packet (number 401) tends to make it through rather than getting dropped all the time. Windows still has more episodes of significant packet loss than either FreeBSD or Linux.
    • Bug-fixes in the workarounds for Windows network-setup flakiness. Setup is now pretty reliable, but Linktest level 4 (bandwith test) reveals that Windows XP can't keep up with a 100 mb/s LAN link; 85mb/s is about the best it'll do.
    • Added the netbt script to enable serving Windows file shares from an experiment node, see The `netbt` command .
    • The OpenSSH package is now version openssh-4.3p2-4 .
    • Added the Cygwin "netcat" package for the nc program. There's no man page, but see /usr/share/doc/netcat/README.


  • Switch to hardware-independent images, using the Microsoft Sysprep/Mini-Setup programs [1] [2] [4] [5] via the "prepare -s" option. It is no longer necessary to specify the hardware type with an image suffix, although you may want to do so to control the allocation of physical nodes to your experiment. The unsuffixed WINXP-{SP[012],UPDATE} images will now run on the pc3000 and pc3000w (WiFi) nodes, in addition to the pc850 and pc600. For compatibility with existing experiments, the image names with -pc3000 suffixes will still work, but they are just symlinks to the unsuffixed images. Notes:
    • Currently, hardware-independent images must be made on a pc850, and will then run on the pc600, pc3000, and pc3000w as well. There is an unresolved boot-time problem going the other direction, from the pc3000 to a pc850 or pc600.
    • The WINXP-SP0 image is almost pure from the 2001 XP CD, but has a 2002 SP1a pci.sys . This is needed to boot on the pc3000's which have a newer PCI chipset.
    • These images work on the __pc3000w (WiFi) nodes. There are drivers for the NetGear WAG311 WiFi cards installed, but no Emulab support to set up wireless networking under Windows XP yet.
    • None of these images will boot on the pc2000 nodes. It's probably a boot disk driver error under Mini-Setup for the ATA100 IDE controller.
    • There is a problem with TCP/IP that affects only SP0 or SP1 images running on the pc600's. (This may be due to the older versions of Sysprep/Mini-Setup for SP0 and SP1.) Due to this, the pc600 bit is turned off for the hardware-independent WINXP-SP0 and -SP1 images. Details: Outgoing connections work fine, so the node sets up under Emulab correctly. Incoming ssh connections time-out, although RDP works fine. Netstat shows the ssh socket 22 listening, but no connection attempts are logged by sshd in /var/log/messages. Packet capture shows that TCP SYN packets are being received, but the SYN-ACK handshake never goes out, so it's a lower-level problem.

  • Also fix an account creation bug and add more workarounds for Windows boot-time and network-setup flakiness. It seems that adding Sysprep to the mix has also improved the reliability of TCP/IP stack setup, probably because it tears down all of the internal network interface data structures and recreates them. This adds about two minutes to the Windows setup time, which seems worth-while.


  • The -UPDATE images include the most recent round of Microsoft patches, plugging both known WMF holes and many others. The -SP* images of course don't have the WMF holes plugged, but that's no different from before.
  • When making custom Windows images, the prepare script now requires you to set your own root password.
  • Within the Emulab code, these images restore linktest to working condition.
  • The other changes are intended to make Windows booting and setup more reliable. One is that sshd is turned off during rc.bootsetup, since it would sometimes go into a loop, eating the CPU and preventing setup from finishing before timing out. Unless you're logging in as root, it won't do you much good to try to log in before accounts are set up anyway... In case of trouble, log in via RDP or the serial console, and say "net start sshd" in a shell.
  • There is a random problem where one of the network interfaces disappears from ipconfig due to a race condition within Windows startup. rc.cygwin/rc.ifconfig now work harder at resetting the interfaces, and reboot as a last resort if that fails. It seems that fixing one interface can make the problem move to another one though. Unless you use all four available experimental-network interfaces in an experiment topology, this should fix the problem.


  • Enable linktest, including ltmap fetching, misc fixes, (c)rude and iperf.
  • Add hacks in watchdog, slothd, and idlemon for clock setback.
  • Back-rev OpenSSH to 4.1 in an attempt to cure sshd boot-time busy-looping.
  • Add rxvt shell windows for X-like mousing.


  • Race condition tweaks to rc.cygwin, add rc.firstboot to EmulabStartup service.
  • Cleanup tweaks to prepare and .
  • Add Cygwin ping package.


  • Cygwin updated, including OpenSSH 4.2p1-1 .
  • Serial console now works, with agetty and sysvinit providing a login shell.
  • network settings: DNS interface registration and TCP/IP autoconfiguration disabled, disabled unused experimental net interfaces, IPEnableRouter enabled on multihomed experimental nodes.
  • slothd: RDP idlemon for RDP keyboard and mouse events, load-avg correction on pc3000's.
  • program-agent: commands forked on experiment nodes now see Samba directories.


  • Everything created behind control-net firewalls to avoid contamination.
  • Patched sshd to support public-key login with Samba shares, and slothd.
  • Emulab program-agent, syncserver and slothd idle detection all work now.
  • NetBT (NetBios over TCP) is disabled to allow network idle detection by slothd.
  • Cygwin syslog now goes into /var/log/messages rather than Event Log.
  • Some Windows services are shut down: Messenger, SSDP Discovery Service, Universal Plug and Play Device Host, and Remote Registry.
  • Image creation time now put in /etc/motd.

Future Work

There are still some things undone:

  • Dynamic routing support for rtproto Session?
  • Support Emulab's storage subsystem.