Someone on our Sametime exam team questioned this this morning and I realised it definitely needs to be publicly called out. The Sametime 9 Community Server no longer has any stpolicy.nsf database or a policies view under the old school web based admin. If you upgrade to Sametime 9 you must install the system console (and db2) to be able to manage and maintain policies going forward.

Something for your planning…

As I said when Sametime 9 shipped, I wanted to spend a few weeks working with it and trying to install it and migrate my existing sites before I blogged.  I’m coming near the end of that now and so wanted to share a few things.  This first blog is about Sametime Communicate which includes Domino , Sametime Community Server, DB2, LDAP, Sametime System Console and Sametime Proxy.  It also includes installing the Sametime Advanced server for Persistent Chat and Broadcast Tools but I want to talk about that separately.

Whether you have installed Sametime 8.5x with WebSphere components or not, Sametime 9 and its install is a very different proposition.  I’m going to start by saying that I would never attempt to upgrade an existing install of WebSphere elements.  IBM in fact say that you should do a side by side upgrade and then move the existing databases for the System Console, Meetings, Advanced and ST Proxy (possibly) over.  That basically involves building an entirely new environment and then switching DNS when you’re ready so your users point there.

It’s my nature to be risk averse and in my testing migrating the existing System Console database is a nightmare. The version of DB2 you should use for Sametime 9 is 10.1, so that means that you’d have to upgrade the database as you migrate. In addition, the schema for the Sametime 9 system console database is not the same as for Sametime 8.5x and, though you can theoretically fix that using the scripts IBM supply, I would rather start completely clean.  The only databases I would make an effort to migrate over are the Meetings and Sametime Advanced because they contain data you can’t lose.  Even so there are no good instructions in the documentation for migrating a Sametime 8.5x Meetings database on DB2 9.7  to a Sametime 9 Meetings database on DB2 10.1 - I would contact IBM support in advance and ask for a tech note with instructions because the documentation has some large gaps there.

Of course, if you don’t have Meetings or ST Advanced right now then you can go ahead and create shiny new databases for your new install.

Download: The first step is to download all the software and get it in place.  Sametime 9 uses WebSphere 8.5 which installs differently than with previous versions of Sametime.  It’s actually a much nicer and easier to manage install, but you will need to install WebSphere by itself before you can install any of the Sametime components.  Make sure you download the version of WebSphere and Installation Manager that is part of the Sametime eAssembly or verify very carefully with the system requirements that you are installing the right version.  Sametime 9 uses WebSphere 8.5 (no fix packs) with additional Sametime specific iFixes, all of which can be downloaded together.

DB2: The version of DB2 supported for Sametime 9 is now 10.1 which is very different in UI from DB2 9.7. For starters, there is no longer a Command Center with a graphical interface allowing you to see and manage databases.  You have to install a separate DB2 client if you want to access the DB2 server and look at the databases. You can install that client on any machine that can access the DB2 server.

WebSphere:  One of the main reasons an in-place upgrade can’t be done is that the underlying version of WebSphere has changed and can’t be upgraded for Sametime.   We have to install WebSphere cleanly.  When installing WebSphere 8.5 you’ll notice the download comes in three parts.  You’ll need to extract all three parts to the same directory which will then contain folders disk 1, disk2 and disk 3 and a file called repository.config in the root folder.  When you install Installation Manager you can then use it to install WebSphere and every other product (other than Domino and the Community Server). You launch Installation Manager and point to the folder where you put your extracted files, it will do the rest.  It sounds complicated but it’s actually very simple and has a huge advantage in that it’s able to search the IBM site for fixes and updates rather than download them each time.

Launch Installation Manager - Choose File - Preferences from the menu and set up your repositories as I have done below (these point to the fixes which were zip files, these didn’t need to be extracted but I wanted them listed separately so I could check them)

Community Server: When installing the Community Server, IBM have added some much needed additional steps to the documentation providing details on performance tuning Windows 2008 and 2012 networking and securing the server to protect against vulnerabilities discovered in the past few years.  None of this is new, it was all public information in technotes but it’s good to see it brought together in the documentation as part of the deployment instructions.  Don’t be tempted to skip over these steps and come back later, they will double the amount of time it takes to install a Community server (from about a day to about a day and a half) but they are important.

If you are moving from an earlier version of Sametime you will need to be using LDAP if you aren’t already and you can’t use your Sametime Community Server as its own LDAP server, that’s not supported and will  present problems.  In fact you should disable LDAP on the Domino server running Sametime completely.

Sametime Proxy Server: The Sametime Proxy server is used for mobile clients, for awareness in web based meetings, for a browser based IM client and more.  You need to install this as a WebSphere component.  It is IBM’s recommendation that each component have its own VM but I have had success in the past co-locating multiple server elements depending on number of users.  There are a few more  settings some of which were available in Sametime 8.5x but again in technotes, etc and so weren’t well known.  Once a Sametime Proxy Server is installed there are several steps to finish the install, as with the Community server, that will improve performance and security. One interesting item that everyone now will probably come across is that the Sametime Advanced server must use the same SSL certificate as the Sametime Proxy server for awareness to work, making wildcard certificates more suitable to our installs.  Previously I had avoided wildcard certs since WebSphere had issues with them in earlier releases but that appears to be resolved now.

Additional steps on completing the install of Sametime Proxy include making sure you connect to the notification servers for both Apple and Google to ensure mobile devices running iOS and Android can receive updates.  There are also settings to tell the Sametime Proxy server to not connect to the user’s home Community server allowing you to explicitly direct traffic to a dedicated Community member instead.  Instructions for that here.

Finally we usually have a WebSphere Proxy server in front of our Sametime Proxy to handle traffic over port 443.  In the Sametime 9 documentation IBM now seem happy to recommend a reverse proxy for accessing  the Sametime Proxy (I have customer doing that and using products like Netscaler) and only using a WebSphere Proxy in front of a cluster of servers.  The WebSphere Proxy is an intelligent authenticating server that will validate the user prior to directing traffic to a Sametime Proxy server.  If you have multiple Sametime Proxy servers in a cluster, the WebSphere Proxy may redirect the traffic to any of them.  Performance tuning for the WebSphere proxy has been nicely consolidated here.

This was meant to be a short blog entry, obviously I haven’t covered everything but hopefully I have given you some pointers.  More to follow…