Today we are going to discuss some techniques on investigating Print server issues. The print server component has been around forever and is rarely changed. Also rare is print server issues actually being the print server component. Most issues I have been involved with ended up not being the print server itself but something more simple like print drivers, windows updates, .net updates, etc..

Anyhow, by the end of this blog you should have some good pointers are where to start looking when print server issues arise. Before looking at any issue we usually play 20 Questions. We try to narrow down the issue with “what, who, when, where, why, how” questions. Some good example questions are noted below

1. Is the version of the Print Server compatible with the version of Crystal Reports installed?
   1. Note: This also includes Designer and any other SAP related .net installs
2. Is the print server component the right version for Sage X3 version installed?
   1. Note: as rare as it is, a new build may come out and may not be compatible with older versions of Sage X3
3. Is the print server compatible with the OS server version?
4. What are the exact steps to duplicate the issue?
5. What reports does it happen to?
6. Is the report a custom report?
7. Is it happening to all user?
8. Is it happening to all endpoint folders?
9. When did the issue start?
10. Were any updates installed recently?
    1. This could be anything from OS updates, to driver updates, to virus scan updates
11. Is the print server properly configured in the Configuration Console?
    1. This could be anything from missing user to folders not published
12. If you have more than one print sever, are they all having the same issue?

I couldn’t quite get to 20 Questions, but I tried. I am sure there are plenty more questions to ask. If your investigating an issue its always best to get as much information as possible. More information is better than less because you can always toss out information you don’t need but you cannot use the information you do not have. After you gather all your information, where do you start. Good Question, it all depends on what the returned data information you get from whoever you interrogated for it. I will however be listing off a few areas that are easy to check and usually help in pointing you in the right direction (if not fixing the issue).

The first and easiest thing to check is the destinations. Sage x3 uses destinations to define what printer is used and what base print configurations you want to use and, if you have multiple print servers, which print server to go to. The destinations can also be assigned to specific users, reports codes, functions, or transaction selections. Were not covering destinations (don’t cry about it, I’ll write a separate blog about them later) except for the part in which we check them.

You can find destinations under Setup, Destinations, Destinations (GESAIM).  Here we would check each of the print destination records to make sure that 1.) they have the right print server hostname in the server field and 2.) that the correct port is listed. Should look similar to my screenshot

If the Print server information is incorrect, delete and recreate the destination(s). I told you this one was easy. The next one is a bit harder because the next one is testing the ODBC connections that are setup when the print server is installed. There are two areas to test. One from the print server and one from the application server where the main runtime is installed. If they are the same machine, then I guess you only have one to test. If you’re on any of the new windows OS machines, then you can right click on the windows start icon and select Control Panel then click on Administrative Tools and finally click on ODBC Data Sources (64-bit). It should load a screen like the screenshot below. Note: some older version of Sage X3 may only have entries in the 32-bit ODBC Data Sources.

You should see a list of ODBC data sources listed in this window and you are able to test each of them

If all is OK you have this message:

The data sources will usually be on the System DSN tab and you may have more than one connection and you may have a combination of 64 bit and 32 bit. If they are failing, the screen should tell you why its failing.

In my example it failed because I removed the x3 password and it could not authenticate.

If there ends up not being anything wrong with the ODBC connections, then there are still a few more things we can take a look at. The print server service can change to run in debug mode and this will generate additional logging for the print server. This can be helpful when its specific report codes that fail but no one seems to be able to tell why. First you have to stop the print server service.

Then you will want to add a new start parameter. The parameter is /d .  It has to be a lower-case “d”

Then start the service.

Launch a X3 Session and run the report. Once you have the error message displayed, you can go check the information in the generated file which is located here: 

…\EDTV2\EDTV7\srvedit\Temp and is called AdxSrvImp_Trace.log

In the log file on the first part of the trace should show the version, service name, and server name.

Then under SrvImpSuper_NewRptJob you should see the name of the report, the name of the destination, the database user, and the application port

If there is any incoherence in this log file, it’s certainly not a setting problem. Which means it’s nothing specific about the report or the way the report is being sent to the server (lame).

There is another way to check what the print server is doing. There is a mode called Console Mode. This allows you to view what the print server is doing in real-time via CMD. This is a more extreme function as I have not had to run this very often. Maybe like 4 times in 2 years. So, its not super common.

First thing we do is locate the print server service in the services application in windows. Once you find it, right click and go to properties. Your service name can be different from mine because its based on the install name given to the print server component when its installed.

Select and copy the highlighted area from the service properties. Paste to a notepad so you don’t lose it. Shut down the service because we are going to run it via command (CMD). Make sure to launch the CMD as administrator. When up paste the path into CMD, or type it if you want to.

Hit enter key and you should get the loading of print server in recovery mode.

If it prompts you with a French message box just say NO to it and continue. What it means, I have no idea. I do not speak French. I could probably google translate it but I am lazy.

Should be able to get here.

If you make it this far, then all you have to do now is go into Sage X3 and print something out and you can watch it work in real-time.

Here is an example of print previewing the TABCOUNTY report code.

We would look to see if there are any errors in connection, sending, or receiving the data requests to and from the print server, application, and database. If you do not see any errors, then there its most likely not a connection error. You can also use this a timestamp to see how long it actually takes to get the request to go full circle. So if a report is taking a long time to print you can sit a watch and see why. After all of that, if you still didn’t manage to solve the issue by using any of the above tests, you can get additional information with the ODBC SQL.log while you check the functioning of the ODBC data sources. To find this last ditched effort of tracing is under the same ODBC application were first looked at. Get back to this same screen

On this screen we want to click on the Tracing Tab. Before you start the tracing, make a note of the” Log File Path” path and make sure you can access it.

Click the start tracing and then go run some stuff. If its going it will shade out the options so you cannot make changes to it while its running.

After your done generating the issue, come back here and click the stop tracing now button and go check the SQL.log file. It may take a few seconds for the trace file to actually show, so don’t freak out if its missing.

…And that is about everything I could possibly do to investigate print server issues. If it seems to be too much, unpublishing, deconfigurating, uninstalling, and installing the print server over again takes about 30 minutes to do. So, it really depends on how much time you have and where the issue is. You should now have a slightly better idea how to at least investigate print server issues and hopefully solve a few too.