Road Map

The successful implementation of Desktop Manager on the Domino server and on client desktops goes through a series of steps, performed according a chronological sequence. Each step is presented with its objectives, pitfalls, and elements required for a proper execution (see related chapters in the documentation).

Here are the different steps to take for installing and operating the application:

• Step 1: Install the Desktop Manager database(s) on the server

The installation of the Desktop Manager database (DskMgr.nsf) on the server should not pose any major problem, as it simply consists in copying a Notes database on a Domino server and in performing usual administration operations (server selection, database signing, ACL update, DskMgrStart.nsf database signing, create database's Setup documents, create Reference document., etc.).

If the target population for software installation is large or spread on different geographical areas, a multi-databases Desktop Manager architecture should be set up. Create a Desktop Manager User database (DskMgrUser.nsf) and link it to the Desktop Manager database using a Database document.

Reference documentation: Architecture, Server installation.

 

• Step 2: Test the application on pilot desktops

Select about ten people with different profiles (PC configuration, geographic location, job, etc.) and have them open the Desktop Manager database on its server. You may also send them mails including a link to the Desktop Manager database. These first installations allow to check whether the Desktop Manager database has been correctly installed on the server (signature, ACL) and whether the application installation on desktops is successful (Desktop Manager Starter database signature, ECL, Connection document to the server). Check that Desktop Manager Starter database starts at the next Notes client start ups.

This step is aimed at detecting as early as possible any reasons that may prevent the software from installing correctly on all desktops.

Reference documentation: Architecture, Server installation, Client installation.

 

• Step 3: Identify the target for client desktops receiving the application

It is necessary to draw up a list of users that should receive the application on their desktop and to inventory their specific limitations. It will also be necessary to precisely identify the various computer types (desktop, laptop, multi-user desktops, Citrix environment, etc.).

Once these limitations are set up, it is necessary to define the best way to install application components on desktops (automatic installation via the application or installation via system scripts). If users are few or geographically distant, sending an installation Mail is an option. If users are numerous and if there is an application deployment solution already in place within the company, Desktop Manager should be probably be deployed on the desktops using this package.

Reference documentation: Architecture, Server installation, Client installation.

 

• Step 4: Create Setup documents

Setup documents reflect the way Desktop Manager is installed and used client desktops. Similar users should be grouped under the same Setup document. Generally, you create as many Setup documents as there are Mail servers, and this way, all users of a mail server are attached to the associated Setup document. It may be necessary to create Setup documents for specific populations (Citrix).

If Mail installation is selected, you may pre-register users in the database.

Make sure you update the Reference document after the creation of all Setup documents.

Reference documentation: Architecture, Server installation, Client installation, Setup documents, Reference document.

 

• Step 5: Communicate with involved users

This very important step should not be ignored. As Desktop Manager will be installed and run on user desktops, these users must be informed, both in terms of application interface (screens overview) and steps to take when installing the application or running it recurrently on their desktop.

One or more messages should be sent to the target population in order to raise awareness about the incoming application.

 

• Step 6: Send installation Mails or Prepare the installation package

If the application is deployed by package, you will not have to prepare a Mail. You should only provide the team in charge of the package with the files to deploy on desktops and with the operating mode (where to copy files).

If the application deployment requires Mail sending, Mails documents should be created in the Desktop Manager database. Mails documents should be written according to the communication campaign that was run previously. The selected message body (including the company logo) must describe the stakes of implementing the application on desktops, as well as the steps to take for installation.
Various types of messages should be created according to the target population (translation in several languages, message body ranging from installation mail to reminder mails).
Installation mails should then be sent to involved users (if the application is installed via Mail sending), using the mail sending interface included in the Desktop Manager database.

Références documentaires : Architecture, Installation serveur, Installation Client, Les documents de Setup, Les documents Mails

 

• Step 7: Monitor application deployment

Once this step is reached, the application installation should be monitored using the User Audit Results / Notes configuration view, which displays the document tree structure illustrating the desktop audit (desktop audit is processed just after the installation phase). As the application is installed on client desktops, the list of remaining users needing installation decreases.

Any problems mentioned in the Administration / On Error Users view (installation or audit problems) should be analyzed and solved.

After one week, latecomers should be sent a reminder mail, according to the number of users who have not yet installed the application (if it is done via mail sending). These users can be easily retrieved since they match the 'pre-registered' and 'not-installed' criteria (visible in the Administration / On Error Users view).

There always remain some users who do not respond positively to the installation request mail. These can be people that are out of the office (due to travel, holidays, sick leave), users who experience problems when accessing their messaging system or simply persons who do not understand what is requested from them and who systematically dismiss the mail. These persons should be contacted directly or through their department in order to find out why they did not respond.

Reference documentation: Architecture, Client installation, Mails documents, Database opening, Problem solving.

 

• Step 8: Analyze desktop audit results

The most time-consuming step consists in analyzing and exploiting the audit results of all Notes configurations on client desktops, since it is an in-depth study of all the data (exporting these data to an external database is possible) that helps with making the decisions on what to modify in the desktop configuration. It is also necessary to browse samples from the desktop's Log database in order to find recurring errors (cache size problems, replication errors, alerts from the ECL, etc.).

The implementation and exploitation of Desktop Manager will go no further if application usage is based exclusively on desktop audit. Within the context of a preliminary study to migrate Notes computers from an old client version to a more recent one, and assuming that all desktops will be impacted, it will not be necessarily useful to modify desktop configuration by using Tasks or by applying Profiles if a new client desktop version has to be installed. On the contrary, the audit result is valuable because it allows identifying the user files to collect on the new installation.

Reference documentation: Audit result.

 

• Step 9: Prepare Tasks

After the desktop audit phase, desktop Notes configurations should regularly be cleaned up in order to solve any problems which may have arisen, and to schedule the execution of administration processes on locally replicated databases (compact, fixup, updall). All these desktop changes are performed with Tasks documents created in the Desktop Manager database and targeted at a specific population. Tasks are used to modify all components in a Notes installation. The Desktop Manager database administrator prepares Tasks documents in the database. These Tasks are applied on the user desktop when the application starts up on this desktop (usually at Notes client start up). Tasks management and execution are asynchronous processes: they are prepared in advance by the administrator and run when the user starts up his Notes client.

After application installation, desktop updates generate an important workload, but this fixing activity is completed after a few weeks. The tasks will then be used recurrently (e.g. compacting a local database once a month) or upon Help Desk request after problem notification on a desktop (tasks allow to operate remotely and asynchronously where as before it was necessary to physically intervene on the desktop or to take remote control of the desktop).

Reference documentation: User Tasks, Named ECL, Use of @, # and % keywords, Syntax of ChangeACL commands.

 

• Step 10: Define Profiles
  

Implementing and applying Profiles on the user desktop is designed for preserving configuration options on this desktop over time. In order to prevent this environment from changing, Profiles allow setting some configuration parameters (Location, Connection and Account documents, user preferences, replication of some databases on the desktop). While Tasks are only used for occasional problem solving, Profiles keep the configuration permanently unchanged (enforcement).

Profiles also allow defining Hooks that are used to control user actions (limit the size of sent mails) and implementing Backup and Roaming procedures for Notes configuration files.

It is naturally possible to define a collection of Profiles documents and to assign them to different user groups according to their needs. The distribution of these documents can be done geographically (pointing Connection documents to the server of a building), functionally (replicating some databases on sales people' desktops) or on a material basis (specific configuration for mobile personnel with laptops).

Applying Profiles on a Notes desktop that has just been configured allows downloading a configuration including all necessary components (applications, workspace icons, Connection documents, Location documents, miscellaneous settings, etc.) on this desktop. Thus, it is possible to matrix desktops according to a configuration created from the Desktop Manager database. As Profiles are systematically applied on user desktops (each time the application starts up), such a configuration can no longer be degraded by the users.

After the creation of Profile documents, be sure to refresh the Reference document.

Reference documentation: Profiles documents, Hook documents, Setup documents, Use of @, # and % keywords, Syntax of ChangeACL commands.

 

Back to Top