I updated the SSC, Community server and Sametime Proxy fine but the Meeting server (on Windows) was failing.

ibmim

In the SSCLogs directory I got the following:

2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.SCLogger init ******************************************************
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.api.Deployment setURLTimeout Cannot run program “env”: CreateProcess error=2, The system cannot find the file specified
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.RestURL getBaseURL 172.xx.xx.xxx
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.RestURL getOutput Is SSLEnabled = true
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.RestURL registerMyTrustManager Entered registerMyTrustManager()
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.RestURL registerMyTrustManager Exit registerMyTrustManager()
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.RestURL getOutput AIDSC0877I: The complete URL is :https://ssc..acme.com:9443/console/deployment/login
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.RestURL getOutput Timeout Set is :60000
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.RestURL registerMyTrustManager   Server Certificate for: CN=ssc.acme.com, OU=STAppCell, OU=sscSSCNode, O=IBM, C=US
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.ConnectionThread run AIDSC1482I: Timer is cancelled since URL hit received response.
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.RestURL constructData AIDSC0903I: The data passed to server is :ProductType=com.ibm.lotus.sametime.meetingserver&Hostname=meetings.acme.com&InstallType=PN&ComponentName=
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.RestURL getBaseURL 172.xx.xx.xxx
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.RestURL getBaseURL 172.xx.xx.xxx
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.RestURL sendData AIDSC0877I: The complete URL is :https://ssc.acme.com:9443/console/deployment/getInstallDepId
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.util.ClientUtility getDepId AIDSC0910I: Response from server :<?xml version=”1.0″ encoding=”UTF-8″?><GetDepID><Id></Id></GetDepID>
2016:5:17 22:14:29 com.ibm.sametime.console.deployment.client.api.Deployment getDepId AIDSC0870I: The Deployment ID is :null

I started looking in to “Cannot run program “env”: CreateProcess error=2, The system cannot find the file specified” and “AIDSC0870I: The Deployment ID is :null” and formulated all kinds of theories such as a bug that was trying to run the “env” command which is a Linux command which has a Windows counterpart of “set.” I exhausted my investigation and enabled trace on STConsoleServer (*=info: com.ibm.sametime.*=all) as well as adding log.properties to the logs directory of IBM Installation Manager

I raised a PMR which was quickly turned around.

In the STConsoleServer trace.log the following was found.

[5/19/16 13:21:29:190 BST] 0000033d DeploymentImp > DeploymentImpl getStatus ENTRY
[5/19/16 13:21:29:193 BST] 0000033d DeploymentImp I DeploymentImpl getStatus AIDSC1486I: Size of object 1
[5/19/16 13:21:29:193 BST] 0000033d DeploymentImp I DeploymentImpl getStatus AIDSC1488I: Query Result  = 8
[5/19/16 13:21:29:193 BST] 0000033d DeploymentImp < DeploymentImpl getStatus RETURN

In the SSC I saw that the deployment plan had a status of “partial.” I haven’t a clue when this changed.

mtg

$ db2 connect to STSC

$ db2 “select * from SSC.DEPLOYMENT where PRODUCTTYPE = ‘com.ibm.lotus.sametime.meetingserver'”

$ db2 “select DEPSTATUS from SSC.DEPLOYMENT where PRODUCTTYPE = ‘com.ibm.lotus.sametime.meetingserver'”

DEPSTATUS
—————————————————————————————————-
8

$ db2 “select DepID from ssc.deployment where DEPSTATUS = ‘8’”

DEPID
————————————————————————————————————————————————————————————————————————————–
14f4cd91acd-00000000000a-MTGSDep

The fix was to change the DEPSTATUS to 1542. This is done by backing up the database first of all and then using the earlier commands to obtain the DepID change the DEPSTATUS

$ db2 “UPDATE ssc.deployment SET DEPSTATUS = ‘1542’ WHERE DepID = ’14f4cd91acd-00000000000a-MTGSDep'”

In the SSC the deployment status is correct.

mtg2

Now IBM IM passes the validation stage and I can update the Meeting server.

A very recent go live of IBM Connections 5.5 from 4.5 resulted in an error affecting Metrics. Metrics was not working what so ever.

A look at the cogserver.logs showed DB2 exceptions. I checked the DB2 client on the Cognos node, it could connect. I noticed that all the daily refreshes failed so it must have been database related.

I checked the value of the numdb having set the value to 25 after the databases were created prior to transfer of the 4.5 data. Running db2 get dbm cfg | find “NUMDB” gave me the value of 15 which is not what I set. I checked my notes and I did set it to 25.

I looked at db2diag.log and could see that the value changed at the time of go live, in fact it had changed after the databases were created and after I had changed the value to 25.

PID     : 7376                 TID : 3468           PROC : db2bp.exe
INSTANCE: DB2                  NODE : 000           DB   : HOMEPAGE
APPID   : *LOCAL.DB2.
HOSTNAME:
EDUID   : 3468
FUNCTION: DB2 UDB, config/install, sqlfLogUpdateCfgParam, probe:30
CHANGE  : CFG DBM: “Numdb” From: “25”  To: “15”

The above entry was at the same time that activity was happening with HOMEPAGE database.

I checked the scripts I had written and all seemed well. I then checked the lcwizard logs directory and found in C:\Users\db2admin\lcWizard\log\dbWizard\homepage_upgrade-50CR3-55.log the following

UPDATE DBM CFG USING NUMDB 15
DB20000I  The UPDATE DATABASE MANAGER CONFIGURATION command completed
successfully.

In ..\Wizards\connections.sql\homepage\db2\upgrade-50CR3-55.sql I found the culprit.

— —————————————————————–
— Defect 164873:
— —————————————————————–

UPDATE DBM CFG USING NUMDB 15@

I really have no idea why IBM would put that in there. There are 16 databases if you include FEBDB. Why have it for HOMEPAGE and not the other database scripts?

I updated the number of databases and then stopped all the application servers and restarted DB2 for good measure and all is well now.

During a 4.5 –> 5.5 migration I got the following when running the transfer scripts for METRICS and PEOPLEDB.

[02/03/16 16:33:26.659 CET] com.ibm.db2.jcc.am.SqlTransactionRollbackException: Error for batch element #1: DB2 SQL Error: SQLCODE=-1476, SQLSTATE=40506, SQLERRMC=-964, DRIVER=3.69.49
[02/03/16 16:33:26.659 CET] com.ibm.db2.jcc.am.SqlException: [jcc][103][10843][3.69.49] Non-recoverable chain-breaking exception occurred during batch processing.  The batch is terminated non-atomically. ERRORCODE=-4225, SQLSTATE=null
[02/03/16 16:33:26.659 CET] error.executing.transfer
err.dbtransfer.exception.labelclass com.ibm.db2.jcc.am.BatchUpdateException: [jcc][t4][102][10040][3.69.49] Batch failure.  The batch was submitted, but at least one exception occurred on an individual member of the batch.
Use getNextException() to retrieve the exceptions for specific batched elements. ERRORCODE=-4229, SQLSTATE=null
com.ibm.db2.jcc.am.BatchUpdateException: [jcc][t4][102][10040][3.69.49] Batch failure.  The batch was submitted, but at least one exception occurred on an individual member of the batch.
Use getNextException() to retrieve the exceptions for specific batched elements. ERRORCODE=-4229, SQLSTATE=null

Looking in the db2diag.log I saw the following

2016-02-03-18.49.00.983000+060 E44991171F646        LEVEL: Error
PID     : 2348                 TID : 1580           PROC : db2syscs.exe
INSTANCE: DB2                  NODE : 000           DB   : METRICS
APPHDL  : 0-809                APPID: 15.91.29.211.49843.160203173533
AUTHID  : DB2ADMIN             HOSTNAME:
EDUID   : 1580                 EDUNAME: db2agent (METRICS) 0
FUNCTION: DB2 UDB, data protection services, sqlpgResSpace, probe:2860
MESSAGE : ADM1823E  The active log is full and is held by application handle
          “0-809”.  Terminate this application by COMMIT, ROLLBACK or FORCE
          APPLICATION.

2016-02-03-18.49.00.983000+060 E44991819F610        LEVEL: Error
PID     : 2348                 TID : 1580           PROC : db2syscs.exe
INSTANCE: DB2                  NODE : 000           DB   : METRICS
APPHDL  : 0-809                APPID: 15.91.29.211.49843.160203173533
AUTHID  : DB2ADMIN             HOSTNAME:
EDUID   : 1580                 EDUNAME: db2agent (METRICS) 0
FUNCTION: DB2 UDB, data protection services, sqlpgResSpace, probe:6666
MESSAGE : ZRC=0x85100009=-2062548983=SQLP_NOSPACE
          “Log File has reached its saturation point”
          DIA8309C Log file was full.

It means that the DB2 transaction log has become full which you can get information of from the following URLs

http://www-01.ibm.com/support/docview.wss?uid=swg21623212

http://www-01.ibm.com/support/docview.wss?uid=swg21617184

http://bpmadmin.blogspot.com/2014/04/db2-sql-error-sqlcode-1476.html

To get the data transferred I used the following values (the values you need may differ) and commands

db2 update db cfg for metrics using LOGFILSIZ 10000
db2 update db cfg for metrics using LOGPRIMARY 80
db2 update db cfg for metrics using LOGSECOND 40

db2stop
db2start

db2 get db cfg for metrics
Log file size (4KB)                         (LOGFILSIZ) = 10000
Number of primary log files                (LOGPRIMARY) = 80
Number of secondary log files               (LOGSECOND) = 40

I was then able to run the transfer for both these databases.

You may want to change the values back to the default values as it will have an impact on disk space and possibly performance.

During a database transfer from Connections 4.5 CR05 (DB2 10.1) to Connections 5.5 (DB2 10.5.0.7) I ran across a number of transfer failures using the tool. After a bit of digging such as looking at db2diag.log and DB2 Technotes I found the problem was that the DB2 transaction logs were being filled. Below are some example errors.

[02/03/16 16:33:26.659 CET] com.ibm.db2.jcc.am.SqlTransactionRollbackException: Error for batch element #1: DB2 SQL Error: SQLCODE=-1476, SQLSTATE=40506, SQLERRMC=-964, DRIVER=3.69.49
[02/03/16 16:33:26.659 CET] com.ibm.db2.jcc.am.SqlException: [jcc][103][10843][3.69.49] Non-recoverable chain-breaking exception occurred during batch processing.  The batch is terminated non-atomically. ERRORCODE=-4225, SQLSTATE=null
[02/03/16 16:33:26.659 CET] error.executing.transfer
err.dbtransfer.exception.labelclass com.ibm.db2.jcc.am.BatchUpdateException: [jcc][t4][102][10040][3.69.49] Batch failure.  The batch was submitted, but at least one exception occurred on an individual member of the batch.
Use getNextException() to retrieve the exceptions for specific batched elements. ERRORCODE=-4229, SQLSTATE=null
com.ibm.db2.jcc.am.BatchUpdateException: [jcc][t4][102][10040][3.69.49] Batch failure.  The batch was submitted, but at least one exception occurred on an individual member of the batch.
Use getNextException() to retrieve the exceptions for specific batched elements. ERRORCODE=-4229, SQLSTATE=null

Db2diag.log

EDUID   : 1580                 EDUNAME: db2agent (METRICS) 0
FUNCTION: DB2 UDB, data protection services, sqlpgResSpace, probe:6666
MESSAGE : ZRC=0x85100009=-2062548983=SQLP_NOSPACE
“Log File has reached its saturation point”
DIA8309C Log file was full.

In http://www-01.ibm.com/support/docview.wss?uid=swg21623212 it suggests increasing the sizes for LogFilSiz, LogPrimary, and LogSecond. On the second attempt changing these settings I found values that worked (for me).

db2 update db cfg for metrics using LOGFILSIZ 10000
db2 update db cfg for metrics using LOGPRIMARY 80
db2 update db cfg for metrics using LOGSECOND 40
db2stop
db2start

I had to increase the default values for Metrics and Profiles as they contain a lot of data.

You may want to reset the values after migration so you do not impact disk space.

I had a few problems with a customer’s deployment of Sametime 9 which probably come down to deployment plans and the order of the servers being installed.

During installation I had problems detailed in “System version is null” on new IBM Sametime Video Manager installation which forced me to uninstall the VMGR and install again with a new deployment plan. The outcome of this was that I could not administer the default policies nor create new Media Manager policies in the SSC, I saw the following error, “AIDSC#####: Could not connect to Sametime Video Manager. Either VMgr is not installed or server is not up. Please retry after installing VMgr or starting it.”

1

I saw in the deployment manager SystemOut.log “[17/10/14 17:02:04:101 BST] 00000220 SametimeVmgrU E   Forbidden” but nothing much else to write home about.

I raised a PMR with IBM and gathered some trace and sent it off. The PMR ended up with Ankit Vij in L3 who worked as a developer on the propagation of policies from the SSC to the VMGR.

After some to’ing and fro’ing it was identified that there were missing credentials in the DEPLOYMENT table of the SSC database. In the DEPCONF  column of the Conference Manager deployment plan lies XML data. In the data are two fields VMGRUSER and VMGRPASSWORD. In the customer’s data these values were empty, this is why the SSC couldn’t access the VMGR’s policies.

There are few ways in which to edit the data, Data Studio is nice and easy and can export the table, edit it and then import it again in no time at all but as I was accessing their environment using Citrix this wasn’t an option because I couldn’t install any software. Using the CLI was the only way to do it.

My first attempts of using the DB2 EXPORT command failed because the tables have LOBs which are truncated when you export the data to a csv file. The way around it is to export to a csv file but also export all the data to LOB files. This can be achieved using the following command.

C:\Windows\system32>db2 “export to d:\export\deployment.csv of del lobs to d:\export\lobs\ modified by lobsinsepfiles select * from ssc.deployment”
SQL3104N  The Export utility is beginning to export data to file
“d:\export\deployment.csv”.

This produces a csv. Where there was LOB data a .lob file is produced and the csv details which number .lob file holds the information for that particular entry.

Once I had found the .lob file referenced for the Conference Manager deployment plan in the DEPCONF  column I had to copy the contents of the .lob to a new text file.

The VMGRUSER and VMGRPASSWORD values were empty so I then updated them with wasadmin (could be admin/admin) and the password associated with it.

Next I had to add to the beginning of the xml data UPDATE SSC.DEPLOYMENT SET DEPCONF=’ and to the end ‘ WHERE DEPID=’14908a6aa1d-00000000000a-MediaDep’

The DEPID is easy to come about and is listed DEPID column for the Conference Manager deployment plan.

The end result is a single line containing 18000+ characters looking something like this.

UPDATE SSC.DEPLOYMENT SET DEPCONF='<?xml version=”1.0″ encoding=”UTF-8″?>………………………….</parameter></parameters></Config>’ WHERE DEPID=’14908a6aa1d-00000000000a-MediaDep’

As the command was too large to paste into the CLI I saved it to a .sql file.

I stopped STConsoleServer, the node agent and the deployment manager.

Before changing the database I needed to back it up.

C:\Windows\system32>db2 backup database stsc
SQL1035N  The database is currently in use.  SQLSTATE=57019

I then needed to force the application connections from the database.

C:\Windows\system32>db2 list applications

Auth Id  Application    Appl.      Application Id                                                 DB       # of
Name           Handle                                                                    Name    Agents
——– ————– ———- ————————————————————– ——– —–
DB2ADMIN db2jcc_applica 41961      192.168.x.x.49442.141124093130                              STSC     1
DB2ADMIN db2jcc_applica 45374      192.168.x.x.61230.141125142939                              STMS     1
DB2ADMIN db2jcc_applica 45483      192.168.x.x.61666.141125152718                              STMS     1
DB2ADMIN db2jcc_applica 41949      192.168.x.x.49385.141124093116                              STMS     1

C:\Windows\system32>db2 force application(41961)
DB20000I  The FORCE APPLICATION command completed successfully.
DB21024I  This command is asynchronous and may not be effective immediately.

After all applications are disconnected I could run the backup.

 C:\Windows\system32>db2 backup database stsc

Backup successful. The timestamp for this backup image is : 20141125154621

C:\Windows\system32>db2 connect to stsc

   Database Connection Information

 Database server        = DB2/NT64 10.1.0
 SQL authorization ID   = DB2ADMIN
 Local database alias   = STSC

At this point I am going to run the UPDATE command using the .sql file I created.

C:\Windows\system32>db2 -vf C:\DB2\ssc.sql

DB20000I  The SQL command completed successfully.

Normally I would run db2 -tvf but that didn’t work, I think because I didn’t use semicolons for delimiters in the .sql file. Anyway, it worked.

I started the deployment manager, node agent and STConsoleServer and I could now edit the Media Manager policies.

Many thanks to Imran and Ankit at IBM for helping me through this frustrating but interesting problem.

A customer wanted to use a series of nested groups to populate Profiles. The theory is that the parent group has a number of child groups which are controlled by various location specific administrators.

Initially I hoped to be able to achieve this by using a special query (LDAP_MATCHING_RULE_IN_CHAIN) which would walk to the root and thus include all members of the nested groups.

“(&(objectClass=user)(member:1.2.840.113556.1.4.1941:(=CN=IBM Connections Users,DC=acme,DC=com)))”

I couldn’t get this to work using ldapsearch so I had their AD admins investigate. They too could not get it to work so the work around was to add all the groups to the source_ldap_search_filter value in profiles_tdi.properties. The search filter consisted of over 26000 characters!!

On running sync_all_dns I saw failures (after enabling debug from Profiles MustGather) in the ibmdi.log. The errors matched Population or Synchronization fails trying to update the Peopledb with the error SQLCODE: -302, SQLSTATE: 22001

I was hesitant to go ahead and make the changes details and read else where that LONG VARCHAR is deprecated in 9.7 potentially meaning CLOB datatype was required. I raised a PMR with IBM to check and they came back and said that there is no change made to PROF_SOURCE_URL in the later versions of Connections. The one pain could be if a side by side migration to 4.5 (or later) is performed as the new database will have VARCHAR as the datatype. With some forward planning this migration failure can be removed.

My DB2 colleague and I decided to back up PEOPLEDB and then run the following command to dump the definitions of the database before altering the datatype.

db2look -d PEOPLEDB -f -l -e -x > D:\db2look_peopledb_prechange.txt

To alter the datatype we used the Control Center which gave us the below SQL.

CONNECT TO PEOPLEDB;
CALL SYSPROC.ALTOBJ ( ‘APPLY_CONTINUE_ON_ERROR’, ‘CREATE TABLE EMPINST.EMPLOYEE ( PROF_KEY VARCHAR (36)  NOT NULL , PROF_UID VARCHAR (256)  NOT NULL , PROF_UID_LOWER VARCHAR (256)  NOT NULL , PROF_LAST_UPDATE TIMESTAMP  NOT NULL , PROF_MAIL VARCHAR (256) , PROF_MAIL_LOWER VARCHAR (256) , PROF_GUID VARCHAR (256)  NOT NULL , PROF_SOURCE_UID VARCHAR (256)  NOT NULL , PROF_DISPLAY_NAME VARCHAR (256) , PROF_LOGIN VARCHAR (256) , PROF_LOGIN_LOWER VARCHAR (256) , PROF_GIVEN_NAME VARCHAR (128) , PROF_SURNAME VARCHAR (128) , PROF_ALTERNATE_LAST_NAME VARCHAR (64) , PROF_PREFERRED_FIRST_NAME VARCHAR (32) , PROF_PREFERRED_LAST_NAME VARCHAR (64) , PROF_TYPE VARCHAR (64) , PROF_MANAGER_UID VARCHAR (256) , PROF_MANAGER_UID_LOWER VARCHAR (256) , PROF_SECRETARY_UID VARCHAR (256) , PROF_IS_MANAGER CHARACTER (1) , PROF_GROUPWARE_EMAIL VARCHAR (128) , PROF_GW_EMAIL_LOWER VARCHAR (128) , PROF_JOB_RESPONSIBILITIES VARCHAR (128) , PROF_ORGANIZATION_IDENTIFIER VARCHAR (64) , PROF_ISO_COUNTRY_CODE VARCHAR (3) , PROF_FAX_TELEPHONE_NUMBER VARCHAR (32) , PROF_IP_TELEPHONE_NUMBER VARCHAR (32) , PROF_MOBILE VARCHAR (32) , PROF_PAGER VARCHAR (32) , PROF_TELEPHONE_NUMBER VARCHAR (32) , PROF_WORK_LOCATION VARCHAR (32) , PROF_BUILDING_IDENTIFIER VARCHAR (64) , PROF_DEPARTMENT_NUMBER VARCHAR (24) , PROF_EMPLOYEE_TYPE VARCHAR (256) , PROF_FLOOR VARCHAR (16) , PROF_EMPLOYEE_NUMBER VARCHAR (16) , PROF_PAGER_TYPE VARCHAR (16) , PROF_PAGER_ID VARCHAR (32) , PROF_PAGER_SERVICE_PROVIDER VARCHAR (50) , PROF_PHYSICAL_DELIVERY_OFFICE VARCHAR (32) , PROF_PREFERRED_LANGUAGE VARCHAR (100) , PROF_SHIFT VARCHAR (4) , PROF_TITLE VARCHAR (256) , PROF_COURTESY_TITLE VARCHAR (64) , PROF_TIMEZONE VARCHAR (64) , PROF_NATIVE_LAST_NAME VARCHAR (256) , PROF_NATIVE_FIRST_NAME VARCHAR (256) , PROF_BLOG_URL VARCHAR (256) , PROF_FREEBUSY_URL VARCHAR (256) , PROF_CALENDAR_URL VARCHAR (256) , PROF_DESCRIPTION CLOB  (1048576   )  LOGGED  NOT  COMPACT , PROF_EXPERIENCE CLOB  (1048576   )  LOGGED  NOT  COMPACT , PROF_SOURCE_URL “LONG VARCHAR” , PROF_SRC_UID_LOWER VARCHAR (256)  NOT NULL , TENANT_KEY VARCHAR (36)  NOT NULL  WITH DEFAULT ‘00000000-0000-0000-0000-040508202233’ , PROF_STATE INTEGER  NOT NULL  WITH DEFAULT 0   ) IN USERSPACE32K INDEX IN USERSPACE4K LONG IN USERSPACE32K ‘, -1, ? );
CONNECT RESET;

After running this the datatype of the column changed to LONG VARCHAR.

We run the definitions dump again and compared the contents with the pre-change information. The contents were the same albeit in a different order.

db2look -d PEOPLEDB -f -l -e -x > D:\db2look_peopledb_prechange.txt

This gave us confidence to continue and started Connections. At which point the sync_all_dns completed successfully and the users in the nested groups are populated to Profiles. Checking EMPLOYEE.PEOPLEDB shows the very long search filter in the PROF_SOURCE_URL for those that were added recently.

Thankfully I knew that I was going to come across one of these problems. When upgrading the policies need to also be upgraded and the wiki describes the process well. Prior to starting the upgrade I tested the approach of editing the LDAP document in the SSC but got the following error

??? nl.ErrorResourceMessages|CWWIM5044E The ******* repository cannot be deleted because it has at least one base entry that is referenced by a realm. [en] ???

To enable SSO to work across Portal, Connections, Domino and Sametime I had to configure a realm which was in line with the other environments as well as make some modifications to my wimconfig.xml. The error above is telling me that it doesn’t like the fact that the realm is different to defaultWIMFileBasedRealm, (more information about how to do this can be found in this Technote).

This had me concerned that this could jeopardize the upgrade so I read around and found the following IBM documents which are worth bearing in mind, LO70452 and LO56702. The former suggested that I change the realm back to defaultWIMFileBasedRealm as it breaks the LDAP guided activity which is what I need to step through. By changing the realm name I saw synchronisation errors with the nodes but that was quickly rectified after the policies were upgraded and the realm reverted to what it was. I ensured that I shut down all the nodes and their node agents and ensured synchronisation was working.

The other problem I came across was just after the clustered Meeting servers were upgraded to 8.5.2 is detailed in After upgrading to 8.5.2, users are no longer able to enter Sametime Meeting Rooms. The instruction in the Technote suggest that you run some DB2 commands to purge the contents of the POLICY.TEMPLATE and POLICY.ASSIGNMENT tables in STSC database. That is all good and well but you will lose ALL your policies so be very careful about doing that.

You can of course take a back up of the database as well as manually making a not of all your policies and their settings.
Below are a couple of commands that may make it easier for you.

db2 “select count(*) as rows from POLICY.ASSIGNMENT” and db2 “select count(*) as rows from POLICY.TEMPLATE”
The above will allow you to check that the number of rows and when run afterwards it checks that it has worked.

This allows you to dump the data out to a text file. This doesn’t give you the configuration of the policy just those who are assigned to them
db2 “select * from POLICY.TEMPLATE” > /tmp/policy.template.original.txt
db2 “select * from POLICY.ASSIGNMENT” > /tmp/policy.assignment.original.txt

This is the command to purge the contents
db2 “delete from POLICY.TEMPLATE”
db2 “delete from POLICY.ASSIGNMENT”

It worked for me BUT I had to recreate the policies.