Planning for upgrade
Use the documented information you gathered in Research and analysis to develop:
A test plan that can measure whether or not the old and new instances behave as expected
A backup and recovery plan
A change control plan to minimize downtime of the production system
A communications plan to prevent calls to the help desk during the process
Test plan
Write a test plan that systematically identifies use cases covering the required capability of the system. This test plan should cover all automated processing expectations, all end-user self-service cases, all help desk assisting user cases, and so on.
Test the plan on the current production system to ensure it is operating as expected.
The Bravura Security suite of products has the potential to interact with nearly every other piece of computing equipment in the enterprise, and as such, the test plan ought to be comprehensive and well maintained.
After an upgrade or migration, systematically test the use cases on the newly upgraded system.
Develop test cases around all the various components of the system that you have implemented; for example:
End-user use of the self-service web interface, and help-desk-user use of the web interface to assist others to perform all possible operations, such as:
Identification of the profile during login
Authentication of the profile using each method
Resetting passwords for yourself and others
Unlocking accounts for yourself and others
Claiming unassociated accounts to your profile
Managing tokens, SmartCard, and/or hard disc encryption keys
Requesting access to a privileged account
Approving a request for access to a privileged account
Accessing a privileged account
Checking in access to a privileged account
Randomizing a password
Randomizing a local service
Assigning access and membership via user classes
Requesting a new account on a target system
Requesting attribute changes
Phone Password Manager functionality
Telephone interface for performing operations
Target system integrations
There should be a test for each operation that is possible on each target system.
Ticket / issue tracking system integrations
There should be a test for each operation that is possible on each ticketing or issue tracking system.
Technologies deployed on user workstations, such as:
Self Service Anywhere (SSA) / Login Assistant (formally Credential Provider / GINA) interface for domain attached users
Other local kiosk solutions for remote and/or local users
Lotus Notes ID file delivery mechanism
Cached credential controls for external users
Technologies deployed on other servers
Transparent synchronization triggers
Target system agent listeners
Bravura Security proxy servers that run connectors for targets
Notification service clients that run in user domain logon scripts
Reverse proxy servers that allow the web interface to be reached from external networks
High availability technologies
Load balancers that direct traffic to multiple Bravura Security servers either based on load or simple round-robin
Redundancy technologies
Bravura Security replication servers
Third-party systems that make periodic backups of the files and registry on the servers
Third-party systems that make backups of the databases that the Bravura Security servers use
Automation and scheduled events
Nightly scheduled update
Automatically scheduled tasks such as auto discovery and log rotation.
Automated report generation and delivery
Notification of soon-to-expire and other bulk email events
Notifications delivered via plugin points or "exit traps" that trigger when certain conditions are met or actions are performed.
Production change control plan
Consider the following points to help reduce the production service outage:
Since production change control windows are usually small, and are typically scheduled during off-hours, extra attention to detail is required to compensate for the late hours.and disruption of routine. Upgrade plans should should be both explicitly documented and easy to follow. For each step:
Describe exactly what to do in clear, plain language, so the person implementing that step does not have to take time to analyze the wording.
Include a quick test to verify that this step was completed.
Include contingency procedures describing how to troubleshoot failure, back out the change, or redo the change.
Describe conditions to help the team decide if the entire migration has reached a critical impasse and must be backed out.
Communications plan
Developing a communication plan that advises end-users well in advance of the upgrade and what to expect when the new version of the software is up-and-running is an important step. This can help reduce call volume from concerned end-users following the upgrade, and set expectations for what they can and can not do during the upgrade window. Ensure that you notify your help desk so that they know how to handle calls from any users who still have questions or concerns. The nature and amount of end-user or even product administrator communication required will depend on whether the new version of the software has changed the user interface in a dramatic way, significantly altered or added new functionality.
This could include telling users that the web interface will not be available during that time; however they can still reset their passwords directly on the target systems if necessary. You could also need to advise users that their passwords may not be synchronized automatically when changed directly on the target systems, and advise them that they can re-synchronize their passwords at a later time.
Ensure that you notify your help desk so that they know how to handle calls from any users who did not get the first messages.
Note
Due to time format changes from Unix time to ISO date strings, there may be time skews in reports and active access requests.