WIth Exchange Server 2013 CU11 and Exchange 2016 CU1 the Exchange Product Group introduced a new feature named Mailbox Anchoring.
The workaround provided by Veritas in KB article 107463 recommends to set a new registry key for the NetBackup process responsible for running PowerShell queries.
There is no guarantee that this workaround will fix your backup issuesd with Exchange Server 2013 CU11 or Exchange Server 2016 CU1. It seems that the only workaround is by creating a new service account for NetBackup service due to rights assignments being removed during Exchange Server CU setup.
Steps required:
Enjoy classic backup with Exchange Server 2013 and Exchange Server 2016.
This is a post summarizing the configuration values for important Exchange-related Active Directory object attributes.
Whenever you need to look up these values for troubleshooting, or editing the values manually.
Note: You should not edit any of the values manually, just because you can. Edit any Exchange-related attributes, if you are familiar with the result of your changes.
Attribute
This script removes Active Directory objects for HealthMailboxes or SystemMailboxes in the Microsoft Exchange System Objects (MESO) container that do not have a homeMDB attribute set.
It is highly recommended to run the script with -WhatIf parameter to check objects first.
Information about accounts deleted or supposed to be deleted are written to a log file.
# EXAMPLE # Perform a WhatIf run in preparation to removing SystemMailboxes having an empty database attribute .\Remove-OrphanedMailboxAccounts.ps1 -SystemMailbox -WhatIf # EXAMPLE # Remove HealthMailbox(es) having an empty database attribute .\Remove-OrphanedMailboxAccounts.ps1 -HealthMailbox
2017-02-10 10:18: 11488 - Info - Script started 2017-02-10 10:18: 11488 - Info - WhatIf Preference: True 2017-02-10 10:18: 11488 - Info - Cleaning HealthMailboxes | 10 objects found 2017-02-10 10:18: 11488 - Info - Cleaning HealthMailboxes | Delete CN=HealthMailboxd32b165a6adf45518c8498fba3c7c93a,CN=Monitoring Mailboxes,CN=Microsoft Exchange System Objects,DC=granikoslabs,DC=de 2017-02-10 10:18: 11488 - Info - Cleaning HealthMailboxes | Delete CN=HealthMailbox6b66930902d8430e831df7b086bfd49b,CN=Monitoring Mailboxes,CN=Microsoft Exchange System Objects,DC=granikoslabs,DC=de 2017-02-10 10:18: 11488 - Info - Cleaning HealthMailboxes | Delete CN=HealthMailbox6bf99bdc31474217a6fdc4cd83260e88,CN=Monitoring Mailboxes,CN=Microsoft Exchange System Objects,DC=granikoslabs,DC=de 2017-02-10 10:18: 11488 - Info - Cleaning HealthMailboxes | Delete CN=HealthMailboxd4410bf131b34907b6a96a7e65263db1,CN=Monitoring Mailboxes,CN=Microsoft Exchange System Objects,DC=granikoslabs,DC=de 2017-02-10 10:18: 11488 - Info - Cleaning HealthMailboxes | Delete CN=HealthMailbox98f334580dbf457ca2a6d1a19fdf49d1,CN=Monitoring Mailboxes,CN=Microsoft Exchange System Objects,DC=granikoslabs,DC=de 2017-02-10 10:18: 11488 - Info - Cleaning HealthMailboxes | Delete CN=HealthMailboxc16704bf98c94f5e8453c7955d7897b5,CN=Monitoring Mailboxes,CN=Microsoft Exchange System Objects,DC=granikoslabs,DC=de 2017-02-10 10:18: 11488 - Info - Cleaning HealthMailboxes | Delete CN=HealthMailboxa64fe085bdff46a786d68782c5070bf1,CN=Monitoring Mailboxes,CN=Microsoft Exchange System Objects,DC=granikoslabs,DC=de 2017-02-10 10:18: 11488 - Info - Cleaning HealthMailboxes | Delete CN=HealthMailbox6c56f94506974a1183c6b71eebb63406,CN=Monitoring Mailboxes,CN=Microsoft Exchange System Objects,DC=granikoslabs,DC=de 2017-02-10 10:18: 11488 - Info - Cleaning HealthMailboxes | Delete CN=HealthMailbox9b6666d46aa746e3848f3240e418d731,CN=Monitoring Mailboxes,CN=Microsoft Exchange System Objects,DC=granikoslabs,DC=de 2017-02-10 10:18: 11488 - Info - Cleaning HealthMailboxes | Delete CN=HealthMailboxb2bd3d4725b249bab81eeed35666de0f,CN=Monitoring Mailboxes,CN=Microsoft Exchange System Objects,DC=granikoslabs,DC=de 2017-02-10 10:18: 11488 - Info - Script finished
These are the results of the Exchange Server Questionnaire from August 2021.
First of all, I want to thank all of you who participated in the questionnaire. The results are pretty interesting. Even though, that the results are not 100% representative they provide a high-level view of the Exchange Organizations, the mail flow configurations, and the future plans regarding hybrid and Exchange Online.
With 55 replies the questionnaire is far from being a comprehensive representation of the Exchange organizations. But the answers provide an idea of the Exchange landscape used by organizations globally.
Exchange Server 2016 is the dominant version currently in use, followed by Exchange Server 2019. The vast majority of 93% runs modern Exchange Server versions. But there are still older and unsupported Exchange Server versions in use. 7% use Exchange Server 2010 and older.
76% of the organizations maintain up to ten Exchange servers. 20% prefer to rely on just one Exchange server. It is interesting that only 2 (not percent) plan to go hybrid or to move to Exchange Online.
The majority of on-premises Exchange organizations are in the 1,000 - 10,000 mailboxes range. Nevertheless, the SMBs with 1 to 1,000 mailboxes adds up to 50% of the Exchange organizations that took part in this questionnaire. There are just a few organizations that host more than 50,000 mailboxes.
There are Exchange organizations that do not use an SMTP-Gateway solution as part of the mail-flow implementation. Thor organizations that do not use a gateway solution run 1 to 10 Exchange servers on-premises. The majority of those have less than 1,000 mailboxes but there are a few that are responsible for more than 1,000 mailboxes. That leaves the question of why an organization prefers to not secure mal-flow with a gateway.
The use of SMTP gateways is a must, as you do not want to expose your domain member servers to the Internet, not even for the SMTP protocol. A majority of 28 answers for other gateways shows, that there are so many products available and that I did not choose valid answer options upfront.
The Other answers include:
65% of the Exchange organizations of this questionnaire already run in a hybrid configuration with Exchange Online. Only 35% are (still) not using a hybrid setup.
Of those who currently do not run a hybrid configuration only 37% plan on implementing Exchange Hybrid or migrate fully to Exchange Online. Staying on-premises is the only option.
The majority of the organizations still running only an on-premises Exchange organization plan on implementing Exchange Hybrid or migrating to Exchange Online by the end of 2021. None of the participating organizations has plans scheduled after 2022.
It is no surprise that Classic Full Hybrid is the most adopted hybrid configuration. And, no surprise either, none of the other classic hybrid options is implemented. The modern hybrid approach is implemented but with lesser.
The reasons for staying with an on-premises Exchange organization vary. the reasons mentioned are:
There are still organizations that choose an on-premises Exchange organization in favor of Exchange Online. I wonder if company policies for reducing the carbon footprint might drive the migration of on-premises data center resources to hosted cloud services.
Exchange Server vNEXT is in scope for 47% of the organizations. When comparing it with the used Exchange Server version currently in use (~50% Exchange Server 2016) it is an indicator that some companies just skip Exchange Server 2019. Some organizations prefer not to follow the full life-cycle of Exchange Server. s7% of those who do not want to implement Exchange Server vNEXT and want to stay on-premises are single server implementations of Exchange.
The product Exchange Server is still widely used in on-premises deployments. The reasons vary from legal and compliance requirements, network bandwidth constraints, and the overall costs for Exchange Online. Exchange Server vNEXT is a must-have for nearly 50% of the organizations participating in this questionnaire. There are still older and unsupported versions in productive use. Why this is the case is unanswered in this questionnaire.
Organizations running a hybrid Exchange configuration primarily use a Classic Full Hybrid configuration. This might be due to an early implementation in those days when nothing else was available, or due to requirements using Microsoft Teams with on-premises mailboxes. The adoption of Modern Hybrid shows that the Hybrid Agent approach helps organizations that cannot implement a Classic Full Hybrid.
I leave the results of this questionnaire to your interpretation and look forward to your replies, either to this blog post or by social media on Twitter and LinkedIn. Please use the hashtag #ExchangeQuest2021.
There will be a new Exchange Server questionnaire in early 2022, covering various implementation scenarios in more detail. If you want to see a specific Exchange topic covered in the 2022 questionnaire, just let me know.
Again, thank you all for participating in this questionnaire.
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 Attendant entry vary depending on the version of the installed Exchange Server.
In regards to the 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.
Do 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
Migrating legacy public folders (Exchange Server 2010 or older) to modern public folders (Exchange 2013 or newer / Office 365) requires a cleanup of public folders.
There are quite a lot of blog posts and tutorials available describing the general process of migrating legacy public folders to modern public folders.
First you have to identify all public folders having a backslash "\" as part of the public folder name.
Get-PublicFolderDatabase | ForEach {Get-PublicFolderStatistics -Server $_.Server | Where {$_.Name -like "*\*"}}
Just rename those public folders to a name without a backslash.
Another issue might prevent a successful public folder migration: Access Controll Lists (ACL)
This will be the case in public folder hierarchies that go back to the early days of Exchange and have never cleaned up properly during past Exchange migrations.
The cleanup any orphaned Active Directory accounts, run the following PowerShell script.
Get-PublicFolder "\" -Recurse -ResultSize Unlimited | Get-PublicFolderClientPermission | ?{$_.User -like "NT User:S-1-*"} | %{Remove-PublicFolderClientPermission -Identity $_.Identity -User $_.User -Access $_.AccessRights -Confirm:$false}
To cleanup just a single public folder, run the following PowerShell script.
Get-PublicFolder "\My Folder" -Recurse -ResultSize Unlimited | Get-PublicFolderClientPermission | ?{$_.User -like "NT User:S-1-*"} | %{Remove-PublicFolderClientPermission -Identity $_.Identity -User $_.User -Access $_.AccessRights -Confirm:$false}
It should be noted that most of the tutorials have been written using an Exchange Server lab environment with just a few legacy public folders. Therefore, some readers tend to beleive that you only need one modern public folder mailbox. That is not true. In a large legacy public folder infrastructure you will end up with a multiple public folder mailboxes. And the number of mailboxes required to serve the public folder hierarchy.
A larger public folder migration batch using 66 public folder mailboxes looks like this:
Get-MigrationUser -BatchID PFMigration | Get-MigrationUserStatistics | ft -AutoSize Identity Batch Status Items Synced Items Skipped -------- ----- ------ ------------ ------------- PFMailbox1 PFMigration Synced 91993 16 PFMailbox2 PFMigration Synced 103239 0 PFMailbox46 PFMigration Synced 35034 0 PFMailbox56 PFMigration Synced 22554 0 PFMailbox57 PFMigration Synced 20740 0 PFMailbox58 PFMigration Synced 20122 0 PFMailbox59 PFMigration Synced 7209 0 PFMailbox60 PFMigration Synced 104727 0 PFMailbox61 PFMigration Synced 23278 0 PFMailbox62 PFMigration Synced 9760 0 PFMailbox63 PFMigration Synced 9277 0 PFMailbox65 PFMigration Synced 5870 0 PFMailbox64 PFMigration Synced 5639 0 PFMailbox66 PFMigration Synced 21261 0 PFMailbox50 PFMigration Synced 27889 0 PFMailbox52 PFMigration Synced 14063 0 PFMailbox47 PFMigration Synced 29476 0 PFMailbox54 PFMigration Synced 24283 0 PFMailbox55 PFMigration Synced 4646 0 PFMailbox51 PFMigration Synced 59943 0 PFMailbox53 PFMigration Synced 30052 0 PFMailbox49 PFMigration Synced 22746 0 PFMailbox48 PFMigration Synced 16941 0 PFMailbox18 PFMigration Synced 34307 0 PFMailbox19 PFMigration Synced 4523 0 PFMailbox11 PFMigration Synced 100409 0 PFMailbox6 PFMigration Synced 116655 0 PFMailbox4 PFMigration Synced 55240 5 PFMailbox12 PFMigration Synced 37790 0 PFMailbox3 PFMigration Synced 113842 2 PFMailbox22 PFMigration Synced 46416 0 PFMailbox23 PFMigration Synced 37387 0 PFMailbox13 PFMigration Synced 231845 1 PFMailbox7 PFMigration Synced 82859 0 PFMailbox20 PFMigration Synced 65818 0 PFMailbox21 PFMigration Synced 32270 0 PFMailbox9 PFMigration Synced 46609 0 PFMailbox14 PFMigration Synced 30637 0 PFMailbox38 PFMigration Synced 246428 1 PFMailbox43 PFMigration Synced 101837 0 PFMailbox45 PFMigration Synced 157571 0 PFMailbox44 PFMigration Synced 61763 0 PFMailbox40 PFMigration Synced 70637 1 PFMailbox41 PFMigration Synced 143042 0 PFMailbox42 PFMigration Synced 81254 0 PFMailbox39 PFMigration Synced 68876 2 PFMailbox15 PFMigration Synced 58221 0 PFMailbox27 PFMigration Synced 28065 0 PFMailbox24 PFMigration Synced 31869 1 PFMailbox5 PFMigration Synced 64125 0 PFMailbox30 PFMigration Synced 72938 1 PFMailbox33 PFMigration Synced 32545 1 PFMailbox31 PFMigration Synced 93782 0 PFMailbox32 PFMigration Synced 28743 0 PFMailbox25 PFMigration Synced 100794 0 PFMailbox26 PFMigration Synced 35412 0 PFMailbox28 PFMigration Synced 27003 0 PFMailbox29 PFMigration Synced 80510 0 PFMailbox17 PFMigration Synced 97952 1 PFMailbox8 PFMigration Synced 18601 0 PFMailbox34 PFMigration Synced 87150 0 PFMailbox35 PFMigration Synced 31531 0 PFMailbox36 PFMigration Synced 37979 0 PFMailbox37 PFMigration Synced 95770 0 PFMailbox10 PFMigration Synced 14193 0 PFMailbox16 PFMigration Synced 64323 1
Enjoy (modern) public folders.
You need assistance with your Exchange Server setup? You have questions about your Exchange Server infrastructure and going hybrid with Office 365? Contact us at office365@granikos.eu or visit our website https://www.granikos.eu.
When you use Symantec NetBackup 7.x you might encounter Error 5, when you try to restore an Exchange Server 2013 DAG mailbox database backup to a Recovery database or to the original datrabase.
The error message in Backup, Archive, and Restore Tool looks similar to this
Enabling NetBackup debug logging by using the mklogdir.bat file located in C:\Program Files\Veritas\NetBackup\logs does not necessarily provide additional input. The restore job fails before entering the job section for local restore activities. So no TAR log is being created.
When following the NetBackup Admin Guide and several Symantec HowTo’s you have already configured the following two services to run using a dedicated Service Account
There are some circumstances (not clearly defined by Symantec) when an additional NetBackup Service performs Exchange PowerShell commands as part of a restore process. Therefore the following NetBackup service must be configured to run using the same Service Account as the other two NetBackup services.
In addition be aware that the Service Account required Debug permission on the Exchange Server. It might be helpful to propagate the permissions for the Service Account using a GPO.