Exchange 2016 EAC displays a blank page upon login after updating SSL certificates

Problem

You’ve recently updated the certificates for your Exchange 2016 servers:

You notice that the ECP / EAC page no longer load properly upon successfully logging in after reassigning the new certificate, deleting the old certificate and restarting the server:

Reviewing the event logs show the following error constantly logged on the Exchange server(s):

Log Name: System

Source: HttpEvent

Event ID: 15021

Level: Error

An error occurred while using SSL configuration for endpoint 0.0.0.0:444. The error status code is contained within the returned data.

Solution

The error above could be caused by the port 444 SSL certificate binding continuing to reference the old deleted certificate.  To determine whether this is the case, start the command prompt and execute the following command:

netsh http show sslcert

The command should list the SSL certificate bindings for the server similar to the following:

C:\>netsh http show sslcert

SSL Certificate bindings:

-------------------------

IP:port : 0.0.0.0:443

Certificate Hash : d0da0b35cf91c55b91a10755c0b4b11dfb1d3ff9

Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}

Certificate Store Name : My

Verify Client Certificate Revocation : Enabled

Verify Revocation Using Cached Client Certificate Only : Disabled

Usage Check : Enabled

Revocation Freshness Time : 0

URL Retrieval Timeout : 0

Ctl Identifier : (null)

Ctl Store Name : (null)

DS Mapper Usage : Disabled

Negotiate Client Certificate : Disabled

Reject Connections : Disabled

IP:port : 0.0.0.0:444

Certificate Hash : c71d3d6f9673dcec57d8c76602562d58bd69d9b9

Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}

Certificate Store Name : My

Verify Client Certificate Revocation : Enabled

Verify Revocation Using Cached Client Certificate Only : Disabled

Usage Check : Enabled

Revocation Freshness Time : 0

URL Retrieval Timeout : 0

Ctl Identifier : (null)

Ctl Store Name : (null)

DS Mapper Usage : Disabled

Negotiate Client Certificate : Disabled

Reject Connections : Disabled

IP:port : 0.0.0.0:8172

Certificate Hash : 403a6eac00d494c03288a1df779aeae7a131886f

Application ID : {00000000-0000-0000-0000-000000000000}

Certificate Store Name : MY

Verify Client Certificate Revocation : Enabled

Verify Revocation Using Cached Client Certificate Only : Disabled

Usage Check : Enabled

Revocation Freshness Time : 0

URL Retrieval Timeout : 0

Ctl Identifier : (null)

Ctl Store Name : (null)

DS Mapper Usage : Disabled

Negotiate Client Certificate : Disabled

Reject Connections : Disabled

IP:port : 127.0.0.1:443

Certificate Hash : d0da0b35cf91c55b91a10755c0b4b11dfb1d3ff9

Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}

Certificate Store Name : My

Verify Client Certificate Revocation : Enabled

Verify Revocation Using Cached Client Certificate Only : Disabled

Usage Check : Enabled

Revocation Freshness Time : 0

URL Retrieval Timeout : 0

Ctl Identifier : (null)

Ctl Store Name : (null)

DS Mapper Usage : Disabled

Negotiate Client Certificate : Disabled

Reject Connections : Disabled

C:\>

The output we’re interested in are as follows:

IP:port : 0.0.0.0:444

Certificate Hash : c71d3d6f9673dcec57d8c76602562d58bd69d9b9

-------------------------------------------------------------------------------------------------------------------

Also make a note of the following information which we will need later:

Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}

-------------------------------------------------------------------------------------------------------------------

Confirm that the IP:port : 0.0.0.0:444 is indeed referencing the old certificate by reviewing the thumbprint of the old deleted certificate with the Certificate Hash:

Note that the thumbprint in the screenshot above matches the certificate hash generated above.  Once confirmed that the IP:port : 0.0.0.0:444 is indeed referencing the old certificate, proceed to delete the binding by executing the following command:

netsh http delete sslcert ipport=0.0.0.0:444

Execute netsh http show sslcert to confirm that the binding has been deleted:

Proceed with creating the binding with the new certificate by executing a command that references the Application ID that we made a note of earlier:

Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}

… and obtaining the thumbprint of the new certificate that we’ll be using:

Use the information above to execute the following command:

netsh http add sslcert ipport=0.0.0.0:444 certhash=d0da0b35cf91c55b91a10755c0b4b11dfb1d3ff9 appid="{4dc3e181-e14b-4a21-b022-59fc669b0914}"

The errors written in the event logs should now be corrected.  Proceed to repeat these steps on all of the affected Exchange servers.

Attempting to expand a Windows 2012 R2 ReFS drive fails with the error message: “There is not enough space available on the disk(s) to complete this operation.”

Problem

You have a Windows 2012 R2 server virtual machine with multiple disks that is formatted with the ReFS file system and you have just one of the disks at the hypervisor level then proceed to extend it within Disk Management:

Attempting to complete the Extend Volume Wizard throws the following error:

Disk Management

There is not enough space available on the disk(s) to complete this operation.

The expansion of the disk fails.  You attempt to use diskpart but receive the same error:

Virtual Disk Service error:

There is not enough usable space for this operation.

You attempt to expand the disk by 1MB but the results are the same:

Solution

I’m not sure whether this is a bug in the earlier versions of Windows 2012 R2 and ReFS but expanding the disk by 1000MB completes successfully:

10000MB also works:

Sames goes for 100000MB:

With 52.60GB of Unallocated space left, leaving the Select the amount of space in MB as the default (maximum) completes successfully:

Configuring a Citrix NetScaler Responder Policy and Action to redirect traffic to another URL based on source IP

I’ve been asked several times in the past about how to configure a NetScaler virtual load balancing server to redirect traffic to another URL based on the incoming source IP address so this post serves to demonstrate the process.

Step #1 – Create the Responder Action

Begin by navigating to AppExpert > Responder > Actions and click the Add button to create the responder action to execute when a policy is met:

In the Create Responder Action window, fill in the following fields as required:

Name: A name that represents the redirect – Redirect_USA_Subnets_Action

Type: Redirect

Expression: Enter the URL you would like to redirect requests to with quotes – “https://www.someURL.com”

Response Status Code: 302

Step #2 – Create the Responder Policy

Navigate to AppExpert > Responder > Policies and click the Add button to create the responder police that will execute the action that was previously created when a requirement is met:

In the Create Responder Policy window, fill in the following fields as required:

Name: A name that represents the redirect – Redirect_USA_Subnets_Action

Action: The previous action created – Redirect_USA_Subnets_Action

Expression: Enter the required IP address or subnet with the expressions:

CLIENT.IP.SRC.EQ(x.x.x.x) || CLIENT.IP.SRC.IN_SUBNET(x.x.x.0/24)

An example of would be:

CLIENT.IP.SRC.EQ(10.43.3.136) || CLIENT.IP.SRC.IN_SUBNET(162.221.215.0/24) || CLIENT.IP.SRC.IN_SUBNET(195.130.217.0/24) || CLIENT.IP.SRC.IN_SUBNET(91.220.42.0/24) || CLIENT.IP.SRC.IN_SUBNET(185.58.84.0/22)

Step #3 – Assign Responder Policy to Virtual Server

Navigate to Traffic Management > Load Balancing > Virtual Servers and edit the properties of the virtual server you would like to redirect traffic based on incoming source IP address:

If there are already policies assigned, scroll down to the Policies section and click on the + button or if there are no policies applied then click on the Policies button listed on the right side of the page to add a new policy:

Configure the following and click Continue:

Choose Policy: Responder

Choose Type: Request

In the Choose Type options window, click on Click to select under Select Policy:

Select the Responder Policy that was created earlier:

Click on the Bind button to bind the policy to the virtual server:

Save the configuration by clicking on the Done button:

The NetScaler will now redirect any traffic coming in for the specified IPs to the alternate URL.

Non domain joined Windows 10 client unable to connect to wireless network with 802.1X authentication

Problem

You have a Cisco Wireless Controller setup to use a Microsoft Network Policy (RADIUS) server to authenticate wireless clients via 802.1X and while Android devices and all Windows clients that are joined to the domain have no issues connecting to the network, non-domain joined Windows 10 workstations are unable to. 

Attempting to join the network with a non-domain joined Windows 10 device shows the following Audit Failure log written in the Security logs of the NPS server:

Log Name: Security

Source: Microsoft Windows security

Event ID: 6273

Level: Information

Network Policy Server denied access to a user.

Contact the Network Policy Server administrator for more information.

User:
     Security ID:            CONTOSO\tluk
     Account Name:            CONTOSO\tluk
     Account Domain:            CONTOSO
     Fully Qualified Account Name:    CONTOSO\tluk

Client Machine:
     Security ID:            NULL SID
     Account Name:            -
     Fully Qualified Account Name:    -
     OS-Version:            -
     Called Station Identifier:        00-17-df-a8-e0-50:CONTOSO_Corp
     Calling Station Identifier:        60-57-18-a7-ea-18

NAS:
     NAS IPv4 Address:        192.168.220.254
     NAS IPv6 Address:        -
     NAS Identifier:            Cisco_7d:fe:e4
     NAS Port-Type:            Wireless - IEEE 802.11
     NAS Port:            13

RADIUS Client:
     Client Friendly Name:        CONTOSO Test
     Client IP Address:            192.168.220.254

Authentication Details:
     Connection Request Policy Name:    CONTOSO
     Network Policy Name:        Secure Wireless Connections 3
     Authentication Provider:        Windows
     Authentication Server:        CONTOSODC01.Contoso.com
     Authentication Type:        PEAP
     EAP Type:            -
     Account Session Identifier:        35393361643862372F36303A35373A31383A61373A65613A31382F3739383139
     Logging Results:            Accounting information was written to the local log file.
     Reason Code:            16
     Reason:                Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.

The error presented in Windows 10 during the login is shown in the following screenshots:

Verifying and connecting

Can’t connect to this network

Solution

One of the reasons why this error would be be presented to non domain joined Windows 10 client is if the NPS / RADIUS server is configured with a certificate issued by an internal Microsoft CA that is not trusted by the Windows 10 device since it is not joined to the domain.  The way around this is to either install the issuing Root CA certificate on the Windows 10 device or configure the SSID network manually and do validate the certificate.  The following outlines these steps:

Begin by opening the Network and Sharing Center then click on Set up a new connection or network:

Select Manually connect to a wireless network:

Fill in the appropriate configuration:

Once the new SSID network has been created, proceed by clicking on Change connection settings:

Click on the Security tab:

Click on the Settings button:

Uncheck the Verify the server’s identity by validating the certificate option:

Configure the above usually does the trick so that the following prompt is displayed the next time an attempt is made to connect:

However, if you continue to encounter the same error then proceed by clicking on the Advanced settings button:

Enable the Specify authentication mode: option:

Change the configuration to User authentication then click on Save credentials:

Enter the appropriate credentials:

The SSID should now no longer prompt for credentials and will automatically connect to the SSID network with the saved credentials.