1

I'm running an application that executes Windows Workflows as a service with some custom activities in them. When I run the activities as a logged on user in a shell that invokes the workflows with the activities, the activities have no problems performing as expected. When the activities get invoked while the user is running the service (e.g. not logged on, at least not graphically) the activities fail with "Access Denied" errors. What's the difference between running the code as a logged on user vs running it as a service user ? Is it that when it runs as a service, the user's profile doesn't get loaded ? If so, how can I force the user's profile to get loaded when running as a service ?

Specifically, the activities I'm working with perform remote management with classes in the System.Management.Automation namespace (i.e. powershell).

Alex Marshall
  • 10,162
  • 15
  • 72
  • 117

1 Answers1

1

A bit late answer, but in case someone else is wondering.

I had a similar problem earlier and have done some research. The following is untested, but may be of help to others.

The difference between a process running as "Windows Service" and under a desktop environment is what Window Station it is assigned to. Normally a service runs under a different station than desktop users.

I say normally because a service can have the "SERVICE_INTERACTIVE_PROCESS" flag set. This will give it a desktop window station. See this article and this article for a more detailed explanation. Setting the "SERVICE_INTERACTIVE_PROCESS" can be done in the CreateService (C# use of that) call or manually by checking the "Allow service to interact with desktop" checbox under "LogOn" under properties of the specific service.

Community
  • 1
  • 1
Tedd Hansen
  • 12,074
  • 14
  • 61
  • 97
  • PS! Also remember Execution Policy for new users such as Local System: https://technet.microsoft.com/en-us/library/hh849812.aspx – Tedd Hansen Mar 09 '15 at 14:07