Search results for 'app:weblogs' matching tags 'Exchange' and 'Best Practices'

How to Configure Exchange 2010 SP1 Federation

Anonymous — Mon, 18 Jul 2011 05:00:00 GMT

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.

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-FederationDomainProof -DomainName exchangedelegation.companyabc.com
Get-FederationDomainProof -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 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.

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

Comprehensive Guide on Addressing Exchange Calendaring Issues

Anonymous — Tue, 27 Jul 2010 05:00:00 GMT

Rand Morimoto wrote a great article for Network World about Exchange calendaring issues. Rand is the president of Convergent Computing, the company I work for. His article covers lost appointments, duplicate appointments, odd delegate issues, etc. This article is based on the real-world experience we as a company have gained working with many organizations of all sizes.

I wanted to add a few comments of my own, to follow up on to Rand's excellent article.

Another factor that can cause calendar issues for delegates is Cached Exchange Mode, which can cause an artificial delay in updating calendar information. For example, the boss (using Entourage, which doesn't have Cached Mode) may accept or alter the same appointment that the assistant (using Outlook in Cached Mode) accepts or alters. The default Cached Mode settings may cause a delay of up to a minute before the assistant's calendar item is updated on Exchange. Who wins is anybody's guess.

By the way, my recommendation is to adjust the Cached Mode latencies to 1 second using Group Policy. There is virtually no network performance impact and it solves a lot of issues, especially "perceived performance" issues. See http://support.microsoft.com/kb/870926/%20target=.

Regarding BES, RIM is making quite a few changes recently due to inconsistency problems (especially in calendaring). BES 5.0 SP2 is supposed to make huge performance improvements so that BES IOPS are now equal to Outlook (see http://flaphead.com/archive/2010/07/24/bes-5-0-sp2-blackberry-user-exchange-2010-iops-now-equal-to-an-outlook-client.aspx). The rumor is that BES 6.0 will completely re-architect BES to use Exchange Web Services (EWS) rather than MAPI.

That said, BES changes versions as often as we change socks. I find that most orgs are WAY behind on BES versions from the current version, so they can't take advantage of these improvements. And as with any other technology with massive changes, it will probably introduce a new set of unknown problems.

Being that calendaring issues are 99% due to client issues (Outlook, Entourage, BES, iPhone, etc.), I expect that most of these issues will go away as the clients move toward using EWS. The problems documented in Rand's article occur because of the way the clients handle calendaring/email objects. If the client software lets Exchange handle these objects using standard EWS APIs, the problems will diminish/disappear.

Don't be too cheap - call PSS when you get stuck.

bradley — Wed, 24 Mar 2004 05:00:00 GMT

Ray, the SBS guru posted this to the newsgroup... but I'd highly recommend that you pay attention to his note at the bottom about calling PSS. Don't ever be TOO cheap. Yes, calling PSS is a US$245 call, but it is worth every penny. The support folks live and breathe SBS and know this box better than anything else. Don't ever be afraid to reach out for help for your server.

296788 Offline Backup and Restoration Procedures for Exchange
http://support.microsoft.com/?id=296788

I recommend you to make a copy of the old MDBDATA folders. In case 
something goes wrong, you still have an untouch copy.

If the article seems complicated, in a nut shell, here is what you need to 
do.

1. Make a backup of the old MDBDATA folder
2. Stop the Microsoft Exchange Information Store service
3. Delete the files in the mdbdata folder (which contains the new clean 
database)
4. Put back the priv1.edb, priv1.stm, pub1.edb, and pub1.stm
5. Start the Microsoft Exchange Information Store service
6. Open Exchange system Manager, go all the way to the Mailbox Store and 
Public folder store. Right-click each one, database tab. Check the box 
"this database can be overwritten by a restore".
7. Right-click and Mount Store.

If the database is in clean shutdwown state, and you rebuild the server 
with the same server and domain name, the store will mount. Of course, 
there are always other problems that may show up. If you run into the 
problem, post back the errors from the application/system log and see the 
next step.

8. Assuming no problem, then close and reopen the Exchange system manager. 
Expand mailbox store, right click Mailbox, and run Clean up agent. 
Mailboxes on your right should be RedX. Right click each one and Reconnect 
to connect back to a user account. If you don't see the user on the list, 
it means the user already has a clean mailbox. You then need to go to AD 
Users and Computer, right click that user, Exchange Tasks and Delete 
mailbox. Back to Exchange System Manager, run Cleanup agent again, and 
reconnect the mailbox back to the user.

To save time, you should consider calling PSS at 1-800-936-4900 and let us 
to walk you through the steps.

Need to disable NDR in your Exchange?

bradley — Sat, 20 Dec 2003 06:00:00 GMT

Disable NDR:
From Exchange System Manager, Global Settings, Internet Message Format.
Double click on your right. Advanced tab. Uncheck Allow
non-delivery reports.