FirM Administration v2!4!01

Administration
& Operations Manual

v2.4
PAG E 2 O F 1 8 5
Table of Contents
1. Introduction ........................................................................4 Configuring Agent Trigger Profiles...........................................56
The Chairman’s Introduction.......................................................4 8. Creating a new Request..................................................57
What is FirM?...................................................................................4 Creating a single request.............................................................57
What does FirM do?.......................................................................4 Creating Bulk requests................................................................58
How does FirM handle large groups? ........................................5
What are profiles? How are they used?...................................5 9. FirM Domino User Transactions Explained................60
Does FirM work with Domino 5, 6, 7 and 8?...........................6 User Create....................................................................................60
Feature List v2.4..............................................................................6 User Modify....................................................................................64
What does FirM consist of? .........................................................9 User Disable...................................................................................65
Target Audience...............................................................................9 User Enable.....................................................................................66
HADSL – About us.........................................................................9 User Delete....................................................................................67
2. How FirM Works.............................................................10 User HTTP password reset........................................................72
User Move Server.........................................................................73
Introduction....................................................................................10 User Move in Hierarchy..............................................................74
Architecture...................................................................................10 User Move Location.....................................................................76
Workflow .......................................................................................10 User Rename Common Name..................................................78
Client Experience..........................................................................10 User Recertify................................................................................80
3. Installing FirM....................................................................11 User Resend User ID and Password........................................81
Introduction....................................................................................11 User Password Digest Enable....................................................83
Who should install FirM?............................................................11 User Password Digest Disable...................................................84
How this product is delivered...................................................11 User Password Digest Reset......................................................85
Installation & Configuration of FirM .......................................11 User Roaming Enable...................................................................86
Stage 1: Encryption key creation...............................................12 User Roaming Disable.................................................................87
Stage 2: Initial install of FirM.......................................................14 User Mail file Grant Access........................................................88
Stage 3: Basic FirM Configuration.............................................17 User Cross-Certify.......................................................................90
Stage 4: FirM System Profiles Set Up.......................................20 User MailFile Quota.....................................................................91
Stage 5: FirM User Profiles Set Up............................................22 User Move Domain......................................................................92
Stage 6: FirM Group Profiles Set Up........................................25 10. Configuring FirM User Transactions..........................94
4. Importing Certifiers & Passwords................................30 Common Tab - Authorisation....................................................94
Name Construction and Token Replacement........................95
5. System Configuration......................................................31 User Create Profile......................................................................96
Target Audience............................................................................31 User Modify Profile.......................................................................99
Introduction....................................................................................31 User Disable Profile.....................................................................99
System Configuration – Databases...........................................31 User Enable Profile.....................................................................100
System Configuration - Servers................................................32 User Delete Profile....................................................................100
System Configuration - Directories.........................................32 User Reset HTTP Password Profile.......................................101
System Configuration – Admin Settings..................................33 User Move Server Profile.........................................................101
System Configuration – Billing...................................................35 User Move Profile.......................................................................101
System Configuration – Name Validation...............................35 User Move Location Profile.....................................................101
System Configuration – Workflow...........................................39 User Rename Profile..................................................................103
System Configuration – Archiving & Expiry...........................39 User Recertify Profile................................................................103
System Configuration – Active Directory (AD)...................40 User Resend User ID & Password Profile............................103
System Configuration – BlackBerry ........................................40 User Password Digest Enable..................................................104
User Password Digest Disable................................................104
6. Administration Tools.......................................................41
User Password Digest Reset....................................................104
Config Tab.......................................................................................41 User Roaming Enable.................................................................104
Profiles Tab.....................................................................................41 User Roaming Disable...............................................................105
Monitor Tab....................................................................................42 User Mail File Grant Access.....................................................105
Import Tab......................................................................................43 User Cross-Certify.....................................................................105
'Group Restore' Tab.....................................................................43 User MailFile Quota...................................................................105
BlackBerry Management Tab......................................................45 User Move Domain....................................................................106
System Views Tab..........................................................................46
11. FirM Group Transactions Explained........................107
7. Configuring System Profiles...........................................48 Group Create..............................................................................107
Common System Profile Tab – “Fields”..................................48 Group Modify..............................................................................109
ID Profiles.......................................................................................49 Group Manage Members..........................................................111
Country Profiles............................................................................50 Group Delete..............................................................................112
Certifier Profiles...........................................................................50
Location Profiles............................................................................51 12. FirM Application Transactions Explained................114
Business Group Profiles..............................................................52 Application Create.....................................................................114
Company Profiles..........................................................................52 Application Modify......................................................................116
Internet Address Profiles............................................................52 Application Delete......................................................................117
Group Profiles...............................................................................53 13. Configuring Application Transactions.....................119
Automatic Recertification Profiles............................................55
Configuring Notification Profiles..............................................55 Common Tab – Authorisation................................................119
© 2008 HADSL FirM Administration Manual v2.4.

PAG E 3 O F 1 8 5
Application Create.....................................................................119 24. Importing Transactions using CSV...........................151

Application Modify......................................................................120 CSV File Overview.....................................................................151
Application Delete......................................................................120 Importing Transactions Using CSV.........................................152
14. Active Directory Overview.......................................121 25. FirM Group Monitoring..............................................160
Architecture.................................................................................121 Group Monitoring Explained...................................................160
15. Installing & Configuring Active Directory..............123 Group Monitoring Components.............................................160
Activating Active Directory ....................................................123 Setting up Group Monitoring...................................................160
The FirMAD LSX DLL...............................................................124 Selecting the Groups to Monitor............................................160
Setting Permissions within AD................................................124 Limitations of Group Monitoring............................................161
Installing the FirM AD Component........................................124 26. ID Backup, Refresh and Escrow................................162
16. FirM AD Transactions Explained..............................128 ID Backup.....................................................................................162
AD User Create..........................................................................128 ID Escrow.....................................................................................164
AD User Disable.........................................................................130 The ID Refresh Process............................................................165
AD User Enable..........................................................................130 27. User MailFile Quota Management...........................166
AD User Password Reset.........................................................131 Non-Person Document Update Mode..................................166
AD User Modify..........................................................................132 Person-Document Update Mode...........................................166
AD Group Create......................................................................133
AD Group Delete.......................................................................134 28. The Automatic User Recertification Engine..........167
AD Group Modify.......................................................................135
29. The Expiry Engine........................................................168
17. Configuring AD Transactions....................................136 The User Expiry Engine............................................................168
Common Authorisation Tabs..................................................136 The Group Expiry Engine.........................................................168
AD User Create..........................................................................137
30. Troubleshooting & Support.......................................169
AD User Disable.........................................................................139
AD User Enable..........................................................................139 The Log Database.......................................................................169
AD User Password Reset.........................................................139 Mailing Log Documents to Support.......................................169
AD User Modify..........................................................................139 Document types within the Log Database...........................169
AD Group Create......................................................................140 Raising a support call.................................................................170
AD Group Delete.......................................................................140 Known Issues...............................................................................171
AD Group Modify.......................................................................140 AdminP Database........................................................................171
This Platform has a fatal code-page issue.............................171
18. BlackBerry Overview..................................................141
31. FirM Databases.............................................................172
Architecture.................................................................................141
Request Processor.....................................................................172
19. Installing the BlackBerry interface...........................142 Help Database ............................................................................172
20. BlackBerry Transactions Explained..........................143 Log Database ..............................................................................172
Extended AdminP processor ..................................................173
Authorisation...............................................................................143 Group Registry ...........................................................................174
BlackBerry Provision..................................................................143 Monitored Group Shadow Repository.................................175
BlackBerry Enable.......................................................................144 Certifier Repository..................................................................175
BlackBerry Disable.....................................................................144 Password Repository ................................................................175
BlackBerry Reset Password.....................................................145 ID Repository .............................................................................176
BlackBerry Delete .....................................................................145 ESCROW Database....................................................................176
21. Configuring BlackBerry Transactions......................146 Audit Repository .......................................................................177
BlackBerry Provision..................................................................146 Archive Repository ...................................................................177
BlackBerry Enable.......................................................................146 Billing Database ..........................................................................177
BlackBerry Disable.....................................................................146 Deleted Records Database......................................................177
BlackBerry Reset Password.....................................................146 Application Monitor...................................................................177
BlackBerry Delete......................................................................146 Application Usage Log...............................................................178
22. The FirM Application Monitor..................................147 Appendix A - The AdminP Push around Agent.........179
The Application Monitor Database........................................147 Overview......................................................................................179
The Application Usage Database............................................149 Configuration of AdminP Push around Agent.....................179
23. The FirM Web Interface.............................................150 Appendix B - Interfacing with FirM...............................181
Web Interface Configuration...................................................150 Triggering your agents from a FirM process........................181
Web Interface Client Experience...........................................150 Using the CSV interface pro grammatically.........................182
Create FirM requests from your own programs................184
FirM Administration Manual v2.4 © 2008 HADSL

PAG E 4 O F 1 8 5 1 . I N T RO D U C T I O N
1. Introduction
The Chairman’s Introduction
Congratulations on choosing and using FirM - the premier solution for optimising the management of your Domino
infrastructure. Over the R5 to D7 releases of Domino the Lotus arm of IBM has worked hard to increase the value
that can be derived from your Domino infrastructure. We at HADSL are committed to ensuring that you can
unlock this value without the penalty of increased administration costs, in fact, with FirM you can match the value
gains from your Domino infrastructure with equal gains in value in your Domino administration. Our designers and
architects not only track technical changes in Domino but also follow best practice usage patterns in IT
management in general and Domino Administration in particular; to bring you a truly effective solution for
controlling and reducing your administration and management costs. With HADSL solutions you will not only keep
pace with the market, but move ahead of the market in best practice administration and management.
At HADSL we value each and every one of our customers, to make sure that you get the best from FirM and
HADSL, make sure that you give us any feedback, both good and bad on the use of any of our products or services.
We particularly urge you to let us know how you would like to see our products develop. Keeping us in touch with
your problems helps us to make sure that our solutions make your life easier.
Ian Tree,
Chairman, HADSL
What is FirM?
FirM is an Identity Management suite for Lotus Notes/Domino designed to automate group and user management.
It enables the delegation of most user and group-related administrative functions to non-IT personnel thereby
providing considerable cost savings without any loss of security and with increased service levels.
How does it work?

FirM presents permitted end-users (Requesters) with simple Domino-based forms to fill in. Optionally, other users
(Authorisers) authorise and accept these change requests. The request is then passed to a back-end processor,
which:
 validates that the request is allowed
 validates the request security
 performs checks to ensure that the request will not cause problems
 performs the request
 informs the Requesters and Authorisers of the change
How does this help me cut costs?

FirM reduces Total Cost of Ownership (TCO) by reducing the administrative burden and overhead costs. It moves
Domino systems closer to a ‘no touch’ user administration model by moving the user administration and group
administration functions out of the expensive corporate IT departments and into the business units themselves.
FirM significantly decreases the amount of time it takes to set up a Domino user. FirM is automated and always
available so remote users in another time zone don't have to wait a business day for new users to be created.
FirM increases security by removing all certifiers and certifier passwords from the majority of Domino
administrators.
The quality of users created by FirM is guaranteed. There are no broken mail files, no incorrect templates, and all
required information is guaranteed to be complete and correct.
FirM’s ‘profiles’ ensure that naming standards and database placement rules are enforced resulting in a known and
coherent infrastructure.
What does FirM do?

FirM allows non-technical users (“Requesters”) a simple end-user interface to perform complex user, group,
application, active directory and Blackberry based transactions.
Why is FirM the best Domino User and Group Managementtool?

1 . I N T RO D U C T I O N PAG E 5 O F 1 8 5
 FirM is very easy to install and implement and does not require expensive code-changes to reflect your
business model.
 FirM is very easy for the end-user to use.
 FirM’s operations are based on ‘profiles’ held within FirM. Profiles pre-define all the technical
infrastructure-based settings of a particular type of request. This means that a business user making a
request, say,to create a new user, only needs to supply information relevant to their business needs. In the
case of creating a new user all that is required is the user’s name.
 FirM’s ‘dynamic fields’ enable the FirM Administrator to specify in a profile that, when a request is made,
information specific to the request is provided by the Requester. For example, the Requester may be
presented with a question such as ‘What is the person’s new office telephone number?’. The supplied
information, in this case the telephone number, is then written to the person’s document in the
appropriate field.
 FirM is based on LotusScript, which means that dedicated add-in tasks do not need to be run on the
server. Add-in tasks are a frequent cause of instability.
 FirM can run on multiple servers with failover capability, giving reliable 24x7 operations.
 At particular stages in a request, FirM can run Domino agents in designated databases. For example, when
a ‘User Create’ request succeeds, FirM can run an agent in a designated database and pass it all the
information from the request document.
 FirM may be integrated into other applications using object-oriented LotusScript classes. This enables
group-management functionality to be simply added to an in-house application, say a web-user
management application for the intranet, by writing less than 20 lines of LotusScript code.
 FirM supports a Domino multi-domain environment.
How does FirM take advantage of load-balancingand server clusters?

FirM fully exploits Domino load-balancing and server clusters. The following happens when a user is created:
 The new name is checked for duplicates in all Domino directories. If the name already exists then
numbers are optionally added to ensure uniqueness
 the name elements are optionally checked against an external database, such as a global short name
directory
 the user is added to relevant groups based on information in the profile
 profile-based information is used to query the directory in order to determine the least-loaded server
 The user's mail file is created using a profile-specified template name and user access level. If that server
is part of a cluster and the configuration variable ‘Add mail file to all clusters’ is set in the System
Configuration, then replica mail files are created on all cluster mates
How does FirM handle large groups?

FirM’s group management capability easily accommodates large groups. Domino limits group size to less than 16K
of information so when a group approaches this size, FirM automatically ‘spawns’ subgroups. For example, when a
group called ‘Mail Users’ gets close to a pre-defined limit, FirM will move the existing members to a new group
called ‘Mail Users_01’, and add ‘Mail Users_01’ as a member to ‘Mail Users’. FirM does not limit the number of
spawned subgroups.
What are profiles? How are they used?

Profiles are templates for FirM requests. A profile is created for a specific request, say, creatinga new user in the
marketing department. Then, when a specific user is to be created, the request is made using that profile. The
profile contains all the technical infrastructure-related information and the Requester simply provides the business-
specific information needed to complete the request, in this case, the user’s name and perhaps other user-related
information like their phone number.
A profile is a collection of rule information that defines:
 The name of the profile as seen by the Requester. This will be a meaningful name in the business context
such as ‘New marketing user in London’ instead of ‘AppSev01Mar/Lon/Business/IBM’
 Who is authorised to use this profile to make requests

 Who needs to authorise requests made with this profile

 Static fields, i.e. the pre-defined content of specific fields on the person document which this profile
creates or modifies.
 Dynamic fields, i.e. the content of fields on the person or group document being created or modified,
which is provided by the Requester at the time a request is made
 The groups to which a newly created person should be added.
For the ‘User Create’ profile, a number of sub-profiles can be specified:

 The ‘ID Type’ sub-profile. The ID Type sub-profile defines different types of IDs. For example, the ID
Types ‘Permanent Staff’ and ‘Temporary Staff’ would have different certificate expiration periods, ID file
encryption strengths and so on
 the Certifier sub-profile specifies the certification hierarchy for a user
 The Location sub-profile specifies which server(s) a new user should be created on. If more than one
server is specified then the server with the fewest users will be used. If the selected server is a member
of a cluster then replicas of the user mail file will be created on all cluster mates, if so specified in the
configuration profile.
 the Country sub-profile allows different groups, static fields and dynamic fields to be used based on
country
 the Company sub-profile allows different groups, static fields and dynamic fields to be used based on
company
 The Business Group sub-profile allows FirM administrators to define different business rules for different
business groups, and to enforce control whilst retain complete flexibility.
Does FirM work with Domino 5, 6, 7 and 8?

Currently, the infrastructure in which FirM operates has to be Domino 5.0.8 or better, and the Requesters must be
using Notes 5.0.8 or better. It has been tested on a cross-platform, cross-domain infrastructure that includes
Domino 5.0.11 and Domino 6.0, 6.5 and 7.0 servers, without difficulty.
Upgrading to R6 or R7 will reduce administrationeffort in any case ?

Case studies and reports have shown that Domino sites upgrading to R6 or R7 can show significant TCO
decreases. These sites report that many facilities within the R6 administration client substantially increase the
productivity of their support staff. Many sites will have reduced TCO because they are able to take advantage of
the infrastructure consolidation that is possible with R6. Admin client utilities for registering users, and many
enhanced AdminP functions too will reduce TCO.
However, this does notsolve the problem addressed by FirM - a skilled and trained administrator is still needed to
be able to use the Notes administration client. The Notes administration client is a complex, sophisticated and
highly technical tool. Not the sort of software that a business user would want to have to use and who, because
the tool is inappropriate, would make many errors resulting in replication conflicts and duplicated groups.
FirM provides a ‘zero technical knowledge’ interface to Domino administration, and does so in a safe and secure
way. FirM may be easily operated by non-technical business staff that do not need any knowledge or skills in
Domino group and user administration.
FirM, in fact, extends in many ways the capabilities of the administration client. Groups are only ever edited
centrally so replication conflicts should not occur. Also group membership rules are enforced as are naming
conventions. Additionally, a full audit trail and request history is maintained for actions carried out against the
address book.
FirM complements and significantly enhances the core administration functionality of R6 enabling significant further
reductions in TCO whilst simultaneously delivering an increase in system control.
Feature List v2.4

FirM is a comprehensive Federated Identity and Resource manager for Lotus Domino.

FirM allows you to create profile information on all user and group operations and allow delegation to non-
technical users, in a completely automated, secure and audited manner, thus reducingadministrator burden and
increasing service level
At v2.4 release, it performs the following operations:
User Operations
● User Create. Full Lotus domino user creation with
● Load balancing - given a selection of Lotus Domino serves, FirM will choose the one with least users.
● Cluster mail file creation on one or more server cluster mates.
● ID and Password secure storage & distribution to mandatory or optional recipients.
● Adding the new user to specified groups.
● Setting specified person document fields.
● Enable ND6 style Roaming User.
● Create Password Digest.
● And sending a customised Welcome Message to the user.
● User Delete. A multi-ability deletion process, including full retention of person document, group
membership, optional archiving of mail file to archive server, optional "data owner" workflow cycle,
allowing another user to view the mail file for a limited period of time
● User Modify. Allow modification of specific fields on a users' person document for directory maintenance.
● User Http Password Reset. Allow a non-administrator to set a new internet password for a user
● User Resend User ID and Password. Allow the sending of the latest user ID and password from the
secure repositories.
● User Disable. The addition of a user to a terminations group, preventing user access to your Lotus
Domino environment.
● User Enable. The removal of a user from a terminations group, allowing user access to your Lotus Domino
environment
● User Move in Hierarchy. Recertify a user to a new Lotus Notes certificate hierarchy, with no administrator
intervention whatsoever.
● User Rename common Name. Rename a users' common name.
● User Recertify. Recertify a user with his existing certificate to extend access to your Lotus Domino
environment.
● User Move Server. Move a user (and their mail files) to a new Lotus Domino server automatically.
● User Move Location. Move a user (and their mail file) from one location to another, optionally removing
the user from location specific groups and adding the user to new location specific groups. Also recertify
the user to a new hierarchy if required.
● User Grant Mail File Access. Grant temporary mail file access to a users mail file to another person.
● User Password Digest Enable. Enable user password periodic changes for a user
● User Password Digest Disable. Disable user password periodic changes for a user
● User Password Digest Reset. Allow access to a user if they have exceeded their password change time
period.
● User Roaming Enable. Set the user to a "Roaming" style ND6 user. .

● User Roaming Disable. Stop the user being a "Roaming" style ND6 user. .
● User MailFile Quota. Set a users Mail File Quota.
Group Operations
● Group Create. Create a new Lotus Domino group with full authentication and delegation rights.
● Group Modify. Modify a group’s attributes.
● Group Manage Members. Add and remove users from groups
● Group Delete. Remove a group from the Lotus Domino Directory
ApplicationOperations
● Mail in Database Create. Create a new application and all relevant replicas from a list of allowed templates.
Populate the applications ACL’s and grant modification access to the application owner. Set the application
quota and warning thresholds. Create a directory mail-in database entry in the Domino directory.
● Mail in Database Manage. Modify a mail in database.
● Mail in Database Delete. Remove a mail in database and all replicas, the groups associated with this mail-in
database, and the directory mail-in document itself.
● Scanning all applications and providing user usage and ACL change log information across all databases in
your environment.
Active Directory Operations

● User Create. Create a new user in Active Directory, checking for uniqueness,in a specified container.
Create the users home drive and assign sharing rights. Update any Active Directory attribute associated
with this person, and optionally add him to AD groups.
● User Disable. Prevent a user logging into Active Directory
● User Enable: Allow a user to log into Active Directory
● User Modify. Change an attribute on the users' Active Directory record
● User Password Reset: Set a users Active Directory password.
● Group Create: Create an Active Directory group
● Group Manage Members: Add or remove users from Active Directory groups
BlackberrySupport
As of version 2.4, FirM supports the followingBlackberryhandset operations:
● ProvisionHandset
● Enable Handset for user
● Disable Handset
● Reset password handset
● Delete Handset
● Kill Handset
Automated Tasks
● Automatic User Recertification: Users can be automatically recertified should they match an
administrator-defined profile

● User Expiration. You can specify when a User should be expired from the system. A pre-set number of
days beforehand, an automated message will be sent to the person's manager asking them to confirm or
reject deletion of this user. Should the manager do nothing or confirm deletion, the user is deleted on
that specified date.
● Group Expiration. You can specify when a Group should be expired from the system. A pre-set number
of days beforehand, an automated message will be sent to the group's owner asking them to confirm or
reject deletion of this user. Should the manager do nothing or confirm deletion, the Group is deleted on
that specified date.
● AdminP Push around. FirM supports multi-domain environments, and allows the administrator to specify
which AdminP transactions should be copied between the various domain admin4.nsf databases.
Security Features
The ID Repository, Password Repository and Certifier Repository are all encrypted databases with each database
using a different encryption key.
The system maintains a complete audit history of every processed transaction.
What does FirM consist of?

FirM consists of 15 Lotus Notes databases, of which four need to be replicated around your environment. See the
section titled “FirM Databases” on page 172 for more information.
Target Audience
This document is targeted at the FirM Administrators, likely to be Notes Super-Administrators who will configure,
monitor and maintain FirM.
It is assumed that these people are:
● Notes Administrators with Notes Administration access to their Domino environments
● Skilled Notes Administrators with at least three years experience of Domino Administration, PCLP
accreditation for Release 5 onwards or both.
HADSL – About us
HADSL is an IBM Business partner, and BlackBerry business parter. Its sole focus is the FirM suite of Identity and
Resource Management tools.
FirM comprises a core team of highly experienced Domino consultants and 10+ associate consultants. The core
FirM team includes:
● Bill Buchan. Bill is a dual-PCLP in Domino v3, v4, v5 and v6, as well as dual-CLP in ND7. He is a 10-year
veteran of Lotus Domino. He was invited to present at Lotusphere 2005-2008. As well as Domino
qualifications, Bill is also IBM Websphere v4 certified, Portal v5 (admin and development) certified, Java v2
programmer and Microsoft MCSE/NT certified. He has worked on Enterprise-level groupware projects
since 1995, all over Europe.
● Richard Sampson. Richard is a PCLP (application development) for Domino v4, v5 and v6 and has been
developing solutions for Notes and Domino since 1996 for firms including BDO, Lotus/IBM,JP Morgan
amongst others. He has worked as an accountant, and has an honours degree in Physics.
● Roy Holder. He started his IT career in mainframe operations and has been involved in corporate IT ever
since. He started with Lotus Notes v3 and has been involved with Domino for 10 years.
● Tony Holder. Tonyis our Commercial & Sales Manager, and has 10 years direct experience in the Lotus
Domino market.
● Ian Tree. Ian is our business Mentor and has been in IT for the last 30 years, at senior management and
technical positions.
Our multi-discipline team means that you get the best knowledge and the best product

PAG E 1 0 O F 1 8 5 2 . H OW F I R M WO R K S
2. How FirM Works

Introduction
The Federated Identity and Resource Manager is a Delegated Proxy Administration system for Lotus Domino. This
means that:
● Administrators can delegate common user, group and application tasks to non-technical personnel.
● These personnel can request that tasks be performed
● FirM automatically validates and checks that the tasks are correct, and if so, carries these tasks out
automatically.
Typically, taskswill be completed within 10 minutes of request (depending on authorisation stage and replication
topology).
Architecture
Architecturally, FirM is a number of Lotus Domino databases. The entire set of these databases reside on the FirM
processing server (or servers, should you choose to have a backup FirM processing server).
A subset of these databases can be replicated throughout the Domino environment to allow requesters (people
who request FirM tasks) to interact with FirM.
The processing server need only be a supported version of Lotus Domino server, running on a supported server
platform. Typically, this server will also bethe Administration server for that environment.
FirM can manage single or multiple Lotus Domino domains.
Workflow
Within FirM, there is a two-stage workflow process.
The person creating the request (The “Requester”) may also be allowed to “Authorise” the request. In this case,
the request is processed immediately.
Should the Requester not be permitted to authorise this request, then details are mailed to personnel allowed to
authorise this request. One of these group of people can then Authorise or reject this request.
Client Experience
The requester interacts with FirM via a Lotus Notes client. They can only see options that have been made
available to them, and every item of information is validated before proceeding.
From v2.1.01 onwards, web clients are now supported. See “Web Interface Client Experience” on page 150 for
examples of this.

3 . I N S TA L L I N G F I R M PAG E 1 1 O F 1 8 5
3. Installing FirM
Introduction
This document contains a step-by-step guide to the procedures that must be followed to install and set up FirM.
The installation instructions are written for Domino administrators and assume familiarity with basic Domino
administration tools and procedures.
If problems are encountered please contact your sales consultant, who will be able to provide assistance and route
your question to technical support if necessary.
Who should install FirM?

FirM should be installed by a Domino Administrator with complete administration access (“Manager”) to their
Domino environment, including certifiers and certifier passwords, etc.. Usually this is the head Domino
Administrator for a company.
How this product is delivered

This product is delivered in two parts:
● An installation package, downloadable from the HADSL web site (http://www.hadsl.com) , which contains
all Notes Databases required for FirM to function, as well as the Windows LSX code should you wish to
install the Active Directory component.
● A License key supplied by HADSL, which allows you to unlock and install a copy of FirM.
How to obtain a license key.

Your Sales Representative will provide you with a license key, which will allow you to install and operate FirM. Two
types of license key are available – Evaluation and Full. The evaluation keys are time-limited, and FirM will stop
operating once the expiration date has been passed.
Installation & Configuration of FirM

These installation instructions are written for Domino administrators and assume familiarity with the basic
Domino administration tools and procedures.
If problems are encountered, please contact your Sales Representative who will be able to provide assistance and, if
necessary, obtain technical support.
Quick Installation Process

FirM now includes a “Quick Config” wizard which quickly and painlessly leads you through the post-installation
configuration steps. The quick configuration guide is available from the Downloads page of our web site.
We recommend that you use the Quick Config wizard only once, and only on an empty, installed copy of FirM.
Prerequisites:Necessary informationand access rights

In order to install FirM the following are required:
1. A Domino R5 or R6 server (R5.0.8 or above, R6.0.1 or above), and an administrator workstation running
Notes R5.0.8 or above or R6.0.2 or above, or R7.0 or above.
2. The administrator ID used must have permission to be able to modify the Domino directory, and issue
Administration (AdminP) Requests.
3. A copy of FirM.
4. A license key - this should arrive in an email from HADSL. The licence will be either for a time-limited
evaluation or will be the fully licensed copy. The licence information should be copied and pasted from
the email into the FirM installer when requested.
5. Domino directories must be properly configured; the directory profile must be set up so that the domain
name matches the actual name of the domain that the directory serves. The following are required; each
domain to be managed, the filename and path of the directory (e.g. names.nsf) and the filename and path
of the AdminP database (e.g. admin4.nsf).

PAG E 1 2 O F 1 8 5 3 . I N S TA L L I N G F I R M
6. Access to the server console, either physical access or through a remote server management tool such as
PCAnywhere, VNC etc..
7. The certifier ID(s) for all hierarchies to be managed together with the password(s) for these certifiers.
Note that FirM does not currently support certifier IDs that have been set up to require multiple
passwords.
Stage 1: Encryption key creation

Note: New in v2.1.01, you may skip this step for evaluation installations only. This means that all certifiers,
passwords, and user ID’s you create will NOT be encrypted, thus lessening security. It does however mean that you
can skip this fairly time consuming step in order to get an evaluation copy of FirM up and running. Should you
choose to do this, you MUST install encryption keys before converting your license to a “full” license as FirM will
not permit unencrypted certificates and passwords during normal production running.
FirM uses three encryption keys to keep sensitive files and passwords secure.
The three keys are created in the server’s ID file and are subsequently imported into the administrator’s ID file.
N.B. Problems have been experienced when passing the keys between the ID files in the other direction due to
differing degrees of security in the two ID files. Please ensure that the encryption keys are created in the server’s
ID file and then imported into the administrator’s ID file.
These encryption keys are called:
● iDM Certificate Encryption Key
● iDM Password Encryption Key
● iDM ID Encryption Key
Creating the Keys

a) Take backup copies of the server’s and the administrator’s ID files and store these in a secure location.
b) Copy the server’s ID file to a location

accessible from the administrator’s Notes
client.
c) Using the administrator’s Notes Client,
switch to the server ID. You may get
warning messages saying that you are not
allowed to use a server ID to connect to a
Domino server, but this doesn’t matter –
you do not need to communicate with a
server at this stage.
d) From the menu choose ‘File, Security,User
Security…’
e) Enter password (if a server ID password
has been set...).
f) Click on the ‘Notes Data’ tab on the left, and then click on ‘Documents’.
g) Click on the ‘New Secret Key’ button at the bottom of the dialogue.
h) Name the key ‘iDM Certificate Encryption Key’. Enter the name without
quotes and retain capitalisation.
i) Choose an appropriate encryption type, e.g. North American, International,
ND6+, etc. (if the option is available). Enter a description for the key and
click ‘OK’.

j) With the key highlighted, click on the

‘Other Actions…’ button at the bottom
of the dialogue and select ‘Export Secret
Key…’.
k) Give the key a secure password in

accordance with your security guidelines
and procedures.
l) Save to a file on a removable disk or to a
network path accessible from the
administrator’s workstation.
m) Repeat steps 1h. to 1m. for the keys…
● ‘iDM ID Encryption Key’
● ‘iDM Password Encryption Key’
It is essential that the names of the keys match the above names exactly. FirM expects to find keys with these
names.
Note: existing iDM customers do NOT need to change the names of their existing encryption keys.
a) Switch back to the administrator’s ID and copy the server ID back to the server.
b) Restart the Domino server and ensure that it is possible to connect to it from the Notes client.
c) The newly created encryption keys must now be imported into the administrator’s ID.
d) On the administrator’s Notes client, select ‘File, Security, User Security…’,and click on the ‘Notes
Data’ tab on the left, and then click on ‘Documents’.
e) At the bottom of the dialogue click on ‘Other Actions…’ and select ‘Import Secret Key…’.
f) Navigate to the files containing the encryption keys and select the ‘iDM Certificate Encryption Key’, enter
the password for the secret encryption key, click ‘OK’ and then click ‘Accept’ in the Accept Secret
Encryption Key dialogue box.
g) Repeat steps 1s. and 1t. for the keys…
● ‘iDM ID Encryption Key’
● ‘iDM Password Encryption Key’
N.B. The encryption keys do not need to be distributed to users or administrators in order for them to operate
FirM. The only server IDs that require these encryption keys are the FirM primary (and optionally secondary)
processing servers. You should store these encryption keys securely in the same manner that you normally secure
certificate files.

Stage 2: Initial install of FirM

1. Extract the FirM installer file (firminstall.nsf) and
open it using the administrator’s Notes client.
(Note that this client needs to be v6.0.1 or
greater for the installation to succeed. This
version limitation does NOT apply to the Notes
clients who will ultimately use FirM). The first
page of the installation wizard dialogue is now
displayed.
● Click on the button to continue.
● If this is the first installation of FirM, select ‘Full

Product Install’. If upgrading from an existing
installation select ‘Product Update’.
● Confirm acceptance of the terms of

the Customer Software Licence to
continue.
● Enter the name of the FirM server.

This may be selected from the
address book using the drop-down.
Enter the name of the target
directory into which FirM should be
installed or accept the default
(recommended). If required, a
secondary server may be set up
during Stage 3 – Basic Configuration
of FirM.


● The databases required by FirM are
now created. Please note that a
green tick indicates that a required
database was found. A red cross
indicates that an existing database
with that name was not found and
that a new one will be created. It
does not indicate a failure in any way.
● Click on the button to

continue.
● Next, the group of users who

are to manage FirM must be
defined. These people will be
granted Manager Access to all
databases, and will be assigned
to the 'Administrator' role
allowing them access to the
FirM configuration screens.

continue.
● A check is now made to ensure

that the encryption keys have
been successfully installed into
the administrator’s ID file.

continue.
● Access control checks are now

made to the Domino directory
(names.nsf), the administration
database (Admin4.nsf) and the
certifier log database (certlog.nsf)
on the target server.

continue.
● Complete the licence
information fields. If upgrading,
these fields will be pre-
populated with values from the
existing installation. If this is a
new installation, the Company
Name, License Key and License
Data information may be found
in the License Confirmation
email you will have received from HADSL.
● Press ‘F9’ after completing the last field.
● Choose whether the databases should be signed using your current

Administration ID, or the ID of the server chosen in step 2.
● A summary of the installation settings is displayed.
● FirM templates and databases are

now created on the primary server
and icons are added to the
administrator's workspace. The
Install log will be written to the screen during the installation – the text will appear at the top of the
dialog and flow down the screen. The installation process takes between 5-15 minutes depending on your
network and workstation performance.
● N.B. Installation will fail if the

administrator's ID does not
contain the FirM encryption keys.
These should have been created
and imported during Stage 1 of
this installation.
● Once the installation is

complete, you will see the
following screen:

2. The installation process will generate a number of requests to sign databases with the server ID which, by
the time this point is reached, should have all completed successfully. If some requests are still pending
then their processing may be expedited by issuing the ‘tell adminp process all’ command at the server
console.
3. Where specific security standards require that databases be signed with a special development ID, this
must be carried out manually.
4. Configure the Access Control Lists for the FirM databases as required. Only FirM Administrators should
be members of the [Administrator] role.
5. Replicate a copy of the FirM Extended AdminP database to each Domino server that will host users
and/or applications managed by FirM.
During the installation phase, the primary processing server will be requested to sign the FirM Request Processor
database with the server's ID file. In many cases, the server will be listed in the Administration Execution Control
List (ECL). Should the server NOT be listed in the Domino Administration ECL, the FirM Request Processor
database may be signed with the normal ‘application signing’ ID file.
Later, the scheduled agents in the FirM Request Processor and, optionally, the FirMExtended AdminP databases will
be signed with an ID capable of running restricted agents.
Stage 3: Basic FirM Configuration.

FirM may now be configured by supplying it with some basic information about its operating environment.
Do the following from the administrator’s Notes client.
a) Create bookmarks to the FirM databases which reside on the server.
b) Ensure that default access to all FirM databases is either ‘No Access’, ‘Reader’, or ‘Author’ depending
upon FirM rollout and security requirements. Default access must not be set to ‘Manager’.
c) Open the ‘FirM Request Processor’ (firmrequestprocessor.nsf)
d) Click on the ‘Tools’ item in the left-hand pane, and then choose the ‘Config’ tab.
e) Click on ‘Edit the System Configuration’ and edit, if necessary, the following :

f) On the ‘Databases’ tab:

● In the ‘File Locations’ tab two temporary
directories must be specified. The first
temporary directory (Local Temporary
Directory) is located on the
administrator’s workstation and is used
during initial set-up and when certifiers
are imported in to FirM. The second
temporary directory (Server’s Temporary
Directory) is located on the server, is
used to run scheduled agents and is required for the normal operation of FirM.
● These directories must be created manually.
● The contents of the fields on the other tabs within the Databases tab will have been automatically
populated by the installer.
g) ‘Servers’ tab:
● The ‘Primary server’ field must contain
the fully qualified name of the FirM
Domino server.
● The ‘Secondary server’ field should be left
blank until the correct configuration and
operation of FirM has been confirmed.
Once FirM has been installed and is
working correctly, return to this field and
specify a secondary server if increased system resilience is required.
● Accept the default value for ‘Secondary Server Delay’ (5 minutes).
h) ‘Directories’ tab:
● Use the ‘Add Entries’ button to add the
directories to be managed by FirM. Each
directory (names.nsf) should have both an
Admin4 database (admin4.nsf) and a ‘Deny
Access’ group specified for that domain.
● Note that the installer creates the first ‘default’ directory entry
but cannot at that stage define the terminations group used in
the environment. It is therefore important that the default
entry be edited post-installation to define a terminations group
for the primary environment.
● The ‘Edit Entries’ and ‘Remove Entries’ buttons can be used to
manage the directories list.

i) ‘Admin Settings’ tab:

● It is recommended that the default values in the fields on all three sub-tabs be used.
● On the ‘Misc Settings’ tab:
1. The default value of ‘No’ for ‘Disable UI request creation for non-administrators’ should be used.
This setting is used to disable the standard UI creation of requests in the situation where a bespoke
front-end has been implemented for FirM, and is beyond the scope of this administration manual.
2. The ‘Default FirM Administrator’ is used in conjunction with notification profiles to enable an
administrator, group of administrators or mail-in database to receive notifications. Default
administrators can also resubmit, cancel and ‘process now’ transactions.
3. The default value for ‘Automatic recertification’ of ‘Disabled’ should be used for initial installation.
j) ‘Billing’ tab:
● Billing information is only written to
the FirM Billing Repository database
when ‘Enable Billing’ is set to ‘Yes’.
● Select each request type to be
recorded in the Billing Repository
database.
k) ‘Name Validation’ tab:

● This tab allows the elements of both user
and group names to be comprehensively
defined.
● Under the ‘Group Names’ sub-tab the way in
which groups are split may be selected. The
options are to split a group when the group
exceeds 15KB in size or when a specified
number of group members is exceeded.
● Ensure that a subgroup separator character
is specified (‘_’ is suggested).
● ‘External Lookup’ tab:
● FirM supports the use of an external database which database that can be used to provide additional
keys and codes to ensure unique naming standards. The default setting of ‘No’ should be used as this
is an advanced option and setting up this database is beyond the scope of these installation
instructions.
l) ‘Workflow’ tab:
● Accept the default of 3 hours for ‘Notify
Every:’
● It is recommended that all days, i.e. Sunday
through to Saturday, arechecked in
‘Notification Window Days’

● Similarly, change the notification times to start at ‘1’ and

end at ‘23’.
m) ‘Archiving & Expiry’ tab:

● These settings control the archiving of
requests from the FirM Request
Processor to the FirM Archive
Repository database.
● The default values are usually
sufficient. Archiving may be enabled
at a later date.
n) ‘AD’ tab:
● Active Directory support may be enabled by clicking the ‘Yes’ radio button. A licence for Active
Directory support must have been purchased to enable this extension.
o) j. Click on the ‘Save & Close’ button

to save the changes.
Stage 4: FirM System Profiles Set Up

FirM system profiles are the building blocks of User Profiles upon which are based various User Requests.
Other profiles, such as Notification Profiles, enable the FirM Administrator to tailor FirM to suit the both the
organisation's management and its IT infrastructure.
Group Profiles, although categorised as System Profiles, describe FirM’s group creation and management
capabilities.
To create FirM ‘System Profiles’:

1) After opening the FirM Request Processor, click on ‘Tools’ in the
menu on the left-hand side of the screen.
2) First select the certifier to be used by clicking on the ‘Certifier

ID’ tab; then click on ‘Import a new Certifier’.
3) The ‘Add Certifier’ file-attach dialogue will be displayed. Select the certifier ID file to be imported. Type the
password for the certifier into the next dialogue and then reconfirm the password. Note: certifiers requiring
multiple passwords cannot be used with FirM.

4) Click on the ‘Profiles’ tab

5) Click on the ‘System Profiles’ sub-tab and perform the
following steps…
a) Click on ‘System Certifier Profiles’ radio button.
System Certifier Profiles contain information on how
to use the certifier in the ‘User Create’, ‘User Move’
and ‘User Rename’ transactions. Do the following:
● Click on ‘Create a new Profile’.
● Enter a name for the Certifier Profile. This name should be

meaningful to Requesters as it is used to distinguish between
different Certifier Profiles. Normally the name is the same as
the certifier’s hierarchy.
● Select the imported certifier to use from the Certifier
Hierarchy list.
● In the ‘Fields’ tab, static and dynamic fields may be specified. Static fields enable the value of a field to be
set to a pre-determined value in the target document. Dynamic fields allow the contents of a field to be
defined by the Requester when creating a user based on this profile. For example, when a user is created
the ‘TelNumber’ field would be set to the user’s supplied telephone number. A static field is set with the
same information every time a request is processed which uses this profile. For example, the
‘OfficeLocation’ field always set to ‘London’.
● In the ‘Default Groups’ box, specify the groups to which a User Created with this profile should be
added. All settings on this tab are optional.
● Entries in the ‘Keys’ tab should not be changed.
● Click on ‘Save’ to save this profile, or ‘Close’ to close the dialogue without saving.
b) Repeat these steps for all the certifiers to be used by FirM.
6) To create a profile for the Company, click on the ‘System Company Profiles’ radio button and do the following:
a) Click on ‘Create a new Profile’
b) Give the company profile a name, typically the name of your
organisation.
c) Specify the Static and Dynamic field settings and default groups,
as necessary.
d) Click on ‘Save’ or ‘Close’.
7) To create a location profile, click on ‘System Location Profiles’
radio button and do the following:
a) Click on ‘Create a new Profile’.
b) Give the new location a name that is meaningful in the
business context such as ‘London’ or ‘New York’ or
‘Edinburgh 5th floor’.
c) In ‘Target Mail Servers’ define the primary mail server for
users created with this profile. If more than one server is
specified, FirM will automatically load balance and create new
users on the server with the fewest users, based upon the
‘Server\Mail Users’ view in the Domino Directory.
d) Note that this location can share servers with other
locations.

e) Static and dynamic field settings and default groups can be specified if necessary.
f) Click on ‘Save’ or ‘Close’.
g) Repeat these steps for as many locations as necessary.
8) System ID Profiles specify the type of ID to be generated in a given user request. To create an ID profile, click
on the ‘System ID Profiles’ radio button and do the following:
a) Click on ‘Create a new Profile‘
b) System ID profiles allow for the comprehensive specification of
IDs; for instance, International or North American, the
recertification period, whether a mail file should be created, etc..
Note that the mail template name refers to the actual file name
of the Domino template which must exist on the server. It is
possible to specify different classes of user ID with this profile type – e.g. ‘Staff’, ‘Contractors’, ‘and
Functional Ids’, etc..
c) Static and dynamic field settings and default groups can be specified if necessary.
d) Click on ‘Save’ or ‘Close’.
e) Repeat these steps for as many ID Types as necessary.
9) System Business Group Profiles are optional.
10) System Country Profiles are optional.
11) System Agent Trigger Profiles are not relevant during this initial set-up of FirM.
12) System Notification Profiles. At each step of the process of executing a transaction, an admin-defined
notification email may be sent. A default set of notification profiles is supplied with FirM and these may be
changed as necessary. A tag language enables different parts of the request to be inserted into the message;
for instance, the name of the requested user ID.
Stage 5: FirM User Profiles Set Up

FirM User Profiles tie together all the other profiles in the
system enabling the creation of a very specific request. Such a
specific request might be, for example, a request to generate a
‘Contractor ID’ in the ‘ACME‘ certification hierarchy for a
‘Leeds office-based’ user. A profile is created for every type
of request used in the organisation, thus constraining users to
ID file requests that are correct and complete.
1. Click on the ‘Tools’ entry in the menu on the left-

hand side of the screen. Select the ‘User Profiles’
sub-tab.
2. Click on the ‘User Create profiles’ radio button and perform the following steps:
 Click on ‘Create a new Profile’
 Give the profile a meaningful name (e.g.
‘London Staff User’)
 In the Fields and Groups tab specify static and dynamic field settings and default groups as
necessary.

● Next, click on the ‘Names & Domains’ tab.

● In the ‘Domino Naming’ tab, use the drop-down
list to select the Notes Domain in which this user
will be created. The ‘Notes Name’ and ‘Notes
Short Name’ fields will be pre-populated with
elements from FirM’s tag language. The tag
language enables the construction of a user’s
Notes name, Internet mail address and mail file
name so that they comply with corporate naming
standards.
● In the 'Optional OU' tab, select whether or not

this profile should have Optional OU hierarchy
support.
● In the ‘Internet Naming’ tab, use the tag language

keywords to construct the user’s Internet email
address. The keyword <INTERNETDOMAIN>
takes its value from the Internet domain selected
in the ‘Internet Domain’ box.
● The ‘Mail File Naming’ tab allows you to specify

the construction of the user’s mail file and the
cluster mail file name if the user is clustered.

● The ‘Sub-Profiles’ tab allows the selection of all the

elements that determine a specific user ID. If
more than one sub-profile is selected within a
section then the user will be prompted for the
appropriate sub-profile to use at the point of
request creation. If only one sub-profile is selected
for a section then no prompt will appear for the
user.
● The ‘ID’ tab allows the selection of the ID profile

that will be applied to the creation of this type of
user.
● The ‘Locations’ tab allows for the selection of a

choice of one or more Location profiles to be
used for this particular type of ID. If more than
one Location profile is selected the Requester will
be prompted to choose between them at the point
of request creation.
● The ‘Certifiers’, ‘Companies’, ‘Countries’ and

‘Business Groups’ tabs similarly allow for the
selection of a relevant pre-defined profile for this
type of ID request.
● The ‘ID & Password’ sub tab allows the recipients

of any newly generated user ID and password pairs
to be defined.
● The Authorisation tab enables the definition of

those users (Requesters) who are permitted to
create new users with this profile. Specify either
individual names, or the names of multi-purpose
groups from the address book.
● The ‘Authorisers’ sub-tab enables the definition of

those users who will authorise the creation of new
users made with this User Create profile. If a
Requester should not authorise their own request,
provide the name of an alternative Authoriser. It is
common to find that the LocalDomainAdmins
group is used for the Authorisers field.

● In the ‘Notification’ tab specify the names of users

or groups who should receive a notification
whenever an ID is created using this profile. This
is especially useful where there are security
considerations for certain certification hierarchies.
● Click on ‘Save’.
● Repeat these steps for as many user creation
profiles needed.
3. Similar profiles must be created for each type of user request that FirM is able to process. For example,
User Modify, User Delete, User Disable etc..
In profiles other than the ‘create’ profiles an additional sub-tab will be found in the Authorisers tab – the ‘Users
Managed by this Profile’ tab. This should contain a name mask, such as ‘*/ACME’, thereby restricting who can be
deleted, renamed, etc., using this profile.
Stage 6: FirM Group Profiles Set Up

Group profiles define the type of the group created thus ensuring that users of FirM do not have to understand the
difference between different types of groups, e.g. a Mail Group, an ACL group or a Multi-Purpose group.
Membership of the group may be restricted. For example, a Group profile called ‘Confidential Internal Emails’
would disallow the addition of any Internet email addresses.
Workflow can also be set up - for instance, restrictions can be placed upon who can submit group create requests,
who can authorise them and who is notified. The Group Profiles define what actions can be done for each type of
group that FirM can manage, what its allowed content is, what the name of the group should be and who can
submit requests to create these groups.
1. Click on the ‘Tools’ entry in the menu on the left hand side of the screen. The control panel screen should
open and default to the ‘Profiles’ tab. Select ‘System Profiles’.
2. Click on ‘System Group Profiles’ radio button entry and perform the following steps:
● Click on ‘Create A Profile’
● Give the profile a name, e.g. ‘ACME Mail Group’
● Select the type of group – e.g. ‘Mail Group’
● Select foreign Dir Sync setting.
● In the Membership tab specify whether each type of group

content is allowed or not allowed to be a member. Valid
Notes users are always allowed to be members of a group.
● In the Name tab, the mask for the group name is created. If a
group is not to be given an Internet address when it is
created then the Internet Address field should be left blank.
The tag ‘<GROUPNAMEUSERELEMENT>’ will be replaced
with the user’s descriptive element of the group name.
● The final three tabs are ‘Request’, ‘Authorise’ and ‘Notify’.
These fields need to be populated with the names of people
who are able to request and authorise the creation of a group.
The rights for modification, deletion and management are
governed by the group’s entry in the database ‘FirM Group
Register’.
● The Notification tab allows the person to be specified who
will be notified when a request progresses through the workflow for the creation, management or
modification of a group created with this profile.
● Click on ‘Save’ or ‘Close’.

3. Repeat for as many different types of group profiles as are necessary. It is possible and perfectly normal to
have more than one type of profile for each group type. This is useful when different naming conventions
must be enforced for, say,a global mailing group as opposed to a regional mailing group, and to assign the
authority to create each of these group types to different people or groups of people.
4. At a minimum there must be a profile defined for each of the basic Domino group types Mail Group, ACL
Group, Multipurpose group, Server Group and Terminations (Deny only) group.
Stage 7: Group Import Utility
In order for a group to be managed with FirM it must have an entry in the FirM Group Registry. This entry contains
information about the group such as which profile it will use, which domain it belongs to, and who are the Owners
and Administrators of this group.
The roles of Owner and Administrator are described in the FirM Help database, but broadly an Owner is a person
who is able to modify the group’s list of owners and administrators, manage the content of the group, and request
the group’s deletion. An Administrator is a person who is only able to manage the content of the group.
A typical Domino installation will have many groups in each Domino
Directory, and the import utility is used to create Group Registry
entries for each of these groups. The tool is run from the FirM
Request Processor, and is accessed from the ‘Tools’ button under
‘Import Group(s)’.
1. Click on the ‘Tools’ entry in the menu on the left-hand side
of the screen.
2. Click on ‘Import’ tab, and ‘group’ sub-tab.
● Click on ‘Import Groups’
● You will be presented with a dialog with
instructions. Click on 'Forward' to continue.
● Select whether a single group, a selection of

groups or all groups of a type in the
directory should be imported.
● Select the Directory/Domain from which
the group/groups is/are to be imported.

● Select whether the groups are to be

imported straight into a ‘Live’ state (i.e. can
be managed from FirM without further
intervention) or into a ‘Draft’ state, in
which case the groups must be manually
moved to Live from within the Group
Registry.
● It is possible to import spanned groups into

FirM as a hierarchy. In order to do this the
spanned groups must follow the naming
convention of
[parent group name][separator
character][number of subgroup]
● Also, the parent group must contain only
the names of subgroups. FirM will honour
the existing separator characters and will
add and remove users from subgroups in
this hierarchy.
● The settings in the ‘Ownership’ tab allow
default entries for group owners and
administrators to be specified. The values
contained in these fields will be added as an
owner and administrator (respectively) to
each group imported with the utility.
● Assign which group profiles should be set

for each type of group imported:
● Finally, click on ‘OK’ and the groups will be

imported.
3. If groups have been imported into a Draft status, open the FirM Group Registry, navigate to the Draft
Groups view, and once the group entry is confirmed to be correct, select the group from the view, and use
the ‘Tools’, ‘Flag selected groups as Live’ action to mark the group as live for management.
4. This operation must be carried out for every directory that contains groups that are to be managed.

Stage 8: Agent Enablement

This stage in setting up FirM for use is to enable the processing and workflow agent. This part of the operation
must be carried out using an ID which is allowed to run ‘Restricted and System’ operations on scheduled agents on
any of the Domino servers.
1. Open the FirM Request Processor and select the 'Tools' menu from the left hand side. When the control
panel appears, select the 'Monitor’ tab, then the ‘Scheduled Agents' tab.
2. Click on the ‘Refresh Agent

Status’ button.
1. On the 'Process
Requests and Workflow'
agent line, click on the
server name, and select
the correct processing
server for FirM. Then
click on the traffic light
on the left hand column
to enable the agent.
2. On the 'Ext AdminP'
agent line, click on the
server name, and set the
processing server to a
single asterisk ( * ). This
means that this agent will
run on every server
where this database is
replicated to. Then click
on the traffic light on the
left-hand column to
enable the agent.
Stage 9: Access Control on FirM Databases

The following FirM databases are accessed by the users during normal operation, and require access to these
databases. This is usually achieved by creating a group called “firmRequesters” within Domino, and adding all FirM
users to this group.
Database Title Database filename ACL Level

Request Processor Database FirmRequestProcessor.nsf Author+Create Document
Group Registry Database FirmGroupRegister.nsf Reader
Help file FirmHelp.nsf Reader
Log File FirmLog.nsf Author+Create Document
This step should be performed before users are allowed access to FirM.

Stage 10: Replicate FirM to the rest of the Domino Environment

The final stage in setting up FirM for use to replicate it to all relevant servers.
1. Replicate the following FirM Databases to all servers (and any intermediate replication servers) where
users will access the FirM Request Processor:
1. The FirM Request Processor (firmrequestprocessor.nsf)
2. The FirM Group Registry (firmgroupregistry.nsf)
3. The FirM Help File (firmhelp.nsf)
4. The FirM Log Database (firmlog.nsf):
2. Replicate the following FirM Databases to all servers (and any intermediate replication servers) where
users and/or applications are to be managed by FirM:
1. the FirM Extended AdminP Request Processor (firmextendedadminp.nsf)
FirM is now installed, configured and ready to be used to create and process user and group management requests.
Note that if you replicate FirM to other domains in your environment, you should add ACL groups to the
databases mentioned above in order to allow inter-domain replication. Wehave deliberately left out the
'OtherDomainServers' ACL entry in order to improve default security. You should use the Admin client to set the
relevant groups for your environment in each database appropriately.
Normal Operation:Creating Requests

1. Open the FirM Request Processor database.
2. The default view is the ‘All Requests’ view. This shows all requests by status. Click on the ‘New Request’
button.
3. A dialogue is displayed allowing the type of request to be chosen. The list of requests to chose from are
those where you are named as a Requester in the relevant user or group profile.

PAG E 3 0 O F 1 8 5 4 . I M P O RT I N G C E RT I F I E R S & PA S S WO R D S
4. Importing Certifiers & Passwords

FirM requires that certifiers are imported into the FirM Certificate repository. Administrators can perform this
procedure by opening the FirM Request Processor, clicking on the ‘Tools’ button, and selecting the ‘Import’ Tab,
then the ‘Certifier’ tab:
The certifier file to import must now be

specified. Using the file dialog box, select the
certifier file.
The Certifier password is then validated. Two
prompts will appear.
If the two passwords match, the certifier and password is imported into FirM.
During this process, the ID file provided is checked to ensure that it is a certifier file,
and its certifier hierarchy is extracted. FirM then checks to see if these already exist in
the FirM certifier repository and the FirM Password repository. If they do, the old
versions may be overwritten with the new versions if desired.
The Certifier has now been imported into the FirM Certifier repository.

5 . S YS T E M C O N F I G U R AT I O N PAG E 3 1 O F 1 8 5
5. System Configuration
Target Audience
This section is intended for use by the FirM Administrator.
Introduction
The System Configuration dialog box contains all system-wide configuration settings for FirM. The users never see
this dialog – only the FirM Administrators. This is usually set up at FirM installation time, and is not normally
updated.
To navigate to the System Configuration Pane, click on the Tools option,followed by the “Config” tab.
Then click on ‘Edit the System Configuration’
System Configuration – Databases
● In the ‘File Locations’ tab two temporary directories must be specified. The first temporary directory
(Local Temporary Directory) is located on the administrator’s workstation and is used during initial set-up
and when certifiers are imported in to FirM. The second temporary directory (Server’s Temporary
Directory) is located on the server, is used to run scheduled agents and is required for the normal
operation of FirM.
● These directories will temporarily contain items such as certifier IDs, user IDs etc.. It is important that
these directories are not accessible to users. These directories must be created manually. Should these
directories not exist, then the normal ‘temp’ directory defined on the operating system will be used.
● On a Unix-based system (such as Linux, AIX, Solaris,HP/UX for instance), the directory should be
specified in the form ‘/tmp/’, using forward slashes to separate directories. On a Windows-based system,
the directory should be specified in the form ‘c:\temp\’ where a drive letter followed by a colon and the
backslash character is used to separate directories.
● The contents of the fields on the other tabs have been automatically populated by the installer. These
values should be changed only if the databases have been renamed or moved.

PAG E 3 2 O F 1 8 5 5 . S YS T E M C O N F I G U R AT I O N
System Configuration - Servers

● The ‘Primary server’ field must
contain the fully qualified name
of the FirM Domino server.
● The ‘Secondary server’ field
should be left blank until the
correct configuration and
operation of FirM has been
confirmed. Once FirM has been
installed and is working correctly,
return to this field and specify a secondary server if increased system resilience is required.
● Accept the default value for ‘Secondary Server Delay’ (30 minutes).
● The secondary server delay value is critical. The secondary server will wait until a request is this number
of minutes ‘old’ before attempting to process it. Should the primary and secondary servers be clustered,
then this value can be as low as thirty minutes. Should the primary and secondary server just rely on
scheduled replication, then this figure should be at least three times the replication period defined
between these two servers for this database.
If this value is too low, then both servers will attempt to process requests, resulting in replication conflicts and at
worst, instances where executing the transaction twice would result in duplicate entries – for instance User
Create, group create, etc..
We recommend that two program documents be created in your directory to support this configuration.
● One program document should run on your primary server, and have the command “rep
<secondaryServer> <firmDirectory”>, and schedule type of “startup”
● The second program document should run on your secondary server, and have the command “rep
<primaryServer> <firmDirectory”>, and schedule type of “startup”
This ensures that the FirM directory is immediately replicated should a server be down for any reason, and
prevents requests being processed twice.
System Configuration - Directories

This pane shows a list of all Lotus
Domino domains managed by FirM. Each
domain requires:
● the name of the directory database
● the name of the Lotus Domino
domain
● the name of the administration database (the admin4.nsf or AdminP database)
● The name of the terminations group relevant to that domain.
Domains can be added, edited or removed by clicking on the relevant button at the bottom of the list.
Use the ‘Add Entries’ button to add the directories to be managed by FirM. Each directory (names.nsf) should
have both an Admin4 database (admin4.nsf) and a ‘Deny Access’ group specified for that domain.

● Note that the installer creates the first ‘default’ directory entry
but cannot at that stage define the terminations group used in
the environment. It is therefore important that the default
entry be edited post-installation to define a terminations group
for the primary environment.
● If more than one domain is to be managed, then the directory
and the admin4.nsf database should be replicated on a
scheduled basis from the other domains onto the primary (and
secondary server, if defined). The other domains’ directory and
administrative databases can then be added to this list of
domains to be added.
It is important that if more than one domain is to be managed,
that each domain has a unique domain identifier set in the
directory profile in each directory database. This can be
updated by:
● Opening the directory database
● Clicking on the Actions menu, and then ‘Edit Directory Profile’
● Editing or updating the ‘Domain defined by this directory’ field.
● The ‘Edit Entries’ and ‘Remove Entries’ buttons can be used to manage the directories list.
System Configuration – Admin Settings

● The debug level will initially be set to ‘4. Very Detailed’. This will generate
a large amount of logging and debugging information which is of use during
the initial configuration phase of FirM. During normal operation, this value
should be set to ‘3. Detailed’ in order to provide more manageable levels of
logging and debugging information.
● The ‘Logging Destination’ allows default Notes output to be logged, that is,
the status line in the client, as well as the FirM log database. The default
Notes output is only recommended during the initial configuration phase
and should not be enabled during normal production use as it displays a large amount of information on
the Notes client status line, which might be confusing.
It is recommended that logging and debugging information is written to the FirM log database.
● The “Number of days” option controls the log database expiration agent.
● “Log File Mail-In Address”. The FirM Extended AdminP processor can now eMail in detailed log reports to
the main FirM log. Create a mail-in database document in your main directory which points at your FirM
Log on your main processing server, and use that address in this dialog.
● “Should Clients Mail In their log documents”. This switches the client log mode from directly writing to
the FirmLog.nsf database, and rather uses the mail-in address defined above. This has a direct performance
gain, as the client no longer has to open the log database, and of course this means that the Log database
need not be replicated to all servers – it need only reside on the Primary and Secondary Processing
servers.
Other server processes that create log documents will use the mail address if it is defined, unless the
other servers are the primary or secondary processing servers.
● The default value of ‘No’ for

‘Disable UI request creation for
non-administrators’ should be
used. This setting is used to
disable the standard UI creation
of requests in the situation
where a bespoke front-end has
been implemented for FirM, and
is beyond the scope of this
administration manual.

● The ‘Default FirM Administrator’ is used in conjunction with notification profiles to enable an
administrator, group of administrators or mail-in database to receive notifications. Default administrators
can also cancel requests.
● The default value for ‘Automatic recertification’ of ‘Disabled’ should be used for initial installation.
● If you wish to monitor groups, enable the Group Changes Monitoring. This will then allow the selection of
groups in the Group Registry for monitoring. Should any monitored groups be changed, the changes are
noted and communicated to selected users.
● Allows the definition of a
rich-text footer which will be
appended to all notification
messages generated by FirM.
This can be used to add
graphics, as well as a standard
footer explaining to the user
that this is a system-
generated email message.
● The Application Monitor tab allows

the setup and configuration of the
Application Monitoring suite.
● The Web Interface allows you

to quickly and easily turn off the
ability for the web interface to
allow new transactions to be
produced. This means that the
web interface can only view existing transactions.
● The “MailFile Quota Tab” allows the

administrator to set “bands” for user
MailFile Quotas.
● The administrator should define up

to five band “names”, and the Mail
File Quota figures to should increase
from top to bottom. The last figure -
for “unlimited” - should be set to
zero.
If you do not wish to use a particular
band, leave its name blank.

● The”Allow Extended AdminP to Update Person Documents” flag defaults to “No”. If this is set to “Yes”, and
the “Check Mail Users MailFile Quota” agent in the Extended AdminP database is set to process, there will be
a large initial update to every person document in the environment. See the section titled “User MailFile
Quota Management” on Page 166 for more information before setting this flag.
● If the flag “Allow Extended AdminP to Update Person Documents” is set, then the administrator should
define fields on the person document that will be used to hold User Quota Management information. Note
that these fields need NOT be added to the “Person” form in order to make these fields visible.
● “If a user does not have a MailFile quota Set” allows the administrator to define how users without existing
bands are set. It is recommended that the setting “Set to level above users current MailFile size” is used in the
first instance, as this allows mail file quotas to be set without initially locking users from their mail files.
System Configuration – Billing
● Billing information is only

written to the FirM Billing
Repository database when
‘Enable Billing’ is set to ‘Yes’.
● Select each request type to be
recorded in the Billing
Repository database.
● It is recommended that the
‘Write Billing Records for sub
transactions’ be set to ‘No’. In
most billing circumstances, only
the initial or main transaction is
relevant for billing purposes. For instance, should a User Create transaction be created, its four or more
sub transactions (send User ID, Create Replica Mail file, etch) are of little value from a billing perspective.
● The field ‘For Groups’ should be set to the individual relevant for group transactions; that is the owner of
the group, or the person who requests the group change.
System Configuration – Name Validation
● This tab defines which name

uniqueness checks are to be
performed during FirM operation:
● ‘Full Name Uniqueness’. This
checks the entire Lotus Notes
name of an object. For instance,
‘Joe Bloggs/HADSL’ would be
compared against ‘Joe
Bloggs/Acme’. It is recommended that this value is checked.
● ’Internet Address Uniqueness’. This checks that each object has a unique internet address defined.
For instance, Joe.Bloggs@hadsl.com would be compared against Joe.Bloggs@acme.com. It is
recommended that this value is checked.
● ‘Short Name Uniqueness’. This checks that each object has a unique Lotus notes ‘shortname’. For
instance, ‘JBloggs’ would be compared against ‘JBloggs’ (and found to be non-unique). It is
recommended that this value is checked.
● ‘Common Name Uniqueness’. This checks the user’s common name field of an object. For instance,
‘Joe Bloggs’ from ‘Joe Bloggs/HADSL’ would be compared against ‘Joe Bloggs’ from ‘Joe Bloggs/Acme’
and found to be non-unique.
It is recommended that this value is checked as this allows the consolidation of all internet domains
to one domain, and still preserves address uniqueness.

‘Name Validation’tab, ‘First Name’, 'Middle Initials' and 'Last Name' subtabs:
● Is required – check this box if this name field is required.
● Minimum Length – this defines the minimum length (in characters)
allowed for a first name in your environment.
● Maximum Length – this defines the maximum length (in characters)
allowed for a first name in your environment.
● Allow Non-ASCII – checking this box allows characters other than A-Z,
a-z in this name field.
● Allow Numbers – checking this box allows number characters 0-9 in this
name field.
● Allow Underscores – this allows the underscore character ‘_’ to be
used in this name field.
● Allow Hyphens – this allows the hyphen character ‘-’ to be used in this
name field.
● Allow Punctuations – this allows punctuation characters such as ‘;’, ‘,’ etc.
to be used in this name field.
● Allow Spaces – this allows the space character to be used in this field. This
could allow people with two words in their first name – for instance, ‘Jan
Willem’.
● Force Case. This forces this name field to be one of the following:
● No Change. No case changing is performed. For example if the
requester types in ‘jan williem’, it is left as ‘jan williem’
● All Lowercase. The name field is converted to lowercase. For
example if the requester types in ‘Jan Williem’, it is converted to
‘jan williem’
● All Uppercase. The name field is converted to uppercase. For
example if the requester types in ‘jan williem’, it is converted to
‘JAN WILLIEM’
● Propercase. The first letter of each word is made uppercase, and the
rest of the word made lowercase. For example if the requester types in
‘jan williem’, it is converted to ‘Jan Williem’
● Allowed Characters. This allows the definition of non-ASCII characters
allowed in name fields, without allowing every possible non-ASCII
character.

‘Name Validation’tab, ‘Group Name' subtab:

● Is required – check this box if this name field is
required.
● Minimum Length – this defines the minimum length (in
characters) allowed for a group name.
● Maximum Length – this defines the maximum length (in
characters) allowed for a group name.
● Allow Non-ASCII – checking this box allows characters
other than A-Z, a-z in this name field.
● Allow Numbers – checking this box allows number
characters 0-9 in this name field.
● Allow Underscores – this allows the underscore
character ‘_’ to be used in this name field.
● Allow Hyphens – this allows the hyphen character ‘-’ to be used in this name field.
● Allow Punctuations – this allows punctuation characters such as ‘;’, ‘,’ etc. to be used in this name field.
● Allow Spaces – this allows the space character to be used in this field. This could allow groups with two
words in their name; for instance, ‘Accounts Department’.
● Force Case. This forces this name field to be one of the following:
● No Change. No case changing is performed. For example if the requester types in ‘jan williem’, it is left as
‘jan williem’
● All Lowercase. The name field is converted to lowercase. For example, if the requester types in ‘Jan
Williem’, it is converted to ‘jan williem’
● All Uppercase. The name field is converted to uppercase. For example, if the requester types in ‘jan
williem’, it is converted to ‘JAN WILLIEM’
● Propercase. The first letter of each word is made uppercase, and the rest of the word made
lowercase. For example, if the requester types in ‘jan williem’, it is converted to ‘Jan Williem’
● Allowed Characters. This allows the definition of non-ASCII characters allowed in name fields, without
allowing every possible non-ASCII character
● Under the ‘Group Names’ sub-tab the way in which groups are split may be selected. The options are to
split a group when the group exceeds 15KB in size or when a specified number of group members is
exceeded.
● Ensure that a subgroup separator character is specified (‘_’ is suggested).

Name Validationtab, 'Mail In Database' subtab:

● Is required – check this box if this name field is
required.
● Minimum Length – this defines the minimum
length (in characters) allowed for a Mail-In
Database Name.
● Maximum Length – this defines the maximum
length (in characters) allowed for a Mail-In
Database Name.
● Allow Non-ASCII – checking this box allows
characters other than A-Z, a-z in this name
field.
● Allow Numbers – checking this box allows number characters 0-9 in this name field.
● Allow Underscores – this allows the underscore character ‘_’ to be used in this name field.
● Allow Hyphens – this allows the hyphen character ‘-’ to be used in this name field.
● Allow Punctuations – this allows punctuation characters such as ‘;’, ‘,’ etc. to be used in this name field.
● Allow Spaces – this allows the space character to be used in this field. This allows applications with more
than one word in their name; for instance, ‘Support Department Inbox’.
● Force Case. This forces the name field to be one of the following:
● No Change. No case changing is performed. For example if the requester types in ‘jan williem’, it is
left as ‘jan williem’
● All Lowercase. The name field is converted to lowercase. For example, if the requester types in ‘Jan
Williem’, it is converted to ‘jan williem’
● All Uppercase. The name field is converted to uppercase. For example, if the requester types in ‘jan
williem’, it is converted to ‘JAN WILLIEM’
● Propercase. The first letter of each word is made uppercase, and the rest of the word made lowercase.
For example, if the requester types in ‘jan williem’, it is converted to ‘Jan Williem’
● Allowed Characters. This allows the definition of non-ASCII characters allowed in name fields, without
allowing every possible non-ASCII character

Name ValidationTab, External Lookup Subtab
FirM supports the use of an external database

which can be used to provide additional keys
and codes to ensure unique naming standards.
● If the “Allow External Database
Lookups” is set to yes, then
● Choose one or more name
elements to compare. In this
case, we have only selected one – short name.
● Define the external database you wish to check.
● Define the view name which is sorted by the relevant comparison data.
● If an entry if found in this view matching our name field, then the test fails – FirM concludes that this name
element exists in this external database
System Configuration – Workflow

The workflow tab allows the definition of the frequency with which the workflow engine
emails notification messages to individuals involved in the authorisation of requests.
● Accept the default of 3 hours for ‘Notify Every:’
● It is recommended that only working days - i.e. Monday through to Friday, are
checked in ‘Notification Window Days’
● Similarly, change the notification times to start at ‘7’ and end at ‘18’, if 7am through
6pm is the normal working day. This prevents users seeing multiple notification
messages in their inbox first thing in the morning.
System Configuration – Archiving & Expiry

Controls the archive and expiry engine,
and dictates how long to wait before a
transaction is moved from the FirM
Request Processor to the transaction
archive, the FirM Archive Repository
database.
The default values are usually sufficient.
Archiving may be enabled at a later date.
The FirM archiving engine is driven by
the agent ‘Archive Old Requests’ and governed by the settings in this tab. The agent should be enabled to run on
the same server as the primary FirM request processing agent.
On each run cycle the agent looks at the current top-level requests in the FirM request processor and checks the
date of the last process that occurred on the request (and any sub-requests). It then looks at the status of the
request and compares the status to the list of expiry times that are set in this tab. These settings are specified in
days.
If the number of days that have passed since the time that the request was last processed exceed the number of
days specified for that particular request status then the request and all of its sub-requests are moved to the FirM
Request Archive repository. The location of the Archive Repository is defined in the ‘Archived Requests’ entry on
the ‘Databases, History’ tab of the configuration profile.
The request and all of its sub-requests will then be removed from the FirM Request Processor.
There are several status values that can have expiry periods set:
● DRAFT – this is the status of a request that has been added to the Request Processor but not yet
submitted. This status is not available from UI-created requests and will only occur if a request was
created from an external process using the FirM LotusScript API.
● COMPLETE – this is the setting for removing old requests that have fully completed their processing.

● REJECTED – these are requests where the Authoriser has declined the transaction.
● CANCELLED – requests that have been cancelled by the Requester, an Authoriser or the default FirM
administrator will be archived according to this setting.
● FAILED OR INVALID – requests that have failed processing or rejected due to broken signatures will be
archived according to this setting.
Requests that are awaiting processing, deferred or awaiting approval will never be archived.
FirM has the ability to create and monitor groups and users for auto-expiry. That is to say, that a date can be set
after which an automatic deletion workflow will remove them from the environment.
This facility is not currently available from the standard FirM UI and is only accessible from the FirM LotusScript
API – this facility may be accessible from the UI in a future release of FirM.
The three settings relating to the automatic expiry of users and groups should therefore be ignored in the standard
install of FirM and only changed under instruction of HADSL or one of its resellers.
System Configuration – Active Directory (AD)

● Active Directory support may
be enabled by clicking the ‘Yes’
radio button. A license for
Active Directory support must
have been purchased to enable
this extension. Note that Active
Directory transactions, profiles,
etc will not be visible until this
has been set to 'Yes.
● This radio-button enables the GUI support for various Active Directory tasks to become visible.
● Active Directory configuration and operation is outlined in the section - “Installing and Configuring FirM
Active Directory”.
System Configuration –
BlackBerry
● Blackberry Support can be

enabled by setting the radio
button to Yes. A license for
BlackBerry support must have
been purchased to enable this
extension. Note that BlackBerry
transactions, profiles, etc will not
be visible until this has been set to
'Yes.
● The BlackBerry Resource Kit Executable name has to be set. This means that the BlackBerry resource
toolkit must be installed on the same location on both the primary and secondary FirM processing
servers.
● On installing the BlackBerry Resource Toolkit, youwere prompted to generate a new password for
security purposes. Enter that password to FirM by clicking the “Password” button.
● List all of the BlackBerry Enterprise Server “BlackBerry” profiles that you wish to expose to FirM for
management. Note that at this point, it is not possible for FirM to automatically build that list, and so the
administrator must maintain this list manually.
● You must now visit each Location document and enter the servers which are running your BlackBerry
enterprise server software, in order that relevant locations are associated with zero or more BES servers.
See the entry “Location Profiles - BlackBerry servers tab” on page 52 for more information on this.
Once all system configuration has been completed, click on the ‘Save & Close’ button to save the changes.

6 . A D M I N I S T R AT I O N TO O L S PAG E 4 1 O F 1 8 5
6. Administration Tools
The Administration Tools panel is accessible only to FirM Administrators – people who have the ACL role
[Administrator] enabled. To access the administration tools, click on “Tools” on the left hand navigator in the FirM
Request Processing database.
The Administration Tools assist the administrator in the set-up, configuration and day to day running of the FirM
application.
Config Tab
The Config Tab enables the administrator to:
● View and edit the global system configuration. See the
section titled “System Configuration” on page 31 for
more information.
● Update the License key within FirM. This may be
necessary from time to time with new releases in
order to enable new transactions. To Update your
license key,
● Click on “Update the FirM License”
● Copy and paste the License key information
supplied to you by HADSL into the relevant
fields
● Click on “Update License.
Profiles Tab
The Profiles tab allows the administrator access to the FirM
profiles that define how each transaction should be processed.
● See the Section entitled “Configuring System Profiles”
on page 48 for more information on the system profile
tab
● See the section entitled “Configuring FirM User
Transactions” on page 94 for more information on the
User Profiles tab
● See the Section entitled “Configuring Application
Transactions” on page 119 for more information on the Application Profiles
● See the section entitled “Configuring AD Transactions” on page 136 for more information on the Active
Directory Profiles.
● See the section entitled “Configuring BlackBerry Transactions” on page 146 for more information on the
BlackBerry profiles.
Note that the Active Directory and BlackBerry profiles will only be visible if these options are switched on (and
you are properly licensed to use these transactions) within the System Configuration Screen. See the section titled
“System Configuration” and the sub-sections sections on Active Directory and Blackberry on page 40 for more
information.

PAG E 4 2 O F 1 8 5 6 . A D M I N I S T R AT I O N TO O L S
Monitor Tab
The Monitor tab assists the administrator in
viewing the current status of the FirM
processing environment.
Scheduled Agents sub-tab

The Scheduled Agents sub-tab shows all
scheduled agents within the FirM processing
environment. To viewtheir current status,
click on the “Refresh Agent Status” button.
Each agent can be controlled or changed:
● Click on the diamond shaped
coloured button to enable or disable
the agent. Green means the agent is
enabled, and red is not.
● Click on the green arrow beside the
agent to run the agent manually on
the server. This is not recommended
on a product environment – it may
cause performance bottlenecks – it
is however very useful whilst testing.
● Click on the Server name for each
agent to change the server, if
required.
Database Versions Sub-tab

This tab allows the administrator to quickly
establish the release version of all FirM databases
in his environment. Click on the “Check Db
Versions” button to refesh this page.
“Check Extended AdminP” tab

This tab allows the administrator to check the
status of all servers in the environment, and the
status of their Extended AdminP subsystems. Note
that Extended AdminP only runs once per 30
minutes, and of course runs on remote servers.
The “Last Run” time will reflect this time
difference, and of course any replication schedules
involved in replicating the status document back to
the Request Processor database.
If you have more than 10 servers in your
environment, click on the arrows on the right of
the screen to scroll the display up and down.
For more information on the Extended AdminP database, see the sub-section “Extended AdminP Processor” in the
“FirM Databases” section on page 173.
Import Tab
The Import tab is used to import various objects to the FirM
Environment.
● The Certifier ID sub-tab allows you to import new
Certifier ID's into the FirM processing system. See the
section entitled “Importing Certifiers and Passwords”
on page 30 for more information on this.
● The Server ID sub-tab allows you to import a Server

ID into the secure ID repository. FirM does not
manage servers and therefore will perform no
operation on the server ID files once they are
imported. It does however,give the administrator a
consistent ID repository for all his ID files.
● The CSV sub-tab allows the administrator to import

FirM transactions from a CSV (Comma Separated File).
See the section titled “Importing Transactions Using
CSV” on page 151 for more information.
● The Group sub-tab allows you to import groups from

your existing Notes environment into FirM in order
that they can be managed. See Stage 7 of the section
titled “Installing FirM” on page 26 for more
information.
'Group Restore' Tab

The Group Restore Tab allows the System Administrator to
restore a group that has been previously deleted by the FirM
Group Delete Request.
To restore a group, click on “Restore a group

previously deleted by FirM”. The following dialog will
appear.
Click on “Forward” to continue:

Click on the button and you will be prompted to

select a group.
Once you have selected the group you wish to

restore, then click Forward.
You will be asked to confirm or modify the list of

owners and administrators for this group. If this
group was deleted some time ago, it is entirely
possible that some of the people named in this list
may no longer be valid.
Update the relevant entries and click on “Forward”.
You may now be prompted for an expiry date for

this group, if it was deleted during the expiry
process.
Select a new expiry date, and click “Forward”.
Click on the “Recover Group” button to recreate

this group in the directory.

BlackBerry Management Tab

The BlackBerry management tab is only visible if the BlackBerry feature has been enabled in the System
Configuration document. See the sub-section “System Configuration - BlackBerry” in the “System Configuration”
section on page 40 for more information.
This tab shows a number of internal views that FirM requires to manage BlackBerry users.
BlackBerryUsers sub-tab
The BlackBerry Users sub-tab allows you to view all
BlackBerry handset users that FirM has detected within the
BackBerry Enterprise servers defined within System Location
Profile documents.
If you click on a user record, you see the following information:

● The Notes Name for this user
● The BES server responsible for this users BlackBerry
communcations
● The PIN number of the users BlackBerry device
● The database name of the users “state” database on the BES
server
● The date that this user account was first activated on the BES server.
You should not manually edit any of this information, as it is pro grammatically gathered from each BES server.
BlackBerryServers sub-tab
The BlackBerry Servers sub-tab shows all BlackBerry servers
defined in location documents within the FirM environment.
BlackBerryusers by Server sub-tab.

This sub-tab shows BlackBerry handset users, categorised by
the BES server responsible for their communication.

System Views Tab

The System Views tab contains views that FirM requires for its operation. You should never change information
within this tab unless expressly instructed to do so by HADSL support.
System Variablessub-tab
The System Variables sub-tab shows internally
defined system variables used by FirM. These
variables are used to override default system
behaviours, and as such should not be changed
unless expressly instructed to do so.
If you open one of these variables, you can observe the variable name
and its value.
System Classes sub-tab

FirM is a data-driven, object orientated
application. This table helps FirM find where
pieces of code for each transaction are located,
and what they are called.
Static Fields sub-tab

Static Fields are defined within FirM, and linked
to internal code. They help expose internal
keywords (such as “<UserName>” for
instance) to the various “keyword” buttons on
the FirM Profiles. These static fields are then
replaced at run-time with relevant values.

Active Directory Static Field

Definitions
This tab shows keywords associated with
Active Directory objects. These keywords
show which object attributes may be amended
by FirM.
Active Directory DLL sub tab

This sub-tab allows you to view, install and
update the DLL required for Active Directory
operation.
This is discussed in the section titled “Installing

* Configuring the FirM Active Directory
Component” on page 123.
MSI Scripts sub tab

This sub tab allows you to view and manage
MSI (Microsoft Script Interface) Scripts which
are used during Active Directory Create User
operations.

PAG E 4 8 O F 1 8 5 7 . C O N F I G U R I N G S Y S T E M P RO F I L E S
7. Configuring System Profiles

All System Profiles are found by navigating
to the “Profiles, System Profiles” tab of
the “Tools” control pane in the FirM
Request processor databases.
Common System Profile Tab – “Fields”

Some System Profiles, as well as the User Create Profile, have a “Fields”
tab:
In this case, this is the “Fields” tab from the System ID Profile document.
If a Fields tab exists, this allows certain operations to be carried out on a
new user created using this profile:
Defining Fields
Fields. Define fields that are created on the new users Person document. For instance:
● OfficePhoneNumber=121-212-232-1212
o Will populate the field “OfficePhoneNumber” on the person document with the value “121-212-
232-1212”. This is useful for defining static information that is common for all users created using
this profile type.
 Owner,AUTHOR=LocalDomainAdmins
o This will create a field called “Owner”, set it as an Author field, and assign it the value
LocalDomainAdmins.
Permitted keywords for the Field directive are:

Keyword
SUMMARY Make this a Summary Field.
All fields are Summary by default – this need not be explicitly defined
AUTHORS Make this an Authors field
PROTECTED Make this a Protected field
NAMES Make this a names field
READERS Make this a readers field on the target document
SIGNED Make this a signed field
ENCRYPTED Make this field available for encryption on the target document.
Bear in mind that the document should also have a “secretEncryptionKeys” field
specifying the encryption key to be used, and that this key should be available on
both the server and the client. Making a field ENCRYPTED means that the field

7 . C O N F I G U R I N G S YS T E M P RO F I L E S PAG E 4 9 O F 1 8 5
cannot be used in view indexes.

NOTESDATETIME Make this a Notes Date/Time field
NUMBER Make this a number field instead of a string field
DELETEFIELD Delete this field from the document
Multiple keys can be specified. For instance:
Owner,READERS,PROTECTED,SIGNED=LocalDomainAdmins
Bear in mind that “Dynamic Fields” can also be defined.
Groups
Groups. Should one or more groups be added to this field, then all users created using this profile will be
automatically added to these groups.
ID Profiles
ID Type profiles are mandatory profiles used during a User Create
process. One or more of these profiles may be associated with a
particular User Create profile.
The profile has four tabs:
The details tab allows you to enter this ID profile name. It is recommended that you use Profile names that are
meaningful to your business, as these names may be visible and used for choices during User operations.
The Mail File details allow you to specify:

● Mail User: This should be set to ‘Yes’ if this user should have a
Notes mail file associated with their name. The following
options are then valid:
● Mail Template Database. Enter the name of the mail
template name (usually mail50.ntf for Notes v5, mail60.ntf
for Notes v6) to be used to create this user.
● Create a Full Text Index: Indicates whether afull text
index should be created for this user when their mail file
is created.
● ACL Level: In Domino 5, users’ ACL levels may be set in
their own mail file to Designer. This prevents them
changing the ACL at a future date. In Domino 6, you may
set their Mail File ACL entry to Editor.
● Mail Quota and Mail Threshold. These should be set to 0 if Domino is not to enforce a mail quota
for this user type. Otherwise the value represents the size in megabytes - for instance, 50 would set
the quota to 50MB. Note that the user’s mail file design elements are included in this figure -
typically 5MB. For instance, in the example of a 50MB mail quota, 5MB of that would be used by the
design, and therefore the user could only store 45MB of mail.
● Create Replica on all Cluster members: If the user is being
created on a mail server which has cluster mates, and this
parameter is set to ‘Yes’, then their mail file would also be
created on all other members of the cluster.
The “ID Type” tab allows you to define:

● User Type: Choose whether users created using this profile are
Notes users (and therefore have an ID file created for them) or
Web Users (where an ID is not created)

● Notes ID Type. Lotus Notes supports two Notes Client key lengths - 64 bit (International) and 128 bit
(Global or US).
● ID Validity in Days. Typically this would be measured in years (720+ days ) for full time staff, or in
hundreds of days for Contractors. Note that setting this value to a lower number means more
administrative work recertifying these people.
● Password Length. The length of password that FirM allocates these people when they are created.
● Minimum Password Length: The minimum length of password that these people have to use when they
choose a new password.
● Create HTTP Password: This should be set to ‘Yes’ to allow FirM to create their Internet (or ‘HTTP’)
password at the same time that the users are created.
● Password Change interval. This value is written to the new users’ Person document in the directory, and
dictates how often the new user should change their password.
● Grace Period. This allows the user to NOT change his password beyond his change interval – usually 14
days or so. Only after the password change interval AND the grace period have expired is the users
account locked by Domino.
● Password Digest Enable Profile. If a Password Digest Enable profile is selected here, then the User
Password Digest function is ran after a user is created, using the details defined in the selected profile.
● Roaming Profile. If a Roaming Enable profile is selected here, then the User Enable Roaming function is ran
after a user is created, using the details defined in the selected profile. (Note that Roaming User enable is
only relevant in Domino v6 or above)
● ID File Name. This field allows you to define how the users’ ID file is created.
● It should be noted that the user’s mail server is determined using their Location Profile.
Country Profiles
Country profiles are profiles used to help define country specific
information in the User Create and the User Move Location processes.
Zero, one or more of these profiles may be associated with a particular
User Create profile. You must, however, associateone Country profile
with each Location profile.
The first tab allows you to define the name of this country profile. Care must be taken to define profile names that
are meaningful for your business users – as the country profile names may be visible and offered as choices during
user transactions.
Certifier Profiles
Certifier profile documents contain information on how to use the
certifier within the User Create, User Move and User Rename
transactions.
There are three sets of information in the certifier profile document.
The detailed information tab:
The Textual Name field is used to distinguish certifier profiles to Requesters and should therefore have some form
of meaningful name that can be easily understood.
The Certifier Hierarchy field is picked directly from the Certifier Repository's list of certifiers and cannot be
edited. This ensures that this certifier profile always points at a valid certificate entry in the Certifier Repository.
This hierarchy field is also used to find the certifier password from the Password Repository.

Location Profiles
Location profiles are mandatory profiles used in the
User Create Process, and explicitly chosen in the User
Create profile document.
● ‘Name’ Field allows definition of this Location
profile. Care must be taken to define profile
names that are meaningful for your business
users – as the location profile names may be
visible and offered as choices during user
transactions.
● The ‘Target Mail Servers’ field contains a list
of one or more target mail servers relevant
for this location name. In the above example
there is one mail server named. This server
will be the one chosen for the user’s target
mail file.
If there is more than one mail server
explicitly named in this field, the load
balancing rule defined below will be used.
● If one or more servers are specified in the
Replica Mail Servers field then all users created using this profile will have replicas of their mail files
created on these servers.
● This location should be associated with a particular Country profile. This allows the User Move Location
transaction to calculate groups associated with Countries and Locations.
● The load balancing method for this method should be used. If there is more than one server to choose
from, FirM will use one of these rules to decide which server is most appropriate. The choices are::
1. Least Users. At the moment the new user is created, the directory will be queried to establish the
server with the fewest number of users.
2. Most Free Disk Space . At the moment a new user is created, the System Extended AdminP view
“Server Heartbeat” will be queried to establish which server has the most available free disk space.
3. Most Percentage Free Disk Space. At the moment a new user is created, the System Extended
AdminP view “Server Heartbeat” will be queried to establish which server has the most available
free disk space.
Location Profiles – 'Allowed Certifiers'tab.

This tab allows you to associate particular certifier
hierarchies with this location. Should your
environment not tightly bind certifier hierarchies with
Locations, do not select any certifier profiles.

Location Profiles – 'Active Directory Servers' Tab

This tab allows you to assign one or more Active
Directory file serves to this location. This is then used
by the Active Directory Create User transaction to
assign new users to File Servers.
Location Profiles – 'BlackBerryServers' tab

This tab allows you to define which BlackBerry
Enterprise server services this site. This information is
used during a BlackBerry Provision transaction.
If more than one BES server is defined, then FirM
allocatesthe next new person to the least loaded
BES server.
Business Group Profiles

Business group profiles are non-mandatory profiles used to help define
business group-specific information in the User Create process. Zero,
one or more of these profiles may be associated with a particular User
Create profile.
All of the fields on a business profile form are ‘standard’ fields - see ‘User Create Profiles - Standard Fields’ for
more information.
The general term ‘Business Group’ is used in place of terms such as ‘Division’, ‘Group’, or ‘Department’ as these
are company-specific terms.
‘Name’. Care must be taken to define profile names that are meaningful for your business users – as the Business
Group profile names may be visible and offered as choices during user transactions.
Company Profiles
Company profiles are non-mandatory profiles used to help define
country specific information in the User Create process. Zero, one or
more of these profiles may be associated with a particular User Create
profile.
‘Name’. Care must be taken to define profile names that are meaningful for your business users – as the Company
profile names may be visible and offered as choices during user transactions.
Internet Address Profiles

Internet Address profiles are non-mandatory profiles that enable you to
set up more complex management of the Internet Address field in users'
person documents, and additional Internet addresses that should be
assigned to new users.
They are used in the User Create process and are associated with User Create Profiles. The User Rename
process can also use Internet Address profiles, as it needs to recalculate users' Internet Addresses.
‘Name’. Care must be taken to define profile names that are meaningful for your users – as the Internet Address
profile names may be visible and offered as choices during user transactions.
‘Internet Domain‘. Enter the domain part of the Internet Address in this field, for instance “hadsl.com”. Do not
include “@” in this field.
‘Local-Part Construction‘. Enter the tags required for constructing the local part of the Internet Address in this
field. For instance, “<FIRSTNAME>.<LASTNAME>”. These tags will be replaced during request processing, when
the Internet Address is calculated.

Group Profiles
Group Profiles define the type of groups that users are allowed to create with FirM.
Group Profile – 'Details' Tab

Fields defined:
● Profile Name:
● Group Type:
● Foreign Directory Synchronization:
● Owner Approval:
● Initial Membership:
● Allow Group Creation in:
A group profile is set up for each distinct type of group. This does not necessarily correspond to the Domino
group types (ACL, Mail, etc.) as there can be many different profiles defined.
Certain restrictions can be placed upon group types, for instance the Domino group-type. This means that users of
FirM do not have to have technical knowledge about the difference between a Mail Group, an ACL group and a
Multi-Purpose group.
Allowed membership of the group can be restricted so that, for instance, SMTP addresses cannot be added to a
group that has been set up using a ‘Confidential Internal Emails’ profile.
Workflow can also be set up. For instance, restrictions can be placed upon who can submit group create requests,
who can authorise them and who is notified.
Group Profile – 'Name Mask' tab

Fields Defined:
● Group Name – this enables group names to be built up using
keyword tags. The part of the group that the user enters is
represented by the “<GROUPNAMEUSERELEMENT>” tag,
and this is used to construct the group name.
● Case Translation
● White space Removal
● Translation Order
The latter three fields define how the group name field should be
translated, and in what order.
Group Profile – 'Internet'tab

Fields Defined:
● Internet Address: This is the internet address that will be
assigned to the group. If an internet address should not be
assigned to a group then leave this field blank.

Group Profile ' Members' Tab

Masks Defined:
● SMTP Addresses: e.g. addresses of the format
“fred@hadsl.com”
● Notes/Domino Users: Users listed within a Domino
Directory
● Servers: Servers listed within a Domino Directory
● Mail-In Databases: Mail-in Databases listed within a Domino
Directory
● Mail Groups: Mail-only groups listed within a Domino
Directory
● ACL Groups: Access-Control list only groups within a Domino Directory
● Multi-Purpose groups: Multi-purpose groups within a Domino Directory
● Deny-Access Groups: Deny List Only groups within a Domino Directory
● Server Groups: Server Only groups within a Domino Directory
● Cross-Domain Membership: If this is set to “Deny” then groups and Notes users from only the group’s
domain will be permitted as members.
Group Profile ' Request' Tab

People listed in the “Create Group” field are allowed to request the
creation of groups of this type.
Group Profile – 'Authorise'Tab

Who can authorise the construction of groups using this profile.
Force Separate Authoriser – if this is set to “Yes” then an
authorisation is forced, i.e. a user cannot effect a group creation
without further authorisation by virtue of them being in both the
“Request” and “Authorise” lists.
Enable anyone to manage this group without authorisation: If this is
set to “Yes” then group membership management requests can be
submitted by anybody and will not require further approval. This
option enables you to create non-critical groups for ‘public’
membership – for instance contact lists for staff sports/social events.
Group Profile – 'Notify' tab

Notification: In common with other FirM profiles, you can specify who
should be notified upon successful completion of various requests
types against groups associated with this profile.

Automatic Recertification Profiles

Fields Defined:
● Profile Name
● Users Managed by this Profile. You may enter a “name mask”
such as “*/Acme”, or “*” in this field, or a list of user names, or
a list of group names.
● Recertification Profile. Choose the Recertification profile that
should be used for these users for this profile.
● ID Profile. This is used to calculate the expiry period of this
recertification event.
Automatically re-certify: Choose Yes for the Recertification Engine to

perform automatic recertification’s on these users.
Configuring Notification Profiles

Notification Profiles contain information required for FirM to construct email messages.
Notification messages are sent out by:
● The User Create process - this is the primary distribution method for sending out user ID files and user
passwords
● The back-end transaction processor - when agent or notification trigger points are reached.
● The back-end workflow processor - to inform people of authentication requirements or status.
Everything in a notification profile can be tailored by the administrator, i.e. the languageused, the formatting,
whether doclinks to the original requests are included, etc..
Fields Defined:
● Trigger Event - This is the transaction type. For
example, a User Create transaction.
● Trigger Name - This is a transactional stage. In
this case, a notification message is sent out at the
‘SendID’ stage of the User Create transaction.
● Principal - The name that appears in the ‘From’
field of the mail message that the user or
administrator receives, regardless of where this
agent runs. This is useful to demonstrate to
users that this email address is non-functional,
and should not be sent mail. It can also be used
to differentiate error messages from status
messages and from informational messages.
● Recipients - To, CC,BCC. In many cases, the
users receiving this message are set by the process. In the case of the UCR-SendID file notification, the
person to whom this message is sent is named in the transaction as the ‘ID Recipient’. The ‘To,CC, BCC’
fields can hold additional names of people who will also receive this message.
● Attach files: You may define files that are attached to the email message from the hard drive of the FirM
processing servers. (This feature may be more conveniently performed by attachingthe files within the
Rich Text footer – see below.
● Encrypt mail message - If this is set then only the Notes user(s) intended to get this message can read this
message. In the case of User ID files and passwords, it is strongly recommended that this is set to ‘Yes’.
● Keep Private: Switching this to “Prevent”.. ensures that the recipient of the notification cannot print,
forward nor copy the notification to the clipboard,

● View Icon Number: By selecting a view icon number, the notification is sent and a view icon displayed in
the recipient’s inbox. This is useful in differentiating system created mail messages or messages that
require urgent attention from other email messages.
● Subject line - Enter the subject line text that the
user receives, with optional tokens to be
replaced at run-time. For instance, during this
User Create transaction, the token ‘<firstname>‘
is replaced with the user’s first name, etc..
● Body Text - The text that appears in the body of
the mail message. Tokens may be included.
● Rich Text Footer.This allows rich text

(formatted text, graphics, tables, file attachments,
etc) to be appended to the bottom of this
particular notification profile. Note that you may
also append a rich text footer to the bottom of
ALL notification messages by defining one in the
Configuration Profile.
Configuring Agent Trigger Profiles

To trigger your own agents from any process within FirM,
● Navigate to the System Profiles configuration tab, and select
“System Agent Trigger Profiles.
● Click on “Create a new Profile”
● Select the transaction or “trigger” that you wish to act upon
● Select the trigger type – “Success” means that the transaction was successful.
● Enter the name of your database
● Enter the name of your agent.

8 . C R E AT I N G A N E W R E Q U E S T PAG E 5 7 O F 1 8 5
8. Creating a new Request

FirM allows you to create requests on a one-by-one basis, and allows the creation of multiple requests for
particular transactions.
Creating a single request

To create a single request:
Open the request processing database, and click on the “New

Request” button. A new frameset will open, allowing the requester
to create a request in the top pane, whilst still being able to see the
existing requests in the bottom pane.
A dialog box will appear, invitingyou to click on the

“Forward” button.
A “Checking security
settings” dialogue will appear for a few seconds. At this
point in time, FirM is establishing (by looking up all FirM
profiles) precisely which transactions this particular
requester may be able to see.
The requester will then need to select the type of

management request they want to create. This can be
done by selecting the option from the drop-down menu.
In this case, this particular requester may see

almost all of the request types, as this requester
is allowed to see one or more profile from each
transaction type, as well as being listed as the
owner or administrator of a number of groups.
The requester then chooses one request type,
and clicks on “Forward”.
At this point, the requester is led through the
construction of the selected transaction.

PAG E 5 8 O F 1 8 5 8 . C R E AT I N G A N E W R E Q U E S T
Creating Bulk requests

In order to create multiple requests of the same transaction type
(“Bulk Requests”), open the FirM request processor database, and
click on “New Bulk Request”
A dialogue box will appear inviting you to click on

“Forward”
At this point, the current requester’s security information is being evaluated.
The requester can then select a particular

transaction type. Not all transaction types are
available, as some transactions require more
information than a username to proceed.
(Note that all transaction types can be imported
from a CSV file. See the chapter entitled
“Importing transactions using CSV” on page 151).
The requester may now select one or more names to perform the selected transaction
on. In this case, the requester has chosen to select a number of names from the address
book.
All of the names entered are then validated against the directory to ensure that they
exist. The list of Accepted and Rejected users is now shown.

8 . C R E AT I N G A N E W R E Q U E S T PAG E 5 9 O F 1 8 5
The requester may now be prompted for a profile name for this particular
transaction. In this case, the requester has been prompted for a “Delete
User” profile name.
Depending on the profile, the requester may be prompted to defer this

transaction.
The transaction is now performed against all selected users and a status for each
selected user is displayed.

PAG E 6 0 O F 1 8 5 9 . F I R M D O M I N O U S E R T R A N S AC T I O N S E X P L A I N E D
9. FirM Domino User Transactions Explained

User Create
User create allows a Requester to create a user in a FirM-registered Domino Directory.
Details relating to the notification of completion of this transaction are stored in the User Create profile
documents.
Walkthroughof transaction
To create new request, select“New Request” and click forward to the
request selection dialog. Now select ‘User Create’.
The requester may be prompted for the name of a user create profile.
Select one and click “Forward”
Enter the following name information:

● First name
● Middle initials
● Last name
● Shortname (optional, based on Profile)
Each of these three name values is compared against validation rules in the System Configuration profile. If the
names pass validation rules, then the Domino Directories are checked for uniqueness. If any name fails, the
Requester is informed and invited to re-enter them. Click forward to go to the next screen.
In order for the requester to enter “ShortName” instead of FirM computing the shortname, the User Create
profile must allow the requester to enter the ShortName.
If the user create profile has been configured to prompt the requester
for the ID and Password information, then the Requester is then invited
to enter the names of:
● One or more people who are to receive an encrypted email
message containing the user’s Notes ID file. This is typically an
IT support person who then performs the Notes client installation for that user.
● One or more people who are to receive an encrypted mail message containing the user’s password. This
is typically the new user’s immediate manager.
In this case, UCR has been configured to send the user ID and password back to the requester. Click forward to go
to the next screen.
Depending on the settings in the User Create Profile, the requester may
be asked to enter the name of an Optional OU to add to the users
name. In this case, the requester is given the choice of a limited number
of Optional OU's to add.
If the User Create Profile option “Allow Optional Groups” is set to

“Yes”, then the requester is given the opportunity to select groups from
the directories. The new user will then be added to these groups.

9 . F I R M D O M I N O U S E R T R A N S AC T I O N S E X P L A I N E D PAG E 6 1 O F 1 8 5
If the UCR profile has been configured to allow processing at a later

date, the ‘Defer Processing’ dialog box will appear.
Click forward to go to the next screen.
Depending on the settings in the User Create profile, the Requester may
be prompted for one or more pieces of ‘dynamic’ data, which will then
be used to update the new user’s ‘person’ document in the Domino
Directory.
Click on the “Tick” mark on each piece of Dynamic Data.
Details of the User Create request are displayed. Clicking Submit

submits this request for processing by FirM.
FirM Processing
The Requester of the transaction will be compared against the
Requester and Administrators fields in the User Create profile. (See
“User Create Profile” on Page 96). If the Requester is not allowed to
submit this request then it will fail.
Processing will check that all relevant information is present in the request. If vital information is missing (this
should not be possible) then the request will fail, detailing the reasons for failure in the FirM log and also in the
request.
The processor makes exhaustive checks to ensure that the user names requested (Notes Full Name, Short name,
Internet Name and common name - all are configurable in the System Configuration Profile) are unique across all
domains managed by FirM.
The Requester then constructs the user ID in the home FirM directory (irrespective of target domain) - and then
moves that record to the correct domain. (This is a notes limitation). Any static or dynamic ‘fields’ specified in the
User Create profile, or any of the six system Profiles (ID, Location,Certifier, Company, Country or Business Unit)
is also applied, replacing ‘tokens’ with run-time variables as necessary.
The user’s Notes ID (if requested by the ID profile) and the user’s initial password are stored in the encrypted
User ID repository and the Password Repository.
A UUP (Resend User ID and Password) request is constructed which will mail the user’s Notes ID (if created) and
their password to the ID and Password recipients listed in the initial request.
Zero or more group manage member requests are created to add the user to groups specified in the User Create
profile, and any of the six system profiles (ID, Location, Certifier, Company, Country or Business Unit) is also
applied, replacing ‘tokens’ with run-time variables as necessary
Using the User Create profile, the correct Location profile is examined to establish the target server. If more than
one target mail server is listed, the target server with the fewest users (according to the Domino Directory) is
used as the target server (load balancing).
The users’ primary replica mail file path is then constructed, together with the cluster mail file if this has been
specified. Otherwise the cluster mail file name will be the same as the primary replica mail file path.
An Admin4 request is then issued to create the user’s primary replica database:
● On the correct target server

● Using the template name, quota and trigger level specified in the ID profile
● Adding the user's name to the mail file ACL at the level specified in the ID profile.
If a cluster replica mail file/s is/are specified in the ID profile, and the server is part of a Domino cluster (again,
established from the Domino directory), then an Extended AdminP request is constructed, which:
● Replicates to the user’s primary mail server, and waits until the user’s mail file has been created by AdminP
● Creates one or more AdminP requests creating the mail file replica on the other cluster mates as
governed by AdminP
Once processing has completed then any people specified within the Notification list for the relevant group profile
will be sent an email telling them that the group has been created.
If the System ID profile dictates Roaming and/or Password digest operations, sub transactions will be created to
perform these tasks.
The request will remain in the state ‘Pending Sub transaction’ until the AdminP requests and the Extended AdminP
Requests have completed. It will then progress to ‘Complete’.
As with all FirM requests, logging information at every stage is created in the Log Database, Audit trail records are
created in the Audit Database, and Billing information is created in the Billing Database.
A welcome message (defined in System Notification profiles, with a name of “UCR-Welcome” will be mailed to the
user.
Configurationfor User Create

FirM searches for the User Create profile that governs the creation of a user. The following information in this
profile is relevant to the User Create request:
● Who is allowed to request new users be created using this profile
● Who is allowed to authorise requests using this profile
● Who will be notified upon deletion of this group
One or more of the following mandatory Profiles:

● ID Profile. This provides details of how the user ID, mail file and clustering should be set up
● Certifier Profile. This gives details of the user’s certification hierarchy
● Location Profile. This gives details of one or more target mail servers where the user should be created.
Note if more than one target server is created, then the server with the least number of users will be
utilised (Automatic Load Balancing). In addition, if this server is in a Domino Cluster, and the ID profile
dictates that there should be a replica of the user’s mail file created on cluster mates, then FirM will create
‘Cluster Replica’ requests to facilitate this.
And zero or more of the following non-mandatory profiles
● Company
● Country
● Business Group
● Internet Address
Name Construction Information
● Notes Name
● Internet Name
● Mail Database Name
● Cluster Database Name
● Internet Name
● Notes Domain Name

Internet Address Profiles

The FirM User Create process can be set to use one of two methods for assigning Internet mail addresses to users
- “Simple Internet Address” and “Internet Address Profiles”.
The Simple Internet Address method calculates a single mail address for the user and sets the new user's Internet
Address field in their person document. This is useful if your organisation has only a single Internet domain for
mail addressing.
If, however,you have multiple Internet mail domains then Internet Address profiles allow much more flexibility in
assigning these addresses to users. See “User Create Profile” on Page 96 for more details.

User Modify
Allows a user to modify details on a person record in a FirM-registered Domino Directory.
Details relating to the notification of completion of this transaction are stored in the User Modification profile.
To create a new request, select ‘NewRequest’, ‘User Modify’.
Should the requester be allowed to see more than one type of User
Modify profile, they are prompted for the profile to use.
Click Forward to go to the next screen.
Select the user that you wish to modify from a normal ‘address’ selection
dialog. This means that you can select any user from any domain.
A number of screens (dependent on the ‘fields’ setting in the user

modification profile) are presented, one question per screen. Enter the
information requested, and click on ‘Forward’
Details of the user modification request that is being submitted are

displayed on the screen. Clicking Submit will submit this request for
processing by FirM.
FirM Processing
The Requester of the transaction will be compared against the list of valid Requesters defined in the User
Modification profile document. If the Requester is not allowed to submit this request then it will fail. A similar
check is performed against the Authoriser of the request.
request.
The processor then updates the person document identified in the request with the information entered by the
user.
Once processing has completed then any people specified within the Notification list defined in the User
Modification profile will be sent an email telling them that the group has been created.

User Disable
The User Disable transaction allows a requester to disable a user in a FirM-registered Domino Directory. The user
is disabled by adding their name to the relevant “terminations” group in the Domino Directory.
Details relating to the notification of completion of this transaction are stored in the User Disable Profile.
To create new request, select‘New Request”, ‘User Disable’.
The requester may be asked to choose which profile should be used for
this transaction, should the requester have the choice of two or more.
Select a user to disable, and click Forward to go to the next screen.
Details of the User Disable request that is being submitted are displayed
on the screen. Clicking Submit will submit this request for processing by
FirM.
FirM Processing
The Requester of the transaction will be compared against the User
Disable Profile Requesters and Administrators field. If the Requester is
not allowed to submit this request then it will fail.
Processing will check that all relevant information is present in the
request. If vital information is missing (this should not be possible) then
the request will fail, detailing the reasons for failure in the FirM log and also in the request.
The processor will now add the user to the deny-access group defined in the System Settings - Directories tab.
Once processing has completed then any people specified within the Notification list for the relevant User Disable
Profile will be sent an email telling them that the request has succeeded.
Configurationfor User Disable

FirM searches for the User Disable Profile that governs the behaviour of this transaction. The following
information in this profile is relevant to this request.
 Who is allowed to request transactions of this type
 Who is allowed to authorise transactions of this type
 Which group of users this transaction can be applied to
 Who will be notified upon transaction success

User Enable
Allows a user to request a user to be enabled in a FirM-registered Domino Directory. The user is enabled by
removing their name from the relevant “terminations” group in the Domino Directory.
Details relating to the notification of completion of this transaction are stored in the User Enable Profile.
To create a new request, select ‘NewRequest’, ‘User Enable’.
Select the user you wish to delete. Since the user is selected using a
standard addressing dialog box, you may not be allowed to manage this
user. Your authority to manage this user is calculated using the User
Enable Profile setting: ‘Name Mask’. If you cannot manage this user, you
will be prompted to select another.
Details of the User Enable request that is being submitted are displayed
on the screen. Clicking Submit will submit this request for processing by
FirM.
FirM Processing
The Requester of the transaction will be compared against the User Enable Profile Requesters and Administrators
field. If the Requester is not allowed to submit this request then it will fail.
request.
The processor will now add the user from the deny-access group defined in the System Settings - Directories tab
for the user’s domain.
Once processing has completed then any people specified within the Notification list for the relevant User Enable
profile will be sent an email telling them that the request has succeeded.
Configurationfor User Enable

FirM searches for the User Enable Profile that governs the behaviour of this transaction. The following information
in this profile is relevant to this request.
● Who is allowed to request transactions of this type
● Who is allowed to authorise transactions of this type
● Which group of users this transaction can be applied to

● Who will be notified upon transaction success
User Delete
The User Delete transaction allows Requester to request deletion of a user in a FirM-registered Domino
Directory.
Details relating to the notification of completion of this transaction are stored in the User Delete Profile
To create a new request, select ‘NewRequest’, ‘User Delete’.
The requester may be asked to choose which profile should be used
for this transaction, should the requester have the choice of two or
more.
Select the user you wish to delete. Since the user is selected using a
Delete Profile setting: ‘Name Mask’. If you cannot delete this user, you
Select the date on which this user account should be terminated.

Optionally (using the setting in the User Delete Profile) you may be
prompted for a Data Owner for the deleted user’s mail file.
Click Forward to go to the next screen
Details of the User Delete request that is being submitted is displayed

on the screen. Clicking Submit will submit this request for processing
by FirM.
FirM Processing
Requesters and Authorisers in the User Delete Profile. If the
Requester is not allowed to submit this request then it will fail.
the request will fail, detailing the reasons for failure in the FirM log and
also in the request.
Initial processingphase – immediate

The list of groups that this user is a member of is enumerated, and listed to the UDE request.
A ‘Disable User’ request is immediate processed for this user, using the Disable User Profile name defined in the
User Delete Profile.
This in turn generates a Group Manage Members sub-transaction, which then places the user name in the relevant
deny-access group (defined by domain membership in the System Configuration Directories pane).
If the profile option to hide the person document with readerfields has been enabled, then a readers field will be
created on the person document and populated with the list of usernames provided in the profile. This will
prevent the person from appearing in mail addressing and other name dialogs.

If a ‘data owner’ has been defined, the data owner is informed that he has access to the user’s mail file. A mail
message is sent using the notification profile UDE-DDONotify.
A ‘System ACL’ Extended AdminP Process is spawned to grant the Data Owner access to the user’s mailfile. The
ACL entry is by default set to ‘READER’.
The ACL for the user’s mailfile will be updated in order to change the ACL level for the DDO.
A ‘class variable’ called ‘DDOACLLevel’ allows you to set different Data Owner ACL Levels. In order to change
this, edit the class definition for the UDE, go to the ‘Class Settings’ tab on the class definition, and ensure that in
the ‘Class Settings’ section, you create a new line with:
‘DDOACLLevel=<ACLLEVEL>‘,where <ACLLEVEL> is replaced with one of:
● Depositor
● Reader
● Author
● Editor
● Designer
● Manager
(See the section “System Variables Sub-tab” on page 46)
If a ‘data owner’ has been defined:
● The transaction will defer itself for 30 minutes, and wait until the ‘System ACL’ Extended AdminP
transaction is complete, and has been replicated back to the FirM processing server. It will keep repeating
this check until the ‘System ACL’ request is complete.
● Once the transaction is complete, FirM will then retrieve the users mail file database replica ID from the
ACL request, and use it to populate the ‘<DBLINKBYUNID’ token on the UDE-DDONotify mail message,
in order that the data owner can then click on a database link to open the users mailfile.
The transaction then ‘defers’ itself to the supplied Deletion Day. On or after 1 minute past midnight on that day, it
will then proceed to the next stage.
If the deletion date is today (that is, the user is to be immediately deleted) the transaction defers itself for 30
minutes to allow time for the UDI operation to complete.
Deletion Day process

On the day that the user should be deleted, the transaction wakes up from ‘deferred’ mode again. It checks to see
if the UDE profile allows the ‘archiving’ of the user’s mail file.
Deletion Day Process – Non Archiving flow.

The process flow for non-archiving UDEs is quite different from those that allow archiving. The non-archiving
process is described:
● The user’s person document is backed up to the deleted names register.
● The person’s document is copied to the audit log.
● The user’s status in the ID and Password repository is set to ‘deleted’.
● An AdminP request is generated to remove
● this user from the Directory
● this user from All ACL’s
● this user from All names fields
● the user’s mail files. (if set in the UDE profile document)

Note that the AdminP request – A type ‘0’ – ‘Delete User in Directory’ spawns these other requests, including the
‘Approve Mail File Deletion’ request (Type ‘22’). This means that the Domino Administrator has to approve the
removal of the user’s mail databases in the AdminP database before they will physically be removed.

Deletion Day Process –Archivingmail file process

When we enable the ‘archiving’ of the user’s mail file in the UDE profile document, we are telling FirM that instead
of removing the user’s mail file from all servers, we wish that a replica of the user’s mailfile be placed on a
particular server (defined in the UDE profile) and in a particular directory (again, defined in the UDE profile).
In this process flow, the user person document has to be completely removed from the directory before the mail
file can be archived – AdminP will then convert this ‘move replica’ request to a ‘move mailfile replica’ request. This
of course may fail as the user is no longer in the directory, or the user is not allowed to place databases on the
archive server.
This process flow has to manage the timing of these AdminP requests.
The UDE process flow looks like:
● The user’s person document is backed up to the deleted names register.
● The person’s document is copied to the audit log.
● The user’s status in the ID and Password repository is set to ‘deleted’.
An AdminP request is generated to remove
● this user from The Directory
● this user from All ACL’s
● this user from All names fields
Note that the user’s mail files are NOT explicitly removed by AdminP at this stage.
The UDE transaction is then ‘deferred’ or put to sleep for 30 minutes.
The UDE transaction awakens, and checks to see if the person document still exists in the directory. If so, it defers
itself for another 30 minutes, and returns to this point to re-check that the user has been removed.
At this stage, since the user name is no longer in the directory, an extended AdminP request (‘SYSMBD’ or System
Move Database) is created.
This in turn creates an extended AdminP document in the Extended AdminP database
The document is replicated to the user’s HOME mail server.
The System Extended AdminP Agent ‘ServerAgent’ picks up this document, and creates a new AdminP request
(Type ‘14’ – ‘Move Replica’) in the server’s Admin4.nsf database. It uses the user’s primary mail file as the source
server and database, the archive server as the target server, and places the user’s mail file into the defined Archive
directory, using the full source path of the user’s mail file.
For instance, if the user’s mail file was called ‘mail/user1.nsf’, and the archive directory was defined as ‘Archive’,
then the mail file will be moved to target directory ‘Archive/mail/user1.nsf’’.
It then marks this extended AdminP request as complete.
AdminP then processes this new AdminP request. This is done in various stages, generating:
● Initially the Type 14 – Move Replica
● A type 25 – Monitor Replica Stub
● then a Type 15 – ‘delete original replica after Move’. This means that the AdminP process itself removes
the user’s primary mailfile ONLY when it is satisfied that the replication process has been successful
between the user’s home server and the archive server.
Now UDE creates a ‘SYSDBDEL’ transaction. It examines the UDE profile ‘delete user’s mail file’ setting. If this is
set to ‘just delete the user’s mail file’, (‘0’) or set to ‘don’t delete the user’s mail file’ (‘1’) then no SYSDBDEL
transaction is created. Otherwise, if the profile setting is set to ‘Delete user’s mail file and all replicas’, then a
SYSDBDEL sub-transaction is created. This:
● Creates an Extended AdminP transaction, which in turn creates a new document in the Extended AdminP
Database, with a transaction type of ‘(SYSDBDEL)’.
● This is then replicated to the user’s home server.
The Extended AdminP ServerAgent then picks up this document and:

● Works out which other servers are in the same cluster as this server.
● For each other server in the cluster, it generates a (SYSDBDEL) transaction, passing the database replica
ID of the user’s mail file.
● It then marks this transaction as complete, and terminates.
Note that this mechanism is NOT used to remove the user’s primary mail file from the cluster, as its entirely
possible that the AdminP process to ‘archive’ this mail file might still be in operation. It is left up to the AdminP
process to remove the primary mail file once the archive process has completed.
The new (SYSDBDEL) ExAmp transactions then replicate to the cluster mates of the user’s home server.
Each cluster mate picks up the ExAmp (SYSDBDEL) transaction. If it finds a replica of the user’s mailfile (by path
or by replicaID), it then generates a (SYSDBDEL2) EXAMP transaction, destined for the AdminP administration
server for the domain. This is defined as the server listed as the administration server of the Domino directory for
this domain.
The (SYSDBDEL2) transactions are then replicated to the Administration server for the domain.
The administration server Extended AdminP process then picks up these (SYSDBDEL2) transactions, and forms
type ‘21’ ‘Delete Mail file’ AdminP transactions for each of the replicas found on the cluster mates. Note that no
authorisation is required within AdminP for these transactions to continue (unlike the non-archive process flow
listed above).
AdminP then replicates back to the servers containing the user’s mail file, and removes those databases.
At this point, the UDE itself is complete. Note that it may take some time for the ExAmp and AdminP transactions
themselves to complete – perhaps four or five replication cycles. The UDE transaction itself sets itself to ‘awaiting
sub transactions’ and awaits the SYSMBD and SYSDBDEL transactions to complete.
Configurationfor User Delete

FirM searches for the User Delete Profile that governs the behaviour of this transaction. The following information
in this profile is relevant to the User Delete request:
● The name of the Disable User Profile to be used
● Can a Data Owner be defined for this profile
● Should the user’s mail file be removed at the end of the deletion process?
Should the user’s primary mail file be ‘archived’ to an archive server instead of being removed?

User HTTP password reset

Allows a requester to reset a user’s HTTP (or “Internet”) password.
To create a new request, select ‘NewRequest’, ‘Reset HTTP password”.
Select a user whom you wish to reset their password.

Enter a new HTTP password for this user:

A default new password is generated, which the requester may override.
Note that the password strength is checked and that the requester may
be prompted to enter a new password if the one entered is not strong
enough. The password strength is set on the transaction profile
document.
Details of the Reset User HTTP Password request that is being

submitted is displayed on the screen. Clicking Submit will submit this
request for processing by FirM.

User Move Server

Allows a Requester to request that a user be moved from his home server to a new Domino server in a FirM-
registered Domino Directory.
Details relating to the notification of completion of this transaction are stored in the User Move Server Profile.
Please note that the User Move Server transaction calls the Domino “Move Mail User” transaction, and therefore
shares the same capabilities as this function. In particular, the Domino “Move Mail User” transaction will not move
a user via a “passthrough server” connection.
To create a new request, select ‘User MoveServer’.
Select the user you wish to move. Since the user is selected using a
Move Server Profile setting: ‘Name Mask’. If you cannot manage this
user, you will be prompted to select another.
You will be prompted for:
● The Target server you wish this user to move to. You must
choose a server object from the Notes directory, and you
cannot choose the user’s existing server.
● The name of the user’s mail file on that server.
Details of the User Move Server request that is being submitted are
processing by FirM.
FirM Processing
The Requester of the transaction will be compared against the User
Move Server Profile Requesters and Administrators field. If the
The processor will now initiate an AdminP request to move this user from their existing server to a new server,
and optionally rename their mail file database name.
Once processing has completed then any people specified within the Notification list for the relevant User Enable
Profile will be sent an email telling them that the request has succeeded.
The request will remain in the state ‘Pending Sub transaction’ until the AdminP request has completed. It will then
progress to ‘Complete’.
Configurationfor User Move Server

FirM searches for the User Move Server Profile that governs the behaviour of this transaction. The following
information in this profile is relevant to this request.
● Who is allowed to request, and authorise transactions of this type
● Who will be notified upon transaction success.

User Move in Hierarchy

Allows a Requester to move a user in certifier hierarchy in a FirM-registered Domino Directory.
Details relating to the notification of completion of this transaction are stored in the User Move in Hierarchy
Profile.
To create new request, select‘User Move in Hierarchy.
Select the user you wish to Move in Hierarchy. Since the user is selected
using a standard addressing dialog box, you may not be allowed to
manage this user. Your authority to manage this user is calculated using
the User Move in Hierarchy Profile setting: ‘Name Mask’. If you cannot
manage this user, you will be prompted to select another.
Select the new Hierarchy - based on a list of all possible hierarchies.
Details of the User Move in Hierarchy request that is being submitted is

processing by FirM.
FirM Processing
Requesters and Authorisers in the User Move in Hierarchy Profile. If the
request. An AdminP Request is then spawned requesting that the user be available for Move in Hierarchy
This request is then immediately accepted by the ‘target’ certifier.
The AdminP Process then confirms with the user that they accept this Move in Hierarchy.
If they answer ‘Yes’, then the user's IDis updated, and their name changed using normal AdminP Processes.

Should there be any groups defined in the users source and target Certifier profile document, then the user will be
removed from the groups defined in the source Certifier Profile document, and added to the groups defined in the
Target Certifier Profile.
Configurationfor User Move in Hierarchy

FirM searches for the Move in Hierarchy Profile that governs the behaviour of this transaction. The following
information in this profile is relevant to the User Move in Hierarchy request:
● Who will be notified upon transaction success?

User Move Location

User Move Location allows a requester to move a user:
● To a new Location.Each system Location profile defines one or more servers which are responsible for
that location. If the users existing mail server does NOT service the new location, then a User Move
Server transaction is initiated.
● To a new certifier. If the user’s certifier profile is NOT allowed in the new location, the requester is
prompted for a new certification hierarchy, and a User Movein Hierarchy request is initiated.
● If groups are defined in the source and target location profile documents, then the user is removed from
the groups in his current location, and added to the groups in his new location. (Note that if a group is
defined in both, no action is performed).
● Locations (in v2.1.01 are now linked to system Country Profiles. If the change in location means a change
in country, then the user is removed from the groups defined in his current Country profile, and added to
groups defined in his new Country profile. (If the same group is defined in both Country profiles, then no
action is performed)
Details relating to the notification of completion of this transaction are stored in the User Move Location Profile.
To create new request, select‘User Move Location’.
this transaction, should the requester have the choice of two or more
profiles.
Select the user you wish to Move Location. Since the user is selected
using a standard addressing dialog box, you may not be allowed to
manage this user. Your authority to manage this user is calculated using
the User Move Location Profile setting: ‘Name Mask’. If you cannot
manage this user, you will be prompted to select another.
FirM will try and establish what the user’s current location is, by using
the users home server. If there is more than one location corresponding
to this user’s home server, youwill be asked to choose a relevant
Current Location.
Based on the User Move Location Profile, you may have the choice of
one or more target Locations to move this user to. In this case, the user
can choose from more than one target Location.
If the users current Hierarchy is not allowed in the new Location, you
will be prompted (using a list of all allowed hierarchies for the new
Location) for a new Hierarchy

Details of the User Move Location request that is being submitted is

processing by FirM.
FirM Processing
Requesters and Authorizers in the User Move Location Profile. If the
If the users change in location means a change in server, then a User Move Server transaction is initiated.
If the users change in location means a change in notes name hierarchy, then a User Move in Hierarchy transaction
is initiated.
The user is removed from his current Location (and Country groups, if this change in location means a change in
Country), and added to his new Location and Country groups.
Configurationfor User Move Location

FirM searches for the User Move Location Profile that governs the behaviour of this transaction. The following
information in this profile is relevant to the User Move in Hierarchy request:
● Who is allowed to authorize transactions of this type
● Who will be notified upon transaction success?
● Which locations are valid locations to move users from
● Which locations are valid locations to move users to

User Rename Common Name

This transaction allows a Requester to rename a target user’s common name
in a FirM-registered Domino Directory.
Details relating to the notification of completion of this transaction are stored
in the User Rename Common Name Profile.
Create new request, select ‘User Rename Common Name’.
The requester may be asked to choose which profile should be used for this
transaction, should the requester have the choice of two or more.
Select the user you wish to rename. Note that this presents a standard
address selection dialogue box. When you select a user, the selection is
confirmed as a user record, and the current Requester is confirmed as
being allowed (authorisation is granted in the User Rename Common
Name Profile document) to rename this user. Otherwise, the Requester
is warned, and invited to select another user.
The users current name elements are displayed, and can be edited.
Details of the User Rename Common Name request that is being
submitted are displayed on the screen. Clicking Submit will submit this
FirM Processing
The Requester and Authoriser of the transaction will be compared
against the User Rename Common Name Profile document. If the
The processor will now initiate an AdminP Request which will:
● Invite the user to accept their rename request (if the user is
running the Notes v5 client. The Notes v6 client automatically
accepts name change requests by default)
● If the user accepts, the user record is then updated via AdminP
● The request will now complete. The AdminP database should be monitored for a successful completion of
the AdminP request.
Configurationfor User Rename

FirM searches for the User Rename Common Name Profile that governs the behaviour of this request. The
following information in this profile is relevant to the User Rename Common Name request:
● Which User Enable profile should be used in the case where the user's new name is found in one of the
Deny Access lists
● Which ID Profile should be used in order to recalculate the ID expiry date for the renamed user
● Which User Create profile should be used to recalculate the user's Internet address
● Who can request this action

● Who can authorise this action

● Who will be notified upon success
● Which group of users can be renamed using this profile?

User Recertify
This transaction allows a Requester to recertify a user in a FirM-registered Domino Directory.
Details relating to the notification of completion of this transaction are
stored in the User Recertify Profile.
To create new request, select‘New Request’, ‘User Recertify’.
Select the user you wish to recertify. Since the user is selected using a
Recertify Profile setting: ‘Name Mask’. If you cannot delete this user, you
Details of the User Move in Hierarchy request that is being submitted is

processing by FirM.
FirM Processing
Requesters and Authorisers in the User Recertify Profile. If the
An AdminP Request is then spawned requesting that the user be recertified, with the expiry time dictated by the
relevant ID profile selected in the User Recertify Profile.
The user's ID is updated, and their public key updated to show the new expiry date using normal AdminP
Processes.
Configurationsettings User Recertify

FirM searches for the User Recertify Profile that governs the behaviour of this transaction. The following
information in this profile is relevant to the User Recertify request:
● What ID profile is associated with this user Recertification (and therefore dictating how long the user ID
is recertified for)

User Resend User ID and Password

This transaction allows a user to re-send (from the ID repository and password repository) the last set of user IDs
and passwords for a particular user defined in an FirM-registered Domino Directory.
Details relating to the notification of completion of this transaction are stored in the User Resend ID and
Password Profile.
To create a new request, select ‘NewRequest’, ‘User Resend User ID
and Password’
The user is then prompted for the users’ names who will receive the
user ID, and which users will receive the Password. Both are mailed out
in encrypted form.
Details of the User Resend User ID and Password request that is being
FirM Processing
The Requester of the transaction will be compared against the list of
valid Requesters defined in the User Resend ID and Password Profile
document. If the Requester is not allowed to submit this request then it
will fail. A similar check is performed against the Authoriser of the
request.
request. If vital information is missing (this should not be possible) then the request will fail, detailing the reasons
for failure in the FirM log and also in the request.
The processor then find the user ID and Password stored in the User ID repository and Password repository for
this user. If these cannot be found, the request will fail.
Two mail messages (using ‘notification’ profile documents UUP-SendID and UUP-Send Password) are constructed,
the information attached, encrypted and sent.

Once processing has completed then any people specified within the Notification list defined in the User Resend
ID and Password Profile will be sent an email telling them that the request has succeeded.
Configurationfor User Resend ID

The following information in the selected User Resend ID and Password Profile is relevant to the User Resend
User ID and Password
● Which Requesters can submit requests of this type
● Which Authorisers are allowed to approve these requests
● Who shall be notified of a successful completion of this request
● Which fields on the person document can be modified by this request, and how the user is prompted for
this information
● Which group of users (by organisational hierarchical structure) that this request can be applied against)

User Password Digest Enable

The User Password Digest Enable transaction allows a requester to enable the Domino “Password Digest” facility
for a user.
Details relating to the notification of completion of this transaction are stored in the User Password Digest Enable
Profile.
To create a new request, select ‘NewRequest’, ‘User Password Digest
Enable’
Details of the User Password Digest Enable request that is being

FirM Processing
valid Requesters defined in the User Password Digest Enable Profile
request.
request.
The processor then creates an AdminP process request to enable password digest usage for this user.
Once processing has completed then any people specified within the Notification list defined in the User Password
Digest Enable Profile will be sent an email telling them that the request has succeeded.
Configurationfor User Password Digest Enable

The following information in the selected User Password Digest Enable Profile

User Password Digest Disable

The User Password Digest Disable transaction allows a requester to disable the Domino “Password Digest” facility
for a user.
Details relating to the notification of completion of this transaction are stored in the User Password Digest Disable
Profile.
Disable
Details of the User Password Disable request that is being submitted are
processing by FirM.
FirM Processing
valid Requesters defined in the User Password Digest Disable Profile
request.
request.
The processor then creates an AdminP process request to disable password digest usage for this user.
Digest Disable Profile will be sent an email telling them that the request has succeeded.
Configurationfor User Password Digest Disable

The following information in the selected User Password Digest Disable Profile

User Password Digest Reset

The User Password Digest Reset transaction allows a requester to reset the Domino “Password Digest” facility for
a user. This means that the user can then authenticate with the Domino environment, ignoring all previous
password changes and/or expirations.
Details relating to the notification of completion of this transaction are stored in the User Password Digest Reset
Profile.
Reset’
Details of the User Password Reset request that is being submitted are
processing by FirM.
FirM Processing
valid Requesters defined in the User Password Digest Reset Profile
request.
request.
The processor then creates an AdminP process request to reset the password digest for this user.
Digest Reset Profile will be sent an email telling them that the request has succeeded.
Configurationfor User Password Digest Reset

The following information in the selected User Password Digest Reset Profile

User Roaming Enable

The User Roaming Enable feature allows a requester to enable a user’ Domino v6 “Roaming” feature
Details relating to the notification of completion of this transaction are stored in the User Roaming Enable Profile
To create a new request, select ‘NewRequest’, ‘User Roaming Enable’
Details of the User Roaming Enable request that is being submitted are
processing by FirM.
FirM Processing
valid Requesters defined in the User Roaming Enable Profile document.
If the Requester is not allowed to submit this request then it will fail. A
similar check is performed against the Authoriser of the request.
The processor will then submit an AdminP request to enable Roaming for this user.
Once processing has completed then any people specified within the Notification list defined in the User Roaming
Enable Profile will be sent an email telling them that the request has succeeded.
Configurationfor User Roaming Enable

The following information in the selected User Roaming Enable Profile

User Roaming Disable

The User Roaming Disable feature allows a requester to disable a user’ Domino v6 “Roaming” feature
Details relating to the notification of completion of this transaction are stored in the User Roaming Disable Profile
To create a new request, select ‘NewRequest’, ‘User Roaming Disable’
Select the user that you wish to manage from a normal ‘address’
selection dialog. This means that you can select any user from any
domain.
Details of the User Roaming Disable request that is being submitted are
processing by FirM.
FirM Processing
valid Requesters defined in the User Roaming Disable Profile document.
The processor will then submit an AdminP request to disable Roaming for this user.
Once processing has completed then any people specified within the Notification list defined in the User Roaming
Enable Profile will be sent an email telling them that the request has succeeded.
Configurationfor User Roaming Disable

The following information in the selected User Roaming Disable Profile

User Mail file Grant Access

The User Mail file Grant Access transaction a requester to open a users mail file for access to another person,
then optionally close that access down at a later point. This feature is of particular value to a security audit team.
Details relating to the notification of completion of this transaction are stored in the User Mail file Grant Access
Profile.
To create a new request, select ‘NewRequest’, ‘User Grant Mail file
Access’
domain.
The user is then prompted for the data owner who should have access
to the target user’s mailfile, and whether to automatically remove his
access at a later date.
Details of the User Grant Mailfile Access request that is being submitted
are displayed on the screen. Clicking Submit will submit this request for
processing by FirM.
FirM Processing
valid Requesters defined in the User Grant Mail file Access Profile
request.
request.
The processor will then issue an Extended AdminP request to change the target users mailfile ACL. Once that has
completed, then the data owner is sent an eMail informing them that they now have access.
Optionally, at the end of the access period, another Extended AdminP request is issued to remove the data-owners
access from the target users mail file.
Once processing has completed then any people specified within the Notification list defined in the User Grant
Mail file Access Profile will be sent an email telling them that the request has succeeded.
Configurationfor User Grant Mail file Access

The following information is defined in the selected User Grant Mail file Access Profile
● Should the data owner be automatically removed at the end of a pre-determined period.

User Cross-Certify
The User Cross-Certify transaction allows a requester to cross-certify a user with a new Notes Hierarchy.
stored in the User Cross-Certify Profile.
To create a new request, select ‘NewRequest’, ‘User Cross-Certify’
domain.
Details of the User Cross-Certify request that is being submitted are

processing by FirM.
FirM Processing
valid Requesters defined in the User Cross-Certify Profile document. If
the Requester is not allowed to submit this request then it will fail. A
The processor then find the user’s latest Safe-ID stored in the repository, and then apply a Cross-Certificate
operation against that and the new Hierarchy defined in the Profile document.
Once processing has completed then any people specified within the Notification list defined in the User Cross
Certify Profile will be sent an email telling them that the request has succeeded.
Configurationfor User Cross-Certify

The following information is defined in the selected User Cross-Certify Profile.
● Which hierarchy should the user be cross-certified against.

User MailFile Quota

The User MailFile Quota transaction allows a requester to optionally view and set a target users mailfile with a
new Quota and Threshold.
Details relating to the notification of completion of this transaction are stored in the User MailFile Quota Profile.
To create a new request, select ‘NewRequest’, ‘User MailFile Quota’
The requester may be asked to choose which profile should be used for this transaction, should the requester have
the choice of two or more.
domain.
If the configuration option “Allow AdminP to update Person Documents”

is set to Yes, then the users current Quota Band, Quota Level (in MB)
and Warning Threshold is displayed.
The requester is invited to choose a new Quota Band, and once selected,
the new Quota and Threshold values are displayed.
Details of the User MailFile Quota request that is being submitted are
processing by FirM.
FirM Processing
valid Requesters defined in the User MailFile Quota Profile document. If
The processor then generate an Extended AdminP request to update the users mailfile Quota and Threshold
Levels.
Once processing has completed then any people specified within the Notification list defined in the User MailFile
Quota Profile will be sent an email telling them that the request has succeeded.
Configurationfor User MailFile Quota

The following information is defined in the selected User MailFile Quota Profile.

User Move Domain

The User Move Domain transaction allows a requester to move a target user from one Domino domain to
another. This allows simple domain consolidation or split activities.
Note that this transaction ONLY moves the person document between domains, and therefore assumes:
● that all servers in all domains to be manage exist in all domain directories. This can be achieved by cutting and
pasting server documents between directories.
● All servers in all domains use Directory Assistance to make available all other Domain directories to all servers.
At the end of this operation, the user is still on the same server, with the same mail directory, but has been moved
between domain directories. The users person document has been set with the correct target domain.
In order to move users between domains and servers in the same operation, see the User Move Location
Transaction.
stored in the User Move Domain Profile.
To create a new request, select ‘NewRequest’, ‘User Move Domain’
domain.
A list of potential target domains is displayed. If the transaction profile

only allows the movement between two domains, then the other domain
– the domain that the user is currently not a member of – will be
selected.
Details of the User Move Domain request that is being submitted are
processing by FirM.

FirM Processing
The Requester of the transaction will be compared against the list of valid Requesters defined in the User Move
Domain Profile document. If the Requester is not allowed to submit this request then it will fail. A similar check is
performed against the Authoriser of the request.
request.
The processor then moves the users person document between Domain directories, and resets the user domain
name in the person document to the name of the target Domain.
Once processing has completed then any people specified within the Notification list defined in the User Move
Domain will be sent an email telling them that the request has succeeded.
Configurationfor User Move Domain

The following information is defined in the selected User Move Domain Profile.
● Which target domains may be utilised during this request.

PAG E 9 4 O F 1 8 5 1 0 . C O N F I G U R I N G F I R M U S E R T R A N S AC T I O N S
10. Configuring FirM User Transactions

This section details how the Domino User Transactions are configured, by showing the FirM administrator how to
configure each transaction profile.
Common Tab - Authorisation

The FirM Domino User Transactions all share a common “Authorisation” tab. This tab allows you to set:
● Who can request a transaction using this profile
● Who can authorise a transaction created using this profile
● Which group of users can be acted upon.
Authoriserstab
The Authorisation, Requesters tab controls which group of users may
use this profile – the Requesters. This field can contain both user
names and groups.
The Authorisation, Authorisers tab controls who may authorise
transactions created using this profile. Should the requester appear in
both tabs (either explicitly named or by virtue of group membership),
then the transaction is deemed immediately authorised and then
processed.
You may enforce separate requesters and authorisers to override this
behaviour in more secure circumstances. Should this be set to
“Separate Requester and Authoriser”, then a new Authoriser is
required regardless of the requesters appearance in this tab.
This tab allows you to define who is sent notifications when this profile
is used.
This tab defines the users against which this transaction may run (This
tab does not appear on User Create profiles). Users may be specified as
“*” for everyone, or by hierarchy such as “*/Acme”.
This tab allows the requester to defer this transaction, if set to “Allow”.

1 0 . C O N F I G U R I N G F I R M U S E R T R A N S AC T I O N S PAG E 9 5 O F 1 8 5
Name Construction and Token Replacement

A common method used throughout FirM is the ability to construct run-time information – such as the users new
Internet address – by using a token replacement language. For instance, to specify the Lotus Notes “ShortName”
field, you may use:
<FirstNameInitial><LastName>
Which is translated at run-time to the users first name first initial, plus the users last name.
A list of relevant keywords are available beside relevant fields by clicking on the “Keyword” button adjacent to the
field.
In some instances, in order to ensure uniqueness, it is necessary to introduce a sequential number at the end of a
name field. For instance, using the rules above, the first John Smith's shortname might be “Jsmith001” and the
second might be “Jsmith002”.
Three special keywords exist within the token processing system to cater for this:
● <UNIQUENUMBER1> - this generates a one-digit unique number – between 1 and 9
● <UNIQUENUMBER2> - this generates a two-digit unique number – between 01 and 99
● <UNIQUENUMBER3> - this generates a three-digit unique number – between 001 and 999
If these keywords are used in name fields, then the suggested name is attempted with an increasing number
sequence until uniqueness is ensured.
The unique number tokens are added to the name field being constructed, and then the potential name is then
tested against the Domino Directory and the Deleted User Repository.
For instance, if the short name field contains “<FirstNameInitial><LastName><UNIQUENUMBER2>,” and the
user “John Smith” is being created, then the system will construct “Jsmith01” and test for uniqueness. If it is not
unique, it will then increment the number and continue to test uniqueness until the name is unique.
This means that user “John Smith” might have short name “Jsmith01”, and Barney Stone might have short name
“BStone01”, and so forth.
It is important to note that this name uniqueness and unique number tokens is only available on the four names
fields – ShortName, FullName, Internet Address and Alternative Language Name. Fields such as Mail File Name or
Cluster File Name do not test for uniqueness.

User Create Profile

The User Create profile document enables the FirM Administrator to define how FirM Requesters are able to
create users. The User Profiles created are visible on the User Create profiles View
The User Create profile allows the FirM Administrator to define:
● The Certifier Profiles with which the user will be created. This determines the certifier hierarchy under
which the user will be created.
● The ID Profiles used. This then determines the ID expiry time, the ID type, and the password strength.
● The Location Profiles with which users will be created. This determines the pool of servers from which
the user’s home server is defined.
● The user’s Country Profiles.
● The user’s Company Profiles.
● The user’s Business Group Profile.
● The static and dynamic fields to be set on the user document.
● The Notes Name with which the user will be created.
● The user’s Internet address.
● The Notes Domain in which the user will be created.
● The user’s Mail file name and path on the home mail server.
● Who is permitted to request users using this profile.
● Who is permitted to authorise requests using this profile.
In addition to the detailed specification for a User Create profile, the FirM administrator is able to define name
construction on a system-wise basis by using the Name Validation settings in the System Configuration profile.
User Create profile Configuration

The User Create profile documents are created by clicking on “Tools, Profiles, User profiles” and either editing or
creating a new User Create Profile
The User Profile Name is used within FirM as a reference,
and can be any text string. It is recommended that this
name is appropriate to the corporate context in which it
will be used so that FirM Requesters may readily identify
the User Profile they need.
You may specify fields and groups in this tab.
● Fields are items that will be added to the new
users’ person document during a User Create
transaction. This may include static information as
well as dynamic (prompt the Requester during the
request) information
● Groups are a list of zero or more groups to which
this user will be added during the User create
operation.
● Allow Optional Groups. If this is set to 'Yes', the
requester at run time may optionally add more
groups to add this user to.
● Clone User. If this is set to 'Yes', the requester isprompted during the User Create for another user.The
other users' groups are established, and added to the list of groups that the new user is a member of. Each
group addition is handled in the same manner as a normal Group Manage Members request, and will
therefore honour any instructions on that group policy – such as requesting permission from the Group
Owner.

You may specify what primitives the new users Notes name
is constructed from. Note that the insertion of static text is
not supported at this stage. Click on the Keywords button
to see a list of supported “tags” which will be replaced at
run-time with relevant values.
You may now choose whether the Shortname is generated,
or whether the requester may type in the Shortname.
Translation features are now available on this field to ensure
uppercase, lowercase, mixed case, etc. This results in the
User Create request “Name” dialog prompting for
Shortname.
Alternate name support allows support to assign users a second “name” within Notes in their native (non-ascii)
language. This will result in an additional prompt in the user create “name” dialog which prompts for this users
non-ascii name.
You may choose to allow Optional OU (Organisational

Unit) – this means that you can add another layer of
hierarchy to new user names without the overhead of
creating another certifier.
This option allows you to choose the level of Optional OU
support you wish to provide for this User Create Profile.
The Internet Naming tab allows you to set the way in which
the user's Internet mail address will be assigned.
There are two distinct options for assigning Internet
addresses – Simple Addressing, and using Internet Address
Profiles.
The apostrophe replacement, space replacement and
translation fields are common to both Simple and Internet
Address Profile options. Use these to define the
translations that are applied to the final calculated Internet
addresses.
Simple Addressing is the default option. If this option is
selected then two additional fields will be displayed – the
Internet Address field and the Internet Domain field.
Use the Internet Address field to construct the users internet address, using tokens (e.g.
“<FIRSTNAME>.<LASTNAME>@<INTERNETDOMAIN>”, and the Internet Domain field to specify the Internet
domain (e.g. “hadsl.com”). Both of these fields should contain only a single value- multiple Internet Addresses
cannot be assigned using the Simple Addressing option.
Internet Address Profiles afford you considerably more
flexibility in the assignment of Internet Addresses, and
additionally allow you to assign multiple Internet addresses
to the new user. If this option is selected then the simple
Internet Address and Internet Domain fields are hidden, and
the settings on the Internet Address Profile tab are used
instead.
In order to complete the Internet Profiles section, you must
first have configured one or more Internet Address Profiles.
These define the domain and the name mask to be applied
to the calculated addresses. “Outbound Address” refers to
the primary Internet address that appears in the “Internet
Address” field in the new user's person document.
“Inbound Addresses” refer to additional Internet mail
addresses that can be added to other fields – usually the
FullName field.
First, use the Allowable Profiles field to select the Internet Address Profiles that are to be enabled for this User
Create profile.

Next, specify whether you want the outbound address to be calculated and applied automatically, or whether there
should be a selection displayed to the requester at request creation time. If you apply the address automatically,
then you must select an outbound profile from the list in the Outbound Internet Address field.
If you want to enable additional inbound Internet Addresses, then specify a person document field name in the
“Inbound field name” field. If this field is left blank then it will default to using the “FullName” field.
The “Always add Outbound address to Inbound field” will ensure, if enabled, that the user's Internet address is
always added to the inbound field. Use this, for instance, to make sure that user's Internet address always appears
in the FullName field.
Finally, use the “Mandatory or Optional” field to determine how additional inbound Internet addresses are assigned.
You can set the profile so that additional addresses are never added, that all additional addresses are automatically
calculated and added, or to allow the requester to select which addresses should be added at request creation
time.
The Mail File Naming tab defines how the new users’ mail
file will be named, as well as the cluster mail file should it be
allowed. Note that the mail file name and the cluster mail
file name may be different, as in this example.
You may also choose various translations that are
appropriate for the mail file name and the cluster mail file
name.
Select one or more ID, Location and Certifier profiles, and

zero or more Company, Country and Business Profiles. (See
the section on “Configuring System Profiles” on page 48 for
more information on these sub-profiles).
These sub-profiles may themselves define fields to add to
the person document. If the same field is defined in more
than one place, then the following order is observed. The
User Create Profile may be overwriten by the Cerifier
Profile, which in turn may be overwritten by the ID Profile,
Location Profile, Country Profile, Business Group profile
and Company profile.
Should only one sub-profile be selected, then the requester is not prompted. Should more than one of any of the
sub-profiles be selected, then the requester is prompted to choose which particular sub-profile is relevant. The
requester is prompted during the initial stages of the User Create transaction - this is why profile names and
system-profile names should always be meaningful in the context of your business, as this reduces requester
confusion and therefore increases accuracy.
Sub-profiles allow the FirM Administrator to devolve only the decisions relevant to the business to the FirM
Requester. For instance, the FirM Administrator may select two ID types in the ID Sub-Profile - one for staff
members and one for ‘Temp’ employees - the ‘Temp’
employee ID profile having a shorter recertification period.
During the user creation, the FirM Requester is prompted
to select one of these two ID types.
Selecting an Active Directory or BlackBerry profile allows
you to automatically create an Active Directory Create
User or a BlackBerry Provision transaction for this user at
creation time.
The “ID & Password” tab allows you to choose the
methods as to how the User ID and password should be
distributed. In the case shown, the requester is presented
with a default list of names, and can accept or change them
as required.

User Modify Profile

A User Modify Profile allows you to define exactly what fields on a target users “person” document you wish to
allow modification to, and define who should be allowed to request transactions of this type.
Configurationfor User Modify

The following information in the selected user modify profile is relevant to the user modification request.
 Which Requesters can submit requests of this type
 Which Authorisers are allowed to approve these requests
 Who shall be notified of a successful completion of this request
 Which fields on the person document can be modified by this request, and how the user is prompted for
this information
Access the User Modify Profiles by clicking on Tools, Profiles, User Profiles:
 The Name field is the name of this user Modify profile. Ensure
that this name makes sense in the context of your business as
the requesters may be prompted using this name.
 Description. A textual description of this profile
 Users can modify themselves. This allows any user to modify
their own person document.
The Fields tab allows you to define one or more static or dynamic field
settings. In this case, the requester is prompted for a new telephone
number for this end user.
For example, clicking on the “Dynamic Fields” button prompts you for:
Which then allows you to create a new dialog box during a user modify
event.
The authorisation tab allows you to define:

 Who may request this operation
 Who may authorise this operation
 Which group of users it should be performed on, defined by Notes hierarchy.
 Which group of users should receive notifications.
User Disable Profile

The User Disable profile specifies how a particular user should be
disabled from the environment and who should be allowed to disable
users.
The fields defined are:

PAG E 1 0 0 O F 1 8 5 1 0 . C O N F I G U R I N G F I R M U S E R T R A N S AC T I O N S
 Name - the name of this profile as it appears to FirM Requesters.

 Description - a description of the profile.
 Active Directory User Disable Profile. If one is selected, then an AD UDI transaction is automatically
generated for this user.
 BlackBerry Profile. If one is selected, then a BlackBerry Disable user transaction is automatically created
for this user.
User Enable Profile

 Name - the name of this profile as it appears to FirM
Requesters.
 Active Directory User Disable Profile. If one is selected, then
an AD UDI transaction is automatically generated for this user.
 BlackBerry Profile. If one is selected, then a BlackBerry Disable user transaction is automatically created
for this user.
User Delete Profile

The User Delete profile specifies how a particular user should be deleted from the environment and who should
be allowed to delete users. Note that each user deleted is also immediately disabled from the Domino
environment.
The fields to be defined are:
Requesters.
 Description - a description of this profile.
 User Disable Profile - select a valid, relevant User Disable
Profile that this user delete transaction will use.
 Blackberry Profile. If a BlackBerry profile is selected, then a
BlackBerry delete sub-transaction is created to remove the
user from the BlackBerry Enterprise Server.
 Allow the Requester to assign a Data Owner? - the FirM
Requester may specify a person who is automatically granted
access to the deleted users' mail file for a period of time. The
Data Owner is defined at run-time. Use of this option should
be in line with your organisation’s data retention and security
guidelines.
 Specify whether you want to hide the person document with
reader fields at the start of the process. If this option is
selected then a field name must be provided, and a list of
users, groups or roles that will see the document. You must ensure that mail and adminp servers are still able
to see the document afterwards – and this includes the name of the user that enabled the FirM processing agent.
 Mandatory/Optional – allow the requester to choose whether a Data Owner should be assigned
 Delete User’s Mail file: Select from one of the following
options:
o Don’t delete the mail file.
o Delete the mail file specified in the user’s person
document.
o Delete the mail file specified in the user’s person
document, and all mail file replicas (useful in a
clustered environment)

1 0 . C O N F I G U R I N G F I R M U S E R T R A N S AC T I O N S PAG E 1 0 1 O F 1 8 5
 Archive the mail file. This does not delete the users mail file but moves it to a server. If this is set to “yes” ,
then
o Archive Server. Select whether to archive to a directory on the user's mail server or to a specific
mail server. Choose the server that the target users mail file will be moved if appropriate.
o Archive Directory. Enter a directory name that the users mail file will be moved to.
User Reset HTTP Password Profile

The User Reset HTTP Password profile is used to specify how a
particular user's HTTP (or Internet) password should be changed and
who should be allowed to change it.
Requesters.
 Can users change their own passwords? - Enabling this allows users to both request and authorise these
password resets.
 Password Strength – specifies the password strength on a scale of 0 to 16. Levels are defined in the Lotus
Administrator’s manual in the article ‘The Password Quality Scale’.
 Active Directory Profile. If one is selected, then an AD User Reset Password will be automatically
generated to set the users AD password to the same as the new “http” password.
User Move Server Profile

The User Move Server Profile is used to specify who is allowed to perform the User Move Server operation.
Requesters.
 Description – a textual description of this profile
User Move Profile

The Move in Hierarchy profile is used to specify how a user should be moved in the Notes Name hierarchy and
who is allowed to perform the operation.
Requesters.
 Allowed Certifiers. If one or more entries are selected from
this list of profiles, then the requester will only have the choice
of the selected Certifiers. Otherwise, the requester will be
able to choose from any Certifier defined within FirM.
 User Enable Profile. If selected, a User Enable transaction is
automatically ran for the users new Notes Name. This ensures
that if a previous users' notes name was added to the
terminations groups, and this new user name matched it, then the target user would not be barred from
accessing your Notes environment.
 ID Profile. Select an ID profile in order that the ID expiry period can be set.
User Move Location Profile

The Move Location profile is used to specify how a user should be
moved in terms of Locations and Hierarchies and who is allowed to
perform the operation.
On the details tab, the fields defined are:
Requesters.

 Description – a textual description

 User Move Server profile – the name of a User Move server profile to be used should the user require to
be moved between servers.

On the Allowed Locations tab, fields defined are:

 Allowed Current Locations
 Allowed Target Locations
In both cases, selecting NO entries allows the user to choose between

ALL system Location profiles defined within FirM.
Please note that location profiles also contain allowed certifier

hierarchies. During a user Move Location, the target location profile is
checked to see if the selected user should also move in Hierarchy. For
more information on Location Profiles, see the section “Location
Profiles” on page 51.
User Rename Profile

The User Rename Profile specifies how a user is renamed within the Notes Name hierarchy and who is allowed to
Requesters.
 User Enable Profile. If selected, a User Enable transaction is
automatically ran for the users new Notes Name. This ensures
that if a previous users' notes name was added to the
terminations groups, and this new user name matched it, then
the target user would not be barred from accessing your Notes environment.
 ID Profile: Select an ID profile in order that the ID expiry period can be set.
 User Create Profile: Select a UCR Profile in order that the User Rename Common Name transaction can
work out the users new internet address. The users “old” internet address will be appended to the users
“fullname” field so that both internet addresses work for this user.
User Recertify Profile

The User Recertify Profile specifies how a user is recertified within the Notes environment and who is allowed to

Requesters.
 ID profile associated with this User Recertify profile. The ID
profile dictates how long the target user ID should be
recertified for.
 ID Profile: Select an ID profile in order that the ID expiry period can be set.
User Resend User ID & Password Profile

The User Resend User ID & Password Profile specifies who is allowed to request that a target users last user ID
and password should be mailed from the secure ID and Password repositories.
Requesters.

User Password Digest Enable

The User Password Digest Enable specifies who is allowed to request that a target user has a password digest
created for them.

Requesters.
User Password Digest Disable

The User Password Digest Disable specifies who is allowed to request that a target user has their password digest
disabled.

Requesters.
User Password Digest Reset

The User Password Digest Reset specifies who is allowed to request that a target user has their password digest
reset.

Requesters.
User Roaming Enable

The User Roaming Enable specifies who is allowed to request that a target user is set to be a Notes v6 “Roaming”
user.
Requesters.
 Store on User Mail Server – the users roaming information is
stored on the users Home server.
 Roaming Folder Format – enter some keywords to define
how the users own roaming folder will be structured.
 Client Cleanup – choose between ‘Do Not Clean Up’, ‘Clean up Periodically’, ‘At Notes Shutdown’, and
‘Prompt User’
 Store ID in Address Book – this will create an AdminP request to store the users ID file in their personal
address book for Roaming.

User Roaming Disable

The User Roaming Enable specifies who is allowed to request that a target user has their Notes v6 “Roaming” user
capability disabled.
Requesters.
User Mail File Grant Access

The User Mail File Grant Access profile allows you to define who is allowed to delegate access for a target user.
This transaction is useful for temporarily granting access of a target users mailfile to another Notes user.
On the Details tab, the fields defined are:

Requesters.
On the User Mailfile Grant Access tab, the fields defined are:
 Target Name – that is, the person who will be granted access.
 Send Mail Message to user – yes or no.
 Requester can set Access Period – Yes or no.This allows the
requester to choose at run-time how long access should be
granted.
 Number of working days to grant access.
 Access Control Level – can be set to any valid ACL level
 Remove this entry: Can be set to Always Remove, Ask the
Requester, or Never Remove.
User Cross-Certify
The User Cross-Certify profile allows the administrator to define who can request that a target user has their user
ID cross-certified with another hierarchy.

Requesters.
 Certifier Profile- the name of the certifier to cross certify
target users against.
 ID Profile – define the ID profile to be used in order to calculate how long the Cross-certification is valid
for.
User MailFile Quota

The User MailFile Quota profile allows the administrator to define who
can request that a target user has their mailfile set with a Quota and
Threshold.
Requesters.

User Move Domain

The User Move Domain profile allows the administrator to define who can request that a user is moved between
domains, and what the target domains should be.

Requesters.

1 1 . F I R M G RO U P T R A N S AC T I O N S E X P L A I N E D PAG E 1 0 7 O F 1 8 5
11. FirM Group Transactions Explained

Group Create
The Group Create transaction allows a user to request the creation of a group in a FirM-registered Domino
Directory.
A Group Create transaction is defined in a Group Profile (See the section “Group Profiles” on page 53 for more
information) document and includes such specifications as the name mask, allowable group content, Internet name,
type of group, authorised Requesters and Authorisers.
To create a new request, select ‘NewRequest’ at the top of the FirM
Request Processor. Then, under Group Management, select ‘Group
Create’.
Select the profile that will be used to govern this group's attributes and
behaviour. These profiles are defined and managed by a FirM
administrator.
Click Forward to move to the next Screen.
Enter the free-text part of the group name. This is the part of the group
name that the Requester specifies. Additional elements will be added to
the group name to enforce naming standards and consistency as
determined by the selected Group Profile.
Select the domain in which this group is to be created. Although FirM
supports the management of groups in different domains with the same
name, it is possible that the administrator has switched on enforcement of ‘globally unique group names’ within the
FirM configuration setup.
Click Forward to move to the next screen.
The group naming rules will be applied to the group name to ensure that
it meets such specified requirements as only containing acceptable
characters and that it meets the minimum or maximum length.
The calculated full group name is displayed, together with the Internet
name if the profile specifies that one is required.
Enter the group description.
Click Forward to the next screen.
Specify the name of the Group Owner. The Group Owner is the person
with ultimate responsibility for the group and is usually also the billing
contact. The Group Owner is also by definition a group manager for this
group.
Add the group managers and administrators.
Group managers are able to create requests to rename this group,
change the ownership, management and administration lists, change the
group description, manage the group's membership content and
ultimately delete the group. The Administrators are only able to change
the group's membership content.

PAG E 1 0 8 O F 1 8 5 1 1 . F I R M G RO U P T R A N S AC T I O N S E X P L A I N E D
The administrator may have enabled membership content to be added at

the time of creation to groups created with this group profile. If this is
the case then a screen will be displayed enabling initial membership
content to be added. Add initial members, if required, and click Forward
to the next screen.
Details of the group request that is being submitted are displayed on the
screen.
Clicking Submit will submit this request for authorisation, if necessary,
and processing by FirM.
FirM Processing
The Requester of the transaction is compared against the list of people allowed to submit Group Create requests
for a group using the selected profile. See the section “Group Profiles” on page 53 for more information. The
request fails if the Requester is not an authorised FirM Requester.
If the Requester is permitted to submit the request but may not authorise the request then details of the request
are sent to all the listed Authorisers in the profile. The Authorisers then follow the doclink in the mail and either
authorise or reject the request.
If the Requester is also present in the authorisation list and the option ‘enforce separate authorisation’ is not
selected in the relevant group profile, then the request requires no further intervention.
Processing checks that all relevant information is present in the request. If, for any reason, vital information is
missing (although this should not be possible), the request fails with failure details written to the FirM log and to
the request.
The proposed group name is checked for uniqueness in the target domain, and optionally across all managed
domains. If the name is unique then a new group document is created in the Domino Directory and a shadow
entry added to the FirM Group Repository - this ensures that the group is available for management by FirM.
Name uniqueness is tested against other group names, mail-in database names, user names, resource names, server
names, etc..
Once processing has completed, people specified in the Notification list for the relevant group profile are sent an
email notifying them of the successful group creation.
This group can now be managed within FirM.
Configurationsettings for Group Create

FirM setup configuration (See the section: “‘Name Validation’ tab, ‘Group Name' subtab: “ on page 37 for more
information) allows the following global settings to be applied to requests for group creation:
 Maximum length of the Requester's free-text part of the group name.
 Allowed and disallowed characters in the free-text element.
 Name uniqueness to be tested on a global basis, or limited to a per-directory basis.
Group profiles (See the section “Group Profiles” on page 53 for more information) obviate the need for FirM
Requesters to be familiar with many of the group settings, e.g. group type, etc.. The following options can be
specified within the group profiles:
 The type of Domino group to be created with this profile, e.g. Multi-Purpose, ACL Only, etc..
 The name mask to be applied to the group name and the group Internet name. For instance, you can
ensure that ‘_mail_’ is prepended to all mail group names. If no Internet name mask is specified then no
Internet name will be created for the group.
 Whether the foreign directory sync flag is set or not.
 The detailed list of permitted membership types. For instance, SMTP addresses can be prohibited from
being added to ACL groups; server-only groups can be created, etc..
 Whether membership for Notes users and resources is restricted to being from the group's domain only.
 Whether a group's content can be managed without restriction by any Notes user with access to FirM.

 Who is permitted to request the creation of this type of group and who is able to authorise the request.
A further restriction may also be defined that the Requester and the Authoriser must be different people.
 Who will be notified when a group is created with this profile and when a group based on this profile is
modified, deleted or managed.
The profile selected when a group is created will be recorded in the group’s record in the FirM Group Repository.
This can only be changed by directly editing the repository record, and it governs the group’s membership masks
and some security settings.
Group Modify
The Group Modify transaction allows a FirM Requester to request the modification of a FirM-registered group in a
FirM-registered Domino Directory and to manage the Ownership, Management and Administration permissions
for that group.
To create a new request, select ‘Group Modify’.
Select the group to be modified from the list. The list will only contain
those groups in which you are the owner or have been given
management rights. This list is managed through the Group Modify
function.
Select the changes to be made to the group, e.g. rename, change

description, change ownership or management lists or change the
administrator list. More than one attribute may be changed in a single
group modify request.
If modifying the group name, enter the new free-text part of the group
name. Clicking on the recalculate button applies the relevant profile's
name mask and displays the new group name. The group's Internet
name is also recalculated. If the new name is the wrong length or
contains prohibited characters, correct the error before proceeding.
If the group description is to be modified, enter the new group

description.
If the group’s ownership or management list is to be modified, specify

the new owner and add or remove entries from the management list as
appropriate. The owner can also be specified as the billing target for
operations on this group (this relates to the records created in the
billing database) and the managers are able to submit group modify,
manage and delete requests for this group.

If modifying the group’s administrators add or remove entries from the

group’s administrators list.
Details of the group modify request are displayed on the screen. Click
Submit to submit this request for processing by FirM.
FirM Processing
The Requester of the transaction is compared against the Owner and
Managers list for this group. The request will fail if the Requester is not
allowed to submit this request.
Checks are now made to ensure that all relevant information is present
in the request. If required information is missing (which should not be
possible) the request fails. The reasons for the failure are detailed in the
FirM log and also in the request.
If group rename is specified then the new group name is checked for uniqueness in the directory according to the
rules specified in the FirM setup configuration.
The group document in the Domino Directory is modified with the new name and all subgroup names adjusted
accordingly. The membership of the parent group is updated to reflect the new subgroup names and the
descriptions of the subgroups are modified accordingly.
An AdminP sub request is created which requests ‘group rename in address book’. The status of this AdminP
request is monitored for completion.
If group description change has been requested, the description of the group in the group document in the Domino
Directory is updated with the new description.
If a request to update the owner or managers list of the group has been requested, FirM updates the group's entry
in the FirM Group Repository.
If a request to update the administrators list of the group has been requested then FirM updates the group's entry
in the FirM Group Repository.
Once processing is complete, any people specified in the Notification list for the relevant group profile are sent an
email notifying them of the modifications to the group.
If there are any incomplete AdminP requests open, the request is marked with a status of ‘Pending Sub-transaction’
Once any sub-transactions have completed the request is marked with the status of ‘Complete’.
Configurationfor Group Manage Members

FirM setup configuration allows the following global settings to be applied to requests for group modification:
 Maximum length of the Requester's free-text part of the group name.
 Allowed and disallowed characters in the free-text element.
 Whether name uniqueness is on a global basis or limited to a per-directory basis.
FirM searches for the group profile that governs the behaviour of this group. The following information in this
profile is relevant to the ‘group manage members’ request:
 The name mask to be applied to the group name and the group Internet name. For example, ‘_mail_’ is to
be prepended to all mail group names. If no Internet name mask is specified then no Internet name will be
created for the group.
 Who will be notified when a group with this profile is modified.

Group Manage Members

This transaction allows user to request the management of the membership list of a FirM-registered group in a
FirM-registered Domino Directory.
The Group Profile documents define valid content and the notification recipients for this transaction.
To create a new request, select ‘Group ManageMembers’
Select the group to be managed from the list. The list will only contain
those groups in which you are the owner or have been given
management rights. This list is managed through the Group Modify
function.
Using the address helper or by typing, create the lists of people to add
or remove from the group.
Details of the ‘group manage members’ request are displayed. Click on

FirM Processing
The Requester of the transaction is compared against the Owner,
Managers and Administrators list for this group. The request fails if the
Requester is not allowed to submit this request.
possible) the request fails. The reasons for the failure are detailed in the FirM log and also in the request.
Each person on the delete list is removed from the group and any of its spawned subgroups.
Each name on the add list is evaluated to determine the type of entity it represents. It is compared against the list
of allowable members as determined by the profile governing the group. If the name satisfies all criteria it is added
to the list. If the name does not pass any of the criteria an error is generated, the name is not added to the list and
processing passes to the next name on the add list.
If a group exceeds its size limit, as determined by the FirM setup Configuration, subgroups are automatically
created according to the following: a new subgroup is created and the contents of the parent group member list
are copied into this subgroup. A new subgroup is created, and the member is added to that group. The parent
group's membership is replaced with a list of all its subgroups. New subgroups will be spawned whenever there is
no room for the new member in any subgroup.
email notifying them that the group has been created.
The request is marked with the status of ‘Complete’.

Configurationfor Group Manage Members

The following global settings as defined in FirM setup configuration are applied to requests for group management:
 The group is split into subgroups either when it reaches the Domino 15Kb size limit or when the number
of entries specified is exceeded.
 The separator character used to identify subgroups. For example, when the separator character is ‘_’, a
group named Mail Group will spawn subgroups named MailGroup_01, MailGroup_02,etc. By default this
character is ‘_’.
FirM searches for the group profile that governs the behaviour of this group. The following information in the
profile is relevant to the ‘group manage members’ request:
 Whether all members must be from the same Domain as the group.
 The types of members that can be added to this group, e.g. whether to allow or disallow SMTP addresses,
Server Names, Mail Groups etc..
 Who will be notified when membership changes to this group are made.
Group Delete
‘Group delete’ allows a user to request the deletion of a FirM-registered group in a FirM-registered Domino
Directory.
Information relating to the notification of completion of this transaction is stored in the Group Profile documents.
To create a new request, select ‘Group Delete’.
Select the group to delete from the list. The list will only contain those
groups in which you are the owner or have been given management
rights. This list is managed through the Group Modify function.
Details of the ‘group delete’ request are displayed. Click Submit to

submit this request for processing by FirM. Click “Submit” to submit this
request for processing.
FirM Processing
The name of the Requester of the transaction is checked to see that
either it is the Owner of the group or is in the list of Managers for this
group. The request fails if the Requester is not allowed to submit this
request.
Checks are now made to ensure that all relevant information is present in the request. If required information is
missing (which should not be possible) the request fails. The reasons for the failure are detailed in the FirM log and
A copy of this group and all FirM subgroups contained in the group are added to the FirM ‘Deleted Groups and
Users’ repository.
The status of the entry for this group in the FirM Group Repository is changed to ‘Deleted’ and the name of the
person deleting this group is added to the record together with the date and time at which the group was deleted.
The group is now deleted from the specified domain’s Domino Directory and a sub-request is created to create
and track an AdminP ‘Delete group in address book’ transaction.
email notifying them that the group has been deleted.

The request remains in the state ‘Pending Sub transaction’ until the AdminP request completes. It then changes to
‘Complete’.
Configurationfor Group Delete

FirM searches for the group profile that governs the behaviour of this group. The following information in this
profile is relevant to the ‘group delete’ request:
 Who will be notified when this group is deleted.

PAG E 1 1 4 O F 1 8 5 1 2 . F I R M A P P L I C AT I O N T R A N S AC T I O N S E X P L A I N E D
12. FirM Application Transactions Explained

FirM allows management of Lotus Domino applications. This facility allows the FirM Administrator to delegate the
right to create new applications in the Domino environment to non-technical, non-authorised personnel.
When FirM creates an application on your behalf, it creates a mail-in database document in the directory, and
stores all relevant information in that document. So all applications are by default mail-in applications. This has the
side-effect of preventing the storage of application information in a separate database, and thus reducing
management effort.
When FirM creates a new application for a requester:
● the requester chooses from a pre-defined list of templates
● The requester assigns an Owner (someone who can manage the application and delete it if required) as
well as zero or more administrators (people allowed to manage the application but not allowed to delete
it.
● The requester chooses a Domino server based on a pre-defined list
FirM then:
● Creates the new mail-in database record, and populates it
● Creates an AdminP request to create the new application with the new file name on the correct server
● It issues AdminP requests to create additional replicas of this database if required
● It creates one or more Groups associated with this application, and populates the database ACL with
these groups. The owners and administrators of the application are set to be owners and administrators
of the groups, and can therefore manage the application via the groups.
Application Create
The Application Create request allows a user to request the creation of an Application database record, its
associated database and any replicas on cluster-mates of the database server.
Details relating to the notification of completion of this transaction are stored in the Application Create profile
documents.
To create a new request, select ‘ApplicationCreate’.
The Requester specifies :

 The domain in which the mail-in database should be created.
The list displayed of possible domains is defined in the Mail-In
Database Create profile.
 The database title of the mail-in database. Any spaces and
punctuation will be removed.
 The Domino server on which the database will be created. The list displayed of possible servers is
defined in the Mail-In Database Create profile.
 The name of the template with which the database should be created. The list displayed of possible
templates is defined in the Mail-In Database Create profile.

1 2 . F I R M A P P L I C AT I O N T R A N S AC T I O N S E X P L A I N E D PAG E 1 1 5 O F 1 8 5
Specify one or more users or groups who are the designated ‘owners’ of
this mail-in database record. The owners may update or delete this mail-
in database record.
Specify zero or more users or groups who are the designated

‘administrators’ of this mail-in database record. The people or groups
listed may update this mail-in database record.
Details of the ‘mail-in database create’ request being submitted are

displayed. Click Submit to submit this request for processing by FirM.
FirM Processing
The name of the Requester of the transaction is checked to ensure that
it is contained in the list of allowed Requesters in the Application Create
profile. The request fails if the Requester is not allowed to submit this
request.
in the request. If required information is missing (which should not be possible) the request fails. The reasons for
the failure are detailed in the FirM log and also in the request.
A check is made on the name of the Application database in the target domain. If an Application database already
exists with that name the request fails.
An Application database record is created in the Domino directory and is populated with information from the
request. The owner’s field is populated using the list of owners supplied by the Requester and the list of default
owners defined in the ‘Application Create’ profile. Similar action is taken for the administrator’s field.
An AdminP request is submitted to create the mail-in database on the Domino server with the supplied template
name.
An Extended AdminP request is submitted to update the database Access Control List with any default database
managers defined in the ‘Application create’ profile.
If the ‘Application create’ profile record requires the creation of a cluster replica of the mail-in database, and the
target server is in a cluster, then an Extended AdminP request is created that will create an AdminP request on the
target server to create a cluster replica of the mail-in database.
Once processing is complete, any people specified in the Notification list for the relevant ‘mail-in database create’
profile are sent an email notifying them that the mail-in database record has been created.
The request remains in the state ‘Pending Sub transaction’ until the Extended AdminP request(s) and the AdminP
request are all complete. It then changes to ‘Complete’.

Configurationfor ApplicationCreate
FirM uses the ‘Application Create’ profile selected at the start of the transaction.
The following information in this profile is relevant to the mail-in database create request:
 The Application mail address and the Requester’s Application title
 The ultimate Application notes mail address (combined with the Requesters Application title)
 The Internet address and with the Requester’s mail-in database title.
 The path to the mail-in database.
 Whether or not the database should be replicated to any cluster servers.
 The Application cluster replica name.
 The list of target servers on which the mail-in database may reside.
 The list of templates that may be used to create the Application database.
 The list of default owners for all Application databases created using this profile.
 The list of default administrators for all Application databases created using this profile.
 The list of entities to add as managers in the Access Control List of the target Application.
 Who may authorise mail-in database deletions using this profile.
 Who will be notified upon successful creation of an Application Create.
Application Modify
The Mail-In Database Modify profile allows a user to request modification of a mail-in database record and its
associated database and any replicas on cluster-mates of the database server.
Details relating to the notification of completion of this transaction are stored in the Mail-In Database Modification
profile documents.
To create a new request, select ‘Mail-InDatabase Modify’.
If the requester is allowed to use more than one Application Modify

profile, the requester will be prompted for which profile to use.
Choose one and click forward to go to the next screen.
Select the mail-in database record to modify. The list of entities, i.e.
users, groups, mail-in databases and servers, in the standard ‘address’
dialog allows the selection of any domain and any mail-in database.
After the entity is selected:
 The entity is checked to ensure that it is a mail-in database.
 The mail-in database record's owner and administrator fields are checked to ensure that the Requester’s
name is either in these fields explicitly or implicitly by being contained in one of the specified groups.
Existing mail-in database information is now displayed. Specifically:
 The Domino address book’s mail-in address
 The Internet address
 The Administrator’s field
 The Owners’ field (if this user is listed as an owner)

1 2 . F I R M A P P L I C AT I O N T R A N S AC T I O N S E X P L A I N E D PAG E 1 1 7 O F 1 8 5
Details of the ‘mail-in database modify’ request are displayed. Click

FirM Processing
The name of the Requester is compared against the owner and
administrator fields in the Application database record. If the Requester
is not listed directly (by Notes full name) or indirectly (by being the
member of a group or subgroup), the request fails.
The Application record is updated with the information in the request.
Once processing is complete, any people specified in the Notification list for the relevant ‘Application modify’
profile are sent an email notifying them that the mail-in database record has been modified.
Configurationfor ApplicationModify
FirM uses the selected ‘Application Modify’ profile selected at the start of the transaction. The following
information in this profile is relevant to the mail-in database modification request:
 Who may request Application modifications using this profile
 Who may authorise Application modifications using this profile
 Who will be notified upon modification of this Application.
Application Delete
The Application Delete request allows a user to request the deletion of an Application record, its associated
database and any replicas on cluster-mates of the database server.
Details relating to the notification of completion of this transaction are stored in the Application Delete Profile
documents.
To create a new request, select ‘ApplicationDelete’.
If the requester is allowed to use more than one Application Delete
profile, the requester will be prompted for which profile to use.
Choose one and click forward to go to the next screen.
Select the Application record to delete. The list of entities, i.e. users,
groups, mail-in databases and servers, in the standard ‘address’ dialog
allows the selection of any domain and any mail-in database.
After the entity is selected:
 The entity is checked to ensure that it is a mail-in database
 The mail-in database record's owner field is checked to validate that the Requester’s name is in the field,
or is contained in any group (or subgroup) in the field.

Details of the ‘Application delete’ request are displayed. Click Submit to

submit this request for processing by FirM.
FirM Processing
The name of the Requester is compared against the owner and
administrator fields in the mail-in database record. If the Requester is
not listed directly (by Notes full name) or indirectly (by being the
member of a group or subgroup), the request fails.
A copy of this Application record is added to the ‘FirM Deleted Groups and Users’ repository.
The mail-in database record in the domain’s Domino Directory is deleted and a sub-request is created to create
and track an AdminP ‘Delete in Names Field’ request.
An AdminP request is created which:
 Runs on the server specified in the mail-in database record.
 Creates deletion AdminP requests for all cluster mates of the server for any replicas of the database.
 Deletes the database specified in the Application record.
A further AdminP request is created which:
 Deletes all references to the mail-in database from any author name or reader name (names fields) in the
environment.
Once processing is complete, any people specified in the Notification list for the relevant ‘mail-in database modify’
profile are sent an email notifying them that the mail-in database record has been deleted.
The request remains in the state ‘Pending Sub transaction’ until the Extended AdminP request has completed. It
then changes to ‘Complete’.
Configurationfor ApplicationDelete
FirM uses the Application Delete profile selected at the start of the transaction. The following information in this
profile is relevant to the ‘mail-in database delete’ request:
 Who may request Application deletions using this profile.
 Who may authorise Application database deletions using this profile.
 Who will be notified upon deletion of this Application.

1 3 . C O N F I G U R I N G A P P L I C AT I O N T R A N S AC T I O N S PAG E 1 1 9 O F 1 8 5
13. Configuring Application Transactions

Application transactions allow the devolution of application deployment and management to the requesters.
The Application model creates a “Mail in Database” record in the Domino Directory, holding information on who
should own and manage each application, as well as the Notes Mail-In database name of that application.
Common Tab – Authorisation

All Application transactions share the same authorisation tab. Note that similar to the group administration model,
applications can be created and managed on a “per application” basis, where the Application has an “Owner” and
list of “Administrators” who may manage this application.
Application Create
Fields defined on the “Details” tab are:

 Profile Name. Give this a meaningful name for your
business
 Mail Address – the mail-in database name of the
application that will be created.
 Internet Address – should the database also have an
internet address associated with it
 Database Path – where should the database be created
 Cluster Db: Should this application be replicated to Cluster members of the target server?
 Cluster Db Path – if cluster replicas are to be created, how should the file names be constructed
Define one or more servers on the “Servers” tab that will be

given as a choice to the requester. If only one is given, then the
application will be deployed on that server. If no choices are
given, the requester can choose any server in the directory.
Define one or more Template databases that the user can use
to create the target application. Note that the template
database must exist on the target server for AdminP to
successfully create the database.
Enter a list of mandatory owners for all applications created

using this profile. These people/groups will be added as
“Managers” to this database ACL and can perform any
operation on those applications.

PAG E 1 2 0 O F 1 8 5 1 3 . C O N F I G U R I N G A P P L I C AT I O N T R A N S AC T I O N S
Enter a list of default Administrators for this Application –

personnel who can manage this application, but may not delete
it.
Enter a default list of one or more entities to be added to the

Application as Default managers.
Application Modify
The application Modify profile allows the FirM administrator to delegate the management of applications to non-
technical users.
Profile Name: Set the modification profile name to some name that
makes contextual sense in your business.
Application Delete
The application Delete profile allows the FirM administrator to delegate the management of applications to non-
technical users.
Profile Name: Set the modification profile name to some name that
makes contextual sense in your business.

1 4 . AC T I V E D I R E C TO RY OV E RV I E W PAG E 1 2 1 O F 1 8 5
14. Active Directory Overview

The FirM Active Directory component (or “FirM AD”) allows you to extend FirM and facilitate Active Directory
user and group management.
Architecture
FirM is a set of native Lotus Domino applications that run on an IBM Lotus Domino Server. FirM manages Lotus
Domino identities and resources, and the FirMAD component allows you to manage Active Directory ("AD")
Accounts.
The central processing core of FirM is the FirM Request Processor database.
In order to manage AD it is necessary to run FirM on a win2k or win2k3 server which must be a domain
controller and a valid member of the AD forest that you wish to manage.
FirM communicates with AD through an LSX (a special DLL file which extends LotusScript).
User Home Directories and User Profile Directories are created by a Windows Service component, which must
be installed on each target Windows server. The service relies upon a Lotus Notes client (which must be installed
on the target server) to communicate with FirM and it performs all of the folder manipulation on the target server.
ExAmp
FirM
AD Operation
Notes FirM AD
Client Service
User
Lotus
LSX Shared
Domino
Folders
Windows 2000
AD / 2003 File Server
Object User
Profile
Management
Folders
Server
Active Directory
This diagram illustrates the FirM Architecture. The blue circle represents a Domino-Only version of FirM, and the
red components represent AD only components.
It should be noted that both the Lotus Domino server and all win2k3 servers have to be in the same Active
Directory domain.
For instance, A FirM AD User Create Operation would perform the following processing:
 A new FirM AD User create Transaction is created in the Firm Request Processor database.
 On the FirM Primary processing server, the FirM “Process Requests and Workflow” agent (in
the Firm Request Processor database) validates and checks the request. If it is valid it will then:
o Pass an “Create User in Active Directory” operation to the LSX, which will then
call Active Directory.

PAG E 1 2 2 O F 1 8 5 1 4 . AC T I V E D I R E C TO RY OV E RV I E W
o “Extended AdminP” requests ("ExAmp Requests") in the FirM Extended AdminP

database ("ExAmp").
 The FirM AD Service on each of the win2k3 file servers polls the ExAmp database using Lotus
Notes RPC calls for tasks. If the Service recognizes a task for itself it:
o Unpacks and validates the task.
o Processes the task. In this case, it would:
 Create the users home folder Directory.
 Set the permissions on the folder in order that the user and the
Administrators group had full access,
 Optionally set this folder to Shared.
o Marks the request as complete.
 On the FirM Primary processing server, the FirM “Process Requests and Workflow” agent (in
the Firm Request Processor database) polls the FirM Extended AdminP database, checking to
see which of the external tasks have been completed. One the external tasks are completed,
the initiating transaction is then marked as complete.

1 5 . I N S TA L L I N G & C O N F I G U R I N G AC T I V E D I R E C TO RY PAG E 1 2 3 O F 1 8 5
15. Installing & Configuring Active Directory

This section deals with installing and configuring the two FirM AD components within your FirM environment.
Activating Active Directory

Open the FirM Request Processing database, click on “Tools”
and then choose the Configuration pane.
Click on Edit Config, and then choose the “AD” tab.
Set “Active Directory Enabled” to “Yes”.

The “Login Name” field is used to select
a user with sufficient authority to run
MSI scripts on the FirM Processing server.
This need not be filled in unless you wish
to run MSI Scripts.
The “Person Document Field to store
AD GUID field” defaults to
“NetUserName”, and is the field on the
domino directory person document upon which we will place the AD GUID (Global Unique ID) number. This then
connects the domino person with an entity in Active Directory. It is highly recommended that this value is not
changed frequently, as previously created persondocuments will have to be updated manually.
This is the same field name as

Lotus Active Directory
Synchronisation uses. If this field
is used, then the field is visible
on the users Person document,
on the “Administration” tab,
without modifying the standard
Directory template:

PAG E 1 2 4 O F 1 8 5 1 5 . I N S TA L L I N G & C O N F I G U R I N G AC T I V E D I R E C TO RY
The FirMAD LSX DLL

Open the FirM Request Processor database,
and select “Tools”. Choosethe last tab,
‘System Views’:
This shows the FirmAD.dll file held in a Notes
Document.
The LSX DLL is used by administration clients
and requester clients which require to browse
the Active Directory tree, or select Active
Directory objects.
The LSX is installed automatically when the
user activates the LSX for the first time – it is
copied to the users data directory.
Setting Permissions within AD

The LSX component is ran by the Domino server, and inherits the Active Directory identity of the computer that
the Domino server is running on.
This means that for the Windows Service to successfully manage User and Group AD Objects, the computer that
the Windows Service runs on must have permission to modify them.
Typically, an AD infrastructure willrevolve around a number of Containers in the AD hierarchy. It is recommended
that the Computer ID to be used by the Windows Service is granted “Full” permissions in the containers in which
you wish to manage AD users and groups.
Installing the FirM AD Component
Prerequisites
The FirM AD Component and its accompanying setup program both are reliant the “Microsoft .NET Framework
Version 2.0 Redistributable Package (x86)”.
MS .Net v2.0 framework loaded onto the target computer. This is usually downloaded automatically as part of the
automatic update process – but can be manually downloaded and installed from this web site:
http://www.microsoft.com/downloads/details.aspx?FamilyID=0856eacb-4362-4b0d-8edd-
aab15c5e04f5&DisplayLang=en
In particular, if you receive this error message:
We advise you to download and install the .Net v2 redistributable framework.
FirM AD Service Installation

The FirM AD Windows service has the following pre-requisites:
● It connects back to the FirM processing server, and collects work from the server using a web service
consumer. This means that the FirM processing server needs to run on a Domino v7.x server or above, in
order to provide web services. Note that the Windows service component itself does not use nor require
Microsoft IIS server on the target AD server.
The Domino web site should NOT be set up to use 'session' based authentication. Please refer to the
following section on Domino Authentication types for a detailed explanation and work-around.
● The FirM AD Windows Service should be installed on ALL win2k3 file servers upon which you anticipate
creating user home directories and/or user profile directories. It should also be installed on the nominated
AD server which will process user and group AD operations, as well as any backup server you nominate.

● The windows service requires the Microsoft .Net framework v2 or greater

● It uses a Domino HTTP username and password in order to log into the Domino web service to collect
work. This username and password should have the same level of access to FirM as a normal requester.
○ It then uses a windows-based configuration tool to update the Windows Registry on that server, and
stores the target URL for the web service, as well as the username and the password in encrypted
form. It is possible to copy the registry settings from one server and apply them to any other servers,
as well as installing the Windows Service using a 'silent' installation.
In order to install the FirM AD Windows service on the AD server:

● Open Internet Explorer on the target AD server, and navigate to the following URL:
○ http://<server>/firm/firmrequestprocessor.nsf/InstalFirmAD.html
Where you should replace <Server> with the name of your FirM Processing server
You may have to change the directory name if you have installed FirM in another location.
● You will be prompted for a username and password. Please enter the username and password for a
Domino user who can access the FirM Request processor.
● You will then be presented with an HTML based screen with instructions, and the ability to download and
install the Windows AD service.
Domino Web Service Authentication

The Windows service running on each of the Active Directoryservers uses non-sessionbased authenticationto
securely log into the Domino web service. This means that the URL they use to open the web service cannot
use a 'Login Page' to authenticate– it has to use 'Default'Domino authentication,where the user is prompted for
their username and password.
If you require this server to also support session based users, you may use the Domino 7.x feature 'Internet
Sites' to allow users to log in using session-basedauthentication,whilst also allowing Web Service agents to log
in without using session-basedauthentication.To achieve this:
● Enable 'Use Internet Site Documents'on the first page of the server setup document.
● Create a new Internet Site document for default usage, and enable session-basedauthentication
● Creae a new Internet Site document using a differenthost name, and disable session-based
authentication.
● Enable in DNS the new hostname,pointing at the same IP address as your Domino server.
● Remember to restart your HTTP task to enable these changes.
Please examine the Lotus Administrationmanual on these features if you are unsure of this process.

PAG E 1 2 6 O F 1 8 5 1 5 . I N S TA L L I N G & C O N F I G U R I N G AC T I V E D I R E C TO RY
Logging Information
When this service runs, it creates logging information in the Windows Event log, in the Applications area.
It creates a number of event log entries

on startup. One lists the current
configuration:
A common issue we have encountered is that the Event Log fills up (especially if verbose level debugging is
enabled). In order to prevent the error 'Event Log Full', you can right click on the 'Application' folder on the left
pane and allow the Event Log to overwrite older events.
Heartbeat Task
In normal operation, the FirM AD service will update a document in the FirM Extended AdminP database on the
FirM primary server. This document confirms that this component is “alive” and also reports back on disk space
characteristics for this file server. This allows us to correctly calculate the most relevant win2k3 file server based
on disk space usage to create new users on.
To view this
heartbeat
information,
open the FirM
Extended
AdminP
database
database, click
on “System
Profiles”, and
select “Server
Heartbeat”
Lotus Domino Servers hosting the Extended AdminP database are shown with their full Lotus Notes abbreviated
names, and win2k3 file servers are shown using their short “common” names.
The highlighted entry is a win2k3 file server, and the “status” column shows that the service is running, as well as
the last time the service updated this heartbeat record.
This is a useful test of the functionality of the service, without having to create any FirM transactions.
Share Names
When the FirM AD service runs, it is passed (from the FirM processor, which calculates the share information
based on the FirM AD User Create profile) a directory name of the form:
\\<servername>\<sharename>\<userDirectory>

Where <servername> is the name of the win2k3 file server, the “shareName” is the name of the windows file
share hosting all the users directories, and the <userDirectory> is the name of the directory we shall create for
the user.
For instance
“\\aphrodite\users\Mike Rondin”
indicates the directory “Mike Rondin” in the share “users” on server “Aphrodite”.
This means that the share “users” must be created on this file server and point to a valid directory on the server,
for the FirM AD to be able to establish what that directory is and then create the subdirectory “Mike Rondin”

PAG E 1 2 8 O F 1 8 5 1 6 . F I R M A D T R A N S AC T I O N S E X P L A I N E D
16. FirM AD Transactions Explained

AD User Create
AD User create allows a Requester to create a user in Active Directory
Details relating to the notification of completion of this transaction are stored in the AD User Create profile
documents.
request selection dialog. Now select ‘AD User Create’.
The requester may be prompted for the name of an AD User Create
Profile. Select one and click “Forward”
The user may be prompted to select an Active Directory container to

place the user object into. Click on the small button to the right to
pop up an Active Directory browser:
This browser allows you to navigate to other parts of the Active

Directory hierarchy – use the drop-down box to select a container
to navigate to, and use the “Go to this container” button to select
it.
Enter the following name information:

 First name
 Middle initials
 Last name
Each of these three name values is compared against validation rules in
the System Configuration profile. If the names pass validation rules, then the Active Directory is checked for
uniqueness. If any name fails, the Requester is informed and invited to re-enter them.
If the AD User Create profile has been configured to prompt the
requester for the Password recipient, then the Requester is then
invited to enter the names of:
 One or more people who are to receive an encrypted mail
message containing the user’s password. This is typically the
new user’s immediate manager.
In this case, AD UCR has been configured to prompt the requester for the Password recipient.
Depending on the settings in the User Create profile, the Requester may be prompted for one or more pieces of
‘dynamic’ data, which will then be used to update the new user’s ‘person’ document in the Domino Directory.
If the AD UCR has been configured to allow processing at a later date, the ‘Defer Processing’ dialog box will
appear.

1 6 . F I R M A D T R A N S AC T I O N S E X P L A I N E D PAG E 1 2 9 O F 1 8 5
Details of the AD User Create request are displayed. Clicking Submit

submits this request for processing by FirM.
FirM Processing
Requester and Administrators fields in the User Create profile. If the
request. If vital information is missing (this should not be possible)
then the request will fail, detailing the reasons for failure in the FirM
log and also in the request.
The processor makes exhaustive checks to ensure that the user names requested (Login Name, Common Name -
all are configurable in the AD User Create Profile) are unique across Active Directory.
The Requester then constructs the user object in Active Directory, setting all relevant AD Person object fields. Any
static or dynamic ‘fields’ specified in the AD User Create profile, is also applied, replacing ‘tokens’ with run-time
variables as necessary.
The user’s initial password is stored in the encrypted Password Repository.
A UUP (Resend User ID and Password) request is constructed which will mail the user’s AD Password to the
Password recipients listed in the initial request.
Zero or more AD Group Manage Member requests are created to add the user to groups specified in the AD
User Create profile.
Using the AD User Create profile, the correct Location profile is examined to establish the target file server. If
more than one target mail server is listed, the target server with the most amount of percentage free disk space is
used as the target server (load balancing).
 An Extended Admin4 request is then issued to create the user’s Home and Profile Directories.
Once processing has completed then any people specified within the Notification list for the relevant group profile
will be sent an email telling them that the group has been created.
The request will remain in the state ‘Pending Sub transaction’ until the AdminP requests and the Extended AdminP
Requests have completed. It will then progress to ‘Complete’.
As with all FirM requests, logging information at every stage is created in the Log Database, Audit trail records are
created in the Audit Database, and Billing information is created in the Billing Database.
Configurationfor User Create

FirM searches for the AD User Create profile that governs the creation of a user. The following information in this
profile is relevant to the User Create request:
 Who is allowed to request new users be created using this profile
 Who is allowed to authorise requests using this profile
 Who will be notified when this transaction succeeds.
One or more of the following mandatory Profiles:
 Location Profile. This gives details of one or more target file servers where the user should be created.
Note if more than one target server is created, then the server with the highest percentage free disk
utilised (Automatic Load Balancing).
And zero or more of the following non-mandatory profiles
1. Country
2. Business Group.
Name Construction Information
3. Login Name
4. Common Name
5. User Home Directory and Share
6. User Profile Directory and Share
AD User Disable
AD User Disable create allows a Requester to disable a user in Active Directory.
Details relating to the notification of completion of this transaction are stored in the AD User Disable profile
documents.
Walkthroughof Transaction
If the requesteris allowed to use more than one AD Disable User
profile, the requesteris prompted as to which profile should be used.
The Requesterthen selects the Active Directoryuser that is to be

disabled,by clicking on the selectionbutton on the right of the name
dialog.
The selectionbox allows you to select a user in the selected

container.If the profile allows, you may navigate to another
containerto choose another Active Directoryuser.
The requesteris then shown the transactionsummary pane. The

requestershould then select 'Submit' to complete this transaction.
FirM Processing
valid Requesters defined in the AD User Disable Profile document. If
The processor then find the selected user within the AD environment, and sets the “Disabled” flag to 'true'.
Once processing has completed then any people specified within the Notification list defined in the profile will be
sent an email telling them that the request has succeeded.
AD User Enable
AD User Enable create allows a Requester to enable a user in Active Directory.
Details relating to the notification of completion of this transaction are stored in the AD User Enable profile
documents.

If the Requesteris permittedto use more than one AD Enable profile,
the Requesteris prompted as to which profile to use.
The Requesterthen chooses an Active Directoryuser to enable.
Finally,atransactionsummary pane is displayed.The requestershould

click on “Submit”.
FirM Processing
valid Requesters defined in the AD User Enable Profile document. If the
Requester is not allowed to submit this request then it will fail. A similar
check is performed against the Authoriser of the request.
The processor then find the selected user within the AD environment, and sets the “Disabled” flag to 'false'.
AD User Password Reset

AD User Password Reset create allows a Requester to reset a user's password in Active Directory.
Details relating to the notification of completion of this transaction are stored in the AD User Password Reset
profile documents.
If the requesteris allowed to use more than one AD Reset User
Password Profile, he will be prompted for the AD Reset Password
Profile to use.
The requesterthen selects (using the AD picker button) the user in

which he wishes to set password.
The requesterthen types in a new password for the selected AD User.

A random password is generatedwhich can be overriddenif required.

And finally on the transactionsummary pane, clicks on Submit.
FirM Processing
valid Requesters defined in the AD User Reset Password Profile
request.
The processor then find the selected user within the AD environment, and sets the user password to the one
specified by the Requester.
AD User Modify
AD User Modify allows a Requester to modify a user in Active Directory.
Details relating to the notification of completion of this transaction are stored in the AD User modify profile
documents.
If the Requesteris allowed to use more than one AD Modify User
profile, the Requesteris prompted to select which AD Modification
profile is most relevant for this target user.
The requester then selects a user (using the AD User picker button) to
modify.
The requesterwill be prompted for each dynamic field defined in the

AD User Modify profile, In this example, the requesteris being
prompted for a departmentname to apply to this AD user.

And finally on the transactionsummary screen, clicks “Submit”.
FirM Processing
valid Requesters defined in the AD User Modification Profile document.
The processor then find the selected user within the AD environment, and modifies the specified attributes to the
values selected by the Requester.
AD Group Create
AD Group Create allows a Requester to create a group in Active Directory.
Details relating to the notification of completion of this transaction are stored in the AD Group Create profile
documents.
If the requesteris allows to use more than one AD Group Create
profile, he is prompted for the one to use in this transaction.
If the AD Group Create profile allows it, the requesterwill be prompted

for the containername in which the requestercan create this group.
The requesterthen enters a new Group Name, Descriptionand Group

Type.
The Requestermay populate this group with a list of Active Directory

users at create-time.

On the transactionsummary pane, the Requestershould click on

“Submit” to submit this transactionfor processing.
16.0.1. FirM Processing

valid Requesters defined in the AD Group Create Profile document. If
The processor then ensure that a group of this name does not already exist. It then creates the group in the
correct container, and populates the group with all information entered by the Requester.
16.0.2. Configurationfor AD Group Create

AD Group Delete
AD Group Delete create allows a Requester to create a delete in Active Directory.
Details relating to the notification of completion of this transaction are stored in the AD Group Delete profile
documents.
If the requesterhas a choice in AD Group Delete profiles,select the
relevant group delete profile:
The Requestershould select which Active Directorygroup should be

removed by selectingthe group using the AD Object picker button.
On the transactionsummary screen, the Requestershould click on the

“Submit” button to submit this transactionfor processing.
FirM Processing
valid Requesters defined in the AD Group Delete Profile document. If
The processor then ensure that a group of this name already exists. It then removes the group from the Active
Directory environment.
Configurationfor AD Group Delete

AD Group Modify
AD Group Modify create allows a Requester to modify a group in Active Directory.
Details relating to the notification of completion of this transaction are stored in the AD Group Modify profile
documents.
If the requesterhas the choice of relevant AD Modify profiles,he
should choose the most relevant profile:
The Requestershould choose which group he wishes to modify by

clicking on the AD Object picker.
The Requesteris then prompted to add and remove members from

this group by completingtwo lists of users. Users can be added to
each list by clicking on the relevant AD Object picker button.
The Requestershould then click on the “Submit” button on the

transactionsummary pane to submit this transactionfor processing.
FirM Processing
valid Requesters defined in the AD Group Modification Profile
request.
request.
The processor then ensure that a group of this name already exists. It then updates the groups attributes to reflect
the changes requested.

PAG E 1 3 6 O F 1 8 5 1 7 . C O N F I G U R I N G A D T R A N S AC T I O N S
17. Configuring AD Transactions

Common Authorisation Tabs
On each of the Active Directory profiles, an “Authorisation” tab allows you to control:
● Requesters – who may request a transaction of this type.
● Authorisors – who may authorise a transaction of this type
● Notification – who is notified when a transaction of this type succeeds
● Manage Users/Groups – defines upon which container this transaction is allowed to be performed. Note
that in terms of Active Directory transactions, delegation is at container level.
● Defer – define whether or not this transaction may be deferred, and if so, the default parameters.
This dialog defines the list of users – using hierarchical wildcards such as
“*/Acme”, or groups – the list of NOTES user ID's which are allowed to
perform this transaction.
This dialog defines the list of users – using hierarchical wildcards such as
“*/Acme”, or groups – the list of NOTES user ID's which are allowed to
authorise this transaction. Should a person who's name appears in both
the Requesters and Authorisors list submit a transaction
People listed in the Notification tab (using their Notes ID name) will be
notified should any transaction using this profile succeed.
The “Manage Users/Groups” tab allows you to define a container on

which this transaction may be executed. That is, a requester of a
transaction using this profile may only select users or groups to manage
from this Active Directory Container. The “Allow Subcontainers” radio
button allows you to delegate users or groups from subcontainers of
this container.

1 7 . C O N F I G U R I N G A D T R A N S AC T I O N S PAG E 1 3 7 O F 1 8 5
The “Defer” tab defines whether or not transactions using this profile
are allowed to be deferred to a future date, and if so, the default date
which should appear to the requester.
AD User Create
The Active Directory User Create profile allows the definition of Active Directory user create transactions. These
transactions create new user objects in your Active Directory environment.
The “Name” tab allows you to define the name of

this Active Directory profile. Care should be taken
to choose a name that is meaningful to your
Requesters – as they may see this name if they are
given the choice of more than one Active Directory profile.
The Fields and Groups tab allows you to define

common AD user object attributes that you can
either define in the profile, or prompt the
requester to define at run time. Multiple attributes
can be defined by placing each attribute on a
separate line. Use the “Keyword” button to show
a list of all attributes allowed against User Objects
in Active Directory.
An example of a list of valid Active Directory
attributes shown when clicking the “Keyword”
button.
The default AD groups option allows you to define one or more groups in Active Directory that this new user
should automatically be added to. Use the “Select” button on the left to browse your Active Directory
environment to select groups. As you can see from this example, we expect the group name to be defined in LDAP
format, using the groups full hierarchical name.
The “Names & Shares” tab allows you to define

naming information and shared directories for new
Active Directory users.
The first tab - “Active Directory Naming” - allows

you to define which name components are used
to create the users AD object.
● “User Login Name” defines what the
user will actually log in as
● “User Common Name” may be the same
as Login Name
● “Container” defines which container the user shall be created in.
● If the “Sub-Containers” radio button is set to Yes, then the requester (at run-time) may choose a
subcontainer of the one defined here.

The “User Home Directory” tab allows you to

define the name of the user home directory, and
whether or not it is shared.
● “User Home Directory” defines the
name of the home directory by using
tokens.
● If defined, the “User Home Directory
Share Name” will allow definition of a
share name to be applied to this user's
home directory.
● Directory Administrators define which
groups or users should be set as
administrators of the users home
directory on completion.
● Home Drive allows the definition of a home drive letter, which will be set on the AD User Object.
The “Profile” tab allows you to define the name of

the user profile directory, and whether or not it is
shared.
● “User Profile Directory” defines the
name of the home directory by using
tokens.
● If defined, the “User Profile Directory
Share Name” will allow definition of a
share name to be applied to this user's
home directory.
If “Script File Name” is defined, then the script file

selected from the list of System Script files, will be
ran after the users home drive is created.
The Sub-profiles tab allows you to define system

profiles that are associated with this AD User
create profile tab. In the same manner as the
Domino User Create profile, selecting two or
more sub-profiles from each list delegates the
decision as to which sub-profile to use to the
requester at run time.
The first sub-profile to be defined is “Location”,
which defines which Active Directory file server
the users home drive and profile drive will be
created on.
The following sub-profiles are non-mandatory, and allow you to optionally provide more flexibility by allowing you
to define AD groups and fields.
● Business Groups
● Companies
● Country
● ID Types

1 7 . C O N F I G U R I N G A D T R A N S AC T I O N S PAG E 1 3 9 O F 1 8 5
The Password tab allows you to define how the

newly created AD User password will be
distributed.
AD User Disable
The Active Directory User disable profile only prompts you to define
the name and description. All authorisation for this activity is defined
using the (common) Authorisation tab.
AD User Enable
The Active Directory User enable profile only prompts you to define
the name and description. All authorisation for this activity is defined
using the (common) Authorisation tab.
AD User Password Reset

The Active Directory User Password Reset profile only prompts you to
define the name and description. All authorisation for this activity is
defined using the (common) Authorisation tab.
AD User Modify
The 'Details' tab of Active Directory User Modification profile prompts
you to define the name and description. Remember - all authorisation
for this activity is defined using the (common) Authorisation tab.
The “Fields” tab allows you to define which AD User Object attributes
will be updated for the target user. In this case, we are hard-coding the
'company' and 'homePhone' attributes to values defined in the profile.
Two buttons - “K” and “D” - are available. The “K” button pops up a list
of attributes available for modification, and the “D” button allows you to
use the dynamic field helper to build one or more prompts for the requester at run-time. Each attribute defined in
each prompt will be updated by the AD User Modification transaction.
In order to see which AD

attributes are available for
modification, click on the
'K' Button. A list will be
displayed allowing you to
select a value.

AD Group Create
The 'Details' tab of Active Directory Group Create profile prompts you
to define the name and description. Remember - all authorisation for
this activity is defined using the (common) Authorisation tab.
AD Group Delete
The 'Details' tab of Active Directory Group Delete profile prompts you
to define the name and description. Remember - all authorisation for
this activity is defined using the (common) Authorisation tab.
AD Group Modify
The 'Details' tab of Active Directory Group Modification profile
prompts you to define the name and description. Remember - all
authorisation for this activity is defined using the (common)
Authorisation tab.

1 8 . B L AC K B E R RY OV E RV I E W PAG E 1 4 1 O F 1 8 5
18. BlackBerry Overview

The BlackBerry component within FirM allows basic management of BlackBerry handsets in your Domino
environment.
Architecture.
The FirM BlackBerry interface relies on the BlackBerry Enterprise Server Resource kit (BRK). A copy of this kit has
to be installed on the FirM primary (and optionally secondary) processing servers.
BES Serv er 1
Domino
BES Serv er 2 Hand set
BES Serv er 3
BRK Client
FirM Primary Processing Serv er
Requests entered in the FirM request processor database are then processed on the FirM primary processing
server. This server, once the request has been validated will then make calls to the BlackBerry Resource Kit client
executable. This in turn will make network calls to the relevant BlackBerry Enterprise Server on your intranet, and
perform the required transactions.
From a network perspective, this means that the FirM Processing Server(s) and all BlackBerry Enterprise servers
require to be able to communicate with each other, using whatever network protocol is utilised by the BES server.
As all BlackBerry components are windows based, this does mean that the FirM Primary and Secondary processing
Domino servers also have to be windows based.

PAG E 1 4 2 O F 1 8 5 1 9 . I N S TA L L I N G T H E B L AC K B E R RY I N T E R FAC E
19. Installing the BlackBerry interface

We advise using v4.x or above of the BlackBerry Enterprise Server Resource Kit (BRK).
The BRK can be downloaded from: http://www.blackberry.net/support/downloads/resourcekit.shtml
1. Install the tool as directed in the Resource Kit instructions.
● You need to install the “BesUserAdminClient” service on the FirM Primary (and optionally
secondary) processing servers.
● You need to install the “BesUserAdminService” on each of the BES Enterprise servers you wish to
manage.
● You will be asked to enter a password in the resource kit during the installation. If you are installing
the BRK in both the FirM primary and secondary processing servers, ensure that the same password
is used. This password will then be lodged in the FirM Password repository using the button on the
Configuration Profile form. See page 40 for more information.
● If you are installing the BRK on the primary and the secondary FirM processing servers, please install
the toolkit to the same location, and enter the full path and executable file into the Configuration
Profile – BlackBerry tab. See page 40 for more information.
2. Test that the BRK is functioning by running the “BESUserAdminClient” with a test transaction from the
command line.
3. Set the Domino server service to log on using a user account rather than the system logon.
● In order that the Domino server application can communicate with the BRK, it is necessary for the
Domino service to be started with a user account rather than the system account.
4. Enable the BlackBerry components within the FirM Processing database. See “System Configuration –
BlackBerry” on Page 40 for more information.
5. Associate one or more BES servers with each relevant location. See the section “Location Profiles -
BlackBerry servers tab” on page 52
6. Create one or more BlackBerry Profiles. See the section titled “Configuring BlackBerry Transactions” on
page 146.
7. Create new FirM requests using these profiles.

2 0 . B L AC K B E R RY T R A N S AC T I O N S E X P L A I N E D PAG E 1 4 3 O F 1 8 5
20. BlackBerry Transactions Explained

This section shows the end-user experience and interaction in creating transactions for BlackBerry Transactions.
Authorisation
The Authorisation process for BlackBerry transactions mirror that for Domino User transactions:
● A list of potential Requesters are defined on the relevant transaction profile document. Only Requesters
listed on that transaction document can create transactions based on that profile.
● A list of Authorisers is listed on that transaction. If a requester is also on the list of Authorisers, then the
transaction is immediately processed.
● A list of name masks is defined on the profile document, showing who this transaction can be applied
against, using that users Lotus Notes name.
BlackBerry Provision
BlackBerry Provision allows you to associate a Lotus Domino mail user with a new BlackBerry device.
To create new request, select“New Request” and click forward to the request selection dialog. Now select
‘BlackBerry Provision’.
The requester may be prompted for the name of a user create profile. Select one and click “Forward”
Select the user you wish to provision, and click Forward.

At this point, the BlackBerry provision transaction will look up the users
home mail server, and try and establish if this home server is associated
with a location which has a BlackBerry server associated with it. If not,
the requester will be prompted to select another user.
If the users home mail server is associated with more than one location,
then the requester is prompted to select the location that the user is
actually associated with (in order to choose the correct BlackBerry
Enterprise server). If the user's mail server is only associated with one
location, then that location will be displayed.
An activation password is generated, which the requester may optionally
override.
Once completed, the requester should click “Forward”
Details of the BlackBerry provision request that is being submitted are

processing by FirM.

PAG E 1 4 4 O F 1 8 5 2 0 . B L AC K B E R RY T R A N S AC T I O N S E X P L A I N E D
BlackBerry Enable
This transaction enables “Mobile Data Service” for a BlackBerry handset user. This is enabled by default when a
new user is created – therefore this transaction is only of value if a BlackBerry handset user has previously been
disabled.
‘BlackBerry Enable’.
The requester may be prompted for the name of a BlackBerry Enable profile. Select one and click “Forward”
Select the user you wish to enable, and click Forward.
Details of the BlackBerry Enable request that is being submitted are

processing by FirM.
BlackBerry Disable
This transaction disables “Mobile Data Service” for a BlackBerry handset user. This is of value if a user does not
wish to use their BlackBerry handset for a short period of time – say – whilst on vacation.
‘BlackBerry Disable’.
The requester may be prompted for the name of a BlackBerry Disable profile. Select one and click “Forward”
Select the user you wish to disable, and click Forward.
Details of the BlackBerry Disable request that is being submitted are

processing by FirM.

2 0 . B L AC K B E R RY T R A N S AC T I O N S E X P L A I N E D PAG E 1 4 5 O F 1 8 5
BlackBerry Reset Password

This transaction allows a requester to reset the password on a users BlackBerry handset.
‘BlackBerry Reset Password’.
The requester may be prompted for the name of a BlackBerry Reset Password profile. Select one and click
“Forward”
Select the user you wish to manage, and click Forward.
A new BlackBerry Handset password is generated, which the Requester

may override.
Click Forward to continue.
Details of the BlackBerry Reset Password request that is being submitted

are displayed on the screen. Clicking Submit will submit this request for
processing by FirM.
BlackBerry Delete
This transaction deletes the association between the BlackBerry server and a Lotus Domino mail user.
request selection dialog. Now select ‘BlackBerry Delete’.
The requester may be prompted for the name of a BlackBerry Delete
profile. Select one and click “Forward”
Select the user you wish to delete, and click Forward.
Details of the BlackBerry Delete request that is being submitted are

processing by FirM.

PAG E 1 4 6 O F 1 8 5 2 1 . C O N F I G U R I N G B L AC K B E R RY T R A N S AC T I O N S
21. Configuring BlackBerry Transactions

All BlackBerry transactions rely on relevant profile documents being set up, and all share the same authorisation
mechanism (and same common “Authorisation tab”) that Domino User transactions employ. See section
“Common Tab – Authorisation” on page 94 for more information.
BlackBerry Provision
The BlackBerry Provision Profile allows you to define:
● The name of this profile
● which one of the BlackBerry Enterprise Server
handset profiles (defined in the BlackBerry section
of the configuration document – see page 40) handsets provisioned from this profile will be set to.
BlackBerry Enable
The BlackBerry Enable Profile allows you to define:

BlackBerry Disable
The BlackBerry Disable Profile allows you to define:
BlackBerry Reset Password

The BlackBerry Reset Password Profile allows you to
define:
BlackBerry Delete
The BlackBerry Delete Profile allows you to define:


2 2 . T H E F I R M A P P L I C AT I O N M O N I TO R PAG E 1 4 7 O F 1 8 5
22. The FirM Application Monitor

The FirM application monitoring suite is a new addition to FirM v2.1. This allows the Administration staff of a
Domino environment to track more effectively the application usage throughout the Domino environment.
Architecturally, it comprises two databases. These databases should be replicated to each server (and any
intermediate server on your replication path) upon which you wish to measure and track application usage.
Two scheduled agents exist within this database. These can be

enabled via the “Tools, Validation,Scheduled Agents” control
panel:
The Application Monitor Database

The Application Monitor database contains:
 Summary information on each database instance on every server throughout your environment.
 ACL information for each database instance.
 ACL Change log information for each application instance.
 Optional Template copies of each application
 Optionally “Design Complexity” information for each application instance.
To open the Application Monitor database, open the database “firmapplicationmontior.nsf” in your FirM
directory on the main FirM processing server, or click on the Icon.
Double clicking on an Application instance document:. The Details tab shows:

 The Application Title
 Application Type
 Instance status – 0 means “Discovered”
 The Application Replica ID
 The server that this instance is hosted on.
 The File Path of the application instance
 Whether the database instance has been removed from the server, and ifso, when it was deleted.
The “Size” tab shows size information for this instance, and when it was last
updated.
The “ACL” tab shows all instances of this database. Double clicking on one shows
the current ACL of this database:

PAG E 1 4 8 O F 1 8 5 2 2 . T H E F I R M A P P L I C AT I O N M O N I TO R
This shows a Database current

Access Control List, and the time
that it was collected
The “ACL Log” tab shows all ACL modifications for all
instances of this application.
The “Instances” tab shows all instances of this database, and

current size information for each instance.
The “Used By” Tab shows usage information for this database,
and allows easy access to the Application Usage database to
highlight actual user usage.

2 2 . T H E F I R M A P P L I C AT I O N M O N I TO R PAG E 1 4 9 O F 1 8 5
The Application Usage Database

The Application Usage Database contains a combined User Activity record for every single database instance in
your environment.
This allows the tracking of Application usage for security and maintenance/operational reasons.
You can browse the database and open a particular tracking

event – this shows application static information such as
Title, Replica ID, server, FilePathand file name, as well as
event information such as User ID, date & time, reads and
writes, transactions and duration.

PAG E 1 5 0 O F 1 8 5 2 3 . T H E F I R M WE B I N T E R FAC E
23. The FirM Web Interface

Web Interface Configuration
New in FirM v2.1.01 is a web-interface for the FirM
Request Processing database. This is enabled by:
 Enabling the system configuration profile, Admin
Settings tab, Web Interface Tab“Enabled” button
to “Yes”.
 Modifying the ACL of your FirM Request
processor ACL to allow Author access to “web”
users. This is done in the “Advanced ACL” section:
 Users should ONLY access the FirM web interface

on the primary or secondary processing server.
Web Interface Client Experience

One Firm has been configured, you can then open the
FirMRequestProcessor.nsf database using a web
browser:
Clicking on the “New Request” button shows the

current subset of requests that the currently logged-in
user can perform. Note that at v2.1.01, only a sub-set of
user requests has been implemented:
Initiate a request by clicking on its name. In this case, we shall

perform a User Disable:
On many requests, a “User Name” picker is available. Clicking on “Select User”

pops up a new window, which allows you to select a username from your directory:
Clicking on the “Submit” button then submits the request and shows its status:
This request has now been successfully created, and is awaiting processing.The “Stop” button allows you to close
this window.

2 4 . I M P O RT I N G T R A N S AC T I O N S U S I N G C S V PAG E 1 5 1 O F 1 8 5
24. Importing Transactions using CSV

FirM allows transactions to be imported via a CSV file. This is of value where a large number of changes need to be
performed in a short period of time.
CSV File Overview

A CSV (Comma Separated File) is a text file,
 Where each data row is on a separate line
 Where each item of data is separated with a comma
 Where strings which may contain commas are surrounded by double inverted comma quotes
 Where the first line defines the field names contained in the file.
For example, a very simple CSV file might look like:

Name,address,postcode,phone number
“Joe Bloggs”, “1 The Penthouse, Anytown, England”, “PE1”, 0555-555-5555
The fields “Name”, “Address”, “Postcode”, “Phone Number” are

defined in the top line, and the file contains one record for “Joe
Bloggs”.
The simplest way to generate a CSV file is to use a spreadsheet,
laying out columns and rows to mimic this:
You can then save the spreadsheet as a

CSV file. In most packages, “File”, “Save As”
offers a CSV file format:

PAG E 1 5 2 O F 1 8 5 2 4 . I M P O RT I N G T R A N S AC T I O N S U S I N G C S V
Importing Transactions Using CSV

FirM imports one CSV file at a time. This file may contain one
or more transactions, and transactions need not be of the
same type.
In order to import a CSV file, select “Tools”, and then choose
the “Import” Tab, and the “CSV” Subtab:
Entries common to all CSV import lines

The following entries are common to all CSV data lines.
Column Name Value

Transaction The transaction code for this transaction. See the
following section for a list of all transaction codes.
TransactionProfile A profile relevant for this transaction, which has already

been defined in FirM, and which the requester importing
the request has the authority to use.
FirM transactionCodes
The following FirM transactions have the ability to be imported via the CSV import interface.
Transaction Name Transaction Name

UCR User Create GCR Group Create
UDE User Delete GDR Group Delete
UDI User Disable GMM Group Manage Membership
UEN User Enable GMO Group Modify
UMA User Grant Mail file Access
UMO User Modify Transaction Name
UMS User Move to another Server BPR BlackBerry Provision
UMV User Move in Hierarchy BRP BlackBerry Reset Password
UPD User Password Digest Disable BDI BlackBerry Disable
UPE User Password Digest Enable BEN BlackBerry Enable
UPR User Password Digest Reset BDE BlackBerry Delete
URC User Rename Common Name
URE User Recertify
URP User Reset HTTP Password
UUP User Resend ID and Password
URMD User Roaming Enable
URME User Roaming Disable
UCC User Cross-Certify
UML User Move Location
UMQ User MailFile Quota
UMD User Move Domain

User Create CSV Definition

Header Field Mandator Comments
y
Transaction Yes This should always be “UCR”
TransactionProfile Yes A User Create profile defined in FirM
NewFirstName Yes The new users’ first name
NewMiddleInitials Depends on The new users’ middle initials field
UCR Profile
NewLastName Yes The new users’ Last or Family name
BusinessGroupProfile See Note The name of the Business Group profile to be used
Below during this user creation.
CertifierProfile See Note The name of the Certifier profile to be used during
Below this user creation.
CompanyProfile See Note The name of the Company profile to be used during
CountryProfile See Note The name of the Country profile to be used during
IDProfile See Note The name of the ID Profile to be used during this
Below user creation.
LocationProfile See Note The name of the Location profile to be used during
IDRecipients Yes One or more users who shall receive the ID file
created for this user. Separate multiple recipients
with the semi-colon (“;”) character.
PasswordRecipients Yes One or more users who shall receive the password
automatically created for this user. Separate multiple
recipients with the semi-colon (“;”) character.
AlternateName No A users Alternate Name.
An example CSV file for a User Create Transaction would look like:
Transaction, TransactionProfile, NewFirstName, NewMiddleInitials, NewLastName, BusinessGroupProfile,
CertifierProfile, CompanyProfile, CountryProfile, IDProfile, LocationProfile, IDRecipients, PasswordRecipients
“UCR, “Default UCR Profile”, “Joe”, “”, “Bloggs”,“Business Group Profile Name”, “Certifier Profile Name”,
“Company Profile Name”, “Country Profile Name”, “ID Profile Name”, “Location Profile Name”, “My IT
Support/MyCo”, “My Boss/MyCo”
User Delete CSV Definition

y
Transaction Yes Should always be “UDE”
TransactionProfile Yes A User Delete profile defined in FirM
UserName Yes A fully hierarchical name identifying the user for this
transaction
DataOwner No The name of a person who will “own” this users mail
file.
DeletionDate Yes The date on which this user will actually be
removed.
An example CSV file for a User Delete would look like:
Transaction, TransactionProfile, UserName, DataOwner, DeletionDate

“UDE, “Default UDE Profile”, “Joe Bloggs/MyCo”, “”, “01/01/2005”
User Disable CSV Definition

y
Transaction Yes Should always be “UDI”
TransactionProfile Yes A User Disable profile defined in FirM
transaction
An example CSV file for a User Disable transaction would look like:
Transaction, TransactionProfile, UserName
“UDI, “Default UDI Profile”, “Joe Bloggs/MyCo”
User Enable CSV Definition

y
Transaction Yes Should always be “UEN”
TransactionProfile Yes A User Enable profile defined in FirM
transaction
An example CSV file for a User Enable transaction would look like:
Transaction, TransactionProfile, UserName
“UEN, “Default UEN Profile”, “Joe Bloggs/MyCo”
User Rename Common Name CSV Definition

y
Transaction Yes Should always be “URC”
TransactionProfile Yes A User Rename Common Name profile defined in
FirM
transaction
NewFirstName Yes The users new First Name field
NewMiddleInitials Yes The users new Middle Initials field
NewLastName Yes The users new Last Name field
OptionalOU No The users new Optional Organizational Unit
An example CSV file for a User Rename transaction would look like:
Transaction, TransactionProfile, UserName, NewFirstName, NewMiddleInitials,NewLastName, OptionalOU
“URC, “Default UCE Profile”, “Joe Bloggs/MyCo”, “Joseph”,“”, Bloggs”, “”
User Grant MailFile Access CSV Definition

y
Transaction Yes Should always be “UMA”
TransactionProfile Yes A User Mail file Grant Access profile defined in FirM
transaction
DDODuration Yes The time, in days, that a DDO should be allowed
access to this users mail file
DataOwner Yes The name of the data owner
An example CSV file for a User Grant Mailfile Access transaction would look like:
Transaction, TransactionProfile, UserName, DDODuration, DataOwner
“UMA, “Default UMA Profile”, “Joe Bloggs/MyCo”, 3,“My Boss/MyCo”
This transaction would allow “My Boss/MyCo” access to “Joe Bloggs/MyCo”’s mailfile fot three days.
User Move Server CSV Definition

Header Text Mandator Comments
y
Transaction Yes Should always be “UMS”
TransactionProfile Yes A User Move Server profile defined in FirM
transaction
TargetServer Yes The name of the target server to which you wish to
move this user.
TargetMailDb Yes The users target mail file name on the new server.
An example CSV file for a User Grant Mailfile Access transaction would look like:
Transaction, TransactionProfile, UserName, DDODuration, DataOwner
“UMA, “Default UMA Profile”, “Joe Bloggs/MyCo”, 3,“My Boss/MyCo”
This transaction would allow “My Boss/MyCo” access to “Joe Bloggs/MyCo”’s mailfile fot three days.
User Move in Hierarchy CSV Defintion

y
Transaction Yes UMV
TransactionProfile Yes A User Move in Hierarchy profile defined in FirM
transaction
NewHierarchy Yes The new hierarchy that this user is moving to
OptionalOU No Any optional OU that the user should be inserted in
the users hierarchical name.
User Password Digest Disable CSV Definition

y
Transaction Yes UPD
TransactionProfile Yes A User Password Digest Disable profile defined in
FirM
transaction
User Password Digest Enable CSV Definition


y
Transaction Yes UPE
TransactionProfile Yes A User Password Digest Enable profile defined in
FirM
transaction
User Password Digest Reset CSV Definition

Header Text Mandatory Comments
Transaction Yes UPR
TransactionProfile Yes A User Password Digest Reset profile defined in FirM
transaction
User RecertificationCSV Definition

Transaction Yes URE
TransactionProfile Yes A User Recertify profile defined in FirM
transaction
OptionalOU No An Optional OU to recertify this user with.
User Reset HTTP Password CSV Definition

Transaction Yes URP
TransactionProfile Yes A User Reset HTTP Password profile defined in FirM
transaction
NewPassword Yes The users new password
User Resend User ID and Password CSV Definition

Transaction Yes UUP
TransactionProfile Yes A User Resend ID and Password profile defined in FirM
transaction
IDRecipients Yes The ID file will be sent to these people
PasswordRecipients Yes The Password will be sent to these people
User Roaming Enable Definition

Transaction Yes URME
TransactionProfile Yes A User Roaming Enable profile defined in FirM
transaction

User Roaming Disable Definition

Transaction Yes URMD
TransactionProfile Yes A User Roaming Disable profile defined in FirM
transaction
User Cross Certify Definition

Transaction Yes URCC
TransactionProfile Yes A User Cross Certify profile defined in FirM
transaction
User MailFile Quota Definition

Transaction Yes UMQ
TransactionProfile Yes A User MailFile Quota profile defined in FirM
transaction
User Move Location

Transaction Yes UML
TransactionProfile Yes A User MailFile Quota profile defined in FirM
transaction
CurrentLocation Yes The current user location
NewLocation Yes The users new Location
NewHierarchy Yes The users new Hierarchy, if required.

Group Create CSV Definition

Transaction Yes GCR
TransactionProfile Yes A Group Profile defined in FirM

GroupName Yes The User Text of the group name
Domain Yes The Domain that this group should be created in
GroupDescription Yes The textual Description of this group
GroupOwner Yes The full hierarchical name of this group owner
GroupManagersToAdd Yes One or more full hierarchical names of Group Managers (separated
by Semi-colon characters)
Group Modify CSV Definition

Transaction Yes GMO
GroupName Yes The group name as shown in the directory

GroupDescription No A new Group Description
GroupOwnersToAdd No A new fully hierarchical name for a group owner to add
GroupOwnersTo No A new fully hierarchical name for a group owner to remove
Remove
GroupAdministrators No One or more fully hierarchical names for group Administrators to
ToAdd add (separated by semi-colon characters)
GroupAdministrators No One or more fully hierarchical names for group Administrators to
To Remove remove (separated by semi-colon characters)
Note that a valid Group Modify must have at least one of the non-mandatory fields defined to be valid and effect
any changes
Group Delete CSV Definition

Transaction Yes GDR
GroupName Yes The Group name as it appears in the directory
Domain Yes The Notes Domain in which this group belongs
Group Manage Members CSV Definition

Transaction Yes GMM
GroupName Yes The GroupName as it appears in the Domino Directory
Domain Yes The Notes Domain in which this group belongs
MembersToAdd No Full Hierarchical names of users to add to this group, separated by
semi-colon characters
MembersToRemove No Full Hierarchical names of users to remove to this group, separated
by semi-colon characters

Note that a valid Group Manage Members transaction must have at least one of the non-mandatory fields defined
to be valid and effect any changes
BlackBerryProvision Defintion
Transaction Yes BPR
TransactionProfile Yes A BlackBerry Provision profile defined in FirM
UserName Yes A fully hierarchical name identifying the user for this transaction
Password Yes The users activation Password for Blackberry
Location Yes The name of a location (as you have defined within FirM) that the
users home server is associated with, and has a BlackBerry server
associated with it.
BlackBerryReset Password Defintion

Transaction Yes BRP
TransactionProfile Yes A BlackBerry Reset Password profile defined in FirM
Password Yes The users new handset password
BlackBerryEnable Defintion
Transaction Yes BEN
TransactionProfile Yes A BlackBerry Enable profile defined in FirM
BlackBerryDisable Defintion
Transaction Yes BDI
BlackBerryDelete Defintion
Transaction Yes BDE


PAG E 1 6 0 O F 1 8 5 2 5 . F I R M G RO U P M O N I TO R I N G
25. FirM Group Monitoring

Group Monitoring Explained
The FirM Group Monitor is designed to tell you if the membership of a critical group was changed without using
FirM.
For example, if you use FirM to manage the group “High Sensitivity Mailing List” then you will have set up
ownership and delegation such that only certain people are authorised to change it's membership.
It is possible that somebody has inappropriate access to the Domino Directory and is able to modify the group
membership directly, adding themselves to this group in order to be the recipient of sensitive emails.
So, the group can be flagged as being monitored, and FirM will alert you to changes of this group's membership that
did not occur through FirM, which now gives you assurance that user in the environment cannot silently use round-
about means to gain access to the group's mailings.
Group Monitoring Components

There are 4 components to FirM Group Monitoring:
 The “Shadow Group Monitoring” agent
 The FirM Monitored Group Shadow repository database
 Settings within the group's entry in the FirM Group Repository
 The “GSR-Group Change” notification profile
The Shadow Group Monitoring agent provides the engine that periodically checks groups and issues warnings of
changes. This can be configured to run at any periodic interval – hourly, daily,weekly, etc.
The FirM Monitored Group Shadow repository database contains reference copies of the groups and their
contents. Every time the Shadow Group Monitoring agent runs it checks for monitored groups and creates and
deletes these documents as required. If a group's content differs from the contents of it's entry in the shadow
repository then the monitor creates and sends a notification, and then updates the membership contents of the
shadow repository document so that persistent notifications are not created.
The group's entry in the FirM Group Repository contains a check box field that tells the group monitor whether it
should check this group for changes or not.
Finally, the notification profile is the template that is used by the group monitor when it creates notification. You
can tailor this notification to your exact requirements.
Setting up Group Monitoring

The Shadow Group Repository will have been created and configured by the FirM Installer and must have a valid
path specified in the FirM Configuration Profile (this is under the “Databases\Group Register” tab). If the Shadow
Group Repository database is not present then you will need to download and install the latest version of FirM.
Review the text of the notification profile “GSR – Group Change” and change if necessary. By default, the
notification is set to mail the “<DEFAULTADMINISTRATOR>” tag withany warnings – this tag is replaced by the
Shadow Group Monitoring engine with the names of the users and groups specified in the FirM Default
Administrators setting of the FirM Configuration Profile.
Now you must enable the Shadow Group Monitoring agent. Under the Tools Menu select the “Validation” tab, and
click on the “Refresh Agent Status” button. (See the subsection called “Validation Tab” in the “Administration
Tools” section on page .)
Locate the entry for the Shadow Group Monitoring agent and ensure that it is set to run on the correct server – if
not, click on the server name and choose the correct server from the displayed list.
Finally, enable the agent by clicking on the red diamond. This should change to a green diamond once the agent has
been enabled.
Selecting the Groups to Monitor

You must manually mark groups that should be monitored by editing their entries in the FirM Group Repository.

2 5 . F I R M G RO U P M O N I TO R I N G PAG E 1 6 1 O F 1 8 5
 Open the firm Group Repository database and select a suitable view to locate the group's entry;
 Locate the entry for the group that you want to monitor and double click on it to open the document;
 Select the “Details” tab;
 Select the check box field “Report unauthorised changes to this group”; and finally
 Save and close the group entry
See the sub-section titled “Group Registry” in the “FirM Databases” section on page 174 for more information.
When the Shadow Group Monitor agent next runs, it will create a shadow entry for this group. Whenever the
group membership changes and there is no corresponding FirM Group Manage Members request for the group
then it will report that the group has been modified.
Limitations of Group Monitoring

Whenever FirM processes a Group Manage Membership request it will update the group's entry in the FirM
Monitored Group Shadow database to reflect the new membership.
However, some processessuch as the Domino Administration Process will also change group membership for such
tasks as user/group deletes and renames. In the current version FirM will report changes made by AdminP as being
unauthorised changes.
Therefore it is recommended that only sensitive groups are monitored for changes, and that the alert list for
modifications is kept fairly small.
You may also consider changing the text on the notification profile so that it warns the recipient that the
notification may have happened as part of a user delete or rename.
In order for FirM Group Monitoring to be able to monitor a group's content, the group must have been imported
into FirM for management, or the group must have been created using FirM. It is the action of importing or
creating a group that will create the group's entry in the FirM Group Repository.

PAG E 1 6 2 O F 1 8 5 2 6 . I D B AC K U P, R E F R E S H A N D E S C ROW
26. ID Backup, Refresh and Escrow

Within a corporate Lotus Domino environment, user ID file management, recovery and auditability are key security
policies. Security within this area should be rigorous and well understood.
FirM will automatically enable you to meet a basic requirement of ID file management, which is to keep secure
copies of all new user IDs and passwords that are created. However, oncethese IDs are distributed to the Notes
clients and actions such as renames, recertifications, moves, etc are performed against the users there is a problem
in that the local Notes workstation copies of the ID files will be updated but not the stored copies.
If loss or irrecoverable software failure occurs on the local computers then you need to be able to restore the
latest version of the ID files – this is especially important in environments that implement the password
checking/digest features of Notes & Domino, or where private encryption keys are used.
FirM incorporates two features that will help you to ensure that stored IDs are always kept up to date – ID Backup
and ID Escrow.
ID Backup is a process that monitors the administration request databases looking for requests that will trigger
changes to the users' ID files. The users who are the subject of these requests will then receive an email that will
enable them to lodge the updated copy of their ID file and password with FirM. The advantage of this method is
that the ID and password combination lodged with FirM is available for immediate use when restoring a
workstation. The disadvantage is that it requires user interaction.
ID Escrow is a process that will leverage the Password Recovery mechanism within Notes and Domino, and lodge
copies of returned IDs in FirM. The advantage of this mechanism is that no user interaction is required. However,
the disadvantage is that the IDs recovered are not immediately useable when restoring an end-user workstation,
and the password recovery procedure must be performed on the ID prior to use.
We recommend that you configure and enable one of these ID maintenance features, but both features must
not be enabled simultaneously.
ID Backup
ID Backup is the process that will actively monitor administration requests that modify the user's ID file, send an
email the user (requesting that they lodge a backup of their ID and password) and process the returned IDs and
passwords so that they are securely stored in FirM's ID and Password repositories.
We recommend enabling this process so that it runs on a periodic basis once per day. The process for ID backup
is as follows:
 ID Backup monitors all Administration Process (AdminP) databases for domains managed by FirM for new
requests of type “Rename User”, “Recertify User” and “Update User Password”.
 When a request is found ID Backup checks for an outstanding request for the user to lodge the password
& ID. If no current request is found then an email is sent to the user requesting that they lodge their ID
and password. This email contains a rich-text button containing code to return the user's ID and
password. A temporary document is created in the Escrow database – this document contains details of
the status of the backup request, all matching AdminP requests for this user, number of reminders sent,
alternative user names, etc. It has an initial status of “Pending”.
 When the end user clicks on the button in the email it will check that they are the mail file owner (this
ensures that incorrect IDs cannot be lodged inadvertently by someone using delegation privileges to
access a mail file), locate the current ID, ask for the password and then create two return emails – one for
the ID file and one for the password. These emails are additionally encrypted (using the public key in the
Escrow database mail-in database document), which ensures that IDs and passwords cannot be
intercepted at any stage of the mail routing.
 ID Backup monitors these returned emails, and will then create encrypted documents in the FirM ID and
Password repositories. The email returned from the user is removed, and the temporary backup request
document is updated with a “completed” status.
 ID Backup also monitors outstanding notifications with a status of “Pending”. If a response has not been
received from the user within a set period of time then it will send a reminder to the user – the total
number of reminders sent to a user for any outstanding request can be specified in the ID Backup
configuration settings.

2 6 . I D B AC K U P, R E F R E S H A N D E S C ROW PAG E 1 6 3 O F 1 8 5
 Temporary request documents for Completed backup notifications will be retained for a period of time
(in order to prevent repeated requests to back up IDs being triggered by the same AdminP request).
After this time they will be removed from the Escrow database.
Configurationof ID Backup
A few simple steps must be followed to configure and enable ID Backup:
 Create a new mail-in database document in your Domino Directory:
 The mail-in name must be “escrow”
 The domain, server name and file name must point to your copy of the FirM Escrow Agent database
 Under the “Administration” tab you will find a section called “Certificates”. You must copy the
public key of the FirM Primary Processing Server into the “Notes certified public key” field (the
server's public key can be found in the “Certified public key” field under the Administration tab of
the server document – this field is only visible for a user with editor or above access, when the
document is in edit mode). Note – if the public key is not present in this document then users will be
presented with a dialog “this email could not be encrypted – ok to send?” when they click on the button in
the backup request email.
 Save and close this mail-in database document.
 If you are implementing this in a multi-domain environment then you must ensure that this mail-in
database is addressable and can receive encrypted emails from all managed domains.
 In the FirM Request Processor database, open the Tools menu, click on the “Config” tab and then click on
the “Edit the System Configuration” link.
 Click on the “Admin Settings” tab, and then the “ID Backup” tab underneath this.
 Set the following field values:
 “AdminP Search Hours” - this sets the number of hours backwards that ID Backup will
search for matching AdminP requests. This should be set as a minimum to the number of
hours between runs of the ID Backup agent, or the longest replication time from any mail
server Admin4.nsf database to the FirM Processing server (whichever is the longer). This
setting ensures that new administration requests cannot be missed by successive runs of the
ID Backup agent.
 “Store Retention Hours” - this sets the minimum number of hours that completed
temporary backup-request temporary documents will be retained in the FirM Escrow Agent
database. Set this value so that it is equal to or greater than the AdminP Search Hours field
value.
 “Reminder Frequency” - this is the number of days that will elapse between users being
reminded to back their ID file up (if they have not already responded). This should be set
to be a minimum of one day (note – for testing purposes this field can be set to be a
negative number. In this case then the reminder frequency will be in minutes, not days).
 “Maximum number of reminders” - this field should be set so that the user does not
continue to receive reminders indefinitely. It sets the maximum number of reminders that
will be sent to the user after the initial backup request.
 “Users to Include” - this is a name-mask field, to enable you to set ID Backup to run for
only a specified subset of users in your organisation. Multiple masks can be defined –
separate entries with new lines. Full usernames or wildcard entries are acceptable – note
that it is NOT possible to specify a group in this name mask field.
 Save and close the configuration document.
 Change to the “System Profiles” sub tab of the “Profiles” section of the tools menu.
 Select “System Notification Profiles” in the radio button selection
 Scroll down through the profiles and locate the “IDB-RequestBackup” profile.
 Select the “Rich Text Footer” tab

PAG E 1 6 4 O F 1 8 5 2 6 . I D B AC K U P, R E F R E S H A N D E S C ROW
 Right-click on the button contained within the rich text footer field, and choose “Edit Button” from
the menu. Note – do not left-click on this button as this will attempt to execute the button code. The
lotusscript edit pane will be displayed.
 Place your cursor anywhere on a blank line or at the end of a line within the lotusscript code and
insert a space.
 Now click anywhere on the notification profile (except for on the button!) and the lotusscript edit
pane will disappear.
 Now use the “Tick” button to save and close this notification profile.
 The code contained within the button has now been signed with your ID. This should prevent the
end users from receiving ECL warnings when they click on the received button. If a different ID is
used to distribute code within your environment then use this ID to sign the button code – contact
your FirM support representative for help with this step if it is required.
 Now change to the “Validation” tab on the Administration Tools menu and click on the “Refresh Agent
Status” button.
 Locate the “Process Incoming Escrow IDs” agent and ensure that this agent is disabled (it should have
a red diamond icon against it). If it is currently enabled then this must be disabled before enabling
the ID Backup agent – click on the green diamond icon to disable it.
 Now locate the “ID Backup” agent and ensure that it is set to run on the FirM primary processing
server (this can be changed by clicking on the server name and selecting the server from the address
book dialog). Enable the agent for execution by clicking on the red diamond icon.
The ID Backup process is now configured for execution.
Monitoringthe ID Backup process.

The ID backup process can be monitoredthrough the use of the views in the FirM Escrow Agent database.
All documentsrelating to the ID Backup process can be viewed through the links under the “ID Backup” menu
section.
The “Requests”views show the temporaryrequest documentsthat are created and updated when new AdminP
requests are found by the agents, emails sent to the users and returns processed.
The “Returns”views show the ID Backup emails that are generatedand returned from users when they click on
the button containedwithin the email. These emails are encryptedwith the server's public key, and you will not
be able to access either the ID file or the password containedwithin them. Once they have been processed
then they will be deleted from the database.
The Identifierthat is referred to within these views and documentsis the UNID of the originatingAdminP
request.
ID Escrow
Since Lotus Notes/Domino v6, a “password recovery” mechanism has been
built into the core Lotus Notes product. ID Escrow is the alternative
mechanism within FirM by which end-user ID files can be captured by
leveraging the password recovery mechanism.
ID files captured with this mechanism do not require end-user intervention, but they
do require password recovery to be performed against them before they can be
used to reconstruct a Notes workstation client.
This process must not be enabled if you are running the FirM ID Backup
procedure – ID Backup should be disabled prior to enabling the ID Escrow
process.
To install “Password Recovery” in your Lotus Notes environment, open the
Lotus Notes Administration Help database, and look for the document
entitled “Setting up ID recovery”. The process is:
● To open the administration client

2 6 . I D B AC K U P, R E F R E S H A N D E S C ROW PAG E 1 6 5 O F 1 8 5
● Click on the “Configuration” tab

● Click on the “Edit Recovery Information” option under “tools” (on the right)
● Open your Notes Certifiers
● Enter the Certifier password
● You will see the Recovery Information Dialog screen:
● Enter one or more names in the “Recovery Authorities”
● Enter a mail-in database name that the modified ID files will be mailed to. We strongly recommend that
the Escrow Database is used for this purpose. See the section “Escrow Database” on page 176 for more
information.
From now on, whenever a client updates their local ID file with their notes client – for instance when they change
their password, accept a new name etc. – their ID file will be automatically and (by default) silently mailed in
encrypted form to this database. (Lotus Notes v5 also performed this function, but prompted the users for
confirmation, resulting in a low success rate).
It should be borne in mind that ID's sent back in this manner require to be “recovered” using the Password
Recovery mechanism.
This method is secure, foolproof, and gives you a complete record of all ID files in use in your environment. This
process is the only reliable secure and non-user reliant method of maintaining an up-to-date ID repository.
The ID Refresh Process

The ID refresh process has been added as an optional agent to:
● Detect, via the Admin4.nsf database, significant ID file changes, such as rename common name, or move in
hierarchy.
● Find the latest copy of the users ID file in the ID repository, and then refresh that ID+Password pair
against the change requests registered in that User's person document in the Domino directory.
This means that even through you may not have a physical copy of the users new ID file (it may still be on their
workstation), the copy of their ID in the ID repository is kept up-to-date.
This process is set to run once per night, and will update each User ID + Password pair only once per change request.
To enable this, enable the agent 'Refresh ID Files', using the Administration 'Tools' page, 'Monitoring' tab.
This process can be monitored by examining the log database, selecting 'Logs by Type' and choosing logs in the
category 'Refresh ID Files'.

PAG E 1 6 6 O F 1 8 5 2 7 . U S E R M A I L F I L E Q U OTA M A N AG E M E N T
27. User MailFile Quota Management

The User MailFile Quota Management system within FirM allows an administrator to delegate User MailFile quota
operations to non-technical staff.
● The configuration section is outlined in section: “User MailFile Quota Tab” on 34.
● The user request is outlined in section: “User MailFile Quota” on page 91.
● The user profile is outlined in section: “User MailFile Quota” on page 105
User MailFile Quota Management supports two modes of operation:
Non-Person Document Update Mode

By default, FirM does not update person documents in your directory to indicate current user Quota settings. This
reduces the amount of change in the Domino directory, but does mean that requesters cannot see a users existing
quota setting whilst setting a new quota.
Person-Document Update Mode.

In this mode, FirM's Extended AdminP Processor (See the section “Extended AdminP Processor” on Page 173 for
more information) will:
● On each new Quota Management request, set the fields outlined in the configuration tab (See Page 34 for
more information) in the relevant person document. The users' person document is updated on the
Administration server for the domain in order to prevent replication conflicts occurring with the users
person documents.
● Every evening, a scheduled agent will compare all user files on the server against the quota management
band defined in the person document. If the users Mail File Quota and Threshold are different, it will set
the users mailfile Quota and Threshold figures to the correct values.
This means that should the Administrator update the Quota Bands on the configuration document, then
overnight all user mail files and cluster replicas will be set to the correct values.
The scheduled agent also checks the users cluster MailFile replicas and set them to the quota limits
defined in the person document, ensuring that the users MailFile and cluster replicas of his MailFile have
consistent quota information set.
● For people who have no quota band figure set, you can choose – using the Configuration Document –
how you wish these people to be managed. The recommended option is to set a mail file quota band
initially above their current mail file quota usage – in order that everyone has a quota band set, and no
users initially are prevented from using their mail file.
In order to view all users by MailFile band, you may wish to amend the design of your Domino Directory to :
● Add a new system-administrators only view categorised by the field you defined for the quota band name
– defined on the Configuration tab.
● Add a table to the subform “$PersonExtensibleSchema” containing the four fields defined on the
configuration tab. This will allow you to open a person document and view the quota information in the
“other” tab.
Note that these modifications are not required for operation, and should only be used to display the MailFile Band
information for users. You may have to reapply these changes whenever you upgrade your Domino Directory
design – for instance, should you upgrade to a new Domino version.

2 8 . T H E A U TO M AT I C U S E R R E C E RT I F I C AT I O N E N G I N E PAG E 1 6 7 O F 1 8 5
28. The Automatic User Recertification Engine

The Automatic User Recertification Engine is used to recertify users whose certificates expire in a pre-configured
number of days.
The automatic User Recertification Engine looks for candidates every day, week or month and generates user
recertification requests for any users that expire within the pre-configured number of days.
This relies on two main pieces of configuration:
 The System Configuration Profile screen – ‘Admin Settings’ tab, ‘Misc Settings’ sub-tab. The engine is
enabled in this tab. Recertification requests are created a certain number of days before the certificate
expires – the number of days is also specified in this tab. See System Configuration – Admin Settings on
page 33.
 The System Recertification Profiles. This attempts to find a match between an expiring user, and a user
expiry profile. See Automatic Recertification Profiles on page 55
If a user matches a profile, a recertification request is automatically created using the matching profile information.
This recertification request uses the user’s certifier to recertify their user ID. See profile? on page 79
To enable the Automatic User Recertification Engine, enable the agent “Automatic User Recertification. See the
subsection “Validation Tab” in the “Administration Tools” section on page for more information.

PAG E 1 6 8 O F 1 8 5 2 9 . T H E E X P I RY E N G I N E
29. The Expiry Engine

FirM contains an Expiry Engine which allows you to programmatically set object to expire in time – this is useful if
your organisation has a high turnover of contract staff, or create groups for specific short-term projects.
The User Expiry Engine

FirM has the ability to manage an expiry workflow for users through the “System User Expiry” transaction. This is
currently a transaction that must be created by the FirM API and has not yet been exposed to the FirM UI.
Therefore this section contains only a brief outline of the operation of this transaction – for further information
please contact HADSL.
When a User Create transaction is generated by an external programme using the FirM API, there is the option to
set a user expiry date. This date is recorded within a field in the Person Document. This field name is specified
within a setting in the System Configuration Profile screen – See System Configuration – Archiving & Expiry on
page 39.
The external process is responsible for monitoring this field in the Domino Directory and when a user nears their
expiry date it must create a transaction of type “System User Expiry”, passing the name of the user, the expiry date
and a list of authorisers who can accept this expiry or change the expiry date.
This expiry transaction will then notify the authorisers of the impending expiry, and they can choose to approve
the deletion of the user or extend their expiry date. If the expiry date is extended then the user expiry request
simply changes the user’s expiry date in their person document, and proceeds to completion.
However, ifthe authoriser chooses to approve the deletion or does not respond to the request then the
transaction will create a User Delete sub transaction.
The User Deletion process is then followed to completion for this user.
The Group Expiry Engine

FirM has the ability to manage an expiry workflow for groups through the “System Group Expiry” transaction.
This is currently a transaction that must be created by the FirM API and has not yet been exposed to the FirM UI.
Therefore this section contains only a brief outline of the operation of this transaction – for further information
please contact HADSL.
When a Group Create transaction is generated by an external program using the FirM API, there is the option to
set a group expiry date. This date is recorded within a field in the Group Document and also within the group’s
entry in the Group Repository. This field name is specified within a setting in the System Configuration Profile
screen – See System Configuration – Archiving & Expiry on page 39.
The external process is responsible for monitoring this field in the Domino Directory and when a group nears its
expiry date then the process must create a transaction of type “System Group Expiry”, passing the name of the
group, the expiry date and a list of authorizers who can accept this expiry or change the expiry date.
This expiry transaction will then notify the authorizers of the impending expiry, and they can choose to approve
the deletion of the group or extend its expiry date. If the expiry date is extended then the group expiry request
simply changes the group’s expiry date in its group document, and proceeds to completion.
However, ifthe authorizer chooses to approve the deletion or does not respond to the request then the
transaction will create a Group Delete sub transaction.
The Group Deletion process is then followed to completion for this group.

3 0 . T RO U B L E S H O OT I N G & S U P P O RT PAG E 1 6 9 O F 1 8 5
30. Troubleshooting & Support

In any complex software product, issues will occur that require to be resolved via a support call. This section
shows how to most efficiently pass information back to HADSL
The Log Database

The Log database logs all system and user
events, and allows you to quickly see
more information around a particular
issue.
Upon opening the log database, the
“Miscellaneous logs” view is shown,
showing all users and servers. The
“Errors” column shows the number of
unhandled errors that has been produced
by this particular user or process.
Mailing Log Documents to Support

You can select one or more documents from this list, and mail them
to the Logs@hadsl.com mailbox. This packages up all selected
documents in DXL format, and eMails them from your account to
our logs@hadsl.com mailbox. They are unpacked, and put pack in log
file format.
HADSL never put user or certifier passwords in log documents, so
they are perfectly safe to eMail to us.
For instance, two documents are selected. Clicking on the “Send
Selected..” button will send these two documents to our support log
database.
Document types within the Log Database

There are two main document categories in the log database – log events, and error events.
 Log events (controlled by the Configuration Profile, Admin Settings tab) logs information on every
process.
 Error events are “memory dumps” caused when
any particular program does not handle an error
in a controlled manner.
This log document, generated by a user interaction, shows
a fatal error in Red, with an asterisk at the start of the line.
This entry shows a server-generated log entry with a run-time
error (in this case, the error is not in red, as LotusScript does
not allow colour coding of Rich Text items in a schedule agent).
The Asterisk still appears at the start of the line.
This is the second type of log

document – a memory dump of all
system variables during an unhandled
error. These should be mailed back to
logs@hadsl.com if they occur.
This performs the software equivalent

of an “NSD” dump, and shows us all
objects in memory.

PAG E 1 7 0 O F 1 8 5 3 0 . T RO U B L E S H O OT I N G & S U P P O RT
Raising a support call

After purchasing FirM from HADSL, you will be issued with a username and password to log into our web site –
http://www.hadsl.com.
Once logged in, you should navigate (via

the left-hand toolbar) to the “Software
Problem Report” (SPR) database. When
opened, you should see:
Click on the “Open SPR’s” to view the

open SPR’s that your company has
raised.
Click on “Create new SPR” to create

a new Software Problem Report:
A support representative from

HADSL will contact you on the same
business day.

3 0 . T RO U B L E S H O OT I N G & S U P P O RT PAG E 1 7 1 O F 1 8 5
Known Issues
This section lists known configuration and installation issues.
AdminP Database
AdminP – do NOT enable “dont support specialised response hierarchy”. This setting
switches off internal support in LotusScript for Response documents. Response
documents are an integral part of AdminP processing and causes ALL AdminP
processes to fail.
FirM manifests this by never being able to find successful AdminP responses to AdminP
requests that FirM generates. Requests appear to never process.
This Platform has a fatal code-page issue

“This Platform has a fatal code-page issue” means that this platform does not properly support ASCII characters
above 127. This error will appear at the top of a “log” report from FirM at the start of a FirM scheduled agent
processing run, and prevent FirM from processing requests.
Red Hat Enterprisev4.0

To fix this issue in Red Hat Enterprisev4, edit the file /etc/sysconfig/i18n
LANG="en_US"
SUPPORTED="en_US.UTF-8:en_US:en"
SYSFONT="latarcyrheb-sun16"
and change the “Lang=” line to “en_US”. This is especiallytrue if this line contains en_US.UTF-8,as Red Hat
linux UTF-8 support appears to be sub optimal. More informationis availableon this page:
http://cc.jlab.org/services/linux/faq.html
Windows XP
On the bottom right hand side of your taskbar, whilst your Lotus Notes client is open, select a language code page
that does not give this error, such as “EN”.

PAG E 1 7 2 O F 1 8 5 3 1 . F I R M DATA B A S E S
31. FirM Databases

FirM is composed of a number of Lotus Notes databases. These databases are discussed in detail here.
Request Processor
The core engine of FirM. This
contains:
 All configuration and profile

documents
 All requests
Help Database
A comprehensive Help database.
Log Database
An application-specific log
database that details all activity
performed by both servers and
users.
See the section titled “The Log Database”
on page 169 for more information.

3 1 . F I R M DATA B A S E S PAG E 1 7 3 O F 1 8 5
Extended AdminP processor

An extension to AdminP that
allows manipulation of databases
on remote servers.
Extended AdminP should be replicated to
all servers upon which you wish to manage
User and/or Applications.
It has a setup and profile dialog – choose “System Profiles” and then
“Extended AdminP Setup”. Fields defined are:
● “Servers to run on”. You can choose “*” meaning that the
Extended AdminP agents will run on all servers upon which
there is an ExAmp replica, or give a list of servers (or groups or
servers).
● “Servers NOT to run on”. This allows you to easily exclude
zero or more servers from the list defined above.
● “Report Faults to”: Provide a list of FirM administrators who
should be notified upon critical error.
Extended AdminP also provides a “heartbeat” function – every time the agents run on the remote servers, they
update a server specific profile document. This profile document is then replicated back to the main processing
server.

Group Registry
A reference database for group
ownership and responsibility.
This maintains the relationships
between Groups and their
profiles.
This registry is populated by the Group

Import agent. This agent is described in
the “Installing FirM” sub-section titled
“Group Import Utility” on page 26.
Each group defined in the registry can be managed by FirM. The Administrator may modify group references in this
database whilst troubleshooting.
Fields defined on the “Ownership” tab are:

● “Name” – the group name
● “Type” – the type of the group.
● “Domain” – the name of the Lotus Notes domain that this
group exists
● “Profile” – the System Group Profile associated with this
group. For more information on System Group Profiles, see the
section titled “Group Profiles” on page 53.
● “Owner/Sponsor”. The person who owns this group and may
delete it.
● “Managers” – a list of Group Managers
● “Administrators” – a list of people who are allowed to add and remove group members.
● “Group Status” - The status (within FirM) of the group.
Fields defined on the “Details” tab are:
● “Is this a spanned group”. If the group has one or more sub-
groups, this is set to “yes”.
● “Force Owner Approval for Mgmt Requests”. Set this to “yes”
if the group owner requires to see and authorise all group
requests.
● “Group Created Date”. The date that the group was created.
● “Group Deleted Date”. If set, the date the group was deleted.
● “Group Expiry Date”. If set, the date the Group Expires
● “Report Unauthorised Changes to this group”. If set, FirM
Group Monitoring will detect changes made outwith FirM,
and report these changes to the group owner. For more information, see the section “FirM Group
Monitoring” on page 160.

● “Prohibit all FirM Management of this group”. This allows you to define this group within FirM but prevent
FirM from ever changing this group. This may be useful for very high-security applications.
Monitored Group Shadow

Repository
A backup Group repository for
tracking group changes.
FirM Group Monitoring populates
and maintains information in this database.
Certifier Repository
Encrypted storage for system
certifiers.
See the section titled “Importing Certifiers

& Passwords” on page 30.
A single certifier has the following fields

defined:
● Name – the name of this certifer
in abbreviated, hierarchical format.
● A description, if provided
● Document Readers – you may choose to restrict further who
has access to this document.
● Certificate – the rich text field containing the certificate.
● Certificate Key Name. The name of the private encryption key
used to encrypt this document. For more on Encryption keys,
see the section “Stage 1 – Encryption Key Creation” on page
12.
● Certificate File Name. The file name of the certificate Key.
● Certificate Key strength – either International or Global
● Alternative Hierarchy and Alternative Language. If Alternate Language support is set up, these are
populated with this certifier keys alternative languages.
Password Repository
The encrypted passwords of
certifiers and user Ids.
A password document has the following

fields defined:
● Type – the type of password
● Name – the full name of the object
for this password.
● Previous Names – if this person changed their name- the previous
names will be listed here.

● Description – you may put a textual description of this documentation

● Password (text only). Note that you have to have edit-mode and then check the “show password”
checkbox to view or edit this password.
ID Repository
An encrypted repository
containing all user IDs created in
FirM.
User ID's are automatically created in this
database by FirM when new users are
created.
This database can also be used to store
other ID files – such as server ID's,
encryption keys and so forth.
An ID document has the following fields
defined:
● ID Type
● Status – active or deleted.
● Name – the full name of the user
object for this ID
● Previous names – if the user has been renamed, this field will contain a list of previous names.
● Description – you may enter a textua description of this ID
document.
● Document Readers – you may further restrict who has access to
this document by defining reader names in this field.
● ID File – a rich text field containing the ID file
● Encryption Key Name – the name of the encryption key used to
encrypt this document. For more information on encryption keys,
see the section “Stage 1 – Encryption Key Creation” on page 12.
● ID Strength – Global or International
● Expires – the ID expiration date
● Allow ID files to be resent. You mayset this to “no” to prevent this ID file being sent out as part of a
“User Resend User ID and Password” request (for more information on this request, see the section
“User Resend User ID and Password” on page 81)
● Comments – used to record system level information about this ID file.
ESCROW Database
The ESCROW database gives the
administrator a convenient mail-in
database for collecting modified
User ID's as part of the ID recovery
process. See the section titled “User ID
Management and Recovery” on page 162 for
more information.

Audit Repository
Stores a full audit history of actions
performed by the system.
Archive Repository
Contains an archive of all
completed and unsuccessful
requests.
Billing Database
Each FirM transaction can be
configured to create billing
transactions, which can help
recharge costs within your
Domino environment.
Deleted Records Database

Storage for all documents deleted
by the system. When users are
deleted by FirM, for instance, their
person documents are copied to
this database.
Application Monitor
A list of all Domino applications in
your environment, highlighting
ACLs and ACL changes
For more information see the the section

titled “The FirM Application Monitor” on
page 147.

Application Usage Log

A list of all application usage events
in your environment.
For more information, see the section titled

“The Application Usage Database” on page
149 149.

A P P E N D I X A - T H E A D M I N P P U S H A RO U N D AG E N T PAG E 1 7 9 O F 1 8 5
Appendix A - The AdminP Push around Agent

This chapter is only of relevance to those environments that:
 Have multiple Notes domains with individual admin4.nsf databases.
 Only process FirM transactions in one of those domains.
 Require AdminP requests to be processed in the other domains.
 Do not wish to use the Lotus Domino ‘Cross-Domain AdminP’ functionality.
The FirM processor incorporates an agent which, on a scheduled basis:
 opens up each domain’s admin4.nsf databases
 Establishes which transactions need to be copied to any other domain’s admin4.nsf databases.
This chapter outlines this agent’s functionality and setup.
Overview
In order to illustrate how this agent works, consider an environment where there is:
 One administration domain – called ‘Admin’.
 one production domain – called ‘Production’
 One test domain – called ‘Test’.
All relevant transactions created in the ‘Admin’ domain must be copied to the relevant other domain, i.e.
‘Production’ or ‘Test’. These transactions also may spawn other transactions which need to be copied around.
Consider a ‘Rename in Address Book’ AdminP operation. This is initiated with a
‘8’ = ‘Initiate Rename in Address Book’ operation. This AdminP request then has to be copied into the relevant
admin4.nsf database so that it can be processed and accepted by the user’s home server. When the user accepts
this request, then, at least, the following requests are generated:
‘1’ = ‘Rename in ACL’
‘5’ = ‘Rename in Address Book’
‘20’ = ‘Rename in Reader/Author Fields’
Each of these requests may then have to be copied around the environment into other domains to update that
user name in ACL’s, names fields on documents in databases, etc..
So, considering this rename operation, we may wish to push transaction number ‘8’ from the ‘Admin’ domain to the
‘Production’ domain, and then pull transactions 1, 5 and 20 from the production domain back in the ‘Admin’ and
‘Test’ domains.
Configuration of AdminP Push around Agent
System ConfigurationVariables
The push around agent is configured using
‘System Configuration’ variables. These are
simple documents located the Tools ‘System
Views’, ‘System Variables’ which allow the
FirM administrator to override default system
behaviour.
N.B. Other than the push around agent configuration, no other variables should be changed unless instructed to do
so by the FirM Support team.
Push around Rules

Each domain can have one or more push around rules associated with it and each of these rules can dictate which
other domains this particular AdminP will be copied to.
The general format for this rule is:

PAG E 1 8 0 O F 1 8 5 A P P E N D I X A - T H E A D M I N P P U S H A RO U N D AG E N T
‘AdminPPusharound_<SOURCEDOMAIN>_<RULENUMBER>=<TRANSACTION>,<DOMAIN>,[<DOMAIN>,…
]
Where:
 SOURCEDOMAIN is the domain where the request is copied from
 RULENUMBER is a two digit number starting at ‘01’, and is used to differentiate rules. Once the push
around agent finds that a rule number is missing for a particular domain, the agent will assume that the
rules have been exhausted for this domain. It is therefore important to number your rules uniquely and
sequentially starting at ‘01’, then ‘02’, etc..
 TRANSACTION is the AdminP Request transaction number.
 DOMAIN is the target domain to which this AdminP request should be copied. There are also two
special keywords that can be used instead of the domain name:
o The string ‘<ALL>‘ means copy this request to ALL other domains.
o The string ‘<TARGETDOMAIN>’ means that the push around agent will attempt to find this
object and only copy it to the relevant target domain.
Multiple domains can be specified, separated by the comma character ‘,’.
Push around Rule Examples:

 AdminPPusharound_ADMIN_01=5,Production
o This is rule number ‘01’ for ‘Admin’ domain. It instructs the push around agent to copy any
AdminP request number ‘5’ to the ‘Production’ domain.
 AdminPPusharound_ADMIN_02=10,<TARGETDOMAIN>
o This is rule number ‘03’ for the Admin domain. It instructs the push around agent to copy the
AdminP Request number ‘10’ to the target domain relevant for the user mentioned in the
AdminP request. The push around agent looks-up this user name in the directories to determine
the relevant target domain.
 AdminPPusharound_ADMIN_03=18,<TARGETDOMAIN>,Test
o This is rule number ‘03’ for the Admin domain. It instructs the push around agent to copy the
AdminP Request number ‘18’ to the target domain relevant for the user mentioned in the
AdminP request and also to the ‘Test’ environment (if this is different). The push around agent
then looks-up this user name in the directories and establishes the relevant target domain. This
type of rule is useful to reflect ‘Production’ environment changes in the ‘Test’ domain, for
instance.

A P P E N D I X B - I N T E R FAC I N G WI T H F I R M PAG E 1 8 1 O F 1 8 5
Appendix B - Interfacing with FirM

FirM has been built from the ground up to be extensible. You can interface FirM with your own Lotus Domino
environment.
Triggering your agents from a FirM process

To trigger your own agents from any process within FirM,
 Navigate to the System Profiles
configuration tab, and select “System
Agent Trigger Profiles.
 Click on “Create a new Profile”
 Select the transaction or “trigger” that you wish to act upon

 Select the trigger type – “Success” means that the transaction
was successful.
 Enter the name of your database
 Enter the name of your agent.
Please note that from v2.4 onwards, the agents are passed copies of the request documents, not the documents
themselves. This prevents any uncontrolled changes to the requests.
You can of course create these agents in the FirM processing database itself – but please remember to enable the flag
'Deny Design Refresh', in order to preserve these agents when FirM is next updated!
An example agent trigger agent is shown below. This Agent trigger actually uses some FirM logging interfaces, and
merely lists all the fields on the document that is passed to it.
(Note that if you choose to use the FirM methods in this manner, then you will have to set Agent Security to at least
level 2)
Function TestHarnessAgentTrigger()
Dim IMF As IMFactoryClass
Set IMF = New IMFactoryClass("", "")
Dim sSession As New NotesSession
Dim dbThis As NotesDatabase
Set dbThis = sSession.CurrentDatabase
Dim A As notesAgent
Set A = sSession.CurrentAgent
Dim docParam As NotesDocument
If (A.ParameterDocID <> "") Then
Call IMF.logVerboseMsg( _
"Agent trigger was called with NoteID: " + A.ParameterDocID)
Set docParam = dbThis.GetDocumentByID( A.ParameterDocID)
Dim itm As NotesItem
Forall thisItm In docParam.Items
Set itm= thisItm
Call IMF.logVerboseMsg(" " + itm.Name + " = " + itm.Text)
End Forall
Else
Call IMF.logVerboseMsg( _
"Agent trigger was called without a parameter ID")

PAG E 1 8 2 O F 1 8 5 A P P E N D I X B - I N T E R FAC I N G WI T H F I R M
End If
End Function
Using the CSV interface pro grammatically
This section is intended to document how the Federated Identity and Resource Manager (FirM) can be extended,
by allowing customers to inject new requests pro grammatically.
It should be noted that this interface is quite simple, and allows requests to be built as specified in the CSV
interface. For more information on the CSV interface see section 20 - “The CSV interface”.
A more complex, full API allows full interaction with FirM, and is used to build fully-featured GUI's in Lotus Notes
and HTML clients.
CSV Introduction
In order to use the CSV LotusScript interface, some background description is required.
A "Comma Separated File" is a text file, typically generated by spreadsheets. Usually, the first row (the "header
row") defines keywords, and second and subsequent rows define data per record.
For instance:
"Transaction", "TransactionProfile", "UserName"
"UDI", "User Disable", "Bill S Buchan/HADSL"
is a fairly simple, complete example of a CSV file. (I've added the <TAB> character between columns to help
differentiate columns -these are not required.)
The FirM CSV interface allows you to import one or more transactions, of any kind, and convert them into valid
FirM transactions (should they pass validation and testing). This means that the CSV interface has to use the header
fields to establish what the data means. This also means that the columns can be in any order
All currently supported transaction types and field definitions are listed in the FirM administration manual.
In some instances, some fields may contain more than one logical value. In this case, separate the values WITHIN
the data field with a semicolon character. For instance, this example has two separate names in the same data field.
This will be converted into a multi-value field by the interface.
..., "MembersToAdd", ...
..., "Joe Bloggs/Acme; Fred Bloggs/Acme", ...
Programmaticallyinterfacingusing the CSV interface
Using the CSV interface, the programmer has to:

•Create a string array, defining the column headers that he shall use
•Create one or more strings with data values.
For example, (taking the example above), the programmer would:
dim Header() as String

redim Header(2) ' Remember, arrays start at ZERO
Header(0) = "Transaction"
Header(1) = "TransactionProfile"
Header(2) = "UserName"
dim dataLine as String
' Note that I'm using the BAR character - | - to define

' the start and the end of the string, in order to preserve
' the double-inverted-commas within the string
' For clarity, I've left in the TAB characters at the start,
' and between each column. The TAB characters are not required.

dataLine = | "UDI", "User Disable", "Bill S Buchan/HADSL" |
The important note is that the data line fields have to correspond to
the same order as the header fields.
Creating an Agent to programmatically create requests
There now follows an example LotusScript agent demonstrating the CSV
interface.
(options)
option public
option declare
Use "class:IMFactoryClass"
Use "class:IMCSVImport"
sub initialise()
dim IMF as variant
' Items in GREEN in this listing illustrate the calls to the FirM API. All other
' lines are normal Lotusscript operations.
' Instantiate a single copy of the FirM factory class.

' If this agent is created in the FirM request processor database, then
pass two
' empty strings meaning "use the current database for profiles".
' If this agent has to be in another database, then ALL script
libraries from the FirM
' Request processor have to be copied to the new database, and
' the path to the FirM request processor passed to the IMFactoryClass
' create as a server, and a filepath.
Set IMF = New IMFactoryClass("", "")
' Create our data for this transaction

dim Header() as String
redim Header(2) ' Remember, arrays start at ZERO
Header(0) = "Transaction"
Header(1) = "TransactionProfile"
Header(2) = "UserName"
dim dataLine as String
' Note that I'm using the BAR character - | - to define

' the start and the end of the string, in order to preserve
' the double-inverted-commas within the string
' For clarity, I've left in the TAB characters at the start,
' and between each column. The TAB characters are not required.
dataLine = | "UDI", "User Disable", "Bill S Buchan/HADSL" |
' Now create a new CSV object with this line.

Dim thisCSV As Variant
Set thisCSV = New IMTestCSVLine(IMF)
' For each "data line",

Call thisCSV.addLine(dataLine, Header)
If Not thisCSV.applyAsRequest(IMF) Then

Print "Request Failed:"
Dim E As Variant
e = Split(thisCSV.getCSVLineErrorMessage(), Chr(10))
' Now print out the errors that FirM has returned to us, one line at a
time.
Forall thisError In E

PAG E 1 8 4 O F 1 8 5 A P P E N D I X B - I N T E R FAC I N G WI T H F I R M
Print thisError
End Forall
' The following line writes to the FirM log file, flagging the
' message as an error
Call IMF.cLog.Write(LOG_LEVEL_ERROR, "Initialise: Failed to apply CSV line")
Else
Call IMF.cLog.Write(LOG_LEVEL_VERBOSE, "Initialise: Applied CSV line")
' This call flags the current log document with our transaction type.
Call IMF.cLog.setCurrentRequestSummary("UDI")
End If
end Sub
Create FirM requests from your own programs.
FirM includes a full LotusScript Application Programming interface (API). Documentation for this API is available on
request from HADSL. FirM itself uses this interface to create its own user interface, and therefore anything that can
be done from the user interface can be enabled via the API.
This API allows you to create and monitor requests in FirM as if the requests were created using a Notes client.
This is useful in enabling existing processes to create FirM requests to manage your Domino environment.
Example agent
Add the class library ‘class:IMFactoryClass’ to your existing lotusscript code by including the statement:
use ‘class:IMFactoryClass’
in the ‘options’ section of your code Initialise the FirM classes by creating a new instance of the IMFactoryClass
object:
dim IMF as new IMFactoryClass(strTargetserver, _ strTargetDatabase)
Note that you have to pass the name of the target server, and the database path name, of the IMFactory ‘requests’
database for the IMFactory object to successfully construct itself.
If you choose to put your agent in the FIRM database itself, you can replace the servername and database name
with a blank string:
dim IMF as new IMFactoryClass(””, ””)
Check, by calling the IMFactoryClass::isFactoryValid() that the factory has initialised correctly
if (not IMF.isFactoryValid()) then
msgbox ‘The factory failed to initialise’
exit function
end if
Create a new request by instantiating a new IMRequestClass object
dim IMR as Variant
set IMR = IMF.getRequestClass()
Set the request Type and who the requestor is
Call IMR.SetRequestType("UCR")
Call IMR.setRequestorAsMe()
Set the User Create profile name you wish to use. This is the name of an existing Profile for this type of
transaction:
call IMR.setProfile(‘My User Create Profile Name’)
Set the new request type, and gain an instance of the sub-request class type by:
dim IMUCR as Variant
set IMUCR = IMR.getRequestObject()
Now set the data for the sub-request class type. In this instance, we're setting up a User Create Request
Call IMUCR.setFirstname("Derek")
Call IMUCR.setMiddleInitials("D")
Call IMUCR.setLastName("Test ")

request Check to see if this request is valid:

if (not IMR.isValidRequest()) then
msgbox ‘The request failed validity check. ‘+_
‘Check the Request Log database for more information’
exit function
end if
And check that we're authorised to submit this document
if (not IMR.isAuthorised()) then
msgbox ‘You are not permitted to submit this request’
exit function
end if
Now that we're sure that its a valid, authorised request, lets write it out to our blank request document:
dim docTarget as NotesDocument
call IMR.getNewRequestDocument()
Write the request to the document
call IMR.WritetoDocument(docTarget)
Sign and save the request
call IMR.SignAndSaveDocument()
That completes the creation and signing of a request document. The back-end process will now revalidate, and re-
authenticate the request before processing it.

FirM Administration v2!4!01

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FirM Administration v2!4!01

Uploaded by

Copyright:

Available Formats

Administration

& Operations Manual

© 2008 HADSL FirM Administration Manual v2.4.

Application Create.....................................................................119 24. Importing Transactions using CSV...........................151

FirM Administration Manual v2.4 © 2008 HADSL

How does it work?

How does this help me cut costs?

What does FirM do?

Why is FirM the best Domino User and Group Managementtool?

© 2008 HADSL FirM Administration Manual v2.4.

How does FirM take advantage of load-balancingand server clusters?

How does FirM handle large groups?

What are profiles? How are they used?

FirM Administration Manual v2.4 © 2008 HADSL

 Who needs to authorise requests made with this profile

For the ‘User Create’ profile, a number of sub-profiles can be specified:

Does FirM work with Domino 5, 6, 7 and 8?

Upgrading to R6 or R7 will reduce administrationeffort in any case ?

Feature List v2.4

© 2008 HADSL FirM Administration Manual v2.4.

At v2.4 release, it performs the following operations:

● Cluster mail file creation on one or more server cluster mates.

● ID and Password secure storage & distribution to mandatory or optional recipients.

● Adding the new user to specified groups.

● Setting specified person document fields.

● Enable ND6 style Roaming User.

● Create Password Digest.

● And sending a customised Welcome Message to the user.

● User Rename common Name. Rename a users' common name.

FirM Administration Manual v2.4 © 2008 HADSL

● User MailFile Quota. Set a users Mail File Quota.

● Group Modify. Modify a group’s attributes.

● Group Manage Members. Add and remove users from groups

● Group Delete. Remove a group from the Lotus Domino Directory

● Mail in Database Manage. Modify a mail in database.

Active Directory Operations

● User Disable. Prevent a user logging into Active Directory

● User Enable: Allow a user to log into Active Directory

● User Modify. Change an attribute on the users' Active Directory record

● User Password Reset: Set a users Active Directory password.

● Group Create: Create an Active Directory group

● Enable Handset for user

● Reset password handset

© 2008 HADSL FirM Administration Manual v2.4.

What does FirM consist of?

FirM Administration Manual v2.4 © 2008 HADSL

2. How FirM Works

© 2008 HADSL FirM Administration Manual v2.4.

Who should install FirM?

How this product is delivered

How to obtain a license key.

Installation & Configuration of FirM

Quick Installation Process

Prerequisites:Necessary informationand access rights

FirM Administration Manual v2.4 © 2008 HADSL

Stage 1: Encryption key creation

Creating the Keys

b) Copy the server’s ID file to a location

© 2008 HADSL FirM Administration Manual v2.4.

j) With the key highlighted, click on the

k) Give the key a secure password in

FirM Administration Manual v2.4 © 2008 HADSL

Stage 2: Initial install of FirM