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 "Microsoft.Exchange.Configuration.Tasks.PublicFolderIdParameter". + 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 ed.aspx
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!
The script can be used to assign an application account (e.g. CRM, ERP) send-as permission to user mailboxes to send emails AS the user and not as the application.
This script loops through a membership list of an Active Directory security group. A single mailbox (CRM/ERP service account mailbox) is added to each mailbox (CRM/ERP user mailbox) of the security group members to provide send-as permission.
The script has been developed as a solution to enable proper functionality with Dynamics NAV 2016.
# Assign Send-As permission to crmapplication@varunagroup.de for all members # of 'CRM-FrontLine' security group. The mailboxes as hosted On-Premises! .\Set-SendAsPermission.ps1 -SendAsGroup 'CRM-FrontLine' -SendAsUserUpn 'crmapplication@varunagroup.de'
# Assign Send-As permission to ax@granikoslabs.eu for all members of 'AX-Sales' # security group. All mailboxes are hosted in Exchange Online! .\Set-SendAsPermission.ps1 -SendAsGroup 'AX-Sales' -SendAsUserUpn 'ax@granikoslabs.eu' -ExchangeOnline
The Excel workbook Public-Folder-Migration-Actionplan-EN.xlsx spreadsheet is supposed to support you during a migration of Legacy Public Folders (Exchange Server 2010) to Modern Public Folders in Exchange Online.
The workbook consists of three spreadsheets:
If you encounter any issues while preparing for migration or during migration of public folder, I recommend to check the Exchange Server Techcommunity Forum.
Enjoy Exchange Public Folders!
You have an Exchange Server 2016 organization and plan to upgrade to Cumulative Update 10. You log on to an Exchange Server, activate DAG maintenance and prepare the Server Component States for installing the new Cumulative Update.
You open an elevated PowerShell Session and start the Setup using
./Setup.exe /Mode:Upgrade /IAcceptExchangeServerLicenseTerms
Out of a sudden the Exchange Server CU Setup fails while executing setup step Stopping Services with an error:
Microsoft Exchange Server 2016 Cumulative Update 10 Unattended Setup Copying Files... File copy complete. Setup will now collect additional information needed for installation. Languages Management tools Mailbox role: Transport service Mailbox role: Client Access service Mailbox role: Unified Messaging service Mailbox role: Mailbox service Mailbox role: Front End Transport service Mailbox role: Client Access Front End service Performing Microsoft Exchange Server Prerequisite Check Configuring Prerequisites COMPLETED Prerequisite Analysis COMPLETED Configuring Microsoft Exchange Server Preparing Setup COMPLETED Stopping Services FAILED The following error was generated when "$error.Clear(); & $RoleBinPath\ServiceControl.ps1 -Operation:DisableServices -Roles:($RoleRoles.Replace('Role','').Split(',')) -SetupScriptsDirectory:$RoleBinPath; & $RoleBinPath\ServiceControl.ps1 -Operation:Stop -Roles:($RoleRoles.Replace('Role','').Split(',')) -IsDatacenter:([bool]$RoleIsDatacenter) " was run: "Microsoft.PowerShell.Commands.ProcessCommandException: Cannot stop process "fms (2496)" because of the following error: Access is denied ---> System.ComponentModel.Win32Exception: Access is denied at System.Diagnostics.ProcessManager.OpenProcess(Int32 processId, Int32 access, Boolean throwIfExited) at System.Diagnostics.Process.GetProcessHandle(Int32 access, Boolean throwIfExited) at System.Diagnostics.Process.get_HasExited() at Microsoft.PowerShell.Commands.StopProcessCommand.ProcessRecord() --- End of inner exception stack trace ---". The Exchange Server setup operation didn't complete. More details can be found in ExchangeSetup.log located in the <SystemDrive>:\ExchangeSetupLogs folder.
Why would an error like Access Denied happen while executing the Setup.exe as a member of the local Administrators security group from within an elevated PowerShell session?
The PowerShell code executed as part of the CU Setup sets the startup type of Exchange and some Windows services to Disabled. This ensures that in the case of a server reboot an automatic start of the service will not interfere partially executed the setup. After setting the startup type to Disabled the services are stopped.
The services are controlled by the ServiceControl.ps1 script which is located on the Exchange Server installation media in \Setup\ServerRoles\Common\.
The function StopServices stops services using the Stop-Service cmdlet. Due to some timing issues some services are stopped by killing the running processes using Stop-Process -Force.
The services stopped by stopping the running process are:
Executing the Stop-Process cmdlet results in the Access Denied error.
The issue is related to fact that the user account logged on the server and executing the Exchange Server Cumulatice Update does not have the local User Rights Assignment to Debug Programs.
By default the right to debug programs is assigned to the local Adminstrators security group. In secured Active Directory infrastructures the user rights assignments and local security groups are often managed using Group Policy Objects (GPO). The GPOs manage the names of local security groups, group memberships and even user rights assignments.
The client encountering the issue described above hasn't had any issues installing Cumulative Updates for Exchange Server 2013 in the past. So this is solution is related to the setup of Exchange Server 2016 Cumulative Updates on Windows Server 2016 only. If you have any information regarding Exchange Server 2013, let me know using the comments section below.
Enjoy Exchange Server!