How many of you moved your emails to the cloud only have to Microsoft turn around and tell you that
in order to manage email in Office 365 you need an on-premises Exchange server? Say what!? I moved
to the cloud so I didn't have to worry about managing servers. What is this? Well, the good news
is that Microsoft have finally made it possible to manage Exchange Online without an actual Exchange
server. The bad news is they did half a job, so the community stepped in and fixed it for them.
Welcome back to The Pro Tech Show. Just to clarify, you didn't always need an Exchange server to
manage Office 365. It's something that has been required when you use directory synchronisation.
If you had a purely Office 365 environment and nothing else it wasn't necessary. It's necessary if
you have an on-premises Active Directory, too. Who uses that? Honestly it's probably easier to ask who
doesn't! Most organisations I've come across have Active Directory. Like almost all of them! Even many
of the ones that started out with the intention to go full cloud ended up deploying Active Directory,
because even though the Microsoft cloud services get better every month they still don't tick
all of the boxes of an on-prem AD; and a lot of applications simply require it. It's so prevalent
they're just built under the assumption that it exists. The problem for Exchange is that it stores
most of its configuration in Active Directory, not on the Exchange server itself. If you go back
far enough you'll see why this is the case. Active Directory's predecessor was the Exchange Directory
Service. It was part of Exchange, not Windows, and Exchange still views it as its own configuration
store. Of course you don't want your people to have two different accounts - one for cloud and another
for on-prem, and you don't want to have to manage the security and configuration of them separately;
so you synchronise them. You configure your accounts in on-prem AD and sync it up to
Azure AD. You create an account on-prem and it appears in the cloud; but how does this affect
Exchange? Well on-prem is a source of authority. The cloud AD gets overwritten by whatever is on-prem,
and remember: the Exchange configuration is in AD. So when you sync your directory the
configuration of Exchange Online in Office 365 becomes a read-only copy of whatever is on-prem;
meaning that if you want to add some Exchange configuration... something as simple as an email
address... you need to add it on-premises and let it sync to the cloud. If you try to change the setting
directly in Office 365 it simply doesn't work. So you need to change the Exchange configuration
on-premises but you don't have an Exchange server, so how do you do it? Microsoft's solution was simple:
install an Exchange server. Simple, but stupid. People didn't move to the cloud because they
wanted to manage Exchange servers! To be brutally honest most IT departments aren't cut out for
managing Exchange servers. They're big, they're complex, and they require more complicated update
procedures than most servers; and they have a habit of destroying the server if you don't do it just
right. Seriously. Did you forget that you need to run as admin on a command prompt to start your
graphical installer? Did you just double click it? It'll install... but break the server. Just look
at the huge number of companies who got breached by vulnerabilities like ProxyShell in the last
year or so. We've had a lot of companies coming to us for help and almost every Exchange server
we saw was missing tons of updates because the IT staff either didn't understand the update process
or were so scared of it they just didn't do it. Managing Exchange servers properly
requires a degree of specialist knowledge, but for many IT professionals it's only one of a
long list of applications they need to support; and they don't have time to give it the special
treatment it demands. So they move to the cloud and get told they need an Exchange server anyway.
To be clear: there were other ways to do it, but they weren't supported.
If you didn't have an Exchange server you could edit the configuration in AD directly,
but Microsoft didn't support it and it's not something I recommend. This is one of those cases
where "Do as I say, not as I do" comes into play. I've been working with Exchange since Exchange 2000
and I've spent several years as the lead Exchange architect for a Microsoft partner. I'm comfortable
editing the configuration in Active Directory, but I've also had to clean up a lot of problems that
have arisen due to people editing it incorrectly. When you use the official tools they make sure the
syntax and the capitalisation are just right. They check for duplicate values elsewhere. If
you edit it manually that's on you; and making a minor typo can result in data loss. Even though
I'm comfortable editing AD directly I'll use the proper tools if at all possible; because nobody's
perfect and it protects you from a silly mistake. So it's good to see that 12 and a half years after
introducing Exchange hybrid topologies Microsoft have finally created an officially sanctioned way
to manage Exchange configuration in Active Directory without a fully-fledged Exchange server.
I mean, yes. It's good that it's here but we should have had it a decade
ago! And it should be a full graphical interface, but it's not. That's right. It's PowerShell only.
Now I know you seasoned Exchange admins will point out that PowerShell is faster once you learn it,
and if you're making changes at scale using PowerShell is a no-brainer. I fully agree, but
it was never the hardened Exchange admins who were struggling. It's the smaller shops.
The places where IT staff have to wear a lot of different hats. They can click their way through
a wizard when needed but using PowerShell means they're basically back to Googling the commands
every time they want to do something instead of just picking the options they need off a screen.
This doesn't help them all that much and it detracts from the ease of management benefits
that you supposedly get by handing your services off to a cloud provider when you need to learn an
on-premises command line to manage it. So in steps the community, or rather; in steps Steve Goodman from
Practical 365 with his Exchange Recipient Admin Center. Styled after Microsoft's own Exchange Admin
Center, Steve's is a web interface for managing Exchange recipient configuration without the
need for an Exchange server. It isn't the first third-party tool for managing Exchange recipients.
Heck, we built our own for our customers as well. What makes this one different, though; is
it has been built on top of the recently released standalone management tools from Microsoft. This
means it's both safer to use and kind of, sort of supported. The tool itself isn't supported.
It's on GitHub so you can see the code, but it's not officially sanctioned by Microsoft. However,
the way it works is by generating and executing PowerShell commands in Microsoft's own management
tools. So although the web interface itself is unsupported, every action it takes on your infrastructure
is fully supported. It can't make any changes that Microsoft haven't approved and sanctioned
because it's running everything through their tools. This is a big deal because now you have
a way to manage Exchange Online recipients from a GUI, without an Exchange server, and without running
tools that make unapproved changes to your Active Directory environment; running the risk of causing
problems and invalidating your support. The way it works is a little funny. You run a PowerShell
script which starts a local web server and launches your browser to connect to it. The plan
is to move it into something like an Electron app in the future so it'll be a bit more polished, but
for now this is how it works. Despite it being a website it is intended to be used as a local tool
on your computer. It's not intended for shared use. This is because it's running in your user context.
You run the PowerShell to start it so every action you take on the website is running as
you. That's an important thing to know because if you try to set this up as a central management
server somewhere every action taken by anyone accessing the web interface would be carried
out as the person who started it. It would use the permissions of the person who started it and
everything would be logged and audited under their name. So how do we get this? Well first of all I
have an important warning for you. When you come to get rid of your last Exchange server you must not
decommission it properly. That sounds odd and it's the complete opposite of the advice I normally give,
but there's a very good reason. Ordinarily you want to go through the full uninstall process
when removing an Exchange server to make sure you've removed all of the objects and references
to it in Active Directory. When you do this for the last Exchange server it rips chunks out of AD
that the Microsoft management tools need. It's not a limitation of Steve's tool. It's a requirement
of Microsoft's. I'm going to tell you to read the documentation for the exact process because at
the moment it feels a little bit half-baked and it may change by the time you watch this. Sacking off
your server without a clean removal is a bit of a kludge. It's going to leave configuration junk
behind and this could cause you a problem later on if you need to introduce an Exchange server for
some reason. Just be aware of that gotcha for now and make sure to check the documentation. Before
installing the Recipient Admin Center you will need to install the standalone management tools
from Microsoft. These do have some prerequisites, so again: check the documentation as they may
change in later versions. Install those and grab the latest cumulative update for Exchange Server.
On the server role selection screen there's now an option for the management tools.
Install that and you've now got the ability to manage Exchange using PowerShell.
To upgrade that to a graphical web interface head over to Steve's GitHub page
(link in the description), click the "Code", button then "Download ZIP", extract the ZIP
file, and inside you'll find a PowerShell script called Start-ExchangeRecipientAdminCenter.
Right-click, run with PowerShell, and wait for web browser to open. There you go! I should stress that
as of the time of this recording this is a very early version and a lot of the planned features
are currently missing. For example, I can use this to enable a remote mailbox for an existing user;
but if i then come and click on it to edit the mailbox, the page doesn't exist.
A lot of it is like this right now with buttons that can't actually be clicked and don't go
anywhere. It's clearly got a long way to go and I normally don't cover projects that are this early
in their development because they often get abandoned long before they amount to anything;
but in this case I wanted to bring some attention to it because for smaller organisations who can't
afford the infrastructure or the skillset to host a full-blown Exchange server this could be a game -
changer for how they manage Exchange Online. Why on earth Microsoft haven't just done this
themselves, I have no idea; but props to Steve for starting it. There's a link to the GitHub
project and the Steve's blog post about in the video description. I'm really looking forward to
seeing how this matures. Give it some love, and give this video some love by clicking the like button;
and maybe even subscribing. Maybe by the time you view this there may be a few more of those
buttons that are actually working and you'll finally be able to ditch that management server.
Of course, there are reasons you might want to keep an Exchange server around. If you need something to
handle cross-premises mail flow from other systems a hybrid Exchange server can kill two birds with
one stone, and despite what some people would like you to believe: Exchange on-premises is still
a valid choice and Microsoft have just renewed their commitment to it. You don't have to go cloud.
Granted, the number of people I'd recommend that to to is getting quite a bit smaller these days
but there are a handful of companies I know for whom Exchange Online is just not reliable enough,
and may never be. Microsoft is trading reliability against cost and the ability to iterate quickly
with new features. It's a one-size-fits-all service so they're going to position that balance wherever
it gains them the most customers. That makes it a good fit for most, but there are always people who
don't fit the standard mould. Something that is not a one-size-fits-all service, however, is this video;
because I have selected the option that tells YouTube to pick the best video for you
based on your viewing habits. That's right, this is a personalised recommendation
so satisfaction is almost guaranteed... according to YouTube's algorithm, anyway.