The presentation I gave at MWLug 2014 in Grand Rapids on IBM Connections / WebSphere security and on Connections migrations

1. IBM Connections Migration - Review your WebSphere security and
then use all these great tricks for your successful Connections
Migration
Learn about your Known Unknowns and your Unknown Unknowns
and where to look for them

2. Security and Connections
IBM Connections is made up of individual components that all have separate security
concerns and (potential) vulnerabilities.
No system will be 100% secure. If Your Connections environment were your home,
what you would look for is:
1. Every door of your house has a lock and a deadbolt and every window can be
shut closed
2. You would not leave a key under the front mat or in the flower pot next to the
door.
3. No Notes sticking the front door detailing which flowerpot to look under for the
key
4. You would have a security light or two and maybe a warning sign of the
dangerous attack Chihuahua dog that lives in your house . . .
That is what we will be concentrating on on this exercise - common sense
security

3. Administration
Real Administration - Means Having a Strategy and a Plan
1. Having an administration scheme just for Connections will not work
2. However you administer the rest of your IT environment - that is how you should be administering IBM
Connections - don’t make it stick out like a sore thumb
3. If you do not have a real strategy and a plan … your have deeper problems than just IBM Connections
4. Look at opportunity and try to make as many common sense improvements as you can, but not so
many that everybody is forced to change 100% of how they are fulfilling their job function.
5. Administration requires two things: Trust & Verification
6. Bring in somebody to take a closer look and be a sounding board - YOU ARE NOT ALONE - it is like
one big AAA meeting out there at times.
Dr. Vic’s Admin Test:
If the main administrator(s) all won the lottery and are not willing to share the bounty with their colleagues or
buy your company outright - do you have any documentation on how to replace their function(s)?
???

4. Administration
Real Administration - Can You Answer This Question?
Dr. Vic’s Admin Test:
• If the main administrator(s) all won the lottery and are not willing to share the bounty with their
colleagues or buy your company outright - do you have any documentation on how to replace their
function(s)?
???
• If you have plan/ documentation and you are the one who has that lottery ticket - do the others on your
team know of the plan and where to find it?
???
• Is this infamous plan every updated and reviewed?
???

5. Security - Accounts - Admins
Some Common Sense Questions to Ponder Over:
1. Do you allow anybody to log into a server?
2. Do you allow Anybody to connect to a NAS? Unlikely
3. Does Everybody in your organization need the exact same access to ALL resources?
4. Does everyone in your support organization have the same skillset and experience
5. Does your organization have a system to keep and manage administrative accounts and
passwords?
6. How many accounts does the average admin have to keep track of and … are they actually
different or are they all the same password …. ?
7. If your company has password rules for “normal users” - do those rules apply to
administrative accounts as well? Cn most of your admin accounts actually be administered
by a system?

6. Security - Accounts - Admins # 2
More Common Sense Questions to Ponder Over:
1. Do you really want to use the same system/generic account for each function?
2. Do you really need the “One Admin Account to Rule Them All”?
3. Do you have so many admins that creating individual admin accounts for them is a great
administrative overhead?
4. When assigning rights, are you thinking of “person” or of “job function”?
5. Do you have more than one “person” or “admin type” for each function so you have
continuity?
6. Is your brilliant administration scheme actually documented someplace?
7. If you use hierarchical directories (LDAP …, it’s hierarchical) are you taking advantage of it?

7. The bits and Pieces of IBM Connections
These are the individual moving parts that make up your IBM Connections environment:
Possible Additions:
● Cognos
● IBM Docs / Doc Viewer
● IBM Forms
● Third Party Products
● Shared File Space (NAS/NFS,
etc.)
● ICMail
Main Components:
● Servers (the OS)
● WebSphere
● DB system (our example DB2)
● LDAP (our example Domino)
● IHS
● TDI

8. Let’s Go WebSphere!
- Granular Admin Rules Totally Rule -
Granular Administration Rights Are The Key
● Not everybody needs to log into the WebSphere console
● Not everybody logged into the WebSphere console needs full security admin rights
● Not everybody needs to be able to stop, start a server/service
● Not Everybody should have the right to configure security on a system
● The only way to ensure your brilliant admin scheme works is to monitor - even a little bit of
monitoring is better than no monitoring at all ….. as long as you can access the events and
you can search back further than 1 day . . . . (WAS logfile settings)

9. WebSphere - The OS Makes the Difference
The Big Divide - Windows vs Unix/Linux
Windows:
1. Run as a service - Yes/No
2. Remote Desktop access
3. File Sharing
4. AD Forests and Trees and … Policies?
5. Local Accounts vs Domain accounts for
install and access
6. File ownership not much of an issue in
95% of all environments
Unix/Linux:
1. Run as a service and under which
account?
2. Remote Desktop access/ssh/xwindows?
3. File ownership can be a BIG issue
4. Is the OS taking advantage of a corporate-wide
Directory infrastructure?
5. How many local admin accounts are there
and who controls them?

10. WebSphere - What is it in Lay Terms?
WebSphere is both a brand and a technology. The WebSphere brand covers a whole host of
technologies that come together to create business solutions. For example, IBM Connections is a
business solution -- underneath the covers it uses WebSphere Application Server (WAS), which is
a runtime environment that Connections runs on.
WAS provides a bunch of services (called J2EE) that Java applications use. Services like
database access, mail services and security services. Without an application WAS does nothing –
it has an administration interface but, unlike Domino you can't "do" anything with out of the box
without an application. Simply put, WebSphere runs Java (J2EE) programs.

11. WebSphere
More on WebSphere …
● WebSphere is a shell, it allows your J2EE applications (=Java) to run in it and simply provides the
support structure and access to outside resources (Memory/CPU, dB access, i/o resources, directories
…)
● For some resources WebSphere holds the authentication information and acts as gatekeeper -
generally these are security related functions (i.e.: LDAP, SSO, etc.)
● Other resources do not require special security authentication, WebSphere provides access without
any internal security being required (i.e.: disk access, network access, memory, CPU). The security for
this is provided by outside/OS level implementation
➔ Think of running a programs on Windows as a service OR under a specific account. In Linux we
would be talking about process ownership.

12. Administration
WebSphere Admin Accounts
Another one of Dr. Vic’s Rule:
1. Create individual admin accounts for all users that need to work on the WebSphere server
2. Don't use the wasadmin account for your daily work. Keep it locked away
3. Don’t assign all admins the same rights.
Dr. Vic’s Test Question:
What is the minimum level of administration necessary to run a wsadmin script on a WebSphere server?
???

13. WebSphere - Look inside that Security Account Crackerjack Box
● Local/file based default WebSphere admin: “wasadmin”
● Additionally created local WebSphere admin accounts
● Directory (=LDAP) based admin accounts (*** look at security settings)
● LDAP bind accounts
● Connections related J2C Security accounts
● Administrative Group settings
All of them exist on one little old file …….
security.xml
Location:
/opt/IBM/WebSphere/Appserver/profiles/Dmgr/config/***
xxx:IBMWebSphereAppServerprofilesDmgrconfigcell
This file also exists on EVERY managed node in the same folder structure in that node’s
profile

14. Security.xml … what was that password again?
Look at this URL …
http://www.poweredbywebsphere.com/decoder.html
Courtesy Andrew Jones - WebSphere Infrastructure Specialist and Architect

15. WebSphere - Admin rights
Here some common sense rules:
● Don’t use local accounts, assign LDAP accounts the rights you need. Local Accounts will
have their passwords in encoded format in the security.xml file …..
● Use Separate admin accounts from your user accounts (or you will get funky results in
Connections)
● Assign rights by group membership … if you can control the membership in groups and can
audit them … must I explain the hell that is nested groups?
● Use LDAP … you can have more than one Federated Repository so you can have a
separate directory jusrt for system and admin accounts - kept separate from the user
accounts and all those helpdesk guys who help administering them . . . . .

16. Cognos - The Potential Problem
One major potential issue - the cognos-setup.properties file …..
When you set up Cognos, the setup properties file contains username and password info for the
Cognos admin and the user account to access the Metrics and Cognos databases. You can either
set the file to remove the password every time you run it or to tell the system to keep the password
so you don’t have to update the file every time you run a command.
Your questions should be:
● Did you set the entry [removePassword=] to [true] or to [false]?
● If you set it to [true] ….. did you go back and remove the passwords .. and maybe the
account names?
Tip: If you just enter the account names but not the passwords you will be prompted for the
passwords in the script at the command line …..

17. Other Add-ons
1. ICMail
2. IBM Doc Viewer
3. IBM Forms
4. IBM Docs
5. Third Party Products
6. DB2????
7. TDI
8. IHS - is there any danger?

18. Connections Mail
1. The [socialmail-discovery-config.xml] might be your open achilles heel
2. Look at your setup, some of them require an LDAP user account and password ….
<ServerConfig name="domino-config">
<ConfigType>DOMINO</ConfigType>
<DirectoryServer>domino.example.com</DirectoryServer>
<DirectoryUser>username</DirectoryUser>
<DirectoryPW>adminpw</DirectoryPW>
<MailPattern type="example.com" />
<MailPattern type="example2.com" />
</ServerConfig>
<ServerConfig name="exampleexchangeconfig">
<ConfigType>EXCHANGE</ConfigType>
<DirectoryServer>exchange.example.com</DirectoryServer>
<DirectoryUser>username</DirectoryUser>
<DirectoryPW>adminExpw</DirectoryPW>
<DirectoryServerDomain>exchange.example.com</DirectoryServerDomain>
<CertificateFile>c:exampleexchangecertificate</CertificateFile>
<CertificateFilePW>exampleCellManager01/certificateFileAuth</CertificateFilePW>
<MailPattern type="example.com"/>
<MailPattern type="example2.com"/>
</ServerConfig>
What can you do?
Create a J2C authentication alias and use that for your username and password. BUT - that
means that username and password will still be in the …(drumroll) security.xml file
SO, USE AN APPROPRIATE ACCOUNT with as few system rights as possible.

19. IBM File Viewer
The only real danger are (drumroll again) …
The setup files : [cfg.properties]
They contain dB access information (usernames). Clean them up, delete them, kill them
...whatever it is you want to do. After the install they are no longer needed (unless you want to
uninstall).
The same goes for IBM Docs and IBM Forms
If you clean up the config/installation files you have taken care of 90% of the potential issues

20. Third Party Products
Some of the more well know products: Domain Patrol Social, CAT, Kudos, Bunchball, ProjExec,
EditLive, TemboSocial. . . .
Some products require an account to run/take action, sometimes this has to be an acoutn with
admin rights
Dr. Vic’s Rule of Thumb (A):
If the Tool needs an admin account .. give it it’s own dedicated account. That way you can trace
actions taken by that account and separate them from your main Connections admin account’s
actions.
Dr. Vic’s Rule of Thumb (B):
Ask the questions: Who has access (person or function)? Do they need access? Do they all need
the same level of access? …
AND - Is the access level documented?

21. DB2 - Any Potential?
1. If your DB access accounts are compromised (default name LCUSER . . . .) then your DB2
server is potentially compromised …. you can change your security to not allow remote OS
access to OS accounts, disallow them from logging on interactively, have alerts tell you
when they are doing ANYTHING other than accessing the DB2 server ….
2. Don’t use the DB2 instance owner account for access …. leaves to many open avenues for
abuse.
3. Back-ups - are they secured? Do you make dB exports at anytime? Where do they go, who
has access and how long are they retained?

22. IHS - Any Danger there?
1. Keep them patched and up-to-date, your IHS is probably the least likely part of your
environment to be compromised … as long as it is only facing towards the inside of your
firewall.
2. Monitor, monitor and then monitor again.
3. If you have set you your IHS to have direct access to FILES for direct download … then you
have a potential open access to the shared file space.
4. This can present different problems depending on your OS.

23. TDI - The double-Edged Sword?
1. TDI can either pull all updates into Connections Profiles or … it can also push changes back
up into the LDAP source(s).
2. Are you using a dedicated LDAP bind account … and does this account have rights to write
as well?
3. Is it the same account as you are using inside of WebSphere?
4. TDI uses the LCUSER account to connect to Profiles .. in theory it could wipe out ALL your
Profiles entries …..
5. If TDI uses the LCUSER account … it can also connect to ALL OTHER DATABASES
6. Do you have just one TDI setup for multiple Connections environments?
Some Ideas …
● Multiple DB2 access accounts that only can connect to specific databases
● Maybe a different LDAP bind account for TDI?
● Monitor … keep those TDI logs so you can review them at some time.

24. Connections Migrations
You Have Choices And Challenges - Depending on Which Version You Are Coming From
MWLUG 2014

25. What Are the Two Most important Considerations?
If it’s real estate - location, location, location …
(but we don’t care about real estate right now)
So we think of
IBM Connections Version, Version, Version . . . .
&
Parallel or In-Place Migration

26. What needs to be migrated?
1. Your DB source
2. Shared Files (uploads, WIKIS, FILES, ACTIVITES, etc….)
3. Connections Settings (Connections XML files, proxy configurations, etc.)
4. Notification Settings/Strings (the emails your system sends out)
5. Media Gallery settings
6. Customizations (no matter how ugly …)
7. IHS Settings
8. WebSphere Security / Admin structure
9. Third Party Software Products / Media players
10. COGNOS … (Again - I pitty you …)
11. CCM (depending on originating version)
What do you NOT migrate:
Search indexes
Local Data Stores (are recreated upon install)

27. You Need a Plan
Sample Plan - Three phases:
Phase 1.
New System - WebSphere install
●Install WebSphere 8.0.0.8 on DM / Managed Node
●Install WebSphere 7.0.025 on IBM Docs server
●Create dB for Connections (new dB)
●TDI INstall - configuration - populate Profiles
●Install IBM HTTP Server
●Install IBM Connections: include CCM/Filenet
●Base configure of Connections
●Configure IHS, CCM, Cognos
●Install 3rd Party Products
Phase 2.
●Adjust configuration to match
existing Connections settings (export/Import)
●Apply any customizations
●Mail/notifications settings
●ICMail install and configuration
Phase 3.
Test migration:
Note: A “real” project plan
has WAAAY more details!
●DATA CLEAN-UP on originating system
●Make copy of existing DB2 dB to new DB2 server
●Make copy of content stores from old environment to
new server
●Make backup of existing (new) V4.5 DB2 databases
●Put old DB2 (V4.x) onto new DB2 server and do test
migration / upgrade to V4.5 schema
●Start new servers and test/verify that data migrated
clean
Migration:
●Shut down V4.0 enviroment
●Shut down V4.5 environment
●re-copy DB2 dB to new server
●Copy delta of new files from V3.x to new server
●Reconfigure V4.5 to use the original url
●Change DNS to point to new server
●Migrate DB2 data
●Start new server
●Test/verify

28. Your first and most important decision is HOW you intend to migrate
Parallel or In-Place
Parallel Migration
Pros:
● No time limit that forces you into a specific schedule
● Gives you opportunity to test and verify freely
● Makes it possible to do test runs for the migration
● Gives you a test bed to verify all the settings and configuration
● Leaves you a working system to fall back onto
Cons:
● Doubles your HW and disk requirements for the duration

29. In-Place Migration
Pros:
● No additional HW required
Cons:
● Everything else!
● Requires an uninstall of Connections, upgrade of WebSphere and IHS then re-install
Connections
● Connections unavailable during the whole process - from deinstall to build to test
● Might require an upgrade of the DB2 version
● No easy fall-back should the migration not be successful
● No good way to test the outcome ahead of time - scheduling is difficult
● Might require OS upgrade (depending on OS)
!YWTATOAAC!
(You Want To Avoid This Option At All Costs!)

30. Versions and Migration Scenarios - The Ugly Ones
Originating
Version
Target
Version
Steps
Cnx V3.0.1 Cnx V4.0.x ● Single step - use the V4 wizards to migrate directly.
● If you are not V3.0.1 -> upgrade first
Cnx V4.5.x ● Two migration steps - Migrate DB from V3.1->V4 and then to V4.5.
● You need to first use the V4.0 wizard, then the V4.5 wizard.
● There will be some missing databases that are new to V4 & V4.5 that
you will need to create separately … (more below)
*** In short .. I pity you ***
Cnx V5.x ● Basically the same as V3->V4.5, just that the V5 wizards are capable
of migrating you from V4.0 directly to V5 without having to
migrate/upgrade to V4.5 first.
*** Again, I pity you ***

31. Versions and Migration Scenarios - The Less Troublesome
Originating
Version
Target
Version
Steps
Cnx V4.0.x Cnx V4.5.x ● Single step - use the V4.5 wizards to migrate directly
● Cnx 4.0 needs to be at least CR2 for the Content stores to be
formatted correctly for an upgrade
Cnx V5.x ● Single step - use the V5 wizards to migrate directly
Cnx V4.5 Cnx V5.x ● Single step - use the V5 wizards to migrate directly

32. Your Database Migration
The most important and probably most difficult part of any Connections migration is the database.
It takes the longest, needs the most babysitting and has the most potential pitfalls.
The Connections Database Wizard supplied with each version of IBM Connections is in charge of
the migration steps. You need to use the wizard of the version you are MIGRATING TO or it will
not work.
Depending on the version you are migrating from and the version you are migrating to you could
have several steps to deal with, let’s take a look:

33. DB2 Migration - Continued:
Originating
Version
Target
Version
Steps
Cnx V3.0.1 Cnx V4.0.x ● Single step - use the V4 wizards to migrate directly.
● If you are not V3.0.1 -> upgrade first
Cnx V4.5.x ● Two migration steps - Migrate DB from V3.1->V4 and then to V4.5.
● You need to first use the V4.0 wizard, then the V4.5 wizard.
● There will be some missing databases that are new to V4 & V4.5 that
you will need to create separately … (more below)
*** In short .. I pity you ***
Cnx V5.x ● Basically the same as V3->V4.5, just that the V5 wizards are capable
of migrating you from V4.0 directly to V5 without having to
migrate/upgrade to V4.5 first.
*** Again, I pity you ***

34. PREPARATION
It’s what for dinner ……. and breakfast, lunch … snacks … seconds …
What this means is - you will have no rest unless you prepare the data first
MWLUG 2014
(note: Gandalf will not help you …..)

35. Data Preparation
If you have already migrated the databases once (or twice?) previously … you will likely have some garbage
in the databases you need to review.
What to do?
CLEAN UP
(just like Momma taught you …)
Even if you have NEVER migrated before .. there can be allot of chaff in the databases and a clean-up &
review of your data is in order prior to doing ANYTHING

36. Data Preparation … Clean-up
Run a user sync - that usually shows up any problems between entries in PROFILES and the other
applications. Your most important one is likely NEWS/HOMEPAGE - both applications use the same
database and it is also the first database to be migrated. HOMEPAGE which is pretty much your most
important database from an end-user's perspective.
Sync command Examples:
First Run the syncAllMembersExtIds commands
wsadmin.sh/.bat -lang jython -user wasadmin -password **** -profile newsAdmin.py -c
"NewsMemberService.syncAllMemberExtIds()"
Followed by the syncAllMembersByExtId with update triggers:
./wsadmin.sh -lang jython -user wasadmin -password **** -profile newsAdmin.py -c
"NewsMemberService.syncAllMembersByExtId({'updateOnEmailLoginMatch':'true'})"
Review the log files, they will tell you allot about your issues - or the lack thereof

37. Data Preparation … Clean-up
If you find errors ….. What do you do now?
Look at the accounts creating errors -
• LDAP accounts - Look at whether they might be different, corrupted or … not there anymore
• Use a dB tool to open the Connections databases and look at the actual datasets ….
• OPEN A PMR WITH IBM - you pay for support so you should use it
• Often what you have is just a set of data that are missing some other related data (dB constraints) and
because they are incomplete you are running into issues.
My side story . . . . :
I once found a client that had several thousand dormant profiles … all with their last update date set to the
same day ...which happened to be the day the previous system was migrated from V3.01 to V4.0 …..
The Voice of EXPERIENCE tells you:
• Just about all problems can be solved with some sql statements, but you will want to have IBM’s input
on this since
• Consider doing all this on a copy of your data … the last thing you need is to corrupt your running
system ….

38. The Database Wizard
The Database Wizard
Has two main functions
1. Creation / Deletion of Connections Databases on the DB server
2. Migration/Upgrade of databases of previous releases to the corresponding release of the Wizard
All sql scripts necessary are actually contained in a subfolder of the unpacked Wizard tself. The Wizard is
just a visual front-end that lets you choose the parameters, build the DB2 (or SQL/Oracle) scripts and then
executes them.
EXAMPLE ….
Let’s look at the real thing!

39. Database Wizard and Migration
The Voice of Experience …. Some things to take into consideration
DB2:
You want to execute the Wizard / SQL scripts using the same account that created the databases in the
first place. A DB2 database has allot of individual items and they all belong to some dentity. Sometimes an
account added later with admin rights will not have all the rights necessary to update individual database
features … maybe it is just a single field but that can be VERY painful.
If your databases are large (anything over 15 GB is large) you might want consider not using the Wizard, but
running the scripts manually so that the wizard does not time out on you. DB2 scripts from the commandline
will not time out - they will run to completion
The Wizard will actually create all the scripts for you, in the correct formatting and in the order they need to
be run in … all bundled up in one nice old document
NOTE: if you run scripts manually, make sure you add a command to create log files, you HAVE TO
REVIEW THEM to be sure everything went well . . . .

40. DB Migration - Manually
Example for manual scripts:
Activities
/opt/ibm/db2/V10.1/bin/db2 -td@ -vf connections.sql/activities/db2/upgrade-40-45.sql
/opt/ibm/db2/V10.1/bin/db2 -td@ -vf connections.sql/activities/db2/appGrants.sql
/opt/ibm/db2/V10.1/bin/db2 -td@ -vf connections.sql/activities/db2/clearScheduler.sql
Blogs
/opt/ibm/db2/V10.1/bin/db2 -td@ -vf connections.sql/blogs/db2/upgrade-40-45.sql
/opt/ibm/db2/V10.1/bin/db2 -td@ -vf connections.sql/blogs/db2/appGrants.sql
Bookmarks
/opt/ibm/db2/V10.1/bin/db2 -td@ -vf connections.sql/dogear/db2/upgrade-40-45.sql
/opt/ibm/db2/V10.1/bin/db2 -td@ -vf connections.sql/dogear/db2/appGrants.sql
There is much more, (EXAMPLE ON SCREEN)
A Trick from the wise . . . . . . .
Look at the log files (they will be HUGE/LONG) you can’t read it all … just search for the work “Error” … if
that word does not exist you are golden . . . . .

41. Let’s Migrate some Configurations
“To automate, or not to automate … that is the question”
MWLUG 2014

42. Migrate Settings From Old to New
Starting with V4, IBM Connections comes with migration tool that exports “application artifacts” from the
originating system. You can then use the same tool on the new system to import those “application artifacts”.
“What are “Application Artifacts”?
All (or actually – most) of your configuration files from the WebSphere Deployment Manager’s
LotusConnections-config folder (and the sub-folders.)
I !SO! hope you did not do
What does NOT get migrated?
• Customizations (=anything in the customizations shared folder)
• Any changes you did INSIDE of applications (ear files)
• Notification settings / strings 9= the wording in the mails that get sent out)
• Profile lay-out settings and customized fields
any of those ….

43. Profiles
A quick word on Profiles Design
Most environments have done some changes to the default profiles setup and lay-out, everything has
changed, but some things are the same.
Any changes you made via TDI – mapping specific LDAP elements to specific Profiles fields – those all
come over, if you reconfigure your TDI correctly
What has changed that you need to look at:
• If migrating to V5 … EVERYTHING has changed, basically you get to do it all over in a new system . .
But I find the new way easier to deal with and to accomplish.
• If migrating from V4 -> V4.5 you are in luck, it is almost the same
• If migrating from V3 .. Well, you get to do it al over again anyway
• Read this in the V5 Wiki: Customizing Profiles

44. Migrate Settings From Old to New
How do I do this?
*** MAKE A BACKUP FIRST … I BEG OF YOU! ***
I generally do a WebSphere Backupconfg.bat/.sh
Go to your [Connections InstallRootmigration] folder, the command is:
[migration..sh/bat lc-export]
This exports (almost) all the files you need to the [Connections InstallRootmigrationwork] folder. This
process creates a log file -> CHECK IT!!! . You can find it in your OS account’s [HOME FLDER]. Take a
copy of the [work] folder and put it in the same location on the target system, then run
[migration..sh/bat lc-import -DDMUserid=wasadmin -DDMPassword=*******]

45. In reality you really
want that opportunity to
review all settings.
AND .. There are a few
new ones you don’t
know of.
Migrate Settings From Old to New
OK, the previous two slides are from the Connections WIKI, now comes something from Dr. Vic’s vast
experience – this is why I have scar tissue:
Don’t Do It
80% of the time it works OK.
20% of the time it screws up your environment.
Those screw-ups are really painful
My most recent case … the update totally mashed my events-config.xml file (there were settings in there
nobody has seen before). This can especially happen if you are dealing with an environment that was
migrated previously using the same tool.
I don’t blame IBM … 80% is a real good ratio! But they just can’t test ALL scenarios and there is no
accounting for human .. ahem … inventiveness
Life all those changes by hand .. Go config file by config file. That also gives you the opportunity to review
the settings and make a determination of they are valid or not.

46. Them Files – They have to Go Somewhere
The “Other White Meat” or How to Migrate The Need To go
MWLUG 2014

47. Share File Space
The “Other White Meat” refers to the share file space .. Also known as your shared data.
In essence this is simply a copy-and-paste operation. You want to move the shared file structure exactly AS
IS from the originating server to the new server
Alternatively – if you have that file shared someplace – you could just re-mount that folder to the new server
…but I am not a friend of this option.
Why? Hhmm …. “What if ..”
• Your migration somehow fails and now you have to recover
• During your failed migration the serves “did something” to your files and now .. You get to go back to a
back-up .. Which is hopefully recent.

48. Files – More White Meat
How Do You Know It Worked?
•Simple .. Look for your files and make sure you can download them.
•Check if the HIS server – which you hopefully have mapped to do file downloads from the file share directly
– actually gives you files. If something is off, the files you download will all have a 0 byte size …
•Also .. If something is off all those images you use to decorate your wine tasting communities and the cat
videos you have secretly been hoarding in your private community will not show ….
Missing Cat Videos – A
Dead Givaway!
You might also see errors in
the WebSphere sysemOut.log
files …..

49. Customizations – What to Look Out For
Don’t just throw your previous version onto the server ….
MWLUG 2014

50. Customizations
We can’t cover ALL customizations but we can touch on two REALLY important items that everybody deals
with:
header.jsp & footer.jsp
Just about EVERYBODY makes some changes to these files. Here is what to look out for:
• Header.jsp and footer.jsp are specific to each version AND CR of IBM Connections
• Much of the functionality of IBM Connections depends on having the correct header.jsp & footer.jsp with
the elements/code in them that Connections needs to run correctly
• Even when just doing a CR install, you should ALWAYS check the applications for changes and whether
the header or footer jsp files have changed . . . . .
• I HOPE that you have all changes documented . . . . .

51. Customiations
This is what I do:
• Step 1: Compare your customized jsp’s to the non-customized file on your existing Connections install
version. This will give you the changes you have in your system. You can now review them AND
DOCUMENT THEM
• Step 2: Compare the vanilla versions of the jsp’s between the originating and target IBM versions. This
will give you an idea of what is new and where there are changes. That way you can tell if you need to
slot your changes into a different place
• Step 3: Review any custom CSS files you might be referring to and check for potential issues (files,
locations, color changes …)
• Step 4:If you have many changes, port your changes over bits and pieces at a time. If you only have few
or a single change, implement it and DOCUMENT IT!

52. Media Gallery – What is New?
Just a few words on the Media Gallery …
• If you are migrating to V4.5 -> nothing special, just port over your custom player, and custom terms (if
you have any)
• Does not exist in V5 anymore, it is replaced with the Thumbnail Gallery
• You can use custom media players in V5 if you want – but my suggestion is to test it in a test
environment first, to make sure whatever version of product you are using is still working well in a new
Connections Version
Review this WIKI entry for V5 media gallery migrations – you basically back-up your applications and then
review them.

53. CCM – FileNet and the changes …..
MWLUG 2014
Don’t you just LOVE FileNet?

54. FileNet / CCM – The Steps Necessary
FileNet is one of the systems where the migration is not that hard .. You only really
have to do these steps for V5 . .
Here your Steps:
• Install FileNet – to the correct version your system needs with all FPs - as a NEW DEPLOYMENT
• When installing FileNet then point them to the dB of the V4.5 system (FNGCD & FNOS)
• Make sure you use THE SAME FileNetAdmin account – it makes your life easier
• You do not have to create a P8 domain, Global Configuration Data (GCD) or create an Object Store and
Add-Ons -> they all already exist in the V4.5 databases.
• Back-up your Existing/New install!!!!! - area [x:IBMConnectionsdatasharedccm] and save it!, also
back-up the x:IBMConnectionsaddonsccm] folder with all content
• Copy the FileNet storage to the new server in the folder [x:IBMConnectionsdatasharedccm]
• Migrate the encryption keys from your old system to the new -> the location is on the Deployment
manager: [x:IBMConnectionsaddonsccmContentEnginetoolsconfigureprofilesCCMear]

55. FileNet / CCM – The Steps Necessary
Continued . . . . .
• Run the following command in the [x:IBMConnectionsaddonsccmContentEnginelib]
java -jar BootstrapConfig.jar -e /temp1_device/Engine-ws.ear -j /temp2_device/Engine-ws.ear
• Go to the IBM WebSphere Console, Applications [FileNetEngine] and Update (replace entire application)
with the NEWLY CREATED .ear file [/temp2_device/Engine-ws.ear]
• Copy the file [x:IBMWebSphereAppServerprofilesDmgr01configcellsCELLNAMElfileRegistry.xml]
from the V4.5 to the V5 server in the same location -> MAKE A BACKUP OF THE FILE YOU ARE
REPLACING
• Sync the Nodes and restart the system

56. MWLUG 2014
Cognos ….
I Don’t Want To Talk About It …….

57. Cognos .. What to do
What is there to do?
• For a straight forward migration – Nothing, all the data necessary is contained in the Metrics database
• You do not need to migrate the Cognos Content Store (the database) – it does not give you anything
and makes your life difficult …
• When installing Connections on the new server, either already have migrated a copy of the Cognos
database over OR point Cognos to the dB on the V4/4.5 database server. -> I prefer to migrate ahead of
time.
• If you have customized reports .. There is a bit more to do
Sounds simple … don’t it?
The customized Reports are a bit of a pin, follow this in the WIKI …..

58. About me . . .
Victor Toal
aka “Dr. Vic”
victor@toalsys.com
Twitter: vtoal
Skype: vtoal