Technical FAQs for "PrizmDoc"

Does viewing HTML in PrizmDoc Viewer allow JavaScript execution or local file access? Can PrizmDoc Viewer block externally-referenced content from being rendered?

When viewing HTML in PrizmDoc, JavaScript and local file access are disabled.

Additionally, you may configure the security.htmlRendering.blockExternalContent setting found in PrizmDoc’s Central Configuration file. When rendering any source document which uses HTML content, this setting controls whether or not externally-referenced content, such as images and iframes, will be blocked. This option affects any source document file type which uses HTML, including HTML, EML, and MSG.

We just installed the PrizmDoc client and noticed that when we run Prizm Application Services, the service states that it is started, but it is not listening on 3000, and there are no logs written to the Prizm\logs\pas folder. What might the issue be?

A possible reason for this issue can be due to the Windows system environment variable called PATHEXT. By default, .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC are configured.

What this variable does is allow commands to be executed without needing to add the extension to them.

For example, PM2, which runs with PAS, has a file extension of .CMD, so when executing PM2 in a command line you just need to type PM2 instead of the full name PM2.CMD.

If .CMD is not in the PATHEXT environment variable, then just typing PM2 would return a command not found error, and you would need to use the full PM2.CMD for it to work.

To fix the issue, ensure the following:

1. Open Control Panel > All Control Panel Items > System
2. Select Advanced System Settings
3. Select Environment Variables
4. Under System Variables double-click PATHEXT
5. Add to the end of the current string
6. Restart Prizm Application Services

We are adding files to the viewing session with HttpWebRequests. We noticed with larger files the response is:

(413) Request Entity Too Large. -  at System.Net.HttpWebRequest.GetResponse(). 

What could be the cause?   

A 413 request entity too large error occurs when a request made from a client is too large to be processed by the web server. If your web server is setting a particular HTTP request size limit, clients may come across a 413 request entity too large response. An example request that may cause this error would be if a client was trying to upload a large file to the server (e.g., a large media file).

Depending on which web server you use, implement the necessary changes described below to configure your web server’s maximum HTTP request size allowance. Below are some suggestions for popular Web Servers:

For Nginx users:

The directive that determines the allowable HTTP request size is client_max_body_size. This directive can be defined in your nginx.conf file located at /etc/nginx/nginx.conf

For Apache users:

The directive is LimitRequestBody which can be defined in your http.conf file or in an .htaccess file.

For IIS users:

1. Open Internet Information Services (IIS) Manager.
2. In the Connections pane, go to the connection, site, application, or directory for which you want to modify your request filtering settings.
3. In the Home pane, double-click Request Filtering.
4. Click Edit Feature Settings in the Actions pane.

When installing PrizmDoc, we specified the wrong user ID and password for the 3 PrizmDoc services. Can we safely change them to another account?

It is possible to change the Login User account on the three PrizmDoc services: Prizm, PrizmDemo, and Prizm Application Services.

You will need to ensure the user id you use is in the local administrators group on the server, as well as a part of the Login As a Service rights in the machine’s local security policy.

To verify the user ID is added to the Local Administrators group:

• Right-click the Windows Logo, select Run, and enter compmgmt.msc
• In Computer Management expand Local Users and Groups
• Under Local Users and Groups select Groups
• Double-click Administrators group in the right panel
• Verify the User ID is listed under Members

To verify the user Id has “Log on as a Service” rights in the Local Security Policy:

• Right-click the Windows Logo, select Run, and enter secpol.msc
• User Security Settings, expand Local Polices, and User Rights Assignment
• In the right panel, double-click Log on as a service
• Verify the user ID is listed, and if not, click on Add User or Group to add

Changing the service “Log on As” user id:

• Right-click the Windows Logo, select Run, and enter services.msc
• Find a service called Prizm and double-click on it
• Click on Log On tab and click Browse to select new user id
• Enter the Password for the new account and then enter Confirm Password
• Restart the service
• Repeat the above steps for PrizmDemo and Prizm Application Services

We entered our S3 bucket name in the customer portal, but used a capital letter for the first character; however, the S3 bucket name is all lowercase in AWS (Amazon Web Services).
Will this cause an issue with starting the service?

Yes, the bucket name is case-sensitive and must be entered exactly the same as the S3 bucket is named in AWS (Amazon Web Services).

AWS recommends you do not use uppercase letters in your bucket name.

If you made the first character of the name uppercase in the Accusoft Customer Portal, then the service will fail to start.

You will need to contact your Account Manager or Accusoft Technical Support to have the license re-created so that you can re-enter the S3 bucket name properly.

Sometimes, when redacting an Office or PDF document, redactions drawn over certain content (such as an image or a logo) appears to get burned on other occurrences of the image on other pages. Why does this happen?

The reason why the duplicate redactions are occurring is because the images are shared images. In PrizmDoc, when a change is made to one instance of the shared image, it gets applied to every other instance. Per engineering, this is to mimic the behavior of Adobe Acrobat.

There currently exists a feature request to allow shared images to be treated as individual images so that they could be redacted separately:

https://ideas.accusoft.com/ideas/PDV-I-655

We are currently using PrizmDoc Cloud licensing. After applying our cloud license, the Prizm services started and show healthy, however, I see “CloudLicenseValidationFailed” errors in the PccErrors.log file. Is this normal, and do I have to worry about Prizm functionality?

Currently the licensing messages referencing “CloudLicenseValidationFailed” in PccErrors.log are a false positive and should not be taken as an issue with PrizmDoc Cloud licensing.
The more accurate way to check whether the license has been validated successfully would be to use watchdog.log and look for “Cloud License Validation” – “isValid”:true which indicates that the license is valid.

The issue regarding that error in pccerrors.log is in our product backlog to consider addressing in a future release, but it is not yet prioritized on our roadmap.

We have just applied the solution name and key for our cloud license, however, when trying to start the Prizm service, it fails to start.
What could be causing this issue?

There are a few reasons why this would occur:

1. The server does not have internet access. Internet access is required for cloud licensing to connect to an S3 bucket.
2. The server does not have proper rights to access the S3 bucket configured. Please verify the rights to the S3 bucket. Information can be found here: https://help.accusoft.com/PrizmDoc/latest/HTML/prizmdoc-cloud-license-and-aws.html
3. Verify the solution name is spelled properly. The solution name is case-sensitive.
4. Verify that the name of the S3 bucket entered in the customer portal matches your actual S3 bucket name. The S3 bucket name is case-sensitive.

We have been noticing in our PrizmDoc environment that the viewer seems to take longer and longer to view documents over time. After a few days, we restart the Prizm services, and the Viewer processes faster. What might be the reason for this issue?

This issue is typically caused by a change in the core count of the server after PrizmDoc has been installed. Specifically, the non-interactive heap size will not automatically update if the core count is changed after PrizmDoc has been installed. We update this value during install.

If you have made changes to the core count of the server after installation, please see the following page for correlation between the non-interactive heap size and the CPU cores count:
https://help.accusoft.com/PrizmDoc/latest/HTML/registry-changes.html?highlight=heap%2C.

The reason the non-interactive heap size matters here is because it affects performance of the Office and HTML conversion services, and the symptom of insufficient non-interactive heap size is soffice.bin crashing.

I am integrating PrizmDoc using just the API to convert documents, and I am noticing an initial delay of about 10 seconds before the conversion starts.

Why is this happening?

One of the likely reasons this could happen is if your PrizmDoc Server is not licensed properly or if you are running in the Evaluation mode. In such cases, there are restrictions in place.

Among those restrictions is an artificial delay of 10 seconds imposed before viewing or conversion operations begin. A dialog window normally indicates this in the Viewer interface, but if you are just making API calls to the server, it will not be apparent.

A valid product license is required to eliminate these restrictions, which can be done as follows: https://help.accusoft.com/PrizmDoc/latest/HTML/prizmdoc-server-docker.html#2-configure-your-license.

What are the different ways to iterate through and select redactions in PrizmDoc Viewer?

Method 1:
Use the mouse to manually select the redactions you want to work with.

Method 2:
With the advancedSearch feature enabled, perform a search of your document. The search will return a list of marks on the document that you can use to select redactions without having to manually locate where they are in the document.

What ports need to be open on my server in order for PrizmDoc to function correctly?

PrizmDoc Server needs to be able to communicate internally over the following ports:

• 18000
• 18001
• 19000-19199

And externally over 18681 (18682 if clustered).

Prizm Application Services (PAS) needs to be able to communicate externally over the following ports:

• 3000