Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Sharepoint 2013 HTTPS monitor failing

I'm trying to monitor several sites on a Sharepoint 2013 cluster using the HTTPS monitor, but they all fail with the error The remote server returned an error: (401) Unauthorized.

The page should be the typical "Please tell us why you need access", but this isn't the usual 401 Unauthorized error. I have Follow Redirect set to Follow. I have tried Do Not Follow, same result.

This problem does not occur on Sharepoint 2010 sites (with the Follow Redirect set to Do Not Follow.)

We're using SAM 6.1.1 currently.

Find more posts tagged with

Accepted answers

All comments

aLTeReGo

Unauthorized typically means no credentials were provided, or that the credentials used have insufficient permissions for accessing the page. It's also possible that the page you are expecting to see is really just a custom designed 404 error page, and SAM is properly reporting it as such. Another possibility is that the SharePoint site is configured to use host headers and can't be accessed using the raw IP address. In this case you should populate the host header field of the HTTP/HTTPS User Experience Monitor with the appropriate host header for the site you wish to monitor.

Host Header.png

ttl

I have actually replaced the default setting within the Url field so that it has the actual named URL (e.g. https://someserver.somedomain.local/sites/baconrules ), so I'm not sure if the raw IP address thought still applies. We don't have any custom designed 404 error pages, just defaults.

aLTeReGo

I would suggest downloading something like wget for windows or Firefox/Chrome, installing it from the Orion server and attempting to access that URL as you have it written above. It sounds like there may be some transparent passthrough authentication happening with Internet Explorer. That or there's a proxy server settings required to access that URL. There is the very rare chance that you're being redirected or otherwise rejected based on the user agent string being passed. You could try updating the User Agent string within the HTTPS Component Monitor to mimic Firefox. E.G. "Mozilla/5.0 (Windows NT 6.3; rv:36.0) Gecko/20100101 Firefox/36.0".

ttl

Thanks for your help aLTeReGo‌ !