Upgrade Procedures and best practices for migrating to Sametime

Size: px

Start display at page:

Download "Upgrade Procedures and best practices for migrating to Sametime"

Barry Wiggins
6 years ago
Views:

1 Upgrade Procedures and best practices for migrating to Sametime Tony Payne Senior Software Engineer - Sametime IBM Collaboration Solutions Powered by IBM SmartCloud Meetings

2 Agenda A few notes about changes to installs and planning Upgrading to Sametime 9 Migrating from Sametime 8.5.x to Sametime 9.0 User data Key Websphere configuration items to consider Compatibility and running mixed environments Q&A

3 A few notes about changes to installs and planning We are using Installation Manager The installation of Websphere is separate from the Sametime Components This means that you will first run IM to Install the 'base' Websphere image The install of the Sametime Component will create the profiles, federate the nodes, etc The same basic structure for your deployments is true This makes upgrades and patching easier and generally smoother As the pieces are now independent DB is now the default for Sametime 9 But just like for Sametime 8.5.2, if you have (or want to keep using) the previous version of DB2, this is fully supported We are now using Websphere Don't let this change in Websphere versions concern you all of the administration and things you learned about Websphere in 7.0 still apply Even if the UI has changed a little, you still do the same items in the same places For the new Sametime Media Manager components (Video Manager and Video MCU) Linux is required for these components These replace the PacketSwitch Component in x

4 Upgrade Options Due to upgrading the core Websphere version from 7.0 to there are no options for a straight 'in place' upgrade Websphere does not offer this either, they offer some tools for migration of settings/applications. With Sametime 9, you're already installing new applications Many (if not all) of the settings will be recreated with the install Testing with the Websphere provided tools proved, well, its complicated In the more complicated environments, validation of the migration was proving more complicated than simply recreating the needed settings In the most complicated environments (Sametime Media Clusters) parts of the components are changing anyway. So what is the strategy then? Minimize end user disruption Migrate end user data and policies Identify Websphere Settings that will need to be re-created in the new environment In some cases, a mixed rollout will help to ease the hardware requirements of this.

5 Minimize End user disruptions You can continue to use the existing environment while you build the new one Plan and build the full Sametime 9 environment Use production hostnames for testing the staging servers Use local hostfiles for temporary DNS issues This allows you to get SSL and SSO configured Import the LTPA Keys from your production environment If you plan to test against your existing Community Servers For the databases SSC will be a new database, Policy information can be imported from old environment Meetings, Advanced and Proxy database can point to production database or you can use a 'staging' database for testing and change the configuration when ready for production. When the new environment is ready Shut down the Environment Point the DNS hostnames to the new environment Most customers are using DNS aliases and loadbalancers If they're not now would be a good time to help them do that.

6 Migrating end user data and policies There are 2 options available for migrating the information stored in DB2 Keep using your existing Sametime databases running on DB2 9.5 or 9.7 or on DB2 for IBMi Migrate the databases from DB to DB For both options, there are a few changes needed for the product databases Sametime Meetings Update the schema of the Sametime Meetings Database. This does not impact existing meetings, only adding new tables for new features Sametime Advanced There are no schema updates required. There are 3 inserts that need to be manually run for new default configuration items. Sametime Proxy No Schema updates required Sametime Community There are no updates required to VPUserinfo.nsf Sametime Policy There are steps (and scripts) to export/import and upgrade the existing policy information Existing Policy settings will be preserved thru this process

7 Identify Settings that will need to be re-created in the new environment Key Websphere settings that need to be considered Virtual Hosts Both of these Technotes still apply to Sametime Single Sign On Same configuration steps as for previous releases SPNEGO (if applicable) This document still applies, although a few menu items may have moved Environment specific tuning Create backupconfigs of the current environment for comparison to S9 Many of the guidelines will still apply that were covered in the Tuning guide Many of those are incorporated into the default install now. Expect new guidelines and documentation as it becomes available.

8 Minimizing the hardware cost upgrading 'a la cart' - Compatibility Sametime Proxy integration Effort was made to keep the APIs 'backwards compatible' Connections, inotes and STMeetings integration is expected to work if STProxy is upgraded 'separately' Sametime Media S9 clients can use media and Community servers x clients can use S9 Media and S9 Community servers with some limitations and a client HF will be needed x clients can use S9 Media and x Community servers assuming that the x Community servers are registered against S9 SSC. Sametime Community Mixed Server environments should work fine, clients will get the features based on the server version they connect to clients can connect to S9 servers and vice-versa clients will not see new features if connected to an S9 server S9 Clients will not see new features if connected to an x server Sametime Clients Mixed versions can be used there are some known limitations/issues with compatibility

9 Minimizing the hardware cost upgrading 'a la cart' Possible Scenario New SSC, STMeetings, STProxy easiest/fastest to deploy and configure Usually the fewest number of physical machines Keep existing x Community and Media components (and existing SSC to manage) Pros Cons One community Server will be re-registered with the S9 environment for STProxy plan Gets a base environment up and running for testing Browser based access sees immediate UI improvements No new media features Rich client features will depend on which client end user has Don't forget Migrate Meeting and SSC Policy to the S9 versions. Could then start staging/building the S9 Media deployment and then swap Isolate the new Media to a single S9 Community server that is not aware of the existing community You can stage Community upgrades over several weekends Rollout new clients at the end

10 Resource Links Sametime x Migration to Sametime uid=swg IBM Sametime page on Support site: Documentation: Administering IBM Sametime 9: 10.lotus.com/ldd/stwiki.nsf/xpDocViewer.xsp? lookupname=administering+sametime+9.0+documentation#action=opendocument&content=catc ontent&ct=proddoc Plan your upgrade to IBM Sametime 9.0: uid=swg

11 Press *1 on your telephone to ask a question. Visit our Support Technical Exchange page or our Facebook page for details on future events. To help shape the future of IBM software, take this quality survey and share your opinion of IBM software used within your organization: IBM Collaboration Solutions Support page IBM Collaboration Solutions Support 11

Ensuring a smooth upgrade to Sametime and IFR 1

Ensuring a smooth upgrade to Sametime 8.5.2 and 8.5.2 IFR 1 Tony Payne, Sametime L3 February 29,2012 2011 IBM Corporation Agenda Plan Prepare Execute Troubleshoot Validate Known Fixes 2011 IBM Corporation