Microsoft (spit) / Services / RPC / Domain Policies

Re: I don't know

My argument exactly, however, when you have an application that have been around for a decade and is used on a number of sites then you have little choice.

Of course, life would be even easier if Microsoft had zero involvement. Smell that coffee.

I don't know

Microsoft brings the world the perfection that is the .NET framework, with remoting over tcp/ip or http,web services, ability to create and deploy windows services, multithreading and thread pools, code access security, automatic garbage collection, type safe pointers, delegates, enterprise services with just in time activation, com callable wrappers, object pooling, two-phase transaction co-ordinator, xcopy deployment.....


And still people piss about with C, low level Windows API's and other arcane 20th century techniques.

:rolleyes

Obviously a Grade B question.

Been a while since I had to dirty my hands inside some Microsoft code and I've forgotten how grubby you can get.

Anyway, I need some pointers and hoped someone on here might be able to help out.

We have a server that is run as a service and our client code (packaged as a lib and dll) uses rpc (ncalrpc driver) as the means of communicating with the server.

Now, here at S........ we are domain users and we don't have any problems installing and running the service and clients in the same domain account.

Unfortunately, we have a customer, also using domain accounts, who can install and run the service but the clients fail to bind to the rpc endpoint.

Have run rpcdump and the endpoint is there on the customer's system. From the code, it looks as though the clients are failing to find the endpoint via the RpcNsBindingImportNext() call.

Is this likely to be a domain setup problem, security issue .....????

Any pointers, good Microsoft (spit) forum etc would be appreciate.