Microsoft Exchange and Remote Desktop Services Specialists

SEMblog

Microsoft Exchange Server and
Blackberry Enterprise Server news, views and fixes.

Exchange 2016 and Exchange 2019 Certificate Management - Post April 2022

In April 2022 Microsoft released CU 23 for Exchange 2016 and CU 12 for Exchange 2019.
While these updates, which were much delayed, were very welcome, one of the changes which wasn't announced was the removal of the GUI management tools for SSL certificates.
With Exchange being heavily web based since Exchange 2010, SSL certificates play a key part in ensuring Exchange and its clients work correctly. The GUI controls have been in place since Exchange 2010 was released.
However the commands used for Exchange 2007 don't work, so a new set of commands is required.

 

Renewing an Existing Certificate

 

For most people, you will be renewing the certificate. If you don't have any changes to make to the current certificate settings, then a simple on-liner of PowerShell will issue a new renewal request for you to use with your preferred SSL provider to get a new certificate - just enter the thumbprint of the current certificate in the sample below:

 

$txtrequest = Get-ExchangeCertificate -Thumbprint 123456789012344567890 | New-ExchangeCertificate -GenerateRequest

[System.IO.File]::WriteAllBytes('C:\SSL\renewal.req', [System.Text.Encoding]::Unicode.GetBytes($txtrequest))

 

Use get-exchangecertificate on its own to list the certificates currently installed so that you can get the thumbprint.

 

New Certificate Request

 

However if this is a new server installation, or you need to change the current certificate configuration (for example to remove autodiscover.example.com as you are in hybrid), then you will need to create a new certificate request.
Another one-liner will do this, but does need to be constructed beforehand with the relevant information:

 

$txtrequest = New-ExchangeCertificate -GenerateRequest -SubjectName "c=GB,o=Test Company,cn=mail.example.com.com" -DomainName autodiscover.example.com,mail.example.net,autodiscover.example.net

[System.IO.File]::WriteAllBytes('\\Exchange01\ssl\example.req', [System.Text.Encoding]::Unicode.GetBytes($txtrequest))

 

Picking apart that request…

The first part is the ISO two letter designation for your country, followed by your company name.
cn= is the common name, which is usually the name used for OWA/ActiveSync etc as it will appear directly on the SSL certificate. In the old wizard, it would be set to the root of the domain (example.com) but most people would change it to mail.example.com or whatever URL they were using for OWA.
The -DomainName elements are the additional names on the certificate. If you are supporting multiple domains with Exchange and need Autodiscover to work directly, rather than one of the other methods, you need to include them here.
Finally is the location to place the certificate request. Unlike the first one-liner, this requires a file share, just like it did with the wizard. As with the old wizard, I would create a dedicated share for this process on the Exchange server, and give everyone full control. That will ensure that Exchange can write to it.

 

Completing the Certificate Request

 

Whether a new or a renewal request, once you have the certificate issued by the SSL provider, you need to get it in to Exchange.

Use the same share as above…

 

Import-ExchangeCertificate -Server Exchange01 -FileData ([System.IO.File]::ReadAllBytes('\\Exchange01\ssl\response.cer'))

 

Where -server Exchange01 is the server where the certificate request was generated.

 

Exporting the Certificate for use on Other Servers

 

If you have multiple servers you will need to export the certificate to a PFX file, and then import back in again.

 

Once again, run get-exchangecertificate to find the thumbprint, then put it in the below one-liner. You will probably want to use a more secure password as well! Note that this command exports to a local folder, not a file share.

 

$bincert = Export-ExchangeCertificate -BinaryEncoded -Thumbprint 98765432109876543210 -BinaryEncoded -Password (ConvertTo-SecureString -String 'Password123' -AsPlainText -Force)

[System.IO.File]::WriteAllBytes('C:\SSL\export.pfx', $bincert.FileData)

 

To import the file, use the following command, which goes back to using a file share for the source

 

Import-ExchangeCertificate -Server Exchange02 -FileData ([System.IO.File]::ReadAllBytes('\\Exchange01\ssl\export.pfx')) -Password (ConvertTo-SecureString -String 'Password123' -AsPlainText -Force)


Enabling the Certificate

 

With the certificate now installed, the final step is to enable it.

 

enable-exchangecertificate -ThumbPrint 98765432109876543210  -Services IIS

 

Services can be IIS, SMTP, IMAP and POP - any combination of them.
If you choose to include SMTP and get a prompt to replace the default certificate, then choose no. 

Windows365 - The MSP Perspective

Microsoft have announced the much anticipated Windows 10 in the cloud - Windows365 (W365).
Having spent what seems like most of the past six months talking to various MSPs about Azure Virtual Desktop (AVD) (previously called Windows Virtual Desktop), the question is how does this new service fit in with what they have been working on, have in pilot stage etc. 

It is becoming quite clear though that this is actually really good news for MSPs, particularly those that support the smaller companies of less than 100 seats. 
While AVD is a really good product, and has a lot of good uses, for small companies it doesn't make much sense because of the complexity of setup, configuration and management. 

What immediately came to mind when comparing AVD and W365, was the comparison between a regular Windows Desktop and Remote Desktop Services (RDS).  

RDS has two main uses - providing a standard desktop to a large number of users, or providing a single application on dedicated servers. These functions I see being deployed on to AVD - it feels like the natural replacement. The classic example would be something like a call centre, where the staff are using a small number of apps, but intensely, probably not requiring the full Office suite and other applications. 
However AVD has similar challenges of setup and management complexity to RDS, making it more of a challenge to get right, with the deployment requiring constant tweaking to get the balance between performance and cost just right - as AVD is priced on consumption. 

For many companies though, a full Windows 10 desktop is the better option, because the staff member is using many different apps, needs the full Office suite and other applications. That makes W365 the better option, particularly being priced per user and not on consumption.
If the company is already invested in Office365, with email, OneDrive and SharePoint in extensive use, then having the desktop in the cloud and close to those data points will also bring performance gains. 

For MSPs, it becomes even more clear cut. 

A common challenge, particularly when it comes to taking on new clients is getting any kind of standardisation on the workstations. We all have the horror stories of the customer taking on a new member of staff and then going to the local computer shop, buying a "cheap" desktop then calling their MSP to get it to work (with Windows Home, and other garbage on it). 
The more recent issues of staff working from home and general supply issues have made the end user workstation more of a challenge. 

However if the end user workstation can be pretty much anything that runs an RDP client, then the problem almost goes away. With solutions to use a raspberry PI as thin client, the MSP can almost leave spares at each client for such events such as new member of staff or a system failing. If the Windows session exists in the cloud and their access device fails, they just move to something else and carry on. Power cut? Send them home. Self isolation? Work from home with everything you need available in the cloud PC. No computer at home, then a cheap chrome book or 

I have a client who is getting close to replacing most of their field staff laptops with what would have been a AVD deployment and Samsung mobile phones (using their DEX feature), but that will probably be switched across to W365. That provides not only a consistent experience across all staff, but also provides some degree of data protection, not only from staff stealing content, but also by loss of the device. There are also considerable cost savings - the laptop and its maintenance for a start. 

Yes there will be cases where a desktop is the better solution, but as those could be seen as niche cases the MSP will have a good opportunity to ensure those niche desktops are bought, built and managed in the way that best fits their technology stack. 

From the MSPs commercial point of view, it will also allow the MSP to provide a single price per user which includes everything - Windows, office, AV and other security software, monitoring and support, with the only additional cost being a standard router in the office and whatever is on the desk. Supporting work from home and nomad users will become easier and more cost effective. 

While the goal of a simple serverless environment for these small businesses has been possible for sometime (I did it many years ago for a small marketing company), there were trade-offs in performance and complexity. Windows365 takes away those two main issues, making that goal within reach of more companies (And their MSPs). 

Therefore I simply hope that Microsoft get the pricing right... 

Microsoft Announce Windows 365

Just as everyone was starting to look at Azure Virtual Desktop (formally Windows Virtual Desktop), Microsoft announce another new service - Windows 365.

https://www.microsoft.com/en-gb/windows-365

https://www.microsoft.com/en-us/microsoft-365/blog/2021/07/14/introducing-a-new-era-of-hybrid-personal-computing-the-windows-365-cloud-pc/ 

The big difference is that the main version that will appeal to small businesses supports AzureAD as the primary and sole domain - unlike Azure Virtual Desktop which still requires a hybrid domain with your on premise or a full server in Azure. For companies that want to go completely serverless, this is going to be the product they will go for.

For MSPs, particularly those that support the smaller companies, this could be a game changer with regards to support. Convert the current desktops in to thin clients, or even just switch to thin clients and have everyone running on the same virtual platform, whether they are at home or in the office. New member of staff joins, they can bring their own machine in, or just have something sat on the shelf waiting. You could even use a Raspberry PI for access!

Of course the main thing here is going to be pricing, which we need to wait a few more weeks for. As it is priced per user, rather than time based as with Azure Virtual Desktop, Microsoft get it priced right, it could be a winner.

July 2021 Updates for Exchange Released

Less than two weeks after the release of the cumulative updates for Exchange 2016 and Exchange 2019, we now have a critical security update for all supported versions of Exchange (so 2013 and up).
Fortunately Microsoft have released updates for both the current and previous cumulative update for Exchange 2016 and Exchange 2019, but for Exchange 2013 they are are only released for CU23.

Full details: https://techcommunity.microsoft.com/t5/exchange-team-blog/released-july-2021-exchange-server-security-updates/ba-p/2523421

However this update requires something new - after installing the update on EXCHANGE 2013 or anything but the latest CU for Exchange 2016 and Exchange 2019, you have to run a schema update. That is something new, but is required because of the issue that has been fixed. The blog posting I have linked to above has full details.

Therefore the decision is whether to deploy the cumulative update and then the the security update, or wait a bit longer on the CU. That may mean that the security update has to be applied twice if you wait.

What I would suggest is that you deploy the CU, reboot and then deploy the security update - in the same downtime window.

Monitoring Exchange Service Availability from the Internet

When it comes to monitoring Exchange, there are multiple choices, involving products that can monitor every aspect of the platform. 

However sometimes it is useful to have a quick overview of whether the Exchange services are available, and with the increasing dependence on mobile working, whether they are available from the outside world. 

Fortunately, Exchange 2013 and higher provides a built in mechanism that allows you to build a quick and easy overview of Exchange using a free monitoring service.

The External Service

For the purposes of this article, we are using Uptime Robot https://uptimerobot.com/ . This provides a five minute check for up to fifty checks, and also provides a publicly available status page. That is useful to distribute to end users to check whether Exchange is available or not.

The Exchange Mechanism

Introduced with Exchange 2013, each of the core Exchange web based services has a health check page. This can be checked with no authentication required and will confirm if the service is working or not. Primarily designed for use with load balancers, so they can check if the server is available, it is also useful for the purpose of monitoring. 

If you browse to the following URL, then you will see what I mean: https://host.example.com/owa/healthcheck.htm (where host.example.com is the host name used by your Exchange server). 

You should see something like this:


The full list of URLs that can be checked in that way are:

  • Outlook Anywhere (aka RPC over HTTP): /rpc/healthcheck.htm
  • MAPI/HTTP: /mapi/healthcheck.htm
  • Outlook Web App (aka Outlook on the web): /owa/healthcheck.htm
  • Exchange Control Panel: /ecp/healthcheck.htm
  • Exchange ActiveSync: /Microsoft-Server-ActiveSync/healthcheck.htm
  • Exchange Web Services: /ews/healthcheck.htm
  • Offline Address Book: /oab/healthcheck.htm
  • AutoDiscover: /Autodiscover/healthcheck.htm
Setting up the Checks

The type of monitor you want is "Keyword". Enter a friendly name for the monitor - this is what will be seen by anyone browsing to the public status page. 

For the URL, use your public URL, in the format above. 

For the keyword, use the name of the server as it appear when you browse to the server. In most cases this will be the server name in all upper case. That the name doesn't resolve externally doesn't matter. You need to change it to "Keyword NOT exists". 

You can then add an alert contact. An external email address would be a good option here, but there is also an App available. 


Repeat for all of the URLs listed above, until you get a list like this:


I have added in a check on the SMTP port as well. If you publish IMAP/POP3 then add those ports too. 

That is all there is to it. If you stop the IIS services then you will get a screen like this: 


Within the Uptime Robot site you can then create a public status site - which uses a CNAME on your domain to point to a site on their server - secured with an SSL certificate by default. 
This is a link to a screenshot of the status site for the above checks:

This URL can be included in any pre-populated bookmarks that are pushed to users - including on phones using your MDM product, so end users can check whether Exchange is available and whether it has been down earlier. 
Furthermore, as it is an externally hosted service it also can give you a quick overview from inside the office if things are working correctly. Just remember to add the same internal CNAME entry if you are using the same domain internally and externally via split DNS. 

What if you are behind a load balancer already?

In that case, give each server a unique URL (which is good practise anyway) and then configure Uptime Robot to connect to it directly. The IP addresses for the monitors are on their web site: 

A similar practise would allow you to monitor Exchange if behind a device in a DMZ. 

The SMTP Port Monitor doesn't confirm it is working? 

Indeed that is the case - Transport can often stop accepting emails, but will still have the port open. For proper testing of SMTP traffic, you need to use a round trip mail monitor. https://www.everycloudtech.com/free-mail-flow-monitor . That will alert you as the administrator directly if mail flow stops for whatever reason. Again use an external email account, rather than one on Exchange.