uberAgent Extension

The uberAgent Extension is an add-on for all our existing modules. It deeply integrates with the following components:

  • PSADT packages for installation of uberAgent on nodes
  • PowerShell DSC configurations to replace your existing GPOs
  • Kibana Dashboards that you can import into your existing Elasticsearch infrastructure or to use it with our insights.XO module without the need to spin up your own Splunk or Elasticsearch instances.
  • Licenses for uberAgent if needed (you can bring your own licenses as well)

Supported Operating Systems

Our uberAgent extension supports the following operating systems and architectures:

Concepts and Guidelines

With our extensive experience in enterprise environments we have developed multiple concepts on how to create software packages for deployments. We focus on reusablity, parameterization, prerequisites and reducing the footprint of single packages. Everything is built to be used with our Lego-principle.

Prerequisites and Integrated Installers

Based on our experience, the installation of a program and associated Windows Roles and Features or software prerequisites and components should be done separately. If a software installation contains test mechanisms for prerequisites and separate installation files for the main program, these are packaged separately in order to be able to be installed during software distribution before the actual program. The control of the installation is therefore entirely in the hands of the infrastructure team.

Such prerequisites are often applicable multiple times for other software products and in large enterprise environments new combinations of infrastructures can be designed from a library of software packages.

Independent and Reusable Packages

Software packages must be universal and independent of the used software distribution product. That’s why we use PowerShell as well as the PowerShell AppDeployment Toolkit. This allows a completely product independent use of packages. This reflects the changeability of the software used by customers. Today a customer might use SCCM, tomorrow something completely different.

Thanks to the packaging basis we provide, we support our customers to be independent in the long term without worrying about re-packaging due to a product change.

Below you will find a wide range of possibilities for entering with our packages:

  • Usage in SCCM
  • Usage in Heat/DSM
  • Installation as standalone package
  • usage in PowerShell DSC or Puppet
  • or in another scripting solution

Minimizing the Package-Footprint

Today, packages are no longer only created and used locally, but are replicated through global locations instead. Because of this, packages must be kept as small as possible (based on the sources it contains).

Parameterization and Variables

To ensure the previous concepts and guidelines, it is not allowed to include an installation package with fixed installation options or paths. All possible installation options must be passed as parameters to the installation package.

The Lego-Principle

The Lego-Principle describes a modular system. By creating software packages for the smallest possible part of an installation, organizations can easily create new package combinations in their environment. Every customer is able to respond to his individual requirements.

Naming Conventions

This chapter discusses the naming convention for our packages. This is the XOAP naming convention. All installation and configuration packages are named after this defined concept.

TYPE_Manufacturer_Name_Version_OperatingSystem_Plattform_Language

Example:

APP_Citrix_VDAServer_1912_W2K19_x64_Any

The following table describes the options:

Type

Possible values are:

  • APP = Application
  • USR= User configuration
  • SYS = System configuration
  • DRV = Driver

Manufacturer

  • e.g. Citrix

Product

  • e.g. VDA Server

Version

  • e.g. 1912

Operating System

Possible values are:

  • W7
  • W8
  • W81
  • W10
  • W2K8
  • W2K8R2
  • W2K12
  • W2K12R2
  • W2K16
  • W2K19

Architecture

Possible values are:

  • x86
  • x64
  • Any

Language

Possible values are:

  • EN
  • DE
  • Any

Packages must not use spaces, only underscores to separate the areas.

Silent installation

All packages created by XOSS have been designed for silent or unattended running capability. However, the deployment scripts can be adjusted to run interactively and with dialog boxes if you like to.