Installing and configuring the One Identity Manager Service in a cluster
The installation of server components from the One Identity Manager installation medium needs to be done on all the physical nodes of the cluster.
NOTE: In the configuration of the JobServiceDestination, the Queue parameter must contain the name of the virtual server.
After saving the configuration, the configuration file in the One Identity Manager Service installation directory needs to be copied to all the physical nodes. You must not change the name of the configuration file.
NOTE: One Identity Manager Service configuration is not part of a cluster resource. Thus, each node keeps its own configuration. For this reason, you must ensure that the configuration files on the physical nodes are consistent. If this is not the case, correct functionality cannot be guaranteed after changing cluster nodes.
Setting up a cluster resource for the One Identity Manager Service
In the Cluster Administrator program, set up a new cluster resource for the One Identity Manager Service and make this available online. For information about this procedure, refer to Microsoft Technet under http://technet.microsoft.com/en-us/library/cc787285(WS.10).aspx. Note the following when creating the cluster resource:
- Select the Generic Service resource type.
- Select the following One Identity Manager Service dependencies.
- Cluster IP address
- Cluster name
- Quorum; for example, disc: D
- Do not enter additional registration keys.
NOTE: After setting up the One Identity Manager Service in a cluster system it is advisable to simulate a failover so that possible problems with the cluster do not arise during live operations.
Storing the One Identity Manager Service log file on a shared volume
- In the Cluster Administrator program, set up a new cluster resource for the and make this available online. Note the following when creating the cluster resource:
- In the configuration file of the One Identity Manager Service, adapt the directory information in the Log file (OutPutFile) parameter of the log writer.
- Copy the configuration file to all the physical cluster nodes in the One Identity Manager Service install directory after you have changed it.
Related topics
Automatic updating of One Identity Manager
Local installation and updating of software in particular can prove to be problematic due to the distributed structure of servers and workstations. To help guarantee an acceptable workload for network administrators, a One Identity Manager automatic update method has been developed for One Identity Manager. Apart from updating the usual One Identity Manager installation files, new custom files can be simply added to the procedure and are, therefore, distributed to workstations and servers in the One Identity Manager network using the automatic software updating mechanism.
Detailed information about this topic
Basics for automatic software update
All files in a One Identity Manager installation are saved with their name and binary code in QBMFileRevision in the One Identity Manager database. The file size and hash values of each file are stored to identify them. Additionally, each file's affiliation to machine roles and installation packages is entered in the QBMFileHasDeployTarget table.
The necessary files are loaded into the One Identity Manager database and updated when a hotfix, a service pack or a full version update is run.
In the database, a semaphore software revision is maintained. When a file is added, changed, or deleted in the database, the semaphore value is recalculated by the DBQueue Processor. In every One Identity Manager installation directory there is a Softwarerevision.viv file. This file is assigned the Read only and Not visible permissions in the file system, and therefore is not normally displayed by the operating system.
The Softwarerevision.viv contains the following information:
As of One Identity Manager version 8.0, the Update.zip file is stored in the QBMFileRevision table. The file plays a central role in automatic updating. The zip archive contains all the files that are required on the clients or server for updating the product. The zip archive is not part of the One Identity Manager installation data but is recreated after the database has been updated by the Configuration Wizard and also the Software Loader.
The zip archive contains the following files:
-
Update.exe
-
VI.Base.dll
-
NLog.dll
-
Newtonsoft.Json.dll
-
InstallManager.Msi.dll
-
InstallManager.Core.dll
The zip archive is extended with all files from the installation data that correspond to the *.Update.dll name filter. This makes it possible for different modules to contribute more functionality to the automatic update.
In addition, the installation directory of all One Identity Manager installations contains the InstallState.config file. This file contains information about the installed machine roles, installation packages and files.
Whether or not a software update is required, depends on the comparison of semaphore values from the database and the .softwarerevision.viv file. If semaphore values vary, machine roles for the computer or server are determined based on the InstallState.config. Each file belonging to a machine role is check to see if the file is known to the database.
If the file exists in the data, make the following checks:
- Has the file size changed?
In this case, the file is added to the list of files to be updated.
- Has the hash value changed?
In this case, the file is added to the list of files to be updated.
New files that have been loaded into the One Identity Manager database through a hotfix, a service pack, or a version update are also added to the list. All the files in the list are updated.
All actions are logged in the file update.log. After the update has finished, the current semaphore value is copied from the database to the file softwarerevision.viv.
Related topics
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 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 necessary.
In this update procedure, not only are the files 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
