Thanks to Jeffrey Miller @ IBM for posting a blog page with links to all the latest fixes for the Sametime components.  He has offered to keep this up to date and I strongly suggest you bookmark the page (I did) to save trying to navigate through the hundreds of individual items on fix list and work out what supersedes what.

http://www.mymiller.name/wordpress/sametime/sametime-9-0-latest-published-versions/

I’ve recently run into a problem deploying Sametime Community Server 9.0.1 at two new sites and on an existing 8.5.2 IFR1 site which I’m not 100% convinced is the same issue but as part of my troubleshooting I discovered a missing piece of  policy behaviour that I”m finding extremely useful.

Prior to Sametime 9, policies were deployed on the Community Server and used the database stpolicy.nsf.  That database no longer exists in v9 and later.  In Sametime 8.5.2, if you didn’t deploy the System Console and just had a standalone Community Server you were still using stpolicy.nsf.  As of v9 of Sametime you can no longer do that as stpolicy.nsf no longer exists.   The Community Server must be deployed with the System Console in order to manage policies from within the Console itself. Carry on reading, that’s not the missing link:-)

Here’s a screenshot of the Sametime System Console showing where you set up policies, this is stored in the STSC DB2 database.

From here the policies are pushed down to Community server (Domino) at intervals (approximately hourly) or when the server or policy service restarts so they can be applied to users on login.  This means that clients logging in are receiving policies from the Community server, they aren’t directly looking up policies from the System Console.  If there’s a breakdown in communication between the SSC and the Community server, you can’t push policy updates down to the users.

When installing the Sametime Community Server, the default policy is to allow minimal features through the embedded client, things like screen capture, file transfer and rich text editing are disabled, however I have discovered on two different sites with new 9.0.1 installs, the changes to the default policy were not feeding down to the clients.  The problem was where to track this down.  The policy was right in the System Console but if I turned on POLICY_DEBUG_LEVEL=5 (in the [Debug] section of sametime.ini) I could see that the policy settings being applied did not match those from the System Console.  I even created and deleted additional policies and saw them continue to be ignored through reboots.

So where was the missing piece – somewhere the Community Server was picking up old values but with no stpolicy.nsf there was seemingly nowhere for me to find them.  A separate earlier PMR to IBM pointed me to two new (to me) Xml files on the Community Server file system (domino program directory)

policies.server.xml

policies.user.xml

These are where the System Console policies are written and updated and where the Community server policy service accesses the settings to deploy to users.  The date / time stamp on those files was suspiciously that of the original install, so they hadn’t been updated since then.  The next thing to check is why these weren’t updating.

The first thing to do is test that the Community Server can access and read policies using your wasadmin (or whatever your administrative account it) account.  To do that launch a browser on the Community Server and go to http://sscserver.turtlehost.net:9080/stpolicy/policy/all – you should be prompted for a login, give it your wasadmin name and credentials and the policies should display as a string of values in your browser.  If that works but the policies.server.xml and policies.user.xml files still aren’t updating then the problem may be with how you are telling the Community Server to connect to the SSC.

In the Domino program directory there is a “console” subdirectory and in there is a console.properties file that tells the Community Server how to connect to the System Console.  The contents of that property file are

SSCEncodedAuthorization= [the encoded password for the wasadmin account or whatever your admin account is}
SSCSSLEnabled]=false
SSCHTTPPort=9080
SSCHostName=sscserver.turtlehost.net
SelectedDeploymentId={deployment id of the community server plan in the SSC}
SSCHTTPSPort=9443
LogLevel=FINEST

What’s missing from there is the SSCUserName which identifies the name of the user who is going to login (usually wasadmin) and SSCPassword which contains the unencrypted password for wasadmin (removed and replaced with SSCEncodedAuthorization on first use).  Both of those were required in 8.5.2 versions but don’t seem to be there in 9.0.1  It may be that they shouldn’t be needed but twice now I have seen policies not update after initial install and adding those values to the console.properties , removing the SSCEncodedAuthorization and restarting fixed the problem permanently.  If you add the SSCPassword and remove the SSCEncodedAuthorization you can tell if the connection to the SSC was successful because the properties file will then remove the SSCPassword and replace the SSCEncodedAuthorization.

So there you have it – three missing pieces to help debug policy deployment in Sametime

1. The Domino server based XML files policies.server.xml and policies.user.xml

2. The URL http://sscserver.turtlehost.net:9080/stpolicy/policy/all

3. The console.properties file in the console subdirectory under the Domino program directory