If you use the Response.End, Response.Redirect, or Server.Transfer method, a ThreadAbortException exception occurs. You can use a try-catch statement to catch this exception (of type ThreadAbortException) but having an empty catch block after my Response.End was kinda ugly.
So, rather than doing Response.End, we can call HttpContext.Current.ApplicationInstance.CompleteRequest it will causes ASP.NET to bypass all events and filtering in the HTTP pipeline chain of execution and directly execute the EndRequest event…
We never stop learning !
As a SharePoint developer, I don't have to play too much with all the administrative tasks when I'm outside of my VMs as our IT service is responsible for ensuring the proper health status of the production facing site. So stuff like Alternate Access Mappings, Bindings and Server Name Mappings were quite new for me.
So, here is a small reminder of the steps that I did to have my site collection accessible through a fake public url (eg : http://www.company.com
) instead of http://sharepoint-dev-01
and ensure the search results are returned properly using the right url.
- Edit the host file on the server, make 127.0.0.1 point to http://www.company.com
- Edit the IIS binding (inetmgr -> point the relevant website entry -> bindings and add a new one with www.company.com as the host name on port 80 (all ip addresses unassigned)
- Add an Internet Alternate Access Mapping for your computer name (in my example : http://sharepoint-dev-01)
- Fire up your browser and access your website through the new url (you can launch Fiddler and have a look at all requests / responses to ensure everything is properly mapped
The most important part is now what to do (or what to avoid) to ensure that your search is working as you would expect it to do. The general idea is to stick with the server name as the host name instead of already playing with the AAM name. The alternate access mapping created previously will take care of all url rewritting so do not do like me and don't mess your content source or scopes with the fully qualified domain name !
- Ensure your content source is pointing to the server name instead of the fully qualify domain name (eg : http://sharepoint-dev-01)
- Ensure all relevant scopes are using the server name instead of the fully qualify domain name on your folder rules (eg Folder = http://sharepoint-dev-01/be-en/products/)
- Make a full crawl
- Enjoy your search results being served with the fully qualified domain name when your search page is accessed through http://www.company.com
It must be possible to adapt url of the search results through the "server name mappings" configuration screen but I've never been able to make it work as expected. I guess the main culprit was the fact that I mixed fqdn and server name at various place which confused the search service.
I'll never stop learning 🙂
Ensure that your account has enough permissions to do the operation or that you’re list as a site collection administrator for the site collection that you are restoring.
Your site collection might also be locked by a previously failed restore job : stsadm -o setsitelock -url “http://yoururl” -lock none
(and don’t worry, even when the backup is on the same disk as the sql server, it’s awfully slow to restore… Don’t kill the process and get a long coffee break !)