When you plan to implement an Exchange Hybrid Configuration between your on-premises Exchange Organization and Exchange online you have to choose between two variants and five operating modes. It is not as complicated as it sounds.
I have written a blog post about the different options available.
The post is published in ENow's ESE blog.
Enjoy.
Once upon a time at an Exchange Conference near you, a member of the Exchange Product Group (PG) announced that the very last Exchange Server will go away when having an active Exchange hybrid setup.
This was a hot topic for discussions at the Microsoft Exchange Conferences (MEC, @IamMEC) in 2012 and 2014, already. Since then the Exchange PG came up with a number of reasons why this is not possible. The question on when we will finally be able to remove the very last Exchange Server from the on-premises Exchange organization was asked every year at the Ignite Conference.
Currently, the supported scenario for hybrid configurations between your on-premises Exchange organization and Exchange Online requires that you keep the last Exchange Server for creating, and managing Exchange related objects, even if those objects are located in Exchange Online.
The following diagram illustrates the current requirements:
In the past, there was communication on certain interim solutions that were supposed to support you in removing the last Exchange Server from your Exchange organization. Such interim solutions were:
At Ignite those solutions even made it into the official session catalog:
All those interim solutions leave your on-premises Exchange organization and the Active Directory configuration in an uncomfortable twilight-zone. It was still something that worked somehow, but you knew it was officially not supported, and the secure and stable operation of the hybrid configuration was at risk.
But wait...
Removing the last Exchange Server is supported! (at least when all components are released)
The new approach for managing your Exchange Online tenancy after migrating your on-premises Exchange organization to Exchange Online does not require an on-premises Exchange Server.
The new mode of operation reduces your on-premises requirements to:
The following diagram illustrates the new modern Exchange Online Management experience:
Simply you remove the requirement to use on-premises Exchange Server to write to your on-premises Active Directory. Instead, Azure AD Connect uses a new synchronization capability to handle the new Exchange Management experience in the AAD Connect MetaVerse. The on-premises AD-connector writes the changes to Active Directory which keeps the Active Directory up-to-date for all other on-premises solutions that require identities to have a proper state.
You execute all Exchange-related actions using the new Exchange Online Management PowerShell module, or, if needed, the new Modern Exchange Admin Center (EAC, which was announced at Ignite 2019.
Before you uninstall the last Exchange Server from your on-premises Exchange organization, ensure that you
PS C:\> Get-WindowsFeature Display Name Name Install State ------------ ---- ------------- [ ] Active Directory Certificate Services AD-Certificate Available [ ] Certification Authority ADCS-Cert-Authority Available [ ] Certificate Enrollment Policy Web Service ADCS-Enroll-Web-Pol Available [ ] Certificate Enrollment Web Service ADCS-Enroll-Web-Svc Available [ ] Certification Authority Web Enrollment ADCS-Web-Enrollment Available [ ] Network Device Enrollment Service ADCS-Device-Enrollment Available [ ] Online Responder ADCS-Online-Cert Available [ ] Active Directory Domain Services AD-Domain-Services Available [ ] Active Directory Federation Services ADFS-Federation Available [ ] Active Directory Lightweight Directory Services ADLDS Available [ ] Active Directory Rights Management Services ADRMS Available [ ] Active Directory Rights Management Server ADRMS-Server Available [ ] Identity Federation Support ADRMS-Identity Available [ ] Device Health Attestation DeviceHealthAttestat... Available [ ] DHCP Server DHCP Available [ ] DNS Server DNS Available [ ] Exchange Online Remote Features EXORemote Available [ ] Fax Server Fax Available [X] File and Storage Services FileAndStorage-Services Installed [X] File and iSCSI Services File-Services Installed [X] File Server FS-FileServer Installed [ ] BranchCache for Network Files FS-BranchCache Available [...]
PS C:\> Install-WindowsFeature -Name EXORemote Display Name Name Install State ------------ ---- ------------- [ ] Active Directory Certificate Services AD-Certificate Available [ ] Certification Authority ADCS-Cert-Authority Available [ ] Certificate Enrollment Policy Web Service ADCS-Enroll-Web-Pol Available [ ] Certificate Enrollment Web Service ADCS-Enroll-Web-Svc Available [ ] Certification Authority Web Enrollment ADCS-Web-Enrollment Available [ ] Network Device Enrollment Service ADCS-Device-Enrollment Available [ ] Online Responder ADCS-Online-Cert Available [ ] Active Directory Domain Services AD-Domain-Services Available [ ] Active Directory Federation Services ADFS-Federation Available [ ] Active Directory Lightweight Directory Services ADLDS Available [ ] Active Directory Rights Management Services ADRMS Available [ ] Active Directory Rights Management Server ADRMS-Server Available [ ] Identity Federation Support ADRMS-Identity Available [ ] Device Health Attestation DeviceHealthAttestat... Available [ ] DHCP Server DHCP Available [ ] DNS Server DNS Available [X] Exchange Online Remote Features EXORemote Installed [ ] Fax Server Fax Available [X] File and Storage Services FileAndStorage-Services Installed [X] File and iSCSI Services File-Services Installed [X] File Server FS-FileServer Installed [ ] BranchCache for Network Files FS-BranchCache Available [...]
Even though not explicitly stated, you should restart the server after installing the Windows feature.
As part of the next AAD Connect synchronization cycle, the magic happens.
Verify that you can edit the Exchange related attributes of synchronized Active Directory objects in Exchange Online or Azure AD before you remove your last Exchange Server.
Whey ready to uninstall the last Exchange Server you must use the following command line parameters to remove the server as intended. Otherwise, you'll leave the Exchange organization in an inchoate state. Ensure that you use an administrative PowerShell session.
./Setup.exe /mode:uninstall /SwitchToMEMA /IAcceptExchangeOnlineLicenseTerms
Normally, you do not have to accept license terms when uninstalling Exchange Server, but in this case, you have to accept the Exchange Online license terms.
Enjoy the modern experience and management options of Exchange Online!
Exchange Conferences
This is a quick post on how to obtain the license key for your on-premises Exchange Hybrid Server.
Even though that there is no such role like a Hybrid Server, you can get a dedicated license key to license your Exchange server used for Office 365 hybrid connectivity.
While using your Office 365 Global Administrator login, you can access your hybrid product key using the follow link:
The web site will check if your Office 365 tenant is eligible for an hybrid key first. Then you have to select the approriate Exchange Server version.
Enjoy your Exchange hybrid setup wth Office 365.
On October 26th ENow hosted the webinar "Deploy Exchange 2016 On-prem and Hybrid Webinar".
"Support for Office 365 is part of the Exchange 2016 DNA. Yet, traditional on-premises deployment still make up a large number of Exchange deployments worldwide. In this session, we will cover the various deployment options and take a peek into what it takes to install, configure and manage an Exchange 2016 on-premises or Exchange 2016 hybrid deployment."
You are not able to list public folders in a co-existence scenario with Exchange Server 2007 and Exchange Server 2010/2013 using the Exchange 2007 EMS or EMC.
When you try to execute Get-PublicFolder you receive the following error:
Get-PublicFolder " There is no existing PublicFolder that matches the following Identity: '\'. Please make sure that you specified the correct PublicFolder Identity and that you have the necessary permissions to view PublicFolder.
This might happen after you have removed the first Exchange 2007 mailbox server, but not the last Exchange 2007 mailbox server.
Exchange Server 2007 uses the Exchange System Attendant to access the public folder store and fails, if the System Attendant discovery in Active Directory does not provide a proper configuration.
KB 2621350 describes the discovery process:
There two annoying things about these steps
The magic System Attendant mailbox has been removed from Exchange 2010. But the System Attendent configuration node does still exist in the Active Directory Configuration Partition for compatibility reasons. The configured attributes of the System Attendent entry vary depending on the version of the installed Exchange Server.
In regards of public folder issue, we need to focus on the following:
To fix the public folder access issue for Exchange Server 2007, set the homeMDB and homeMTA attributes. Set the Exchange System Attendant attributes to appropriate values for your Exchange servers.
Repeat steps 4 to 8 for each Exchange 2013 server in your environment.
Repeat steps 4 to 13 for each Exchange 2010 server in your environment.
Wait for Active Directory replication and retry to access the public folders using Get-PublicFolder in an Exchange Server 2007 Management Shell.
It might be required to restart the Exchange 2007 Information Store and System Attendant service of the Exchange 2007 server in question
Use an administrative PowerShell
Restart-Service MSExchangeIS Restart-Service MSExchangeSA
I haven’t noticed any issues in production environments so far. If you encounter any issues in your environment, feel free to leave a comment.
You need assistance with your Exchange Server setup? You have questions about your Exchange Server infrastructure and going hybrid? You are interested in what Exchange Server 2016 has to offer for your environment?
Contact me at thomas@mcsmemail.de Follow at https://twitter.com/stensitzki
As an Exchange administrator you normally perform tasks by executing PowerShell scripts. Some of these scripts are executed automatically, some are run manually as these scripts require more attention.
Think about a completely different approach. Have you ever thought about administrating Exchange Server or your Exchange Online instance using your voice?
Thanks to Alexa skills we can do something like
"Alexa, ask Exchange Assistant to create a new mailbox for John Doe" "Alexa, is the CEO's mailbox in good shape?"
"Alexa, ask Exchange Assistant to create a new mailbox for John Doe"
"Alexa, is the CEO's mailbox in good shape?"
Or run something more complicated
"Alexa, start Exchange to setup 5 new Exchange servers, please"
Sounds like magic, right?
As a solution we use the following technologies:
The Azure Hybrid Runbook Worker enables you to execute PowerShell runbooks in your local infrastructure to manage local ressources.
The solution consists of a Visual Studio Solution acting as an Alexa skill endpoint. The configured intents connect to your Azure Automation webhooks and trigger the execution of preconfigured PowerShell automation runbooks.
These runbooks can either run againt Azure resources or against your local infrastructure. Automation of your local infrastructure requires the setup of the Azure Hybrid Runbook Worker components.
The following diagram illustrates the functionality.
The solution utilizes the Azure4Alexa and AlexaSkillsSet.NET projects available on Github. Currently the approach requires some manual steps and Visual Studio knowledge, as you want to deploy your own Alexa custom application. This is primarily driven due to security demands. The Hybrid Runbook Worker can access your local infrastructure. So you went to be in charge of the credentials used to access your infrastructure.
Start enjoying how your administrator's can orchestrate your Exchange Server environment.
Enjoy your wonderful life with Exchange :-)
I came across an interesting issue when setting up a new Exchange 2013 server in an Exchange organization having the cmdlet extension agent enabled.
As mentioned in my last post Exchange setup checks for the existence of the ScriptingAgentConfig.xml file when agent extenstion is enabled in the Exchange organization. It turned out that this ist not only true when you install an Exchange update using /mode:update, but as well when installing a new Exchange server using /mode:install.
The following error occurs when Exchange Management Tools are provisioned.
Configuring Microsoft Exchange Server Preparing Setup COMPLETED Stopping Services COMPLETED Copying Exchange Files COMPLETED Language Files COMPLETED Restoring Services COMPLETED Language Configuration COMPLETED Exchange Management Tools FAILED The following error was generated when "$error.Clear(); Set-WERRegistryMarkers; " was run: "Microsoft.Exchange.Provisioning.ProvisioningBrokerException: Provisioning layer initialization failed: '"Scripting Agent initialization failed: "File is not found: 'C:\Program File s\Microsoft\Exchange Server\V15\Bin\CmdletExtensionAgents\ScriptingAgentConfig.xml'.""' ---> Microso ft.Exchange.Provisioning.ProvisioningException: "Scripting Agent initialization failed: "File is not found: 'C:\Program Files\Microsoft\Exchange Server\V15\Bin\CmdletExtensionAgents\ScriptingAgentConf ig.xml'."" ---> System.IO.FileNotFoundException: "File is not found: 'C:\Program Files\Microsoft\Exc hange Server\V15\Bin\CmdletExtensionAgents\ScriptingAgentConfig.xml'." at Microsoft.Exchange.ProvisioningAgent.ScriptingAgentConfiguration.Initialize(String xmlConfigPa th) at Microsoft.Exchange.ProvisioningAgent.ScriptingAgentConfiguration..ctor(String xmlConfigPath) --- End of inner exception stack trace --- at Microsoft.Exchange.ProvisioningAgent.ScriptingAgentConfiguration..ctor(String xmlConfigPath) at Microsoft.Exchange.ProvisioningAgent.ScriptingAgentClassFactory.get_Configuration() at Microsoft.Exchange.ProvisioningAgent.ScriptingAgentClassFactory.GetSupportedCmdlets() at Microsoft.Exchange.Provisioning.ProvisioningBroker.BuildHandlerLookupTable(CmdletExtensionAgen t[] enabledAgents, Exception& ex) --- End of inner exception stack trace --- at Microsoft.Exchange.Provisioning.ProvisioningLayer.GetProvisioningHandlersImpl(Task task) at Microsoft.Exchange.Provisioning.ProvisioningLayer.GetProvisioningHandlers(Task task) at Microsoft.Exchange.Configuration.Tasks.Task.<BeginProcessing>b__4() at Microsoft.Exchange.Configuration.Tasks.Task.InvokeNonRetryableFunc(Action func, Boolean termin atePipelineIfFailed)".
As expected a fresh Exchange install contains the sample file only. The following screenshot shows the Exchange Management Shell and the releated folder in the background.
The only solution currently known to me is to disable the cmdlet extension agent until the setup of the new Exchange server has finished.
Disable-CmdletExtensionAgent "Scripting Agent"
Having the cmdlet extension agent disabled the setup finishes without any issues. Don't forget to copy the cmdlet extension Xml file to the newly built server and to enable the cmdlet extension agent again.
Enable-CmdletExtensionAgent "Scripting Agent"