The Troubleshoot area allows administrators to run three basic tests against the application and can assist in identifying issues within the ProjectDox site.
Permissions
URL Spawning
Tests remote URL calls from the server. If a failure is received this could mean connectivity issues are present, but can vary on the level of security of the IIS server.
With URL Spawning, the server is sending an http request, as opposed to a user's browser sending the http request. The server is configured in such a way as to not allow outbound http connections to be spawned programmatically from the server.
ProjectDox uses server-spawned http for the following activities:
Sending job request to the publisher.
In thumbnails view, silently checking whether the files are published or not to allow the thumbnails to be auto-displayed without requiring a refresh.
Folder Permissions
The Folder Permissions test will verify access to four key folders of the ProjectDox installation.
You will see green text stating “Success” meaning that the shares (UserFilesSource, UserFilesPublish, PDoxTemp, and the Queue) have been granted correct permissions. “Failed” in red will display when that is not true for any one of the four required shares. The list below describes what a failure may indicate and what it will affect within the ProjectDox system.
PDoxTemp Folder
The Web Server is unable to copy the uploaded files to create tickets in the Queue folder resulting in failures for publishing documents to ProjectDox. An inaccessible PdoxTemp folder will also prohibit the downloading of files from ProjectDox.
Queue Folder
Tickets are created in the Queue folder, but are not picked up by the Job Processor resulting in a publishing failure.
Source Folder
Uploaded file(s) cannot be copied and deposited via UNC to the UserFilesSource folder, resulting in the site being unable to create new projects, copy projects, download files, or publish files.
Publish Folder
The Job Processor cannot deposit the published files via UNC to the UserFilesPublish folder, resulting in publishing failures.
SMTP Email
Tests the sending of emails from ProjectDox using the configurations established in the SMTP tab of the configuration area. SMTP Email is the ideal location to confirm that the email configuration is operational. If it is successful, the message will be “Email has been sent.” If it fails, the ideal location to review details of the failure is from the web server ProjectDox Event Log. The Event Viewer contains a ProjectDox-specific item that will give details of the failure such as “relay has been rejected.”
HTML Viewer
An absolute directory to where brava holds the DLCache. This cache can be deleted from this page. When Delete Viewer DLCache button is clicked it calls a web API method which will delete the contents of the path that is configured in the DLCachePath setting. A new path can be created from the Admin > Configuration page under the Brava tab.
Republish
The Republish section allows you to republish any files that do not publish correctly the first time the file is uploaded to a ProjectDox project. Select a project by typing the project name in the By Project field. A list of the file will display. The files can then be selected and republished by clicking the Republish Selected button.
When viewing by Batch file listing, the current success status of each published file is listed in the right column. Any files failing to publish, display a red NO in this column. Be sure to examine all available pages for failed status by clicking the next page buttons (if multiple pages exist).
<add key="SecondsBetweenInvoke" value="300"/> <!-- how many seconds between when web services/processing are invoked, recommended is 300 - 600 seconds (5 - 10 minutes) -->
<add key="RepublishMaxRetryCount" value="2"/> <!-- Maximum # of times to attempt to republish a file. This service will try to republish the files every time the service executes based on the [SecondsBetweenInvoke] setting in this config file. If the file hasn't been attempted to be republished the first time before [SecondsBetweenInvoke] comes again then it won't immediately try to republish the file. Instead, it will wait until the file fails the second time and then republish again [RepublishMaxRetryCount] times. -->
<add key="TicketConsideredDeadMinutes" value="240"/> <!-- Maximum # of minutes before a ticket is considered dead. This is required in the case where the Job Processor fails to notify ProjectDox of success/failure of the publishing (i.e. Job Processor critical error, network problems, ProjectDox down, etc). The minute count is measured from when the ticket was originally submitted. For example, if you submit 10 files for publishing then the Job Processor server takes those 10 tickets into memory to publish the files. If the Job Processor server dies while processing the 10 tickets without being able to ping ProjectDox on the file publish status, then after [TicketConsideredDeadMinutes] minutes it will resubmit those tickets for publishing. -->
· The JPQueueTicket database record is always created when a file is uploaded with the JPSuccess column as 0 until the Success Notification is received which changes the value to 1.
· Files that are stuck in “Processing” are in the JPQueueTicket table and will continue to show JPSuccess column as 0. After 240 minutes the file will timeout. The next time the Utility runs, there will be an attempt to publish. It will continue the attempts per the RepublishMaxRetryCount value in the Utility.
· Once the PublishAttemptCount column equals the RepublishMaxRetryCount, no other action will be taken.
· If the file completes with an error, it no longer shows “Publishing” in the user interface, then the error is written to the PublishResult column of the JPQueueTicket table.
o Example: Primary error: publish_error, Error # 0: Unrecognized output format: .dwf, Error # 1: DWF output format is no longer supported.
· Failures to publish will have a single file, a Heartbeat.txt file, in UserFilesPublish folder with details of the failure.
· In some instances, in the case of a bad license, the SecondsBetweenInvoke at 300 seconds, (5 minutes) for 2 RepublishMaxRetryCount may not be enough time to resolve the problem and the attempts will hit the max.
o You can take advantage of the systemconfig page in this scenario.
o Or, you can increase the RepublishMaxRetryCount by 1 and restart the Utility.
· When a file is republished via the Utility or the systemconfig page, the process updates the existing JPQueueTicket, it does not create another JPQueueTicket or record in the shared queue folder.
· If you select 1 file to republish from the systemconfig page, the code retrieves up to 500 files that are ready for publishing and sends them all to the Job Processor, it is generic method that is called.
· HTML publishing failure, it is not part of the republishing tool or the ProjectDox Utility.
o ActiveX must successfully publish first in order to publish the HTML
The HTML rendition will republish only when the HTML file is clicked on.System
Services
