Today is a wonderful day.
I just received the notification email that I am awarded as a MVP for Office Servers and Services.
Looking forward to interesting times with the other fellow MVPs, MCM and MCSM colleagues.
Thanks.
SharePoint Conference North America is just 4 weeks away! Now is a great time to register and make your plans to BE THERE in Las Vegas.
See the schedule, available now, with over 160 sessions to immerse yourself each day on what you need to know about SharePoint, OneDrive, Yammer, Microsoft Teams, and Office 365. Check out The Road to @SPConf, which reveals the inside scoop about SharePoint Conference North America and what you can expect with the return of the SharePoint community.
Register today | Don't miss the conference
Exchange Server 2016 introduced the PowerShell cmdlet Get-MailboxServerRedundancy. This cmdlet helps you plan and prepare for Exchange Server maintenance by querying the current maintenance readiness of the database availability group (DAG).
Interestingly, there is no PowerShell help available for this vital cmdlet. Microsoft Docs or Exchange Management Shell's Get-Help provide any valuable information.
When querying a DAG about the server redundancy status, the cmdlet's default output provides you with the essential information.
The default output contains information about:
This example shows the Get-MailboxServerRedundancy output of a six server DAG, before activating maintenance mode for server LOCEXS06.
Get-MailboxServerRedundancy -DatabaseAvailabilityGroup EXDAG01 Identity IsServerFound IsInMainten RepairUrgency SafeForMaintenance HealthInfoLastUpdateTime InAD ance -------- ------------- ----------- ------------- ------------------ ------------------------ LOCEXS01 True False Prohibited False 17.02.2020 09:10:11 LOCEXS02 True False Normal True 17.02.2020 09:10:11 LOCEXS03 True False Normal True 17.02.2020 09:10:11 LOCEXS06 True False Normal True 17.02.2020 09:10:11 LOCEXS05 True False Normal True 17.02.2020 09:10:11 LOCEXS04 True False Prohibited False 17.02.2020 09:10:11
As Exchange Administrator, you are most interested in the information displayed in columns RepairUrgency and SafeForMaintenance.
As you can see in this screenshot, no server is in maintenance mode. Servers S01 and S04 have a RepairUrgency state of Prohibited, and a SafeForMaintenance state of False. The latter tells us that we cannot activate maintenance mode for servers safely without risking mailbox database redundancy.
What is the reason for this? Let's have a look.
You can use the same cmdlet to query detailed information for each member server of the DAG. The default output for a single server does not provide any additional information on the server status.
Get-MailboxServerRedundancy -DatabaseAvailabilityGroup EXDAG01 -Identity LOCEXS01 Identity IsServerFound IsInMainten RepairUrgency SafeForMaintenance HealthInfoLastUpdateTime InAD ance -------- ------------- ----------- ------------- ------------------ ------------------------ LOCEXS01 True False Prohibited False 17.02.2020 09:11:11
Because we cannot activate maintenance mode for server LOCEXS01 safely, we are interested in identifying which redundancy state is responsible.
You can find this information by displaying the detailed server information.
Use the Format-List, or short FL, cmdlet to display the Get-MailboxServerRedundancy cmdlet output as a formatted list.
Get-MailboxServerRedundancy -DatabaseAvailabilityGroup EXDAG01 -Identity LOCEXS01 | FL RunspaceId : 70d82f8d-e6ca-4bfc-863f-11300a9784ff Identity : LOCEXS01 IsServerFoundInAD : True IsInMaintenance : False RepairUrgency : Prohibited SafeForMaintenance : False ServerContactedFqdn : LOCEXS04.VARUNAGROUP.DE HealthInfoCreateTime : 15.06.2018 15:16:19 HealthInfoLastUpdateTime : 17.02.2020 09:11:11 ServerFoundInAD : CurrentState: Active; LastActiveTransition: 15.06.2018 15:22:16; LastInactiveTransition: InMaintenance : CurrentState: Inactive; LastActiveTransition: 17.01.2020 09:07:02; LastInactiveTransition: 17.01.2020 10:42:02 AutoActivationPolicyBlocked : CurrentState: Inactive; LastActiveTransition: 09.01.2020 10:14:50; LastInactiveTransition: 09.01.2020 11:00:51 ActivationDisabledAndMoveNow : CurrentState: Inactive; LastActiveTransition: ; LastInactiveTransition: 15.06.2018 15:22:16 HighAvailabilityComponentStateOffline : CurrentState: Inactive; LastActiveTransition: 17.01.2020 09:07:02; LastInactiveTransition: 17.01.2020 10:42:02 CriticalForMaintainingAvailability : CurrentState: Inactive; LastActiveTransition: 31.01.2020 16:52:49; LastInactiveTransition: 31.01.2020 16:56:49 CriticalForMaintainingRedundancy : CurrentState: Active; LastActiveTransition: 29.01.2020 11:43:06; LastInactiveTransition: 29.01.2020 11:42:06 PotentiallyCriticalForMaintainingRedundancy : CurrentState: Active; LastActiveTransition: 01.02.2020 05:49:37; LastInactiveTransition: CriticalForRestoringAvailability : CurrentState: Inactive; LastActiveTransition: 06.05.2019 09:16:36; LastInactiveTransition: 06.05.2019 09:20:36 CriticalForRestoringRedundancy : CurrentState: Inactive; LastActiveTransition: 29.01.2020 11:42:06; LastInactiveTransition: 29.01.2020 11:43:06 HighForRestoringAvailability : CurrentState: Inactive; LastActiveTransition: 29.01.2020 11:42:06; LastInactiveTransition: 29.01.2020 11:43:06 HighForRestoringRedundancy : CurrentState: Inactive; LastActiveTransition: 10.02.2020 09:05:02; LastInactiveTransition: 10.02.2020 09:06:02 IsSafeForMaintenance : CurrentState: Inactive; LastActiveTransition: 03.11.2019 09:42:35; LastInactiveTransition: 12.11.2019 06:29:58 IsValid : True ObjectState : Unchanged
The lines 24-27 show the information we want to know. Both, the CriticalForMaintainingRedundancy and PotentiallyCriticalForMaintainingRedundancy parameters have a CurrentState value of Active. The Primary Activation Manager (PAM) considers the server availability critical to provide redundant availability of the database copies hosted by this server.
Each of state-parameter shows three pieces of information:
But there is still the bothering question of why are two of the six servers not safe for activating maintenance?
The reason is simple. The mailbox databases mounted by the member servers of the DAG have a different number of database copies. This configuration is due to data storage capacity constraints.
The mailbox databases storing primary user mailboxes use four database copies per database. Those copies are evenly distributed across all six mailbox servers. Mailbox database storing online archive mailboxes use three copies per database. This database copy layout allows for safely activating server maintenance for one server at a time without risk to database redundancy.
The servers LOCEXS01 and LOCEXS04 hold mailbox databases with just two copies per configured database. Placing one of those two servers into maintenance mode reduces the database availability for these mailbox databases to one. Therefore, PAM informs us that database redundancy is at risk when activating maintenance for those two servers.
This example shows the member server redundancy state while LOCEXS06 is in maintenance. The reason for monthly maintenance for installing Windows updates.
Maintenance was activated using the StartDagServerMaintenance.ps1 PowerShell script.
Get-MailboxServerRedundancy -DatabaseAvailabilityGroup indag01 Identity IsServerFound IsInMainten RepairUrgency SafeForMaintenance HealthInfoLastUpdateTime InAD ance -------- ------------- ----------- ------------- ------------------ ------------------------ LOCEXS01 True False Prohibited False 17.02.2020 11:04:12 LOCEXS02 True False Normal True 17.02.2020 11:04:12 LOCEXS03 True False Prohibited False 17.02.2020 11:04:12 LOCEXS06 True True High True 17.02.2020 11:04:12 LOCEXS05 True False Prohibited False 17.02.2020 11:04:12 LOCEXS04 True False Prohibited False 17.02.2020 11:04:12
Having a single server in maintenance has a significant impact on all other servers in the DAG. The servers LOCEXS03 and LOCEXS05 are not safe for maintenance as well. Activating maintenance for those two servers would affect the database redundancy for the databases hosted by those two servers.
After completing all maintenance tasks, e.g., installing Windows Updates or a new Exchange Server Cumulative Update, you end server maintenance using the PowerShell script StopDagServerMaintenance.ps1.
We query the server redundancy state again.
Get-MailboxServerRedundancy -DatabaseAvailabilityGroup indag01 Identity IsServerFound IsInMainten RepairUrgency SafeForMaintenance HealthInfoLastUpdateTime InAD ance -------- ------------- ----------- ------------- ------------------ ------------------------ LOCEXS01 True False Prohibited False 17.02.2020 11:23:12 LOCEXS02 True False Normal True 17.02.2020 11:23:12 LOCEXS03 True False Normal True 17.02.2020 11:23:12 LOCEXS06 True False High True 17.02.2020 11:23:12 LOCEXS05 True False Normal True 17.02.2020 11:23:12 LOCEXS04 True False Prohibited False 17.02.2020 11:23:12
Server LOCEXS06 is not in maintenance, but the RepairUrgency state is High. The local Exchange Server replication engine is still busy replicating and processing log files, and updating the search indices. When CopyQueueLength and ReplayQueueLength are back to 0, and ContentIndexStates are back to Healthy, the RepairUrgency switches to Normal.
You receive an error message when activating maintenance for an Exchange Server not safe for maintenance using StartDagServerMaintenance.ps1 -serverName [SERVER] In this case, you must use:
.\StartDagServerMaintenance.ps1 -serverName SERVERNAME -overrideMinimumTwoCopies:$true
Enjoy Exchange Server!
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!
When you migrate messages from an alternative email solution (e.g. Lotus Notes) you might migrate sensitive content that must stay private in the new Exchange Server target location.
So how can you mark such messages as private?
The privacy level (Sensitivity) of a mailbox item is controlled by MAPI extended property 0x36.
The command line tool searches for messages containing a given text as a subject substring.
The c# code sets the extended property 0x36 to 2.
A mailbox is accessed using Exchange Web Services. The EWS endpoint is discovered using AutoDiscover for the selected mailbox.
The item modification is handled by the following code segment:
foreach (var extendedProperty in Message.ExtendedProperties) { if (extendedProperty.PropertyDefinition == extendedPropertyDefinition) { if (log.IsInfoEnabled) { log.Info(string.Format("Try to alter the message: {0}", Message.Subject)); } else { Console.WriteLine("Try to alter the message: {0}", Message.Subject); } // Set the value of the extended property (0 is Sensitivity normal, 2 would be private) Message.ExtendedProperties[extendedPropertyindex].Value = 2; // Update the item on the server with the new client-side value of the target extended property Message.Update(ConflictResolutionMode.AlwaysOverwrite); } extendedPropertyindex++; }
SetPrivateFlags.exe -mailbox user@domain.com -subject "[private]"
Search the mailbox for all messages having a subject string containing [private] and ask for changing each item if -logonly is not set to true. If -logonly is set to true only a log will be created.
SetPrivateFlags.exe -mailbox user@domain.com -subject "[private]" -noconfirmation
Search the mailbox for all messages having a subject string containing [private] and change all found messages without confirmation.
It should be noted that this solution is intended for use in migration scenarios.
When providing access to mailbox delegates you can enable access to your private elements as well. But access to shared mailboxes is not configured using the delegation workflow.
The code has been tested using Exchange Server 2013 CU15.
The program utilizes log4net to log detailed information to the file system. The configuration is controlled by the application's config file.
Any issues or feature requests? Use Github.
Like the code? Leave a note.
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.
It happend again.
A new .Net Framework version has been released via the Windows Update distribution channel and the Exchange Server Team has decided to skip support for the new release.
You're only option is to block the automatic installation by the local Windows Update Agent using a registry.
The follow BlockNetFramework472.reg file simplifies setting the registry key.
As always... Enjoy Exchange Server