4

Problem

Since the end of support is coming on July 14th for Windows servers 2003 we are moving all of our scheduled tasks to a Windows 2008 R2 server.

We use a Microsoft(MS) Access 2003(mdb) database to handle various backend processes that compliment user and customer interactions with our system.

One of the backend processes inside of MS Access, the cause of this question, is refusing to print when a user is not logged in.

The backend process populates a temp table, that is later used to populate the report that is supposed to print out. This report has an embedded query, linked images and a saved default printer.

The user that is executing the scheduled tasks is a domain user.

What We Speculate It Might Be

Session 0 Isolation - Access has a very small printing window that comes up that shows that you are on page X of N. This window cannot be interacted with. I feel that this may be the culprit, but everything we have tried has not worked to stop it.

What We Have Tried

  1. Created Desktop folder under system profile
  2. Made sure user is local admin with elevated privileges
  3. Manually running it while logged in (This works)
  4. Creating a miniature version of the application that does a small sample of the print job.
  5. Setting the scheduled task to run if the user is logged in or not. Regardless, the other processes in the MS Access database still run, and we get the empty report for the process that is not printing.

Current Workaround

We are keeping the domain user logged in.

Elias
  • 93
  • 1
  • 9
  • What exactly the scheduled task invoking? access.exe? script.vbs? A full set of screens for all the task options would be helpful. You wrote "we get the empty report" does that mean the job runs and prints, but produces a blank page? – Clayton May 06 '15 at 13:46
  • The scheduled task invokes an Access.mdb that walks through a list of functions. The report is simply an email that Access sends with the count of the number of pages printed. – Elias May 06 '15 at 14:27
  • what credential this task is running under? Could it be run under a credential, say, "system", that don't have access to the printer? I will relax the permission on printer to test. – strongline May 06 '15 at 16:36
  • We have a domain user that is an a local administrator group for the server this scheduled task is on. – Elias May 06 '15 at 17:24

4 Answers4

2

This problem can easily occur if you print to a session printer.

HKEY_Current_User\Printers\Connections (session printers)

vs

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Printers (local printers)

Any printer installed over a network share will fall in that category. Please try again with a printer installed with a local tcp/ip queue, that printer will be available system wide.

yagmoth555
  • 16,300
  • 4
  • 26
  • 48
  • This fixed the issue. Do you know why making it local will stop it from failing? – Elias May 12 '15 at 12:35
  • It's the task privilege, if its run under a system account or if the profile does not load correctly for the user the task is setupped to run under (if a roaming profile, blocked by the av or simply an unknown issue), you are sure the planned task can use the printer. (as for a session printer, the profile must be loaded) – yagmoth555 May 12 '15 at 12:50
1

Elias did you look at the scheduled task and check the box that says "run whether user is logged on or not"? Your issues sounds like it's not checked so when the task tries to run it can't.

Jon
  • 339
  • 2
  • 10
  • Yes, I had not mentioned that in the question, as we had tried a ton of different settings. I will now. – Elias Apr 30 '15 at 20:46
  • Okay. What does the history log of the job task say? What's the error code? Also have you tried a domain admin account for running the task just to check if it's a permission issue? – Jon Apr 30 '15 at 20:54
  • The history log shows 0 issues. We have it email us before and after the scheduled task closes as well. We have used a domain admin account, and besides leaving it completely logged in at all times, the issue persists. – Elias Apr 30 '15 at 21:37
  • So the run result is (0x0)? Is the printer in question able to print other scheduled tasks? If you haven't tried other jobs with that printer try it as a test. Last but not least, it may seem weird but I've seen issues with printouts when the printer in question is not set to the default printer. It's worth a shot. – Jon Apr 30 '15 at 22:09
  • Yes, it does return successfully. Regardless of what printer it is, the task does not print. We have tried mocking up a smaller version of the task to test, and it fails as well. Setting it as a default printer has not helped. – Elias May 04 '15 at 16:35
  • Are the printer, access mdb and task on the same server? Also server 2008 prefers printers that don't use kernel mode drivers. This might be what your referred to as session 0? Did you try upgrading the driver for the printer or temporarily use a different printer that is 2008 compatible? Have you looked at the event log under system or application to see any info on the print job? – Jon May 06 '15 at 22:08
0

It sounds like the printers themselves are not being detected when the process is running. Did you try to add some debug code to output to a file and see where it is getting caught up? I have found that processes that hang in VBA do not generate much information in the event viewer and typically require more error catching in the code.

I have seen the session 0 isolation issue and there are workarounds but all the examples I have come across were related to excel.

Here is an explanation of what is affected by the Session 0.

https://msdn.microsoft.com/en-us/library/windows/hardware/dn653293%28v=vs.85%29.aspx

Nick N.
  • 1
0

If you set UAC to the lowest setting does this improve the situation? To do this, Click Start, then Run Type msconfig into the run box/prompt and click OK Click the tools tab Click 'Change UAC Settings' and then click Launch Drag the slider to the bottom Ok the windows and restart the server

When you migrated the task, did you recreate the task? A great way of migrating tasks between 2003 and 2008 is to open the task scheduler on 2008, connect to the 2003 server and then export the tasks. You can then point task scheduler back to the 2008 server and import the tasks. If the task is running with a 0x0 result I would say the problem is outside of the scheduled task itself.

Can you confirm that the printer prints when a test page is sent? It might be an idea to compare the settings of the printer on the old and new servers if you have not already.

Evolutionise
  • 311
  • 1
  • 4