Thursday, January 30, 2014

Exchange 2013 CU3 Invalid Hybrid Product Key

On a newly installed Exchange Server 2013 Cumulative Update 3 (CU3) server (not an upgrade from an earlier 2013 build), when you are setting up a hybrid deployment and you enter the product key to activate it, you will receive the following error message:
error
Invalid Product Key.

This issue occurs because of a regression in CU3 for Exchange 2013 which causes the product to be mistakenly recognized as invalid.
You can safely ignore this product activation error message. Until this issue is resolved in the near future, there are no adverse effects from leaving the server unlicensed. This is a known issue that is scheduled to be addressed in SP1.

If you already deployed the product key for the Hybrid Edition on a server and later upgraded the server to Exchange 2013 CU3, the server will remain licensed, and the license will be displayed as valid.

Tuesday, January 21, 2014

Staged Exchange Migration with ADFS and DirSync

Some organizations implement ADFS and DirSync in order to take advantage of the Single Sign-On capabilities. However, not all of them opt for a hybrid deployment and perform a Staged Exchange Migration instead to move mailboxes from the on-premises environment to Office 365.
 
In order to perform such migration, one of the steps involved is the creation of a CSV for the Migration batch. This CSV needs to have three columns: EmailAddress, Password and ForceChangePassword.
 
The problem here is if the ForceChangePassword field is set to True. This will cause the migration to fail because Office 365 cannot modify that attribute for an Identity Federated user (remember we are using ADFS and DirSync) so you would get an error.
 
To overcome this, simply update the CSV file and set the ForceChangePassword field to False. This should allow for the migration to succeed.

Thursday, January 16, 2014

Office 365 Identity Federation Debug Tool

The Microsoft Remote Connectivity Analyzer tool has been updated and it now includes testing for Office 365 federated identity provider. This can be used with an Office 365 tenant configured for federation with either ADFS or another WS-* based Security Token Service. It helps debug possible issues with the federated identity provider through simple tests.
 
The tool is available for download here.
 
Once downloaded and installed, click on “I can’t setup federation with Office 365, Azure, or other services that use Azure Active Directory (Beta)”:
 
 Then enter your Office 365 credentials and begin the login test of your federation configuration:
 
 Tests are done from the PC that you download the testing tool to. It will attempt to log in to Office 365 using the federation configuration. The testing will proceed and then show results which should help debug any possible federation issues.

Tuesday, January 7, 2014

Message Tracking Report

New to Exchange 2013, the Get-MessageTrackingReport cmdlet is used to return data for a specific message tracking report.
 
This cmdlet, used by the delivery reports feature, requires you to specify the ID for the message tracking report you want to view. Therefore, first you need to use the Search-MessageTrackingReport cmdlet to find the message tracking report ID for a specific message. You then pass the report ID to the Get-MessageTrackingReport cmdlet.
 
Note that you need to be assigned permissions before you can run this cmdlet. You will not have access to some of its parameters if the account used is not a member of one of the following groups: Organization Management, Records Management or Recipient Management.
 
 
This first example gets the message tracking report for messages sent from one user to another and returns the summary of the message tracking report for a message that Alice Jones sent to John Richardson:
$Temp = Search-MessageTrackingReport “Alice Jones” -Recipients “johnr@letsexchange.com”
Get-MessageTrackingReport $Temp.MessageTrackingReportID -ReportTemplate Summary
  • The ReportTemplate parameter specifies a predefined format for the output. You can either return a summary for all recipients or a detailed tracking report for one recipient using one of the following values: RecipientPath or Summary.
 
 
The second example gets the message tracking report for the following scenario: a user named Nuno Mota was expecting an e-mail message from joe@domain.com that never arrived. He contacted the Help Desk, which generated a message tracking report on behalf of Nuno returning detailed troubleshooting information for the specific recipient path:
Search-MessageTrackingReport “Nuno Mota” -Sender “joe@letsexchange.com” -ByPassDelegateChecking -DoNotResolve | ForEach {Get-MessageTrackingReport $_.MessageTrackingReportID -DetailLevel Verbose -BypassDelegateChecking -DoNotResolve -RecipientPathFilter "nunom@domain.com" -ReportTemplate RecipientPath}
  • The BypassDelegateChecking switch allows Help Desk staff and administrators to retrieve message tracking reports for any user. By default, each user can only see the message tracking reports for messages sent or received by the user. When using this switch, Exchange allows administrators to view message tracking reports for messages exchanged among other users.
  • The DoNotResolve switch prevents the resolution of e-mail addresses to display names. This improves performance, but the end result may not be as easy to interpret because it is missing the display names.
  • The DetailLevel parameter specifies the amount of detail to be displayed for the message tracking report. You can use one of the following values: Basic or Verbose. If you specify Basic, simple delivery report information is displayed, which is more appropriate for information workers. If you specify Verbose, full report information is displayed, including server names and physical topology information.
  • The RecipientPathFilter parameter specifies the recipient for which the command returns the detailed tracking report. This parameter is used when using the RecipientPath report template.