There is one more approach that can be followed. ![]() To map the drive as persistent as already pointed above. There can be two solutions to this problem. And you might be knowing that the 'SYSTEM' doesn't have rights to access network resources. But, when you install the executable as a service, by default if you see in the task manage it runs under 'SYSTEM' account. ![]() And that user has the privileges to access the network. The reason why you are able to access the drive in when you normally run the executable from command prompt is that when u are executing it as normal exe you are running that application in the User account from which you have logged on. But if you really need access to that share by the drive letter not just UNC, map that share with the different drive letters, e.g. In this case the user doesn't see that annoying "Disconnected network drive. There are 2 connections to the same share. Now the logged user can see and access that mapped drive. Added a logon script (or just add a batch file to the startup folder) with the mapping to the same share with some drive letter: net use Z: \\\. What I did, I didn't map any drive letter in my startup script, just used net use \\\server\share. If your service's 'Log on as: Local System account' it should work. So if you use, for example, a scheduled ntbackuo job, System account must be used in 'Run as'. But if you have only some particular user whose credentials you used in your batch script and this batch script was added to the Startup scripts, only System account will have access to that share not even Administrator. If you have Everyone in the share permissions, this mapped drive will be accessible by other users. If the real service will only work when run as LOCALSYSTEM or somesuch, things get more interesting, as it either won't be able to 'see' the network drive at all, or require some credential juggling to get things to work. If the real service runs under a normal user account, you can run the helper service under that account as well, and all should be OK as long as the account has appropriate access to the network share. Things may get a bit tricky credential-wise. If the real service accepts custom SCM commands, remember to pass those on as well (I don't expect a service that considers UNC paths exotic to use such commands, though.) The helper service will need to pass on all appropriate SCM commands (start/stop, etc.) to the real service. ![]() The only things that are not entirely trivial about this are: The helper process approach can be pretty simple: just create a new service that maps the drive and starts the 'real' service. You'll either need to modify the service, or wrap it inside a helper process: apart from session/drive access issues, persistent drive mappings are only restored on an interactive logon, which services typically don't perform. That's how you can tell this hack is not supported by M$. It may claim to be disconnected but it will work for everyone. NOTE: The newly created mapped drive will now appear for ALL users of this system but they will see it displayed as "Disconnected Network Drive (Z:)". If you need to remove it, follow steps 1 and 2 but change the command on step 3 to net use z: /delete. ![]() WARNING: You can only remove this mapping the same way you created it, from the SYSTEM account. Net use z: \\servername\sharedfolder /persistent:yes The -i is needed because drive mappings need to interact with the userĬreate the persistent mapped drive as the SYSTEM account with the following command You are now inside of a prompt that is nt authority\system and you can prove this by typing whoami. Navigate to the folder containing SysinternalsSuite and execute the following command Open an elevated cmd.exe prompt (Run as administrator) (I have tested it on XP and Server 2008 圆4 R2)įor this hack you will need SysinternalsSuite by Mark Russinovich:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |