Windows: Can I map a network drive for a service account?
772
The title says it all, really.
Is it possible to create a network drive mapping that is visible to a service? Supposing the service runs under a domain account that has permissions to the share, of course.
Open an elevated cmd.exe prompt (Run as administrator). Then, do psexec -i -s cmd.exe. You are now "nt authority\system" :) Now, all you have to do is net use z: \servername\sharedfolder /persistent:yes
Keep in mind if you need to delete the mapped drive you will have to do it in the same way (instead doing net use z: /del).
Persistant drive mappings are only restored during an interactive login, which the service does not use. I believe the only way to get a service to use a network drive is for that service to map the drive itself or alternatively for it to us a UNC path instead of a mapped drive.
Why not? My work does this all the time, although I suspect that your user accounts are probably a bit more restrictive than ours, i.e. you're talking about accounts that don't log into a desktop session.
But...if you do allow the account to log in as a desktop session...
Create the account like you would any other user, and provide a logon script like you would any other user - but it's one that's specifically tailored to that account. Set the machine to auto-logon when powered up, which in turn will run the script, from which the drives are mapped. Simple.
If you're stuck in a situation where it can't, you'll still need a desktop session to do this - so create a simple service account that is separate from the others, one that has the sole task of logging into a server and providing drive access. Lock down that account to just the drive access for security. Your other accounts have their own privs and are not related in this manner. Best of both worlds.
Related to some comments below, this is being done from a perspective of a Windows XP or 2003 setup. Things have changed a bit since then, most people are running Win7 and 2008, both having newer features. The original question didn't specify what environment was being used, so I can only answer for the one I am familiar with.
Also, the entire need-a-GUI thing is really an artifact of how Windows was sold and marketed, circa 1990's. Because of this, it has taken a long time, nearly a decade, for Microsoft to come round and create adequate tools for supporting headless environments (witness PowerShell and 2008 without a GUI). A common occurance at the time was to simply purchase another machine, log it in, run the service, and stick the box in a corner. As a result of this mentality of the time, it wasn't uncommon for out-of-control server growth to occur in back rooms, and as a side-effect, the need for more licensing and seats to be purchased. Over the years, this "organic growth method" of installing more and more servers was curtailed as unit cost, power needs, virtualization, and budget-cutting took their toll. Today, it's merely a faded memory and you really can't find people that remember "the bad old days".
If there is a better solution present for older systems like mine (XP/2003), I'd like to know, it would certainly be valuable info.
P.S. before you heap on unneeded ridicule for running 10 year old software, keep in mind (a) I don't make all of the decisions here (b) I don't sign the checks to fork over for new tech (c) the ERP application at my work might not reliably run on Windows 7 without using the "XP emulation" (i.e. rebadged Virtual PC) extension, and finally (d) my work is very cost-sensitive, so throwing everything out and getting "new and shiny" doesn't make a lot of sense all the time.
Do like this with the psexec utility:
Open an elevated cmd.exe prompt (Run as administrator). Then, do
psexec -i -s cmd.exe. You are now "nt authority\system" :) Now, all you have to do isnet use z: \servername\sharedfolder /persistent:yesKeep in mind if you need to delete the mapped drive you will have to do it in the same way (instead doing
net use z: /del).Persistant drive mappings are only restored during an interactive login, which the service does not use. I believe the only way to get a service to use a network drive is for that service to map the drive itself or alternatively for it to us a UNC path instead of a mapped drive.
Why not? My work does this all the time, although I suspect that your user accounts are probably a bit more restrictive than ours, i.e. you're talking about accounts that don't log into a desktop session.
But...if you do allow the account to log in as a desktop session...
Create the account like you would any other user, and provide a logon script like you would any other user - but it's one that's specifically tailored to that account. Set the machine to auto-logon when powered up, which in turn will run the script, from which the drives are mapped. Simple.
If you're stuck in a situation where it can't, you'll still need a desktop session to do this - so create a simple service account that is separate from the others, one that has the sole task of logging into a server and providing drive access. Lock down that account to just the drive access for security. Your other accounts have their own privs and are not related in this manner. Best of both worlds.
Related to some comments below, this is being done from a perspective of a Windows XP or 2003 setup. Things have changed a bit since then, most people are running Win7 and 2008, both having newer features. The original question didn't specify what environment was being used, so I can only answer for the one I am familiar with.
Also, the entire need-a-GUI thing is really an artifact of how Windows was sold and marketed, circa 1990's. Because of this, it has taken a long time, nearly a decade, for Microsoft to come round and create adequate tools for supporting headless environments (witness PowerShell and 2008 without a GUI). A common occurance at the time was to simply purchase another machine, log it in, run the service, and stick the box in a corner. As a result of this mentality of the time, it wasn't uncommon for out-of-control server growth to occur in back rooms, and as a side-effect, the need for more licensing and seats to be purchased. Over the years, this "organic growth method" of installing more and more servers was curtailed as unit cost, power needs, virtualization, and budget-cutting took their toll. Today, it's merely a faded memory and you really can't find people that remember "the bad old days".
If there is a better solution present for older systems like mine (XP/2003), I'd like to know, it would certainly be valuable info.
P.S. before you heap on unneeded ridicule for running 10 year old software, keep in mind (a) I don't make all of the decisions here (b) I don't sign the checks to fork over for new tech (c) the ERP application at my work might not reliably run on Windows 7 without using the "XP emulation" (i.e. rebadged Virtual PC) extension, and finally (d) my work is very cost-sensitive, so throwing everything out and getting "new and shiny" doesn't make a lot of sense all the time.