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
Sometimes you need to know the version of the installed .NET Framework version quickly.
Simply use the following PowerShell one-liner:
(Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full' ).Release
Enjoy!
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.
You can block an user from logging on to Office 365 by setting the BlockCredential attribute to $true.
Set-MsolUser -UserPrincipalName myuser@mcsmemail.de -BlockCredential $true
But the MSOL user attribute is reverted to $false, when ADD Connect synchonization cycle runs.
This happens, because the local Active Directory attribute accountEnabled is used to controll the BlockCredential attribute in Azure AD.
If your IT operation requires the ability to have enabled users in your local Active Directory infrastructure and you need to prevent logon to cloud services you need to prevent the accountEnabled attribute from being synchronized to Azure AD. This might not necessarily be a general requirement during normal operations, but might be useful while doing a Proof-of-Concept.
Just exclude the attribute from the Azure Active Directory connector in the Synchronization Service Manager.
The following script disables all users excluding
# Userfilter $UserExceptions = ("Sync_SYNC01_add98768492f@mcsmemail.onmicrosoft.com","SPO-SRV-ACCOUNT@mcsmemail.de","SynchedAdmin@mcsmemail.de") # Fetch synchronized users $DomainAccounts = Get-MsolUser -EnabledFilter EnabledOnly -MaxResults 5000 | Where-Object -Property LastDirSyncTime -ne $null # Select synchronized users not following the pattern ADM*@mcsmemail.de (admin accounts in this case) $DomainAccountsWithoutAdmins = $DomainAccounts | Where-Object -Property UserPrincipalName -notlike "ADM*@mcsmemail.de" # Exclude accounts listed in $UserExceptions $DomainAccountsWithoutAdminsFiltered = $DomainAccountsWithoutAdmins | Where-Object -Property UserPrincipalName -NotIn $UserExceptions # Now block cloud logon for all filtered users ForEach ($User2Block in $DomainAccountsWithoutAdminsFiltered) { Write-Host ('Disabling User: {0}.UserPrincipalName)' -f $User2Block) Set-MsolUser -UserPrincipalName $User2Block.UserPrincipalName -BlockCredential $true }
Enjoy Office 365.
Public folders are one solution to provide a team collaboration tool for companies. Legacy public folders utilized a proprietary multi-master replication mechanism which was not planned to handle today's data volumes. Therefore, Exchange 2013 introduced modern public folders which utilize the robust DAG replication functionality. Due to the technology change between legacy public folders and modern public folders a migration is required.
You can migrate legacy public folders hosted on Exchange 2007 or Exchange 2010 to modern public folders hosted on Exchange 2013. Or you can migrate legacy public folders hosted on Exchange 2010 to modern public folders hosted on Exchange 2016. If a cloud migration is a viable option for your company, you are able to migrate legacy public folders hosted on Exchange 2007 or Exchange 2010 to modern public folders hosted in Exchange Online.
The requirements for legacy Exchange Servers are:
Since Exchange Server 2013 RTM the public folder migration scripts and the migration guidance have quite often been updated. The information provided at TechNet is very detailed for each migration option and there is no need to repeat each step in this blog post. Please see the link section for all hyperlinks.
Preparing a legacy public folder migration is pretty straight forward. The main issue companies are facing is the required downtime for finalizing the public folder migration batch. The required downtime cannot be determined exactly (not as exactly as requested by upper management). This means that you have to plan for scheduled maintenance during off-hours. In the past, a single migration request has been used to migrate legacy public folders. The new batch approach migrates public folder content using multiple requests within a single batch.
The Create-PublicFolderMailboxesForMigration.ps1 script uses the parameter EstimatedNumberOfConcurrentUsers to determine the overall number of public folder mailboxes serving the hierarchy. The TechNet articles explain this parameter as follows:
The estimated number of simultaneous user connections browsing a public folder hierarchy is usually less than the total number of users in an organization.
Exchange Server 2013 and Exchange Server 2016 currently support 2.000 concurrent connections to a single mailbox. This limit (2.000) is used by the Create-PublicFolderMailboxesForMigration.ps1 in conjunction with EstimatedNumberOfConcurrentUsers to determine the number of public folder mailboxes required to serve the public folder hierarchy. The current version of the script uses a coded limit of max 100 public folder mailboxes. This means that you can only serve 100 x 2.000 = 200.000 concurrent users accessing the public folder hierarchy.
Finalizing the migration request and setting the PublicFolderMigrationComplete attribute requires the legacy public folder information store to be restarted. Otherwise, the configuration change will not be picked up in the information store in a timely fashion. Remember to restart the information store service on all legacy public folder servers.
If your current public folder infrastructure is based on Exchange 2007 and you want to get rid of that Exchange version, you might think of replicating all content to Exchange 2010. This is not the best approach. Due to known content conversion issues, you might encounter data loss when replicating public folder content between Exchange 2007 and Exchange 2010.
The recommended approach is to migrate Exchange 2007 legacy public folders to Exchange 2013 modern public folders directly.
A recommended reading on legacy public folder migration from Exchange 2010 to Exchange 2016 is Butch Waller’s blog post “Migration to Modern Public Folders – Notes from the Field”
The PowerShell script referenced in that blog post does not work with Exchange 2007. You can use my PowerShell script which utilizes UTF8 encoding and runs with Exchange 2007 and Exchange 2010: https://gallery.technet.microsoft.com/Exchange-2010-Public-315ea9aa
Remark All limits mentioned in this post reflect the information available at the time of writing.
Do 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.
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.
At a recent troubleshooting case I was wondering why the pipeline tracing target directory remained empty after enabling the Exchange 2013 CU12 transport pipeline tracing using
Set-TransportService -PipelineTracingSenderAddress john.doe@mcsmemail.de -PipelineTracingEnabled $true
In this case the sender address itself was John.Doe@MCSMemail.de.
In past scenarios the email address to trace was copied from the original message and therefore this issue never occured.
After heading down the road on why no trace messages got logged in the pipeline tracing folder, and enabling and disabling the feature several times across multiple servers, the sender address made it's way into the cmdlet via Copy&Paste. And voilá... transport started tracing messages.
Set-TransportService -PipelineTracingSenderAddress John.Doe@MCSMemail.de -PipelineTracingEnabled $true
The TechNet article on pipeline tracing does not state anything about the fact that the email address attribute is case sensitive.
If you want to enable or disable pipeline tracing across multiple Exchange 2013 servers, you might want to use the following one-liners:
# One liner to activate Pipeline Tracing on multiple Exchange 2013 servers in a co-ex scenario Get-ExchangeServer | ?{$_.AdminDisplayVersion -ilike "*15*"} | Get-TransportService | Set-TransportService -PipelineTracingEnabled $true -PipelineTracingSenderAddress John.Doe@MCSMemail.de # One liner to deactive Pipeline Tracing across multiple Exchange 2013 servers Get-ExchangeServer | ?{$_.AdminDisplayVersion -ilike "*15*"} | Get-TransportService | Set-TransportService -PipelineTracingEnabled $false -PipelineTracingSenderAddress $null
Not mention that the output stored in the pipeline tracing folders might be sensitive, as all data is stored in a readable format.
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