Just can't get enough of IT

When you run the following cmdlet to prepare Active Directory for the installation of an Exchange Server Cumulative Update (in this case CU17) you might encounter a System.UnauthorizedAccessException. 

D:\tmp\Cu17>setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms

Microsoft Exchange Server 2013 Cumulative Update 17 Unattended Setup


Unhandled Exception: System.UnauthorizedAccessException: Access to the path 'C:\
Windows\Temp\ExchangeSetup\ExSetup.exe' is denied.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.File.SetAttributes(String path, FileAttributes fileAttributes)
   at Microsoft.Exchange.Setup.CommonBase.SetupHelper.DeleteDirectory(String pat
h)
   at Microsoft.Exchange.Bootstrapper.Setup.BootstrapperBase.CopySetupBootstrapp
erFiles()
   at Microsoft.Exchange.Bootstrapper.Setup.Setup.Run()
   at Microsoft.Exchange.Bootstrapper.Setup.BootstrapperBase.MainCore[T](String[
] args)
   at Microsoft.Exchange.Bootstrapper.Setup.Setup.Main(String[] args)

There is a simple reason for the the System.UnauthorizedAccessException:

• .NET Framework Optimization Service 

The required .NET Framework 4.6.2 had been installed just minutes before executing setup.exe. Preparation of the Active Directory schema ran without any issues. But when the /PrepareSchema call finished, the temporary folder in C:\Windows\Temp\ExchangeSetup could not be fully cleaned up, as mscorsvw.exe had an open file handle on ExSetup.exe.

Additionally, when you run Setup.exe and the folder C:\Windows\Temp\ExchangeSetup exists, the setup will not try to copy required installation files. Regardless if the folder files exists in the folder or not.

Solution

• End both mscorsw.exe processes or wait until both process have finished optimizing your .NET Framework applications
• Manully delete the folder C:\Windows\Temp\ExchangeSetup
• Run the required Exchange setup step again

D:\tmp\Cu17>setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms

Microsoft Exchange Server 2013 Cumulative Update 17 Unattended Setup

Copying Files...
File copy complete. Setup will now collect additional information needed for
installation.

Performing Microsoft Exchange Server Prerequisite Check

    Prerequisite Analysis                                     COMPLETED

Configuring Microsoft Exchange Server

    Organization Preparation                                  COMPLETED

The Exchange Server setup operation completed successfully.

Enjoy Exchange!

There are quite a lot of good step-by-step manuals available describing how to enable Kerberos authentication for Exchange Server 2013/2016.

The following issue has been seen in an Exchange 2013 infrastructure (8 server DAG) where Outlook clients use OutlookAnyhwere to connect to Exchange Server. MAPI over Http is disabled on an organizational level due to a compatibility issue with another client software.

Problem

Even if you follow the detailed descriptions you might end up in a situation where your Outlook clients still won't connect to Exchange Server using Kerberos. The Outlook connection status overview (Ctrl + Right Click on the Outlook icon in System Tray) still shows Ntlm as the used authentication provider:

Reason

You are supposed to use the following PowerShell cmdlets to configure OutlookAnywhere to use Kerberos:

Get-OutlookAnywhere -Server CASSERVER | Set-OutlookAnywhere -InternalClientAuthenticationMethod  Negotiate

All eight Exchange 2013 servers where still not offering Nego as an authentication provider even after some period of time. Verifying the OutlookAnywhere configurations using PowerShell showed the correct configuration values. So what to do?

A quick check at the IIS authentication settings of the \Rpc virtual directory of the Front End web site (Default Web Site) showed that this virtual directory was still configured to use Ntlm only.

Solution

Use the IIS management consolte to add the Negotiate authentication provider to the list of available providers and reorder the list to use Nego first.

Now Outlook clients will pick up the configuration change an will connect to OutlookAnywhere using Kerberos.

Note

You should not use the IIS management console to change any settings of the Exchange Server virtual directories during normal operations. Using the IIS management console should only be used for troubleshooting fancy situations that you encounter in your Exchange Server infrastructure. 

The preferred method to change Exchange Server vDir settings is PowerShell.

Links

• Configuring Kerberos authentication for load-balanced Client Access services (Exchange 2016), https://technet.microsoft.com/en-us/library/ff808312(v=exchg.160).aspx
• Configuring Kerberos authentication for load-balanced Client Access servers (Exchange 2013), https://technet.microsoft.com/en-us/library/ff808312(v=exchg.150).aspx

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!

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