What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

I get the error "WinRM cannot process the request" when I try to use a PowerShell sensor

Votes:

0

Whenever I try to use a PowerShell sensor with a server or computer that is not joined to the domain, I get the message

Connecting to remote server failed with the following error message : WinRM cannot process the request. The following error occured while using Kerberos authentication: There are currently no logon servers available to service the logon request.

Why is this?

kerberos off-domain powershell prtg windows-update-status winrm

Created on Jan 14, 2014 2:52:40 PM by  Greg Campion [Paessler Support]

Last change on Sep 13, 2019 8:24:37 AM by  Brandy Greger [Paessler Support]



16 Replies

Accepted Answer

Votes:

0

This article applies as of PRTG 22

"No logon servers available" when using PowerShell sensors

With a system that is not joined to the domain, you cannot start a remote PowerShell session via Kerberos Authentication. This is the authentication type for the PowerShell sensors in PRTG.

We set this up with Kerberos because other forms of authentication are not as secure. By enabling these sensors to work with other forms of remote PowerShell session authentication, the respective servers would be open to other systems outside the domain that are initiating similar sessions.

"Unknown security error" when using PowerShell sensors

If WinRM cannot process the request and you get an Unknown security error, see the link below:

My PowerShell sensor returns an error message. What can I do?.

Created on Jan 14, 2014 2:59:08 PM by  Greg Campion [Paessler Support]

Last change on Jun 2, 2022 8:42:06 AM by  Brandy Greger [Paessler Support]



Votes:

0

Hi Paessler Team,

In the following scenario:

Net-A<---->INTERNET<---->Net-B

Where Net-A is in Domain-A and Net-B is in Domain-B. If in Net-A I have the PRTG Main Server and in Net-B a PRTG Remote Probe.

1.- Would be possible to execute a powershell script that connects from Net-A to a remote Windows server in Net-B and executes a script located in this remote machine? Or the forced Kerberos authentication will fail (because of different domains)? This is assuming every machine is in their own domain (A or B).

2.- The Kerberos authentication you force in powershell applies both your included sensors and custom Powershell sensors?

Thanks.

Created on Jun 25, 2014 7:41:30 PM



Votes:

0

Sorry, it will be necessary to execute the Remote Powershell scripts on the machine with the Remote Probe in Net-B, if you want to target machines in the domain of Net-B.

Created on Jun 30, 2014 9:27:43 AM by  Torsten Lindner [Paessler Support]



Votes:

0

Hi, I will join the 2-nd jf_hernandez`s question. Are there any other solutions (without Kerberos authentication) to collect Windows Update statistics from computer that is not joined to the domain? May be I should use custom Powershell sensor with using invoke-command and pass explicit credentials, such as in this example: https://kb.paessler.com/en/topic/63936-custom-sensor:-get-process-with-powershell ? But I cant find complete script to collect Windows Update statistics in PRTG. Pls help me

Created on May 8, 2015 7:37:06 AM



Votes:

0

Well, for starters, the updates are read like this: $updatescope = New-Object Microsoft.UpdateServices.Administration.UpdateScope

In order to execute a command via Invoke-Script, something like this would work:

Param( [string]$ComputerName = "",  [string]$UserName = "", [string]$Password = "" )

# We need a credential object 
#######################################
function createCredentials(){
	if((($env:COMPUTERNAME) -ne $ComputerName)){
		# Generate Credentials Object first 
		$SecPasswd  = ConvertTo-SecureString $Password -AsPlainText -Force
		$Credentials= New-Object System.Management.Automation.PSCredential ($Username, $secpasswd)
		return $Credentials
	}
	else{ return "false" }
}

function getUpdates(){
    $Credentials = (CreateCredentials);
    # Generate CIMSession
    $RemoteSession = New-PSSession -ComputerName $HostName -Credential $Credentials -Name "PRTG Scheduled Task Remote Session"
    $UpdateScope = (Invoke-Command -Session $RemoteSession -ScriptBlock { New-Object Microsoft.UpdateServices.Administration.UpdateScope })

<# the output has to go here #>

	if (!($RemoteSession)){
		Write-Host 1":Error creating remote session.";
		Remove-PSSession($RemoteSession);
		exit 1;
	}

	Remove-PSSession($RemoteSession)
	exit 0
}

# Action!
getUpdates;

Since I'm not quite sure how you need the output, have a look at this "Hey, Scripting Guy!" article, it explains how to retrieve the various updates accordingly.

Created on May 13, 2015 8:52:43 AM by  Stephan Linke [Paessler Support]



Votes:

1

Answer from PRTG does not make any sense. Why kerberos is required? Why not rely on NTLM which is the same protocol which is used for remote management via WMI and is allowed by PRTG. Please remove this ridiculous and unnecessary limitation.

Created on Mar 27, 2016 1:40:39 PM



Votes:

0

Dear artisticcheese

We use Kerberos because it is more secure and faster. Powershell code poses a much greater security risk than a WMI read-out.

Created on Mar 28, 2016 1:46:18 PM by  Arne Seifert [Paessler Support]



Votes:

0

Why you don´t use (as second or fallback option) connectivity with TrustedHosts set on Remote side. Or simply try to use this when Kerberos isn´t working. It is similar to using WMI or Performace monitor.

Created on Aug 4, 2016 1:31:46 PM



Votes:

0

We are aware of certain cases when the sensors using Remote Powershell run into issues, but the current solution covers most of the real-world cases. If we see the potential to help many PRTG users with an alternative to Kerberos, we will have another look.

Created on Aug 4, 2016 1:56:29 PM by  Arne Seifert [Paessler Support]



Votes:

0

Go to IIS Manager on your Exchange server and make sure you do not Kerbauth.dll register on the default Web Site. if it is, just delete it and register it to the power shell section under module. if you have question email me at [email protected]

Created on Feb 20, 2017 10:54:50 PM



Votes:

1

This doesn't make sense at all... I want to use a sensor to monitor windows updates on my 3 Hyper-V hosts, running 2008 R2. They're all on the same LAN, behind VPN.

This is ridiculous, so this means it can't be done? You've got to be kidding me.

Created on Apr 8, 2017 12:45:16 PM



Votes:

0

Are those servers part of the same domain as your PRTG server?

Created on Apr 10, 2017 8:45:33 AM by  Stephan Linke [Paessler Support]



Votes:

1

So then, how can i monitor Windows Update statuses for servers that aren't connected to a domain? There surely must be a way. We have many, many servers (over 50) that can't and won't be domain connected and that I need to monitor for Windows updates. Please let me know!

Created on May 19, 2017 9:58:00 AM



Votes:

0

Hi there,

We're currently looking into checking hosts not part of the domain, i.e. lack kerberos authenticaion. Please bear with us on this one, it may take a bit due to technical complexity of the topic.


Kind regards,
Stephan Linke, Paessler Tech Support

Created on May 19, 2017 11:59:10 AM by  Stephan Linke [Paessler Support]



Votes:

1

Hi,

Have you managed to make any progress with checking hosts outside of the domain?

Kind regards,

Andrew

Created on Aug 29, 2017 5:13:44 PM



Votes:

0

Unfortunately, this can't be done - please use remote probes when checking hosts outside for the domain.

Created on Aug 30, 2017 6:07:49 AM by  Stephan Linke [Paessler Support]




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.