Service isnt seeing files over the network

I have a simple service that reads directory values from the registry, then locates the file they point to and copies it to the local machine.  The service properly installs and runs on all of the machines that are a part of my office domain.

I am currently trying to get it to work on a computer that is part of the office network, but not joined to the domain.  I can successfully UNC to the directory I want (\\myServer\install$\batchfile.bat is what I'm trying to reach).  I wrote a few lines of code in C# and compiled them; I pulled the registry values to form the path as usual, then used System.IO.File.Exists to check that file - and it can be seen fine!  I used the directory object to check multiple directories and list the files therein - and THAT works fine too.  Its only when I'm attempting to use my service that it checks the exact same file path and says file not found.  It makes no sense.

Furthermore, I tried checking ANY machine that is on the local network.  As long as my service is not trying to do the check, I can UNC to the computers, and I can programmatically check for files or directories... its only when the service is trying to do it that it doesnt work.

In the code section below I listed part of the installation I use.  I've tried using ServiceAccount.NetworkService (shown here) and ServiceAccount.LocalSystem (this is how I installed it on the domain machines, all of which are working properly) and neither one helps.  I would really, really like to avoid having to add all of these machines to the domain.  There is no reason for them to be added, as it would drive our costs way up, but I need this program to work, and work now.  My deadline is almost up and I cannot figure out what is wrong.

Help!
ServiceProcessInstaller serviceProcessInstaller = new ServiceProcessInstaller();
ServiceInstaller serviceInstaller = new ServiceInstaller();
 
// Service Account Information
serviceProcessInstaller.Account = ServiceAccount.NetworkService;
serviceProcessInstaller.Username = null;
serviceProcessInstaller.Password = null;

Open in new window

SkkraAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

ToddBeaulieuCommented:
I suspect you need to specify the credentials to use when accessing a machine not on the domain.

I'm doing this for a current project using PowerShell.

Here are a couple of examples:

<%
option explicit
dim WshNetwork
Set WshNetwork = CreateObject("WScript.Network")
WshNetwork.MapNetworkDrive "K:", "\\serverip\share", "false", "user", "password"
%>

    $net.MapNetworkDrive("x:", "\\server\share", $false, "username", "password")

0
SkkraAuthor Commented:
Maybe I wasn't clear in my original question - the problem is when going FROM a machine not on the domain TO a machine that IS on the domain.  Do you still think its a credentials problem?  My access code simply looks like this:

if (File.Exists(@sMasterServer + @sMasterServerDirectory + @sBatchFile))
        File.Copy(@sMasterServer + @sMasterServerDirectory + @sBatchFile, @sStorageDirectory + @sBatchFile, true);

This same code works perfectly in my little GUI application, where I hit a button to actively check for the existance of the file.  When my installed service does it, however, it fails.

As a final note, the only account on the computer I'm testing this on is an administrative account.  Thanks!!!
0
ToddBeaulieuCommented:
Oh, Sorry. I misunderstood.

I never tried to do that.

I don't think Network Services wil have access to a domain resource.

http://msdn.microsoft.com/en-us/library/ms684272(VS.85).aspx

But, I believe the approach that I mentioned should let you access a domain resource by specifying the desired account to use, including the domain.

Another approach would be to have the service run under a special account that has rights to the shares. This is really the way to go, I think.



0
Powerful Yet Easy-to-Use Network Monitoring

Identify excessive bandwidth utilization or unexpected application traffic with SolarWinds Bandwidth Analyzer Pack.

SkkraAuthor Commented:
// But, I believe the approach that I mentioned should let you access a domain resource by specifying the desired account to use, including the domain.

Another approach would be to have the service run under a special account that has rights to the shares. This is really the way to go, I think. //

Do you know how/where I would use this in C# programmatically for my service?  Would it go in the service installation information?  I'm not sure where else I could put this kind of authentication information, as I'm not ever logging onto a machine exactly... just trying to access it...
0
ToddBeaulieuCommented:
Thinking about going from a non-domain machine to a domain machine is really hard for me, for whatever reason. :)

Ok...

You have this service running on a non-domain machine under Network Services, right?
And you want it to access a share on a domain server.

You mentioned running a test GUI. Form which machine? Which account?

If you use the approach I originally mentioned in the service, regardless of which account it's running under, it could access a domain resource under a specific account, which you could test with your account, but ultimately it should be a domain account used by this service to reach in. At that point, you could probably just have the service run under that account, avoiding the need to provide credentials when accessing the rosource.

So can you create a new domain account that has access to the share(s)? And then configure the service on one of the boxes to use that account, instead of NS? That should solve the problem. As a test, you can use your own account to prove it out.

Finally, I wonder if best practices would dictate this process run the other way around, with the trusted code living inside the domain and reaching out to the non-domain resources?
0
SkkraAuthor Commented:
Let me give it a shot.  I have a meeting this afternoon but I will try it at some point.  Thanks for your help; responses forthcoming.
0
SkkraAuthor Commented:
Sadly, nothing would make this work.  Programmatically, the network would always reject non-domain attempts to access domain resources, even when shares were made available.  I'm going to have to re-code and find another way to do this.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Networking

From novice to tech pro — start learning today.