Maybe it is good to share with you want I think are the best features in the design of teamsite, and sure I'll also include the design area where teamsite should improve in a next blog.

But in this months issue the good teamsite stuff:

1. This must really be the branching and versioning system of Teamsite. What they did, or what it looks like they did, is taken the idea (and maybe even the code) of cvs and build a web-gui around it. This versioning can't be beaten. It gives you a detailed history of every file and roll-back options at both the file and full website level. Using the branching structure multiple websites (or releases) can be managed on the same server without any dependencies.

2. Runner-up must be the workflow system. It's strong, robust and very flexible. And it offers a wide range of different tasks: for user or group actions, to execute a command or cgi, to submit or update files/folders. However, what I deeply miss is easy support for email-notifications and unlocking (not by an external task as is the current use)

3. Another award must go to the complete openness of teamsite in every sense: input, processing and output. Any content can be uploaded via a file-mount, processing is open via command-line tools, java-api, soap and output can flow to every OS and web-technology (html, xml, jsp, php, asp.net, ruby, database, what ever you want)

4. And finally we should not forget the customisation options on offer. One can define custom cgi, workflows, scripts, templates, deployments.

One of the most useful features for a Teamsite administrator could very well be the flexible Teamsite groups.

These teamsite groups, which are equivalent to groups at the os-level, have two major advantages over these os-groups:

• they are controlled by the teamsite administrator
• they have to option to add a group to a group, empowering a hierarchical set up

The first is important because the os-groups are normally managed by a far away department that is usually slow to react. Adding or removing a user from a group could easily take days, leaving the end-user without proper access to Teamsite.

The second is maybe even more important because this, once set up right, enables the teamsite admin to easily add new users the proper rights by adding the user to 1 group only. Example: a basic group division would be 1 group of global adminstrators, 1 group of developers per 'teamsite-project' and a group of content-editors per 'teamsite-project'. Normally the developers have the same rights as the editors and some more and the admin's have all rights of the developers but IN EVERY PROJECT. This can be done by creating these groups:

• a group for the editors which contains all editors and the developers-group (per project or branch)
• a group for the developers which contains all developers and the admin-group (per project or branch)
• a group for the admins

Does using these ts-groups also have disadvantages? Sure:

• The iwchgrp clt does not work recursive where as chmod -R does
• In the os-level privileges all you see is the iwglobal group

OpenDeploy 6.1.1 has been out for quite a while. I have not had a look at it for a while but I don't think there was any reason to look at this version before: it does not contain much news.

The new features that are included are not that shocking (some new adapters and an option to only deploy files at the root-level, I'm not sure yet what good that is for).

But it comes with 1 major drawback and one that is well hidden in the release notes: you must obtain (and install) a license key for each install (both base server and receiver). This fact should be WRITTEN IN BOLD in the release notes but no, Interwoven has chosen not to mention this at all. How stupid can you be? The good thing is that license keys for receivers can be installed remote via.... opendeploy!!!. That is indeed quite nice.

And obtaining an license key is the same old hassle it has been since TS65 Sp2: via a website that is running on (or should I say hidden behind) port 8080. This port is, in most sensible enterprises, blocked for out going traffic. And thus you either have to use your private home internet connection, how professional, or send a request to support via email. Either way, it will cost you extra downtime, something that you can do without on any production server. You would think Interwoven would be wiser and run this website on a decent port, well let's say port 80.

Little tip for if you want to install Ts65Sp2 on a production server AND minimize downtime: install the service pack on another server, copy the license-detail executable to your production server and run it. It will return the needed details to generate a key BEFORE you run the Sp2-installer.