Problem with services

[djmob]

I am very new to .NET and Windows programming in general so please bare with
me...

I created a Windows service by deriving a class from ServiceBase and
installing it via the 'sc create' commands as follows:

sc create <name> binPath= <path>

Where path is the fully qualified path name. The new service appeared in the
Services GUI and I was able to start and stop it without problems. Next I
recreated the service via the 'sc create' command where binPath used a mapped
drive letter via the subst command i.e. 'subst x: c:\actual\path\ name' The
service is created but it does not start and I get the following error
message:

Could not start the <name> service on Local Computer. Error 3: The system
cannot find the path specified.

Unfortunately it is a requirement of my project to be able to used a mapped
driver letter. It appears that when the service is started it has no
knowledge of the drive mappings in my environment. After some research it
also appears that using the subst command is discouraged in later versions of
Windows and the preferred method is to use net commands. I have not been
entirely successful with the net commands and hope there is another approach
to solving this problem. Any suggestions???

[djmob]

When you say the "The SCM can not start a service that is located on

a remote server" you mean even if it is mapped to the local drive i.e. 'subst x: c:\path'.
The reason this is a requirement is that I am turning an existing application
into a service and it is important for us to preserve this drive mapping to
support our current development environment (the exact details of why this is
important is a little sketchy to me too). The only reason I brought up the
net commands is that I thought there was something inherent in the subst
command for it not to work with a service.

As I said before this is very new to me so I hope I am making some sense.

Willy Denoyette [MVP] wrote:|I am very new to .NET and Windows programming in general so please bare with
| me...
[quoted text clipped - 21 lines]
| entirely successful with the net commands and hope there is another approach
| to solving this problem. Any suggestions???

Service executables should be stored on local drives, what you are trying is
not a supported scenario. The SCM can not start a service that is located on
a remote server, the reason is that SCM (Service.exe) runs as SYSTEM
(localsystem ) which is a local security account that has no network access
token. Note that it's possible for SYSTEM to access remote resources from
domain members running in a W2K Active Directory domain, provided that the
"server" starting the service is granted access to the remote share (the
server name is used to authenticate over the network in this case), but even
then there is in guarantee that the service will get loaded, for instance
what if the remote server is not up?
Honestly, I don't see any reason why you need to load a service from a
remote share, I'm I missing something?.

Willy.

[Amir_Hasan]

Your right I was assuming the Service Implementation is within the same
assembly as the executable (the exe assembly with the Main.) If it is
not you have to make sure that Appdomain Private Path contains the
path of the assembly that is implementing the service (and any of its
dependencies) so that the CLR can find it. You will then have to use
Reflection to load it using Activator.Creat eInstance

This can be done by appending private path to the appdomain in the
static Main e.g.
static void Main(string [] args)
{
AppDomain.Curre ntDomain.Append PrivatePath("se rviceimp"); //note this
assumes the assembly with YourServiceAsse mbly.dll is in a subfolder
(with its private dependencies ) called serviceimp
System.ServiceP rocess.ServiceB ase[] ServicesToRun;
System.ServiceP rocess.ServiceB ase impl =
Activator.Creat eInstance("Your ServiceAssembly ,ServiceImpl.My Service");
// note the fully qualified class name is ServiceImpl.MyS ervice where
ServiceImpl is the namespace
ServicesToRun = new System.ServiceP rocess.ServiceB ase[] { impl };
System.ServiceP rocess.ServiceB ase.Run(Service sToRun);
}

I hope this makes sense.

..

[Amir_Hasan]

Sorry I am not addressing the underlying issue. Your basically stuffed.
Mapped and substited drives are in terms of a user who has logged in.
the SCM that is running up your service is running under the system
account and so does not know anything about the substituted X:. This is
even before the CLR has loaded or kicked in there is basically nothing
you can do. Please ignore my previous posts

[Willy Denoyette [MVP]]

The SCM knows x: is not a real local drive, so it asks the 'Workstation'
service (also called the redirector)to resolve the path, which is not
possible as per my previous explaination, and it's not what you are after
anyway.

What you need to do is:
1. Load your service from a local drive (loading from a remote drive would
not give access to that drive from within your service anyway) and run it as
a user account with access privileges to the remote share, that is as:
- a domain account or
- a shadow account, that is a local account with the same credentials (user
name and password) that exists on both servers.

2. Don't use drive letters to access the remote share, use UNC paths instead
(like : \\server\shared \filename ).

If you can't use UNC paths (I see no reason why not), you need to map the
drive from withing your service.
This can be done using:
1 - PInvoke "NetUserAdd " or "WNetAddConnect ion2, or
2 - a by invoking the utility "net.exe" using Process.Start from within your
service.
complete command looks something like:
net use x: \\servername\sh are /user:remoteserv ername\userName pwd
where: remoteservernam e is the name of the remote machine
userName is the name o a user on above with valid access privileges
to the share
pwd is it's password.

Willy.
"djmob" <u19229@uwe> wrote in message news:5c9c092af5 3d7@uwe...
| Yes that is correct. The problem is with the service being loaded from a
| locally mapped drive. Currently the drive is mapped using the subst
command
| i.e. 'subst x: c:\pathToServic e'.
|
| Willy Denoyette [MVP] wrote:
| >| The cause of this is you have to remember that the Service has to be
| >| running under a certain context.
| >[quoted text clipped - 24 lines]
| >|
| >| }
| >
| >This makes no sense, sorry, the problem is that the service cannot be
loaded
| >so certainly not be started, how would this solve the problem?
| >
| >Willy.

[djmob]

I think your right. Thanks for the help.

Amir_Hasan wrote:

Sorry I am not addressing the underlying issue. Your basically stuffed.
Mapped and substited drives are in terms of a user who has logged in.
the SCM that is running up your service is running under the system
account and so does not know anything about the substituted X:. This is
even before the CLR has loaded or kicked in there is basically nothing
you can do. Please ignore my previous posts

[Willy Denoyette [MVP]]

Sorry but, you got it wrong again, the problem can not be solved in the
service code, the problem is that the Service Control Manager (the SCM)
cannot load the exeutable from the path as defined by the configuration
utility.
The service path is configured like : x:\myservice.ex e, but the SCM does not
know what x: is all about so he asks the Workstation service to resolve the
mapping, which is not possible either, because it's the result of "subst"
command done in the interactive users logon context. So, it's not a network
share redirection either, which is finaly what the OP is trying to sumulate
(wrongly).

Willy.

"Amir_Hasan " <ah****@gmail.c om> wrote in message
news:11******** *************@v 46g2000cwv.goog legroups.com...
| Your right I was assuming the Service Implementation is within the same
| assembly as the executable (the exe assembly with the Main.) If it is
| not you have to make sure that Appdomain Private Path contains the
| path of the assembly that is implementing the service (and any of its
| dependencies) so that the CLR can find it. You will then have to use
| Reflection to load it using Activator.Creat eInstance
|
| This can be done by appending private path to the appdomain in the
| static Main e.g.
| static void Main(string [] args)
| {
| AppDomain.Curre ntDomain.Append PrivatePath("se rviceimp"); //note this
| assumes the assembly with YourServiceAsse mbly.dll is in a subfolder
| (with its private dependencies ) called serviceimp
| System.ServiceP rocess.ServiceB ase[] ServicesToRun;
| System.ServiceP rocess.ServiceB ase impl =
| Activator.Creat eInstance("Your ServiceAssembly ,ServiceImpl.My Service");
| // note the fully qualified class name is ServiceImpl.MyS ervice where
| ServiceImpl is the namespace
| ServicesToRun = new System.ServiceP rocess.ServiceB ase[] { impl };
| System.ServiceP rocess.ServiceB ase.Run(Service sToRun);
| }
|
| I hope this makes sense.
|
| .
|

[Willy Denoyette [MVP]]

"djmob" <u19229@uwe> wrote in message news:5c9c1a1dd1 373@uwe...
| When you say the "The SCM can not start a service that is located on
| >a remote server" you mean even if it is mapped to the local drive i.e.
'subst x: c:\path'.
|
| The reason this is a requirement is that I am turning an existing
application
| into a service and it is important for us to preserve this drive mapping
to
| support our current development environment (the exact details of why this
is
| important is a little sketchy to me too). The only reason I brought up
the
| net commands is that I thought there was something inherent in the subst
| command for it not to work with a service.
|

Service are not regular application, this is something you need to consider
when turning regular applications into Services, something that is common
place since the introduction of .NET.
Everyone seems to need services these day's, which IMO, is terribly wrong in
most circumstances.

I have explained what you have to do in an other reply, but before you do,
make sure you know what services are all about, what they are meant to solve
and what their restrictions are. Failing to do your homework will bite you
sooner that later.
What you need to know to begin with is (non exhaustive!):
- Services are meant to run in a restricted security context, they need
(preferably) to run under service users credentials (localsystem, local
service or network service). Running them under domain credentials is a
security threat.
- The run in a secured desktop (in the background as the sage goes) that has
no access to the active (visible) desktop, the active desktop has no access
to the service(s) desktop(s) either. That means they should not have a UI,
nor should they assume they can access, the UI of a running programs, by
whatever means.
- They don't have access to the profile data of the currently logged on user
(interactive), nor should the assume the presence of such a user.
- They have access to the services hives for their private profile storage,
these are mapped as:
- HKU\.Default or S-1-5-18 for localsystem and all other accounts
running the service (local or domain)
- HKU \S-1-5-19 for Local Service
- HKU \S-1-5-20 for Network Service

None of these hives contain configuration data like printers and persistent
mapped network shares, application paths like MyDocuments, MyPictures etc;
paths to document folders etc...

They run their threads in an MTA, so, be sure your COM objects can live
safely in this context, inspect your COM servers requirements first.
They should not use any library that requires a UI to be present even not a
hidden window (think System.Drawing and managed/unmanaged DirectX).
Willy.

[djmob]

Thanks for the advice and help. Greatly appreciated.

Willy Denoyette [MVP] wrote:

I have explained what you have to do in an other reply, but before you do,
make sure you know what services are all about, what they are meant to solve
and what their restrictions are. Failing to do your homework will bite you
sooner that later.