Advanced

Contents

• Custom Sensors Redirection
• Credential Spec / Active Directory Authentication
• Image Compatibility
  • Windows Updates
• Hyper-V Isolation

Custom Sensors Redirection

By default, PrtgDocker will redirect the C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors folder to C:\ProgramData\Paessler\PRTG Network Monitor\Custom Sensors. When -Volume is specified to New-PrtgContainer, C:\ProgramData\Paessler\PRTG Network Monitor will be mapped to your volume, giving you direct access to the Custom Sensors folder within from your Docker host's filesystem.

While this works well for one container (such as the PRTG Core Server), if you're attempting to create half a dozen probes for load balancing purposes, copying and pasting sensors across all of your container's Custom Sensors folders whenever you make a change no longer becomes ideal.

PrtgDocker allows you to work around this issue by specifying a -CustomSensorsPath pointing to a UNC folder containing your Custom Sensors files.

New-PrtgContainer -Probe -CustomSensorsPath "\\fs-1.consoto.local\CustomSensors"

When -CustomSensorsPath is specified, the original symlink on C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors is replaced with a new symlink to the external UNC path you specified.

It is important to note that your Custom Sensors UNC path must use the fully qualified domain name of the target server. i.e. make sure you specify \\fs-1.contso.local\CustomSensors and not \\fs-1\CustomSensors. Your container will not know how to resolve your server's short name by default. Unless you know how to make DNS search domain resolution work, I recommend just specifying the FQDN to avoid any issues.

Note that while specifying -CustomSensorsPath will allow your Custom Sensors folder to point to an outside domain resource, in practice you will likely find that your container is unable to authenticate to this network resource, as containers are not part of the domain. To work around this issue, please see the Credential Spec section.

Credential Spec / Active Directory Authentication

Docker containers can authenticate to network resources using Active Directory credentials via the use of a Group Managed Service account (gMSA). Once a gMSA has been created for your domain and your Docker hosts have been configured to use it, individual containers can take advantage of gMSA accounts via the use of a credential spec configuration file. PrtgDocker can automatically create credential specs for you and pass them in the arguments to docker run via the -CredentialSpec and -CredentialSpecAccount parameters

New-PrtgContainer -Probe -Name "New York 1" -CredentialSpec -CredentialSpecAccount container_gmsa

When -CredentialSpec is specified, PrtgDocker will attempt to locate a credential spec based on the -Name that was specified for the container (in this case, the credential spec would be called new_york_1). If a -Name was not specified, New-PrtgContainer will throw an exception. If a credential spec with the desired name could not be found, PrtgDocker will helpfully create one for you based on the specified -CredentialSpecAccount. If a credential spec could not be found and -CredentialSpecAccount was not specified, New-PrtgContainer will throw an exception.

If you don't like how PrtgDocker handles credential specs, you can take over this process yourself and specify the Docker credential spec arguments as -AdditionalArgs to New-PrtgContainer.

For more information on configuring your environment for use with Group Managed Service Accounts, please see gMSA Configuration.

Image Compatibility

PRTG is compatible with both Windows Server 2016 and 2019 based images when utilizing (mainly) 64-bit executables. When installing in Server Core 2019 based images, PrtgDocker will automatically install the required fonts (Arial and Tahoma) required for PRTG's chart drawing library (Chart Director) that have been stripped from the base installation.

Attempting to use the 32-bit version of PRTG Server will cause immediate crashes upon starting when utilizing any version of PRTG using Themida anti-cracking software (PRTG 16.4.28+).

Windows Updates

If you've downloaded a Windows Server Core base image after February 11, 2020, please note that these images are incompatible with the version of Server 2016 and Server 2019 that is installed out of the box. In order to successfully install PRTG in these images, please make sure the version of Windows on your Docker host is at least higher than the February 11, 2020 update.

To check whether your Docker Host is up to date, run the following command to check the version of Windows installed on the host

C:\> winver

Microsoft Windows Server
Version 1607 (OS Build 14393.2248)
...

If you've already attempt to run New-PrtgBuild or have run docker pull on the appropriate Server Core LTSC image already, you can inspect the version of the image to compare it with the version of your Docker host

C:\> docker inspect mcr.microsoft.com/windows/servercore:ltsc2016 -f "{{.OsVersion}}"

10.0.14393.3930

To find out what update each version correspond to, simply Google the build number. In this scenario, we can see that while the container image is running the September 8, 2020 update, the host is only running the May 8, 2018 update, so will likely encounter issues when attempting to install PRTG inside of Docker.

For more information please see the following articles

• Host and Container Version Compatibility
• You might encounter issues when using Windows Server containers with the February 11, 2020 security update release

Hyper-V Isolation

If you wish to run your images on a system that does not match the system the image was built on, you may be able to do so using Hyper-V isolation. Images can be built and deployed using Hyper-V isolation by specifying the -HyperV parameter to New-PrtgBuild or New-PrtgContainer respectively.

1. Install Hyper-V on your Docker server
2. New-PrtgBuild -HyperV
3. New-PrtgContainer -HyperV

Note: If your Docker server is a virtual machine, you may need to enable nested virtualization in order to install Hyper-V