Debugging MSP Portal Posts
Modified on: Tue, 22 Nov, 2016 at 2:54 PM
The PathSolutions product should be able to make MSP portal record posts from the PathSolutions TotalView product back to the MSP Portal deployed in the MSP’s NOC.
This process involves having the TotalView product send an outbound HTTP POST message out the customer’s firewall,through the Internet and to the MSP Portal which is exposed to the Internet on port 80.
Troubleshooting should generally use the following process:
1) Check to make sure that the MSP Portal can be reached and accept HTTP POST messages from the customer’s site. This can be accomplished by using a browser at the customer’s site and browsing to the following page:
Fill out the form (or just accept the defaults) and click “Submit”. An outbound HTTP post will be made from the browser back to the MSP Portal.
If the HTTP POST goes through successfully, you should see:
If the HTTP POST does NOT go through successfully, use the resulting error message to investigate the customer’s firewall or proxy server to make sure that the messages can go through.
This may involve testing the HTTP POST from the MSP’s own NOC to validate that the MSP Portal server is operational and accepting messages.
2) The PathSolutions TotalView service has a number of debugging options that can be employed to further investigate why HTTP POST messages may not be going through.
a. Alert destination (email address field) not formatted correctly. The alert destination should be formatted as such:
There should not be any “http” or “https” in front of the URL. If the domain cannot be reached, or the post does not go through, there will be an error in the Windows Application Event log from the TotalView service indicating the failure.
b. Proxy server is preventing outbound HTTP POST messages. If the customer has a proxy server type of firewall, special configuration is typically required for Internet access. In this case, the customer will usually have their browser configured with a special proxy server configuration to allow it to browse. Make sure that Internet Explorer on the computer is configured with this proxy configuration and can execute HTTP POST messages.
Once the browser can successfully send messages, a special command should be run to copy this browser configuration to allow non-browser based services to also use the proxy server. Refer to PathSolutions Proxy Firewall Configuration on how to configure the service to use the proxy server configuration.
You can check the Windows Application Event log for errors from the TotalView service to see if it has problems making the HTTP POST message.
c. Other problems. To troubleshoot other problems, you can view portal post responses as well as enable runtime debugging to see where the program is having problems.
i. Create a file “PostDebug.flg” in the C:\Program Files(x86)\PathSolutions\TotalView directory. This file can contain any contents, but has to exist with that filename.
When the filename exists, all portal post responses will be saved into the “Web” directory as “Post00000.htm” filenames. You can open these files to see what the response is from the MSP Portal server.
ii. Run RegEdit and navigate to the HKEY_LOCAL_MACHINE/Software/NetLatency/SwitchMonitor key. Change the “EventLogLevel” entry from (hex) 0x0F to 0x2000000F. The next time a poll occurs, the program will output additional details in the Windows Application Event log of where the program is having problems making the connection. In addition, the resulting HTML page from the submittal will be created in the C:\Program Files(x86)\PathSolutions\TotalView\Web directory. Look for files in this directory named “Post-00000.htm”. These files will show the result of the post from the Portal server.
Typically, you will want to save the Windows Application event log and send it along with the associated “Post-00000.htm” messages to PathSolutions support for interpretation.
Did you find it helpful?
Sorry we couldn't be helpful. Help us improve this article with your feedback.