Windows PowerShell hangs under 24x7

The actual job I have which is hanging is more convoluted than this, but this simplified code illustrates the problem:

If I create a job which calls a DOS command it works fine, e.g.:

	Code:
	cmd /c dir

If I create a job which calls a PowerShell command the job hangs:

	Code:
	powershell get-date

Both DOS and PowerShell commands work when run from the Windows Task Scheduler.

Any thoughts?

24x7 Multi-Platform edition 4.1 under Windows XP Pro SP2; Windows PowerShell 1.0

Have you tried

	Code:
	cmd /C powershell get-date

SysOp wrote:

Have you tried

	Code:
	cmd /C powershell get-date

Still hangs...

Please take a look at http://www.interopcommunity.com/tm.aspx?m=11330
Is that your "no prompt" case or is that something else?

	SysOp wrote:
	Please take a look at http://www.interopcommunity.com/tm.aspx?m=11330 Is that your "no prompt" case or is that something else?

Sorry, I can't tell. In both my production code and the test above, no window is displayed when PowerShell starts up--it's a faceless application.

Please check if you get anything related in Windows event logs

	SysOp wrote:
	Please check if you get anything related in Windows event logs

Good thinking batman.

In the Windows PowerShell log there's 7 messages for 'provider's starting, followed by the engine state changing to available.

These messages mirror the same PowerShell command being successfully run from the DOS prompt; EXCEPT from the DOS prompt there's then 7 corresponding messages about providers stopping plus the engine being unavailable.

i.e. From my reading PowerShell is starting up OK and not hanging until after startup.

There's nothing in the Application/Security/System logs.

I can reproduce this issue on WinXP system. Indeed powershell.exe appears to be hung and not doing anything. Process Explorer likely shows that it is waiting for some NET event. I think the best place to continue troubleshooting this, is to post a question in one of the MS support forums for NET/Powershell technologies and check how to troubleshoot this issue. If you can somehow debug the Powershell process and find out what resource or event it is waiting for, you can then figure out how to workaround that the entire issue.

SysOp wrote:

I can reproduce this issue on WinXP system. Indeed powershell.exe appears to be hung and not doing anything. Process Explorer likely shows that it is waiting for some NET event. I think the best place to continue troubleshooting this, is to post a question in one of the MS support forums for NET/Powershell technologies and check how to troubleshoot this issue. If you can somehow debug the Powershell process and find out what resource or event it is waiting for, you can then figure out how to workaround that the entire issue.

We tried a few things but I haven't been able to come up with much from news::microsoft.public.windows.powershell

We did find the job would work if 24x7 first called a VBScript which then called up PowerShell, but I can't use that in my production job (24x7 calls SAS which then calls PowerShell and reads a pipe from it).

And this which seems of limited help:

	Quote:
	in that case I would ask the 24x7 guys [t]hat they wait for after a command has started

Thoughts? As this is reproducible is it something the developers can take a look at?

Well, first after reading your post, I first though that you hit a wall here. Process management is done by JDK/JRE so it is unlikely anything can be done here to change the behavior. Then I realized that if it works from VBScript that injecting an intermediate process can make it work in other places too. And this is how I made it to work. I enabled job security (step 4 in the Job Wizard) and it did the trick. When security is enabled, 24x7 internally uses RunAs utility on Windows to start the process as another user. You don't have to use another user, you can specify the same one that is running the scheduler, just make sure you give that user "Act as part of the operation system", "Create a token object", and "Logon as a batch job" privileges and bounce the system, after that the scheduler should be able to run jobs on behave or other users or same user but as a separate batch process. RunAs creates powershell process as a native process without use of JDK/JRE and it appears to work. I was able to schedule and run C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe get-date > C:\powershell.log

	SysOp wrote:
	And this is how I made it to work. I enabled job security (step 4 in the Job Wizard) and it did the trick

Sounds good, thanks! I'm having trouble editing my Windows security settings (they come from the server), I'll report back when I've got the Apply credentials working.

I finally had some time to fiddle some more.

I went into Control Panel -> Administrative Tools -> Local Security Policy

Under Security Settings -> Local Policies -> User Rights Assignment I added myself to 'Act as part of the operating system' and 'Create a token object'. I already had 'Logon as a batch job'.

Under the job's step 4 I set user authentication and put myself in. The job is running on [local]

24x7 complains:

	Code:
	Create process error. Extended error: Error #1314: A required privilege is not held by the client. Note: User account running RunAs must be assigned "Act as part of the operation system" rights and also have "Create token" rights. User account used to run the process must be assigned "Logon as a batch job" rights.

I've double-checked the security settings, rebooted, and tried both domain\user and .\user for the job username.

Is there something in Windows I've missed? XP Pro.

Are you loggin in as a local user or as a domain user? Under which account the job and scheduler are running, local or domain?

How do I tell if I'm local or domain? The scheduler runs as me--both as GUI and service, though I'm currently testing under GUI.

If the logon account is entered as .\user_name, or (local_machine_name\user_name) it is a local account. If it is entered as domain_name\user_name, it is a domain account. In the latest case you need to grant permissions to the domain user. You can Active Directory Management tools for that purpose. In most cases domain user permissions override local user permissions.