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).
- 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.
- it just works like every other Windows application to printer process.
- Can be used with any of the reporting types within ERP–Crystal, SSRS, bartender (technically), and outbound EDI.
NOT A PRO:
- Requires an active user session at the time the report is scheduled to print/print preview to completely process.
- 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.
- 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.
- Every printer that users need to be able to print to needs to be installed on every workstation.
ADDITIONAL NOT A PRO:
- 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.
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.
- 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).
- 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.
- The printers are installed once per Epicor server instead of on every workstation.
- Does not require an active user session at the time the report is scheduled to print to completely process.
- 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.
- 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:
- Can’t be used with Crystal reports.
- 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.
- 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:
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
Konica Minolta: http://www.biz.konicaminolta.com/solutions/universal_print_driver/
Label printers: https://www.seagullscientific.com/drivers/windows-printer-drivers/
Others? Use your internet search engine of choice and search for “[make of printer] universal print driver”
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.
- 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.
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.
- 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!
- 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):
- ERP RELEASE: You are using ERP 10.1.600 as that is what I have already installed on my homelab VM.
- 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.
- 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:
- RDP into HV-WIN2008R2SVR with a user account that is a member of the local administrator group.
- From the Windows run line, enter “inetmgr” (without quotes) and press ENTER.
- Expand [NAME OF SERVER] from the left pane (e.g. HV-WIN2008R2SVR) and click on Application Pools.
- 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:
- 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.
- 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.
- 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:
- Click the Windows button, and search for Devices and Printers.
- 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.
- 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:
- Log into the client with a security manager account.
- Navigate to System Management > Reporting > Printer Maintenance.
- 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.
- While logged in with a security manager account, navigate to System Setup > Company / Site Maintenance > Company Maintenance.
- Click on Email and Reporting tab.
- In the Print Options section, in the SSRS Printer Option dropdown, select Client and Server Printing if it is not already.
- Save your changes.
- 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.
- From the desktop of the hv-win2008r2svr, launch the Epicor Administration Console.
- Expand Server Management > [Name of server]
- Click on the name of the appserver process.
- From the Actions panel, click Recycle IIS Application Pool.
- 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.
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:
- 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: 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: 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.
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.
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?
- 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!
- 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.
- Browse to the server that has the shared printer from step 1 and simply connect to the printer.
- Restart all of the appserver machines (just in case).
- Enable all of your taskagent configurations.
- 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.
**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.