Alan's sysadmin Blog

Working smarter not harder

Archive for the ‘Windows Servers’ Category

Script: Checking for Expired Certificates in Exchange

Posted by Alan McBurney on August 27, 2014

I was working with a customer that had unintentionally let their Exchange certificates expire.

This resulted in a bit of a headache for the team as users were now getting certificate warnings and mobility services were down until the certificate was replaced.

I decided to put together a script that will check and warn about expired or soon to expire certificates.
The script gets the certificates which have services bound to them on all Exchange 2010 client access and hub transport servers.
It checks for certificates that have expired or that will expire within the next 60 days and optionally emails the report and creates a schedule task.
An email will only be generated if expired\expiring certificates have been detected

Detects expired certificates on Exchange 2010 Client Access & Hub Transport servers
Version 1.0, August 27th, 2014
This script will get the certificates which have services bound to them on all Exchange 2010
client access and hub transport servers.
It checks the expiration for any certificates that are due to expire within 60 days and optionally
emails the report and creates a schedule task
An email will only be generated if expired\expiring certificates have been detected
Parameters, checks and scheduled tasks stolen from Steve Goodman's Exchange Environmental Reports script
To Do list: Enable Autnetication for SMTP
Support for Exchange 2007 & 2013
Send Mail after completion. Set to $True to enable. If enabled, -MailFrom, -MailTo, -MailServer are mandatory
Email address to send from. Passed directly to Send-MailMessage as -From
Email address to send to. Passed directly to Send-MailMessage as -To
SMTP Mail server to attempt to send through. Passed directly to Send-MailMessage as -SmtpServer
Attempt to schedule the command just executed weekly. Specify the username here, schtasks (under the hood) will ask for a password later.
[parameter(Position=1,Mandatory=$false,ValueFromPipeline=$false,HelpMessage='Send Mail ($True/$False)')][bool]$SendMail=$false,
[parameter(Position=2,Mandatory=$false,ValueFromPipeline=$false,HelpMessage='Mail From')][string]$MailFrom,
[parameter(Position=3,Mandatory=$false,ValueFromPipeline=$false,HelpMessage='Mail To')]$MailTo,
[parameter(Position=4,Mandatory=$false,ValueFromPipeline=$false,HelpMessage='Mail Server')][string]$MailServer,
[parameter(Position=5,Mandatory=$false,ValueFromPipeline=$false,HelpMessage='Schedule as user')][string]$ScheduleAs
#Check Powershell Version
if ((Get-Host).Version.Major -eq 1)
  throw "Powershell Version 1 not supported";
#Check Exchange Management Shell, attempt to load
if (!(Get-Command Get-ExchangeServer -ErrorAction SilentlyContinue))
  if (Test-Path "C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1")
    .'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'
    Connect-ExchangeServer -auto
  } elseif (Test-Path "C:\Program Files\Microsoft\Exchange Server\bin\Exchange.ps1") {
    Add-PSSnapIn Microsoft.Exchange.Management.PowerShell.Admin
    .'C:\Program Files\Microsoft\Exchange Server\bin\Exchange.ps1'
    } else {
    throw "Exchange Management Shell cannot be loaded"
# Check if -SendMail parameter set and if so check -MailFrom, -MailTo and -MailServer are set
if ($SendMail)
  if (!$MailFrom -or !$MailTo -or !$MailServer)
    throw "If -SendMail specified, you must also specify -MailFrom, -MailTo and -MailServer"
$HTMLReport = $Dir + "\ExpiredCerts.html"
$CASServers = Get-ExchangeServer | Where-Object {$_.AdminDisplayVersion -match "Version 14" -and $_.ServerRole -match [regex] 'Hub|Client'}
$Certs = Foreach ($srv in $CASServers) {Get-ExchangeCertificate -Server $srv| Where-Object {$_.NotAfter -le (Get-Date).AddDays(60) -and $_.Services -ne "None"} | Select @{n="Server";e={$}}, @{n="Expiry Date";e={$_.NotAfter}}, Thumbprint, Services, Issuer, Subject}
$Certs | ConvertTo-Html | Out-File $HTMLReport

if ($SendMail)
  if ($Certs.count -gt 0)
    Send-MailMessage -Attachments $HTMLReport -To $MailTo -From $MailFrom -Subject "Warning - Expired Exchange Certificates Detected" -Body "Expired or soon to be expired certificates have been detected on Exchange Servers. Please see attached file for certificates affected" -SmtpServer $MailServer
if ($ScheduleAs)
  if ($SendMail)
    $params+=' -SendMail:$true'
    $params+=" -MailFrom:$MailFrom -MailTo:$MailTo -MailServer:$MailServer"
  $task = "powershell -c \""pushd $dir; $($myinvocation.mycommand.definition) $params\"""
  schtasks /Create /RU $ScheduleAs /RP /SC WEEKLY /ST 22:00 /TN ExpiredCerts /TR $task

Posted in Certificates, Exchange 2010, PowerShell, Windows 2008 R2, Windows Server 2012, Windows Servers | Tagged: , , | Leave a Comment »

Windows Server Core 2012 R2 Remote Management

Posted by Alan McBurney on October 8, 2013

In my last blog post I added certificate services to a server core installation.

Well as it turns out after some more hands on with server core I did it the hard way as Server 2012 brings with it a new level of remote or headlesss management.

When I first got this up and running I was pretty blown away by the experience.

What I’m going to walk though in this blog post are the configuration steps that are required in order to get remote management of the server core installation up and running via a dedicated management server.

In this lab I have 2 Windows 2012 R2 Servers

  • 1 Server Core
  • 1 GUI

I’m not going to include the steps that are required in order to get the VM’s installed.
I’m going to pick this up from the point that the installation is complete.

Once Server Core has been installed and you have created your admin password and logged in. The first thing to do is fire up SConfig in order to set:

  • Server Name
  • IP Address\Subnet Mask
  • DNS Servers
  • Remote Desktop


Running sconfig from the command prompt brings up the screen as below and allows basic server setup options to be configured


Select Option 2 and enter a computer name for the server. This requires a reboot once complete

Once the server comes backup and your logged back in run sconfig again and this time choose option 8 in order to set the IP Adresss, Subnet mask, Default Gateway and DNS Servers

Once complete that’s about all that needs done on the server core installation.

We can now switch over to the Management Server.

Configure this server up in the normal way, setting:

  • IP Address\Subnet Mask
  • Default Gateway
  • DNS Server
  • Server Name

Reboot the server and get logged back in.

As we are still to configure a domain we are effectively in a workgroup.
And as there is no domain there is no DNS for name resolution.

To work around these issues there are few steps that need to be taken.

  1. Add a host file entry for the DC on th emanagement server
  2. Add the would be Domain Controller to the trusted hosts file on the management server

Lets go ahead and take care of the easy task of assining the Domain Controller ServerName to the management servers host file

Open Notepad as administrator and then open:


Add an entry for the domain controller similar to that below


Close the file and test name resolution via ping.
We won’t get a ping response due to the Firewall on Quarkalbs-DC01 but thats not the point. The point here is to test name resolution.


Now that name resolution is functional for QuarkLabs-DC01 the next step is to add the server to the trusted hosts file on the management server

Open PowerShell and run the following command

Set-Item WSMAN:\localhost\Client\TrustedHosts quarklabs-dc01 -force


All items are now set and we can go back to the Server Manager Dashboard on the management server and add our remote server

From Server Manager choose Add other server to manage


Select DNS and add the remote server


Click OK and wait for a moment while the remote server is added.

The server count should have increased from the dashboard


Open All Servers and be sure that the recently added server is now present


The server can now be managed via the management server like any normal server.

That wraps it up for this post. In the next post I’ll configure and promote the server to be a domain controller all via the management server.


Posted in Active Directory, Server 2012 R2, Server Core, Windows Servers | Tagged: , , , | Leave a Comment »

Creating OpenSSL Certificates for vSphere & vCenter

Posted by Alan McBurney on October 28, 2011

I have been meaning to write this blog post for a while but never quite managed to find the time until now.

As part of a project that I have been working on, I had a need to replace the default certificates that get installed during the installation of vCenter and vSphere 4.1 with OpenSSL certificates.

This guide is based on vSphere & vCenter 4.1 although it should also work for vSphere 5

The process will be broken into a number of steps

  1. Installation of OpenSSL & creating the working directory structure
  2. Creating a Root CA
  3. Creating the CSRs (Certificate Signing Requests) for vSphere and vCenter
  4. Signing the CSRs using the Root CA
  5. Assign certificates to vCenter & vSphere
  6. Deploying the OpenSSL RootCA via GPO

I want to make this process as easy as possible and as such I’ll be using the default values that are already predefined in the openssl.cfg file

So lets get started with replacing vSphere certificates.

Installing OpenSSL & creating the directory structure

Download OpenSSL for Windows x64 from


Accept the license agreement and use the defaults when installing.

OpenSSL has now been installed to C:\OpenSSL

The next thing that needs to be done is to create the working directory structure. The directory structure will be used when signing the certificates using the RootCA.

Use the following commands

mkdir C:\openssl\bin\demoCA\newcerts
mkdir C:\OpenSSL\bin\demoCA\private
Copy C:\OpenSSL\bin\PEM\demoCA\serial C:\OpenSSL\bin\demoCA\
copy con C:\OpenSSL\bin\index.txt

(after issuing the above command use CTRL-Z then enter to finish the command. This will create a blank document called index.txt)


Creating the Root CA

We are now ready to create the RootCA.
Open a command prompt at C:\OpenSSL\bin and issue the below command

openssl req -new -x509 -extensions v3_ca -keyout rootca.key -out rootca.crt -days 3650 -config openssl.cfg

The first thing that you will be asked for is a “Enter PEM pass phrase:”

This is a pass phrase of your own choosing (Should be a strong pass phrase) and will be used again when signing the certificates for vSphere & vCenter

Complete the remainder of the fields that you are asked information about.
The relevant fields have been highlighted in the below graphic.


Once the command has complete you will find 2 new files named rootca.crt and rootca.key within C:\OpenSSL\bin


Creating the CSR’s

Next we need to create the CSRs for the vsphere and vcenter certificates

Again open a command prompt from C:\OpenSSL\bin and issue the following commands

openssl req -new -nodes -out vsphere.csr -keyout vsphere.key -config openssl.cfg

openssl req -new -nodes -out vcenter.csr -keyout vcenter.key -config openssl.cfg

The above commands will create the CSRs, each CSR will consist of 2 files, the csr file and the key file.

At the end of the request you will be prompted to enter ‘extra attributes’. Leave these 2 options blank.

The yellow highlight below are the options that you need to fill in, the green are the optional setting that are to be left blank.


We now have the private key and the CSR for both vsphere and vcenter within C:\OpenSSL\bin.


Signing CSR

The next step is issue certificates based on the the CSRs using the RootCA.

Remember back to that start when we created the directory structure? Well this is where it comes into use.

Issue the below commands at a command prompt from C:\OpenSSL\bin.
The first thing that you will be asked for is the pass phrase from the rootca we entered when creating the initial rootca files

openssl ca -cert rootca.crt -keyfile rootca.key -out vsphere.crt -config openssl.cfg -infiles vsphere.csr

openssl ca -cert rootca.crt -keyfile rootca.key -out vcenter.crt -config openssl.cfg -infiles vcenter.csr


Going back to C:\OpenSSL\bin we see 2 new files, vsphere.crt & vcenter.crt.
Double clicking these files will show that they have been signed by the Root CA.



Creating PFX

A PFX file is required for vcenter, a PFX file is the amalgamation of the certificate and its associated private key

The following command will create the PFX for vcenter

openssl pkcs12 –export -in vcenter.crt -inkey vcenter.key -name vcenter  -passout pass:testpassword -out vcenter.pfx


Again looking in C:\OpenSSL\bin you will see the newly created PFX file.

Replacing Certificates on vCenter

We now need to replace the default certificate that are installed on vcenter with are newly created certs.
The SSL certificates for vCenter are located at

C:\Users\All Users\VMware\VMware VirtualCenter\SSL

Opening this folder you will find 3 files

  • rui.crt
  • rui.key
  • rui.pfx

Copy these certificates to a safe location as you will need to replace these if anything has gone wrong with the newly created certificates.

Copy across the vcenter.crt, vcenter,key and vcenter.pfx files created earlier and rename these to reflect the original rui files

On the vCenter Server, restart the service VMware VirtualCenter Management Webservices

Installing Root CA on Windows

Now that we have out certificate signed by our Root CA we need to ensure that the Root CA is trusted by servers and clients that will be connecting to both vsphere & vcenter.

The easiest way to do is this is via a GPO

Create a new GPO and give it a meaning full name


Navigate to
Computer Configuration – Policies – Windows Settings – Security Settings – Public Key Policies – Trusted Root Certificate Authority
and choose Import


Import the rootCA.crt certificate


You can now close Group Policy.

Uploading Certificates to vSphere

The part went really smoothly for me due to a PowerShell script by Martijn Baecke that’s available on the VMware communities website.

See the post at for full instructions on uploading the certs to vSphere.

Testing certificates from Clients

Finally we have everything in place and we are now ready to test the certificates for trust from out clients.

First thing to do is to issue a group policy update from the client. This will install the Root CA into the clients Trusted Root Certificate Authorities container


Once the update has been issues we can check that the certificate has been installed.

  1. Click Start, click Run, type mmc, and then click OK.
  2. In the File menu, click Add/Remove Snap-in.
  3. In the Add/Remove Snap-in box, click Add.
  4. In the Available Standalone Snap-ins list, click Certificates, and then click Add.
  5. Click Computer Account, and then click Next.
  6. Click the Local computer (the computer this console is running on) option, and then click Finish.
  7. Click Close, and then click OK.

Expand Certificates – Trusted Root Certificate Authorities – Certificates and you should now see the RootCA installed


Finally open Internet Explorer and point the browser to your vCenter URL. If all has gone correctly the page will display without the certifcate security warning.


My next post will cover using a Windows CA to sign the CSR

Posted in Certificates, OpenSSL, VMware, vSphere, Windows Servers | Tagged: , , , , , | 2 Comments »

Exchange 2010 NLB and remote Subnets

Posted by Alan McBurney on June 14, 2011

While configuring an Exchange 2010 NLB I had no choice but to publish direct access to the Exchange servers from the Internet instead of using my preferred method of directing all traffic through a TMG\ISA server.

Consequently access to the published NLB wouldn’t resolve properly from external locations. All traffic on the local LAN was fine although traffic originating from outside the local subnet was dropped and no response was received by clients.

The servers were configured with dual NIC’s with a dedicated NIC on each host being assigned for NLB traffic. As the NLB NIC only has an IP and Subnet entered I suspected that the lack of default gateway to be the issue.

I changed the Firewall rules to point to an individual servers Public NIC then everything was fine although this bypassed the NLB and as such wasnt really of much use to me.

As of Windows 2008 R2 all networking uses “Strong Host Model” whereby traffic can only exit from the interface that it entered on.

A resolution for this was to allow forwarding of traffic from the NLB NIC to the public NIC via the following command.

netsh int ipv4 set int “[Name of NLB NIC]” forwarding=enabled

Posted in Exchange 2010, Windows 2008 R2, Windows Servers | Tagged: , , | Leave a Comment »

RSAT for Windows 7 SP1 now available

Posted by Alan McBurney on April 11, 2011

RSAT for Windows 7 SP1 is now available for download from here

Posted in Windows 2008 R2, Windows 7, Windows Servers | Leave a Comment »

Migrate DHCP from Windows 2003 to Windows 2008 R2

Posted by Alan McBurney on November 3, 2010

Migrating a DHCP scope from Windows 2003 to Windows 2008\R2 is a very simple task

On the source DHCP server open a command prompt and type
netsh dhcp server export C:\dhcpdatabase.dat all

On the target 2008 box run
netsh dhcp server import C:\dhcpdatabase.dat all

How easy is that 🙂

Posted in Windows Servers | Tagged: | Leave a Comment »

Change default gateway on clients with static IP’s using PowerShell

Posted by Alan McBurney on July 29, 2010

Recently when working on a project I need to change the gateway on a bunch of clients that had static IPs.

This PowerShell Script did the job

——-Begin Script———-

function Set-Gateway  {

#Get NICS via WMI

$NICs = Get-WmiObject -Class Win32_NetworkAdapterConfiguration -ComputerName $_ -Filter “IPEnabled=TRUE”

foreach($NIC in $NICs) {$Gateway = “”




function Get-FileName {

$computer = Read-Host “Please specify the location of the file containing the computer names”

return $computer


$f = Get-FileName

Get-Content $f | foreach {Set-Gateway}

——-End Script———-

Posted in PowerShell, Windows Servers | Tagged: | 2 Comments »