TeamSite 7.3 Admin Rev2 en

TeamSite
Administration Guide
Version 7.3
Document Revision 2
08 February 2013
Copyright Notice
Notice
This documentation is a proprietary product of Autonomy and is protected by copyright laws and international treaty. Information in this
documentation is subject to change without notice and does not represent a commitment on the part of Autonomy. While reasonable efforts have
been made to ensure the accuracy of the information contained herein, Autonomy assumes no liability for errors or omissions. No liability is
assumed for direct, incidental, or consequential damages resulting from the use of the information contained in this documentation.
The copyrighted software that accompanies this documentation is licensed to the End User for use only in strict accordance with the End User
License Agreement, which the Licensee should read carefully before commencing use of the software. No part of this publication may be
reproduced, transmitted, stored in a retrieval system, nor translated into any human or computer language, in any form or by any means,
electronic, mechanical, magnetic, optical, chemical, manual or otherwise, without the prior written permission of the copyright owner.
This documentation may use fictitious names for purposes of demonstration; references to actual persons, companies, or organizations are
strictly coincidental.
Trademarks and Copyrights

Copyright 2013 Autonomy Corporation plc and all its affiliates. All rights reserved. Advise, AudioLogger, Autonomy etalk, ContentServices,
ControlHub, DataDeploy, etalk PRO, etalk, e-talk, Expert, Explore, Interwoven, LiveSite, MediaBin, Media Aggregation Service, Observe,
OpenDeploy, Optimost, Qfiniti Enterprise 3, Qfiniti, Recorder, SmartEncode, SoftSound, SoftSound Analysis Plug-in, Survey, TeamSite,
VideoLogger, Virage ControlCenter, Virage Encoder, Virage SmartEncode, Virage VideoLogger, Virage, VisualAnnotate, VS Archive, VS
Broadcast Monitoring, and all related titles and logos are trademarks of Autonomy Corporation plc and its affiliates, which may be registered in
certain jurisdictions.
Microsoft is a registered trademark, and MS-DOS, Windows, Windows 95, Windows NT, SharePoint, and other Microsoft products referenced
herein are trademarks of Microsoft Corporation.
UNIX is a registered trademark of The Open Group.
AvantGo is a trademark of AvantGo, Inc.
Epicentric Foundation Server is a trademark of Epicentric, Inc.
Documentum and eRoom are trademarks of Documentum, a division of EMC Corp.
FileNet is a trademark of FileNet Corporation.
Lotus Notes is a trademark of Lotus Development Corporation.
mySAP Enterprise Portal is a trademark of SAP AG.
Oracle is a trademark of Oracle Corporation.
Adobe is a trademark of Adobe Systems Incorporated.
Novell is a trademark of Novell, Inc.
Stellent is a trademark of Stellent, Inc.
All other trademarks are the property of their respective owners.
Acknowledgments
MediaBin 8 uses Sea Dragon Ajax Code provided by Microsoft Corporation for Deep Zoom feature. (License: http://
gallery.expression.microsoft.com/site/SeadragonAjax/eula?licenseType=None)
Notice to Government End Users

If this product is acquired under the terms of a DoD contract: Use, duplication, or disclosure by the Government is subject to restrictions as set
forth in subparagraph (c)(1)(ii) of 252.227-7013. Civilian agency contract: Use, reproduction or disclosure is subject to 52.227-19 (a) through
(d) and restrictions set forth in the accompanying end user agreement. Unpublished-rights reserved under the copyright laws of the United States.
Autonomy, Inc., One Market Plaza, Spear Tower, Suite 1900, San Francisco, CA. 94105, US.
08 February 2013
Contents
Figures ............................................................................................................................................13
Tables ..............................................................................................................................................15
About This Document ...............................................................................................................17
Documentation Updates...............................................................................................................17
Conventions .................................................................................................................................19
Autonomy Customer Support .......................................................................................................21
Contact Autonomy........................................................................................................................22
Part 1 Introduction
Chapter 1
TeamSite Overview ................................................................................................................... 25
TeamSite Elements ......................................................................................................................25
Content Stores ......................................................................................................................25
Branches ..............................................................................................................................26
Workareas ............................................................................................................................26
Staging Areas .......................................................................................................................26
Editions .................................................................................................................................27
User Roles ...................................................................................................................................28
Reviewer ...............................................................................................................................29
Author ...................................................................................................................................29
Editor ....................................................................................................................................29
Administrator .........................................................................................................................29
Master ...................................................................................................................................30
WorkflowUser .......................................................................................................................30
WorkflowAdmin .....................................................................................................................30
TeamSite Administration Guide
Contents
TeamSite Workflow ..................................................................................................................... 30

Jobs ..................................................................................................................................... 31
Tasks ................................................................................................................................... 32
TeamSite Architecture ................................................................................................................. 32
Understanding the TeamSite File System ............................................................................ 34
NFS Exports ......................................................................................................................... 36
Specify VPaths ..................................................................................................................... 36
Related Documentation ........................................................................................................ 37
Chapter 2
Configuration File Overview ................................................................................................. 39
The iw.cfg File ............................................................................................................................. 39
Location of iw.cfg ................................................................................................................. 40
The iw.cfg File Options ......................................................................................................... 41
Additional Configuration Files ..................................................................................................... 46
Part 2 Administrative Tasks

Chapter 3
Configure the TeamSite Server ........................................................................................... 51
Configure User Interface Functionality......................................................................................... 51
Enable and Disable VisualPreview ....................................................................................... 52
Configure Domain Lists in the Login Screen ........................................................................ 52
Configure Email Settings ...................................................................................................... 53
Specify Valid Domains ......................................................................................................... 53
Configure Server Functionality .................................................................................................... 54
Control Modification Times ................................................................................................... 54
Modify Extended Attributes .................................................................................................. 55
Specify the Encoding of the iw.cfg File ................................................................................. 55
Configure the Web Daemon ................................................................................................. 56
Change the Servlet Engine .................................................................................................. 56
Set Locking Models .............................................................................................................. 56
Set a Locking Model on a Branch .................................................................................. 57
Locked File Submission ................................................................................................. 58
Locking Behavior ........................................................................................................... 58
Compare Files ...................................................................................................................... 58
Submit and Update Logs ...................................................................................................... 59
Autoprivate Feature .............................................................................................................. 59
Contents
Working with the Utility Service ....................................................................................................61

Run as Non-Root User ..........................................................................................................64
Start/Stop the iwutild Server .................................................................................................65
Enable the Event Subsystem .......................................................................................................65
Verify that the Event Subsystem is Enabled .........................................................................66
Ensure that the Event Subsystem Servlet is Started .............................................................67
Enable DAS Publishing .........................................................................................................67
Configure Server Performance.....................................................................................................68
Cache Size ...........................................................................................................................68
External Task Impersonation ................................................................................................69
Throughput Monitors .............................................................................................................69
Detect Low Disk Space and Inode Count ..............................................................................70
Configure the TeamSite Server Locale ........................................................................................70
Configure FormsPublisher............................................................................................................72
Set up the Example Environment ..........................................................................................72
FormsPublisher Settings in iw.cfg .........................................................................................73
Identify the Templating Directory ....................................................................................73
Maintain Preview Files ....................................................................................................73
Control Printing of Data Records ....................................................................................74
TeamSite Embedded Failsafe ......................................................................................................74
Chapter 4
Manage the TeamSite Server ................................................................................................ 75
Verify Server Operation................................................................................................................76
Start and Stop the TeamSite Server.............................................................................................77
Check for Multiple Servers ...........................................................................................................78
Check Request Handling..............................................................................................................78
Verify the Server Mount................................................................................................................79
Locate the Installation Directory ...................................................................................................80
Review TeamSite Log Files..........................................................................................................80
WFS Log ...............................................................................................................................80
Installation Log ......................................................................................................................81
Server Log ............................................................................................................................81
Trace Log .............................................................................................................................81
Events Log ............................................................................................................................81
Workflow Log ........................................................................................................................82
Windows Event Viewer .........................................................................................................83
Monitor the Server Load...............................................................................................................83
Reconfigure iwwebd to Recognize a New IP Address..................................................................84
Contents
Manage Disk Space .................................................................................................................... 84

File Locations ....................................................................................................................... 85
Enhance File System Performance on the TeamSite Server ................................................ 87
Monitor Disk Space Usage .......................................................................................................... 88
Delete Editions ..................................................................................................................... 89
Metadata Forking ................................................................................................................. 90
Move the Content Store and Removing Old Versions .......................................................... 91
Chapter 5
Work with Branches ................................................................................................................. 93
Overview ..................................................................................................................................... 94
Control Branch Ownership and Administration ............................................................................ 94
Create Branches ......................................................................................................................... 96
Integrate Content From Different Branches ................................................................................ 97
Manage Branches ...................................................................................................................... 98
Work with Branch Properties ....................................................................................................... 99
View Branch Users and Roles .................................................................................................... 99
Chapter 6
Manage TeamSite Access.................................................................................................... 101
Access Considerations .............................................................................................................. 101
Working with Permissions.......................................................................................................... 103
Workarea Access ............................................................................................................... 109
Branch and Workarea Security .......................................................................................... 109
Default Permissions ........................................................................................................... 110
View File Permissions ........................................................................................................ 110
Share TeamSite Assets using Windows Groups ........................................................................111
Group Usage with Native Mode Active Directory ................................................................ 112
Group Usage for Larger AD Networks ................................................................................ 113
Manage Windows Groups for Best Performance ............................................................... 114
Enable the User/Group/Role Disk Cache................................................................................... 116
Disable Group Nesting ....................................................................................................... 116
Enable the ADSI Debug Flag ............................................................................................. 116
Additional Tools for Debugging .......................................................................................... 117
Operate System Group Membership ......................................................................................... 117
Change Group Ownership of Workareas ............................................................................ 118
Example ....................................................................................................................... 119
Web Server Group/UID ...................................................................................................... 119
Group Remapping .............................................................................................................. 120
Contents
Maintain the GID .................................................................................................................120

Authentication ............................................................................................................................121
Store TeamSite Users .........................................................................................................121
The user_databases.xml File ..............................................................................................121
The Password Attribute ................................................................................................124
Create a Certificate Authority Database in the cert7.db Format ..........................................125
Create a Certificate Authority Database in the cert7.db Format for Linux .....................127
Synchronize LDAP Users ...................................................................................................127
Identify LDAP Synchronization Files .............................................................................127
Modify LDAP Schemas to Store TeamSite User Interface Information .........................128
Configure TeamSite to Work Without an Anonymous Bind .................................................129
LDAP Synchronization ........................................................................................................129
Impact of Using Non-OS Users in TeamSite .......................................................................130
User Authentication ............................................................................................................131
TeamSite and PAM Configuration File Interaction ..............................................................132
The Authentication Daemon ...............................................................................................133
Domains to Use for Group Authentication ...........................................................................134
Log Users and Groups ........................................................................................................134
Configure Submit Filtering..........................................................................................................135
The submit.cfg File .............................................................................................................135
Submit Filtering Sequence ..................................................................................................138
Sample submit.cfg file .........................................................................................................138
Test and Debug Submit Filtering .........................................................................................141
RCS Macro Expansion .......................................................................................................141
Available Macros ..........................................................................................................142
Enable Macro Expansion ..............................................................................................143
Chapter 7
Set Up TagUI .............................................................................................................................. 145
TagUI Features ..........................................................................................................................146
Using TagUI Rulesets ................................................................................................................146
TagUI Form Design ....................................................................................................................147
Configure TagUI.........................................................................................................................149
Map to Rulesets ..................................................................................................................149
Adjust Server Timeout ........................................................................................................152
Tag Large Numbers of Files ...............................................................................................152
Control the Search Function ...............................................................................................153
Revert to MetaData Capture Tagging .................................................................................153
Create Rulesets ........................................................................................................................153
Contents
Merge Rulesets ........................................................................................................................ 161

Dynamic Addition of Select Box Entries ............................................................................. 163
Using FormAPI .......................................................................................................................... 163
Best Practices for using JavaScript .................................................................................... 164
Troubleshooting JavaScript ................................................................................................ 165
Integrate IDOL Taxonomy Solution............................................................................................ 165
Create a Ruleset ................................................................................................................ 165
Requirements for Designing Rule Sets ........................................................................ 167
Create a Mapping File ........................................................................................................ 168
Supported IDOL Project Types .................................................................................... 169
Use the IDOL Taxonomy Solution in the User Interface ............................................... 169
Chapter 8
Configure the TeamSite Web Daemon and Proxy Server ....................................... 171
About the TeamSite Web Daemon ............................................................................................ 172
About the Proxy Server.............................................................................................................. 172
Apply Changes to Proxy Configuration ............................................................................... 174
Configure TeamSite Web Daemon and Proxy Server Operation ............................................... 174
Resolve Relative and Absolute Paths ................................................................................ 175
Document Roots ................................................................................................................ 176
Resolve Fully Qualified URLs .................................................................................................... 178
Redirect Fully Qualified URLs.................................................................................................... 178
Configure the Proxy Server to Redirect Fully Qualified URLs ............................................. 179
Configure your Web browsers to Use the TeamSite Web Daemon .................................... 179
Redirect TeamSite Views to Different Areas ............................................................................. 181
Using iwproxy_preconnect_remap .................................................................................... 181
Using iwproxy_preconnect_redirect .................................................................................. 182
Configure TeamSite to Use Different Web Servers.................................................................... 183
Configure External Remappings ................................................................................................ 183
Using iwproxy_preconnect_remap ..................................................................................... 184
Using iwproxy_external_remap .......................................................................................... 184
Host Header Remappings ......................................................................................................... 185
Enable iwproxy Access Control ................................................................................................. 185
Configure SSI Remapping ......................................................................................................... 186
Configure Proxy Failover ........................................................................................................... 186
Debug Your Proxy Server Configuration.................................................................................... 188
Contents
Chapter 9
MediaBin Connector ............................................................................................................... 191
Configure the MediaBin Connector ...........................................................................................192
Display the MediaBin Properties Screen .............................................................................192
Edit the MediaBin Connector Properties .............................................................................193
Connect to a Legacy MediaBin Server ................................................................................195
FormsPublisher Configuration Files ...........................................................................................197
datacapture.cfg ...................................................................................................................198
Presentation Template Files ...............................................................................................200
MetaData XML Record...............................................................................................................201
attribute Metadata Elements ...............................................................................................202
Representation of Data Types ............................................................................................202
Dublin Core Metadata Elements .........................................................................................203
Custom Metadata ...............................................................................................................204
MediaBin Configuration ..............................................................................................................205
Setting Anonymous Access ................................................................................................205
Configuring MediaBin Trusted Client and LDAP Authentication ..........................................205
Troubleshooting .........................................................................................................................205
Running MediaBin Connector 1.1 and 2.0 Toolkits Simultaneously ....................................205
Import from MediaBin Requires Anonymous Access to the Transfer Directory ...................206
Update Required When Using Microsoft Internet Explorer 6.0 SP1 ....................................206
Chapter 10
Back Up TeamSite ................................................................................................................... 209
Integrate with Third-Party Backup Solutions...............................................................................209
Suggested Strategies for Incremental Backups..........................................................................211
Appendixes
Appendix A
Internationalization ..................................................................................................................215
Overview ....................................................................................................................................216
Supported Client and Server Platforms ......................................................................................216
Supported Content .....................................................................................................................217
Limitations and Assumptions......................................................................................................217
Content Stores and Character Encoding ....................................................................................218
About UTF-8 ..............................................................................................................................218
URL Commands with Multibyte Characters................................................................................218
Contents
Interface with Localized Operating Systems .............................................................................. 219

Access the Localized Interface .................................................................................................. 219
Language of the VisualPreview Tool Bar ................................................................................... 220
Run TeamSite CLTs in DOS Console Mode ............................................................................. 221
Specify File Encoding of Text Files ........................................................................................... 222
Text Editor Encodings ........................................................................................................ 223
Behavior of Netscape Navigator ......................................................................................... 223
Scenario 1 ................................................................................................................... 223
Scenario 2 ................................................................................................................... 224
Configure Netscape for Multibyte Characters ..................................................................... 224
Usage Scenarios ....................................................................................................................... 224
Scenario 1 ................................................................................................................... 225
Scenario 2 ................................................................................................................... 225
Scenario 3 ................................................................................................................... 225
Scenario 4 ................................................................................................................... 225
Scenario 5 ................................................................................................................... 226
Scenario 6 ................................................................................................................... 226
Appendix B
Specify Content Encoding.................................................................................................... 227
regex_map Defined ................................................................................................................... 228
Simple regex_map Example .............................................................................................. 228
The regex_map Format ............................................................................................................. 229
Rule Syntax ........................................................................................................................ 230
Regular Expression Syntax ................................................................................................ 230
Variables ............................................................................................................................ 231
Application Variables .......................................................................................................... 231
Intermediate Variables ....................................................................................................... 231
Interpolation of Variables and Captured Subexpressions ................................................... 232
Quoting .............................................................................................................................. 234
Strategies for Effective regex_maps .......................................................................................... 236
Internationalization and regex_maps ......................................................................................... 237
VisualPreview and file_encoding.cfg ......................................................................................... 238
Source Differencing and Merging and file_encoding.cfg ............................................................ 238
Sample file_encoding.cfg ................................................................................................... 239
Appendix C
Single Sign-On .......................................................................................................................... 241
Overview ................................................................................................................................... 242
10
Contents
Integrate SiteMinder and TeamSite with an Active Response ....................................................242

Prerequisites .......................................................................................................................243
Overview .............................................................................................................................243
Integration Procedure .........................................................................................................245
Install and Configure the SiteMinder Web Agent on the TeamSite System ..................245
Set Realms, Rules, and Responses on the SiteMinder Policy Server ..........................246
Set Environment Variables on the SiteMinder Policy Server ........................................247
Copying the Active Response Module to the SiteMinder Policy Server ........................249
Integrate SiteMinder and TeamSite Without an Active Response ..............................................249
Prerequisites .......................................................................................................................250
Overview .............................................................................................................................250
Install and Configure the SiteMinder Web Agent ..........................................................252
Configure the SiteMinder Policy Server ........................................................................253
Configure TeamSite .....................................................................................................257
Integrate an SSO Product Other than SiteMinder with TeamSite ...............................................258
Prerequisites .......................................................................................................................258
Overview .............................................................................................................................258
Install and Configuring the SSO Web Agent .................................................................260
Configure the SSO Server ............................................................................................260
Configure TeamSite .....................................................................................................260
Troubleshooting .........................................................................................................................261
Troubleshooting the SiteMinder Web Agent ........................................................................261
Failed to start the LLAWP process. Execlp failed: No such file or directory. ...............261
child pid 1234 exit signal Abort (6) .............................................................................262
Server already running. Duplicate LLAWP processes not allowed, exiting. ................262
Troubleshooting the Active Response ................................................................................263
Appendix D
Troubleshooting........................................................................................................................265
Index ..............................................................................................................................................281
11
Contents
12
Figures
Figure 1
Using TeamSite for Web site development ............................................................... 28
Figure 2
Assign-edit-approve workflow model ......................................................................... 31
Figure 3
Example of a workflow for a job................................................................................. 31
Figure 4
Connections from client computer to TeamSite server.............................................. 33
Figure 5
Connections from client computer to TeamSite server.............................................. 34
Figure 6
TeamSite file system structure .................................................................................. 35
Figure 7
How the Event Subsystem Works ............................................................................. 66
Figure 8
Registry Editor window .............................................................................................. 87
Figure 9
Expanding the directory tree of the TeamSite server ................................................ 87
Figure 10 Viewing a shared access drive .................................................................................. 88

Figure 11
Viewing the size of the iw-store ................................................................................. 89
Figure 12 New Branch screen ................................................................................................... 96

Figure 13 Manage Branches screen from the Actions menu..................................................... 98
Figure 14 TagUI screens for single file tagging ....................................................................... 147
Figure 15 TagUI screen for multiple file tagging with Description tab...................................... 148
Figure 16 Tagging multiple files .............................................................................................. 169
Figure 17 Browser access to iwwebd ...................................................................................... 172
Figure 18 Processing proxy requests through the iw.cfg file ................................................... 173
Figure 19 Local Area Network settings dialog box................................................................... 180
Figure 20 Proxy failover remap diagram.................................................................................. 187
Figure 21 SiteMinder integrated with TeamSite and Active Response.................................... 244
Figure 22 SiteMinder integrated with TeamSite without Active Response .............................. 251
Figure 23 SSO product integrated with TeamSite without Active Response ........................... 259
13
Figures
14
Tables
Table 1
TeamSite options configurable in the iw.cfg File......................................................... 41
Table 2
Functions of Configuration Files ................................................................................. 46
Table 3
Autoprivate Encodings ................................................................................................ 60
Table 4
server_locale Settings in iw.cfg................................................................................... 71
Table 5
server_locale Settings in iw.cfg................................................................................... 72
Table 6
Other files and directories controlled by [location] ...................................................... 86
Table 7
Role operations and permission checking ................................................................ 104
Table 8
Attributes for user_databases.xml file....................................................................... 123
Table 9
Vpaths and corresponding rulesets .......................................................................... 152
Table 10
MediaBin metadata elements ................................................................................... 204
Table 11
Language Encodings ................................................................................................ 220
Table 12
Code Pages for CLTs ............................................................................................... 221
Table 13
Default Encodings for Text Editors ........................................................................... 223
Table 14
XML Special Characters ........................................................................................... 235
Table 15
Realms...................................................................................................................... 246
Table 16
Rules......................................................................................................................... 246
Table 17
Response.................................................................................................................. 247
Table 18
Realm........................................................................................................................ 253
Table 19
Rules......................................................................................................................... 253
Table 20
Rules......................................................................................................................... 253
Table 21
Response.................................................................................................................. 254
Table 22
Response.................................................................................................................. 255
Table 23
Response.................................................................................................................. 255
Table 24
Response.................................................................................................................. 256
Table 25
Policy ........................................................................................................................ 256
Table 26
Troubleshooting options............................................................................................ 265
15
Tables
16
About This Document
This document is for TeamSite Administrators and Master users, Web server
administrators, and system administrators.
Documentation Updates
Conventions
Autonomy Customer Support
Contact Autonomy
Documentation Updates
The information in this document is current as of TeamSite version 7.3. The
content was last modified 08 February 2013.
You can retrieve the most current product documentation from Autonomys
Knowledge Base on the Customer Support Site.
A document in the Knowledge Base displays a version number in its name, such
as IDOL Server 7.5 Administration Guide. The version number applies to the
product that the document describes. The document may also have a revision
number in its name, such as IDOL Server 7.5 Administration Guide Revision 6.
The revision number applies to the document and indicates that there were
revisions to the document since its original release.
It is recommended that you periodically check the Knowledge Base for revisions
to documents for the products your enterprise is using.
To access Autonomy documentation
1. Go to the Autonomy Customer Support site at
https://customers.autonomy.com
2. Click Login.
17
About This Document
3. Enter the login credentials that were given to you, and then click Submit.
The Knowledge Base Search page opens.
4. In the Search box, type a search term or phrase. To browse the Knowledge
Base using a navigation tree only, leave the Search box empty.
5. Ensure the Documentation check box is selected.
6. Click Search.
Documents that match the query display in a results list.
7. To refine the results list, select one or more of the categories in the Filter By
pane. You can restrict results by
Product Group. Filters the list by product suite or division. For example,
you could retrieve documents related to the iManage, IDOL, Virage or

KeyView product suites.
Product. Filters the list by product. For example, you could retrieve
documents related to IDOL Server, Virage Videologger, or KeyView Filter.

Component. Filters the list by a products components. For example, you
could retrieve documents related to the Content or Category component in

IDOL.
Version. Filters the list by product or component version number.
Type. Filters the list by document format. For example, you could retrieve
documents in PDF or HTML format. Guides are typically provided in both

PDF and HTML format.
8. To open a document, click its title in the results list.
To download a PDF version of a guide, open the PDF version, click the Save
icon
in the PDF reader, and save the PDF to another location.
18
Conventions
Conventions
The following conventions are used in this document.
Notational Conventions
This document uses the following conventions.
Convention
Usage
Bold
User-interface elements such as a menu item or button.

For example:
Click Cancel to halt the operation.
Italics
Document titles and new terms. For example:

For more information, see the IDOL Server
Administration Guide.
An action command is a request, such as a query or
indexing instruction, sent to IDOL Server.
monospace font
File names, paths, and code. For example:

The FileSystemConnector.cfg file is installed in
C:\Program Files\FileSystemConnector\.
monospace bold
monospace italics
Data typed by the user. For example:
Type run at the command prompt.
In the User Name field, type Admin.
Replaceable strings in file paths and code. For

example:
user UserName
19
About This Document
Command-line Syntax Conventions

This document uses the following command-line syntax conventions.
Convention
Usage
[ optional ]
Brackets describe optional syntax. For example:

[ -create ]
Bars indicate either | or choices. For example:

[ option1 ] | [ option2 ]
In this example, you must choose between option1
and option2.
{ required }
Braces describe required syntax in which you have a

choice and that at least one choice is required. For
example:
{ [ option1 ] [ option2 ] }
In this example, you must choose option1, option2,
or both options.
required
Absence of braces or brackets indicates required

syntax in which there is no choice; you must type the
required syntax element.
variable
Italics specify items to be replaced by actual values. For

example:
<variable>
-merge filename1
(In some documents, angle brackets are used to denote
these items.)
...
Ellipses indicate repetition of the same pattern. For

example:
-merge filename1, filename2 [, filename3
... ]
where the ellipses specify, filename4, and so on.
The use of punctuationsuch as single and double quotes, commas, periods

indicates actual syntax; it is not part of the syntax definition.
20
Notices
This document uses the following notices:
CAUTION A caution indicates an action can result in the loss

of data.
IMPORTANT An important note provides information that is

essential to completing a task.
NOTE A note provides information that emphasizes or

supplements important points of the main text. A note supplies
information that may apply only in special casesfor example,
memory limitations, equipment configurations, or details that
apply to specific versions of the software.
TIP A tip provides additional information that makes a task

easier or more productive.

Autonomy Customer Support provides prompt and accurate support to help you
quickly and effectively resolve any issue you may encounter while using
Autonomy products. Support services include access to the Customer Support
Site (CSS) for online answers, expertise-based service by Autonomy support
engineers, and software maintenance to ensure you have the most up-to-date
technology.
To access the Customer Support Site, go to
https://customers.autonomy.com
The Customer Support Site includes:
Knowledge Base: The CSS contains an extensive library of end user

documentation, FAQs, and technical articles that is easy to navigate and
search.
21
About This Document
Case Center: The Case Center is a central location to create, monitor, and
manage all your cases that are open with technical support.
Download Center: Products and product updates can be downloaded and

requested from the Download Center.
Resource Center: Other helpful resources appropriate for your product.
To contact Autonomy Customer Support by e-mail or phone, go to

http://www.autonomy.com/content/Services/Support/index.en.html
Contact Autonomy
For general information about Autonomy, contact one of the following locations:
22
Europe and Worldwide
North and South America
E-mail: autonomy@autonomy.com
E-mail: autonomy@autonomy.com
Telephone: +44 (0) 1223 448 000

Fax: +44 (0) 1223 448 001
Telephone: 1 415 243 9955

Fax: 1 415 243 9984
Autonomy Corporation plc

Cambridge Business Park
Cowley Rd
Cambridge CB4 0WZ
United Kingdom
Autonomy, Inc.
One Market Plaza
Spear Tower, Suite 1900
San Francisco CA 94105
USA
PART 1
Introduction
This section introduces important TeamSite administration

concepts.
TeamSite Overview
Configuration File Overview
Part 1 Introduction
24
CHAPTER 1
TeamSite Overview
This chapter introduces three major TeamSite concepts and concludes with a
description of the TeamSite system architecture.
It includes the following topics:
TeamSite Elements
User Roles
TeamSite Workflow
TeamSite Architecture
TeamSite Elements
The following sections describe some common TeamSite concepts that you
should be familiar with before beginning to configure TeamSite.
Content Stores
The Content Store is a large directory created by the TeamSite installation
program that contains TeamSite files and metadata. By default, the Content Store
is located in Unix:/iw-store; Windows:C:\iw-store.
TeamSite supports as many as eight Content Stores per TeamSite server (the first
is created automatically by the installation program, and the others are created as
needed by the TeamSite system administrator.
25
Chapter 1 TeamSite Overview
Branches
TeamSite provides branches for different paths of development for content.
Branches can be related to each other (for example, alternate language versions
of the same Web site) or they may be completely independent. Typically, each
branch contains all the content for a Web site or a major section of it (such as a
department), or a collection of related content (such as the program files for a
software application or the image and text files for a book). Branches can be
indexed and searched.
A single branch contains archived copies of its content as editions, a staging area
for content integration, and individual workareas where users may develop
content without disturbing one another. Branches can also contain subbranches,
so that teams may keep alternate paths of development separate from each other.
Content can be easily shared and synchronized across branches and
subbranches. Users may work on one branch or on several, and the number of
branches on a system is not limited.
Branches facilitate distributed workflow because they allow separate teams to
work independently on different projects. Because all branches are located on the
same TeamSite server, it is easy for one team to incorporate the work of another
into their project.
Workareas
Each workarea contains a virtual copy of all related content, which may be
modified in any way without affecting the work of other contributors. Users who
have access to a workarea may modify files within that workarea and view their
changes within the context of all related content before integrating their work with
that of other contributors. Users can lock files in each workarea, eliminating the
possibility of conflicting edits.
All changes made to files in a workarea are kept completely separate from other
workareas and the staging area until the user chooses to submit his changes to
the staging area. Within a workarea, users may add, edit, or delete files, or revert
to older versions of files without affecting other users.
Staging Areas
Each branch contains one staging area where contributors incorporate their
changes with the work of others. Users submit files from their workareas to the
staging area to integrate their work with other contributions, and test the integrity
of the resulting content. Because the staging area is an integrated component of
the system, conflicts are easily identified and different versions of the same file
can be merged, rather than overwritten.
26
TeamSite Elements
Editions
Editions are read-only snapshots of a branch, taken at sequential points in its
development. Contributors with appropriate permissions can create new editions
any time they feel their work is well integrated, or any time they want to create an
updated snapshot of all content for reference or deployment to a production
server. For Web site content development, each edition is a fully functional
version of the Web site, so that users can see the development of the Web site
over time and compare it with current work.
TeamSite branches contain private workareas, which contain complete virtual
copies of the Web site; staging areas, where contributors integrate their work; and
editions, which are read-only snapshots of the Web site at various points in its
development. Each area contains a virtual copy of the entire Web site. Content is
submitted from workareas to the staging area, and the staging area is then
published as an edition. Older editions are available for reference. Figure 1 on
page 28 illustrates the use of TeamSite for Web site development.
27
Figure 1 Using TeamSite for Web site development
User Roles
TeamSite ships with out-of-the-box user types, each with specific access
permissions and optimized user interfaces. These user types are known as roles.
The roles are:
28
Administrator
Author
Editor
Master
Reviewer
User Roles
Site Manager
WorkflowUser
WorkflowAdmin
These default roles are summarized in the following sections. Each installation
can create or modify roles to meet the needs of your organization.
Reviewer
Reviewers generally review work done by others. They may have approval
authority. They can browse workareas and review files and forms, search for
content, and work with tasks. Reviewers usually access TeamSite from the
browser-based ContentCenter Standard interface.
Author
Authors are primary content creators. All work done by Authors goes through an
explicit approval step. They can receive assignments from Editors, which are
displayed in task lists when Authors log in to TeamSite. Authors usually access
TeamSite from the browser-based ContentCenter Standard interface and do not
need to be sophisticated computer users.
In order to test their work, Authors have full access to the content in their Editors
workareas, but do not need to concern themselves with the larger structure and
functionality of TeamSite. The Author role is appropriate for non-technical users or
for more technical contributors who do not need access to extended TeamSite
functionality, such as advanced version management features.
Editor
Editors own workareas. They create and edit content, just as Authors do, but they
are primarily responsible for managing the development taking place within their
workareas. This includes assigning files to Authors and submitting completed
content to the staging area, and it may include creating editions.
Editors have access to specialized TeamSite content and workflow management
functions. Editors are generally managerial users, who primarily supervise the
work of Authors, or self-managing power users, who need extended TeamSite
functionality to manage their own content.
Administrator
Administrators own branches. They have all the abilities of Editors, but they are
primarily responsible for the content and functioning of their branch.
Administrators can manage project workflow by creating new workareas for
29
Editors and groups and by creating subbranches of their own branch to explore
separate paths of development. They can assign TeamSite users to groups and
assign users to roles on the branch.
An Administrator is the supervisor of the project being developed on his branch.
Master
Master users own the entire TeamSite Content Server. They can create new
stores and perform all the functions of Editors and Administrators on any branch.
They can create or modify roles. The Master user is generally involved in the
installation of TeamSite and can reconfigure TeamSite on a system-wide basis.
Users with the Master role have access to the Administration Console within
ContentCenter Professional. This allows them to add operating system users to
TeamSite, assign groups, create and edit roles, and perform other TeamSite
tasks. Most installations only have a few Master users.
WorkflowUser
By default, all TeamSite users should be able to use workflow models. To achieve
this, the workflowModels branch of the iwadmin store is shared for
iwEveryone with role as WorkflowUser. This role has the minimum privileges
required to instantiate a workflow.
WorkflowAdmin
The WorkflowAdmin role has privileges to design workflows using Interwoven
Workflow Modeler and upload them to TeamSite. They have privileges to manage,
configure, and debug the workflow models. Users who can perform these
operations include workflow developers or TeamSite administrators.
TeamSite Workflow
A workflow model is a general workflow configuration that can be used repeatedly.
Each workflow model describes a process that may include user tasks and a wide
variety of automated tasks. Workflow models are configured by the system
administrator or by the Client Services organization.
For more information about configuring different workflow models, consult the
TeamSite Workflow Developers Guide.
Figure 2 on page 31 is a diagram of a very simple assign-edit-approve workflow
model. Email is sent to the participants at every stage of the process, and some
automated tasks are performed at the end.
30
TeamSite Workflow
Figure 2 Assign-edit-approve workflow model

Editor
initiates job
Task:
Email sent
to Author
Task:
Author
edits files
Task:
Email sent
to Author
Task:
Email sent
to Editor
Reject Task: Approve

Editor
Task:
Email sent
reviews
to Author
Authors
work
Task:
Content
submitted
to the
staging area
Task:
Automated
deployment
Jobs
A job is a set of interdependent tasks. One example of a TeamSite job would be
the set of tasks needed to prepare a new section in a marketing Web site to
support a new product launch.
Each job is a specific instance of a workflow model. When a job is created, the job
creator must supply all the specific information for that job. For example, the
workflow model in Figure 2 on page 31 might be used to create the job in Figure 3
on page 31.
Figure 3 Example of a workflow for a job
Andre
initiates job
Task:
Email sent
to Pat
Task:
Pat edits
index.html
and
banner.gif
Task:
Email sent
to Pat
Task:
Email sent
to Andre
Reject Task: Approve

Andre
Task:
Email sent
reviews
to Pat
Pats
work
Task:
Content
submitted
to the
staging area
Task:
Automated
deployment
Because jobs follow predefined workflow models, tasks cannot be added to or

removed from individual jobs, although not every possible task may actually take
place for a given job.
31
Tasks
A task is a unit of work performed by a single user or process. Each task in a job is
associated with a particular TeamSite workarea and carries a set of files with it.
The user or process owning a task can modify, add files to, or remove files from
the task.
Tasks have two possible states: active and inactive. A task becomes active when
its predecessor task signals it to do so (predecessor tasks and conditions for
activation are all configured as part of the workflow model). Once the task has
been activated, users or external programs can work on it. For example, once a
user task has been activated, the user can work on the files contained in the task.
Once an external task has been activated, the appropriate external program can
run on the files contained in the task. Inactive tasks are tasks that have been
completed or that have not been activated yet.
The TeamSite file system is composed of the TeamSite Content Server and
device driver kernel module, the TeamSite Content Store of files and metadata, a
suite of command-line tools, TeamSite CGI, proxy servers for access through the
TeamSite browser-based user interfaces (ContentCenter), and file system mounts
for access through the file system interface.
The TeamSite file system is the core of the TeamSite system, where detailed
information about the Web site, the Web assets, Web asset metadata, the
production process and the users is stored. The TeamSite file system collects and
maintains metadata on TeamSite files, directories, and areas, and allows
TeamSite to process and present information according to who is asking for the
information, and under what conditions. By using an object-oriented design within
a file system architecture, TeamSite combines extensive metadata tagging with
open access and file system performance for Web content.
The client computer connects to the TeamSite server in several ways. Requests
from the browser interfaces or Local File Manager are routed through the
TeamSite Web daemon, which allows consistent views of TeamSite areas. The
double proxy server redirects hard-coded links within the Web site. Requests
through the file system interface (TeamSite shared drive) (NFS mount/Samba)
and command-line tools, which do not go through the web server, are not routed
through a proxy server.
32
Figure 4 Connections from client computer to TeamSite server

TeamSite Content Server
Client Computer
TeamSite File System

TeamSite
Content
Store
command
line
Command
Line Tools
RPC
CSSDK
Soap
Server
Web
Daemon
(port 80)
Servlet
Engine
TeamSite
Server
(iwserver)
CSSDK
TeamSite
Shared
Drive
Content
Web
Server
(port 81)
Browser
Interfaces
Local File
Manager
Content
Services
Applications
iwproxy
Workarea
Virtualization
(port 1080)
Local File
Manager
Device
Driver
SMB
Network
Share
33
Figure 5 Connections from client computer to TeamSite server

TeamSite Content Server
Client Computer
TeamSite File System

command
line
Command
Line Tools
TeamSite
Content
Stores
TeamSite
RPC
Content
Server
(iwserver)
CSSDK
Soap
Server
Web
Daemon
Servlet
Engine
(port 80)
Browser
Interfaces
Local File
Manager
CSSDK
TeamSite
kernel
file system
driver
/.iwmnt
File system
mount
NFS
Content
Web
Server
(port 81)
iwproxy
Workarea
Virtualization
(port 1080)
/iwmnt
File system
mount
Content
Services
Applications
Local File
Manager
NFS mount
Samba
Understanding the TeamSite File System

The TeamSite file system mount contains a file system view of all the Content
Stores, branches, workareas, staging areas, and editions on the TeamSite server.
TeamSite areas do not contain physical copies of the collection of content, but
rather pointers to the files contained in the collection of content. The only physical
files contained within TeamSite areas are the files that have actually been
modified in those areas. That is, the only files actually contained in a workarea are
those files that have been modified in that workarea but not yet submitted to the
staging area. The only files contained in the staging area are the files that have
been submitted since it was last published. The only files in an edition are the files
that have changed since the previous edition was published.
34
A simple TeamSite file system structure is shown in Figure 6:

Figure 6 TeamSite file system structure
default or
store name*
main
WORKAREA
STAGING
admin
development
EDITION
INITIAL
WORKAREA
Legend:
andre
pat
STAGING
chris
EDITION
INITIAL ed_0001
System-created
User-created
* Store name is user-assigned in
MultiStore implementations
Each branch contains three system-generated directories:
WORKAREAContains an individual workarea for each contributor on the

branch.
STAGINGStaging area common to all workareas on the branch.
EDITIONAll published editions on the branch.
It may also contain directories that hold subbranches. In the example above, the
main branch (main) contains one workarea (admin), a staging area, an initial
edition, and a subbranch (development). The subbranch contains three
user-defined workareas (andre, pat, and chris), a staging area, and two
editions, one of which is user-generated (ed_0001).
Although many of the files contained within this file system structure are virtual,
they can be treated as if they were real. They appear to exist even when you run
link checkers and scripts against them. However, staging areas, editions, and
container directories (for example, WORKAREA, EDITION, main, or
development) are all read-only. Only workareas can be written to.
35
NFS Exports
Linux only
Exporting the TeamSite file system for NFS clients requires two steps:
1. The TeamSite file system entry in /etc/exports must use the fsid export
option.
2. The TeamSite file system must be unexported prior to stopping TeamSite.
Failure to specify the fsid option in /etc/exports causes NFS client mount
requests to fail with Permission denied errors. Failure to unexport the TeamSite
file system prevents the TeamSite file system from unmounting, which in turn
prevents a clean shutdown of TeamSite. An alternative to unexporting the
TeamSite file system is to stop the NFS services.
The following is an example entry in the /etc/exports file for the TeamSite file
system (see the UNIX man exports page for more information):
/iwmnt/default *(rw,fsid=1000)
The following command shows how to unexport just the TeamSite file system (see
the UNIX man exportfs page for more information):
# exportfs -u *:/iwmnt/default
The following command can be used to stop NFS services:

# /etc/init.d/nfs stop
Specify VPaths
The path describing a workarea is its workarea VPath. The path describing a files
location within an area is its area relative path. Combined together, a files full
VPath describes its precise location in the file system.
A vpath (version path) is a path within the TeamSite content repository,
specified as one of the following:
\store\branch+\EDITION\edition
\store\branch+\WORKAREA\area\directory*\file
\store\branch+\STAGING\directory*\file
where + indicates 1 or more; * indicates 0 or more, and a path may omit the
elements below it in order to specify just a directory, area, branch, or store.
A branch may not be named EDITION, WORKAREA, or STAGING.
STAGING is a special area that every branch has. Thus, an area is either a
workarea, specified as WORKAREA\area, or STAGING.
36
The following are all valid vpath specifications:
\default, a store.
\default\main, the branch main.
\default\main\pubs, the (sub)branch pubs.
\default\main\pubs\EDITION\initial, the edition initial.
\default\main\pubs\STAGING, the staging area for the pubs branch.
\default\main\pubs\WORKAREA\uitk, the workarea uitk.
\default\main\pubs\WORKAREA\uitk\guide\examples, a directory.
\default\main\pubs\WORKAREA\uitk\guide\examples/example1,
a file.
\default\main\pubs\WORKAREA\uitk\README, a file directly under a

workarea.
The path delimiter can be either / or \ when specifying a TeamSite path, but
will be output as: / (Unix) or \ (Windows).
Optionally, a vpath can include the server name by prepending //servername
to it, though doing so is generally not needed.
The maximum length of a vpath (including host name, branch, workarea, and
folders) is currently limited to about 600 bytes.The limitation is imposed by the
maximum length of a GET URL command supported by a browser. The 600-byte
requirement provides 30 folder levels with average 20-byte folder names.
For multi-byte languages (Chinese, Japanese, Korean), the maximum length is
reduced by a factor of 9 to about 67 bytes. Each CJK character, when used as
part of an URL, must be encoded. The encoding for UTF-8 expands each
character to a 9-byte sequence of the form %xx%xx%xx where xx is the
hexadecimal UTF-8 code.
Related Documentation
For information and preliminary configuration information, consult the TeamSite
Installation Guide.
For more information about configuring different workflow models, consult the
TeamSite Workflow Developers Guide.
For more information on specifying a vpath, see the TeamSite Command-Line
Tools Guide.
37
38
CHAPTER 2
Configuration File Overview

Most of the settings for the TeamSite server are configured in the main
configuration file, iw-home\etc\iw.cfg (default location). Additional settings
are configured in a variety of additional files.
Configuration and customization of the ContentCenter interfaces is done through
the UI Toolkit. Refer to the TeamSite User Interface Customization Guide for
details.
This chapter includes the following topics:
The iw.cfg File
Additional Configuration Files
The iw.cfg File

The TeamSite iw.cfg configuration file is divided into sections that display in
square brackets (the iwwebd section is shown in the following example). The
configurable parameter (http_port) is to the left of the equal sign, and the
current setting (80) is to the right; for example:
[iwwebd]
http_port=80
To edit any of the settings

1. Open the configuration file in a text editor.
<ProductNameFull> <DocumentType>
39
Chapter 2 Configuration File Overview
2. Change the current setting.

You cannot have a space before or after the equal sign.
3. Save and close the file.
Changes to most of these configuration settings take effect within a few minutes
(although for options that affect a user interface, users may need to clear their
browser cache in order to see the changes). For these settings to take immediate
effect, use the iwreset.exe command-line tool (CLT). Configuration options
that require TeamSite to be restarted in order to take effect are noted where
appropriate.
NOTE If section headings are duplicated in the iw.cfg file, some or all of
the values given for the parameters in one copy of the section will be
ignored. Verify that a section heading only appears once in your iw.cfg file.
You can also edit the iw.cfg file using the Configuration tab in the
Administration Console. Refer to the TeamSite User Interface Administration
Guide for information.
Location of iw.cfg
If iw.cfg does not exist in the default location, TeamSite looks for it in the
following locations, in the following order:
Windows:
iw-home\local\etc\iw.cfg
iw-home\etc\iw.cfg
HKEY_LOCAL_MACHINE\Software\Interwoven\TeamSite\
iw-config (registry key)
Unix:
/etc/iw.cfg
iw-home/config/iw.cfg
iw-home/local/etc/iw.cfg
iw-home/etc/iw.cfg
If iw.cfg is not found in any of these places, TeamSite assumes the default
values for iw.cfg settings.
40
The iw.cfg File
The iw.cfg File Options

Table 1 describes the configurable options in iw.cfg, lists the option or section
name, and identifies the section from this guide that describes the option.
Table 1 TeamSite options configurable in the iw.cfg File
Function
iw.cfg option
Page
Enabling/disabling
VisualPreview
[iwproxy_smartcontextedit_all
owed]
Enable and Disable

VisualPreview on page 52
Windows: Configuring
domain lists in the login
screen
domain_list
Configure Domain Lists in the

Login Screen on page 52
Configuring email settings
maildomain, mailserver,
use_mapping_file,
email_mapping_file,
debug_output
Configure Email Settings on

page 53
Specifying valid domains to

redirect ContentCenter users
from a public URL
valid_domains
Specify Valid Domains on

page 53
Configuring UI functionality
Configuring server functionality

Controlling modification time
old_mod_times
Control Modification Times

on page 54
Modifying extended attributes
force_EA_mod_times
Modify Extended Attributes

on page 55
Setting the encoding of

iw.cfg
encoding
Specify the Encoding of the

iw.cfg File on page 55
Configuring the Web daemon
host, http_port, https_port,

default_protocol
Configure the Web Daemon

on page 56
Configuring the servlet engine
servlet_port
Change the Servlet Engine

on page 56
Setting the main branch

locking model
main_lock_model
Set Locking Models on

page 56
Controlling locked file

submission
only_lock_owner_creator_submi
ts
Locked File Submission on

page 58
Controlling behavior of
Mandatory Write and Optional
Write locking
lockmodel_compatibility
Locked File Submission on

page 58
41
Table 1 TeamSite options configurable in the iw.cfg File (continued)

Function
iw.cfg option
Page
Specifying the number of

versions to check for the
common ancestor of
compared files.
compare_search_limit
Compare Files on page 58
Specifying the number of

events logged in the submit
and update logs
event_log_size
Submit and Update Logs on

page 59
Setting the port number for

the iwutild service
utild_ext_tasks_portnum
Working with the Utility

Service on page 61
Unix: Running iwutild as

non-root user
iwutild_runas_root
Run as Non-Root User on

page 64
Enabling the Event

Subsystem
ew_enable
Enable the Event Subsystem

on page 65
Setting the default size of the

event log file
ew_rollover_threshhold

on page 65
Configuring server performance

Setting cache size
cachesize
Cache Size on page 68
Windows: Controlling
impersonation
disable_ext_task_impersonation,
impersonate_without_password
External Task Impersonation

on page 69
Setting throughput monitors
thruputmonitoring,
thruputmonitorx
Throughput Monitors on
page 69
Detecting low disk space and

inodes
disklow_mybtes,
disklowpercent,
disklow_knodes (Unix)
Detect Low Disk Space and

Inode Count on page 70
Configuring the TeamSite

server locale
server_locale
Configure the TeamSite

Server Locale on page 70
Setting TeamSite file

locations
[locations]
File Locations on page 85
Setting FormsPublisher
default directory
data_root
Identify the Templating

Directory on page 73
Setting number of previews
preview_history_limit
Maintain Preview Files on

page 73
Specifying directory for

preview files
preview_system_directory
Maintain Preview Files on

page 73
Configuring FormsPublisher
42
The iw.cfg File

Function
Formatting data record
printing
iw.cfg option
Page
pretty_print_dcrs
Control Printing of Data

Records on page 74
Configuring TeamSite access

Identifying default OS group
iwglobal_group
Specifying the default role for

the owner of a branch
branch_owner_role
Control Branch Ownership

and Administration on
page 94
Specifying the role or roles

that can administer branches
admin_roles

page 94
Windows: Specifying a
secondary master user
secondary_admin_account

page 94
Changing branch owner and

group
main_owner, main_group

page 94
Setting branch and workarea

security
branch_security,
workarea_security
Branch and Workarea

Security on page 109
Setting default permissions
branch_default_perm, Unix:
workarea_default_perm,
file_default_perm,
directory_default_perm
Default Permissions on
page 110
Windows: Using Domain

Local Groups to share
workareas
domain_local_groups
Share TeamSite Assets using

Windows Groups on
page 111
Windows: Using the Active

Directory System Interface
use_adsi, debug_adsi
Share TeamSite Assets using

Windows Groups on
page 111
Windows: Enabling user/

group/role disk cache
enable_user_group_disk_cache
Enable the User/Group/Role

Disk Cache on page 116
Windows: Specifying groups

for Active Directories
windows_groups_for_users,
windows_groups_for_sharing,
include_nested_groups
Group Usage for Larger AD

Networks on page 113
Setting the webserver

(Windows)group/(Unix)UID
(Unix) webserver_uid/
(Windows) webserver_group
Web Server Group/UID on

page 119
43

Function
iw.cfg option
Page
Managing permissions on the

workarea
mask_workarea_access
Authentication on page 121
Unix: Configuring group

remapping
map_secondary_to_primary_gid
Group Remapping on
page 120
Unix: Maintain gid
honor_setgid,
honor_setgid_on_rename
Maintain the GID on

page 120
Unix: Specifying information

for iwldapsync updates.
ldapcache_thread_delay,
log_ldap_sync, ldap_sync_retry
Synchronize LDAP Users on

page 127
Unix: Specifying the

frequency of updating the
operating system users cache
enumerate_os_users_thread_del
ay
LDAP Synchronization on
page 129
Unix: Check credentials in an

external source.
password_file
User Authentication on
page 131
Unix: User authentication
authenticate_by
User Authentication on
page 131
Unix: PAM Configuration
pam_service, pam_do_acct_mgmt
TeamSite and PAM

Configuration File Interaction
on page 132
Windows: Configuring which

domains to use for group
authentication
domain_list
Domains to Use for Group

Authentication on page 134
Windows: Configuring user

and group logging
show_user_list
Log Users and Groups on

page 134
debug_event_handler
Test and Debug Submit

Filtering on page 141
Configuring submit filtering

Specifying debug submit
handling
Configuring the TeamSite proxy server
44
Configuring proxy server

operation
[iwproxy]
Configure TeamSite Web

Daemon and Proxy Server
Operation on page 174
Setting document roots
[iwproxy_remap]
Document Roots on
page 176
Resolving fully-qualified
URLs
[iwproxy_fullproxy_redirect]
Resolve Fully Qualified

URLs on page 178
The iw.cfg File

Function
iw.cfg option
Page
Redirecting TeamSite views

to different areas
[iwproxy_preconnect_remap]
Redirect TeamSite Views to

Different Areas on page 181
Configuring TeamSite to use

different Web servers
[iwproxy_preconect_remap]
Configuring external
remappings
[iwproxy_external_remap]
Configure External
Remappings on page 183
Setting host header

remappings
[iwproxy_hostheader_remap]
Host Header Remappings on

page 185
Enabling iwproxy Access

Control
[iwproxy_access_control_enabl
ed]
Enable iwproxy Access

Control on page 185
Configuring SSI remappings
[iwproxy_plugin_remap]
Configure SSI Remapping

on page 186
Configuring proxy failover
[iwproxy_failover_remap]
Configure Proxy Failover on

page 186
store_directory_store-name,
store_comment_store-name
Enabling query on workflow

events
delete_jobs_on_completion
**
Controlling adding files to

command line of external task
command callouts
external_task_add_filelist
**
Controlling nesting depth
wftask_nesting_depth_allowed
**
Controlling external task

retries
external_task_retry_wait
**
Checking for locking and

others conflicts before submit
presubmit_check
**
Unix: Preventing external

tasks from being owned by
the root user
external_task_root_allowed
**
[iwproxy_preconnect_redirect]
Configure TeamSite to Use

Different Web Servers on
page 183
Identifying Content Stores

Defining content stores
Configuring workflows
45

Function
iw.cfg option
Page
Controlling jobs being

assigned to users without
access to files
task_areavpath_file_access_ch
eck
**
Controlling whether files are

locked when creating jobs
and tasks
permit_add_locked_files_to_
locking_tasks
**
* Refer to the TeamSite Installation Guide for information.

** Refer to the TeamSite Workflow Developers Guide for information.

The following files contain information about your TeamSite server configuration:
Table 2 Functions of Configuration Files
46
Configuration File
Function
Unix: /etc/defaultiwhome
Describes the location of the TeamSite application

software. The default location is /usr/iw-home.
Unix: /etc/defaultiwstore
Describes the location of the TeamSite Content Store

directory. The default location is /usr/iw-store.
Unix: /etc/defaultiwmount
Describes the location of the TeamSite virtual mount point.

The default location is /iwmnt.
Unix: /etc/defaultiwlog
Describes the location of the iwserver.log file. The

default location is /var/adm/iwserver.log.
Unix: /etc/defaultiwelog
Describes the location of the iwevents.log file. The

default location is /var/adm/iwevents.log.
Unix: /etc/defaultiwtrace
Describes the location of the iwtrace.log file. The

default location is /var/adm/iwtrace.log.
iw-home\local\config\submit.cfg
Specifies all file permissions that are automatically

changed at submit time.
iw-home\local\config\
autoprivate.cfg
Specifies what types of files are automatically marked

private.
Table 2 Functions of Configuration Files (continued)

Configuration File
Function
file_encoding.cfg
Contains rules that determine the character encoding of

the contents of files that do not specify their encoding. See
Specify Content Encoding on page 227 for information
about creating these rules.
templating.cfg
Specifies the forms that are used in which TeamSite areas

and how the forms map to presentation templates as well
as setting form display options.
iw-home\conf\roles\tsusers.xml
Contains information on all TeamSite users.
iw-home\conf\roles\
user_databases.xml
Identifies the databases that contain user information.
iw-home\conf\roles\roles.xml
Contains information on operations performed by each

role, as set through the Edit Roles screen.
iw-home\conf\tsgroups.xml
Contains information on TeamSite groups.
iwsearch-home\etc\
search.properties
Configures the index server and search server.
iwsearch-home\etc\branches.cfg
Lists the branches to be indexed by the index server.
iwsearch-home\etc\FieldMapping.xml
Defines extended attributes and templating attributes to be

indexed.
iw-home\tsreport\conf\
spring-config.xml
Configures the EAs to be used by TeamSite ReportCenter.
iw-home\httpd\webapps\
eventsubsystem\
WEB-INF\iw_bridge_cfg.xml
Provides additional Event Subsystem configuration.
iw-home\etc\iwutild.cfg
Configures commands for the utility service.
datacapture.cfg
Defines rule sets for capturing metadata or forms.
metadata-rules.cfg
Provides information on mapping vpaths to data capture

rules.
47
48
PART 2
Administrative Tasks
This section describes the main administrative tasks.
Configure the TeamSite Server
Manage the TeamSite Server
Work with Branches
Manage TeamSite Access
Set Up TagUI
Configure the TeamSite Web Daemon and Proxy Server
MediaBin Connector
Back Up TeamSite
Part 2 Administrative Tasks
50
CHAPTER 3
Configure the TeamSite

Server
This chapter describes how to configure the TeamSite Server.
Configure User Interface Functionality
Configure Server Functionality
Working with the Utility Service
Configure Server Performance
Configure the TeamSite Server Locale
Configure FormsPublisher
TeamSite Embedded Failsafe

The following sections describe the configuration settings that enable you to
customize the functionality displayed in the user interfaces.
51
Chapter 3 Configure the TeamSite Server
Enable and Disable VisualPreview

You can selectively enable or disable VisualPreview for different workareas or files
by adding lines to the [iwproxy_smartcontextedit_allowed] section of
iw.cfg. If this section does not exist or contains no entries, VisualPreview is
enabled by default.
The [iwproxy_smartcontextedit_allowed] section begins with one
_default line, which specifies whether VisualPreview is turned on or off in any
area or for any file not otherwise specified. This line is then followed by any
number of _regex lines. Each _regex line uses a case-insensitive regular
expression to specify areas or files, and then specifies whether VisualPreview is
enabled or disabled for the specified items. A _regex line has the following
case-insensitive syntax:
_regex=regular-expression=yes|no
Lines in the [iwproxy_smartcontextedit_allowed] section are

order-dependent. In the following example, the _default=yes line turns
VisualPreview on for all files managed in TeamSite. The first regex line explicitly
turns it on for all files in all of user32s workareas on all branches. The second
regex line turns VisualPreview off for all CGI files. But because the line turning
VisualPreview on for user32s workareas comes first, user32 can use
VisualPreview for CGI files in their workarea.
[iwproxy_smartcontextedit_allowed]
_default=yes
_regex=(.*)/WORKAREA/user32/.*=yes
_regex=\.cgi(\?.*)?$=no
Configure Domain Lists in the Login Screen

Windows:
The domain_list parameter is a comma-separated list of domains that defines
the options that display in the Domain field of the TeamSite login screen. It is
located in the [iwcgi] section of iw.cfg.
If the [iwcgi] section of iw.cfg does not contain this line, add it as follows:
[iwcgi]
domain_list=This Domain,That Domain,The Other Domain
52
You can include any number of domains in this list.

If your [iwcgi] section does not contain a domain_list, domains are
automatically detected and displayed.
Domains are listed in alphabetical order, not the order listed in iw.cfg.
Do not confuse this line with the domain_list line in the [iwserver]
section of iw.cfg.
Configure Email Settings

The TeamSite Assign feature sends email to the recipient of a task. The following
settings in the [iwsend_mail] section of iw.cfg enable you to configure how
this email is sent:
maildomain=domain.topleveldomain
Specifies the domain (for example, maildomain=Autonomy.com)
mailserver=<your mail server domain>

Specifies the mail server to use (for example, mailserver=mailbg01).
use_mapping_file=false|true
Optional entry that specifies whether or not to use a mapping file to configure
individual email addresses or aliases.
email_mapping_file=path_to_file
Optional entry that specifies the location of the mapping file to use (a sample
file is located in <iw-home>/local/config/wft/email_map.cfg).
debug_output=path_to_file
An optional entry that specifies that debug output will be sent to the file
location indicated.
Specify Valid Domains

When ContentCenter users go to a public URL and then return through a
done_page parameter, you can specify the valid domains to which users can be
redirected. This prevents users from being maliciously directed to a harmful
domain.
53
Use the valid_domains setting to provide a comma-separated list of valid

domains for URLs in TeamSite ContentCenter. By default, the TeamSite server
host name, domain and IP address are automatically included and do not have to
be specified here.
[teamsite_servlet_ui]
valid_domains=domain,domain,domain

The following sections describe the configuration settings that determine the
TeamSite server functionality.
Control Modification Times

The old_mod_times setting controls what value is returned for the modification
time of a file through the file system interface.
[iwserver]
old_mod_times=true
By default, old_mod_times is set to true, and the modification time of a file is

the time a user last changed the file's contents. Submitting a file to the staging
area or updating it into your workarea through Get Latest does not affect the
modification time; the modification time will be the same as the modification time
of the source file. If old_mod_times=false, the modification time of a file is the
later of the time (1) a user last changed its contents and (2) the time the file was
updated into the workarea (with get-latest, copy-to-area, or iwupdate operations)
or submitted if it is a file in the staging area or an edition.
This distinction is important when you are using TeamSite for SCM. A lot of build
tools, such as UNIX make, rely on timestamps to determine whether it needs to
regenerate object files. They typically compare the modification time of the source
file with the modification time of the corresponding object file and decide to rebuild
the object file only if the source file has a later modification date. If you use such a
build tool out of a TeamSite workarea with old_mod_times=true (the default),
you could have problems if your workarea is updated before a build.
For example: You run make to recompile file1.c in your workarea. This
generates object file file1.o, with the current time as its modification time.
However, yesterday another user submitted another version of file1.c, but you
did not update your workarea before running make. This newer version of file.c
has a modification time from yesterday (when it was modified before being
submitted). If you now update your workarea, you will get the new version of
file1.c, but its modification time would still be the time from yesterday. By
default, with old_mod_times=yes, the modification time of a file has no
54
correlation to the time you update your workarea. If you run make again, it would
fail to recompile the new version of file1.c, because the modification time of
file1.o is later than the modification time of the newer file1.c. This can be
resolved by setting old_mod_times=false. The modification time of file1.c
would then show in your workarea with the time when you did the get-latest
procedure, and make would know to regenerate the object file.
The old_mod_times setting only affects the modification time displayed through
the file system interface and not through ContentCenter. The modification time of
a file in a user interface is always the time the contents changed.
Modify Extended Attributes

Normally when extended attributes (EAs) are modified, the content modification
timestamp of the file is not updated (although there is an attribute modification
timestamp that is updated). This is the default and is equivalent to setting false
for this option.
You can set up TeamSite so that the content modification timestamp is updated
whenever the EAs are modified using the force_EA_mod_times option in the
iw.cfg file.
[iwserver]
force_EA_mod_times=true
Specify the Encoding of the iw.cfg File

To facilitate the internationalization of TeamSite, you have the ability to use text
editors that save the iw.cfg file in various encodings. The encoding setting in
the first section of the iw.cfg file declares the encoding of the iw.cfg file itself.
The default setting is ascii.
To change the encoding of the iw.cfg file, add the following lines to the
beginning of the file:
[iwcfg]
encoding=encoding_type
where encoding_type is one of the following:
ascii (default setting)
cp1252
euc-jp
ISO-8859-1
shift_jis
utf-8
55
NOTE This must be the first section in the iw.cfg fileno

other entry can precede it.
Configure the Web Daemon

To set Web daemon defaults, edit the [iwwebd] values in the iw.cfg file:
[iwwebd]
host=hostname.domain
http_port=80
https_port=443
default_protocol=http
The default_protocol setting is used by the following scripts when TeamSite

generates URLs:
iwsend_servlet_mail.ipl scriptuses it to embed URLs into the email

messages it sends. Set this to default_protocol=https to have the email with
the https prefix for the task URL after running a workflow.
<iwov_webdesk_url> presentation template taguses it when generating

hyperlinks to the TeamSite server.
Set this to default_protocol=https for email messages

For more settings in [iwwebd], see Configure the TeamSite Web Daemon and
Proxy Server on page 171
Change the Servlet Engine

By default, the servlet port is set to 8080. To change this setting, edit the
servlet_port value in the [teamsite_servlet_ui] section of the iw.cfg
file.
[teamsite_servlet_ui]
servlet_port=8080
Set Locking Models

Locking prevents users in other workareas on the branch from editing or
submitting a file that is locked. TeamSite supports three types of file locking:
56
Submit. Enables users to ensure that their changes are submitted before
others can submit theirs. When a file is locked, users in different workareas
can edit their version of the file, but cannot submit it until the owner of the lock
submits his work or manually releases the lock. This option is selected by
default and is well-suited for environments where parallel development is

desired.
Mandatory Write. Ensures that only one user can edit a file at a given time.
Users must lock files while editing them. While files are locked, no other users
in any workarea on the branch can edit their version of those files. This option
is suitable for environments where serial development is required.
Optional Write. Enables users to choose whether or not to lock a file. While
files are locked, no other users in any workarea on the branch can edit their
version of those files. This option is suitable for environments where serial
development is desired, but optional.
A branchs locking model is set when the branch is created. Different branches on
one TeamSite server may use different types of locking. All workareas on a branch
use the same type of locking. The type of locking a branch uses cannot be
changed after the branch has been created.
You can also set these locking models, plus the option None, when creating roles.
Since a branch and a role can have separate file locking, TeamSite uses the more
restrictive of the role locking and branch locking when determining what locking
model is in place for a particular user on that branch. TeamSite also evaluates
whether a user has multiple roles on the branch and uses the least restrictive
locking specified in a role. It then compares locking for the role with the branch
locking model and applies the most restrictive model.
Role locking is useful if you wanted to have a different locking model for users
having different roles on a given branch. For example, the author role may have
mandatory write locking, implying that users who are authors in a branch that has
submit locking should have the lock on the file and lock the file in their workarea
before editing the file. This lowers the need for authors to deal with conflict
resolution and merging while other roles enjoy a more lenient model.
Submit Locking is the least restrictive followed by Optional Write Lock and
Mandatory Write Lock.
ContentCenter configurations may impose additional restrictions on whether a
user needs to lock a file before being able to edit it.
Set a Locking Model on a Branch

TeamSite enables you to specify the locking model of each branch at the time that
it is created. However, the main branch is created automatically by the TeamSite
installation program and it uses the default option of Submit locking.
Creating a new Content Store also creates a new main branch. You can specify
which locking model to use for the main branch of a new Content Store by
completing the following procedure:
57
1. Edit the main_lock_model line in the [iwserver] section of iw.cfg as

follows:
[iwserver]
main_lock_model=locking_model
where locking_model is either of the non-default models:

optional_write_lock (or o)
mandatory_write_lock (or m)
2. Save and close the iw.cfg file.

3. Run the iwreset CLT to ensure the edit is recognized.
4. Create a new Content Store as described in the TeamSite Installation Guide.
The new Content Store uses the setting specified by the main_lock_model
option when it is created.
Locked File Submission

You can configure TeamSite to allow only the owner or creator of the lock to
submit a locked file to the staging area (as opposed to allowing any member of the
workarea where the file is locked). To configure this option, add the following line
to the [iwserver] section of iw.cfg:
[iwserver]
only_lock_owner_creator_submits=yes
Locking Behavior
The lockmodel_compatibility option in the iw.cfg file controls behavior of
Mandatory Write and Optional Write locking. When the option is set to true, all
users who have access to the same workarea can edit the locked file. When the
option is set to false, the file can be edited only by the lock owner in the
workarea where it was locked.
[iwserver]
lockmodel_compatibility=true|false
Compare Files
When TeamSite is comparing two versions of a file, it checks the version history
chain to determine a common ancestor for the two versions. You can specify the
number of versions to check using the compare_search_limit option in
iw.cfg, as follows (the default is 20):
[iwserver]
compare_search_limit=20
58
Submit and Update Logs

By default, the Submit and Update logs contain the 64 most recent Submit or Get
Latest operations for a workarea (as opposed to the 64 most recent files that were
submitted or updated). You can change this number, by editing the
event_log_size line in the [iwserver] section of iw.cfg.
[iwserver]
event_log_size=64
Autoprivate Feature
TeamSites Autoprivate feature enables you to prevent certain file types and
directories from being submitted to the staging area or copied during a Copy To
operation. Examples of these files may include temporary files, backup files and
Macintosh resource forks. File types specified in the Autoprivate configuration file
automatically get marked Private.
NOTE Changes to Autoprivate only apply to files or
directories that are created or renamed after the changes
are made. Changes do not apply to existing files.
Files and directories may also be specified Private by turning on the Do not submit
check box in the Properties screen in ContentCenter.
To activate Autoprivate, create a text file named autoprivate.cfg in your
iw-home\local\config\ directory. The Autoprivate file consists of two
sections:
files (or directories) matched by pattern
files (or directories) matched by name
Each section is set off by parentheses on their own lines, and the file begins with a
( (open parenthesis) on its own line and ends with a ) (close parenthesis) on
its own line.
Individual entries in the first section are in the following format:
((filenamepattern)(#_characters_to_match_at_beginning)(#_character
s to match_at_end))
where both #_characters_to_match_at_beginning and

#_characters_to_match_at_end are in hexadecimal.
For example, to have Autoprivate detect any file or directory that ends with .frk,
add the following entry:
((x.frk)(0)(4))
59
meaning to match zero characters at the beginning of the name and the four
characters (.frk) specified at the end of the name.
To set Autoprivate to detect any filename that ends in .backup.fm, add the
following entry:
((x.backup.fm)(0)(a))
where 0 specifies not to match any characters at the beginning, and a

(hexidecimal 10) specifies to match ten characters at the end of the filename.
Entries in the second section specify exact filename matches, set off by double
parentheses. These filename matches apply across all directories in all workareas
on the TeamSite server. For example, if autoprivate.cfg includes:
((test))
then all files and directories named test that are created after this line is added,
in all directories in all workareas in TeamSite, will be marked private.
The autoprivate.cfg file recognizes the following six special characters: ( )
[ ] # and a space (spacebar). If your file names contain any of these
characters, you must encode these values when specifying them as a pattern. For
example, to have Autoprivate detect a file name that includes spaces, encode the
spaces with a \20, for example, to match Network Trash Folder include:
((Network\20Trash\20Folder))
Encodings are represented as \xx where xx is the hex value of the corresponding
ASCII character. The following table shows the mappings for the six special
characters.
Table 3 Autoprivate Encodings
60
Special Character
Autoprivate Encoding
\23
\5b
\5d
\28
\29
space (spacebar)
\20
Encoding examples:
((\23x\23)(1)(1))
matches file names of the form: #*#
((\23bbaax)(2)(0))
matches: #b*
((\28ab\29)(2)(2)) #(ab)
matches the file name: (ab), the #(ab) is a comment
((a\5b\5db)(2)(2))
matches: a[]b
The following sample autoprivate.cfg file includes a few common entries:

(
(
((x.o)(0)(2))
((x.a)(0)(2))
((x~)(0)(1))
((.nfsXXX)(4)(0))
((x.bak)(0)(4))
((x.tmp)(0)(4))
)
(
((network\20trash\20folder))
((Network\20Trash\20Folder))
((.HSAncillary))
((.HSResource))
((.hsancillary))
((.hsresource))
((.tnatr:intf))
((.tnatr:reso-fork))
((resource.frk))
((trash))
)
)
For changes to autoprivate.cfg to take effect, restart the TeamSite server or

use the iwreset command-line tool.

The utility service or daemon named iwutild performs various tasks including
executing commands on behalf of trusted clients with impersonation, reading and
writing configuration files, and reading log files. Programs executed on behalf of
trusted clients are restricted to those explicitly specified in the iw-home\etc\
iwutild.cfg file.
61
All iwat triggers and workflow external tasks are executed by iwutild.
However, the programs executed by iwat triggers and workflow external tasks
need not be specified in iwutild.cfg. The iwutild daemon replaces
iwprocessd (Unix).
The iwutild.cfg file can be edited to modify error logging, executed
commands, and file locations. The following code shows the default
iwutild.cfg file.
<?xml version="1.0" encoding="UTF-8"?>
<iwutild>



<log
level="error"
path="/var/adm/iwutild.log"
cmdoutputpath="/var/adm/iwutild_cmdout.log"/>


<hopi
port-http="6688"
port-ssl="6689"
ssl-cert-dir="/usr/iw-home/local/config/ssl/iwutild"
log-level="error"/>


<command-list>
<command
name="iwpt_compile"
path="/usr/iw-home/bin/iwpt_compile.ipl"/>
<command
name="iwstat"
impersonate="false"
path="/usr/iw-home/bin/iwstat"/>
</command-list>
<file-list>
<file
name="iwcfg"
path="/etc/iw.cfg"/>
<file
name="iwutildcfg"
path="/usr/iw-home/etc/iwutild.cfg"/>
62
<file
name="iwlicense"
path="/usr/iw-home/etc/TS.lic"/>
<file
name="useropsxml"
path="/usr/iw-home/private/etc/userops.xml"/>
<file
name="useropsuixml"
path="/usr/iw-home/private/etc/userops_ui.xml"/>
<file
name="iwutildclientcfg"
path="/usr/iw-home/servletd/conf/iwutild_client.cfg"/>
<file
name="cssdkcfg"
path="/usr/iw-home/cssdk/cssdk.cfg"/>
<file
name="iwserverlog"
path="/var/adm/iwserver.log"/>
<file
name="iwtracelog"
path="/var/adm/iwtrace.log"/>
<file
name="iweventslog"
path="/var/adm/iwevents.log"/>
<file
name="iwutildlog"
path="/var/adm/iwutild.log"/>
<file
name="transformcfg"
path="/usr/iw-home/local/config/transform.cfg"/>
<file
name="datasourceconfigxml"
path="/usr/iw-home/local/config/DataSourceConfig.xml"/>
<file
name="metadatarulescfg"
path="/usr/iw-home/local/config/metadata-rules.cfg"/>
<file
name="templatingcfg"
path="/usr/iw-home/local/config/templating.cfg"/>
<file
name="fileencodingcfg"
path="/usr/iw-home/local/config/file_encoding.cfg"/>
<file
name="availabletemplatescfg"
path="/usr/iw-home/local/config/wft/
available_templates.cfg"/>
</file-list>
</iwutild>
63
The iwutild.cfg file uses the port-ssl option to set the port number to be
used for the iwutild service. The default value is 6689. This value can be
changed during the TeamSite installation.
If you change the port number in iwutild.cfg after installation, you need to
update the cssdk.cfg file and set the following option in iw.cfg so that
iwserver can find the iwutild service.
[iwserver]
utild_ext_tasks_portnum=portnumber
The iwutild.cfg file allows you to select which commands or scripts use
impersonation and which are to run as System. The iwptcompiler is one of
these commands. Disable impersonation for a command by specifying
impersonate="false" for the command.
The iwutildreset CLT can force iwutild to re-read the iwutild.cfg file.
The iwutildstat CLT provides status information for the iwutild server.
Refer to the TeamSite Command-Line Tools for information on these CLTs.
Run as Non-Root User

Unix:
The iwutild process can also be run as the non-root user iwts. This is
achieved through a setting in the iw.cfg file, which defaults to true:
[iwserver]
iwutild_runas_root=true|false
You should be aware of the following areas that are impacted when iwutild is
invoked as a non-root user:
64
Files and directories created by customer scripts through the file system
interface (/iwmnt) may not have the correct ownership and permissions.
They will be owned by iwts.
Creation of assets outside of the Teamsite environment may not be possible

without the appropriate directory and file permissions. The files created will be
owned by iwts.
The iwat triggers will not run as the user root; instead they run as the
non-root user iwts. If the triggers invoke scripts that create or delete files and
directories through the file system interface, ownership and permissions will
be for user iwts.
The existing external workflow task scripts will have to be re-written by the
customer to use the URL-based workflow feature.
If you are running the utility daemon as non-root and invoke any workflow
external tasks by mistake, the behavior of the task is not determined. The task
might end up creating files with incorrect ownership since the external tasks
will be run as the user iwts.
The templating scripts will have to be re-written using XLST, instead of the
current PT compiler implementation.
The TeamSite server (that is, iwserver) running on UNIX systems is run by the
process iwts rather than by root. As a result, after TeamSite is installed,
permissions on all Content Store files are reset to enable iwts, and all TeamSite
processes except iwauthend run as iwts or iwui. This conversion cannot be
undone, and the installer cannot opt out of it.
NOTE You must still log in as the user root to run the
TeamSite installation script and to perform administration
tasks.
Start/Stop the iwutild Server

Unix: The iwutild daemon is started and stopped with iwserver.
Windows: The iwutild service is a separate service that is automatically started
and stopped.

The Event Subsystem is packaged and installed with TeamSite and can be used
to deliver messages (events) to and from Search or ReportCenter with TeamSite
as an event publisher and Search and ReportCenter as subscribers. To do this,
the Event Subsystem stores and queues events.
In addition to Search and Report center, other subscribers include Workflow
Modeler and OpenDeploy DAS module. DAS is enabled for DataDeploy. For more
information about the DataDeploy module, see the OpenDeploy documentation.
The Event Subsystem uses a JMS (Java Message Service)-compliant model of
message delivery, which is based on three concepts:
Events Synonymous with message. Events are the result of changes,

end-user actions, or occurrences in a Publisher program. For example,
TeamSite server events include (but are not limited to):
CreateBranch
Submit
TaskActivate
65
Events have names and properties, such as user, role, and timestamp,
that are represented in the Event Subsystem as attribute/value pairs.
A subscriber can be set up to perform functions after a TeamSite event occurs.
For example, an index can be updated after files are submitted.
Publishers. Applications that send events to the Event Subsystem. The Event
Subsystem then passes the events to Subscribers that have registered to
receive them.
Subscribers. Applications that register with the Event Subsystem to receive

events. Subscribers can filter events so that they receive only the ones they
need.
Figure 7 illustrates how the Event Subsystem works.

Figure 7 How the Event Subsystem Works
Publishers
TeamSite
Server
Event Subsystem
Subscribers
Search
Proxy Servlet
Message Service Interface

Message Service
Implementation
ReportCenter
Workflow
Modeler
OpenDeploy
DAS
The Event Subsystem is configured by the TeamSite installer. Refer to the

TeamSite Installation Guide for information.
Verify that the Event Subsystem is Enabled

The Event Subsystem is normally enabled during the TeamSite installation. You
can verify that the Event Subsystem was enabled by checking the iw-home\
etc\iw.cfg file. Look for the following line in the [event_subsystem]
section:
[event_subsystem]
ew_enable=true
If the line is not included, add it to the iw.cfg file. Save and close the file; issue
the iwreset CLT.
The default size of each default_log_location/iwevents/
TeamsiteEvents.x log file (before it rolls over) is 100 MB. This is specified in
iw.cfg under the [event_subsystem] section.
[event_subsystem]
66
ew_rollover_threshold=104587600
Ensure that the Event Subsystem Servlet is Started

The Event Subsystem Service is only available on Unix. Run /etc/init.d/
iw.server start to start the Event Subsystem daemon.
To ensure that the Event Subsystem servlet is started, restart the servlet engine
by issuing an iwreset -ui command. This will also ensure that the application
container and Event System webapps are started. You can verify that the Event
System webapps are started by looking at iw-home/local/logs/iwui/
iweventproxy.log.
Enable DAS Publishing

OpenDeploy and DataDeploy subscribe to a deprecated message topic called
TeamSite_User. Publishing to this topic is disabled by default. To enable this,
perform the following steps. Future releases of OpenDeploy use the new
message topic Interwoven.
If you are using DataDeploy, enable DAS by performing the following steps:
1. Stop the TeamSite services.
2. Make the following changes to the iw-home\httpd\webapps\
eventsubsystem\WEB-INF\iw_bridge_cfg.xml file.
Add dasTopic="TeamSite_User" property to the iwovJMS tag.
For example:
<iwovJMS classpath="_IW_HOME_/eventsubsystem/lib/
openjms-client-0.7.6.1.jar" initialContextFactory="org.exola
b.jms.jndi.InitialContextFactory" url="tcp://localhost:3035/
" factoryName="JmsTopicConnectionFactory" topic="Interwoven"
dasTopic="TeamSite_User" expiryTimeInDays="4"
waitTime="300000">
</iwovJMS>
Uncomment logFile tags with the name property value of
"TeamSiteDASLog" and "TeamSiteClientDASLog".

For example:
<logFile name="TeamSiteClientDASLog"
baseLogName="_IW_LOG_DIR_/iwui/iwevents/
TeamSiteClientEvents" stateFileName="_IW_HOME_/servletd/
logs/iwclientDASproxy.properties" waitTime="30000"
isDAS="true" />
67
<logFile name="TeamSiteDASLog" baseLogName="_IW_LOG_DIR_/

iwevents/TeamsiteEvents" stateFileName="_IW_HOME_/servletd/
logs/iwDASproxy.properties" waitTime="30000" isDAS="true" />
3. Restart the TeamSite services.

4. The DAS enabling can be verified by looking into the messages_handles
database table for the messages published for the DAS.
example: Pseudo Query:
Select * from message_handles where destinationId in
(Select destinationId from destinations where name
='TeamSite_User')

The following sections describe the configuration settings that enable you to
maximize the performance of TeamSite relative to your unique environment.
Cache Size
To set the TeamSite cache size, edit the cachesize line in the [iwserver]
section of iw.cfg. If a comment symbol (#) begins the line, remove it. If this line
does not appear in your iw.cfg file, add it as shown below. The initial cache size
setting should be approximately three times the number of files and directories on
the largest branch.
For example, if the largest branch contains 15,000 files and directories, you
should set cache size to 45000 as follows:
[iwserver]
cachesize=45000
Minimum cache size is 1000; maximum is 400,000 entries. Each cache line
takes a maximum of 1KB of physical memory. Recommended physical memory is
cache size times 1KB plus an additional 25% as a safety margin. In the example
shown below, physical memory would be (45,000 * 1KB) + 11MB = 56MB. If you
encounter a great deal of memory swapping, you should either reduce the cache
size or install more memory.
NOTE The value of cachesize is not the amount of
memory that is used, but the number of objects kept in the
cache.
You must restart the TeamSite server for this change to take effect.
68
External Task Impersonation

Windows:
When the disable_ext_task_impersonation option in the iw.cfg file is
set to true, workflow external tasks run without impersonation (that is, as
System).
[authentication]
disable_ext_task_impersonation=true|false
External tasks run as the task owner and are restricted to the permissions
associated with the task owner. If the impersonate_without_password
option in the iw.cfg file is set to false, the behavior from earlier TeamSite
versions in which the iwauth cookie carries the password is in effect. This
applies only to iwptcompile and CGIs and has no effect if impersonation is
turned off for a given command in the iwutild.cfg file.
[authentication]
impersonate_without_password=true|false
Throughput Monitors
Throughput monitors can be used in conjunction with the iwstat CLT to monitor
system status and performance. By default, the throughput monitoring is set to
off. To turn on throughput monitoring edit the thruputmonitoring line in the
[iwserver] section of iw.cfg as follows:
[iwserver]
thruputmonitoring=on
After turning monitoring on, the five default throughput monitors are activated.
They return system statistics over the previous minute, 15 minutes, hour, eight
hours, 24 hours, and for the entire time that the system has been running.
You can deactivate any of the default monitors by adding a comment mark (#) to
the beginning of the line. The last two throughput monitors can be configured with
custom time intervals.
[iwserver]
thruputmonitoring=on
thruputmonitor1=1
thruputmonitor2=15
thruputmonitor3=60
thruputmonitor4=480
thruputmonitor5=1440
thruputmonitor6=-1
thruputmonitor7
thruputmonitor8
#
#
#
#
#
#
1 minute
15 minutes
1 hour
8 hours
24 hours
forever
69
Detect Low Disk Space and Inode Count

TeamSite is configured to freeze the Content Store when it detects that free disk
space or inode count (on Unix) is low. The Content Store remains frozen until
sufficient disk space or inode count (on Unix) is restored, at which point the server
returns to its normal running state. This feature helps prevent possible corruption
of the Content Store. While the Content Store is frozen, users cannot write to the
TeamSite Content Store. Users can still perform read-only operations. The CLT
iwfreeze can be used to manually freeze the Content Store.
The disklow lines in the [iwserver] section of iw.cfg control the behavior of
disk/inode (on Unix) low detection. They are shown here with their default
settings:
[iwserver]
disklow_mbytes=50
disklowpercent=10
(Unix)disklow_knodes=50
disklow_mbytesDefines the freeze threshold in MB for the TeamSite

server. The TeamSite server does not allow any write operations if the disk
space falls below this setting.
disklowpercentDefines the percentage of free disk space that is

considered low.
(Unix)disklow_knodesDefines a freeze threshold in thousands of

inodes for the TeamSite server.
NOTE If the server detects a low-disk state based on the threshold set in
iw.cfg, it does not allow you to manually unfreeze the Content Store with
the iwfreeze command. The TeamSite server does not allow
disklowpercent to go below 2 percent. To change these settings, edit the
setting on any of these lines.

The iw.cfg file contains a server_locale entry in the [iwserver] section.
The entry specifies the locale in which current execution of the TeamSite server
(iwserver) runs. For example:
[iwserver]
server_locale=English_UnitedStates.MS1252 (Windows)US-ASCII
(Unix)@Binary;
70
This setting is automatically created in the iw.cfg file when iwserver is

started. The native/system locale is determined by reading the LANG environment
variable (Unix)/System Locale setting in the Regional Settings control
(Windows). Once the server_locale setting exists in the iw.cfg file, it is used
to determine the TeamSite servers native/system locale at every invocation of
iwserver. If this setting is not present, iwserver determines its locale from the
LANG environment variable (Unix)/System Locale setting in the Regional
Settings control panel (Windows).
While this setting can be user-modified, it is designed to serve as reference as to
the locale in which iwserver is currently running. If you have a situation where
you want to force iwserver to run in a particular locale (independent of the LANG
environment variable (Unix)/System Locale setting (Windows), you can stop the
TeamSite server, manually edit the server_locale line, then restart the
TeamSite server.
The locale in which the server operates (as defined by the server_locale
entry), effectively determines the locale of the TeamSite IFS. For example, if
iwserver runs under the Japanese_Japan.Shift_JIS@Binary locale, all
file and directory names are encoded in Shift_JIS encoding.
The server_locale setting in the iw.cfg file can contain any of the locales
listed in the following table (note that these settings are Autonomy naming
conventionsthe operating system locales to which they map are also contained
in the table):
Table 4 server_locale Settings in iw.cfg
iw.cfg server_locale Setting (Unix)
Solaris/AIX 5.1
SimplifiedChinese_China.MS936@Binary
zh/zh_CN
Korean_Korea.MS949@Binary
ko/ko_KR
Japanese_Japan.Shift_JIS@Binary
ja_JP.PCK/Ja_JP.IBM-932
Japanese_Japan.JapanEUC@Binary
ja/ja_JP
German_Germany.Latin1@Default
de/de_DE
English_UnitedStates.US-ASCII@Binary
C (C locale)
71
Table 5 server_locale Settings in iw.cfg

iw.cfg server_locale Setting
Windows Locale
SimplifiedChinese_China.MS936@Binary
Simplified Chinese
Korean_Korea.MS949@Binary
Korean
Japanese_Japan.MS932@Binary
Japanese
German_Germany.MS1252@Default
German
English_UnitedStates.MS1252@Binary
U.S. English
The following sections describe how to configure FormsPublisher to provide an
example templating environment. After the initial setup is complete, you can:
Use the example templating environment to become familiar with the

FormsPublisher end-user features.
Customize the example environment to create your site-specific configuration.
Set up the Example Environment

Perform the following steps to set up the example FormsPublisher environment.
You must copy these files and directories to locations that are specific to your site.
1. Decide which workarea you will use for the initial FormsPublisher setup.
Ideally, this workarea should be on a temporary test branch where you can
submit and publish without affecting the rest of your TeamSite installation.
After FormsPublisher is configured in a workarea on this test branch, you can
copy the workarea to a permanent branch. You can then submit the workarea
to the staging area and use Get Latest to propagate the setup to other
workareas on the branch.
2. Read the iw-home\examples\Templating\README file for details about
directory contents and last-minute information that might not be documented
elsewhere.
3. Copy the contents of iw-home\examples\Templating\templatedata
(including the templatedata directory itself) to the workarea determined in
Step 1.
Ensure all users have read and write permission for each file.
Do not change any directory or file names.
The end result should be workarea_name/templatedata/...
72
4. Edit the templating.cfg file to specify the branches where FormsPublisher

is used.
5. Optionally, edit the available_templates.cfg file as described in the
Workflow Developers Guide.
FormsPublisher Settings in iw.cfg

You may need to configure the following FormsPublisher settings in your
TeamSite iw.cfg file:
Identify the Templating Directory

To change the directory in your workareas where templating content will reside,
modify the /etc/iw.cfg file. The default directory is templatedata.
[teamsite_templating]
data_root=directory
Maintain Preview Files

A manifest file is created at the top of the users workarea when a preview is
performed. Included in the manifest file is a list of files created during a preview.
When a new preview is requested, the manifest file is checked and the temporary
files listed in it are deleted. The manifest file is also deleted. The preview is then
generated and a new manifest file is created.
The preview_history_limit parameter in the iw.cfg file lets a user do
multiple previews and compare the results of previews without the preview files
being deleted. For example, if preview_history_limit=2, two temporary
preview files would be maintained. When the user does a third preview in the
same workarea, the oldest set of preview and manifest files are deleted and
replaced with preview files that are created by the current preview. As a result, a
user's workarea always contains two manifest files and the corresponding preview
files. These files are marked private so they will not be submitted to the staging
area or shown in a TeamSite directory listing.
preview_history_limit=value
The preview_system_directory parameter in the iw.cfg file puts preview

system files, such as manifest files, in a directory other than data_root
(templatedata).
preview_system_directory=directory
73
Control Printing of Data Records

Data records are normally written so that all content appears on a single line. You
have the option to print so that each new XML element in a data record starts on a
new line, indented. To enable this type of printing, include the following line in the
/etc/iw.cfg file.
pretty_print_dcrs=true
TeamSite Embedded Failsafe

The TeamSite Failsafe functionality has been automated to improve the ability to
protect your assets against unexpected server outages. Unlike previous versions
of TeamSite, there is no need to modify your iw.cfg file to benefit from what is
now known as Embedded Failsafe.
Embedded Failsafe improves reliability by automatically flushing the cache at
clean flush points, thereby reducing the possibility of on-disc metadata
inconsistencies caused by abnormal server termination.
74
CHAPTER 4
Manage the TeamSite Server

This chapter describes configuration settings and procedures that can be used to
manage and enhance your server performance. While there are many variables
that contribute to your TeamSite server performance, the information contained in
this section should prove useful to most TeamSite administrators.
Verify Server Operation
Start and Stop the TeamSite Server
Check for Multiple Servers
Check Request Handling
Verify the Server Mount
Locate the Installation Directory
Review TeamSite Log Files
Monitor the Server Load
Reconfigure iwwebd to Recognize a New IP Address
Manage Disk Space
Monitor Disk Space Usage
75
Chapter 4 Manage the TeamSite Server
Verify Server Operation

To verify that the TeamSite server is running, complete the following procedure:
Windows
1. Press Alt + Ctrl + Delete and select Task Manager to open the
Windows Task Manager.
2. Click the Processes tab.
3. Ensure that one iwserver.exe is running.
If there is no iwserver.exe listed:
a. Open the Control Panel (Start > Settings > Control Panel) and select
Administrative Tools.
b. Double-click Services.
c. Ensure that TeamSite is listed in the Name column, and that it is listed as
Started in the Status column (TeamSite in the Services window is the
equivalent of iwserver.exe in the Task Manager).
4. Optionally, check the Mem Usage column of the Task Manager to see how
much memory iwserver.exe is using.
For details about analyzing and changing the amount of memory it is using,
and the relationship between cache size and memory usage, see Cache
Size on page 68.
Unix
1. Type the following command:
% /bin/ps -ef | grep iwserver | grep -v grep
If the iwserver process (that is, the TeamSite server) is running, you will see
a response similar to this:
iwts 643 638 0 Feb 08 ? 7:22 iwserver.sol -e /Interwoven/
TeamSite/local/logs/iwevents.log /iw-store
If you do not see a similar response, iwserver is not running. To

troubleshoot your installation:
SolarisCheck the iwtrace.log file to see if TeamSite stopped
abnormally producing an EXITED: message.

AIXCheck the var/admin/iwserver.log file for ERROR: and
WARNING: messages.
76
2. If you determine that the TeamSite server stopped abnormally, stop the
TeamSite services with the following command:
% /etc/init.d/iw.server stop
3. Start TeamSite by running the following command:

% /etc/init.d/iw.server start

Windows
To manually stop the TeamSite server
1. Log in to Windows with Administrator permissions.
2. Select Start > Settings > Control Panel.
3. Double-click Administrative Tools.
4. Double-click Component Services.
The Component Services Control Panel opens.
5. Select TeamSite from the list of services, and click Stop.
6. Select Proxy from the list of services, and click Stop.
7. If you are using OpenDeploy, select OpenDeploy from the list of services, and
click Stop.
8. To restart TeamSite, you must reboot the server host machine.
Do not attempt to restart the TeamSite service from the Services control
panel. By default, TeamSite is configured to start automatically on reboot.
NOTE If you stop the TeamSite server while there are open
handles (for example, someone has a file from the Content Store
open, or is exploring it, or it is remotely mounted), either of the
following entries may be written to iwtrace.log:
ERROR: DrvUnMountDevice - Lock volume failed
Access Denied
Trying to delete non-existent vnode 0xXXXXXXXX
These messages can be ignored.
77
Unix
To stop the TeamSite serve:
To restart the TeamSite server

Check for Multiple Servers

Unix
One server process should be running at any given time. If there are no processes
running, then the server is not running. If more than one server process is running,
there is a problem with the server and it should be stopped and restarted.
To reset the server to ensure that only one server process is running
1. Issue the following command to stop the server:
2. Verify that all server processes have stopped. If not, manually kill any
remaining processes. For more information on the kill command, consult a
UNIX reference manual.
3. Restart the server with the following command:
Check Request Handling

To ensure that the TeamSite server is answering requests correctly, type the
following command:
% >iw-home\bin\iwversion
If the TeamSite server is responding, you will see a response similar to this:
iwserver: 7.1.2 Build 61235 Interwoven 20101031
If the server does not respond or stops, then the server is not handling requests
correctly. Restart the server as described in Check for Multiple Servers on
page 78 for Unix and as described on Start and Stop the TeamSite Server on
page 77 for Windows.
78

Windows
Use Windows Explorer to verify that the Y: (default) drive is mounted as a file
system volume.
If you did not use the default installation location, check the iwmount line in the
[locations] section of iw-home\etc\iw.cfg to find out what drive letter
was used. Use Windows Explorer to verify that the drive is mounted as an IFS
volume. If it is not, reboot the server.
NOTE If you are using IIS, the Microsoft Management
Console may show an error flag next to the IFS volume
when you reboot the Windows server. This does not
necessarily indicate an error. Because IIS starts before
TeamSite, it cannot find the IFS volume when it first starts,
and it does not remove the error even after TeamSite starts
and the IFS volume appears. Once the TeamSite server
does start, you can navigate to the IFS volume and see your
content files in your backing store.
Unix
Verify the server is mounted to the correct drive partition with the following
command:
% df -k | grep iwserver
The output should contain two lines similar to this:

Filesystem
kbytes
used
avail
capacity
Mounted on
server:/iwserver/default
3141968
1542472
1285336
55%
/iwmnt/default
server:/iwserver/default
3141968
1542472
1285336
55%
/.iwmnt/default
If the server does not respond properly, stop and restart it with:
/etc/init.d/iw.server stop then /etc/init.d/iw.server start.
79
Locate the Installation Directory

Windows
To locate the TeamSite installation directory, use the iwgethome.exe CLT.
1. Select Start > Run.
2. Type cmd in the Open field and click OK.
The command window opens.
3. Type iwgethome at the command prompt and press Enter.
TeamSite displays the installation directory:
>iwgethome
C:Program Files\Interwoven\TeamSite
Unix
To locate the TeamSite installation directory, type iwgethome at a command
prompt. TeamSite displays the installation directory:
% iwgethome
/local/iw-home
For detailed information about iwgethome and all TeamSite CLTs, refer to the
TeamSite Command-Line Tools manual for your platform.

TeamSite records events in various TeamSite log files and also in the Windows
Event Viewer. These files, their contents, and default locations are described in
the following sections. The default locations of files is iw-home\local\logs.
WFS Log
Unix
On system startup, the TeamSite kernel device driver (iwovwfs) is installed. This
occurs before most other services are up. Messages from this installation are
logged into /var/adm/iwwfs.log, and an error message is printed to the
console instructing you to look at this log file. The location of this file cannot be
changed.
80
Installation Log
Unix
The TeamSite installation log records the prompts and your replies to them during
the execution of the TeamSite installation program. The file is called
installer.log and, by default, is located in <iw-home>/iwinstall/logs.
Server Log
The server log records the state of TeamSite over timeincluding, but not limited
towhen the TeamSite server is started, stopped, and mounted. The file is called
iwserver.log and, by default, is located in iw-home\local\logs. If the file is
not in the default location, you can locate it using the CLT iwgetelog.
Master users can also view the server log from the Logs tab in the Administration
Console.
Trace Log
The trace log records any irregularities on the TeamSite server. It is primarily used
by Consulting Services to diagnose system performance issues. The file is called
iwtrace.log and, by default, is located in iw-home\local\logs. If the file is
not in the default location, you can locate it using the CLT iwgettrace.exe.
Master users can also view the trace log from the Logs tab in the Administration
Console.
Events Log
The iwevents.log records TeamSite activitiesincluding, but not limited to
file submits, edition, branch and workarea creation, and DiskLow, Freeze,
ShutDown, StartUp and Thaw events. It is used with certain TeamSite triggering
scripts. By default, the file is located in iw-home\local\logs. On Unix, if the file
is not in the default location, you can locate it by checking the /etc/
defaultiwelog file or by using the CLT iwgetelog. On Windows, if the file is
not in the default location, you can locate it using the CLT iwgetelog.exe. The
entries in your iwevents.log file will be similar to these:
Windows
timestamp
domain\user
role
[Thu Aug 23 15:43:27 2010] SYSTEM

master
[Thu Aug 23 15:44:11 2010] INTERWOVEN\bgunn _
event
StartUp
ModifyEntity
ModifyEntity
81

[Fri Aug 24 11:47:47 2010] INTERWOVEN\tom
editor
CPE Workflow 0x3ffcf Editor Review 0x3ffd8 tom
ModifyEntity
ModifyEntity
TaskGroupTaken
event-specific information
(the example line wrapped)
Unix
timestamp
[Thu Aug
[Thu Aug
[Thu Aug
[Thu Aug
[Fri Aug
Workflow
user
role
event
event-specific
information
23 19:44:57 2010] root master

StartUp
23 20:47:27 2010] root master
Freeze
60
23 20:47:29 2010] root master
ShutDown
23 20:50:15 2010] root master
StartUp
24 11:47:47 2010] tom
editor
TaskGroupTaken CPE
0x3ffcf Editor Review 0x3ffd8 tom
event-specific information
(the example line wrapped)
The last sample line states that on Friday August 24, 2010, the user tom, who is
logged in with the role of editor, took ownership of task 0x3ffd8 (or 262104).
The task is labeled Editor Review in job 0x3ffcf (or 262095) and is part of a
workflow named CPE Workflow. The user tom assigned ownership to the task to
tom (himself).
Master users can also view the event log from the Logs tab in the Administration
Console.
Workflow Log
The workflow log records the output from workflow runtime diagnostics. The file is
called iwjoberrors.log and, by default, is located in iw-home\local\logs.
The log file contains entries when the following events occur:
When the TeamSite server encounters an error compiling a workflow,

including:
a tasks named owner has insufficient privileges to its areavpath
an areavpath does not exist
This does not include every workflow specification that has errorssome
errors occur on the client.
82
When externaltasks have trouble forking on Windows.
When the workflow engine has problems while running tasks in a job,
including:
attempting to create a task variable that already exists.
attempting to add a file to a task that is already in its file list.
Windows Event Viewer

You can configure TeamSite to log and display any of the following events in the
Windows Event Viewer:
DiskLow
Freeze
ShutDown
StartUp
Thaw
Configuration is controlled by the [iwserver] section in the iw.cfg file. See

the Windows Event Viewer documentation provided by its manufacturer for usage
details.

The TeamSite CLT iwstat.exe returns a list of all current TeamSite processes,
for example:
While the TeamSite server is not running (as the result of iwfreeze),
iwstat returns:
*** SERVER FROZEN: 55 SECONDS REMAINING ***
ID
Thread
User
Duration
Operation
0x9d
0xf
root
0.000
GetArchiveStatus
While the TeamSite server is running, iwstat returns:

Store
iwadmin
dev
ThirdParty
pubs
bugdb
dropzone
integrations
Status
Running
Running
Running
Running
Running
Running
Running
83
products
scratch
CIE
workflow
ID
0x28e33f4
0x28543a1
Running
Running
Running
Running
Thread
0x1a75
0x1e
User
dvallabh
-
Store: dev
Batch Jobs (running):
Queued
[Fri Jul 9 15:27:19 2010]
Minutes
1
5
15
60
Thruput
13
17
233
1792
Avg op
0.0000
0.0003
0.0041
0.0004
Duration
0.000
2529.446
User
root
Store
dev
Operation
GetServerStatus
BatchJobs
Job
Object ID
RemoveDuplicateData (Phase 1)
Load
0.00
0.00
0.95
0.71
See TeamSite Command-Line Tools for details about iwstat.exe usage and
output.
Reconfigure iwwebd to Recognize a New IP Address

If you change the IP address of the server hosting TeamSite, complete the
following procedure to reconfigure iwwebd to recognize the new address.
1. Go to the iwwebd.bin directory/folder.
2. Run iwwebd_conf.ipl from the command line.
3. Restart iwwebd.
Manage Disk Space

The following sections describe procedures you can use to manage disk space on
the TeamSite server.
84
Manage Disk Space
File Locations
The [locations] section of iw.cfg must be updated if you change the
locations of certain TeamSite files and directories from their default locations. By
default, iw.cfg includes the following entries:
#[locations]
#iwhome=/usr/iw-home
#iwmount=/iwmnt
#iwcgimount=/.iwmnt
#iwstore=/local/iw-store
#iweventlog=/var/adm/iwevents.log
#iwtracelog=/var/adm/iwtrace.log
#iwserverlog=/var/adm/iwserver.log
To change the location of one of the entries, remove the comment (#) marks from
its line and edit the line to point to the new location. (Ensure that the
[locations] line is not also commented out). For example:
[locations]
iwbin=C:\Program Files\Interwoven\TeamSite\(Unix:usr/iw-home/)bin
iwmount=Y:/iwmnt
iwcgimount=Y:/.iwmnt
iwroles=C:\Program Files\Interwoven\TeamSite\(Unix:usr/iw-home/
)local\/config\roles
iwstore=Window:C:\iw-store;Unix:local\iw-store
iwsubmitconfig=C:\Program Files\Interwoven\TeamSite\(Unix:usr/
iw-home/)local\config\submit.cfg
iwautoprivate=C:\Program Files\Interwoven\TeamSite\(Unix:usr/
iw-home/)local\config\autoprivate.cfg
iwlogs=C:\Program Files\Interwoven\TeamSite\(Unix:usr/iw-home/
)local\logs
iwconfigs=C:\Program Files\Interwoven\TeamSite\(Unix:usr/iw-home/
)local\config
iweventlog=C:\Program Files\Interwoven\TeamSite\local\logs\
(Unix:var/adm/)iwevents.log
iwtracelog=C:\Program Files\Interwoven\TeamSite\local\logs\
(Unix:var/adm/)iwtrace.log
iwserverlog=/var/adm/iwserver.log
iwdeploylog=C:\Program Files\Interwoven\TeamSite\Unix:usr/iw-home/
)local\logs\iwdeploy.log
After restarting, TeamSite looks for the specified file or directory in the new
location.
85
The default iw.cfg does not contain all applicable files. The following table lists
other files and directories controlled by [location] in iw.cfg, some of which
are included in the preceding example.
Table 6 Other files and directories controlled by [location]
Specifies the location of TeamSite binaries (by default Unix:/Interwoven/
iwbin
TeamSite/bin;Windows: iw-home\bin).
86
iwmount
Specifies the location of the TeamSite mount point.
iwcgimount
Specifies the location of the non-attribute caching TeamSite mount point.
iwroles
Specifies the directory containing the TeamSite roles files.
iwstore
Specifies the location of the TeamSite Content Store (this setting can be
overridden by the Registry key on Windows).
iwsubmitconfig
Specifies the location of the Submit Filtering configuration file.
iwautoprivate
Specifies the location of the Autoprivate configuration file.
iwlogs
Specifies the directory containing TeamSite logs.
iwconfigs
Specifies the default configuration file directory.
iweventlog
Specifies the location of the TeamSite event log.
iwtracelog
Specifies the location of the TeamSite trace log.
Unix:
iwserverlog
Specifies the location of the TeamSite server log.
iwdeploylog
Specifies the location of the deployment log.
On Unix, if you change the location of iwmount, you must edit its webserver
alias to point to the new location. Also make sure the values in /etc/
defaultiw* match these settings.
On Windows, the TeamSite shared drive location can be configured to any

drive letter (for example, to change the shared drive to X:, edit the
[locations] section to contain the line iwmount=X:). If you change the
shared drive location, you must update the webserver alias (iw-mount)
accordingly. After changing shared drive locations, you must reboot the server
for the changes to take effect.
If you change the location of one of the logs and no file with the specified
name is present in the new location, a new file is created.
On Windows, to change the location of the TeamSite Content Store, you must
edit the Registry.
Manage Disk Space
Figure 8 Registry Editor window
Enhance File System Performance on the TeamSite Server

On Windows, on the TeamSite server, browsing the TeamSite shared drive using
Windows Explorer can be slow. If you are working on the system that hosts the
TeamSite server, you can improve performance by completing the following
procedure:
1. Open Windows Explorer or My Computer.
2. Select Tools > Map Network Drive.
The Map Network Drive window opens.
3. Click Browse.
The Browse For Folder window opens.
4. Locate the system that hosts the TeamSite server.
5. Click the plus sign (+) to expand the directory tree of your TeamSite server.
The following graphic shows this for a TeamSite server called Bgunn.
Figure 9 Expanding the directory tree of the TeamSite server
6. Select IWServer, then click OK.
87
7. In the Map Network Drive window, click Finish.

The new drive is assigned a drive letter (M: in this example) and has access to
the same files, but without sharing.
Figure 10 Viewing a shared access drive
Local access only, no sharing, but

much faster access
Shared access (over a network), but

slower local access
When you browse the contents using the new mounted drive, you will notice
improved performance. Users accessing the TeamSite file system interface
remotely (over a network) are not affected.

You have two options for checking the amount of disk space used by the files
being managed by TeamSite, either:
The size of the Content Store. Actual disk space being used.
The size of the mount point. Contains many virtual copies of files in
workareas, staging areas, and editions.
To check the amount of disk space used by files managed by TeamSite

1. On Windows, open Windows Explorer or My Computer on the TeamSite
server host.
2. Navigate to, and highlight either the content store (C:\iw-store by default)
or the mount point (IFS Volume Y: by default).
NOTE You can determine their locations by issuing the

iwstore or iwmount CLTs.
88
The amount of disk usage for your selection is shown in the bottom of the window:
Figure 11 Viewing the size of the iw-store
Size of C:\iw-store
On Unix, issue the following command:

% df -k `cat /etc/defaultiwstore`
The system will return something similar to the following:

Filesystem
unted on
/dev/dsk/c0t2d0s2
local
kbytes
used
avail
capacity
Mo
17637068
9613319
7847379
56%
Although the mount point contains many virtual copies of files in workareas,
staging areas, and editions, df -k only checks the actual disk space used.
Delete Editions
To reclaim some disk space, you can delete old editions, which also deletes all
files contained in that edition and all intermediate submissions between
publication of editions. You should be aware that if a file is contained in more than
one edition and not all of these editions are deleted, the file is not deleted; only the
pointer to the file in the deleted edition is deleted. Therefore, you may not save as
much space as you anticipate.
To delete an edition using the ContentCenter Professional interface
1. In the branch view, click the check box next to the edition you want to delete.
2. Select File > Delete.
A confirmation window is displayed.
3. Type YES in the confirmation field and then click Delete.
89
The edition and all versions of the files contained within that edition are
deleted. Additionally, all Submit Log entries are transferred to the next most
recent edition. If the edition you have deleted is the newest one, the Submit
Log entries are transferred to the staging area.
You can also delete editions using the iwrmed CLT as described in the TeamSite
Command-Line Tools.
Metadata Forking
Metadata forking conserves disk space by reducing the number of files whose
content is duplicated throughout the TeamSite Content Store. That is, if you have
an old version of a file in one branch, and an identical version on another branch,
the same data may appear twice in the Content Store. Metadata forking is
accomplished by running the iwfsshrink CLT and results in no user-visible
changes to the TeamSite virtual file system (for example, file histories are not
changed).
The iwfsshrink utility must be run while the TeamSite server is running;
however, TeamSite may experience some performance degradation while it is
running. Also, iwfsshrink may not remove all duplicates (for example, it does
not remove any duplicates created by TeamSite users while the utility is running).
The iwfsshrink utility should be run every few months.
1. Start the iwfsshrink utility from the command line:
% >iwfsshrink run storename
The utility may take several hours to run.

2. Issue the command again using the status option to view the current status:
% >iwfsshrink status storename
when iwfsshrink finishes running, it returns a message similar to:

Not currently running.
Last started Mon Jun 26 15:47:53 2002
Last completed Tue Jun 27 00:40:04 2002
Files examined: 317974
Bytes examined: 75936814830
Files found to be duplicates: 233430
Files converted: 198352
Bytes removed: 23455046531
3. Optionally, you can pause the operation with the pause option, then restart it
with the run option.
For more details about the iwfsshrink utility, see the TeamSite Command-Line
Tools.
90
Move the Content Store and Removing Old Versions

If you are running out of disk space and iwfsshrink does not recover enough
extra space, you may need to move the TeamSite Content Store. The TeamSite
Content Store must reside on a single logical volume, for example, a single disk or
an array of disks.
Alternatively, if you have unused branches in TeamSite, you can delete these
branches to recover disk space. Over time, individual branches take up an
increasing amount disk space, as the number of versions and files on the branch
grows. If you do not need any of your old version history, you can create a new
(empty) branch, create a workarea, copy all the old content into the workarea,
then delete the old branch. Exercise extreme caution when doing this, as all
version and metadata information will be irrevocably lost.
91
92
CHAPTER 5
Work with Branches

TeamSite provides branches for different paths of content development. Branches
can be related to each other (for example, alternate language versions of the
same Web site) or they may be completely independent. Typically, each branch
contains all Web site content or a major section of it (such as a department) or a
collection of related content (such as the program files for a software application
or the image and text files for a book). Branches can be indexed and searched.
Overview
Control Branch Ownership and Administration
Create Branches
Integrate Content From Different Branches
Manage Branches
Work with Branch Properties
View Branch Users and Roles
93
Chapter 5 Work with Branches
Overview
Branches represent paths of content development. Branches contain exactly one
staging area, one or more editions, and one or more workareas. Newly created
branches are based on an edition of the parent branch. A staging area and an
INITIAL edition are created automatically when a new branch is added;
workareas must be created manually.
Content can be shared among branches. See Integrate Content From Different
Branches on page 97.
A locking model is one of the properties set when a branch is created. Locking
models specify locking behavior for all workareas on the branch and determine
whether users can edit files in different workareas at the same time. The role the
user has on a branch also sets locking behavior. The locking behavior for both the
branch and the role are combined to determine the locking behavior for a user in a
branch. See Set Locking Models on page 56.
All users can view public branches and their properties, but only users with a role
on the branch can view private branches. Only users in roles who have
authorization can reassign a branch to a new owner and update the branch
properties. Only some properties are editable after the branch is created.
Deleting branches removes them and their contents, including the version history,
from the system. Use caution when deleting branches.
To access branches
1. Select the Content tab.
2. Navigate to the store that contains the branches you want.
3. Open the main branch. If subbranches exist, navigate through them to the
branch you want.

You can specify the owner and group of the main branch of a new Content Store
by editing the main_owner and main_group lines in the [iwserver] section
of iw.cfg. When TeamSite is first installed, it uses the default option of root/
Administrator for main branch ownership as follows.
[iwserver]
main_owner=root/Administrator
main_group=root/Administrators
94
To change this setting on an existing main branch, you must use the Windows File
Properties to take ownership, or the command-line tool iwchgrp to change the
group on Windows and chown and chgrp commands to change the ownership
on Unix of the root directory of the main branch. However, if you edit the
main_owner and main_group lines and then create a new Content Store, the
new settings take effect on the new Content Store. For information about creating
a new Content Store, see the Web Solutions Authoring Components Installation
Guide.
You can specify the role that the owner of a branch has in the iw.cfg file. This
role will be added for the person who is the branch owner. This will be in effect
whenever a new branch is created. If nothing is specified, the Administrator role is
used.
[iwserver]
branch_owner_role=role_name
You can specify the role or roles that can administer branches (have access to the
Actions > Manage Branches menu item) with the following iw.cfg option:
[iwserver]
admin_roles=role_name, role_name
If a user has one of the roles specified in the admin_roles setting in the branch
being viewed, the Manage Branches menu item is enabled. This setting controls
whether the user sees the menu item; it does not give users in the roles any
additional privileges, such as adding users to a role on a branch. For that, you still
need to modify the role to have Delegate permission.
(Windows) You can specify a secondary master user other the local administrator
with the following iw.cfg option:
[iwserver]
secondary_admin_account=domain\user
95
Create Branches
Users with appropriate permissions can create subbranches within branches.
Figure 12 New Branch screen
To create a branch
2. Navigate to the branch under which you want to create the new branch.
3. Click New Branch in the view pane title bar.
4. Enter a name for the branch.
5. Enter a general description of the branch (for example, if content for a product
catalog is to be developed on the branch, you might enter Branch established
for the development of product catalog content.).
6. Your user name is displayed in the Owner field by default. Enter a different
user name if you want to assign the branch to another person. By default, this
user will have the Administrator role on the branch (unless a different role has
been configured using the branch_owner_role option in the iw.cfg file).
7. Select a locking option. See Set Locking Models on page 56 for information
about those options.
8. Enter the name of the edition you want to use as a starting point. The edition
must be from the parent branch.
96
9. Specify whether you want to you want the branch to inherit access from the
parent branch.Turn on Inherit from Parent to indicate that the users and their
roles should initially be identical to those on the parent branch. You can add
additional users later. This is the recommended setting. If this setting is not
turned on, you select the users and groups for this branch separate from the
parent branch. It is recommended that individual users be added to a
TeamSite group rather than being added individually to a branch.
10. Select Restrict Access to set up this branch so it is only displayed for users
or the groups that have permission to work in the branch. By default, a
restricted branch is shown in general listings of all branches, but users without
a role on that branch cannot go into that branch. (The branch_security
option in iw.cfg controls whether the name of restricted branches can be
seen.)
11. Click OK.
The branch is created and contains no workareas, one edition named
INITIAL, and a staging area. The staging area and INITIAL edition contain
a copy of the content from the edition you chose as a starting point.
After a branch is created you can create workareas and base them on the
branchs INITIAL edition, or any other editions you create on the branch.

You can integrate content from different branches manually, or through automated
workflow processes. This section describes the manual process; see the
Workflow Developer Guide for information about automated workflow processes.
The staging area and INTIAL edition in newly created branches contain a copy of
the content in the parent branchs edition on which they are based. Newly created
workareas contain a copy of the content in the branchs edition on which they are
based. Therefore, if you want to create subbranches with workareas that contain
content similar to that in the parent branch, create an edition for the parent branch
that contains the content you want, and base your subbranches on that edition.
You can then base the workareas on the INITIAL edition in each subbranch.
To manually integrate content from one branch to another
2. Navigate to the branch that contains an edition of the content that you want to
propagate.
3. Click Editions.
97
The view pane displays the Editions view. The Editions view lists the staging
area (top) and editions (most recent first).
4. Select the edition that contains the content you want, or navigate into the
edition and select the items you want to propagate if only a subset of the
editions content is desired.
5. Select a workarea.
6. Select an overwrite option.
7. Click OK.
The content is copied to the selected workarea.
After the content is copied to the workarea on the target branch, you can submit
the content and create new editions to meet your needs.
Manage Branches
If your role allows you to manage branches, you can use the Actions > Manage
Branches menu item from the Content tab to display the Manage Branches
screen. This screen lists the branches you can manage. From this screen, you
can delete or rename the branch. Each branch also has a Properties link so you
can modify the branch properties.
Figure 13 Manage Branches screen from the Actions menu
98

In the Manage Branches screen, click a Properties link to open the Branch
Properties screen.
It contains the following information:
Name. The name of the branch.
Location. The path to the branch.
Description. The text entered to describe the branch. You can modify this
field if you have permission to manage branches.
Created on. The date the branch was originally created.
Locking. The locking model that was selected when the branch was created.
Based on. The edition that was used to provide content for this branch.
Owner. The owner of the branch. You can modify this field if you have
permission to manage branches. You can use the Find link to search for the
user who will own the branch.
Private. The Restrict access check box determines whether the branch is
visible only for users with access to this branch or whether it can be viewed by
all TeamSite users.
Inherit from Parent. The Users and Roles check box controls whether users
and their roles should initially be identical to those on the parent branch.
Additional users can be added later. If this setting is not turned on, the users
and groups for this branch are selected separate from the parent branch.
If you make changes to the branch properties, click Save to save and close the
Branch Properties screen.
View Branch Users and Roles

The Users and Roles screen shows a list of users and groups who can work on
the selected branch or store.
As the following users or groups are always permitted to work on the specific
branch or store, they cannot be removed or their roles cannot be altered from this
screen.
Owner of the branch.
99
Inherited users or groups, if any. An inherited user or group can be identified

by a green arrow mark in the icon that represents the user or group.
At times, you may come across the same user or group being listed multiple times
with various roles. In such cases, the user or group will have cumulative
permissions from all the roles.
To access the Users and Roles screen
1. Navigate to the branch or store where you want to assign users or groups.
2. Click Configuration.
3. Click Users and Roles.
The roles that have been assigned to a user or group are listed next to the user
and are comma-separated. If there are too many roles such that they cannot be
displayed in a single line next to the user, mouse over the Roles column next to
the user to see the entire list of roles as a tooltip.
Options from this screen enable you to:
Assign Users and Roles. Assign a user or group to the branch.
Edit Roles. Modify the role that a user or group has in that branch.
Remove. Remove a user or group from working on that branch.
Download List. Download a list of users and roles who have permission to
work on this branch.
For more information about working with users and roles, see the ContentCenter
Professional User Guide.
100
CHAPTER 6
Manage TeamSite Access

This chapter discusses various procedures for managing access to TeamSite,
including assigning user roles, user authentication, and filtering user submissions.
Access Considerations
Working with Permissions
Share TeamSite Assets using Windows Groups
Enable the User/Group/Role Disk Cache
Operate System Group Membership
Authentication
Configure Submit Filtering
Access Considerations
Access to TeamSite is governed by the following two factors:
Windows/UNIX-related authentication permissions
TeamSite role-based access
Windows/UNIX file permissions control who has access to individual files and
directories. Windows/UNIX password authentication is used when logging in to
TeamSite. However, TeamSite access privileges govern the role a user has in
101
Chapter 6 Manage TeamSite Access
various branches and workareas. For example, to edit a file in a workarea, a user
must both be able to access that workarea (through TeamSite access privileges),
and have permissions for that file and its parent directory (through Windows/UNIX
permissions).
When adding a new user, you need to consider the following factors:
Whether the user will have access to the server.
The role the user will play in your TeamSite operations.
The content the user will be editing.
To decide what groups new users need to belong to and which workareas they
need to access, consider your existing groups and the content and workareas
they can access. Add new users to the groups that work on the same content that
they need to edit, and they will automatically have access to their workareas and
to their content files. If the new users need their own workarea, create a private or
shared workarea, but make sure that they own or have group-level (Unix) access
to the files that they will be editing. To change ownership or group (Unix) access to
files, see Change Group Ownership of Workareas on page 118.
When creating a new workarea, you need to decide:
What the name of the workarea should be.
Who will need to access the workarea (On Unix, this can be one person or one
person and a group).
What content the workareas owner and group should and should not have
access to.
Set permissions on your files according to the latter consideration. Remember that
a file cannot have different permissions in different workareas.If a files
permissions differs across workareas, you will encounter conflicts when you
submit files to the staging area.
NOTE The TeamSite log-in screen accepts passwords of
virtually any length. If you are using multi-byte characters,
the maximum length is 64 characters. On Unix, other
underlying authentication operating system mechanisms
(including /etc/passwd, PAM, LDAP, and SecureID) may
have different policies.
102

When users try to perform any action in TeamSite, the TeamSite server
automatically checks to see whether or not they have permission to perform that
action. TeamSite checks the following factors:
User roles. If you are attempting to perform any of these actions through
ContentCenter, you must be a user or member of a group associated with a
role authorized to perform the action on the branch.
Workarea permissions. A user has workarea permissions if he is either the

primary owner of a workarea or if he belongs to the group that has access to
the workarea.
File permissions. File permissions are Windows: Modify, UNIX:

read-write-execute permissions (unless otherwise specified) to a file.
Directory permissions. Directory permissions are Windows: Change, UNIX:

read-write permissions (unless otherwise specified) to a directory.
Permission overrides. Standard permissions are overridden for that role.
Not all of these factors apply to every action. TeamSite checks only the factors
that apply to the action being attempted. Generally, it checks as follows:
All the roles a user has on the branch are calculated. If any of these roles
allow the operation, permission is granted; otherwise the operation is not
allowed for the user on that object.
For operations on files in workareas:

The user must be the owner or a member of the owning group of the
workarea.
The user must have the appropriate Windows/UNIX file directory
permissions.
The file must meet the appropriate locking constraints.
The user must be the owner of the job or task (if applicable).
If the user has a role on the branch that has permission overrides set, these
restrictions may not apply.
Table 7 lists all of the operations that can be specified when roles are being
created or edited. It also shows the scope of each of the operations and the
permissions that are checked before a user can perform the function.
103
NOTE TeamSite workflow tasks may require users to perform actions

such as editing a file, submitting it to the staging area, or taking
ownership of a group task. To perform the task, the user must have the
ability to perform the action as specified in the table. For example, if
you assign a task that requires an Author to edit a file, the Author must
have workarea permissions, parent directory permissions, and file
permissions for that file in addition to the Edit operation in the role.
Table 7 Role operations and permission checking

Operation
Object Affected
Permissions Checked
Branch Administration
Create Branch
branch
Delete Branch
branch
Delete Edition
edition
Modify Branch
Properties
branch
Rename Branch
branch
Rename Edition
edition
ContentCenter Professional Operations

Show Reporting UI
Content Management
Compare
workarea, staging area,

edition, file, folder,
deleted file, symlink
(Unix)
User/group has file read permission on source and

destination areas.
Workarea is readable.
Publish Edition
branch
Submit
workarea, file, folder,

User/group is member of workarea.
Update Workarea
workarea, file, folder,

External Triggers
Create or Delete
External Triggers
104
Table 7 Role operations and permission checking (continued)

Operation
Object Affected
Permissions Checked
Files, Forms, and Folders

Copy Files and
Folders
file, folder, symlink
User/group has file read permission on source area.

User/group has file write permission on destination
area.
Delete Files and

Folders
Has operating system permission to delete files.

Satisfies branch and role locking constraints.
User is owner of task or job requesting deletion.
Download
file, folder
User/group has file read permission.

Edit
file, folder
User/group has file write permission.

User is owner of task or job requesting edit.
Generate Form

User is owner of task or job requiring the form
generation.
Lock File
file, deleted file, symlink
File is not locked.

Mark Private
Merge File
file, symlink

Modify File and

Folder Permissions

Has operating system permission to change files.
User is owner of task or job requesting edit.
105

Operation
Modify File Extended
Attributes
Object Affected
Permissions Checked
file, symlink

User is owner of task or job requesting modification.
Move Files and

Folders

Has operating system permission to rename files.
User is owner of task or job requiring the rename.
Preview File
Preview Form
Rename Files and

Folders
file, folder, branch,

edition, workarea,
staging area, symlink
file, folder, workarea,

symlink

Has operating system permission to rename files.
User is owner of task or job requiring the rename.
Revert File
Search
content store, branch,

workarea, staging area,
edition, file, folder,
file, workarea, symlink
Undo Changes

User is owner of task or job requesting change.
Unlock File
File is locked.
User/group is workarea owner or locked the file.
Unmark Private
106

Operation
View File History
Object Affected
Permissions Checked

New and Imported Content

Create File
folder

User is owner of task or job requesting file creation.
Create Folder
folder

User is owner of task or job requesting file creation.
Create Form
file, folder

User is owner of task or job requesting form
creation.
Import
file, folder

User is owner of task or job requesting file import.
Store Administration
Freeze Store
content store
Modify Store
Properties
content store
Thaw Store
content store
User Administration
Create TS Group
Create TS User
Delete TS User
Workarea Administration
Create Workarea
branch
Delete Workarea
workarea
107

Operation
Object Affected
Permissions Checked
Modify Workarea
Properties
workarea
User/role is member of workarea.
Rename Workarea
workarea
Workflow
Add Task Comment
task
User is owner of task or job.
Assign
file, folder, deleted file,

symlink
Attach to Task
task
Change Task Owner
task
Configure Workflow
Models
workflow
Detach From Task
task
End Job
job
User/group is owner of job.
Manage Workflow
Models
workflow
Modify Job
Properties
job
User/group is owner of job.
Modify Task
Properties
task
User is owner of job.
Publish Workflow
Models
workflow
New Job
Read Job Properties
job
Read Task
Properties
task
Retry Task
task
Return Group Task
task
Take Back Task
task
Take Group Task
task
View All Jobs
108

Operation
Object Affected
Permissions Checked
View All Tasks

View Job Details
job
View My Jobs
View My Tasks
Webview Workflow
Models
workflow
Workarea Access
By default, the workarea root file system permissions restrict any subdirectory
access. For example, the permissions on a subdirectory or a file specify that a
user can modify the subdirectory or file. However, permissions on the root
directory do not grant write permissions to the user. Therefore, TeamSite does not
allow the user to modify the file or subdirectory. To disable this check, set this
option to no.
[iwserver]
mask_workarea_access=no
When set to no, permissions on the workarea root directory affect only this
directory rather than the entire tree.
Branch and Workarea Security

Branch and workarea security determines whether or not users can see (in
ContentCenter) the names of branches and workareas they do not have access
to. By default, the branch_security and workarea_security lines in the
[iwserver] section of iw.cfg are set to off. This means that all branch and
workarea names are displayed to users even if they do not have permission to
access them (they see the name of the branch or workarea, but they cannot click
on it and [N/A] is displayed next to it).
You can configure TeamSite to not display the names of branches and workareas
in the ContentCenter if the user does not have read permissions by editing the
branch_security and workarea_security lines in the section of iw.cfg
as follows:
[iwserver]
branch_security=on
workarea_security=on
109
Default Permissions
Unix
You can configure the default permissions for branches, workareas, directories,
and files created using ContentCenter. Permissions on files created through the
file system interface are determined by your file system interface configuration (for
example, the Samba configuration).
To change the permissions, edit any or all of the four permission lines in the
[iwserver] section of iw.cfg to specify the octal values of the default
permission bits for newly created branches, workareas, directories, and files. The
default settings are as follows:
[iwserver]
branch_default_perm=775
workarea_default_perm=775
file_default_perm=664
directory_default_perm=775
The new settings only apply to branches, workareas, directories, and files created
after you have edited these lines and run iwreset.
Windows
You can control branch permissions on Windows by adding the
branch_default_perm parameter to the [iwserver] section of the iw.cfg
file as follows:
[iwserver]
branch_default_perm=0
The default behavior creates all branches with read access for the group
Everyone. If you add branch_default_perm=0 as shown, the group
Everyone is not added to the ACL for new branches created after this
configuration setting is added.
View File Permissions

Windows
When you click the Permissions link on a File Properties screen, the Permissions
screen is displayed. It shows the permissions set for the file and the inherited
permissions.
From this screen, you can perform the following operations:
110
Add Permissions. Click Add Permissions to display the Users and Groups
dialog box with the Permission field. Select the type of permission you are
granting (Read only, Full Control, Modify). Then search for and select users
and groups. Click Add or Add and Close when you finish.
NOTE Permissions can only be changed in ContentCenter

or with the iwaccess CLT and not through a browser
window. Use add-windows-permission option of the
iwaccess CLT to set permissions recursively for a folder
and the files or folders below that folder.
Edit. Click Edit opposite a user to display the Edit Permissions screen. The
Name and User display. Select a Permission option and save the change.
Delete. Click Delete to remove the user from the permissions. You are
prompted to verify the deletion.
Remove Inherited Permissions. When you click Remove Inherited

Permissions, you are asked if you want to make a local copy of the inherited
permissions.
Unix
When you click the Permissions link on a File Properties screen, the Permissions
screen is displayed. It shows the permissions set for the file.
From this screen, you can perform the following operations:
Change the permissions for the file owner.
Change permissions for the group.
Change permissions for others.
The permissions you can set are:
Read Only
Read and Write
Write Only
No Access
You cannot change the Execute permission.

Windows groups can be used to group users and to share TeamSite assets such
as branches and workareas. They may also be used, in conjunction with Windows
Access Control Lists (ACLs) to provide finer-grained access control for individual
directories and files. Over time, Windows has evolved, and the use of Windows
111
groups has evolved with it. Best practice for using groups with TeamSite depends
on the Windows Operating System version, and on the size and complexity of the
network in which it works. There are two basic scenarios:
A small-scale Windows 2003 network using Native Mode Active Directory.
A large-scale Windows 2003 network using Native Mode Active Directory.

NOTE TeamSite groups are an alternative to Windows
groups. The advantage of TeamSite groups is that they are
managed entirely within TeamSite whereas Windows
groups require management through the Windows
operating system. The advantage of Windows groups is that
they interoperate with Windows and AD.
The following sections explain how Windows groups are typically used in each of
these environments, and describe in what circumstances the new Active Directory
System Interface (ADSI) and disk-caching code can be used to improve
performance.
Group Usage with Native Mode Active Directory

When a Mixed Mode Active Directory installation is converted to Native Mode
operation, the local groups on the Primary Domain Controller become domain
local groups. This type of group is not available in an NTLM or Mixed Mode AD
environment.
The advantage of domain local groups is that they are known to all machines in
the domain in which they are defined. If domain local groups are used to share
TeamSite resources, the TeamSite server may run on any machine in the domain,
and moving the TeamSite server software to a different machine in the domain
does not require any changes to the group structure. In a Mixed Mode
environment, where the groups for sharing are tied to a particular machine rather
than to the domain, it is more difficult to swap out failed hardware or to move the
TeamSite server to a different machine.
In this environment, use domain local groups for sharing rather than traditional
local groups. To enable the use of domain local groups as groups for sharing, use
the following setting in iw.cfg:
[iwserver]
domain_local_groups=yes
TeamSite may be configured to use traditional Windows APIs to collect group

information, or it may be configured to use the Active Directory System Interface
(ADSI) supported by Windows. Use of the newer ADSI code may improve
performance if users and groups come from multiple domains and there are larger
112
numbers of users and groups. The groups for sharing must be domain local
groups rather than (machine) local groups. To select the ADSI code, specify the
following two lines in the iw.cfg file:
[iwserver]
use_adsi=yes
For larger installations, TeamSite may be configured to use cached user and
group information to significantly reduce the server's startup time. This feature
may be used with or without enabling the ADSI code. See Enable the User/
Group/Role Disk Cache on page 116.
Group Usage for Larger AD Networks

TeamSite is often installed on a machine that is part of a large, complex Windows
network. Such a network may contain many different domains, and each domain
may contain resources that must be shared across domains. In this scenario,
recommended practice is to use universal groups rather than global groups to
group users. Universal groups are known across all domains, and they may
contain users from any domain. (Global groups, by contrast, may only contain
users from their own domain). Like domain local groups, universal groups are only
available in domains that have been promoted to run Native Mode Active
Directory.
In this environment, where users are grouped in universal groups, and resources
are shared using domain local groups, the new ADSI code must be enabled in
iw.cfg:
[iwserver]
use_adsi=yes
When TeamSite users are in tsusers.xml, the TeamSite server may take
several minutes to start up as it collects user and group information. This startup
time can be significantly reduced when the server is configured to use cached
user and group information at startup time (this is on by default). See Enabling
the User/Group/Role Disk Cache and information later in this section.
In networks that are spread over large geographic areas and where TeamSite
users are spread among different domains, network response times may
encounter unusual delays when the TeamSite service is first started. The
TeamSite service is usually configured to start automatically after a Windows
reboot. At startup, TeamSite reads a variety of user and group information from
the Active Directory. This process may take several minutes. In extreme cases,
the time required to start the server may result in a system timeout, which occurs
when the server requires more than 10 minutes to start. These are possible
solutions for this problem:
113
Increase the timeout period from the default value of 600, which denotes 600
seconds (10 minutes), to a larger value. The timeout period may be set to a
different value by changing a parameter in the Windows Registry. The key to
be changed is found in the Registry at HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\iwserver\Parameters\Start
Timeout. Its value is the number of seconds that Windows should wait for the
server to start.
If the server startup time is unacceptably long, consider limiting the number of
inquiries that TeamSite must make to remote AD controllers. This is done by
limiting the number of domains that TeamSite is required to search using the
domain_list parameter in the iwserver section of iw.cfg. If it is not
practical to limit the number of domains, the need to query remote AD
controllers for group membership information can be reduced or eliminated
completely by careful choice of Windows group type for various uses. These
possible changes may improve performance:
Use universal groups exclusively to group users. This is recommended
practice from Microsoft (although other group types may be used). To

instruct TeamSite to restrict its user search to universal groups, set the
following parameter in iw.cfg:
[iwserver]
windows_groups_for_users=UNIVERSAL
If the groups used to share TeamSite resources are domain local groups
only, limit the TeamSite search for nested groups to groups nested in
domain local groups. This is done with the following iw.cfg setting:
[iwserver]
windows_groups_for_sharing=LOCAL
Use universal groups exclusively to share TeamSite resources.
Recommended practice is usually to share resources using domain local

groups, but in larger systems, significant performance gains may be made
if universal groups are used instead. If universal groups only are used to
share TeamSite resources, then the TeamSite server can use the Active
Directory Global Catalog for all its inquiries about groups for sharing. To
configure the server to restrict its groups for sharing to universal groups,
include the following settings in the iw.cfg file:
[iwserver]
windows_groups_for_sharing=UNIVERSAL
Manage Windows Groups for Best Performance

System response times are dependent on several factors:
114
The number of groups in the system.
The extent of group nesting.
The size of groups.
The number of TeamSite users.
The number of domains to be searched for users and groups.
The performance of the corporate network.
While some of these factors may be outside your control, response times can
usually be improved by trying some of the following:
Where practical, limit the number and size of groups used for sharing
TeamSite assets. Create dedicated groups, composed solely of TeamSite
users, instead of using large existing groups. This is especially helpful if the
existing operating system groups contain many members that are not
TeamSite users.
Limit the number of domains that contain TeamSite users and Windows
groups used for sharing. The domain_list parameter in the [iwserver]
section of iw.cfg should be set to include only domains that contain
TeamSite users and groups; see Domains to Use for Group Authentication
on page 134. A short list of domains can be searched faster than a long one.
If possible, use universal groups exclusively to group TeamSite users. Set

windows_groups_for_users=UNIVERSAL in iw.cfg. This is
recommended for most TeamSite installations.
Consider using universal groups instead of domain local or global groups to

share TeamSite resources. Set
windows_groups_for_sharing=UNIVERSAL in iw.cfg. This restriction
is not necessary for most TeamSite installations.
Where TeamSite users are in tsusers.xml and there are a lot of users,
groups or domains, leave the user/group/role disk cache enabled (the default
setting). This is a good practice for most large TeamSite installations.
In installations that do not include nested groups in the groups used for
sharing TeamSite assets, disable the nested group handling functions (see
Disable Group Nesting on page 116). This option is not frequently used, but
is sometimes chosen to improve response times where there are very large
numbers of TeamSite users.
115
Enable the User/Group/Role Disk Cache

Installations with large numbers of users and group memberships may benefit
from the use of a disk cache for users, groups, and roles. When the user/group/
role disk caching code is enabled, TeamSite saves a copy of the in-memory user,
group, and role cache to disk every time the in-memory cache is refreshed. This
disk image of the cache is used the next time the TeamSite server is started to
improve the server startup performance. Server startup time is faster.In the case
of Windows, particularly where TeamSite must search multiple domains and
process large amounts of user and group information, this feature also improves
the usability of the server during its first few minutes of operation. This improved
usability is due to the fact that the server does not have to wait until all of the
access information is collected from Windows before it allows access to particular
TeamSite resources.
The disk cache is enabled by default. To disable this feature in iw.cfg, set:
[iwserver]
enable_user_group_disk_cache=false
Disable Group Nesting

In some TeamSite installations, the Windows groups used for sharing TeamSite
assets do not contain any nested groups. In this case, server operation can be
sped up by disabling the code within TeamSite that handles nested groups.
Group nesting is enabled by default. To disable TeamSite's handling of nested
groups in iw.cfg, set:
[iwserver]
include_nested_groups=false
Enable the ADSI Debug Flag

On Windows, to examine the TeamSite group information in detail, use the
debugging flag to examine the cache of nested groups that TeamSite builds on
startup. Enabling this flag causes TeamSite to write the contents of the ADSI
group cache to the iwtrace log.
This flag is disabled by default. To enable the group debugging flag in iw.cfg,
set:
[iwserver]
debug_adsi=true
116
Additional Tools for Debugging

Several software tools can be used to examine the group memberships of
TeamSite users on Windows.
The iwdebug command-line tool can be used to display the contents of the
TeamSite internal cache at any time the server is running. The output from
iwdebug commands is written to the iwtrace log. The -g option lists
group information, and the -u option lists each user in the cache and the
groups of which that user is a member. The two options can be used
together, if desired: iwdebug -g -u.
The iwldapsearch command-line tool can be used to search an Active

Directory or an LDAP directory for user or group information. It uses syntax
similar to the ldap search utilities that accompany most LDAP server
installations. However, unlike the generic LDAP search tools, it knows about
any LDAP configuration information found in iw.cfg. For example, if
TeamSite roles are kept in an LDAP attribute called description, the
following command can be used to retrieve the names of all the TeamSite
Authors in the system: iwldapsearch "description=author" dn.
The iwldapsearch utility may be used even if there is no LDAP or Active
Directory configuration information in iw.cfg. In this case, the server (host)
name and search base need to be specified. The following command lists all
of the Windows groups on an Active Directory server called
qa.qadomain.com:
ldapsearch -h qa.qadomain.com -b "cn=users,dc=qadomain,dc=com"
"objectclass=group" name

TeamSite supports two types of groups for user management: those managed
through standard Windows functions/UNIX commands (referred to as operating
system groups) and those managed through TeamSite (referred to as TeamSite
groups). Workareas can be shared by either type of group. For users to have
access to a particular workarea, they must either be the owner of the workarea or
a member of the workareas group. TeamSite uses Windows/UNIX groups for
access control; it also uses TeamSite groups.The UNIX groups can be managed
with standard UNIX commands.
To create a UNIX operating system group
1. Open the /etc/group file in a text editor.
2. Add a new line to the file using the following format:
117
groupname:*:gid:username1,username2,username3
For example, the entry for the group allauthors might look like this:
allauthors:*:2000:pat,andre,chris
3. Save and close the file.

To add a user to a Windows/UNIX group
Windows:
1. Select Start > Programs > Administrative Tools > Computer Management.
The Computer Manager is displayed.
2. In the Computer Manager, select Local Users and Groups > Groups.
3. Double-click the group that has access to the workarea to which you want to
add the user.
The Properties window for the selected group opens.
4. Click Add.
5. Select the user you want to add from the list or type the user name, then click
OK.
Unix:
1. Open the /etc/group file.
2. Locate the group that has access to the workarea to which you want to add
the user.
3. Add the name to the list of usernames that follows it. Usernames must be
separated by commas.
If the user is an Administrator and you want that user to have Administrator
privileges for a branch, add the user to the group of Administrators for that
branch.
You can add any number of users to a group.
Change Group Ownership of Workareas

To change which group has access to a workarea:
1. From the Command Prompt, navigate into the directory containing the
workarea.
2. Use the iwchgrp.exe command (Windows) (see <Emphasis>TeamSite
Command-Line Tools) or the chgrp command (Unix) to change the
workareas group. You can change either the OS group or the TeamSite
group. The chgrp command can only be used to change the OS group.
118
TeamSite only checks the primary group owner of a workarea and does not
rely on ACLs to determine workarea ownership.
You can also change ownership of workareas through ContentCenter
Professional in the Workarea Properties screen.
Example
Unix
In this example, user Chris changes the group for one of the workareas on the
sales subbranch. First, he navigates into the directory containing the workareas.
Then, he looks at the existing workareas and learns that Andre has two
workareas, one private (andre1) and one shared with the group demoauthor
(andre2). Chris has one private workarea (wa1). He uses the chgrp command
to change the group on his workarea, then checks the results. After this change,
all members of the group demoauthor can access all files and directories in the
andre2 and wa1 workareas.
% cd /.iwmnt/default/main/sales/WORKAREA
% ls -la
total 3
drwxrwxr-x 27 andre
nobody
512 Apr 23 17:07 andre1
drwxrwxr-x
3 andre
demoauthor
512 Apr 17 11:52 andre2
drwxrwxr-x
2 chris
nobody
512 Apr 17 11:37 wa1
% chgrp demoauthor wa1
% ls -la
total 3
drwxrwxr-x 27 andre
drwxrwxr-x
3 andre
drwxrwxr-x
2 chris
nobody
demoauthor
demoauthor
512 Apr 23 17:07 andre1

512 Apr 17 11:52 andre2
512 Apr 17 11:37 wa1
Web Server Group/UID

The web server group/uid setting should be set to any group/uid that allows
the web server to see the web content as an outside viewer would see it, in order
for users to be able to preview the Web site like any external user would. On Unix,
specify a single user ID. Because many external browsers access the web server
as nobody, this is used as the default.To improve security, you are encouraged to
change your web server to another user other than nobody and change the value
of webserver_uid. To change the web server group/uid setting, edit the
webserver_groupuid line in the [iwserver] section of iw.cfg. If iw.cfg
does not contain this line, add it as shown:
[iwserver]
webserver_uid=web_uid (Unix)
webserver_group=IWGROUP (Windows)
119
On Windows, this sets a group of users, all of whom have full file system access.
If this line does not exist, the group Everyone is used.
Group Remapping
Unix
This option provides a workaround for a limitation of NFS. When NFS checks the
operating system group that can access a file against the groups that a user
belongs to, it only checks the first sixteen groups that the user belongs to.
Therefore, if the group on the file is the seventeenth (or higher) group that the
user belongs to, NFS will incorrectly deny the user access to the file (this applies
only to operations performed through the file system).
The map_secondary_to_primary option in iw.cfg works around this
problem. Because TeamSite does not have NFSs sixteen-group limitation, it first
determines whether a user should have group-level access to the file. Then, if the
map_secondary_to_primary option is turned on, it maps the files group to the
users primary group. Therefore, if you check the gid on a file using the file
system, it could return a gid different from the true gid of the file. To find the files
true gid, use the File > File Properties menu item in TeamSite or the iwattrib
CLT.
By default, map_secondary_to_primary_gid=no, to turn group remapping
on, edit the line in the [iwserver] section of iw.cfg to read as follows:
[iwserver]
map_secondary_to_primary_gid=yes
Recommendation: Use TeamSite groups.
Maintain the GID

Unix
To disable all setgid behavior through ContentCenter, set honor_setgid to
false.
[iwserver]
honor_setgid=true|false
When a file is imported or renamed, the group for the target directory is applied to
the file. By default, this is set to true. If you do not wish the gid to be applied to
import and rename operations, set this option to false.
[iwserver]
honor_setgid_on_rename=true|false
To turn off all setgid functionality during a ContentCenter Import, you must set
honor_setgid_on_rename=false and honor_setgid=false.
120
Authentication
Authentication
Authentication involves determining whether users can access TeamSite
resources. The tsusers.xml file maintains information on TeamSite users.
Operating system users are usually identified as TeamSite users and added to
this file through the Manage Users option in the ContentCenter Professional
Administration Console that is available to Master users.
OS and non-OS users can be identified in LDAP or an external source.
The LDAP files can be set up in one of two ways:
Users in the LDAP file display in the Administration Console and can be
added through the Manage Users screen or with the iwuseradm CLT.
Users in the LDAP file are added as TeamSite users through a

synchronization process that reads the LDAP files; they cannot be added
through the Administration Console or using the CLT (refer to Synchronize
LDAP Users on page 127).
Store TeamSite Users

Potential TeamSite users must be identified in a database or must have operating
system access. This database may be an LDAP file or an external database.
These databases are identified in the user_databases.xml file. An LDAP
database can contain either OS users or non-OS users; they cannot be mixed.
The user_databases.xml File

TeamSite reads information on user databases from the user_databases.xml
file. You must edit this file manually. The file is stored in iw-home/conf\roles
directory; and example file ships with TeamSite. Databases identified in the file are
used to authenticate TeamSite users. Only configurations for LDAP databases
and external databases are supported. Define as many LDAP or external
databases as are required for your site.
NOTE LDAP files that contain users that are to be added
through synchronization include the attr_sync attribute
described in Synchronize LDAP Users on page 127.
The following code is an example of the user_databases.xml file that defines

two LDAP databases and two external databases. Databases set up using these
formats are used to add TeamSite users through the iwuseradm CLT or the
Administration Console.
<iwuser_databases>
121
<iwldap id="ldap_1" display_name="my ldap_1" os="t">

<server value="ishuffle-sol.amer.interwoven.com" />
<port value="389" />
<search_key value="uid" />
<ssl_port value="0" />
<CAFile value="" />
<dnBase value="marketing.interwoven.com" />
<account value="admin" />
<password value="52616e646f6d4956c82bafa0f007
0585907d439c34792e66c55ade1fd1e21fc4" />
<attr_email value="mail" />
<attr_display_name value="cn" />
</iwldap>
<iwldap id="ldap_2" display_name="my ldap_2" os="f">
<CAFile value="" />
<dnBase value="sales.interwoven.com" />
0585907d439c34792e66c55ade1fd1e21fc4" />
</iwldap>
<external-source id="ext_src_1" display_name="my ext_src_1">
<authentication_source value="http://localhost/iw/my_prog1"/>
<param_username value="username"/>
<param_password value="password"/>
<timeout value="500"/>
</external-source>
<external-source id="ext_src_2" display_name="my ext_src_2">
<authentication_source
value="https://host:443/iw-bin/
sample_extsrc.cgi"/>
<CAFile value="c:\iw-home\iw-webd\conf\client\cacert.pem"/>
<timeout value="500"/>
</external-source>
</iwuser_databases>
122
Authentication
Table 8 describes each of the attributes in the user_databases.xml file.

.
Table 8 Attributes for user_databases.xml file

Attribute or Element
Description
id
Unique id that identifies a particular LDAP server or external source.
display_name
Identifies the LDAP server or external source in the ContentCenter

Professional Administration Console. If it is not defined, the id attribute is
used.
os
Boolean value that indicates whether the users from this LDAP server are OS
users (t) or non-OS users (f). The default value is f. Each LDAP
configuration can contain either OS users or non-OS users, but not both.
server
Name or IP address of the LDAP server.
port
Port for the LDAP server (default is 389).
search_key
Name of the LDAP attribute that holds the user account names (default is
uid).
ssl_port
Port that the LDAP server uses to communicate when SSL is in use. This is
assumed to be port 636.
CAFile
The location of your CA certificate database file. This entry must be in the
Netscape cert7 format.
An example default cert7.db file that contains the certifications for a
variety of Certification Authorities is found in the TeamSite installation in the
directory iw-home\tools\db\netscape\cert7.db.
dnBase
Specification of the DN base location according to LDAP search syntax.
account
Specifies the Distinguished Name of the LDAP/Active Directory user account

to be used for LDAP/Active Directory searches. This is not a simple account
name, but a complete Distinguished Name (DN) for a user.
password
Encrypted version of the password (refer to The Password Attribute on

page 124).
attr_email
Used to query the LDAP server for email addresses. The default is mail. If
the value is specified with an empty string, LDAP will not be queried for this
attribute.
attr_display_name
Used to query the LDAP server for user display names or common names.
The default is cn. If the value is specified with an empty string, LDAP will not
be queried for this attribute.
123
Table 8 Attributes for user_databases.xml file (continued)

Attribute or Element
Description
authentication_url
A URL that TeamSite uses to authenticate a user from the external source.
Username and password are included as URL parameters and the command
is posted to the external source server. Both HTTP and HTTPS protocols are
supported. If HTTPS protocol is used, the filepath for the Certificate Authority
file must be specified using the CAFile attribute.
param_username
Used with param_password to construct the URL for authentication. The

default is username.
param_password
Used with param_username to construct the URL for authentication. The

default is password.
timeout_value
Specifies how long (in ms) to wait for the HTTP response; default is 500 ms.
The Password Attribute

The password value stored in user_databases.xml is an encrypted version
of the password. Blowfish encryption software is used to encrypt/decrypt the
password.
Since the user_databases.xml file has to be maintained manually, you need
to manually encrypt the password and save the encrypted password in
user_databases.xml.
To encrypt a LDAP login password
1. Define IWCLT_PASSWORD environment variable as the actual password.
2. Run the following CLT to generate the encrypted password:
iwuseradm encrypt-userdatabase-pwd
The CLT outputs a 64-bit password like the one shown below:
52616e646f6d4956c82bafa0f0070585907d439c34792e66c55ade1fd1e21fc
4
3. Copy the 64-bit encrypted password to the corresponding LDAP server

configuration in user_databases.xml file.
To verify whether an encryption is correct
1. Define IWCLT_PASSWORD environment variable as the actual password.
2. Run the following CLT to verify an encryption:
iwuseradm encrypt-userdatabase-pwd -v
52616e646f6d4956c82bafa0f0070585907d439c34792e66c55ade1fd1e21fc
4
124
Authentication
The CLT outputs YES if the encrypted password matches the original password.
When you use the ContentCenter Professional Administration Console to
manage users, you can search for users in these databases.
Create a Certificate Authority Database in the cert7.db Format

Certificate Authority (CA) Certificates used by the TeamSite server for SSL must
be in the cert7 format. This section describes how to create a new CA database
in the cert7 format and how to add a CA Certificate to the database. The Sun/
Netscape utilities keyutil and certutil are used for this procedure. Contact
Customer Support for information about where you can obtain these utilities.
1. Create a new (empty) key3 database file.
This step is a requirement of the old Sun/Netscape keyutil and certutil
utilities. The key database must exist even though CA certificates do not
require keys. Since it will be empty, we will not create a password to protect its
contents when we create it. The keyutil program is used for this step:
keyutil -C
2. Create a new cert7 database containing your CA certificate.

The following command creates a new cert7.db file and adds a single new
CA certificate file to the database. The certutil program is used for this step:
certutil -A -i certicicateToAdd -n nickName -t "C,C,C"
Replace certificateToAdd in this command with the name of the file that
holds the CA certificate you want to put into the database.

Replace nickName in this command with the name that the certificate
will be known by in the database. The value for nickName is normally the
same as the CN of the issuer for your certificate.
For example:
certutil -A -i CA.crt -n "Acme Manufacturing, Inc. CA" -t
"C,C,C"
You will now have three new files in your directory: cert7.db, key3.db, and
secmodule.db. These files should all be copied to the same directory. They
should also match what is specified in the authentication section of iw.cfg
and, if used, in the XML files that specify user databases.
3. Verify that the new database exists and contains the CA certificate.
List all of the certificates in the database. Look for the name of the one you just
added. The utility adds a variety of standard CAs, so there will be other
certificates included with the one you added.
125
On the line that contains the name of the certificate you just added, you
should see C,C,C. (C is the code for a Certificate Authority; the three Cs
indicate that this authority can issue certificates for any purpose). The
command to list all of the certs is:
certutil -L
Next, verify that the certificate you added is valid. The command to show
detailed information about the new certificate is:

certutil -L -n "Acme Manufacturing, Inc. CA"
Replace Acme Manufacturing, Inc. with the value you used for
nickName in Step 2. This command should result in the display of about
a page of information with the details of the certificate.
Check that the CN field for Issuer is the same as the one you typed
when you created the database.

Check the dates under Validity.
The Not before date should be no later than todays date.
The Not after date should be some date in the future, preferably a
few years into the future. (The Not after date is the expiry date for the
certificate.)
4. Create a java truststore (used by the Interwoven Application Container to

support LDAP search and browse functions):
keytool -keystore truststore -import -alias myCA -file myCA.crt
-trustcacerts
keytool is available in the java SDK that ships with TeamSite.

5. Copy the files to the destination you specified in your iw.xml file (and
user_databases.xml file, if used).
Note that the CAFile tag in user_databases.xml expects a directory
name where the CA files exist, not the name of the cert7.db file. These files
should all be copied to a single directory. They should also match what is
specified in the authentication section of iw.cfg and, if used, in the XML files
that specify user databases. Be sure that the .db file(s), certificate file(s) and
truststore are readable by iwts and iwui (chmod 644 is recommended for most
installations).
126
Authentication
Create a Certificate Authority Database in the cert7.db Format

for Linux
For Linux, the process is the same except for the following:
The version of certutil which ships with most Linux distributions creates a
cert8.db file which is not compatible with TeamSite. To create a cert7.db file,
download an older version of NSS from
ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/
NSS_3_2_2_RTM/Linux2.2_x86_glibc_PTH_OPT.OBJ/nss-3.2.2.tar.gz
Use the certutil included in that download.
Synchronize LDAP Users

The LDAP synchronization process (iwldapsync) reads the LDAP databases to
synchronize the users contained in the databases with TeamSite users. It adds
new users, deletes obsolete users, and updates user attributes, such as email
addresses, based on changes made to the LDAP databases.
Identify LDAP Synchronization Files

The description of a LDAP file in user_databases.xml must contain the
attr_sync attribute to allow users in that LDAP file to be automatically created
as TeamSite users. The synchronization process updates attributes of LDAP
users in TeamSite or removes TeamSite users that are no longer in LDAP.
When attr_sync is defined, TeamSite users from the LDAP file can only be
created by the synchronization process; TeamSite users from this LDAP file
cannot be added or deleted through the Administration Console or using the
iwuseradm CLT.
The following section of code is used in user_databases.xml to describe an
LDAP file from which the users will be synchronized. The attr_sync name is the
name of the LDAP attribute that identifies TeamSite users (in this example it is
named description). The attr_sync value contains possible values in that
field that provide TeamSite user information.
<iwldap id="ldap_1" display_name="my ldap_1" os="f">
<CAFile value="" />
<dnBase value="marketing.interwoven.com" />
d439c34792e66c55ade1fd1e21fc4" />
<attr_email value="mail" />
127
<attr_display_name value="cn" />

<attr_sync name="description"
value="master,tsuser,ccpro,ccstd,ccpro_only,ccstd_only" />
</iwldap>
NOTE If attr_sync attribute is not defined, LDAP users
are added to TeamSite through the ContentCenter
Professional Administration Console or the iwuseradm
CLT.
Modify LDAP Schemas to Store TeamSite User Interface

Information
If you do not have an existing attribute in your LDAP schema where you can store
TeamSite user interface information, add a new attribute to your LDAP schema as
described in this section. If you already have an attribute where you can store
TeamSite interface information, start the procedure with Step 3.
1. Add an auxiliary class to an existing object in the schema.
2. Add a new attribute to that object that will contain the TeamSite information.
This attribute is the name specified for attr_sync.
3. Your LDAP administrator can now assign TeamSite interface information to
users configured in your LDAP server using the servers administration tools.
The information for this attribute indicates whether the user is a TeamSite user
or a TeamSite Master user and the ContentCenter interface the user can
access.
The following are the valid values (they are case-sensitive):
master. This user is a TeamSite Master user.
tsuser. This user is a TeamSite user.
ccpro. ContentCenter Professional is displayed when the user logs in. A
link at the top of the screen allows them to move between ContentCenter
Professional and ContentCenter Standard. When logging in later, the user
returns to the interface they were using when they logged out.
ccpro-only. ContentCenter Professional is displayed. The user cannot
switch to ContentCenter Standard.

ccstd. ContentCenter Standard is displayed when the user logs in. A link
at the top of the screen allows them to move between ContentCenter

Standard and ContentCenter Professional. When logging in later, the user
returns to the interface they were using when they logged out.
ccstd-only. ContentCenter Standard is displayed. The user cannot
switch to ContentCenter Professional.
128
Authentication
Configure TeamSite to Work Without an Anonymous Bind

In some installations, anonymous binds to LDAP/Active Directory are not
permitted for security reasons. If you cannot use an anonymous bind to LDAP/
Active Directory to read user names, you can establish a dedicated LDAP/Active
Directory user account to use for user authentication. All searches for users
Distinguished Names are done using this account instead of an anonymous bind.
DistinguishedName specifies the Distinguished Name of the LDAP/Active
Directory user account to be used for LDAP/Active Directory searches. This is not
a simple account name, but a complete Distinguished Name (DN) for a user. For
example:
account=cn=TeamSite,cn=Users,ou/dc=myCompany,c=us/dc=com.
The password specifies the encrypted password of the LDAP/Active Directory

user account that matches account.
This information is included in the user_databases.xml file using the
account and password attributes.
LDAP Synchronization
Synchronization is done with the iwldapsync CLT (refer to the TeamSite
Command-Line Tools for options on this CLT). This CLT is normally launched
when TeamSite starts up and is run periodically as defined by
ldapcache_thread_delay in the iw.cfg file. The default is every 24 hours.
The CLT can also be run manually.
You can enable logging of the LDAP synchronization process using the
log_ldap_sync option in the iw.cfg file; logging is on by default. The
ldap_sync_retry_count is used to specify the number of retries to connect to
the TeamSite server when the LDAP synchronization process runs. By default, the
retry count is 12, which means that TeamSite waits about 60 seconds to start
responding to client requests.
Set these options in the [authentication] section as:
[authentication]
ldapcache_thread_delay=1440
log_ldap_sync=yes
ldap_sync_retry=12
TeamSite automatically synchronizes TeamSite users up to the search limit set by

the LDAP server for each LDAP configuration. If the LDAP server is configured to
limit the number of records returned by a search query to a number that is less
129
than the number of TeamSite users in the LDAP database, no LDAP users will be
found during the synchronization. Try the following options to address the issue
when using LDAP synchronization:
Divide the users under different LDAP subtrees (under different base DNs)
and define multiple LDAP databases in TeamSite such that the number of
TeamSite users under each LDAP database configuration is no more than the
LDAP search limit.
Increase you LDAP search limit to the number of TeamSite users configured in
LDAP.
The other option is to add LDAP users to TeamSite using either the Administration
Console or the iwuseradm CLT instead of using the LDAP synchronization
procedure.
Impact of Using Non-OS Users in TeamSite

Enabling non-OS users in TeamSite impacts the way TeamSite operates in some
areas. You should be aware of the following:
130
The file system interface is not available for contents that belong to non-OS
users. An OS user, with the exception of the TeamSite global OS user
(iwguser), will not be able to view TeamSite content properties that belong to
a non-OS user through the file system interface.
File permissions cannot be set for multiple non-OS users or non-OS groups on
a single asset because non-OS users or groups are mapped to a single OS
user or group.
Non-OS user functionality is only available from sciface, CSSDK, and the
ContentCenter interfaces. There is no file system support for Non-OS users.
From the file system, all non-OS users appear as iwguser.
Non-OS users can only be added to non-OS groups.
While LaunchPad works for non-OS users, the Direct Edit feature that uses
the file system interface will not be available on content belonging to non-OS
users.
Non-OS users cannot use the Perl compiler to compile presentation

templates. The XSLT PT compiler must be used.
Non-OS users cannot be the owners of external tasks since OS impersonation

is not possible; use an URL external task. If a non-OS user attempts to
execute an external task, the task is not launched and an error is displayed in
the iwjoberrors.log file.
TeamSite does not manage LDAP user passwords (such as expiration

information). You need to manage LDAP user passwords.
Authentication
User Authentication
Unix
TeamSite can be configured to authenticate users by the following methods:
External source. Users credentials are checked against a customer-specified

file that is in the same format as /etc/passwd or a shadow password file.
The file name is specified in the [authentication] section of iw.cfg
using the password_file=fileName parameter.
Local. Users credentials are passed to the UNIX user authentication. If there
is a shadow password file, it is used to verify the credentials. If no shadow
password file is available, use the /etc/passwd file (this is the default
method).
Pluggable authentication modules (PAM). Users credentials are passed to a

PAM for verification.
Single Sign-On. If all authentication is performed by an SSO product such as

SiteMinder, you should specify only sso in authenticate_by. If authentication is
done by an SSO product and by other means as well, you can use the sso
setting together with other authenticate_by settings such as pam, local, and
file.
Complete the following procedure to specify the type of authentication used by

TeamSite:
1. Add the following line to the [authentication] section of iw.cfg:
authenticate_by=mode
where mode specifies one or more of file, local, sso, or pam.

You can separate multiple entries by commas or spaces, and you can specify
precedence. For example, if you specify authenticate_by=file pam, the
file is checked first. If this check fails, pam is checked next.
2. If file is specified as one of the possible authentication modes (that is the
[authentication] section contains the line authenticate_by=file),
add the following line:
password_file=absolute-path-to-file
where absolute-path-to-file is the absolute path to a file containing

encrypted user passwords using the same format found in /etc/shadow.
The section should look like this:
[authenticate]
authenticate_by=file,pam
password_file=absolute-path-to-file
131
If pam is specified as one of the authentication modes (as shown), TeamSite

communicates with pam to perform account management functions on the
authenticated user. Account management functions includebut are not
limited tocontrolling expired passwords and login time restrictions.
3. To configure TeamSite not to perform account management functions, add the
following line to the [authentication] section of iw.cfg:
pam_do_acct_mgmt=no
Every LDAP directory has a schema that describes the objects and attributes that
are found in the directory. For example, you could have an object called user and
an attribute postaladdress. To configure TeamSite to perform user
authentication, you can either modify an existing attribute to represent TeamSite
users or create a new one; this procedure is described in Modify LDAP Schemas
to Store TeamSite User Interface Information on page 128.
TeamSite and PAM Configuration File Interaction

Solaris
By default, on TeamSite for UNIX, PAM controls authentication by using entries
tagged with the teamsite service name stored in the /etc/pam.conf file. You
can specify that PAM use /etc/pam.conf entries tagged with something other
than teamsite by changing the pam_service line in the [authentication]
section of iw.cfg.
For example, to specify that TeamSite instead use the lines in /etc/pam.conf
that also control the telnet program, edit the pam_service line in iw.cfg so
that it reads as follows:
[authentication]
pam_service=telnet
The format of /etc/pam.conf is described in detail in the pam.conf(4) man

page. You should configure TeamSite with its own entries in /etc/pam.conf
using the service name teamsite (or whatever service name you specify for
pam_service in iw.cfg). Only the auth and account modules in /etc/
pam.conf are used for TeamSite authentication. If no entries are present for
TeamSite in /etc/pam.conf, PAM uses whatever settings are specified for the
other service. Note that this scenario is not recommended.
The following lines in /etc/pam.conf produce behavior equivalent to the
traditional TeamSite authentication method:
teamsite
teamsite
132
auth
account
required
required
/usr/lib/security/pam_unix.so.1
/usr/lib/security/pam_unix.so.1
Authentication
To use a third-party PAM module, specify its path instead of /usr/lib/

security/pam_unix.so.1. For more information about PAM, see http://
www.sun.com/software/solaris/pam/.
NOTE TeamSite is tested with the pam_ldap and
pam_unix modules that ship with Solaris. No other testing
or certification of any vendor's PAM modules is performed.
If you want to use PAM with TeamSite, you should do a
proof-of-concept to verify that the particular PAM module will
work satisfactorily with TeamSite in your environment.
Linux
Linux systems do not contain the file /etc/pam.conf. Instead, Linux systems
use individual PAM configuration files in the directory /etc/pam.d.
The following entry is required in the iw.cfg file to enable PAM on Linux:
[authentication]
pam_service=filename
The filename should be the name of a PAM configuration file located in /etc/
pam.d. For example, you would use the following entry to specify that TeamSite
use the PAM settings for sudo located in /etc/pam.d (assuming that a
configuration file named sudo already exists in /etc/pam.d):
pam_service=sudo
If this entry does not exist in the iw.cfg file, PAM does not default to any other
settings, and therefore is not enabled.
In many installations, the content of the sudo file is an acceptable starting point
for PAM configuration. The sudo file typically contains the following:
#%PAM-1.0
auth
account
password
session
required
required
required
required
pam_stack.so
pam_stack.so
pam_stack.so
pam_stack.so
service=system-auth
service=system-auth
service=system-auth
service=system-auth
The file named in the pam_service entry must be located in /etc/pam.d and
must be owned by root.
The Authentication Daemon

TeamSite for UNIX includes a daemon called iwauthend that processes PAM
login requests on behalf of the TeamSite server.
133
The iwauthend daemon is automatically installed by the TeamSite installation

program and is started with TeamSite. It requires no configuration and logs its
internal issues to the iwauthend.log file, which is located in iw-home/local/
logs.
Domains to Use for Group Authentication

Windows
To configure which domains are used for group authentication, configure the
domain_list line in the [iwserver] section of iw.cfg. This setting can be
used to reduce the startup time for TeamSite, by limiting the number of domains it
tries to authenticate against.
By default, TeamSite authenticates against all domains. To limit the number of
domains used for group authentication, add the following line to the [iwserver]
section of iw.cfg:
[iwserver]
domain_list=domain1,domain2,domain3
You can include any number of domains in this list.

You can explicitly specify the domain controller that should be used for a particular
domain. This option should not be used if the use_adsi parameter is enabled.
[iwserver]
domain_list=domain1, domain2:domain_controllerA, domain3
In this example, the primary domain controller would be used for first and third
domains, while domain_controllerA would be used for the second domain.
NOTE Do not confuse this line with the domain_list line

in the [iwcgi] section.
Log Users and Groups

Windows
TeamSite can be configured to record in its log files every authenticated user and
all groups with which each user is associated. To activate this feature, add the
following line to the [iwserver] section of iw.cfg:
[iwserver]
show_user_list=true
134
Once this feature is activated, each time TeamSite is restarted, it logs all users in
the roles files and their associated groups in iw-home\local\logs\
iwtrace.log. Log files use the following format:
user: username [associated groups]
NOTE If this feature is left on for too long, your log files will
grow extremely large.

The TeamSite server enables you to automatically change file attributes, including
uid/owner, gid/group, and permissions/ACLs, at the time that you submit a file.
This functionality enables you to automate the task of defining the permissions
associated with each file stored in TeamSite. The submit filter performs the
specified operation on files immediately before they are submitted, so that
changes are made to the files in the workarea, which are then submitted.
The submit.cfg File

On startup, the TeamSite server reads a configuration file named submit.cfg in
the iw-home\local\config\ directory (unless the location of this file is
otherwise specified in the [locations] section of iw.cfg). The submit.cfg
file contains rules to match file and workarea patterns to specific actions to
perform when files and directories are submitted.
NOTE This file is not present by default; you need to create

the file in the location specified.
The submit.cfg file uses the following format:

case-sensitive = [yes|no]
rules
{
workarea1_pattern
{
file_pattern1 { action1 action2 ... }
file_pattern2 { action3 action4 ...
...
}
workarea2_pattern
135
{
...
}
...
}
where:
The case-sensitive statement specifies whether or not the rules matching

should ignore the case of the path names. If case-sensitive is not specified,
the value is assumed to be no on Windows, and yes on Unix, so that
rules matching does not ignore the case of the path names.
workarea#_pattern is used to match a workarea to the set of file rules to

apply when a submit is done from that workarea. Each pattern can only be
specified once, and the first match is used. For Solaris, and Windows, the
syntax of the pattern is regex(5) (extended syntax). For AIX, use the POSIX
1003.2 extended regular expression syntax. For more information on regular
expressions, consult a reference manual such as Mastering Regular
Expressions, by Jeffrey Friedl., or read the man page (Solaris only):
% man -s 5 regex
The match is done against the path name of the workarea, starting with \
default\main.
file_pattern# is used to match a file or directory to the set of actions to

perform on it when it is submitted. Each file or directory pattern can only be
specified once, and the first match is used. The syntax of the pattern is
regex(5) (extended syntax) for Solaris, or the POSIX 1003.2 extended
regular expression syntax for AIX.
The match is done against the path name of the file or directory relative to the
workarea.
action# is one of:

Unix:
uid=name
gid=name
perm=octal number
amask=octal number
omask=octal number
expand_rcs_macros=[yes|no] (see Enable Macro Expansion on
page 143)
136
and specifies the operation to perform on the file or directory being submitted.
uid=, gid=, and perm= specify new values for these attributes. amask=
specifies a bit mask to and to the existing mode of the file or directory.
omask= specifies a bit mask to or with the existing mode of the file or
directory.
Windows:
owner = name (changes the owner of the file or directory)
group = name (changes the group of the file or directory)
setaccess = ACL (replaces the access control list for the file or directory)
changeaccess = ACL (modifies the access control list so that the specified
users have only the specified rights)
where name is one of:
username
groupname
domainname\username
domainname\groupname
and where ACL (Access Control List) contains one or more Access Control
Entries (ACE), as follows:

name:perms (a single ACE, to specify a single user or group)
{ name:perms, name:perms, ... } (multiple ACEs, to specify multiple users
or groups)
where perms specifies the permissions granted to the specified user or
group and is either any sequence made of the characters:
R (read)
W (write)
X (execute)
D (delete)
P (change permissions)
O (take ownership)
or one of the preset combinations:
ALL (RWXDPO)
NONE (none)
READ (RX)
WRITE (W)
CHANGE (RWXD)
137
For example:
setaccess={ andre:ALL, marketing\pat:RX }
would remove the existing ACL and grant andre full access and pat (in
the marketing domain) read and execute access to the specified files.
changeaccess={ chris:CHANGE, everyone:RX }
would remove any existing ACEs for the user chris and the group
everyone, and grant chris change access and the group everyone
read access to the specified files. Any other existing ACEs would remain
unchanged.
Submit Filtering Sequence

When you submit files or directories, the following sequence is initiated:
1. The server determines what files and directories have changed and need to
be submitted. It also verifies that none of them are in conflict with the staging
area or locked in other workareas.
2. The path name of the workarea from which the submit is being done is
matched against the workarea patterns in the submit.cfg file.
3. If the workarea matches one of the workarea patterns, then, for each file and
directory that needs to be submitted (as determined in step 1), the files path
name is matched against the file patterns in the matching workareas section.
4.
If a match is found, the server performs the specified set of actions (defined in
submit.cfg) to the file or directory in the workarea.
5. The server submits the transformed files and directories to the staging area.
Sample submit.cfg file

Windows:
CASE-SENSITIVE = NO
RULES
{
.
# any workarea
{
/a/b/.*\.html$ # files ending in .html under /a/b
{
owner=DOMAIN\andre
group="DOMAIN\\web editors"
setaccess = {everyone:Read, domain\andre:ALL}
}
[^/]$
# all other files
{
138
setaccess = {users:rx, "domain\\webeditors:change"}
}
/$
# all directories
{
setaccess = {everyone:rwx/rx, "domain\\webeditors:change"}
}
}
}
Unix:
CASE-SENSITIVE = YES
RULES
{
# SECTION 1
^/default/main/WORKAREA/.*$ # any workarea in the main branch
{
^/index\.html$ { gid=test perm=0664 uid=andre }
# attributes fixed for /index.html
.*\.sh$ { omask=0111 } # execute bits on all .sh files
/$ { uid=andre } # andre owns all the directories
.* { amask=0775 } # don't allow world write access
}
# SECTION 2
^/default/main/TeamSite/WORKAREA/chris$ # just for chris
{
^/html/chris/.*$ { uid=chris gid=iw } # under /html/
chris/
.* { amask=0775 } # don't allow world write access
}
# SECTION 3
.* # any other workarea on any other branch
{
.* { amask=0775 gid=test } # no world write access
}
}
Notes
Only the first match is applied. That is, the first match is used if multiple rules
match the file or directory. The submit.cfg file should be ordered so that the
most specific workarea patterns are closer to the top and the most specific file
patterns are earlier in each section. You may need to duplicate some actions
for them to apply to multiple rules.
For purposes of matching, the path name of a directory must end in a slash (/
).
139
Single or double quotes around patterns are optional, but they must be used
around workarea and file patterns that contain spaces or the following special
characters:
#, {, }, =, or ,.
Backslashes (\) are special characters when used within patterns surrounded
by quotes; a backslash followed by any character is replaced by the single
character. For example, to embed a single quote, double quote, or backslash
in a pattern, precede the character with a backslash (\', \", or \\).
Backslashes are not special characters in patterns that are not quoted.
Windows:
For example, the following three specifications are equivalent:
owner = DOMAIN\andre
owner = 'DOMAIN\\andre'
owner = "DOMAIN\\andre"
You can use backslashes (\) or forward slashes (/) as the path delimiter in
regular expressions, but using forward slashes is more readable. This is
because the backslash is treated as a special character in regex(5) syntax,
and it is also treated as a special character by the configuration file parser
when the expression is enclosed in quotes or double quotes. Therefore, when
an expression using backslashes is contained in quotes or double quotes, the
backslashes must be escaped twice, for a total of four backslashes.
For example, the following are equivalent expressions for matching any file
whose name ends in .html in the \a\b directory:
^/a/b/.*\.html$
'^/a/b/.*\\.html$'
"^/a/b/.*\\.html$"
^\\a\\b\\.*\.html$
'^\\\\a\\\\b\\\\.*\\.html$'
"^\\\\a\\\\b\\\\.*\\.html$"
140
Do not specify duplicate workarea patterns multiple times, duplicate file

patterns multiple times within a workarea section, or the same action multiple
times within a file rule.
(Unix) Because of client-side attribute caching, the modes, uid, and gid may
not reflect the changes in the workarea immediately after a submit. The
correct attributes are displayed after a sufficient time-out interval (usually
about 30 seconds).
(Unix) You cannot change the permissions for a symbolic link. The perm,
amask, and omask actions are not performed on a submitted symbolic link.
The uid and gid actions are performed on a submitted link, not on the actual
file.
(Unix) The permission values must be specified as an octal number (using the
digits 0 to 7) and taking the structure XXXX.
Changes to submit.cfg do not take effect until the server is restarted or until
you use iwreset.
File permissions could be overwritten with submit.cfg options. If

submit.cfg and file permissions are not designed properly, the end user
could be confused.
Test and Debug Submit Filtering

The iwtestcfg CLT can be used to determine which workarea and file patterns
are applied to a file at the time of submission. For example:
%/>iwtestcfg /default/main/WORKAREA/andre/cgi/test.sh
would return:
Matched
Matched
Actions
owner =
area pattern "^/default/main/WORKAREA/.*$"

file pattern ".*\.sh$"
to do are:
andre/omask=0111
Matched area pattern and Matched file pattern are the

case-insensitive regular expressions found in submit.cfg that match the
workarea and file. Actions to do are the actions (specified in submit.cfg)
that will be applied to the file.
Refer to the TeamSite Command-Line Tools manual for more information about
this CLT.
You can also get debugging information on the submit handling configuration
printed to iwtrace.log by adding the following line to the [iwserver] section
of iw.cfg:
[iwserver]
debug_event_handler=yes
This configures the TeamSite server to print:
A configuration map of submit.cfg.
Which actions are performed as files are submitted.
RCS Macro Expansion

Unix
TeamSite provides RCS-style macro substitution at submit time. These macros
enable you to embed version information into files, including:
File name
141
Revision string
Last modifier
Last modified
Submit comments
To use the macro facility, you must add new rules to the submit.cfg
configuration file (see Sample submit.cfg file on page 138), then manually insert
the macros into files in your workarea. When the files are submitted, the TeamSite
server replaces the macros with the appropriate information, and rewrites the file
in your workarea and the staging area.
Available Macros
The macros are a subset of those used in RCS (called keywords in the RCS
documentation). The following description is taken from the UNIX co(1) man page,
modified for TeamSite semantics.
Strings of the form $keyword$ and $keyword:...$ embedded in the text are
replaced with strings of the form $keyword:value$ where keyword and value
are pairs listed below. Keywords can be embedded in literal strings or comments
to identify a revision.
Initially, the user enters strings of the form $keyword$. On submit, the server
replaces these strings with strings of the form $keyword:value$. On
subsequent submits, the value fields will be replaced automatically with updated
values.
The following keywords (macros) and their corresponding values are recognized
by TeamSite:
142
$Author$. The login name of the user who last modified the file. This is a
standard RCS keyword and does not refer to the TeamSite Author role.
$Date$, The date and time the file was last modified.
$Header$. A standard header containing the path name of the file, the
revision string, the date and time, the author. The path is relative to the area
root.
$Id$. Same as $Header$, except that the filename does not include the
path.
$Log$. The comment supplied during submit, preceded by a header

containing the filename, the revision string, the date and time when the file
was last modified, and the author. The comment is either the submit comment
supplied for the individual file or, if this is empty, the comment supplied for the
all the files associated with the submit. Existing log messages are not
replaced. Instead, the new log message is inserted after $Log:...$. This is
useful for accumulating a complete change log in a file.
Each inserted line is prefixed by the string that prefixes the $Log$ line. For
example, if the $Log$ line is // $Log:tan.cc $, RCS prefixes each line of
the log with //. This is useful for languages with comments that go to the end
of the line. The convention for other languages is to use a * prefix inside a
multiline comment. For example, the initial log comment of a C program is
conventionally of the following form:
/*
* $Log$
*/
$Revision$. The revision string.
$Source$. The pathname of the file, relative to the root directory of the area.
The following RCS keywords (macros) are ignored by TeamSite:
$Locker$
$Name$
$RCSfile$
$State$
The following characters in keyword values are represented by escape

sequences:
Character
Escape Sequence
end-of-line
\n
\044
\\
Enable Macro Expansion

To enable RCS macro expansion for a particular set of files, you must include the
following action in the submit.cfg rules that apply to those files:
expand_rcs_macros=yes
Here is a sample submit.cfg file:

CASE-SENSITIVE = YES
RULES
{
"." # any workarea
{
143
".*\.[ch]$" { gid=iw, expand_rcs_macros=yes }

# files ending in .c or .h
".*" { gid=iw } # all other files/directories
}
}
144
CHAPTER 7
Set Up TagUI
TagUI provides a method for tagging files (that is, assigning metadata to files).
TagUI can be used to add metadata to a single file or to multiple files at one time.
The purpose of tagging is to add extended attributes to your content that can be
used later to generate more informative web sites. For example, an expiration
date can be used to specify when content is to be removed. You can also add tags
that are used to search for content.
When end-users set metadata on files (that is, tag them), the metadata is added to
files as TeamSite extended attributes and stored in the TeamSite Content Store.
Adding metadata is a file-specific feature. That is, users must explicitly select the
files on which to set metadata. Metadata cannot be set globally for an entire area
or branch. For example, to set metadata on all files in a workarea, the user must
select each file in that workarea (by clicking Select All or by clicking the check
box next to each file) and then initiate a TagUI session. If the data meets all
necessary criteria, TagUI adds the new metadata (in the form of TeamSite
extended attributes) to the specified files.
When a user selects the tagging option from ContentCenter or within a workflow, a
form displays to obtain the metadata values. This form is designed using the data
capture framework described in the TeamSite FormsPublisher Developers Guide.
This chapter describes specific TagUI-form design issues.
This chapter describes how to set up and use TagUI. It then discusses how to
move Metadata Capture Tagging configuration files to TagUI.
TagUI Features
145
Chapter 7 Set Up TagUI
Using TagUI Rulesets
TagUI Form Design
Configure TagUI
Create Rulesets
Merge Rulesets
Using FormAPI
Integrate IDOL Taxonomy Solution
TagUI Features
TagUI differs from the Metadata Capture Tagging in several key areas. Tagging
features provided by TagUI include:
Scripting through FormAPI. You can use FormAPI and the <script>
element to create dynamic TagUI input forms. See the TeamSite
FormsPublisher: FormAPI Developers Guide for details about using FormAPI.
Rich text editor support. You can configure data forms to use the TinyMCE
rich text editor for data entry. Values stored for these text fields will include rich
text formatting information.
Tab Support. You can use the <tab> element when defining the form to
divide content input onto multiple pages.
Additional replicant and container support. You can configure data forms
using combination=or for item replicants and containers. The
<replicant> element is no longer supported.
Additional <browser> attribute support. You can use attributes such as

ceiling-dir with the <browser> element.
Support for IDOL Taxonomy Solution integration. If the IDOL Taxonomy

Solution is installed, you can map individual data form items to specific IDOL
projects to enable additional tagging options for those items.
Using TagUI Rulesets

When a user selects a file or files to tag in ContentCenter Standard or
Professional:
1. The TagUI process is invoked.
146
TagUI Form Design
2. The TagUI processor reads the file iw-home/local/config/

metadata-rules.cfg to determine which ruleset or rulesets to use for the
files selected for tagging. (The ruleset is specified by name in the <ruleset>
element.) A ruleset is a data capture template (DCT) that contains one ruleset
and has a file name with a .cfg extension.
3. TagUI searches for the ruleset or rulesets in the files located in the iw-home/
local/config/tagui/rulesets60 directory. If multiple files have been
selected for tagging, it searches for rulesets for all the files. All of the rulesets
in this directory must conform to the DTD for the TagUI as defined by
iw-home/local/config/datacapture6.0.dtd.
4. If TagUI does not find rulesets for all of the files, it looks in iw-home/local/
config/datacapture.cfg. If it finds rulesets in the datacapture.cfg
file, it dynamically migrates the rulesets to conform to the
datacapture6.0.dtd so they can be merged with other rulesets.
5. The rules defining the TagUI appearance and behavior are executed. The
TagUI form displays using the same rendering engine used by
FormsPublisher and Workflow Modeler. The user can complete the process of
tagging the file or files originally selected. If multiple rulesets are found, they
are merged.
TagUI Form Design

This section shows a possible form for collecting metadata for a single file. The
form uses tabs so the information is divided between screens.
Figure 14 TagUI screens for single file tagging
147
When a user selects multiple files, the form is rearranged. The metadata items are
listed in the left panel while the main screen lists the files and contains fields for
entering the metadata. The Copy to All link lets a user enter information for one
item in a file and then copy that information to the corresponding item in all files.
Figure 15 shows the Description tag for multiple file tagging.
Figure 15 TagUI screen for multiple file tagging with Description tab
148
Configure TagUI
Configure TagUI
To configure TagUI, you need to:
1. Create one or more ruleset files in the iw-home/local/config/tagui/
rulesets60 directory. Ruleset file names must end in .cfg, and the files
must conform to the DTD defined in iw-home/local/config/
datacapture6.0.dtd. Each ruleset file can contain only one ruleset. See
Create Rulesets on page 153.
2. Specify the name of the ruleset you created in the iw-home/local/config/
tagui/ rulesets60 directory to the iw-home/local/config/
metadata-rules.cfg file. See Map to Rulesets on page 149.
Map to Rulesets
The metadata-rules.cfg file maps vpaths to data capture rules that are
defined in the iw-home/local/config/tagui/rulesets60 directory. The
metadata-rules.cfg file consists of a series of <cond> (conditional)
elements. A <cond> element can contain <rule> elements and other <cond>
elements. Each vpath is run through metadata-rules.cfg, possibly resulting
in a one-to-many mapping from vpaths to named rules. Whenever a list of
<cond> elements is found, the first to match the current vpath takes effect, and
the rest of the elements in the list are discarded. Therefore, entries in this file
should have broader regex expressions at the bottom and more specific
expressions at the top.
The TeamSite installation program installs the metadata-rules.cfg in the
iw-home/local/config/ directory. The metadata-rules.cfg file uses the
following DTD:
<!ELEMENT metadata-rules (cond)*>
<!ELEMENT cond (cond|rule)*>
<!ATTLIST cond
vpath-regex
CDATA
>
<!ELEMENT rule EMPTY>
<!ATTLIST rule
name
CDATA
>
#REQUIRED
#REQUIRED
The contents of the metadata-rules.cfg file are as follows:
149
<?xml version="1.0" encoding="UTF-8" ?>

<metadata-rules>
<cond vpath-regex=".">
<rule name="Default Rule" />
</cond>
</metadata-rules>
International Encoding
Vpath Expression
Rule Identifier
Notes
International EncodingUTF-8 is an encoding of Unicode, a standard for
encoding the character sets of international languages. All of your content
should specify their encoding as UTF-8.
Vpath Regular ExpressionNames the vpath (in this case, all files in all
directories) to which the rules named in the following subelements are applied.
Rule IdentifierNames the rule that applies to the preceding vpath. The rule
itself is defined in the <ruleset> element of a file contained in the iw-home/
local/config/tagui/rulesets60 directory. In this example, the Default
Rule rule always applies to all files in all directories.
The following metadata-rules.cfg file illustrates a more detailed example.

When multiple rule names are specified under a single cond expression, these
rulesets are merged as described on Merge Rulesets on page 161.
150
Configure TagUI
<metadata-rules>
<cond vpath-regex="^/default/main/syndication">
<rule name="Default" />
<rule name="Syndication" />
<cond vpath-regex="\.pdf$">
<rule name="PDF Files" />
</cond>
<cond vpath-regex="\.doc$">
Vpath Expression1
Rule Identifiers2
Vpath Expression3
Rule Identifier4
Vpath Expression5
<rule name="MS Word Files" />

</cond>
</cond>
Rule Identifier6
<cond vpath-regex="^/default/main/www">
<rule name="Default" />
<rule name="Web Content" />
<cond vpath-regex="\.html$">
<rule name="HTML Files" />
<cond vpath-regex="/pr/">
Vpath Expression7
Rule Identifiers8
Vpath Expression9
Rule Identifier10
Vpath Expression11
<rule name="PR" />

</cond>
<cond vpath-regex="/corp/">
Rule Identifier12
<rule name="Corporate" />

</cond>
</cond>
</cond>
</metadata-rules>
Rule Identifier14
Vpath Expression13
Table 9 shows the results of the vpath expressions identified in the example code.
It also identifies the rulesets that will be applied to each category of files. For
example, any file in the /default/main/syndication directory has the
Default and Syndicate rulesets because it is in the /default/main/
syndication directory. Additionally, files with a .pdf file extension in the /
default/main/syndication directory also have the PDF Files ruleset
applied while files with a .doc extension in the /default/main/syndication
directory also have the MS Word Files ruleset applied. The number in brackets
(such as [1]) shows the corresponding identifier in the example code.
151
Table 9 Vpaths and corresponding rulesets

Result of vpath Expression
Rulesets Applied to Files
[1] any file in the /default/main/syndication

directory
[2] Default, Syndicate

directory with .pdf extension
[2] Default, Syndicate, [4] PDF Files

directory with a .doc extension
[2] Default, Syndicate, [6] MS Word

Files
[7] any file in the /default/main/www directory
[8] Default, Web Content
[9] any file in the /default/main/www directory

with a .html extension
[8] Default, Web Content, [10] HTML

Files
[11] any file in the /default/main/www/pr

directory with a .html extension
[8] Default, Web Content, [12] PR
[13] any file in /default/main/www/corp with a

.html extension
[8] Default, Web Content,

[14] Corporate
Adjust Server Timeout

If a user receives a Request Timed Out message after clicking Save or Save
and Close when tagging multiple files, this indicates a slow response time and
you may need to increase the timeout value. To adjust the timeout value, modify
the following entry in the application_custom.xml file:
<default-param id="iw.tagui.ajax-timeout"
value="60000"/>
The default is 60000, which is the connection timeout value in milliseconds (and
equivalent to 60 seconds).
Tag Large Numbers of Files

Attempting to tag a large number of files at one time may impact system
performance. You can specify the number of files that can be tagged in one
screen to improve the tagging response times. After the user tags the first group
of files, the next group of files displays for tagging. To adjust the number of files to
be tagged in each group, modify the following entry in the
application_custom.xml file:
<default-param id="iw.tagui.taggingGroupSize"
value="500"
public="true"/>
Set value to unlimited to disable grouping.
152
Create Rulesets
Control the Search Function

By default, users can search for data in forms. This feature has little meaning for
TagUI and is automatically turned off when a user is tagging multiple files. It can
be disabled for tagging single files with the following entry in the
application_custom.xml file:
<param id="iw.tagui.searchdcr.enabled"
value="false"
public="true"/>
Revert to MetaData Capture Tagging

To revert to the original Metadata Capture Tagging (Tagger GUI) for either single
files or multiple files, set the following separately for ContentCenter Professional
and ContentCenter Standard in application_custom.xml:
<default-param id="iw.tagui.singleFilelUI"
value="old"
public="true"/>
<default-param id="iw.tagui.multiFilelUI"
value="old"
public="true"/>
Create Rulesets
A ruleset defines the form that is used for collecting metadata for a particular type
of file. You may have rulesets created especially for files with certain extensions
(such as .pdf, .html, .doc, .txt). The metadata collected for each of these types
may be different. A ruleset is actually a data capture template (DCT) similar to
those used for FormsPublisher. A .cfg file defines a ruleset for capturing data;
you specify the file name. Rules are referred to by name in
metadata-rules.cfg. You may create as many rulesets as you need.
Rules contain items, where each item is a single set of data that is to be captured
from the end user. An item consists of one instances. Each instance encapsulates
how to capture the data for the item. You can specify access control elements that
determine whether a field is applicable to a particular user.
The TeamSite installation program installs a sample file called
datacaptureExamplewithValidation.cfg in the iw-home/local/
config/tagui/rulesets60 directory. You can copy, rename, and edit the
example file to create your actual rules file. Use the datacapture6.0.dtd and
annotated examples described in the TeamSite FormsPublisher Developers
Guide as a reference to create your own site-specific configuration.
153
The contents of the datacaptureExamplewithValidation.cfg file used to

create the form in Figure 14 are shown here; the section immediately following the
file explains the callouts.
International Encoding

<!DOCTYPE data-capture-requirements SYSTEM "datacapture6.0.dtd">
<data-capture-requirements>
Rule Identifier
<ruleset name="Default Rule with Validation">
<root-container name="Asset_metadata" location="Asset_metadata">
<tab name="Description">
root-container Element
<label>Description </label>
Tab Element
<description>
Metadata that describes the topic of the asset.
</description>
<item name="Title" pathid="Title">
<label>Title</label>
<description>Title description</description>
<text required="f" size="32" maxlength="60"/>
</item>
<item name="Keywords" pathid="Keywords">
Item Elements
<label>Keywords</label>
<description>
Keywords can include terms that are not in the asset itself.
</description>
<text required="f" size="32" maxlength="60"/>
</item>
<item name="Description" pathid="Description">
Text Instance
<label>Description</label>
<description>
A brief summary of 250 characters or less.
</description>
<textarea required="f" rows="5" cols="72" wrap="virtual"
maxlength="250"/>
</item>
Textarea Instance
</tab>
154
Create Rulesets
Tab Element
<tab name="Details">
<item name="Business_Unit" pathid="Business_Unit">
<label>Business Unit</label>
<description>
Unit that is responsible for the asset.
</description>
<select>
Select instance
<option label="Administration" value="Admin"/>
<option label="Facilities" value="Facilities"/>
<option label="Finance" value="Finance"/>
<option label="Human Resources" value="HR"/>
<option label="Legal" value="Legal"/>
<option label="Marketing" value="Marketing"/>
<option label="Sales" value="Sales"/>
<option label="Systems" value="Systems"/>
</select>
</item>
<item name="Creation_Date" pathid="Creation_Date">
<label>Creation Date</label>
item element
<description>
The date the asset was created, in the YYYY-MM-DD format.
</description>
<text required="f" maxlength="10" size="32" validation-regex=
"^[0-9][0-9][0-9][0-9]-[0-1][0-9]-[0-3][0-9]$"/>
</item>
<item name="Expiration_Date" pathid="Expiration_Date">
<label>Expiration Date</label>
<description>
The date the asset should be retired, in the YYYY-MM-DD format.
</description>
<text required="f" maxlength="10" size="32" validation-regex=
"^[0-9][0-9][0-9][0-9]-[0-1][0-9]-[0-3][0-9]$"/>
</item>
validation-regex
</tab>
</root-container>
155
Creation_Date","onItemChange",testCDate);
IWEventRegistry.addItemHandler("/Asset_metadata/Details/
Expiration_Date","onItemChange",testEDate);
IWEventRegistry.addFormHandler("onSave",testCombinedData);
script Element
// event handler for copyToAll
Creation_Date","onAfterItemReplace",testCDate);
Expiration_Date","onAfterItemReplace",testEDate);
function testCDate(itemCDate) {
// check build-in validations
itemCDate.setValid(null);
var itemEDate = IWDatacapture. getItem("/Asset_metadata/Details/Expiration_Date");
itemEDate.setValid(null);
if (itemCDate.isValid() && itemEDate.isValid()) {
if (!compareDates(itemCDate.getValue(), itemEDate.getValue())) {
//use item-specific messages instead of alert()
itemCDate.addErrorMessage("Creation Date must be before the Expiration Date");
itemEDate.addErrorMessage("Expiration Date must be after the Creation Date");
itemCDate.setValid(false);
itemEDate.setValid(false);
// alert("Expiration Date must be after the Creation Date");
return false;
} else {
itemCDate.clearErrorMessages();
itemCDate.setValid(true);
itemEDate.clearErrorMessages();
itemEDate.setValid(true);
return true;
}
}
return false;
}
function testEDate(itemEDate) {
//check build-in validations
itemEDate.setValid(null);
var itemCDate = IWDatacapture. getItem("/Asset_metadata/Details/Creation_Date");
itemCDate.setValid(null);
if (itemEDate.isValid() && itemCDate.isValid()) {
if (!compareDates(itemCDate.getValue(), itemEDate.getValue())) {
// use item-specific messages messages instead of alert()
itemCDate.addErrorMessage("Creation Date must be before the Expiration Date");
itemEDate.addErrorMessage("Expiration Date must be after the Creation Date");
156
Create Rulesets
// alert("Expiration Date must be after the Creation Date");
return false;
} else {
itemEDate.clearErrorMessages();
itemEDate.setValid(true);
itemCDate.clearErrorMessages();
itemCDate.setValid(true);
return true;
}
}
return false;
}
function compareDates(creationDateStr, expirationDateStr) {
if ((creationDateStr.length==0) || (expirationDateStr.length==0))
return true;
var creationYear = creationDateStr.substring(0,4);
var creationMonth = creationDateStr.substring(5,7);
var creationDay = creationDateStr.substring(8,10);
var creationDate = (new Date()).setFullYear(creationYear,
creationMonth,creationDay);
var expirationYear = expirationDateStr.substring(0,4);
var expirationMonth = expirationDateStr.substring(5,7);
var expirationDay = expirationDateStr.substring(8,10);
var expirationDate = (new Date()).setFullYear(expirationYear,
expirationMonth,expirationDay);
return (creationDate < expirationDate);
}
157
//only allow SAVE if either "Keywords" or "Title" has value

function testCombinedData(button) {
var canSave = true;
if (IWDatacapture.SAVE_BUTTON == button) {
var itemKeywords = IWDatacapture. getItem("/Asset_
metadata/Description/Keywords");
var itemTitle = IWDatacapture. getItem("/Asset_metadata/Description/Title");
IWDatacapture.clearFormInfoMessage();
if (itemKeywords.getValue() == "" && itemTitle.getValue() == "" ) {
IWDatacapture.postFormInfoMessage("At least one of Keywords or Title must
have a value");
canSave = false;
}
}
return canSave;
}
]]>
</script>
</ruleset>
</data-capture-requirements>
Notes
International Encoding. UTF-8 is an encoding of Unicode, a standard for
encoding the character sets of international languages. All web assets should
specify their encoding as UTF-8.
158
Rule Identifier. The <ruleset> element contains all of the items define the
appearance and behavior of the TagUI form. The name attribute is required.
Root-container Element. This is a required element to provide the first path

of the extended attribute name. The name and location attributes are
required.
Tab Element. Each <tab> element groups the fields that are on that screen
of the form. It also provides the text on the tabs. In this form, there are two
tabs: the first is named Description and contains the Title, Keyword, and
Description fields, and the second is named Details and contains the
Business Unit, Creation Date, and Expiration Date fields.
Item Element. An item is a single set of data (that is, a single field on the
form) that is to be captured from a content contributor. Item names must be
unique within any given nesting level. An item does not require a label; the
field shows up without a caption. However, if you are tagging multiple files, the
label on the left will be the value specified with the name attribute.
Create Rulesets
Item Element. Specifies that data will be entered and captured using an
unformatted single-line text field. The optional <text> element controls the
length of text entry fields in metadata capture and search forms. It also
controls whether an end-user is required to enter text in a field. If the data field
is used to hold a date or time with a specific format, it is best to include a
validation-regex to force users to input data in the correct format (see
the validation-regex description that follows). In this example the user is
required to enter a string between one and 60 characters in the text field.
Textarea Instance. Specifies that data will be entered and captured in a

textarea field of a specified size. You can specify the number of rows and
columns and how text will wrap.
Description Element. The <description> element is used to provide the

information that displays when a user clicks on the question mark next to a
field on a form.
Select Field. Specifies that data will be captured using a drop-down or

multi-select list.
Item Element with a specific format (date). If a value for date or time is
needed, specify a format and include a validation. Because there are many
formats for date and time, specifying a format forces the user to enter data in
that format and reduces the chance of user error.
Validation-regex. The user can be forced to enter a date or time in the format
you specify by including a validation regex. The value for the
validation-regex attribute must match the format specified. The regex in
this example specifies the range of digits that can be entered for yyyy-mm-dd
and that dashes must separate year, month and day.
Script Element. Indicates that FormAPI calls are being used. This example
shows validation checking of the information the user entered in the form. It
uses the postMessage API call instead of alerts that were used in earlier
versions. This is preferred if the ruleset is used for tagging multiple files
because it eliminates the need for the user to click through an alert dialog box
once for every file.
Requirements for Designing Rulesets

Only one <ruleset> element can be used in a .cfg file. The file must have a
.cfg extension.
All ruleset .cfg files must conform to the datacapture6.0.dtd as

described in the TeamSite FormsPublisher Developers Guide.
The <replicant> attribute is not supported when designing forms for TagUI.
Use the <container> or <item> elements with the min and max attributes.
159
If at least one ruleset uses tabs, all rulesets that will be merged must also
contain tabs; otherwise a merge conflict error will occur.
The location attribute is required for <container> elements, and the

pathid attribute is required for <item> elements. Use relative locations and
pathids; for example: <container name="A" location="X">. One
recommendation is to use a unique location or pathid across all rulesets.
Another suggestion is to use the same value for location/pathid as you
use for name; however, replace any special characters with an underscore for
the location/pathid.
The following are examples of unsupported location/pathid formats in
TagUI:
non-located locations/pathids: <container name="A"> or
<container name="A" location="">

absolute locations/pathids: <container name="A" location="/X">
attribute locations/pathids: <container name="A" location="@X">
PCDATA locations/pathids: <item name="A" pathid="#PCDATA">
The <dialog> element is not supported.
Use the same root-container name, such as root, for rulesets that will be
merged. Otherwise, a FormAPI script that registers handlers in one
root-container will not work when scripts are merged. For example: Ruleset A
contains a root container named A, which contains item A1. Ruleset B
contains a root container named B, which contains item A1 and a FormAPI
script. The merged ruleset will contain root container A, with item A1 merged
with item A1 from container B; it will not include the script because it did not
get merged since it belongs to root container A.
Do not use a slash (/) in an item or tab name; the Copy to All link and
FormAPI will not work.
Best Practices for Designing Rulesets

Items in different rulesets should be uniquely defined. If you want to merge
rulesets, items with the same name must be defined identically in different
rulesets. For example, if a field with a particular name is identified as a text
field in one ruleset and as a drop-down menu in another ruleset, an error will
occur when the rulesets are merged. This is different from the Metadata
Capture Tagging previously used in TeamSite.
160
Do not name a TagUI ruleset datacapture.cfg.
Merge Rulesets
Merge Rulesets
When a user selects a file or files to tag, multiple rulesets may need to be
combined before the form displays in a process known as ruleset merging.
When a single file is tagged, rulesets may need to be merged to find rules for
all the fields in the TagUI form.
When multiple files are being tagged, the rulesets for all files are merged to
include all fields from all rules. Depending on the files being tagged, there may
be fields that are identified as Not Applicable in the TagUI form for a
particular file. These are fields that would not appear if a file is tagged alone.
The following files illustrate a very simple example of how rulesets are merged.
The rulesets files RS1.cfg and RS2.cfg define the items being displayed in the
tagging form. The metadata-rules.cfg file defines the files that use each
ruleset.
RS1.cfg
<ruleset name="RS1">
<root-container name="root" location="root">
<item name="itemA" pathid="itemA" >
<label>Item A</label>
<textarea >
<default>Item A default value</default>
</textarea>
</item>
<item name="itemB" pathid="itemB" >
<label>Item B</label>
<textarea >
<default>Item B default value</default>
</textarea>
</item>
</root-container>
</ruleset>
RS2.cfg
<ruleset name="RS2">
<root-container name="root" location="root">
<item name="itemA" pathid="itemA" >
<label>Item A</label>
<textarea >
161
<default>Item A default value</default>

</textarea>
</item>
<item name="itemC" pathid="itemC" >
<label>Item C</label>
<textarea >
<default>Item C default value</default>
</textarea>
</item>
</root-container>
</ruleset>
metadata-rules.cfg
<?xml version="1.0" encoding="UTF-8" ?>
<metadata-rules>
<cond vpath-regex=".*file1\.txt">
<rule name="RS1" />
</cond>
<rule name="RS2" />
</cond>
<rule name="RS1" />
<rule name="RS2" />
</cond>
</metadata-rules>
The file RS1.cfg defines Item A and Item B. The file RS2.cfg defines Item A
and Item C. The metadata-rules.cfg indicates files with names or vpaths
containing the string file1.txt are to be tagged as defined in RS1.cfg while
files containing the string file2.txt are to be tagged as defined in RS2.cfg
and file with names or vpaths containing the string file12.txt are to be tagged
as defined in both RS1.cfg and RS2.cfg.
When the user selects Item A, all files will have fields for entering metadata for
that value. When the user selects Item B, file2 will be marked as not applicable
and the field will not display. Similarly, when the user selects Item C, file1 is
marked as not applicable. The user can view and add metadata in all values for
file12 since it uses both rulesets RS1 and RS2.
An example that would be used to tag one file would be if the user selected a file
that satisfied the condition for *file12.txt shown as the third condition in
metadata-rules.cfg. Rulesets RS1 and RS2 would be merged to create the
tagging form for the selected file.
162
Using FormAPI
Troubleshooting Merged Files

If ruleset merging fails, the merged data capture template is printed into the
servlet_out.log debug log.
Dynamic Addition of Select Box Entries

TagUI supports dynamic changes to select box entries. TagUI must interpret
saved select box values from another source as dynamic entries from a previous
session, and allow those values into the drop-down list. Dynamic changes may
occur because:
Extended attributes from an old data capture template are not consistent with
what was specified in the new data capture template.
The values for the extended attribute are not valid. When a file that was
previously tagged has a value that is no longer an option, the value will be
added to the select box; however, the label for that value is not shown.
Multiple select drop-down values (have multi="t") are saved in a single
string (for example, "value1, value2, value3"). On changing a

multi-valued list into a single-valued list, TagUI renders "value1,
value2, value3" as a legal option in the select list. Metadata Capture
Tagging would have arbitrarily chosen one of the values.
If you anticipate the meaning of a saved value could change, it is
recommended that you migrate the extended attribute data to the new format
to achieve the result your organization desires.
The list changes through a CGI callout, a CLT, or by FormAPI. For example, if
value4 is added as a select value through a CGI callout, a CLT, or by
FormAPI, the select box will contain this additional value, even though it was
not included in the original ruleset definition.
If you anticipate the meaning of a saved value could change, it is recommended

that you migrate the extended attribute data to the new format to achieve the
result your organization desires.
Using FormAPI
Event handlers can be specified in JavaScript in the ruleset through the use of the
FormAPI <script> element. This can specify form-level or item-level event
handlers and perform tasks such as custom validation.
When rulesets with a <script> element are merged, the content of the
<script> elements are also merged.
163
A custom handler doing item validation can use IWItem.addErrorMessage to

provide an explanation. This message remains displayed next to the item until the
item value has been fixed and revalidated through another invocation of a handler.
The custom handler is responsible in clearing any previous messages using
IWItem.clearErrorMessages.
In releases prior to TeamSite 6.7.2, a JavaScript alert() function was often
used to display a message in a dialog box that the user needed to acknowledge.
This alert was used by the event handler author when an event handler prevented
further processing by returning a value of false. An example for item-level
events is onCallout to explain why a callout was cancelled; an example for
form-level events is onSave to explain why the save process could not proceed.
The JavaScript alert function will continue to work. However in multi-file tagging
this method may require a user to click through a large number of pop-up dialog
boxes.
A custom handler can replace the use of JavaScript alert() function with a
FormAPI postMesage call. This message can be posted at the item level using
IWItem.postMessage or at the form level using
IWDatacapture.postFormInfoMessage. These messages are transient and
are cleared automatically when the form is redrawn when the user switches tabs
or selects a different item in multi-file tagging. Use item.setValid(null) to
clear old messages. You can also use item.clearErrorMessages; however if
you miss entering this for a message, the message may appear multiple times.
See the <script> example in the
datacaptureExamplewithValidation.cfg file.
Best Practices for using JavaScript
164
Unique function names across rulesets are recommended; you may want to
prepend the ruleset name to a function name. For example, a ruleset named
validateMyData in ruleset1 could be renamed
ruleset1_validateMyData.
Avoid the use of the JavaScript function alert in TagUI rulesets. When
rulesets are merged, multiple alerts may occur, requiring the user to click each
one.
The JavaScript code in each <script> element should only contain the
function declaration and the event handler registration. Any other executable
code could be executed before FormAPI finishes initialization and the results
would be unpredictable and unrepeatable.
By default, IWEventRegistry registrations from different <script> tags may

overwrite previous registrations so only the last registered handler is
processed. For IWEventRegistry.addFormHandler and
IWEventRegistry.addItemHandler API calls, specify replace=false

for TagUI so the event handler is added and not overwritten.
Troubleshooting JavaScript
You can insert debugger statements inside a <script> tag to debug and trace
execution of the code.

You can configure TeamSite to use the IDOL Taxonomy Solution whenever files
are tagged in the user interface. Integration consists of three steps:
1. Manually install and configure the solution. Refer to the IDOL Taxonomy
Solution Technical Note for more information.
2. Create a rule set for the data form that will use the IDOL Taxonomy Solution
(see Create a Ruleset on page 165).
3. Create a file that maps projects to data form items defined in the rule set. The
mapping file is necessary for metadata retrieval (see Create a Mapping File
on page 168).
To view items that use the IDOL Taxonomy Solution, tag an item in the TeamSite
user interface or ContentCenter Professional. TeamSite obtains the metadata for
the items that use the IDOL Taxonomy Solution and populates the form.
If the file is being tagged for the first time, TeamSite displays the metadata
automatically.
If the file has already been tagged, the user clicks Suggest to request
metadata from the IDOL Taxonomy Solution, which overwrites existing
metadata.
Create a Ruleset
Use the sample rule set in this section as the basis for your own rule set. The file
that defines the rule set must:
be located in the iw-home/local/config/tagui/rulesets60 directory.
have a .cfg file extension.
contain the tagEngineConfig attribute, which points to the mapping file that
you will create as described in Create a Mapping File on page 168.
165
conform to the tagging DTD defined in datacapture6.0.dtd. Do not use

<select>, <radio>, and <check box> attributes in items that use the
TeamSite; instead use <textarea>.
All IDOL Taxonomy Solution items become <select> items. The original item
type is not relevant. However, the drop-down list does not behave like a normal
drop-down list and the user does not need to select any of the items.
The following example shows a rule set file named PDF_Files.cfg. It defines a
data form named Asset_metadata. Code to enable the IDOL Taxonomy Solution
is shown in bold.
This data form has two tabsNew Default and Details. It collects input from a
user in five data entry areas (Title, Keywords, Description, Creation Date, and
Expiration Date); the first two are IDOL Taxonomy Solution-enabled items. It uses
the IDOL Taxonomy Solution when the user chooses to add metadata, using the
projects defined in MT_PDFTitle (see Create a Mapping File on page 168).
<ruleset name="PDF_Files">
<root-container name="Asset_metadata" location="Asset_metadata">
<tab name="New Default">
<item name="PDF_title" pathid="PDF_title"
tagEngineConfig="metatagger://MT_PDFTitle">
<label>Title</label>
<description>Title description</description>
<textarea required="f" size="32" maxlength="60"/>
</item>
<item name="PDF_Keywords"
pathid="PDF_Keywords"tagEngineConfig="metatagger://MT_PDFTitle">
<label>Keywords</label>
<description>
Keywords can include terms that are not in the asset
itself.
</description>
<textarea required="f" size="32" maxlength="60"/>
</item>
<item name="PDF_Description" pathid="PDF_Description">
<label>Description</label>
<description>
A brief summary of 250 characters or less.
</description>
<textarea required="f" rows="5" cols="72"
wrap="virtual"maxlength="250"/>
</item>
</tab>
<tab name="Details">
<item name="Creation_Date" pathid="Creation_Date">
166
<label>Creation Date</label>
<description>
The date the asset was created, in the YYYY-MM-DD
format.
</description>
<text required="f" maxlength="10" size="32"
validation-regex="^[0-9][0-9][0-9][0-9]-[0-1][0-9]-[0-3][0-9]$"/>
</item>
<item name="Expiration_Date" pathid="Expiration_Date">
<label>Expiration Date</label>
<description>
The date the asset should be retired, in the YYYY-MM-DD
format.
</description>
<text required="f" maxlength="10" size="32"
validation-regex=
"^[0-9][0-9][0-9][0-9]-[0-1][0-9]-[0-3][0-9]$"/>
</item>
</tab>
</root-container>
</ruleset>
NOTE Ensure that the maxlength attribute is set to a value large enough
to display all results for metadata suggestions. If maxlength is too small,
the display field truncates the returned result, and users may lose some of
the data that was suggested or be unable to edit the information.
NOTE Be careful if you plan to set the textarea required attribute to
true. When set to true, every IDOL Taxonomy Solution-enabled field
must have at least one value generated using the Suggest button. If a value
is not available, users cannot save the entire set of files they are attempting
to tag.
Requirements for Designing Rule Sets
The <choice> element is not supported.
The or container is not supported if a <choice> element has an

TeamSite-enabled item as a child.
The container/item replicant is not supported if the item or items inside the
replicant container are IDOL Taxonomy Solution-enabled.
itemRef is not supported.
167
Create a Mapping File

Use this procedure to create a file that maps IDOL Taxonomy Solution projects to
data capture template items.
To create a mapping file
1. Create a metataggerMappings directory in iw-home/local/config/
tagui.
All IDOL Taxonomy Solution mapping files must be placed in this directory.
2. In iw-home/local/config/tagui/metataggerMappings, create a file
with a name of your choice (in this example, the file name is MT_PDFTitle).
3. Edit the file so that it contains just the <tagUIConfig> element and its
associated sub-elements.
The <tagUIConfig> element can contain multiple items (one for each data
entry area that will use the IDOL Taxonomy Solution). Each item also contains
one or more parameter sub-elements mapping the data entry area for that
item to a IDOL Taxonomy Solution project. The metataggerProjectName
is required. For example:
<?xml version="1.0"?>
<tagUIConfig>
<item name="/Asset_metadata/New Default/PDF_title">
<parameter name="metataggerProjectName" value="title"/>
<parameter name="suggestButton" value="f"/>
<parameter name="idoltaggerProjectType" value=/>
</item>
<item name="/Asset_metadata/New Default/PDF_Keywords">
<parameter name="metataggerProjectName"
value="WEB-thesaurus"/>
<parameter name="suggestButton" value="t"/>
<parameter name="idoltaggerProjectType" value="ATTRIBUTE"/>
</item>
</tagUIConfig>
NOTE All item references are rooted in the node specified in the
<root-container> element in PDF_Files.cfg. The syntax for item
references is the same as the base FormAPI path syntax. Refer to the
FormsPublisher Developer Guide for more information.
The data entry areas of the Asset_metadata form are mapped to Metatagger
projects as follows:
168
PDF_title (mapped to the title project)
PDF_Keywords (mapped to the WEB-thesaurus project)
Because suggestButton for the first item (PDF_title) is set to f, a Suggest

button does not appear in the form next to that field. The metadata from the
Suggest All button will not overwrite the value in the field for that item. This is
useful if you want to disable the Suggest button for a browse-only project.
Supported IDOL Project Types

The IDOL Taxonomy Solution supports types of project by default:
ATTRIBUTE. Returns keyword values.
FREE_TEXT. Returns document summaries.
CONTROLLED_VOCABULARY. Defines the ACC taxonomy to use. If you set the

Type to CONTROLLED_VOCABULARY, you must specify an additional
parameter:
<parameter name="idoltaggerProjectTaxonomy" value="TaxName"/>
where TaxName is the name of the ACC taxonomy.
Use the IDOL Taxonomy Solution in the User Interface

When IDOL Taxonomy Solution is enabled for tagging multiple files, each file
displays a field for the metadata for the file type, as shown in Figure 16.
Figure 16 Tagging multiple files
169
170
CHAPTER 8
Configure the TeamSite Web

Daemon and Proxy Server
The chapter describe the configuration settings for the TeamSite web daemon and
the TeamSite proxy server. They begin with an overview of each of these features,
and then are followed by sections on specific configuration settings.
About the TeamSite Web Daemon
About the Proxy Server
Configure TeamSite Web Daemon and Proxy Server Operation
Resolve Fully Qualified URLs
Redirect Fully Qualified URLs
Redirect TeamSite Views to Different Areas
Configure TeamSite to Use Different Web Servers
Configure External Remappings
Host Header Remappings
Enable iwproxy Access Control
Configure Proxy Failover
171
Chapter 8 Configure the TeamSite Web Daemon and Proxy Server
Debug Your Proxy Server Configuration
About the TeamSite Web Daemon

TeamSite uses a web daemon, iwwebd.exe, to provide a single HTTP interface
to the TeamSite ContentCenter interfaces.
Figure 17 Browser access to iwwebd
optional
fire wall
Browser
iwwebd
iwproxy
servletd
Customer
Web server
TeamSite
File System
Remote contributors can use TeamSite securely without having to establish a

Virtual Private Network (VPN). The iwwebd web daemon also serves the
non-servlet-based parts of TeamSite ContentCenter. For an illustration of how
requests are processed, see Figure 4 on page 33.

TeamSite uses a proxy server to perform the following functions:
172
Resolve relative and absolute URL names in TeamSite areas in order to

present users with a virtualized view of the Web site contained within an area
(see Resolve Relative and Absolute Paths on page 175).
Redirect fully qualified URLs into TeamSite areas (see Redirect Fully
Qualified URLs on page 178).
Redirect browsing in one branch or workarea into another area (see Redirect
TeamSite Views to Different Areas on page 181).
Redirect individual workareas to use different Web servers (see Configure

TeamSite to Use Different Web Servers on page 183).
Remap links to external Web servers (see Configure External Remappings

on page 183).
Modify Host: headers (see Host Header Remappings on page 185).
Remap SSI requests (see Configure SSI Remapping on page 186).
Each time a request is made through the TeamSite proxy server, the following
sections of iw.cfg are processed as shown in the following graphic. More than
one rule may be applied to a request. When a rule matches a URLdepending on
the section in which the rule was specifiedeither an HTTP redirect is sent back
to the browser to indicate the new location or the URL is rewritten and passed to
the new section. The first rule that matches in any section prevails; no other rules
in that section are applied.
Figure 18 Processing proxy requests through the iw.cfg file
See Configure the Proxy Server to
Redirect Fully Qualified URLs.
Applies only if the browsers proxy is
set to the TeamSite proxy server.
iwproxy_fullproxy_redirect
iwproxy_remap
See Document Roots.
iwproxy_external_remap
See Configure External

Remappings. Applies only if none
of the preceding rules matched.
iwproxy_preconnect_redirect
iwproxy_preconnect_remap
See Redirect TeamSite Views to

Different Areas.
iwproxy_hostheader_remap
See Host Header Remappings.
wproxy_smartcontextedit_allowed
See Enable and Disable
VisualPreview.
Can the rewritten path
be found?
No
Yes
The specified page is returned.
iwproxy_failover_remap
See Configure Proxy Failover.

Sends the rewritten path to be
reprocessed.
173
Apply Changes to Proxy Configuration

If you change any of the iwproxy mappings in iw.cfg, you must use the
iwreset -a CLT to ensure that TeamSite recognizes the changes.
NOTE iwreset -a does not apply changes to the
[iwproxy_remap] or [iwproxy_plugin_remap]
sections of iw.cfg if you are using Web server plug-ins. If
you make changes to these sections and you are using Web
server plug-ins, you must restart the Apache Web server
(not the Apache Tomcat, IBM WebSphere, or BEA
WebLogic Web application server) to apply the changes.
Configure TeamSite Web Daemon and Proxy Server

Operation
The [iwproxy] section of iw.cfg is used to configure the operation of the
TeamSite proxy server. By default, your [iwproxy] section reads as follows:
[iwproxy]
customer_webserver_host=hostname or IP_address
iwproxy_host=proxy_hostname
iwproxy_port=1080
customer_webserver_port=81
where:
customer_webserver_host is the host name of the content Web server.

The value must be set to the host name of the Web server that serves the
content of your Web sites.
iwproxy_host specifies the host where the TeamSite proxy daemon runs.
Usually this is the TeamSite server.
iwproxy_port is the port on which the TeamSite proxy server operates. It

should be set to an open port value. This port need only be open to the
TeamSite proxy server. It may be blocked from end-user clients for added
security.
customer_webserver_port is the port through which the TeamSite proxy

server communicates with the Web server. It must be set to the value of the
port used by the Web server.
The settings in the [iwproxy] section are set during the TeamSite installation.
They can be manually edited if necessary.
174

Operation
Resolve Relative and Absolute Paths

Relative paths specify file locations relative to the referencing files directory
location. Absolute paths specify file locations relative to the Web sites document
root directory.
For example, the file whose directory path (rooted in a TeamSite area) is /main/
index.html might contain a link to the file /images/banner.gif. This link
can be specified as either a relative or an absolute path as follows:
As a relative path:
../images/banner.gif
As an absolute path:
/images/banner.gif
NOTE The proxy server does not allow you to remap the
document root directory for Content Store branches other
than the default Content Store.
Links in HTML documents are often specified with relative or absolute path
names. For example, in a link to an image, the file name might appear as:
/images/miles.gif
On a typical Web server, this link reference would be mapped by the Web server
to its document root, for example:
/images/miles.gif
)images\miles.gif
D:\inetpub\wwwroot\(Unix:usr\httpd/
All users that attempt to access the file using the absolute path name are mapped
to the same file location on the Web server.
However, TeamSite supports a system of private workareas, giving each user
access to the Web sites files from within their own personal, virtual version of the
Web site. TeamSite uses a proxy server to manage mapping of files to workareas
with relative and absolute path references. Using the previous example, the
TeamSite proxy server enables all users attempting to access /images/
miles.gif from within TeamSite to be mapped to the copy of miles.gif in
their own workareas. The redirected mapping would look like:
/images/pic.gif
Y:\(Unix:iw-mount)default\main\branchpath\
WORKAREA\workareaname\images\miles.gif
175
Document Roots
TeamSite maps the initial Web server directory structure (the document root) of
workareas to the top level of the workarea directory by default. You may, however,
want to move the document root, or group types of files together for improved
clarity, convenience, or efficiency. On a branch-by-branch basis, the TeamSite
proxy server allows you to remap the document root anywhere within the
workarea directory. It also allows you to define mappings directly to subdirectories
within workareas.
NOTE The proxy server does not allow you to remap the
document root directory for Content Store branches other
than the default Content Store.
Document roots are defined in the [iwproxy_remap] section of iw.cfg. The

default setting is as follows:
[iwproxy_remap]
global_default_map=/
NOTE The iw.cfg file also contains a section called
[global_default_map]. There must be a
corresponding section for each parameter defined in the
[iwproxy_remap] section.
To configure document roots for individual branches

1. For each branch that you want to configure, add a line to the
[iwproxy_remap] section of iw.cfg as follows:
[iwproxy_remap]
configSectionName=vpath
where configSectionName is the name of the section of the configuration

file that defines the branch remappings, and vpath is the vpath to the branch
you are configuring.
2. For each line that you added to [iwproxy_remap] section, create a section
in iw.cfg named [configSectionName].
3. Add a line to this new section that defines the document root:
_docroot=dirpath
where dirpath is a directory path rooted in a workarea.

You can also add lines that bypass the document root, as follows:
path=path
176

Operation
For example, if you added the following lines to [iwproxy_remap]:

[iwproxy_remap]
branchrewrite_1=/main
branchrewrite_2=/main/training
The first line tells TeamSite to use the section [branchrewrite_1] to set the
document root configuration for the /main branch. The second line tells TeamSite
to use the [branchrewrite_2] section to set the document root configuration
for the /main/training branch.
You would then create two new sections in iw.cfg corresponding to the lines in
[iwproxy_remap]:
[branchrewrite_1]
_docroot=/htdocs
/pictures/=/pictures/
/html/=/html/
[branchrewrite_2]
_docroot=/htdocs
/images/=/images/
Note that the first line of both the new sections contains _docroot=/htdocs.
This defines a special directive that sets the mapping of the document root. Any
requests from workareas on the main branch or the main/training branch to
the root level directory (/) now start at:
.../workareaname/htdocs/
Thus, the request for file /miles.gif will now be mapped to:
.../workareaname/htdocs/miles.gif
newly defined docroot
file
The two docroot configuration sections also contain lines similar to the following:
/pictures/=/pictures/
This line maps file requests directly to the listed directory /pictures/,
bypassing the document root defined in the first line. Thus, a request for the file /
pictures/mingus.gif gets mapped to:
.../workareaname/pictures/mingus.gif
not:
.../workareaname/htdocs/pictures/mingus.gif
The TeamSite proxy server operates using literal string matches and substitutions
in path names. To avoid inadvertently rewriting names, always use trailing slashes
in your remap definitions.
177
NOTE Do not use trailing slashes in your remap definitions

for _docroot directories.
Resolve Fully Qualified URLs

The proxy server can also be configured to resolve fully qualified paths. For
example, a link to the main page of a Web site might appear as: http://
www.name.com.
If such a link appears in an HTML file in a TeamSite workarea, and you follow that
link while performing in-context QA, you will be taken out of the workarea and to
the actual referenced Web site.
Therefore, if you use fully qualified URLs to reference pages within your own Web
site, clicking on these links will take you out of the in-context view of the current
workarea, staging area, or edition and into your own currently deployed Web site.
To solve this problem, TeamSite enables you to configure your proxy server to
redirect fully qualified links within your Web site, then pass them to the regular
proxy server to ensure the integrity of the in-context view in a workarea, staging
area, or edition.
NOTE Only configure this setting if your Web site uses fully
qualified URLs that you need to view in-context. This setting
requires you to manually configure your browser, so that you
cannot view the actual Web site without reconfiguring your
browser. This also slows the TeamSite server by sending
every request through iwwebd and iwproxy.

There are two major steps you must complete to configure TeamSite to redirect
fully qualified URLs:
Configure your proxy server by editing the

[iwproxy_fullproxy_redirect] section of iw.cfg.
Configure your Web browsers proxy to use the TeamSite Web daemon
(iwwebd).
These procedures are described in detail in the next two sections.
178
Configure the Proxy Server to Redirect Fully Qualified URLs

This feature allows fully qualified URLs in a Web page to be redirected back into
workarea-virtualized paths if users set their browsers proxy to iwproxy. This
feature must be specifically enabled (enabled=yes) to prevent it from being
abused. If you enable this feature, be sure you understand the security
implications and properly secure the HTTP and HTTPS ports of your TeamSite
server using a firewall and VPN where needed.
Edit the [iwproxy_fullproxy_redirect] section of iw.cfg. to include any
number of _regex lines as follows:
_regex=source_regex=dest_ex
where source_regex is a case-insensitive regular expression specifying a fully

qualified URL that might appear in a page, and dest_ex is an expression
specifying the path that the link will be redirected to. This expression should
always be the path to the file specified in source_regex, but rooted in a
TeamSite area. For example:
[iwproxy_fullproxy_redirect]
enabled=yes
_regex=http://www(\.example\.com)?/(.*)=/$2
enables the feature and redirects links that specify http://www.example.com

in the URL and sends them to the corresponding location in the current TeamSite
area.
NOTE If your iw.cfg files [iwwebd] section defines the
host as host=hostname.domain, and your browser's
proxy server is set to hostname.domain:port, when you
start TeamSite, you must enter http://
hostname.domain/iw/ in your browser rather than
http://hostname/iw/.
Continue the configuration by completing the procedures described in the next

sections.
The TeamSite web daemon can be used as a proxy server to connect to any
outside address and access content. You can create a regex in the
[iwproxy_fullproxy_redirect] section of iw.cfg to disable this
functionality. Refer to the [iwproxy_fullproxy_redirect] section of
iw.cfg.example for details.
Configure your Web browsers to Use the TeamSite Web Daemon

You must modify your Web browser to use the TeamSite proxy server as
described here for Internet Explorer.
179
1. In Internet Explorer, select Tools > Internet Options.

The Internet Options window is displayed.
2. Select the Connections tab.
3. Click LAN Settings.
The Local Area Network (LAN) Settings window is displayed.
Figure 19 Local Area Network settings dialog box
4. Click the Use a proxy server check box.

5. Type the name of your TeamSite server (for example,
teamsite1.example.com) in the Address section.
6. Type the http-port specified in the [iwwebd] section of iw.cfg (for
example, 80) in the Port section.
7. Click OK.
To configure Internet Explorer to not use the TeamSite proxy server:
1. In Internet Explorer, select Tools > Internet Options.
The Internet Options window is displayed.
2. Select the Connections tab.
3. Click LAN Settings.
The Local Area Network (LAN) Settings window is displayed.
4. Either:
Clear the Use a proxy server check box, and click OK.
Click Advanced. The Proxy Settings window is displayed. Continue with
Step 5.
5. In the Exceptions field, enter the URLs that you want to access without using
the proxy server.
180
6. Click OK.

The proxy server enables web teams to work on branches of development that
are populated only with the portion of the content that they are developing, but still
maintain a full in-context view of the entire content collection by referencing the
staging area or a known edition on another branch of development.
This feature is very flexible in that it can be configured on a per-branch or
per-workarea basis, and the redirected view can be configured to take the user to
any TeamSite area on any branch. Redirection can occur in one of two ways:
Through [iwproxy_preconnect_remap], which retains your original area

as the current working area and directs files there from another area. In this
scenario, docroot is based on the original areas parent branch.
Through [iwproxy_preconnect_redirect], which causes the area you

redirect into to become the current working area (and that areas parent
branch becomes the basis of docroot).
Using iwproxy_preconnect_remap
To configure TeamSite to redirect workarea views and retain your original area as
the current working area (as described in the first bullet), edit the
[iwproxy_preconnect_remap] section of iw.cfg as follows:
where source_regex is a case-insensitive regular expression describing the

area to be mapped from, and dest_ex is an expression describing the area to be
mapped to. These areas are most commonly workareas or staging areas, but you
can map to and from any workarea, staging area, or edition. You can add any
number of _regex lines to this section.
For example:
_regex=(.*)/branch1/WORKAREA/[^/]+/products/(.*)=$1/branch2/
STAGING/products/$2
tells the proxy server to remap the products directory of any workarea on any
branch named branch1 to the products directory of the staging area on its
sister branch, branch2.
In the source regular expression, (.*) is used to specify an arbitrary path, and
$1 in the destination expression means that it must follow the same path (and
therefore branch1 can be anywhere in the branch structure, but branch2 is a
181
sister branch of branch1). Also in the source regular expression, [^/]+ is used
to specify a single directory level, of any name (which in this case would be the
workarea name, and therefore all workareas on branch1 are specified). Finally,
the source regular expression uses (.*) to specify another arbitrary path, and $2
in the destination expression tells it to follow the same path.
You can also specify the exact location of the areas you want to remap:
_regex=^/
iw-mount/default/main/branch1/WORKAREA/[^/]+/products/(.*)=/
iw-mount/default/main/branch2/STAGING/products/$1
Or, you can specify an individual workarea to remap:

_regex=^/
iw-mount/default/main/dev/branch1/WORKAREA/andre/coolstuff/(.*)=/
iw-mount/default/main/branch2/STAGING/coolstuff/$1
The TeamSite proxy server applies the first match it finds, so you can exclude a
particular area from a more general rule by creating a separate rule for that area
and placing it before the more general rule. For example:
_regex=(.*)/branch1/WORKAREA/chris/products/(.*)=$1/branch1/
STAGING/products/$2
_regex=(.*)/branch1/WORKAREA/[^/]+/products/(.*)=$1/branch2/
STAGING/products/$2
remaps the products directory in all workareas on branch1 except for Chriss
to the staging area of branch2.
See Configure Proxy Failover on page 186 for more details about configuration
rule precedence.
Using iwproxy_preconnect_redirect
To configure TeamSite to redirect workarea views and cause the area you redirect
into to become the current working area (as described in Redirect TeamSite
Views to Different Areas on page 181), edit the
[iwproxy_preconnect_redirect] section of iw.cfg:
[iwproxy_preconnect_redirect]
where source_regex and dest_ex are as described in Using

iwproxy_preconnect_remap on page 184. If you set
[iwproxy_preconnect_redirect] and then click on a link defined by an
absolute path name, the docroot of that link is based on the branch you
redirected into (as opposed to the branch of the area you redirected from, which
would be the behavior if you had set [iwproxy_preconnect_remap]). See
Configure Proxy Failover on page 186 for a details about configuration rule
precedence.
182

You can configure TeamSite to use different Web servers for different workareas
or different types of content. For example, Andre might want to make all
under-development CGIs in his workarea on branch1 be served by
test1.example.com:1234. This would let Andre test different Web server
configurations for his CGIs on branch1 without disturbing anyone else.
To configure TeamSite to use different Web servers, edit the
[iwproxy_preconnect_remap] section of iw.cfg:

area and files to be served by the other Web server, and dest_ex is an
expression describing the area and files on the other Web server. This expression
must include the port number.
For this to work properly, the other Web server must have the appropriate NFS
TeamSite directory mounts and privileges. The Web server alias used by httpd
on port 1234 of test1.example.com must be configured with the TeamSite
alias as well (/iw-mount/).
The following example would allow Andre to test all CGIs in his workarea on
test1.example.com, as previously described:
_regex=^/iw-mount/default/main/branch1/WORKAREA/andre/(.*)\.cgi(\
?.*)?$=http://test1.example.com:1234/iw-mount/default/main/
branch1/WORKAREA/andre/$1.cgi$2
Configure External Remappings

The TeamSite proxy server enables you to define mappings to directories outside
of the TeamSite system or on different computers altogether. You can define these
mappings using either of the following methods:
If you use [iwproxy_preconnect_remap], the mappings follow normal

[iwproxy_preconnect_remap] precedence rules. However,
[iwproxy_external_remap] mappings apply only if no other remapping rule
has been applied.
183
Using iwproxy_preconnect_remap
To configure TeamSite to redirect workarea views to external Web servers, edit
the [iwproxy_preconnect_remap] section of iw.cfg as follows:

area to be mapped from, and dest_ex is an expression describing the area to be
mapped to. These areas are most commonly workareas or staging areas, but you
can map to and from any workarea, staging area, or edition. For example:
_regex=(.*)/branch1/WORKAREA/[^/]+/logos/(.*)=http://
corporateidserver.example.com/logos/$2
sends all requests for files in the /logos directory in all workareas on branch1
to another server, corporateidserver.example.com.
Using iwproxy_external_remap
You can also use [iwproxy_external_remap] rules for external remappings,
although [iwproxy_preconnect_remap] is the preferred methodology.
For example, if all your corporate logo files reside on a separate server, you can
use [iwproxy_external_remap] to create a mapping to the directory where
they reside:
/logos/=http://corporateidserver.example.com/logos/
This remapping sends all requests for /logos/ to a directory on another server,
corporateidserver.example.com/logos/. You can also create
associations using case-insensitive regular expression mapping.
The [iwproxy_external_remap] section is read after the
[iwproxy_remap] section, and is only applied if none of the
[iwproxy_remap] rules were invoked. For example, if you create a mapping for
/logos/ in one of the [branchrewrite] sections, all requests on that branch
for files in the /logos/ directory will use that mapping instead of the external
mapping. Requests on other branches will still be sent to the
corporateidserver.
184

If your Web server manipulates Host: headers (for example, virtual domains),
you can configure TeamSite to replicate that behavior. To configure Host: header
remapping, edit the [iwproxy_hostheader_remap] section of iw.cfg.
[iwproxy_hostheader_remap]

area to be mapped from, and dest_ex is an expression describing the new
Host: header. For example:
_regex=^/iw-mount/default/main/branch1/WORKAREA/.*=example.com:1234
will change the Host: header that the source server gets from the TeamSite
proxy server to read:
Host: example.com:1234
whenever content in a workarea on branch1 is accessed.
Enable iwproxy Access Control

By default, iwproxy allows any authenticated TeamSite user to view any file in
TeamSite. To configure iwproxy to verify the users ability to read certain files in
the file system, add an [iwproxy_access_control_enabled] section to your
iw.cfg file based on the example that follows.
This example implements the following policy:
All users should be able to read any document on the intranet, except for files
in the /hr/ directory, which require specific read access.
All users should be able to read any document on the internet site.
For all other branches, iwproxy should check to ensure the current user has
read access.
[iwproxy_access_control_enabled]
_default=yes
_regex=^/iw-mount/dc/main/intranet/(((WORKAREA|EDITION)/[^/
)]+)|STAGING)/hr/=yes
_regex=^/iw-mount/dc/main/intranet/(((WORKAREA|EDITION)/[^/
]+)|STAGING)/=no
_regex=^/iw-mount/dc/main/www%20external/(((WORKAREA|EDITION)/[^/
]+)|STAGING)/=no
185

The TeamSite Web server plug-in supports the ability to both remap and virtualize
SSI requests. To enable SSI request virtualization, you must install the necessary
redirector module (iwproxy_nsapi.solaris.sodll or
iwproxy_isapi.dll) in addition to the Web server plug-in.
After installing the necessary redirector module as described on as described in
the Web Solutions Authoring Components Installation Guide, you can configure
TeamSite to remap SSI requests by adding or modifying the
[iwproxy_plugin_remap] section of iw.cfg. In the following example, any
SSI request containing the string /forms/ is mapped to /iw-mount/default/
main/Branch2/STAGING/forms instead of being referred to the root of the
users workarea:
[iwproxy_plugin_remap]
_regex=(.*)/forms/(.*)=/iw-mount/default/main/Branch2/STAGING/
forms/$2
If you want to debug regular expressions, set the value for _debug in the
[iwproxy_plugin_remap] section to true. On NES and Apache, debugging
information is stored in the Web server error log file. On IIS, this information is
stored in C:\temp\iw_isapi.log. This log file can grow extremely large over
time.

If a requested page does not exist, the [iwproxy_failover_remap] section
of iw.cfg can be used to specify an alternate location. This section enables you
to specify both alternate locations and the number of times to process an URL in
an attempt to find a valid location. The figure below illustrates the process by
which proxy failover remaps URLs.
186
Figure 20 Proxy failover remap diagram

The proxy server rewrites the URL according to
rules specified in iwproxy_fullproxy_redirect,
iwproxy_remap, iwproxy_external_remap
iwproxy_preconnect_redirect
Can the rewritten

path be found?
Yes
No
iwproxy_preconnect_remap
iwproxy_hostheader_remap
iwproxy_smartcontextedit_allowed
Can the rewritten

path be found?
Has maxfail been
reached?
No
iwproxy_failover_remap
remaps the rewritten URL and

increments maxfail.
Yes
The specified page is returned, if found.
If it is not found, the proxy server returns a
File not found message.
The [iwproxy_failover_remap] section has the following structure:

[iwproxy_failover_remap]
_maxfail=#
To specify the number of times to try to remap a URL, edit the _maxfail line of
the [iwproxy_failover_remap] section of iw.cfg. The default value of this
line is _maxfail=0, which turns off proxy failover. Note that proxy failover is
seldom needed because files are almost always in locations that can be specified
187
using static, case-insensitive regular expressions during configuration. If you need

to enable proxy failover, it is recommended that you do not set _maxfail to more
than 1 or 2 due to the impact on system performance.
To specify expressions to remap, add _regex lines to
[iwproxy_failover_remap]. These lines specify an incoming pattern to
match, and an expression that they should be mapped to. The proxy server will
take the first match it finds, remap it as specified, then try to locate the page. If it
cannot find the new location, it will try to match the remapped expression to a
regular expression specified in [iwproxy_failover_remap]. This process will
continue until a match is found or the number of iterations specified by the
_maxfail line is reached.
_regex lines in the [iwproxy_failover_remap] section follow the same
syntax as _regex lines specified in the [iwproxy_preconnect_remap]
section of iw.cfg, where source_regex is a case-insensitive regular
expression describing the area to be mapped from, and dest_ex is an
expression describing the area to be mapped to. For examples of _regex syntax,
see Resolve Relative and Absolute Paths on page 175.

If your proxy server does not seem to be configured correctly, use the
iwproxy.exe CLTs debug option to list all the translations being made by the
proxy server:
iwproxy [-d|-x]
-d
Debug mode (outputs client & server headers)
-x
Extended (verbose) debug mode (outputs client body text as well)
iwproxy returns debug output which you can redirect to a file. Note that the
iwproxy debug mode is single-threaded; it therefore slows the TeamSite server
down significantly. Use the debug mode for diagnostic purposes only.
One common source of proxy configuration problems is the inclusion of any
character or blank space past the end of a branch name in any line in any
[iwproxy*] section in iw.cfg. For example, the following line in the
[iwproxy_remap] section is illegal because it contains blank spaces and
characters after the branch name:
[iwproxy_remap]
tag_engspecs=/main/engspecs #This is the engineering spec site
188
NOTE iwproxy.exe needs to run as root/local

Administrator or a user with the following access privileges:
Act as Part of Operating System, Log on Locally, Increase
Quotas, and Replace a Process Level Token.
189
190
CHAPTER 9
MediaBin Connector
This chapter describes the configuration of the MediaBin Connector. MediaBin
Connector provides Web content developers seamless access to the business
and creative content managed in MediaBin repositories when using TeamSite for
performing Web content management tasks.
The chapter includes the following topics:
Configure the MediaBin Connector
FormsPublisher Configuration Files
MetaData XML Record
MediaBin Configuration
Troubleshooting
NOTE For information on importing MediaBin assets, refer

to the ControlCenter Professional User Guide.
191
Chapter 9 MediaBin Connector

Configuration of MediaBin Connector involves establishing connectors between
the TeamSite server and the MediaBin servers. Connectors can be established
using one of the following methods:
Trusted login. Connection is attempted using the TeamSite users personal

TeamSite login information. MediaBin trusted login is accomplished using
LDAP authentication. An entry matching the TeamSite user name must be
present in the LDAP.
Trusted login is not supported for root (UNIX) or Administrator (Windows)
accounts. It is intended only for end users.
See MediaBin Configuration on page 205 for more information.
Guest login. Connection is attempted using a Guest account established on

the MediaBin server for use with TeamSite. This account information must be
configured in TeamSite prior to the connection being attempted. This single
account applies to all TeamSite users. This method is also known as proxy
login.
When TeamSite connects to MediaBin, it does not use the identity of the
current TeamSite user. Instead, it impersonates a MediaBin user. The
credentials of these proxy users are stored in the TeamSite system and are
used by all TeamSite users. Autonomy recommends that you do not use the
credentials of a real person, but instead create dedicated user accounts in
MediaBin for use as TeamSite proxy users. The proxy users should be given
read access to those assets that are to be made available to TeamSite; they
do not need any write privileges.
Each server connector exists independently of the other. For example, you can
configure a guest login connector between your TeamSite and MediaBin servers.
Configuration of the connection to DigitalSafe, MediaBin and Optimost servers is
performed through the Connectors tab in the Administration Console.
Display the MediaBin Properties Screen

To display the MediaBin Properties screen
1. In TeamSite, go to ContentCenter Professional.
2. Click Administration to display the Administration Console.
3. Click the Connectors tab.
4. In the left pane, select MediaBin.
The MediaBin Properties screen is displayed.
192
Edit the MediaBin Connector Properties

Use the following procedure to configure the MediaBin Connector to connect to a
MediaBin 8.0 or higher server. To connect to a MediaBin 7.x or earlier server, see
Connect to a Legacy MediaBin Server on page 195.
To edit the MediaBin Connector properties
1. Display the MediaBin Properties screen.
2. Click Edit on the menu bar or right-click and select Edit.
The Edit MediaBin Connector screen is displayed.
193
3. Complete the following attributes in each of the following sections to configure

your MediaBin connector. Note that some attributes only become available
when Legacy Settings are enabled (see Connect to a Legacy MediaBin
Server on page 195). For MediaBin 8.x, complete the following attributes:
MediaBin Server Settings:
Check the associated box to enable direct import.
User Authorization Settings:
Select one of the following authorization options:
194
Login as the TeamSite user. Login to the MediaBin server using the
same user name that was used to login to the TeamSite server. An
entry for this TeamSite user must be present in the LDAP used by
MediaBin.
Login with a MediaBin guest account. Login with the guest user
account you set up on the MediaBin server for use with your TeamSite
server.
Trusted Client:
Complete the following attribute if you selected the Login as the

TeamSite user as your User Authorization Settings option.
Enter the hint required for trusted client access in the Hint field. This is
the same value as is used in the MediaBin web.config files
TrustedClientHint value.
Guest User:
Complete the following attributes if you selected the Login with a

MediaBin guest account as your User Authorization Settings option:
Enter the MediaBin user name of the account in the Name field.
Enter the MediaBin domain (if necessary) in the Domain field.
Enter the password associated with the user name in the Password
field.
File Import Destination Information:
Enter the directory within your TeamSite workarea in which any files
imported from the MediaBin server when using content templates are
written. Note that when you are importing MediaBin assets using the
Import command, files are stored in your current working directory.
4. After you have entered the appropriate attributes, click one of the following:
Save and Test to save the MediaBin connector properties and to test the
connection to the MediaBin server.

Save and Close to save the MediaBin connector properties and close the
window.
Cancel to cancel the changes.
Connect to a Legacy MediaBin Server

To connect to a MediaBin 7.x or earlier server, you must use the Legacy Settings
option. The Legacy Settings dialog box contains some additional attributes.
195
To configure the MediaBin Connector for MediaBin 7.x or earlier

1. Open the Edit MediaBin Connector dialog box.
2. Click Enable Legacy Settings in the top right corner of the dialog box.
The Legacy Settings are displayed.
3. Complete the following attributes:
MediaBin Server Settings:
Enter the name of the MediaBin server hosting the Web services.
Check the associated box to enable a connection to the MediaBin

server you specified.
Check the associated box to enable direct import.
Enter the appropriate URL to point to the MediaBin web services in the
Web Services URL field. In most cases you can simply change the
host name in the default value.
User Authorization Settings:
Select one of the following authorization options:
Login as the TeamSite user. Login to the MediaBin server will be

done using the same user name that was used to login to the
TeamSite server. An entry for this TeamSite user must be present in
the LDAP used by MediaBin.
Login with a MediaBin guest account. Login with the guest user
account you set up on the MediaBin server for use with your TeamSite
server.
Try to login as TeamSite user, use MediaBin if unsuccessful. This

option uses your TeamSite user login information first, but if it is not
successful, then it will try the MediaBin guest account automatically.
Trusted Client:
Complete the following attribute if either the Login as the TeamSite user
or Try to login as TeamSite user, use MediaBin if unsuccessful option
was selected as your User Authorization Settings option.
Enter the hint required for trusted client access in the Hint field. This is
the same value as is used in the MediaBin web.config files
TrustedClientHint value.
Guest User:
Complete the following attributes if either the Login with a MediaBin

guest account or Try to login as TeamSite user, use MediaBin if
unsuccessful option was selected as your User Authorization Settings
option:
196
Enter the MediaBin user name of the account in the Name field.
Enter the MediaBin domain (if necessary) in the Domain field.
Enter the password associated with the user name in the Password
field.
Connection Timeout Setting: Enter the time in seconds before which the
MediaBin connection times out.

File Import Destination Information:
Enter the directory within your TeamSite workarea in which any files
imported from the MediaBin server when using content templates are
written. Note that when you are importing MediaBin assets using the
Import command, files are stored in your current working directory.
Web Client Setting:
Enter the appropriate URL to point to the MediaBin server on which

you can edit assets selected within TeamSite. In most cases you can
simply change the host name in the default value.

The following FormsPublisher configuration files must be modified to use
MediaBin Connector:
datacapture.cfg. Defines rule sets for capturing data.
Presentation templates (.tpl files). Contains HTML code and FormsPublisher

tags to describe the output files.
Samples of these files are included in the following location:
iw-home/examples/Templating/templatedata/MediaBin/
press-release
press-release-immediate
press-release-iwov
Refer to the README file residing at the following location for descriptions of each
of these samples:
iw-home/examples/Templating/templatedata
This chapter assumes the reader is familiar with creating FormsPublisher
datacapture.cfg files and presentation templates. Refer to the TeamSite
FormsPublisher Developers Guide for more information.
197
datacapture.cfg
You can incorporate MediaBin functionality in your FormsPublisher form by
including a dialog for either or both remote servers in your associated
datacapture.cfg file. In the datacapture.cfg file, dialogs are configured
using the dialog element. Each dialog has a set of named parameters that are
used to connect the FormsPublisher form fields to the dialogs inputs and outputs.
Each parameter can have an input, an output, or both. An input parameter can
have an actual value, or it can reference an item whose value will be obtained
when the dialog is activated. An output parameter can only reference an item
whose value will be set by the dialog. The set of output parameters can be
different depending on whether the form is configured to import files from the
remote server immediately upon selection, or whether to wait until the Web page
is actually generated.
Dialog parameters reference items by name, not by path. When a dialog
references an item, it first looks for an item with that name in the same container
as the dialog itself. If it is not found, then it looks in the enclosing (parent)
container, and so on up the hierarchy.
You can configure the dialog element anywhere that an item element can
appear. The dialog element has the following attributes:
type. Specify one of the following values to indicate what type of remote
server is being represented:
mediabin
You must specify a value. There is no default value.
label. Specify the text that appears on the button, for example MediaBin.
The following configuration inserts a MediaBin field into the form, and gives the
associated button the label MediaBin:
<dialog type="mediabin" label="MediaBin">
...
</dialog>
The dialog element can also include the optional rowcontinue and
window-features attributes, which are used elsewhere in the
datacapture.cfg file. Refer to the FormsPublisher documentation for more
information.
Each parameter associated with the dialog is configured within the dialog element
as a separate dialog-param element. The type of parameter is specified by the
dialog-param elements name attribute. For example:
<dialog-param name="path">
...
198
</dialog-param>
...
</dialog>
Inputs and outputs are configured within each dialog-param element using the
dialog-input and dialog-output elements, respectively. Both these types
of elements include the field-ref sub-element, which associates the item
reference to the input or output.
In the following example, the parameter path includes both an input and an
output, while the parameter label includes only an output.
<dialog-param name="path">
<dialog-input><field-ref name="path"/></dialog-input>
<dialog-output><field-ref name="path"/></dialog-output>
</dialog-param>
<dialog-param name="label">
<dialog-output><field-ref name="label"/></dialog-output>
</dialog-param>
Here is a list of parameters used by MediaBin:
immediate. Indicate whether (true) or not (false) the selected MediaBin

asset file is to be imported into TeamSite at the time it is selected within
FormsPublisher, or whether it will exist as a reference pointer until the Web
page is actually generated. Default value is false.
asset-id. The MediaBin ID value for the selected digital asset. The value
can later be used by the presentation template import tags to import the
selected asset. When you specify an input value, it indicates a
previously-selected asset that allows the browser to open up in the context of
that asset.
label. The default file name of the MediaBin asset you selected, or a
user-defined label value. The value you use will appear as the hyperlink text to
the MediaBin asset in the generated Web page.
path. Displays a path on the MediaBin server where the document file can be
accessed.
arearelpath. Indicates the path to the imported MediaBin document relative

to the TeamSite workarea. This value only applies if immediate="true".
format. The desired format for the asset rendition. Use of the following
values:
GIF
JPG
JPEG
199
task. The name of the desired retrieval task. This parameter only applies to
MediaBin version 7.x or lower.
taskId. The ID of the MediaBin retrieval task. This parameter only applies to
MediaBin version 8.0.3 or higher.
width (optional). The width in pixels of the asset.
height (optional). The heght in pixels of the asset.
ceilingDirectory (optional). The MediaBin container path that the user

can browse. The user can only browse assets and containers under this
directory.The leading slash is required; do not include a trailing slash.
Example: /Media Database/TestFolder
destinationDirectory (optional). The path relative to the TeamSite

workarea where the selected MediaBin asset should be imported. This value
only applies if immediate=true. The MediaBin assets path in the
MediaBin repository is not re-created under this TeamSite directory.
Example: pressRelease/images
Use of the format parameter is not compatible with the task, taskId,
width, and height parameters. If you do not specify any of these
parameters, then the asset is imported in its existing state.
The original proportions of the asset will be maintained even if the specified
width and height do not conform to those original proportions. If you specify
the width and height parameter values as each being 0, then the original
dimensions of the asset are used.
Presentation Template Files

MediaBin Connector makes the following tags available to the presentation
templates:
iwov_import_mediabin. Creates a TeamSite file that is a copy or

derivative of an asset in MediaBin. It then emits a URL that points to the
imported file. The URL will be relative to the workarea of the data capture
record.
Refer to your sample presentation templates that were installed with MediaBin
Connector to get additional usage information.
These tags require the IW_AUTH environment variable to be set to a valid value.
This variable will be set when the presentation template is invoked from the user
interface or a workflow external task. If you want to test the presentation template
from the command line, you must set this variable before calling the
iwpt_compile CLT.
200
MetaData XML Record
When these tags are used in a presentation template, the template may not
function if it is applied from the command line (for example, using iwgen or
iwregen) or in a nonstandard execution environment. These tags require access
to a valid TeamSite session string. The session string is provided by
ContentCenter when the Preview or Generate commands are performed and is
provided by the workflow engine if the template is applied in an external task.This
IW_AUTH environment variable can be set to a valid session string if one is not
already available
You can also run the perldoc program to get more information on these tags. To
run this program, navigate to the following location:
iw-home/iw-perl/bin
and enter the following command at the prompt:
Windows. perldoc.bat tagname
UNIX. perldoc tagname
where tagname is one of the MediaBin Connector tags listed at the beginning of
this section, for example:
perdoc.bat TeamSite::PT::iwov_import_mediabin
MetaData XML Record

MediaBin assets have associated metadata. This metadata contains information
about an asset such as the creation date, author name, and description. It can
also contain product-specific information such as a MediaBin repository path. For
a full list of metadata for MediaBin assets, refer to the documentation for these
products.
In MediaBin Connector, the metadata associated with an imported MediaBin asset
is also imported into TeamSite. The imported metadata is represented as an XML
record, and this XML record is written to a TeamSite extended attribute (EA) of the
imported asset. The EA names is:
MediaBin/Metadata. Metadata EA name for a MediaBin imported asset;
The basic structure of the metadata XML record is a document-level metadata

element that contains namespace attributes, and zero or more attribute
metadata child elements and Dublin Core metadata elements. The following is an
example of a partial metadata XML record for a MediaBin file.
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<dc:type>JPEG</dc:type>
201
<attribute>
<name>Asset Type</name>
<value type="xs:string">JPEG</value>
</attribute>
<attribute>
<name>Dimensions (pixels)</name>
<value type="xs:int">300</value>
</attribute>
<dc:date.created>2004-10-19T09:50:00</dc:date.created>
...
</metadata>
attribute Metadata Elements

MediaBin metadata is represented in the XML record within attribute
elements. The metadata name and value is unaltered from the original assets
metadata. An attribute element contains one name child element and zero or
more child elements. The following shows a MediaBin attribute element with a
single value.
<attribute>
</attribute>
This example shows a MediaBin attribute element with multiple values.

<attribute>
<name>Dimensions (pixels)</name>
</attribute>
MediaBin metadata comprises both system metadata, such as insertion time,

modified time, and dimensions, and file format specific metadata for formats such
as JPEG, PhotoShop, and MS Office. All this metadata is represented for a single
asset. For an imported MediaBin asset, the metadata concerns the asset in
MediaBin, not the rendition. For example, if a TIFF file is retrieved as a GIF, the
attributes regarding the format, size and dimensions of the asset will be
appropriate for the TIFF file.
Representation of Data Types

The metadata value element contains a type attribute. This attribute gives the
data type of the metadata value. The W3 standard namespace for data types is
used with the namespace prefix xs. The namespace URI is an attribute of the
metadata element. It is located at the following URL:
202
MetaData XML Record
http://www.w3.org/2001/XMLSchema
The following data types are represented:
boolean
dateTime
double
float
int
long
string
Dublin Core Metadata Elements

The standard Dublin Core metadata element set is used to represent
corresponding MediaBin metadata. Dublin Core metadata elements are qualified
by the Dublin Core namespace with the namespace prefix dc. The namespace
URI is an attribute of the metadata element. It is located at the following URL:
http://purl.org/dc/elements/1.1/
The Dublin Core standard permits omitted or repeated metadata elements. The
Dublin Core element set comprises the following elements:
Title
Creator
Subject
Description
Publisher
Contributor
Content
Date
Type
Format
Identifier
Source
Language
203
Relation
Coverage
Rights
For the Dublin Core Date metadata element there are two qualifiers applied:
Created
Modified
MediaBin metadata elements that correspond to Dublin Core metadata elements

are represented in the metadata XML record as the following:
A Dublin Core metadata element
A proprietary metadata element
This example shows the two elements representing MediaBins Asset Type
metadata: a Dublin Core dc:type element and an attribute element.
<dc:type>JPEG</dc:type>
<attribute>
</attribute>
The following table lists MediaBin metadata elements that correspond to Dublin
Core metadata elements:
Table 10 MediaBin metadata elements
MediaBin
Dublin Core
Name
Title
Asset Type
Type
Check In User
Creator
Insertion Time
Date Created
Modified Time
Date Modified
Custom Metadata
MediaBin supports the generation of custom metadata. MediaBin custom
metadata associated with an asset is captured along with the system and file
format specific metadata.
204
This section contains instructions for configuring your MediaBin server for use
with the MediaBin Connector. The instructions here are supplemental to the
MediaBin product documentation.
The MediaBin Web Service README file contains information on configuring
MediaBin. This file is named readme.txt and resides in the following location:
c:\InetPub\www\MediaBinWebService
Setting Anonymous Access

The MediaBin Web Service depends on anonymous access. To configure this
correctly, follow these steps:
1. For the MediaBinWebService virtual directory, go to the Authentication
Methods screen and turn on the Enable anonymous access check box.
2. For the folder in the MediaBinWebService directory that is used for
transferring files, verify that the Enable anonymous access check box is
turned on.
3. Verify that the anonymous user has read and write access to the temporary
directory specified in the TempPath setting in the MediaBin web.config file.
Configuring MediaBin Trusted Client and LDAP Authentication

Refer to the LDAP Support and Trusted Client Support sections in the
README file for the appropriate information.
Additional information is available in the section on configuring the MediaBin Web
service for LDAP support in the MediaBin Asset Server Administration Guide.
Troubleshooting
This information may provide information on issues related to MediaBin
Connector.
Running MediaBin Connector 1.1 and 2.0 Toolkits Simultaneously

The MediaBin Connector 1.1 and 2.0 toolkits have not been tested together in the
same ContentCenter Web application. If you are upgrading from a system that
uses MediaBin Connector 1.x, the recommended best practice is to remove the
205
MediaBin Connector 1.x toolkit from ContentCenter and migrate existing

datacapture templates and presentation templates to the MediaBin Connector 2.0
solution.
If you want to run both the MediaBin Connector 1.1 and 2.0 toolkits in the same
ContentCenter instance, follow these steps:
1. Back up the following files:
k3.jar
MediaBinServer.jar
from their home location:

iw-home/local/config/lib/content_center/sample_connector_src/
lib
into a backup directory.

2. Extract the following files (using tools such as WinZip or Gnu Zip):
wom.jar
MediaBinServer.jar
from the MediaBinconnector.tk.war file, which resides in the following

location:
iw-home/private/lib/content_center
3. Copy the wom.jar and MediaBinServer.jar files to the location

referenced in Step 1.
4. Rebuild the MediaBin Connector 1.1 toolkit. Refer to the instructions included
with the toolkit for more information.
Import from MediaBin Requires Anonymous Access to the Transfer

Directory
The ability to import digital assets from the MediaBin server requires that IIS be
configured to allow anonymous access to the MediaBin transfer directory. By
default, anonymous access to the transfer directory is not enabled. Refer to your
MediaBin documentation for more information on configuring anonymous access.
Update Required When Using Microsoft Internet Explorer 6.0 SP1

If you are using Microsoft Internet Explorer 6.0 SP1 as your browser, you must
install the following update:
Cumulative Security Update for Internet Explorer 6 Service Pack 1
for
Corporations - Windows XP and Windows 2000 (873377)
206
Troubleshooting
You can obtain this update from the following Microsoft Web site:
http://www.microsoft.com/downloads/
details.aspx?amp;amp;amp;amp;displaylang=en&familyid=8C6560FC-297C
-4982-8BA5-DE7949043B17&displaylang=en
NOTE This link could change at any time.
207
208
CHAPTER 10
Back Up TeamSite
Your TeamSite Content Stores represent a tremendous investment in resources
and are a valuable corporate asset. As such, they should be backed up daily, or
even more frequently, to minimize the possibility of damaged or lost data. Any
third-party backup solution that can guarantee exact time and state directory
content recovery can be used.
Integrate with Third-Party Backup Solutions
Suggested Strategies for Incremental Backups
Integrate with Third-Party Backup Solutions

It is recommended that you use a high-quality third-party backup solution for
protecting the Content Store data. When evaluating a backup solution, the
following criteria are essential:
The backup method must provide a way to perform an iwfreeze operation

prior to performing the backup. This must be done to assure that the Content
Store does not change during the backup. The backup method must then
perform an iwfreeze -- operation to allow writes to the Content Store
when the backup is finished.
The backup method must be fast enough to perform a full or incremental

backup of the Content Store within a reasonable length of time. The maximum
209
Chapter 10 Back Up TeamSite
allowable length of time depends on the requirements of the particular

installation, but should probably be less than 12 hours.
The restore method must provide a way to do a complete state-restore of a

directory as of a given time. This means that when a directory is recovered,
the contents must match exactly what was in the directory at the time the
backup was performed. Only files that were present at the time of the backup
must be present in the restore. That is, if a file was deleted from the original
directory between backups, it should not be present in the restore. For
example, take a backup, delete a file, take another backup; a restore from the
second backup should not contain the deleted file. Some backup and restore
products regard all backed-up files to be sticky, that is, as long as a file ever
existed, it is present in the restoration regardless of whether it was deleted
prior to the last backup.
Additional criteria to consider are:
An automated backup execution facility capable of performing full backups

followed by level (preferred) or incremental backups to provide a customizable
backup strategy.
Automated backup media management and manipulation (for example, a tape

jukebox or silo).
The ability to make copies of completed backups for off-site storage.
If the available backup method is efficient and inexpensive (compared to the value
of the data being protected), the TeamSite workareas can also be backed up to
allow users to recover individual files or directories from their workareas, rather
than having to recover the entire Content Store. This is a very convenient feature
for users, but can come at a relatively high price in terms of extra time and space
needed for these redundant backups. Although the virtual files which comprise
much of theTeamSite file system mount (Y:/iwmnt) take up no extra space on
the TeamSite server, if the actual TeamSite workareas are backed up, the virtual
files in the workareas will be treated as actual files and will take up space in the
backup media.
NOTE Workarea backup must be done through the Y:

drive.
You must freeze the TeamSite Content Store (with the iwfreeze command)
while you are backing up your Content Store or workareas. Failure to freeze the
Content Store while you are backing up can result in possible data loss and
corruption. For details about the iwfreeze CLT, refer to TeamSite
Command-Line Tools for your platform.
210
NOTE If you are using multiple Content Stores, you can

back up each store independently. The iw-store directory
should be backed up if you have in-progress workflows or
batch jobs that you do not want to lose. Because workflows
can span all stores, a full frozen backup of all stores and the
workflow store is needed. You can freeze and unfreeze the
workflow store just like any other store, but you cannot move
it outside of iw-store.
Backing up workareas alone is not a substitute for backing up the TeamSite

Content Store. If you only back up the files that appear in the TeamSite file system
mount, you will lose important metadata such as version histories and file status.
Always back up the actual TeamSite Content Store whether or not you back up
individual workareas.

It is possible to implement a level-oriented backup if a sufficiently sophisticated
backup solution is available. For example, a full backup can be performed on the
first Saturday of the month, then incremental backups that build on each other can
be performed for the rest of the week. On the second Saturday of the month, a
super-incremental backup based on the original full backup done on the first
Saturday is performed. The super-incremental backup supersedes all of the
previous incremental backups. Only the first full backup and super-incremental
are needed to completely recover the Content Store. For the subsequent week,
incremental backups are again performed based on the super-incremental backup
done on the second Saturday. The following Saturday, another super-incremental
backup based on the previous super-incremental file is performed, again
eliminating the need for the previous weeks incrementals to recreate the Content
Store. To perform a recovery at this point, restore the original full backup, then
each super-incremental in sequence, and finally the balance (if any) of the current
weeks incrementals.
This tiered, or level-oriented backup can be repeated on a monthly basis to
produce a week-by-week record of the Content Store. To reproduce the Content
Store as of any particular Saturday, recover the full backup from the beginning of
the month, then apply each Saturday backup in turn until the desired Saturday is
reached.
To determine your optimal backup strategy, you must analyze the trade-offs of
convenience and speed in backing up versus simplicity and speed of restoration,
and decide what best suits your needs. A strategy using a single full backup and
an indefinite string of incrementals is optimized for backup speed, but the amount
211
Chapter 10 Back Up TeamSite
of time required to perform a full recover of the Content Store grows with each
passing day as a new incremental is added to the list. Every backup must be
preserved to be able to recover the Content Store. One benefit of this method is
that a complete daily record of the Content Store will be preserved.
The opposite extreme is to perform a full backup every day. Each backup will take
the maximum amount of time to perform, but only one recover needs to be done
to completely recreate the Content Store. If you only preserve the previous days
backup, no history of the Content Store will be retained, but the amount of storage
space used by the backups is minimized.
212
Appendixes
This section includes the following topics.
Internationalization
Specify Content Encoding
Single Sign-On
Troubleshooting
Appendixes
214
APPENDIX A
Internationalization
This appendix includes the following topics:
Overview
Supported Client and Server Platforms
Supported Content
Limitations and Assumptions
Content Stores and Character Encoding
About UTF-8
URL Commands with Multibyte Characters
Interface with Localized Operating Systems
Access the Localized Interface
Language of the VisualPreview Tool Bar
Run TeamSite CLTs in DOS Console Mode
Specify File Encoding of Text Files
Usage Scenarios
215
Appendix A Internationalization
Overview
TeamSite is engineered with your global enterprise in mind. This includes
internationalizing the TeamSite server to support multibyte languages and locales
at the operating system, and localizing the ContentCenter user interface and
documentation. Internationalized TeamSite supports the following needs:
International user data. Enables users to enter data, content, and field values
in English, Korean, Traditional Chinese, Simplified Chinese, French, German,
and Japanese.
Localized operating system. The TeamSite server runs on any one of the
following localized operating systems: English, French, German, Korean,
Simplified Chinese, Traditional Chinese, and Japanese (one locale per
instance of iwserver).
Localized user interfaces. The ContentCenter Professional and

ContentCenter Standard interfaces have been localized into French, German,
Japanese, Korean, Traditional Chinese, and Simplified Chinese.
Localized file names. You are no longer restricted to having file and directory
names in ASCII character encoding. For example, file, directory, branch,
workarea, and edition names can have Japanese names on Japanese
servers, German names on German servers, Simplified Chinese names on
Simplified Chinese servers, and so forth.
Continued support for processing of non-English metadata and

FormsPublisher content.
NOTE Information on localized servers contained in this
chapter is only valid with localized TeamSite versions.
Check the Release Notes to determine whether localized
servers are supported in your TeamSite version.
Supported Client and Server Platforms

The client connecting to the TeamSite server must use the same language as the
server (they can be different locales of the same language). For example, running
ContentCenter on German Windows connected to a Solaris TeamSite server
running in the German Latin 1 locale (de) is supported. However, if that same
German Windows client logged into a Windows Japanese TeamSite server and
216
Supported Content
added files with names containing German High ASCII characters, those files
would not be supported by the TeamSite server due to limitations with the native
file system and handling of characters outside of its code pages.
Supported Content
TeamSite supports non-ASCII characters in branch, area, directory, vpath, and
file names in addition to the contents of a file.
Limitations and Assumptions
An internationalized TeamSite server does not mean that your TeamSite

server can be run in multiple locales concurrently. The TeamSite server can
run in any supported locale, but one locale at a time.
It is expected that the locale in which the TeamSite server runs is the same
locale as the rest of file system and server operating systems. Consider the
following scenario:
a. You have a file server which runs in ja (Japanese Extended UNIX Code)
locale, with a hierarchy of file and directory structures with names encoded
in Japanese EUC.
b. You install and run your TeamSite server on this file server.
c. You use the file system interface to migrate your existing hierarchy of files
and directories into the TeamSite File System (/iwmnt).
d. The TeamSite server must run in the ja locale for these file and directory
names to be processed correctly. If you change the locale to ja_JP.PCK
(Japanese Shift-JIS) before TeamSite server is started, the TeamSite
server would incorrectly interpret the imported file and directory names as
ja_JP.PCK encoded. This is not a supported scenario.
Mixed-locale file systems are not supported. For example, a scenario where a
parent directory has directory names encoded in ja_JP.PCK (Japanese
Shift-JIS, and child directories have file names encoded in ja is not
supported.
If TeamSite server is running on a German operating system using a German

Latin1 locale, it is possible to create a branch or workarea on the TeamSite
File System with Japanese names using ContentCenter. However, when
viewed with the file system interface, these Japanese names would appear as
illegible characters because the server is running in a Latin1 locale and
does not include the Japanese character set. This is not a supported scenario.
217
This scenario is supported for Metadata because Metadata entered using the
ContentCenter does not interact with server operating system. Any data that is
interchanged with the server operating system (including VPATHs) are only
meaningful if they are within the server locales encoding.
If the TeamSite File System is functioning as a networked file server, it is

expected that all other networked file system clients (for example, NFS clients)
are operating in the same locale as the TeamSite File System file server.
Currently, NFS does not enforce this restriction and therefore enables NFS
clients to be in a different locale than the NFS server. However, NFS protocol
does not do encoding conversion. Therefore, file and directory attributes
(including names) are passed through in binary format. This would not work
for TeamSite File System functioning as a file server because it does encoding
conversion from and into UTF-8 based on the server file systems locale.
Content Stores and Character Encoding

User-defined Content Stores that are named using multibyte characters must
have a corresponding entry in the iw.cfg file. Refer to the Web Solutions
Authoring Components Installation Guide for detailed information on creating
Content Stores.
About UTF-8
UTF-8 is the 8-bit encoding format for Unicode. Unicode is a system for
exchanging, processing, and displaying diverse written languages. Unicode
supports the principal written languages of the world as well as many classical
languages.
URL Commands with Multibyte Characters

When constructing URL commands when parameters contain multibyte
characters, make sure that these parameters are URL- and UTF-8--encoded.
Multibyte characters should be URL-encoded based on their Unicode
representation in UTF-8.
For example, the URL to edit the file:
/archive/main/WORKAREA/area/
218
.html
would be:
/iw/iw-cc/edit?vpath=/archive/main/WORKAREA/area/%e5%ba%9c.html
since the Japanese character

is Unicode character U+30D5, which is encoded
as the bytes 0xe5 0xba 0x9c in the UTF-8 format.

The internationalized TeamSite servers virtualized Intelligent File System (IFS)
functions the same way a regular file system does on localized operating systems.
For example, if TeamSite runs on a server that is running in the EUC-JP locale,
the TeamSite IFS is displayed and functions as an EUC-JP encoded file system.
To achieve this, TeamSite system calls to the operating system are converted
from UTF-8 encoded textual data (for example, VPATH information) into the locale
of iwserver (as defined by the server_locale setting in iw.cfg). In most
cases, this is the same as the operating systems native locale. The conversion is
also required when operating system information is returned to TeamSite.
NOTE If the TeamSite server is run in a different locale than
the host operating systems locale, the TeamSite virtual file
system would use a different encoding locale compared to
the rest of host servers file systems. By default, the
TeamSite server locale uses the native locale of the host
operating system.
Access the Localized Interface

To display the localized (French, German, Japanese, Korean, Traditional Chinese,
or Simplified Chinese) ContentCenter interface, you must change your browsers
language settings to the appropriate language.
To display the localized (French, German, Japanese, Korean, Traditional Chinese,
or Simplified Chinese) Local File Manager interface, your client operating system
must be in the same language as the interface you want to display.
219
Language of the VisualPreview Tool Bar

The language of the VisualPreview tool bar normally follows the browser's
language settings, as does the rest of ContentCenter user interface. The
exception is when the character encoding of the document being worked on
through VisualPreview conflicts with the chosen user interface language
(browser's settings).
For example, an HTML document being worked on through VisualPreview has a
specified charset of Shift_JIS, but the chosen user interface language is
German. In this case, the VisualPreview tool bar cannot appear in German.
Instead, the tool bar appears in English. If the document being worked on through
VisualPreview is in ISO-8859-1 encoding, then the Visual Preview tool bar
appears in German. Whenever there is a conflict, the tool bar appears in English.
The following table lists the encodings that are allowed for specific browser's
language settings.
Table 11 Language Encodings
Encoding of document (charsets)
220
Allowed Languages
(browser's settings)
shift_jis, shift-jis, x-ms-cp932,

x-sjis, ms-Kanji, cp932, euc-jp,
x-euc-jp, x-euc
Japanese or English
gb2312, chinese, GB2312-80,

GB231280, GBK, euc-cn, x-euc-cn,
cp936
Simplified Chinese (PRC) or

English
ks_c_5601-1987, euc-kr, korean,

KSC5601, KSC_5601, cp949
Korean or English
iso-8859-1, Windows-1252, Latin1,

latin1, iso_8859-1
German, French, or English
us-ascii, us, x-ansi, ISO646-US,

ascii
English only
utf-8, utf-16be,utf-16le
Japanese, Simplified Chinese,

Korean, German, French, or
English

By default, the TeamSite Server (like most Windows applications) uses code page
1252 on Single Byte Character Set (SBCS) systems in English and German.
However, the DOS command window uses different OEM code pages for SBCS
English systems and German systems. This difference can cause CLT output to
be displayed incorrectly.
Table 12 Code Pages for CLTs
Single Byte Character
Set System Language
Default Code
Page
DOS Command Window

OEM Code Page
English
1252
437
German
1252
850
To avoid this issue, complete the following procedure before running any CLT on
SBCS systems.
1. Open the DOS command window.
2. Right-click on the command windows title bar and choose Properties from
the menu.
The Properties dialog box is displayed.
3. Click the Font tab.
4. Select Lucida Console font from the Font list, and click OK.
The Apply Properties dialog box is displayed.
5. Select Save properties for future windows with same title, and click OK.
6. At the DOS prompt, type chcp and press Enter.
The system returns the active code page number: 437 for English systems, or
850 for German systems. Record the code page number so you can revert to
the default code page for commands that require it.
7. Type chcp 1252 and press Enter to change the code page to 1252.
The system confirms the active code page is set to 1252. All command
window input and output will use this code page.
221
Specify File Encoding of Text Files

All browsers rely on default settings to guess the encoding of web pages whose
encoding is not explicitly declared. If the browsers default setting is different than
that of the actual encoding of the page passed to the browser, the browser may
render the page incorrectly. Therefore, the best practice is for your web pages to
always declare their encoding. This prevents your browser from guessing
incorrectly when you use TeamSite, and ensures that your web site viewers
browsers will not have to guess which encoding they should use.
For HTML documents, VisualPreview honors the encoding specified by the
charset parameter in either a Content-Type HTTP header or in an HTML
META tag. For example:
Content-Type: text/plain; charset=UTF-8
<META HTTP-EQUIV="Content-type" CONTENT="text/html;

charset=UTF-8">
To display multibyte characters in non-HTML text documents in VisualPreview

with the desired character encoding, the content webserver must be configured to
return a Content-Type HTTP header that specifies the encoding, for example:
Content-Type: text/plain; charset=UTF-8
If the charset is not specifiedeither by the content webservers

Content-type HTTP header, or by the charset tag within the file
VisualPreview assumes that the document is encoded in ISO-8859-1, which
may cause the document to be displayed with garbage characters.
NOTE To solve the issue of text files that do not specify
their encoding, use the file_encoding.cfg
configuration file. Refer to Specify Content Encoding on
page 227 for detailed information about creating configuring
settings in file_encoding.cfg.
222
Text Editor Encodings

The following table shows the default settings for various text editors and how to
modify them to use UTF-8 encoding.
Table 13 Default Encodings for Text Editors
Text
Editor
Platform
Notepad
Windows
Wordpad
Windows
Default
Encoding
To Save as UTF-8
Encoding:
ANSI (relative
to the localized
operating system)
Select File > Save As.
Rich Text Format

(RTF) (relative
to the localized
operating system)
Select UTF-8 in the

Encoding drop down menu.
Select File > Save As.
Select Unicode Text
Document in the Save as
type drop down menu.
vi
Solaris
Depends on the
locale of vis active
process.
Cannot save or render text as

UTF-8.
emacs
Solaris
Depends on the
locale of emacs
active process.
Cannot save or render text as

UTF-8.
Behavior of Netscape Navigator

If a Netscape browser finds a UTF-8 page, it uses UTF-8 as its default encoding
for pages that do not specify their encoding. This may cause the browser to
display pages incorrectly if the user browses pages that do not specify their
encoding, or creates pages without specifying the encoding.
Scenario 1
1. A Japanese user goes to a Japanese site which does not specify its encoding.
Netscape defaults to Japanese (Auto-Detect).
2. The Japanese user logs into TeamSite (UTF-8 pages). Netscape switches to
UTF-8.
3. The Japanese user opens a new window and returns to the Japanese site
which does not specify its encoding. Now Netscape defaults to UTF-8.
This would not happen if the site specified the encoding of its web pages.
223
Scenario 2
1. A Japanese user logs into TeamSite (UTF-8 pages). Netscape switches to
UTF-8.
2. The Japanese users content in TeamSite does not include the Content-type
META tag.
3. Upon entering SmartContext QA, Netscape tries to render the content as
UTF-8, which is probably wrong. The solution to this problem is to always
specify the encoding for all HTML content.
Configure Netscape for Multibyte Characters

Complete the following procedure if you are using a Netscape browser to display
multibyte characters:
1. Open your Netscape browser.
2. Select Edit > Preferences to display the Preferences dialog box.
3. Click Appearance > Fonts to display the Fonts settings.
4. Set the For the Encoding field to Unicode.
5. Set the Variable Width Font field to a font which supports the language you
want to use.
6. Set the Fixed Width Font field to a font which supports the language you
want to use.
7. Click the Use my default fonts, overriding document-specified fonts
option.
8. Click OK.
If this procedure does not deliver the expected results (that is, certain characters
are not displayed properly), try the following procedure:
1. Select View > Character Set > Set Default Character Set.
2. Select View > Character Set > Unicode (UTF-8).
Usage Scenarios
The following examples illustrate some of the advantages of using TeamSite in a
global enterprise. Note that a branch scenario could also apply to a workarea,
directory, or file operation (for example, New Branch, New Workarea, and Import
File). Scenarios can also be applied to other locales.
224
Usage Scenarios
Scenario 1
1. The TeamSite server is running in the Windows Japanese /ja_JP.PCK
(Shift-JIS)locale on Solaris.
2. You create a branch with a Japanese name using ContentCenter running on
Japanese Windows. This branch is created in the TeamSite File System with
Windows Japanese/Shift-JIS encoding.
3. You can navigate this branch with the Japanese name using ContentCenter.
4. You can also log on to the server machine and access this branch with
Japanese name using the file system interface (Windows Explorer).
Scenario 2
1. The TeamSite server is running in the Windows Japanese /ja_JP.PCK
(Shift-JIS)locale on Solaris.
2. Your TeamSite Administrator copies a directory from the Windows Explorer file
system into the TeamSite File System. This directory contains file and
directory names with Japanese encoded names.
3. Your TeamSite Administrator creates a file in the TeamSite File System with a
Japanese (Shift-JIS) encoded name.
4. ContentCenter users (on any client platform) can view and access this
directory (and corresponding files) with a Japanese name.
Scenario 3
1. You install and run TeamSite on a Japanese Solaris system in the ja_JP.PCK
locale. The file server for this system operates in the Shift-JIS locale
(ja_JP.PCK locale on Solaris is a Shift-JIS locale.
2. You create a branch with a Japanese name using ContentCenter.
This branch is displayed in /iwmnt as a directory with a Shift-JIS encoded
directory name and is displayed in all typical file system operations with a
Shift-JIS encoded directory name just like the other files and directories in
the file system.
Scenario 4
1. You install and run TeamSite on a Japanese Solaris system in a ja_JP.PCK
locale. The file server for this system operates in the Shift-JIS locale.
2. You copy an existing hierarchy of files and directory structures into a workarea
called isuzuki within /iwmnt.
3. You use ContentCenter to access the isuzuki workarea.
225
The file and directory hierarchy display with Japanese directory and file names
and is correctly referenced in ContentCenter.
Scenario 5
1. Type an iwsubmit command in a shell window running on a Japanese
system.
2. Create submit comments in Japanese.
3. Execute the iwsubmit command. In ContentCenter, the Japanese submit
comments are displayed correctly with the corresponding entity submitted.
Scenario 6
1. You install and run TeamSite on a Japanese Solaris system in a ja_JP.PCK
locale.
2. Using ContentCenter, you submit a file and comments in Japanese.
3. You use the iwsubmit CLT to view the extended attributes of the file.
The Japanese submit comments are displayed correctly on the command-line.
After executing the submit, the same submit comments are displayed correctly
in history log of the file submitted.
226
APPENDIX B
Specify Content Encoding

TeamSite includes a configuration file called file_encoding.cfg that enables
you to create rules to determine the character encoding of the contents of files
that do not specify their encoding. The file_encoding.cfg file (located by
default in iw-home\local\config) uses an XML-based language called
regex_map. The regex_map format is designed to be structured enough for
maintainability, and extensible so that the same format may be used in future
configuration files. This file contains a <regex_map> element, which contains
rules to map vpaths (directory paths) to the character encoding specification of
file contents.
For TeamSite to correctly interpret a text document, it is necessary to know the
character encoding in which its contents are represented. Unlike an HTML
document that can declare the encoding of its contents using an <HTTP
META="Content-Type" CONTENT="text/html; charset=charsetname">
tag, a plain text file has no mechanism for storing this information. The encoding is
required for certain TeamSite functionality including VisualPreview and the Source
Differencing and Merge tools.
In previous releases, VisualPreview relied on the Content-Type header from the
content Web server to specify the encoding of plain text files. This required you to
configure the encoding at your content Web server which may limit flexibility and
scalability. By default, the Source Differencing and Merge tools assumed that text
files are encoded in ISO-8859-1, which is not suitable for content in eastern
Asian languages.
The following sections describe the regex_map language, and how it is used to
specify the character encodings of text files used by TeamSite:
regex_map Defined
227
Appendix B Specify Content Encoding
The regex_map Format
Strategies for Effective regex_maps
Internationalization and regex_maps
VisualPreview and file_encoding.cfg
Source Differencing and Merging and file_encoding.cfg
regex_map Defined
A regex_map is a filter that transforms a set of input variable values into a set of
output variable values through a set of rules written in XML using the following
form:
Input Variables
var1 = "original value1"
var2 = "original value2"
regex_map
<regex_map>
<match .../>
<subst .../>
<subst .../>
<match .../>
</regex_map>
Output Variables
var1 = "transformed value1"
var2 = "transformed value2"
var3 = "new value3"
Simple regex_map Example

The following regex_map determines the character encoding of TeamSite files.
Each reg_vpath means that a match is to be performed on the vpath variable,
and each val_encoding assigns a result if the match succeeded.
228
Input Variable
vpath = path of a TeamSite file
regex_map
<regex_map>
<match reg_vpath= "/web/techsupport/jp/" val_encoding= "Shift_JIS"/>
<match reg_vpath= "\.txt$" val_encoding= "8859_1"/>
<match reg_vpath= ".*" val_encoding= "UTF8"/>
</regex_map>
Output Variable
encoding = character encoding
for the given vpath
In the preceding regex_map example:
If the input vpath variable is "/x/y/z.txt", the resulting encoding variable

is set to "8859_1" because "/x/y/z.txt" ends with ".txt".
All files in the /web/techsupport/jp branch are encoded in Shift-JIS,

because their vpath begins with "/web/techsupport/jp/".
If the input vpath variable does not contain "/web/techsupport/jp/",

the output encoding variable is set to "UTF8" because ".*" matches any
string.
Each rule within <regex_map> is evaluated in order, the first <match> tag with a
regular expression that matches the input variable vpath is used, and
subsequent rules are ignored. Therefore, it is important for the <match
reg_vpath= ".*" val_encoding= "UTF8"/> rule to appear last.

A regex_map consists of a <regex_map> element that contains substitution and
match rules expressed by using <subst> and <match> tags. Substitution and
match rules are consulted in the order in which they are listed within the
<regex_map> element. Each rule may assign values to variables.
229
Rule Syntax
Every <subst> or <match> rule expresses the following logical operation:
If all the regular expressions within this rule match, then perform all of this
rules variable assignments; otherwise, ignore this rule and consult the next
rule.
Execution terminates when the first <match> rule has been applied, or when
there are no more rules. A <subst> rule that has been satisfied does not
terminate execution (unless it is the last rule).
All attributes of rules use the form reg_varname or val_varname.
reg_varname attributevApplies a regular expression to varname.
val_varname attribute. Assigns a value to varname if all of the regular

expressions in the current rule are satisfied.
The following are some simple examples of rules.
If vpath starts with /default/main/ set the encoding to 8859_1 and

continue processing:
<subst reg_vpath="^/default/main/" val_encoding="8859_1"/>
The encoding of all files named index_zh_TW.html anywhere in the /web

branch is Big5. There are no exceptions to this rule, so stop processing if it
applies.
<match reg_vpath= "^/web/(STAGING|WORKAREA|EDITION).*/
index_zh_TW.html"
val_encoding= "Big5"/>
Note that the or capability of regular expressions, expressed by the pipe

character ( | ), enables this single rule handle three cases at once (STAGING
or WORKAREA or EDITION).
The encoding is always "Shift_JIS".

<match val_encoding="Shift_JIS"/>
When there are no reg_ conditions, the assignment always executes if the
rule is encountered. Any rules that occur after this statement are unused.
Regular Expression Syntax

The regex_map interpreter uses Perl-Compatible Regular Expressions (PCRE)
as its regular expression engine. The PCRE is similar to the Perl regular
expression engine and includes advanced features such as lookahead
assertions.
230
Regular expressions in regex_map are case-sensitive by default. If a variable is

listed in the opt_case_insensitive attribute of <regex_map>, all regular
expressions applied to that variable in the regex_map are case-insensitive.
For example, because filenames and URLs are case-insensitive on Microsoft
Windows, the following declaration would be recommended when writing a
regex_map for a TeamSite server on Microsoft Windows:
<regex_map opt_case_insensitive="vpath url">
<subst reg_vpath="..." .../>
<match reg_url="..." .../>
</regex_map>
Variables
Variables store strings to be passed in the following ways:
As input to a regex_map from an application.
From rule to rule within a regex_map.
As results from a regex_map to the application.
Variable names are case-sensitive and must begin with a letter and may contain
any sequence of alphanumeric characters and the underscore character ( _ ).
References to any variable whose value is not set by the application or by rules in
the regex_map evaluates to an empty string.
Application Variables
Any application that uses a regex_map gives it a set of inputs before execution
and inspects a set of output variables when the regex_map processing
completes. These input and output variables are known as application variables.
Intermediate Variables
You may find it helpful to assign intermediate results to your variables in
regex_map rules before arriving at final output values. These intermediate
variables can help make a complex set of rules more manageable by factoring out
several separate conditions into one condensed case. You can then write one rule
to act on the condensed case, instead of repetitively writing the same actions for
the individual initial conditions. Strategies for Effective regex_maps on page 236
contains an example of factoring.
Intermediate variables should have names that begin with x_ to avoid conflicts
with application variables that may be created in the future.
231
Interpolation of Variables and Captured Subexpressions

When assigning a value to a variable, the values of other variables can be
included. In val_attributes, each occurrence of ${varname} or $varname
causes the value of varname to be inserted instead, as shown in the following
example:
Input Variables
good = "Bon"
my = "mon"
friend = "ami"
regex_map
<regex_map>
<subst val_french="${good}jour"/>
<match val_friend="copain"
val_french="$french, $my $friend!"/>
</regex_map>
Output Variables
good
my
friend =
french =
= "Bon"
= "mon"
"copain"
"Bonjour, mon ami"
In the preceding example:
In the <subst> rule, curly braces ({ }) are required to separate the variable
name good from the literal string jour that immediately follows.
In the <match> rule, there is no need to disambiguate the three variables

because the variable names french, my, and friend are followed by a
comma, a space, and an exclamation point, none of which can be confused as
being part of a variable name.
In the second rule, the values of friend and french are taken from the time
at which the rule was encountered. All assignments in a rule appear to occur
simultaneously and do not affect each other.
It is also possible to include just portions of variables. Placing parentheses around

portions of a regular expression applied to varname creates a captured
subexpression variable that can be used when assigning values. The longhand
form of a captured subexpression variable is ${varname:n}, which refers to the
string captured by the nth pair of parentheses in reg_varname.
232
NOTE Pairs of parentheses are numbered according to the

order in which their left parenthesis occurs within the regular
expression. Parentheses of the form
(?:some_expression) are used solely for grouping
characters in the regular expression, not for capturing text
during matching, and are excluded from the count.
The shorthand version of a captured subexpression variables is $n. Note that the
shorthand notation can only be used when the variable being modified is the same
as the variable from which the subexpression was captured.
Unlike application and intermediate variables, captured subexpression variables
are scoped to the <subst> or <match> rule that created them. If a captured
subexpression variable needs to be used in a subsequent rule, it should be stored
in an intermediate variable.
For example, the pair of rules in the following regex_map makes the assignment
message="regex_maps are awesome maps!" in an inefficient way:
Input Variables
text = "My, how large your eyes are!"
message = "regards some maps with awe"
regex_map
<regex_map>
<subst reg_text="This regular expression match fails"
reg_message="some (m[aeiou]ps)"
val_text="so this assignment never occurs..."
val_message="... and the $1 capture is wasted."/>
<subst reg_text="(?:(bloop)|([a-z]+)(!))"
reg_message="(...)ards ((.{4}) (.{4})) with (.*)"
val_message="$1ex_${4} ${text:2} ${message:5}$2${text:3}"/>
</regex_map>
Output Variables
text = "My, how large your eyes are"
message = "regex_maps are awesome maps!"
In the previous example:
The first rule does not apply because the value of the text variable does not
match the regular expression in reg_text.
233
While performing the regular expression match for message, the special
variable ${message:1} (the $1 variable associated with message) takes on
the value maps within the scope of the rule. However, since the entire rule is
inapplicable, it has no effect. Neither of the two val_assignments happens,
and the temporary ${message:1}="maps" binding is discarded.
The second rule does apply, since both of the reg_text and reg_message
matches succeed. The parentheses also capture the text in the strings,
resulting in the following temporary bindings:
${text:1} = empty string
${text:2} = are
${text:3} = !
${message:1} = reg
${message:2} = some maps
${message:3} = some
${message:4} = maps
${message:5} = awe
Finally, variable interpolation occurs for the val_message assignment. Since

the $1, ${4}, and $2 occur in a val_message context, they are treated as
shorthand for ${message:1}, ${message:4}, and ${message:2},
respectively. The curly braces for ${4} are optional in this case, and could be
used in other situations to clarify where the variable name ends and literal text
begins.
Quoting
Inside a val_ attribute, dollar signs ($) have special meaningthey mark the
start of captured subexpression names. To force a dollar sign to lose this special
meaning (and be treated as a literal dollar sign), it must be escaped by preceding
it with a backslash. Similarly, a backslash is treated as a special quoting character
unless it is escaped by a preceding backslash.
234
Input Variable
hello = "Hi"
regex_map
<regex_map>
<subst reg_hello="(.*)"
val_hello="$1! Parking costs \$1\\hr."
</regex_map>
Output Variable
hello = "Hi Parking costs $1\hr."
In the preceding example, hello is assigned the value "Hi! Parking costs
$1\hr." (with the deliberately wrong backslash used instead of a forward slash
for demonstration purposes).
Also, because regex_map is written in XML, characters with special meaning in
XML need to be represented using XML entities. These special characters are
described in the following table.
Table 14 XML Special Characters
Special XML
Character
Visual
Representation
XML Entry
Double quote
"
Apostrophe
'
Ampersand
&
&
Greater than
>
>
Less than
<
<
For example,
<subst val_statement="Programmers think "1 & 1 is
1.quot;"/>
assigns the following value to the statement variable:

Programmers think 1 & 1 is 1.
235
Strategies for Effective regex_maps

The regex_map grammar is a powerful string manipulation language yet still
allows simple configurations to be expressed simply. This is due to:
the ability to work with multiple variables
the use of regular expressions with the capability to reference captured

subexpressions
the option to chain rules with <subst> or stop processing with <match>
By taking advantage of these features, you can write configuration files that are
compact and manageable.
The following example demonstrates how factoring and intermediate variables
can make a regex_map configuration scale to handle complex situations.
Suppose that a system-wide reorganization forced you to rename all files named
README to README.TXT and relocate all files under the /a/b branch to the /c/d
branch. You could list all of the possibilities as follows:
<regex_map>
<!- Handle both branch move and file extension addition ->
<match reg_vpath= "/a/b/((WORKAREA|EDITION|STAGING).*)README$"
val_vpath= "/c/d/$1README.TXT"/>
<!- Handle branch move only ->
<match reg_vpath= "/a/b/((WORKAREA|EDITION|STAGING).*)"
val_vpath= "/c/d/$1"/>
<!- Handle file extension addition only ->
<match reg_vpath= "(.*)/README$"
val_vpath= "$1/README.TXT"/>
</regex_map>
But this strategy could become extremely complicated if there were more
combinations. A factored set of rules can handle each change independently:
<regex_map>
<!- Handle a possible branch move ->
<subst reg_vpath= "/a/b/((WORKAREA|EDITION|STAGING).*)"
val_vpath= "/c/d/$1"/>
<!- Handle a possible file extension addition ->
<subst reg_vpath= "(.*)/README$"
val_vpath= "$1/README.TXT"/>
</regex_map>
236
A complicated set of rules could be clarified with intermediate variables, for

example:
<regex_map>



<subst reg_vpath="^(.*?)/((?:WORKAREA|EDITION|STAGING).*)"
val_x_branch="${vpath:1}"
val_x_rest="${vpath:2}"/>
<subst reg_x_rest="((?:WORKAREA|EDITION)/[^/]+|STAGING)(.*)"
val_x_area="${x_rest:1}"
val_x_rest="${x_rest:2}/>
<subst reg_x_rest="(.*)(/.*)"
val_x_dir="${x_rest:1}"
val_x_file="${x_rest:2}"/>


<subst reg_x_branch="^/a/b$"
val_x_branch="/c/d"/>
<subst reg_x_file="^/README$"
val_x_file="/README.TXT"/>


<subst val_vpath="$x_branch$x_area$x_dir$x_file"/>
</regex_map>
In the preceding example, factoring out the vpath decomposition logic simplifies
the actual transformation rules. In a complex situation with many transformation
rules, adding a few standardized rules at the beginning and end of the
regex_map is worthwhile.

TeamSite regex_maps should be written in UTF-8 and should provide UTF-8
input values and expect UTF-8 output values for all variables. The regular
expression engine is UTF-8-aware. For example, a period (.) in a regular
expression matches a single character, regardless of the number of bytes needed
to represent that character.
If you need to specify non-ASCII literal characters in your regex_maps, ensure
the text editor you are using can edit and save the file_encoding.cfg in
UTF-8 encoding. Refer to Specify File Encoding of Text Files on page 222 for
details about text editor encodings.
237
VisualPreview and file_encoding.cfg

To determine the encoding of a text file, VisualPreview mimics the behavior of
your web browser by performing the following series of checks:
First, VisualPreview checks the Content-Type header from the content

webserver. If the MIME type (text/html or text/plain) is followed by a
character encoding declaration (for example, Content-Type: text/
plain; charset=UTF-8), it uses the specified encoding.
If the file is an HTML document, VisualPreview searches for a character

encoding declaration in an HTML META tag (for example, <META
HTTP-EQUIV="Content-Type" CONTENT="text/html;
charset=Big5">), which it uses if found.
If the aforementioned methods do not return the encoding, VisualPreview

computes the encoding using the regex_map configuration in the
file_encoding.cfg file. It uses the vpath as the input variable and the
encoding as the expected output.
Source Differencing and Merging and

file_encoding.cfg
Unlike VisualPreview, the Source Differencing and Merge tools do not mimic your
web browser. Instead, they rely entirely on the file_encoding.cfg file to
determine the character encoding of text documents. The Source Differencing and
Merge tools assume that the other file and the common ancestor file share the
character encoding of the workarea file.
The following list of encodings are the IANA preferred charset names (http://
www.iana.org/assignments/character-sets) and are valid entries for
the file_encoding.cfg file:
English, German:
ISO-8859-1
ISO-8859-15
windows-1252
Japanese:
238
Shift_JIS
EUC-JP
Source Differencing and Merging and file_encoding.cfg
Korean:
EUC-KR
Simplified Chinese:
EUC-CN
GB2312
Unicode:
UTF-8
NOTE file_encoding.cfg has no effect on the file
encoding seen in visual differencing. This is so that what is
seen in the visual differencing tool most closely
approximates what will be seen in the production
environment.
Sample file_encoding.cfg


<vpath_to_encoding_map>

<regex_map opt_case_insensitive="vpath encoding">

<subst val_encoding="8859_1"/>

<subst reg_vpath="(?:_ja|_jp|_jpn)\."
val_x_lang="Asian:Japanese"/>

<subst reg_vpath=".*\.zh\.txt$"
val_x_lang="Asian:Chinese"/>

<subst reg_x_lang="Asian:Japanese"
val_encoding="Shift-JIS"/>

<subst reg_x_lang="Asian:Chinese"
val_encoding="Big5"/>
239

<subst reg_vpath="(?:(?:WORKAREA|EDITION)/[^/]+|STAGING)/
([^/]+)/"
val_encoding="${vpath:1}"/>

<match reg_encoding="(sjis|shift[_-]jis)"
val_encoding="Shift_JIS"/>
</regex_map>
</vpath_to_encoding_map>
240
APPENDIX C
Single Sign-On
This chapter describes the procedure for configuring TeamSite to integrate with
single sign-on (SSO) authentication products. These products include SiteMinder
from Computer Associates as well as authentication software from other vendors.
The integration enables:
The TeamSite server to act as another web server in a portal environment

controlled by the SSO product.
A single sign-on where TeamSite users log in once against the SSO
authentication engine and are authorized to access all of its resources
(TeamSite and the other web servers in the portal) without having to log in to
TeamSite explicitly.
The appendix includes the following topics:
Overview
Integrate SiteMinder and TeamSite with an Active Response
Integrate SiteMinder and TeamSite Without an Active Response
Integrate an SSO Product Other than SiteMinder with TeamSite
Troubleshooting
241
Appendix C Single Sign-On
Overview
TeamSite provides a framework providing integration with SiteMinder. You can
also use this framework to integrate SSO products from other vendors. See the
TeamSite Release Notes for details about which SSO products are currently
supported.
After completing the integration described in this chapter, the SSO product
controls access to TeamSite by authenticating the user against its user database
and placing an authentication cookie in the browser. Three different integration
scenarios are described in detail:
Integrating CA SiteMinder with TeamSite together with the Active Response

module. This is the same integration that was supported in previous versions
of TeamSite and is the recommended configuration. No SiteMinder Policy
Server configuration changes are necessary when an existing system is
upgraded to TeamSite 6.7.1 or later from TeamSite 6.5 or 6.7. However, if you
are using an older Web Agent that does not support Apache 2, you will need to
upgrade to a version that supports Apache 2. See Install and Configure the
SiteMinder Web Agent on the TeamSite System on page 245 for more
information.
Integrating CA SiteMinder with TeamSite without employing the Active

Response module. This integration is recommended when it is not practical to
install an Active Response module for TeamSite in the SiteMinder Policy
Server.
Integrating an SSO product other than SiteMinder with TeamSite without

employing an active response.
The following sections describe these integrations in detail.
Integrate SiteMinder and TeamSite with an Active

Response
This section describes how to integrate CA SiteMinder and TeamSite using the
Active Response module. This configuration is the one most widely used in
existing TeamSite/SiteMinder installations. It is a good choice when maximum
security is desired and where it is possible to install an Active Response on the
Policy Server that communicates with the TeamSite authentication system.
242

Response
Prerequisites
The following conditions must already be met before you start this procedure:
TeamSite 6.7.1 or above is installed on one computer.
SiteMinder Policy Server 5.5 or 6.0 is installed on another computer.
You have an SSL certificate for the TeamSite system.
TeamSite and SiteMinder share the same user database.
Overview
With this configuration, two credential verifications are performed when a user
signs on through the SiteMinder system. First, SiteMinder authenticates the user
and sets an SMSESSION authentication cookie. Upon successful authentication by
SiteMinder, the SiteMinder Policy Server opens an encrypted channel to the
TeamSite authentication service, and the user is authenticated by TeamSite.
Following successful authentication by TeamSite, a TeamSite IWAUTH
authentication cookie is set, and the user is able to access TeamSite.
Advantages to this configuration include the following:
It makes it possible set up a system that has some users that authenticate
using the SSO system and some that use standard TeamSite authentication.
Both authentications are controlled by SiteMinder, and are done in the context
of a secure SiteMinder server.
It can be used with various older TeamSite servers, as well as with current
products.
A disadvantage of this approach is that it requires the installation of proprietary

authentication code in the SiteMinder Policy Server and requires a communication
channel between the SiteMinder Policy Server and the authentication service.
The typical sequence of data and operation flow following integration is depicted
in the following figure and described in the legend that follows.
243
Figure 21 SiteMinder integrated with TeamSite and Active Response

SiteMinder Policy Server
7
Active Response Module

5
Browser
2
3
8
9
10
iw-webd with SiteMinder web agent
6
9
TeamSite servletd
(Content Services)
10
1. A TeamSite user accesses the TeamSite server by entering hostname/

iw-cc/ in a browser.
2. The web agent intercepts the request and prompts for a user name and
password.
3. The user enters a user name and password.
4. The CA Web agent passes the login information to the SiteMinder Policy
Server, which authenticates the user. The Policy Server then calls the Active
Response function in the iwtssmar.so file.
5. The Active Response module makes an SSL connection to the TeamSite
Access Service and sends the users login credentials.
6. The TeamSite Access Service authenticates the user and returns a session
string that the Active Response module uses to create an IWAUTH cookie.
7. The Active Response module then writes the IWAUTH persistent cookie to the
web agent.
8. The web agent passes the cookie to the users browser.
9. The cookie is checked each time the user visits a page served by TeamSite.
10. Upon verification, the page is served from TeamSite and displayed in the
users browser.
244

Response
Integration Procedure
Performing this integration involves the following main steps:
Install and Configure the SiteMinder Web Agent on the TeamSite System.
Set Realms, Rules, and Responses on the SiteMinder Policy Server.
Set Environment Variables on the SiteMinder Policy Server.
Copying the Active Response Module to the SiteMinder Policy Server.
Details are in the following sections.
Install and Configure the SiteMinder Web Agent on the TeamSite

System
1. Ensure that the host and agent configuration objects that you plan to use are
created prior to running the SiteMinder Web Agent installation script. This is
necessary because the SiteMinder Web Agent installation script prompts you
for the IP address of the SiteMinder Policy Server, the name of the agent
configuration object, and the name of the host configuration object.
2. Run the SiteMinder Web Agent installation script supplied by CA. Refer to the
documentation provided with that product for more installation details. On
Windows systems, SiteMinder Web Agent V5QMR8 is supported. On UNIX
systems, SiteMinder Web Agent V5QMR7 is supported.
3. On UNIX systems, the SiteMinder Web Agent software is usually installed in a
different location from the web server it services. To find the various libraries
and executables it needs, the Web Agent uses the following environment
variables:
$LD_LIBRARY_PATH
$NETE_WA_ROOT
$NETE_WA_PATH.
SiteMinder provides a script called nete_wa_env.sh with the Web Agent

software that sets these environment variables.
In a typical TeamSite installation, TeamSite is configured to start automatically
whenever its host computer is booted. For the SiteMinder Web Agent to start,
values for $LD_LIBRARY_PATH, $NETE_WA_ROOT, and $NETE_WA_PATH
must be known to the TeamSite startup script iwuiboot at boot time. The
recommended configuration is to execute the nete_wa_env.sh script every
time iwuiboot is run. To do this, add the following line to the script
iw-home/private/bin/iwuiboot as the first executable command
following the block of comments at the top of the file:
. pathToWebAgentRoot/nete_wa_env.sh
245
The . followed by a space at the beginning of the command is required. It

tells the shell to execute the script in the current shell environment without
forking another shell.
4. On Windows systems, copy the WebAgent.conf and LocalConfig.conf
files from $NETE_WA_ROOT\BIN\IIS to $IW_HOME\iw-webd\conf. This
step is necessary because the Windows Web installation script for Web
Agents does not recognize the iwwebd Apache server. This step is not
necessary on UNIX systems.
Set Realms, Rules, and Responses on the SiteMinder Policy

Server
1. Open the SiteMinder Policy Server user interface where you will create
Realms and Rules to protect TeamSite resources.
2. Create the following SiteMinder Realms:
Table 15 Realms
Realm Name
Realm Type
Resource Filter
protected_iw
Protected
/iw
unprotected_iw
Unprotected
/iw/services/cm/2.0/
accessservice
3. Under the protected_iw Realm, create the following Rules:

Table 16 Rules
Rule Name
Description
Authenticate_iw - iw*
Configured for authenticating event actions.
Protected_iw - iw*
Configured for GET, PUT, POST actions.
The other Realm does not require any rules.

4. Create a SiteMinder Response with the name IWResponse and the following
details:
246

Response
Table 17 Response
Field
Entry
Attribute of the Response
WebAgent-OnAccept-Redirect
Attribute Kind
Active Response
Library Name
UNIX: full_path/iwtssmar.so
Windows: full_path\iwtssmar.dll
Function Name
activeResponse
NOTE Leave the Parameters field empty.
5. Create a SiteMinder Policy with the following label:

Add TeamSite users
6. In the Rules tab, add the following Rules:

Authenticate_iw
Protect_iw
For the Authenticate_iw Rule, set the Response to IWResponse.
Set Environment Variables on the SiteMinder Policy Server

The Active Response module uses two environment variables. One of these
specifies the host computer and port that is used to talk to the TeamSite Access
Service. The other specifies the location of a text file that is used to seed the
pseudo-random number generated used by the SSL encryption libraries. This
may be any file, preferably one that changes randomly.
Perform the following procedure on the system where the SiteMinder Policy
Server is running.
On a UNIX system:
1. Change to the home directory for smuser.
2. Open the .profile file in your text editor.
3. Create an environment variable called INTERWOVEN_AUTH_HOST, for
example:
export INTERWOVEN_AUTH_HOST=server.interwoven.com:443
247
This environment variable provides the name of the TeamSite server and
optional port. If no port number is specified, the default port number 443 is
used.
4. Create an environment variable called INTERWOVEN_RAND_FILE. This
variable specifies the complete path of a file containing random text. For
example:
export INTERWOVEN_RAND_FILE=/var/adm/random.txt
5. If you are using an LDAP system and the UNIX account name is not a
component of the Distinguished Name (DN) of the systems users, you must
tell the Active Response module where to find a users UNIX account name.
To do this, set an additional environment variable called
INTERWOVEN_USER_ATTR to the LDAP attribute that holds the UNIX account
names. This is typically uid. For example:
export INTERWOVEN_USER_ATTR=uid
6. Save and close the .profile file.

On a Windows system
1. Right-click on the My Computer icon on your desktop and select Properties
from the menu. The System Properties window is displayed.
2. Click the Advanced tab.
3. Click Environment Variables. The Environment Variables dialog box is
displayed.
4. In the System variables section, click New. The New System Variable dialog
box is displayed.
5. Enter INTERWOVEN_AUTH_HOST in the Variable Name field.
6. Enter the name of the server and optional port in the Variable Value field, for
example: server.interwoven.com:443.
This environment variable provides the name of the TeamSite server and
optional port. If no port number is specified, the default port number 443 is
used.
7. Click OK to close the New System Variable dialog box.
8. Again, select New from the System variables section to display the New
System Variable dialog box.
9. Enter INTERWOVEN_RAND_FILE in the Variable Name field.
10. In the Variable Value field, enter the complete path of a file containing random
text, for example: c:\iw\random.txt.
11. If you are using an LDAP system and the Windows account name is not part
of the Distinguished Name (DN) of the systems users, you must tell the Active
248
Integrate SiteMinder and TeamSite Without an Active

Response
Response module where to find a users Windows account name. To do this,

set an additional environment variable called INTERWOVEN_USER_ATTR as
follows. (The Windows account name is typically already part of the DN. If that
is the case with your system, skip to Step 12.)
a. Select New from the System variables section to display the New System
Variable dialog box.
b. Enter INTERWOVEN_USER_ATTR in the Variable Name field.
c. In the Variable Value field, enter the name of the LDAP attribute that
contains your systems users Windows account name. This name is
typically uid or SAMAccountName.
12. Click OK to close the New System Variable, Environment Variables, and
System Properties windows.
13. Reboot your system.
Copying the Active Response Module to the SiteMinder Policy

Server
The installation program automatically places the Active Response module
needed to integrate TeamSite and SiteMinder in the iw-home/lib directory on
your TeamSite server. The module is in a file is called iwtssmar.so (on UNIX
systems) or iwtssmar.dll (on Windows systems) and must be copied to your
SiteMinder Policy Server.
1. Stop all SiteMinder Policy Server daemons (UNIX) or services (Windows).
Refer to the SiteMinder Operations Guide for detailed instructions.
2. Copy the iwtssmar.so (UNIX) or iwtssmar.dll (Windows) file from
iw-home/lib to where the policyserver_home/bin/smservauth
executable can find it.
For example (UNIX):
%cp iw-home/lib/iwtssmar.so /var/siteminder/bin/

Response
This section describes how to integrate CA SiteMinder and TeamSite without
using the Active Response module.
249
Prerequisites
TeamSite release 6.7.1 or above is installed on one computer.
SiteMinder Policy Server 5.5 or 6.0 is installed on another computer.
TeamSite and SiteMinder share the same user database.
Overview
This configuration does not require the installation of any proprietary software on
the SiteMinder Policy Server, and requires no connection between the Policy
Server and the TeamSite authentication service. With this approach, users are
authenticated solely by SiteMinder, and there is no additional TeamSite
authentication step. SiteMinder verifies the users password, sets an SMSESSION
authentication cookie, and passes the users identity to TeamSite through a
session cookie or HTML header parameter. TeamSite prepares an IWAUTH
access cookie based on the users identity, and does not perform any further
credential check.
The advantages of this approach are that there is no requirement to install an
authentication plug-in in the SiteMinder Policy Server, and there is no need to
open a communication channel between the Policy Server and the TeamSite
authentication service.
250

Response
Figure 22 SiteMinder integrated with TeamSite without Active Response

SiteMinder Policy Server
5
Browser
2
3
6
7
8
iw-webd with SiteMinder web agent
TeamSite servletd
(Content Services)
8

password.
3. A user enters a user name and password.
4. The SiteMinder web agent passes the login information to the SiteMinder
Policy Server, which authenticates the user.
5. TeamSite sees the SMSESSION cookie that SiteMinder has set, looks up the
user name, and sets an IWAUTH cookie that TeamSite will use for access
control.
users browser.
251
Performing this integration involves the following main steps:
Install and Configure the SiteMinder Web Agent.
Configure the SiteMinder Policy Server.
Configure TeamSite.
Install and Configure the SiteMinder Web Agent

1. Ensure that the host and agent configuration objects that you plan to use are
created prior to running the SiteMinder Web Agent installation script. This is
necessary because the SiteMinder Web Agent installation script prompts you
for the IP address of the SiteMinder Policy Server, the name of the agent
configuration object, and the name of the host configuration object.
2. Run the SiteMinder Web Agent installation script supplied by CA. Refer to the
documentation provided with that product for more installation details. On
Windows systems, SiteMinder Web Agent V5QMR8 is supported. On UNIX
systems, SiteMinder Web Agent V5QMR7 is supported.
3. On UNIX systems, the SiteMinder Web Agent software is usually installed in a
different location from the web server it services. To find the various libraries
and executables it needs, the Web Agent uses the following environment
variables:
$LD_LIBRARY_PATH
$NETE_WA_ROOT
$NETE_WA_PATH.
SiteMinder provides a script called nete_wa_env.sh with the Web Agent

software that sets these environment variables.
In a typical TeamSite installation, TeamSite is configured to start automatically
whenever its host computer is booted. For the SiteMinder Web Agent to start,
values for $LD_LIBRARY_PATH, $NETE_WA_ROOT, and $NETE_WA_PATH
must be known to the TeamSite startup script iwuiboot at boot time. The
recommended configuration is to execute the nete_wa_env.sh script every
time iwuiboot is run. To do this, add the following line to the script
iw-home/private/bin/iwuiboot as the first executable command
following the block of comments at the top of the file:
. pathToWebAgentRoot/nete_wa_env.sh
The . followed by a space at the beginning of the command is required. It

tells the shell to execute the script in the current shell environment without
forking another shell.
252

Response
4. On Windows systems, copy the WebAgent.conf and LocalConfig.conf

files from $NETE_WA_ROOT\BIN\IIS to $IW_HOME\iw-webd\conf. This
step is necessary because the Windows Web installation script for Web
Agents does not recognize the iwwebd Apache server. This step is not
necessary on UNIX systems.
Configure the SiteMinder Policy Server

1. Open the SiteMinder Policy Server user interface where you will create
Realms and Rules to protect TeamSite resources.
2. Create the following SiteMinder realm:
Table 18 Realm
Realm Name
Realm Type
Resource Filter
protected_iw
Protected
/iw
3. Create a rule under the protected_iw Realm.

If you are using a session cookie, use the following rule:
Table 19 Rules
Rule Name
Description
Action
iwCookieRule
Sets a session cookie

upon successful
authentication.
Authentication event
onAuthAccept.
If you are using an HTTP header parameter instead of a session cookie, use
the following rule:
Table 20 Rules
Rule Name
Description
Action
iwHeaderVarRule
Sets a header
parameter upon
successful
authentication.
Authentication event
onAuthAccept.
4. Create a SiteMinder Response.

If you are using a session cookie:
253
Use the name iwCookieResponse and set the attributes as shown in

following table. The purpose of this response is to set a session cookie to the
users TeamSite account name after the user is successfully authenticated by
SiteMinder. The implementation shown here assumes that the SiteMinder
user database is in an LDAP directory and that the uid attribute in the
directory contains the users TeamSite account name. The variable name you
choose can be any name, but it must match what is specified in the TeamSite
configuration file for iw.common.authentication.ssoUserCookie. For
UNIX account names, the values are case sensitive, and must match the user
names in the tsusers.xml file.
Table 21 Response
Field
Entry
Name
iwCookieResponse
Description
Set user name in session cookie
Agent Type
SiteMinder Web Agent
WebAgent-HTTP-Cookie-Variable
Attribute Kind
User Attribute
Attribute Name
uid
Variable Name
IW_UNAME
If the SiteMinder Policy Server is on a UNIX system, go to Step 6.

If you are using an HTML header parameter (rather than a session cookie):
Use the name iwHeaderVarResponse and set the attributes as shown in
following table. The purpose of this response is to set a session cookie to the
users TeamSite account name after the user is successfully authenticated by
SiteMinder. The implementation shown here assumes that the SiteMinder
user database is in an LDAP directory and that the uid attribute in the
directory contains the users TeamSite account name. The variable name you
choose can be any name, but it must match what is specified in the TeamSite
configuration file for iw.common.authentication.ssoUserParam. For
UNIX account names, the values are case sensitive, and must match the user
names in the tsusers.xml file.
254

Response
Table 22 Response
Field
Entry
Name
iwHeaderVarResponse
Description
Set user name in header parameter
Agent Type
WebAgent-HTTP-Header-Variable
Attribute Kind
User Attribute
Attribute Name
uid
Variable Name
IW_UNAME
If the SiteMinder Policy Server is on a UNIX system, go to Step 6.

5. If the SiteMinder Policy Server is on a Windows system, TeamSite requires
both a user name and a domain name for authentication. You can choose
whether the user account name and the domain name are passed to TeamSite
together or separately. If your user directory contains an attribute for each
TeamSite user in the form domain\user, domain/user, or
user@domain.com, you may pass this value to TeamSite in the session
cookie or parameter you specified for ssoUserCookie or
ssoUserParameter. Otherwise, if you store domain information separately
in a different attribute in your user database, you may send the user name in
ssoUserCookie or ssoUserParameter, and send the domain name in a
different cookie or parameter.
If the ssoUserCookie or ssoUserParameter does not contain a domain
name, create an additional SiteMinder cookie response or header response as
shown in the following tables to set the domain name.
If you are using a session cookie for the domain name:
.
Table 23 Response
Field
Entry
Name
iwDomainResponse
Description
Set user domain in session cookie
Agent Type
WebAgent-HTTP-Cookie-Variable
255
Table 23 Response
Field
Entry
Attribute Kind
User Attribute
Attribute Name
domain
Variable Name
IW_UDOMAIN
If you are using an HTML header parameter for the domain name:
Table 24 Response
Field
Entry
Name
iwDomainResponse
Description
Set user domain in header

parameter
Agent Type
WebAgent-HTTP-Header-Variable
Attribute Kind
User Attribute
Attribute Name
domain
Variable Name
HTTP_IW_UDOMAIN
6. If the protected_iw realm does not already have a policy, create one with
the following settings:
.
Table 25 Policy
Policy Name
Enabled
iw-policy
Yes
If you configured the system to pass user information in the session cookie, in
the Rules tab select Add/Remove Rules. Select iwCookieVarRule that
you created earlier and add it to the policy. After you add the rule, select
Select Response to tie iwCookieVarResponse to the rule.
If you configured the system to pass user information in an HTML header
parameter (rather than in the session cookie), in the Rules tab select Add/
Remove Rules. Select iwHeaderVarRule that you created earlier and add
it to the policy. After you add the rule, select Select Response to tie
iwHeaderVarResponse to the rule.
256

Response
If TeamSite is running on a Windows computer, and you have chosen to pass

the users domain name separately from his account name, create another
rule under the protected_iw domain called iwDomainRule, and add it to
iw-policy. After you add the rule, select select Response to tie
iwDomainResponse to the rule.
Configure TeamSite
The TeamSite configuration described here is performed through the UI toolkit. All
of these Java parameters are customized by entering their values as
default-param subelements in the applications element of the
application_custom.xml file. See the TeamSite User Interface
Customization Guide for details about setting parameters in
application_custom.xml.
NOTE You can perform this configuration before or after

you install and configure the SiteMinder Policy Server.
Set Java parameters as follows:

1. To enable SSO authentication in TeamSite, set:
iw.common.authentication.ssoEnabled=true
The default value for this parameter is false; to enable SSO, it must be set to
true.
2. Verify that the name of the SSO cookie set by the SSO package is already set
to SiteMinders default of SMSESSION. The setting should appear as shown
here. If it does not, reset it accordingly:
iw.common.authentication.ssoCookieName=SMSESSION
3. TeamSite requires either an HTTP header parameter or a session cookie that

contains the TeamSite users account name. You can choose to use either
alternative.
If you choose to set a header parameter, set ssoUserParam to the following:
iw.common.authentication.ssoUserParam=header_parameter_name
If you choose to set a cookie, set ssoUserCookie to the variable name that
you specified in Step 5 in the preceding section:
iw.common.authentication.ssoUserCookie=session_cookie_name
4. On Windows systems, if your user directory does not contain an attribute for
each TeamSite user in the form domain\user, domain/user, or
257
user@domain.com, you may need to send the domain information

separately in a different session cookie or HTTP header parameter.
If you choose to set a header parameter, set it as follows:
iw_common.authentication.ssoDomainParam=header_parameter_name
The default value is HTTP_IW_DOMAIN.

If you choose to set a session cookie, set it as follows:
iw.common.authentication.ssoDomainCookie=session_cookie_name
The default value is IW_DOMAIN.
Integrate an SSO Product Other than SiteMinder

with TeamSite
This section describes how to integrate TeamSite with an SSO product from any
vendor. This integration does not use the Active Response module.
Prerequisites
TeamSite release 6.7.1 or above is installed on one computer.
An SSO product is installed on another computer.
You have an SSL certificate for the TeamSite system.
TeamSite and the SSO product share the same user database.
Overview
This configuration does not require the installation of any proprietary software in
the SSO system. Authentication is delegated completely to the SSO system,
without TeamSite playing a role. This approach accommodates a variety of
different SSO products from different vendors. To use an SSO system with
TeamSite, it must be able to pass the authenticated users account name to
TeamSite upon completion of authentication. This may be done using an HTTL
header parameter or a browser session cookie.
258
Integrate an SSO Product Other than SiteMinder with

TeamSite
Figure 23 SSO product integrated with TeamSite without Active Response

SSO Server
5
Browser
2
3
6
7
8
iw-webd with SSO web agent
TeamSite servletd
(Content Services)
8

password.
3. A user enters a user name and password.
4. The Web agent for the SSO product passes the login information to the SSO
Policy Server, which authenticates the user.
5. TeamSite sees the authentication cookie that the SSO system has set, looks
up the user name, and sets an IWAUTH cookie that TeamSite will use for
access control.
users browser.
259
Performing this integration involves three main steps:
Install and Configuring the SSO Web Agent
Configure the SSO Server
Configure TeamSite
Install and Configuring the SSO Web Agent

The web agent must be compatible with Apache 2 web servers. See the SSO
vendors documentation for the recommended version and installation
instructions.
Configure the SSO Server

The SSO server needs to generate either a session cookie or an HTML header
parameter that contains a TeamSite user account name. For Windows account
names, the domain may be sent in the same cookie or parameter, or it may be
sent in a different cookie or parameter. When the domain and user name are sent
together, any of the following forms is acceptable:
domain\user
domain/user
user@domain.com
Configure TeamSite
TeamSite configuration is performed through the UI toolkit. All of the parameters
are located in the application_custom.xml file. See the TeamSite User
Interface Customization Guide for details about setting parameters in
application_custom.xml.
NOTE You can perform this configuration before or after

you install and configure the SSO Server.
Set Java parameters as follows:

1. To enable SSO authentication in TeamSite, set:
iw.common.authentication.ssoEnabled=true
The default value for this parameter is false; to enable SSO, it must be set to
true.
260
Troubleshooting
2. Verify that the name of the SSO cookie set by the SSO package is already set
to SiteMinders default of SMSESSION. The setting should appear as shown
here. If it does not, reset it accordingly:
iw.common.authentication.ssoCookieName=SMSESSION
3. TeamSite requires either an HTTP header parameter or a session cookie that

contains the TeamSite users account name. You can choose to use either
alternative.
If you choose to set a header parameter, set ssoUserParam to the following:
iw.common.authentication.ssoUserParam=header_parameter_name
If you choose to set a cookie, set ssoUserCookie to the following:

iw.common.authentication.ssoUserCookie=session_cookie_name
4. On Windows systems, if your user directory does not contain an attribute for
each TeamSite user in the form domain\user, domain/user, or
user@domain.com, you may need to send the domain information
separately in a different session cookie or HTTP header parameter.
If you choose to set a header parameter, set it as follows:
iw_common.authentication.ssoDomainParam=header_parameter_name
The default value is HTTP_IW_DOMAIN.

If you choose to set a session cookie, set it as follows:
iw.common.authentication.ssoDomainCookie=session_cookie_name
The default value is IW_DOMAIN.
Troubleshooting
Troubleshooting the SiteMinder Web Agent
If the Web Agent is configured correctly, you should see the SiteMinder login
dialog when you attempt to visit a TeamSite web page. If the SiteMinder dialog
does not appear, it may be due to one of the following errors:
Failed to start the LLAWP process. Execlp failed: No such file

or directory.
These and similar messages may result if the NETE_WA_* environment variables
are not correctly set. See SiteMinder Knowledge Base article 222207 for
additional details.
261
child pid 1234 exit signal Abort (6)

If the ServerPath parameter is missing from the Web Agent configuration, you
may get messages of the form child pid 1234 exit signal Abort (6).
The solution is to add a value for ServerPath to the WebAgent.conf
configuration file.
Server already running. Duplicate LLAWP processes not

allowed, exiting.
If the SiteMinder LLAWP process does not shut down correctly when iwweb is
stopped, it may be because the SiteMinder ServerPath parameter was
specified in the Agent Configuration Object instead of in WebAgent.conf. The
solution is to move ServerPath to the WebAgent.conf file, and to remove any
associated semaphores. You can do this using the OS commands ipcs and
ipcrm, or by rebooting the system. See SiteMinder Knowledge Base article
222318 and Tech Note 1027 for additional details.
If the problem persists after applying the ServerPath resolution, a workaround is
to issue the following command before running any script or command that stops
and restarts the TeamSite iwweb web server:
LLAPW /pathToConfigDirectory/webagent.conf -APACHE20 -shutdown
If the SiteMinder dialog appears correctly, then after entering the user name and
password for a valid TeamSite user, you should see the TeamSite page you
requested. If, instead, you see a TeamSite login page, then TeamSite did not
detect an IWAUTH session cookie, either because one was not created, or
because it was created in the wrong domain.
If the IWAUTH cookie is not present, it may be because the user is present in the
SiteMinder user database, but he is not a valid TeamSite user. Make sure that the
user is present in the tsusers.xml file.
Netscape and Mozilla Firefox web browsers provide a cookie manager option
that displays the value of all cookies, including session cookies. If an IWAUTH
cookie is present, but its domain does not match the path you typed for the
TeamSite web page, you may need to make changes to your Web Agent
configuration file, or to your systems DNS settings to correct this. If the IWAUTH
cookie is absent completely, and the user is a valid TeamSite user, then the
problem is probably due to a SiteMinder Policy Server configuration error. If you
are using a session cookie to pass the user name to TeamSite, make sure that the
cookie is set as expected, and that its name matches the name you have selected
in the TeamSite application.xml configuration file.
262
Troubleshooting
Troubleshooting the Active Response

Normally, if SiteMinder successfully authenticates a user, the Active Response
module also authenticates the user successfully. If SiteMinder successfully
authenticates a user and the authentication fails, one of the following messages is
logged to the SiteMinder access log file:
Failed to read INTERWOVEN_AUTH_HOST value.
This message is logged if the INTERWOVEN_AUTH_HOST environment variable

has not been set.
Failed to read random seed data.
This message is logged if the INTERWOVEN_RAND_FILE environment variable is

missing or does not point to a file that can be read by SiteMinder.
TCP socket connection error.
This message is written to the log file if the SiteMinder computer is unable to open
a TCP/IP socket connection to the TeamSite server. A possible reason for this
might be that the TeamSite server is unreachable or that the
INTERWOVEN_AUTH_HOST environment variable contains an incorrect host name
or port number.
SSL Connection error.
This message is written to the log file if SiteMinder is able to open a socket
connection to the TeamSite server but is unable to establish an SSL session over
the channel. Possible reasons include a misconfigured TeamSite server whose
X.509 certificate is missing or corrupt.
Failed to send query to server.
This message is written to the log file if the SSL channel to the TeamSite server
fails.
Failed to get session string from server.
This message appears if the supplied user name and password are valid, but no
TeamSite role is associated with the user. This message does not necessarily
denote an error if there are some SiteMinder users that are intentionally not given
access to TeamSite.
263
264
APPENDIX D
Troubleshooting
This appendix contains miscellaneous information regarding a variety of
troubleshooting issues. In addition to the suggestions that follow, Consulting
Services and Technical Support can assist you with any configuration issues you
might encounter.
NOTE Several features have troubleshooting sections in

the chapters describing those features.
Table 26 Troubleshooting options

Unexpected Server Shutdown
After an unexpected server shutdown (such as a power outage or system failure), if the server does
not start properly when the system is brought back up, immediately contact Technical Support.
Do not attempt to restart the server by manually modifying or deleting system files. Doing so may
cause irreparable damage to the Content Store.
Only run the iwfsfix CLT under the supervision of Technical Support. Conducting any of the
suggested repairs without first confirming the action with Technical Support is not recommended
because it could result in inadvertent damage to the Content Store.
265
Appendix D Troubleshooting
Table 26 Troubleshooting options (continued)

Other Server Issues
On
Unix:
NTCSFsdClaimASharedMemoryChannel: No shared memory communication channel

available message appears in Windows System Log.
The code is trying to get a buffer and is not successful. However, it retries and succeeds. The
workaround is to add the following registry setting HKLM \SYSTEM \CurrentControlSet \
Services \iwfsd \Parameters Value:
CoreCommRetryCount REG_DWORD 0x100
File operations on task files may not return clear warnings if the store in which the task files reside
is deactivated. If you attempt to perform an operation on a file whose store is deactivated, one of
the following messages may appear:
Internal Server Error
TeamSite FileEdit
Error:Call to sciLocateObjectWithVersionPath()returned an error
SCI Error
No archive found
TeamSite iwdirnav.cgi
Error:iwdirnav.cgi could not open path "/s1/main/WORKAREA/w1"
You should not disable stores if users are actively working on those stores.
Install/Remove Programs
On
Unix:
When the TeamSite installation is started, the following warning is displayed: Cannot convert
string monotype-arial-regular-normal--*-140-*-*-p-*-iso8859-1 to type
FontStruct. The installation program substitutes a font; therefore, this warning can be ignored.
Email
HTML format email notifications do not display correctly with Eudora 6.01 on a Macintosh client;
however, the email is still usable. The user can choose Open in browser to see the email properly.
The Exchange 2000 server may corrupt the workflow emails. Use Exchange 2003.
Windows XP
The VisualAnnotate toolbar does not automatically display on Windows XP. Select View >
Toolbars> Visual Annotate to turn on the toolbar.
JVM
When editing a file in ContentCenter Professional, the editor goes to the background and the Local
File Manager is displayed. This applies when using a Sun JVM plug-in instead of the browsers
built-in JVM in Windows.
IIS (Windows)
266

Content may not refresh after an edit. The solution is to turn off caching in IIS, as follows:
1. Run the Internet Services Manager (Start > Programs > Administrative Tools > Internet
Services Manager) and expand the icon for my computer.
2. Click Default Web Site.
3. Right-click on the iw-mount icon and select Properties.
4. In the properties dialog, select the HTTP Header tab.
5. Turn on the Enable Content Expiration check box and made sure that the expiration setting is
Expire Immediately.
VisualPreview/Local File Manager: When used with some editors, you may see the accessed by
another process message (does allow save). When you edit a file using these editors through the
VisualPreview tab, you may get the message The document name is in use by another application
and cannot be accessed. This does not happen with NotePad. This a known IIS problem, which
occurs because IIS keeps a file open for a while after it is requested in an http transaction.
Workarounds are waiting for a while (20-30 seconds), not using IIS in combination with
VisualPreview (since normally VisualPreview accesses the file just before it is being edited), or
using a different Web server.
If a branch, directory, or filename contains .com or .exe, navigating to that location results in 404
page not found error. This applies when using IIS on Windows and is an IIS mechanism to
prevent worms and viruses.
IIS caching can cause cached versions of files to be displayed during a preview operation. If users
do not see recent modifications when previewing documents from My Local Files, turn off global
caching from the IIS control panel. Select the machine name, then select Action > Properties. In
the Server Extensions tab of the Properties dialog box, select Use Custom Settings from the
Performance drop-down menu. Then, click the corresponding Settings button. Set In-memory
document cache, Include file cache and Image file cache each to 0.
Virus Scanning and TeamSite (Windows)

Virus scanning software can be used on both the TeamSite server and TeamSite clients, but it
should not scan the files on the TeamSite servers IFS drive (Y:\) or any TeamSite share to which
a client is connected
(\\ServerName\iwserver\path_to_workarea).
If you scan these areas, you may see file properties changed or General Protection Fault errors
(GPFs). You can scan the iw-store directory.
Refer to Knowledge Base articles 51697 and 52911.
Flexible Roles
If a logged-in user is assigned a new role in a branch, the user should refresh the ContentCenter
screen before attempting to open a workarea in the branch.
267
Appendix D Troubleshooting

Permissions
In a situation where an administrator has override privileges on a workarea where he is not part of
the group for sharing, attempting to generate a form causes an error. The iwpt_compile CLT
does not have permission to access the workarea from ContentCenter or from the file system. Other
commands may have similar results. The purpose of the override feature is to allow a user to do
certain work in the workarea without being in a workarea group, but it does not change file
permissions.
The number of permission entries on any given node (server/store/branch) is restricted to 4000.
268
Glossary
A
Administrator
An out-of-the box role configured for the owner of a branch, responsible for
the project being developed on it. An Administrator can perform all the
functions that an Author or an Editor can, and can also create and delete new
subbranches and workareas on his branch. Administrators exercise control
over workflow by giving workareas to editors and subbranches to other
administrators.
Advanced File Merging
TeamSite can automatically merge two separately modified versions of a file,

producing a new file containing the changes made by both users. Advanced
File Merging is completely automatic if the edits were made to different parts
of the file (non-conflicting edits).
approve
When an Editor approves a file returned by an Author, the file is submitted to

the staging area. Approving a file automatically unlocks it and removes it
from the Authors Task list.
assign
To lock a file for the use of a specific Author and attach comments. A list of
assigned files is displayed in the Authors Task list. Editors can also view a
list of files that they have assigned.
attribute search
A basic parametric search that involves single-level value-pairs AND/OR

search criteria. The supported operators for parametric search are: equal (=),
less than (<), less than or equal (<=), greater than (>), greater than or equal
(>=), not equal (<>).
Author
An out-of-the box role configured for a primary web content contributor with
limited access to the TeamSite system, usually using ContentCenter
Standard. Authors can access, create, and modify web content through their
Editors workareas. An Editor can assign specific files to an Author, which will
appear in the Authors Task list.
269
Autoprivate
The Autoprivate feature helps minimize clutter on the development server.

Autoprivate automatically identifies file types that should not be submitted to
the staging area and marks them as Private. These files typically include
Microsoft temporary files (.TMP), various backup files (.BAK), and Macintosh
resource forks (.FRK).
branch
A path of development for a body of content developed and maintained by a

team. Each branch contains one or more workareas, a staging area, and a
published edition and may contain subbranches and previous editions.
casual contributor
A person who modifies or creates content using TeamSite, usually on an

infrequent or sporadic basis. Contributor is a generic term that does not
designate a specific TeamSite role.
category
In FormsPublisher, a category is a grouping of types of templates. Category

directories are the first division of the templatedata directory. Each category
has its own directory, which contains subdirectories for each type within it. An
example of a category would be beverages, which may contain tea, coffee,
milk, and soda types.
When editing roles, categories are groupings of operations that users can
perform within a role.
270
collection
The metadata for a set of documents with optimized architecture for

searching.
command-line tool (CLT)
TeamSite has many command-line tools that make TeamSite functionality

available from the command line. Consult the TeamSite Command-Line
Tools.
command trigger
A type of command-line tool that can trigger scripts when specific TeamSite
events occur. An example is the use the iwatsub command trigger to trigger
an event when files are submitted.
comment
A note attached to a file, directory, workarea, branch, edition, job, or task.

Comments can be attached to workareas, branches and editions when they
are created. Comments can be attached to files and directories when they
are assigned, returned, rejected, locked or submitted. Global comments can
be set when these functions involve multiple files.
Compare
A function that displays a list of the differences between any two TeamSite
objects. Objects that can be compared include workareas, staging areas, or
editions.
Composite search
An advanced search feature that allows multiple search criteria to be

specified. These criteria can be a mixture of full text, form entry, and
metadata parameters.
conflict
Occurs when multiple users make changes to the same file in multiple
locations, for example, when a file has been changed in two different
workareas.
conflicting edits
Occur when multiple users make changes to the same parts of the same file,
producing two versions of the file that cannot be automatically merged.
Conflicting edits require users to specify which individual changes will go into
the merged version.
content
A set of information contained within a text document, vocabulary, file, or

database record. See also data record.
ContentCenter
Professional
A user interface for experienced TeamSite users, technical users, or users

who have some familiarity with content management systems. It is intended
for power users, and users who must administer content development
projects. It includes integrated administrative functions for easy, contextual
TeamSite administration and fully customizable menus, tabs, and more.
ContentCenter Standard
A user interface for business usersthat is, non-technical subject matter

experts and infrequent users of a content management system. It includes
an initial customizable home page containing module UI components
displaying areas for a user's tasks, favorites, work in progress, and forms,
wizards for common functions, and out-of-box email messages for workflow
task notification.
contributor
A person who modifies or creates content using TeamSite. Contributor is a

generic term that does not designate a specific TeamSite role.
convert
The process of changing a Microsoft Word file to PDF or HTML format.
data capture template
An XML file, datacapture.cfg, that defines the form used to capture data
from content contributors. A data capture template is associated with a
category and type. The category and type define the type of data required by
the data capture template. The data that a content contributor enters in a data
capture template is saved on the TeamSite file system as an XML file in the
form of a data record.
271
data record
An XML file containing formatting information interspersed with data

captured from a contributor or through other means. A data record is named
when a content contributor saves the record. Content contributors can edit a
data record by reopening it in the form that created it. Several different data
records can also be matched to a single presentation template to create one
or many output files. Data records can also be deployed to a database by
DataDeploy.
delegated administration
Users in specific roles may be allowed to delegate administrative activities to

users in other roles. This is set up in the Edit Roles screen. This allows
administrative activities to be performed by users who are most involved with
that content.
edition
A frozen, read-only snapshot of a branch of development. An edition contains

a copy of all the files in the staging area at the time it was published. New
editions can be released to production servers as complete, functional Web
sites. Editions also serve as rollback points for projects in development, and
they provide permanent archives of the Web site for Site Rollback.
Editor
An out-of-the box role configured for the owner of a workarea or workareas.

Editors assign files to Authors, manage files, and edit and create files, submit
content to the staging area, and may create editions. Editors may have
access to workareas that they do not own, but they cannot assign files in
these workareas.
form
The form generated by a data capture template. A contributor fills out a form
to create a data record. A form is displayed in the FormsPublisher window so
that a user can enter and format data, select options, and access menu
items.
form entry
The information a user enters in a blank form. Form entry files are stored in
locations selected within the templatedata/form_category/form_type/
data folder in the users workarea, and are available to recall and use as
necessary.
Form Entry Search
Ability to search on specified fields within a form entry.
form item
An element in a data capture template that defines a form field, such as a text
field, text area, check box, combo box, or option button.
272
FormsPublisher
A TeamSite module that allows you to configure the look and feel of your web
pages. Use it to generate forms used within ContentCenter for capturing
data. For more information, consult TeamSite FormsPublisher Developers
Guide.
Full-text search
Ability to search by entering one or more keywords from any document and
applying AND/OR operators on the keywords.
Get Latest
A command that brings staging area content that is different from the
workarea content into the workarea.
groups
TeamSite groups are a collection of users who can access branches and
share workareas. TeamSite groups complement the operating system
groups that may exist.
history
A complete record of all changes that have been made to a file through time.
A user can see the complete history of a file by selecting it and selecting
History from the View menu.
initial edition
The first edition on a newly created branch. The initial edition serves as the
original source of content for all workareas on a new branch. This edition may
be empty, or it may be a copy of an edition from another branch.
job
A set of interdependent tasks assigned to one or more people. All jobs are
based on predefined workflows, and each job is a specific instance of a
workflow model. When a user starts a job based on a workflow, the user
specifies who should perform each task, and then initiates the job. The
person who is to perform each task is notified through the Tasks section of
the ContentCenter interface (and optionally through email) that there is a task
to perform. After a task is completed, the job proceeds to the next task in its
sequence that was defined by the workflow. When all of the tasks in a job are
done, the job is complete.
273
L
locking
Restricting file access within a branch. Locking a file reduces the possibility
of conflicting edits but also reduces the teams ability to work on files
simultaneously. Every time a file is locked, the version in the workarea is
compared with the version in the staging area and the latest is taken
(although this behavior can be overridden). TeamSite supports three types of
locking, or locking models: Submit Locking, Optional Write Locking, and
Mandatory Write locking. The locking model is defined at the branch level by
the Administrator or for a specific role when the role is created.
main branch
The first branch created when TeamSite is installed. The Main Branch is
owned by the Master user. All branches in the TeamSite system are
subordinate to the main branch.
Mandatory Write locking
A type of locking where users are required to lock a file in order to edit it. Until
a user locks a file, all files in his workarea are read-only. Taking the write lock
allows only a single person to modify the file at a given time, ensuring serial
development and eliminating conflicting edits.
Master
An out-of-the box role configured for the owner of the main branch. The
Master user is responsible for the entire Web site. The Master organizes the
structure of the TeamSite system and coordinates the activities of all users,
creates roles, assigns operating system users, and can also perform all
functions on all branches. Master users have access to the ContentCenter
Professional Administration Console.
merge
The process of reconciling conflicts between versions of a file that have been
edited by two people. The two versions can be merged in the staging area to
produce a new version of the file, incorporating changes made by both users.
Merging can be automated with TeamSites Advanced File Merging.
metadata
There are four types of metadata: file properties, user-specified metadata,

system-provided metadata (such as FormsPublisher extended attributes),
and derived metadata from Metatagger operations.
Navigation Window
The left-hand side of the TeamSite window, which allows you to navigate
through TeamSite by clicking on the underlined names of branches,
workareas, staging areas, editions, or directories.
274
O
Optional Write Locking
A type of locking in which users can choose to lock a file to ensure no other
users edit the file, even within their own workareas. When a user locks a file,
it becomes read-only to all other users. Under the Optional Write Lock model,
locking files ensures serial development of those files and reduces the risk of
conflicting edits.
output file
A file that a user generates by combining form entries with a presentation

template. The output file is typically in HTML format for use as a Web page,
although it can be other file types. The user can generate output pages using
any combination of form entries and presentation templates that the
ContentCenter developer has made available. Multiple output files can
optionally be generated using different presentation templates.
presentation template
A template that defines how form entries will appear when displayed. For
example, a presentation template could specify the size, color, and layout of
a Web page.
A presentation template is populated with data from one or more of the

following sources:
Data record
Queries to databases
FormsPublisher can be configured to populate any presentation template
with any data record plus additional information as required from a relational
database.
A contributor can match a single data record with several presentation
templates to create multiple output files containing the same or similar
information, each suitable for a different Web site, each with a different look
and feel.
Presentation templates can be used with component templates. A
component template is a presentation template nested within another
presentation template. Multiple data records of the same type can use a
single presentation template to create multiple output files in the same
format.
275
preview
Viewing content prior to submitting, deploying, or generating an output file

from it. Previewing typically pertains to Web sites that being working on. For
example, before beginning work on a Web site, a user may preview it to
assess its current look and feel. Previewing is also useful after you have
finished working on a Web site to ensure that your changes appear as you
intended prior to making the Web site publicly available. Previewing within
FormsPublisher is limited to displaying the output of the form being worked
on using a specific presentation template.
private
Within a workarea, a user can mark a file as Private, which prevents the file
from being submitted to the staging area if the file is a part of a workarea or
directory that is submitted. It also prevents the file from being copied to
another workarea during a Copy To operation.
public
The opposite of Private, the Public function removes the private marking on
a file. All files are public by default.
publish
The publishing of finished content to environments beyond the one where it

was created. For example, a user could create a press release from within
ContentCenter, submit the final version for approval and inclusion in the
staging area, and then publish the finished version to a production system
that lets the general population access it. Not all ContentCenter users have
the ability to deploy content; permission to do so is controlled by the
ContentCenter administrator.
publisher
An application that sends events to the Event subsystem.
Reviewer
An out-of-the box role configured for users who are responsible for reviewing
content prepared by other users.
role
A collection of operations that are assigned to users. These are stored in the
roles.xml file. Master users configure roles to meet the needs of their
installation.
search field type
Available, indexed fields within the search project dictate the possible values
for the user to search. For example, a date field would provide a calendar for
the use to select a date to be searched.
Search index
Search is enabled by building an index of searchable content and metadata.
Search results
The returned set of assets that adhere to the specified criteria.
276
Site Rollback
The process of deploying a previous edition in place of the current Web site.
Because TeamSite editions are complete copies of the entire Web site at the
time of publication, they can be referenced to revert to prior versions of files,
directories, or the entire Web site.
staging area
The area where users integrate the contents of their workareas. Users
submit read-only copies of files from their workareas to the staging area to
integrate with other contributions, and test the integrity of the resulting Web
site.
subbranch
A branch subordinate to a major branch. To separate development efforts

among teams or team members, an Administrator can create subbranches.
The subbranch receives its own unique staging area and workareas and
generates its own editions. Editions published on a subbranch can be
integrated back into work on the higher branch, or released as stand-alone
Web sites.
submit
The act of transferring Web site content from a workarea to the staging area.
After a user performs an action on a file, the user must submit the file so that
it can be approved and integrated into the staging area. For example, if a
user edits a file in a workarea, the file must be submitted so that the changes
can be reviewed and promoted to the staging area when approved. When a
users work reaches the staging area it is integrated with the work of other
contributors into publishable, deployable content.
Submit Locking
A type of locking in which users can choose to lock a file to insure that their
changes are submitted to the staging area. While a file is locked, other users
can edit their own version of the locked file within their workarea, but they
cannot submit to the staging area. Once the lock holder has released the file
lock, other users can merge their modifications with the new file version.
subscriber
An application that registers with the Event Subsystem to receive events.
tag
When users tag a file, they specify additional descriptive information that
remains with the file indefinitely (this information is also called metadata). For
example, a user could tag a press release file by adding a title such as Press
Release, key words such as July and Acquisition, a region such as
California, and so on. These tags do not appear in the text of the file, so they
are not displayed when the file is viewed through a browser or editing
application. Instead, they appear when you view the files tags, use search
functionality, or use a product such as MetaTagger.
277
task
A unit of work performed by a single user or process that is part of a job. Each
task in a job is associated with a particular TeamSite workarea and carries a
set of files with it. There are two types of tasks: individual and group.
Individual tasks are assigned to a specific person. When an individual
task is assigned to a user, it appears under Tasks > My Tasks view in the
Workflow tab. From there the user can take whatever action is necessary
to complete the task.
Group tasks are assigned to a group of people, any one of whom can
perform the task. (Groups are defined and maintained by ContentCenter
administrators and other maintainers of your ContentCenter system.) If a
group task is assigned to your group, it appears under the Workflow tab
> Tasks > Unassigned Group Tasks view. From there a user can take
ownership of the task and complete it.
After you perform a task, the job proceeds to the next task in its predefined
sequence. When all of the tasks in a job are done, the job is complete.
task list
The Task list shows the user which tasks and jobs he is responsible for and
allows the user to do the necessary work to complete the tasks.
task transition
Selecting a task transition moves the job along the workflow process by
activating successor task(s).
template
A file that specifies attributes of another file, such as look and feel. When you
create a file, you can choose to base that file on a template.
templating.cfg
A configuration file that controls what presentation templates are available to

TeamSite users, and in what category they appear. It is located in the
iw-home/local/config/ directory.
type
A division within a category in FormsPublisher. Each type has a

corresponding data capture template so that users can enter information for
that type. Examples of types could be tea, coffee, milk, and soda, which are
part of the beverages category.
unlock
To remove a lock from a file. If an Editor has locked a file, the branch
Administrator or Master user can also remove the lock. The Master user can
remove any lock from any file.
user
A person who has been set up to be a TeamSite user and is assigned specific
roles in various TeamSite branches. A Master user has additional
responsibilities for maintaining TeamSite and adding users, creating roles,
and so forth.
278
V
version
A numbered iteration of a content file. Whenever users submit a file and it is

approved, ContentCenter saves the new version of the file containing the
changes and retains the original, pre-edited version. Because previous
versions are not deleted, users can view all previous versions of the file, see
when and by whom each version was modified, and if necessary revert the
current file back to an earlier version. Note that versioning only occurs when
a file is submitted to the staging area. If a user just edits a file and saves the
changes, a new version is not created until the file enters the staging area.
VisualPreview
A tab that is displayed on an output page that allows you to perform various
TeamSite functions.
279
Web site
A generic term, meaning a set of interrelated files viewed through a browser.

In TeamSite, the term Web site generally refers to all the contents on a
branch of development, though these may be a superset or a subset of an
organizations actual Web site.
workarea
A virtual copy of a Web site, which may be worked on independently without

affecting the actual site or the work of other contributors. A workarea can be
owned by a single user or a number of users together. Editors and
Administrators can own workareas, but Authors cannot.
workflow
A sequence of tasks that can be assigned to one or more people. For

example, a workflow could define three tasks: to edit some text, to add an
image, and to review the work. Whenever users start a job, it must be based
on a predefined workflow. Workflows are defined by ContentCenter
administrators and other maintainers of the ContentCenter system. See also
workflow model, job, and task.
workflow model
A general workflow configuration that can be used repeatedly. Each workflow

model describes a process which may include user tasks and a wide variety
of automated tasks.
280
Index
A
absolute paths 175
access 132
branch 99
inherit 97
privileges, to TeamSite 101
restricting 97
to files 102
ACEs
about 137
changing at submit time 138
ACLs
about 137
changing at submit time 135
Active Directory 129
Active Response Module 249
adding
users to TeamSite 102
admin_roles 95
administration
creating branches 96
integrating content 97
Administrators
defined 29, 269
Advanced File Merging
defined 269
anonymous binds 129
application variables 231
approve
defined 269
area relative path 36
assign
defined 269
assigning files 29
attribute search
defined 269
attributes
filtering 135
in LDAP schemas 128
authenticate_by 131
authentication 133
external file 121, 131
LDAP 121, 131
local 131
modes 131
PAMs 131
password 101
setting type 121
users 131, 242
Authors
defined 29, 269
Autoprivate
defined 59, 270
matching
filenames 60
patterns 59
autoprivate.cfg
encoding 61
format 59
location 59
sample 61
special characters 60
available_templates.cfg 73
B
backups
Content Stores 209
multiple stores 211
of workareas 210
strategies 211
281
Index
branch_default_perm 110
branch_owner_role 95
branch_security 109
branches 94
administrator 95
creating 96
defined 26, 270
inherit access 97
locking models on 57, 94
managing 98
owner 95
private 94
properties 99
read access 109
remappings, configuring 176
restricting access 97
security 109
sharing content among 97
structure 35
browsers
clearing cache 40
C
cache size
configuring 68
cachesize 68
caching 267
captured subexpression 232
casual contributor
defined 270
changing
file attributes, on submission 135
group ownership of workareas 118
permissions, on directories 103
TeamSite file locations 85
TeamSite mount 86
characters
non-ASCII 217
charset parameter, content encoding 222
checking
disk space usage 88
for multiple servers 78
282
request handling 78
server status 76
chgrp command 118
CLTs
code page requirements 221
defined 270
iwchgrp 118
iwfsshrink 90
iwgetelog 81
iwgettrace 81
iwldapsync 129
iwstat 83
iwtestcfg 141
iwutildreset 64
iwutildstat 64
code pages 221
collection
defined 270
command trigger
defined 270
command-line tool
defined 270
comments
defined 270
compare_search_limit 58
comparing
defined 271
Composite search
defined 271
configuration files
iw.cfg 39
list of 46
locations 85
configuring
Autoprivate 59
branch and workarea security 109
branch remappings 176
cache size 68
Content Store freezes 70
default permissions
on files 110
different web servers 183

domain lists in the login screen 52
domains for group authentication 134
encoding of text files 222
external remappings 183
file locations 85
group remapping 120
IP addresses 84
iw.cfg 39
locking behavior 58
main branch 57
options in iw.cfg 40
PAMs 132
proxy server 174
restarting after changes 40
rule sets for metadata capture 153
Submit and Update logs 59
submit filtering 135
throughput monitors 69
user interface 51
web server uid 119
conflicting edits
defined 271
conflicts
defined 271
conserving disk space 90
content
defined 271
Content Store
backing up 209, 211
deactivated 266
defined 25
freezing 70
moving 91
ContentCenter
localized interface 219
user interface 128
ContentCenter Professional
defined 271
ContentCenter Standard
defined 271
control panel, Regional Setting 71
convert
defined 271
creating
branches 96
editions 29
workareas 102
customer_webserver_host 174
customer_webserver_port 174
D
DAS Publishing 67
data record
defined 272
printing 74
data_root 73
datacapture.cfg 153, 198
annotated example
rule identifier 158
UTF-8 encoding 158
validation-regex 159
configuring 153
DataDeploy
enabling DAS publishing 67
debug_adsi 116
debug_event_handler 141
debug_output 53
debugging
proxy server configuration 188
submit filtering 141
default
code pages 221
drive (Y:) 79
file permissions 110
user authentication 131
default_protocol 56
iwov_webdesk_url tag 56
iwsend_servlet_mail.ipl script 56
delegated administration
defined 272
deleting
branches 91
editions 89
283
Index
device drivers
kernel 80
directories
permissions 103
directory structure
copying 72
directory_default_perm 110
disable_ext_task_impersonation 69
disabling
VisualPreview 52
disk cache
users/group/role 116
disk space
checking usage 88
compression 89
conserving 90
file system mount 34
low 70
managing 88
moving the Content Store 91
recovery 89
removing old versions 91
removing unused branches 91
usage 89
disklow_knodes 70
disklow_mbytes 70
disklowpercent 70
document root
configuring 176
defined 176
mapping 176
domain local groups 114
domain_list 52, 134
domain_local_groups 112
domains
configuring, in the login screen 52
for group authentication 134
DTD
metadata-rules.cfg 149
E
editions
284
creating 29
defined 27, 272
deleting 89
initial, defined 273
see also publishing editions
Submit logs 90
Editors
defined 29, 272
email
corrupted 266
domains 53
incorrect display 266
mapping files 53
servers 53
settings, for workflow 53
tasks 53
email_mapping_file 53
Embedded Failsafe 74
enable_user_group_disk_cache 116
enabling
VisualPreview 52
encoding 55
charset parameter 222
file_encoding.cfg 222, 239
html files 227
IANA preferred names 238
Merge tool 238
META tag 222
setting in iw.cfg 55
Single Byte Character Sets 221
Source Differencing tool 238
specifying 222
text editors 223, 237
text files 227
Unicode 218
UTF-8 218, 237
valid charsets 238
visual differencing 239
vpaths 227
environment variables
LANG 71
SiteMinder 247
event subsystem 65
events 65
publishers 66
subscribers 66
event_log_size 59
events log 81
locating 81
example templating environment 72
copying 72
extended attributes 145
migrating 163
modifying 55
external remappings, configuring 183
F
failover see proxy server
file system
mount 34
performance, improving 87
structure 35
file_default_perm 110
file_encoding.cfg
content encoding 222
defined 227
Merge tool 238
sample file 239
Source Differencing tool 238
UTF-8 237
valid encodings 238
visual differencing 239
VisualPreview 238
files
access to 102
assigning 29
autoprivate.cfg 61
changing attributes of 135
comparing 58
configuration 227
datacapture.cfg 153, 198
default permissions 110
editing 267
encoding 227
file_encoding.cfg 222, 227, 239
histories, defined 273
iw.cfg 39
iwauthend.log 134
iw-bridge_cfg 47
iwevents.log 81
iwinstall.log 81
iwjoberrors.log 82
iwserver.log 81
iwtrace.log 77, 81, 134
iwutild.cfg 61
log 134
metadata-rules.cfg 149, 150
modification time 54
pam.conf 132
permissions 103, 110
private 59
sample metadata-rules.cfg 150
sample submit.cfg 143
setting permissions on 102
sharing among branches 97
submit.cfg 135
submitting locked 58
tagging 146
timestamp 55
user_databases.xml 121
virtual 35
filtering, on file submission 135
finding the installation directory 80
font message 266
force_EA_mod_times 55
form entry
defined 272
form item
defined 272
FormsPublisher
configuring 72
freezing the Content Store 70
full-text search
defined 273
fully qualified paths
285
Index
see proxy server
G
Get Latest
defined 273
global_default_map 176
groups
adding user 118
authenticating domains 134
creating 117
defined 273
domain local 114
global 113
improving performance 114
membership 117
nested 116
NFS limitations 120
operating system 117
remapping 120
TeamSite 96
universal 113
UNIX 117
Windows 112
H
histories
defined 273
honor_setgid 120
honor_setgid_on_rename 120
host 56
host headers, remapping
see proxy server
http_port 56
https_port 56
I
IANA charset names 238
IFS volume 79
IIS
and the server mount 79
impersonate_without_password 69
286
include_nested_groups 116
inherit from parent 97
inode count 70
installation directory, locating 80
intermediate variables 231
internationalization
browser behavior 223
client and server 217
encoding setting in iw.cfg 55
file_encoding.cfg 227
IANA charset names 238
iw.cfg settings 70
recommendations 222
regex_map 237
server_locale setting 70
text editor encoding 223
Unicode 218
UTF-8 218, 237
VisualPreview 227
vpath encoding 227
Interwoven Merge tool 227
IP addresses, changing 84
iw_bridge_cfg.xml 47
iw.cfg 39, 70, 73, 132
about 39
access 43, 94, 95, 109, 112, 114, 116, 120, 129
admin_roles 95
and the proxy server 176
authenticate_by 131
authentication section 131
branch_default_perm 110
branch_owner_role 95
branch_security 109
cachesize 68
changing the templating directory 73
compare_search_limit 58
configuration options 40
Content Stores 45
customer_webserver_host 174
customer_webserver_port 174, 176
data_root 73
debug_adsi 116
debug_event_handler 141
debug_output 53
default_protocol 56
directory_default_perm 110
disable_ext_task_impersonation 69
disklow_knodes 70
disklow_mbytes 70
domain_list 52, 134
domain_local_groups 112
email_mapping_file 53
enable_user_group_disk_cache 116
encoding 55
event_log_size 59
file_default_perm 110
force_EA_mod_times 55
format 39
FormsPublisher 42, 73, 74
honor_setgid 120
honor_setgid_on_rename 120
host 56
http_port 56
https_port 56
impersonate_without_password 69
include_nested_groups 116
iwproxy_host 174
iwproxy_port 174
iwproxy_smartcontextedit_allowed 52
iwutild_runas_root 64
ldap_sync_retry 129
ldapcache_thread_delay 129
list of options 41
locating 40
lockmodel_compatibility 58
log_ldap_sync 129
maildomain 53
mailserver 53
main_group 94
main_lock_model 58
main_owner 94
maintaining preview files 73
map_secondary_to_primary_gid 120
mask_workarea_access 109
old_mod_times 54
only_lock_owner_creator_submits 58
pam_do_acct_mgmt 132
pam_service 132
password_file 131
pretty_print_dcrs 74
preview_history_limit 73
printing data records 74
proxy server 44
secondary_admin_account 95
server functionality 41, 54, 55, 56, 58, 59, 64
server performance 42, 68, 69, 70
server_locale 70
servlet_port 56
setting ports 56
show_user_list 134
specifying preview directory 73
submit filtering 44
thruputmonitoring 69
UI functionality 41, 52, 53, 54
use_adsi 113
use_mapping_file 53
utild_ext_tasks_portnum 64
valid_domains 54
webserver_group 119
webserver_uid 119
windows_groups_for_sharing 114
windows_groups_for_users 114
workarea_default_perm 110
workarea_security 109
workflow 45
iwauthend 133
iwauthend.log 134
iwchgrp 118
iwevents.log 81
iwfsshrink 90
iwgetelog 81
iwgettrace 81
iwinstall.log 81
iwjoberrors
log file 82
iwjoberrors.log 82
287
Index
iwldapsync 127, 129

iwovwfs.log 80
iwproxy
configuring 174
debug option 188
iwwebd 172
performance considerations 178
SSL support 172
iwproxy_host 174
iwproxy_port 174
iwproxy_smartcontextedit_allowed 52
iwserver
checking 76
locating 80
log file 81
memory usage 76
starting 77
stopping 77
iwserver.log 81
iwstat 83
iwtestcfg 141
iwtrace.log 77, 81, 134
iwtssmar file
SiteMinder 249
iwutild 61
iwutild_runas_root 64
iwutild.cfg 61
iwutildreset CLT 64
iwutildstat CLT 64
iwwebd 172, 178
J
Java servlet engine 56
jobs
defined 31, 273
K
kernel device driver 80
languages, browser behavior 223

LDAP
anonymous binds 129
authentication 131
login password 124
modifying schemas 128
schemas 132
search, troubleshooting 130
setting up 121
synchronization 127, 129
TeamSite user interface 128
user authentication 121
users adding automatically 127
LDAP synchronization 127
ldap_sync_retry 129
ldapcache_thread_delay 129
Local File Manager
localized GUI 219
locales
native 70
TeamSite server setting 70
locations
installation directory 80
iw.cfg 40
TeamSite files, changing 85
locking
branch 94
branches 57
configuring submits 58
defined 274
in workareas 58
on the main branch 57
role and branch 57
types of 56
lockmodel_compatibility 58
log files
event 81
installation 81
iwauthend 134
iwevents.log 81
iwinstall.log 81
iwjoberrors.log 82
LANG environment variable 71
288
iwserver.log 81
iwtrace 134
iwtrace.log 81
reviewing 80
server 81
submit 59, 90
trace 81
update 59
workflow 82
log size 59
log_ldap_sync 129
logging
users and groups 134
logging in
authentication 101
login
screen, configuring domain lists 52
low disk space 70
low inode count, detecting 70
M
macro expansion 141, 143
macros 142
expansion 143
maildomain 53
mailserver 53
main branch
defined 274
locking model 57
ownership 94
main_group 94
main_lock_model 58
main_owner 94
Manage Branches screen 98
mandatory write locking 57
defined 274
map_secondary_to_primary_gid 120
mask_workarea_access 109
Master
defined 30, 274
secondary 95
MediaBin
anonymous access 205

connecting to 192
MediaBin Connector properties 192
MediaBin Connector
configuration 192
modifying FormsPublisher 197
modifying presentation templates 200
troubleshooting 205
memory
shared 266
Merge tool 227, 238
merging files
defined 274
META tag 222
metadata
attribute 202
custom 204
data types 202
defined 274
Dublin Core 203
MediaBin Connector 201
metadata capture
DTD 149, 153
rule sets 153
metadata-rules.cfg
configuring 149
DTD 149
examples 149
rule identifier 150
sample file 150
UTF-8 encoding 150
vpath identifier 150
Microsoft Management Console, mount errors 79
modification time 54
monitoring
system status 69
mount errors, Microsoft Management Console 79
mounting the TeamSite server 79
multibyte characters
browser behavior when interpreting encoding
223
multiple servers 78
289
Index
MultiStore
backing up 211
N
Native Mode Active Directory 112
Navigation Window
defined 274
nested groups
disabling 116
Netegrity 241
New Branch screen 96
new users
adding 102
NFS exports 36
NFS, group limitations 120
non-ASCII characters 217
non-OS users 121
impact 130
Notepad, saving documents as UTF-8 223
O
old_mod_times 54
only_lock_owner_creator_submits 58
operating system groups 117
optional write locking 57
defined 275
OS groups 118
output file
defined 275
override permissions 103
ownership
branch 94
workareas, changing 118
P
PAM
account management 132
and TeamSite 132
authentication 133
configuring 132
defined 131
290
third-party modules 133

pam_do_acct_mgmt 132
pam_service 132
pam.conf 132
password_file 131
passwords 101
encrypting 124
length 102
paths
absolute 175
relative 175
resolving see also proxy server
vpath 36
performance
monitoring 69
using groups 114
permissions
checking 103
default 110
directory 103
file 101, 102, 103, 110
override 103, 268
required for actions 103
role-based 101
types of 103
workarea 103
port number
proxy server 174
servletiw.cfg
servlet_port 56
web server 174
presentation templates
for MediaBin Connector 200
pretty_print_dcrs 74
preview
defined 276
maintaining files 73
specifying directory for 73
preview_history_limit 73
preview_system_directory 73
private
branches 94
defined 276
files 59
properties
branch 99
proxy server
about 172
configuring
applying changes 174
basic operation 174
overview 171
to use different webservers 183
debugging 188
document roots 177
external remappings 183
failover 186
fully qualified paths
Internet Explorer 180
resolving 178
server configuration 179
host header remappings 185
host name 174
port number 174
redirecting TeamSite views 181, 182
relative and absolute paths 175
remapping document roots
rules of precedence 173
SSI remapping 186
public
defined 276
public URL protection 53
publisher
defined 276
publishing
defined 276
publishing editions 29
R
RCS macro expansion
about 141
enabling 143
reconfiguring IP address 84
recovering disk space 89
redirecting TeamSite views see proxy server

regex_map
element 227, 229
illustrated 228
internationalization 237
introduced 227
regular expression syntax 231
strategies 236
UTF-8 237
variables 231
Regional Settings control panel 71
regular expressions
about 136
case-sensitivity 231
expression engine 230
file encoding 227
in regex_maps 231
in Submit filters 136
relative paths 175
see also proxy server
remote contributors 172
request handling 78
resolving path names see proxy server
restart server 265
restrict access 97
reverse proxy
SiteMinder 246, 253
Reviewers
defined 29, 276
reviewing TeamSite logs
overview 80
with Windows Event Viewer 83
roles
defined 28, 276
operations 103
rule sets, configuring 153
rule syntax 230
S
SCE
see VisualPreview
schemas
291
Index
LDAP 132
search
composite 271
full-text 273
secondary_admin_account 95
server
load, monitoring 83
locales 70
mount errors 79
mount, verifying 79
multiple 78
operations
verifying 76
resources
disk space 88
managing 85, 87
starting 77
status, checking 76
stopping 77
server log
location 81
server mount
verifying 79
server performance
configuring 68
server shut down
unexpected 265
server_locale 70
servlet
engine 56
port 56
servlet_port 56
setgid behavior 120
settings
email, for workflow 53
encoding 55
server_locale 70
show_user_list 134
Single Byte Character Set (SBCS) 221
single sign-on 241
Site Rollback
defined 277
292
SiteMinder Policy Server 241, 263

configuring 246, 253
environment variables 247
Source Differencing tool 227, 238
SSIs, remapping see proxy server
SSL support 172
staging area
defined 26, 277
starting TeamSite
server 77
startup time
reducing 113, 134
stopping TeamSite server 77
subbranches
defined 277
submit
changing file attributes 135
filtering
debugging 141
introduced 135
RCS macro expansion 141, 143
sequence of events 138
locked files 58
log file 59, 90
submit locking 56
defined 277
submit.cfg
about 135
format of 135
sample 138, 143
submitting
defined 277
subscriber
defined 277
synchronization
LDAP 127, 129
system information
monitoring 69
T
tag
defined 277
Tagger GUI
reverting to original 153
TagUI
configuring 149
features 146
next generation 146
select box entries 163
task list
defined 278
tasks
defined 32, 278
email 53
ownership 104
states 32
transitions
defined 278
TeamSite
architecture 32
configuration files 46
disk space usage 88
file locations, changing 85
groups 96
internationalized 216
mount, changing 86
proxy server
iwwebd 171
overview 172
see also proxy server
server
answering requests 78
enhancing performance 87
mounting 79
process 78
resetting 78
restarting 77, 78
starting 77
stopping 77, 78
UNIX permissions 103
web daemon 171
templatedata directory
copying to workarea 72
templates
defined 278
templating directory
changing 73
templating environment
example 72
templating.cfg
defined 278
text editor encodings 223, 237
throughput monitors 69
thruputmonitoring 69
timestamps 54
trace log
debugging information 141
location 81
troubleshooting 263, 265
Content Store 266
email 266
flexible roles 267
IIS 267
JVM 266
MediaBin Connector 205
navigating 267
permissions 268
server shut down 265
shared memory 266
SiteMinder Policy Server 263
Unix installation 266
virus scanning 267
trusted clients 61
U
Unicode 218
universal groups 113
UNIX permissions 103
unlock
defined 278
URL commands
multibyte characters 218
use_adsi 113
use_mapping_file 53
user interface
configuration 51
293
Index
stored in LDAP 128

user_databases.xml 121
attributes 123
example 121
users
authenticating 121
authentication
types of 131
defined 278
identifying 121
logging 134
non-OS 121, 130
roles
permitted actions 103
UTF-8
about 218
recommendations 222
regex_map 237
utild_ext_tasks_portnum 64
utility service
iwutild 61
V
valid_domains 53, 54
variables
application 231
captured subexpression 232
intermediate 231
naming convention 231
regex_map 231
verifying server mount 79
version path 36
versions 58
defined 279
viewing
branches and workareas 109
virtual files 35
virus scanning 267
VisualPreview
defined 279
disabling 52
294
enabling 52
encoding of text files 227
localizing 220
tool bar 52
vpath 36
defined 36
vpaths, encoding mappings 227
W
web browsers, interpreting encoding 223
web content, specifying encoding 222
web daemon
about 172
configuring 171, 174
setting defaults 56
web servers
configuring 183
group 119
host name 174
plugins 174
port number 174
starting and stopping 174
uid 119
Web site
defined 279
development 27
webserver_group 119
webserver_uid 119
Windows
Event Viewer 83
permissions and TeamSite 103
Task Manager 76
Windows groups 112
Windows network 113
windows_groups_for_sharing 114
windows_groups_for_users 114
Wordpad, saving documents as UTF-8 223
workarea_default_perm 110
workarea_security 109
workareas
changing group ownership 118
creating 102
defined 26, 279
locking files in 58
ownership changes 119
permissions 103
permissions on directory 109
read access 109
security 109
workflow
defined 279
jobs
defined 31
tasks
defined 32
workflow log
locating 82
workflow models
and jobs 31
assign-edit-approve 30
defined 30, 279
WorkflowAdmin
defined 30
WorkflowUser
defined 30
Write locking
see also Optional Write locking, Mandatory Write
locking
X
XML
datacapture.cfg 153
metadata-rules.cfg 149
regex_map language 227
special characters 235
Y
Y: drive (default TeamSite drive) 79
295
Index
296

TeamSite 7.3 Admin Rev2 en

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

TeamSite 7.3 Admin Rev2 en

Diunggah oleh

Hak Cipta:

Format Tersedia

TeamSite

Trademarks and Copyrights

Notice to Government End Users

TeamSite Administration Guide

TeamSite Workflow ..................................................................................................................... 30

Part 2 Administrative Tasks

TeamSite Administration Guide

Working with the Utility Service ....................................................................................................61

TeamSite Administration Guide

Manage Disk Space .................................................................................................................... 84

TeamSite Administration Guide

Maintain the GID .................................................................................................................120

TeamSite Administration Guide

Merge Rulesets ........................................................................................................................ 161

TeamSite Administration Guide

TeamSite Administration Guide

Interface with Localized Operating Systems .............................................................................. 219

TeamSite Administration Guide

Integrate SiteMinder and TeamSite with an Active Response ....................................................242

TeamSite Administration Guide

TeamSite Administration Guide

Using TeamSite for Web site development ............................................................... 28

Assign-edit-approve workflow model ......................................................................... 31

Example of a workflow for a job................................................................................. 31

Connections from client computer to TeamSite server.............................................. 33

Connections from client computer to TeamSite server.............................................. 34

TeamSite file system structure .................................................................................. 35

How the Event Subsystem Works ............................................................................. 66

Registry Editor window .............................................................................................. 87

Expanding the directory tree of the TeamSite server ................................................ 87

Figure 10 Viewing a shared access drive .................................................................................. 88

Viewing the size of the iw-store ................................................................................. 89

Figure 12 New Branch screen ................................................................................................... 96

TeamSite Administration Guide

TeamSite Administration Guide

TeamSite options configurable in the iw.cfg File......................................................... 41

Functions of Configuration Files ................................................................................. 46

Autoprivate Encodings ................................................................................................ 60

server_locale Settings in iw.cfg................................................................................... 71

server_locale Settings in iw.cfg................................................................................... 72

Other files and directories controlled by [location] ...................................................... 86

Role operations and permission checking ................................................................ 104

Attributes for user_databases.xml file....................................................................... 123

Vpaths and corresponding rulesets .......................................................................... 152

MediaBin metadata elements ................................................................................... 204

Language Encodings ................................................................................................ 220

Code Pages for CLTs ............................................................................................... 221

Default Encodings for Text Editors ........................................................................... 223

XML Special Characters ........................................................................................... 235

Policy ........................................................................................................................ 256

Troubleshooting options............................................................................................ 265

TeamSite Administration Guide

TeamSite Administration Guide

About This Document

Autonomy Customer Support

TeamSite Administration Guide

About This Document

you could retrieve documents related to the iManage, IDOL, Virage or

documents related to IDOL Server, Virage Videologger, or KeyView Filter.

could retrieve documents related to the Content or Category component in

documents in PDF or HTML format. Guides are typically provided in both

TeamSite Administration Guide

User-interface elements such as a menu item or button.