Exchange Server 2019 is the most recent release of the successful email messaging solution, introduced by Microsoft in 1996. Since the early days of the product supported a single primary email address only. The primary email address is used as the sender address when a user composes a new email message and sends the message. A mailbox can have multiple email addresses to receive messages for, but only one so-called reply-address.
But the limitation is not valid anymore.
A recent build of the Exchange Server 2019 Cumulative Update 1 released to VLSC contains a new feature called Multi-Reply Addresses.
This new feature is very helpful in scenarios where a single user sends email messages for multiple companies. Think of a business owner who is responsible for two or more companies. In the past, it was required to configure a mailbox account per primary email address used as a reply address. Such a configuration resulted not only on multiple inboxes but in multiple calendars and contact folders as well.
The new Multi-Reply Addresses feature of Exchange Server 2019 provides a much better solution. Moreover, it is a CEO-safe solution.
After enabling the multi-reply feature in your Exchange Organization the new functionality is available in Exchange Admin Center and Exchange Management Shell.
When you edit the email address properties using the Edit User Mailbox dialogue of an existing mailbox you can add additional reply addresses.
The following screenshot illustrates the steps.
When you close the Edit User Mailbox dialogue the additonal reply addresses and the status are displayed in the recipient list view and the detail pane.
The following screenhot shows how the reply addresses are displayed in the list view and how the status is displyed in the detail pane.
You can verify the updated proxyAddresses Active Directory attibute using ADSIEdit or the Attribute Viewer of the ADUC MMC.
When you compose a new email message using Outlook on the Web, the From selector is displayed automatically. You can select one of the configured reply email addresses as the sender address.
You can configure separate email signatures for each available reply address.
A user can select Options - Mail - Email signature to open the Email signature form. The form provides a new option to set a different email siganture for each reply address.
This is a really exciting new feature.
You can enable the new multi-reply function using the following new Exchange Cmdlet:
# Enable Multi-Reply functionality in Exchange Server 2019 Enable-SmtpMultiReply # Disable Multi-Reply functionality in Exchange Server 2019 Disable-SmtpMultiReply -CleanupPrimarySmtp -Force
When disabling the Multi-Reply feature a all but one primary SMTP address is converted to a legacy proxy smtp address.
You need to be assigned permissions before you can run this cmdlet. It is required to be assigned to the Elevated Exchange Organization Management role.
I do not know if the new feature had been exposed accidentally, but the on-premises version of the Exchange Server 2019 benefits from this new feature. This is a true differentiator to the cloud-based service of Exchange Online.
Enjoy Exchange Server 2019!
The latest downloadable build of Exchange Server 2016 Cumulative Update 9 disclosed an information that was previously shown accidently to the public by Greg T. during his breakout session BRK3249 - Modern Authentication for Exchange Server On-Premises at Microsoft Ignite 2017.
As part of the global harmonization of the product name space of the well established Outlook brand the next release of Exchange Server will be named Outlook Server 2019.
This name change was mentioned originally on this slide:
Give it a thought and you'll realize that this change makes absolute sense as different product names for the same software function distract customers and users.
Another reason for renaming Exchange Server is a new functionality for integrating personal mailbox files (PST). It was and still is a tedious task for administrators to get hold of all those PST files in use by end users. Instead of implementing a complex and data protection safe process to import PST files to the primary users mailbox the new Outlook Server 2019 offers synchronized PST folders. A functionality we've waited for for years.
Two new functions are introduced as part the new modern Outlook Server 2019
How does it work?
The following diagram illustrates the new functionality in a simple Outlook Server 2019 setup:
The following screenshot illustrates the new PSTSync folder and some sample PST file for a user with SAMAccountName JohnDoe
It's good the see that there is a future for a email server product like Exchange Server and that after so many years of cloud only an on-premises only feature got added.
Enjoy the day and Happy Easter!
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 :-)
The Exchange Server product used the Extensible Storage Engine (ESE, aka JET Blue) to store data for decades. The story of the JET Blue (in contrast to JET Red which is used for Access database) can be read here (https://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine). In the acient days of data storage the ESE database was the best choice for storing mostly unstructured data with many dynamic properties.
The Messaging API (MAPI) had been developed in the 1990s to provide programmers with a set of unified interface for easier message exchange. The MAPI documentation at TechNet has been replaced by the current Outlook 2013 MAPI Reference. In todays world it is not easy to find reliable ressource about the original MAPI implementation. The only printed resource is Inside Mapi (Microsoft Programming Series) , ISBN 978-1572313125 , which has been published in 1996.
At Ignite 2015 Ross Smith VI joked about moving the Exchange storage engine to SQL. Back in the day with Exchange 2013 in production and Exchange 2016 coming, this was true. But Ross laid the tracks for the evolution of Exchange.
But it seems that the Exchange Product Team realized that in today's world with heavily standardized communication and less dynamic requirements than in the 1990s the days of JET blue are over. At the same time SQL Server evolved to mature database solution, capable of handling big data. The question was, if it can store SharePoint data, why not Exchange data. After twenty years of Exchange Server using the good ole ESE engine it was time to move on.
The SQL scripts that are used by Exchange to configure SQL are loacted in $exbin\SQL
CREATE TABLE [dbo].[MAPI_PROPERTIES]( [MAPI_PROPERTTY_ID] [int] IDENTITY(1,1) NOT NULL, [MAPI_PROPERTY_NAME] [nchar](127) NOT NULL, [IsWellKnownProperty] [bit] NOT NULL, [MAPI_TYPE_ID] [int] NOT NULL, CONSTRAINT [PK_MAPI_PROPERTIES] PRIMARY KEY CLUSTERED ( [MAPI_PROPERTTY_ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO ALTER TABLE [dbo].[MAPI_PROPERTIES] WITH CHECK ADD CONSTRAINT [FK_MAPI_PROPERTIES_MAPI_TYPES] FOREIGN KEY([MAPI_TYPE_ID]) REFERENCES [dbo].[MAPI_TYPES] ([MAPI_TYPE_ID]) GO ALTER TABLE [dbo].[MAPI_PROPERTIES] CHECK CONSTRAINT [FK_MAPI_PROPERTIES_MAPI_TYPES] GO
The current Exchange 2016 CU2 Preview supports an undocumented registry key to activate SQL Server support for Exchange. Personally I do not know, if this was supposed to be officially included in a public realease. So maybe the SQL support was made available by error and is already removed from the most current build again.
The famous SqueakyLobster registry key in has been used in Exchange 5.5 to troubleshoot performance issues. The new "Lobster" key is used to activate hidden code in Exchange Server product. The name of the key is LobsterMapiDB.
This key activates support for Exchange modern storage. Without this key you won't be able to move mailboxes from ESE legacy storage to SQL modern storage.
It is assumed that a SQL Server 2014 instance is available. A SQL Server 2014 Express edition is sufficient for testing purposes.
Note: Any changes to configurations or the registry should be validated in a test environment first. Never try this in production right away.
The high level steps required to activate SQL support for Exchange 2016 are:
The detailed steps are:
<?xml version="1.0" encoding="utf-8" ?> <!-- Exchange SQL Configuration - preliminary support --> <!-- %MAILBOXDATABASENAME% will be replaced by Exchange --> <!-- More information https://goo.gl/QiTtDo --> <configuration> <sectionGroup name="SqlMapiProviderGroup" type="Microsoft.Exchange.Data.SQL.SqlMapiProviderGroup, Microsoft.Exchange.Data.Common, Version=15.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"> <section name="SqlMapiProviderSection" type="Microsoft.Exchange.Data.SQL.SqlMapiProviderGroup, Microsoft.Exchange.Data.Common, Version=15.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> </sectionGroup> <runtime> <gcServer enabled="True" /> <generatePublisherEvidence="False" /> </runtime> <appSettings> <add key="MigrateMailboxesAutomatically" value="false" /> <!-- Not yet supported --> <add key="AllowJETBlueCoexistence" value="true" /> <!-- Allows for SQL/ESE Coexistence in DAG --> <add key="PerDatabaseMaxSize" value="1GB" /> <add key="VerboseLoggingEnabled" value="False" /> </appSettings> <SqlMapiProviderSection> <SqlMapiProvider> <add name="LobsterMapiDB" providerName="System.Data.SqlClient" connectionString="Data Source=SERVERNAME\INSTANCE;Initial Catalog=%MAILBOXDATABASENAME%;Integrated Security=True;MultipleActiveResultSets=True" /> </SqlMapiProvider> </SqlMapiProviderSection> </configuration>
CREATE LOGIN [DOMAIN\Exchange Trusted Subsystem] FROM WINDOWS
More can be found here:
Enjoy Exchange for the next 20 years...