The "Unable to load SiteMinder host configuration object or host configuration file" error message may appear for a number of reasons:
- Situation - The Policy Server is hosted on a Unix platform and the Web Agent is hosted on a Windows platform or vice versa and the path delimiter from one platform is in use on another.
Reason - The directory path delimiter for Unix & Windows platforms are different. Please ensure all the directory path delimiters are set appropriately for the target platform.
- Situation - The HostConfigFile is not at the path listed in the WebAgent.conf
Reason - Ensure the HostConfigFile is accessible at the directory address listed in the WebAgent.conf. Accessibility may be affected by location as well as effective permissions on the file.
- Situation - The AgentConfigObject of the WebAgent.conf does not match (spelling, case, etc) an Agent Configuration Object in the policy store.
Reason - If a string comparison on the two strings does not return as a perfect match, this can cause the issue.
- Situation - The DefaultAgentName is unset or not agent as defined in the policy store.
Reason - DefaultAgentName needs to be set to a valid agent. It is a string compare so it must match spelling/case/etc.
- Situation - The SMHost.conf hostname is inaccurate
Reason - SMHost.conf hostname parameter must define a policy server by the FQDN or IP address, and must be resolvable via DNS
- Situation - The HostConfigObject of the SMHost.conf does not match (spelling, case, etc) a Host Configuration Object
Reason - As with the AgentConfObject, this is a string compare that needs a perfect match
- Situation - The Host Configuration Object on the Policy Server has no uncommented PolicyServer parameter
Reason - The PolicyServer parameter is required and needs to be uncommented and filled out to a hostname that can be resolved via DNS or an IP. It starts commented out because there is no default and it is an example of the format only.
- Situation - Error resolving DNS
Reason - On Windows, try the "nslookup" command from the DOS prompt to determine if the hostname resolves properly.
Reason - On Unix machines there is a command called "getent hosts" which tests for resolution as a program would. In other words, this tests as the name resolution starting with the highest order source, commonly the /etc/hosts file, and then moves down the chain ultimately ending on DNS. This can tell you if there's a name resolution issue better than doing a reverse look up as one of the files may contain an erroneous entry.