Skip to main content
Matrix42 Self-Service Help Center

Step by step guide

This chapter contains a "step-by-step" guide for using the Matrix42 OS Deployment - based on WinPE.

In general, this new variant of deployment is based on a WinPE based PXE boot image that starts the Matrix42 Universal Agent Framework at boot time. The Matrix42 Universal Agent Framework then ensures that the booting computer connects to the assigned Empirum Server and executes the assigned Matrix42 PreOS packages. For the connection to the Empirum Server, the information in the selected agent template is used.

The Windows installation package is one of these Matrix42 PreOS packages and contains the functionality to perform a Windows installation. It comes with additional variable definitions that control the installation behavior. WindowsInstallation version 4 and later depends on the package DiskPartitioning, which must be executed before WindowsInstallation. In addition, the packages PxeOffAndReboot, DomainJoin and EmpirumAgentSetup must be executed after the Windows installation package.

The Matrix42 PreOS packages can be imported via the Depot configuration of the Matrix42 Management Console and are then available as a special software package in Empirum. This allows you to assign the Matrix42 PreOS packages as usual to a computer via the administration, which then executes them during a WinPE boot process.

The following chapters now describe the steps to perform the WinPE based deployment:

  • Importing Matrix42 PreOS Packages
    • Especially the packages DiskPartitioning, (DriverIntegration), WindowsInstallation, PxeOffAndReboot, DomainJoin and EmpirumAgentSetup
  • Creating a WinPE based boot configuration
  • Configuration of the required variables; assignment of the created configurations and activation
  • Special features when using Empirum Depot Servers

Importing Matrix42 PreOS Packages

A Matrix42 PreOS package can be imported like a software package via the Matrix42 Management Console and is therefore available in Empirum.

The following describes how Matrix42 PreOS packages are imported and how they are approved afterwards.

Importing the necessary PreOS Packages 

The import of a Matrix42 PreOS package is done via the Matrix42 Management Console. Follow the instructions to import the Matrix42 PreOS packages.

  1. Start the Matrix42 Management Console (EMC), change to Configuration > Software Management > Depot tab in the navigation bar.
  2. In the tree view, select the entry Register and start the Import Wizard via the context menu Import/Export > Import Package.

clipboard_ee9098f7c0363a35a13343931af672610.png

The dialog for importing software packages opens.

clipboard_e067fbebc56c93866587fedba55073f4c.png

  1. Click on Next.

clipboard_edfe910d8ae2595685fb34efeb305ba51.png

  1. Now enter the directory in which the Matrix42 PreOS packages are located.

\\%EmpirumServer%\Configurator$\PackageStore\PreOsPackages

Do not select the option Delete packages from directory after successful import so that the Matrix42 PreOS packages remain in the source directory.

  1. Click Next to continue.

clipboard_e0b94988a965ecf58b6c1a5b53985ad15.png

  1. The Import Wizard displays all detected OS software packages. Select the latest packages for DiskPartitioning, DriverIntegration, WindowsInstallation, PxeOffAndReboot, LanguagePacksInstallation, DomainJoin and EmpirumAgentSetup from the list.
  2. Click Next.

If the Matrix42 PreOS package already exists, the Import Wizard asks if the package should be imported anyway. If the import is performed anyway, an error will occur.

clipboard_ec60197033ff477b7ac3ff491143d37cd.png

  1. The Import Wizard displays a summary of which packages will be imported afterwards. Click on Finish to complete the import.
  2. After the successful import, the Import Wizard closes and the packages DiskPartitioning, DomainJoin, DriverIntegration, EmpirumAgentSetup, LanguagePacksInstallation, PxeOffAndReboot and WindowsInstallation are displayed in the register Matrix42 PreOS Packages.

clipboard_e3dbe51aa9a263e0f6b07018285e6c378.png

 

Matrix42 PreOS packages are always imported into the register specified in the configuration file (EmpirumPackageData.xml) of the package. This behavior differs from the behavior when importing software packages. If you start the import there using a special register (for example, software), the software packages to be imported are also stored in this register.

If there are still no Matrix42 PreOS packages available, the order of the packages is set according to the information in the configuration file (EmpirumPackageData.xml).

From Empirum v20.0 on: If a version of a Matrix42 PreOS Package is already available, its position in the register is first determined during import and then transferred to the newly imported package. The new version of the package will then appear directly below the already existing version.

Approval of the Matrix42 PreOS packages (up to Version 1.8.0)

Until WinPE Support 1.8.0 the DiskPartitioning, DriverIntegration, WindowsInstallation, PxeOffAndReboot, DomainJoin and EmpirumAgentSetup packages must still be released for installation via the depot configuration after the import of the packages. Proceed as follows to do this:

  1. Start the Matrix42 Management Console (EMC), change to Configuration > Software Management > Depot tab in the navigation bar.
  2. Open the Matrix42 PreOS Packages tab in the tree structure and select a package.

If a newly imported package is not yet displayed, the depot configuration must be updated. To do this, select View > Update from the menu bar. The depot configuration will then be read from the database again.

  1. Open the properties of the new package via the context menu.

clipboard_edf55c0893f100a2320072467bb075e3e.png

  1. The property Ready for installation must be checked under the View tab.
  2. Approve the change with OK.
  3. The change must then be saved in the depot configuration via the File > Save menu

 

In general, it is possible to execute several Matrix42 PreOS packages when booting the WinPE based PXE image. As with other software packages, the execution order of these packages can be globally controlled by the order of the packages in the depot.

Since WinPE Support 1.8.1 the packages are Ready to Install by default.

The following sequence is a prerequisite for Windows installation:

clipboard_e6645d5b31ba8648d7c0193799998fdcb.png

This is explained in detail in chapter 2.3.1 Package Order in the Depot Configuration on page 20.

Creating a WinPE based boot configuration

The following chapter describes how to use the new WinPE based Empirum Preinstallation Environment configuration.

Starting with Empirum v20.0.1 in combination with the Matrix42 PreOS packages WindowsInstallation 5.3 and DriverIntegration 2.14 or higher, a manual IP configuration can also be used for the operating system installation in the WinPE / Windows phase.

For this purpose, the IP configuration in the register IP address and DNS must be made in the client properties (EMC > Administration > Properties Computer > IP address > Static).

clipboard_e574ccd96e1f9c354970afbe365fe89ba.png

The values entered here are then entered into the <computer name>.ini in the [MS_TCPIP] section.

clipboard_efa8853a57ffd5f13605f97a8a1ea8356.png

Creating a Boot Configuration

In the boot configuration a WinPE based PXE boot image based on the Windows ADK installed on the Empirum Master Server can be created. The following steps are necessary for this:

  1. Change to Configuration in the navigation bar and select Boot Configurations.

To create or change a boot configuration the currently logged in user requires the role EMP_I_DISK_CONFIG which can be assigned in Matrix42 DBUtil in the User Management. If the logged in user does not have the role, the content of the boot configuration is grayed out and disabled.

  1. Click on the New button to create a new configuration.

clipboard_e19d0017b2951210eaf596548ef6fc21f.png

Symbol definition:

  •  One or more critical entries are missing or incorrect
  •  Specifications or data have been changed but not yet saved.
  •  The Boot Configuration job is in the queue.
  •  The Boot Configuration is being created in the background.
  •  The Boot Configuration was successfully created
  •  An error occurred during the Boot Configuration creation.
  •  The Boot Configuration was changed in the background and can't be saved any more. A refresh is needed to load the changes.
  •  The boot configuration has been deleted in the background and can't be saved any more. A refresh is needed to remove the configuration from the list.
  1. Customize the Name and Description fields according to your requirements.

 

Only alphanumeric characters (a-z, A-Z and 0-9) are allowed for the name.

Names must be unique.

The use of reserved names is prohibited. This also includes names that are already used in the boot disk configuration (EPE 3).
The symbol   indicates that the input is not permitted.

  1. Select WinPE as configuration type to create a WinPE based PXE boot image - if not already selected.

clipboard_e84650c64a24ad10256c32c4557c446a9.png

If you select WinPE as the configuration type, the Empirum PE Source and Dynamic Server Detection selections are hidden and not available in the configuration. These properties are only available in the EPE4 configuration and are not necessary in the case of a WinPE preinstallation environment. By default, WinPE is selected for new configurations.

  1. Select the desired agent template from the drop-down field Agent Template.

 

The specifications in the selected agent template determine how and with which server the system attempts to connect during OS deployment.

If no entry is displayed in the Agent Template selection, first create an Empirum Agent Template via Configuration > Software Management > Empirum Agent. In addition to the username, password and server name, the settings for the DHCP options are also transferred to the PXE boot image if it has been configured in the Agent Template.

Afterwards the selection can be updated via the Refresh   button. If several Empirum Agent templates have been created, the first one is always displayed directly, sorted alphabetically.

The Links overview is updated in real time. However, changes   are only permanently accepted after confirmation with Save.

  1. To select which platforms should be supported, you must either check EFI x86 or EFI x64 or select one of the platforms from the BIOS drop-down box. Multiple platforms can be selected at the same time. For BIOS, however, only one of the platforms can be selected at a time - either 32 bit or 64 bit. To create a configuration, at least one of the platforms must be selected. By default, EFI x64 (64 bit) is selected.
  2. You can make the settings for TFTP block size, self-provisioning, and driver folders using Advanced Properties. Click the button  clipboard_e369d8e44a0b8e8663761a1993d2a5dea.png to show the fields.

clipboard_ec7c4593d5412d44ec17a89d743164208.png

  1. The TFTP block size setting can be used to adjust the WinPE Boot image transmission to make it either more stable or faster.

A higher TFTP block size value usually leads to a faster transmission of the boot image. However, a larger block size can also lead to transmission aborts. An optimal value depends on the existing network infrastructure and its usage. In a new boot configuration, the default value of the TFTP block size is 4 KB.

  1. Enable Self Provisioning is described in detail in Chapter 7.
  2. If you want to use additional drivers in WinPE, proceed as follows:

 

A detailed step-by-step guide for handling drivers is described in the document "Matrix42 Driver Integration in WinPE - HowTo - EN.pdf".

When creating the WinPE PXE image, the contents of the additional driver directories are copied into the image and are then available at runtime. Both 32-bit and 64-bit drivers can be added.

  1. Click on the button   below the list of additional driver directories to add another directory to the list.

clipboard_e34ce9b3ac7833328a17665aab6ac59f2.png

The Browse Folder window will open, allowing you to select a directory.

  • Confirm the selection with OK.
  • The selected directory will be added to the list of additional driver folders.

clipboard_e617aaa180c7fe6c35b3cc8c601c43314.png

  • If you want to remove a driver directory, click on the button to the right of the driver directory entry.
  1. If all settings have been made to your satisfaction, confirm with Save and then answer the security question with Yes.

As with the EPE 4 configuration, not only the configuration is now saved in the database, but also a PXE boot image is created directly.

After successful creation of the PXE boot image, it is saved with the specified name in Management > Administration under PXE boot image.

Generation process of the PXE Image

After saving the Empirum Preinstallation Environment configuration, the automatic creation of the PXE image is taken over by the backend task queue extension. After wards the PXE boot image can be assigned as usual in the administration.

Back-end Task Queue

The current jobs in the backend task queue can be viewed via the following dialog in the Matrix42 Management Console (EMC):

  • Matrix42 Management Console > Management > Administration > file menu > Info > Back-end tasks.

The queue entries named PE (= Preinstallation Environment) are the jobs that are of interest for creating the PXE image.

The list shows which jobs are currently being processed by the queue.

clipboard_e30d0907dd75474841ad7804d59846085.png

The BTQH service must run under a user with administrative privileges.

Back-end Task Log

In the Back-end Task log tab, you can view the status of jobs that have already been processed.

The success of the task can be seen in the Result column.

If the task fails, detailed information about the error is stored in the Note column.

clipboard_ec1334aff56a0e7e051d10b3627be7378.png

 

Note: Detailed information can also be obtained from the log file of the backend task queue - this is below:

C:\ProgramData\Matrix42\Logs\BackendTaskQueueHost64\BackendTaskQueueHost64.log

Assignment in Administration

To enable a computer to execute the OS deployment via WinPE, following settings must be made in the administration.

  • The created PXE boot image ("WinPEBoot") must be assigned to the computer.
  • The desired edition of the operating system import must be assigned to the computer.
  • The desired language package imports can be assigned to the computer.
  • The Matrix42 PreOS packages DiskPartitioning, WindowsInstallation, PxeOffAndReboot, DomainJoin and EmpirumAgentSetup must be assigned to the computer to be installed. When using language pack imports, the LanguagePacksInstallation package must also be assigned. If drivers must be integrated into operating system, the DriverIntegration package has to be assigned additionally.
  • The computer variables required by DiskPartitioning, WindowsInstallation, PxeOffAndReboot, DomainJoin and EmpirumAgentSetup must be set for deployment.
  • The computer must be activated and can then perform the deployment.

Generally, it is also possible to assign several Matrix42 PreOS packages, which are then executed one after the other when booting the WinPE based PXE image. As with other software packages, the order in which these packages are executed can be globally controlled by the order of the packages in the depot.

The individual steps are explained in more detail below:

  1. Assign the packages DiskPartitioning, WindowsInstallation, PxeOffAndReboot, DomainJoin, EmpirumAgentSetup and the WinPE based PXE boot image (in this example WinPE) to the computer.

clipboard_ea8ad57d9614bb6dc2fd433b8cfff31b2.png

Package Order in the Depot Configuration

If this variant of the Windows Deployment is to be used, it must be ensured that the Matrix42 PreOS packages are also executed in the correct order. For this the order in the depot configuration can be adapted.

clipboard_ea0e5331a022ed939afba766bcd38f197.png

The order must therefore look as follows:

  • DiskPartitioning
  • DriverIntegration (see chapter on driver integration)
  • WindowsInstallation
  • PxeOffAndReboot
  • LanguagePacksInstallation
  • DomainJoin
  • EmpirumAgentSetup

The changes to the sequence in the depot configuration must be saved.

Global Variables

TimeZone

The TimeZone variable under OS_RegionalSettings is used to set the time zone both under WinPE and in the operating system to be installed (e.g. (UTC+1:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna).

Windows installation and SimpleOsDeployment packages use this variable to set the time zone under Windows.

The PE Agent uses this variable to set the time zone under WinPE at runtime.

DiskPartitioning Package

The first package in the series is the DiskPartitioning package, which performs the partitioning of the hard disk. The configuration of the partitioning is controlled by the package variables.

Note: Executing the DiskPartitioning package switches the package status of all previously installed packages to YELLOW, even if they were GREEN shortly before. Since this will completely erase the hard disk, the previously determined status can no longer be correct.

clipboard_ec1e5cc35ae00f20063f1a708b5a1f027.png

There are two variants available for partitioning (absolute or percentage partitioning), which are controlled by the variable DiskPartitioning.InterpretSizeInputAsPercentage. If the value is set to 1, the entries in DiskPartitioning.SizeDataPartition, DiskPartitioning.SizeSystemPartition are interpreted as percentages.

SizeSystemPartition

The SizeSystemPartition value specifies the partition size of the system partition in gigabytes for an absolute partitioning variant.

Example:

DiskPartitioning.SizeSystemPartition = 150

Here the DiskPartitioning package will try to create a 150 GB system partition.

SizeDataPartition

The SizeDataPartition value specifies the partition size of the data partition in gigabytes for an absolute partitioning variant.

Example:

DiskPartitioning.SizeDataPartition = 400

Here the DiskPartitioning package will try to create a second 400 GB data partition behind the system partition.

InterpretSizeInputAsPercentage (Percentage based Partitioning)

If relative specifications are to be used for partitioning, the following variable value must be set.

DiskPartitioning.InterpretSizeInputAsPercentage = 1

In this case, the values in SizeSystemPartition and SizeDataPartition are interpreted as percentage values.

Example:

DiskPartitioning.SizeSystemPartition = 100

DiskPartitioning.SizeDataPartition = 0

Here, the DiskPartitioning package creates only one system partition that occupies the entire free space of the hard disk.

DiskPartitioning.SizeSystemPartition = 50

DiskPartitioning.SizeDataPartition = 50

Here, the DiskPartitioning package creates a system partition and data partition, each having same size on the hard disk.

If fixed gigabyte values are to be used for partitioning, the following variable value must be set.

DiskPartitioning.InterpretSizeInputAsPercentage = 0

The DiskPartitioning package will abort with an error if the disk is too small to create the specified partition sizes.

MinimumSystemPartitionSizeInGB

If a relative/percentage-based partitioning method (InterpretSizeInputAsPercentage=1) has been selected, the MinimumSystemPartitionSizeInGB variable can be used to specify a minimum system partition size that will not be undershot during partitioning.

SizeWinREPartitionInMB

If a Windows Recovery partition is to be created during partition partitioning, the size can be defined in MB using the SizeWinREPartitionInMB variable. If this variable is empty or 0, a Windows Recovery partition will not be created.

PreferFastDisk (Preferred installation target drive)

Often there are several hard disk drives of different types in the client. Usually one would prefer to install the operating system on the fastest hard disk drive available. The DiskPartitioning package offers the possibility to install the preferred installation target drive using the variable 

DiskPartitioning.PreferFastDisk = 1

based on the storage technology of the drive.

If this variable is set to 1, the DiskPartitioning package searches for the first (according to BIOS) NVME disk and will prepare it for the operating system deployment.

If there are several hard disks and already a Windows installation on the device, and another disk has been selected as the system hard disk. Using the 'PreferFastDisk' for example - then it can lead to problems. You can either clean all disks manually via DISKPART or via the hidden variable 'ClearAllDisks' when running the DiskPartitioning package. You must add the variable "ClearAllDisks" as number to variable DiskPartitioning under "Tools > Variable Definitions..." in EMC and set it to 1.

SizeEfiPartitionInMB

In EFI-based client scenarios, the SizeEfiPartitionInMB variable defines the size of the EFI partition to be created in MB.

By default, the EFI partition is created with the size of 100 MB. For EFI-based installations the size may be defined larger, but not smaller.

In older MBR-based client scenarios, this variable is ignored.

SizeMsrPartitionInMB

In EFI-based client scenarios, the SizeMsrPartitionInMB variable defines the size of the "Microsoft Reserved Partition" to be created in MB.

By default, the MSR partition is created with the size of 128 MB. For EFI-based installations the size may be defined larger, but not smaller.

In older MBR-based client scenarios, this variable is ignored.

Driver Integration Package

If drivers were integrated into the WinPE, it is very likely that also drivers for the Windows installation must be integrated.

For more information about this, please read chapter 4 Driver integration for the operating system installation on page 39 first, if further drivers must be integrated.

WindowsInstallation Package

The Windows installation package must be configured as follows.

  1. Set the computer variables required by the Windows installation package, which are structured below the Windows installation variables:
  • LocalUserName (login name for the local account)
  • LocalUserPassword (password for the local account)
  • LocalUserDisplayName (display name for the local account)
  • SetupUILanguage (Defines the language to be used in Windows Setup and Windows Deployment Services. e.g. en-US. The Language Pack installations take place after the operating system has been installed, so only languages can be selected which are available in the operating system import itself.)
  • InputLocale (Specifies the input language and input method for input devices, e.g. the keyboard layout. e.g. de-DE)
  • SystemLocale (Specifies the default language to be used for non-Unicode programs. e.g. en-US)
  • UILanguage (Specifies the language to install that will be used as the default system language for displaying user interface elements (such as menus, dialog boxes, and help files), such as en-US)
  • UserLocale (Specifies the user-related settings for formatting date, time, currency and numbers in a Windows installation. e.g. de-DE)
  • ProductKey variable specifies the product key to use within the Windows setup phase. The Product Key could be a KMS Client Setup Key (see https://docs.microsoft.com/en-us/win.../kmsclientkeys). For MAK-Activation-Scenarios the configuration (ProductKey=KMS Setup Key) / (ActivationKey=MAK Activation Key see below) is necessary. In VL/KMS-Environments currently there is no need to configure the variables ProductKey or ActivationKey; your KMS server manages all configurations.
  • UnattendXmlFile variable can be used to point to another unattend.xml template, which will then be used when installing Windows. The path must be specified relative to the EmpInst$ share.
    Example:
    WindowsInstallation.UnattendXmlFile = Sys\unattend.xml
    Corresponds to:
    \\%empirumserver%\EmpInst$\Sys\unattend.xml
    If the variable UnattendXmlFile is not set, the unattend.xml template from the package directory is used.
  • ActivationNow variable (0/1) requests an immediate Windows activation within the first logon phase of the OS-Installer. While using an ActivationKey the variable ActivationNow must be set to "1" too. The result of the Windows activation process may be inspected via the client log file     C:\ProgramData\Matrix42\Logs\UAF\WinActivation.log.
  • ActivationKey variable specifies the key, that is used for windows activation. The definition of an ActivationKey is not necessary for VL/KMS-Environments but is necessary for MAK based activation scenarios.
  • UACLevel variable defines the setting for the Windows User Account Control. The variable offers, in a dropdown box, the UAC settings as represented in windows. The defined UAC Level will be applied to the windows client being set up.
    The value "Don't change UAC settings" will usually result in the default UAC setting. It is included for backward compatibility reasons, allowing customers that use own solutions to continue using that without forcing a change in the deployment process.
  • BuiltinAdministratorActive (activate or deactivate the built-in Administrator account)
  • BuiltinAdministratorPassword (password for the built-in Administrator account)
    Per default - if no password is configured - the password Matrix42! is set.
  • ForceDotNetInstallation variable (Yes/No). Forces the installation of .Net 4.7 if the value of the variable is set to Yes - e.g. necessary for the installation of Windows 10 2016 LTSB.

The variables for the domain join are no longer available as of the WindowsInstallation package version 4.0, because the package no longer prepares the client for the domain join. This functionality has moved to the separate DomainJoin package. The corresponding variables must be set in this new package, as described in more detail in chapter 2.3.9 DomainJoin Package on page 30.

  1. Confirm the variable adjustment again with OK.

Here are the values used for the example:

clipboard_ed08e26ecfba71860ea96fab3d8ce7ba9.png

  1. Select the operating system source to be used by switching to the operating system imports in the right tree. There, all imported Windows 7, Windows 10, Windows Server 2016, and Windows Server 2019 operating systems are displayed in the folder structure as they are used for the operating system import. Each time you import an operating system, the available editions of the operating system will be displayed. Assign the desired edition to the computer in the middle tree.

clipboard_e84b434ffb89713fa5be8d388a562b45f.png

 

You can still configure the operating system source to be used using the OS_PACKAGE_SOURCES operating system variable. Note that no operating system import may be assigned to the computer via the administration, otherwise this assignment is preferred. When using the OS_PACKAGE_SOURCES operating system variable, you must also note that the edition of the operating system to be used cannot be specified.

For older Empirum versions (before 18.0.2), the operating system variable OS_PACKAGE_SOURCES must be set.

With Empirum v19.0, Windows 7, Windows Server 2016, and Windows Server 2019 operating system imports can be assigned in addition to Windows 10.

  1. Set the TimeZone variable under OS_RegionalSettings to set the time zone used in WinPE and in the operating system to be installed. (e.g. (UTC+1:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna).

clipboard_e67f9088a57c4708fd67602dca372f4fc.png

LocalExperiancePacksInstallation- Package

  1. Assign the LocalExperiancePacksInstallation package to the appropriate configuration. This package installs the assigned language packs after the Windows installation package has installed the Windows operating system.

 

Make sure that the order of the packages is kept in the software depot:

The Matrix42 PreOS package LocalExperiencePacksInstallation 2.0 or higher must be placed after the PxeOffAndReboot package in the Software Depot, because it must be executed in the late Windows phase.

For older versions of the LocalExperiencePacksInstallation packages, the packages must be placed in the Software Depot after the WindowsInstallation and before the PxeOffAndReboot package, because they must be executed in the early WinPE phase.

  1. Select the LXP/APPX language packs you want to use. To do this, switch to the language pack imports in the right tree. All imported Windows 10 language packs are displayed in the folder structure there. Assign the desired language packs to the computer in the middle tree.

Local Experience Packs are supported from Windows 10 Version 1809 upwards. The base installation OS language should be English (EN-US). Different base languages are only supported experimentally. The desktop/UILanguage can be user specific set via the Windows dialogue "Regions and Languages".

PxeOffAndReboot- Package

After the WindowsInstallation-Package the PxeOffAndReboot-Package must be executed. PXE is deactivated for this client and the client is rebooted afterwards. The next time the client is rebooted it will no longer start from network and the unattended operating system installation can be performed on the client.

After the operating system installation, the PE Agent is also started under Windows to execute the last PreOS packages intended to be executed under Windows (Those are especially LanguagePacksInstallation, DomainJoin, EmpirumAgentSetup).

LanguagePacksInstallation- Package

  1. Assign the LanguagePacksInstallation package to the appropriate configuration. This package installs the assigned language packs after the Windows installation package has installed the Windows operating system.

 

Make sure that the order of the packages is kept in the software depot: LanguagePacksInstallation must be arranged after WindowsInstallation and PxeOffAndReboot packages. Note that the actual installation of the language packs will take some time.

  1. Select the language packs you want to use. To do this, switch to the language pack imports in the right tree. All imported Windows 10 language packs are displayed in the folder structure there. Assign the desired language packs to the computer in the middle tree.

clipboard_e6911c650166d2457da76c7f3ac2968ee.png

After the Windows installation and the PxeOffAndReboot packages, the LanguagePacksInstallation package will run under Windows and install the assigned language packages on the client.

Configure Display Language

WindowsInstallation package uses the variable "UILanguage" to configure the display language.

If the operating system image already has the configured language, this language is set during the Windows setup by executing the WindowsInstallation package.

If the required language is added while language packs installation the LanguagePacksInstallation package also sets the display language. For this purpose, the WindowsInstallation package passes the language setting to the LanguagePacksInstallation package.

So, the setting of the display language is defined in the WindowsInstallation package variable "UILanguage".

DomainJoin Package

The DomainJoin package is executed to add the computer to a domain.

With Empirum v20.0.3 and higher in combination with the Matrix42 PreOS package DomainJoin 1.8 or higher, the computer property Domain is considered by the Matrix42 PreOS package DomainJoin.

clipboard_e8b18119924befdcb2b17342b70e7af15.png

If the Domain is not selected, then even if the Matrix42 PreOS package DomainJoin is assigned, no domain join is performed and the computer is added to the specified workgroup.

With older versions, no Matrix42 PreOS package DomainJoin must be assigned, so that the domain join is not performed and the computer is added to the workgroup!

A domain join requires the DomainJoinCredentialsUser (domain\username) and DomainJoinCredentialsPassword variables to be set. The FQDN and ORGANIZATIONAL_UNIT variables, which can be configured from the Computer Properties dialog, are used by this package.

Variables that set the credentials for the domain join

  • DomainJoinCredentialsUser:
    Name with domain of the domain user to be used.
  • DomainJoinCredentialsPassword:
    Password of the user to be used.
  • DomainJoinErrorAction:
    Error handling during the join process.
    • Warning:
      If an error occurs during the logon process to another OU, a warning message is displayed in the log that the client could not be logged on to the specified OU. The installation process will continue if possible.
    • Error:
      If an error occurs during the logon process to another OU, an error message is displayed in the log and the installation process is terminated.
  • DomainJoinAuthority: 
    Defines whether the AD or Empirum controls the join process. Only if Empirum has been selected here, an existing client can be moved to another OU.
  • DomainJoinOptionFlags:
    Defines a custom NETSETUP Option Flag bitmask, which can be used to execute the join process before or instead of the Empirum DomainJoin. Allowed here are empty values (default), decimal values, or hexadecimal values in the format "0x0000". More information about the Empirum DomainJoin:
    https://docs.microsoft.com/en-us/win...-netjoindomain
  • DomainJoinOptionFlagsOnly:
    If DomainJoinOptionFlags are defined, the value DomainJoinOptionFlagsOnly can be used to determine whether a DomainJoin should only be executed via Option Flags (value "1") or whether a standard Empirum DomainJoin should be executed if it fails (value "0" or empty).

clipboard_ef8a1e14a6db6b7f4dc71bd875b3a2fb6.png

The option "Moving to a different OU" is available starting from Windows 10 Build 1809!

  1. If a computer is configured for a workgroup, no further information is required.

clipboard_e995ff2b663ca64bde052f22b19c093c5.png

The Matrix42 PreOS package DomainJoin will not perform a domain join and will add the computer to the specified workgroup.

With Empirum v20.0.3 and higher in combination with the Matrix42 PreOS package DomainJoin 1.8 or higher, the computer property Domain is considered by the Matrix42 PreOS package DomainJoin.

With older versions, no Matrix42 PreOS package DomainJoin must be assigned, so that the domain join is not performed and the computer is added to the workgroup!

  1. If the computer is configured for the domain, make sure that the FQDN value is set in the computer's properties. This value must be specified for the domain join.
  2. Open the computer properties from the computer's context menu. The FQDN value can be set if the Overwrite property is enabled (check mark is set).

clipboard_ee76f0909eb9bc83006686e8dc66a4c16.png

  1. If desired, the OU (Organizational Unit in Active Directory) can also be customized.
  2. Confirm the changes with OK.

EmpirumAgentSetup-Package

The EmpirumAgentSetup package is executed to install the Empirum Agent on the client.

The variable M42_AGENT_PUSH_PACKAGE_FOLDER.Windows is used to specify the version and variant (Matrix42 Advanced Agent or Matrix42 UEM Agent) of the Empirum Agent.

The value of this variable is a relative path to the desired agent directory starting with the folder located at "Configurator$\Packages\Matrix42\". For example:

  • UEM Agent Windows\2006.4
  • EmpirumAgent\19.0
  • EmpirumAgent\18.0

 

EmpirumAgentSetup 2.2 and higher determines and uses the latest Matrix42 UEM Agent version that is released for installation, if no value is set.

Older versions of EmpirumAgentSetup use by default the Matrix42 Advanced Agent EmpirumAgent\19.0, or EmpirumAgent\18.0.

clipboard_e383c422432ff872ed911d0f56c1dc6b7.png

  1. Once all assignments have been made, the computer can be activated via the context menu.
  2. In the activation wizard that opens, activate PULL via DDS/DDC (software packages only) and Activate PXE (reinstall computer).

clipboard_e6c96ad934d0d2e95437e2c35d357e814.png

  1. Click on Next. The activation wizard must then be confirmed with Finish.
  2. The activated computer can now be booted via network/PXE and will load the created WinPE based PXE boot image.

clipboard_ed59d6318eeef39bd5b9bffcda0893c08.png

  1. If the loaded WinPE is started on the computer, the Matrix42 Universal Agent Framework starts automatically, which executes the assigned packages one after the other.

 

In the current version, manual intervention in the execution of the Matrix42 Universal Agent Framework is possible.

This should enable you to analyze the processes as easily as possible and to correct them if necessary.

A manual intervention may lead to a termination of the installation!

clipboard_e9d84002fc1f167a4ea63dcc3276552d9.png

When the Windows installation package is executed, the Windows installation is also executed.

clipboard_ee077ad9c4982cdf5d960f1c8528b61de.png

After the various installation phases have been completed, the operating system is installed on the computer.

PXE-Log

During a deployment with these packages, several restarts take place. The operating system is executed several times. During this time, the PE agent executes the assigned packages: LanguagePacksInstallation, DomainJoin and EmpirumAgentSetup. The PE agent itself is installed with the first boot of Windows in the phase of the first logon and removes itself after successful execution of all packages.

To understand or track the situation, it is recommended to check the PXE log of the corresponding client.

clipboard_e917e7cd30ab64975def7690652ae02b6.png

 

  • Was this article helpful?