Ned here again. Today’s post is a quick technique I use to show how to slap the DFS Management snap-in around when it acts foolishly. Hopefully you find it helpful someday.
Here’s the situation
- There are multiple administrators at your company managing DFSR or DFSN.
- Everyone (naturally) uses the DFS Management snap-in from their own workstation, or from various servers.
- Someone deletes a large number of DFSR Replication Groups or DFSN roots – maybe they are recreating a new topology, working in the lab, or whatever.
So let’s say I had this:
Then I start up DFSMGMT.MSC and now I have this:
No big deal, I’ll just click the refresh button. Wait, where’s the refresh button? No matter, I’ll just press F5, that always refreshes stuff… crud, still there. Ok, I’ll just press CTRL+A and select everything… you have got to be kidding me! Are you saying that I have to right-click every single object node and choose ‘Remove Replication Group from Display’?
A little background
The DFS UI development team writes the DFS Management snap-in for optimal performance. They achieve performance gains by caching new expensive data from LDAP. This optimization prevents the management tool from over utilizing the network with unnecessary queries. The snap-in recognizes when information is new and remembers it. However, the behavior changes when we delete information. The concept of deleting setting in masses in large environments was overlooked.
Never mind that, fix it!
So where’s this cache? Right here:
Open the path listed above. This path expands to a folder within your profile, like this:
You’ll see a file named ‘dfsmgmt’ without a file extension.
Close the DFS Management snap. Then delete or rename the dfsmgmt file. Start the snap-in. Voila. All the extraneous deleted goo, which was removed by someone else, is now gone. You can use the same file and technique to remove large numbers of DFS Roots. We’re looking into getting a darned refresh button added too. 😉
I told you it was quick.
– Ned ‘Hammer Approach’ Pyle