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

Unable to add ANY of the Exchange sensors on a remote probe

Votes:

0

Scenario: Computer A is the core PRTG install. Computer B (called SHSRV.SHF.local), on a remote site, is hosting a PRTG probe and is also hosting Exchange 2010 - it's an SBS2011 box.

I am trying toa dd any of the Exchange sensors - Exchaneg Database for example, but they are failing due to WMI issues. I have enabled Analytic logging on the Wndows Remote Management event log and I can see the information flow, but I see this message:

SOAP [client sending index 1 of 4 total chunks (1500 bytes)] <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:w="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd" xmlns:p="http://schemas.microsoft.com/wbem/wsman/1/wsman.xsd"><s:Header><a:To>http://127.0.0.1:80/Powershell?PSVersion=2.0</a:To><w:ResourceURI s:mustUnderstand="true">http://schemas.microsoft.com/powershell/Microsoft.Exchange</w:ResourceURI><a:ReplyTo><a:Address s:mustUnderstand="true">http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</a:Address></a:ReplyTo><a:Action s:mustUnderstand="true">http://schemas.xmlsoap.org/ws/2004/09/transfer/Create</a:Action><w:MaxEnvelopeSize s:mustUnderstand="true">153600</w:MaxEnvelopeSize><a:MessageID>uuid:B7623B18-4D7F-4EB5-89D8-DF75DCA7105C</a:MessageID><w:Locale xml:lang="en-US" s:mustUnderstand="false" /><p:DataLocale xml:lang="en-GB" s:mustUnderstand="false" /><p:ActivityId s:mustUnderstand="false">03EC8C60-F800-0004-5A8D-7C37B5DAD001</p:ActivityId><w:OptionSet xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" s:mustUnderstand="true"><w:Option Name="protocolversion" MustComply="true">2.1</w:Option></w:OptionSet><w:OperationTimeout>PT180.000S</w:OperationTimeout><rsp:CompressionType s:mustUnderstand="true" xmlns:rsp="http://schemas.microsoft.com/wbem/wsman/1/windows/shell">xpress</rsp:CompressionType></s:Header><s:Body><rsp:Shell xmlns:rsp="http://schemas.microsoft.com/wbem/wsman/1/windows/shell"><rsp:IdleTimeOut>PT240.000S</rsp:IdleTimeOut><rsp:

followed by this message

An error was encountered while processing an operation.
Error Code: 2150859019
Error String:<f:WSManFault xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="2150859019" Machine="****"><f:Message>The WinRM client cannot process the request. Kerberos authentication cannot be used when the destination is an IP address. Specify a DNS or NetBIOS destination or specify Basic or Negotiate authentication. </f:Message></f:WSManFault>

The important bit from the second message is: Kerberos authentication cannot be used when the destination is an IP address

and the imortant bit from the first message is: <a:To>http://127.0.0.1:80/Powershell?PSVersion=2.0</a:To>

127.0.0.1 probably makes sense, as the probe and Exchange are on the same box. But what am I missing from the setup or any configuration please?

My prtg user (a domain admin) is authorised for remote management Set-User prtg -RemotePowerShellEnabled $True

Many thanks

Jim

exchange prtg wmi

Created on Aug 20, 2015 2:01:25 PM

Last change on Aug 20, 2015 2:37:36 PM by Torsten Lindner [Paessler Support]



8 Replies

Votes:

0

You have to add the Exchange as a device under the probe, using SHSRV.SHF.local as its address. Sounds weird, but the way you currently configured it, the authentication chain is broken and the sensors won't work properly :)

Created on Aug 21, 2015 11:30:39 AM by Stephan Linke [Paessler Support]

Last change on Aug 21, 2015 11:30:53 AM by Stephan Linke [Paessler Support]



Votes:

0

Hi Stephan

Many thanks....but that's exactly what I have already. Here's my setup:

https://mail.mx500.co.uk/2015-08-21_123227.jpg

Doing further googling, it seems that the prope is ALWAYS checking via IP address, not FQDN, which seems wrong. For it to work via IP you must use SSL and you must pass the Credentials parameters. The Exchange sensor seems to do neither of these..

Any thoughts? Does anything need setting up via kerberos?

Jim

Created on Aug 21, 2015 11:38:12 AM



Votes:

0

Hmm....weird. I already have that server under the probe but it has IP 127.0.0.1. I didn't add this, prtg added it automatically when I installed the probe, and it knows that it's a probe device. So must I add the device AGAIN but this time with the FQDN?

As the existing entry is a probe, I do not get the option to change the IP/DNS entry.

Created on Aug 21, 2015 11:46:28 AM



Votes:

0

Sorry, you got me wrong - create a new device on that very remote probe and give it the address SHSRV.SHF.local in its settings - then you'll be able to add the exchange sensors properly.

Created on Aug 21, 2015 12:01:51 PM by Stephan Linke [Paessler Support]



Votes:

1

Many thanks, this is now solved. For the benefit of others, yes, the above suggestion was correct.

All of my normal sensors, including WMI sensors, were fucntioning correctly when they were attached directly to the probe device. But the Exchaneg sensors do not. So the solution is to add a second device, with the same details as the probe device EXCEPT to have a FQDN instead of an IP, and add the Exchaneg sensors there.

Many thans for the help stephan.

Jim

Created on Aug 21, 2015 4:27:10 PM



Votes:

0

You're very welcome :)

Created on Aug 24, 2015 7:30:50 AM by Stephan Linke [Paessler Support]



Votes:

0

Why is there no solution without the second device. That's annoying. For example a new feature which allows us to set the FQDN manual in the Sensor settings for this kind of Sensors? Please note this as feature request. Thanks.

Created on Feb 18, 2016 4:20:08 PM



Votes:

0

As noted in my previous post, it's not possible without a second device featuring the FQDN of your exchange. Otherwise, the authentication chain is broken and PRTG can't authenticate against the server. Sorry, that's the way it is :)

Created on Feb 19, 2016 6:42:12 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.