How WDS works- An inside story with Netmon traces.

  • Article

Hello My name is Mayank Sharma and I am a technical Advisor at Microsoft. In this blog I am going discuss how WDS performs the installation on a remote client and what the role of each component is. Reason why I’m writing this blog is that while there is a lot of information available in web about each WDS component; it is quite scattered, so thought of consolidating all at one place. 

 

So before we get started, here is what my lab looked like when I did a test deployment.

  • WDS server- It is named MDT.domain.mayank while it’s IP was 10.162.100.50 running windows server 2012 R2 Ent version. it is MDT and not WDS as it hosts MDT role as well, not related to this post in any way. 
  • Client machine- it didn’t have any name (I am yet to deploy it) however DHCP gave it an IP 10.162.100.51 (more on this later.)
  • A DC running window server 2012 R2 Ent version and also hosting the DHCP role, both DHCP and WDS server were in same subnet.
  • Netmon was installed on WDS server to capture all the network frames in and out.
  • I also enabled WDS tracing on WDS server as per: https://support.microsoft.com/kb/936625 (I will covery logging part in some later posts.)

 

Ok, so let’s get started:

  • When we first start a client machine, and it is configured to boot from network adapter, first thing it does is to load a very minimal network device driver that can support TFTP protocol. This is embedded in the adapter firmware and thus to boot from network adapter client computer must have a PXE capable network card. The specification of a PXE boot is developed by Intel.
  • Once the network adapter loads the very thin firmware and is capable TFTP file transfer, it then sends a broadcast request in entire subnet and looks out for DHCP server, essentially it is asking for an IP so that it can register itself on TCP network. The traffic request is on a UDP ports, DHCP uses port 67 for DHCP server and 68 for client machine. Since my WDS and DHCP servers are both on same subnet, the broadcast request will reach WDS source server as well however it will be discarded by WDS server in absence of a valid IP.
  • DHCP acknowledges the request and then DORA process occurs, here is more about the DORA process, https://technet.microsoft.com/en-us/library/cc780760(v=ws.10).aspx (look under client and server interaction.) It basically is a mechanism how we assign an IP to the client. Wait… it os too of theoretical stuff going on right now, in my netmon trace I can easily see how DORA process is going on client:

 

  1. 5      5:16:16 PM 11/29/2014                15.6000421 svchost.exe 0.0.0.0       255.255.255.255          DHCP        DHCP:Request, MsgType = DISCOVER, TransactionID = 0x5E8C2629  {DHCP:5, UDP:23, IPv4:22}
  2. 6      5:16:16 PM 11/29/2014                15.6004369 svchost.exe 10.162.100.101            255.255.255.255          DHCP        DHCP:Reply, MsgType = OFFER, TransactionID = 0x5E8C2629       {DHCP:5, UDP:23, IPv4:22}
  3. 46     5:16:16 PM 11/29/2014                15.8789009 svchost.exe 10.162.100.51             255.255.255.255          DHCP        DHCP:Reply, MsgType = OFFER, TransactionID = 0x5E8C2629       {DHCP:5, UDP:23, IPv4:22}
  4. 49     5:16:20 PM 11/29/2014                19.5682145 svchost.exe 0.0.0.0       255.255.255.255          DHCP        DHCP:Request, MsgType = REQUEST, TransactionID = 0x5E8C2629   {DHCP:5, UDP:23, IPv4:22}
  5. 50     5:16:20 PM 11/29/2014                19.5687886 svchost.exe 10.162.100.101            255.255.255.255          DHCP        DHCP:Reply, MsgType = ACK, TransactionID = 0x5E8C2629          {DHCP:5, UDP:23, IPv4:22}

 

  • Keep in mind the DHCP server has an IP address of 10.162.100.101 and by this time it has assigned the IP of 10.162.100.51 to the Client which will eventually get a windows installed on it.

 

  • Now Once client is no the TCP network it contacts the WDS server and then seeks the information of the WDS server name and the network boot program, below is how we see things in the netmn trace.

 

 

  1. 53     5:16:20 PM 11/29/2014                19.5697607 svchost.exe 10.162.100.51             10.162.100.50             DHCP        DHCP:Request, MsgType = REQUEST, TransactionID = 0x5E8C2629   {DHCP:5, UDP:23, IPv4:22}
  2. 82     5:16:20 PM 11/29/2014                19.6229946 svchost.exe 10.162.100.50             10.162.100.51             DHCP        DHCP:Reply, MsgType = ACK, TransactionID = 0x5E8C2629          {DHCP:5, UDP:23, IPv4:22}

 

  • Below screenshot actually shows how during a communication WDS server is sending our client the name of the WDS server as well as the network boot program.

 

 

 

 

  • Now once client knows what network boot program it needs to download, it sends the request switches to TFTP protocol to download the network boot program, here is how it looks in my netmon traces.
    1. 83     5:16:20 PM 11/29/2014                19.6784518 svchost.exe 10.162.100.51             10.162.100.50             TFTP          TFTP: Read Request - File: boot\x86\wdsnbp.com, Transfer Mode: octet tsize: 0          {UDP:27, IPv4:22}

 

 

  • It is important we know what a WDSNBP is, a WDS NBP is the boot program which performs two very important tasks,

 

    1. It performs the architecture validation to identify information about the underlying architecture.
    2. It also proceeses the data that is needed while processing auto-add policy, more information about auto-add feature can be found here: https://technet.microsoft.com/en-us/library/cc754117.aspx
    3. WDSNBP now initiates a TFTP session with the WDS server and then downloads PXEboot.com or PXEbootn12.com. these are actually boot program which starts the boot up processes for the client. Depending upon if you have configured your client machine to configure clients to press F12 to start the network boot or proceed to network boot without asking for user intervention PXEbootn12.com or PXEboot.com will get selected. Below is the snippet for the pxebootn12.com download from WDS server to client.

 

161   5:16:21 PM 11/29/2014                20.1944063 svchost.exe 10.162.100.51             10.162.100.50             TFTP          TFTP: Read Request - File: boot\x64\pxeboot.n12, Transfer Mode: octet blksize: 1456   {UDP:34, IPv4:22}

 

 

  • PXEbootn12.com will in turn download bootmanager.exe, it is important we know why; we typically boot into winpe first and then from there we use install.wim file to extract it to our to be c:\ drive and this is how an OS is installed. Now just in case there are multiple boot.wim that lies in WDS server, user must be given an option to choose which boot.wim he wants to use to boot to. (A typical back screen that comes up listing to all the boot.wim files in the WDS server.)  For this purpose; there is a separate BCD store which contains the entries for each of the boot.wim files that are added in WDS server, I have blogged some more about the WDS server here: https://blogs.technet.com/b/sunshine/archive/2014/11/23/how-to-change-the-the-display-order-while-doing-pxe-boot-from-wds.aspx . In a nutshell, we will need the open this store to let a user choose what boot.wim to boot from and thus we will need a boot manager.

 

  • After bootmanager.exe is downloaded, BCD store is downloaded on the client machine

 

1092 5:16:37 PM 11/29/2014                36.9675165 svchost.exe 10.162.100.51             10.162.100.50             TFTP          TFTP: Read Request - File: \Tmp\x86x64{C4357FF3-9277-4970-A2DD-10AA08FAC69B}.bcd, Transfer Mode: octet tsize: 0 blksize: 1456                {UDP:40, IPv4:22}

 

Once BCD is parsed and a specific boot.wim is selected, we download boot.sdi file, counter-intuitive? As we are supposed to download boot.wim at this time? Well; actually No. boot.sdi is holds the directory structure for boot.wim. you cannot access a wim file as is; it must be mounted somewhere, (remember dism command to mount a wim, making changes and then committing the wim?) Boot.sdi is the location where the boot.wim is actually mounted. Physically; boot.wim is loaded in the physical memory of the client machine.

 

    1. 1118 5:16:38 PM 11/29/2014                37.0843144 svchost.exe 10.162.100.51             10.162.100.50             TFTP          TFTP: Read Request - File: \Boot\Boot.SDI, Transfer Mode: octet tsize: 0     {UDP:45, IPv4:22}

 

  • After boot.sdi is downloaded, boot.wim is downloaded

 

  1. 3895 5:16:39 PM 11/29/2014                38.6296372 svchost.exe 10.162.100.51             10.162.100.50             TFTP          TFTP: Read Request - File: \Boot\x64\Images\boot.wim, Transfer Mode: octet tsize: 0 blksize: 1456 windowsize: 4 msftwindow: 31416 {UDP:53, IPv4:22}
  2.  
  3. After boot.wim is copied over, we start booting from boot.wim, now that winpe is loaded, it is a thin and a stripped operating system, Now next in line is to download the install.wim, one important thing that happens at this time is the communication switches from TFTP to SMB2 protocol.

 

  1. 190491              5:18:35 PM 11/29/2014                154.4522134               System      10.162.100.52             10.162.100.50             SMB2        SMB2:C   CREATE (0x5), Sh(RWD), MxAc+QFid, File=Images\ImageGroup1\install.wim@#190491                {SMB2:96, SMBOverTCP:87, TCP:86, IPv4:71}