Implementing SSL with PowerShell for existing SharePoint 2013 farm – Part 3

In part 1 I described the environment I am working in and what will be affected by the SSL implementation. In part 2 I described the deployment of the SSL certificates. In this 3rd part of the series I will describe how to correctly change your SharePoint web applications to use SSL.

There are a lot of articles describing how to implement SSL, even for existing web applications. But not all scenario’s are valid or recommended. Let’s review some of those scenario’s.

 

1. Just edit the bindings in IIS

You have installed your SSL certificates on each web server and then you open IIS Manager on each web server. You go to the IIS site for your web application, edit the bindings and add the HTTPS binding.

Well. SharePoint isn’t aware of anything manually edited in IIS, so to make these changes effective you’ll also need to edit the Alternate Access Mappings.

Although this scenario does seem to work, it won’t hold. And therefor I would not recommend it. Why? Because SharePoint keeps the web application configuration in the config database (the original SPWebApplication object). It was initially set up for HTTP and not HTTPS/SSL. So when the service Microsoft SharePoint Foundation Web Application service gets restarted, you will see that all your manually edited settings are gone and the web application is back to HTTP.

 

2. Delete and re-create the web application

You could delete the HTTP configured web application and re-create it with HTTPS and SSL configured. This scenario does indeed store the correct settings the configuration database and there will be an IIS site with HTTPS bindings. All you have to do then, is select you SSL certificate for the HTTPS binding.

Sounds promising, doesn’t it? Well, you’ll regret it. Why? Because you probably have custom solutions, perhaps even “legacy” 2010 solutions. As soon as you delete your web application, all your associations for the installed solutions are deleted as well. They will never return when your re-create your web application, so you have to deploy them again to the new web application. And you know, you have crappy coded solutions. Crappy solutions that have crappy features to be activated again and all hell breaks loose.

 

So, where does it leave us now? The answer is to un-extend and re-extend your web application.

3. Un-extend and re-extend the web application

This works very well when you have already extended your web application to another zone, like Intranet. Just un-extend your zone and re-extend it with the new HTTPS and SSL options configured. Even your solutions are okay and you do not have to re-deploy them.

However (and this is an important however!), if you have just one zone (and that will be the Default one of course), you must NOT un-extend and re-extend that one zone. Then you will be in the same dissociated-crappy-solutions-situation. All hell just broke loose again. In this case you’ll need to temporarily extend your web application to a dummy URL on another zone, like Intranet. Then you can un-extend and re-extend the Default zone. And you’re good to go. (don’t forget the un-extend the intranet zone with the dummy site)

The Script

Let’s do some un-extending and extending web applications with PowerShell. Again, I use some XML configuration:

<WebApplications>
        <WebApplication name="MySites" currentUrl="http://mysites.company.com" newDefaultUrl="https://mysites.company.com" hasHostHeader="TRUE" />
        <WebApplication name="Hosting Web App" currentUrl="http://hostingwebapp.company.com" newDefaultUrl="https://hostingwebapp.company.com" hasHostHeader="FALSE" />
</WebApplications>

The script reads this configuration and performs the following code:

$config.WebApplications.WebApplication | % {

    $currentURL = $_.currentUrl
    $newDefaultURL = $_.newDefaultUrl
    [bool]$hasHostHeader = [System.Convert]::ToBoolean($_.hasHostHeader)
    
    $webapplicationName = $_.name

    Write-Host
    Write-Host -f Cyan Changing $webapplicationName to SSL
    
    $wa = Get-SPWebApplication $webapplicationName
    if( $wa )
    {
        # Create dummy extension
        Write-Host - Creating Dummy web application extension... -NoNewline
        $wa | New-SPWebApplicationExtension -Name "DummyIntranetSite" -Zone "Intranet" -URL "http://dummy-intranet.company.com"
        Write-Host -f Green " [Done]"

        # Unextend the default web application
        Write-Host - Removing Default web application... -NoNewline
        $wa | Remove-SPWebApplication -Zone "Default" -DeleteIISSite -Confirm:$false
        Write-Host -f Green " [Done]"

        # Create new default HTTPS web application
        Write-Host - Creating SSL Default web application extension... -NoNewline
        if( $hasHostHeader )
        {
            $hostHeader = $newDefaultURL.Replace("https://", "")
            $wa | New-SPWebApplicationExtension -Name $webapplicationName -HostHeader $hostHeader -Zone "Default" -URL $newDefaultURL -SecureSocketsLayer -Port 443
        }
        else
        {
            $wa | New-SPWebApplicationExtension -Name $webapplicationName -Zone "Default" -URL $newDefaultURL -SecureSocketsLayer -Port 443
        }
        Write-Host -f Green " [Done]"
        
        # Remove Dummy extension
        Write-Host - Removing Dummy web application extension... -NoNewline
        $wa | Remove-SPWebApplication -Zone "Intranet" -DeleteIISSite -Confirm:$false
        Write-Host -f Green " [Done]"
        
    }
    else
    {
        Write-Host -f Red " [Not Found]"
    }
    
}

The key cmdlets in this script are New-SPWebApplicationExtension and Remove-SPWebApplication. For more information, click the links and read the TechNet articles.

[Update: Worth mentioning is the Confirm switch for the Remove-SPWebApplication cmdlet. It is documented incorrectly on TechNet. To suppress the confirmation question you’ll have to provide the $false value, as used in my script.]

Running the script

You could add the XML configuration to the existing configuration file from previous post, but it is okay to create another one.

Before running the script, the web applications in Central Administration look like this:

Let’s kick it off:

After the script has run, the web applications in Central Administration look like this:

Summary

Changing your SharePoint web applications has to be done carefully. You need to consider your options, especially when custom solutions are in place. Editing IIS manually, does not update SharePoint objects in the configuration database.

In the next part I will focus on editing the IIS bindings to set the SSL certificate.

Tags: CertificatesIISPowerShellSharePointSSL