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 Unknownsand where to look for them

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 key4. 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

Administration

Real Administration - Means Having a Strategy and a Plan

1. Having an administration scheme just for Connections will not work2. 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 thumb3. 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 & Verification6. 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)?

???

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????

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? Unlikely3. 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 experience5. 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?

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?

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

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)

WebSphere - The OS Makes the Difference

The Big Divide - Windows vs Unix/Linux

Windows:1. Run as a service - Yes/No2. Remote Desktop access3. File Sharing4. AD Forests and Trees and … Policies?5. Local Accounts vs Domain accounts for

install and access6. 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 issue4. Is the OS taking advantage of a

corporate-wide Directory infrastructure?5. How many local admin accounts are there

and who controls them?

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.

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.

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 server2. Don't use the wasadmin account for your daily work. Keep it locked away3. 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?

???

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:\IBM\WebSphere\AppServer\profiles\Dmgr\config\cell

This file also exists on EVERY managed node in the same folder structure in that node’s profile

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

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 . . . . .

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 …..

Other Add-ons

1. ICMail2. IBM Doc Viewer3. IBM Forms4. IBM Docs5. Third Party Products6. DB2????7. TDI8. IHS - is there any danger?

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:\example\exchangecertificate</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.

IBM File ViewerThe 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 FormsIf you clean up the config/installation files you have taken care of 90% of the potential issues

Third Party ProductsSome 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?

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?

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.

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 DATABASES6. 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.

MWLUG 2014

Connections Migrations

You Have Choices And Challenges - Depending on Which Version You Are Coming From

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

What needs to be migrated?

1. Your DB source2. 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 settings6. Customizations (no matter how ugly …)7. IHS Settings8. WebSphere Security / Admin structure9. Third Party Software Products / Media players10. COGNOS … (Again - I pitty you …)11. CCM (depending on originating version)

What do you NOT migrate:Search indexesLocal Data Stores (are recreated upon install)

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:

●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

Note: A “real” project plan has WAAAY more details!

Your first and most important decision is HOW you intend to migrateParallel 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

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!)

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 ***

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

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:

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 ***

MWLUG 2014

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

(note: Gandalf will not help you …..)

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

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 commandswsadmin.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

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 ….

The Database Wizard

The Database Wizard

Has two main functions

1. Creation / Deletion of Connections Databases on the DB server2. 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!

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 completionThe 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 . . . .

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 . . . . .

Let’s look at some examples!

MWLUG 2014

Let’s Migrate some Configurations

“To automate, or not to automate … that is the question”

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.)

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

I !SO! hope you did not do any of those ….

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

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 InstallRoot\migration] folder, the command is:

[migration..sh/bat lc-export]

This exports (almost) all the files you need to the [\Connections InstallRoot\migration\work] 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=*******]

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 It80% 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.

MWLUG 2014

Them Files – They have to Go Somewhere

The “Other White Meat” or How to Migrate The Need To go

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.

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 …..

MWLUG 2014

Customizations – What to Look Out For

Don’t just throw your previous version onto the server ….

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 . . . . .

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!

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.

MWLUG 2014

CCM – FileNet and the changes …..

Don’t you just LOVE FileNet?

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:\IBM\Connections\data\shared\ccm] and save it!, also

back-up the x:\IBM\Connections\addons\ccm] folder with all content• Copy the FileNet storage to the new server in the folder [x:\IBM\Connections\data\shared\ccm] • Migrate the encryption keys from your old system to the new -> the location is on the Deployment

manager: [x:\IBM\Connections\addons\ccm\ContentEngine\tools\configure\profiles\CCM\ear]

FileNet / CCM – The Steps Necessary

Continued . . . . .

• Run the following command in the [x:\IBM\Connections\addons\ccm\ContentEngine\lib]

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:\IBM\WebSphere\AppServer\profiles\Dmgr01\config\cells\CELLNAMEl\fileRegistry.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

MWLUG 2014

Cognos ….

I Don’t Want To Talk About It …….

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 …..

About me . . .

Victor Toal aka “Dr. Vic”

victor@toalsys.comTwitter: vtoalSkype: vtoal