After installation of Credit Hound v6, the Credit Hound Client cannot connect to the Credit Hound Server, giving the error "Failed to communicate with the Credit Hound Web API authentication endpoint"
The Application Pool for Credit Hound's web API will be stopped and an Event 5059 will be logged in the Windows Event viewer:
Event Viewer : Log Name: System Source: Microsoft-Windows-WAS Date: 28/11/2017 16:56:38 Event ID: 5059 Task Category: None Level: Error Keywords: Classic User: N/A Computer: computer.domain.co.uk Description: Application pool CreditHoundWebApi has been disabled. Windows Process Activation Service (WAS) encountered a failure when it started a worker process to serve the application pool.
And the Credit Hound log file will show an HTML server response code 503.
Credit Hound v6
When Credit Hound v6 is installed, it needs to create two Application Pools in IIS, one responsible for the layout of the Credit Hound Dashboard screen and the Accounts list screens in the Credit Hound client application, and one that provides an authenticated API to the Credit Hound database.
These Applications Pools must be run under a given Windows user identity; the Credit Hound installer will create a local user named CreditHoundSU and will configure this account to run the application pools. In the majority of cases this account is all that is needed. However certain environments may prevent this from happening:
If Credit Hound server is installed onto a domain controller, the installer cannot create a local account, and will instead create a domain account.
If Credit Hound server and the SQL server are installed to different PCs, then the Application Pools must run using a domain account, which must be created manually.
The account to be used (whether local or domain) must have the following rights:
- Log on as a Service
- Log on as Batch Job
- It must be a member of the group IIS_IUSRS
- It must have read/write access to the Credit Hound shared folder
The issue above occurs when these requisites have not been met, which can occur if these user rights are managed by a domain group policy rather than a local system policy. This can be seen by opening Control Panel>Administrative Tools>Local Security Policy>Security Settings>Local Policies>User Rights Assignment:
Note that the icon for Log on as a batch job shows that these rights are managed by group policy on the domain. If you open the properties you will see that the editing functions are greyed out:
To modify these right you will need to use the Group Policy Management Console on the domain, under Computer Configuration>Windows Settings>Security Settings>Local Policies>User Rights Assignment.
Ensure that the account that is running the IIS Application Pools has the correct rights and memberships as described above, whether via local policy or via domain group policy.
For more information regarding User Rights Assignment, see this MS technote: https://technet.microsoft.com/en-us/library/dn221963(v=ws.11).aspx
|Related Product||Credit Hound v6|
|Original Author||Vince Hodgson|
|Update Author||Vince Hodgson|