Problem accessing network drives from service

[jboothco]

We have developed an app that may be run as a classic application or installed as a service. It is written in a mixture of C# and VB using VS2005. As an app, it has no problems using a mapped netword drive. When we install it as a service it no longer "sees" the mapped drives. We have attempted to change the login setup for the service, but that didn't help at all. Obviously, the scope of the program is different when running as a service, but we are not sure what is going on or how to program around it. How do we access mapped drives from within a service?

Thanks in advance to anyone who can help!

John

 

[Gill Bates]

Try referencing the network path instead:

\\machine\this\is\my\dir

or

\\192.168.0.155\this\is\my\dir

 

[jboothco]

Try referencing the network path instead:

\\machine\this\is\my\dir

or

\\192.168.0.155\this\is\my\dir

This seems to have helped as I have been able to get access now. The only remaining issue is that the only way for the access to work is to modify the Logon property for the service to be the logon for a valid user. We have the service set as a network type with no specified userID or password. When it is installed the logon property defaults to "NT AUTHORITY\NetworkService" with some unknown password. This entry is not able to access the network paths and I have to substitute my own logon parameters.

Is there any way for this service to inherit the logon for the current user of the computer or the logon for the user that was in effect when the service was installed?

Thanks!

 

[PlausiblyDamp]

A windows box can have more than one current user or no current user at all so the idea of using the logon credentials of the current user doesn't really make sense.

If you wish to run only when a user is physically logged onto a given PC then you could just run the app as a background process that starts automatically when they logon.

If you wish it to run all the time regardless of who may be physically logged in to the local machine (could be zero users, could be multiple if fast user switching is enabled) then it will need it's own security credentials. Best practice is to create a user account on the network specifically for this service and then get the service to run under those credentials.
This is better than using an existing account as you will encounter problems if you ever change you password, change group membership or the account is ever deleted / locked out.

 

[jboothco]

A windows box can have more than one current user or no current user at all so the idea of using the logon credentials of the current user doesn't really make sense.

If you wish to run only when a user is physically logged onto a given PC then you could just run the app as a background process that starts automatically when they logon.

If you wish it to run all the time regardless of who may be physically logged in to the local machine (could be zero users, could be multiple if fast user switching is enabled) then it will need it's own security credentials. Best practice is to create a user account on the network specifically for this service and then get the service to run under those credentials.
This is better than using an existing account as you will encounter problems if you ever change you password, change group membership or the account is ever deleted / locked out.

As I mentioned previously, this is a service so it is to be run continuously. The computer it is running on is used as an order entry kiosk so there is typically just a single logon used that is left running all the time, as long as the computer has not been rebooted for some reason. The logon credentials for this service are only necessary for the connectivity between this computer and 2 other computers, this computer being the "middle man" handling the transfer of data between these other computers which do not have direct access to each other. Only our computer has access to both networks so we are providing a secondary feature from this vantage point that cannot be done easily otherwise. Since a service may not have more than one logon (as far as I can tell), then your suggestion of creating a unique user account that is the same in both domains I am accessing would be a viable solution. I just wish it was simpler, but that is the price of security. Thanks for your input!