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
Article Comments
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
Aug, 2015 - Permalink
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.
Aug, 2015 - Permalink
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.
Aug, 2015 - Permalink
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
Aug, 2015 - Permalink
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.
Feb, 2016 - Permalink
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 :)
Feb, 2016 - Permalink
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 :)
Aug, 2015 - Permalink