Office Sharepoint Search Scopes and SSL
To come straight to the point, I had problems using the contextual search scopes from Office SharePoint Search (also known as This Site : <SiteName> and This List : <List Name> scopes). Problems being that I didn't get any searchresults. I did get search results however when I used the All Sites scope.
So far I didn't mention that the site was using SSL and during the creation we choose that the site was using SSL. This implies that the site can only be accessed using the SSL port (and host-header). This is the point where (our) shit hits the fan.. So I created an alternate access mapping to make the site accessible from within our network and created a searchscope using this address. When I used this scope I received the searchresults I wanted. Unfortunatly the "This Site" scope didn't work and not wanting to create a custom searchscope for each individual site I tracked the problem down to the SSL thingie.
So I performed the following steps to fix this problem :
- Deleted the webapplication leaving only the content databases
- Created a new webapplication using the local address as default zone
- Added an alternate access mapping in the extranet zone of the newly made webapplication
- Added the SSL certificate in IIS and modified the hostheader.
- IISRESET
And voila.. my OTB contextual searchscopes were working! :)
UPDATE 5 SEPT 2007
Below is a more detailed overview of the steps to make it all work by Glenn :
- Obtain a wildcard SSL Certificate for your external domain name and install it. E.g. if your external domain name is MyBusiness.com then you would need an SSL certificate for *.MyBusiness.com
- Install Sharepoint 3.0 in side by side configuration with the existing version 2.0 as per the document at this link: http://www.microsoft.com/downloads/details.aspx?FamilyID=0DAAFC81-EFFF-4F5B-A28A-8265F1E99F5B&displaylang=en
- Configure sharepoint/SBS to enable the search feature on the farm (this may require a little googling as I can't remember where I found this).
- Create a CNAME DNS entry on your DNS server, in 'Forward Lookup Zones/MyInternalDomain' for what will be your internal access url; e.g. http://sharepoint would require a CNAME entry of 'sharepoint', pointing to the appropriate Host record.
- Create a CNAME DNS entry on your DNS Server, in 'Forward Lookup Zones/MyDomain.com' for what will be your public access url; e.g. https://share.mydomain.com would require a CNAME entry of 'share' pointing to the same Host record as in step 4. Don't forget to add a similar record to your ISP's DNS listings if you use an ISP for your public DNS record hosting.
- Create your Web Application in Central Administration using your internal url; e.g. http://sharepoint on a NEW virtual server (i.e. DON'T use the existing 'Default' instance) but DO put it on port 80 (if thats what you want) as long as you enter 'sharepoint' (or whatever you used in step 4.) as the Host Header. Don't forget to run 'iisreset /noforce' on your web server after creating the Web Application in Central Administration. Do use NTLM authentication - I haven't tried Kerberos and don't know how this would be done.
- Extend your Web Application to a NEW virtual server, also running on port 80. Once again - do use NTLM authentication. Enter the Host Header as per your chosen external url in step 5. E.g. share.mydomain.com Do choose 'Use SSL'. Yes, I know I am skipping some other settings here, but they are relatively self explanatory.
- Once this is created, switch to IIS and you will see that your new external website is there, but it will likely be stopped with some nasty error message. Don't worry, just bring up the website's properties and make sure that SSL the port is set to 443, also check that the Host header value is set properly (it is blank on our machine when I do this - but it should be whatever you entered in step 7.).
- Also, while in the website's properties, assign the wildcard certificate that you obtained in step 1. to this website. The website will still be stopped at this stage. Thats OK, we aren't ready to start it yet.
- Set the SSL host header on your external website by doing the following:
- Start a command prompt and change directories to C:\Inetpub\AdminScripts
- enter the following 'cscript adsutil.vbs set w3svc/websiteID/SecureBindings :443:HostHeaderName' where websiteID is the Id number of the website as listed in IIS and HostHeaderName is the same host header that you entered into the properties for the website in IIS in step 8. and 7.
- While your in the command prompt hit F3 to repeat what you just ran and change it so that you have 'cscript adsutil.vbs set w3svc/websiteID/AccessSSL TRUE' and run it. Note that this is optional - all it does is force people to connect using https.
- You should be able to right click the website now and select 'Start' and it should do so without error.
- In Central Administration, under Operations>Alternate Access Mappings make sure that you have two mappings present:
Default Zone:
Internal URL: http://sharepoint
Public URL: http://sharepointInternet Zone:
Internal URL: https://share.MyBusiness.com
Public URL: https://share.MyBusiness.com- Browse to one of your site collections from a machine on your network using your internal URL E.g. http://sharepoint/site1/home. You should be able to access it without any log in prompts and search etc. should be working.
- Hop on an external machine and browse to your external URL. E.g. https://share.MyBusiness.com/site1/home. You should be presented with a log in dialogue. Enter your credentials and you should be in. Check that the site is secured with SSL (the little padlock should be showing) and that the search feature is working etc.
thats it (well - thats all I know so far...).
Please note that I haven't tested this much beyond this so there may be things that I have wrong yet which I haven't found. No doubt if anyone else reads this they will spot something.
If anyone has any more information about this problem just let me know!
21 comments:
There is likely one problem here. IIS 6 does not support host headers over SSL. Furthermore you are not permitted to amend IIS from outside Sharepoint. If you do you are outside support. Not a risk I'd like to take.
Actually IIS 6 does support host headers over SSL if you bind the certificate to the instance of virtual server through a command line visual basic script.
The drawback of this is that you have to use the host headers you need to have a wildcard certificate - somewhat of a problem and quite expensive at that.
This was made possible through Windows Server 2003 SP1's update to IIS 6.
Now the right and better way of doing things is to have a separate IP address for each web application that you're running, in which case you can bind the individual SSL certificates to each of the web application instances.
What the anonymous author also failed to mention is that if you should for some reset your configuration database it will reload your original configuration, without certificates into IIS which is bullocks and will make your day quite shirty.
@ Anonymous, well apparently (as -du- is pointing out) II6 does support SSL hostheaders. Or it does so by giving the virtual server a hostname and check the option for SSL and adding a proper certificate.
So I am not a IIS guru but this pretty much makes sense to me. The search is giving me back the proper links (with https).
Robin -
Your post comes at an interesting time in that we seem to be having issues with the "This Site" scope as well. Basically, both the "This Site" and "This List" scopes are not returning results with those results clearly showing up in the main search scope, with the more specialized scopes returning exactly nothing.
I'm a little disturbed to think about the idea of entirely disconnecting a database without being absolutely sure that our problem matches exactly.
Hi Peter,
are you also using SSL on your webapplication?
Robin
Hmmm, I have the same problem with a Sharepoint web application, and yes it is set up to run under SSL. Previous incarnations of the site were not set up using SSL and the search features worked fine.
I configured the site to use SSL by deleting all the exisiting virtual servers in sharepoint and then extending a new virtual server, configured to run with SSL.
The actual procedure to get it working in IIS is similar to what -du- outlines; I.e. use a wildcard certificate and bind the host headers to the sites using the command line utility adsutil.vbs.
After setting this up, the search feature bombs with "The search request was unable to connect to the Search Service." I haven't looked into this too deeply yet, but it smells like a problem related to what you describe.
In regard to Anonymous's post about it not being recommended to configure SSL in IIS outside of sharepoint, well check out this microsoft link on that very subject: http://www.microsoft.com/resources/documentation/wss/2/all/adminguide/en-us/stse10.mspx?mfr=true
It states fairly clearly that you 'can' just change it in IIS.
Hi Glenn,
is your https url accessible by the crawl account? In my situation the external url is used in the SSL host header and the crawling account cannot access the external url because of firewall restrictions. Therefore I have to use the internal name of the server as the default zone.
Hi Robin,
no, I don't have that problem. Our physical setup is all behind one firewall. I did take alook at the Alternate Access Mappings but couldn't see anything wrong with the setup.
Taking a closer look yesterday, I found that my search service was 'out of comission'. After some reasearch I found out how to use the stsadm.exe tool to reconnect the content database and start the search service again with a full crawl here:-
http://arbyzee.wordpress.com/2007/04/25/wss-30-search-problem/
But, this still didn't fix things entirely. The search feature went from throwing an error to simply stating that there were no results - for any searches that I tried... which was an improvement!
after some more looking I found this:-
http://support.microsoft.com/kb/927919
I think this is where I'm at now and suspect that I will need to create a new web application with SSL enabled to host my ssl site collections as the current web application was created as http. I'll try this out perhaps this weekend.
Our environment is also placed behind the firewall ;)
Did you try the following :
1. Create a webapplication, attach the contentdb using the hostname on port 80 and NOT using SSL.
2. Extend the webapplication to a new virtual server that is using SSL
3. Configure SSP to crawl the first webapplication
4. Map all the urls together in the AAM
Hi Robin,
whew! what a load of work! (this has been my first exposure to sharepoint and it has been very time consuming).
OK, I tried a LOT of differnt things but in the end failed to get the SSL website up on its own with the search feature functioning correctly, so have resorted to something similar to what you have just described in your last post:-
Created a new Web Application using HTTP, exposed to our internal network on it's own unique url (http://sharepoint), including 'sharepoint' as the host header for the site. This is after adding an Alias(CNAME) record for 'sharepoint' in our DNS Forward Lookup zone because I can't simply use the server name in the URL as there are other websites that cannot be moved, on the same port. Therefore host headers must be used to differentiate between them.
Extended the Web application to a new virtual server over https as e.g. https://AnExternalUrl and set up IIS to handle it (assigning certificates, adding secure bindings etc).
Configured Alternate Access Mappings with the following:
Default Zone:
Internal Url: http://sharepoint
Public Url: http://sharepoint
Internet Zone:
Internal URL: https://AnExternalUrl
Public URL: https://AnExternalUrl
OK, so far this works alright when looking at either of these urls from inside the network. Search is working too.
BUT, there appears to be something missing in my AAM table - when an External user (someone on the internet accessing the site via https://AnExternalUrl/TheirSite) does a search, they get an error message that ends with "If the URL should be serving existing content, the system administrator may need to add a new request url mapping to the intended application"
This indicates that I need to add another Acess Mapping to allow the results to return correctly. Basically, the search feature is still working, but the results can't be returned to the user.
I read through this article:-
http://technet2.microsoft.com/Office/en-us/library/0d2efc06-afb4-40fe-9ac9-f973ac3d985f1033.mspx?mfr=true
many times because it covers exactly this scenario but with one difference - the article keeps talking about using reverse proxy servers to terminate the incoming SSL requests and then creating a corresponding AAM to map the https URL to a third intermediate http URL that is associated with the application. But - we don't have a proxy server! The sharepoint site is hosted on our one and only SBS 2003 server and it's a do-it-all machine. I would have thought that the basic mappings that we currently have would be sufficient, but that doesn't appear to be the case. Do we have to have' a proxy server on our network for this to work? Or, can I fudge this in DNS by creating another CNAME entry just so that I can create a second Internet zone mapping that associates the external https URL with the internal application.
Apololgies for the long post - and I understand if you don't have a reply for this.
Ahhhhh!
the releif is truly vast!
I got it working - The two AAM entries ARE sufficient - it's just that on my 'Internet' zone url I had left the port number on the end of the url's, and even though it was port 80, it still caused the search results page error AND caused errors on some lists in some of the sites.
So, basically, the procedure for setting up a secure, public/private SSL Sharepoint 3.0 Web application on port 80 with SSL on 443, on 'Small Business Server 2003 Premium' box with SQL Server 2000 Standard installed (but not ISA) goes like this:
1. Obtain a wildcard SSL Certificate for your external domain name and install it. E.g. if your external domain name is MyBusiness.com then you would need an SSL certificate for *.MyBusiness.com
2. Install Sharepoint 3.0 in side by side configuration with the existing version 2.0 as per the document at this link: http://www.microsoft.com/downloads/details.aspx?FamilyID=0DAAFC81-EFFF-4F5B-A28A-8265F1E99F5B&displaylang=en
3. Configure sharepoint/SBS to enable the search feature on the farm (this may require a little googling as I can't remember where I found this).
4. Create a CNAME DNS entry on your DNS server, in 'Forward Lookup Zones/MyInternalDomain' for what will be your internal access url; e.g. http://sharepoint would require a CNAME entry of 'sharepoint', pointing to the appropriate Host record.
5. Create a CNAME DNS entry on your DNS Server, in 'Forward Lookup Zones/MyDomain.com' for what will be your public access url; e.g. https://share.mydomain.com would require a CNAME entry of 'share' pointing to the same Host record as in step 4. Don't forget to add a similar record to your ISP's DNS listings if you use an ISP for your public DNS record hosting.
6. Create your Web Application in Central Administration using your internal url; e.g. http://sharepoint on a NEW virtual server (i.e. DON'T use the existing 'Default' instance) but DO put it on port 80 (if thats what you want) as long as you enter 'sharepoint' (or whatever you used in step 4.) as the Host Header. Don't forget to run 'iisreset /noforce' on your web server after creating the Web Application in Central Administration. Do use NTLM authentication - I haven't tried Kerberos and don't know how this would be done.
7. Extend your Web Application to a NEW virtual server, also running on port 80. Once again - do use NTLM authentication. Enter the Host Header as per your chosen external url in step 5. E.g. share.mydomain.com
Do choose 'Use SSL'. Yes, I know I am skipping some other settings here, but they are relatively self explanatory.
8. Once this is created, switch to IIS and you will see that your new external website is there, but it will likely be stopped with some nasty error message. Don't worry, just bring up the website's properties and make sure that SSL the port is set to 443, also check that the Host header value is set properly (it is blank on our machine when I do this - but it should be whatever you entered in step 7.).
9. Also, while in the website's properties, assign the wildcard certificate that you obtained in step 1. to this website. The website will still be stopped at this stage. Thats OK, we aren't ready to start it yet.
10. Set the SSL host header on your external website by doing the following:
a. Start a command prompt and change directories to C:\Inetpub\AdminScripts
b. enter the following 'cscript adsutil.vbs set w3svc/websiteID/SecureBindings :443:HostHeaderName' where websiteID is the Id number of the website as listed in IIS and HostHeaderName is the same host header that you entered into the properties for the website in IIS in step 8. and 7.
11. While your in the command prompt hit F3 to repeat what you just ran and change it so that you have 'cscript adsutil.vbs set w3svc/websiteID/AccessSSL TRUE' and run it. Note that this is optional - all it does is force people to connect using https.
12. You should be able to right click the website now and select 'Start' and it should do so without error.
13. In Central Administration, under Operations>Alternate Access Mappings make sure that you have two mappings present:
Default Zone:
Internal URL: http://sharepoint
Public URL: http://sharepoint
Internet Zone:
Internal URL: https://share.MyBusiness.com
Public URL: https://share.MyBusiness.com
Please make sure that you don't have ':80' at the end of your URL's as I did as this will cause grief! It should be a clean URL.
13. Create a site collection or two in Central Administration under your web application
14. Browse to one of your site collections from a machine on your network using your internal URL E.g. http://sharepoint/site1/home. You should be able to access it without any log in prompts and search etc. should be working.
15. Hop on an external machine and browse to your external URL. E.g. https://share.MyBusiness.com/site1/home. You should be presented with a log in dialogue. Enter your credentials and you should be in. Check that the site is secured with SSL (the little padlock should be showing) and that the search feature is working etc.
thats it (well - thats all I know so far...).
Please note that I haven't tested this much beyond this so there may be things that I have wrong yet which I haven't found. No doubt if anyone else reads this they will spot something.
Sorry for the massive post Robin, I just thought that I should share this hard won experience to save someone else from having to spend the same amount of time that it took me to assemble every one of these steps from nothing.
Hi Glenn,
no problem! I'm happy that you are willing to post all your problem solving here! Hopes this helps everyone in the future ;)
You mind if I copy/paste your last comment in the post itself?
No problem Robin, you can use it however you want.
I'll be rewriting that procedure with some more detail and tidying it up to possibly use in part 1 of a series of sharepoint presentations to the local .NET user group.
Thanks for the use of your post and best of luck.
Thank you! Thank you! Thank you!
After days of troubleshooting, this post finally helped me solve my problems!
Thanks! Always nice to hear that I could help someone :)
OK. It's work, but I have a problem with orders in docs library. If you click in https://sharep.com/docs/ to order you will get the new fenster with question: do you want to go from https to http://standard zone ?
an idee?
The procedures for this section are performed at the server level. To perform these procedures, you must be a member of the Administrators group for each server on which you want to perform them.
I can tell what you mean. Great thoughts and they have really opened my own eyes to the opportunity of what you’re declaring. You definitely have got a lot of responses on this article!
Thank you Robin and Glenn for taking the time to write up this post. It has been a great help, which is probably down to the great level of detail included. The way in which it is written step-by-step is perfect for following the instructions.
Hi Peter!
Nice Blog, but we want to you especial thanks for below enlisted steps within blog as they helped us to solve SSL issue.
-> Deleted the webapplication leaving only the content databases
-> Created a new webapplication using the local address as default zone
-> Added an alternate access mapping in the extranet zone of the newly made webapplication
-> Added the SSL certificate in IIS and modified the hostheader.
-> IISRESET
Such an outstanding share! Thanks for spending the time to talk about this topic here on your blog.
Post a Comment