VMware

If you have a server running VMware or a VMware player, it only takes a few mouse clicks to install a base opsi-server:

ESXi-Server

Virtualbox

General

The VMware player is free of charge and available for all common operating systems at vmware.com. Usually it can be installed without any problems, as long as the resources of the host computer (especially memory) meet the needs of running software systems in parallel.

The first step is to choose the preferred language:

Figure 4.1. Language selection

The opsi-server needs to be connected to the Internet to work properly. The script 1stboot.py will automatically start at the first boot in order to configure the opsi-server network settings.

If something goes wrong while running 1stboot.py, then you may run 1stboot.py again from the command line.

The log file of 1stboot.py is located at /var/lib/1stboot/1stboot.log.

Figure 4.2. Startup mask

Fill in the configuration information for your network and answer the questions.

Figure 4.3. Input mask

In the following, you will be asked for:

After the program 1stboot.py finishes, the server VMware machine will be rebooted.

After the reboot, login as adminuser with your password.

The graphical user interface of the opsi-server should have already started (implemented as a sustainable window manager). A "Firefox" browser window might appear at startup, and display further instructions and information. This information can serve as a reference to the getting started document (the document you are currently reading).

If you get a message that there is no network connection, try rebooting the server. This might solve the problem.

Figure 4.4. View of fresh started opsi-server

If the network was correctly configured in the previous steps, then you should be able to remotely access the opsi-server, for example:

Use root as the user name, and authenticate with the root password.

In the following sections, some commands have to be entered into a command line interface. It may be the easiest way to work through these instructions.

The commands are input into a window called a "terminal window". Here are examples that explain how to access a terminal window:

We recommend cutting and pasting commands from this handbook directly into the opsi-server terminal window (most applications support cut and paste).

Example snippets from configuration files are formatted like this:

depoturl = smb://smbhost/sharename/path

Example snippets for commands that you have to execute are formatted like this:

cd /tmp
ls -l

Angle brackets < > mark abstract names. When entering commands, please replace the <abstract name> with a real name.
For example: The file share, where opsi places the software packages, may abstractly be noted as <opsi-depot-share>. If the real file share is /var/lib/opsi/depot, then you have to replace the abstract name by this exact string. The location of the package <opsi-depot-share>/ooffice becomes /var/lib/opsi/depot/ooffice. .

If the network configuration is correct, and the computer is connected to the Internet, then you can access any Internet address using the browser in the start window.

If the Internet connection is not working, then you have to open a terminal window (maybe remote access isn’t possible, except using the server terminal window) and then perform the necessary network connection checks and fixes.

You can re-enter the network configuration by entering this command in the terminal window:

1stboot.py

A reboot is forced with the command:

reboot

If the network connection works, then you can install opsi packages or update them, and configure the environment for the first installation test. If you want to use the VMware machine (and not install the opsi-server directly to your host system), then skip to Section 4.2, “Update and Configuration of the opsi-server”.

To update your opsi-Server you need to double click the Icon "Update Manager" on the desktop.

By performing a double click the Icon opsi-product-updater FirstRun the minimal opsi Products will be installed. To do this please introduce the current password for the adminuser. Through this installation the actual stock of opsi-products, incl. templates for Windows- and Linux-OS, will be downloaded from http://download.uib.de/opsi4.0/products/ and installed on the server. For more information you can see here Section 4.5, “Install the Minimal opsi Products”.

For a description of the Server Interface check Section 4.7, “Starting the management interface (opsi-configed)”.

You have a running opsi server now, i.e. the opsi application itself is fully configured.

You can now proceed with:

In the Univention App-Center an automatic installation of the opsi-Server is available. The installation-app for opsi can be found in the UCS-Management-Webinterface in the category "System". Over the App-Center opsi can be installed on UCS4-Serverroles Master and Backup. If you want to update a existing opsi4ucs-Installation please check the next Chapter for further information.
The following will describe what will be happen during a installation:

Please note that no automatic transfer of clients to opsi takes place. More information at the section called “Synchronising data from LDAP to opsi”.

After the described steps the opsi-Installation on a UCS-Server over the Univention App-Center is finished. Please continue with following chapter: Section 4.6, “Installing and Checking the Activation File”

Since opsi 4.0.5 the group opsifileadmins replaces the group pcpatch in UCS. This group has already been introduced with the support of UCS 3.0, but only on installations that had Samba 4 and the Univention Directory Services (Samba4-AD). In all other Variants and roles the group continues to be, as it was before pcpatch.

Since this situation represents a problem not only on the installation, but could also lead to potential problems with migrations (especially of Samba3 on Samba4) since the release of 4.0.5 the group pcpatch will be created as opsifileadmins.

Make sure the conditions in Section 2.3, “Configuration Requirement” are fulfilled.

Necessary preparations:

The installation of opsi is possible on the roles master, backup, slave and member. For the installation on a member you need to read the section called “Hints about installing opsi on an UCS server with the role member”!

The following documentation describes an installation on a master with Samba4.

The classic installation with the user: pcpatch in the primary group: pcpatch does not work with UCS. Samba4 has placed fundamental restrictions on the Active-Directory, so groups with the same name as a user are no longer allowed. For this reason the configuration file /etc/opsi/opsi.conf has been introduced. This file controls how the group used for Samba access will be named. More specifically for UCS the group name pcpatch will be renamed to opsifileadmins. This means that users that need clearance for opsi (opsi package builder for example) can’t be members of the group pcpatch but must be member of opsifileadmins. This peculiarity applies only to UCS and is different to other distributions and chapters in the opsi-documentation. Furthermore, since UCS 3 the user pcpatch is created as an domain user. For more information about this new configuration file please refer the opsi-manual.

UCS 4.2:
 

echo 'deb http://download.opensuse.org/repositories/home:/uibmz:/opsi:/opsi40/Univention_4.2/ /' > /etc/apt/sources.list.d/opsi.list

Now import the key to the repository system with the following command:

UCS 4.2. 

wget -O - http://download.opensuse.org/repositories/home:/uibmz:/opsi:/opsi40/Univention_4.2/Release.key | apt-key add -

For the installation the following commands must be entered:

univention-install opsi-atftpd
univention-install opsi4ucs
univention-install cabextract mysql-server p7zip-full wimtools

If the role of the target systems different than Master or Backup then the following commands run the opsi4ucs Join-Script:

univention-run-join-scripts

A link to the management interface can be found at the URL https://<servername>:4447.

Finally the opsi_depot release point must be released in UDM. To realize this settings set the link to yes under Advanced Settings → Advanced Samba Settings: follow symlinks. The same should be done for the opsi_depot_rw, so the driver integration will run without problems. If the directory /var/lib/opsi/depot was found on an extra partition or hard disk then the option for wide links should be set to yes.

To make sure that opsi is running with the proper settings restart opsi by entering the following commands:

opsi-setup --init-current-config
opsi-setup --set-rights
service opsiconfd restart
service opsipxeconfd restart

Since UCS 3 there is no direct contact between the Univention LDAP backend and opsi. Clients must first be created in LDAP using opsi over udm including all system information (in particular the MAC address). Deleting the LDAP clients in Univention does not mean that the client was also deleted under opsi. A solution for this is in the section called “Synchronising data from LDAP to opsi”.

Since opsi has already been run on the server we assume that the network configuration is correct.
Continue with the installation be skipping forward to Section 4.2.3, “Backend Configuration”.

Installing opsi on a server with the role member is possible. However an automated installation through the Univention App Center is currently not possible.

After an installation you need to make sure that the setting for the user that will be used to access the depot is set with the current domain. Control the host parameter clientconfig.depot.user for this. Let’s assume that the domain is backstage, then the value has to be backstage\pcpatch. If it is memberserver\pcpatch then it has to be changed.

Setting the password for the user pcpatch through opsi-admin fails because of the missing AD write access of a member server. To change the password you have to do so additionally on a server with write access - a master, backup or slave.

If the PXE-Boot should used for OS installations the DHCP-service on the relevant UCS-System has to be reconfigured. There are two characteristics which UCS differentiate from other supported distributions.

You have to set guide lines to realized the mentioned configurations at the UCS-System. These guide lines are depend on existent guide lines and has to realize appropriate. If opsi was installed on an UCS-test system without existing guide lines you need an installed DHCP-service at first. If the DHCP-service is installed already the easiest way to create guide lines in the UMC-web interface (Univention Management Console) is from UCS-server. Therefore choose the category "Domain" and subjacent the module DHCP-server. As next you have to choose the service (in a testing system you find only one entry usally). In the following detail views choose guide lines in the menu. The needed guide line is a DHCP-Boot guide line. During the guide line configuration dial as default entry cn=default-settings (sould be the only entry) and choose edit. Under the normal settings DHCP-boot for the option Bootserver enter the IP from opsi-server and insert as boot-file name pxelinux.0.

Optional you can run the udm-commands at the console. You can find more informations in the UCS-documentation.

In an opsi4ucs installation Windows-Clients have to be created in the UDM first and in a second step they have to be created in opsi. Changes to the client in UDM will not be passed on to opsi. For example if a client’s MAC address changes in LDAP and in opsi a netboot-product is set to setup, the boot configuration would be provided with a wrong MAC address.

A solution for this is the extension opsi-directory-connector. Please consult the manual for more information.

The easiest available method for tweaking your PE requires a computer that has opsi-client-agent installed, as well as a Windows ADK (Win8.1,Win10). Doing all steps manually is being described below the section called “Manually Creating a PE”.

opsi-setup --set-rights

Here is how to manually tweak a PE. The console commands are very similar in 32- or 64-bit versions, except for the <ARCH> entries. These have to be set to either x86 , amd64 or ia64.

Start a terminal as Administrator with elevated rights (Start ⇒ Programs ⇒ Accessories ⇒ right click on "Command Prompt" ⇒ "Run as" ⇒ Administrator)

"%ProgramFiles%\Windows AIK\Tools\PETools\copype.cmd" <ARCH> C:\winpe

"%ProgramFiles%\Windows AIK\Tools\<ARCH>\imagex.exe" /mountrw "C:\winpe\winpe.wim" 1 "C:\winpe\mount"

echo c:\opsi\startnet.cmd > "C:\winpe\mount\Windows\System32\startnet.cmd"

(Remark: The file startnet.cmd will be created by the opsi linux boot image after the script setup.py is executed. The startnet.cmd contains the call to wpeinit.)

"%ProgramFiles%\Windows AIK\Tools\<ARCH>\imagex.exe" /commit /unmount "C:\winpe\mount"

move "C:\winpe\winpe.wim" "C:\winpe\ISO\sources\boot.wim"

opsi-setup --set-rights /var/lib/opsi/depot/<productid>/winpe

run Start > "Windows Kits" > "Windows ADK" > "Deployment and Imaging Toolkits Environment" from the Start Menu. You will see a command prompt, but with some enironment variables set.

copype.cmd <ARCH> C:\winpe

dism /Mount-Wim /WimFile:C:\winpe\media\sources\boot.wim /index:1 /MountDir:c:\winpe\mount

echo c:\opsi\startnet.cmd > "C:\winpe\mount\Windows\System32\startnet.cmd"

(Remark: The file startnet.cmd will be created by the opsi linux boot image after the script setup.py is executed. The startnet.cmd contains the call to wpeinit.)

dism /Unmount-Wim /MountDir:c:\winpe\mount /Commit

opsi-setup --set-rights /var/lib/opsi/depot/<productid>/winpe

In some cases it is useful to extend a PE. Especially when using Dell-Hardware. Dell provides special network and storage drivers for use in PE. These instructions only work with Windows 7. (Windows Vista does not inherit the needed DISM- Deployment Image Servicing and Management.) These instructions assume that you have already completed the chapter "Creating a PE".

The first step is to download Dell-PE-drivers from the Dell-Website. For Windows 7, you will need the WINPE 3.0 Drivers from Dell. The downloaded CAB-File must be extracted to the local disk. This can be done with 7zip or the command-line-tool Expand.exe. For simplicity, we recommend creating a directory called "dell-driver" on the local disk, and then extracting the CAB-File into this directory.

dism /Get-WimInfo /WimFile:C:\winpe\ISO\sources\boot.wim

In the output of this command, you can see which images are included in the image file.

dism /Mount-Wim /WimFile:C:\winpe\ISO\sources\boot.wim /index:1 /MountDir:c:\winpe\mount

dism /Image:C:\winpe\mount /Add-Driver /Driver:c:\dell-driver\winpe\x64 /Recurse

If the architecture is 32Bit, the x64 must be replaced with x86. The Driver-CAB from Dell inherits drivers for both architectures.

dism /Unmount-Wim /MountDir:c:\winpe\mount /Commit

opsi-setup --set-rights /var/lib/opsi/depot/win7/winpe

The control file for the unattended installation is the XML file unattend.xml, which you can find under /var/lib/opsi/depot/win7/custom. If you would like to make any modifications to this file, then do it in this directory and not in the opsi directory.

The file unattend.xml that comes with the opsi package, contains the activating of the Administrator account with the password nt123.

Documentation of the file unattend.xml can be found (after the installing WAIK) in the directory c:\Program Files\Windows\Waik\docs\chms.

Place your driver directories in /var/lib/opsi/depot/<product-id>/drivers/drivers. Then call the script create_driver_links.py in the folder /var/lib/opsi/depot/<product-id>/.

Please keep in mind that only signed drivers are accepted. Therefore, if you want to use driver packs like the driver packs from driverpacks.net, be sure to use only the Windows 7/8.1/10 versions.

Copy the complete installation DVD to
/var/lib/opsi/depot/win7/installfiles Adjust the file access rights by entering:

opsi-setup --set-rights /var/lib/opsi/depot/win7/installfiles

<productid>-
           |-i386/                              NT5 only: Installations files
           |-installfiles/                      NT6 only: Installations files
           |-winpe/                             NT6 only
           |-opsi/                              scripts and templates by opsi.org
           |  |-$oem$/                                  NT5 only: $oem$ according to MS
           |  |-postinst.d/                             scripts after OS-install by opsi.org
           |  !-unattend.(txt/xml).template             Template by opsi.org
           |-custom/                            scripts and templates by customer
           |  |-$oem$/                                  NT5 only: $oem$ according to MS by customer
           |  |-postinst.d/                             scripts after OS-install by customer
           |  !-unattend.(txt/xml)                      unattend.txt by customer
           |-drivers/                           drivers directory
           |  |-drivers/                        drivers directory
           |  |-pciids/                         symbolic links to drivers
           |  |-vendors/                        symbolic links to drivers
           |  |-classes/                        symbolic links to drivers
           |  |-usbids/                         symbolic links to drivers
           |  |-hdaudioids/                     symbolic links to drivers
           |  |-pci.ids                         PCI-IDs DB
           |  !-usb.ids                         USB-IDs DB
           |-setup.py                           installation script
           |-<productid>_<version>.control      meta data (only for info)
           |-<productid>.files                  file list (created automatically)
           |-create_driver_links.py             driver management script
           |-show_drivers.py                    driver management script
           |-download_driver_pack.py            driver management script
           !-extract_driver_pack.py             driver management script

Both directories contain scripts and configuration files for the OS installation. During the installation process, the directories work together in such a way that they give the priority usage to the files in the custom directories.

The opsi directory contains files and templates that are maintained by opsi.org, and maybe replaced during the next update. So it’s not a good idea to make specific (or customized) changes to these files in this location. Please use the custom directory for this purpose, because that directory is not subject to any changes by opsi.org.

The subdirectory postinst.d contains scripts which are executed after the OS installation is completed by the postinst.cmd program. These scripts are needed to install the opsi-client-agent, among other software. The scripts will be executed in alphabetic order. To make it easier to see the order in which the scripts will be executed, the name always starts with a 2 digit number (10_dhcp.cmd). If you want to make extensions, then please do so in the custom/postinst.d directory and start numbers between the 10, 20, 30 ,… (e.g. 13_myscript.cmd). The starting numbers 10, 20, 30,… are reserved for use by opsi org / uib gmbh. The script 99_cleanup.cmd is the last one and initiate a reboot.

This directory is used for the integration of drivers and is described in the following chapter.

When the hardware configuration is very heterogeneous, then it may be reasonable to work with general driver packages.
General drivers can be placed under ./drivers/drivers.
You can find example of general driver packages here http://driverpacks.net/ .
Download the appropriate driver package to a temporary directory, and then unpack the driver package using the opsi script extract_driver_pack.py as such:

./extract_driver_pack.py <path to the temporary directory with the compressed driverpacks>

This will unpack and store the drivers in the directory ./drivers/drivers/.
It may be the case that the drivers found by opsi in this location do not necessarily work with your hardware.
For the drivers which are found in ./drivers/drivers/, the driver will be matched to the corresponding hardware using the PCI IDs (i.e. USB- or HD_Audio-ID) in the description file, and then integrated into the Windows setup as needed.

In the case that you have to support special hardware, and you can find the additional drivers from the manufacturers, then use the following procedure to include them in the installation.
Place the additional drivers in their own directory under:
./drivers/drivers/preferred.
(the naming and depth of the directory structure is not important). Drivers that are found in the directory ./drivers/drivers/preferred will be integrated into the Windows setup, assuming that opsi finds a suitable match to the drive hardware based off of the PCI IDs (i.e. USB or HD_Audo-ID) in the description file.
Problems can occur when the same PCI ID of the drivers is found in preferred. In this case, a direct mapping of the drivers to the devices is needed.

When installing additional drivers based on the PCI-IDs or USB-IDs, they should be installed under the directory ./drivers/drivers/additional (where name and depth of the directory structure is not important). You can map one or more drivers to a client using the Product-Property additional_drivers and a list of driver directories under ./drivers/drivers/additional. The directories specified by additional_drivers are searched recursively until all drivers are found. This method can be used to make a specific directory based on the client type (i.e. dell-optiplex-815).

When a driver is found under the drivers directory that is specified by additional_drivers and also matches the PCI identifier, then other drivers in drivers/preferred or drivers/ will not be used. Therefore the drivers under additional_drivers add functionality that would not have been found with the normal drivers. Also, the drivers that are manually bound to a client using additional_drivers receive priority over other drivers (additional_drivers can be thought of as super-preferred).

The previously described mechanisms that directly map drivers to devices is automated since the 4.0.2 Release 2 of opsi. The opsi-linux-bootimage will search the directory ./drivers/drivers/additional/byAudit for a director name that matches the field Vendor that was given in the Hardware Inventory. This Vendor directory will be search for a Model directory that corresponds to what is seen in Hardware Inventory. If this directory is found, then it will be manually assigned to the product property additional_drivers.
The directory name byAudit is case sensitive. The directory names for Vendor and Model are not case sensitive (Dell and dELL are treated the same way).

Since opsi 4.0.5 one can use opsi-configed for uploading the drivers Automatic driver upload (see opsi-manual "Automatic driver upload")

The opsi-linux-bootimage looks first for drivers in

/var/
  !-lib/
     !-opsi/depot/
        !-<productid>/
           !-drivers
              |-classes/                (Links to driver device classes)
              |-hdaudioids/             (Links to HD-Audio drivers)
              |-pciids/                 (Links to PCI-ID drivers)
              |-pci.ids                 (PCI database)
              |-usbids/                 (Links to USB-ID drivers)
              |-usb.ids                 (USB database)
              |-vendors/                (Links to manufacturer drivers)
              !-drivers                 (place for general driver packages)
                 |-additional/          (manually assigned drivers)
                    |-byAudit/          Model-specific drivers that
                       |-<vendor>               will be assigned by
                          |-<model>             the Hardware Inventory
                 |-buildin/             (data for the i386 version)
                 |-preferred/           (certified drivers)
                 |-exclude/             (excluded drivers)
                 !-mydriverpacks/       (example driver packages)

The top priority is given to drivers that are found using the property additional_drivers or using the inventory data in ./drivers/drivers/additional/byAudit. Tests will be made during driver integration to determine which drivers are already installed on which hardware devices. When a driver is not found for a device, the following method will be used to search for drivers.

For devices that have drivers that were not listed in additional_drivers, opsi will search for, and integrate, an appropriate driver based off of the PCI ID (ie. USB-, HD_Audio-ID).

Integration of drivers means the following:

After any changes in the directory ./drivers/drivers have been made, call the following command from the Netboot Products root directory in order to set the permissions:

opsi-setup --set-rights ./drivers

Then call the script ./create_driver_links.py. The script searches through the directories under ./drivers/drivers and generates a list of links using PCI-IDs, USB-IDs, HD-Audio-IDs that enables hardware to know about drivers. The script will use the drivers in the preferred directories.

The script setup.py examines the hardware of the installed computers and identifies the necessary drivers. These will be copied to the disk and the file unattended.txt will be patched. The script create_driver_links.py examines the NT5 products one at a time in the i386 tree and extracts the .inf files of the necessary drivers into windows_builtin. If you make a change to the i386 directory tree (i.e. after installing a service pack), then delete that directory and run create_driver_links.py again. The recognized drivers for NT6 products are found in WinPE at windows_builtin.

With the following command, one can see the hardware inventory for a client:

./show_drivers.py <clientname>

When this is command is called, it will show a selection for which drivers would be chosen for installation to the Bootimage via PCI-IDs, USB-IDs, HD-Audio-IDs, and additional_drivers (or byAudit), and which hardware still has no driver.

Use the output of show_drivers.py to check and see which drivers need to be installed.

It could be that manufacturers include different drivers for different operating systems (i.e. Vista vs. Win7) or different configurations (ie. SATA vs. SATA RAID). The create_driver_links.py cannot make this distinction. If you think the wrong driver has been installed, then move the driver to the drivers/exclude directory and then call create_driver_links.py again. Drivers in the directory drivers/exclude are not used during the integration.

Example output of a show_drivers.py call:

./show_drivers.py pcdummy

PCI-Devices
   [(Standardsystemgeräte), PCI Standard-PCI-zu-PCI-Bridge]
      No driver - device directory  /var/lib/opsi/depot/<productid>/drivers/pciids/1022/9602 not found
   [ATI Technologies Inc., Rage Fury Pro (Microsoft Corporation)]
      Using build-in windows driver
   [(Standard-IDE-ATA/ATAPI-Controller), Standard-Zweikanal-PCI-IDE-Controller]
      /var/lib/opsi/depot/<productid>/drivers/drivers/D/M/N/123
   [Realtek Semiconductor Corp., Realtek RTL8168C(P)/8111C(P) PCI-E Gigabit Ethernet NIC]
      /var/lib/opsi/depot/<productid>/drivers/drivers/preferred/realtek_gigabit_net_8111_8168b
   [IEEE 1394 OHCI-konformer Hostcontroller-Hersteller, OHCI-konformer IEEE 1394-Hostcontroller]
      No driver - device directory '/var/lib/opsi/depot/<productid>/drivers/pciids/197B/2380' not found
   [Advanced Micro Devices, Inc., AMD AHCI Compatible RAID Controller]
      /var/lib/opsi/depot/<productid>/drivers/drivers/preferred/ati_raid_sb7xx
   [(Standard-USB-Hostcontroller), Standard OpenHCD USB-Hostcontroller]
      No driver - device directory '/var/lib/opsi/depot/<productid>/drivers/pciids/1002/4397' not found
   [ATI Technologies Inc, ATI SMBus]
      /var/lib/opsi/depot/<productid>/drivers/drivers/preferred/ati_smbus

USB-Devices
   [(Standard-USB-Hostcontroller), USB-Verbundgerät]
      /var/lib/opsi/depot/<productid>/drivers/drivers/preferred/brother_844x_pGerb
   [Microsoft, USB-Druckerunterstützung]
      /var/lib/opsi/depot/<productid>/drivers/drivers/preferred/brother_844x_pGerb

Additional drivers
   [ati_hdaudio_azalia]
     /var/lib/opsi/depot/<productid>/drivers/drivers/additional/ati_hdaudio_azalia

Example with additional_drivers:

 ./show_drivers.py e5800
Manually selected drivers (additional)
   [hp_e5800]
      [/var/lib/opsi/depot/<productid>/drivers/drivers/additional/hp_e5800/sp52852/Vista64/HDXHPAI3.inf]
      [/var/lib/opsi/depot/<productid>/drivers/drivers/additional/hp_e5800/sp52852/Vista64/HDX861A.inf]
      [/var/lib/opsi/depot/<productid>/drivers/drivers/additional/hp_e5800/sp52852/Vista64/HDXHPAI1.inf]
      [/var/lib/opsi/depot/<productid>/drivers/drivers/additional/hp_e5800/sp52852/Vista64/HDXCPC.inf]
      [/var/lib/opsi/depot/<productid>/drivers/drivers/additional/hp_e5800/sp52852/Vista64/HDXHPAI2.inf]
      [/var/lib/opsi/depot/<productid>/drivers/drivers/additional/hp_e5800/sp50134/autorun.inf]
      [/var/lib/opsi/depot/<productid>/drivers/drivers/additional/hp_e5800/sp50134/ibxHDMI/IntcDAud.inf]
      [/var/lib/opsi/depot/<productid>/drivers/drivers/additional/hp_e5800/sp50134/HDMI/IntcHdmi.inf]
      [/var/lib/opsi/depot/<productid>/drivers/drivers/additional/hp_e5800/sp50134/Graphics/kit24890.inf]
      [/var/lib/opsi/depot/<productid>/drivers/drivers/additional/hp_e5800/sp50134/IIPS/Impcd.inf]
      [/var/lib/opsi/depot/<productid>/drivers/drivers/additional/hp_e5800/sp54284/Realtek 64bit/hp64win7.inf]

PCI-Devices
   [8086:27C8]  Intel : Intel(R) N10/ICH7 Family USB Universal Host Controller - 27C8
      /var/lib/opsi/depot/<productid>/drivers/drivers/preferred/R293337/WIN7
   [8086:27DA]  Intel : Intel(R) N10/ICH7 Family SMBus Controller - 27DA
      /var/lib/opsi/depot/<productid>/drivers/drivers/preferred/R293337/WIN7
   [8086:27C9]  Intel : Intel(R) N10/ICH7 Family USB Universal Host Controller - 27C9
      /var/lib/opsi/depot/<productid>/drivers/drivers/preferred/R293337/WIN7
   [8086:27DF]  Intel : Intel(R) ICH7 Family Ultra ATA Storage Controllers - 27DF
      /var/lib/opsi/depot/<productid>/drivers/drivers/preferred/R293337/WIN7
   [8086:27CA]  Intel : Intel(R) N10/ICH7 Family USB Universal Host Controller - 27CA
      /var/lib/opsi/depot/<productid>/drivers/drivers/preferred/R293337/WIN7
   [8086:2E30]  Intel : Intel(R) 4 Series Chipset Processor to I/O Controller - 2E30
      /var/lib/opsi/depot/<productid>/drivers/drivers/not_preferred/x64/C/Intel/1
   [8086:27CB]  Intel : Intel(R) N10/ICH7 Family USB Universal Host Controller - 27CB
      /var/lib/opsi/depot/<productid>/drivers/drivers/preferred/R293337/WIN7
   [8086:2E32]  Intel Corporation : Intel(R) G41 Express Chipset
      Manually selected [hp_e5800] /var/lib/opsi/depot/<productid>/drivers/drivers/additional/hp_e5800/sp50134/Graphics
   [8086:27CC]  Intel : Intel(R) N10/ICH7 Family USB2 Enhanced Host Controller - 27CC
      /var/lib/opsi/depot/<productid>/drivers/drivers/preferred/R293337/WIN7
   [8086:244E]  Intel : Intel(R) 82801 PCI-Brücke - 244E
      Using build-in windows driver
      This driver will not be integrated, because same device already integrated in: '/var/lib/opsi/depot/<productid>/drivers/drivers/not_preferred/x64/C/Intel/1/dmi_pci.inf'
   [8086:27D0]  Intel : Intel(R) N10/ICH7 Family PCI Express Root Port - 27D0
      /var/lib/opsi/depot/<productid>/drivers/drivers/preferred/R293337/WIN7
   [8086:27B8]  Intel : Intel(R) ICH7 Family LPC Interface Controller - 27B8
      /var/lib/opsi/depot/<productid>/drivers/drivers/preferred/R293337/WIN7
   [8086:27D2]  Intel : Intel(R) N10/ICH7 Family PCI Express Root Port - 27D2
      /var/lib/opsi/depot/<productid>/drivers/drivers/preferred/R293337/WIN7
   [8086:27C0]  Intel : Intel(R) N10/ICH7 Family Serial ATA Storage Controller - 27C0
      /var/lib/opsi/depot/<productid>/drivers/drivers/preferred/R293337/WIN7
   [8086:27D8]  Microsoft : High Definition Audio-Controller
      No driver - device directory '/var/lib/opsi/depot/<productid>/drivers/pciids/8086/27D8' not found
   [10EC:8136]  Realtek : Realtek RTL8102E/RTL8103E-Familie-PCI-E-Fast-Ethernet-NIC (NDIS 6.20)
      Manually selected [hp_e5800] /var/lib/opsi/depot/<productid>/drivers/drivers/additional/hp_e5800/sp54284/Realtek 64bit

USB-Devices
   [0461:0010]  (Standardsystemgeräte) : USB-Eingabegerät
      No driver - vendor directory '/var/lib/opsi/depot/<productid>/drivers/usbids/0461' not found
   [0461:4D20]  (Standardsystemgeräte) : USB-Eingabegerät
      No driver - vendor directory '/var/lib/opsi/depot/<productid>/drivers/usbids/0461' not found
   [058F:6366]  Kompatibles USB-Speichergerät : USB-Massenspeichergerät
      No driver - vendor directory '/var/lib/opsi/depot/<productid>/drivers/usbids/058F' not found
   [0461:0010]  (Standard-USB-Hostcontroller) : USB-Verbundgerät
      No driver - vendor directory '/var/lib/opsi/depot/<productid>/drivers/usbids/0461' not found

HD-Audio-Devices
   [10EC:0662]  Realtek High Definition Audio
      Manually selected [hp_e5800] /var/lib/opsi/depot/<productid>/drivers/drivers/additional/hp_e5800/sp52852/Vista64

Example with byAudit:

 ./show_drivers.py pctry5detlef
Manually selected drivers (additional)
   [/var/lib/opsi/depot/<productid>/drivers/drivers/additional/byAudit/nvidia/awrdacpi]
      [/var/lib/opsi/depot/<productid>/drivers/drivers/additional/byAudit/nvidia/awrdacpi/pctry5detlef/Display/Radeon X300-X550-X1050 Series Secondary (Microsoft Corporation - WDDM)/atiilhag.inf]
      [/var/lib/opsi/depot/<productid>/drivers/drivers/additional/byAudit/nvidia/awrdacpi/pctry5detlef/Display/Radeon X300-X550-X1050 Series (Microsoft Corporation - WDDM)/atiilhag.inf]
      [/var/lib/opsi/depot/<productid>/drivers/drivers/additional/byAudit/nvidia/awrdacpi/pctry5detlef/MEDIA/Realtek AC'97 Audio/oem21.inf]

PCI-Devices
   [1002:5B70]  ATI Technologies Inc. : Radeon X300/X550/X1050 Series Secondary (Microsoft Corporation - WDDM)
      Manually selected [/var/lib/opsi/depot/<productid>/drivers/drivers/additional/byAudit/nvidia/awrdacpi] /var/lib/opsi/depot/<productid>/drivers/drivers/additional/byAudit/nvidia/awrdacpi/pctry5detlef/Display/Radeon X300-X550-X1050 Series Secondary (Microsoft Corporation - WDDM)
      Multiple selected [/var/lib/opsi/depot/<productid>/drivers/drivers/additional/byAudit/nvidia/awrdacpi] /var/lib/opsi/depot/<productid>/drivers/drivers/additional/byAudit/nvidia/awrdacpi/pctry5detlef/Display/Radeon X300-X550-X1050 Series (Microsoft Corporation - WDDM)
   [10DE:0053]  (Standard-IDE-ATA/ATAPI-Controller) : Standard-Zweikanal-PCI-IDE-Controller
      No driver - device directory '/var/lib/opsi/depot/<productid>/drivers/pciids/10DE/0053' not found
   [10DE:005D]  (Standardsystemgeräte) : PCI Standard-PCI-zu-PCI-Brücke
      No driver - device directory '/var/lib/opsi/depot/<productid>/drivers/pciids/10DE/005D' not found
   [1022:1100]  AMD : AMD HyperTransport(tm)-Konfiguration
      Using build-in windows driver
   [10DE:0054]  (Standard-IDE-ATA/ATAPI-Controller) : Standard-Zweikanal-PCI-IDE-Controller
      /var/lib/opsi/depot/<productid>/drivers/drivers/preferred/evb_potsdam_fsc__esprimo_p625/FTS_NVIDIASATAAHCIDRIVERVISTA64V103042MCP78__1026963/NVIDIA_SATA_AHCI_DRIVER_Vista64_V10.3.0.42_MCP78 (textmode capable)
   [1022:1101]  AMD : AMD-Adresszuordnungskonfiguration
      Using build-in windows driver
   [10DE:0055]  (Standard-IDE-ATA/ATAPI-Controller) : Standard-Zweikanal-PCI-IDE-Controller
      /var/lib/opsi/depot/<productid>/drivers/drivers/preferred/evb_potsdam_fsc__esprimo_p625/FTS_NVIDIASATAAHCIDRIVERVISTA64V103042MCP78__1026963/NVIDIA_SATA_AHCI_DRIVER_Vista64_V10.3.0.42_MCP78 (textmode capable)
   [1022:1102]  AMD : AMD DRAM und HyperTransport(tm)-Nachverfolgungsmoduskonfiguration
      Using build-in windows driver
   [10DE:0057]  NVIDIA : NVIDIA nForce-Netzwerkcontroller
      Using build-in windows driver
   [1022:1103]  AMD : Sonstige AMD-Konfiguration
      Using build-in windows driver
   [10DE:0059]  Realtek : Realtek AC'97 Audio
      Manually selected [/var/lib/opsi/depot/<productid>/drivers/drivers/additional/byAudit/nvidia/awrdacpi] /var/lib/opsi/depot/<productid>/drivers/drivers/additional/byAudit/nvidia/awrdacpi/pctry5detlef/MEDIA/Realtek AC'97 Audio
   [10DE:005E]  NVIDIA : NVIDIA nForce4 HyperTransport-Brücke
      /var/lib/opsi/depot/<productid>/drivers/drivers/preferred/ga-ma78-pcbon4/chipset_win7-64/SMBUS
   [104C:8025]  Texas Instruments : OHCI-konformer Texas Instruments 1394-Hostcontroller
      No driver - device directory '/var/lib/opsi/depot/<productid>/drivers/pciids/104C/8025' not found
   [10DE:005A]  (Standard-USB-Hostcontroller) : Standard OpenHCD USB-Hostcontroller
      No driver - device directory '/var/lib/opsi/depot/<productid>/drivers/pciids/10DE/005A' not found
   [10DE:0050]  (Standardsystemgeräte) : PCI Standard-ISA-Brücke
      No driver - device directory '/var/lib/opsi/depot/<productid>/drivers/pciids/10DE/0050' not found
   [10DE:005B]  (Standard-USB-Hostcontroller) : Standard PCI-zu-USB erweiterter Hostcontroller
      No driver - device directory '/var/lib/opsi/depot/<productid>/drivers/pciids/10DE/005B' not found
   [1002:5B60]  ATI Technologies Inc. : Radeon X300/X550/X1050 Series (Microsoft Corporation - WDDM)
      Manually selected [/var/lib/opsi/depot/<productid>/drivers/drivers/additional/byAudit/nvidia/awrdacpi] /var/lib/opsi/depot/<productid>/drivers/drivers/additional/byAudit/nvidia/awrdacpi/pctry5detlef/Display/Radeon X300-X550-X1050 Series Secondary (Microsoft Corporation - WDDM)
      Multiple selected [/var/lib/opsi/depot/<productid>/drivers/drivers/additional/byAudit/nvidia/awrdacpi] /var/lib/opsi/depot/<productid>/drivers/drivers/additional/byAudit/nvidia/awrdacpi/pctry5detlef/Display/Radeon X300-X550-X1050 Series (Microsoft Corporation - WDDM)
   [10DE:0052]  NVIDIA : NVIDIA nForce PCI-Systemverwaltung
      Using build-in windows driver
   [10DE:005C]  (Standardsystemgeräte) : PCI Standard-PCI-zu-PCI-Brücke
      No driver - device directory '/var/lib/opsi/depot/<productid>/drivers/pciids/10DE/005C' not found

USB-Devices
   [1241:1111]  (Standardsystemgeräte) : USB-Eingabegerät
      No driver - vendor directory '/var/lib/opsi/depot/<productid>/drivers/usbids/1241' not found

HD-Audio-Devices
   No devices installed

Example:

DefVar $ProductId$
Set $ProductId$ = "firefox"

Displaying text during runtime:
Message <string>

Example:

Message "Installing "+ $ProductId$ +" ..."

Displaying a picture during installation:
ShowBitMap [<file name>] [<sub title>]

Example:

ShowBitmap "%ScriptPath%\python.png" "Python"

Syntax:

if <condition>
        ;statement(s)
[
else
        ;statement(s)
]
endif

For an unattended or silent setup, the original setup will be switched to an unattended non-interactive mode using the proper command line arguments.

The problem is to find the correct arguments

Look on the internet: Before you start integrating a new package, you’d better first have a look online to see if somebody has already done that job for you:

Ready to run opsi-winst scripts, built by the community, can be found at the opsi wiki.

A collection of links to web sites with switch collections can be found at opsi wiki: Software integration web-links.

Search the software producer’s site: Many software manufacturers are aware of the needs of unattended software distribution, so there are often some hints and instructions in the product documentation or on the software producer’s website.

Identify the manufacturer of the setup program: Most setup programs are built using frameworks like Inno, NSIS, Installshield or Wise. Each one of these setup frameworks has their own switch. The following method can be used to determine the framework and other necessary information: The input strings can be determined using the command line program strings given the setup program setup.exe, and the output framework names can be found using grep or findstr.

The Linux commands looks like this (change <mysetup.exe> to the name of your setup.exe):

strings <mysetup.exe> | grep -i -E "(inno|nsis|installshield|wise)"

Windows does not have a native strings command, so you will have to install it. You can download a strings.exe program from here: http://technet.microsoft.com/en-us/sysinternals/bb897439

To use this program, enter these commands at the command line interface (change <mysetup.exe> to the name of your setup.exe):

strings.exe <mysetup.exe> | findstr /i /r "inno installshield nsis wise"

The same method is used in the opsi-setup-detector. See the example below:

Figure 7.6. opsi setup detector

This GUI program can be called from the Windows context menu Explore.

Figure 7.7. opsi setup detector in Windows Explore context menu

The opsi setup detector is part of the Windows package repositories and can be obtained through them.

A collection of links to web sites with switch collections can be found at opsi wiki: Software integration web-links.

A short overview of the opsi-winst commands can be found in the opsi-script reference card.

All syntax details are described in the opsi-script manual.

Here are some hints regarding important methods:

Stringlisten. String lists can be powerful tools to review the output from other programs. Read the opsi-winst manual for details.

Product Properties. For some products it is important to know which product properties can modify the installation in order to make a client-specific installation. Creating these properties is described below in "Creating an opsi package".

To evaluate these properties, opsi-winst provides the function GetProductProperty

if GetProductProperty("example-property", "no") = "yes"
        Files_copy_extra_files
endif

Before we begin, we assume that you have tried an unattended installation using an opsi-winst script, and the installation worked OK when the user had administrative privileges. However with some software products, you will see that the installation fails when started from within the opsi deployment software (opsi-client-agent). A possible reason for that difference might be that the installation process requires knowledge about the user environment or profile.

In the case of a MSI package, the option ALLUSERS=1 might help. Example:

[Actions]
DefVar $MsiLogFile$
Set $MsiLogFile$ = %opsiLogDir% + "\myproduct.log"
winbatch_install_myproduct

[winbatch_install_myproduct]
msiexec /qb-! /l* $MsiLogFile$ /i "%ScriptPath%\files\myproduct.msi" ALLUSERS=1

Another possibility is that the installation starts a second process and stops before the second process is finished. So from the point of view of the opsi-winst script, the task is finished while in fact the second process is still working (installing / uninstalling).
In this case, you may use the modifier /WaitSeconds <seconds> , or /WaitForProcessEnding "program.exe" /TimeOutSeconds "<seconds>", in the WinBatch section so that the script waits for the end of the second process.

Another more complex way to solve the problem is to create a temporary administrative user account and use this account for the program installation. For a detailed description on how to do this, please refer to the opsi-winst manual chapter 8.3 Script for installation in the context of a local administrator and use the template opsi-template-with-admin.

With Windows 2000, Microsoft launched its own installation concept based on the Microsoft Installer Service "MSI". Since then, many setup programs have become MSI compliant.

To be MSI compliant means to provide a package with installation instructions for the MSI. Usually this is a file named product.msi.

In practice, the setup.exe of a product contains a product.msi file and an additional control program for the installation. The control program unpacks the product.msi and pops up a window that asks if it is allowed to start the installation. If installation has been approved, then the control program checks whether or not MSI is installed, and if so passes product.msi to MSI. If no MSI is found, then the control program tries to install MSI.

If you were to interrupt the installation at that point, you will often find the unpacked MSI-package in a temporary directory.

For example, this package can be used for an unattended installation with the statement:

msiexec /i "%ScriptPath%\Product.msi" /qb-! ALLUSERS=1 REBOOT=ReallySuppress

After a successful silent installation, some customizing might be useful. The opsi-winst is a powerful tool to do that job. First, find out what patches have to be applied. For example, that could mean analyzing which registry settings are affected by the GUI customizing tools.

You can use the tools shown in the section called “Analyze and Repackage”.

Some other often used tools are:

Another fast way of integration is to provide an automated answer file for the setup process. The answer file contains pre-defined answers. To be more precise, the answer file is used by a control tool, which waits for the setup to come up with the interactive windows. The control tool then passes input to these windows as defined in the answer file. As a control tool we recommend AutoIt. The AutoIt program and the documentation can be found at: http://www.hiddensoft.com/autoit3.

AutoIt provides a lot of commands to control the setup process. Also, several error states can be handled (if known in advance) with the [ADLIB] section in the script.

There is, however, a fundamental challenge in using AutoIt:
The AutoIt script must provide input for every window that might pop up during installation. So if any unexpected window pops up, which isn’t handled in the [ADLIB] section, AutoIt provides no input for this window and the installation stops at that point while waiting for input. This input could be done interactively by a user, and then the script can take over again and handle the next windows.

Another situation that may cause failure of an AutoIt installation:
The user can interfere with the installation if the mouse and keyboard are not disabled. Therefore we regard unattended or silent setup as a more stable solution.

A combination of both might do a good job:
The silent-setup does the main installation and the AutoIt script handles special conditions that might occur.

If you use the opsi option of running the installation on another desktop than the current desktop, or if the current desktop is locked, then you will find that some autoit functions do not work properly under these conditions.

Therefore you should avoid using the following autoit commands in opsi-winst scripts:

Because these commands are so widely used, we provide substitutes: winwait()
should be replaced by the function
opsiwinwait($title, $text, $maxseconds, $logname)
which is defined as:

Func opsiwinwait($title, $text, $maxseconds, $logname)
        Local $exists = 0
        Local $seconds = 0
        Local $mylog
        $mylog = FileOpen($logname, 1)
        While ($seconds <= $maxseconds) and ($exists = 0)
                $exists = WinExists($title , $text)
                FileWriteLine($mylog,"win: "  & $title & " ; " & $text & " exists result (1=exists): " & $exists )
                $seconds = $seconds + 1
                sleep(1000)
        WEnd
        FileClose($mylog)
EndFunc

The parameters are:

Send()
should be replaced by the function
opsiControlClick($title, $text, $id, $maxseconds, $logname)
respectively by
opsiControlSetText($title, $text, $id,$sendtext, $maxseconds, $logname)
which are defined as:

Func opsiControlClick($title, $text, $id, $maxseconds, $logname)
        Local $result = 0
        Local $seconds = 0
        Local $mylog
        $mylog = FileOpen($logname, 1)
        While ($seconds <= $maxseconds) and ($result = 0)
                $result = ControlClick($title , $text,$id)
                FileWriteLine($mylog,"answer for " & $title & " ; " & $text & " id: " & $id & " sended: result (1=success) : " & $result)
                $seconds = $seconds + 1
                sleep(500)
        WEnd
        FileClose($mylog)
EndFunc

Func opsiControlSetText($title, $text, $id,$sendtext, $maxseconds, $logname)
        Local $result = 0
        Local $seconds = 0
        Local $mylog
        $mylog = FileOpen($logname, 1)
        While ($seconds <= $maxseconds) and ($result = 0)
                $result = ControlSetText ($title , $text,$id, $sendtext)
                FileWriteLine($mylog,"answer for " & $title & " ; " & $text & " id: " & $id & " set: " & $sendtext & " sended: result (1=success) : " & $result)
                $seconds = $seconds + 1
                sleep(500)
        WEnd
        FileClose($mylog)
EndFunc

The parameters are:

Therefore, you should use the program Au3info.exe to get the ControlId needed by these commands. Please use the numerical ControlId, because the other variants do not seem to work properly:

Below is an example from a script.
In this script we produce a log file from the autoit activities, which may be integrated in the opsi-winst log file with the following commands:

includelog %opsiLogDir% + "\au3.log" "500"

Example:

[ExecWith_autoit_confirm]
Func opsiwinwait($title, $text, $maxseconds, $logname)
        Local $exists = 0
        Local $seconds = 0
        Local $mylog
        $mylog = FileOpen($logname, 1)
        While ($seconds <= $maxseconds) and ($exists = 0)
                $exists = WinExists($title , $text)
                FileWriteLine($mylog,"win: "  & $title & " ; " & $text & " exists result (1=exists): " & $exists )
                $seconds = $seconds + 1
                sleep(1000)
        WEnd
        FileClose($mylog)
EndFunc

Func opsiControlClick($title, $text, $id, $maxseconds, $logname)
        Local $result = 0
        Local $seconds = 0
        Local $mylog
        $mylog = FileOpen($logname, 1)
        While ($seconds <= $maxseconds) and ($result = 0)
                $result = ControlClick($title packet
        FileClose($mylog)
EndFunc

Func opsiControlSetText($title, $text, $id,$sendtext, $maxseconds, $logname)
        Local $result = 0
        Local $seconds = 0
        Local $mylog
        $mylog = FileOpen($logname, 1)
        While ($seconds <= $maxseconds) and ($result = 0)
                $result = ControlSetText ($title , $text,$id, $sendtext)
                FileWriteLine($mylog,"answer for " & $title & " ; " & $text & " id: " & $id & " set: " & $sendtext & " sended: result (1=success) : " & $result)
                $seconds = $seconds + 1
                sleep(500)
        WEnd
        FileClose($mylog)
EndFunc

; exact title match
Opt("WinTitleMatchMode", 3)
$mylog = FileOpen("%opsiLogDir%\au3.log", 2)
FileWriteLine($mylog,"auto-it started - waiting for the window")
FileClose($mylog)

opsiwinwait("InstallShield Wizard" , "Wollen Sie wirklich", 200, "%opsiLogDir%\au3.log")
        opsiControlClick("InstallShield Wizard" , "Wollen Sie wirklich", 6, 5, "%opsiLogDir%\au3.log")
opsiwinwait("InstallShield Wizard" , "Deinstallation ist abgeschlossen", 400, "%opsiLogDir%\au3.log")
        opsiControlClick("InstallShield Wizard" , "Deinstallation ist abgeschlossen", 1, 5, "%opsiLogDir%\au3.log")

Sleep(500)
;and good bye
Exit

see also:
http://www.autoitscript.com/wiki/FAQ#Why_doesn.27t_my_script_work_on_a_locked_workstation.3F
http://www.autoitscript.com/autoit3/docs/
http://www.autoitscript.com/autoit3/docs/intro/controls.htm
http://www.autoitscript.com/autoit3/docs/functions.htm

When a software developer builds a setup for deployment, the developer usually knows about the required components of the software that have to be installed. But if somebody has a black box as a setup, then they need first to analyze what the setup does. This can be done by monitoring the setup activities with the appropriate tools (e.g. monitoring files and registry access) or by comparing the system states before and after installation.

To analyze the before or after states, there are several tools. For Example:

To uninstall a software product from a computer, you need an uninstall script to perform the deletion. The fundamental difficulty in software deletion is deciding what exactly has to be removed. Not all of the files that came with a software package can be deleted afterwards. Sometimes a package comes with standard modules that are also referred to by other programs. Often only the software manufacturer himself knows what parts have to be removed. The manufacturer’s setup might offer an unattended uninstall option which can be embedded in the opsi uninstall script. Otherwise opsi-winst provides several commands for software deletion:

Using an uninstall routine. If the product manufacturer provides an option for software deletion, you must checked whether or not it can be run unattended (or in silent mode). If it requires some user interaction, an AutoIt script combined with the uninstall routine might do the job. The uninstall statement can be embedded in a [WinBatch] section of the opsi-winst script:

[WinBatch_start_ThunderbirdUninstall]
"%SystemRoot%\UninstallThunderbird.exe" /ma

When using an uninstall program, always run a test to see if all of the files have been deleted and the computer is still in a stable state.

Products that are installed by MSI normally come with an uninstall option, which is usually the program msiexec.exe combined with the parameter /x. The parameter /qb-! is for the unattended mode (or without user interaction). So here is an example of an unattended uninstall command:

msiexec.exe /x some.msi /qb-! REBOOT=ReallySuppress

Instead of the package name, you could also use the GUID (Global Unique ID) with msiexec.exe. This GUID identifies the product in the system, which can be found in the registry directory HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall

A request using the GUID looks like this:

msiexec.exe /x {003C5074-EB37-4A75-AC4B-F5394E08B4DD} /qb-!

If none of these methods are available or sufficient, the uninstall can be done using a opsi-winst script as described below:

Useful opsi-winst commands for uninstall. If a product has been installed by opsi-winst functions, or if there is no uninstall routine for the product, the complete uninstall has to be done by a opsi-winst script. opsi-winst comes with some powerful uninstall functions. This chapter provides a brief overview of the uninstall functions, and more detailed information can be found in the opsi-winst handbook.

Basic uninstall means deleting one or more files from the file system. This command can be executed from a opsi-winst files section:

delete -f <file name>

or to delete a directory including sub directories:

delete -sf <dir name>\

The parameter f means force or to delete the files even if they are marked as read only and the parameter s means including the subdirectories. A file or directory can be deleted from all user profiles using the option /AllNTUserProfiles (see opsi-winst manual for details).

Directories containing files with the attribute hidden or system can be deleted by using a DosInAnIcon-section:

[DosInAnIcon_deleteDir]
rmdir /S /Q "<List>"

To stop a running process before deletion use the ‘killtask` command with the process’ name (look at the task manager for process name):

KillTask "thunderbird.exe"

If the product or part of it, runs as a service, you will have to stop the service before deleting the files. One way to do so, is to set the service state to inactive in the registry and restart the computer. Or to stop the service by using the command net stop, which doesn’t need a reboot:

net stop <servicename>

Deleting DLL files also requires special attention, since DLLs could also be used by other products. There is no general way of handling this.

To delete registry entries with opsi-winst you can use the command DeleteVar. This command deletes entries from the currently open key:

DeleteVar <VarName>

To delete a registry key with all sub keys and registry variables, you can use the opsi-winst command DeleteKey:

DeleteKey [HKLM\Software\Macromedia]

The opsi installer opsi-winst is a 32 bit program. There are no known problems when installing 32 bit software on a 64 bit system using opsi-winst. For the installation of 64 bit software, some constants (like %ProgramFilesDir%) give wrong values.

New versions of opsi-winst have special commands to handle these problems. So read the opsi-script manual for these issues.

To start creating a new product, change directories to the product directory, and start the creation of the new product by entering the command opsi-newprod. The next question will ask you about the type of product you want to create. Choose the type localboot for products which should be installable by opsi-client-agent/opsi-winst. The product type netboot is used for products which are activated as a bootimage (like OS installation)

Figure 7.8. Choose the product type: localboot

Confirm your choice with tab (or F12). Next, fill in the basic product parameters. At the top of the window there is an explanation for the current input field.

Figure 7.9. Input of the product information

After the product information is completed, fill in which action scripts should be provided:

Figure 7.10. Input of the opsi-winst script names for different actions

After editing the product information you should mention the script you want to use for different activities.

Usually the Setup script is named setup.ins

Usually the Uninstall script is named uninstall.ins

An Update-Script will be used for minor changes on existing big installations. If this product is switched to the required action setup, then the update script will be automatically executed after the setup script.

An Always-Script will be executed at the beginning of every activity of opsi-client-agent (e.g. on every boot).

A Once-Script has the resulting state not_installed. It is a very special kind of script, and you should only use it if you really know what you are doing.

A Custom-Script doesn’t change the resulting state. It is a very special kind of script, and you should only use it if you really know what you are doing.

A userLoginScript is used to modify the user’s profile after the user logs into the system. It only works with the opsi extension User Profile Management, which is described at the User Profile Management chapter in the opsi-manual.

The next step is to define one or more product dependencies. If there are no product dependencies, select No.

Figure 7.11. Create product dependency: No/Yes

To create a product dependency, enter the following data (help is available at the top of the window):

Figure 7.12. A(nother) product property to create?

If you answer Yes, you will have to describe the product properties.

The product properties are client specific, and have names (keys) which can hold different values. These values can be evaluated by the opsi-winst script, and result in installing different options at installation time.

First we have to decide if our property is a text value (unicode) or a logical value e.g. true/false (boolean). If you are not sure choose unicode.

Figure 7.13. Choose the data type of the property

Next, a description for the switch needs to be specified. This description will be shown in the opsi-configed as a help text. Next, you can define the set of values for the switch (separated by comma). If this is left blank, then any value is allowed for the switch.

Figure 7.14. Description of the product properties

Next, you can decide if the product property has a default value (switch).

Figure 7.15. Default value of the product property

If you choose boolean as the data type, then the description will contain only the Property name and Property description.

Figure 7.16. Description of a boolean property

After defining a product property, you will be asked if you want to create another product property. If you choose Yes, then the procedure of defining a property will be repeated. If you choose No, then you will be asked for name and email of the product maintainer. This data will be written on the changelog.

Figure 7.17. Input of the maintainer data

Finally, the basic definitions for the new product are done.

Using the list command (ls), you can see the directory structure as described above. Change to the OPSI folder and list the content. The control file now contains the data you just defined, and you can load the file into an editor to view or change the entries.

Example of a control file: 

[Package]
version: 1
depends:
incremental: False

[Product]
type: localboot
id: mytest
name: My Test
description: A test product
advice:
version: 3.14
priority: 10
licenseRequired: False
productClasses:
setupScript: setup.ins
uninstallScript:
updateScript:
alwaysScript:
onceScript:
customScript:
userLoginScript:

[ProductDependency]
action: setup
requiredProduct: javavm
requiredStatus: installed

[ProductProperty]
type: unicode
name: mytextprop
multivalue: False
editable: True
description: hint
values: ["off", "on"]
default: ["off"]

[ProductProperty]
type: bool
name: myboolprop
description: yes or no
default: False

[Changelog]
mytest (3.14-1) testing; urgency=low

  * Initial package

 -- jane doe <j.doe@opsi.org>  Mi, 14 Jul 2010 12:47:53 +0000

For the next step, you will have to copy the product opsi-winst script, and any necessary data files (i.e. program-installation-executable.exe), into the CLIENT_DATA folder.

So if the script you have written is currently at c:\test, just mount the share \\<opsiserver\opsi_workbench e.g. to w:, and then copy the complete content of c:\test to the directory CLIENT_DATA.

Now you may build the package. Change to the root directory of the product (maybe /home/opsiproducts/myproduct/, and enter opsi-makeproductfile. The product package will be built. The package (<package name>) will be a file that has a format similar to /home/opsiproducts/<myproduct>/<myproduct_ProductVersion-PackageVersion>.opsi.

Finally, install the package. The resulting package can be installed on the opsi-server with the command
opsi-package-manager -i <package name>.

opsi-makeproductfile can be started with different options:

#  opsi-makeproductfile --help

Usage: opsi-makeproductfile [-h] [-v|-q] [-F format] [-l log-level] [-i|-c custom name] [-I required version] [-t temp dir] [source directory]
Provides an opsi package from a package source directory.
If no source directory is supplied, the current directory will be used.
Options:
   -v          verbose
   -q          quiet
   -l          log-level 0..9
   -n          do not compress
   -F          archive format [tar|cpio], default: cpio
   -h          follow symlinks
   -I          incremental package
   -i          custom name (add custom files)
   -c          custom name (custom only)
   -C          compatibility mode (opsi 3)
   -t          temp dir

It is recommended to create the packages with a corresponding md5 checksum file. This file is used amongst others by opsi-product-updater to check after a file transfer to ensure package integrity. Such a file can be created with -m.

When transferring packages to opsi-depot-server zsync can be used to only transfer differences between different packages. To be able to use this method a special .zsync file is required. Such a file can be created with -z.

If you are running into the problem that the creation of a package fails because of insufficient free space in /tmp you can use the option -t to specify a different temporary folder.

If there is already a package file with the same version information, opsi-makeproductfile will ask for overwrite confirmation:

Package file '/home/opsiproducts/mytest/mytest_3.14-1.opsi' already exists.
Press <O> to overwrite, <C> to abort or <N> to specify a new version:

Choosing o will overwrite, c abort, and n will ask for new version information.

The created opsi-package can be installed at the opsi-server with the command:
opsi-package-manager -i <packagename>

More information about the opsi-package-manager can be found in the opsi-manual.