Your SlideShare is downloading. ×
Mwlug2014 - IBM Connections Security and Migration
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Mwlug2014 - IBM Connections Security and Migration


Published on

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

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

Published in: Software
1 Like
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 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 … 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 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></DirectoryServer> <DirectoryUser>username</DirectoryUser> <DirectoryPW>adminpw</DirectoryPW> <MailPattern type="" /> <MailPattern type="" /> </ServerConfig> <ServerConfig name="exampleexchangeconfig"> <ConfigType>EXCHANGE</ConfigType> <DirectoryServer></DirectoryServer> <DirectoryUser>username</DirectoryUser> <DirectoryPW>adminExpw</DirectoryPW> <DirectoryServerDomain></DirectoryServerDomain> <CertificateFile>c:exampleexchangecertificate</CertificateFile> <CertificateFilePW>exampleCellManager01/certificateFileAuth</CertificateFilePW> <MailPattern type=""/> <MailPattern type=""/> </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 : [] 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 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 -lang jython -user wasadmin -password **** -profile -c "NewsMemberService.syncAllMemberExtIds()" Followed by the syncAllMembersByExtId with update triggers: ./ -lang jython -user wasadmin -password **** -profile -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: [ 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 [ 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” Twitter: vtoal Skype: vtoal