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

Exchange 2010 support for host-based failover clustering and migration

Some Exchange-supported virtualization platforms, such as Hyper-V and VMware include features that support the clustering or portability of guest virtual machines across multiple physical root machines.  Examples of host-based failover clustering and migration include Hyper-V Live Migration and VMware ESX vMotion.

Microsoft support for host-based failover clustering and migration virtualization with Database Availability Groups (DAGs) depends on the Exchange 2010 service pack level.  Per the Exchange 2010 System Requirements:

With Exchange 2010 RTM:

Microsoft doesn't support combining Exchange high availability solutions (such as DAGs) with hypervisor-based clustering, high availability, or migration solutions that will move or automatically failover mailbox servers that are members of a DAG between clustered root servers. DAGs are supported in hardware virtualization environments, provided the virtualization environment doesn't employ clustered root servers, or the clustered root servers have been configured to never failover or automatically move mailbox servers that are members of a DAG to another root server.

With Exchange 2010 SP1 (or later) deployed:

Exchange server virtual machines (including Exchange Mailbox virtual machines that are part of a DAG), may be combined with host-based failover clustering and migration technology, as long as the virtual machines are configured such that they will not save and restore state on disk when moved, or taken offline. All failover activity must result in a cold boot when the virtual machine is activated on the target node. All planned migration must either result in shutdown and cold boot, or an online migration that makes use of a technology like Hyper-V Live Migration. Hypervisor migration of virtual machines is supported by the hypervisor vendor; therefore, you must ensure that your hypervisor vendor has tested and supports migration of Exchange virtual machines. Microsoft supports Hyper-V Live Migration of these virtual machines.

In summary, Exchange 2010 SP1 or better supports hypervisor migrations such as Hyper-V Live Migration and VMware ESX vMotion for DAG member servers.  Host-based failover cluster migrations, such as Hyper-V Quick Migration, is supported only if the virtual Exchange DAG server is restarted immediately after the quick migration completes.  Exchange 2010 RTM is not supported with either migration technology.  RTM only supports the native Exchange high availability features present in DAGs.

Other Exchange Server 2010 roles (CAS, Hub Transport, Edge Transport, and Unified Messaging) fully support host-based failover clustering and migration because they do not employ native Exchange high-availability solutions.

For a list of the virtualization platforms supported by Exchange, visit the Windows Server Virtualization Validation Program website.

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

New Prerequisite for Exchange 2010 SP2

Exchange Server 2010 Service Pack 2 (SP2) was released today without the accompanying release notes.  Until they are released, know that SP2 requires an additional role service for Client Access Servers to support the new Outlook Web App Mini feature: The IIS 6 WMI Compatibility component.

Before you install Exchange 2010 SP2 you need to add this role service using either of the two following methods.

From Windows Server Manager:

• Open Server Manager and navigate to Roles | Web Server (IIS)
• Right-click Web Server (IIS) and select Add Role Services
• Scroll down to IIS 6 Management Compatibility and select IIS 6 WMI Compatibility and click Install

From Windows Powershell:

• Open Windows Powershell as administrator
• Enter the following commands:

Import-Module ServerManager
Add-WindowsFeature Web-WMI

Now you can install Exchange 2010 SP2 as planned.

Read more ...

Exchange 2010 Service Pack 2 is Now Available

Today Microsoft released Exchange Server 2010 Service Pack 2 (SP2).  Along with numerous bugfixes, SP2 includes the following new features:

• Cross-Site Silent Redirection for Outlook Web App (a.k.a. my favorite new feature): With Service Pack 2, you will have the ability to enable silent redirection when CAS must redirect an OWA request to CAS infrastructure located in another Active Directory site. Silent redirection can also provide a single sign-on experience when Forms-Based Authentication is used. Yes!
• Address Book Policies: Allows organizations to segment their address books into smaller scoped subsets of users providing a more refined user experience than the previous manual configuration approach. The Exchange Team blogged about this new feature recently in GAL Segmentation, Exchange Server 2010 and Address Book Policies.
• Outlook Web App (OWA) Mini: A browse-only version of OWA designed for low bandwidth and resolution devices. Based on the existing Exchange 2010 SP1 OWA infrastructure, this feature provides a simple text based interface to navigate the user’s mailbox and access to the global address list from a plurality of mobile devices.
• Hybrid Configuration Wizard: Organizations can choose to deploy a hybrid scenario where some mailboxes are on-premises and some are in Exchange Online with Microsoft Office 365. Hybrid deployments may be needed for migrations taking place over weeks, months or indefinite timeframes. This wizard helps simplify the configuration of Exchange sharing features, like: calendar and free/busy sharing, secure mailflow, mailbox moves, as well as online archive.

All fixes contained within update rollups released prior to Service Pack 2 will also be contained within SP2. Details of the regular Exchange 2010 release rhythm can be found in Exchange 2010 Servicing.

You can download Microsoft Exchange Server Service Pack 2 here.

Read more ...

Adjusting Exchange 2010 DAG Failover in High Latency Networks

Some Exchange 2010 DAG implementations have DAG members that are separated by high latency WAN networks.  In these networks you may find that the increased latency causes unexpected DAG failovers or failures. 

This is especially likely to happen with a two node DAG with a File Share Witness (FSW).  When network latency increases to the point that the cluster heartbeat threshold is reached, the node furthest from the FSW will go offline.  The node that's in the same LAN as the FSW will stay online because it maintains quorum.

There are two properties that specify cluster health, as measured in heartbeats.

• CrossSubnetDelay specifies the heartbeat interval (in milliseconds) between subnets. The default is 1000 milliseconds (1 second).
• CrossSubnetThreshold specifies how many heartbeats can be missed between subnets before cluster failover (or failure) occurs. The default is 5 heartbeats.

With the default settings, any WAN latency that causes 5 missed heartbeats over 5 seconds causes the cluster to fail. This matches the settings used by the SameSubnetDelay and SameSubnetThreshold properties.

If WAN latency causes unexpected cluster failover or failures, adjust the CrossSubnetDelay value to its maximum value of 4000 milliseconds (4 seconds) and the CrossSubnetThreshold property to its maximum value of 10,  With these settings the cluster will not failover or fail until there are 10 missed heartbeats, 4 seconds apart (40 seconds).

This is accomplished from Powershell by doing the following:

• From one of the DAG members open the Windows Powershell Modules in Administrative Tools.  This will launch Powershell and import all the Windows Powershell modules for installed features, including the new Windows Failover Cluster module.
• Run the following one-liner to configure the maximum values:

$cluster = Get-Cluster; $cluster.CrossSubnetThreshold = 10; $cluster.CrossSubnetDelay = 4000

• Check your settings using the following cmdlet:

Get-Cluster | fl *

Since cluster properties are instantly replicated between all nodes in the cluster, this only needs to be configured from one node in the DAG.  The changes go into effect immediately and there is no need to restart services or the server.

Note that you can configure the same properties using cluster.exe, but I'm using Powershell here because cluster.exe is deprecated in Windows Server 2008 R2.

Read more ...

Exchange DAG Cluster Service Terminated with Error 7024

I ran into an interesting issue at a client site yesterday on an Exchange 2010 SP1 DAG member.  One DAG member's databases would not mount (even Public Folders) and the Cluster service would not start.  The DAG is configured as a three member stretched DAG, with two nodes in the main site and another in the DR site.

The event IDs logged were:

Log Name:      System
Source:        Service Control Manager
Date:          10/23/2011 12:07:44 AM
Event ID:      7024
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      EX03.domain.local
Description:
The Cluster Service service terminated with service-specific error Log service encountered an invalid log block..

Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          10/23/2011 12:00:43 AM
Event ID:      1177
Task Category: Quorum Manager
Level:         Critical
Keywords:     
User:          SYSTEM
Computer:      EX03.domain.local
Description:
The Cluster service is shutting down because quorum was lost. This could be due to the loss of network connectivity between some or all nodes in the cluster, or a failover of the witness disk.
Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapter. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.

Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          10/23/2011 12:00:43 AM
Event ID:      1135
Task Category: Node Mgr
Level:         Critical
Keywords:     
User:          SYSTEM
Computer:      EX03.domain.local
Description:
Cluster node 'EX02' was removed from the active failover cluster membership. The Cluster service on this node may have stopped. This could also be due to the node having lost communication with other active nodes in the failover cluster. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapters on this node. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.

Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          10/23/2011 12:00:43 AM
Event ID:      1135
Task Category: Node Mgr
Level:         Critical
Keywords:     
User:          SYSTEM
Computer:      EX03.domain.local
Description:
Cluster node 'EX01' was removed from the active failover cluster membership. The Cluster service on this node may have stopped. This could also be due to the node having lost communication with other active nodes in the failover cluster. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapters on this node. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.

The cluster failed when two of the three DAG members (EX01 and EX02) went offline at 12:00:43 AM due to a network failure in the active site.  For some reason, this corrupted the CLUSDB.BLF file on the member in the DR site which prevented that node from coming online when the network came back up.  CLUSDB.BLF is a CLFS Base Log File used by the cluster service which contains metadata that is used to manage access to the log data. 

To correct the problem, navigate to the %WINDIR%\Cluster folder and rename CLUSDB.BLF to CLUSDB.BLF.OLD.  Then restart the Exchange server.  The cluster service will generate a new CLUSDB.BLF file on restart.  The cluster service will be able to start and the databases will mount.

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

Exchange 2010 SP1 Quorum Configuration Doesn't Failback to Node Majority

Fellow MVP and work colleague, Tom Pacyk, wrote about a problem we've seen with Exchange 2010 SP1 UR3 where the quorum configuration does not change back to Node Majority after all odd numbered DAG members are online.  You can read Tom's article, File Share Witness and Datacenter Failback, here.

This seems to occur when the alternate file share witness (FSW) is invoked during a complete datacenter failure in the primary site.  The DAG quorum configuration switches to Node and File Share Majority in that case, but does not switch back to Node Majority automatically for some reason when the primary datacenter comes back online.

As Tom writes, the fix is to run the Set-DatabaseAvailabilityGroup DAGName cmdlet without any other parameters.  Exchange realizes that the quorum configuration is not correct and fixes it.

Read more ...

How to Configure Exchange 2010 SP1 Federation

Exchange federation allows different Exchange organizations to share free/busy information with each other.  It does this without having to configure a one- or two-way trust between the organizations.

Federation is accomplished using the Microsoft Federated Gateway server, a free cloud-based service offered by Microsoft.  The Microsoft Federated Gateway (MFG) server acts as a trust broker between federated organizations, similar to the way a trusted root CA works for certificates.  All organizations that use federation must configure a one-time federation trust with the MFG, and orgs that share free/busy information must have an Organization Relationship with the other org(s) they want to share with.  Organization Relationships (sometimes called sharing policies) can be one-way, meaning that CompanyABC can share free/busy info with CompanyXYZ, but not necessarily the other way around.  Usually, each org will have a reciprocal Organization Relationship with the other org so they can see each other's calendar data.

There are a number of articles that explain how to configure federation, but all of them are for Exchange 2007 or Exchange 2010 RTM.  Exchange Server 2010 SP1 simplifies federation configuration, primarily by eliminating the requirement for a trusted-CA certificate and providing most of the federation configuration from the Exchange Management Console (EMC).

Microsoft also changed the Microsoft Federation Gateway servers in Exchange 2010 SP1.  The RTM version uses what Microsoft calls the "consumer instance" of MFG and requires a trusted certificate for federation.  SP1 uses the same Microsoft Online Services MFG used by the Business Productivity Online Suite (BPOS) and Office365, Microsoft's cloud offerings.  This new Online Services MFG uses self-signed certificates for federation (recommended), but can also still use trusted third-party certs.

If you are using the new SP1 MFG and try to create an organization relationship with an external org that uses the RTM MFG, you will see the following warning:

Warning:
The token issuers for the domain extrateam.com (uri:WindowsLiveID) don't match the issuer for your organization (urn:federation:MicrosoftOnline).

The following guide explains how to configure federation between two Exchange 2010 SP1 organizations.

Note: This article assumes there is a working autodiscover record for the partner organization.  Federation uses autodiscover to automatically configure the Organization Relationship for the remote org.  If autodiscover is not working, you will need to enter that information manually.

Create a new Federation Trust

• Open the Exchange Management Console (EMC) and select the Organization Configuration node.
• In the Actions pane, select New Federation Trust.  The New Federation Trust wizard will run.
• Click New to form the new trust with the Microsoft Federation Gateway.  The wizard will create a new self-signed certificate called Exchange Delegation Federation with the subject name of Federation.  The Federation and SMTP services will be assigned to this certificate, but it will not change the default SMTP certificate.  The Microsoft File Distribution service will automatically copy and install this self-signed certificate to all of your Exchange 2010 client access servers.
• Click Finish to close the wizard.

Create Domain Proof Records
Domain Proof records are TXT records created in your domain's external DNS zone.  The purpose of these TXT records is to prove the identity of your domain for the trust with the MFG server.  Exchange SP1 requires that you have at least two TXT records, one dedicated for domain delegation (typically, exchangedelegation.companyabc.com) and another for each SMTP domains you use for users (for example, companyabc.com).

Run the following cmdlets from the Exchange Management Shell (EMS) to generate the domain proof values:

Get-FederatedDomainProof -DomainName exchangedelegation.companyabc.com
Get-FederatedDomainProof -DomainName companyabc.com

Repeat the second cmdlet for additional SMTP domains you want to federate, if any.

Each cmdlet will generate a unique Proof value, based on a hash using the Exchange Delegation Federation self-signed certificate.  If the MFG can read the domain proof value in an external DNS record and it matches the calculated value, it proves domain ownership and validates the trust.

You must create one TXT record in external DNS for each of the Proof values.  How you do this depends on your external DNS management platform.  Here's how that looks for Microsoft DNS:

And here's how it may look in a managed DNS web GUI:

Remember, these TXT records should be entered in your external DNS, not internal.  You may need to wait a bit for the new TXT records to propagate across the Internet.  You will be unable to manage the federated domains until the MFG servers can access the domain proof TXT records.

Manage the Federated Domains
Once the domain proof TXT records have propagated you can add the federated domains to the Federation Trust.  But before we can add the federated domains, we must first add the new exchangedelegation.companyabc.com namespace to the Accepted Domains on the hub transport configuration.

• Back in the EMC navigate to Hub Transport in the Organization Configuration node.
• Click the Accepted Domains tab and click New Accepted Domain in the Actions pane.
• Enter Exchange Federated Delegation for the Name and enter exchangedelegation.companyabc.com for the Accepted Domain, then click New.  This new authoritative accepted domain will never be used by users - it is only used by the federated trust.

• Click the Organization Configuration node and select the Microsoft Federation Gateway trust under the Federation Trust tab.
• Click Manage Federation in the Actions pane.  You will see the current federation certificate status.  You can click Show distribution state to check that the federation certificate is installed on all Exchange 2010 client access servers. 
• Click Next to bring up the Manage Federated Domains window. 
• Click Add and select the Microsoft Federated Trust accepted domain you created earlier.  I recommend adding just the Microsoft Federated Trust first, which creates the delegation namespace on the MFG server, the unique Application Identifier (AppID) and Application URI.  Then go back and add the SMTP domain(s) you want to federate (i.e., companyabc.com).

• Click Next and Manage to configure Microsoft Federated Trust.  When the configuration is successful you will see the federation trust has an Application Identifier and Application URI.

• If the TXT records you created earlier are incorrect or have not propagated yet to the MFG server, you will get the following error:

Error:
Proof of domain ownership has failed. Make sure that the TXT record for the specified domain is available in DNS. The format of the TXT record should be "example.com IN TXT hash-value" where "example.com" is the domain you want to configure for Federation and "hash-value" is the proof value generated with "Get-FederatedDomainProof -DomainName example.com".
The proof of domain ownership is not valid or is missing.

• Once you have configured the original Microsoft Federated Trust you can repeat these steps to add your other accepted domains.  You can only add accepted domains that you have created domain proof TXT records for.

Create Organization Relationships
Now that the federated trust has been created and then validated by the MFG, you can create organization relationships.  These are the federation sharing policies that determine what is shared with whom.

• Click the Organization Relationships tab on the Organization Configuration node in the EMC.
• Click New Organization Relationship in the Actions pane.  The New Organization Relationship wizard will start.
• Enter a name, such as Share with CompanyXYZ.
• Select the Enable free/busy information access checkbox and specify the free busy data access level you wish to share using the dropdown box.
• You may select a security group for which this relationship should apply.  If you do not select a security group the settings will apply for all users.

• Click Next to enter the External Organization details.
• Enter the domain you want to federate with (i.e., companyxyz.com), then click Next and New.  Exchange will create a new organization relationship using the data results from the Get-FederationInformation cmdlet.  If the external domain does not have a valid federation trust with the MFG or autodiscover record, you will see an error:

Error:
Federation information could not be received from the external organization.

• When the organization relationship has been successfully configured you will see it listed under the Organization Relationships tab.  Sharing Enabled and Calendar enabled will show as True.

Testing and Troubleshooting
Use the following command to query for TXT records in DNS:

nslookup -q=txt companyabc.com [DNS server name to query]

Use the following cmdlets to get or test Exchange federation configuration information:

• Get-FederatedOrganizationIdentifier - gets the Microsoft Exchange Server 2010 organization's federated organization identifier and related details, such as federated domains, organization contact, and status.  The Enabled attribute will show as False until the MFG has validated the trust using the domain proof TXT records in external DNS.
• Get-FederationInformation - gets federation information, including federated domain names and target URLs, from an external Exchange organization.  It does this using the autodiscover record of the external domain.  This cmdlet will not work until you have a valid Federated Trust configured.
• Get-FederationTrust - displays the federation trusts configured for the organization.  Use with Format-List to display the ApplicationIdentifier and ApplicationUri attributes, details about the federation certificates. and token information.
• Get-OrganizationRelationship - gets settings for a relationship that has been created for free/busy information access or secure e-mail delivery using federated delivery.
• Test-OrganizationRelationship - verify that the organization relationship is properly configured and functioning as expected for a given user.
• Test-FederationTrust - runs the following series of tests to ensure that federation is working as expected:
  • A connection to the Microsoft Federation Gateway is established.  This test ensures that communication between the local Exchange server and the Microsoft Federation Gateway is working correctly.
  • Certificates are checked to ensure they're valid and can be used with the Microsoft Federation Gateway.
  • A security token is requested from the Microsoft Federation Gateway.  This test ensures that a token can be properly retrieved and used.
  
  
  Note that you must run the Test-FederationTrust cmdlet from either an Exchange Server 2010 Hub Transport or Client Access server.

If you're federating with a mixed-mode Exchange organization with Exchange 2003 users (as in a migration scenario) you will need to populate the TargetSharingEpr attribute of the Organization Relationship with that domain.  If you don't populate this value the free/busy information for Exchange 2003 users will be unavailable.  Populate the TargetSharingEpr value  in both organizations with the following cmdlet:

Set-OrganizationRelationship "CompanyABC" -TargetSharingEpr https://mail.companyabc.com/EWS/Exchange.asmx/WSSecurity

Replace mail.companyabc.com with the FQDN used by the external organization's Exchange Web Services (EWS) ExternalURL.  For example, run the following cmdlet in CompanyABC:

Get-WebServicesVirtualDirectory -Server ex2010 | fl ExternalUrl

ExternalUrl : https://email.companyabc.com/ews/exchange.asmx

CompanyXYZ should set Organization Relationship's TargetSharingEpr for CompanyABC to https://email.companyabc.com/EWS/Exchange.asmx/WSSecurity

Continuing the example, run the same cmdlet in CompanyXYZ:

Get-WebServicesVirtualDirectory -Server exchange01 | fl ExternalUrl

ExternalUrl : https://webmail.companyxyz.com/ews/exchange.asmx

CompanyABC should set Organization Relationship's TargetSharingEpr for CompanyXYZ to https://webmail.companyxyz.com/EWS/Exchange.asmx/WSSecurity

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

Error Running New-TestCasConnectivityUser.ps1

I ran into a strange problem running the New-TestCasConnectivityUser.ps1 script at a client today. When I ran the script to create the test account on a new Exchange installation, I received the following error:

CreateTestUser : Mailbox could not be created. Verify that OU ( Users ) exists and that password meets complexity requirements.

I verified that I could create a user account in the User container in AD just fine using the same password I supplied in the script. Obviously, I had sufficient rights and the password was complex enough.

After examining the new-TestCasConnectivityUser.ps1 script I noticed that the $OrganizationalUnit variable is looking for a match in AD for "Users". A quick search using AD Users and Computers found that the client had many OU's named Users throughout AD. The script was actually bombing out because it didn't know which "Users" OU to use.

The fix is to add the following line below line 171 in the script to make it look for a better (more specific) match:

OrganizationalUnit = "CN=Users,DC=domain,DC=com"

Be sure to edit this to match your domain naming context.



Then save the script and run it.

Read more ...

TechEd 2011: Day 2 Review and Random Photos

Second day is nearly done.  I started off with another Laura Chappell session, "We Don't Need No Stinkin' GUI: Command-Line Capture Techniques (Remote Options)".   It sounded good when I signed up for it, but it wasn't right for me.  Unfortunately, it was on the far side of the planet and took a very long time to get to my second choice, "Hyper-V and Dynamic Memory in Depth".  This was a better fit and I enjoyed what I saw of it.

Next up was "Best Practices for Virtualization for Microsoft Exchange 2010" which I decided to attend because of the new virtualization support agreement. Now that Live Migration is supported, I asked if vMotion is, as well.  The answer was, "We support Live Migration type technologies, as long as they're on the virtualization support list."  Throughout the sessions, I've decided to tweet important points that are discussed or mentioned.  Follow me on Twitter if you'd like to keep up.  WIFI is much better this year and I've not found any connectivity issues so far.

The next session was "Load Balancing with Microsoft Exchange 2010".  Really good session and demo with F5 hardware load balancers.  Awesome equipment and this was one of the best deep-dive sessions so far.  Lots of good info, but it was covered fast.  There was really nothing new in this session from last year, but if you want to do a proper large-scale deployment you have to get the load balancers right.

Attendees evaluating their swag

Some of The Krewe

Stephen Rose (Sprinboard), Joey Snow and Adam Carter (Channel 9/Edge)

Michael Bender (@TheKrwe) and Jessica Anderson from Xiotech, a sponsor of The Krewe Meet-N-Greet

Read more ...

TechEd 2011: Day 1 Review and Random Photos

The Georgia World Congress Center

 Whew, TechEd Day 1 is in the bag!  And speaking of which, here's what the TechEd bag looks like.



The TechEd 2011 Bag


Yesterday was a day to get registered, meet up with other people, and get bearings on the conference center.  After that, I was able to take in a game at Turner Field where the Braves beat the Phillies 3-2.

The evening ended with an epic Meet-n-Greet party with The Krewe at STATS bar in Atlanta.  A terrific time was had by all.  We had about 150 people show up, including old and new members of The Krewe.  It was a great time!


The Krewe Meet-N-Greet Party

 Day 1 of TechEd Atlanta started with the keynote address at 9AM with Robert Wahbe, Corporate Vice President of Server and Tools, and Jason Zander, Corporate Vice President of Visual Studio.  As usual, the first hour was devoted to IT Pros and the second for developers.  And as expected, we heard how wonderful life is going to be when we move into the cloud.  As one person tweeted about 15 minutes into the keynote, "Drinking game is cancelled. If I took a drink every time keynote speaker said 'cloud,' I'd be dead by now."

We followed up the keynote with a brief visit to the vendor area and a not so brief trip to the food area (aka, Tennessee, because it's so far away from everything).  As we entered the food area, the wait staff started applauding and cheering us to have a great lunch.  It was like being in a parade.  Very surreal.

My first session was with Laura Chappell on "Wiretapping 101: Catching Evidence on the Network."  It was a good session and was highly technical and entertaining.  Laura is great, but she needs some Ritalin.

I followed that up with my first Exchange session, "What's New in Microsoft Exchange Server 2010 SP2: Featuring GAL Segmentation."  We learned that SP2 will be released in the second half of this calendar year.  It will have over 500 bug fixes and include some knew features which require schema changes.  OWA Mini will be like a completely rewritten OMA for text-based browsers.  GAL segmentation allows you to have more than one Global Address List in the organization.  Users assigned the GAL policy 1 will only see users in that policy, and users assigned GAL policy 2 will only see their users.  There are quite a few caveats about this feature, like it doesn't work for Mac clients.  It's still early in the development cycle, so we'll have to see how it pans out.

They will also have a fix for CAS redirection when a user signs into OWA from a less optimal site.  Rather than logging in and getting a link that says to use a different CAS, and then having to log in again on that CAS, the first CAS will automatically pass credentials to the second CAS.

From 6-9PM was the vendor reception party, where there was mass consumption of food and drink while collecting large amounts of SWAG.  Personally, I wasn't too impressed with the food (bland/cold) and there wasn't much in the way of SWAG.  No biggie, that's not what I'm here for.  It was good hanging out with my friends.

Tomorrow I'll be up bright and early, attending mostly Exchange and Lync sessions.

Here are some random photos from the day:

Welcome to TechEd 2011

The TechEd Alumni Lounge

The vendor area being setup on Saturday

The $5 cell phone charger. The free one is on the left.

Centennial Olympic Park

Me and Aubrey at Turner Field to watch the Braves

Our TechEd Krewe buttons



Tennessee

Me and Scott Ladewig at our special Blogger Hub area in the Connect Zone

 

Read more ...

How to specify which IP address to use for an Exchange Send Connector

If you have multiple IP addresses on and Exchange 2010 Hub Transport server for the same network, Exchange will always use the preferred IP address for all outbound traffic and consequently, the send connector.

There may be times when you want Exchange to use another IP.  Maybe because you already have that IP address configured in your firewalls.  Unfortunately, you can't specify the IP address to use in Exchange for a send connector on Hub Transport servers, only Edge Transport servers.

You can, however, install a hotfix on Windows Server 2008 or Windows Server 2008 R2 servers which allows you to use netsh to disallow certain IPs to be used for outbound traffic.  The hotfix is required for all versions of Windows Server 2008 SP2 and Windows Server 2008 R2 RTM.  It is included in Windows Server 2008 R2 SP1.

Hotfix for Windows Server 2008 SP2: http://support.microsoft.com/kb/975808
Hotfix for Windows Server 2008 R2 RTM: http://support.microsoft.com/kb/2386184/

Once the hotfix is installed, run the following command from an elevated CMD prompt:

Netsh int ipv4 add address <Interface Name> <IP address> skipassource=true

This will cause Windows to disallow the IP address on the specified NIC from being used for outbound network traffic.

Read more ...

Issue with IE9 and the Exchange 2010 Management Console

I ran into this issue today at a customer.  With Internet Explorer 9 installed on the Exchange 2010 server, you cannot close the Exchange Management Console.  When you try to close it, you get the following message: 

You must close all dialog boxes before you can close Exchange Management Console

As of yet, this is unresolved.  See http://social.technet.microsoft.com/Forums/en-US/exchangesvradmin/thread/ea4e1ffe-472e-4508-9a14-0735ac6322ca for other reports of the same problem.

The workarounds are to end task mmc.exe every time or uninstall IE9.

---

10/17/2011 Update:

Finally!  A fix is now available for this issue.

See "A fix for the interoperability issues between Exchange 2007 and 2010 EMC and IE9 is now available" on the Exchange Team blog.

Here is the direct link to the Microsoft download page for the hotfixes.  There are two versions, one for Internet Explorer 9 for Windows Vista SP2 or Server 2008 SP2 and another for Internet Explorer 9 for Windows 7 or Server 2008 R2.

---

9/20/2011 Update:

Thank you all so much for the continued community efforts on other workarounds, aside from the known Task Manager route.

In terms of an update, a fix has been developed and is undergoing testing and various other processes we have to do prior to releasing updates. The work is being carried out by the IE team and as soon as we can provide information on a release date we are confident with, we'll post again.

Regards

Mark Feetham Senior Program Manager Internet Explorer Product Quality

---

8/17/2011 Update:

Tony Redmond is chiming in to see if he can carry any weight in resolving this issue and get a fix from Microsoft more quickly.  You can read his article, Why can’t Microsoft get IE9 to work with the Exchange Management Console? 

As I wrote below, my contacts at Microsoft said they are planning to release the fix with a Q4 service update for IE9.  But for most people this is an inordinate amount of time, being that the issue was reported back in April 2011 and has such a painful effect.

I see two problems here. One is the obviously irritating problem itself, and the other is Microsoft's (the company's) lack of response and information about this issue. I almost think the second problem is more important in this case. When so many users are complaining about an issue and there's little or no authoritative response, it's viewed as a failure and customers don't feel the love.

It's even more aggrivating when the IE9 train keeps coming down the track - IE9 is now listed as an important update in WSUS and will be installed automatically on WSUS clients, MS is pushing IE9 whenever and wherever it can, more companies are deploying it in managed environments. etc. The fact that most users affected are admins running the Exchange management tools from their Win7 desktops is mainly lost here.

Yes, we know we can end task the MMC. Yes, we know that it can be solved by uninstalling IE9 (if possible - it's not in managed environments) and ignore the WSUS update. These do nothing to eliminate the irritation. and having Microsoft seemingly ignore customer complaints does not help.

On a side note, it's noteable that Exchange 2010 is useable and stable enough that (relatively) small irritations like this get a lot of press.

Scott Schnoll of the Exchange Team wrote:

OK, so let's talk about some more details.

Susan mentioned this issue has been around since March.  Based on forum threads and emails I have, it looks like late March is when this issue first surfaced.  And then in April, the issue started getting reported more frequently (although at this point not an alarming frequency) because IE9 was released to Microsoft Update.  As it was reported primarily by Exchange admins on both Exchange 2007 and Exchange 2010 and initially only with the EMC, this was initially thought to be an Exchange bug.  But, given the combination of software bits in use (Exchange, MMC, IE and Windows), this could just as easily have been an IE, Windows or MMC bug.  We (Exchange) didn't know at this point, but nonetheless our product quality team and others took ownership of this issue and began an investigation in late April.

After investigating the matter in Exchange and IE, it was determined in early May (May 4, to be specific) that this was actually an MMC bug. However, after discussing the issue with the MMC team, the IE team took ownership of the bug.  It turns out that there was a similar bug they (IE) fixed in Windows, but that fix did not resolve this issue because MMC hosts the mshtml component directly instead of using a web browser control.  So why did the issue appear with IE9, but not, for example, in IE8?  In a nutshell, in IE9, the "Internet Explorer_Hidden" window has a property flag on it that did not exist in IE8 and earlier. MMC checks for this flag in its process and if any remain open, it will prevent the dialog from being closed and report the error message we've all come to hate.

In any event, after working with the MMC team throughout May, the IE team retained ownership of this issue.  Like all companies, Microsoft has a finite amount of resources (time, money, people, tools, etc.).  So, we prioritize the work we do based on a number of criteria.  Like all bugs, this one has a specific priority and severity, and like some bugs, it's current status is active, which means the bug is being actively worked on by one or more people.  It takes time to work out all of the issues with code bug that can span across multiple products.

So, I would say, first, don't bash the IE team.  The actual bug is within the MMC code, and not in IE or Exchange.  The IE team has graciously stepped up to take ownership of this issue and to provide a fix in IE so that MMC (and any other apps similarly situated) are fixed.  I have personally communicated with the PMs and devs that own this issue and I can assure you that they are well aware of your frustration and that their current plans are to aim for this to be included in the December update.  Note, however, that they did not guarantee that, and that I am not guaranteeing that to you.

They did, however, promise to update me late next month as their plans for the December release solidify, so I should know and be able to report back here in a month or so with an answer as to whether or not it will be in the December update.

Some other points worth raising:
 •While many of us monitor these forums regularly, these forums are not a substitution for reporting bugs by contacting CSS.  If you contact CSS, yes they will ask you for a credit card, but if you are reporting a bug, no charges will be made against your credit card.  In other words, calling CSS to report bugs is basically free (except for your time, of course).  But it is the proper and official way to notify Microsoft of bugs like this.
 •We still want you to report these issues in the forums because lots of us monitor these forums and can take action based on them.  But when it comes down to things like prioritizing bug work and stacking bugs, official customer reports via CSS or another proper escalation path are required.
•We have been somewhat vocal about this.  I spoke about this publicly at TechEd North America in May, and internally in July (at an internal conference) so that the field, PFEs, etc., could spread the word, too.
 •But that said, there really hasn't been much to say about it.  We've detailed the workarounds, but we don't have a fix yet.
 •As much as I would like to keep the forums up-to-date on this and every other issue, it simply is not practical to post regular status updates about every single bug.  Not only would that not scale, it would be unmanageable, as well.  That said, I will post back here when I get more information from the IE team in September.
 •IMHO, this is a very minor issue that, while frustrating, is not pervasive, does not cause any damage or data loss, has viable workarounds and is really inconsequential from a day-to-day perspective (hey, just leave MMC open <g>).

These are my own viewpoints and they do not necessarily reflect the viewpoints of Microsoft.  Nonetheless, I hope they help.

---

6/22/2011 Update:

I've been working with Microsoft via some of my contacts and I finally have a little information to share.

Officially, the statement is:

1. The IE9 engineering team is aware of the issue and actively triaging it.
2. They are considering a fix to be delivered later this year.

Unofficially, the issue has been linked to the Microsoft Management Console (MMC) and Internet Explorer 9.   While the issue is primarily in the MMC, the IE9 team can release a fix sooner than the MMC team.   They are cautiously optimistic that a fix will be released in a Q4 2011 service update.

That's all I've got, folks.   Stay tuned.

Read more ...

Are you an Exchange Maestro?

Register to become an Exchange 2010 Maestro!

Exchange superstarts Tony Redmond and Paul Robichaux will focus on the key “gotchas” and hurdles experienced by IT professionals in the real world. The workshop will cover Exchange 2010 Service Pack 1 as well as the RTM version released by Microsoft in October 2009.

Paul writes,

The Exchange Maestro program is a 300/400-level blitz of all the major features of Exchange 2010. We assume good knowledge of Exchange 2003/2007, and we have enough new material so that even people with some 2010 experience will learn something useful.  In addition to the lecture material, attendees get a full set of Exchange 2010 lab VMs on a take-home disk drive. That frees attendees to focus on learning because they can work on the labs during scheduled lab times, in the evenings, or once they return home.

On the third day we have a sort of capstone exercise where the attendees form teams and design an Exchange 2010 organization, then present their design proposal to Tony, playing the role of a hard-nosed customer CIO.

I have a discount registration code for you to share with your readers: “PAUL” will net $250 off for the US events, and “PAUL100” will net 100 pounds off the London event.

If you administer Exchange 2010, this is a worthwhile opportunity to learn from some of the best! 

Use the discount codes above to save $250 in the US or £100 in Europe off regular registration.  Read more at the Become an Exchange 2010 Maestro website.

Read more ...