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.

 

Read more ...

Fix for MSExchange Availability Event ID 4002 Errors

You may find in an Exchange 2007 to Exchange 2010 coexistance enviroment that the following event is logged with some regularity:

Log Name:      Application
Source:        MSExchange Availability
Date:          12/7/2011 12:49:41 PM
Event ID:      4002
Task Category: Availability Service
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      exch2.domain.com
Description:
Process 2540: ProxyWebRequest IntraSite from S-1-1-0 to https://email.domain.com/ews/exchange.asmx failed. Caller SIDs: NetworkCredentials. The exception returned is Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequestProcessingException: System.Web.Services.Protocols.SoapException: Microsoft.Exchange.InfoWorker.Common.Availability.TimeIntervalTooBigException: The requested time duration specified for FreeBusyViewOptions.TimeWindow is too long. The allowed limit = 42 days; the actual limit = 62 days. ---> The requested time duration specified for FreeBusyViewOptions.TimeWindow is too long. The allowed limit = 42 days; the actual limit = 62 days.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)
   at Microsoft.Exchange.InfoWorker.Common.Availability.Proxy.Service.EndGetUserAvailability(IAsyncResult asyncResult)
   at Microsoft.Exchange.InfoWorker.Common.Availability.FreeBusyApplication.EndProxyWebRequest(ProxyWebRequest proxyWebRequest, QueryList queryList, Service service, IAsyncResult asyncResult)
   at Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequest.EndInvoke(IAsyncResult asyncResult)
   at Microsoft.Exchange.InfoWorker.Common.Availability.AsyncWebRequest.EndInvokeWithErrorHandling(). The request information is ProxyWebRequest type = IntraSite, url = https://email.domain.com/ews/exchange.asmx
Mailbox list = <Robert Donaldson>SMTP:RDonaldson@domain.com, Parameters: windowStart = 12/1/2011 12:00:00 AM, windowEnd = 2/1/2012 12:00:00 AM, MergedFBInterval = 30, RequestedView = FreeBusy
. ---> System.Web.Services.Protocols.SoapException: Microsoft.Exchange.InfoWorker.Common.Availability.TimeIntervalTooBigException: The requested time duration specified for FreeBusyViewOptions.TimeWindow is too long. The allowed limit = 42 days; the actual limit = 62 days. ---> The requested time duration specified for FreeBusyViewOptions.TimeWindow is too long. The allowed limit = 42 days; the actual limit = 62 days.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)
   at Microsoft.Exchange.InfoWorker.Common.Availability.Proxy.Service.EndGetUserAvailability(IAsyncResult asyncResult)
   at Microsoft.Exchange.InfoWorker.Common.Availability.FreeBusyApplication.EndProxyWebRequest(ProxyWebRequest proxyWebRequest, QueryList queryList, Service service, IAsyncResult asyncResult)
   at Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequest.EndInvoke(IAsyncResult asyncResult)
   at Microsoft.Exchange.InfoWorker.Common.Availability.AsyncWebRequest.EndInvokeWithErrorHandling()
   --- End of inner exception stack trace ---
. Name of the server where exception originated: EXCH2. Make sure that the Active Directory site/forest that contain the user's mailbox has at least one local Exchange 2010 server running the Availability service. Turn up logging for the Availability service and test basic network connectivity.

This happens because the default values used for publishing free\busy are different between Exchange 2007 and Exchange 2010.  The fix is to extend the free\busy value on the Exchange 2007 client access servers in IIS.

• Log into the Exchange 2007 Client Access Server (CAS)
• Open Internet Information Services (IIS) Manager in Adminstrative Tools
• Navigate to Sites > Default Web Site > EWS
• Double-click Application Settings under the ASP.NET heading
• Click Add in the Actions pane and create the following new application setting:
• Name: maximumQueryIntervalDays
• Value: 62
• Click OK to set the new value and close IIS Manager
• Repeat for each Exchange 2007 CAS

There's no need to restart IIS on the Exchange 2007 CAS.  The event 4002 errors will go away.

Read more ...

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.

Read more ...

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 <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.

Read more ...

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, mailgate.expta.com) as shown below, and click OK.

To reconfigure the Hub Transport's Send Connector:

• On the Hub Transport, 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 Hub Transport certificate's Common Name (for example, ht01.expta.com) and click OK.

Read more ...

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.

Note: If you are seeing OWA light mode after applying Windows Updates, which includes Internet Explorer 11, this is a known bug. The fix is to have your network administrator install Update Rollup 3 for Exchange Server 2010 Service Pack 3 or Cumulative Update 3 for Exchange Server 2013.  Have your network administrator read KB2866064 or send them this article.

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 Premium 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, provided they are using a supported browser.

Read more ...

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.

Read more ...

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.

Read more ...

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

Word is that Microsoft will implement the password reset tool for Exchange Server 2010 when Exchange 2010 SP1 is released.  It's a pretty handy feature!

Read more ...

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.

Read more ...

How to add a "Log On Again" button to the Exchange 2007 OWA Log Off page

---

Note: Click here to view how to add the Sign In Again button to Exchange Server 2010.

---

By default when you click "Log Off" in OWA 2007, Exchange 2007 directs you to a page that explains that you have successfully logged off from Outlook Web Access.  The only button available, "Close Window", closes the existing browser window or tab.  This article explains how to add a "Log On Again" button to the logoff.aspx page, as shown below:

To add the Log On Again button, follow these steps on each Exchange 2007 Client Access Server (CAS):

• Logon to the CAS using a local Administrator account.
• Using Windows Explorer, navigate to the  %ProgramFiles%\Microsoft\Exchange Server\ClientAccess\Owa\auth folder and make a copy of the logoff.aspx file for backup.
• Edit the logoff.aspx file using Notepad.
• Use Find to search for the word logoffclose.  In Exchange 2007 SP2 this will be line 115.
• Insert the following code before this line, as a single line:

<input id="btnCls" type="submit" class="btn" title="Click here to log on again" value="Log On Again" onclick="window.navigate('https://mail.contoso.com/owa')" onmouseover="this.className='btnOnMseOvr'" onmouseout="this.className='btn'" onmousedown="this.className='btnOnMseDwn'">

• Edit the line above to use your company's URL for OWA. 
• Save the logoff.aspx file.
• Copy the new logoff.aspx file to the same file path on all your CAS servers.

Remember that applying any Exchange 2007 Service Pack or Update Rollup to your CAS servers will overwrite the changes you made, so create a copy of the edited logoff.aspx file to reapply the Logon Again button after the update.  Also know that Service Packs and Update Rollups could possibly include changes to the logoff.aspx page, so you may need to follow these steps again to edit the new page included in the update.

Read more ...

Exchange 2007 Test-ReplicationHealth Shows False Warning for CCR Geo-Clusters

The Test-ReplicationHealth cmdlet in Exchange 2007 will show an inaccurate warning for the ClusterNetwork check if your CCR nodes are configured in geographically dispersed clusters.

Exchange 2007 CCR clusters must be located on the same subnet(s) when deployed on Windows 2003 servers.  Clustering enhancements in Windows Server 2008 enable you to create clusters in different subnets, negating the need to do networking acrobatics like stretching VLANs across geographic sites.  Unfortunately, the Test-ReplicationHealth cmdlet still expects that the network adapters are on the same network and will display the following warning if they are not:

Server Check Result Error

------ ----- ------ -----
EXNODE1 PassiveNodeUp Passed

EXNODE1 ClusterNetwork WARNING Warnings:
Network 'EXNODE2 Public' used for client connectivity is up but node 'EXNODE1' does not have a Network Interface Card configured on it. Check that a NIC is configured for this network and is enabled.

Network 'EXNODE2 Private' used for internal cluster communications is up; however, node 'EXNODE1' does not appear to have a configured network interface card (NIC). Check that a NIC is configured and enabled for this network on this node.
Network 'EXNODE1 Private' used for internal cluster communications is up; however, node 'EXNODE2' does not appear to have a configured network interface card (NIC). Check that a NIC is configured and enabled for this network on this node.
Network 'EXNODE1 Public' used for client connectivity is up but node 'EXNODE2' does not have a Network Interface Card configured on it. Check that a NIC is configured for this network and is enabled.


EXNODE1 QuorumGroup Passed
EXNODE1 FileShareQuorum Passed
EXNODE1 CmsGroup Passed
EXNODE1 NodePaused Passed
EXNODE1 DnsRegistrationStatus Passed
EXNODE1 ReplayService Passed
EXNODE1 DBMountedFailover Passed
EXNODE1 SGCopySuspended Passed
EXNODE1 SGCopyFailed Passed
EXNODE1 SGInitializing Passed
EXNODE1 SGCopyQueueLength Passed
EXNODE1 SGReplayQueueLength Passed

VLEM SGReplayQueueLength Passed

This behavior also affects System Center Operations Manager 2007, since SCOM uses the same Test-ReplicationHealth cmdlet to monitor Exchange 2007 replication health.  This will cause the CCR nodes to show in a critical condition for the Exchange 2007 Test Replication Health Monitor - Log Shipping monitor.

Read more ...

Exchange 2010 Makes You an Expert

One of the great things about working with Microsoft Exchange is the breadth and depth of knowledge you gain by designing and managing it.  In Exchange 2003, we made you a storage expert.  In Exchange 2007 you became a digital certificates expert.  Now in Exchange 2010 you will become a load balancing expert.

The Client Access Server role in Exchange 2010 has evolved into a true universal connection point for all client access - be it Outlook, MAPI, POP, ActiveSync, or web services clients like Entourage WS Edition.  This abstraction makes load balancing and fault tolerance for CAS servers paramount in any Exchange design where high availabilty is required.

There is no one size fits all solution for load balancing CAS arrays.  You may find that simple Windows Load Balancing will work for you, or you may have a need for bigger (and more expensive) hardware load balancers.  Do your research.  Learn.  Become an expert.

I encourage you to read Exploring Exchange 2010 RPC Client Access Service on the MSExchangeTeam blog.  This article gives an excellent overview of the new RPC Client Access and Address Book services in Exchange 2010.  It also explains many of the details about Client Access arrays.

Read more ...

Solution for Cannot Failover Exchange 2007 CCR Cluster Because Copy Status is Initializing

You may find that your Exchange 2007 CCR cluster will not failover to the other node because continuous replication is not in a healthy state.  Here's what you see from the Exchange Management Shell (EMS):

[PS] C:\>Move-ClusteredMailboxServer exchange2 -TargetMachine CCR2 -MoveComment:"Failover Test"


Confirm
Are you sure you want to perform this action?
Moving clustered mailbox server "exchange2" to target node "CCR2" with move comment "Failover Test".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): y
Move-ClusteredMailboxServer : Continuous replication is in a failed, seeding, or suspended state on 'First Storage Group'. Move-ClusteredMailboxServer cannot be performed if one or more of the server's storage group copies are in failed, seeding or suspended states.
At line:1 char:28
+ Move-ClusteredMailboxServer <<<< exchange2 -TargetMachine CCR2 -MoveComment:"Failover Test"
[PS] C:\>

If you check the storage group in the Exchange Management Console (EMC), you will see that the Copy Status is Initializing, as shown below:

This happens because the CCR copy status stays in an initializing state until at least one transaction log has been replicated to the target node. 

As you probably know, the transaction logs in Exchange 2007 are 1MB in size, as opposed to 5MB in previous versions of Exchange.  To get the copy status to Healthy, simply send 1MB of email to or from a user on that storage group.  Now you can failover the CCR cluster to the other node.

Read more ...

How to Brand OWA 2007 and 2010 with the Server Name

If your Exchange 2007 or Exchange 2010 environment includes more that one CAS server, it's sometimes helpful to know which one a client is connecting to.  Environments with more that one CAS usually use some form of hardware or software load balancing, making it difficult to troubleshoot OWA issues.

A relatively easy way to do this is to brand each CAS server's OWA logon page with the server name.  This way, end-users are able to provide the server name if they run into problems.

For Exchange 2007, navigate to C:\Program Files\Microsoft\Exchange Server\ClientAccess\owa\auth folder and open the logon.aspx file using Notepad.

Add either of the two edits shown in the screenshot below:

Adding the server name as highlighted above in red will visibly add the server name to the logon screen, as shown below:

Adding the server name as highlighted above in blue will add the server name "invisibly" below the logon screen.  To view the server name, click anywhere on the screen and press CTRL-A to select all.  You can then see the server name, as shown below:

For Exchange 2010, navigate to the C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\auth folder and open the logon.aspx file using Notepad.


Add the server name, as shown in the screenshot below:

This will add the server name to the logon screen, as shown below:

Important Note: These edits are overwritten anytime an Exchange Server update is applied to the CAS servers.  This is because every update includes a complete reinstallation of the Exchange binaries, and the logon.aspx file you edited will be overwritten.

Typically, the logon.aspx page rarely changes, so you can usually make a copy of it after you've made your edits and copy it back after the update.  However, there are no guarantees that the file will not be changed by an update.  If so, you will need to re-edit the logon.aspx file.

Read more ...

How to Use Telnet to Send SMTP Email to Exchange 2007 and 2010

Unlike previous versions of Exchange, Exchange Server 2007 and Exchange 2010 use strict RFC compliance to send and receive SMTP email.  This can cause some unexpected behavior if a server or application the sends email to Exchange does not comply with RFC 5322 or RFC 2822.

Many email administrators know how to use the Telnet client to send SMTP email.  In this article I’ll show you how to send RFC compliant email using Telnet.  Doing so also allows you to also add X-Headers to your email, which I’ll explain later.

First, you need to have access to the Telnet client.  This is already installed as part of the operating system on all Windows platforms prior to Windows Vista or Windows 2008.

To install the Telnet Client for Windows Vista and Windows 7:

1. Open Control Panel > Programs and Features
   
2. Select Turn Windows features on or off
   
3. In the list that appears, check the box beside Telnet Client
   
4. Click OK
   

For Windows Server 2008 and Windows Server 2008 R2:

1. Open Server Manager and select Features
   
2. Click Add Features
   
3. Check Telnet Client, click Next and Install
   

You may also want to try PuTTY.  PuTTY is a free Telnet/SSH client that has extended features, such as logging and appearance personalization.  More importantly, PuTTY allows you to use the backspace key to correct typing mistakes – something the Telnet client won’t do.

So, on with the demo.  Let’s start first with an example of the way most people use Telnet to send email.  Use your Telnet client to connect to the SMTP server on port 25 and issue the following commands.  I’ve color coded what I type in blue and what the server returns in maroon.

telnet exchange.domain.com 25
220 exchange.domain.com Microsoft ESMTP MAIL Service ready at Sun, 28 Mar 2010 08:49:36 -0700
helo domain.com
250 VLHC.scif.com Hello [10.1.117.29]
mail from:user1@domain.com
250 2.1.0 Sender OK
rcpt to:user2@domain.com
250 2.1.5 Recipient OK
data
354 Start mail input; end with <CRLF>.<CRLF>
Subject:Test email using Telnet
This is a test.
.
250 2.6.0 <9c642f92-e0e3-4b9e-b3d3-21054eed3247@exchange.domain.com> Queued mail for delivery
quit
221 2.0.0 Service closing transmission channel
Connection to host lost.

Assuming that the recipient email address is valid and the configuration on the Exchange server allows the email to be relayed, this results in an email being sent to user2@domain.com.  However, you will notice a few peculiar things about the email that was received.

First, the To: field in the email is blank.  If you look at the SMTP headers, you will see that the To: header shows “Undisclosed recipients:;”, as shown below.

The second issue with the email is that the body of the message is blank.  It should show “This is a test.”

Here’s how to send that same email using RFC 2822 compliance to have it displayed correctly in Outlook.  Use your Telnet client to connect to the SMTP server on port 25 and issue the following commands.  This time I've used the color green to indicate the changes.

telnet exchange.domain.com 25
220 exchange.domain.com Microsoft ESMTP MAIL Service ready at Sun, 28 Mar 2010 08:52:17 -0700
helo domain.com
250 VLHC.scif.com Hello [10.1.117.29]
mail from:user1@domain.com
250 2.1.0 Sender OK
rcpt to:user2@domain.com
250 2.1.5 Recipient OK
data
354 Start mail input; end with <CRLF>.<CRLF>
to:user2@domain.com
Subject:Test email #2 using Telnet
          <---This is a CRLF
This is a test.
.
250 2.6.0 <10c637ec-f8fb-4753-85c4-76d5c4f76108@exchange.domain.com> Queued mail for delivery
quit
221 2.0.0 Service closing transmission channel
Connection to host lost.

This results in an email where the To: field is displayed correctly in both the SMTP headers and the email itself, and the body of the message is displayed, as shown below.

The difference between the two emails are the “to:user2@domain.com” immediately after the “data” command and before the “Subject:…” command.  There must also be a blank line after the
Subject and before the body of message is entered.

Technically, the to: line can be entered as either to:user2@domain.com or to:John Smith <user2@domain.com>.  Outlook will attempt to auto-resolve the To: line to the display name stored in Active Directory and will overwrite the display name entered.  Keep in mind that the
To: command does not have to match the address used in the RCPT command. If the address entered cannot be resolved, Outlook will display the display name listed on the To: line, or just the email address if none was entered.

If you want to add a custom X-Header, you add it anytime after the DATA command and before the Subject:... command.  For example:

data
354 Start mail input; end with <CRLF>.<CRLF>to:user2@domain.com
X-My-Test-Header:My Data
Subject:Test email with custom X-Header

This results in the X-My-Test-Header: My Data being added to the SMTP header, as shown below:

X-Headers are often used to add metadata to an email message.  Antivirus and anti-spam solutions usually add some form of X-Header to emails to show what type of processing has occurred and possibly what score has been applied to the message.

You can use the X-Headers to create Hub Transport rules that act upon messages in a particular way. For example, you can set the Spam Confidence Level (SCL) on a message based on the anti-spam solution's score, reported in an X-Header.

You can also use this method to test that the X-Headers are promoted properly in Exchange. You can read more about named property promotion here.

Read more ...

Fixing Leading and Trailing Whitespace in Exchange Objects

You must remove all the leading and trailing spaces from Exchange 2000/2003 user names, group names, and Public Folder names prior to migrating them to Exchange 2007 or Exchange 2010.  Previous versions of Exchange and Outlook would let you create these objects, usually by accident.  Exchange 2007 and Exchange 2010 have strict conformance rules that will not allow this, so you'll have to fix it before the objects are migrated.

For example, you may use the Exchange AddReplicaToPFRecursive.ps1 script to add your Exchange 2007 or 2010 servers as replicas to your Public Folders.  If the Public Folder contains leading or trailing whitespace you will receive an error in the Exchange Management Shell (EMS):

Set-PublicFolder : The Name property contains leading or trailing whitespace, which must be removed.
At C:\Program Files\Microsoft\Exchange Server\Scripts\AddReplicaToPFRecursive.ps1:147 char:24
+ $_ | Set-PublicFolder <<<< -server $_.OriginatingServer;
WARNING: Object \Information Technology\Website Resources\Software Development has been corrupted and it is in an inconsistent state. The following validation errors have occurred:
WARNING: The Name property contains leading or trailing whitespace, which must be removed.

Use the following PowerShell one-liners to trim the leading and trailing whitespace from Exchange objects in AD:

USER OBJECTS

---

Single User Object:
Get-Mailbox -Identity USER | Foreach { Set-Mailbox -Identity $_.Identity -DisplayName $_.DisplayName.Trim() }

All User Objects:
Get-Mailbox | Foreach { Set-Mailbox -Identity $_.Identity -DisplayName $_.DisplayName.Trim() }

---

PUBLIC FOLDERS

---

Single Public Folder:
Get-PublicFolder -Identity "\Test\SubPath\PublicFolderName" | Set-PublicFolder -Identity $_.Identity -Name $_.Name.Trim()

All Public Folders:
Get-PublicFolder -Identity "\" -Recurse -ResultSize Unlimited | Foreach { Set-PublicFolder -Identity $_.Identity -Name $_.Name.Trim() }

---

DISTRIBUTION GROUPS

---

Single Distribution Group:
Get-DistributionGroup -Identity GroupName | Set-DistributionGroup -Identity $_.Identity -DisplayName $_.DisplayName.Trim()

All Distribution Groups:
Get-DistributionGroup | Foreach { Set-DistributionGroup -Identity $_.Identity -DisplayName $_.DisplayName.Trim() }

---

Note: These commands all give a warning if the object is not changed, which you can safely ignore:

WARNING: The command completed successfully but no settings of '\xxxxx\xxxxxx\xxxxx\IT Department Calendar' have been modified.


Another configuration that can cause errors is when a Public Folder alias contains spaces. Use the following one-liners to remove spaces from Public Folder aliases:

---

Remove Spaces From a Single Public Folder Alias:
Get-PublicFolder -Identity "\Test\SubPath\PublicFolderName" | Get-MailPublicFolder |
Where {$_.Alias -like "* *"} | ForEach-Object { Set-MailPublicFolder $_.identity -Alias:($_.Alias -Replace " ","") }

Remove Spaces From All Public Folder Aliases:
Get-PublicFolder -Identity "\" -Recurse -ResultSize Unlimited | Get-MailPublicFolder |
Where {$_.Alias -like "* *"} | ForEach-Object { Set-MailPublicFolder $_.identity -Alias:($_.Alias -Replace " ","") }

---

These PowerShell one-liners demonstrate how easily some tasks can be performed.  This might take days to do using the GUI with thousands of objects.

Read more ...

How to Securely Deploy iPhones with Exchange ActiveSync - Phase 6 - End-User Deployment of the ActiveSync Profile

This is the seventh and last post in my series, How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise. To read an overview of the solution click here.  In this phase I will demonstrate the steps and procedures that the end-user will perform to configure their iPhone for ActiveSync.  I will also cover some advanced reverse proxy configurations, such as using Microsoft Threat Management Gateway (TMG), ISA, Tivoli Access Manager (TAM), etc.

As a review, the infrastructure has been built and the necessary software and certificates have been installed and configured.  Members of the ActiveSync Administrators group configure iPhone Configuration Profiles, one per iPhone, which includes the user's ActiveSync configuration settings and the ActiveSyncUser user certificate.  Each iPhone Configuration Profile (iCP) is married to the iPhone and exported to the EAS share, which is also a website virtual directory on the CAS server.  The iCP is named for the user for which it is intended (i.e., jqsmith.mobileconfig).

In this final phase, the user authenticates to the EAS website using Safari from the iPhone.  The iPhone automatically downloads the iCP that matches the username.

Here are the steps in detail:

The user is instructed to tap Safari on the iPhone and navigate to https://webmail.companyabc.com/eas (where webmail.companyabc.com is the public FQDN for the CAS server).  The user logs into the Secure Website using the user's AD logon name and password, as shown:

After successfully logging in, the iPhone will download the user-specific ActiveSync Configuration Profile, as shown.

The green Verified indication signifies that the profile was encrypted and signed for this device.

If the user taps More Details on the profile, the details of the configuration profile are displayed showing the ActiveSync server and the email address used in the configuration profile, as shown.  Note that the user cannot tell that a user certificate is embedded in the configuration profile.

Back on the Install Profile screen, tap Install and Install Now to begin installing the profile.

Note that the iPhone only supports one Exchange ActiveSync profile at a time (I sincerely hope this changes in the near future).  If the user already has Exchange ActiveSync configured, the iPhone will display the warning, "Can't install Profile. Only one Exchange account can be set up at a given time."  Remove the existing ActiveSync settings and begin the process again.

If the iPhone already has a passcode configured, the user will need to enter it at this time to begin installing the profile.

During installation of the profile the user is prompted for his/her AD password to connect to their mailbox, as shown:

Enter the AD password, tap Return, and then tap Next to complete installation of the profile.  When the profile has been successfully installed, tap Done.  The user can now close Safari.

If a device lock passcode has been configured in the Exchange ActiveSync Policy, the iPhone will display a message that the user must accept the new policy.  It will then prompt the user for a passcode using the complexity requirements specified in the EAS policy.

It may take a few minutes to complete synchronizing the user's email, calendar, contacts and tasks for the first time.

If at any time in the future the user needs to re-install the ActiveSync Profile on the iPhone (for example, after a hardware reset or software restore), simply follow these steps again.

Removing the ActiveSync Profile
If the user wants to remove the ActiveSync Profile, follow these steps.  Removing the ActiveSync profile also removes the user certificate from the iPhone.

Tap Settings on the iPhone home screen and then tap General.  Scroll to the bottom and tap Profiles.  Tap the profile to remove and then tap Remove.  If the iPhone has a passcode configured, it must be entered to remove the profile.


Reverse Proxy Scenarios
Some environments secure their Client Access Servers from direct Internet communication using Microsoft ISA, Threat Management Gateway (TMG) server, or another reverse proxy solution.

In these scenarios, the public ActiveSync connection and authentication is made at the reverse proxy.  The reverse proxy then proxies the authentication to the internal CAS server(s).  The CAS servers, themselves, act as reverse proxies to the mailbox servers.

With an environment such as this, you need to install the certificate and private key on the reverse proxy server(s).  The reverse proxies need to be configured to require client certificates and use Basic Authentication.  They must then pass the certificate, username, password to the CAS servers to complete the connection.  This diagram should help.

I hope this series helps you with the deployment of iPhones in your Exchange ActiveSync environment.  I welcome your comments.

---

This concludes my series, How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise.

Other articles in this series:

• How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise
• Phase 1 - Building the CA
• Phase 2 - Configuring ActiveSync and Active Directory
• Phase 3 - Publishing User Certificates to Active Directory
• Phase 4 - Creating the iPhone Configuration Profile
• Phase 5 - Creating the Web Site for iPhone Profile Deployment
• Phase 6 - End-User Deployment of the ActiveSync Profile

Read more ...

How to Securely Deploy iPhones with Exchange ActiveSync - Phase 5 - Creating the Website for iPhone Profile Deployment

This is the sixth post in my series, How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise. To read an overview of the solution click here.  In this phase, we will create the deployment website that end-users will use to download the appropriate iPhone Configuration Profile created in Phase 4.

Since you're most likely using Outlook Web Access served up by the CAS servers, these make a natural choice for hosting the website.  I'll cover how to do this using a single CAS server and then follow up with guidance and best practices for environments with multiple CAS servers.

Add the ASP Role Service to the Web Server
Begin by logging into the CAS server with administrator credentials and opening Server Manager.  Expand Roles and select Web Server (IIS).  Right-click Web Server (IIS) and select Add Role Services.  Under Application Development add the ASP role service, as shown.

Click Next and Install to complete the installation.  No restart is required.

Create the EAS Virtual Directory
Open Internet Information Services (IIS) Manager.  Expand the CAS server name > Sites > Default Web Site.  Right-click Default Web Site and choose Add Virtual Directory.  Enter EAS for the Alias and click the (...) button to browse for the Physical Path.  Navigate to C:\inetpub\wwwroot and click the Make New Folder button.  Name the new folder EAS and click OK twice.

Configure the EAS WebSite Permissions
Right-click the new EAS virtual directory and choose Edit Permissions.  Click the Sharing tab and configure the EAS share with the following share permissions: Add ActiveSync Users (Read) and ActiveSync Admins (Full Control).  Remove Everyone from the share permissions. 

On the Security tab click Advanced and Change Permissions.  Uncheck Include inheritable permissions from this object's parent, click Add (for Windows Server 2008, click Copy), and click OK twice.  Click Edit and remove the Users (CASname\Users) group.  Add ActiveSync Users (Read & Execute, List Folder Contents, Read) and ActiveSync Admins (Full Control), and click OK twice.

Configure the EAS WebSite Authentication
Select the EAS website and double-click Authentication.  Disable Anonymous Authentication and enable Basic Authentication.  Select Basic Authentication and click Edit in the Actions pane.  Enter the domain name for the Default Domain and click OK.

Configure MIME Handling
MIME handling tells the web server how to handle different file extensions and associates file extensions with applications.

Select the EAS website and double-click MIME Types.  Click Add in the Actions pane.  Enter mobileconfig for the File name extension and application/iphone-configuration for the MIME type, as shown, then click OK.

Create the Default Document for the EAS Website
We now need to create a default ASP document for the folder.  This ASP page will be used to cause the iPhone to automatically download the correct iPhone Configuration Profile.

Download the default.asp page here.  Edit default.asp to replace webmail.companyabc.com in the second to last line with the FQDN of your publicly available CAS server.  Save the file in the EAS folder.  You can now close Internet Information Services (IIS) Manager.

Putting It All Together
Now that we have the EAS share and website configured, it's simply a matter of exporting the iPhone configuration profiles to the EAS share (as described in Phase 4), using the ActiveSync user's logon name as the name of the file (for example, jqsmith.mobileconfig). 

You then instruct the user to enter https://webmail.companyabc.com/eas in Safari from the iPhone.  The user will be prompted for authentication to access the website.  After the user enters his/her AD username and password, the iPhone Configuration Profile that matches the logon name will be downloaded to install on the iPhone.  I'll cover those steps in detail in the final phase.

Special Configuration for Multiple CAS Servers
If your environment has more than one CAS server in a load-balancing solution used for OWA, you need to perform the procedures above for each of those CAS servers.

You will also need to make sure that you copy the encrypted and signed iPhone Configuration Profiles to each CAS server's EAS share when you export it.  If this pertains to your environment, I recommend using DFS to replicate and distribute the profiles amongst the participating CAS servers.  With DFS you can save the iPhone Configuration Profiles to \\domain\EAS and it will replicate to all the CAS servers automatically.

This completes the configuration of the EAS deployment website.

---

This concludes Phase 5 of my series, How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise.  In the last phase I will provide the end-user instructions and procedures.

Other articles in this series:

• How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise
• Phase 1 - Building the CA
• Phase 2 - Configuring ActiveSync and Active Directory
• Phase 3 - Publishing User Certificates to Active Directory
• Phase 4 - Creating the iPhone Configuration Profile
• Phase 5 - Creating the Web Site for iPhone Profile Deployment
• Phase 6 - End-User Deployment of the ActiveSync Profile

Read more ...