James Callaghan

Tag: SysAdmin

  • Configuring a host name with a SSL Certificates in IIS 7

    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 hostname 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 customer’s wildcard SSL certificate was issued without an * in the name, therefore, the hostname 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 hostname 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 hostname field should now be editable where you should then enter the hostname for your SharePoint site.
  • Force a full syncronisation – Windows Azure Active Directory Sync

    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 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 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.

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

  • 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 few 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 check-in systems and data centres. 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.