Some of you may have experienced during an upgrade / installation of ERPM 5.5.2 Webservice errors. ERPM Web Services now integrates closely with the ERPM Web Application. It caches information per the user’s permission under a profile that is on the local machine. In any case, I pretty much have run through all error scenarios and have documented errors, causes and fixes. Trust and browser cache are the driving force behind these errors. GPOs will handle trusts, and clearing cache is a little bit more difficult. Basically, you must trick the browsers into thinking it is a fresh browser (you will not experience the red flagged errors on a fresh installation).
All normal IIS rules apply.
This is a result of the Browsers not able to validate the Web Services at the listed address in the Web Application instance. Because the browser is looking at the certificate for the qualified names, or subject names), it will attempt to establish a connection to whichever server is in the certificate. If local or group policies do not inherently trust these sites, then your browser will prompt you for credentials. You can tell if this is true when the credential dialog’s subject name = iexplorer.exe.
Often if you are running an NLB (network load balancer) you will get this error. Make sure the site(s) NLB, Each Web Server hosts is in the local intranet zone and trusted, also ensure the certificate has the NLB FQDN as well as the Subject Alternative Names (SAN) of all web servers in the NLB. You may use a wild card certificate, but in doing so, you might be required to do an additional step, which will be explained later.
Also, enabling Cross Origin Resource Sharing (CORS) in the Web.config will help resolve this when you are deploying the Web Services on multiple Web Servers.
This error occurs when your Lieberman Red Web Service COM+ isn’t there or doesn’t have correct credentials. Often this is caused by an invalid password or username during the installation of ERPMWebService. As a result, the ERPMWebService COM+ Component is created, but not registered.
Due to the complexity of registering a COM+ Component, it is recommended that you uninstall the ERPMWebService, and reinstall it, using the correct Username and Password.
On rare occasions, this also occurs when the bindings for SSL/443 has been removed for the ERPMWebService.
Recreate the binding
This is usually a result of the Browser not trusting the page within the Web Application and is directly related to a profile cache issue. The browser’s cache needs to be cleared, go so far as hitting CTRL-F5 for each page this pops up on. Sometimes clearing the internet browser cache will not do it, and doing it for the individual pages themselves will. For Internet browser cache, it is best to clear ALL cache, including cookies. In addition to this, you will also need to clear the Web Service Cache by clicking on the Cogwheel next to the Logout button (top right). It will bring up the Site Settings page, and on that page is a clear cache button.
Testing from the Web Application instance you get this message.
Add host names to Local Intranet (trusted by the browser – Doing this on the ERPM Host machine clears it.
Additional Registry Entry
When using Alias names, NLB addresses for your Web Service, local policies might have Connection return directed to another address, or Loopback turned off, or restricted to 127.0.0.1 address. A common error dialog to enter credentials for iexplorer will popup. Even after adding the addresses to the Local Intranet sites, you keep getting this error.
This can be fixed by adding an entry to the Registry to allow permission(s) to multiple sites on the ERPM Host machine, as well as the NLB Web Servers. If you are using short names for each web server, then you will need to add those as well.
- Add new String Value: BackConnectionHostNames
- Add to the value: Host names of NLB, Web Servers hosting the ERPM Web Application.
Web Site fails to load in Internet Explorer but can load in FireFox and Chrome from an external source (not in the local network).
If you run across where browsing from another computer, HTTP:// fails (asking for credentials three times and returns a 401 error), the following is happening.
When all the above seems to work internally, then you attempt to reach the site from an external source, and you get the HTTP Error 401. The requested resource requires user authentication.
This is often a result of the Authentication Header of the IIS site not large enough to handle the Token. Also, it could mean IE is attempting to authenticating to a default method; NTLM, Negotiate, Kerberos. FF and Chrome will check all methods, IE only checks against the first one in the Authentication List in IIS.
- Open IIS.
- Drill down to the Default Web Site.
- Double click on Authentication
- Select Windows Authentication
- On the right-hand side click on Providers
- Select NTLM and move it to the top.
- Restart IIS.