Thomas Stensitzki is a principal technology consultant focusing on the Microsoft messaging and collaboration technologies and the owner of Granikos GmbH & Co. KG.
He was awarded as MVP for Office Apps & Services in 2018.
He holds Master certifications as Microsoft Certified Solutions Master Messaging and as Microsoft Certified Master for Exchange Server 2010. This makes him a subject matter expert for any messaging topic related to Microsoft Exchange, Exchange Online, Microsoft 365, and Hybrid configurations.
Follow Thomas on: Google+, LinkedIn, Twitter
My sessions: https://sessionize.com/thomas-stensitzki
Personal blog: http://justcantgetenough.granikos.eu
Personal blog (legacy): http://www.sf-tools.net
Personal website: http://www.stensitzki.de
Contact Thomas at firstname.lastname@example.org
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.
When you mail enable an Exchange legacy public folder, a system object is created in Active Directory which is stored in the so called MESO object container
The object created contains all required attributes for Exchange address lists and other Exchange attributes.
When you mail disable a public folder Exchange Server is supposed to delete the MESO object as well. For some reason that might not happen. In this case the public folder will show in Public Folder Management Console as mail disabled, is still capable of receiving emails sent to its email address.
From an Exchange perspective, the email address can still be resolved, because a system object containing the email address still exists.
At first it looked like a permission issue on the MESO object container, but it wasn’t.
A Microsoft KB article described the issue for a single forest, multi-domain environment and a similar issue with Exchange Server 2010.
Configure the following registry on each Exchange Server hosting a public folder database and restart the MSExchangeIS service.
In addition you should name the public folder and domain controller in the Exchange cmdlet
Enable-MailPublicFolder “\Public Folder Name” –Server PUBLICFOLDERSERVER –DomainController DC01
When you mail enable an exisiting public folder which looks like being mail disabled, but still having an (old) MESO object, a new MESO object will be created. The situation will be as follows:
The result is not necessarily as expected, as the old MESO object is orphaned an never reconfigured again.
Orphaned objects need to be cleaned up manually and beeing recreated again, if necessary. In an Exchange environement that has been migrated from ancient versions to 2010, you might already have a lot of MESO objects having digits added to their common names.
You can cleanup the MESO obejcts as follows:
This results in a correctly named and configured MESO object. You can use Bill Long’s PowerShell script to identify orphaned public folder objects in the MESO container.
This information is related to legacy Exchange public folders being hosted on Exchange Server 2007 and/or Exchange Server 2010.
The solution has been validated for Exchange Server 2007 as well, even though the KB article has been published for Exchange Server 2010 only.
This post had originally been posted at my former blog SF-Tools.
You need assistance with your Exchange Server setup? You have questions about your Exchange Server infrastructure and going hybrid? You are interested what Exchange Server 2016 has to offer for your environment?
Contact me at email@example.com
Follow at https://twitter.com/stensitzki
Given Microsoft’s success in building Exchange Online running on its Office 365 cloud platform, it has undoubtedly learned a few valuable lessons that can be applied to on-premises deployments.
In this whitepaper, ENow board member and Microsoft Exchange MVP Tony Redmond reveals how standardization, automation and monitoring played into Microsoft’s success with scaling its platform.
Download the Whitepaper here: http://enowsoftware.com/whitepaper/Improve-Your-Exchange-Deployment-by-Learning-from-Massive-Scale.pdf
Are you unsure, if you should migrate to Office 365? You want to know more about security of cloud applications and services? Your Exchange Server infrastructure requires an upgrade? Contact me via email: firstname.lastname@example.org
A new community PowerShell script to simplify Exchange Server mailbox migrations has been published to TechNet Gallery and Github.
See script help for examples.
Checkout the professional services provided by Granikos for planning and migration your exisiting Exchange Server infrastructure to the cloud. Protect your cloud services using the CloudSOC™ technology provided by Elastica.
PowerShell module providing centralizied logging and other helpful functions.
$ScriptDir = Split-Path $script:MyInvocation.MyCommand.Path
$ScriptName = $MyInvocation.MyCommand.Name
# Create a new logger object, keeping the last 14 days of log files
$logger = New-Logger -ScriptRoot $ScriptDir -ScriptName $ScriptName -LogFileRetention 14
# Write a new informational message to the log file
$logger.Write('My Log Message')
# Write an error message to the log file
$logger.Write('My custom error message')
# Write a warning message to the log file
$logger.Write('My custom warning')
# Send a log file by email at the end of your script
$logger.SendLogFile('email@example.com', 'firstname.lastname@example.org', 'smtpserver.mcsmemail.de')
You can "install" a PowerShell module by copying the module to a sub folder of the same name as the module in either of the two following locations:
PS C:\> $env:PSModulePath
Create a new folder named GlobalFunctions in C:\Program Files\WindowsPowerShell\Modules
Copy the GlobalFunctions.psm1 file to C:\Program Files\WindowsPowerShell\Modules\GlobalFunctions
These steps assume that you use a dedicated PowerShell scripts folder, e.g. D:\MyScripts
Close the current PowerShell window and open a new PowerShell window. That's it.
When using PowerShell 5, you can simply use the following PowerShell command from within an administrative PowerShell window.
When a new version of the GlobalFunctions module has been released, use the following PowerShell command to update the module.