Exchange 2013 Blank ECP/OWA Screen, Showing Event ID 15021 HttpEvent System Log

I hit this one today after switching out an expired UCC certificate on two Exchange 2013 servers in a DAG.  Both the ECP/OWA screens after login just went to a white page and never load.  The servers were both showing hundreds of ID 15021 in the system event log that says "An error occurred while using SSL configuration for endpoint 0.0.0.0:444.  The error status code is contained within the returned data."

Here's the steps to fix it:

1. Open a command prompt.

2. Enter netsh http show sslcert  This will show the certs on the server.  Copy and paste this information into notepad.  Copy this info "IP: port: 127.0.0.1:443".  Note that this information contains the certificate hash and the application ID.  This is the information needed.

3.  Run this command:  netsh http delete sslcert ipport=0.0.0.0:444

4.  Next run this command:  netsh http add sslcert ipport=0.0.0.0:444 certhash=123443211234321123 appid="{ab34k32abkr3252jsnekgljw}"  Make sure to include the quotes around the appid.

5. Finally restart the server.

This is all it takes to correct the issue.  Apparently this glitch is specific to Exchange 2013 as a web based ECP doesn't exist in the earlier versions.

Simple fix to a real inconvenience.

Good luck!

Certificate Not Showing After Importing Into Exchange 2013

I ran into this one today with two servers in a DAG.  This is caused by the certificate you're using not having the private key.  Here's how I fixed it:

Go to the 1st server -> Start -> Run -> MMC -> File -> Add/Remove Snap Ins -> Certificates -> Computer Certificates -> Local Computer

Browse to the personal certificate store, right click on the correct certificate, select All Tasks, and then Export.  Make sure here you choose "Export Private Key" and assign a password.  Click Next and then name the file and where you want to save it.  The file will have a .pfx extension.

From there on the 1st server inside ECP you can go to Servers -> Certificates -> Choose the server you want and then import the certificate.

Once this process is done just assign the services to the certificate (SMTP, POP, etc) and then restart the server if possible.  If not some say you can do an IISRESET from the command prompt and then you'll be good.

Good luck!

Unable to scan IIS status - The IIS Common Files... Server 2012/2012 R2

I ran into this issue today while trying to run the Microsoft BPA (Best Practices Analyzer) 2.3 on a Windows Server 2012 R2 box with IIS 8.5 installed.  Below is the full text of the error:

"Unable to scan IIS status - The IIS Common Files are not installed on the local computer.  Refer to the system requirements list under the Microsoft Business Security Analyzer Help."

Here's the short fix:

Go back into Roles and under Web Server (IIS) and install IIS 6 Management Compatibility --> IIS 6 Metabase Compatibility.

Apparently from what I find this is a Windows Server 2003 item that hasn't been updated in the current server platform documentation on the MBSA to reflect the need for this additional set of files.

The longer explanation is that in order for the MBSA to be able to scan IIS properly it needs to have IIS 6 Management Compatibility turned on and more specifically the IIS 6 Metabase Compatibility.

I hope this one helps as it took me quite a bit of research to run this issue down.

Good luck.

Manually Applying Updates to Trend IMSVA

Whenever Trend issues an update for these virtual machines the GUI interface isn't always able to apply the patches to the VM.

 This is where a bit of time and patience have to come in to get them updated. Below is how I get it done quickly without much headache to keep these VMs current.

1. Download the patch or hot fix to your computer (Ex: imsva_90_en_criticalpatch1560.zip).

2. Extract the file.  You'll see a couple of files extracted such as readme_en.txt and imsva_90_en_criticalpatch1560.tar.gz listed.

3.  Use a program to upload the files to the IMSVA virtual machine.  I choose to use WinSCP.  Upload the file to the /tmp folder.

4.  Login to the IMSVA using root privilege using Putty or another program via SSH.  NOTE: You have to use SCP on WinSCP as the protocol and the root account for the VM.  If not it won't connect with the standard "admin" and password the web browser login uses.

5.  Run the following commands:

   # tar -zxvf /tmp/imsva_90_en_criticalpatch15160.tar.gz -C /tmp
   # cd /tmp/imsva_90_en_criticalpatch15160
   # ./imssinst

6.  Allow the installation to run and when the install completes you'll see something similar to this:

   Installation is complete and related services are started.

Just a note when you are done you can delete both the *.tar.gz file and the folder it created off of the IMSVA virtual machine to save space.

Login to the web interface and verify with the "About" option the new build version of your IMSVA.

I have found that not every hot fix or patch raises the build level in the web interface but if you try to apply it again to the IMSVA you'll find out it has already been installed.

For those of you that are not great in the Linux/Unix world I hope these instructions help you keep your critical infrastructure system patched and up to date.

It's Friday afternoon now so I hope you all have a great weekend.

Managing FSMO roles with PowerShell in Server 2012 R2

Powershell was released some time ago but it feels to me like it was just yesterday.  Part of that is because as time moves on Microsoft is adding more and more features.  With Windows Server 2012 R2 now in full effect and quite stable, it's clear PowerShell is taking over as the primary Windows scripting language of choice.

I am a firm believer that everything in Windows Server 2012 R2 that can be done in the GUI can also be done in PowerShell.  Case in point, I just upgraded one of our network Domain Controllers from Windows Server 2012 to Windows Server 2012 R2.

Since this server was a DC the first thing I needed to do before the upgrade was to ensure the server was not running any of the five FSMO roles on our network.  To do this I ran the following command in PS on the server.

netdom query FSMO

This will return which DC or DCs on your network contain the FSMO roles.  Since the server I was upgrading had none then I had none to move before the upgrade.  Once the upgrade had completed I now wanted to make sure the newest DC on the network had the roles while others were being upgraded.

To transfer all five roles you can simply run this command in PS:

Move-ADDirectoryServerOperationMasterRole -Identity “Target_DC_name” –OperationMasterRole 0,1,2,3,4

For reference the command line syntax replaces the role number for the full name of the FSMO role.

• PDC Emulator = 0
• RID Master = 1
• Infrastructure Master = 2
• Schema Master = 3
• Domain Naming Master = 4

If you find yourself in a situation where the DC you want to transfer roles from is offline and cannot be brought back then you'll need to seize the roles.  Here's the command for that:

Move-ADDirectoryServerOperationMasterRole -Identity “Target_DC_name” –OperationMasterRole 0,1,2,3,4 - Force

 Finally to transfer or seize just one role you would run the exact same command and just use the number of the role you need to move.  These commands work on Server 2008 R2 and up or Windows 7 with the RSAT (Remote Server Administration Tools) installed.

I don't find myself moving FSMO roles often but when I need to this is much easier than using the GUI.  A great reference on PowerShell is Learn Windows PowerShell 3 in a Month of Lunches.  It's a great read and has tons of great PowerShell information.

Good luck.