Let's talk about SSP (server-side printing)

[aidacra (Nathan your friendly neighborhood Support Engineer)]

Epicor ERP 10.1+ has two different high-level printing mechanisms: client-side printing and server-side printing. Support has received a number of cases regarding server-side printing and wanted to provide some additional context for those that are considering it.

Let’s go over the high-level aspects to both client-side and server-side printing from an ERP perspective to start.

BACKGROUND ON PRINTING MECHANISMS:

CLIENT-SIDE PRINTING OVERVIEW:
Think of this as your “how every Windows programs has worked since the beginning of time” option. **Any printer that is installed on the user’s workstation is available to be used with client-side printing. (see the end of more detail about the **) If you can print it XYZ printer within Notepad, you can use it as a client-side printer within Epicor ERP. You can use this with Crystal reports, SSRS reports, outbound EDI reports, and Bartender reports (though the impact on bartender is really zero in practice).

PRO:

1. If the printer is installed on a workstation and it can be used in any other Windows program, it can be used as a client-side printer.
2. it just works like every other Windows application to printer process.
3. Can be used with any of the reporting types within ERP–Crystal, SSRS, bartender (technically), and outbound EDI.

NOT A PRO:

1. Requires an active user session at the time the report is scheduled to print/print preview to completely process.
2. There is a polling process that executes every X seconds from the client-side so there is increased processing time as the report is returned to the client.
3. For reports that process very quickly (e.g. labels), the added 0.000000000001 to ~3 seconds of processing time that the polling introduces can make up 50%+ of the total time to printer.
4. Every printer that users need to be able to print to needs to be installed on every workstation.

ADDITIONAL NOT A PRO:

1. RDP printer redirection. While the Easy Print printer redirection since Windows Server 2008 has made it much easier to implement, the generic driver isn’t optimized for performance–it just works.

Ways to optimize? Well, lots of articles online that suggest this or that. Every article I’ve found and sent to a customer hasn’t exactly made a night or day difference.

• http://techgenix.com/how-configure-microsoft-rds-universal-printing/

Epicor’s single-tenant hosting solution uses a product called Parallels with their 2x client and RAS printer redirection product to improve performance for when we don’t install the printers on the appserver server (and connect to the customer’s environment via VPN), and install the printers for every user on the RDS server.

Parallels RAS Improves and Simplifies RDP Printer Redirection Issues

NEUTRAL?:

1. For reports that take two hours to process, the added 0 to 30 seconds delay that the polling mechanism introduces may not be that big of a downside considering the added complexity of server-side printing.

SERVER-SIDE PRINTING OVERVIEW:
Think of this as “any printer that is installed, configured, and shared in a very specific way on the Epicor servers” option. When this is used, as soon as the print request is done rendering on the Reporting Services server, the appserver passes the request to the designated printer. Just because one can use XYZ printer within Notepad, it doesn’t mean that it can be used as configured as a server-side printer within Epicor ERP. You can use this with SSRS reports, outbound EDI reports, and bartender reports (though, the impact on bartender is really zero in practice).

PRO:

1. It is almost always faster than client-side printing as the delay that the polling mechanism introduces for client-side printing isn’t involved. As soon as the report is done rendering with the SSRS instance, the appserver submits it for printing to the printer in question.
2. The printers are installed once per Epicor server instead of on every workstation.
3. Does not require an active user session at the time the report is scheduled to print to completely process.
4. For users that use an RDP client to access the client, one doesn’t have to use the RDP redirected printers which, in practice, is sub-optimal from a performance standpoint without optimization.
5. Can be used with outbound EDI as of 10.1.600.x so that it doesn’t require an active user session, but, technically, one doesn’t need a server-side printer for this–it just uses this mechanism.

NOT A PRO/NEUTRAL:

1. Can’t be used with Crystal reports.
2. It is more involved to configure than client-side printing. I go through the process of configuring a server-side printer later in this post.
3. Can’t reference an IP address in server-printer maintenance; it needs to be shared from some machine and that share path needs be entered in printer maintenance.

Printer maintenance requires a UNC path to a shared printer

Cannot directly reference the IP address of the printer

GUIDELINES TO IMPLEMENTING SERVER-SIDE PRINTING IN YOUR ENVIRONMENT:

1. Always use the printer manufacturer’s universal print driver instead of one specific to the model. This is always true unless we are talking about label printers, then always use the driver from Seagull Scientific for that make label printer even if you aren’t using Bartender. No exceptions, please.
   HP printers: http://h20564.www2.hp.com/hpsc/swd/public/readIndex?sp4ts.oid=4157320
   Lexmark: Universal Print Driver | Lexmark United States
   Konica Minolta: http://www.biz.konicaminolta.com/solutions/universal_print_driver/
   Ricoh: http://support.ricoh.com/bb/html/dr_ut_e/rc3/model/p_i/p_i.htm
   Label printers: https://www.seagullscientific.com/drivers/windows-printer-drivers/
   Brother: Download and install the Brother Universal Printer Driver for PCL
   Others? Use your internet search engine of choice and search for “[make of printer] universal print driver”

2. All server-side printers that you wish to use within Epicor must be installed on the actual Epicor server which has the appserver process that is used with the taskagent configuration under the Windows user account of the user on the IIS application pool for the appserver. Log into the Epicor server with the Windows user that is on the application pool for the appserver.

• The printer also must be shared from the same Epicor server.

NOTE: Don’t use spaces in the share name, please. Hyphens and underscores are your friends.

3. When using autoprint BPMs, always start by making sure to configure your BPM to run QUEUED so that it processes like a client-side printing process instead of IMMEDIATE which processes like a server-side printing process until you know your BPM autoprints successfully. Once you are really, really sure, then change it to IMMEDIATE and retest. If there are any issues, you know where to look next. Even so, I always leave my autoprint BPMs as QUEUED.

Cheat sheet:
QUEUED=how every print request you have submitted from within Epicor ERP up to this point behaves.
IMMEDIATE=server-side printing AND server-side processing. I touch on this in a response to this article with the difference between IMMEDIATE RUN REQUEST vs SERVER-PRINTING vs IMMEDIATE PRINTING.

NOTE: IMMEDIATE from the BPM perspective means it processes on the appserver that the client is connected to when the BPM is triggered, not the one that is configured to handle background processes unless you only have one appserver process which handles both interactive (aka: user sessions) and background processes (aka: things that flow through the system monitor). If you only have one appserver process in production, you should correct that by adding another one just for background processes.

4. Since we are talking about IMMEDIATE processing, every appserver process connected to the Epicor database must be configured for SSRS printing in the Epicor Administration Console, and the same web service URL, root folder, and report database name must be used–if you have interactive and dedicated appservers already and have not configured SSRS against the interactive, that would need to be completed.

This is a screenshot of my dedicated background processing appserver > EAC> appserver Server Configuration > Application Server > Reporting Services tab. This is on a server named hv-win2008r2svr.

This is a screenshot of my interactive client appserver > EAC> appserver Server Configuration > Application Server > Reporting Services tab. This is on a server named hv-win2016svr. They are pointing to the same web service URL, root folder, and report database name. Good!

5. Understand that it is possible to be successful without following some of the guidelines above, and some of them can actually be completely ignored if you are planning on using certain aspects of server-side printing. No, I will not list out all of the ways to ignore my advice above. You will increase your chances of success if you follow them, and if you run into problems then call support–we’ll tell you to do the above anyway, so might as well start there.

HOW TO ACTUALLY ADD A SERVER-SIDE PRINTER THAT ONE CAN ACTUALLY USE IN ONE’S ACTUAL ENVIRONMENT
ASSUMPTIONS I’M GOING TO MAKE(adjust as appropriate for your situation):

1. ERP RELEASE: You are using ERP 10.1.600 as that is what I have already installed on my homelab VM.
2. MACHINES INVOLVED:
   • You have a dedicated interactive session appserver process named ERP101600 that handles interactive sessions on a server named hv-win2016svr.
   • You have a dedicated printing appserver process named ERP101600Print that handles all background processes on a server name hv-win2008R2svr.
   • You have a client workstation that is running the client on a machine named hv-win10.

NOTE: the location of the client itself doesn’t matter at all and most of my screenshots are from my client on the hv-win2016svr server.

3. PRINTER: You have a BROTHER MFC-7860DW that has the fancy double-siding printing in majestic 600 DPI monochrome with the built-in scan-to-FTP server ability as it’s the only printer I have access to at home. This printer is installed on and shared from hv-win2008R2, because, my server-side print requests process through the ERP101600Print appserver process.

NOTE: Only have one taskagent configuration and you are on at least 10.1.400*? Please see the end of the post for more context as to why that isn’t recommended. This text will be hidden

~DETERMINE THE USER ACCOUNT ON THE ERP101600PRINT WORKER PROCESS(AKA: APPSERVER PROCESS) ON THE HV-WIN2016SVR SERVER:

1. RDP into HV-WIN2008R2SVR with a user account that is a member of the local administrator group.
2. From the Windows run line, enter “inetmgr” (without quotes) and press ENTER.
   
3. Expand [NAME OF SERVER] from the left pane (e.g. HV-WIN2008R2SVR) and click on Application Pools.
4. Locate the ERP101600Print application pool. Note the identity/Windows user account on the process. In my screenshot, it would be homelab\service-account
   
   

~LOG INTO HV-WIN2008R2SVR WINDOWS SERVER WITH USER ACCOUNT SET AS IDENTITY ON ERP101600Print WORKER PROCESS:

1. RDP into HV-WIN2008R2SVR with a user account that was set as the identity for the appserver process in the previous section.
   

~DOWNLOAD AND INSTALL UNIVERSAL DRIVER FOR BROTHER MFC-7860DW printer on HV-WIN2008R2SVR WHEN LOGGED IN AS HOMELAB\SERVICE-ACCOUNT.

1. I am going to make another assumption that people are familiar with this activity and not document it.

~INSTALL BROTHER MFC-7860DW printer on HV-WIN2008R2SVR WHEN LOGGED IN AS HOMELAB\SERVICE-ACCOUNT.

1. I am going to make another assumption that people are familiar with this activity and not document it. Every printer is a little different.

~SHARE PRINTER ON HV-WIN2008R2SVR SERVER:

1. Click the Windows button, and search for Devices and Printers.
   
2. Right-click on the printer that was installed, and select Printer properties.

NOTE: I already had these screenshots from a Windows 2016 server, so if you are using Windows 2008R2 it will look a little different.

3. Click on Sharing tab.
   a. Check the box for Share this Printer.
   b. Share name: Something meaningful without spaces in the name.
   c. Render print jobs on client computers should be enabled as a general best practice in a LAN environment, but it can decrease performance in a WAN environment. You may need to experiment for the best configuration for your usage.
   d. click Apply then OK.

~CONFIGURE THE PRINTER WITHIN ERP CLIENT:

1. Log into the client with a security manager account.
2. Navigate to System Management > Reporting > Printer Maintenance.
   
   
3. File > New
   

• Printer ID: Something meaningful without spaces in the name.
• Description: Something meaningful, spaces OK.
• Network Path: \[Epicor Print Server Name][ Shared Printer Name] .
• Make sure that SSRS Printer is checked.
• If the printer is not a Color printer, deselect Color.
• Make any other adjustments to margins, paper size, etc as needed.
• Press Save and close out of the Printer Maintenance Window.
  
  

~CONFIGURE COMPANY MAINTENANCE RECORD TO ALLOW FOR BOTH CLIENT AND SERVER-SIDE PRINTING.

1. While logged in with a security manager account, navigate to System Setup > Company / Site Maintenance > Company Maintenance.
   
   
2. Click on Email and Reporting tab.
3. In the Print Options section, in the SSRS Printer Option dropdown, select Client and Server Printing if it is not already.
   
4. Save your changes.
5. Close out of the client.
   NOTE: Whenever a change is made to the Company maintenance record, it should be assumed that in order for users who are currently logged in to see the change that they would need to log out of the session and log in to create another one.

~RECYCLE THE ERP101600Print APPSERVER ON hv-win2008r2svr (this just makes me feel better; it isn’t actually needed):

NOTE: If you are doing this in a production environment, make sure that there aren’t any active tasks in the system monitor before recycling the appserver process.

1. From the desktop of the hv-win2008r2svr, launch the Epicor Administration Console.
   
2. Expand Server Management > [Name of server]
3. Click on the name of the appserver process.
4. From the Actions panel, click Recycle IIS Application Pool.
   
   
5. When prompted “Are you sure?”, click Yes.
   

~PRINT REPORT FROM WITHIN THE CLIENT:
Video of me and my happy helper Buttercup showing the world that server-side printing works.

TROUBLESHOOTING:
The key to understanding most IT issues boils down to knowing

who is doing what where, when (and why, but, you are the why in this situation)

Let’s take server-side BPMs out of the equation for a moment, and just focus on the manual printing of a report to a server-side printer:
WHEN: when the user submits the print request, within the number of seconds that the processing delay is set to on the system agent
WHERE: the appserver process that handles printing requests. If you have more than one, then, all of them. Make your life easier at first and disable all but one until you get the one server processing successfully.
WHAT: All of the things that Windows does and needs when a print request is submitted. It’s a relatively complex topic and we take it for granted that it usually just works. Some additional resources on this topic:

• How Printing Works in Windows 7 - Windows 7 Tutorial
• https://www.lynda.com/Windows-Server-tutorials/Understanding-how-Windows-printing-works/171574/360289-4.html ← this isn’t a free resource, and I’m not affiliated with the provider. It just came up in a search and it does look useful.

WHO: The user account that is set as the application pool identity on the IIS worker process for the appserver process that the task agent(s) is/are pointing to

With server-side autoprint BPMs in the mix:
WHEN: when the user triggers the autoprint BPM
WHERE: the appserver process that the client that the user who triggered the autoprint BPM is connected to.
WHAT: All of the things that Windows does and needs when a print request is submitted.
WHO: The user account that is set as the application pool identity on the IIS worker process for the appserver process that is handling that user’s client connection.

Need more info?
ERP APPLICATION HELP TOPICS:

• Server and Client Printing
• Printing Outages

NOTE: We have LOTS of troubleshooting steps in application help. Check it out.

Still not enough?! Alright, two more. Then, maybe one more bonus.

ISSUE 1:

• ISSUE: Say that you are getting a number of tasks in the Active Tasks tab of the System Monitor, with a status of “Pending” (capital P lowercase ending) instead of “PENDING” (all capital letters).
• INFORMATION: This occurs when an IMMEDIATE run BPM is triggered, but couldn’t be processed for some reason–most likely that the interactive appserver wasn’t configured for SSRS printing.
• RESOLUTION: change your autoprint BPMs to QUEUED instead of IMMEDIATE or configure all appservers in your environment to have the same SSRS settings in the EAC > Application Server Configuration.

ISSUE 2:

• ISSUE: Say you are getting something like this:
  Program Ice.Services.Lib.RunTask raised an unexpected exception with the following message: RunTask: Settings to access printer '\\hv-win2008r2r2\Brother_MFC-7860DW_Printer' are not valid.
• POTENTIAL RESOLUTION 1: This is a generic error that means “hey, it didn’t work”. Start with reviewing everything in the guidelines and implementation sections. If you thought you could get away with XYZ thing that deviates from what was recommended, go back to do it the way that I said and try again.
• POTENTIAL RESOLUTION 2: On the server that you installed and shared the printer, download the following client printer helper tool our development team created for an unrelated reason from: https://1drv.ms/u/s!Arusj_dIaLAVg0VFrVWzYikhH_jD . Download and launch the .exe, then click Collect. Change what is in Printer Maintenance to match what is displaying in the Client Printer Information program.
  
  

NOTE: As you can see, my paper source kind doesn’t match what is appearing in the Client printer and it works fine–only match everything up at this level if you have eliminated other causes.

NOTE: In this case, it was because I mistyped my server name

• ADDITIONAL INFO 1: Anything that shows up in the System Monitor has a record on ice.systask and at least one ice.systaskparam. If one were to query the ice.systask table for the report that threw an error to find the systasknum. Then, queried the ice.systaskparam table to see all the parameters that the report was submitted with. You’d find that there are three parameters that are interesting as it relates to printing: PrinterName, RptPageSettings, and RptPrinterSettings. You can use this to determine the parameters that ERP is passing to the printer match up with what the printer is expecting.

NOTE: This is why the generic driver is recommended as some drivers need additional parameters passed to complete the request than what we can pass by default.

CONCLUSION:
Getting server-side printing functioning in an environment is definitely possible and when properly implemented, is incredibly useful for many reporting situations where client-side printing has some limitation.

We talked about all the good things
and the bad things that may be

involved in configuring and working with server-side printing. It isn’t as complex as it may appear if you remember who is doing what where, when if you run into an issue.

APPENDIX:
Let’s revisit guideline number 2 for a moment:

How does this really work when multiple taskagent configuration servers? One shared printer and printer record per server? Absolutely not.

Let’s assume that:

• you are making full use of the three taskagent configurations per database functionality within ERP 10.1+
• each taskagent configuration is on its own server
• there is a dedicated appserver process on that same server as each taskagent configuration.
• you actually want to use IMMEDIATE run BPMs on your X number of interactive appserver servers, and thankfully SSRS printing is already enabled on all appservers
• the application pool identities are the same on every ERP appserver application pool.

How could you go about implementing this?

1. Pick one taskagent server to go through the process laid out above. Fully test it. If you need to disable two of the taskagent configurations to control which server/appserver/taskagent processes a request, do so. It works there, woohoo!
2. On every other server that has an appserver process (the two remaining task agent servers, the X number of interactive appservers, etc), log in with the same user account that is set as the application pool identity on the one taskagent server you already got working with server-side printing.
3. Browse to the server that has the shared printer from step 1 and simply connect to the printer.
   
4. Restart all of the appserver machines (just in case).
5. Enable all of your taskagent configurations.
6. Server-side print anything you want.

NOTE: You’d approach label printers in a similar way. Share it from workstationA. Connect to it while logged into serverA while logged in with the application pool identity user. Repeat for every appserver server in your environment. Create a printer record pointing to that shared label printer. Restart all of the appserver servers. Remember to only use Seagull Scientific drivers, and use the Client Printer tool if you run into an issue.

---

* Only have one taskagent configuration and you are on at least 10.1.400? Please see this post for some more context as to why that isn’t recommended: Epicor ERP 10.1 Task Agent Configuration Implementation Options - Experts' Corner - Epicor User Help Forum.
**depending on the release/update of ERP running, you’ll want to avoid the possessive 's in printer names (e.g. Sally’s Printer = where Sallys Printer = ). Also, depending on the release/update, you’ll want to make sure that every client printer is always online before launching the ERP client otherwise

Opinions expressed are solely my own and do not express the views or opinions of my employer.

[ckrusen (Calvin Krusen)]

Awesome article! Thanks so much.

Several times you refer to the “3 seconds” delay when printing to a non-server side printer. I’ve never seen a print job render in anything under 15 seconds (maybe 10 at best). Seems that it takes at least 5 seconds from when it is first submitted, before it even becomes active. And another 5 to 10 after it completes(moves from active tab to history tab), until it is sent to the printer (or preview window). Is this normal?

Also, does having the System Monitor window open slow down the time between when it is finished processing(goes from active to history tab), and it renders? Maybe it’s a psychological thing (“watched pot never boils”) that just makes it seem to take longer. But seems like it doesn’t render until I close the SysMonitor.

Is there any advantage (or disadvantage) to setting up a printer that is connected to a workstation (and shared on the network) as a server side printer? Besides other users being able to print to it. If that workstation is disconnected, would E10 show an error to the user that initiated the print job?

Finally, between pts 4 and 5 of the section "GUIDELINES TO IMPLEMENTING SERVER-SIDE PRINTING IN YOUR ENVIRONMENT’ you refer to 2 screenshots that appear to be missing.

[josecgomez]

Moved to EC thanks @aidacra!

[aidacra (Nathan your friendly neighborhood Support Engineer)]

@ckrusen

Finally, between pts 4 and 5 of the section "GUIDELINES TO IMPLEMENTING SERVER-SIDE PRINTING IN YOUR ENVIRONMENT’ you refer to 2 screenshots that appear to be missing.

Thank you, I have added those screenshots. I was drafting this in Evernote, and I had to manually copy/paste each image here afterward --I missed a few

@ckrusen

Several times you refer to the “3 seconds” delay when printing to a non-server side printer. I’ve never seen a print job render in anything under 15 seconds (maybe 10 at best). Seems that it takes at least 5 seconds from when it is first submitted, before it even becomes active. And another 5 to 10 after it completes(moves from active tab to history tab), until it is sent to the printer (or preview window). Is this normal?

The “3 seconds delay” I am referring to is technically the processing delay set on the System Agent record within the application–it could be any value between 0 and 9999 seconds. It should never be set to less than 3 seconds and setting this higher than 3 seconds is just added additional latency to any IMMEDIATE run request like most reports, which is why I just referred to it as the 3-second delay–never set it lower and doesn’t make sense to set it higher. Fun fact, in E905 and earlier, if one set the processing delay to less than 3 we treated it as 15 seconds so setting it to 2 seconds actually is a longer delay than setting it to 3. Maybe not really fun.

This processing delay really is the polling frequency of the task agent configurations. When the taskagent configuration starts up, it makes a connection to the appserver to determine a number of things from the database and the frequency in which it checks for new requests to process is this processing delay. A value of 3 here means that every 3 seconds after the taskagent configuration is started it will check to see if there are any scheduled/immediate run requests that need to process within that cycle. If not, it just ends the cycle. If so, it will move to ACTIVE up to the number of concurrent tasks set on the taskagent configuration and any number of tasks exceeding that concurrent tasks threshold is set by that taskagent configuration as “PENDING” (all capital letters) in active tasks.

All of this context is to say that sometimes this polling frequency has a huge impact on total “submit print to actual printer time” and other times, it doesn’t. If your processing delay is anything other than 3, I would recommend changing it and restarting your taskagent configurations.

Also note that sometimes the line between server-side printing AND IMMEDIATE printing AND IMMEDIATE RUN REQUESTS can be a little confusing–IMMEDIATE printing requires server-side printing to be enabled but they are not the same. This polling frequency applies to all background processing tasks (printing, processes, etc) where it wasn’t triggered by an IMMEDIATE queued autoprint BPM even if server-side printing is enabled. IMMEDIATE queued autoprint BPMs (which require a server-side printer to submit it to) will immediately submit the report to the server as soon as it is done being rendered. IMMEDIATE RUN REQUESTS aren’t immediate in the technical sense–in fact with the exception of autoprint BPMs set to IMMEDIATE, everything else that is processed through the System Agent is really asynchronous and when the system will start processing them is based on what the processing delay is on the System Agent.

@ckrusen

Also, does having the System Monitor window open slow down the time between when it is finished processing(goes from active to history tab), and it renders? Maybe it’s a psychological thing (“watched pot never boils”) that just makes it seem to take longer. But seems like it doesn’t render until I close the SysMonitor.

Let’s sidestep whether or not it’s in your head for a moment and instead make some adjustments to return completed reports back to your workstation sooner regardless.

If you open your System Monitor > Actions > Configurations. There are three values:

I am going to talk about them out of order:

• Priority: By default, it is 3 seconds. When the user session submits a print request, it starts this priority client to appserver polling mode so it checks “hey any print requests that belong to my workstation method on the company maintenance record, are you done?” If so, it pulls the request back to the client.

NOTE: Always change the workstation method to literally anything other than the default for every company. My preference is Machine Name + Domain User as it is most likely to be the most unique.

• Duration: By default, it is 15 seconds. This is how long the priority mode lasts. What this really means is that every 3 seconds, for 15 seconds, the System Monitor will try to return back to that client any print requests that complete within that 15 second period.
• Normal: By default, this is 30 seconds. If the System Monitor isn’t in “priority” mode, it is how frequently the system monitor polls for reports to bring back to this client session. That means that the System Monitor will only check for reports to bring back to the client every 30 seconds.

So for client-side printing, if your report takes 16 seconds to process on the server, you won’t see it be returned to the client until 45 seconds after the print request was submitted (the normal frequency starts as soon as the priority frequency ends–15 + 30 seconds).

For it to not be in your head, one of two things would need to be happening:

1. When the System Monitor is closed, the client makes a call to the appserver to return any completed reports back to the client
   OR
2. The polling frequency with the System Monitor being open is different than the polling frequency of the System Monitor not being open.

I tested this in 10.1.600 by adjusting my normal frequency to 60 seconds to make it easier for me to keep track of it, then enabling the UI trace and the Powershell get-content “UI trace file name” -Wait command against my UI trace file–I couldn’t duplicate either of the two things that could be causing what you are saying to happen. (the call I was looking for was ReportMonitor.GetRowsKeepIdleTime). This isn’t to say that at some point in the ERP history that we didn’t do one of the two things above, but, not seeing it in 10.1.600.

That being said, you can use your observation and just change how the system works with the System Monitor is open or closed and just make some adjustments to the three values above so you don’t have to worry about it. If you were to change the duration from 15 seconds to 60 seconds, for any report that takes less than 60 seconds to process from the perspective of the appserver process it will be returned to the client within 3 seconds instead of up to 44.9 seconds if the report were to take 15.1 seconds to process.

You can edit the values on the server’s copy of the .sysconfig file in the clientdeployment folder, so the next autoupdate of the clients brings down the updated values. You would change the SystemMonitorPriorityPollDuration to 60000 instead of 15000.

@ckrusen

Is there any advantage (or disadvantage) to setting up a printer that is connected to a workstation (and shared on the network) as a server side printer? Besides other users being able to print to it. If that workstation is disconnected, would E10 show an error to the user that initiated the print job?

If the printer is simply powered off, an error wouldn’t present to the user that submitted the request because from the ERP side, the report was successfully processed and we handed it off to the printer without the printer throwing an error–once we submit it to that printer, we have no awareness of what happens from that point on.

From the printer’s perspective, it is just sitting in the queue and as soon as the printer is powered on it will start processing.

If the workstation is off, I suspect you would see the following error message because we can’t hand off the report to the printer, and if anything goes wrong, it’s this error:
Program Ice.Services.Lib.RunTask raised an unexpected exception with the following message: RunTask: Settings to access printer '\\machinename\sharedprinter' are not valid.

And to test it, I enabled a taskagent configuration on my interactive appserver server (win2016) and powered off my dedicated taskagent server (win2008R2) with my Printer record pointing to my shared win2008R2 printer. Submitted a book listing, and it stayed in ACTIVE tasks as ACTIVE for much longer but after ~30 seconds it failed with this error:
Program Ice.Services.Lib.RunTask raised an unexpected exception with the following message: RunTask: Settings to access printer '\\hv-win2008r2svr\Brother_MFC-7860DW_Printer' are not valid. Stack Trace:

Not sure if either of the two behaviors would be considered advantages or disadvantages–I’ll let you decide that

[Chris_Conn]

Excellent content Nathan! Thanks for taking the time to compile and share!

[jeowings (Josh Owings)]

I agree Chris I have printed both of these at home his weekend. Will rescan to PDF at the office and tuck away on a OneNote section.

**Josh Owings ** | JR Automation | 22 S. Main St, Greenville, SC 29601

ERP Applications Manager | jowings@jrautomation.com | O: +1.864.397.9193 | C: +1.864.884.6587

Visit us on the web | Sign up for our e-newsletter

[Hally (Simon Hall)]

WOW! And this is why it’s worth supporting E10 Help on Patreon.

Thanks Nathan.

[hkeric.wci (Haso Keric)]

Amazing Content!

[Ottoette (Kim JS Doty)]

Fantastic stuff, Nathan, thank you.
I disagree on one point - in a WAN environment with terminal servers, “Render print jobs on client computers” is the kiss of death. Adds time and , it even stops AP checks from printing at all.

[aidacra (Nathan your friendly neighborhood Support Engineer)]

I clarified that point. Changed it to:

c. Render print jobs on client computers should be enabled as a general best practice in a LAN environment, but it can decrease performance in a WAN environment. You may need to experiment for the best configuration for your usage.

[RobHunter]

Thanks Nathan,

This is one of the best examples of technical writing I have seen.

[aidacra (Nathan your friendly neighborhood Support Engineer)]

[hkeric.wci (Haso Keric)]

@aidacra

POTENTIAL RESOLUTION 2 : On the server that you installed and shared the printer, download the following client printer helper tool our development team created for an unrelated reason from: https://1drv.ms/u/s!Arusj_dIaLAVg0VFrVWzYikhH_jD . Download and launch the .exe, then click Collect. Change what is in Printer Maintenance to match what is displaying in the Client Printer Information program.

@aidacra can you reshare this file, no longer available.

[hkeric.wci (Haso Keric)]

@aidacra

If the printer is a Color printer, deselect Color.

deselect?

[Evan_Purdy]

To make an option that is selected not selected. Like if a checkbox is currently “checked” deselect would mean unchecking it.

[aidacra (Nathan your friendly neighborhood Support Engineer)]

ClientPrinterInformation.txt (12.5 KB)
rename the attached to have an .exe extension and then execute.

[aidacra (Nathan your friendly neighborhood Support Engineer)]

@hkeric.wci

deselect?

I try to embiggen other’s vocabulary with perfectly crumulent words.

Embiggen (v.) Cromulent (a.) - The Simpsons have changed our language. - The Video Dictionary

[MikeGross]

This is superb Nathan! Thank you so much for putting this all together!!

[josecgomez]

LoL a famous line in my house was uttered by my wife who asked me to
“De-Thaw” the chicken so now we DeThaw things all the time.

[hkeric.wci (Haso Keric)]

wasnt nit picking on the word, but actually the action to take. hehe. Nathan dealing with support all these years, odd-sentences should no longer be cryptic for you.

Customer: “Server Broken Kaboom”
Nathan: “You mean, your Epicor App Server is down and you can’t connect to it?”

@aidacra: If its a color printer, deselect
Epicor Help: if its a color printer, select [ Indicates if the page should be printed in color. ]

I was wondering if there is a reason, if it is a color printer to deselect it, unless you meant if you want to print B&W deselect it?