Task Scheduler problem

Posted by James Palmer on 12-May-2015 08:49

Trying to configure the task scheduler on our new Win Server 2012 R2 box. Progress 11.5 64 bit. 

The schedule is set to call as follows: 

Start Program: G:\Batch\Batch Files\ProcessBatchRecords.bat, arguments: BatchProcess.p "TITLE=Alarms, AD Accounts and ICR|TYPES=ALM,AD-ACC,ICRDELETE,ICRWRITE,FPCRD" 

The batch file is: 

call pathpro

start C:\Progress\OpenEdge\bin\prowin.exe -basekey "INI" -ini G:\batch\INI\SDMbatch.ini -pf g:\batch\PFs\ICMASliv.pf -p %1 -param %2

BatchProcess.p does some stuff and then loads a window to give status displays. 
If I run the command from a CMD box I get a Progress window opening quite happily and doing what's expected. When run from the scheduler it won't work at all. I get nothing. 

Here's the XML of the batch process. 

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.1" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Author>Administrator</Author>
  </RegistrationInfo>
  <Triggers>
    <CalendarTrigger>
      <Repetition>
        <Interval>PT1H</Interval>
        <Duration>PT23H</Duration>
        <StopAtDurationEnd>false</StopAtDurationEnd>
      </Repetition>
      <StartBoundary>2010-01-26T00:15:00</StartBoundary>
      <Enabled>true</Enabled>
      <ScheduleByDay>
        <DaysInterval>1</DaysInterval>
      </ScheduleByDay>
    </CalendarTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">
      <UserId>NETWORKS\inencoadmin</UserId>
      <LogonType>InteractiveToken</LogonType>
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
    <IdleSettings>
      <StopOnIdleEnd>false</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <Enabled>false</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>PT2H</ExecutionTimeLimit>
    <Priority>5</Priority>
  </Settings>
  <Actions Context="Author">
    <Exec>
      <Command>"G:\Batch\Batch Files\ProcessBatchRecords.bat"</Command>
      <Arguments>BatchProcess.p "TITLE=Alarms, AD Accounts and ICR|TYPES=ALM,AD-ACC,ICRDELETE,ICRWRITE,FPCRD"</Arguments>
      <WorkingDirectory>G:\Batch\Batch Files\</WorkingDirectory>
    </Exec>
  </Actions>
</Task>


All Replies

Posted by Matt Gilarde on 12-May-2015 09:10

You may be running into Session 0 Isolation. Newer versions of Windows run services in a sandbox called Session 0. This sandbox is non-interactive and can't display UI. I believe that scheduled tasks are run by a service; that service runs in the session 0 sandbox and the tasks it runs are not able to display UI.

Posted by James Palmer on 12-May-2015 09:21

Thanks Matt. Is there a way to work around this? On our test bed of 2012 (not R2) It worked if we told it to emulate Win 2003.

Posted by Matt Gilarde on 12-May-2015 09:35

I don't know of a workaround or of a way to disable the isolation. I think you're expected to re-architect things so that the task talks to a client running in a user session (which can display UI). The client displays the UI for the task.

Posted by James Palmer on 12-May-2015 09:41

This is very unfortunate indeed. I've done a bit of reading and can sort of understand the reason why it is necessary (unfortunately), but it's a major problem for this implementation. I've got a week and a half until I need to get this server live or else we'll have to wait until the end of August (due to the long weekends here in the UK). Our projections are that the current server will no longer be able to adequately serve the application imminently.

Posted by ChUIMonster on 12-May-2015 09:51
It's a *batch* process.  Why in the world are you using prowin.exe in the first place?

Batch processes should use _progres.exe.

Is there a -b in the .pf file?  (There should be.)

Are you redirecting input and output to a log file?  (You should be.)

If all it is using the UI for is to display status updates then it should be simple enough to redirect output to a log file.



[collapse]On 5/12/15 9:49 AM, James Palmer wrote:
Thread created by James Palmer

Trying to configure the task scheduler on our new Win Server 2012 R2 box. Progress 11.5 64 bit. 

The schedule is set to call as follows: 

Start Program: G:\Batch\Batch Files\ProcessBatchRecords.bat, arguments: BatchProcess.p "TITLE=Alarms, AD Accounts and ICR|TYPES=ALM,AD-ACC,ICRDELETE,ICRWRITE,FPCRD" 

The batch file is: 

call pathpro

start C:\Progress\OpenEdge\bin\prowin.exe -basekey "INI" -ini G:\batch\INI\SDMbatch.ini -pf g:\batch\PFs\ICMASliv.pf -p %1 -param %2

BatchProcess.p does some stuff and then loads a window to give status displays. 
If I run the command from a CMD box I get a Progress window opening quite happily and doing what's expected. When run from the scheduler it won't work at all. I get nothing. 


[/collapse]
Posted by James Palmer on 12-May-2015 09:55

Thanks Tom. I'm using prowin because _progres isn't working in conjunction with the scheduler either. I plan to work out why, but that is going to have to wait until after go-live.

Yes there's -b in the pf.

Posted by ChUIMonster on 12-May-2015 10:02
Then it is probably just because you are not redirecting the output.

Put OUTPUT TO "logfile". at the top.

[collapse]On 5/12/15 10:56 AM, James Palmer wrote:
Reply by James Palmer

Thanks Tom. I'm using prowin because _progres isn't working in conjunction with the scheduler either. I plan to work out why, but that is going to have to wait until after go-live.

Yes there's -b in the pf.

Stop receiving emails on this subject.

Flag this post as spam/abuse.



-- 
Tom Bascom
603 396 4886
tom@greenfieldtech.com
[/collapse]
Posted by Frank Meulblok on 12-May-2015 10:08

"Win Server 2012 R2 box. Progress 11.5 64 bit. "

"I'm using prowin because _progres isn't working in conjunction with the scheduler either"

I think you'll want to focus on getting the _progres to work. Otherwise you risk running into this:

knowledgebase.progress.com/.../Running-a-prowin32-exe-as-a-background-process-causes-extremely-slow-login-times-in-Windows

Which is really quite nasty, especially if your server is going to be used as a terminal server.

Posted by James Palmer on 12-May-2015 10:35

Thanks Frank. Not noticed any problems in testing, but I will bare that in mind.

Posted by Rob Fitzpatrick on 12-May-2015 10:35

Hi James,

On a somewhat-related note, you should read this:

Self Service client launched by Windows Task Scheduler runs much slower than same job started outside of Task Scheduler on Windows 2008 or 2008 R2

Clients you launch from Task Scheduler will, by default, have lower priority than those launched from the shell.  The article provides a workaround.

Posted by James Palmer on 12-May-2015 10:37

Thanks Rob - yes I'm aware of that foible :)

Posted by James Palmer on 14-May-2015 03:18

So this has raised its ugly head again. Most of our batch jobs use "Redemption" (a com object plugin for Exchange) to send email reports. I cannot get this working in the scheduler at all. It works fine when run from proenv. In the scheduler session it says the Redemption.dll has not been registered yet. I'm guessing this is the same Session 0 isolation problem. Would really appreciate any input people have because this is going to be a complete show stopper now.

Posted by tbergman on 14-May-2015 05:55

Do you have the 64 bit version of Redemption installed?

Posted by James Palmer on 14-May-2015 06:10

Yes got both on. Although if I unregister the 32 bit dll the cmd prompt version stops working as well. So it seems the scheduler is trying to run 64 bit and failing, but the command prompt is running 32 bit and succeeding. Maybe?

Posted by tbergman on 14-May-2015 06:59

That's very weird about the unregister - The version used should be dependent upon the bitness of the Progress session.

While I don't use Redemption, we do a fair amount of other COM on Server 2012 R2 with the scheduler. The link below is something we've had to do since Server 2008 to get things like Excel to work properly from a service. Perhaps this will help. Basically, all you need to do is create a folder named C:\Windows\System32\config\systemprofile\Desktop. That's for 64 bit processes. For 32 bit you may also need C:\Windows\SysWOW64\config\systemprofile\Desktop.

https://social.msdn.microsoft.com/Forums/en-US/b81a3c4e-62db-488b-af06-44421818ef91/excel-2007-automation-on-top-of-a-windows-server-2008-x64?forum=innovateonoffice,

We also do a couple of other things that probably are not needed for this particular problem but they solve other issues for us.

We disable UAC. That's under Control Panel - User Accounts - Change User Account Control setting

We also set a local policy called “User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode” to “Elevate without prompting”. This is set using the secpol.msc tool.

Tom

Posted by James Palmer on 14-May-2015 07:13

Thanks Tom. I appreciate the effort. That hasn't helped me unfortunately.

I've also tried forcing it to use the 32 bit and 64 bit cmd lines and that's also giving the errors so I'm thinking the dll unregister thing is a red herring.

Posted by James Palmer on 14-May-2015 09:11

Fixed it. Phew. Turns out I had to explicitly grant the user rights to log on as a batch job, to create a token, and then (rather counter-intuitively) remove the tick from the Run with highest privileges box on the task itself.

This thread is closed