1

I need to create a service remotely and would rather not break out to a command and run "sc \remotemachine create ......" and want to do it within the C# code.

However, when running the code even though the sc command works quite happily and thus is managing the remote system the ManagementScope.Connect call is throwing an exception with "The RPC server is unavailable."

A snippet of code that does this is

string machineName = "othermachine";
string path = string.Format(@"\\{0}\root\cimv2", machineName);
ManagementScope scope = new ManagementScope(path);
scope.Connect();

as this is about the first step on the journey I'm a bit stuck as to where to go next. The sc command works, so what is it doing different (other than not using .net libraries - maybe I need to hit the winapi harder?)

Thanks

Alan Mullett
  • 1,106
  • 13
  • 26

2 Answers2

2

After pondering this for a little while seeing the time assigned to this task being erroded away I got the old WIN32 api documentation out and [DllImport]'ed the calls I needed to do this the "old fashioned way". Being an old C dog I used to know my way around these calls, amazing how much comes back even after quite a few years of using the managed libraries.

What I needed to do was to be able to create a servcie, start it up, do useful work, stop it and delete it. The create, start, stop and delete are mechanics and I wanted to concentrate on the "do useful work" part of the activity.

I first copied the service's exe to the ADMIN$ share and verified the local path to that (with our server admins there is no telling!). To do this I call 

["netapi32.dll"]NetShareGetInfo

and then I used the following with from advapi32.dll

  • OpenSCManager
  • CreateService
  • StartService
  • OpenService (for when I want to stop and delete it - don't keep the handles open as this may take a while so cleaner to keep thngs self contained)
  • ControlService
  • QueryServiceStatus
  • CloseServiceHandle

This all works even across the VPN connection.

I can only guess that the managed api is trying to do far more than I actually need - the difference in time taken using the managed api and the Windows api is quite a lot, and with no guarantees that the managed api will get through it wasn't a suitable way forward.

Alan Mullett
  • 1,106
  • 13
  • 26
  • Good thinking on the workaround. That situation changes the whole question, now that it's a VPN issue.... – MPelletier Nov 23 '10 at 12:09
  • It only really became clear after I was in the office yesterday and my code worked, where it hadn't the evening before. Only difference was the Juniper VPN connection. – Alan Mullett Nov 23 '10 at 16:26
0

Obviously the stock code from MSDN doesn't paint the whole picture. I get the same results as you.

Check out what this guy did.

EDIT:

I believe you're trying it on a workgroup and not a domain, right? That's the trick, workgroups demand a bit more work to get through. The link above seems to have a workaround. I will try again from home tonight.

MPelletier
  • 16,256
  • 15
  • 86
  • 137
  • No, I'm in a domain. The code works if I'm directly connected to the LAN in the office, however that is only two days a week. The rest of the time I'm connected in via a VPN connection and the code doesn't work over that link. SC and PSEXEC work fine in both places which leads me to believe there are fundamental differences - but see post below... – Alan Mullett Nov 23 '10 at 09:40
  • To be honest I got another exception, RPC access denied, which I figured meant that at least something was working properly, if I could get as far as denied. – MPelletier Nov 23 '10 at 12:11