gvmdevelopment
asked on
Windows Service cannot access Shared Drive
Hi,
I have a windows console app that accesses files on a mapped shared drive under a domain account on Windows XP. Now this console app is being called by a Windows Service and the shared drive is no longer accessible by the console app. "Allow service to interact with desktop" does not work because only the domain account has access to the shared drive and not the local system account. I have the source code for both the console app as well as the Windows Service. Is there a way I can make the service see the shared drive?
I have a windows console app that accesses files on a mapped shared drive under a domain account on Windows XP. Now this console app is being called by a Windows Service and the shared drive is no longer accessible by the console app. "Allow service to interact with desktop" does not work because only the domain account has access to the shared drive and not the local system account. I have the source code for both the console app as well as the Windows Service. Is there a way I can make the service see the shared drive?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Ah; wrong problem. . . So, can you not simply map the drive when the user logs on, so that's it's premapped for the service account? Or will that create either security issues with having a user map the drive, or timing issues with when the app is designed to run?
ASKER
So what you are saying is when the service starts it should map the drive using "net use f: \\Server\drive" so that when the app is called the mapping is already there?
Since there are other things using the same mapped drive, it might already exist, does re-mapping the same drive letter cause any problems to things that are using the drive at that point in time? timing should not be an issue if the mapping is done only once, at service startup...
Since there are other things using the same mapped drive, it might already exist, does re-mapping the same drive letter cause any problems to things that are using the drive at that point in time? timing should not be an issue if the mapping is done only once, at service startup...
What I was really doing was just asking if that approach would work. But I think I'm assuming too much, as I seem to be having trouble getting a handle on the problem. . .
Is the problem: A) you just need to make sure the network drive gets mapped, so that the application can access it? In other words, does the app work if you manually map the network drive?
or B) the network drive is mapped, but it still doesn't work?
or C) something else?
When it comes to network drive mapping, it really doesn't matter who maps the drive, or when it was mapped, as long as it's there when you need it. Typically, network drives are mapped as part of the user login, using a login script or whatever. That gives each user on a given system the drives they need. If your app, whatever it is, is only run while a user is logged on, that would take care of problem A. If you need the app to run when no user is logged on, though, you'd have to do something else, like wrap the net use commands around the app call, in service startup parameters, a custom script, or what have you.
You asked about issuing 'net use' when the drive is already mapped; if the drive is already mapped, you don't need to remap it just for the app, although you can try, and it won't hurt anything. It can use the existing mapping, except in a case where the security credentials aren't correct. For example, is user John Doe is logged onto the system, and has \\server\drive mapped for him by a login script so he can access documents on \drive; but the app we're talking about needs to access \\server\drive\directory, which John Doe doesn't have access to, then the app won't be able to use the mapping established under John Doe's credentials, because it won't be able to access \directory, just the top-level \drive. Note that if you did have an issue with credentials, any net use you issue when the service starts will not have any effect if the drive is already mapped under the user's credentials with the same; you'd have to net use /disconnect the existing mapping, then remap under the service account in that case. You can, however, map the same network location more than once under different drive letters, and you could create each mapping with different security credentials, if you needed or wanted to.
As to the service account; just to be clear, I'm not talking about the account you are logged on with when you install the application - that has nothing to do with it. I'm talking about the account under which context the windows service, and thus the app it calls, is set to run. That is set on the Logon tab of the Service propery page. You've only got two basic options; either 'Local System Account', which is fine for most services that don't require network access, or 'This Account', which can be any account you want, depending on what on your network that service needs to access.
You referenced the 'Allow the service to interact with the desktop' in your first post, which is only an option if the service is running under the Local System Account. If you're doing that, you won't have access to any network drives, mapped or not; you need to specify an account for the service to run under, using the 'This account' option. That can be your domain admin account, although I wouldn't recommend it, or an account in your domain setup specifically for your app to use. Whatever account you choose, it needs access rights to the network drive in question. That may be the solution if the problem is B.
I really think we ran into problems when I misread your first Author Comment. I thought you'd already done what I suggested, using the domain admin account. Rereading it and your initial question now, I wonder if I wasn't on the right track to begin with. Read through the two paragraphs above, and tell me if we're on the same page yet. . . .
Is the problem: A) you just need to make sure the network drive gets mapped, so that the application can access it? In other words, does the app work if you manually map the network drive?
or B) the network drive is mapped, but it still doesn't work?
or C) something else?
When it comes to network drive mapping, it really doesn't matter who maps the drive, or when it was mapped, as long as it's there when you need it. Typically, network drives are mapped as part of the user login, using a login script or whatever. That gives each user on a given system the drives they need. If your app, whatever it is, is only run while a user is logged on, that would take care of problem A. If you need the app to run when no user is logged on, though, you'd have to do something else, like wrap the net use commands around the app call, in service startup parameters, a custom script, or what have you.
You asked about issuing 'net use' when the drive is already mapped; if the drive is already mapped, you don't need to remap it just for the app, although you can try, and it won't hurt anything. It can use the existing mapping, except in a case where the security credentials aren't correct. For example, is user John Doe is logged onto the system, and has \\server\drive mapped for him by a login script so he can access documents on \drive; but the app we're talking about needs to access \\server\drive\directory, which John Doe doesn't have access to, then the app won't be able to use the mapping established under John Doe's credentials, because it won't be able to access \directory, just the top-level \drive. Note that if you did have an issue with credentials, any net use you issue when the service starts will not have any effect if the drive is already mapped under the user's credentials with the same; you'd have to net use /disconnect the existing mapping, then remap under the service account in that case. You can, however, map the same network location more than once under different drive letters, and you could create each mapping with different security credentials, if you needed or wanted to.
As to the service account; just to be clear, I'm not talking about the account you are logged on with when you install the application - that has nothing to do with it. I'm talking about the account under which context the windows service, and thus the app it calls, is set to run. That is set on the Logon tab of the Service propery page. You've only got two basic options; either 'Local System Account', which is fine for most services that don't require network access, or 'This Account', which can be any account you want, depending on what on your network that service needs to access.
You referenced the 'Allow the service to interact with the desktop' in your first post, which is only an option if the service is running under the Local System Account. If you're doing that, you won't have access to any network drives, mapped or not; you need to specify an account for the service to run under, using the 'This account' option. That can be your domain admin account, although I wouldn't recommend it, or an account in your domain setup specifically for your app to use. Whatever account you choose, it needs access rights to the network drive in question. That may be the solution if the problem is B.
I really think we ran into problems when I misread your first Author Comment. I thought you'd already done what I suggested, using the domain admin account. Rereading it and your initial question now, I wonder if I wasn't on the right track to begin with. Read through the two paragraphs above, and tell me if we're on the same page yet. . . .
ASKER
The problem is closest to (B). When I am logged on using that domain account , the drive mapping is there, but the console app still cannot access it when called by the Windows service. The console app CAN access it when run standalone (without being called by the Windows Service).
Okay, so how's the Windows service that calls the app configured to log on? 'Local System' or a domain account?
ASKER
domain account
Hm. Sounds more and more like it's a problem at the code level, which you probably already suspect. Not my area of expertise. And judging from the lack of other replies here, I'd suggest trying it in one of the programming topic areas, where the people who know their stuff w/ API's and C# hang out. . . . :-) Sorry I can't be of more help.
ASKER
thanks for your suggestions. However, I ended up using the UNC notation (\\Server\Share) directly, and it seems to work fine without any degradation in performance.
ASKER
I am currently using the domain Administrator account. How is that different from a "service" account you are talking about
>Give it rights to the network share, and set the Windows service that's running the console app to logon with that account. . . .
The account I mentioned above has full acces to the share. And I am installing the service using the same account. The question is : How will the service see that mapping when the above account has not logged on yet ? because the mapping is done when the user logs on...