a.k.a. - Living on the Edge. Just remember, there’s a reason it’s called the bleeding edge . . . Here’s your warning: In this post I am going to explain configuration changes I made to my own internal production environment to get http://companyweb to point to a new WSS v3 site. This configuration is not supported by Microsoft or myself. If you decide to try to replicate these settings in your environment, you are doing so at your own risk.
OK, let’s recap. We’ve talked about the benefits of Sharepoint v3? Check. We’ve talked about planning what we’re going to move, how we’re going to move it, and what we’re going to have to clean up after the move? Check. We’ve talked about prepping our environment so that WSS v3 search works? Check. We’ve talked about installing WSS v3 and accessing it via a common name? Check. Chad has warned everyone that just because he’s crazy enough to implement a non-supported configuration doesn’t me he’s recommending it or supporting it? Check.
First, it’s important to discuss why having http://companyweb point to your new WSS v3 web site is not supported. As we all know, there is a decent amount of integration between the SBS wizards and our WSS v2 companyweb site. Additionally, that integration is heavily dependent on DNS resolution to companyweb. However, the key issue is with the integrated SBS setup. If you find yourself in a position where you need to re-run SBS Integrated Setup and touch the Intranet piece, it’s going to try to access your WSS v3 site, and with the differences between WSS v2 and v3 – well, let’s just say it’s not going to be pretty and will break more than it fixes.
It’s important to note that I installed and configured my new WSS v3 site using the process I outlined in my previous post, and migrated all of my content over to my new WSS v3 site prior to making the changes mentioned below.
So when I was looking at deploying WSS v3 and deciding if I wanted to tackle having http://companyweb resolve to a new v3 site, I decided that if I were to do this, I needed to leave myself a backdoor so that I could point companyweb to the original companyweb site in the event that I found myself needing to re-run SBS Integrated Setup and touch various intranet components. Additionally, I wanted to be able to access the original companyweb site if need be after migrating everyone to a new v3 site.
Here’s what I came up with. First – I needed to configure the original companyweb so that I could access it using another name. For my environment, I chose to use http://companywebold
1) I started with adding the entry to our internal DNS so that companyebold resolved to the internal IP of our SBS.
2) I flushed the DNS cache and verified that my SBS responded when I pinged companywebold
3) I opened Sharepoint Central Administration (v2) and clicked the link to Configure Virtual Server Settings
4) I clicked to select the companyweb virtual server, then clicked to Remove Windows SharePoint Services from virtual server.
5) I verified that the Remove without deleting content databases option was selected and clicked OK.
6) I opened IIS Manager, and opened the Properties page for the companyweb web site.
7) I added two new host headers to the companyweb site – companywebold and companywebold.domain.local Both host headers were bound to port 80 on the internal IP of the SBS (not all unassigned). DO NOT REMOVE the companyweb host headers at this point!
8) I closed the Properties pages of the companyweb site and returned to Sharepoint Central Administration (v2).
9) I clicked on the Extend or Upgrade virtual server link, then clicked to extend the companyweb virtual server.
10) I clicked the option to Extend and Map to Another virtual server.
11) I verified that the companyweb site was being mapped, and that the option to Use an existing application pool was selected.
12) I verified that the DefaultAppPool was selected, then clicked OK.
At this point, I verified that both http://companyweb and http://companywebold resolve to the original WSS v2 companyweb. The key piece to understand with SharePoint, is that the SharePoint configuration database has to know about the host headers that you’re using to access your Sharepoint sites. You can’t just add another host header to a site in IIS and expect to get to your SharePoint site using the new host header. That is why I removed WSS from the companyweb site, then added the new host header values (companywebold), then re-extended WSS to the companyweb site. By doing so, the SharePoint configuration database picks up the host headers already defined for that site, and we are now able to get to the original companyweb site using either of our two host headers. It is important that WSS v2 configuration database knows about both host headers.
Now, I was ready to make the switch so that my http://companyweb pointed to the new WSS v3 site – both internally AND externally The key point to remember is that with WSS v3 we can have multiple web sites pointing to the same SharePoint application. The first thing we need to do is change the Properties of the existing companyweb site.
1) I opened IIS Manager, expanded [servername], expanded [web sites], right-clicked on companyweb and selected Properties.
2) On the General tab, I removed 444 from the SSL port, then clicked the Advanced button to edit the host headers.
3) I removed two host headers: companyweb and companyweb.domain.local then clicked OK to close the Advanced window, then clicked OK to close the companyweb properties page.
4) At this point I closed IIS Manager.
This leaves the original companyweb in-tact, however right now I can only access it via the alternate http://companywebold URL I created earlier. Now I was able configure http://companyweb to pull up the new WSS v3 web application:
1) I opened SharePoint 3.0 Central Administration, and on the Application Management tab, I clicked on Create or extend Web application.
2) I then clicked on Extend an existing web application
3) Under Web application, I clicked Change web application then selected my WSS v3 web app (Sharepoint – 80)
4) Under the IIS Web Site section, I selected the option to Create a new IIS web site, and entered companyweb new for the description
5) I entered 80 for the port, and companyweb for the host header, then clicked OK.
At this point, I opened Internet Explorer and verified that http://companyweb opened the new WSS v3 site – yay! But I still wanted to enable SSL so that I could access the Sharepoint v3 application externally:
1) I opened SharePoint 3.0 Central Administration and on the Application Management tab, I clicked on Create or extend Web application.
2) I then clicked on Extend an existing web application
3) Under Web application, I clicked Change web application then selected my WSS v3 web app
4) Under the IIS Web Site section, I selected the option to Create a new IIS web site, and entered companyweb – SSL for the description
5) I entered 444 for the port, and my public FQDN for the host header (mail.mobitech.biz)
6) Under the Security Configuration section, I clicked the option to Use Secure Sockets Layer (SSL), then clicked OK.
Now that I had created a separate web site for remote access, I just needed to add my SSL cert to the site.
1) I opened IIS Manager, expanded [servername] and [web sites].
2) I right-clicked on companyweb – SSL and selected Properties.
3) On the Directory Security tab, I clicked the Server Certificate button.
4) I clicked Next to start the IIS Certificate Wizard.
5) On the next page, I clicked the option to Assign an existing certificate and clicked Next.
6) I selected my SSL certificate, then finished the wizard. (I had to check the SSL cert on my old companyweb to make sure I got the right cert)
At this point, I opened my web browser on a remote system and verified that I could access the new WSS v3 site via the public URL (https://mail.mobitech.biz:444) . . . and then just to test, I also logged in to RWW and verified that I could access the new WSS v3 site by clicking on the Use my company’s internal web site link . . . YAY!
Now – I have my new WSS v3 site accessible remotely via the normal companyweb URLs both internally & externally. I can get to my original WSS v2 site via http://companywebold, and I can also get to the new WSS v3 site via http://intranet as well.
The key here is that http://companyweb is registered in both the WSS v2 and v3 configuration databases. So – if I find myself in a position where I need to recover my SBS server or some task that requires running a wizard that touches the Intranet portion, before I do so, all I have to do is stop two of my new WSS v3 sites (companyweb new and companyweb – SSL), then update the original companyweb site to include the original host headers (companyweb and companyweb.domain.local), and add 444 back in as the SSL port. As a result, the SBS wizards will touch the original companyweb site (that they can work with), instead of the new WSS v3 site that the wizards can’t work with. And if necessary, users can still access the new site internally via http://intranet. When the wizards are done, I can reverse the process and be back to using the new WSS v3 site as my companyweb.
So far, the upgrade to WSS v3 has been well worth the effort – every day we’re finding new functionality and my users are liking it more and more.
Having said that, I want to reiterate that the configuration outlined in this post IS NOT SUPPORTED. If you opt to duplicate this configuration in your environment, you are doing so at your own risk and realize that you will not get support from either Microsoft or myself
Regardless, if you opt to deploy WSS v3 in your SBS environment either in a supported configuration (the first 4 parts of this series), or in an unsupported configuration as outlined here, some of your SBS integration is not going to work with WSS v3. The big piece you’ll notice eventually is the Add User Wizard – when you add new users to your SBS, they will not be automatically added to your WSS v3 site – you will have to manually add your new users to the new site.