Category Archives: 13177

Improvements to the Exchange Remote Connectivity Analyzer




The Exchange Remote Connectivity Analyzer (ExRCA) has to be one of the best troubleshooting tools that the Exchange product team has ever produced.  It’s a one-stop shop that allows you to test remote connectivity to an Exchange organization using Autodiscover, ActiveSync, Outlook Anywhere, Web Services, or inbound/outbound SMTP from a Microsoft hosted cloud application on the Internet.  It works with both on-prem and Office 365 Exchange organizations.



Shawn McGrath is the developer in charge of ExRCA development and previewed recent improvements to us at the MVP Summit in February 2012.  I’m pleased to say that ExRCA version 1.4 has now been released!  The biggest changes are around the CAPTCHA experience, which I’ve been a vocal about for the past year.  Constructive Feedback = Good.  J



Here’s a list of the changes in this release:

  • We are using a new CAPTCHA service provided by an internal team.
  • The challenge is NOT case sensitive, so it doesn’t matter if you type upper or lower case letters.  We also note this on the web page.
  • The CAPTCHA challenges will not include hard to distinguish letters/numbers.  For example 2 and Z or O and 0.
  • If you get the challenge wrong, the password entries will not be removed.
  • Once you enter a correct response to the challenge, you will be verified for a set amount of time (~30 minutes).  This means you will not see additional CAPTCHA challenges until the timeout period expires.
  • The inbound SMTP test now inserts the IP address of the user performing the test into the test email message. The IP is also inserted into an SMTP Header (X-Originating-IP).
  • Fixed an issue in the Sender-ID test where certain DNS responses while evaluating the “exists” mechanism were incorrectly being treated as a TempError
  • The outbound SMTP Sender-ID tests now conform to the RFC specified limit of ten DNS-based mechanisms that can be used during the evaluation of the SPF record.
  • Fixed an issue where host names with all numbers in the top-level domain were not considered valid input
  • Fixed user interface issues that can cause the “helper bubble” to stick around when navigating in the wizard
  • Added a note to the EWS service account access test indicating that the mailbox must be empty
  • Changed the Windows Mobile Certificate test to warn instead of fail when certificates aren’t trusted by Windows Mobile since many other devices also use ActiveSync and may trust the certificate
  • Changed the Outlook Anywhere mutual authentication test to report a warning instead of an error when the mutual authentication (msstd: string) only matches a Subject Alternative Name on the certificate. Windows Vista SP1 and later can handle this configuration.
  • The Outlook Anywhere Proxy Ping and HTTP Authentication Method Tests now use the full query string; this is necessary to support certain UAG configurations.
  • Added additional error mappings for known issues

Shawn also created this fun video to demonstrate the new CAPTCHA
experience.





 

Cloning Exchange Remote IP Ranges Between Connectors

I’ve been doing a number of Exchange 2007 to 2010 migrations lately.  Most of these customers have internal relay Receive Connectors that allow internal application servers to relay SMTP email through Exchange to internal and/or external recipients.  The connectors are configured to allow only certain IP addresses to use them, and often it’s a pretty extensive list.  This article explains how to copy, or “clone”, these remote IP addresses from one connector to another.



For example, here’s an Exchange 2007 connector with over 25 remote IP addresses that are allowed to use this connector:






Typing in these IP addresses into a new Exchange 2010 Receive Connector is not only laborious, it can lead to errors that may take quite a bit of time to troubleshoot.



Using Powershell we can easily clone this set of IP addresses from an existing connector, named Anonymous Relay on EX2007HT, to another connector with the same name on an Exchange 2010 Hub Transport server, EX2010HT.



Begin by creating a Receive Connector on the target server, EX2010HT with the name Anonymous Relay and configure it with the appropriate permissions.  Then run the following cmdlets to clone the RemoteIPRanges attribute:

$connector = Get-ReceiveConnector “EX2007HT\Anonymous Relay”
Set-ReceiveConnector “EX2010HT\Anonymous Relay” -RemoteIPRanges $connector.RemoteIPRanges

You can use this method to copy any remote IP range from one connector to another.  Simply replace the server\connector names.

Fix for "Default Policy" with mailbox manager settings cannot be managed by the current version of Exchange Management Console

I’m doing an Exchange 2007 to Exchange 2010 migration for a client and found that the Address Lists and E-mail Address Policy had not been updated from Legacy Exchange 2003 policies when they upgraded to 2007.  Typically, these are converted from Legacy policies in Exchange 2007 or 2010 by adding an RecipientFilter OPATH filter.



Exchange 2003 Mailbox Management policies were replaced by Messaging Records Management (MRM) in Exchange 2007.  During the migration from Exchange 2003, you’re supposed to create new MRM policies to match your Exchange 2003 Mailbox Manager polices and then remove the 2003 policies using the Exchange 2003 Management Console.



The customer didn’t do this before Exchange 2003 was decommissioned, so I’m doing it now in the 2010 migration.  But as I tried to convert the Default Policy in E-mail Address Policies using the Set-EmailAddressPolicy “Default Policy” -IncludedRecipients AllRecipients command, I get the following error:



Set-EmailAddressPolicy : The recipient policy “Default Policy” with mailbox manager settings cannot be managed by the current version of Exchange Management Console. Please use a management console with the same version as the object.
At line:1 char:23
+ Set-EmailAddressPolicy  <<<< “Default Policy” -IncludedRecipients AllRecipients




This happens when the Default Policy also includes Mailbox Manager settings.  Since there are no Exchange 2003 servers anymore (or 2003 console) in this environment, I can’t remove the Mailbox Manager settings from the policy.  Here’s how to fix this using ADSI Edit:

  • Run ADSI Edit from the Exchange 2010 server.
  • In the Configuration container, navigate to CN=Recipient Policies,CN=<Exchange Org>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain>,DC=<com>
  • In the middle pane, view the properties of the Default Policy.
  • Remove the value(s) of the MsExchMailboxManagerFolderSettings attibute so that it’s now <Not Set>
  • Edit the MsExchPolicyOptionList attribute and remove all the attributes that do not begin with 0xfc.  The policy that begins with 0xfc is the email addressing policy.
Now when you run Get-EmailAddressPolicy “Default Policy” | FL you will see that HasMailboxManagerSetting is set to False and you will be able to update the Default Policy.

How to remove Exchange 2003 Mailbox Manager settings without the 2003 Management Console

I’m doing an Exchange 2007 to Exchange 2010 migration for a client and found that the Address Lists and E-mail Address Policy had not been updated from Legacy Exchange 2003 policies when they upgraded to 2007.  Typically, these are converted from Legacy policies in Exchange 2007 or 2010 by adding an RecipientFilter OPATH filter.



Exchange 2003 Mailbox Management policies were replaced by Messaging Records Management (MRM) in Exchange 2007.  During the migration from Exchange 2003, you’re supposed to create new MRM policies to match your Exchange 2003 Mailbox Manager polices and then remove the 2003 policies using the Exchange 2003 Management Console.



The customer didn’t do this before Exchange 2003 was decommissioned, so I’m doing it now in the 2010 migration.  But as I tried to convert the Default Policy in E-mail Address Policies using the Set-EmailAddressPolicy “Default Policy” -IncludedRecipients AllRecipients command, I get the following error:





Set-EmailAddressPolicy : The recipient policy “Default Policy” with mailbox manager settings cannot be managed by the current version of Exchange Management Console. Please use a management console with the same version as the object.
At line:1 char:23
+ Set-EmailAddressPolicy  <<<< "Default Policy" -IncludedRecipients AllRecipients




This happens when the Default Policy also includes Mailbox Manager settings.  Since there are no Exchange 2003 servers anymore (or 2003 console) in this environment, I can’t remove the Mailbox Manager settings from the policy.  Here’s how to fix this using ADSI Edit:

  • Run ADSI Edit from the Exchange 2010 server.
  • In the Configuration container, navigate to CN=Recipient Policies,CN=<Exchange Org>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain>,DC=<com>
  • In the middle pane, view the properties of the Default Policy.
  • Remove the value(s) of the MsExchMailboxManagerFolderSettings attibute so that it’s now 
  • Edit the MsExchPolicyOptionList attribute and remove all the attributes that do not begin with 0xfc.  The policy that begins with 0xfc is the email addressing policy.
Now when you run Get-EmailAddressPolicy “Default Policy” | FL you will see that HasMailboxManagerSetting is set to False and you will be able to update the Default Policy.

How to fix MSExchangeTransport Event ID 12014 on Edge and Hub Transport servers

By default, Exchange 2007 and 2010 attempt to use Transport Layer Security (TLS) for all SMTP traffic.  TLS uses a certificate on the receiving server to encrypt SMTP traffic between SMTP servers, similar to the way a certificate on the CAS server is used to secure OWA traffic.  If TLS cannot be negotiated, SMTP will usually fallback to non-encrypted SMTP.

In order for a server to send SMTP email via TLS:
  1. The receiving server must have an Exchange certificate in the computer’s local Personal store.
  2. The SMTP service must be assigned to use this certificate.
  3. The FQDN used in the Receive Connector must match either the Common Name or one of the Subject Alternative Names (if they exist) on the SMTP certificate.
If any one of these requirements is not met, you will see the following error in the application log of the Edge Transport server:

Log Name:      Application
Source:        MSExchangeTransport
Date:          9/28/2010 9:35:58 AM
Event ID:      12014
Task Category: TransportService
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      mailgate
Description:
Microsoft Exchange could not find a certificate that contains the domain name mail1.expta.com in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector Default internal receive connector MAILGATE with a FQDN parameter of mail.expta.com. If the connector’s FQDN is not specified, the computer’s FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.
When you see this error on Edge Transport servers you have to examine the error description to determine where the mismatch occurs.  In the example above, the connector in error is the “Default internal receive connector MAILGATE“, which is the receive connector that exists on the Edge server itself.  If the connector in error is on the “EdgeSync – Inbound to domain” connector, the mismatch is on the Hub Transport server’s receive connector.

You can fix this by reconfiguring the offending connector to use the Common Name or Subject Alternative Name used on the Exchange certificate.  You can find this value by viewing the certificate from the Certificates MMC, as shown below:
To reconfigure the Edge Server’s Receive Connector:
  • On the Edge server, open the Exchange Management Console.
  • Navigate to Microsoft Exchange > EdgeTransport.
  • Click the Receive Connectors tab to view the existing connectors.
  • Double-click the Default internal receive connector SERVER connector to view its properties.
  • In the Specify the FQDN this connector will provide in response to HELO or EHLO field, enter the certificate’s Common Name (for example, ex1.expta.com) as shown below, and click OK.

To reconfigure the Hub Transport’s Receive Connector:
  • On the CAS, open the Exchange Management Console.
  • Navigate to Microsoft Exchange > Microsoft Exchange On-Premises > Organization Configuration > Hub Transport.
  • Click the Send Connectors tab to view the existing Send Connectors.
  • Double-click the EdgeSync – Inbound to domain connector to view its properties.
  • In the Specify the FQDN this connector will provide in response to HELO or EHLO field enter the certificate’s Common Name (for example, ex1.expta.com) as shown above, and click OK.

Fix for OWA always uses Light Mode for some users

This article explains the difference between OWA Light Mode and Premium Mode and why some users may only see the Light Mode client, even though they haven’t selected it at logon.

Exchange 2007 Outlook Web Access and Exchange 2010 Outlook Web App offer two different modes for viewing OWA – Premium Mode, with all the bells and whistles that Internet Explorer can muster, and Light Mode, which provides fewer features and is sometimes faster.  You would usually use the Light client if you are on a slow connection or using a computer with unusually strict browser security settings.

If you are using a browser other than Internet Explorer 6 or later for OWA 2007, you can only use the Light client.  OWA 2010 supports the full Outlook Web App experience (aka Premium Mode) on Internet Explorer 7 and some other browsers on Windows, Mac, and Linux computers.  To check out all the supported browsers and operating systems for OWA 2010, click here.

Here’s a comparison between the Outlook Web Access 2007 Light and Premium clients:

And here’s a comparison between the Outlook Web App 2010 Light and Premiun clients:

Normally, users will default to use the Premium Mode client if they are using IE6 or better for OWA 2007 or IE7 or better for OWA 2010.  However, you may hear complaints from some users that they always get the Light Mode client, regardless of whether they selected to use it or not when they logged in.  This happens if the user selected to use “the blind and low vision experience” when logging into OWA for the first time.

To disable this mode and allow IE to use the Premium Mode, have the user login to OWA and open Options in the upper right corner.  Then select Accessibility and clear the checkbox for Use the blind and low vision experience, as shown below.

Now have the user sign out of OWA and sign back in.  They should be using OWA Premium Mode, providing they are using a supported browser.

How to Apply a Default Managed Folder Mailbox Policy to All Users in Exchange 2007

Exchange 2007 provides a way for you to apply message retention settings to default and custom folders in user mailboxes.  This process is called Messaging Records Management (MRM) and is covered in pretty good detail here, so I won’t go into details on how to configure MRM.

MRM is similar to the Mailbox Manager process in previous versions of Exchange, with one notable exception — there is no built-in way to apply a Managed Folder Mailbox Policy to all Exchange 2007 users by default.  You must remember to apply the Managed Folder Mailbox Policy to new users when they are created.

I wrote a small Powershell script that will apply a Managed Folder Mailbox Policy to all Exchange 2007 users that do not already have a Managed Folder Mailbox Policy configured.  The script also writes an event to the Windows Application event log so you know it ran successfully.  Copy the script to any Exchange 2007 server and run it as a Scheduled Task.

Here’s the 5-line script, called Set-DefaultManagedFolderMailboxPolicy.ps1, wrapped for clarity:
Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize unlimited | Where-Object {$_.ManagedFolderMailboxPolicy -eq $null} | Set-Mailbox -ManagedFolderMailboxPolicy “Default mailbox policy” -ManagedFolderMailboxPolicyAllowed
$EventLog = new-object System.Diagnostics.EventLog(‘Application’)
$EventLog.MachineName = “.”
$EventLog.Source = “Set-DefaultManagedFolderMailboxPolicy”
$EventLog.WriteEntry(“Set-DefaultManagedFolderMailboxPolicy.ps1 has configured the ‘Default mailbox policy’ for new Exchange 2007 user mailboxes.”,”Information”,100)
The first line (in red) is where the actual work is done.  You can see there are three parts to this one-liner:
  • The first part gets all the Exchange 2007 (or Exchange 2010) user mailboxes.  This is useful for mixed Exchange 2003/2007 environments because MRM policies only apply to 2007/2010 mailboxes.
  • The second part filters the collection to only include user mailboxes that do not have a Managed Folder Mailbox Policy already configured (is null).
  • The third part assigns the Default Mailbox Policy to the filtered collection of mailboxes.  Note the -ManagedFolderMailboxPolicyAllowed parameter.  This parameter applies the policy without prompting the following confirmation:
Confirm

When assigning a managed folder mailbox policy with managed custom folders to the mailbox “contoso.com/Users/Jeff Guillet”, Outlook clients older than Outlook 2007 do not have all available client features and clients older than Outlook 2003 SP2 are not supported. You may use the “Set-CASMailbox” task to enable client version blocking. Are you sure you want to assign a managed folder mailbox policy to this mailbox?

[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is “Y”):
Normally, you would suppress a confirmation prompt like this using the -confirm:$false parameter, but that doesn’t work for the -ManagedFolderMailboxPolicy parameter for some reason.
 
The remaining four lines (in blue) are used to write the event to the Application event log.
 
Save the script above as Set-DefaultManagedFolderMailboxPolicy.ps1 in C:\Scripts on the Exchange 2007 server where it will be run.  Now we need to create a Windows scheduled task.
  • Configure the task to run the following program: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe with the following arguments: -PSConsoleFile “C:\Program Files\Microsoft\Exchange Server\bin\exshell.psc1″ -command “. C:\Scripts\Set-DefaultManagedFolderMailboxPolicy.ps1″
  • Configure the task to Run whether user is logged on or not using a service account that has at least Exchange Recipient Administrator rights.
  • Schedule the task to run daily at least one hour before the the Managed Folder Mailbox Policy is scheduled to run.

Exchange Setup Repeatedly Says ‘A Restart from a Previous Installation is Pending’

You may find when installing Exchange 2007 or Exchange 2010 that the server repeatedly reports:
A restart from a previous installation is pending. Please restart the system and rerun setup.
Exchange Setup reads the following registry key to determine whether a system restart is required after installation or removal of a software update such as a security update, critical update, or hotfix.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\UpdateExeVolatile

Exchange Setup also checks the following registry key to determine whether a previous software update installation was not completed and the system must be restarted to finish the installation.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations

If setup still complains that a restart is needed after you’ve performed a restart, do the following:
  • Open RegEdit.
  • Set the HKLM\SOFTWARE\Microsoft\Updates\UpdateExeVolatile key value to 0 or delete it.
  • Delete the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations key.
  • Rerun Setup.

The New Exchange 2007 SP3 Password Reset Tool

Exchange Server 2007 Service Pack 3 includes a handy new web page that allows users to change their password before logging into Outlook Web Access (OWA).

Previously, new users who are required to change their password at next logon or users whose password has expired cannot log on to OWA.  They will get the less than helpful error from the OWA, “The user name or password that you entered is not valid. Try entering it again”, as shown below:

 
In order to logon to OWA, the user must logon to the network, enter their old password and the new password.  Obviously, this causes problems for remote users whose password has expired or for new users who must change their password before logging in for the first time.

Exchange 2007 SP3 introduces a new SSL web page for these users that allows the user to change their password outside of OWA.  The page tells the user, “Your password has expired and you must change it prior to signing in to Microsoft Outlook Web Access.”

 
Once the user changes their password, the page redirects the user back to OWA.

This new functionality is not enabled by default, since some organizations do not allow password changes from outside the internal network.  To enable it:
  • Logon to the CAS with administrator rights
  • Run Regedit and navigate to HLKM\SYSTEM\CurrentControlSet\services\MSExchange OWA
  • Create a new DWORD (32-bit) Value called ChangeExpiredPasswordEnabled
  • Assign the ChangeExpiredPasswordEnabled value: 1
  • Restart IIS using IISRESET /NOFORCE from the command line
Surprisingly, this functionality does not exist in Exchange Server 2010 (or the SP1 beta).  I hope Microsoft decides to implement this when Exchange 2010 SP1 is finally released.  It’s a pretty handy feature!

Fix for Microsoft Exchange Protected Service Host service failed to start

If you install Exchange Server 2007 SP3 on a Windows Server 2008 R2 all-in-one server, you may get an error during installation of the Hub Transport role.  The error says,
A timeout was reached (30000 milliseconds) while waiting for the Microsoft Exchange Protected Service Host service to connect.

The Microsoft Exchange Protected Service Host service failed to start due to the following error: The service did not respond to the start or control request in a timely fashion.
This happens because there is a dependancy in the Microsoft Exchange Service Host service on IPv6.  Check to ensure that Internet Protocol Version 6 (TCP/IPv6) is enabled on the properties of the network adapter.