Over the past few days I have been installing a Connections environment in a locked down windows environment with a very agressive group policy.
Which was a lot more locked down than I expected it to be, so here are a few gotchas that I discovered that may assist you if you are in the same situation.
In this scenario we were using 3 machines:
machine 1 – DB2, TDI and Domino (for LDAP)
machine 2 – Connections (Deployment manger and Connections node)
machine 3 – HTTP server
DB2
The Group Policy would only allow the db2admin user to do anything DB related. For the databases to install and function correctly I had to follow these steps.
Create the db2admin and lcuser accounts as a local machine admin, logon as the db2admin to install and configure db2, be logged on as the db2admin user to use the connections db creation wizard (it would work as another user to create them but all the grants failed) – normally I would add my machine admin account to the corrrect db2 groups, but the windows policy was not playing ball.
Once db2 is installed and the Connections dbs created the only users with access to the dbs are db2admin and lcuser – regardless of the users that were placed in the db2 windows groups – to query the DBs you must connect to the db with either of the valid users.
TDI
Appeared to work correctly (thank you TDI) – but I did find the issue in my previous post that if you use TDI 7.1 and then downgrade the connections wizards don’t work as expected.
HTTP Server
Installed as expected, but there were a few issues with communicating with the deployment manager.
Connections
Connections installed as expected, but took a long time, longer than normal.
Ports and other considerations
Pass the coms team / firewall team – whomever looks after such things a copy of the WebSphere plugin file and ask them to open all ports listed between HTTP and Depolyment manager machine, also port 8008 should be opened up for HTTP Admin.
Becuase of issues between the HTTP server and Dmgr/Connections machine, the news application was not mapped properly and plugin did not generate. This caused issues with the news app, which manifested itself with recomendations widgets, media gallery widgets and who do i know widgets throwing errors (no errors in the system out log) – after checking the http server error log, I found it was trying to serve news up from the webserver, after checking the plugin news wasn’t mapped.
This was easily resolved by remapping the news app to the webserver, regenerating and propagating the plugin file.
The Connections machine itself requires access to the internet for RSS feeds – if the machine can’t get out it can not retrieve RSS feeds and will give a nasty error.
It was a little challanging, especially when you have to justify every port, but once I spent 5 mins explaining how the environment hangs together and what the ports are required for it was no problem at all.
No doubt I shall be using this blog post to remind me of what needs to be opened up when I hit this issue again 🙂
