We help IT Professionals succeed at work.

Configuring WSUS 3.0 with DFS to use for multiple sites...

PNJIT
PNJIT asked
on
2,863 Views
Last Modified: 2012-05-05
I want to deploy WSUS 3.0 across a few servers. We have external offices that have servers with a slow WAN link -- so I wanted to use DFS to coordinate.

This is the question I have.... let's say I have 3 servers -- A, B, and C -- all in different AD sites and geographic locations.

I set up WSUS 3.0 on Server A, and store all files into \\domainroot\dfsrootname so that all the files are dumped into DFS.

Now how do I set up the downstream servers to take advantage of the DFS root, so that they themselves aren't downloading content? Or... should I just point them to download to the same DFS root? The only reason I ask, is because I don't want them to have problems with downloading the content and then fighting for file access or whatever on the DFS share. I intend to configure replication between Servers A, B, and C so that the files are always local to each server.

Let me know if you have any insight!
Comment
Watch Question

....OK. First of all I don't see that you've made you case yet for needing DFS.  There seems to be a HUGE misunderstanding about WHAT DFS really is, how it works and what it offers.  But I'll get to that in a minute.

Your question:

If Servers B & C, per your plan,  are planning to download the patches from Server A then the slow WAN link will be a factor anyway whether it's DFS trying to replicate (which it is only Rep-ing Metadata anyway,....again, I'll get to that) or WSUS trying to download FROM THE PARENT SERVER.

I would recommend that you config WSUS to have a Parent Server (A) and then to downlevel Servers (B & C) which will look to Server A for their Updates.  THESE you would test-out in the Server A Environment and either approve, or deny.  At which point, it would only be the updates you APPROVE which would then be passed-out to the downlevel Servers.

The alternative to this is to have each site have a stand alone WSUS server which would decentralize management and make GPO usage difficult at best (but I do not know how you've got the Domain(s) set up).

DFS is a means by which to make multiple shares, on different devices, centrally available as though (but not ACTUALLY) via a single share point.  Seven servers, for example, each share-out a folder.  The DFS Root could then be mapped (script, script via GPO, your choice) as....say.... G:.  This mapping would have seven folders available to the user base.  While the users do not know it these reside in different places.

What DFS "Replicates" are each folders' content data, in essence an Table of Contents, NOT actual files/folders.  As changes occur and files are added or deleted Active Directory replicates these changes so that the view from the client's mapped drives also changes.

DFS DOES NOT "MIRROR" your data (a common misconception).

I hope this helps.

Author

Commented:
Actually, I figured out how I can use it... I wasn't clear in my question.

I am going to deploy a single WSUS server on my network. I'll hold all the files in a DFS share, say \\domain\WSUS

I'll set up links to other servers, B, and C so that the data is replicated over to them locally.

This way, when the WSUS server says to install an update, the PC will go to the DFS root and in turn, its local server to get the data, instead of pulling data over the WAN.

Let me know if that sounds right to you.
If you are going to use FRS so that "...the [updates are] replicated over to them locally..." then, yes. But it isn't DFS which will keep the Server's Updates Synchronized on the Remote servers (B & C) that's FRS.

You had a concern about "...with a slow WAN link...".  The time that it is going to take to replicate the downloaded and approved updates using FRS (which does work rather well with DFS) to servers on Site B & C (this, you will schedule for after hours of course) is going to be the same as if WSUS Pushed them out to the clients off hours.

So I guess the question remains: What do you perceive the benefit to be of deploying DFS for this?

Don't get me wrong.  DFS by itself allows a wonderful means of making distributed shares centrally accessible.  In conjunction with FRS, you can use multiple DFS Replicas to maintain copies of your DFS data, again, centrally accessible.

WSUS, as you are installing it, offers you with a number of options in how to approve & deploy Updates.  One of these options is WHEN you want approved updates to be deployed.  My recommendation is to set this time to an off-hour as , unless each site has a dedicated Internet connection (other than the one used for the VPN Tunnel), there is going to be replication over the WAN link either way.  Where WSUS is concerned, the DFS component merely complicates matters.

I AM SORRY....(never let it be said I can't admit when I've done WRONG!)

(More to follow)
This one is on us!
(Get your first solution completely free - no credit card required)
UNLOCK SOLUTION

Author

Commented:
Haha thanks -- I figured it out after I put up the question, but I figured I'd leave it incase I'd get any different information. My computers aren't really put in proper OUs for site location, so in order for me to start figuring it out now, is going to be a very difficult and painful process. The goal was as you said, just to make sure that clients are getting their updates from a local server rather than a remote one (ie, over the WAN). This way all the bandwith is coming from the internal LAN, and the only time it comes over the WAN is when the DFS replicates the information into a local server. Keeps my WAN utilization low, and the LAN gets used in its place to distribute the updates.

Thanks for going through the whole thing and making me more certain this is the way to go! :)
Unlock the solution to this question.
Join our community and discover your potential

Experts Exchange is the only place where you can interact directly with leading experts in the technology field. Become a member today and access the collective knowledge of thousands of technology experts.

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.