I’ve had a problem with my Windows 2008 R2 server for over a year that I could never figure out. After every reboot (which I only do after a Windows Update), shared folders were no longer available to network clients. My initial workaround was to RDC to the server, right-click on all the folders, and re-share them. But what puzzled me is that the share name I’d used and all the correct sharing permissions were still intact — the properties simply said “Not shared.”
I eventually found a quicker workaround which was to open the Services from the Control Panel and restart the Server service (technically the LanmanServer service).
Thinking about the Server service got me thinking about what might actually be the problem.
Some web searching led me to others with a similar problem of file shares stored on an iSCSI device disappearing after a Windows Server reboot. All my shares resided on a 4TB Drobo array, which was physically connected to my server via FireWire. It wasn’t being seen as an iSCSI disk, but predominant fix I kept reading about for the iSCSI issue was that the Microsoft iSCSI (MSiSCSI) service needed to be up and running before the Server service (LanmanServer) started.
Using this same idea, I first checked to see what the current dependencies were for the Server service by right-clicking it in the Control Panel. I discovered it was dependent on two services already: the Security Accounts Manager and the Server SMB 1.xxx Driver:
To find out the “under the hood” names for those two services that depend on this service (which I call a “child” dependency), you can use the sc command from the command prompt by using the qc (query config) option:
C:\Windows\system32>sc qc LanmanServer [SC] QueryServiceConfig SUCCESS SERVICE_NAME: LanmanServer TYPE : 20 WIN32_SHARE_PROCESS START_TYPE : 2 AUTO_START ERROR_CONTROL : 1 NORMAL BINARY_PATH_NAME : C:\Windows\system32\svchost.exe -k netsvcs LOAD_ORDER_GROUP : TAG : 0 DISPLAY_NAME : Server DEPENDENCIES : SamSS : Srv SERVICE_START_NAME : LocalSystem
Note the SamSS service (Security Accounts Manager) and the Srv service (Server SMB 1.xxx Driver) as the two current dependencies.
Next, I looked through the currently running services on my Windows 2008 R2 box to see if I could find something akin to the iSCSI service that relates to my Drobo, which I could use as another dependency for LanmanServer. I found the DDService service, which is the Drobo Dashboard:
That sounded promising, so I figured it was as good a service as any for a first attempt. I couldn’t see any way via the GUI to add another dependency for the Server service, so I searched for a command line method and found that this is how to make a Windows service dependent on another service from an “elevated” command prompt (warning: read this, but don’t type anything yet).
sc config <child_service> depend= <parent_service>
Armed with this new-found knowledge, I typed the following (again, don’t type this yourself):
C:\Windows\system32>sc config LanmanServer depend= DDService
I got a [SC] ChangeServiceConfigSUCCESS message, so I figured everything was great. I went back to the Control Panel GUI to see if the new dependency appeared in the “This service depends on the following system components:” window.
The good news is that yes, the Drobo Dashboard Service did indeed appear in the parent dependency window. The bad news is that the two previous parent dependencies were missing, and the DDService service was now the only parent dependency.
Doh!
The sc config command doesn’t add to existing dependencies, it sets the dependencies, meaning it will clobber any old dependencies you fail to mention in the command.
Luckily, since I knew the service names of the original dependencies because of the earlier sc qc command, I was able to run a new sc config command that set all three desired dependencies for LanmanServer (this is the one you can use if you’re in the same boat as I was):
C:\Windows\system32>sc config LanmanServer depend= SamSS/Srv/DDService
A quick check of the GUI confirmed it had worked:
I rebooted the server, crossed my fingers, and waited.
When the server came back online, I attempted to connect to a shared folder. It worked!
I don’t know if there’s a better service to use as a parent dependency for the Server service (if you have ideas, please leave them in the comments), but making that service wait for the Drobo Dashboard service before starting seems to be sufficient to allow everything to work as expected.
So if you’re experiencing shared folders on a Drobo not being shared after a Windows server reboot, this fix might also work for you. If it does, let me hear about it in the comments!