How about using domain-based DFS?
Please could I have some advise on the best way to map network shares at multiple sites.
At the moment I am using Group Policy Preferences to map the network shares for each site. I have applied the policy at the "site" level. In the policy I have set a "delete" as first in the order. I was hoping this would delete the shares when the user is no longer in that site. However when a user goes home and logs onto the laptop they experience a long delay whilst logging on.
Is it best to just have one policy for mapping drives and apply it at an OU level using item level targeting to set the IP range for it to apply?
How about using domain-based DFS?
Please could you expand on this?
Sorry, don't know if this has changed in WS2008, other than knowing that there may be a problem with mixed WS2003/2008 networks.
The basic idea is that you can use Distributed File System to maintain multiple copies of shares on different servers. Set up the shares as normal on each server, with a master copy of each one on a specific server. Say, for example, the share was called HOME$ and you wanted it available on SERVER1, SERVER2 and SERVER3 on 3 different sites. Create \\SERVER1\HOME$, \\SERVER2\HOME$ and \\SERVER3\HOME$. Ensure an up-to-date copy is on one of the servers, say SERVER1 for example.
Then, in DFS, create a new domain-based DFS root, identify \\SERVER1\HOME$ as the master copy, and the others as replicas, and Windows should use FRS to replicate the files to all 3 servers and keep them updated. If big shares best to kick this off on a Friday afternoon!
Once this is done, you can map to the share based on the domain name rather than any particular server, say for example \\curric.myschool.local\HOME$. As long as you have configured your sites and subnets properly in AD, the DFS client should identify the server best placed to provide the share and connect to that.
But the problem he has is when users are away from the network so I can't see how this helps.
I don't see this from the OP. Surely the issue is about mapping to the shares that are available on the local servers at whatever site the user is on. By making all shares available regardless of site, and ensuring the client maps to the share on a server on the same site, isn't the problem solved? (apart from the FRS traffic over the WAN, of course!)
Thank you for your input Waldronm2000. However I think Ben may be correct.
The problem I am having is relating to when the users have been on a site and then take their laptops home. I have done some testing and the logon delay is solved by manually deleting the mapped drives.
As I am using GPP at the site level I don't think the "delete" action comes into effect because the user is not at that site. Would it be better for me to just make one map drive GPO and apply it at an OU level? Instead of having a separate one for each site?
You do not need the Delete map drive as has been pointed out, the policy is not applied on a different site. In my experience, making sure the Reconnect option is not checked should be enough to ensure that the drive is not carried over into another logon session, however, also selecting the 'Remove this item when it is no longer applied' option on the Common tab should also ensure that it is removed.
My understanding was when using GPP for mapping drives you do something like this:
1. Delete all drives
--Item Level Targeting
----Apply if IP Range is NOT in x.x.x.x
--Label: NAS04 - Support (Reconnect is unticked)
--Item level targeting--
----Apply if IP Range IS in x.x.x.x
and so on for the rest of the drives.
I have 5 of these policy. One for each of my site. When a user goes to "Site A" they get the drives mapped for that site. This works great when the user is within our network but the problem happens when they are not on site, eg, when they are at home.
When the user is at home the laptop seems to be trying to locate the mapped drives because the "delete action" is not applied when they are at home because they are not in the site. This is what I think is happen. However when you manually delete the mapped drives at home the laptop can log on normally within a few seconds.
In my experience, mapped drives to servers which don't exist haven't caused problems like this, even with Reconnect enabled. However, I would combine the policies into one, changed the "Delete All" one to have no Item level targeting and then the individual drives with the appropriate settings and item level targeting on the off chance that the Delete All is getting confused about whether it should apply or not.
Other than that, if you want a work-around, make a log off script which removes all mapped drives.
How do you map your network share is it via GPP or scripts?
We used GPP. Some of the drives have item level targeting for different OUs but the policies don't have a delete set up to remove the drives since the drives don't change like yours do, however, the laptop users who work from home have never reported any issues with mapped drives or slow logins. We used to use scripts, which works just as well and are easier to customise if you're familiar with vbscript, we just moved it to GPP just to keep everything together.
Just to confirm, do you think the best way for me to map the drives is with one GPO which has "delete all" as number one and then the rest of the drives with Item Level targeting. Also, should this be applied at an OU level rather then a site level?
That's how I would do it at any rate, it worth a try. As for where to apply it, it doesn't really matter I guess, apply it at the highest level to encompass all the computers you want affected, I guess in this case, the OU which contains all of your "sites". Don't link it in each site, there's no need.
SteveAllen (5th May 2011)
There are currently 1 users browsing this thread. (0 members and 1 guests)