Test Automation tool not running via Windows Task Scheduler - powershell

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.

Related

Running Windows Powershell script always from task scheduler

This might be a very basic question. I have FileWatcher script in windows powershell which I want to run always so that it keeps watching a particular location for files. when I run it from Windows Powershell IDE its run perfectly fine. I understand that I can schedule a task in windows task scheduler for that but what's happening is that the task runs and then comes back in "Ready" status. This is NOT working. I think it should be in "Running" state always. I might be missing something. Please kindly help with your valuable suggestions.
You can do this with TaskSchedule…
Running PowerShell scripts as a “service” (Events: Prologue)
but this is also what permanent Event Subscriptions are for or setting up as user10675448 suggest, make it a real service.
How to run a PowerShell script as a Windows service
Windows PowerShell - Writing Windows Services in PowerShell
This article presents the end result of that effort: A novel and easy
way to create Windows Services, by writing them in the Windows
PowerShell scripting language. No more compilation, just a quick
edit/test cycle that can be done on any system, not just the
developer’s own.
There is also this approach...
PowerShell and Events: Permanent WMI Event Subscriptions
Unlike the temporary event, the permanent event is persistent object
that will last through a reboot and continue to operate until it has
been removed from the WMI repository.
There are multiple ways of setting up the WMI events and I will be
covering 3 of those ways (as they deal with PowerShell) in this
article.

Wix toolset - powershell script msi creation

I have a new project at work, for customer, that require me to do an OEM image creation.
The pre
The idea would be deploy OEM image, it will install, and deploy all software, and then shutdown. Once started back up it will prompt users to chose pc name, select Domain to join and regional settings.
I think i can do this by using a powershell script and wrapping it up in an msi and add it to MDT with no silent install switches (so that it prompts users to manually go through the steps)
Now my issue is how do i inject a powershell script as well as ensure that if this scipt has user input required, that it actually prompts the user to input the data (is this even possible with Wix?)
WiX is able to install files, configure Windows settings, interact with SQL Servers, and etc, but you are working with an installer file. It is not possible to receive input from the end user after a system reboot from WiX alone since you can run a PowerShell script while the system is active, but once it restarts, the process will get terminated and has to be restarted. Unless there is some way to schedule the PowerShell script in Windows such as running it from a service created in C#.

Running Powershell script using Task Scheduler freezes when in "Run whether user is logged in or not" mode

I currently have a Powershell script that can access Microsoft Outlook, and which I want to be executed automatically every x minutes. For the latter part I created a task in Task Manager that fires the following command:
Powershell.exe -windowstyle minimized -c "powershell -c [PATH_TO_SCRIPT] -verbose >> [PATH_TO_LOG]"
This works perfectly fine, except for the problem that, even with the -windowstyle minimized flag, it still briefly opens a powershell window, that disappears to the background after 2 seconds or so. A solution to this problem is to change the setting in Task Scheduler, checking "Run whether user is logged in or not". However, at that point, my script doesn't execute anymore. From the logs I found that the script runs perfectly fine until the following line:
$outlook = New-Object -ComObject Outlook.Application,
the line on which I open the Outlook application. I'm not sure what the "run whether user is logged in or not" option actually does, but whatever it is, it can no longer access an instance of my Outlook application.
Given what I actually want to achieve, could I tweak either my script or my task to fix this, or is there maybe another way to tackle this?
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article.
As a workaround you may consider using a low-level API instead - Extended MAPI. Or just any other third-party wrapper around that API such as Redemption.

Opening Interactive PowerShell GUI script for other logged on users

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.

Running a cgi perl script as an Administrator

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.