Solved

501 Not Implemented The requested method is not implemented by this server.

Posted on 2009-05-04
28
3,246 Views
Last Modified: 2013-12-14
I am receiving the following error when trying to access our SharePoint 3 site while connected to an external network via IE or FF using https://intranet.domain.com

501 Not Implemented.  The requested method is not implemented by this server.

We are hosting the site internally with IIS 6 on a win2k3 R2 server.

SharePoint works fine internally with the URL above, we recently implemented SSL and it is working fine with a self signed cert for testing.  External access has never worked, before SSL was implemented the page would timeout and a 401 would be returned to the browser.  Now that SSL is implemented we are prompted to accept the Cert, then we receive the 501.

Any suggestions would be greatly appreciated!
0
Comment
Question by:joefreedom
  • 17
  • 11
28 Comments
 
LVL 8

Author Comment

by:joefreedom
Comment Utility
*before SSL was implemented we would receive 404's not 401's my bad...
0
 
LVL 22

Expert Comment

by:cj_1969
Comment Utility
If you are not getting prompted for credentials when connecting to SharePoint and are using authentication and not just allowing guest access to everything then you are going to have a problem with external access as any machine that is not in the same domain as the server is not going to be passing valid user credentials to authenticate the user account.

Try granting guess access and see if this allows people to at least browse from external.
Another though ... if you REQUIRE SSL for the entire site then you can enable basic authentication which would allow external users to use the logon credentials of their machine to authenticate against the machine ... they would have to be logged in with domain accounts for this to work though.
0
 
LVL 8

Author Comment

by:joefreedom
Comment Utility
Ok, the machines are configured with domain credentials and logins, if a domain configured PC is physically away from the domain, would it still send its domain credentials when trying to access the domain externally?  (my gut is yes?)

I will try granting guest access as you've suggested and report back results.  I will then try testing with basic authentication for domain accounts.

Thanks for your help, I won't be able to get to this for a day or two (i'm out sick) so please check back!
0
 
LVL 22

Expert Comment

by:cj_1969
Comment Utility
In order for SharePoint to authenticate domain users the users have to be able to connect to the domain controller in order to authenticate their Kerberos token first.  If they can not/do not do this then the Kerberos token that is passed to the SharePoint server for authentication will not be valid when passed to the domain controller for authentication ... so ... yes, it passes the credentials but the credentials will not be valid in this case.

Basic authentication will pass the user ID and password and then allow SharePoint to pass this to the domain controller instead of a Kerberos token.   So this should work.

The problem in this scenario is that for security reasons MS only allows the encoded ID to be passed once, from the browser to a server, it does not allow the encoded ID to then be passed from the server to another server for authentication, only Kerberos allows this.  That said, if your SPS server is also a domain controller then this should work as there is no additional "hop" in the credential passing.
0
 
LVL 8

Author Comment

by:joefreedom
Comment Utility
Thanks for the informative post, If I understand correctly Integrated Windows Authentication wasn't working because the kerberos ticket cannot be passed from browser to SharePoint to a Domain Controller (our SPS is not a DC).

I attempted enabling anonymous access as well as Basic authentication and received the same results.  The browser would prompt regarding the SSL cert and then I would receive the 501 Not Implemented error both times.

Just to note, I do have a SSL redirect script that did not work externally but does work when internally connected on our LAN.  Not sure if this is tied together, just thought it wouldn't hurt to throw out there.  Also, I had previously setup IE to automatically send passwords for Local Intranet sties, I removed this setting before testing the authentication methods.  Also after changing each authentication method I issued a iisreset -noforce on the sps box.
0
 
LVL 22

Accepted Solution

by:
cj_1969 earned 500 total points
Comment Utility
Keep the anonymous authentication off.
If you leave WIA with Basic authentication enabled and run it through SSL then you should be good.
Internally users should authenticate normally.
Externally a logon box should appear where the users can enter their credentials in the format <Domain>\<ID> and then gain access to the site.

If you enable anonymous I don't know off the topof my head how SPS will react ... it might try the credentials and then grant anonymous ... unless SPS itself is set up for authenticated users.
0
 
LVL 8

Author Comment

by:joefreedom
Comment Utility
Kept anonymous off, enabled Integrated auth with Basic auth, SSL was enabled and I still am receiving 501's?!
0
 
LVL 8

Author Comment

by:joefreedom
Comment Utility
BTW, I checked out http://support.microsoft.com/?kbid=811262&sd=RMVP which suggested completing a few browser configuration changes such as disabling HTTP 1.1 and disabling friendly http error messages.  No changes.
0
 
LVL 22

Expert Comment

by:cj_1969
Comment Utility
after disabling the friendly error messages did you get a different/better description of the error that you are receiving?
0
 
LVL 8

Author Comment

by:joefreedom
Comment Utility
Unfortunately no,

501 Not Implemented
The requested method is not implemented by this server.
0
 
LVL 22

Expert Comment

by:cj_1969
Comment Utility
This would imply that it is issuing a GET or POST command which is not enabled.  Internally it must be using the other method.

take a look at this page and see if you need to enable one or the other ... http://support.microsoft.com/kb/819267
0
 
LVL 8

Author Comment

by:joefreedom
Comment Utility
After reading through the article I went ahead and implemented the suggested alternative fix by manually adding the changes to the machine.config file.  Our server is x64 as such it has both a Framework and a Framework64 directory where machine.config resides, being new to all this I haven't the slightest where it is actually supposed to go...  Initially I added only the suggested Post and Get configuration changes to the framework folder, tested, no change, then added the same config to the framework64 folder keeping the other configuration as well, tested, resulted in no change.

I ended up adding the entire suggested fix from MS including httpsoap,postlocalhost, etc into both the framework and framework64 folder to no avail...I also wanted to mention that the only place I could find the config folder(s) were in .net v2.0.50727 directories, although  v3.0 and v3.5 directories resided there as well.  Probably no concern, just wanted it to be known...

Still receiving 501's! and now my https auto-redirect is broken (I believe from changing around IIS directory permission inheritance but I should be able to fix this later...)
Initally I added only:
 

<protocols>

    <add name="HttpPost"/>

    <add name="HttpGet"/>

</protocols>
 
 

Ultimately I added the following to both the 'framework' and the 'framework64' directories:
 

<protocols>

	<add name="HttpSoap"/>

	<add name="HttpPost"/>

	<add name="HttpGet"/> 

	<add name="HttpPostLocalhost"/>

      <!-- Documentation enables the documentation/test pages -->

	<add name="Documentation"/>

</protocols>

Open in new window

0
 
LVL 8

Author Comment

by:joefreedom
Comment Utility
Are there any software tools or logs I can utilize to help give us a better idea where this is bombing out?

Thanks alot for your help i REALLY appreciate it!
0
 
LVL 22

Expert Comment

by:cj_1969
Comment Utility
What versions of .net do you have installed on the system?
This could be a problem with the version of .Net that the application is trying to run under, especially since you mentioned v3 and v3.5
0
Do You Know the 4 Main Threat Actor Types?

Do you know the main threat actor types? Most attackers fall into one of four categories, each with their own favored tactics, techniques, and procedures.

 
LVL 8

Author Comment

by:joefreedom
Comment Utility
The 'framework' folder contains:

v1.1.4322
v2.0.50727
v3.0
v3.5

The 'framework64' folder contains:
V2.0.50727
v3.0
v3.5
0
 
LVL 22

Expert Comment

by:cj_1969
Comment Utility
If this is a 32 bit application then try selecting the v1.1 and see what happens.
0
 
LVL 8

Author Comment

by:joefreedom
Comment Utility
Sorry to be a pest, by 'selecting' do you mean adding the code below to the machine.config for v1.1?
<protocols>

	<add name="HttpSoap"/>

	<add name="HttpPost"/>

	<add name="HttpGet"/> 

	<add name="HttpPostLocalhost"/>

      <!-- Documentation enables the documentation/test pages -->

	<add name="Documentation"/>

</protocols>

Open in new window

0
 
LVL 8

Author Comment

by:joefreedom
Comment Utility
If so, and I should have clarified this earlier...the v2.0 directory is the only directory of the bunch that has the 'CONFIG' directory and subsequently the 'machine.config' file...
0
 
LVL 8

Author Comment

by:joefreedom
Comment Utility
any other ideas?
0
 
LVL 22

Expert Comment

by:cj_1969
Comment Utility
Sorry, no.
I meant in the IIS Management interface, for the site, bring up the .NET tab of the properties and then select 1.1 from the version list.
0
 
LVL 8

Author Comment

by:joefreedom
Comment Utility
Thanks for the clarification,
ASP.NET version 2.0.50727 is the only available version in the sites ASP.NET drop-down property.  This information is mirrored in IIS Web Service Extensions, ASP.NET v2.0.50727 is the only available instance of ASP.NET.

0
 
LVL 22

Expert Comment

by:cj_1969
Comment Utility
Do you still have non-SSL access enabled on your server?
This will be easier to troubleshoot if we can remove SSL from the equation.

That said ... everything works from inside, on the LAN, correct?
So, the problem is with access from the Internet.
In looking into this further ... this appears that it might be a SPS specific issue.
Check out this page ... http://technet.microsoft.com/en-us/library/cc288609.aspx
Read this section first ... "Troubleshooting alternate access mappings"

"Mistake 1: Assuming that you do not need to configure alternate access mappings unless you are deploying SharePoint in an unusual way

The most common cause of alternate access mapping-related issues is administrators not realizing that they need to configure alternate access mappings in the first place. It is certainly understandable because alternate access mappings are a new requirement in Windows SharePoint Services 3.0. Every Windows SharePoint Services 3.0 administrator needs to make sure that alternate access mappings are configured correctly, even for a simple deployment. "
0
 
LVL 8

Author Comment

by:joefreedom
Comment Utility
Yes, everything works from inside while connected to the LAN.

I had previously (before configuring SSL) setup alternate access mappings for only the URL of "http://intranet.domain.com".  Our requirement is that both the internal and public-facing URL be the same, we do not have any proxies or reverse-proxies in the mix in our environment.  I had previously extended the site (before implementing SSL) ultimately we were still unable to reach the site from an external network.

I went ahead and implemented SSL to keep the ball moving on this project, updated the alternate access mappings, then discovered that when trying to connect via an external network we were getting prompted to accept the SSL cert.  In my mind, that meant to me that our DNS settings are correct, our port-forwarding on the router is working, and the external connection is 'getting' to the IIS server.

I will disable SSL then attempt to redo AAM's and re-extend the site and see if that gets us anywhere.
0
 
LVL 8

Author Comment

by:joefreedom
Comment Utility
Upon further inspection I am finding that our router (Linksys RV042) is blocking traffic on port 80.  We have several other forwarding rules which are setup on the router and are confirmed working and fully functional.  Yet for some reason our tcp traffic on port 80 is still being blocked.  I am going to postpone this question until I can resolve the issue with our router.  I apologize for stretching this out this long...

I am new to web hosting (as you are already aware i'm sure!) because we had SSL implemented utilizing port 443, would we still have to open port 80 for secure http/sharepoint?  I am thinking that fixing the router is still not going to resolve the WSS issue, but it feels like resolving this first would help greatly in solving the wss issue...
0
 
LVL 22

Expert Comment

by:cj_1969
Comment Utility
If you are going to use port 80 for SSL then you are going to have to explicitly specifiy the port in the URL.
By default the reference http:// will use port 80 and https:// will use port 443.
If you want to use SSL on port 80 then you are going to have to specify https://<domain>:80
0
 
LVL 8

Author Comment

by:joefreedom
Comment Utility
Yes, we do not want to use port 80 for SSL I would prefer to use 443.  I had a working HTTPS redirect script before messing around with all of the site settings, I will implement this again when I have external access up and running so that users who enter http://intranet.domain.com:80 will be re-directed automatically.

I guess I asked the question wrong.  Is there any reason that traffic would still attempt to utilize port 80 if we had Sharepoint setup for SSL and the user entered https://intranet.domain.com when attempting external access?

My assumption is that SSL only uses 443, and that SSL has no prerequisites or required counter-parts that utilize another port other than 443...correct?
0
 
LVL 22

Expert Comment

by:cj_1969
Comment Utility
You can use any port(s) you want ... the browser is the one that will use the default ports if nothing is specified in the URL.  So you should be good.
Well, I guess the configuration of the web server defaults the port usage also, but you have that one under control already  ;)
0
 
LVL 8

Author Closing Comment

by:joefreedom
Comment Utility
Ultimately the issue was not a WSS configuration error, it was a router config that was malfunctioning.  After a quick router firmware update and some playing around I was able to resolve this one.  I want to thank cj_1969 for all of their help and for the informative posts, although the issue wasn't directly tied to the solutions they provided, it certainly was helpful to dig into these materials and learn more about WSS.  Thanks alot, much appreciated!
0

Featured Post

Find Ransomware Secrets With All-Source Analysis

Ransomware has become a major concern for organizations; its prevalence has grown due to past successes achieved by threat actors. While each ransomware variant is different, we’ve seen some common tactics and trends used among the authors of the malware.

Join & Write a Comment

Meet the world's only “Transparent Cloud™” from Superb Internet Corporation. Now, you can experience firsthand a cloud platform that consistently outperforms Amazon Web Services (AWS), IBM’s Softlayer, and Microsoft’s Azure when it comes to CPU and …
PRTG Network Monitor lets you monitor your bandwidth usage, so you know who is using up your bandwidth, and what they're using it for.
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.
In this tutorial you'll learn about bandwidth monitoring with flows and packet sniffing with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're interested in additional methods for monitoring bandwidt…

744 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

8 Experts available now in Live!

Get 1:1 Help Now