Task Scheduler problem

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.

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.

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.

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.

Task Scheduler problem

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. 

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.

RE: Task Scheduler problem

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

"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.

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

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.

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

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.

Do you have the 64 bit version of Redemption installed?

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?

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

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.

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.