Monday, November 11, 2013

Upgrading your Sametime DB2 databases for Sametime V9



Upgrading your Sametime DB2 databases for Sametime V9

In an "upgrade" from a Sametime V8.5 deployment to Sametime V9, probably the most important thing is to keep is the database information in the Sametime Console (just the policies), Sametime Meetings and Sametime Advanced  DB2 databases. Sametime V9 uses a newer version of DB2 (V9 moves to V10.1 because DB2 V9 went to “end of support” on April 30, 2012), so the databases will need to be upgraded and moved onto a DB2 V10.1 server. IBM’s technote covers this DB2 upgrade.
I haven't tried the upgrade procedure yet, so please feel free to post results on this blog post.

I did note on this technote that you can leave the older version of DB2 running and just update the actual databases, whereas if you upgrade to V10 DB2, you have to do that and then upgrade the actual DB2 databases...

Tuesday, September 10, 2013

Sametime V9 due out soon

Sametime V9 is due out pretty soon - September 20th is the date I have seen on the Sametime Blog.
The new version promises better features on the Video side and a new, sexier interface.... Once I download it, I will be writing a more thorough review. I will leave judgement until then :-)

Saturday, April 20, 2013

Control of Sametime user policy using Managed Settings in Domino Policy

For the past few years I have advised against using Managed Settings in Domino Policy because of bad experiences using this particular way to manage the Sametime clients. For one thing, you can't managed the stand-alone client this way which means that unless you are 100% sure that users will use the embedded Notes ST client, you should always use the Managed-settings.xml file approach.
Having said that, I have clients that have used the Managed Settings in Domino Policy because that the way they manage their users Notes clients and no-one in their environment uses the stand-alone client. When I have worked with these clients on Sametime deployments, I have moved them to the XML-based way of thinking but in some cases we have had residual effects left behind by the attempted usage of Managed Settings in Domino Policy. These residual effects were left due to a misunderstanding of the way Managed Settings in Domino Policy works.
When you set a Managed Settings in Domino Policy, you set it in the Desktop Policy settings under the "Managed Settings" tab which is under the "Custom Settings" main tab i.e.
The most important thing to mention here is:
IF YOU WANT TO REMOVE THESE SETTINGS, DO NOT SIMPLY DELETE THE SETTING FROM HERE.
If you already set this in the policy, then the setting is saved to the desktop policy. If you delete this line, it DOES NOT remove this setting from the policy. This is "working as designed" by IBM and it is understandable if you think about it.
So if you want to change this setting, you set it to "off" or "false" or whatever you need it to be set to, to turn it off.... just remember, you don't delete the line.
Using this approach, you can rectify issues that may have set desktop policy in the past and there is no reference in the GUI to the setting - you can only find these settings by looking at the Policy using "Document - properties" on the Policy document (or by using a cool tool like the Ytria scanEZ tool)

To validate what I just stated above about the policy not being deleted, I removed the two lines you see in the screen shot above and saved the policy - here is a a screenshot of the policy with the two lines removed but with the document properties window open to show the actual settings STILL in the policy:

So the bottom line here is not to use Managed Settings in Domino Policy if at all possible and use Managed-Settings.xml in a web accessible form for providing Sametime user's with policy. However, if someone has dabbled previously with Managed Settings in Domino Policy, bear this in mind as there may be hidden policy settings that you cannot see through the GUI affecting the Policy that is pushed to the client.