Tag Archives: Exchange 2010

Postel’s Law, Exchange ActiveSync, and iOS 6

Over the last week the Exchange community has learned a bit more about problems with Apple’s Exchange ActiveSync implementation in iOS 6; Microsoft has released a KB article outlining the problem and suggesting some workarounds, and Tony Redmond this morning pointed to a TUAW article that I hadn’t previously seen which asserts that the hijacking problem is a known issue with previous versions of iOS.

Tony’s article is titled “The emerging need for more supervision over ActiveSync implementations.” It’s certainly hard to disagree with that basic premise. Just over 18 months ago, Microsoft launched an Exchange ActiveSync logo certification program with the goal of inducing third parties who sell EAS-compatible devices or software to verify that they properly implement the client side of EAS. A quick check of this page maintained by Microsoft’s legal department shows just over four dozen EAS licensees, but only 3 vendors are listed on the EAS logo page itself. There are several possible explanations, ranging from lack of vendor interest in getting certified to a Microsoft failure to update the contents of the page.

Whatever the reason, I think Tony is right that Microsoft needs to be more proactive in requiring their EAS licensees to perform more robust testing on their clients.

Furthermore, I’m starting to think that the certification and testing program isn’t sufficient in and of itself, which brings me to Postel’s Law.

Some years ago, I worked for a company that made e-mail encryption software. This was during a time when even basic SMTP interoperability between different vendors’ systems was not assured– the Electronic Mail Association had biannual “plugfests” where vendors such as Lotus, Microsoft, and Netscape got together to ensure that their products could exchange SMTP mail properly. Whenever we ran into an interop problem, my boss would cite Postel’s Law:

Be conservative in what you do, be liberal in what you accept from others.

It seems pretty clear that Apple’s iOS EAS implementation has bugs– long-standing ones, if the TUAW article is right– and that Apple has a responsibility to fix them. I am coming to the opinion, though, that the server-side EAS implementation is too lenient about what it accepts. For years Exchange administrators had to suffer through a dance that went something like this:

  1. A new version of Outlook would ship with a bug that would occasionally corrupt calendar or message items in some interesting way.
  2. The corrupted items would cause the client to crash; in more severe cases, they could also crash the store process or cause backups, mailbox exports, etc. to fail.
  3. The Exchange team would release a hotfix to keep that particular flavor of badly formed item from causing such a problem.
  4. The Outlook team would release a hotfix that would keep that version of Outlook from emitting that particular flavor of corruption.
  5. In the next release of Exchange, the team would add business logic to reject items with the specific flaws generated by Outlook.
  6. GOTO 1

Over time, the Exchange business logic got better, as did Outlook’s track record of not creating bad items in the first place. This approach has served Exchange administrators and users pretty well, and it’s clear that the lessons learned from this painful process have been applied in Exchange Web Services. For example, EWS will reject attempts to create calendar items with end dates that come before start dates– something that Outlook used to occasionally do out of sheer perversity.

However, it looks as though, at least in this specific case, EAS doesn’t have business logic in place to catch the modifications that lead to the hijacking behavior. That’s something that Microsoft can fix in three steps.

  • First, they can update the EAS spec so that it clearly defines which fields of each data item are to be considered read-only. This gives implementers a fair shot to understand where they may need to change their clients.
  • Second, they can update Exchange itself so that it rejects client requests that violate the updated spec.
  • Third, they can vigorously “encourage” their major ISV partners to test more aggressively against the updated spec. I have to wonder, for example, how much, if any, testing Apple has done against Exchange 2013…

I’ve been putting the blame on Apple for this problem, and while I don’t think that doing so is unfair or inaccurate, I also believe that the Exchange team can do a better job on the server side of blocking bad client requests, and I hope they’re madly planning how to do so in Exchange 2013 SP1.

Leave a comment

Filed under UC&C

More on bugs in iOS6 Exchange ActiveSync

As I hoped they would (but couldn’t mention in my previous post), Microsoft has weighed in with a KB article on the iOS 6 “hijacked meeting” bug. The article ID is 2768774, and it makes a couple of cogent points: first, that Microsoft is aware of, and is actively investigating, the bug. Second, that “Microsoft cannot mitigate this issue”; they recommend contacting Apple. The interesting part to me was the section on workarounds. Microsoft’s suggestions include:

  • telling users not to make calendar changes using the iOS app
  • recommending that users not update to iOS6 (as if! iOS device users are legendarily quick to update to new versions)
  • blocking iOS 6 devices using Exchange ActiveSync allow/block/quarantine
  • blocking users who have delegates, or who are granted delegate access, from using EAS
  • using POP/IMAP instead of EAS (this made me laugh out loud– really!)

I have been testing Savvy Software’s Agenda app recently and like it quite a bit. However, it, like almost all the other calendar apps of which I’m aware,  it uses the underlying iOS calendar data store and sync mechanism, so I’d expect it to fall victim to the same bug. NitroDesk has ported its Touchdown app to iOS (though its App Store reviews are pretty poor), and Emtrace has the MoxierMail EAS client (which I still need to review.) So pick your poison: none of Microsoft’s suggested workarounds are great, but their hands are tied. It’s pretty clear this is an Apple problem and it will be incumbent on Apple to fix it… which I am sure they will, eventually. 




Filed under UC&C

iOS 6 and Exchange ActiveSync misbehavior

Brace yourself for a surprise: there’s at least one major bug in Apple’s Exchange ActiveSync client in iOS 6.

cue shocked silence…

This is not surprising, of course; EAS is a fairly complex protocol and Apple has displayed a somewhat cavalier attitude towards verifying that their EAS clients behave properly. If you don’t believe me, all you have to do is look at this list of known EAS issues with third-party devices and see how many of them involve iOS.

Anyway, the latest widely reported  issue is that meetings sometimes appear to be hijacked– Alice will send out a meeting invitation to Bob and Carole, but somehow Carole will end up as the meeting organizer, thus gaining the ability to cancel or change meetings.

The hijacking bug isn’t the only one; users have reported a few other iOS 6 EAS issues, including its apparent failure to handle the case where the user’s primary SMTP address is different from the user name (e.g. an SMTP address of paul@robichaux.net coupled with a UPN of paul.robichaux@robichaux.net, for example), but these other issues all have easy workarounds; meeting hijacking is the most pestiferous.

The usual pattern for these bugs is fairly predictable:

  1. Apple (or another EAS licensee) releases an update.
  2. People start complaining in various fora that some EAS-related functionality is broken. However, these reports are only rarely made directly to either Microsoft or the vendor.
  3. A critical mass of reports accumulates and begins to draw attention. This is often accelerated by the opening of support cases with either Microsoft or the ISV.
  4. The source of the problem is identified, a resolution is developed, and everything is fixed.
  5. GOTO 1

Now, stop laughing. That really is what usually happens. Note that Microsoft’s hands are somewhat tied during this process. Until they get feedback from customers that something is broken, they can’t very well investigate it. I imagine that it is very frustrating for the EAS team to see people blaming Exchange for what end up being bugs in the EAS client implementation. But I digress.

Tony points out a few nuances of how the process works, including suggestions for figuring out which devices are actually in use. (Note that one improvement in iOS 6 is that it reports a value for the DeviceOS property returned by Get-ActiveSyncDeviceStatistics; older versions just left that field blank.) Leaving that aside, though, it’s interesting to consider what’s known about the calendar hijacking bug. The best explanation I’ve seen, ironically, comes from the Z-Push development team. (Z-Push, you may recall, is an open-source EAS implementation that has nothing to do whatsoever with Exchange.) However, they are apparently first to market with a public explanation of the problem with iOS 6 that causes meeting hijacking. I won’t repeat it here; it’s worth reading the original. The root of the problem appears to be that iOS 6 emits meetings with zero attendees, and that Exchange accepts these as valid. I’m not sure whether Exchange’s acceptance is a desired behavior or not but I’m pretty sure that the device should never be emitting a zero-attendee meeting. It’s possible that there are cases where this is not true, which is why the Z-Push folks are holding their patch in QA for now instead of pushing it into the main tree of their product.

The tricky issue here, of course, is how to get the problem fixed for those of us who aren’t using Z-Push. Microsoft could conceivably make a change to Exchange’s business logic for calendar items, preventing ill-formed meeting items from being propagated. Apple could likewise fix their client so that it doesn’t send out ill-formed items in the first place. Both sides have an interest in providing a smooth EAS experience for iOS users, but each side has a different set of engineering and delivery constraints that make the process of actually getting the fix out to customers a challenge.

Microsoft hasn’t publicly said much about this bug, other than that it is being investigated. (And Apple, AFAIK, has said absolutely nothing about it, which is regrettably typical.) Your best bet is to keep an eye on KB 2563324 for updates so you’ll know when Microsoft believes they have a solid understanding of the problem and the best way to fix it.

Meanwhile, the Z-Push team claims that turning off the Exchange calendar attendant feature would eliminate the problem, at the cost of some useful functionality. The iOS 6 bug is rare enough in most environments that I’d advise living with it rather than giving up the attendant functionality, but that’s a choice you’ll have to make based on your users and their needs.

I wonder whether Emtrace’s MoxierMail client has this problem? I’ve got an evaluation copy but haven’t been able to evaluate it yet; might be time to move that up a couple of notches on the priority scale….


Filed under UC&C

Some MEC schedule and content updates

Today the Exchange team updated the MECIsBack.com website to share more details of what awaits us in a mere 48 days! The complete schedule is a pretty broad outline, but the session list is quite tantalizing.

Day 1 starts with an opening keynote by Rajesh Jha, but the real goodies start with a technical keynote covering the architecture of what Microsoft is calling “the new Exchange.” (It’s interesting, btw, that SharePoint, Lync, Office 2013, and Windows 8/2012 aren’t calling their products “the new X”. I like the Exchange branding.)  There are a total of 8 additional breakout sessions, all on Exchange 2013, scheduled for the rest of day 1. This is definitely a good news/bad news situation, as these 8 sessions are stuffed into three time slots so you cannot attend them all. That means that we’ll all have to choose which sessions seem most interesting. The arrangement reminds me a bit of past MVP summits when we had to make choices such as “would I rather go to the ‘what’s new in PowerShell’ or ‘storage architecture changes’ session?” This is rather jarring given how lame the last few years’ worth of TechEd content has been for Exchange, but it’s a good problem to have. Fortunately the MEC folks will have the Exchange 2013 day-1 sessions recorded for later viewing. (Personally, I think I will probably hit the high availability, security, and “Apps for Outlook and OWA” sessions.)

Days 2 and 3 are all chalk talks. Microsoft is calling them “classroom sessions” but I picture something more informal than the typical lecture sessions, with lots of back-and-forth Q&A. The preview session content list includes a bunch of sessions both on Exchange 2013 and Exchange 2010. There are some interesting tidbits hidden in the session list: “What’s New In Support Programs with Exchange,” for instance, sounds intriguing given that Microsoft has not yet publicly said anything about upcoming support changes. The sessions on site mailboxes, modern public folders, and what’s new in anti-malware (you did know Exchange 2013 includes malware filtering now, right?) look worthwhile as well.

Microsoft hasn’t yet announced exactly which speakers will be presenting the new Exchange 2013 content. However, if you look at the speaker list you can make some informed guesses. I’d expect all of the Exchange 2013 sessions to be covered by Microsoft speakers (I love it that the Microsoft product group folks are listed under the heading of “Exchange Team Personalities”– I can attest that many of the Exchange folks are, in fact, lively personalities), and if you know who does what on the product team you can probably match session titles to personalities pretty easily.

I’m presenting two sessions: E14.302, “Developing Mobile Applications with Exchange Web Services,” and E14.303, “10 Things You Didn’t Know About Exchange Unified Messaging.” Other presenters include unindicted co-conspirator Tony Redmond, fellow MCM instructor Brian Reid, the formidable Glen Scales, ex-3Sharpie Devin Ganger, and a host of others whose names you’ll probably recognize.

Interestingly, Microsoft is still looking for suggestions for sessions– drop mecideas@microsoft.com a line if there are specific things you want to talk about that aren’t covered. The exhibitors list is now up to date as well, with most of the usual suspects represented– Quest, Binary Tree, Sherpa, and so on.

One open question: there are two evening events, plus an option post-event activity… I wonder what the MEC planners have up their sleeves for us? I can’t wait to find out. See you there!

Leave a comment

Filed under UC&C

Man-in-the-middle attacks against Exchange ActiveSync

I love the BlackHat security conference, although it’s been a long-distance relationship, as I’ve never been. The constant flow of innovative attacks (and defenses!) is fascinating, but relatively few of the attacks focus on things that I know enough about to have a really informed opinion. At this year’s BlackHat, though, security researcher Peter Hannay presented a paper on a potential vulnerability in Exchange ActiveSync that can result in malicious remote wipe operations. (Hannay’s paper is here, and the accompanying presentation is here.)

In a nutshell, Hannay’s attack depends on the ability of an attacker to impersonate a legitimate Exchange server, then send the device a remote wipe command, which the device will then obey. The attack depends on the behavior of the EAS protocol provisioning mechanism, as described in MS-ASPROV.

Before discussing this in more detail, it’s important to point out three things. First, this attack doesn’t provide a way to retrieve or modify data on the device (apart from erasing it, which of course counts as “modifying” it in the strictest sense.) Second, the attack depends on use of a self-signed certificate. Self-signed certificates are installed and used by Exchange 2007, 2010, and 2013 by default, but Microsoft doesn’t recommend their use for mobile device sync (see the 2nd paragraph here); contrary to Hannay’s claim in the paper, my experience has been that relatively few Exchange sites depend on self-signed certs.

The third thing I want to highlight: this is an interesting result and I’m sure that the EAS team is studying it closely to ensure that the future attacks Hannay contemplates, like stealing data off the device, are rendered impossible. There’s no current cause for worry.

The basis of this attack is that EAS provides a policy update mechanism that allows the server to push an updated security policy to the device when the policy changes. There are 3 cases when the EAS Provision command can be issued by the server:

  • when the client contacts the server for the first time. In this case, the client should pull the policy and apply it. (I vaguely remember that iOS devices prompt the user to accept the policy, but Windows Phone devices don’t.)
  • when the policy changes on the server, in which case the server returns a response indicating that the client needs to issue another Provision command to get the update.
  • when the server tells the device to perform a remote wipe.

The client sends a policy key with each command it sends to the server, so the server always knows what version of the policy the device has; that’s how it knows when to send back the response indicating that the device should reprovision.

If the client doesn’t have a policy, or if the policy has changed on the server, the client policy key won’t match the current server policy key, so the server sends back a response indicating that the client must reprovision before the server will talk to it.

There seems to be a flaw in Hannay’s paper, though.

The mechanism he describes in the paper is that used by EAS 12.0 and 12.1, as shipped in Exchange 2007. In that version of EAS, the server returns a custom HTTP error, 449, to tell the device to get a new policy. A man-in-the-middle attack in this configuration is simple: set up a rogue server that pretends to be the victim’s Exchange server, using a self-signed certificate, then when any EAS device attempts to connect, send back HTTP 449. The client will then request reprovisioning, at which time the MITM device sends back a remote wipe command.

Newer versions of Exchange return an error code in the EAS message itself; the device, upon seeing this code, will attempt to reprovision. (The list of possible error codes is in the section “When should a client provision?” in this excellent MSDN article). I think this behavior would be harder to spoof, since the error code is returned as part of an existing EAS conversation.

In addition, there’s the whole question of version negotiation. I haven’t tested it, but I assume that most EAS devices are happy to use EAS 12.1. I don’t know of any clients that allow you to specify that you only want to use a particular version of EAS. It’s also not clear to me what would happen if you send a device using EAS 14.x (and thus expecting to see the policy status element) the HTTP 449 error.

Having said all that, this is still a pretty interesting result. It points to the need for better certificate-management behavior on the devices, since Hannay points out that Android and iOS devices behaved poorly in his tests. Windows Phone seems to do a better job of handling unexpected certificate changes, although it’s also the hardest of the 3 platforms to deal with from a perspective of installing and managing legitimate certificates.

More broadly, Hannay’s result points out a fundamental flaw in the way all of these devices interact with EAS, one that I’ve mentioned before: the granularity of data storage on these devices is poor. A remote-wipe request from a single Exchange account on the device arguably shouldn’t wipe out data that didn’t come from that server. The current state of client implementations is that they erase the entire device– apps, data, and all– upon receiving a remote wipe command. This is probably what you want if your device is lost or stolen (i.e. you don’t want the thief to be able to access your personal or company data), but when you leave a company you probably don’t want them wiping your entire device. This is an area where I hope for, and expect, improvement on the part of EAS client implementers.

1 Comment

Filed under Security, UC&C

Licensing change for Exchange multi-mailbox search

Microsoft today announced that you no longer need an enterprise client access license (ECAL) to use the multi-mailbox search feature. This is a welcome change, of course, since it means that it is now OK to run multi-mailbox searches against mailboxes that are licensed with a standard CAL. In essence, Microsoft is giving standard CAL holders something for free that formerly cost money. ECAL holders, of course, aren’t getting anything extra out of the deal, but I’d argue that the other ECAL features (including legal hold and the Personal Archive feature) probably make up for that.

The interesting question to me is: why this change at all, and why now? It’s common for Microsoft to adjust licensing terms with new releases of Exchange, so my guess is that we’ll see some differences in how the data loss prevention (DLP) and information management features of Exchange 2013 are licensed and which specific mix of CALs you need to use them.

Stay tuned…

1 Comment

Filed under UC&C

Stalking the wily ADAccess event 2112

Timing is everything.

A week ago, I got a late-night phone call about a problem with an Exchange server that seemed to be related to an expired certificate; the admin had replaced the expired cert on one member of a two-node DAG, but not the other. He noticed the errors in the event log when troubleshooting a seemingly unrelated problem, installed the new cert, and then boom! Bad stuff started happening.  Problem was, the reported problem was that inbound SMTP from a hosted filtering service that doesn’t use TLS wasn’t flowing, so it didn’t seem likely that certificate expiration would be involved. By the time he called me, he had installed the new certificate and rebooted the affected server, and all seemed to be well.

Fast forward to Sunday night. I’d planned to patch these same servers to get them on to Exchange 2010 SP2 UR3, in part because I’d noticed a worrisome number of events generated by the MSExchange ADAccess service, chiefly event ID 2112:

Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=8356). The Exchange computer HQ-EX02.blahblah does not have Audit Security Privilege on the domain controller HQ-DC01.blahblah. This domain controller will not be used by Exchange Active Directory Provider.

This was immediately followed by MSExchange ADAccess event ID 2102 with the rather ominous message that

Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=8356). All Domain Controller Servers in use are not responding:

However, the event ID 2080 logged by ADAccess indicated that all but 1 of the GCs were up and providing necessary services, including indicating that their SACL allowed Exchange the necessary access. I couldn’t puzzle it out in the time I had allotted, so I decided to take a backup (see rule #3) and  wait to tackle the patching until I could be physically present. That turned out to be a very, very good idea.

Last night, I sat down to patch the affected systems. I began with the passive DAG node, updating it to SP2 and then installing UR3. I half-thought that this process might resolve the cause of the errors (see rule #2), but after a reboot I noticed they were still being logged. I suspected that the reported 2102 errors might be bogus, since I knew all of the involved GCs were running and available. As I started to dig around, I learned that this error often appears when there’s a problem with permissions; to be more specific, this SCOM article asserts that the problem is that the Exchange server(s) don’t have the SeSecurityPrivilege user right on the domain controllers. However, I was still a little skeptical. I checked the default DC GPO and, sure enough, the permissions were present, so I moved on to do some further investigation.

Another possible cause is that the Exchange servers’ computer accounts aren’t in the Exchange Servers group, or that permissions on that group were jacked up somehow, but they appeared to be fine so I discounted that as a likely cause.

Along the way I noticed that the FBA service wouldn’t start, but its error message was meaningless– all I got from the service control manager was a service-specifc error code that resisted my best attempts to Bing it. Without that service, of course, you can’t use OWA with FBA mode, which would be a problem so I made a mental note to dig into that later.

A little more searching turned up this article, which is dangerously wrong: it suggests adding the Exchange computer accounts to the Domain Admins security group. Please, please, don’t do this; not only does it not fix the problem, it can cause all sorts of other tomfoolery that you don’t want to have to deal with.

Still more digging revealed two common problems that were present on this server: the active NIC wasn’t first in the binding order and IPv6 was disabled on the two enabled NICs. Now, you and I both know that IPv6 isn’t required to run Exchange.. but Microsoft does not support disabling or removing IPv6 on Windows servers. And you know what they say about what “unsupported” means! So, I enabled IPv6 on the two adapters and got the binding order sorted out, then bounced the AD topology service and…

… voila! Everything seemed to be working normally, so I ran some tests to verify that *over was working as it should, then started patching the DAG primary– only to have setup fail partway through. Upon reboot, w3svc was caught in an endless loop of trying to load some of the in-proc OWA DLLs; it kept trying endlessly until I power-cycled the server. The problem with this is that the Active Manager service was starting, so the current active node would try to sync with it before mounting its copy of the DAG databases, but it never got an answer! Net result, no mounted databases on either server, and an unhappy expression on my face as the clock ticked past 11pm.

I put the primary member server in safe mode, then set the Exchange and w3svc services to manual star and rebooted it. Rather than spend a lot of time trying to pin down exactly what happened, I ran setup in recovery mode; it installed the binaries, after which the services restarted normally. I did a switchover back to the original primary node, verified mail flow, and went home. Life was good.

Until, that is, this morning, when I got an e-mail: “OWA is down.” I checked the servers and, sure enough, the errors were back and the FBA service was again refusing to start. After some creative swearing, I once again started digging around in the guts of the server. I couldn’t shake the feeling that this was a legitimate permissions problem of some kind.

At that point, I found this article, which pointed out something critical about GPOs: you have to check the effective policy, not just the one defined in the default policy. Sure enough, when I used RSoP to check the effective policy on the DCs, the Exchange servers did not have SeSecurityPrivilege on the DCs because there was a separate GPO to control audit logging permissions, and it had recently been changed to remove the Exchange Servers group. That was easy to fix: I added the Exchange Servers group to the GPO, ran gpudate, rebooted the passive node, and found that the services all started normally and ran without error. A quick switchover let me restart the topology service on the primary DAG member, after which it too ran without errors. End result: problem solved.

It’s still not entirely clear to me why that particular service needs to have the SeSecurityPrivilege right assigned. I’m trying to find that out and will update this post once I do. In the meantime, if you have similar symptoms, check to verify that the effective policy is correct.


Filed under UC&C

What "supported" really means

If I had a nickel for every time I had had a discussion like the below…

<Customer> wants to <do something>. I don’t think it’s a good idea and tried to explain that to them. They want to do it anyway. Is it supported?

The particular discussion that triggered this post was a conversation among MCMs concerning a customer who wanted to know if they could configure an Exchange 2010 server so that it was dual-homed, with one NIC on the LAN and another in their DMZ. There are a number of good reasons not to do this, most related to one of two things: the inability to force Windows and/or Exchange to use only one of the installed NICs for certain operations, or the lack of knowledge about how to configure everything properly in such a configuration. For example, you’d have to be careful to get static routes right so that you only passed the traffic you wanted on each interface. You’d also have to be careful about which AD sites your server appeared to be a member of.

The big issue for me: that configuration would add complexity. Any time you add complexity, you should be able to clearly articulate what you’re gaining in exchange. Performance, scalability, flexibility, security, cost savings.. there has to be some reason to make it worth complicating things. This is a pretty fundamental principle of designing anything technical, from airplanes to washing machines to computer networks, and you violate it at your peril.

In this case, the gain is that the customer wouldn’t need to use TMG or a similar solution. That seems like an awfully small gain for the added complexity burden and the supportability issues it raises.

You might be wondering why I’d bring up supportability in this context. The cherry on the sundae was this comment from the fellow who started the thread: “It’s not written that you can’t do it, so they assume that means you can.” This is a dangerous attitude in many contexts, but especially so here.

I’ve said it before (and so has practically everyone who has ever written about Exchange), but it bears repeating:

Just because something is not explicitly unsupported, that doesn’t mean it is supported.

Microsoft doesn’t– indeed, can’t— test every possible configuration of Exchange. Or Windows. Or any of their other products (well, maybe except for closed consumer systems like Windows Phone and Xbox 360). So there’s a simple process to follow when considering whether something meets your requirements for supportability:

  1. Does Microsoft explicitly say that what you want to do is, or is not, supported?
  2. If they don’t say one way or the other, are you comfortable that you can adequately test the proposed change in your environment to make sure that it only has the desired effects?

Point 1 is pretty straightforward. If Microsoft says something’s explicitly supported, you’re good to go. If they explicitly say something is unsupported, you’re still good, provided you don’t do it.

Brief digression: when Microsoft says something’s unsupported, it can mean one of three specific things:

  • We tested it. It doesn’t work. Don’t do it. (Example: a long list of things involving Lync device provisioning.)
  • We tested it. It works. It’s a bad idea for some other unrelated reason. Don’t do it. (Example: going backupless with a 2-copy DAG.)
  • We didn’t test it. We don’t know if it works. You could probably figure out some way to make it work.  If it doesn’t work, on your own head be it. (Example: the prior stance on virtualization of Exchange roles.)

OK, where was I? Oh yeah: if Microsoft doesn’t make an explicit statement one way or another, that is not an unconditional green light for you to do whatever you want. Instead, it’s an invitation for you to think carefully about what you’ll gain from the proposed configuration. If what you want to do is common, then there will probably be a support statement for it already; the fact that there isn’t should give you pause right there. If you believe the gain is worth the potential risk that comes from an increase in complexity, and you can demonstrate through testing (not just a SWAG) that things will work, only then should you consider proceeding.

(n.b. permission is hereby granted for all you Exchange folks out there to copy this and send it to your customers next time they ask you for something dangerous, ignorant, unsupportable, or otherwise undesirable.)


Filed under Musings, UC&C

How Autodiscover works in Outlook 2011

Fellow Exchange MVP Rajith Enchiparambil, proprietor of the excellent How Exchange Works blog, asked an interesting question the other day: how does Autodiscover work in Outlook 2011? Is it different from the way Autodiscover works in Outlook for Windows?It turns out that the answer is (as you might have predicted) “it depends.” To answer that question in depth, we have to dig into the guts of Autodiscover (or AutoD, as its friends call it).

The first thing to know is that there are two parts to AutoD. One is the service that runs on Exchange 2007 and later. This service is implemented as a virtual directory named “Autodiscover” on the CAS role. When you install the CAS role, the vdir is automatically created and provisioned for you. In addition to the vdir, an Active Directory service connection point (SCP) object is created. (For probably more detail on SCPs than you’d want, see this article.)

See, in Windows Outlook, there are two primary ways that AutoD can work: domain-joined Windows machine can perform an LDAP lookup to find an AD SCP, or any machine can try to hit a predefined series of URLs. Why are there two methods? Because this design allows a computer, or device, to find the correct Exchange CAS whether it’s domain-joined or not, and whether or not it’s on the internal corporate network.

(See what I did there? I said device, because mobile devices can use AutoD also. Currently, iOS and Windows Phone 7.x devices use AutoD, as do some Exchange ActiveSync clients on some Android devices. For our purposes, we’ll treat mobile devices just like Macs insomuch as they use similar web-based queries for the AutoD vdir.)

So let’s ignore the SCP lookup process. How does Mac Outlook 2011 use AutoDiscover?

First it tries to connect to the standard AutoD URL, which is made up of the primary Exchange SMTP domain plus /Autodiscover/Autodiscover.xml. For example, https://robichaux.net/Autodiscover/Autodiscover.xml would be the first URL Outlook would try for an account in the robichaux.net domain. If that works, great. If not, it will then try tacking “autodiscover” onto the FQDN and keeping the same relative path.

If neither of those standard URL requests, both of which are made using HTTPS, bear fruit, the next attempt will be to do an HTTP request for the second URL. This request will be redirected if HTTP-to-HTTPS redirection is in use, which is what we want– if a redirection occurs, Outlook will catch the HTTP 302 response and make an AutoD request against the redirected URL.

If that check fails, the next step is to perform a DNS SRV lookup to try to find the FQDN of an Exchange CAS. If the SRV query returns a target machine, Outlook will tack on /autodiscover/autodiscover/xml to it and perform an AutoD query against the result.

Once Outlook or a mobile device gets back an Autodiscover manifest, of course, what it does with the result will vary according to its capabilities. For example, Outlook 2011 and mobile Exchange ActiveSync clients don’t (currently) use the returned URL for the target mailbox’s Exchange unified messaging (UM) server.

This process is generally pretty robust unless you’ve misconfigured the Autodiscover or service URLs on the CAS. It turns out that there’s a separate Exchange Web Services (EWS) external URL property on the CAS, and if you fail to set that properly– say, if some of your users snuck some Macs or iPads or something onto your network– then AutoD will return the EWS URL that you set, which will be wrong, so Mac Outlook won’t connect properly. The Test-* cmdlets are very useful in tracking this kind of problem down; Exchange MVP Tim Harrington has written a good primer on their use.


Filed under UC&C

2011 Exchange Maestro wrap-up

Greetings from high over Nebraska, where I’m aboard a Delta flight to San Francisco for a well-deserved day of rest at home (and, hopefully, a visit to In-N-Out) before heading to Vegas for Exchange Connections and then back to Pensacola.

My first visit to Connecticut was, I’d say, quite the success. We had a good-sized group of attendees, and they asked excellent and focused questions throughout. As a presenter it’s always rewarding when the audience asks questions that indicate not only that they’re listening but that they’re thinking and this group did so particularly well. That kind of back-and-forth increases the value of the workshop for everyone, and we had a lot of it.

For a first, Tony and I hit all of our timing marks until the third day! (As you might expect, I ran long on the UM content; my natural enthusiasm got the best of me.) This left the attendees more time than usual for labs, which they used to their full advantage. We didn’t have any major equipment or logistical problems; the sponsor presentations from Hewlett-Packard and BinaryTree were quite well done.

In a side note, I’m glad to report that Tony now knows what “homeboy” means in American English after discussing my PC price advantage post. He and Brian both disagreed strenuously with my assessment of the build quality of H-P’s EliteBook line, and Tony further questioned why I spec’d a 17″ EliteBook given its inconvenient size for truly mobile use– I did so because I wanted the closest match for CPU speed. In any event my admission that there still seems to be a price premium at the higher end of the configuration scale stands. Having said that, I’ve no plans to switch away from my MacBook Pro.

As of right now, we don’t currently have plans to do any Maestro events in 2012. I’m certainly open to the possibility, but we’ve had a hard time finding the optimum way to market these events and get the word out. One possibility is that we’ll work more closely with consulting and systems integration firms to go directly to their customers, and we have a few other potential tricks up our sleeves. Stay tuned for more details!

1 Comment

Filed under General Tech Stuff, UC&C

A tricky UM routing problem

A colleague who earned his Exchange 2010 last year recently contacted me with a bit of an odd UM question. Here’s the basic scenario: Steve Secretary answers the phone for Betty Bosswoman. This was set up in Cisco Call Manager such that Steve’s phone has two extensions: 1000 (Betty’s extension) and 1001 (Steve’s extension). When someone calls Betty, both phones ring, and Steve can answer it as necessary. Sometimes Steve would answer the phone and the caller would ask for Betty’s voicemail; Steve could oblige by doing a blind transfer to Betty’s extension and the call would be routed to the voicemail system.

Things were all fine with this configuration until the advent of Exchange UM. Call answering and delivery worked fine until Steve tried to transfer a call to Betty’s voicemail, now hosted on Exchange UM. The caller whose call was transferred was getting Steve’s voicemail.. not at all the right result.

This was happening because when the call was transferred, CUCM was emitting a diversion header that indicated that the call was being sent to Steve. Why? Because Steve had Betty’s extension assigned as a secondary extension! Remember, Exchange UM uses the SIP diversion information to determine where the call’s from, who it’s to, and why Exchange is getting it. If any of these three data are incorrect or missing, Exchange will fall back to assuming that the call is to the voicemail pilot number, and you’ll hear “Welcome to Microsoft Exchange. Please enter your mailbox extension” (or whatever; the exact phrase escapes me) instead of the correct greeting.

My interlocutor wanted to know if there was a way to change this behavior on the Exchange side. Sadly there isn’t– whatever diversion header information is provided, Exchange will consume. There’s no way to rewrite, edit, or otherwise control the diversion data on the Exchange side, nor can you create rules or filters that modify the actions that Exchange takes. That’s what the call coverage map on the PBX is for, see?

Anyway, after a little head scratching, some consultation with a CUCM engineer, and the sacrifice of a chicken, it was discovered that CUCM had a way to modify the extension information sent as part of a blind transfer. The change was made so that transferring a call from Steve’s phone emitted Betty’s extension instead, and the problem was solved. Unfortunately I don’t know exactly what change was made, or I’d document it here. Such are the perils of not being a CUCM guy…


Filed under UC&C

E-mail and defamation

So LegalZoom (which I recommend if you need a will or other basic legal document) sent me an interesting newsletter the other day. Headlined “Can You Be Sued for Sending an Email?”, it covers the case of Sandals Resorts vs Google. Basically, Sandals filed suit to force Google to disclose information about a Gmail user who wrote an e-mail they didn’t like. Google won, Sandals lost, and LegalZoom’s asking a valid question.

(Disclaimer: as though you didn’t know this, I’m not a lawyer, and this is not legal advice.)

The first facile answer that comes to mind is “of course you can be sued for an e-mail you write.” Under the American system of jurisprudence, anyone can sue anyone for anything. I’ve been harassed and threatened with lawsuits by a crazy person who objected to something I wrote on my blog about his business; so could you be. That’s part of the price of admission to a nation where you get the benefits of a stable, well-established judicial system based on adversarial law. It doesn’t mean that such a suit would be valid, just that the potential exists for it to be filed.

A little more nuanced answer requires us to dig into the facts of this particular case: Sandals didn’t sue the person who wrote the e-mail, they asked Google to find out who that person was. Google declined, and the fight was on. Anonymity is often an effective defense against bearing the consequences of what you say in e-mail… but don’t count on it. Some e-mail providers are more, shall we say, flexible than others when asked to provide information about who created an e-mail; they may do so based on a subpoena or merely upon a written request. If you use an e-mail service that you don’t run yourself, it would be worth your time to find out what kind of privacy and disclosure policies your provider follows. In this case, Google did the right thing and resisted the discovery request.

A still more nuanced answer: in this particular case, Sandals claimed that the e-mail in question was libelous, defamed their business, and caused them financial injury. The judge ruled against them on several points. The most interesting ones are these: first, because the plaintiff didn’t prove any actual financial injury, they couldn’t claim that the alleged defamation had actually harmed them. Second, the judge found that the e-mail was clearly an expression of opinion, and would be very likely perceived as such by the recipients. Defamation and libel require that the offender present their claims as fact. It’s OK for me to say “It’s my opinion that Oracle makes crappy software”; couched as an opinion, my statement cannot be construed as libelous or defamatory. If I instead claimed that Larry Ellison eats small children, and presented that claim as fact, that might be defamatory (unless I could prove that it was true, not that I’m planning on trying.)

The New York Law Journal review of the case is worth reading in depth if this sort of thing interests you, in part because it explains what you must do to write e-mails that don’t meet the legal standard for defamation (hint: overblown rhetorical language helps). It’s also fairly entertaining in its own right.

Leave a comment

Filed under UC&C

Testing speech grammars with Exchange Unified Messaging

One of the things i teach in the MCM UM curriculum is the fact that Exchange UM has a phonetic name attribute that you can use to adjust how the system pronounces unusual names like “Robichaux” or “Szcezpanski.” MVP (and now Exchange MCM!) Jeff Guillet shared an article with me during the MCM R10 UM class that explains how to preview the pronunciation you’re going to get from a given phonetic value– I’d always done it with trial and error, but Jeff’s method is better. See Jeff’s article for background on how the phonetic system works, and learn how to preview pronunciation as a bonus.

Leave a comment

Filed under UC&C

Exchange MCM R10 wrapup and a reminder about Exchange Maestro

Fellow Exchange MVP Jeff Guillet just finished rotation 10 (R10) of the Microsoft Certified Master program for Exchange. His writeup gives an excellent overview of what the program’s really like: intense and focused learning, now 7 days per week. It is very hard work, but the quality of the work that MCM candidates do with the skills and knowledge they get at MCM speaks for itself.

But suppose that you can’t spare the time or money to attend an MCM rotation? Good news: Tony Redmond and I have one more Exchange Maestro class coming up at the end of October in Greenwich, CT. For a limited time, using the registration code “FAN” will net you $250 off registration. (When I say “limited”, what I really mean is that I don’t know when Penton will stop honoring the code so I encourage you not to dawdle; the class is nearly full.)

But further suppose that you aren’t able to attend this Maestro event– after all, Connecticut in the fall isn’t for everyone. Good news: don’t forget that Tony and I are co-presenting a one-day workshop on planning and executing Exchange 2010 migrations as a pre-conference session at the Fall Exchange Connections show. In one action-packed day, we’ll cover the migration-related highlights from the Maestro curriculum, plus Tony will tell jokes. Trust me when I say that his jokes are not to be missed. Plus, it’s Halloween that day, so if I can persuade Tony to agree we might have a costume contest for attendees. I mean, who wouldn’t want to dress up in costume for Halloween in Las Vegas? That’s certainly on my bucket list. Feel free to leave costume suggestions for me in the comments section of this post.

Leave a comment

Filed under UC&C

Advice to Exchange ActiveSync developers

Now the folks at Apple, Google, and other ISVs who develop Exchange ActiveSync clients no longer have excuses for bugs and misfeatures in their clients. Why? Because Katarzyna Puchala of Microsoft (already one of my favorite Microsofties thanks to her work as part of the Exchange unified messaging team) has posted three very detailed articles on how clients should behave when synchronizing with Exchange servers:

That means, third parties, that there are no longer any credible excuses for why your clients do things like randomly delete meeting requests, or fail to work with EAS autodiscover. Sadly these articles come after the release of OS X Lion, and past the point at which EAS bugs are likely to meet the release bar for iOS 5… but I can always hope that the first service release for each of those operating systems will include fixes to make their EAS implementations act right.

Leave a comment

Filed under UC&C