Just can't get enough of IT

Problem

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?

Issue

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:

• FMS
• MSExchangeServiceHost
• MSExchangeTransport
• MSExchangeInferenceService
• MSExchangeDagMgmt

Executing the Stop-Process cmdlet results in the Access Denied error.

Solution

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.

• To avoid the error described above you must ensure that the group of Exchange Administrators that install Exchange Server Cumulative Updates has the user rights assignment to debug programs.

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!

The PowerShell script to Set mailbox quotas at database or mailbox level the simple way has been updated to Version 1.4.

The code has been refactored to functions and has received some PowerShell hygiene patters.

Please report any issues directly at Github.

If you like the script, please rate the script at TechNet Gallery.

Enjoy!

As an Exchange administrator you normally perform tasks by executing PowerShell scripts. Some of these scripts are executed automatically, some are run manually as these scripts require more attention.

Think about a completely different approach. Have you ever thought about administrating Exchange Server or your Exchange Online instance using your voice?

Thanks to Alexa skills we can do something like

"Alexa, ask Exchange Assistant to create a new mailbox for John Doe"

"Alexa, is the CEO's mailbox in good shape?"

Or run something more complicated

"Alexa, start Exchange to setup 5 new Exchange servers, please"

Sounds like magic, right?

Solution

As a solution we use the following technologies:

• Alexa custom skills extension for Exchange
• Azure subscription supporting
  • Azure Web API
  • Azure Automation
• Azure Hybrid Runbook Worker

The Azure Hybrid Runbook Worker enables you to execute PowerShell runbooks in your local infrastructure to manage local ressources.

How does it work

The solution consists of a Visual Studio Solution acting as an Alexa skill endpoint. The configured intents connect to your Azure Automation webhooks and trigger the execution of preconfigured PowerShell automation runbooks.

These runbooks can either run againt Azure resources or against your local infrastructure. Automation of your local infrastructure requires the setup of the Azure Hybrid Runbook Worker components.

The following diagram illustrates the functionality.

Requirements

• You need to have an Amazon Alexa device
• You need to have an Amazon Alexa Developer account
• You need to have an active Microsoft Azure subscription
• You need to deploy the Hybrid Runbook Worker component in your local infrastructure, if you want to automate your local infrastrucute

Preparation

The solution utilizes the Azure4Alexa and AlexaSkillsSet.NET projects available on Github. Currently the approach requires some manual steps and Visual Studio knowledge, as you want to deploy your own Alexa custom application. This is primarily driven due to security demands. The Hybrid Runbook Worker can access your local infrastructure. So you went to be in charge of the credentials used to access your infrastructure.

1. Clone the Visual Studio solution from Github (https://github.com/Apoc70/ExchangeSpeechAssistant)
2. Follow the description provided here to setup your personal Alexa developer account and to get your Azure trial subscription to host the application
3. Publish the Visual Studio solution as an intital endpoint to setup your Alexa custom skill
   This results in a simple web page demonstrating the new Azure Web App
   
4. Modify the AlexaConstants.cs to use your Application Id
5. Re-Publish the Visual Studio solution with your custom Application Id
6. Prepare your local infrastructure for the use with Hybrid Runbook Worker
   1. Installing Hybrid Runbook Worker
   2. Create a Runbook Automation Account
      
   3. Create a runbook for whatever action you want to execute
      

Start enjoying how your administrator's can orchestrate your Exchange Server environment.

Links

• Alexa Developer Account
• AlexaSkillsSet.NET (implemented by Alexa4Azure)
• Additonal Notes

Enjoy your wonderful life with Exchange :-)

Problem

You implement shared mailboxes as part of a legacy public folder migration. Access to the shared mailbox provided by dedicated security groups which, in this case, provide access to dedicated sub folders within the mailbox.

The migrated legacy public folder content contained items marked as private.

When you access a shared mailbox as a group member you are not able to see or access private items.

The following two screenshots are used to demontraste the issue:

The Inbox node shows three unread items:

The Inbox detail pane just shows a single read message:

So how to access items marked as private?

Solution

The privacy level (Sensitivity) of a mailbox item is controlled by MAPI extended property 0x36.

• 0x36 = 0, sensitivity = normal
• 0x36 = 2, sensitivity = private

When an item does have an extended property 0x36, the value is set to 0.

A mailbox is accessed using Exchange Web Services. The EWS endpoint is discovered using AutoDiscover for the selected mailbox.

The item modificatiuon is handled by the following code segment:

var extendedPropertyDefinition = new ExtendedPropertyDefinition(0x36, MapiPropertyType.Integer);
int extendedPropertyindex = 0;

foreach (var extendedProperty in Message.ExtendedProperties)
{
	if (extendedProperty.PropertyDefinition == extendedPropertyDefinition)
	{
		if (log.IsInfoEnabled)
		{
			log.Info(string.Format("Try to remove private flag from message: {0}", Message.Subject));
		}
		else
		{
			Console.WriteLine("Try to remove private flag from message: {0}", Message.Subject);
		}

		// Set the value of the extended property to 0 (which is Sensitivity normal, 2 would be private)
		Message.ExtendedProperties[extendedPropertyindex].Value = 0;

		// Update the item on the server with the new client-side value of the target extended property.
		Message.Update(ConflictResolutionMode.AlwaysOverwrite);
	}
	extendedPropertyindex++;
}

Usage

RemovePrivateFlags.exe -mailbox user@domain.com [-logonly] [-foldername "Inbox"] 

Search through the mailbox and ask for changing a item if -logonly is not set to true.
If -foldername is given the folder path are compared to the folder name.
If -logonly is set to true only a log will be created.

RemovePrivateFlags.exe -mailbox user@domain.com [-foldername "Inbox"] [-noconfirmation]

Search through the mailbox, if -noconfirmation is set to true all items will be altered without confirmation.

Note

It should be noted that this solution is intended for use in migration scenarios.

When providing access to mailbnox delegates you can enable access to your private elements as well. But access to shared mailboxes is not configured using the delegation workflow.

The code has been tested using Exchange Server 2013 CU15.

The program utilizes log4net to log detailed information to the file system. The configuration is controlled by the application's config file.

Updates

• 2017-03-17: Release 1.1.0.0, Parameter changes
• 2017-03-09: Release 1.0.0.0

Links

• Download the source code at Github: https://github.com/Apoc70/RemovePrivateFlag
• Download the most current release here: https://github.com/Apoc70/RemovePrivateFlag/releases
• Download and vote at TechNet Gallery: https://gallery.technet.microsoft.com/Clear-Private-Flag-on-3cac4d50

Any issues or feature requests? Use Github.

Like the code? Leave a note.

Description

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.

Requirements

• This script utilizes the GlobalFunctions PowerShell module. This module needs to be installed first.
  Read more here: https://www.granikos.eu/en/justcantgetenough/PostId/210/globalfunctions-shared-powershell-library
• Delete permission to MESO container objects in Active Directory

Examples

# 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

Example log file

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

Version History

• 1.0, Initial community release

Links

• Download and follow at Github: https://github.com/Apoc70/Remove-OrphanedMailboxAccounts
• Download and like at TechNet Gallery: https://gallery.technet.microsoft.com/Remove-orphaned-HealthMailb-9f33ccbe

Follow

• Twitter @stensitzki
• LinkedIn
• Xing