WDS and DFSR: Love at First Sync

12/16/2009

11 minutes to read

In this article

Ned here again. Windows Server 2008 introduced a new way to roll out your computers called Windows Deployment Services (WDS). WDS replaces the old Remote Installation Services introduced a decade ago with Windows 2000. By leveraging WDS, you can create image-based deployments, script settings, multicast, and all that other stuff that gets the OS installation folks excited.

If you dig into the WDS documentation you will find that DFSR and DFSN are recommended for scaling out your deployment servers. You can centralize administration and improve performance by creating multiple distribution points that replicate OS images. All while using components you already paid for when you bought your servers.

A few months ago, someone asked if DFSR’s Remote Differential Compression (RDC) feature had any benefits when being used with WDS, where OS images are periodically updated. Would a robocopy script perform better? Are there any interoperability issues? Is the only advantage that files are automatically copied?

I’ve been asked about this a few more times since then, so today I’ll talk about the results. Spoiler alert: WDS and DFSR work really well together. :)

Make changes to it ( in my case, about ~1MB of data added to the image)

Dismount it

Replace the previous image

WDS uses a single instance store (SIS) as part of its storage mechanism. In basic terms, this means that data common among images is unified in one RWM file. And then the differences are stored in the OS image WIM file, which operates like a stub when you start installing the OS. This saves disk space, which is critical when you’re talking about dozens of images. This also means that both the Install*.WIM and Res.RWM files are altered when modifying your image.

Note: in my case I did not have to increase the staging quota as my files still easily fit in the 4GB default staging space. You may need to increase it using our old, reliable DFSR performance tuning article:

The Results

WDS always replaces the existing Install*.WIM file with another copy. Additionally, the binary contents of the replaced file are effectively completely different than the original – it’s just how WIM creation works. So RDC does not provide any gains when replicating a WIM file. The file is copied in its entirety, but more on this below. However, the WIM files in WDS are comparatively small, so DFSR moves them very fast.

WDS does not replace RWM files; it modifies them in place. This means that DFSR uses RDC and we see substantial savings over the wire in bandwidth. In our test, we added a small amount of data to the mounted image, which modifies the Res.RWM file. DFSR dies not replicate the whole 3.6GB of data; instead, DFSR replicates the delta of the change plus some overhead. The total delta of replicated data with the RWM file was around 1MB of data. That is an RDC savings of roughly 99.98%.

The cost here when using RDC, is that a file this large spends most of its time in local disk I/O and CPU time on both WDS servers.

Upstream on “A” - copying the file to staging, walking all of its data to create signatures – took several minutes

Downstream on B – copying the file to staging (unless it already exists), walking all of its data to create signatures, taking the bits that were sent over the wire and reconstructing the file with its changes, installing the file

So only a few seconds and 1MB of data was network time – the rest is “thinking time”. If you have a low-latency, high-bandwidth, gigabit network between all servers, then using DFSR with RDC to save bandwidth is not advantageous over just copying the files with say robocopy or xcopy – it might appear slightly slower. But if the network WAN connections are not fast or high bandwidth, then DFSR with RDC saves a ton of bandwidth and time. Also, you can turn off RDC on just these super-fast network scenarios and at least get DFSR’s “keep my files in sync so I don’t have to think about it” advantage.

That’s the short answer. Not everyone likes to read my DFSR debug diatribes, but if you do, carry on to the next section.

20091007 18:06:18.139 1852 INCO 6593 InConnection::LogTransferActivity Received RAWGET uid:{7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v137 gvsn:{7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v246 fileName:install.wim connId:{D3F93FEA-BF07-4CEF-8E4E-E82564BE2E7B} csId:{35F6E8DD-422B-4566-B7AD-9D13338E498C} stagedSize:2657686 ß RDC could not be used – no matching signatures - so we do a raw copy

20091007 18:06:18.498 1852 MEET 1804 Meet::InstallStep Done installing file updateName:install.wim uid:{7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v137 gvsn:{7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v246 connId:{D3F93FEA-BF07-4CEF-8E4E-E82564BE2E7B} csName:RemoteInstall ß B has the new file. Took about 6 seconds on a fast network so this would be much slower on most WAN's. And since the file was never that big anyways, probably acceptable behavior.

So there it is. If you’re using WDS and DFSR and your servers are not connected purely by gigabit end-to-end, modifying your images and letting DFSR take care of the modification can save big time and bandwidth. And that is something you can put towards your bottom line with more productive users who can use more of that WAN for other things.