CA SiteMinder Internet Access Manager R12 improves upon the functionality available in SiteMinder 6.x in several areas. In addition to fine-grained delegation through the new administration user interface, R12 improves directory mapping, adds support for web services, bundles federation support previously only available through the Option Pack and introduces fine-grained authentication capabilities. While these features warrant upgrade consideration on their own, an eventual end-of-life of SiteMinder 6.x will require an upgrade of your existing environment. As you begin the process of upgrading your environment to R12, careful consideration is required to make sure the migration goes smoothly. New components like an application server are required and even the way policies are stored has changed with the addition of the extended policy objects. SiteMinder deployments provide mission critical functionality and the upgrade must be completed with minimal risk or downtime. To ensure a smooth upgrade path, ensure that you spend sufficient time planning for each phase of the move to SiteMinder R12.
Your Upgrade Strategy
As you look at your strategy for upgrading to SiteMinder R12, you need to consider the following:
- Make sure that you have detailed information on each component of your SiteMinder environment
- Understand your maintenance windows
- Ensure that you have a good recovery and rollback plan
- Map out the upgrade order of the components
When breaking down your existing SiteMinder environment, keep in mind the following SiteMinder components:
There are several things to consider as you analyze your current environment. Make sure that you minimally have the following details:
- The number of policy servers and agents you have deployed and the versions of each component. The audit logs on the policy servers can be reviewed to capture this information.
- Which policy servers are being used by each agent. While the host config object can provide some details here, don’t forget that the SmHost.conf file contains the bootstrap policy server for the agent and that information is not stored centrally. You can use the audit logs to help narrow this down further.
- Determine if your agents are operating in failover or round-robin modes and which agents are providing single sign-on for unified applications. Careful review of the upgrade documentation is required to ensure that single sign-on and correct handling of failover and round-robin modes are maintained during the upgrade process.
- Determine which authentication schemes are being used and ensure that there are no required configuration changes for those authentication schemes.
- Map out all your 3rd-party and custom components. You will want to validate that your 3rd-party components are compatible with R12. Any custom components will require testing and may need to be recompiled.
Spending the time to collect this information will allow you to map out a detailed plan. You can combine this with information on your maintenance windows and off-peak times to minimize the upgrade impact and reduce risk.
If you have the luxury of standing-up another environment and then migrating over to your new systems, recovery is simply a matter of switching back to the old environment. Similarly if you are using VMWare or similar virtualized systems, this give you the flexibility or taking your existing image, upgrading it and then deploying it while being able to roll back to the old image if needed. If you’re like most of us, the only way to do this is inline. Before upgrading, be sure to backup. Aside from backing up the machine, make sure you backup the following:
- Policy store using smobjexport
- Configuration files like the WebAgent.conf conf, SmHost.conf customized forms and other FCC’s, etc.
- Web Server configuration files like Apache’s httpd.conf
Once you have completed the analysis of the environment put together a plan that ensures that all components in the environment will remain compatible. The typical approach is to upgrade the policy servers first and then the web agents. This may change depending on the version of the agents deployed. Once you have run the installer for R12, you can’t revert back without uninstalling. So, make sure that you’ve mapped out a strong recovery strategy.
Make sure that you have tested the upgrade in several environments prior to rolling this out to production. Having a well documented and tested strategy takes some time to put together, but the reduced risk and post-upgrade issues is well worth the investment.
Stay tuned for additional information. We'll be posting tips-and-tricks, troubleshooting and other information to our blog over our next few posts.