You make the changes in active directory. Working for an MSP we have 200+ clients without an exchange server that use Azure AD Sync. The only example you gave is changing / adding an email which is simply the proxyaddress attribute in AD.
At the risk of sounding pedantic, it is not "simply the proxyaddress attribute". It is the proxyAddresses attribute, with a specific syntax; after checking the proxyAddresses, mail, and userPrincipalName attributes on every object in this and any linked forests for potential conflicts. Sometimes people miss a step and a service impact can result. The typo you made on the attribute name demonstrates how easy it is for people to make the sort of minor error that can cause issues when you edit AD directly. As an MSP I'd expect you to demonstrate good practice to your customers and not take shortcuts that could set them up for failure. In many cases the customer doesn't have the in-house expertise so they are looking to you for best practice. Perhaps your customers are aware their infrastructures are in an unsupported state. Perhaps they have no IT team of their own and all changes go through your service desk. Perhaps your service desk follows robust procedures or uses specific tools to avoid such errors. There are ways you could be managing the risk. "Unsupported" doesn't mean "doesn't work", but it rarely means "good practice" either.
The truth most don’t want to admit is the ‘cloud’ has made everything more expensive. Owning your own servers including a contracted IT tech to manage them is less expensive nowadays than the cost of MS365 with hundreds of licenses accounts. Not to mention the security threats aren’t any better than on premise. I know - I’m the IT tech that manages many of these businesses.
For a lot of cloud scenarios I'd agree with you - paying someone else to do it rarely costs less than doing it yourself. With Exchange Server, though; once you get into a few hundred users in enterprise agreement territory the cheapest way to licence Exchange on-prem usually ends up being to buy M365 and use the on-prem rights from the cloud licences. At that point on-prem is more expensive because you end up paying for cloud, anyway, and on-prem still needs servers.
@@ProTechShow Well - and that’s because of how they’ve changed the licenses overtime. In Exchange 2012, 2013 days it was very inexpensive overtime in comparison, but of course this was all by design.
So I'm not an exchange expert. My previous employer had an on-prem AD but no exchange server. They had EXO only. I came to the employer after they had moved to EXO, but I honestly don't know what they had before if it was self-hosted Exchange or not. (To be honest I don't think they ever had self-hosted Exchange). With very minimal exception we were able to create users in ADDS, have those sync with Azure AD Connect to AAD, then have EXO create the mailboxes for the users (after they're licensed of course). None of this required an on-prem exchange server for anything. The only exception that comes to mind is hiding a user from the GAL which required editing the attribute in ADDS. Am I missing something or is this one of the things skipped over for sake of brevity?
What your employer was doing was unsupported. That doesn't mean it won't work, but you invalidate support with Microsoft by doing it (some 3rd parties will also refuse to help with related problems) so it's not ideal. I touched on it briefly and basically said it works but I don't recommend it. In practice for a really simple use case you can get away with it. E.g. if you just put an email address in the standard AD field Office 365 will make assumptions that work for most people, as long as they don't need any aliases. Strangely enough Exchange doesn't actually use that email address field in AD for your email address (it uses ProxyAddresses which has a more specific and case-sensitive format - you may have edited that to add aliases), but if all that's filled in is the standard AD field Office 365 will generate the missing attributes on their end based on some some standard rules. When you enable a mailbox properly (using Enable-RemoteMailbox) it changes a whole bunch of other AD attributes as well. Where the manual approach tends to fall down is when aliases are needed, or permissions have to be added for something - essentially where it's not just a boolean attribute in AD you need to fiddle with. Typos or accidental duplication can cause things to break, and people make typos and miss things when there isn't a proper tool validating their input. I've seen a lot of emails get lost because of mistyped ProxyAddresses attributes, unfortunately!
When you install the 2019 management tools it will upgrade the AD schema to Exchange 2019 and you'll effectively be running a mixed 2016/2019 environment. This is fine, though - the two can coexist.
I was always sad to see that there is no "generate PowerShell script" in the exchange management console, like there is a "generate sql" option in ssms
There kind of is... In 2007/2010 the Exchange Management Console had a PowerShell icon on a lot of the GUI items. If you clicked it, it would show the PowerShell that would run when you clicked OK. In other places it would output the PowerShell after running it. In 2013 onwards you can't see the PowerShell in advance, but if you click the dropdown arrow in the top-right by the question mark, the help menu has "Show Command Logging" which will list all of the PowerShell commands executed as you click through the GUI. In Exchange Online it's in a similar place in the help menu. Steve's looking to add a similar feature to his tool in the future. I don't think they have it in the new/preview Exchange Online Admin Center because it uses the Graph API rather than PowerShell.
Hello, Thanks for the great post, what if i have exchnage server 2016 with the latest CU, can i use the exchanage mgmt tools ? or its required to have exchange 2019
If you install the 2019 management tools it will upgrade the AD schema to Exchange 2019 and you'll effectively be running a mixed 2016/2019 environment. This is fine, though - the two can coexist.
@@ProTechShow thanks for your response, is there any requirements for the mixed mode to avoid any issues specifically this my first time doing this kind of task
@@ahmedesam6036 there are too many considerations when upgrading between Exchange versions to put it in a YT comment; but in this case if you're just installing the management tools and don't have any older versions (pre-2016) kicking about it's fairly low-impact because you're not actually changing user-facing services. It is still worth reading through the documentation, though.
Does it matter if you have simple or full hybrid, and classic or modern? And if any will work, is any of them a better option if you are starting from scratch with just an on premise Exchange? Thanks!
The management tools don't actually rely on any form of hybrid topology. If you aren't hosting any on-premises Exchange services you don't necessarily need a hybrid topology. Making changes locally will write them to AD, and as long as AD syncs to the cloud that's all you actually need. A hybrid is necessary when you host mailboxes on-premises, and it can be useful to simplify mail-flow, but if your services other than identity are all in the cloud you can skip it.
You don't need a hybrid topology to use the management tools to manage Exchange Online, but it sounds like you actually have Exchange On-Prem and want to perform a migration. Long-term you may not need a hybrid, but for the migration itself I always prefer a hybrid migration to a cutover migration.
It does seem a bit bizarre, doesn't it? You can follow the logic if you consider the on-premises legacy they took to the cloud with them, but as a customer coming to them for a cloud service it is nonsensical. I don't know why it took so long to start addressing it - every single migration I've done over the last decade the customer has found this part of it frustrating.
I wouldn't say Exchange itself is garbage. Everything else I've tried has felt like a poor knockoff compared to Exchange from the user side, but the hybrid integration... that's hacky as hell. Yuk.
@@balfor1114 I've played with a few over the years, although I'd struggle to remember the names of most. The main issue is that Exchange does a LOT of different things and most alternatives only cover a fraction of its capabilities. Those that try to do everything are typically bolted together from a whole bunch of separate projects, feel inconsistent and amateur by comparison, and still only cover the most common features. The one I recall testing most recently was Nextcloud Groupware (or Zoho if you count SaaS). Nextcloud Files is great, but the Groupware stuff doesn't come close at the moment. Zoho... is cheap for a reason. I'd say the closest real competitor to Exchange is Gmail with its Google Workspace integrations, but you can't exactly install that on your own server. Good idea for a video, though. I'm going to add that to my list, thanks!
Perfect video. Talks about the stuff that most people are feared to speak about.
Thanks!
You make the changes in active directory. Working for an MSP we have 200+ clients without an exchange server that use Azure AD Sync. The only example you gave is changing / adding an email which is simply the proxyaddress attribute in AD.
At the risk of sounding pedantic, it is not "simply the proxyaddress attribute". It is the proxyAddresses attribute, with a specific syntax; after checking the proxyAddresses, mail, and userPrincipalName attributes on every object in this and any linked forests for potential conflicts. Sometimes people miss a step and a service impact can result. The typo you made on the attribute name demonstrates how easy it is for people to make the sort of minor error that can cause issues when you edit AD directly.
As an MSP I'd expect you to demonstrate good practice to your customers and not take shortcuts that could set them up for failure. In many cases the customer doesn't have the in-house expertise so they are looking to you for best practice. Perhaps your customers are aware their infrastructures are in an unsupported state. Perhaps they have no IT team of their own and all changes go through your service desk. Perhaps your service desk follows robust procedures or uses specific tools to avoid such errors. There are ways you could be managing the risk. "Unsupported" doesn't mean "doesn't work", but it rarely means "good practice" either.
The truth most don’t want to admit is the ‘cloud’ has made everything more expensive. Owning your own servers including a contracted IT tech to manage them is less expensive nowadays than the cost of MS365 with hundreds of licenses accounts. Not to mention the security threats aren’t any better than on premise. I know - I’m the IT tech that manages many of these businesses.
For a lot of cloud scenarios I'd agree with you - paying someone else to do it rarely costs less than doing it yourself. With Exchange Server, though; once you get into a few hundred users in enterprise agreement territory the cheapest way to licence Exchange on-prem usually ends up being to buy M365 and use the on-prem rights from the cloud licences. At that point on-prem is more expensive because you end up paying for cloud, anyway, and on-prem still needs servers.
@@ProTechShow Well - and that’s because of how they’ve changed the licenses overtime. In Exchange 2012, 2013 days it was very inexpensive overtime in comparison, but of course this was all by design.
Oh, absolutely. Gotta get you tied into that recurring revenue somehow, right?
@@ProTechShow Yep - linux and open source is looking more attractive all of the time.
So I'm not an exchange expert. My previous employer had an on-prem AD but no exchange server. They had EXO only. I came to the employer after they had moved to EXO, but I honestly don't know what they had before if it was self-hosted Exchange or not. (To be honest I don't think they ever had self-hosted Exchange).
With very minimal exception we were able to create users in ADDS, have those sync with Azure AD Connect to AAD, then have EXO create the mailboxes for the users (after they're licensed of course). None of this required an on-prem exchange server for anything. The only exception that comes to mind is hiding a user from the GAL which required editing the attribute in ADDS.
Am I missing something or is this one of the things skipped over for sake of brevity?
What your employer was doing was unsupported. That doesn't mean it won't work, but you invalidate support with Microsoft by doing it (some 3rd parties will also refuse to help with related problems) so it's not ideal. I touched on it briefly and basically said it works but I don't recommend it.
In practice for a really simple use case you can get away with it. E.g. if you just put an email address in the standard AD field Office 365 will make assumptions that work for most people, as long as they don't need any aliases. Strangely enough Exchange doesn't actually use that email address field in AD for your email address (it uses ProxyAddresses which has a more specific and case-sensitive format - you may have edited that to add aliases), but if all that's filled in is the standard AD field Office 365 will generate the missing attributes on their end based on some some standard rules. When you enable a mailbox properly (using Enable-RemoteMailbox) it changes a whole bunch of other AD attributes as well. Where the manual approach tends to fall down is when aliases are needed, or permissions have to be added for something - essentially where it's not just a boolean attribute in AD you need to fiddle with. Typos or accidental duplication can cause things to break, and people make typos and miss things when there isn't a proper tool validating their input. I've seen a lot of emails get lost because of mistyped ProxyAddresses attributes, unfortunately!
Nice info Adam Sandler 😁
Great video. Is this possible with Exchange 2016 (I.e just install the 2019 Management tools) , or do I need to fully migrate to 2019 first?
When you install the 2019 management tools it will upgrade the AD schema to Exchange 2019 and you'll effectively be running a mixed 2016/2019 environment. This is fine, though - the two can coexist.
I was always sad to see that there is no "generate PowerShell script" in the exchange management console, like there is a "generate sql" option in ssms
There kind of is...
In 2007/2010 the Exchange Management Console had a PowerShell icon on a lot of the GUI items. If you clicked it, it would show the PowerShell that would run when you clicked OK. In other places it would output the PowerShell after running it.
In 2013 onwards you can't see the PowerShell in advance, but if you click the dropdown arrow in the top-right by the question mark, the help menu has "Show Command Logging" which will list all of the PowerShell commands executed as you click through the GUI. In Exchange Online it's in a similar place in the help menu.
Steve's looking to add a similar feature to his tool in the future.
I don't think they have it in the new/preview Exchange Online Admin Center because it uses the Graph API rather than PowerShell.
Last Update on the Github was 7 Months ago. It seems it has been abondened already...
Hello,
Thanks for the great post, what if i have exchnage server 2016 with the latest CU, can i use the exchanage mgmt tools ? or its required to have exchange 2019
If you install the 2019 management tools it will upgrade the AD schema to Exchange 2019 and you'll effectively be running a mixed 2016/2019 environment. This is fine, though - the two can coexist.
@@ProTechShow thanks for your response, is there any requirements for the mixed mode to avoid any issues specifically this my first time doing this kind of task
@@ahmedesam6036 there are too many considerations when upgrading between Exchange versions to put it in a YT comment; but in this case if you're just installing the management tools and don't have any older versions (pre-2016) kicking about it's fairly low-impact because you're not actually changing user-facing services. It is still worth reading through the documentation, though.
Does it matter if you have simple or full hybrid, and classic or modern? And if any will work, is any of them a better option if you are starting from scratch with just an on premise Exchange?
Thanks!
The management tools don't actually rely on any form of hybrid topology. If you aren't hosting any on-premises Exchange services you don't necessarily need a hybrid topology. Making changes locally will write them to AD, and as long as AD syncs to the cloud that's all you actually need. A hybrid is necessary when you host mailboxes on-premises, and it can be useful to simplify mail-flow, but if your services other than identity are all in the cloud you can skip it.
So deploy Azure AD connect, then do something like a cut over migration? What about the tick box for hybrid exchange in AAD Connect?
You don't need a hybrid topology to use the management tools to manage Exchange Online, but it sounds like you actually have Exchange On-Prem and want to perform a migration.
Long-term you may not need a hybrid, but for the migration itself I always prefer a hybrid migration to a cutover migration.
Microsoft is a weird company, interesting information, thanks
It does seem a bit bizarre, doesn't it? You can follow the logic if you consider the on-premises legacy they took to the cloud with them, but as a customer coming to them for a cloud service it is nonsensical. I don't know why it took so long to start addressing it - every single migration I've done over the last decade the customer has found this part of it frustrating.
shame that Steve abandoned the Admin Center project
Aye. It was looking very promising for a while.
Great news!
Can't believe it took this long, but glad they eventually did it!
Listening to you talk about Exchange just makes me realize how garbage Exchange is.
I wouldn't say Exchange itself is garbage. Everything else I've tried has felt like a poor knockoff compared to Exchange from the user side, but the hybrid integration... that's hacky as hell. Yuk.
@@ProTechShow What else have you tried? Maybe a video on this matter would be a great idea. :)
@@balfor1114 I've played with a few over the years, although I'd struggle to remember the names of most. The main issue is that Exchange does a LOT of different things and most alternatives only cover a fraction of its capabilities. Those that try to do everything are typically bolted together from a whole bunch of separate projects, feel inconsistent and amateur by comparison, and still only cover the most common features.
The one I recall testing most recently was Nextcloud Groupware (or Zoho if you count SaaS). Nextcloud Files is great, but the Groupware stuff doesn't come close at the moment. Zoho... is cheap for a reason. I'd say the closest real competitor to Exchange is Gmail with its Google Workspace integrations, but you can't exactly install that on your own server.
Good idea for a video, though. I'm going to add that to my list, thanks!