Microsoft Exchange and Remote Desktop Services Specialists

SEMblog

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

27 March 2023 10.30

PodCast - Disaster Recovery & Business Continuity Planning


This a blog post supporting one of the Cyber Anxiety series, hosted by Inbay, alongside Daniel Welling of WellingMSP. 
The latest one is about Disaster Recovery and Business Continuity Planning. 

Is Disaster Recovery and Business Continuity an Outdated Concept, and if not, where to start?


Disaster Recovery or Business Continuity Planning is something that all MSPs should have not only for themselves, but also for their clients. 
However, with the growth of cloud-based services, it could be argued that DR/BCP is now an outdated concept which most companies no longer need. Yet the company still needs to operate, so even if the plan is simply to work from home, it is still valuable to have a plan which can be communicated to staff. 

Disaster Recovery – what is it and where to start?


Traditionally, what is a Disaster?


Simply put a disaster should be considered the loss of something within the business. All of the below would mean that a DR plan of some kind maybe activated. 
  • Loss of the building.
  • Loss of access to the building.
  • Loss of data.
  • Loss of internet access.
  • Loss of electric supply. 
The likelihood of the above and their impact will play a big part in the planning that needs to take place. 

With the warnings in the Autumn of 2022 that we could have seen scheduled power blackouts, planning for that kind of scenario seems a good opportunity to open conversations with your clients regarding their plans and see what can be adapted or needs to be changed. 

Where to Start with DR Planning?


A lot of companies and their IT support will look at DR and not know where to begin, or because some or all of their services are now in the cloud, feel they are at least partially covered. 

Obviously the first thing to consider is what is still physically in the office and would therefore be affected by a local failure. 

Then, after looking at the list above, it should be obvious that a lot of clients and their IT support will already have the beginnings of a plan, which can be adapted and expanded for other scenarios.

Start by asking the client a few simple questions:

  • What do you do when the power goes out?
  • What do you do when the internet goes down?
  • What do you do if everyone is snowed in and cannot get to the office?
For power loss, this could be a UPS that requires its own room and a generator the size of a small van in the car park, at the other end of the scale, something as simple as pen and paper or more sophisticated such as telling everyone to go home and work from there.

For loss of the internet, you might already have a 4g gateway available to take to a client at a moment’s notice.

If everyone is snowed in, do staff work from home, have soft phones for example, or is it just a day off?

For loss of data, you should already have a plan for dealing with ransomware.

All of those elements can be used and adapted for the more serious events. If the client has everything in the cloud already, then all you might have to add to a plan is how to get access to the data in a secure manner. That can be something as simple as renting dedicated servers and building a remote desktop services farm, or even just deploying Azure Virtual Desktop. 

For on premise servers, if you have protection for encryption malware, then that protection may well be adaptable for dealing with other scenarios. 

Disaster Recovery shouldn’t be seen as a massive thing that can overwhelm you or your clients. A basic plan can be put together which can be easily adapted for most clients IT needs. Even if the client then requires more advanced needs, this can be a good start and also a valuable source of revenue with the initial planning and then annual reviews to ensure the plan keeps up with the technology that they are now using. 

Luke, Daniel and I discuss DR in the pod cast series Cyber Anxiety, the link to it can be found above. 


If you would like to listen to the rest of the series, then they can be found here:
25 January 2023 09.00

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
29 April 2022 11.05

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. 

15 July 2021 02.07

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... 
14 July 2021 04.18

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.