Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I would like to have some feedback about the best practices you use to publish your network share.

Now, we have on our file server :

  • one named directory for each of our user, which is backed up daily
  • one named directory for each service, backed up daily too

To publish these shares easily, we use a script which runs when the windows session is opened and which maps a letter to this share, here it is :

Net use * /delete /yes

The problems with this are:

  • Our laptop users can log on without being on the network, so when they connect to the network, they don't have their network shares
  • If the server goes down, our users needs to reopen their windows sessions to get their network shares

How do you manage this in your organizations ? Don't hesitate to share your technical solutions and organizationals too !

Thanks very much,

share|improve this question
Mapping network shares? Publishing and mapping network shares are two different things. – HopelessN00b Feb 5 '14 at 11:04
up vote 0 down vote accepted

We use a combination of methods.

Application Storage: Like Safado we use AD Group Policy to map drives though we typically use this just for specific application storage. If a user is a member of a specific security group in AD the Group Policy applies and a drive is mapped. Security filtering is used to ensure that the specific Group Policy only applies to members of a certain security group even though the Group Policy itself is linked at the domain level. This is how we get around constraints of the the OU structure not necessarily matching up with who needs the mapped drive. Of course a corresponding Discretionary Access Control List (DACL) is used on the share itself to ensure that only members of the group have access permissions.

User Files: A single share is created on DCs and read only access to the share is given to all Authenticated Users. Inside of the share a folder is created with the same name as each person's username and the user's account is the only one given access (read, write, execute) to the folder. Access Based Enumeration is turned on for the share and as such other users cannot see the folders of other users regardless of being allowed read access to the main shared folder. The user profile section in AD contains settings to allow a single mapped drive and we use this for user files only. The %username% macro can be used in these boxes and as the macro implies it is replaced with the actual username at login, resulting in a mapped drive with contents specific to that user.

Fault Tolerance: In the event that the mapped drives need to be a bit more fault tolerant and handle the loss or disconnect of one (or more) DCs you can use DFSR (Distributed File System Replication). For example a DFS Namespace could be created on three DCs and the DFS Namespace UNC path could be used in the Group Policy or AD user profile. This would result in a setup where files are accessible even if a DC goes down and furthermore would allow for the system to act like a CDN if you have DCs in other geographical locations that is a member of the DFS Namespace.

Like Safado said the shares will show up with a red X if they cannot connect just double-clicking on the share once the server is online will allow access.

Note: I couldn't post a link to the MS page for DFSR due to reputation being below 10 :-(

Edit: Linking a ton of GPO objects to the top of the domain level is not exactly a great idea. A well thought out OU structure may allow you to link the drive mapping GPO object to an OU which contains only the users which need to mount the share. In such case there is no need to use the nuance of security filtering as the inheritance structure of your OUs already handles this. Of course this isn't always the case...for example when dealing with a client's AD domain that has been poorly managed :P.

share|improve this answer

We use a GPO (User>Preferences>Windows Settings>Drive Maps) to map the drives for the user's personal share and their department share. We mark it to Reconnect after a reboot, so even if they boot their computer up while off the network, the share is still listed, but with a red X. Then when they get back on the network, they just click the share and it'll reconnect.

share|improve this answer
Will it remount network share in case of network connectivity problems? – ahaw Feb 18 '14 at 8:49
I don't know if there's a specific scenario you're trying to get at, but the drive mapping is never "unmounted". My IT share is mapped to S: and that drive mapping is there, whether I'm at work, I'm at home, at the coffee shop, on an airplane.. wherever. In the event of network connectivity problems, it just says it cannot reach the server when I click on it. When I reconnect to the network, it starts working again. If I boot my computer while off the network, the share has a red X. When I connect to the LAN and click on the share, red X goes away and I can access my files. – Safado Feb 18 '14 at 15:04

I had the same issue a few years back : Mounted shares made unavailable as soon as the laptop disconnected from the network.

The user was more than happy when I simply created a shortcut on his Desktop pointing to \\myserver\myshare. It was also much faster for the OS to announce the unreachability of the shares (though I don't have data to back that up). So, a solution would then be to create shortcut on Desktops via a GPO for example.

If you want to keep the mounted share, for you laptop users, you might also modify your login script to check if the server is reachable, in such case don't mount it.

As for the case when the server goes down, it shouldn't be the case in the first place, and especially not when users need the share. If you can planify the server maintenance and maintain high-availability overall, your second scenario wouldn't impact much (any) end-users, thus won't be an issue anymore.

share|improve this answer
GPO is the way to go on this one, either through desktop shortcuts or Mapping drives through GPO. They'll always be there, with or without network access. Now if these laptops are not on the domain, then you'll still need a script for them to fire off at least once. – Lee Harrison Feb 14 '14 at 14:41

I would use a script:

$computer = "SRVFILES01"
$shares = "\\SRVFILES01\MyName ", "\\SRVFILES01\MyService"
$disks = "R:", "S:"
If (Test-Connection -comp $computer -count 1 -quiet) 
    for ($i=0;$i -lt $shares.Count;$i++)
        NET USE $disks.Get($i)  $shares.Get($i) /PERSISTENT:NO
    Net use * /delete /yes

And execute it periodically via "Scheduled Tasks".

You can execute script remotely and modify it without interaction on client PC.

share|improve this answer

We had the same problem with our VPN users.

We mostly use Add a network connection to solve the problem.

Back in the times i used to simply have a bat file sitting in my startup folder with SUBST command to assosiate a path with a drive letter.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.