© 2014 IBM Corporation

BP304 : What We Wish We Had Known: Becoming an IBM Connections AdministratorGabriella Davis, The Turtle Partnership Paul Mooney, Bluewave

© 2014 IBM Corporation

Connections in all its guises

!3

• A Connections Administrator is knowledgeable about many different products and tools that have a wider application than just IBM Connections

• A Connections developer can use development tools from CSS to OpenSocial gadgets to Java and more, all have a much wider application than just IBM Connections

© 2014 IBM Corporation

Installing

Do Yourself Some Favours

▪ Install all fixpacks for all products especially WebSphere.

▪ Use the system requirements page to verify they haven’t changed

▪ Don’t let Installation Manager install what it considers the latest

▪ Avoid special characters in any passwords including @ ! < > { }

▪ Use backupconfig before making any changes to deployment manager configuration, especially changes to LDAP

▪ Modify security.xml if you get locked out of WebSphere

▪ Make sure plugin-cfg.xml is deployed to the correct directory to be used by IHS

▪ Don’t skip the post installation tasks

▪ Make sure the deployment manager disk is big enough to install all components including Filenet for CCM

!5

© 2014 IBM Corporation

Where Things Are

▪ WebSphere has no database itself and your information has to be stored somewhere.

– We need a database server, either DB2 , SQL or Oracle

– Most of the applications have their own dedicated database for storing the tables and data they need

▪ As administrators we don’t mess with the design or structure of the Connections databases

– These are created by IBM supplied scripts and occasionally updated during fixpacks by new scripts

– If you touch it, you break it.

DATA SOURCES

!7

▪ Well no, there’s data in other places too

▪ File attachments uploaded into files or activities or forums etc aren’t kept in the databases

– Only pointers to those files are kept in the databases

– The files themselves are stored on the file system

▪ If you have multiple WebSphere servers those files can’t stay in sync, this isn’t Domino

– So there needs to be a file share location (NFS) that all servers can see and access

– Don’t worry the files aren’t easily readable as content or even a file structure

▪ This is called Connections Shared Data

Is That all?

!8

▪ Back up your Connections shared data location

▪ Make sure that shared data is on a fast accessible disk that isn’t fragmenting

▪ Make sure you move the data if you move the servers

▪ The location of the share is determined by an environment variable set in WebSphere so it’s easy to change the value of that variable or even where that path points to, at a later date if you need more capacity

▪ Handling shared data is part of your upgrade strategy

▪ If your shared store is broken you may not notice until someone tries to look at, download or upload a file attachment

Shared data

!9

▪ No. There’s also local data stores for Connections applications

▪ Some information needs to be local to the server running each application and is exclusively used by that application on that server

▪ Another server with a cluster of the application will have a different local data store and its own locally created information

▪ A good example of this is the search index

– The search index is created by the search application on each server that application runs on

Is THAT all?

!10

Local Data

!11

▪ You can copy a search index between servers but that’s a point in time copy, it won’t stay in sync

– Don’t copy any local data whilst your destination server is running

▪ Local data in general will be re-created by the applications if removed

▪ Whereas the shared data is a single location to backup, the local data is different on every server

– Losing your local data shouldn’t be fatal for your environment but I don’t recommend it

Anything else?

!12

▪ Many customisations are in a specific customisation directory in the shared data store

– This protects them from being overwritten during upgrades

– More on this later

▪ Communities are a special case

– A community contains data from many other applications like forums, blogs, files, activities

– Community content is written out directly to those applications and cross referenced in a Community

▪ If you delete a Community you create holes in the databases of those applications, restoring a backup of your Community won’t fill in those holes again

– Deleting a Community is very bad.

LDAP - Authentication

!13

▪ LDAP is used In Connections for authenticating users access to the system

▪ Multiple different LDAP servers can be specified to operate like Directory Assistance in Domino

▪ If you want to use failover LDAP servers set those up in WebSphere rather than point WebSphere at a load balancer for LDAP

– WebSphere will be more consistently reliable and stable

!▪ If your LDAP server (or even DNS) is slow to respond, your users will experience slow server

access

LDAP – Populating profiles

!14

▪ Profiles in Connections are populated from your LDAP directory

▪ Connections uses Tivoli Directory Integrator to move the data from your LDAP source to the PEOPLEDB database

▪ It’s possible to populate bi-directionally and to populate from multiple sources

▪ IBM supply all the scripts, batch files and assemblylines needed to manage profiles

– Use the IBM supplied files as templates, do not create your own – you won’t have support

Administrator –populating profiles

!15

▪ There are three methods to populate profiles

– The population wizard that provides a GUI to import LDAP source to PeopleDB destination

– Manually modifying the XML and properties files supplied by IBM and running the batch files such as collect_dns and sync_all dns to populate the data either LDAPtoPEOPLEDB or LDAPtoPEOPLEDBtoLDAP (bi directionally)

!– Create an assemblyline using TDI’s configuration editor interface and using IBM supplied

ProfileConnector

• As assemblyline can connect to nearly any data source

• Assemblylines can run very quickly and custom populate data to and from multiple data sources

IBM HTTP Server

!16

▪ The IBM HTTP Server routes URL queries to and from users to the back end WebSphere applications

▪ Since this is the route through which all traffic travels we can secure SSL through IHS intead of WebSphere

▪ IHS is cluster aware when added to WebSphere and will dynamically route requests across the cluster

▪ Multiple IHS servers can be used via a load balancer to route Connections traffic

IBM HTTP Server - administrator

!17

▪ Configuration for IHS happens in three main places

▪ Httpd.conf file , a complex text file held on the file system

– This can easily be ovewritten and a simple change can break Connections completely

▪ Plugin-cfg.xml – the WebSphere plugin file that informs IHS what URLs need to be redirected to the back end servers and not resolved locally

– This is generated from within WebSphere and distributed via the ISC

▪ Plugin-key.kdb / plugin-key.sth used to store the SSL certificates

Connections content manager

!18

▪ CCM uses FileNet as a document library which itself needs to store file data and references

!▪ We have additional databases that are created either during install or via the DBWizard to be

used exclusively by Filenet

▪ The FileNet program files will be on your deployment manager server even if the applications are on another WAS server so make sure you have enough capacity

!▪ There is also a Filenet Administration Interface called the Administering Console for Content

Engine where the Filenet specific configuration settings are held including how to map Filenet to Connections applications and behaviour hostname:serverport/acce

▪ Installing CCM with Connections is the only guaranteed way to ensure Single Sign On out of the box and across Filenet servers

Cognos

!19

▪ Cognos is used for creating and reporting Metrics, it uses WebShere to deliver HTML reports that are built into the Metrics application in Connections

▪ Data is held in three places

– Metrics and Cognos databases created by the Connections DBWizard

– Cognos configuration interface

– Transformer Cubes on the Cognos file system

Forms experience builder

!20

▪ Connections 4.5 IFR1 is a change in entitlement enabling the user of Polls and Surveys within your environment

▪ Polls and Surveys use a standalone install of FEB which integrates with Connections Communities

▪ FEB is an optional install that can be added to an existing WebSphere cluster

▪ FEB has it’s own database for storing surveys

– and only supports DB2 as a data source

© 2014 IBM Corporation

Administration

WEBSPHERE ADMINISTRATION

!22

▪ Once IBM Connections is installed there are two places where we would perform day to day administration

!– Application security - the rights users have to applications

• Application security isn’t very granular “one size fits all”

• New roles that change behaviour aren’t something you can add

!– Wsadmin

• WebSphere’s command line administration tool for sending instructions to applications

• Wsadmin is also used to make changes to application configuration settings

Application security

!23

▪ For every application there are pre-defined roles that that determine the scope of the user’s behaviour

▪ Many of the roles such as “admin” or “global-moderator” apply across multiple applications

– But do different specific things in each application

– And must be set separately

▪ There are also pre-defined special “categories” you can assigned to applications such as

– all authenticated users in application’s realm

– Everyone (includes anonymous users)

Application security - activities

!24

WSAdmin – sending commands

!25

▪ To run any wsadmin command always start from the bin directory of the deployment manager e.g

!– C:\IBM\WebSphere\AppServer\profiles\Dmgr01\bin

– Call wsadmin by typingwsadmin(.sh) –lang jython –username [name] –password [password] then choose which application you want to work with execfile(“profilesAdmin.py”)

▪ Any changes you make here will be pushed out to all the nodes

▪ Wsadmin commands are case sensitive regardless of your platform

WSAdmin – modifying connections configuration

!26

– wsadmin –lang jython –username [name] –password [password]

– execfile(“connectionsConfig.py”)

– LCConfigService.checkOutConfig(“[filepath]”,AdminControl.getCell())

!▪ The LotusConnections-config.xml file will be in your filepath where it can be edited then

checked back in and validated

!– LCConfigService.checkInConfig()

JAAS AUTHENTICATION

!27

▪ To connect each application to its data source there is a J2C authentication resource created during install

▪ If you need to change the account name or password you will need to edit the details for the JAAS Alias

– Global Security – JAAS – J2C authentication data

Reorg scripts

!28

▪ To handle database fragmentation you should regularly run the supplied IBM reorg.sql scripts

▪ The scripts are located in the connections.sql directory of the installer

▪ The reorg scripts traverse each table in the database clearing up whitespace and optimising the remaining data

Backing up configuration

!29

▪ Always backup before making configuration changes

▪ From the deployment manager bin directory run the backupconfig(.sh)

– Backupconfig c:\backups\gdbackup.zip –nostop

• The backup will be a zip file,

• The –nostop command prevents backupconfig from stopping the deployment manager before running

– Restoreconfig c:\backups\gdbackup.zip

• Restore once you have stopped the server

Logs

!30

▪ Any application problems will be found in the SystemOut.log of the server where the application is running

▪ If you are using a cluster then you will need to check the SystemOut for each server in the cluster

– Modify the LOG_ROOT WebSphere variable for log location

– Configure each server log for rollover and retention

Do’s & do nots

!31

▪ Backup your configuration using backupconfig before making changes to the configuration

– Never manually edit an XML configuration file, always use wsadmin which verifies the XML structure as it’s checked back in

– Schedule the database reorg maintenance scripts to run regularly,

– Set up specific credentials for developers to use to access the Connections data, don’t re-use administration credentials

– Ensure you have a test / staging server to test customisations and developments on

!– Never let your developer have ISC access or wsadmin access to a production

environment!