Sembee | Sembee - BlogBlog of Exchange Consultant Simon Butler

0

Version Error When you Install Exchange in Recovery Mode Post Jan 2023 SU

Quick post to say that if you are attempting to recover a server with the Jan 2023 security update installed, it will fail with a version mismatch error and ask you to use a later version of the installer. Microsoft have published a fix for the error.

https://learn.microsoft.com/en-us/exchange/troubleshoot/setup/version-error-in-recover-server-mode-install

0

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 -PrivateKeyExportable:$true

[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 -PrivateKeyExportable:$true -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.
The -PrivateKeyExportable:$true allows the certificate to be exported for use in another server. The default is false.

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

Update May 2022

This post was originally written using a single test server, so exporting the certificate wasn't required. The commands supplied by Microsoft in their process are as used above, but the resulting certificate cannot be exported. I have updated the above commands to include the ability to export the certificate so it can be used on other servers.

0

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

0

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.

0

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.

SEMblog