Setting a Windows Service to interact with the desk top and also log on as a user account

[Ian Frawley]

Hello everyone

I have written a Windows Service to monitor local and remote
Processes/Applications. However I am stuck because if it is installed as a
user account I cannot get it to interact with the desktop and therefore get
the System.Diagnostics.Process.Responding of an app. But if I set it as a
System account that interacts with the desktop I have all sorts of security
issues.

I frigged the Type field within the Services registry entry which now shows
that it can interact with the desktop but it still refuses to play. Anyone
else come up against anything like this?

Cheers

 

[Nicholas Paldino [.NET/C# MVP]]

Ian,

I would not ever have a service that interacts with a desktop. It just
doesn't make sense. The reason for this is that there might not always be a
user logged in, but the service will always be running.

What you should do is have an application that communicates with the
service (using some mechanism, remoting, pipes, etc, etc). This will allow
you to run the service under any account you like, and allow it to interact
with the desktop (through a layer of indirection).

Hope this helps.

 

[Ian Frawley]

Hi Nicholas,

Yeah I see what you mean. However the majority of the apps being monitored
will be running as processes on remote machines and will definatley be
logged on to the desktop. This means that even if the service is able to
interact with the desktop it probably means that it won't be able to on a
remote machine anyway. Hmmmmmm this seems to have become the fly in the
ointment and bust me design.

Damn

Ian,

I would not ever have a service that interacts with a desktop. It just
doesn't make sense. The reason for this is that there might not always be a
user logged in, but the service will always be running.

What you should do is have an application that communicates with the
service (using some mechanism, remoting, pipes, etc, etc). This will allow
you to run the service under any account you like, and allow it to interact
with the desktop (through a layer of indirection).

Hope this helps.

 

[Nicholas Paldino [.NET/C# MVP]]

Ian,

I am surprized that the Process class can not monitor the local
processes if it is not interactive with the desktop. Are you sure this is
the case?

Also, even if you can't interact with the desktop, you should still see
information about remote services (since you can't interact with their
desktops).


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi Nicholas,

Yeah I see what you mean. However the majority of the apps being monitored
will be running as processes on remote machines and will definatley be
logged on to the desktop. This means that even if the service is able to
interact with the desktop it probably means that it won't be able to on a
remote machine anyway. Hmmmmmm this seems to have become the fly in the
ointment and bust me design.

Damn

message news:[email protected]...

Ian,

I would not ever have a service that interacts with a desktop. It just
doesn't make sense. The reason for this is that there might not always

be

a
user logged in, but the service will always be running.

What you should do is have an application that communicates with the
service (using some mechanism, remoting, pipes, etc, etc). This will allow
you to run the service under any account you like, and allow it to interact
with the desktop (through a layer of indirection).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hello everyone

I have written a Windows Service to monitor local and remote
Processes/Applications. However I am stuck because if it is installed

as

a therefore
get

as

 

[Ian Frawley]

Nick,

I have tested the Process class and it always returns true when running as a
service that doesn't interact with the desktop. I dun know why it just does.
I am going to see if there are any WMI classes that I can use instead.

Cheers

Ian

Ian,

I am surprized that the Process class can not monitor the local
processes if it is not interactive with the desktop. Are you sure this is
the case?

Also, even if you can't interact with the desktop, you should still see
information about remote services (since you can't interact with their
desktops).


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi Nicholas,

Yeah I see what you mean. However the majority of the apps being monitored
will be running as processes on remote machines and will definatley be
logged on to the desktop. This means that even if the service is able to
interact with the desktop it probably means that it won't be able to on a
remote machine anyway. Hmmmmmm this seems to have become the fly in the
ointment and bust me design.

Damn

message news:[email protected]...

always

be

a
user logged in, but the service will always be running.

What you should do is have an application that communicates with the
service (using some mechanism, remoting, pipes, etc, etc). This will allow
you to run the service under any account you like, and allow it to interact
with the desktop (through a layer of indirection).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hello everyone

I have written a Windows Service to monitor local and remote
Processes/Applications. However I am stuck because if it is

installed

as as

 

[Nicholas Paldino [.NET/C# MVP]]

Ian,

You should be able to use the Win32_Process class as an alternative.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Nick,

I have tested the Process class and it always returns true when running as a
service that doesn't interact with the desktop. I dun know why it just does.
I am going to see if there are any WMI classes that I can use instead.

Cheers

Ian

Ian,

I am surprized that the Process class can not monitor the local
processes if it is not interactive with the desktop. Are you sure this is
the case?

Also, even if you can't interact with the desktop, you should still see
information about remote services (since you can't interact with their
desktops).


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi Nicholas,

Yeah I see what you mean. However the majority of the apps being monitored
will be running as processes on remote machines and will definatley be
logged on to the desktop. This means that even if the service is able to
interact with the desktop it probably means that it won't be able to

on

a

remote machine anyway. Hmmmmmm this seems to have become the fly in the
ointment and bust me design.

Damn

"Nicholas Paldino [.NET/C# MVP]" <[email protected]>

wrote
in

message Ian,

I would not ever have a service that interacts with a desktop. It
just
doesn't make sense. The reason for this is that there might not

always

be
a
user logged in, but the service will always be running.

What you should do is have an application that communicates with the
service (using some mechanism, remoting, pipes, etc, etc). This will
allow
you to run the service under any account you like, and allow it to
interact
with the desktop (through a layer of indirection).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hello everyone

I have written a Windows Service to monitor local and remote
Processes/Applications. However I am stuck because if it is

installed

as
a
user account I cannot get it to interact with the desktop and therefore
get
the System.Diagnostics.Process.Responding of an app. But if I set

it
as

a
System account that interacts with the desktop I have all sorts of
security
issues.

I frigged the Type field within the Services registry entry which now
shows
that it can interact with the desktop but it still refuses to play.
Anyone
else come up against anything like this?

Cheers

 

[Ian Frawley]

Yeah I have been looking at that as I collect other Process metrics from
that class. I am also looking at using Event Traces.

Cheers

Ian,

You should be able to use the Win32_Process class as an alternative.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Nick,

I have tested the Process class and it always returns true when running

as

a
service that doesn't interact with the desktop. I dun know why it just does.
I am going to see if there are any WMI classes that I can use instead.

Cheers

Ian

this

is

the case?

Also, even if you can't interact with the desktop, you should

still
see

information about remote services (since you can't interact with their
desktops).


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi Nicholas,

Yeah I see what you mean. However the majority of the apps being monitored
will be running as processes on remote machines and will definatley be
logged on to the desktop. This means that even if the service is

able

to

interact with the desktop it probably means that it won't be able to

on

a
remote machine anyway. Hmmmmmm this seems to have become the fly in the
ointment and bust me design.

Damn

in
message Ian,

I would not ever have a service that interacts with a desktop. It
just
doesn't make sense. The reason for this is that there might not always
be
a
user logged in, but the service will always be running.

What you should do is have an application that communicates

with
the

service (using some mechanism, remoting, pipes, etc, etc). This will
allow
you to run the service under any account you like, and allow it to
interact
with the desktop (through a layer of indirection).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hello everyone

I have written a Windows Service to monitor local and remote
Processes/Applications. However I am stuck because if it is installed
as
a
user account I cannot get it to interact with the desktop and
therefore
get
the System.Diagnostics.Process.Responding of an app. But if I

set

it which
now