New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

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

Free PRTG
Download >>

 

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

 

Top Tags


View all Tags


I get the error "WinRM cannot process the request" when I try to use a Powershell Sensor

Votes:

0

Your Vote:

Up

Down

Whenever I try and 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]



10 Replies

Accepted Answer

Votes:

0

Your Vote:

Up

Down

This article applies to PRTG Network Monitor 13 or later

"No Logon Servers Available" when Using PowerShell Sensors

With a computer that is not joined to the domain, you cannot start a remote Powershell session using Kerberos Authentication. This is the authentication type for the Powershell sensors that are used by PRTG.

The main reason we have set this up with Kerberos is that the other forms of authentication are not as secure. By enabling these sensors to work with these other forms of Remote PS session authentication, those servers would be open to other computers outside the domain initiating similar sessions.


"Unknown security error" with PowerShell Sensors

Please see this article if WinRM cannot process the request and you encounter an Unknown security error:

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

Last change on Jan 14, 2014 3:43:19 PM by  Gerald Schoch [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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 by  jf_hernandez (0) 1



Votes:

0

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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: http://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 by  DmitriyS (0)



Votes:

0

Your Vote:

Up

Down

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:

0

Your Vote:

Up

Down

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 by  artisticcheese (0) 1



Votes:

0

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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 by  Jiri Hadamek (0)



Votes:

0

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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 amontes@newportsystemsusa.com

Created on Feb 20, 2017 10:54:50 PM by  amontes0911 (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.