Can some one please let me know what are additional steps need to be followed in CA Secure Proxy server and CA Directory server end, if we want to add two new policy server in existing infrastructure.
CA Directory version :- CA Dir R12.0
CA SPS version :- CA SPS R12.52 CR01
Existing Policy Server Version :- CA PS R12.52 CR01
New Policy Server Version (will be added along with existing one) :- CA PS R12.52 CR04
Note :- We are only required to add to new policy server with existing PS (version diffrenece CR01 and CR04) and CA SPS and CA Directory server ( Policy Store, Session Store) will be same.
POLICY SERVER --> PSTORE
Point new policy servers to existing pstore.
Update cert8.db for backend SSL Connections.
WebAgent --> POLICY SERVER.
Update Host Configuration Object in WAMUI.
Update SmHost.conf for boot strap (optional) in SPS.
Since your Policy Server version is CR02 and CR04. Only Install the Policy Server binaries on the new servers.
I would compare XDD files across both versions before running XPSDDInstall, just to make sure I know if it absolutely necessary to run XPSDDInstall.
Similarly I'd also compare smpolicy.xml, ampolicy.xml and all the other xml files which import default object - across both version - to be absolutely sure if I need to run'em because of any new additions.
Since it is CA Directory, I'd be smart enough to backup the policy store before I begin running any XPS Commands.
Thank you, I will follow above suggestion.
1- Since in production existing Policy server will be R12.52 CR01 and SPS will be R12.52 CR01 and new addition policy server will be R12.52 CR04 so I believe there should not be any compatibility issue for CA Directory and CA SPS with new policy server CR04. Correct me if I am wrong ?
2- Do you think we also need to run smreghost command from CA SPS to register this policy server, or changing in HCO and updating SmHost.conf file would be sufficient ?
Answer to  : There should not be any issues, as long as both CA Directory and CA SPS is not older versions. Just being overly cautious. Your CA Directory is just R12.0 or R12.0 SP(something?). CA SPS version you inked above is good.
Answer to  : No need to run smreghost as the Trusted Host is already present in Policy Store. New Policy Servers are going to point to the same Policy Store / Key Store. Just modify the HCO and SmHost,conf
ONE IMPORTANT FACT : Encryption key MUST match. If you do not remember the Encryption key, then after you install the policy server, copy the EncryptionKey.txt file from the older policy server.
Thank you so much for clarifying all my doubts.
yes our CA Directory is R12.0 SP12 Build 7338.
That version of CA Directory is good.
One another fact. After you install the New Policy Server, do not forget to Turn Off Agent Key Generation (via SmConsole). Only one Policy Server in a cluster / pool of Policy Server generate the Agent Keys.
After adding new policy server in QA with existing policy store I see some of partnership application are working fine while others are throwing 403 error. Policy server trace and smps.logs are attached in CA Support case # 00430311.
In QA all policy server are of same version :- CA R12.52 SP01 CR04 and after adding new policy server with existing policy store I didn't run any XPSDDinstall and XPSImport to import policy store default objects, as I compared the data in all .xml and .dd file with other PS and found out same, so didn't run any XPS command.
The similar issue we were facing last time in production as well, but was unable to find out any resolution.
Can you please help me figure out the solution for this issue ?
I think that may be due to some Data Definition not being set correctly. But first check the FWSTrace.log and smtracedefault.log to confirm why the 403 was returned. This step is crucial.
I see that we were missing JCE patches and that caused the issue for the partnerships. I think we missed reading the pre-requisites for Policy Server Install when installing CR02. JCE is a mandate.
#### CAUSE OF THE PROBLEM ####
Lack of JCE patches on the policy server
#### WORKAROUND ####
#### SOLUTION ####
Once we updated the JCE, issue got resolved.
#### RELEASE/FIX THAT RESOLVES THE PROBLEM ####
Thank you, yes JCE patch doesn't have read permission for other user (smuser) that's why it was failing. Thanks to you and CA support for resolving this issue.