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.

Tue Oct 23, 2007 7:44 pm

SysOpSite Admin

Joined: 26 Nov 2006Posts: 6608

Please check if you get anything related in Windows event logs

Tue Oct 23, 2007 8:20 pm

barefootguru

Joined: 10 Aug 2007Posts: 195

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.

Tue Oct 23, 2007 11:36 pm

SysOpSite Admin

Joined: 26 Nov 2006Posts: 6608

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.

Wed Oct 24, 2007 1:52 am

barefootguru

Joined: 10 Aug 2007Posts: 195

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 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?

Sun Oct 28, 2007 10:44 pm

SysOpSite Admin

Joined: 26 Nov 2006Posts: 6608

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

Sun Oct 28, 2007 11:42 pm

barefootguru

Joined: 10 Aug 2007Posts: 195

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

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.

Mon May 19, 2008 10:32 pm

SysOpSite Admin

Joined: 26 Nov 2006Posts: 6608

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?

Mon May 19, 2008 10:41 pm

barefootguru

Joined: 10 Aug 2007Posts: 195

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.

Mon May 19, 2008 10:49 pm

SysOpSite Admin

Joined: 26 Nov 2006Posts: 6608

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.