Install Dfsutil Windows 7
I am looking at finding a third party application that can mimic this funtionality on Windows 7. DFS on Windows 7. Service where I can practice installing.
Hi Guys, I've got an odd issue with DFS I'm hoping someone can help with. I have a DFS root called ' Domain SharedFiles' which contains around 15 shares from various locations, but mostly from my main File Server. It seems some of our Windows 7 64bit machines randomly loose the shares in the DFS root, and browsing to Domain SharedFiles shows an empty folder.
Sometimes the shares reappear with a PC restart, other times they wait a little while and then reappear on their own. I've also seemed to be able to get them back with an 'Ipconfig/registerdns', although that may be coincidence. I created a test root called ' Domain SharedFilesTest' and added a couple of the same shares to it, and they don't seem to disappear or have problems accessing them. I have 4 2008R2 DC servers hosting the root, and also one 32bit 2008 File Server hosting the root, but that server status is Disabled (which can only be seen in the DFS Management on the 2008R2 it seems. I've got a few other DFS roots to, and they seem ok.
This problematic one has been around since day one on our old 2003 server, while the others were created on the 2008R2 servers if that's of any significance. Anyone any ideas on how to stop these disappearing?
As we have software that references Domain SharedFiles and also mapped drives to the same place, it's stopping people working when the shared disappear. I'll have a loot at that thread. When the shares disappear from the DFS root, I can still browse direct to any of the missing shared using ServerName ShareName and don't get any errors.
Odd that it's only this one out of 4 dfs roots having a problem. We never had any issues with Windows XP, only on Win7 64bit. DHCP Lease is set to 1 day (24 hours).
Set to 'update DNS A and PTR records only if requested by the DHCP clients.' Set to 'Discard A and PTR records when lease is deleted'. DHCP server's computer account is a member of 'DNS-Admins' group.
DNS Server Aging/Scavenging no-refresh and refresh properties are set to the 7 and 7 at the DNS server level. Zone 'no-refresh' and 'refresh' are 6 days, but not enabled. I've got 80 ip's spare so could increase the lease a little as doubt I need it as low as 1 day. Although I don't fully understand how the scavenging works. I seem to recall changing from 'Always update' to 'Only if requested' for some reason a while ago; possibly when I last visited this DFS problem. I think that's when I added the DHCP server's computer account to the DNS-Admin group too.
I've changed it back to 'always update, and will see what effect that has I'm right in thinking this will make the DHCP server register the DNS record for the client PC? That thread seems to mention dropping the scavenging down from the default to help avoid duplicate IP's.
I have noticed a couple of duplicate DNS records for some client PC's, but there's no duplicates for the few clients that had issues with the shares disappearing today. (which prompted me to look into this again). I've also increased the IP lease to 3 days too, so they keep the IP longer. Jma89.tk wrote: Just a sanity check: Open command prompt and do an nslookup against your domain. Make sure that every IP (ie: host) returned is also set as a root for that DFS. NSlookup for Domain.net returns IP's for all the servers that host the DFS roots, except the Fileserver (which isn't a DC).
It also returns an additional IP address of one of my remote DC's that I don't need or have DFS hosted on. Do I need to have everyone as a DFS host?
I doubt any of my clients will ever be in that site with that domain controller or ever access DFS from there. Also the IP of the file server isn't in the list either, which is a DFS host. But which is disabled for this particular problematic SharedFiles root, and enabled for the SharedFilesTest root. Think of the operation in layers: Windows sees a name (domain.net) and thinks of it (initially) as a host. It'll do a DNS lookup and might get any of the IPs (unless you've configured DNS to be site-aware, but that's a different topic.) Therefore you should add every DC as a root host for all domain-based DFS roots. Note that you can have more servers set as roots, but all of your DCs MUST be roots to avoid any funky behavior later. After that initial referral DFS will kick in and your clients should all be talking to the nearest servers.
Dfsutil Remove Namespace Server
Quick test on that DNS being site-aware bit: Do an nslookup against your domain repetitively and see if the list of IPs fully rotates or if just the nearest server(s) stay on top. If the whole list rotates through then you'll definitely need to configure that remote DC to be a root, and then turn your attention towards configuring AD Sites and Services followed by making DNS site-aware. More info here. All status check's come back as ok on the DFS tab. When I've checked the DFS tab on the root on client machines, they always seem to be connected to the same local DC, which is our main DHCP DC.
Windows 7 Update
I've never seen it, or remember it, being connected to the other local DC unless I change it. On one of the clients that had a problem today I tried swapping the active server, and after a little while the shares did reappear. Although I can't tell if that sorted it as sometimes the shares reappear on their own. In fact, I think they always reappear on their own, however as all our clients map drives to a share that's disappearing in the DFS root, it just depends how long the client is willing to wait for their mapped drive to come back before shouting for us.
Tstoner wrote: I have run into a similar issue in the past. In our case the DFS shares were being created by group policy. Sometimes the group policy would take to long to load and the shares would not get created.
Dfs Tools Windows 7
If this is how your creating the DFS shares on the client you may want to take a look at one of the offending machines and see if that part of group policy is being applied before log on. Our shares are usually created manually using 'right click properties share tab' of a folder, on the 32bit 2008 server. Then manually added to DFS in DFS management. When they aren't accessible in the Domain.net SharedFiles DFS root, I can still browse to the relevant servername share and access them fine that way. The only group policy we have I can think that may be relevant, is one that maps an S drive to Domain.net SharedFiles, and maps an N drive to Domain SharedFiles Files. Naturally neither of these mapped drives work when I'm having the problem, but direct to servername Files does.
Yeah, there is a share Domain.net SharedFiles HomeFolders, and when the shares aren't available, HomeFolders is all that's available.so think that is available offline. At the same time as the shared folder Domain.net SharedFiles Files randomly isn't available, the same 'Files' share can be reached from a new test DFS root I created Domain.net SharedFilesTest Files. This also isn't every day, maybe a couple of times a week, and typically for a couple of users at a time. It's just enough to annoy them when it happens. I'm thinking of maybe changing their mapped drives back to servername share, but we've got quite a few things referencing shares in Domain.net SharedFiles. Check to see if offline files has kicked in - Using DFS with offline files gets funny when Windows detects a server as being offline, even it just for a 'slow connection'.
(In fact, I just had an issue like that this morning. Wired into the network but he had been in a meeting and best I can tell Windows tried doing a test while he was walking and it got very angry.) If you pull up that HomeFolders folder look for a 'Work Online' button at the top of the window, and the offline status at the bottom of the window. I'll have a look and see the next time someone reports the contents of the drive have disappeared again. Our group policy is set to redirect users desktop and Documents etc to their homefolder in the DFS share. We've also got the policy for 'Do not automatically make redirected folders available offline' enabled which I'd have thought wouldn't make it offline.
I've also recreated the whole structure in a new test DFS root and will see if that's available and compare the next time the problem surfaces.