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 ins
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.