What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
300.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

How to integrate Azure Active Directory into PRTG?

Votes:

1

Your Vote:

Up

Down

I want to use Azure AD as SSO provider for PRTG. How can I do this? What steps are necessary?

active-directory azure-ad prtg sso

Created on Sep 4, 2020 10:10:42 AM by  Brandy Greger [Paessler Support]



35 Replies

Accepted Answer

Votes:

1

Your Vote:

Up

Down

This article applies as of PRTG 21

Important: The following article only applies to PRTG Network Monitor. It does not apply to PRTG Hosted Monitor.

How to integrate Azure Active Directory into PRTG

As of PRTG 21.2.68, you can use Azure Active Directory (Azure AD) as single sign-on (SSO) provider in PRTG. For the integration to work seamlessly, follow the steps in this article.

Steps to take:

  • Step 1: Configure Azure AD
  • Step 2: Configure SSO in PRTG
  • Step 3: Add a user group in PRTG

Step 1: Configure Azure AD

Follow these steps to configure Azure AD to work as SSO provider in PRTG.

  • Step 1.1: Register your app
  • Step 1.2: Create a client secret
  • Step 1.3: Add a platform
  • Step 1.4: Create a groups claim
  • Step 1.5: Add a scope
  • Step 1.6: Edit accessTokenAcceptedVersion

Step 1.1: Register your app

  • Log in to https://portal.azure.com.
  • Go to the App registrations tab. App Registrations TabClick to enlarge.
  • Click the New registration button.
    • Enter a name, for example My_Registration.
    • Select Accounts in this organizational directory only. Register an App Click to enlarge.
    • Optional: Enter the redirect URI if you already know it. If you do not know it yet, you can enter it later.
    • Click the Register button to register the new app.
  • Select the newly registered app My_Registration.
  • Copy the Application (client) ID and Directory (tenant) ID.
    Note: You need these to configure PRTG later. Client ID and Tenant IDClick to enlarge.

Step 1.2: Create a client secret

  • Go to the Certificates & secrets tab. Certificates & Secrets Tab Click to enlarge.
  • Click the New client secret button. Add a Client Secret
    Click to enlarge.
    • Enter a Description, for example My_Client_Secret.
    • Enter the period after which the client secret expires.
    • Click the Add button to save the client secret.
      Important: Make sure to note the client secret now because it will not be visible again and because you need it when you configure PRTG.

Step 1.3: Add a platform

  • Go to the Authentication tab. Add a Platform Click to enlarge.
  • Click the Add a platform button. Configure Platforms Click to enlarge.
  • Select Web. Configure Web Click to enlarge.
    • Enter the redirect URI under Redirect URIs. Use the format https://IP address or DNS name:port/cb. For example, https://192.0.2.0:443/cb.
      Note: Make sure to add redirect URIs for the ports that PRTG uses, namely port 443 (default), port 8443 (fallback). If both 443 and 8443 are not available, PRTG sends a ticket that shows you the currently used port number. Add a redirect URI for this port until PRTG can switch back to 443 as soon as it is available again.
    • Click the Continue button to continue.

Step 1.4: Add a groups claim

  • Go to the Token Configuration tab. Token Configuration Tab Click to enlarge.
  • Click the Add groups claim button. Add Groups Claim Click to enlarge.
    • Select Security groups and Directory roles.
    • Click the Add button to save the new groups claim.

Step 1.5: Add a scope

  • Go to the Expose an API tab. Expose an API Tab Click to enlarge.
    • Click the Add a scope button. Add a Scope Click to enlarge.
    • Enter an Application ID URI.
    • Click the Save and continue button. Scope Settings Click to enlarge.
    • Enter a name for the scope. By default, Azure uses the format api://<client-ID>/<name given>. For our example, we will use api://<client-ID>/AnAPIName.

Step 1.6: Edit accesstokenacceptedversion

  • Go to the Manifest tab. Edit Manifest Click to enlarge.
    • Change accessTokenAcceptedVersion = 0 to accessTokenAcceptedVersion = 2

You have now successfully configured Azure AD.

Step 2: Configure SSO in PRTG

Now that you have configured Azure AD, you now need to configure the SSO settings in PRTG accordingly. To do so, follow these steps.


Important: Make sure that PRTG uses a connection that is encryped via SSL. For more information, see PRTG Manual: PRTG Administration Tool on Core Server System


  • Log in to the PRTG web interface.
  • Go to Setup | System Administration | Single Sign-On. Single Sign-On Tab Click to enlarge.
  • Under SSO Login, select Enable. Single Sign-On Settings Click to enlarge.
  • Under Provider, select Azure Active Directory from the dropdown list.
  • Under Configuration Endpoint, enter the configuration endpoint URL as follows https://login.microsoftonline.com/<tenant-ID>/v2.0/.well-known/openid-configuration
    Note: Make sure to replace <tenant-ID> with your directory (tenant) ID from Step 1.1.
  • Click the Load Configuration button. This automatically fills in the values in the next four fields.
    Note: If this does not work, then you have to manually enter the values instead as follows. Also, make sure to replace <tenant-ID> with your directory (tenant) ID from Step 1.1.
    • Authorization Endpoint: https://login.microsoftonline.com/<tenant-ID>/oauth2/v2.0/authorize
    • Token Endpoint: https://login.microsoftonline.com/<tenant-ID>/oauth2/v2.0/token
    • JSON Web Key Set (JWKS) URI: https://login.microsoftonline.com/<tenant-ID>/discovery/v2.0/keys
    • Issuer: https://login.microsoftonline.com/<tenant-ID>/v2.0
  • Under Scope, enter offline_access email. This is from Step 1.5. The full scope entry should look like this: openid profile offline_access email api://<client-ID>/AnAPIName
  • Under ClientID, enter the application (client) ID from Step 1.1.
  • Under Client Secret, enter the client secret from Step 1.2.
  • Under Available Callback URLs, select the URLS that your users will use to log in to PRTG. You will need to add these to the Azure app you configured in Step 1.3.
  • If the URL your users use to log in to PRTG is not listed because PRTG is reachable via a different URL (for example, myPRTG.example.com for login but PRTG lists myPRTG.internal.example.com), you can use the option Manually enter a URL. PRTG still lists all available endpoints if needed for forwarding. You then need to add the URL to the Azure app you configured in Step 1.3.
    Note: Azure AD and PRTG both check whether or not the callback URLs are allowed. Make sure you configure each required URL on both ends; otherwise, you will not be able to log in.

You have now configured SSO in PRTG.

Step 3: Add a user group in PRTG

Now that you have configured SSO, you need to add a new user group in PRTG.

  • Log in to the PRTG web interface.
  • Go to Setup | System Administration | User Groups.
  • Hover over the blue + button and select Add User Group. User Group Settings Click to enlarge.
    • Under User Group Name, give the group a meaningful name, for example Azure AD SSO.
    • Under Active Directory or Single Sign-On Integration, select Use single sign-on integration.
    • Under SSO Group Access Claim, enter the groups claim that you created in Step 1.4.
      Note: For claims, you can use Azure group IDs. To find a group ID, open the Azure portal and select the Groups tab. There you find a list of all groups and their object IDs. Find the object ID you need and enter it under SSO Group Access Claim. Alternatively, you can use the API name you previously configured, for example AnAPIName.

You have now successfully integrated Azure AD as SSO provider in PRTG.

Created on Sep 4, 2020 11:15:58 AM by  Brandy Greger [Paessler Support]

Last change on Jun 15, 2021 6:52:12 AM by  Brandy Greger [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hello,

thank you the tutorial worked.

My question: How Can I restrict the API to a special group?

I tried it with the object ID but this didn't work.

Created on May 28, 2021 12:18:26 PM by  Rixius (0) 1



Votes:

1

Your Vote:

Up

Down

I've followed this and it works fine. The the post above mine, the Object ID does work. I have tested this and when creating a PRTG SSO Group, and inputting the Azure AD Group Object ID into the 'SSO Group Access Claim', when a user from that Group logs into PRTG via SSO, they will join that group.

All good here. Thanks very much for this long awaited feature.

Created on Jun 1, 2021 10:35:51 AM by  AuRiSmith (70)



Votes:

1

Your Vote:

Up

Down

Also, can anyone confirm that the current mobile app is SSO/2FA compatible? I am having issues logging in with an SSO based account via cellular with a bad password hash error.

I have raised a case to check on this as well.

Created on Jun 2, 2021 9:54:46 AM by  AuRiSmith (70)



Votes:

1

Your Vote:

Up

Down

Does this work in the iOS app yet? I don't see an option for SSO there.

Created on Jun 2, 2021 3:53:24 PM by  Mike Garb (24) 1



Votes:

0

Your Vote:

Up

Down

Mobile Apps (IOS/Android) currently do not support Azure SSO. They use the classic login and require credentials. We are looking into implementing this in the future, however there is no ETA for this.


Kind regards,
Sasa Ignjatovic, Tech Support Team

Created on Jun 3, 2021 1:23:22 PM by  Sasa Ignjatovic [Paessler Support]



Votes:

5

Your Vote:

Up

Down

@ Sasa Ignjatovic ^^ Please look to do that soon! Many of us use the mobile app on weekends, after-hours and SSO via the app is important functionality to be released/

Created on Jun 4, 2021 2:26:54 AM by  AuRiSmith (70)



Votes:

3

Your Vote:

Up

Down

Can we use App Roles or any other form of permissions? Id like to assign different Azure AD users to different groups in PRTG.

Created on Jun 7, 2021 4:33:02 PM by  dbekker (30)



Votes:

0

Your Vote:

Up

Down

This is not possible. There are also currently no plans for this.


Kind regards,
Sasa Ignjatovic, Tech Support Team

Created on Jun 11, 2021 10:05:33 AM by  Sasa Ignjatovic [Paessler Support]



Votes:

4

Your Vote:

Up

Down

I'm having a similar issue when attempting to use a Azure group ID to target PRTG groups. I get an SSO logon failure. If I use the API name it works without issue, but doesn't allow me to restrict or target access. Any advice or way to troubleshoot?

Created on Jun 11, 2021 3:10:31 PM by  LWUsername (40)



Votes:

2

Your Vote:

Up

Down

I have also the same problem. If I use the api name everyone in our Azure AD can login via SSO. If I use the Group ID of the Azure Group I get an error. Is there any special setting/type of AD Group?

Created on Jun 22, 2021 2:43:36 PM by  Michael Schneider (43) 2



Votes:

1

Your Vote:

Up

Down

I<m having the same issue too for logging in the Group claims on PRTG I tried the API name, the object id of the user group, and the claim group that is in Token menu of azure.

After i logging with sso on PRTG it sayd we cannot log you in with SSO contact your Admin

Created on Jun 30, 2021 2:08:55 PM by  Gyslainh (10) 1



Votes:

0

Your Vote:

Up

Down

Does the URL configured in Azure AD for PRTG need to be a publicly accessible URL, or can it be the internal URL?

Created on Jul 1, 2021 4:44:24 PM by  jbuschSLWSD (0)



Votes:

0

Your Vote:

Up

Down

The Redirect- or Callback-URI does not have to be publicly acessible.


Kind regards,
Matthias Kupfer - Team Tech Support

Created on Jul 2, 2021 9:22:01 AM by  Matthias Kupfer [Paessler Support]



Votes:

1

Your Vote:

Up

Down

Me too. I am having the same issue that @Gyslainh for logging in the Group claims on PRTG I tried the API name, the object id of the user group, and the claim group that is in Token menu of azure.

After I logging with sso on PRTG receive message text "Your login via SSO has failed. Please contact your administrator!"

by Eder Aprigio

Created on Jul 3, 2021 4:11:53 AM by  TI-INFRASERVIDORES (10)



Votes:

1

Your Vote:

Up

Down

For those of you who would like to restrict the access via Azure-SSO, do as I did:

In Azure Portal go to "Enterprise Applications", search for your PRTG SSO app and open it. Under "properties" enable "user assignment". Then you need to go to "Users and Groups" and assign users or a groups you want to grant access. But still no way to assign users/groups to different roles.

@PRTG: It´s a shame that the Azure-Intigration is so rudimentary. Do you realy think I want to assign all 1300 Azure-Users admin-rights inside of PRTG. Group to Roll assignment is no nice-to have - it´s a must-have!!!

And please make mobile App and MFA happen. Same as role assignment - must-have.

THX!

Kai

Created on Jul 6, 2021 11:42:14 AM by  KaiDzialas (10)



Votes:

1

Your Vote:

Up

Down

Hello,

when implementing features, we first aim to cover the most important things. Then we check if there is a lot of demand for further options. This way we make sure to meet market demand.

Features can be requested this way. I agree that a more thorough implementation of AD authentication options would be useful, however many items on our roadmap are currently in higher demand than MFA or more AD assignment options. As developer of off-the-shelf software, we have to carefully decide when to do what.

Regarding user mapping, you can map different AD groups to different PRTG user groups in which you set the respective set of rights, with copying in the respective claim.

Created on Jul 12, 2021 6:59:03 PM by  Arne Seifert [Paessler Support]

Last change on Jul 14, 2021 8:42:14 AM by  Arne Seifert [Paessler Support]



Votes:

1

Your Vote:

Up

Down

I see a few posts on here about not being able to authenticate with sso and getting the error "Your login via SSO has failed. Please contact your administrator!", but I don't see any updates on where that issue is coming from.

Anyone resolve that issue?

I don't know where to find my "api name", maybe people mean the "scope name"?

I've tried the obect ID for the security group I set up in Azure AD, and still getting the error. I tried the "display name" for the app registration, and I've tried about every ID I could find, and still getting the error.

When I test the SSO connection (in the PRTG setup) it says OK (200), but I'm not sure of any other way to verify this is set up correctly.

I'm not finding any log info on Azure or PRTG that lets me know what is failing. Anyone find a way to see details on the failures?

Created on Jul 19, 2021 8:05:51 PM by  Jesse (10)



Votes:

0

Your Vote:

Up

Down

Thank you for implementing SSO, we have been keenly waiting for this. Unfortunately we are also unable to get the Azure group objectID to work. It allows you to enter your credentials but then gives an error "Your login via SSO has failed. Please contact your administrator!"

Created on Jul 19, 2021 11:38:43 PM by  RolandJ (0)



Votes:

0

Your Vote:

Up

Down

Hello Jesse,

the api name is an alternative input for the groups claim. Normally, the groups claim is used, and can be setup in Azure AD.

More detailed logs can be written by adding the line

category.Core_LoginTrace=DEBUG

in PRTG_GlobalLoggingConfiguration.logcfg. Default location is "C:\ProgramData\Paessler\PRTG Network Monitor\Logs\PRTG_GlobalLoggingConfiguration.logcfg" on the PRTG core server. Make sure that the path is the same as the one displayed in PRTG Administration Tool, tab PRTG Core server. ​

Once the change is saved, reload the logging configuration in PRTG using Setup / System Administration / Administrative Tools, function "Reload Logging Configuration".

It is important do remove this line later on, otherwise the logs are filled quickly, making them more difficult to read for analyzing other issues.

Created on Jul 20, 2021 2:59:50 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hello Roland,

for more detailed information about login issues, you can change the log level as described above.

Created on Jul 20, 2021 3:00:16 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Thank you, Arne! I'm getting this logging set up now.

When you say "groups claim", do you mean any security group in Azure AD?

Where do I find the API name?

Created on Jul 20, 2021 6:07:27 PM by  Jesse (10)



Votes:

0

Your Vote:

Up

Down

Update on my issue. The debug logging for login was exactly what I needed. It showed "Invalid client secret is provided".

In my case I got the secret ID and Value mixed up. Once I had the actual secret value in the SSO setup for PRTG it worked right away.

Thanks again for all your help, Arne!

Created on Jul 20, 2021 7:42:42 PM by  Jesse (10)



Votes:

0

Your Vote:

Up

Down

I was initially having issues with my SSO configuration, and it turned out that I was using the wrong Client Secret (I was using the Secred ID instead of the Value). Once I corrected that, I was able to log in using the API name and also using group ID's. I haven't thoroughly tested it, but it looks like I was able to assign admin and standard user privileges in PRTG correctly. I've only tested with a couple of users, but here's what I did. I created 2 separate user groups in PRTG, and I used the Azure group object ID for each of them. The first group was named Azure SSO Admins, and I used the group object ID for an Azure group named PRTG Admins. The second group was named Azure SSO Regular Users, and I used the group object ID for the Azure group named PRTG Users. When I tried SSO as an admin for my own account, it correctly identified me as such. When one of my staff tried SSO as a regular user, it also correctly identified him as such. I tested using Microsoft Edge and Google Chrome. Please keep in mind that when you're logging in, you should not be putting in any user creds (username and password are both BLANK), but just hitting the "Log in with single sign-on" button. There are plenty of scenarios I haven't tested yet, but I hope this helps somebody, as I was getting frustrated when trying to configure this. The tip about enabling the logs in a previous post is what helped me identify the issue with the secret, which also reminds me of something else. I used category.CoreLoginTrace=DEBUG (NO UNDERSCORE) which followed the standard of the other parameters in that log config file. It didn't seem to work with the underscore in it. Have fun!

Created on Jul 20, 2021 8:43:29 PM by  PJ Campos (0)



Votes:

0

Your Vote:

Up

Down

Hello Jesse,

the group claim can be configured in AzureAD.

Nice to hear that you got SSO to work.

Created on Jul 21, 2021 10:07:33 AM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I was wrong. Did not work!

I managed to assign different PRTG groups to different Azure AD groups.

Add both groups as scope in "Expose an API" in Azure App registrations with the Azure group Object Id as name.

The part that I missed first: Add both groups to the scope in the SSO Config in PRTG.

openid profile offline_access email api://<applicationId>/<group1Id> api://<applicationId>/<group2Id>

Created on Jul 21, 2021 3:09:58 PM by  ABS (0) 1

Last change on Jul 22, 2021 12:32:12 PM by  Felix Wiesneth [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hello PJ,

the correct line should contain the underscore, even though the other categories have none.

Hello ABS,

thank you for the input.

Created on Jul 21, 2021 5:04:06 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hello Peassler Team,

could you please integrate the important information from my colleague ABS regarding configuration of several access groups with group id in section "scope" to the knowledgebase article above?

I think adding that information with an example would help lot of other people.

Yours

Created on Jul 22, 2021 9:48:35 AM by  ATP (0) 1



Votes:

0

Your Vote:

Up

Down

additional information for the post from my colleague ABS:

we have tested the solution, and now all SSO users are associated to both groups (admin and user groups) in PRTG. We checked the azure ad group, and there affected users are only member of one group! So it seems that SSO with different rights dependent on membership of azure ad group is not possible at the moment. Please paessler team solve this issue. Thanks!

Created on Jul 22, 2021 10:00:09 AM by  ATP (0) 1



Votes:

0

Your Vote:

Up

Down

Hello ATP,

Thank you for your comment.

However, please note that this option is already possible.

Yet there is one way of configuring SSO in a way, that members will end up in both PRTG groups: using the exposed API name as an SSO claim - which is what you did in this case. Problem here is that any Azure user logging in will be assigned both claims.

Instead of that, you should add a groups claim to the app in Azure, then the users' associated group IDs will be part of the claims list and can be used to assign Azure user accounts to different PRTG groups.

Best regards

Created on Jul 28, 2021 9:29:17 AM by  Isidora Jeremic [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hello ATP,

Thank you for your comment.

However, please note that this option is already possible.

Yet there is one way of configuring SSO in a way, that members will end up in both PRTG groups: using the exposed API name as an SSO claim - which is what you did in this case. Problem here is that any Azure user logging in will be assigned both claims.

Instead of that, you should add a groups claim to the app in Azure, then the users' associated group IDs will be part of the claims list and can be used to assign Azure user accounts to different PRTG groups.

Best regards

Created on Jul 28, 2021 9:29:18 AM by  Isidora Jeremic [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hello,

I wanted to add different groups based on my Azure group. My SSO was working but with a single group. I got it working following the different comment.

First you need to

  • create an Azure group (security for example) and copy it's ID
  • Add a user to this group
  • Then you create a group in PRTG and past the group ID in SSO Group Access Claim

And, what I had forgotten to do :

  • Login to your Azure portal
  • Go to your application
  • Go to Token configuration
  • Add a group claim and choose the type of group you want (in my case security)

Now the specific ID you had put in your SSO Group Access Claim is recognize and should be working when you login with a member of the Azure Group you had created

Good luck

Created on Aug 4, 2021 4:19:58 AM by  moncloud-prtg (0)

Last change on Aug 5, 2021 6:55:14 AM by  Florian Lesage [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Just for awareness, there doesn't seem to be a way to apply SSO sign in to existing users. Once SSO is configured, it creates a new user account for the user which has none of their original permissions. For my environment, where we have many users and groups configured with different permissions across thousands of devices, the only way I can get SSO integrated would be to completely rebuild my PRTG environment and recreate all the different permissions using the new groups and users. Hopefully one day there will be a way to apply it to existing users, but until then this integration isn't of much use unless you have a very simple deployment or are starting from scratch.

Created on Aug 4, 2021 2:00:58 PM by  cb1ocker (0)



Votes:

1

Your Vote:

Up

Down

Jut want to inform that I was able to integrate on premises ADFS : in your onprem ADFS go to "Application groups", add... , choose from template "server application accessing a web API", name it, next, under "redirect uri " enter one of the "Available Callback URLs" from your servers sso settings page i.e. https://<prtg server FQDN>:443/cb , take note of the "client identifier" on this page, next, under "Configure application credentials" mark "generate a shared secret", take note of the generated secret, next, configure Web API identifier : https://<prtg server FQDN>, add, next ,next, in "Configure Application Permissions / Permitted Scopes " make sure openid is selected, next and finish. Now back to yor PRTG SSO settings page in configuration endpoint : https://<ADFS fqdn>/adfs/.well-known/openid-configuration click "load configuration" it should populate most fields, but you need to replace "Scope" field with "openid profile offline_access email api:<client-ID>/AnAPIName" as is , now enter the client id and the secret we took note from ADFS, select the "Available Callback URLs" and test it, it should give you "OK (200)" , save and you are done. This is just a basic ADFS setup, you can tweak it to make it more secure.

Created on Aug 31, 2021 9:07:37 AM by  Alon Or (10)

Last change on Aug 31, 2021 1:00:14 PM by  Felix Wiesneth [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Just in case anyone also has a larger azure tenant where some users might have over 200 groups assigned:

Be aware that, at least for now, prtg can't handle these with previously mentioned setups!

This is due to a hard limit for groups in a claim. https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-group-claims In larger organizations the number of groups a user is a member of may exceed the limit that Azure Active Directory will add to a token. 150 groups for a SAML token, and 200 for a JWT.

You can quite easily adapt previously mentioned setups like this (where you filter claims by a group id to have different priviledges in prtg based on group membership) by doing these steps:

  • Within app registrations: Select your app and create an app role for each group you need. The "value" property for roles, at least for now, doesn't seem to matter.
  • Within enterprise applications: Select your appand and assign all ad/azure groups you need within the "Users and Groups" menu. Select the according app role counterparts you've created before for each group.
  • Within app registrations: Finally, go to "Token configuration", select "add a groups claim" and only select "Groups assigned to the application" and nothing else.

The ID you'll set in each SSO Group within PRTG will still be the Object ID of the according azure group.

There is one major downside though:
Claims by app roles will ignore nested group members meaning that each and every member has to be a direct member of the ad/azure group. If your environment wouldn't allow for this (or you simply don't want to assign each user directly) you could:

  1. Use a dynamic azure group which automatically assigns users to itself based on rules/properties you provide (like a specific string in an extenionattribute). Unfortunatley you cannot create groups based on current group membership as the memberOf property is not available for dynamic groups.
  2. Assign Users via a script/scheduled task/etc.

Created on Oct 14, 2021 6:01:22 PM by  MohnJcAfee2 (0)



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.