>>>I'm guessing that when you say you're running the service as an Administrator, you mean under a Domain Administrator account on the server. If the client computer is a member of the domain, then the Domain Admin account has full privileges on the client machine, so your code works.
>>>
>>>The "Network Service" account has no privileges on the client machine, which is why you're getting the exception.
>>>
>>>AFAIK you can't assign privileges on a client machine to an account that's local to another i.e. you can't directly assign privileges to \\ServerMachine\Network Service on the \\Client computer. What you can do, which is probably better from a management standpoint is:
>>>
>>>- create a new Domain security group, called e.g. ClientPipeUsers
>>>- add the \\ServerMachine\Network Service account to that group
>>>- give that group privileges on the client computer
>>>
>>>I don't know which privileges you'd need, you'll have to experiment there.
>>
>>To be truthful... I haven't actually deployed it to the server yet, I'm still on the Dev machine. I installed it as a NETWORK SERVICE which works fine for receiving pipe requests, my clients can connect to the server with no problems. It fails with the "Access to the path is denied." when the server tries to connect to the client. I was somewhat anticipating having this problem, that's why I started to test for it on the Dev machine. It works fine if I run it under the localsystem or under my admin account. I'm pretty sure localsystem will begin to fail when I deploy it to the server.
>>
>>Overall I think I like your solution. But I'm thinking it might be even better if I just create a \\ServerMachine\PipeAccount and use that as the login account for this service, then assign that account to the ClientPipeUsers group rather than the \\ServerMachine\Network Service account. That way I don't open up access to the clients for all of the processes that are running in the Network Service account. Seems more secure.
>
>Hmm, if your server can connect to a client while running under a local machine admin account, or LocalSystem, then I don't think the problem (or at least all of it) is the security scenario I outlined. It might be worthwhile looking at the differences between say, LocalSystem and Network Service e.g. http://www.google.com/search?q=localsystem+vs+networkservice

I did the google, and found most of it to be clear as mud.<g>

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

It sounds like NETWORK SERVICE may work when I put it on the domain controller. However it fails on the local machine because NETWORK SERVICE has lower privileges locally than it does on a remote system. (NETWORK SERVICE locally couldn't even write a log file to the HD until I gave it permissions to the folder where I was writing the log file.)

Or at least I think I'm reading that right. (Testing an install will be the true test.)

BTW, thanks for all your help on this.