Solved Weird DFS issue
-
Hi all,
I have a weird issue.
I have a windows 2008 R2 server as AD and using DFS for user shares. The files are on a Netapp on the same location. All users have a dfs namespace created and added the shares on to their namespaces. Their namespace is added on to their user profile and AD and when a user logs in from their pcs, gets a mapped drive with access to their corresponding shares. Users from our branch offices in India used to access the same via ftp using their AD credentials.
We got aquired by a different company and we were migrated to thier MPLS connection and as part of their IT policy, FTP is not allowed. The next option for me was to use the server as mapped drive (\serverip\sharename). One of our remote user who is in the same country connected using checkpoint vpn and accessing the server without issues.
Now from India anyone trying to access the server, gets the list of all shares and when try to access their folder, windows gives an error "Windows cannot access \ipaddress\sharename. Error code: 0x8004005.
I created a regular share on the server and given access to a user, and user from india was able to access that. But when accessing the dfs share we get this error. But the same user access works from my main office LAN. We are able to ping and traceroute the main office IP from India without issues, access a simple shared drive without issues. Have you guys come across such an issue? Seems like users accessing DFS is the issue, but other user using vpn able to access the same confuse me.
Please help
-
Sorted! Installed and additional DC in the branch office, within few minutes all objects from main office synced to branch office server, added machines to that domain with the local server IP as DNS and boom!
All working fine, users when logs in gets the mapped drive automatically mounted from the DFS. Changing the subject to "Solved" might be helpful for someone some day!
Thanks guys. -
No AD experts here? Would be a great help if someone can advice me on this. Still looking at various options available on internet, so far without much luck!
-
AD yes. Not many DFS people though, I don't think.
-
Is there any way I could test the complete communication between the client machine to server communication. Just wanted to make sure there are no network level blocks on anything.
-
One thing I found from spiceworks,
To allow the Microsoft machines at the remote site to join the HQ domain, transfer files, and process DFS, you'll need to let the proper traffic through. Here's the list of ports that I allow out and in both ends. (Each port generates 4 firewall rules, 2 in each router, like the DNS entry above):Active Directory Trust Policy TCP - Port 49155
Active Directory Trust Policy TCP - Port 49158
CFS TCP and UDP - Port 455
Kerberos TCP - Port 88
LDAP TCP and UDP - Port 389
LDAP SSL TCP - Port 636
Microsoft DFS TCP - Port 5722
Microsoft DFSR TCP - Port 49154
Netbios TCP and UDP - Port 135
Netbios TCP - Port 139
Netbios TCP - Port 138
NTP TCP and UDP - Port 123Informed the networking team to check this and I hope its just the ports getting blocked!
-
Figured it out. The machines in India are on workgroup and workgroup machines has limitation on accessing DFS shared even if we authenticate by the domain user. Joined one of the users computer to our main office Domain and all works well. Installing an additional DC in India office and joining all users on to that domain and all should work. Will post the results
-
Nice find.
-
Awesome.
-
Sorted! Installed and additional DC in the branch office, within few minutes all objects from main office synced to branch office server, added machines to that domain with the local server IP as DNS and boom!
All working fine, users when logs in gets the mapped drive automatically mounted from the DFS. Changing the subject to "Solved" might be helpful for someone some day!
Thanks guys. -
Glad that you got it all sorted.
