Open Management Architecture

OMA

Functions (for experts)


Deployment of operating systems

OMA offers a variety of means to deploy operating systems. Due to this flexibility OMA is able to provide optimal solutions in a vast number of different conditions. Moreover, it does not matter which system software you use, since OMA is capable of handling all major operating systems. Likewise, the manner through which your operating systems are connected to the company network does not make a difference. The basic prerequisite of all procedures consists of booting up a minimized operating system (OMA Client Console). All available client consoles are administrated by the OMA-Server. Computers may boot into the OMA Client Console via network, USB-devise or local management partition.

Deployment

Only a single master installation on one client is necessary to generate an infinite number of different outcomes. The replica of the master installation is called image. The shape of the image depends on the operating system you want to deploy. The image is made and optimized on a single client system. After your master client is installed properly the OMA server can receive the content and makes an image. Afterward, the mass roll out may start.

One image per operating system

This ideal approach has been implemented among many customers of AROSOFT. Individual settings, like the name of the computer, IP-address, and user identification are generated automatically by the OMA server. OMA holds available more then 1000 different options to customize the client. The image does not contain any software or operating system settings. Instead, OMA uses software packages to provide a high degree of flexibility. For every outcome you want to achieve unique deployment names can be created. For example, the name "Windows_Server_2012_domain_controller" may stand for the following installation steps:

  • Create partition tables
  • Format drive D:
  • Deploy drive C: (OMA partition image)
  • Transfer data of the hardware group
  • Transfer data of the client
  • Transfer software groups
  • Reboot
  • Enlarge drive C:
  • Reboot
  • Install software packages
  • Reboot
Windows starts after the second reboot. The individualization of the computer and the installation of the software packages takes places subsequently. Other outcomes than illustrated in this simplified example are archived easily. You may crate another deployment name. Yet, you may also just change the settings of "Windows_Server_2012_domain_controller". You also can change the process for individualization or the software group. However, no matter what specific settings you want to alter the image remains unchanged.
If you purchase new hardware, data regarding these specific hardware groups must only be saved once on the OMA server.
Hence, all you need to do after hardware groups are saved is create or modify software packages.
New software packages and patches are smoothly transferred via the online distribution. The operating system remains unaffected.

One image per hardware group

You should only use this feature either if you do not want a separate hardware settings for each hardware group or if hardware settings become to comprehensive.

One Image per client

You should only use this feature if the desired set up of a single client is not achievable through the creation of the necessary software packages. Backing up old client configurations is recommended.

Recovery

Recovery is a feature that allows you to set up the client based on an online transferred full-backup. OMA works hand in hand with your backup tool. Usually the recovery process is as follows: First, a OMA Client Console is booted via network. Second, a bootable minimum installation is made on the client. Third, the backup is transferred from the OMA server to the client. The feature is fully-automated, implemented via SSH, and accessible through a single recovery name.

Offline Deployment

Offline Deployment is a feature that allows you to set up the client without network connection. Necessary data is preferably provided by a none interactive Secure System Management Stick. However, other local data storage devices, like locale partitions, CDs and DVDs or USB hard drives can be used as well. The basic advantage of offline deployment comes with the fact that no specific knowledge is required. Basically all you need to do plug in the USB-Stick which makes the whole installation a peace of cake. More precisely the process is as follows:

  • Plug in USB-stick
  • Turn on the computer
  • Wait till the computer turns of automatically
  • Remove the USB stick
  • Turn on the computer

Configuration of operating systems

Usually the image does not contain any information regarding the client or operating system settings. Thus, OMA is able to provide highly flexible methods for tuning the operating system settings. Tuning is either carried out trough individualization or through the adjustment of the operating system via software packages.

Individualization of Clients

To individualize the client you need to allocate one of over 1000 different methods to the deployment. All necessary information, obtained from the OMA server, will be processed automatically.
Among other things, the following adjustments are conducted:

  • Machine name
  • Network configuration
  • User identification
  • Domain registrations
  • Workgroup
  • Autologon
The adjustments conducted via the individualization methods depend on the operating system you want to deploy.

Adjust operating system

Adjustments which are not conducted via individualization methods are implemented via software packages.

Install software

Deploying software packages is one of the essential features OMA offers. OMA distinguishes between three types of software packages:

  • Packages containing script
  • Packages containing data
  • Packages containing script and data
Data is compressed and stored on the OMA server, as opposed to scripts, which are stored yet not compressed. Hence, scripts may be easily adjusted at all times. OMA does not use a specific software package format. Instead, all conventional software package formats are supported. Examples include:
  • Configure Windows via loading Reg data
  • Configure Windows via System or PowerShell commands
  • Install Windows software via unattended setup
  • Configure Linux via data transfer
  • Configure Linux via Shell script
  • Install Linux software via .rpm oder .deb data
  • Install Mac OS X software via .dmg-data
  • ...
It is also possible to integrate already existing software deployment procedures in order that already existing packages need not be created twice. Software packages are transferred from the OMA server via SSH and are under no circumstances fetched by the client. The restricted rights of the client enables us to fulfill even the the highest security standards and maintain full control over of networks and server capacity at all times. Even if the client triggers the software deployment it is only allowed to signal that it is ready to receive data. The final decision whether or not software deployment starts rests with the OMA server.

Offline deployment

By offline deployment we mean the deployment of software packages within the operating system installation. This takes place before the computer boots up for the first time after installation. If necessary, an automated log in takes place after the computer boots in order to process the installation routines.

Online deployment

By online deployment we mean the deployment of software packages while a operating system is running on the client. Either before or after the installation is complete, necessary steps can be taken to ensure the proper functioning of the software.

It is possible to allow users to deploy selected software autonomously.

Patch management

Patches may be deployed online or offline through the above mentioned procedures.

Observation of Clients

There are quiet a few goods reasons why one wants to monitor a system. Yet, two things appear to be particularly important: First, one wants to know what kind of hardware is used. Secondly, one wants to review what software and versions are installed on the system.

Offline inventory

By offline inventory we mean an application for taking inventory of the client while the OMA Client Console is running. The method is primarily used to figure out what kind of hardware the client uses. The obtained information may be further processed in different ways. For example, it may be used to examine to which hardware group the client belongs before deploying starts. Having access to this relevant information will automatically ensure that the client receives the right data. This is particularly important if you know what kind of hardware you have, yet you do not know exactly which client uses which hardware.

Online inventory

By online inventory we mean gathering information while the operating system is running. No specific inventory software must be installed on the client. Before the OMA server retrieves information a script is delivered to the client. The script collects the defined data. Eventually, the OMA server summarizes and evaluates the information according to your preferences. Besides, it is possible to take information from third party systems into consideration.

OMA-Server-Cluster

OMA-servers may be arranged in a federated structure. Merging multiple OMA-servers in such manner enables the efficient maintenance of an unlimited number of clients. Within this federated structure, it is not necessary that each OMA-server knows each single client. A secondary OMA-server only knows its assigned clients. Each and every OMA-server within the network is still able to work as a self-sustaining system, that fulfills all functions without any network contact to other servers. To minimize administration effort one server is declared as the first OMA-base-server. Besides, another server is declared as the second OMA-base-server. The second systems steps in forthwith, if the first system fails for any reason. Only these omniscient OMA-base-servers know everything about each client within the system. All administration tasks are done by the first OMA-base-server. Only in the case of client installations a login on the assigned secondary OMA-server is necessary. If the federated structure of the the OMA-servers is redundant at least two OMA servers should be available to install a single client. The data transfer between the OMA-servers can be configured particularly filigree in order to match the bandwidth of the networks and the organizational requirements.

Virtual systems

OMA automatically creates the virtual systems, that you need on your real computers. Special Software packages are used to define the properties of the virtual machines. If you assign such a software package to a virtual client configuration, the OMA system creates an individual copy of this package for the client. This copy contains all individual details for the virtual machine. As a result, each real computer has a list of assigned virtual clients and each client has his own virtual machine definition. Thus, each user of a real computer has access to these virtual machines. If the user starts a virtual machine on a real client for the first time, OMA installs the predefined operating system. OMA controls which virtual machines exists on which real computers. The methods and procedures used for installing, modifying, and observing virtual and real computers are identical.