This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.
Footprints Service Core 12.1
An error occurs on Autorun report.This appears on the history of the report task:
com.numarasoftware.footprints.business.analytics.schedule.ReportSchedulerException: Failed to run scheduled report with name (Report_Name), ID (2), and URL ( http://10.10.10.710/footprints/servicedesk/rdPage.aspx?rdReport=CustomReport&LocalCode=en_US&rdShowM
Another possible error, only in the Footprints.log, when the Base URL is pointing to IIS with SSL enabled:
- javax.net.ssl.SSLHandshakeException : sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
To troubleshoot this problem, please use the following article to get the error details from the footprints.log.
How to troubleshoot Footprints 12.1 using the footprints.log?
Unable to connect Footprints Sync to Exchange Web ServicesWhen trying to configure Footprints Sync, the connection to port 443 on the Exchange Web Services may fail due to failing to negotiate with the Exchange server certification.
incorrect Base URL SSL certificate is not added to the Java Keystore
UPDATE the Footprints Base URL to match the current Footprints 12.1 websiteEnsure the Administration -> Main -> System Setting -> Server Configuration - Base URL is valid for your outgoing notifications, survey notifications, and auto-run scheduled reports.
Notice the url error above.
When the url starts with http:// the url should have the tomcat port like http://servername:8080/footprints/servicedesk if you are not redirecting to IIS.
If the url is on https means it is using SSL.Then the URL is now https://servername/footprints/servicedesk when using IIS.
For this example of error, the Base URL is missing port 8080 since it is not on https. This can cause the error above on Autorun Report
Setting the Base URL from Administration -> Main -> System Setting -> Server Configuration - Base URL to http://servername:8080/footprints/servicedesk should fix the issue
After the release of Footprints 12.1.02, the problem in previous versions with Scheduled Reports and Web Server Authentication on IIS conflicting was resolved.
PKIX path building failed:
When a TLS/SSL Certificate is applied to an external application, the local Java installation used by the Footprints Service core may not get access to the root certificate authority (CA). This will block adding the certificate to the Java datastore.
The error that appears in the Footprints.log, " PKIX path building failed" and " unable to find valid certification path to requested target", can be fixed using the steps below and the attached Java tool "UpdateCacertsTool".
1. IP address of the server that has the problem TLS/SSL certificate. This can be the local Footprints server or an Exchange server on the domain.
2. The port that TLS/SSL is using to connect to the server. This could be 443 or 636 or 465
Steps to update the Java datastore:
1. Create a working folder on the Footprints application server.
2. Place the attached UpdateCacertsTool Java program to the location created in step 1.
3. Start a CMD, DOS Console or Linux command prompt window with local Administration rights.
4. Change working directory to the location created in step 1.
5. Verify that the command window has access to the Java 8 runtime by running the command:
If the command fails to execute then make sure the Java bin folder is part of your execution path.
6. Execute the UpdateCacertsTool with the following command: NOTE CASE SENSITIVE
Provide the information requested by the program gathered as a prerequisite. It is recommended NOT to enable debugging output unless there are errors executing the program.
7. If the program runs successfully a file called jssecacerts will be created in the same execution directory.
8. Copy the jssecacerts file to the <java.home>/jre/lib/security folder.
9. Restart Footprints application server Apache Tomcat service for the change to take affect.
The following snapshot shows a typical execution of the UpdateCacertsTool,
Note the red highlights, in particular the last one where success is indicated and additional instructions are provided for “deploying” the created jssecacerts file to the Java security folder.
IMPORTANT! There is no need to run this UpdateCacertsTool program for SSL communications that do not report the same error.
IMPORTANT! Steps 6, 7 and 8 must be repeated for every SSL server connection reporting the same error. This may appear burdensome at first glance but it is necessary so that ONLY when no errors are encountered in the creation of the jssecacerts file it is “safe” to use it (i.e. copy it to the Java security folder.) The UpdateCacertsTool program will look for the existence of the jssecacerts file in the Java security folder and if it finds it, it will use it in creating a new jssecacerts file that has the aggregate information.
IMPORTANT! If the Java installation is updated, it is possible that the jssecacerts file will be inadvertently deleted. Of course the jssecacerts file can be regenerated but it might be a good idea to keep a backup copy of it to save time.