Configuring a host name with a SSL Certificates in IIS 7

A customer asked me if I could help troubleshoot their SharePoint environment – they had extended a web application and configured it to use Forms Based Authentication (FBA) with SSL however they were getting errors when accessing the new site.

I started troubleshooting the configuration across all the servers in their SharePoint 2013 farm. I stepped through the configuration for the web application in Central Administration – reviewing the authentication provider settings and alternate access mappings. I then reviewed the web.config and made sure that the FBA settings were present and correct along with the IIS website bindings. This is when I noticed that there was no host name against the https/443 binding –  the option to add one was also disabled.

IIS binding - host name disabled
IIS binding – host name disabled

After a little research I found an article from ArmgaSys.  It turns out that my customers wildcard SSL certificate was issued without a * in the name therefore the host name cannot be specified once the SSL certificate is selected. I followed the steps in this article from and the customer was able to access their SharePoint site without any errors this time.

IIS binding - host name editable
IIS binding – host name editable

A summary of these instructions are included below: –

  1. To resolve this and make the host name field editable launch Microsoft Management Console (MMC) and open the Certificates snap-in.
  2. Locate the wildcard certificate, right click on it and select properties.
  3. If the Friend Name property doesn’t start with a * then add one and apply any changes you make.
  4. Now go back to IIS and select the SSL certificate in the bindings of the SharePoint website with the issue.
  5. The host name field should now be editable where you should then enter the host name for your SharePoint site.

Force a full syncronisation – Windows Azure Active Directory Sync

When configuring Windows Azure Active Directory Sync (or DirSync as it was previously known) it’s useful to be able to run various synchronisation tests. The default synchronisation schedule is 3 hours so unless you want to wait you will need to force a full synchronisation using PowerShell.

Start-OnlineCoexistenceSync cmdlet
Start-OnlineCoexistenceSync cmdlet

To do this you need to load the Windows Azure Active Directory Sync PowerShell module and run a cmdlet. Start by navigating to “C:\Program Files\Windows Azure Active Directory Sync” in PowerShell and then run “.\DirSyncConfigShell.psc1” from this directory. This will launch a new PowerShell console with the Windows Azure Active Directory Sync PowerShell module loaded (Add-PSSnapin Coexistence-Configuration). Then to force a full synchronisation you need to run the Start-OnlineCoexistenceSync cmdlet.

[code lang=”PowerShell”]
Start-OnlineCoexistenceSync -fullsync
[/code]

You can verify that a synchronisation has occurred by reviewing the application event log on the server running DirSync – there should be several items in the log such as “Directory Synchronization, Event ID – 114, Export cycle completed”. There is also a status of the Active Directory Synchronisation on the “Users and Groups” page in the Office 365 admin portal. There are also two other ways to see the status of synchronisation jobs which I will go into in more detail in a later post but these include using the Forefront Identity Manager (FIM) client and Fiddler a web debugging proxy.

Office 365 Active Directory Sync status
Office 365 Active Directory Sync status

You can create a shortcut to “C:\Program Files\Windows Azure Active Directory Sync\DirSyncConfigShell.psc1” on the desktop for ease of administration. I however take this one step further and create a shortcut to perform a synchronisation as well. Create a shortcut with the following target below.

[code]%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -PSConsoleFile "%PROGRAMFILES%\Windows Azure Active Directory Sync\DirSyncConfigShell.psc1" -Command "& Start-OnlineCoexistenceSync -fullsync[/code]

Identifying your SQL server version using SQL Server Management Studio

This one’s quick. There are a couple of ways to find out your SQL server version. Firstly the version is listed within the Object Explorer in the Microsoft SQL Server Management Studio. The second option which provides more detailed information is to run the following query.

select @@version

The version information is returned in the query results section at the bottom. Both examples of obtaining the SQL server version are shown in the image below.

Identifying Microsoft SQL Server version using Microsoft SQL Server Management Studio
Identifying Microsoft SQL Server version using Microsoft SQL Server Management Studio

Remote Desktop Connection Manager

When I started my new job a fews weeks ago I decided I was going to  introduce some new tools and utilities to help myself and my colleagues be more productive. The first one I brought to their attention was Remote Desktop Connection Manager (RDCMan) from Microsoft.

Remote Desktop Connection Manager (RDCMan)
Remote Desktop Connection Manager (RDCMan)

I’ve known about this tool for almost a year now but it always surprises me how few administrators out there don’t know about this tool. It’s a must have for any System Administrator using mstsc.exe or Remote Desktop to manage more than one server or computer!

RDCMan manages multiple remote desktop connections. It is useful for managing server labs where you need regular access to each machine such as automated checkin systems and data centers. It is similar to the built-in MMC Remote Desktops snap-in, but more flexible.

Remote Desktop Connect Manager can be downloaded directly from the Microsoft Download Centre.

Please also say a big thank you to Julian Burger the developer at Microsoft who wrote this awesome tool and David Zazzo for working to get it released! You can read about how David discovered Julian’s RDCMan tool within an internal Microsoft repository  and worked to get it licensed for external distribution on the Exchange TechNet Blog.