As part of a new project, we are migrating our Toad automations from Windows 7 desktops to Windows Server 2012 R2 VMs.
With that, however, comes an issue where the service account that runs the Toad automations isn’t allowed to remain logged in on the Windows Server 2012 desktop for more than 48 hours - this is a corporation-wide GPO setting and cannot be changed.
Where we’re having a problem is that the TDP Scheduled Task will appear to execute, but no output is produced, and the log is not updated.
If I leave the service account logged in, and simply ‘lock’ my session, everything works as expected - just like our Windows 7 machines - but in 48 hours, the account is automatically logged out, and we’re back to either having to login, or getting no output.
From my research, it appears that starting with Windows Vista (yeah, I know…), Microsoft implemented Session 0 Isolation, meaning all interactive logins start at Session 1 and up, and Session 0 is reserved for system and service use only, including Scheduled Tasks configured with the option of ‘Run whether user is logged on or not’. The problem is that Session 0 does not have an interactive desktop, so any processes that are expecting a UI response, or even the ability to create a UI, seem to fail, which would appear to include Toad.
That said, I’ve read in various threads on here and around the net that folks have gotten this to work correctly, but so far - after several weeks - I haven’t been able to figure it out, and I’m hoping one of you kind folks will be able to point me in the right direction.
I had this problem for over a year, & I finally cracked it with the help of Toad support along with trial & error. Make sure that your scheduled tasks that are created from the Toad Automation are configured as “Windows Server 2012 R2”. Also, make sure to select the checkbox “Run with highest privileges”. These settings are found at the bottom of the Task Scheduler Library in Server 2012 under each task. Be sure the radio button for “Run whether user is logged on or not” is selected but that should be default.
Please note, every time I create a new Toad Project & Automate, it creates a new schedule task configured as Windows Server 2008 by default without the highest privilege. I have to explicitly change these 2 default settings on new projects.
I've actually got my task configured exactly as you described, but it still won't run:
Oddly enough, the task scheduler history Last Run Result indicates 'The operation completed successfully. (0x0)', but nothing was generated and the log file is still from the previous day when I was leaving the account logged in:
Look in the event viewer. Perhaps the job is starting but there is something wrong with launching TDP. If this is the case you might see something in the event viewer. Have you started TDP on the server to know the license has not expired, etc?
I’m not finding anything in the Event Viewer related specifically to Toad or created by Toad, and the TaskScheduler > Operational log has this:
Task Scheduler successfully completed task “<…> - Daily <…> Tech” , instance “{806c7f0b-ee5b-4371-ba1d-e6f113d5e7ac}” , action “C:\Program Files (x86)\Dell\Toad Data Point 3.8\toad.exe” with return code 0.
Which would seem to indicate that the job ran fine.
However, the automation creates two files in C:\temp and leaves them there while also emailing them - neither of which have occurred.
The license isn’t expired, and I’ve verified that the task works fine so long as I leave the service account it runs under logged in - problem is, I can’t do that for more than 48 hours at a time.
The only other thing I can think of is installing Toad Intelligence Central and scheduling automation scripts with that. It does not use the windows scheduler and logs on the user when running the script and then logs it off. The Community edition is free and can be downloaded here.
From working with TIC CE, it only let me add Toad for Oracle jobs, and last I heard TIC didn’t support Windows Authentication to SQL Server - which is an issue, since we only support Windows Authentication, hence the service account.
I would open a case with support since you have a valid license. They called me & we did have a remote collaborative session. The one thing we discovered when I migrated from the old Server 2008 (TDP3.4) to the new Server 2012 (TDP3.6), was a Windows roaming profile configuration issue after installing toad on new server & importing the database connections from the old server “My Connections.xml” file. We started getting more meaningful error codes when support had me turn the TDP logging to the greatest level of detail. I suspect you are already doing this.
When I migrated to the new server and started importing the Database Connections from one server to another, the roaming profiles were using DB connections from the import file “My Connections.xml” from a shared folder where all .tas projects and supporting files were being stored. Actually, Toad would grab that file and copy it to each c:\users***\username***\AppData\Roaming\Quest Software\Toad Data Point 3.6\ folder rather than making a “Connections.xml” file that is needed for this version of TDP. Some of the DB connections were missing as projects were developed/migrate over time. The Connections.xml file subsequently need to be copied to each user folder including the c:\users***\default***\AppData\Roaming\Quest Software\Toad Data Point 3.6.
We also continued testing and re-scheduled the project via TDP. I was still having issues and discovered the target file for this particular project was a .xls file created with DB queries that are exported correctly but the email was failing. Checking the log file generated, we discovered we needed to create an “Automation” subfolder under each user folder. Support believed that since these projects were first developed under older version, they were not using the “Automation Publishing” subfolder that is now used with the newer version (or vice-versa) if a new project was created. This “Automation” subfolder subsequently needed to be created to each user folder including the c:\users***\default***\AppData\Roaming\Quest Software\Toad Data Point 3.6.
The lesson I learned on supporting a multi-user environment for the same projects is to keep all of the AppData in-synch.
I am guessing you probably tried this as you did respond to a thread I created back in May when I resolved with the help of support. I thought I would post this in case you missed it.
See if your IT can get you a service account to use for the jobs that can stay logged in (no 48 hour requirement). They have to have accounts like this or they would have to restart their own stuff every 48 hours. You can develop the automation with your account but you must schedule it with the service account. If you have a lot of jobs already scheduled, it is a bit of a pain to have to end everything scheduled and reschedule as the service account, but you only have to do it once.
