Automatic updating of the One Identity Manager tools
When a program starts up, VI.DB.dll establishes a connection to the database and carries out the semaphore test. If the softwarerevision.viv file 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) requires an administrator to log in if user account control is active, assuming that the current 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 begins.
The application then loads the Update.zip file 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 may interfere with the update process. At the same time, administrator permissions requirements are authorized by user account control, if they are necessary.
In this update procedure, not only are the files exchanged but other migration steps from the *.Update.dlls are also run. 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 run 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 or not the users of One Identity Manager tools can decide when their own workstations are updated, is controlled by the Common | AutoUpdate | AllowOutOfTimeApps configuration parameter. This means:
-
Users have no way of intervening in the update if the configuration parameter is not set. The update is run immediately.
-
If the configuration parameter is set, the logged-in user is prompted with a message. Users can decide whether the One Identity Manager tools update takes place on their workstation straight away or at a later time.
NOTE: If users do not want to update immediately, they can continue working. The update begins 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 necessary 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 software revision semaphore. If this value differs from the value in the database, the Job server is labeled as "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 Common | Autoupdate | ServiceUpdateType configuration parameter.
First, the start time of the last change is determined from the SoftwareRevision.viv file. 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 obtains an AutoUpdate process from the server. which loads the Update.zip file 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 run.
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 updates. 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 Replace a process level token and Adjust memory quotas for a process local security policies.
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 http://<servername>/<application>/monitor runtime 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 Update.zip file 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
