Symantec Access Management

Hi,
I Configured Webagent 6qmr5-cr009-win64 Web server. Root is protected

when i hit abc.xyz.com i am getting error " 500: Server Error [20-0003] " , If I refresh 3 to4 times I see login page. I checked the policy servers both are up and running. I don't see any communication issues between Policy server and Webagent. I tried another web server with same settings same error. What could be the cause the communication issue.

Environment :
Policy server 6sp4 win 2003 ,

Webserrver :
Windows 2003 64Bit, VM environment

Thank you

Good morning SSO,

The fact that you are hitting F5 serveral Times to refresh and then it goes through would suggest that you are running an HCO with multiple policy servers in a round robin fashion. The fact that you can hit one policy server and it works and you hit others and it does not suggest that you may have an issue with replication.

Without detailed web agent logs and policy server logs to look at this is just a hypothsis.

I would start by using the SiteMinder test tool to point to each of the policy servers in the HCO and testing the SmHost.conf and configuration you are trying to use. This should point you to the policy servers that are working and the ones that are not. From there you can find out why the some are working and some are not.

The only other thing I can think of might be that you have multiple keys in the key store that are causing you an issue. This is not as likely due to the fact you said you were not getting anything in your Policy server logs. I would expect this to show as a handshake error. To look at this you can use the smobjexport -x command to export the keys and make sure there is only 1 set of 4 listed. If you see 8 then you have duplicates and you need to correct that issue.

Should you not find the answer by these tests, I would suggest that you open a case with support and provide the following information,

1) Web agent version
2) Web agent OS type and patch level
3) Web server type and version
4) Web agent logs and trace logs
5) Policy server version
6) Policy server OS type and version
7) Policy server SMPS.log
8) Policy server trace logs with full tracing on.
9) Policy store type and version
10) When did the problem start
11) Have you tried upgrading to 6SP5CR35 ( as the version you are running is rather old)
12) Is there some type of LoadBalancer in front of the web servers?


All of this information will be needed to look into this more deeply by Support.

Hope this helps

Gene

Please also note the combination is not supported.
The policy server must meet or exceed the sp and cr of the web agent. we cdd new features between the service packs and thus not matching service packs IS a big deal.

also, it sounds like agent wait time may come into play here.

Josh_Perlmutter wrote:

Please also note the combination is not supported.
The policy server must meet or exceed the sp and cr of the web agent. we cdd new features between the service packs and thus not matching service packs IS a big deal.

also, it sounds like agent wait time may come into play here.

I hate to thread jack...but I thought that a the policy server had to meet or exceed at the SP level but for CR that the web agent could have higher version than the policy server.
Wasn't that new starting in 6SP5?

david.kramer wrote:

Josh_Perlmutter wrote:

Please also note the combination is not supported.
The policy server must meet or exceed the sp and cr of the web agent. we cdd new features between the service packs and thus not matching service packs IS a big deal.

also, it sounds like agent wait time may come into play here.

I hate to thread jack...but I thought that a the policy server had to meet or exceed at the SP level but for CR that the web agent could have higher version than the policy server.
Wasn't that new starting in 6SP5?

Hi David!

That was new to 12.0 SP3. this was never done in 6.0.
It is still best practice to always have a matching or newer CR on the Policy Server but it's not officially supported to have just the SP match until 12.0 sp3.

Personally i will still troubleshoot until i have a reason to beleive that the CR is the key, and i think most others here will too.
With SPs though, as previously stated, we use that as the delivery for major changes that can cause a lack of backward compatability.

The best example I can think of is 6.0 SP6. the changes for newer technologies actually changed things so drastically the web agents look for more information to come across than suypplied with previous versions of the Policy Server.

Sincerely,
Josh

The resaon for the error code is :

20-0003
Reason:
Unable to reach SiteMinder authorization server or an unexpected Policy
Server error occurred.
Action:
Do the following:
■ Check Policy Server logs for more detailed information on the error.
■ Check connectivity between the Web Agent and the Policy Server by
pinging the Policy Server. If a firewall is configured between the Agent and
the Policy Server, check that it is not blocking the following service ports:
– 44441 (accounting)
– 44442 (authentication)
– 44443 (authorization)

And it happens when the webagent cant connect to the policy server.

I would expect as Gene mentioned you should find some erros in the webagent side, and you should look at

SmHost.conf

HCO

The order things happen on the webagent are :

[list=1]
[*]Read SmHost.conf
[*]Contact hosts in SmHost.conf to get HCO
[*]Read HCO
[*]disconnect from SmHost.conf connection
[*]Connect to Hosts as defined in HCO
[list]

So generally the connection problems are either in SmHost.conf or in HCO settings.

As Gene suggestions, it is likely you have some round robbin, or failover scheme, or load balancer, and as you hit refresh, your hitting different webserver/webagents or using different PS hosts in your list until you get the occasional one that works.

On more rare occasions, the request causes a problem on the policy server, and an Exception is thrown in the PS worker thead, can happen if you do something odd in an active expression that sort of thing - but for those cases there will be clear error in the smps.log and it is less common.

Cheers - Mark

Hi SSO,

Did the responses the team provided help you resolve your issue? If so please mark the appropriate posts as Solution Accepted.

Thanks!
Chris