Share via

WDS New Features Comming!!

  • Article

While the original WDS release plan was to have the feature set between WDS on Server 2003 and WDS on LH Server be identical, new hardware trends and customer feedback have necessitated some new feature development. Without further delay, we’d like to go ahead and announce the availability of three new features for WDS in LH Server –

 

1. Multicast.

2. TFTP download enhancements.

3. EFI x64 network boot support.

 

Multicast:

 

Yes, this is probably the most asked for feature in the deployment space and has been for many, many years. That said, the WDS multicast implementation takes things *way* beyond the existing technologies out there today. Sure, you can still accomplish the same scenarios that customers are used to with 3rd party products – configure an image for multicast, “stage” a bunch of clients, and click the ‘go’ button (or have the transmission automatically kick-off based on some administrator-set criteria). But imagine “always on” multicast where clients can request an image at any point in time and trigger a new multicast deployment or join mid-transmission to an existing deployment and still receive all the data. The WDS Team built a brand-new multicast protocol to handle both scenarios that has congestion control and flow control, making it more “TCP-like” and able to play well on production networks without saturating links and interfering with existing traffic.

 

Extensibility points were strongly considered when architecting the solution and were built into the client, server, and MGMT toolsets. Also, the ability to perform ImageX multicast deployments – without requiring full-blown WDS or Active Directory – are enabled, complete with a CMD-line multicast client app that can run within LH Server Windows PE, Windows Vista, Windows XP SP2, and Windows Server 2003 SP2 and easy set-up / configuration on the WDS Server.

 

Many changes were implemented in support of multicast scenarios. A few of the highlights –

 

a) New MGMT tasks in the WDS MMC and WDSUTIL

b) New WDS Client UI page indicating multicast transmission

c) Real-time multicast client view + ability to remove clients from a transmission via WDS MGMT tools

d) Real-time transmission progress / monitoring via WDS MGMT tools

e) Installation logging and reporting via Crimson to the application logs (read: this is how you can get installation metrics / tracking!)

f) Ability to install a “stand-alone” WDS multicast server complete with MGMT tools (command-line via WDSUTIL) and CMD-line client

 

TFTP Download Enhancements:

 

There were actually two pieces to this DCR. The networking team, owners of TFTPD, made it clear they wished to deprecate the TFTPD component. WDS was the only consumer of the component – it was included in the WDS manifests and only installed when installing the WDS Server role. The current TFTPD code base needs some work to help support WDS scenarios, particularly those involving a dual-homed server machine. Given the current design of TFTPD, this work would require almost a complete rewrite of the service. To solve this problem, we implemented a subset of TFTPD functionality, only that which was required for WDS network boot scenarios, and incorporated it as part of the WDS Server component. This option was chosen because the WDS Server architecture already supported dual-homed server scenarios, so making the changes needed to provide TFTP functionality within the WDS Service was actually faster and easier than rewriting the existing TFTPD.                               

 

The second piece to the functionality was to speed up TFTP downloads. TFTP uses UDP as the transport layer (which is itself connection-less) and requires that the client application send an ‘ACK’ for each packet received. As the latency of a network increases, TFTP becomes less and less efficient. Same goes for saturation of a link. The solution the WDS Team has produced is something we call TFTP windowing – sort of a hybrid implementation of windowing as seen in TCP. The idea is that instead of sending an ‘ACK’ for each packet received, the client will receive as many packets as dictated by the window size value and then send an ‘ACK’ that encompasses all of those packets. TFTP windowing allows for considerable improvements in TFTP download times, an area that is becoming more and more of an issue as the size of Windows PE images continues to increase (TFTP is used for downloading Windows PE).

 

X64 EFI Boot Support:

 

Recent hardware trends, especially in the server market, are showing an increased push to move from BIOS to EFI. In LH Server, WDS will provide simple network boot functionality for X64 EFI machines. This support allows clients to network boot, but does not allow for more advanced scenarios, such as PXE referral, that are offered on PC BIOS machines via WDSNBP.COM.

Comments

  • Anonymous
    January 01, 2003
    Now I must make some time to have a play with this (when I do I'll let you know, please feel free to

  • Anonymous
    February 08, 2007
    Looking over the TechNet master OPML this morning and came across this post. This has been a major ask