On May 11th, the SharePoint Saturday Cologne took place at the new Microsoft Office in Cologne.
My session covered the migration of legacy public folders from Exchange Server 2010 to modern public folders hosted on-premises or Exchange Online. Additionally, I've talked about the pros and cons of a migration to Office 365 Groups and Microsoft Teams.
The slide deck is available on SlideShare.
Enjoy Exchange Server and do not forget about the end of support for Exchange Server 2010 on January 14th, 2010.
The Exchange PowerShell script (Set-ReceiveConnectorIpAddress) to add or remove remote IP address ranges to/from Exchange Server 2013+ receive connectors received an update.
The script now checks if the required PowerShell modules are available before failing to load the modules.
Get the most recent version at Github or TechNet Gallery
As always, enjoy Exchange Server On-Premises.
In Legacy Public Folder World with Exchange Server 2010 it was pretty easy to find the parent path of email enabled public folder:
(Get-MailPublicFolder MAILADRESS | Get-PublicFolder).ParentPath
When you try the same approach with modern public folders using Exchange Server 2013+ EMS, you receive an error.
Get-MailPublicFolder MSTeamsPF@varunagroup.de | Get-PublicFolder
Cannot process argument transformation on parameter 'Identity'. Cannot convert the "varunagroup.de/Microsoft
Exchange System Objects/MSTeamsPF" value of type "Microsoft.Exchange.Data.Directory.ADObjectId" to type
+ CategoryInfo : InvalidData: (MSTEamsPF:PSObject) [Get-PublicFolder], ParameterBindinmationException
+ FullyQualifiedErrorId : ParameterArgumentTransformationError,Get-PublicFolder
+ PSComputerName : P01.varunagroup.de
You need to use the EntryId paramater of the Get-MailPublicFolder result.
$pf = Get-MailPublicFolder MSTeamsPF@varunagroup.de
Get-PublicFolder -Identity $pf.EntryId
Name Parent Path
MSTeamsPF \Modern Collaboration
Get-PublicFolder does not take pipeline inputs.
Enjoy modern public folders :-)
When you install a Cumulative Update for Exchange Server 2016 you might receive the following informational message:
MAPI over HTTP, the preferred Outlook desktop client connectivity with Exchange server, is currently not enabled.
Consider enabling it using: Set-OrganizationConfig -MapiHttpEnabled $true
For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.WarnMapiHttpNotEnabl
This modern protocol for Outlook has been introduced to Exchange Server with Exchange Server 2013 SP1. The protocol removes the dependency to the Windows Server RPC over HTTP component. The reduced complexity enhances the reliability of the client access protocoll. It's available for quite some time now.
You can enable MAPI over HTTP on the organization level using the following Exchange cmdlet:
Set-OrganizationConfig -MapiHttpEnabled $true
You can still controll the protocol setting at the user level by deactiviting MAPI of HTTP for certain users, if required:
Set-CASMailbox -Identity [USER] -MapiHttpEnabled:$false
If your IT infrastructue is still not ready for MAPI of HTTP, your IT components pretty outdated. It's time to move forward and to modernize the infrastructure.
What are you reasons to not enable MAPI over HTTP? Let me know.
Enjoy Exchange Server 2016!
Exchange Server extends the Active Directory schema during the PrepareSchema step during setup. The steps PrepareAD, PrepareDomain, or PrepareAlLDomains create Active Directory containers and objects that are crucially important for a stable operation of Exchange Server.
There are different Active Directory objects that are used to determine, if Active Directory has a proper Exchange Server configuration up and running.
At Active Directory forest level the following attributes are used to determine the Exchange Server release:
At Active Directory domain level the following attribute is used to determine the Exchange Server release:
Enjoy Exchange Server!