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!
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
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...
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!
You might encounter EventId 106 errors on Exchange 2013/2016 servers.
There are some article available on how to fix this issue on servers having a full installationof Exchange Server 2013/2016.
But you might encounter this error on servers having the Exchange 2013/2016 Management Tools installed only as well. In this case the solutions described will not work as expected.
Running the New-PerfCounters cmdlet requires the Microsoft.Exchange.Management.PowerShell.Setup PowerShell snapin. This PowerShell snapin cannot be loaded on servers having the Exchange Management Tools installed.
Add-PsSnapin : The Windows PowerShell snap-in 'Microsoft.Exchange.Management.PowerShell.Setup' is not installed on this computer. At line:1 char:1 + Add-PsSnapin Microsoft.Exchange.Management.PowerShell.Setup + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidArgument: (Microsoft.Excha...owerShell.Setup:String) [Add-PSSnapin], PSArgumentEx ception + FullyQualifiedErrorId : AddPSSnapInRead,Microsoft.PowerShell.Commands.AddPSSnapinCommand
The required code library is available on servers having the Exchange Management Tools installed. But the library is not added to the registry by default.
Registry of a server running Exchange Management Tools only:
Registry of a fully installed Exchange Server:
Just export the registry key Microsoft.Exchange.Management.PowerShell.Setup from an Exchange Server, fix Exchange file paths (if required) and import the regiytry file on the server having the Exchange Management Tools installed.
Example registry file:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellSnapIns\Microsoft.Exchange.Management.PowerShell.Setup] "CustomPSSnapInType"="Microsoft.Exchange.Management.PowerShell.SetupPSSnapIn" "ApplicationBase"="D:\\Program Files\\Microsoft\\Exchange Server\\V15\\bin" "AssemblyName"="Microsoft.Exchange.PowerShell.Configuration, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" "Description"="Setup Tasks for the Exchange Server" "ModuleName"="D:\\Program Files\\Microsoft\\Exchange Server\\V15\\bin\\Microsoft.Exchange.PowerShell.configuration.dll" "PowerShellVersion"="1.0" "Vendor"="Microsoft" "Version"="15.0.0.0"
After adding the registry key, you can successfully fix the performance counter issue.
Add-PsSnapin Microsoft.Exchange.Management.PowerShell.Setup New-PerfCounters -DefinitionFileName "$exinstall\setup\perf\WorkerTaskFrameworkPerfCounters.xml”
When you've enabled the Exchange scripting agent extension agents, it is required to copy the configuration file to each Exchange server. Paul Cunningham's script helps you to achive this goal pretty easily.
But if you have installed the Exchange 2013 Management Tools on additonal servers, these servers are not fetched using the Get-ExchangeServer cmdlet. But when you install a Cumulative Update the existence of the extension agent config file is checked. And this even on a server having only the Exchange Management Tools installed.
Therefore the following PowerShell code provides an easy and simple way to add additonal server having the Exchange 2013+ Management Tools installed (aka Admin Servers, Monitoring Servers, Job Servers, etc.). The script uses a filter to select Exchange 2013 servers only, as the script has been extended in an environment having still active Exchange 2007 servers.
The following PowerShell snippet displays only the changes, which need to be added to Paul's original script starting row 68.
# Original PowerShell code # $exchangeservers = Get-ExchangeServer # Select all Exchange 2013 servers only, restrict properties to Name and AdminDisplayName $exchangeservers = Get-ExchangeServer | ?{$_.AdminDisplayVersion -like "Version 15.0*"} | Select Name, AdminDisplayVersion # Add additional servers as needed $manualServers = @() # Copy and modify as needed $manualServers += (New-Object PSObject -Property @{Name="EXSRV2010";AdminDisplayVersion="Version 14"}) $manualServers += (New-Object PSObject -Property @{Name="EXSRV2013-01";AdminDisplayVersion="Version 15"}) $manualServers += (New-Object PSObject -Property @{Name="EXSRV2013-02";AdminDisplayVersion="Version 15"}) # Combine arrays $exchangeservers = $exchangeservers + $manualServers # End Modification $report = @() [string]$date = Get-Date -F yyyyMMdd-HHmmss
Enjoy extending the Exchange PowerShell cmdlets.
Questions? Just leave a comment.
You have an Exchange Server 2016 organization and plan to upgrade to Cumulative Update 10. You log on to an Exchange Server, activate DAG maintenance and prepare the Server Component States for installing the new Cumulative Update.
You open an elevated PowerShell Session and start the Setup using
./Setup.exe /Mode:Upgrade /IAcceptExchangeServerLicenseTerms
Out of a sudden the Exchange Server CU Setup fails while executing setup step Stopping Services with an error:
Microsoft Exchange Server 2016 Cumulative Update 10 Unattended Setup Copying Files... File copy complete. Setup will now collect additional information needed for installation. Languages Management tools Mailbox role: Transport service Mailbox role: Client Access service Mailbox role: Unified Messaging service Mailbox role: Mailbox service Mailbox role: Front End Transport service Mailbox role: Client Access Front End service Performing Microsoft Exchange Server Prerequisite Check Configuring Prerequisites COMPLETED Prerequisite Analysis COMPLETED Configuring Microsoft Exchange Server Preparing Setup COMPLETED Stopping Services FAILED The following error was generated when "$error.Clear(); & $RoleBinPath\ServiceControl.ps1 -Operation:DisableServices -Roles:($RoleRoles.Replace('Role','').Split(',')) -SetupScriptsDirectory:$RoleBinPath; & $RoleBinPath\ServiceControl.ps1 -Operation:Stop -Roles:($RoleRoles.Replace('Role','').Split(',')) -IsDatacenter:([bool]$RoleIsDatacenter) " was run: "Microsoft.PowerShell.Commands.ProcessCommandException: Cannot stop process "fms (2496)" because of the following error: Access is denied ---> System.ComponentModel.Win32Exception: Access is denied at System.Diagnostics.ProcessManager.OpenProcess(Int32 processId, Int32 access, Boolean throwIfExited) at System.Diagnostics.Process.GetProcessHandle(Int32 access, Boolean throwIfExited) at System.Diagnostics.Process.get_HasExited() at Microsoft.PowerShell.Commands.StopProcessCommand.ProcessRecord() --- End of inner exception stack trace ---". The Exchange Server setup operation didn't complete. More details can be found in ExchangeSetup.log located in the <SystemDrive>:\ExchangeSetupLogs folder.
Why would an error like Access Denied happen while executing the Setup.exe as a member of the local Administrators security group from within an elevated PowerShell session?
The PowerShell code executed as part of the CU Setup sets the startup type of Exchange and some Windows services to Disabled. This ensures that in the case of a server reboot an automatic start of the service will not interfere partially executed the setup. After setting the startup type to Disabled the services are stopped.
The services are controlled by the ServiceControl.ps1 script which is located on the Exchange Server installation media in \Setup\ServerRoles\Common\.
The function StopServices stops services using the Stop-Service cmdlet. Due to some timing issues some services are stopped by killing the running processes using Stop-Process -Force.
The services stopped by stopping the running process are:
Executing the Stop-Process cmdlet results in the Access Denied error.
The issue is related to fact that the user account logged on the server and executing the Exchange Server Cumulatice Update does not have the local User Rights Assignment to Debug Programs.
By default the right to debug programs is assigned to the local Adminstrators security group. In secured Active Directory infrastructures the user rights assignments and local security groups are often managed using Group Policy Objects (GPO). The GPOs manage the names of local security groups, group memberships and even user rights assignments.
The client encountering the issue described above hasn't had any issues installing Cumulative Updates for Exchange Server 2013 in the past. So this is solution is related to the setup of Exchange Server 2016 Cumulative Updates on Windows Server 2016 only. If you have any information regarding Exchange Server 2013, let me know using the comments section below.
Enjoy Exchange Server!