Troubleshooting: Could not load type 'System.ServiceModel.Activation.HttpModule' from assembly 'System.ServiceModel...'

 

This error can occur when there are multiple versions of the .NET Framework on the computer that is running IIS, and IIS was installed after .NET Framework 4.0 or before the Service Model in Windows Communication Foundation was registered.

 

For Windows 7 and Windows Server 2008, use the ASP.NET IIS Registration Tool (aspnet_regiis.exe,) to register the correct version of ASP.NET. To do this, follow the steps below: 

1. On the computer that is running Microsoft Dynamics NAV Web Server components, open a command prompt as an administrator as follows:
   
   
   1. From the Start menu, choose All Programs, and then choose Accessories.
   2. Right-click Command Prompt, and then choose Run as administrator.
      
      
2. At the command prompt, type the following command to change to the Microsoft.NET\Framework64\v4.0.30319 folder, and then press Enter.
   
   cd\Windows\Microsoft.NET\Framework64\v4.0.30319
3. At the command prompt, type the following command, and then press Enter.
   
   aspnet_regiis.exe -iru


4. At the command prompt, type the following command, and then press Enter.
   
   iisreset

 
The information below is to provide general information regarding adding an additional storage location to ProjectDox and does not provide step by step instructions.

ProjectDox is flexible and can store the UserFilesPublish and UserFilesSource shared folders across multiple storage devices. For example, current storage location may be \\Server1\UserFilesSource and \\Server1\UserFilesPublish and that location fills up. The files uploaded to ProjectDox to date would have those paths stored in the database so the application knows where to access them when being worked with by a user logged into ProjectDox.

Since storage location 1 is filled up, additional file shares can be created with the same NTFS permissions and File Share permissions on the new storage device, \\Server2\UserFilesSource2 and \\Server2\UserFilesPublish2.  A copy of the web.config file that is located at the root of the directory of the original storage location \\Server1\UserFilesPublish needs to be place at the root of the new storage location \\Server2\UserFilesPublish2.   Then you would add storage location 2 into the ProjectDox configuration.  In order to use the new storage location 2, we would modify the ProjectDox Admin / Configuration / Core tab and set the path for the new UserFilesSource and UserFilesPublish folders that way any Projects created with files uploaded from that point on would be stored in the new location.

We would then add an additional Virtual Folder / Application in IIS configuration and call it UserFilesPublish2 and point it to storage location 2. The last step would be to update the UserFilesPublish virtual folder name field under the ProjectDox Admin / Configuration / Core tab to the new Application name of UserFilesPublish2.

With all of those changes applied, any new Projects that are created will have their storage location setup for storage location 2 and so as files are uploaded the path in the database will be pointed to the correct location for the files. Since both locations are setup in IIS, when a user clicks on a file to view, either path is obtained from the database and the user can be taken to both successfully.

It is actually beneficial to spread the shared folders among several locations on different physical devices so there is not so much load being placed on a single device. If your ProjectDox site has a large number of users, having the requests be distributed to multiple devices can speed up the performance so you do not have the situation where there is a bottleneck waiting for the return from a single physical device.

For questions regarding additional storage locations or to schedule time to have assistance in performing the steps outlined above, please contact Avolve Support or your Account Manager.
 

 

Product:  ProjectDox 8.3x, ProjectDox 8.5x, ProjectDox 8.6x

 

Problem: Uploading large files take a long time, slow performance.

 

Solution: This issue is often due to firewall settings on the network where ProjectDox is installed. In order to determine if this is an issue with ProjectDox or with the network, perform the following steps to troubleshoot. 

 

1. Logon to the ProjectDox web server.

2. Open a new browser window and navigate to the ProjectDox site using LocalHost as the address in the browser. For example, the URL would be http://localhost/ProjectDox.

3. Login to ProjectDox using whatever account will give you permission to upload a test file to the Project.

4. Copy a large file to the ProjectDox web server to use as a test to upload to a Project.

5. Click the Upload Files button and determine if the file uploads faster and at the expected speed, use your results to determine the next step.

    

   Test Results:

    

1. Uploads Faster / Performs as Expected

   If the large file uploads faster and performs as expected directly from the ProjectDox web server then that indicates that there may be an issue with the Firewall routing and your network team should be notified.

   Some Firewall devices have a default setting limiting the size of files that are transmitted through the Firewall and in to the internal network. Some of the settings that could be checked on the Firewall are tcp-mss-sender and tcp-mss-receiver. The values for these settings controls the maximum amount of data that can be sent in a single packet and can sometimes be troublesome when transmitting large files.

    

2. Uploads Slow / Performs the Same

   If the large file uploads slowly and performs the same, please notify Avolve Support so additional troubleshooting can be performed by the Support Team.

Product:  ProjectDox 8.6x, ProjectDox 9.1x, Brava 16.0, Brava 16.2

Problem: Certain files take a long time to publish, slow performance when viewing files on the Brava Viewer.

Solution: This issue is often related to how the file was created originally. The PDF driver requires an edit to disable 8-bit images in BESS 16.0.2 and 16.2. A PDF created with Bluebeam Stapler produces these types of PDFs and the file will fail to publish. Starting with PDF2DL 2.5.37.100 an option is included to disable 8-bit. The side-affect is that it may cause some file sizes to be negligibly larger.

• Once the updated PDF driver has been applied, open .\Program Files (x86)\IGC\Brava! Enterprise\JobProcessor\Igc.Loaders\pdf2dl-config.xml file for edit.

• Update the 3 parameters for DisablePaletteCheck to true.

<Parameter name="DisablePaletteCheck" system-param="true" default-value="true" value="true">

• The update takes affect with a full reboot of the Job Processor.