Sembee | Sembee - BlogBlog of Exchange Consultant Simon Butler

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.

0

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:

UptimeRobotDemoSiteScreenShot.PNG (95.8KB)

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:

https://uptimerobot.com/locations.php

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.

0

Exchange 2016, Windows 2016 and Macs

Now starting to see more implementations of Windows 2016 and Exchange 2016, so odd issues are starting to come to light.

One that I have seen a few times is a problem with Macs connecting to EWS on the 2016 versions of Exchange and Windows.

Going through the logs, there are 401 errors (unauthorised), yet the same credentials work with OWA.

Further troubleshooting with the web server and a hint on an Apple forum suggested that Windows 2016 was using HTTPS 2 by default and that the Mac was having some problems working with that for authentication.
The fix was to downgrade to HTTP 1.1.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters

New DWORD values

EnableHttp2Cleartext
EnableHttp2Tls

Set both to a value of 0.

The first one is for HTTP, the second for HTTPS. I set both, even though in most cases only HTTPS is allowed to the server and being used.

Reboot the server (restarting the IIS services does not appear to work).

Here is the registry value content to create a reg file for easy installation:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters]
"EnableHttp2Tls"=dword:00000000
"EnableHttp2Cleartext"=dword:00000000

From an operational point of view, I cannot see any loss of functionality. OWA is designed to work with Windows 2012 R2 which still uses HTTP 1.1. In very large environments you might see a small performance hit because of the loss of the optimisations provided by HTTP 2, but most systems will not see anything.

SEMblog