Connections 6 migration observations

I am sure that lots of you have installed or started migrations to Connections 6 by now .. but I have found a couple of gotchas across the installs and updates that I have managed so far.

I am listing them here for sanities sake as I know when we google an error – this blog will show up πŸ™‚

 

Connections 6 itself

 

Generally this was a nice smooth install and all worked as it should in a clean 6 environment

On testing a migration though I found issues when trying to migrate some of the DBs.

After dropping and restoring the DBs some were not updating to the latest DB2 version – this is resolved by running the update DB command

db2 upgrade db <DBNAME>

this upgrades the DB to the latest DB2 version – I run this after each restore command now to ensure the DB does update

for example

db2 restore db BLOGS from E:\install\V55_Backup\db2_backup taken at 20170718123342 ON E:\ into BLOGS
db2 upgrade db BLOGS

 

The metrics DB would not restore as it was complaining about heap size – after a quick google on the error I found a page suggesting just to change the application heap size using the following command

db2 UPDATE DB CFG FOR METRICS USING APPLHEAPSZ 4000

This resolved the problem and the metrics DB could be restored

 

I have also seen issues with the Connections DB update wizard when the databases have a lot of data. In a mature environment I generally run through the wizard and save the update commands to a text file. Then execute them manually from the db2 command window – for example

Activities
 1. E:\IBM\SQLLIB\bin\db2cmd -c -w -i db2 -td@ -vf connections.sql\activities\db2\upgrade-55CR2-60.sql
 2. E:\IBM\SQLLIB\bin\db2cmd -c -w -i db2 -td@ -vf connections.sql\activities\db2\appGrants.sql
 3. E:\IBM\SQLLIB\bin\db2cmd -c -w -i db2 -td@ -vf connections.sql\activities\db2\reorg.sql
 4. E:\IBM\SQLLIB\bin\db2cmd -c -w -i db2 -td@ -vf connections.sql\activities\db2\runstats.sql

Blogs
 1. E:\IBM\SQLLIB\bin\db2cmd -c -w -i db2 -td@ -vf connections.sql\blogs\db2\upgrade-55-60.sql
 2. E:\IBM\SQLLIB\bin\db2cmd -c -w -i db2 -td@ -vf connections.sql\blogs\db2\appGrants.sql
 3. E:\IBM\SQLLIB\bin\db2cmd -c -w -i db2 -td@ -vf connections.sql\blogs\db2\reorg.sql
 4. E:\IBM\SQLLIB\bin\db2cmd -c -w -i db2 -td@ -vf connections.sql\blogs\db2\runstats.sql

Bookmarks
 1. E:\IBM\SQLLIB\bin\db2cmd -c -w -i db2 -td@ -vf connections.sql\dogear\db2\upgrade-55-60.sql
 2. E:\IBM\SQLLIB\bin\db2cmd -c -w -i db2 -td@ -vf connections.sql\dogear\db2\appGrants.sql
 3. E:\IBM\SQLLIB\bin\db2cmd -c -w -i db2 -td@ -vf connections.sql\dogear\db2\reorg.sql
 4. E:\IBM\SQLLIB\bin\db2cmd -c -w -i db2 -td@ -vf connections.sql\dogear\db2\runstats.sql

.................. ETC.

For some reason if you have large DBs the wizard struggles massively. Running the commands manually from the command window also allows you to dump each commands logs out into a text file if you need to. Great for debugging and used a LOT when I ran through the AIX Oracle to Windows DB2 migration last year.

 

Once the DBs were restored and updated run the reorg and runstats against each of the DBs before you start it up and if you can also run theΒ clearScheduler.sql for each DB.

That should sort out the majority of DB issues you may see during the update.

 

Connections TouchPoint

 

Again a fairly easy process once you work out what the documentation is talking about – things of note

The document speaks of copying the touchpoint folder contents to the htdocs directory –

 

 

 

 

 

 

you have to copy the entire folder – for example

Copy files from E:\install\Connections\Touchpoint\touchpoint to E:\IBM\HTTPServer\htdocs\touchpoint the wording in the documentation doesn’t really make that clear.

All of the paths etc in the documenation are case sensitive.

Another thing of note which has tripped me up twice now so I have to blog it (thank you Ben for the extra eyes on this one) is the contents of the touchpoint.deploy.properties

The touchpoint.deploy.properties which is included in the install files is different from the example the documentation gives, we basically mix the two and have the contents of the file looking like this

# when install to a clustered environment, provide clusterName.
# when install to a standalone server, provide node and server name.
clusterName=apps
#nodeName=icbvtDB2Node01
#serverName=server1

# setting required REE custom properties
ree.prop.image.upload.path=E:/IBM/CnxData/shared/touchpoint/upload_pic
ree.prop.profiles.app.entrypoint.host=connections.url.com
ree.prop.profiles.app.entrypoint.scheme=https
ree.prop.profiles.app.entrypoint.port=443

NOTE:Β  If using windows the image upload path must have / the linux way not \ the windows way. It will fail if you don’t even if you have it in “E:\IBM\etc…” it appears to be a java / python thing and the error will complain that it can not pass the properties file if the slashes are not /

 

IBM Docs CR2

 

To use IBM Docs with Connections 6 you must update to CR2 for Docs – that is fine (and see previous blog posts about issues with applying the CR2 fix).

There is an awesome gotcha that my good friend Roberto pointed me in the direction of the fix for – this one was a good one (thank you Marti for writing the blog)

The symptoms are Docs editing works fine, but when attempting to view a file the error : CLFAF400W: Can’t access the document repository appears

Its a super quick fix – edit the viewer-config.json which can be found in the (i.e \IBM\WebSphere\AppServer\profiles\Dmgr01\config\cells\<cell name>\IBMDocs-config)

Under the section

"components": [
 {
 "config": {
 "uploadRepository": "lcfiles",

find the line

 "class" : "com.ibm.concord.viewer.lc3.repository.LCFilesEJBRepository",

and replace it with

 "class": "com.ibm.concord.viewer.lc3.repository.LCFilesCMISRepository"

Just above that you can see the files_path

 "files_path": "E://IBM//CnxData//shared/files/upload"

Add the additional info to that section

 "j2c_alias": "connectionsAdmin", 
 "s2s_method": "j2c_alias", 
 "server_url": "https://connections.url.com/files",
 "files_path": "E://IBM//CnxData//shared/files/upload"

So the full section will now look like this:

 "components": [
 {
 "config": {
 "uploadRepository": "lcfiles", 
 "adapters": [
 {
 "config": {
 "j2c_alias": "connectionsAdmin", 
 "s2s_method": "j2c_alias", 
 "server_url": "https://connections.url.com/files",
 "files_path": "E://IBM//CnxData//shared/files/upload"
 }, 
 "id": "lcfiles", 
 "class": "com.ibm.concord.viewer.lc3.repository.LCFilesCMISRepository"
 },

 

Save the file and do a full sync once a restart of the viewer app is done the viewer will now work.

 

One other thing of note when it comes to migrating the Docs data and DBs is that almost every time you do a migration the wasadmin user will be out of sync and you will see duplicate user issues in the log.

easily resolved by running the syncMember command from the DMGR\bin directory

wsadmin.bat -lang jython

execfile("filesAdmin.py")

FilesMemberService.syncMemberExtIdByLogin("wasadmin")

 

Other things you should do once the docs data has been migrated is to run the generate thumbnails command (also from wsadmin in the filesAdmin section)

wsadmin.bat -lang jython

execfile("filesAdmin.py")

FilesThumbnailService.generateForAllFiles()

 

Also to migrate any drafts from the docs installer directory i.e

wsadmin.bat -lang jython -f E:/IBM/ConnectionsDocs/Docs/installer/docs/tasks/start_migration_tool.py

 

Hopefully you won’t come across any or more than one of these issues, but if you do hopefully there will be a quick resolution.

If I find anything else I will be sure to blog them.

FEB / Connections Surveys – custom LDAP attributes

Thanks to Christopher Dawes in the IBM Forms support team a long running issue I have seen with FEB (Forms Experience Builder) / Connections surveys is now resolved!!

Once of my long standing very awesome customers was seeing a problem with Connections surveys. They do not use a standard LDAP attribute for their displayname – the cn is the employee number and the uid is a short name which is not always easy to differentiate between users. These are the 2 attributes that FEB expect to use as the user display name. Not always easy to tell who abc12345 is .. or sbell123 so I opened a PMR to get to the bottom of how to change this to a custom LDAP attribute – in this case we use fullName – which displays my user as Sharon E Bellamy.

After a bit of backwards and forwards, many logs and tracing and a bit of DB hacking to prove the theory we now have a solution.

So here is how to resolve it.

Firstly you need your custom LDAP attribute – fullName
You will the repository Id of your LDAP – this is basically the label you have given the LDAP in the configuration. In this case it was novell as the LDAP is Novell E Directory

LDAPID

 

 

 

 

 

 

but in another example here you can see an Active Directory example (ADInternal)

 

 

LDAPID2

 

 

 

 

 

 

 

Step 1:

Add a new WebSphere Entity Type – wsadmin

open a command prompt to the deployment manager/bin directory

run wsadmin (you do not need to set the lang type to jython)

enter the command to set the new entity type – were name = your LDAP attribute name and repositoryIds is your LDAP identifier

 

[blockquote]

$AdminTask addIfMgrPropertyToEntityTypes { -name fullName -dataType String -isMultiValued false -entityTypeNames PersonAccount -repositoryIds Novell}

[/blockquote]

 

 

 

 

 

This registers the attribute in the WIM config.

 

 

 

Step2:

Add the entity type into WebSphere

open the WebSphere admin console / ISC

browse to Security > Global Security > Configure federated repositories

Click on the link for your repository identifier (novell in my case)

LDAPID3

 

 

 

Once in the repository config, click on the Federated repositories property names to LDAP attribute mappings

 

LDAPIDs4

 

Enter a the new attribute for our custom LDAP entry (fullName)

 

LDAPIDs5

 

Where Name = a meaningful name for the new attribute

 

Property name = the LDAP attribute name

 

Entity types = PersonAccount

 

Apply and save

 

Save a lot

 

then restart the deployment manager.

 

Step 3:

Edit the Builder_config.properties on the node where FEB is installed (in my case the primary connections node)

the default directory where this is kept is

Windows – C:\IBM\Forms\extentions

Linux – /opt/IBM/Forms/extentions

Open the property file in your favourite text editor

near the top of the file ensure the

ibm.was.MemberManager.userProps.displayName property is not commented out and add your new LDAP attribute

in my case

 

[blockquote]

ibm.was.MemberManager.userProps.displayName = fullName

[/blockquote]

 

 

 

 

 

Save and close the file

 

and restart everything

 

Now when you create a survey or fill one in your new attribute it used.

Existing surveys are updated with the owner / creators name when they log in. The freedom (FEB) DB is updated when the user logs on and the display name is updated.

 

There you have it – took a while as there was a little bit of jiggery pokery with the wsadmin command and the PersonAccount attribute but it works πŸ™‚

Hope this helps anyone else seeing the same problem

External users in connections, multiple LDAPs when using domino root

Originally posted over on the Cube Soft Blog

As mentioned in our presentation at EngageUG – We came across a problem when adding multiple LDAP repositories in WebSphere.

The scenario was a Domino customer – who use the root domino domain – had a requirement for a second LDAP repository in connections to manage external users. They are a global company and via directory assistance grab the users that need access to connections but have no control over the records themselves. The plan was to have a 2nd domino domain for external users that the admins could manage independently of the main directory / domain.

We hit a problem as when using the domino root – it does all sorts of *fun* things inside WebSphere to overwrite any 2nd LDAP or additional base realm entries. After much testing with domino and ad as a 2nd LDAP, all the known work arounds didn’t resolve the issue, we opened a PMR.

As it turns out the answer was pretty simple:

Set your domino root LDAP us as you would do normal – but, when you get to the point of adding the unique base entry to the realm add a name i.e o=dominoRoot (it doesn’t matter what this is as long as its o= something)

Select the tick the box to use a different distinguished name – leave the 2nd box blank
*EDIT* – you may need to add double quotes to provide a blank – i.e β€œβ€ we will remove this in the next step

domRoot

Save the config.

Next we need to edit the wimconfig to remove the offending entry that causes WebSphere to get confused.

The wimconfig can be found in <WAS_HOME>/profiles/Dmgr01/config/cells/<CELL_NAME>/wim/config

Find the entry relating to the new domino root entry .. and remove the duplicate base entry :

<wimconfig.xml>--------------------------------------------
<config:baseEntries name=""/>
<config:baseEntries name="o=dominoldap" nameInRepository=""/>
</wimconfig.xml>--------------------------------------------

remove the line
<config:baseEntries name=""/>

save and close the file and restart the deployment manager and connections nodes.

Once restarted the Domino root users and groups are still accessible inside WAS / Connections and it is now possible to add a second LDAP base entry correctly.

In the case of this particular customer we have added an External users AD, but another domino domain directory or any other supported LDAP should also work perfectly πŸ™‚

Fun and games with Commuity wigets

Last night we managed to close a PMR that had been open for a few weeks on a strange issue with Community Widgets.

After remapping the connections admin user everything worked exactly as expected except for 2 tiny issues – Adding the blogs and surveys widgets inside a community thew a nasty error.

communityError

 

Thanks to Justin Cornell in IBM support we managed to get to the bottom of the issue by remapping the widgets admin user even though it was mapped correctly.

Jump over to the Cube Soft Blog –Β  Fun and games with Community Widgets for the full diagnosis and resolution.

Fun and Games – O yes πŸ™‚

 

 

 

 

 

Odd issue with Connections Mail

I have been looking to implement Connections mail for a while for one of my customers, after finally sorting out some SSO issues we had been seeing I was ready to deploy into their DEV/TEST environment. No problem I thought – Connections mail is a very simple install a couple of config files and a quick wsadmin command to get the help to work.

Once I had deployed I was seeing the strangest issues –

Contact your system administrator:
Missing element with class=”os-site-mail-notify”

After spending a few hours trying to work out what the issue was, sanity checking myself in the Connections skype chat and much google-ing – I threw in the towel and opened a PMR.Β I did my usual of explaining the situation, listing OS and level, Connections versions and fixes etc and sending in a screen shot, Log files and the Connections mail config file – a couple of hours later I had a response.

It appears that something has changed between V4 and V4.5 of connections – I had customisations brought over from V4 and copied the header.jsp as it looked on first glance that there was no changes between 4 & 4.5

In Version 4.5 the span for the mail notify icons is :
–%><spanΒ class=”os-site-mail-notify”></span><%–

Previously it was:
–%><spanΒ id=”os-site-mail-notify”></span><%–

Changing this span from id to class resolved my issue.

So the moral of the story is even if you think nothing has changed – it most likely has

Big thanks to Jonathan P. Dormady Staff Software Engineer in Connections Support for finding me a solution so quickly

 

Connections 4.x search – well that was a weird problem

If you have migrated or moved an IBM Connections instance from 3.0.1 > 4.x (either 4.0 or 4.5) or moved data between 4.x servers you may have noticed a weird issue with searching, especially around communities.

The reason I have been a bit quiet on the blog of late is because I am working on a few Connections projects many of which have involved migrating data between test and live servers or replicating data between servers. I have come across a few issues relating to search so I thought I would share them to save you guys the pain.

Everyone knows when you migrate or move data between servers you should clear the scheduled tasks and rebuild the search indexes – but in V4.x a new set of search data came in for Community searching – the catalog.

When the search task runs is collects a bunch of information about communities for the lists you see under the my communities tab and public communities – it collects this in the catalog.

The issues I was seeing was that all historical data regarding Community membership and Public communities was not being shown and that is because of the catalog.

There are a couple of places that catalog data is stored and you can check this by looking up the WebSphere variables :

CATALOG_INDEX_DIR
CATALOG_REPLICATION_DIR

Typically CATALOG_INDEX_DIR is stored in < Connections install > /data/local/catalog/index

and CATALOG_REPLICATION_DIR is stored in < Connections install > /data/shared/catalog/indexReplication

there is also a temporary folder in your os tmp directory called indexCreationDir in the case of most linux systems it is /tmp/indexCreationDir

When you run your data migration and delete the search index under < Connections install > data/local/search ( I normally rename the index folder to #index)

also rename or remove the Places folder under < Connections install >/data/local/catalog/index/ and < Connections install > /data/shared/catalog/indexReplication and remove or rename the /tmp/indexCreationDir

once you restart Connections run an index now to rebuild the indexes, seedlist and the catalog data and your search will function as expected.

for example:

execfile(“searchAdmin.py”)

SearchService.indexNow(“activities, blogs, calendar, communities, dogear, files, forums, profiles, status_updates, wikis”)

 

I am sure that our resident Community script guru (Mr Christoph Stoettner) could script clearing these but for now its a manual process – hope this will save you some head aches on upgrades and migrations πŸ™‚

 

 

 

 

 

Returning user login issues – fun with the connections databases

I recently had an issue with a user having issues logging in to certain applications.

The user could log in to some apps but recieved an error on others – for instance profiles, activities, communities and forums the user was fine.

Each applications database holds information regarding the user login and their external / directory / guid id – this guid is unique to the user – I found after extensive investigation that this user had orphaned entries in the other application DB tables.

The SQL queries and statements used to resolve this were *fun* to work out and they may be slightly different for each user that has this issue, but it should be fairly straight forward to work out once you know what the issue is.

*NOTE* below is the solution that I used to resolve the issue – it will be / may be different for each user with a similar problem. It is advised where possible to test this on a back up of the DB to ensure it resolves the issue. Always back the databases up before making any change.

Firstly look up the user in the profiles database and gather thier login id (prof_uid) and external directory id (prof_guid)

Once you have these you are ready to start the investigation.

In the case of this user the SQL was as follows :

CORRECT GUID / EXT / DIRECTORY ID = C7B75D042B4C7C7B8025791100311ADA

== BLOGS ==

select * from blogs.rolleruser where username =’jsmith’;
select * from blogs.rollerloginname where username like ‘jsmit%’;
get the user id = 62537efa-3959-42a4-84f3-5e1fdc8cfac0
select * from blogs.rollerloginname where userid = ‘62537efa-3959-42a4-84f3-5e1fdc8cfac0’;
delete from blogs.rollerloginname where userid = ‘62537efa-3959-42a4-84f3-5e1fdc8cfac0′;
delete from blogs.rolleruser where username =’jsmith’;

== DOGEAR ==

select * from dogear.personlogin where loginname like ‘jsmit%’;
get the person_id = 436b98eb-59a9-420f-90d6-22b7a4926e00
select * from dogear.personlogin where person_id = ‘436b98eb-59a9-420f-90d6-22b7a4926e00’;
delete from dogear.personlogin where person_id = ‘436b98eb-59a9-420f-90d6-22b7a4926e00′;
select * from dogear.person where person_id=’436b98eb-59a9-420f-90d6-22b7a4926e00′;
delete from dogear.person where person_id=’436b98eb-59a9-420f-90d6-22b7a4926e00’;

== FILES ==

SELECT * FROM FILES.USER_TO_LOGIN where login_id = ‘jsmith’;
delete FROM FILES.USER_TO_LOGIN where login_id = ‘jsmith’;
select * from FILES.LIBRARY where title like ‘John Smit%’;
get label – C53524EEDB0F84E8802578C5002676AD
delete from FILES.LIBRARY where label =’C53524EEDB0F84E8802578C5002676AD’;
SELECT * FROM FILES.”USER” where name = ‘John Smith’;
delete FROM FILES.”USER” where name = ‘John Smith’;

== forums not an issue – has the correct GUID ==

select * from forum.df_memberlogin where loginname like ‘jsmit%’;
get memberid = d1140454-09ac-4484-a50e-ce914e573e7d

== HOMEPAGE ==

select * from homepage.loginname where loginname like ‘jsmit%’;
get person_id = cf48e29d-7d89-4f8a-acf0-47b9a8bcb98a

select * from homepage.loginname where person_id = ‘cf48e29d-7d89-4f8a-acf0-47b9a8bcb98a’;
delete from homepage.loginname where person_id = ‘cf48e29d-7d89-4f8a-acf0-47b9a8bcb98a’;

select * from homepage.person where displayname = ‘John Smith’;
get person_id of the incorrect GUID – db306bce-40cc-413a-b93c-1ad61a24cdae

select * from homepage.hp_ui where person_id in (‘cf48e29d-7d89-4f8a-acf0-47b9a8bcb98a’,’db306bce-40cc-413a-b93c-1ad61a24cdae’);
make note of any person IDs that bring back any entries – cf48e29d-7d89-4f8a-acf0-47b9a8bcb98a
and ui_ids – 45cbd2dc-aefa-46f4-9607-654ddab953d8

select * from homepage.hp_tab_inst where ui_id like ‘%45cbd2dc-aefa-46f4-9607-654ddab953d8’;
make note of full ui_id – 45cbd2dc-aefa-46f4-9607-654ddab953d8
make a note of tab_inst_id b1072db9-c553-4a04-8366-e7d26a415edb b9114d19-4d97-42b0-8760-580cc956abe8

select * from HOMEPAGE.HP_WIDGET_INST where tab_inst_id in (‘b1072db9-c553-4a04-8366-e7d26a415edb’,’b9114d19-4d97-42b0-8760-50cc956abe8′);
delete from HOMEPAGE.HP_WIDGET_INST where tab_inst_id in (‘b1072db9-c553-4a04-8366-e7d26a415edb’,’b9114d19-4d97-42b0-8760-580cc956abe8′);

delete from homepage.hp_tab_inst where ui_id = ’45cbd2dc-aefa-46f4-9607-654ddab953d8′;

delete from homepage.hp_ui where person_id in (‘cf48e29d-7d89-4f8a-acf0-47b9a8bcb98a’);

delete from homepage.person where person_id in (‘db306bce-40cc-413a-b93c-1ad61a24cdae’);

correct person id = e8238bbd-255f-4609-8a54-e28128f3e66b

== Activities is ok – is the correct GUID==

select * from activities.oa_memberlogin where loginname like ‘jsmit%’;
get memberid – CACG7F00000152B3E7EBA823194CED0000C6

SELECT * FROM ACTIVITIES.OA_MEMBERPROFILE where memberid=’CACG7F00000152B3E7EBA823194CED0000C6′;

== Communities is ok has the correct GUID ==

select * from sncomm.memberlogin where loginname like ‘jsmit%’;
get member_uuid – 0e56702f-9f37-4f2c-b295-2dd3250da726

select * from sncomm.memberprofile where display = ‘John Smith’;

== Wikis ==
SELECT * FROM WIKIS.”USER” where name like ‘John%’;
select * from wikis.user_to_login where login_id like ‘jsmit%’;
delete from wikis.user_to_login where login_id = ‘jsmith’;
delete from wikis.user_to_login where login_id = ‘jsmith@org.com’;

==

When these statements had been run the user can log in correctly as the additional orphaned entries have been removed.

Please note that due to the data and the contstraints on the database that there may be additional statements required – the SQL above is a guide on how I resolved the issue.

It was a FUN FUN FUN one to sort out .. I do love a good problem:)

A fix for the Chrome header issue

Stuart blogged back in January about a known issue with downloading files from the files application using Chrome.

chromeIssue

IBM do not officially support Chrome with Connections 3.0.1 – but our good friend & IBM Champion Sjaak Ursinus has devised a work around.

Header edit Content-Disposition ^(.*)creation-date=(.*);\smodification-date=(.*);$ “$1creation-date=\”$2\”; modification-date=\”$3\”;”

ensure the mod_header module is uncommented httpd.conf

save and close the file.

Restart the HTTP server to pick up the change

Sjaak’s full explanation can be found on the Connections Forum

Issue with custom themes and communities

I have had a PMR open for some time relating to a bit of a known issue with Custom themes and Connections communties

There was an issue where you would create a custom theme


In my case I also customised the coloured community themes also

When clicking on forums, blogs etc the theme was stripped out displaying

It appears there was a step missing from the wiki!!

http://www-10.lotus.com/ldd/lcwiki.nsf/dx/Defining_a_community_theme_ic301

Step 1.dd. Remove the file theme.css from the corporateTheme directory

In my case I had based my custom theme on the default theme and had used it as the default Community theme (which has no theme.css), so all communities with the default theme appeared correctly.

BUT, I had also lightly customised the coloured community themes – removing (or renaming) the theme.css from each coloured theme has resolved the issue.

Thank you mr Kieran Reid for investigating and confirming this was the issue.

Issue with Connections media widget timing out

Whilst building a new Connections environment for a customer we noticed a strange issue when uploading large files to the media gallery.

Initially I thought it was related to the size of the file, but the same file will upload to the Connections files application without issue. There is very little errors in the SystemOut.log for the Connections server, so I was baffled.

A PMR was opened and the very helpful Mr Dave McCarthy was the PMR owner and we then started on our investigation. During the testing I noticed that the uploads appeared to timeout after 20 mins, exactly 20 mins. After some experimenting on 4 different Connections systems, it was confirmed that it was a timeout, reguardless of the file policy or file library size. So not many people are on a intenet connection that may take 20 mins to upload a video, but we know it is an issue as the customer I was building the system for confirmed this.

After much digging through existing PMRs Dave was stummped, so the PMR was passed up the chain to the development team. Who confirmed very quickly that their is a setting in the config.js which is burried in the news ear file which has a time out set to 1200 sec (20 minutes)!! Change this setting and as if by magic the timeout issue is resolved.

To change the time out setting do the following :

/installedApps//News.ear/qkr.lw.war/WEB-INF/pages/js/config.js

Find this section, (Line 450), that specifies some timeout values,
including one for upload that is set to 1200 sec (20 minutes):

timeout: {
request: 60,
update: 200,
upload: 1200,
retrieveFiles: 100,
userSearch: 200,
userTypeahead: 10
},

Raise the upload value from 1200 to what is needed to complete the large file upload on your connection speed and save the file. Then restart the News application to make the change effective. This file should be changed on the primary Connections node if you have more than one and sync the changes around the other nodes.