Getting EndpointNotFoundException with NetNamedPip

I am running a windows service to which I send messages over a NetNamedPipeBinding. The messages are send from a client application which is triggered by a GPO. I just installed the service and client on a new server and I'm getting the following message:

System.ServiceModel.EndpointNotFoundException: 
There was no endpoint listening at 
net.pipe://localhost/VOXAServices/VOXADefaultPipe that could accept the
message. This is often caused by an incorrect address or SOAP action.
See InnerException, if present, for more details.

There is no inner exception. If I run the client application by double-clicking it's icon on the desktop, it runs without a problem. I manage the code for both the windows service and client application, so I can change whatever I need to. But so far, I'm pretty convinced that the binding, contract, and address are all correct (since everything runs fine when run from the desktop). I believe the problem must be with the client app being run from a GPO. But I can't think of any reason why that would cause this error.

UPDATE:

I read this this on Microsoft's website:

A named pipe is an object in the Windows operating system kernel, such as a section of shared memory that processes can use for communication. A named pipe has a name, and can be used for one-way or duplex communication between processes on a single machine.

When communication is required between different WCF applications on a single computer, and you want to prevent any communication from another machine, then use the named pipes transport. An additional restriction is that processes running from Windows Remote Desktop may be restricted to the same Windows Remote Desktop session unless they have elevated privileges.

(Choosing a Transport, Emphasis added)

I need the client process to run in the context of the (unprivileged) user and having a UAC dialog pop up is not an option. Is there anyway for me to give this client process elevated privileges while keeping the process running in the user context and not making the user privileged?

UPDATE #2:

It appears that there is such a thing as global and local (to the windows session) Named Pipes. I believe my windows service is creating a local named pipe and that if I can force it to create a global named pipe, it would solve my problem. (This explains why I couldn't see my pipe in sysinternals "Process Explorer", even though my client app could find it if I launched it from a privileged session). The trouble is, I don't know (and can't seem to find out) how to force a named pipe to be created globally (c#). Any ideas?

The mechanism by which WCF clients find WCF service NetNamedPipe endpoints involves a kernel shared memory object which the service uses to tell clients the actual name of the pipe to be used. If clients are going to be in a different logon session to the server, this shared memory object must be in the Global and not the Local kernel namespace. The named pipes themselves have a single namespace, visible to all clients. You cannot directly control the namespace WCF uses for the shared memory object, but it will be the Global kernel namespace provided that your server is a Windows Service running with SeCreateGlobalPrivilege. Your question seems to imply that this is the case, so I'm sceptical whether your problem is connected with kernel object namespaces.

Two other possible causes are:

The ACLs which protect both the shared memory object and the named pipe. These will always deny access to any security context which has membership of the NETWORK USERS group (SID S-1-5-2). This enforces the WCF guarantee of no remote access to named pipe endpoints.
If you are running on Vista or later, the Mandatory Integrity level of the client process must not be lower than the Mandatory Integrity level of the kernel objects (which will be the implied level - Medium - unless you have taken special steps to elevate using Mandatory Integrity Labels)

I don't know enough about the security context in which your client process started by the GPO would run to advise further, but I suggest you check these two possibilities and post further updates to your question accordingly.