Script Updates

powershellA small heads-up for those not following me on Twitter of one of the other social media channels. Last week I made updates to the following three scripts:

Install-Exchange2013.ps1, version 1.72

  • Added CU5 support
  • Added KB2971467 (CU5 Disable Shared Cache Service Managed Availability probes)

Remove-DuplicateItems.ps1, version 1.3

  • Changed parameter Mailbox, you can now use an e-mail address as well.
  • Added parameter Credentials.
  • Added item class and size for certain duplication checks.
  • Changed item removal process
  • Remove items after, not while processing folder. Avoids asynchronous deletion issues.
  • Works against Office 365.

Remove-MessageClassItems.ps1, version 1.3

  • Changed parameter Mailbox, you can now use an e-mail address as well
  • Added parameter Credentials
  • Added parameter PartialMatching for partial class name matching.
  • Changed item removal process. Remove items after, not while processing folder. Avoids asynchronous deletion issues.
  • Works against Office 365.
  • Deleted Items folder will be processed, unless MoveToDeletedItems is used.
  • Changed EWS DLL loading, can now be in current folder as well.

Be advised I keep am overview of the scripts and their current versions with publish dates here.

 

Exchange 2013 Cumulative Update 5

Ex2013 LogoToday, Cumulative Update 5 for Exchange Server 2013 was released by the Exchange Team (KB2936880). This update raises Exchange 2013 version number to 15.0.913.22.

This Cumulative Update contains the following fixes compared to SP1 (CU4):

  • 2963590 Message routing latency if IPv6 is enabled in Exchange Server 2013
  • 2963566 Outlook Web App accessibility improvement for UI appearance in Exchange Server 2013
  • 2962439 You cannot sync contacts or tasks in Microsoft CRM client for Outlook in an Exchange Server 2013 environment
  • 2962435 CRM synchronization fails if the time zone name of a meeting is not set in an Exchange Server 2013 environment
  • 2962434 Slow performance in Outlook Web App when Lync is integrated with Exchange Server 2013
  • 2958430 “Some or all Identity references could not be translated” error when you manage DAG in Exchange Server 2013 SP1 in a disjoint namespace domain
  • 2957592 IME is disabled in Outlook Web App when you press Tab to move the focus in an email message in Exchange Server 2013
  • 2942609 Exchange ActiveSync proxy does not work from Exchange Server 2013 to Exchange Server 2007
  • 2941221 EWS integration for Lync works incorrectly in an Exchange Server 2013 and 2007 coexistence environment
  • 2926742 Plain-text message body is cleared when writing in Outlook Web App by using Internet Explorer 8 in Exchange Server 2013
  • 2926308 Sender’s email address is broken after importing a PST file into an Exchange Server 2013 mailbox
  • 2925559 Users always get the FBA page when they access OWA or ECP in Exchange Server 2013
  • 2924519 “SyncHealth\Hub” folder is created unexpectedly after installing Cumulative Update 2 for Exchange Server 2013
  • 2916113 Cannot open .tif files from email messages by using Windows-based applications in an Exchange Server 2013 environment
  • 2592398 Email messages in the Sent Items folder have the same PR_INTERNET_MESSAGE_ID property in an Exchange Server 2010 environment

Notes:

  • Be advised that this CU includes a Managed Availability probe configuration that may result in the frequently restarting of the Microsoft Exchange Shared Cache Service in some environments. More information, see KB2971467.
  • Be advised of OAB architectural changes documented here. If you are affected, it is recommended to update CAS servers prior to Mailbox servers.

This Cumulative Update includes schema and AD changes, so make sure you run PrepareSchema / PrepareAD. After updating, the schema version will be 15300.

Note that Cumulative Updates can be installed directly, i.e. no need to install RTM or Service Packs prior to installing Cumulative Updates. Note that once installed, you can’t uninstall a Cumulative Update nor any of the installed Exchange server roles. The order of upgrading servers is irrelevant, unlike with previous generations of Exchange.

Finally, and I can’t emphasize this enough: For any Hotfix, Rollup, Service Pack or Cumulative Update, I’d recommend to thoroughly test this in a test and acceptance environment first, prior to implementing it in production. When you lack such facilities, hold out a week or two and monitor the comments on the release article or TechNet forum for any issues.

You can download Exchange 2013 Cumulative Update 5 here; UM Language Packs can be found here. More details about these changes, preparing Active Directory or installing this Cumulative Update can be found in the original announcement.

Get-MyMailboxStatistics

powershellLast update: Version 1.01, July 14th, 2014.

Those leveraging quota settings to manage their Exchange environments, you are probably periodically running some sort of script or set of cmdlets to retrieve information on mailbox sizes, quota settings and if any mailbox is above any of the quota thresholds. For a quick indication of the current size in relation to the quota settings, StorageLimitStatus may contain one of the following indicators depending on the quota settings on the mailbox or mailbox database hosting the mailbox:

  • BelowLimit – Speaks for itself
  • IssueWarning – Mailbox size above Issue Warning limit
  • ProhibitSend – Mailbox size above Prohibit Send limit
  • NoChecking – No quota checking
  • MailboxDisabled – Mailbox size above Prohibit Send and Receive quota limit

So, to get a list of all mailboxes with any over-quota status, you can use:

Get-MailboxDatabase | Get-MailboxStatistics | Where {$_.StorageLimitStatus -match 'IssueWarning|ProhibitSend|MailboxDisabled'} | Select DisplayName, ItemCount, TotalItemSize, StorageLimitStatus, LastLogonTime

Unfortunately, in Exchange 2013 the StorageLimitStatus gets no longer populated:

image

As KB2819389 explains, this is by design. In Exchange 2013, mailbox quotas are no longer cached. By not being cached, retrieving quota information may result in poor performance as it queries Active Directory for quota related attributes. The argument is a bit puzzling, considering there is a NoADLookup switch which directs the cmdlet to retrieve information from the mailbox database (cache) instead of Active Directory. Perhaps a better workaround would have been to make NoADLookup a parameter, make it $true by default and leave StorageLimitStatus unpopulated when NoADLookup is $true.

Of course, that does not help customers who want a quick quota report. For this purpose I have created two things in 1 script:

  1. A helper function Get-StorageLimitStatus() which will take a mailbox statistics object and return a StorageLimitStatus object.
  2. A script Get-MyMailboxStatistics.ps1, a proxy function for Get-MailboxStatistics which will use the Get-StorageLimitStatus helper function to populate the StorageLimitStatus.

Get-StorageLimitStatus
When you want to use the helper function, extract it and include it in your quota reporting script or PowerShell profile (making it available when firing up a shell). To use the helper function in the cmdlet shown earlier, use:

Get-MailboxDatabase | Get-MailboxStatistics | Where {$_.StorageLimitStatus -match 'IssueWarning|ProhibitSend|MailboxDisabled'} | Select -ExcludeProperty StorageLimitStatus DisplayName, ItemCount, TotalItemSize, @{n="StorageLimitStatus"; e={ Get-StorageLimitStatus $_}}, LastLogonTime

This will remove StorageLimitStatus from the output and add a calculated field bearing the same the name, calling the Get-StorageLimitStatus helper function with the current mailbox statistics object to set its value.

Get-MyMailboxStatistics.ps1
This is a proxy function for the Exchange Management Shell cmdlet Get-MailboxStatistics. This means that the current, original cmdlet was used to create a wrapper which will call the original cmdlet. Having a wrapper allows you to restrict or enhance the original cmdlet and tailor it to your needs.

A quick tip on how to create a proxy script in the clipboard (more information on creating proxy commands here):

$data= New-Object System.Management.Automation.CommandMetaData (Get-Command Get-MailboxStatistics) 
[System.Management.Automation.ProxyCommand]::create($data) | clip.exe

Downside is that future changes to the Get-MailboxStatistics cmdlet will not be automatically incorporated in the wrapper. Feeding it objects also doesn’t work, but you can work around that by temporary storing the objects in a variable and passing that to the script (see examples below).

To populate the StorageLimitStatus, we will post-process each object in the output of Get-MailboxStatistics, using Add-Member to overwrite (-Force) its current value and –PassThru to pass it along in the pipeline. Being a proxy command, the parameter options are identical to the original Get-MailboxStatistics. Some examples:

.\Get-MailboxStatistics.ps1 -Database MDB2
$m= Get-Mailbox –Database MDB2 
$m | .\Get-MailboxStatistics.ps1 | ft –AutoSize DisplayName,TotalItemSize,StorageLimitStatus

image

Do be aware that this will incur Active Directory queries and thus performance of the script may not seem fast. However, in previous versions of Exchange you got immediate results as all the quota information was readily available from the cache. On the plus side, the status you see will be non-cached, current information.

On a final note and maybe needless to say that in order to use this you need to run it from the Exchange Management Shell and since it’s an unsigned script you need to set ExecutionPolicy to Unrestricted.

Feedback
Feedback is welcomed through the comments. If you got scripting suggestions or questions, do not hesitate using the contact form.

Download
You can download the script from the TechNet Gallery here.

Revision History
See Technet Gallery page.

Exchange 2013 Server Role Requirements Calculator 6.3

Excel-2013[1]The Exchange 2013 Server Role Requirements Calculator received an update to reflect changed incorporated in Exchange 2013 SP1, such as adjusted guidance to accomodate for MAPI/http and its impact on the CAS role, as well as revised pagefile sizing guidance. The new version number is 6.3.

Changes since version 6.1:

  • Fixed Backup Requirements calculations to include greater than 50 databases.
  • Added additional processor core support.
  • Fixed the number of database volumes calculation when disk count is specified.
  • Fixed the database size calculation for A/P scenarios to match A/A scenario calculations.
  • Fixed the calculator to take into account halving database number per volume in non-site resilient scenarios.
  • Fixed conditional formatting errors on transport configuration settings.
  • Fixed transport sizing to take into account mailbox growth.
  • Updated CAS megacycle calculations to align with SP1 guidance.
  • Revised Dispart.ps1 script to create database mount points consistent with JetStress performance counters.
  • Added Calculator version number to record one field three of CSV export files.

You can download the calculator here. For more information, please consult the release notes and read me

Internal Message Classifications visible in Outlook

Ex2013 LogoMessage classifications were introduced with Exchange 2007 which seems like ages ago now. They are a piece of metadata which you can assign to messages, for example the intended audience or sensitivity of messages. These message can then be treated accordingly by the recipient or you can leverage transport rules functionality and Rights Management Services to act on or protect these messages.

Let’s assume you have created a custom message classification using the following cmdlet:

New-MessageClassification –Name ‘InternalUseOnly’ –DisplayName ‘Internal Use Only’ –SenderDescription ‘This message is for internal use only.’

When you retrieve the list of message classifications using Get-MessageClassifications you will notice three additional classifications:

image

Exchange comes with these message classifications which are used by Exchange internally: ExAttachmentRemoved, ExOrarMail and ExPartnerMail. These should not be used by users, let alone be visible. To make them hidden, the PermissionMenuVisible attribute is set to $false for these classifications. This will make them not show up in Outlook WebApp:image

Now, using classifications in Outlook is less admin-friendly and requires exporting of classification information and configuring Outlook to read these classifications from a file. In short, the process described on TechNet TechNet to use message classifications from Outlook is as follows:

From the Exchange Management Shell, run the Export-OutlookClassification.ps1 script from Exchange scripts folder, e.g.

& ‘C:\Program Files\Microsoft\Exchange Server\v15\Scripts\Export-OutlookClassification.ps1’ | Set-Content ‘C:\OutlookClass.xml’

Next, copy the XML file to a location on the client or networked location which is readable by Users. On the client, make the following registry changes:

[HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Policy]
"AdminClassificationPath"="c:\\Classifications.xml"
"EnableClassifications"=dword:00000001
"TrustClassifications"=dword:00000001

Note: For the purpose of this example the XML is stored as C:\Temp\OutlookClass.xml . Note that “15.0” is for configuring Outlook 2013, replace with 14.0 for Outlook 2010 and 12.0 for Outlook 2007.

Restart Outlook so it will use these settings. When composing a message you will now see the message classification options appear under Options > Permission:

image

Apart from the message classification “Internal Use Only” we created, you will also see that Outlook shows the internal classifications by their display name. That should not be happening.

When you open up the Outlook classifications export file, you will spot that it contains all classifications, including the internal ones:image

So, what you can do now and what the documentation seems to fail to mention, is that after exporting message classifications you may want to remove the internal classifications “Attachment Removed” (ExAttachmentRemoved), “Originator Requested Alternate Recipient Mail” (ExOrarMail) and “Partner Mail” (ExPartnerMail) from the XML export file. Downside is that message with these internal classifications will not display the related description in Outlook, but that should not be an issue and a better option than users being able to select them.

When you have removed the three entries from the XML file and restarted Outlook, the built-in options will no longer be on the permission menu:

image

Exchange 2013 SP1 Transport Agent Fix (updated)

Ex2013 LogoAfter installing Exchange 2013 Service Pack 1, people reported issues with Transport Agents. Symptoms are that the Transport service doesn’t start or stops shortly after starting the service or you can’t install the 3rd party product.

Products experiencing the issue are TrendMicro ScanMail, McAfee Email Security (GroupShield), Symantec Mail Security for Exchange, AVG for Servers, ESET Mail Security for Exchange and CodeTwo Exchange Rules. Products from other vendors may be affected as well.

Microsoft is aware of this issue and has published KB2938053 which has a small Exchange2013-KB2938053-FixIt.zip script to fix the issue.

The cause of the issue lies in XML files containing invalid XML markup in the form of “comments” which prevents .NET from loading the XML files, e.g.

<!-- 15.0.847.30 -------------------------------->

The two files containing the invalid XML markup are:

$Env:Windir\Microsoft.NET\assembly\GAC_MSIL\policy.8.0.Microsoft.Exchange.Data.Common\v4.0_15.0.847.30__31bf3856ad364e35\Microsoft.Exchange.Data.Common.VersionPolicy.cfg
$Env:Windir\Microsoft.NET\assembly\GAC_MSIL\policy.8.0.Microsoft.Exchange.Data.Transport\v4.0_15.0.847.30__31bf3856ad364e35\Microsoft.Exchange.Data.Transport.VersionPolicy.cfg

Be advised that the script supplied in the KB article tries to locate and fix various alternate versions of those files. Something you might want to consider as well when fixing it manually, should you be unable to locate the specific files mentioned above.

After running the script you should be able to start the Transport service or install 3rd party containing transport agents..

Update (3/5): Updated blog after official KB article got published. The issue was also blogged on by fellows Jason Sherry, Paul Cunningham while Tony Redmond has additionanal background details here.

Inbound e-mail not accepted after applying Exchange 2013 SP1

Ex2013 LogoAfter installing Exchange 2013 Service Pack 1 you may notice that inbound e-mail is not accepted and attempts to connect to port 25 will result in a timeout.

The application event log will contain event log entries ID 7012, generated by the MSExchangeFrontEndTransport, mentioning that “The service state for frontend transport is inconsistent. Current state – Inactive. Expected state – Active”:

image

When inspecting the component state from the Exchange Management Shell using:

Get-ServerComponentState <ServerID> -Component FrontendTransport

you will notice that it really is inconsistent, as Exchange will report that the component is active:

image

The quick workaround for this issue at the moment is to restart the Frontend Transport service:

Restart-Service MSExchangeFrontendTransport

After a restart of the service, or system restart if you must, the component state is working fine again and connections are accepted. In addition, the MSExchangeFrontendTransport will generate an event log entry ID 7009, “Retrieved the service state. Host service – FrontendTransport, Service state data – Active.”

Exchange and The UC Architects fellow Paul Cunningham discovered the same issue and blogged about it here.

Exchange 2013 Service Pack 1

Ex2013 LogoThe long awaited Service Pack 1 for Exchange Server 2013 was released today by the Exchange Team (KB2926248). This update raises Exchange 2013 version number to 15.0.847.32.

Service Pack 1 introduces the following changes or enhancements:

  • Support for running Exchange Server 2013 SP1 on Windows Server 2012 R2.
  • Support for Windows Server 2012 R2 Domain Controllers and Windows Server 2012 R2 Forest and Domain Functional Level.
  • MAPI over HTTP.  More information on MAPI over HTTP here. Note that MAPI over HTTP requires Outlook 2013 SP1; you can download Office 2013 SP1 32-bit version here and the 64-bit version here.
  • DLP policy tips for OWA.
  • Add custom document types to DLP using fingerprinting technologies.
  • Cmdlet logging in Exchange Administrative Console.
  • Support for IP-less DAGs (on Windows Server 2012 R2).
  • S/MIME support.
  • Rich-Text editor for OWA.
  • Edge Transport server role.
  • Support for SSL Offloading.

Service Pack 1 includes the following fixes:

  • 2860242 HTML format is lost after saving as an MSG file in Exchange 2013
  • 2900076 Mailbox quota warning message uses an incorrect language in Exchange Server 2013
  • 2910199 “Reply all by IM” chat window displays seven recipients in Outlook Web App
  • 2913999 Meeting request body and instructions are lost in delegate’s auto-forwarded meeting request
  • 2918655 Microsoft.Exchange.Servicehost.exe crashes after you enable FIPS
  • 2918951 Users cannot access public folders after you upgrade to Exchange Server 2013 Cumulative Update 3
  • 2925281 Outlook connectivity issue if SSLOffloading is “True” in Exchange 2013
  • 2925544 Empty ExternalURL value for ActiveSync virtual directory after build-to-build upgrade of Exchange Server 2013
  • 2927708 Resource mailboxes that are created by EAC will not be updated by policies in Exchange Server 2013
  • 2928748 Default from delegate’s address in shared mailboxes in Exchange Server 2013
  • 2928803 Long server connection for Outlook after a database failover in Exchange Server 2013
  • 2930346 POP3 access does not work if the name of the resource mailbox differs from the user’s name
  • 2930348 Manual redirection occurs in Outlook Web App if External URLs in each site are the same
  • 2930352 Outlook Web App cross-site silent redirection does not work in Exchange Server 2013

Cumulative Updates and Service Packs includes schema and AD changes, so make sure you run PrepareSchema /PrepareAD. After updating, the schema version will be 15292.

Note that Service Packs and Cumulative Updates can be installed directly, i.e. no need to install RTM prior to Cumulative Updates or Service Packs. Note that once applied, you can’t uninstall a Cumulative Update or Service Pack nor any of the installed Exchange server roles. The order of upgrading servers is irrelevant, unlike with previous Exchange generations.

Finally, and I can’t emphasize this enough: For any Hotfix, Rollup, Service Pack or Cumulative Update, I’d recommend to thoroughly test this in a test and acceptance environment first, prior to implementing it in production. When you lack such facilities, hold out a week or two and monitor the comments on the release article or TechNet forum for any issues.

Also check with any 3rd party products you may use – there are reports of compatibility issues with 3rd party transport agents by Exclaimer, Trendmicro (other AV solutions possibly as well) and CodeTwo. The cause of the Transport service failing to start or problems with installing 3rd party transport agents has been identified. A workaround can be found here.

You can download Exchange 2013 Service Pack 1 here. The Exchange 2013 SP1 UM Language Packs can be found here. More details about these changes, preparing Active Directory or installing this Cumulative Update can be found in the original announcement here.

So long RPC/HTTP, Hello MAPI/HTTP

Ex2013 LogoMicrosoft published three sessions from the Redmond Interoperability Protocols Plugfest 2013 on Channel 9 on the protocol MAPI over HTTP or MAPI/HTTP which looks scheduled to arrive with Exchange 2013 Service Pack 1.

This protocol is set to (over time!) replace the RPC/HTTP protocol we all know. RPC/HTTP, or Outlook Anywhere, is used by Outlook to communicate with Exchange Server and is most often seen with clients working remotely. With Exchange Server 2013, support for MAPI was dropped and RPC/HTTP became the only protocol. With Exchange 2013 SP1 it seems we will receive an alternative which is set to replace RPC/HTTTP, MAPI/HTTP.

Of course, the information is preliminary and subject to change as Exchange 2013 SP1 hasn’t been released yet, but it won’t harm to get familiar with the planned changes. It also remains to be seen how quick organizations will adopt this new protocol, which I’m pretty sure we will soon see getting supported by Office 365.

MapiHttp in Exchange 2013 SP1
Joe Warren, Principal SDE at Microsoft delivering a presentation covering the Exchange 2013 MapiHttp protocol implementation in Exchange 2013 SP1. Topics: What is MAPI-HTTP?, Why do MAPI-HTTP?, Goal of MAPI-HTTP, Why not rebuild with EWS?, Existing RPC-HTTP, New MAPI-HTTP, What does a MAPI-HTTP request look like?, What does a MAPI-HTTP response look like?, Session Context, Request Types, Sequencing & Protocol Failures. Click here.

Outlook 2013 Client Protocols
Shri Vidhya Alagesan, SDE at Microsoft presenting on Outlook 2013 Client Protocols from a client’s perspective. Topics: Client side view of Outlook-Exchange MAPI-HTTP protocol using WinHTTP, Error Handling & RPC Vs. MAPI-HTTP with sub-topics of Architecture Overview, Outlook & WinHttp, Cookies, Connection Status Dialog, Timeout, Pause/Resume & Protocol Switching. Click here.

Exchange 2013 Protocols
Andrew Davidoff, Senior Software Developer Engineer in Test at Microsoft presenting on the Exchange 2013 protocol families and important protocol updates for Exchange 2013. Click here.

Apart from these sessions on protocol change announced for Exchange Server 2013 SP1, Microsoft also published some other interesting Exchange-related sessions:

Exchange 2013 Web Services Overview
Harvey Rook, Principal Development Lead, and Naveen Chand, Senior Program Manager Lead, deliver a presentation on Exchange Web Services best practices. Click here.

Exchange RPC and EWS Protocol Test Suites
Jigar Mehta, Software Development Engineer in Test provides an in depth overview of the test suite packages for the Exchange RPC and Exchange Web Services protocols. Click here.

Cmdlet Extension Agents & XML Case Sensitivity

Ex2013 LogoOccasionally, I get requests to come to the aid of a fellow IT professional (I seldomly get requests to come to the aid of fair maidens. Oh, well). This weekend I responded to one of those distress calls by someone who couldn’t get his Cmdlet Extension Agent to work. This post is a quick heads-up for the collective memory of IT Professionals as it took me quiet a bit of screen staring to spot the issue.

For those unfamiliar with Cmdlet Extension Agents, they are modules which allow you to enhance or customize the behavior of cmdlets in Exchange. For example, the built-in Mailbox Resources Management agent is responsible for picking the database when creating new mailboxes when a database hasn’t been specified. By means of the Script Agent and an XML file named ScriptingAgentConfig.xml containing PowerShell code fragments, you can enhance and tailor Exchange cmdlets to your own needs. For those interested in Cmdlet Extension Agents, I did two earlier articles on Cmdlet Extension Agents, here and here.

The code provided was a simple agent to enhance New-Mailbox with enabling SingleItemRecovery after the mailbox was created:

<?xml version="1.0" encoding="utf-8" ?>
<Configuration version="1.0">    
        <Feature Name="Mailbox Provisioning" cmdlets="new-mailbox">
         <ApiCall Name="OnComplete">
             if($succeeded) {
                $newmailbox = $provisioningHandler.UserSpecifiedParameters["Name"]
                set-mailbox $newmailbox -SingleItemRecoveryEnabled $true
                }
        </ApiCall>
        </Feature>
</Configuration>

The Scripting Agent was enabled using Enable-CmdletExtensionAgent. Yet, for some reason after creating a new mailbox, SingleItemRecoveryEnabled wasn’t enabled. Running New-Mailbox in Verbose mode showed that the Scripting Agent did not come into play:

Capture1Now know that debugging and troubleshooting Cmdlet Extension Agents can be an unpleasant task since you put PowerShell code in XML files and there is no way to easily perform simple tests except running the Cmdlet you’re customizing or developing script fragments in an external PowerShell script and copy/paste it in the Scripting Agent XML file when you think it’s ready for and want to perform some final tests.

I didn’t immediately spot it, so to see if the problem was actually in the XML I picked the example of my 2nd article on Cmdlet Extension Agents and I compared it with the non-working XML using WinMerge (which by the way is an excellent tool to compare code or plain texts):

WinMergeIt took some time to discover why the Scripting Agent wouldn’t pick up the XML and it can be easily overlooked. The culprit in underlined in red: the C of the Cmdlets attribute in the Feature tag should be uppercase. Doh! This case sensitivity is perhaps not a primary suspect by Windows folks, as mostly we don’t have to worry about it and things “just work”, but in the case of XML it is essential. The XML standard prescribes that element names (<Feature> .. </Feature>) and attribute names (<Feature Cmdlets=..>) are case-sensitive entitling the Scripting Agent to be strict.