Exchange Queue & A: Automate and Consolidate
There are many ways to work around automation, mailbox sharing and consolidation issues in Exchange.
Henrik Walther
With guest contributor Georg Hinterhofer
Site Resiliency in Send Connectors
Q. We’re in the process of deploying Exchange 2010 across multiple sites and setting up for redundancy. When planning for outbound mail delivery via smart hosts, we want to achieve automatic redundancy in case the primary site goes down. We’d like to keep the traffic in the primary site when all is well. How can we achieve this?
A. You can easily add multiple smart hosts in a send connector and Exchange will just round-robin through them. However, this only solves one requirement: redundancy across sites. Traffic will still be evenly distributed even when all the sites are up, thereby burning unnecessary bandwidth between sites.
In this case, the send connector is configured with both primary and secondary mail gateways listed as smart hosts. Exchange will use those in an alternating order to deliver outbound mail.
To solve this, you’ll need to apply a nifty trick taught at Microsoft Certified Master training. It’s based on the little-known fact that the smart host box in Exchange (2003, 2007 and 2010 versions) can’t take only the A records or resolved IP addresses, but must also take Mail Exchanger (MX) records. You can, however, assign priority to the MX records.
First of all, ensure you have DNS A records for your mail gateways in place. Next, come up with a random name for your soon-to-be-created MX record in DNS. In this example, I chose allsmarthosts.forest1.local. Create the required MX records in DNS.
As with plain MX-based routing, Exchange will use the MX record with the higher priority, as long as it’s available. Now the only thing left to do is to reconfigure the Exchange Send Connector to read allsmarthosts.forest1.local as the only smart host.
By doing so, Exchange will use primary.forest1.local for outbound mail, as long as it’s available. Once it goes down or becomes unreachable, Exchange will start using secondary.forest1.local as the smart host. That’s what a little DNS trickery can do for you.
Sharing Between Organizations
Q. We recently acquired a company that’s also running Exchange 2010. While the plan is to consolidate both environments, we need to immediately establish calendar (not only Free/Busy) sharing across both organizations. There seems to be little information out there. Can you share some detail on how 1:1 calendar sharing works and what we need to configure for this?
A. This feature was developed for Office 365 to facilitate on-premises coexistence. You can use it for this scenario as well. Both organizations need to be running Exchange 2010. The clients can either be Outlook Web Access 2010 (OWA) or Outlook 2010.
In this case, the client sharing the calendar can specify how much information (only Free/Busy, Free/Busy plus location, Free/Busy with full detail) to share. So how does it work? Technically, your own Mailbox server will create a copy or cache of the shared calendar and show it to you in Outlook or OWA. This is one of the major stumbling blocks. Your Mailbox servers must be able to reach the Internet, as they’re the ones querying for the shared calendar items.
When you look at the shared calendar in MFCMAPI, it looks very much like one of your own. The exception is that it’s marked as read only. You can see all the items from the shared calendar, as they’re really stored in your own mailbox.
To set this up, you’ll need to configure both organizations to federate with the Microsoft Federation Gateway (MFG). You’ll also need to ensure that if one organization is still running the RTM release of Exchange, you’ll need to update it to at least the first service pack so you’ll hit the same instance of the MFG. You don’t need organizational relationships in that case. (You’d need those for Free/Busy sharing, but you’ll want to get calendar sharing in this case.)
To federate your organization with the MFG, just follow the steps outlined here. You’ll need to publish additional TXT records in DNS to prove domain ownership. Do this for both sites you want to federate and add the appropriate domains. Furthermore, you’ll need to set the sharing policies on both sides to allow for calendar sharing with details.
Notice the default policy already lets your users share calendar Free/Busy info with the whole wide world (indicated by the * domain). You want to have full calendar sharing with your partner, so you need to set the sharing dial correctly and add the domains of the organization that you want to be able to share with. Again, you need to do this at both sites.
Sharing policies effectively let you control which users can share their calendars and with whom. This sharing isn’t limited to calendar items. You can share your contacts as well.
First share the calendar. The recipient can then choose to add the shared calendar. Your calendar will soon appear with the shared items.
If you need to troubleshoot this, a good place to start is to look at the actual URL. This is stored in the recipient’s mailbox. You can retrieve it with MFCMAPI. Make sure the URL is reachable from your local Mailbox servers.
Cmdlet Extension Agents
Q. For every new mailbox we create, we want to disable ActiveSync per default. Access should only be available on request. However, when creating a new mailbox with the New-Mailbox cmdlet, we don’t have the option to disable ActiveSync at creation time. We need to run a Set-CASMailbox –ActiveSyncEnabled:$false manually after creation. People sometimes forget this step, and therefore leave ActiveSync access enabled for people that shouldn’t have access. Do you know of any way to change these defaults globally, or is there some other easy way around it?
A. This question comes up quite often. Unfortunately, the short answer is no. There’s no way to change those defaults (such as Web Access enabled by default, ActiveSync enabled by default, Litigation hold disabled and so on). Exchange will always configure those to its hardcoded likings.
Fortunately, there is a way to work around this limitation—with cmdlet extension agents. What a cmdlet extension agent (also sometimes referred to as a scripting agent) does is listen to any Exchange command being fired. If programmed to do so, it will run any given command afterward or change data in the actual cmdlet being fired.
Here’s an example that suits your question:
New-Mailbox -Name "Georg Hinterhofer" -Database DB1 -UserPrincipalName hiho22@hihosoft.local –Password $p.password
This creates a user with all default settings in place. The cmdlet extension agent detects that the New-Mailbox cmdlet has run, and automatically spins up a second cmdlet (one that’s not visible to you). It runs Set-CASMailbox –identity hiho22 –ActiveSyncEnabled:$false, configuring all settings to your needs.
So how do we get the agent up and running? First of all, identify which action you want to set as the trigger, and what action you want to run when the trigger fires. In this case, it’s easy. Every time someone runs the New-Mailbox cmdlet, you want to fire up the Set-CASMailbox cmdlet to disable ActiveSync.
Now you can go and do the actual coding. Look for a file named scriptingagentconfig.xml.sample in %ExchangeInstallPath%\bin\CmdletExtensionAgents and copy it. Rename the copy to scriptingagentconfig.xml and open it up with your favorite editor. For this example, modify the file contents to look like this:
<?xml version="1.0" encoding="utf-8" ?> <Configuration version="1.0"> <Feature Name="DisableEASonNewlyCreatedMailboxes" Cmdlets="new-mailbox"> <ApiCall Name="OnComplete"> if ($succeeded) { $dc = (Get-ADServerSettings).DefaultPreferredDomaincontrollers $user = $provisioninghandler.UserSpecifiedParameters["UserPrincipalName"] set-casmailbox $user -ActiveSyncEnabled:$false -DomainController $dc.item(0) } </ApiCall> </Feature> </Configuration>
Save the modified file. If you have more than one Exchange server, you also need to copy the modified copy of the file to every one of those servers. Also note how Get-ADServerSettings determines the preferred domain controller to avoid any errors related to Active Directory replication latency. You can remove this option if you only have one DC in your environment.
Finally, you’ll need to enable the Scripting Agent. This is an organization-wide setting, so you only need to run this once, not once for every server:
Enable-CmdletExtensionAgent "Scripting Agent"
Verify the outcome and you’re done. Now, run everyone’s favorite New-Mailbox cmdlet and watch as ActiveSync is automatically disabled.
.jpg "Henrik Walther")
.jpg "Georg Hinterhofer")
Henrik Walther is a Microsoft Certified Master: Exchange 2007 and Exchange MVP with more than 16 years of experience in the IT business. He works as a technology architect for a Microsoft gold partner in Denmark, and as a technical writer for Biblioso Corp. (a U.S.-based company that specializes in managed documentation and localization services). He’s also a contracted vendor working on various product teams (including the Exchange and Lync teams) at Microsoft.
Georg Hinterhofer is a Microsoft Certified Master: Exchange 2010. He works as a senior premier field engineer, focusing on solely on Microsoft Exchange. He is based in Austria, near Vienna.