IBM Docs 2 CR3 is here – and with some cool new features

So at last IBM Docs 2 CR3 has been released and with it some awesome new features that the community have been asking for (thank you IBM).

 

What’s new in Docs 2 CR3? LOADS of new features and fixes including …

The most exciting is probably the ability to deploy the Conversion server on linux (finally)!!

  • You can directly deploy Conversion server on Linux when installing IBM Docs.
  • If you already have IBM Docs installed with Conversion server on Windows, you can migrate existing Conversion server from Windows to Linux.

 

A track change feature for the Docs editor which is another feature that has been on the wish list for a while

  • Added Track Change support in Document Editor. People with editing access can use a new view in the sidebar to see what changes were made to the file and when and who. Changes can be filtered by the timeline and editors. File owners can turn Track Change on and off, and clear change history.

 

You can install CR3 straight over Docs 2, no need for the other CRs or iFixes – make sure you run the DB updates though to update the Docs schema.

 

Additional features and full realse notes can be found here: IBM Connections Docs 2 CR3 release notes

Download it now from Fix Central 🙂

Issues with IBM Connections 5 / 5.5 and Chrome 60

There is a known issue with Connections 5 CR4 and all versions of Connections 5.5 when using Chrome version 60.

It affects events not being displayed and errors relating to events in the UI. It has also been reported that comments can be affected also.

After multiple BP’s and Customers reported this IBM Support have come up with a fix very quickly.

The fix you need is IFLO92844 – currently it is only available from IBM support – not sure how long it will be until it is available on fix central.

Open a PMR with IBM and reference these 3 PMR numbers: 76364,082,000 – 76379,082,000 – 38309,756,000 and ask for IFLO92844. You will need to specify the Connections version and CR.

The fix updates the Common app and takes about 10 mins to deploy.

Thank you IBM Connections Support / Dev for resolving this so quickly

Connections 6 migration observations

I am sure that lots of you have installed or started migrations to Connections 6 by now .. but I have found a couple of gotchas across the installs and updates that I have managed so far.

I am listing them here for sanities sake as I know when we google an error – this blog will show up 🙂

 

Connections 6 itself

 

Generally this was a nice smooth install and all worked as it should in a clean 6 environment

On testing a migration though I found issues when trying to migrate some of the DBs.

After dropping and restoring the DBs some were not updating to the latest DB2 version – this is resolved by running the update DB command

db2 upgrade db <DBNAME>

this upgrades the DB to the latest DB2 version – I run this after each restore command now to ensure the DB does update

for example

db2 restore db BLOGS from E:\install\V55_Backup\db2_backup taken at 20170718123342 ON E:\ into BLOGS
db2 upgrade db BLOGS

 

The metrics DB would not restore as it was complaining about heap size – after a quick google on the error I found a page suggesting just to change the application heap size using the following command

db2 UPDATE DB CFG FOR METRICS USING APPLHEAPSZ 4000

This resolved the problem and the metrics DB could be restored

 

I have also seen issues with the Connections DB update wizard when the databases have a lot of data. In a mature environment I generally run through the wizard and save the update commands to a text file. Then execute them manually from the db2 command window – for example

Activities
 1. E:\IBM\SQLLIB\bin\db2cmd -c -w -i db2 -td@ -vf connections.sql\activities\db2\upgrade-55CR2-60.sql
 2. E:\IBM\SQLLIB\bin\db2cmd -c -w -i db2 -td@ -vf connections.sql\activities\db2\appGrants.sql
 3. E:\IBM\SQLLIB\bin\db2cmd -c -w -i db2 -td@ -vf connections.sql\activities\db2\reorg.sql
 4. E:\IBM\SQLLIB\bin\db2cmd -c -w -i db2 -td@ -vf connections.sql\activities\db2\runstats.sql

Blogs
 1. E:\IBM\SQLLIB\bin\db2cmd -c -w -i db2 -td@ -vf connections.sql\blogs\db2\upgrade-55-60.sql
 2. E:\IBM\SQLLIB\bin\db2cmd -c -w -i db2 -td@ -vf connections.sql\blogs\db2\appGrants.sql
 3. E:\IBM\SQLLIB\bin\db2cmd -c -w -i db2 -td@ -vf connections.sql\blogs\db2\reorg.sql
 4. E:\IBM\SQLLIB\bin\db2cmd -c -w -i db2 -td@ -vf connections.sql\blogs\db2\runstats.sql

Bookmarks
 1. E:\IBM\SQLLIB\bin\db2cmd -c -w -i db2 -td@ -vf connections.sql\dogear\db2\upgrade-55-60.sql
 2. E:\IBM\SQLLIB\bin\db2cmd -c -w -i db2 -td@ -vf connections.sql\dogear\db2\appGrants.sql
 3. E:\IBM\SQLLIB\bin\db2cmd -c -w -i db2 -td@ -vf connections.sql\dogear\db2\reorg.sql
 4. E:\IBM\SQLLIB\bin\db2cmd -c -w -i db2 -td@ -vf connections.sql\dogear\db2\runstats.sql

.................. ETC.

For some reason if you have large DBs the wizard struggles massively. Running the commands manually from the command window also allows you to dump each commands logs out into a text file if you need to. Great for debugging and used a LOT when I ran through the AIX Oracle to Windows DB2 migration last year.

 

Once the DBs were restored and updated run the reorg and runstats against each of the DBs before you start it up and if you can also run the clearScheduler.sql for each DB.

That should sort out the majority of DB issues you may see during the update.

 

Connections TouchPoint

 

Again a fairly easy process once you work out what the documentation is talking about – things of note

The document speaks of copying the touchpoint folder contents to the htdocs directory –

 

 

 

 

 

 

you have to copy the entire folder – for example

Copy files from E:\install\Connections\Touchpoint\touchpoint to E:\IBM\HTTPServer\htdocs\touchpoint the wording in the documentation doesn’t really make that clear.

All of the paths etc in the documenation are case sensitive.

Another thing of note which has tripped me up twice now so I have to blog it (thank you Ben for the extra eyes on this one) is the contents of the touchpoint.deploy.properties

The touchpoint.deploy.properties which is included in the install files is different from the example the documentation gives, we basically mix the two and have the contents of the file looking like this

# when install to a clustered environment, provide clusterName.
# when install to a standalone server, provide node and server name.
clusterName=apps
#nodeName=icbvtDB2Node01
#serverName=server1

# setting required REE custom properties
ree.prop.image.upload.path=E:/IBM/CnxData/shared/touchpoint/upload_pic
ree.prop.profiles.app.entrypoint.host=connections.url.com
ree.prop.profiles.app.entrypoint.scheme=https
ree.prop.profiles.app.entrypoint.port=443

NOTE:  If using windows the image upload path must have / the linux way not \ the windows way. It will fail if you don’t even if you have it in “E:\IBM\etc…” it appears to be a java / python thing and the error will complain that it can not pass the properties file if the slashes are not /

 

IBM Docs CR2

 

To use IBM Docs with Connections 6 you must update to CR2 for Docs – that is fine (and see previous blog posts about issues with applying the CR2 fix).

There is an awesome gotcha that my good friend Roberto pointed me in the direction of the fix for – this one was a good one (thank you Marti for writing the blog)

The symptoms are Docs editing works fine, but when attempting to view a file the error : CLFAF400W: Can’t access the document repository appears

Its a super quick fix – edit the viewer-config.json which can be found in the (i.e \IBM\WebSphere\AppServer\profiles\Dmgr01\config\cells\<cell name>\IBMDocs-config)

Under the section

"components": [
 {
 "config": {
 "uploadRepository": "lcfiles",

find the line

 "class" : "com.ibm.concord.viewer.lc3.repository.LCFilesEJBRepository",

and replace it with

 "class": "com.ibm.concord.viewer.lc3.repository.LCFilesCMISRepository"

Just above that you can see the files_path

 "files_path": "E://IBM//CnxData//shared/files/upload"

Add the additional info to that section

 "j2c_alias": "connectionsAdmin", 
 "s2s_method": "j2c_alias", 
 "server_url": "https://connections.url.com/files",
 "files_path": "E://IBM//CnxData//shared/files/upload"

So the full section will now look like this:

 "components": [
 {
 "config": {
 "uploadRepository": "lcfiles", 
 "adapters": [
 {
 "config": {
 "j2c_alias": "connectionsAdmin", 
 "s2s_method": "j2c_alias", 
 "server_url": "https://connections.url.com/files",
 "files_path": "E://IBM//CnxData//shared/files/upload"
 }, 
 "id": "lcfiles", 
 "class": "com.ibm.concord.viewer.lc3.repository.LCFilesCMISRepository"
 },

 

Save the file and do a full sync once a restart of the viewer app is done the viewer will now work.

 

One other thing of note when it comes to migrating the Docs data and DBs is that almost every time you do a migration the wasadmin user will be out of sync and you will see duplicate user issues in the log.

easily resolved by running the syncMember command from the DMGR\bin directory

wsadmin.bat -lang jython

execfile("filesAdmin.py")

FilesMemberService.syncMemberExtIdByLogin("wasadmin")

 

Other things you should do once the docs data has been migrated is to run the generate thumbnails command (also from wsadmin in the filesAdmin section)

wsadmin.bat -lang jython

execfile("filesAdmin.py")

FilesThumbnailService.generateForAllFiles()

 

Also to migrate any drafts from the docs installer directory i.e

wsadmin.bat -lang jython -f E:/IBM/ConnectionsDocs/Docs/installer/docs/tasks/start_migration_tool.py

 

Hopefully you won’t come across any or more than one of these issues, but if you do hopefully there will be a quick resolution.

If I find anything else I will be sure to blog them.

Docs 2.0 CR2 – here we go again

I am blogging this mainly so I remember how to solve this

Big thanks to fellow ICS community member and all round great guy Robert Farstad for blogging this

Again you can see a problem when patching Docs 2 to CR2 as it can’t find the FQDN of the hosts.

The code has changed so it’s not possible to use the work around that we had previously.

There is a slight twist to getting it to work which Rob has explained fabulously so thank you mate .. you saved me a lot of grief .. and even IBM point people to that blog as they did when I opened a PMR to find out how to fix it .. 🙂

Migrating Connections DB from Oracle to DB2 part 3

In part 3 of the series we will actually attempt to migrate the data.

 

Migrating Connections DB from Oracle to DB2

In my experience the database migration is always most time consuming, so I always do the database first

Use the text file of Commands that we created in part 2.

  • Back up the exisitng Connections databases
  • Drop database, create database, app grants (for homepage also initdata, and re org and run stats)
  • CR update scripts
  • Pre DB fixer script
  • Run the DBT command
  • Application specific scripts (IBM provided addional fixup scripts for Blogs, Files and Wikis for me)
  • Post DB fixer script
  • Re org script
  • Run stats script

I run the commands one database at a time. This made it much easier for troubleshooting issues and ensuring that each database was in a consistent migrated state before moving onto the next – if I had issues I made notes in the commands text file and moved on to the next DB.

Homepage took a very long time to migrate as there was a LOT of data here, the other DBs I had issues with were Files, Wikis and Blogs which are the ones that IBM expect to cause issues. I will use Blogs as an example on how to troubleshoot later.

I also had some DBs that were already using DB2 like IBM Docs, Surveys app for Communities and ProjectExec – we backed these up also and migrated them across to the server in the sameway that we would do a normal DB migration – Droped, restored and checked the DB roles and permission. These all came across with no issues.

 

Troubleshooting

It goes without saying that you should ALWAYS RUN THIS ON A TEST / DEV SERVER FIRST!

If i could have this as scrolling flashing marquee text with it playing a siren I would. I CAN NOT emphasise enough how important it is that you should run this in a test environment – which we did 3 times before actually doing it for real.

The most troubleshooting I did on this project revolved around the dbt transfer script (see example below).

The database schemas are quite different between types and even between OS versions so there will be a lot of tinkering to resolve the problems. Typically its where one DB type expects a NULL and the other expects a NOTNULL

Firstly run the script

java -cp D:\IBM\Connections\ConfigEngine\lib\DBT_HOME\dbt.jar;D:\IBM\Oracle\ojdbc6.jar;D:\IBM\SQLLIB\java\db2jcc.jar com.ibm.wps.config.db.transfer.CmdLineTransfer -logDir D:\IBM\Connections\ConfigEngine\lib\DBT_HOME\logs -xmlfile D:\IBM\Connections\ConfigEngine\lib\DBT_HOME\files\activities.xml -sourcepassword sourcepassword -targetpassword targetpassword

If there are problems it will be shown in the console and written out to a log file.

for example you may see an error like this:

[07/20/16 13:22:56.756 PDT] com.ibm.db2.jcc.am.SqlIntegrityConstraintViolationException: Error for batch element #50: DB2 SQL Error: SQLCODE=-407, SQLSTATE=23502, SQLERRMC=TBSPACEID=3, TABLEID=5, COLNO=1, DRIVER=3.65.110

All of these issues I saw related to the NULL / NOTNULL issue.

The next step is to make a note of the tablespace id, table id and column number as we need those for an sql query.

Fire up your DB client and run the following query

 

SELECT C.TABSCHEMA, C.TABNAME, C.COLNAME
 FROM SYSCAT.TABLES AS T, SYSCAT.COLUMNS AS C
 WHERE T.TBSPACEID = 3 AND T.TABLEID = 5 AND C.COLNO = 1 AND C.TABSCHEMA = T.TABSCHEMA AND C.TABNAME = T.TABNAME

Use the TBSPACEID, TABLEID & COLNO from the error message

The query will report back the DBName (as the TABSCHEMA), the table name (as TABNAME) and the column name (as COLNAME)

 TABSCHEMA     TABNAME             COLNAME
 ---------     ---------------     --------
 BLOGS        ROLLERLOGINNAME        USERNAME

Now you have the name of table and column with the null/not null issue.

The next step is to edit the createDB.sql script to make the change in the example here remove the not null from the username field as below.

create table BLOGS.rollerloginname (
    userid             varchar(48) not null,
    username           varchar(255),
    ORG_ID             varchar(36) not null
) IN BLOGSREGTABSPACE@

 

Once that change has been made the process needs to start again…

 

  • Drop database, create database, app grants (for homepage also initdata, and re org and run stats)
  • CR update scripts
  • Pre DB fixer script
  • Run the DBT command

Rinse and repeat until the DB transfers all the tables over correctly. This part of the process took the longest. Working out which tables to remove the not nulls from was SO time consuming. I kept a record of all the tables / columns I changed for my records more than anything else, at least the Post DB fixer script puts things back to the way it should be – and if you do hit issues with that you can manually fix them as you have a record.

 

ALTER TABLE BLOGS.ROLLERLOGINNAME ALTER COLUMN USERNAME SET NOT NULL;

 

So hurrah .. after all of that mucking about we have the Connections 5 data from Oracle on AIX in to DB2 on Windows – now what?

Well I backed it ALL up, including the existing V5 DB2 databases Docs, FEB and Projexec and migrated it to Version 5.5.

On the whole this part of the process wasn’t too bad and it was a good test for a real live migration ..

 

Migrating to Live

The whole migrating to live took about 21 hours in total – including waiting time for the DBs to transfer and the steps were are follows

On the Live5 machines

  • Stop Connections
  • Backup the File system
  • Back up the DB2 databases that need migrating (FEB, Docs, Projexec)

On the Dev5 DB machine (that I had been using for testing)

  • Drop database, create database, app grants (for homepage also initdata, and re org and run stats)
  • CR update scripts
  • Pre DB fixer script
  • Run the DBT command
  • Application specific scripts (IBM provided addional fixup scripts for Blogs, Files and Wikis for me)
  • Post DB fixer script
  • Re org script
  • Run stats script
  • Restore the backed up Live DB2 databases (FEB, Docs, Projexec)
  • Backup the DBs – so we now have a FULL set of V5 DB2 data
  • Copy backups to LIVE 55 DB2 machine

On the Live5.5 machines

 

  • Stop Connections
  • Drop the DB2 databases
  • Restore the V5 DB2 databases
  • Set numb dbs to at least 25
  • Run the upgrade scripts to update them to V5.5 – ran these manually not using the GUI as the amount of data caused issues
  • Run the CR updates
  • Run the Docs DB2 Fixes
  • Run the FEB DB fixer from the FEB admin GUI
  • Started Connections
  • Cleared the scheduled tasks
  • Post migration steps
  • Restarted Connections

And we were live 🙂

This took WAY longer than it should have done because of all the issues we had with the DBT to begin with .. but hopefully info in these posts will hope anyone who needs to do this pre PINK.

This was a LONG journey – but we all learned a lot in the process of doing this .. the main lesson learnt was don’t attempt this unless you HAVE to 🙂

If you missed the other 2 parts of this series you can find them here:

 

 

IBM Cloud migration and management Webinar

I have the pleasure of giving another webinar on Wednesday at 4pm UK / 11 am EST – with my friend and IBMer Luis Guirigay

We will be talking about migrating to the cloud and user management once you are there ….

Join this webinar to learn more. Register here.

[blockquote align=center]

Are you interested in running some or all of your messaging platform in the Cloud? Interested in IBM Verse? Worried about how to manage the user-lifecycle in a hybrid or cloud environment? Not sure about how or where to start?

If you ever had any of these questions join IBM’s Luis Guirigay and BCC’s Sharon James for a quick but thorough review of how to deploy a SmartCloud Notes infrastructure, how to start your user migration project in no time and how to manage a hybrid or cloud environment with ease using BCC’s AdminTool for Connections Cloud.

AdminTool for Connections cloud offers centralized user management and administration, customizable user interface, security and logging features whether on-premises, hybrid or cloud only

[/blockquote]

 

Want to go to IBM Connect .. be nice to a Champion for a discount

Being an IBM Champion is great and it does come with some benefits.

Today all IBM Champions are happy to announce that we can offer YOU a discount of $100 for IBM’s upcoming ICS event – IBM Connect in San Francisco

So what do you need to do – just reach out to an IBM Champion tell us why you want to go to Connect and what your expectations are and as if by magic we will give you the dscont code.

Now is a great time to register .. and I wish I was going to be there with you all (but I will be in Orlando – on a very long awaited family holiday) – so ping a champ and get the code 🙂

6 years a Champion !!

I recieved an email yesterday – just before I joined a live stream to watch the IBM Champions for ICS be announced.

[blockquote align=center]

On behalf of IBM, it is my great pleasure to recognize you as a returning IBM Champion in 2017. Congratulations!

[/blockquote]

 

 

 

 

I am so honoured to be amongst a great group of champions again. I have been an ICS IBM Champion since the program began in 2011.

Being an IBM Champion is all about being part of a great extended  community, sharing knowledge, giving feed back and constructive critism and helping IBM with what ever they will let us help them with – from documentation to ideas about Connect.

In my 6 years of being an IBM Champion .. I have made some great friends and been introduced to some great IBMers (who I now class as great friends), helped influence some products, given a lot of honest feed back, and assited with my favourite thing – Documentation 🙂 It really has been a blast .. and I would still continue to do these things If I wasn’t a Champion 🙂

Being an IBM Champion doesn’t mean you have to be a *yes man/woman* – It just means you are passionate about what you do and have the right attitude – that doesn’t mean agreeing to everything, being constructive, giving feed back and ideas is part of being a champion which is why I love it.

 

So thank you once again IBM and especially to Amanda and Libby for everything they do for us Champions .. and I hope to be worthy of this title for the next year 🙂

 

So Docs 2 CR1 and iFix 1 is not playing ball

I knew that some of our community had seen issues with applying Docs 2 CR1 and the accompanying iFix, so I purposely held off applying it.

But low and behold on Saturday afternoon when I did attempted to install CR1 I had problems.

The Docs and Viewer applications deployed without issues, but the Conversion server had these errors:

WASX7303I: The following options are passed to the scripting environment and are available as arguments that are stored in the argv variable: "[remote_install_a_version, connections.hostname.com, [u\'connections.hostname.com\'], 8]"

WASX7017E: Exception received while running file "../execwas.py"; exception information: com.ibm.websphere.management.exception.AdminException: CWWSY0102E: Target with name connections.hostname.com was not found.

My friend and co-speaker Roberto Boccadoro had had this exact issue .. so off I went to his blog and round this post: IBM Connections Docs 2.0 CR1 fix does not install.

Excellent .. Followed the instructions but that didn’t resolve it – exactly the same issue. I checked the machine name, its host entry and FQDN and they were all correct – stumpted I asked in the Connections skype chat as I know other people had seen similar issues.

Monday morning .. I started getting some answers ….

Another quality participant Robert Farstad had seen issues with the Conversion application installing the iFix 1 for CR1 so I checked out his blog post here: Docs 2.0 CR1 iFix 001 – Conversion app will not update. Where there is an issue with the conversion-config.json in the Dmgr config not having the iFix attribute in the build section
i.e

 "ifix_version": 6,

I added this at version 1 for my test as I hadn’t applied any fixes at this point.

Tried to run the update again and you guessed it – failed again with the same issue as previously.

Roberto went back through his notes and found another post he had made on another Docs install he had issues applying the fix on ..IBM Connections Docs CR1 installation may fail with an error on Conversion server. This issue was exactly the same problem as I had the resolution is actually very simple

  1. Edit the applypatch.py in the Docs CR1 install directory
    Comment out the 2 lines in red from the def update_apps() section of the file

    def update_apps():
    
     “””update apps in present work directory”””
    
     for filename in os.listdir(‘./’):
    
     if(filename.endswith(“.ear”) or filename.endswith(“.ear.zip”)):
    
     appname = get_app_name(filename)
    
     CONFIG.call_was_task(‘update_app’,[appname, filename])
    
     #if os.path.exists(“docs_remote_installer.zip”):
    
     #update_conversion_binary()
  2. Under Docs CR1 install directory, go into the DocsApp subdirectory and rename the file concord-config.json to concord-config.json.OLD or something similar
  3. Re run the apply update script – it should work this time AND update the ifix version number in the config file to 6.
  4. Stop the Conversion cluster
  5. Under Docs CR1 install directory open the DocsConversion subdirectory. Unzip the docs_remote_installer.zip to a directory (in my case this was E:\Install\Docs\IBMConnectionsDocs_2.0_CR1\DocsConversion\docs_remote_installer)
  6. Check the [SYM_COUNT] which is the number of instances of symphony that are configured, typically this is between 4 and 8. Check the <Conversion_Install_Root>\symphony directory (in my case E:\IBM\ConnectionsDocs\Conversion\symphony)
  7. From the docs_remote_installer directory () run the command
    upgrade_node.bat --installroot <CONVERSION_INSTALL_ROOT> --symcount <SYM_COUNT>
    
    i.e
    
    upgrade_node.bat --installroot E:\IBM\ConnectionsDocs\Conversion --symcount 8
  8. Check fixpack.log in directory <CONVERSION_INSTALL_ROOT>\logs\
  9. Restart the Conversion cluster

Now all is good with my Docs update .. its working perfectly with Connections.

Thanks again to Roberto and Robert for helping me find the right solution.