When DFS goes wrong…

(Also posted in this month’s TrueSec.com newsletter!)
A while back I consulted with the IT department at a large computer hardare company (well known in the computer graphics business). Josh, their MDT Administrator, asked recently for debugging help with MDT and DFS shares.

System Center Configuration Manager has an excellent system to replicate content out to remote distribution points. MDT LiteTouch, however, has nothing built in, instead you can use DFS-R do the replication out to remote DFS leaf nodes. Many years ago I worked on a deployment project that relied on DFS, and it was a nightmare. The DFS links were complex and setup by hand (not DFS-R), not all sites received the same content (by design), or sometimes sites got content very slowly, like a week later. I spent a lot of time trying to debug DFS replication issues.

From the client’s point of view, it’s hard to tell where the DFS share actually points. When DFS is working, this is great, end users don’t need to know where their requests are actually going. But if you wanted to check, one way is to use Windows Explorer to select a folder on a DFS Share, Right click and select “Properties”, there should be a “DFS” tab showing each DFS leaf, and the status of which DFS server is active.


My friend Josh asked about adding a script to dump the DFS status for each client into the bdd.log during LiteTouch deployment. If there was an error in the deployment he could use this information to track down the real DFS Leaf Node server and verify that the content got replicated correctly. I had developed a tool a while back that helped dump DFS information on the client side, but it was written in C/C++, and I thought this was a great opportunity to experiment with PInvoke and calling .net Classes from Powershell.

I knew from my previous coding experience that the trick to getting DFS info on the client was using the Win32 API call NetDfsGetClientInfo(). This API call can’t be made directly from PowerShell, instead we need to use some conversions in order to make the call. I went to the excellent http://PInvoke.net site to create a C#/.net program to make the call and return a native .net framework structures. I could then use PowerShell to compile the C# code, and make the call call to .NET. PowerShell does a great job of parsing the returned structures, and makes it appear that the results were native PowerShell objects.


With the powershell script, it’s just a matter of adding this script to our task sequence. If you have added powershell to WinPE, you can try this during the “pre-install” phase of the Task Sequence, but in this case, I put the script at the start of the “State Restore” phase.


When done I could see in my BDD.log file the results of the script and which active DFS Leaf node was active.

Code attached get-DFSLinkStatus.ps1

Hope you find this helpful.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s