Identity Manager 8.1 - Installation Guide

About this Guide One Identity Manager overview Installation prerequisites Installing One Identity Manager Installing and configuring the One Identity Manager Service Automatic updating of One Identity Manager Updating One Identity Manager Installing and updating an application server Installing the API Server Installing, configuring and maintaining the Web Portal Installing and updating the Manager web application Logging in to One Identity Manager tools Error handling Appendix: Creating a One Identity Manager database for a test or development environment from a database backup Appendix: Extended configuration of the Manager web application Appendix: Machine roles and installation packages Appendix: Settings for a new SQL Server database

Automatic updating of the One Identity Manager tools

When a program starts up, VI.DB.dll creates a connection to the database and carries out the semaphore test. If the file softwarerevision.viv is not found, a new file is added.

If the One Identity Manager installation directory does not have write access, an error message is displayed and the software update continues.

The update program (Updater.exe) expects a login by an administrator when user account control is active, assuming the logged in user does not have administration permissions for the installation directory (for example %ProgramFiles%). If installation takes place in a directory without user account control, the query does not apply. Then the update process is started.

The application then loads the file Update.zip from the database or from the application server, which is unpacked in a temporary directory.

In the first step, the Update.exe informs the main application whether it can run an update or not. Depending on the configuration, the user may still be able to cancel the automatic update at this point.

To prevent further applications from starting during the update, a file called Update.lock is created in the installation directory. The trigger program and the update program (Update.exe) write their process ID in the file. The Update.lock file is deleted from the installation directory once updating has been successfully completed. The program is then restarted. To ensure that automatic updating is restarted when an application is restarted after quitting unexpectedly, Update.lock files older than two hours are ignored. If none of the processes whose IDs are saved in the Update.lock file exist on the workstation when the application is restarted, the Update.lock file is also ignored and the update is restarted.

Before actually updating, the preparation steps that prepare the installation for the update, are called from the *.Update.dlls. A preparation step might be renaming a machine role, for example.

For the actual update, the Update.exe searches for all the necessary files and saves them in a temporary directory. Communication with the system is established through the client application to be updated because only it has the required permissions for contacting the database or the application server. Once all the required files have been transferred, the Update.exe takes control and starts the data exchange. At this point the user is prompted to quit all running applications that might interfere with the update process. At the same time, administrator permissions requirements are authorized by user account control, if necessary.

In this update procedure, not only the files are exchanged but other migration steps from the *.Update.dlls are also executed. The functionality in these migration steps is not restricted. Typical examples are customizations in the registry database or configuration files and removal of obsolete program data on the computers. These migration steps are executed after the files have been exchanged.

If all the update steps have been carried out successfully, the Update.exe creates a new SoftwareRevision.viv and restarts the client application. The Update.exe then ends and removes the temporary working directory itself. This software update is thus complete.

The semaphore test is carried out by VI.DB.dll on a cyclical basis during normal operations. If a file is identified for update, the update process is started automatically.

Related Topics

User intervention in automatic updating of One Identity Manager tools

When the automatic One Identity Manager tool update is detected on a workstation, the user is prompted to close all open programs. Updating starts after the user has closed all the programs.

Whether the users of One Identity Manager tools can decide when their own workstations are updated, is controlled using the configuration parameter Common | AutoUpdate | AllowOutOfTimeApps.

  • Users have no possibility to intervene in the update if the configuration parameter is not set. The update is executed immediately.
  • If the configuration parameter is set, the logged in user is prompted with a message. The user can decide whether the One Identity Manager tools are updated on the workstation immediately or at a later time.

    If the user does not want to update immediately, he can continue working. The update is started the next time the program is started.

Automatic updating of the One Identity Manager Service

Automatic software update is the default method for updating the One Identity Manager Service on servers. However, the update method takes into account that it may be essential to exclude certain servers from being updated automatically and to update them manually.

For every query of process steps, the One Identity Manager Service returns the current status of the semaphore software revision. If this value differs from the value in the database, the Job server is labeled with "updating" in the database and no more normal process steps are sent to it.

The Job server is updated depending on the procedure set in the configuration parameter Common | Autoupdate | ServiceUpdateType.

First, the start time of the last change is determined from SoftwareRevision.viv. A list is compiled of all files with additional information specifying whether each file is new or not. This list is evaluated on the Job server to be updated and another list is compiled specifying which files will be updated.

To do this, the service receives an AutoUpdate process from the server. which loads the file Update.zip and the update process begins.

If updating with the new process cannot be completed because, for example, there is no direct connection to the database or an application server, the files are transfer by process steps in the Job queue (fallback). In this case, any existing update steps from the module library might not be executed.

One Identity Manager Service is restarted if any one of the files has changed on the Job server. After the update is completed, the Job server label is reset in the database.

Automatic updating of web applications

In principle, web applications support automatic software update. However, a few web applications may require extra configuration to take part in automatic software updating.

The following permissions are required for automatic updating:

  • The user account for updating requires write permissions for the application directory.
  • The user account for updating requires the local security policy Log on as a batch job.
  • The user account running the application pool requires the local security policies Replace a process level token and Adjust memory quotas for a process.

Updating the web application requires restarting the application. The web application is restarted automatically by the web server when it has been idle for a defined length of time. This may take some time or be hindered by continuous user requests. Some web application offer you the option to restart manually.

NOTE: To update the Web Portal automatically, use a browser to connect to the runtime monitor http://<servername>/<application>/monitor and start the update of the web application.

If the web application update is identified, new files are copied from the database to a temporary directory on the server.

The application then loads the file Update.zip from the database or from the application server, which is unpacked in a temporary directory.

The Update.exe starts, waits until the web application process has shutdown and copies the files from the temporary directory to the web application's directory.

Related Topics
相关文档