5

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.

4
  • 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 6, 2015 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 6, 2015 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 6, 2015 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 6, 2015 at 17:24

4 Answers 4

3
+50

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.

2
  • This fixed the issue. Do you know why making it local will stop it from failing?
    – Elias
    May 12, 2015 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, 2015 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.

6
  • Yes, I had not mentioned that in the question, as we had tried a ton of different settings. I will now.
    – Elias
    Apr 30, 2015 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, 2015 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, 2015 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, 2015 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 4, 2015 at 16:35
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

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .