An Intranet DNS Question
Ok, so I've got a topic to start here -- Never seen this before, but I'm sure one of you guys will have a simple answer for it.
So I'm gonna give BS names to everything. Let's see we're in LAN domain.com, and server1 is the DC while server2 is the file server.
So if I need to map a drive to user_share folder, I'm going to map a drive to \\server2\user_share. That's the way I've always seen it done. So far, very basic here.
So at the new place I'm working, I've encountered a method I've never seen before nor knew was possible:
Here, if I want to access \\server2\user_share, I actually map a drive to \\domain.com\user_share, and it maps to the exact same location.
So my question is this: If DNS resolves the domain to the DC, so that when I ping domain.com it returns with the IP address of the DC, how is it DNS is allowing me to get to the file server by going to \\domain.com\user_share? How is that not resolving to server1 instead?
It IS resolving to server1... server1 is just pointing the client to server2
Well, it isn't necessarily pointing to server1... it is pointing to any domain controller closest to them (their site or subnet). You can have domain.com point to any number of domain controllers. If you do a nslookup on your domain.com, you'll see all the DCs that can be resolved.
This can happen if you have a distributed file system implemented. It is useful for several reasons. You have one place to publish all your shares. If you have several sites and you want to replicate data to the file servers at your branch locations, DFS will do that too.
Say you want to move to a new file server but don't want to go and change all your logon scripts or mappings... DFS will do that. You simply add a new replica, wait for the data to replicate and remove the other server.
Or, say your file server runs out of room and you want to add another. Instead of confusing your users and telling them to go to a different server, nothing changes... you can just move data to another server or create new shares on the new server and publish them. The users won't even notice.
Read more about it @ http://www.windowsnetworking.com/art...le-System.html
I use it in my domain to push out files to branch office file servers. So, I have to manage one distribution point and not a dozen or more. It is helpful for storing software to deploy via AD group policy too. The machines will connect to the DFS server closest to them (their subnet or site) and not saturate the WAN links trying to all download from one server.
Oh, another great reason to use DFS... Say you have a bunch of branch offices that you want to backup on a regular basis. You don't necessarily want to do full backups over the WAN nor do you want to deploy backup servers, tape drives and etc. to each branch office. So, you just have those branch offices replicate their data to some file server that has enough space. Then you just backup that data. If you loose the branch server or someone deletes data, etc... just restore to the server closest to you and wait for it to replicate back out to the branch. That's saved us a couple of times when users accidentally delete data. It also saves their job... ;) lol In this case, it is very important to implement quotas on the users drives. Otherwise, if they were to copy a couple gigs of data at a time or a dvd image, etc... your WAN is going to be hurting while the data tries to replicate.