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).
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.
Related
I am working on a TFS CI build pipeline. The build includes execution of functional UI tests (Run Functional Tests) and the required accompanying preparatory test agent deployment step (Deploy Test Agent).
This build executed successfully in the past but spontaneously stopped working recently.
I initially ran into difficulty with the DTA task executing hanging:
Task 'SetupTestMachineForUiTests' on machine '[testVM]:5985' is taking time. Please Wait
I had encountered this issue with this build task before albeit intermittently. However, this time the step would not complete no matter how many times it executed. Eventually (~20 minutes), the step crashed out with the following error:
Task 'SetupTestMachineForUiTests' for machine [testVM]:5985's Error :
System.Exception: Stopping test machine setup as it exceeded maximum number of reboots. If you are running test agent in interactive mode, please make sure that autologon is enabled and no legal notice is displayed on logon in test machines.
Unfortunately, the DTA task only writes logs to the usual location on the test VM when the DTAExecutionHost.exe is manually closed on the server after the step has failed. The logs offer no clue as to what the problem might be.
One of the prerequisites for the DTA step to execute successfully is that AutoLogon is enabled on the test VM; I had done this with a simple PowerShell script, executed prior to the DTA task. In order to confirm that the test VM registry values had been correctly assigned (to enable auto logon, disable legal notice, screensaver etc) during my PowerShell script execution, I added a further PowerShell debug script to the build to output each relevant registry value to the build console (all are correctly assigned).
However, when I went to test remote login on the test VM, using the test username, the user creds are accepted but the following warning message shows:
To sign in remotely, you need the right to sign in through Remote Desktop Services. By default members of the Administrators group have this right. If the group you're in does not have the right, or if the right has been removed from the Administrators group, you need to be granted the right manually.
I believe this is the problem. However, the solution has so far eluded me.
I double- and triple- checked; the test user has been added to the
Remote Desktop Users group (also Administrators group).
I've also confirmed that both Administrators and Remote Desktop Users groups
have been granted 'Allow log on through Remote Desktop Services' user
rights.
In testing, I forced successful execution of the build by substituting my own username instead of the test user into the build definition (my user name is also added to RDU and Admin user groups on the server but I can successfully remote onto the box with my own creds); this build executed successfully.
I also inspected the other (possibly, probably) related user groups:
Srv_SeDenyInteractiveLogonRight (test user is absent)
Srv_SeDenyRemoteInteractiveLogonRight (test user is absent)
Srv_SeInteractiveLogonRight (test user present)
I've been fighting with this problem for days now; it's now become a major headache. I'd be very grateful for any insights that might help find a resolution.
Thanks for looking.
The problem was that the account had been added to the AD domain 'DenyInteractiveLogon' group. Adding the account to the local 'Remote Desktop User' and/or the 'Srv_SeInteractiveLogonRight' groups had no effect.
Removing the user account from the domain group resolved the problem.
Hello Folks,
I have a powershell MTA (GUI script using winForms), which works well, lets take the script name to be "ENDUserMTA.ps1" which does invoke certain commands and does something which really needs admin rights. this works fine when run manually or via task scheduler or when set via [registry] RunOnce or Run or whatever when there is admin rights..
The problem is i want to invoke this script on the END users laptop and make them to work with it [interactively]
Options that i have tried so far:
Tried Scheduling the "ENDUserMTA.ps1" in Task Manager SYSTEM account [using When running the task, use the following user account] - this starts and run NOT INTERACTIVE [since system account does not have interactive session]
Tried Scheduling the "ENDUserMTA.ps1" in Task Manager with Different user account which has admin rights [using When running the task, use the following user account] - This again starts but the GUI is not shown to the End User who has logged without admin rights, rather shown to only the user who was set under the option [When running the task, use the following user account]
My situation is not possible to create PSSessions or Delegated Remoting. I am now is middle of forest and no where to go!!!
Not sure how to invoke the script as admin to a user who has logged into a machine without admin rights..
WHat i exactly need or similar solution: When scheduling this script, i schedule the script to start atlogon[any user], after the script completes it will delete the scheduled task
Pls help..
Balaji
Begining on Vista Microsoft has started to separate UI stacks for security reasons.
My advise for your problem is to change the architecture of your code in order to create two scripts.
The first one with no UI will be scheduled with administrative rights
The second one with UI will be started with the user rights and will be a client of the first one.
You can use Inter-Process Communication between the two scripts, but you will met a security issue, you server part vill need particular ACLs to allow the client part to connect.
It exists other way to communicate between scripts, but it's not so easy with an asynchronous UI architecture on one side. It would be simple using managed code (.NET code) or native code(unmanaged code). For me, you are on the limit of the scripting place even if scripting capacities are very large as far as PowerShell is built on the top of .NET.
Here is a general description of the issue which I cannot solve:
We have a WindowsServer 2008 R2 system that is used to running the install of our product(using powershell script), and then the Powershell script calls the .exe of our UI test automation tool (Ranorex).
The install of the product works fine, but the UI automation portion only runs if some is physically logged in via remote desktop.
If the remote desktop session is closed (but the programs continue to run..so user is technically logged in), the UI automation portion will NOT run.
The options I selected on the General tab of the job are:
-Run only when the user is logged in;
-Run with highest privileges;
Any ideas on from anyone who has had this issue and got it to work would be extremly helpful.
Thanks,
Eric
UI operations are usually in suspended state when a user is disconnected from an RDP session. Use a tool like VNC or equivalent where you have access to the main console for these UI operations to remain active.
I'm writing a perl script for a website, and I need to be able to control VirtualBox via the website. I'm not sure where to start, or if I'm even trying to debug in the right area, but here goes.
My server is running IIS7 on Windows Server 2008 R2. I'm also running 2 virtual machines through the vboxmanage command line interface. These VMs are running under SERVER\administrator.
When I open my website, it requests a login. I login to the website as SERVER\administrator and click a link that calls my script using an xmlhttprequest. Now, normally, it doesn't matter what user I run these as, but with vboxmanage, if I run the command as a different user, the list of VMs is different. I tried whoami, which returned SERVER\administrator, but %DOMAINNAME%\%USERNAME% returns the domain that the server is connected to as dommainname and SERVER$ as the username. The vboxmanage command then fails.
On the website, impersonation is turned on. When I turn impersonation off, the whoami request changes to be iis apppool\website. Any ideas on how to get around this?
As a final note, I've thought about using runas, but since it prompts for a password, there's no way to call it through scripting (and that would be a poor security decision, I'd imagine).
This is an oft recurring, well-known and well-solved problem. Instead of having one big program dealing with requests from the Web and managing the VM (strong coupling), separate the concern and write two programs, each doing exactly one task.
The user facing program running in the Web server context can continue with limited privileges. The VM manager is a stand-alone program running with the necessary admin privileges, either repeatedly from the scheduler or as daemon/service.
Have the first communicate with the second over a message-queue.
First of all, I'm not sure if this is generic to services in general, but the problem I'm having is pretty specific, it has got to do with the SageTV service component.
Since there isn't much help over at the SageTV forums regarding this specific subject, I thought maybe this was a generic issue with services and therefore worth asking here at Stackoverflow.
Here goes:
I'm running the SageTV windows service with a plugin activated which is supposed to execute external programs. When running under the Local System Account (with the "Interact with the desktop option" enabled), this works fine. For testing purposes I'm using notepad.exe as the program to execute.
Then I created a new user (let's call it mediabrowser) and changed the SageTV service so it would run as that user. When I do that, the SageTV plugin no longer executes notepad. It just does nothing, I don't get any errors or anything, it's just that nothing happens when notepad should be getting executed.
The mediabrowser user has administrative priviliges. The option to interact with the desktop is only available for the Local System Account, and I believe that normal users are always allowed to interact with the desktop anyways.
Is this a general issue with services? If so, what permissions might my mediabrowser user need in order for this to work? I'm pretty sure this is because of permission differences between my mediabrowser user and the Local System Account.
Thanks in advance ...
Uhhh OK. Now I feel like an idiot. I just launched the tast manager on the machine and I can see that there are tons of notepad.exe processes under the mediabrowser user so I guess that notepad IS being executed correctly. It's just not being shown on the desktop.
So I guess this just works :-)