IOS 7.0: To Block or Not to Block? (updated)

iPhone iOSWith the meeting and log flooding issues caused by certain IOS 6.x versions still fresh in memory, one may prefer to adopt a more conservative strategy when it comes to new IOS releases interacting with your Exchange infrastructure – or any mobile OS for that matter.

After Apple released IOS 7.0 this week, some shops consider blocking or quarantining this version until it’s been approved after proper testing and monitor online communities for potential issues during a small waiting period.

In an earlier article, I mentioned how to accomplish (temporarily) blocking IOS 6.x on Exchange 2010 or TMG; here’s how to achieve this for IOS 7.0 on current platforms:

To distinguished IOS 7.0 from earlier versions, you need to check the DeviceOS field as returned by Get-ActiveSyncDevice (Exchange 2010) or Get-MobileDevice (Exchange 2013). For example, here’s how to return current partnered EAS devices:

#Exchange 2010:
Get-ActiveSyncDevice | Where {$_.DeviceOS -like"IOS 7.0*"}

#Exchange 2013:
Get-MobileDevice | Where {$_.DeviceOS -like "IOS 7.0*"}

To block or quarantine IOS 7.0 devices you can utilize Exchange’s Allow/Block/Quarantine (ABQ) mechanism using the New-ActiveSyncDeviceAccessRule cmdlet in conjunction with the DeviceOS, DeviceModel or UserAgent string. When using DeviceOS, it requires specifying the full device OS string, which can vary per device or IOS.

For example, when the DeviceOS is iOS 7.0 11A465 (meaning build 11A465) or 7.0.1 11A470a, the cmdlet for setting up the quarantine rule would be (for blocking replace Quarantine with Block):

New-ActiveSyncDeviceAccessRule -QueryString “iOS 7.0 11A465″ -Characteristic DeviceOS -AccessLevel Quarantine
New-ActiveSyncDeviceAccessRule -QueryString “iOS 7.0.1 (11A470a)″ -Characteristic DeviceOS -AccessLevel Quarantine 

For the exact strings consult Get-ActiveSyncDevice/Get-MobileDevice output.

For examples of alternative blocking methods using TMG or F5, check this article. More information on ABQ here. Note that users utilizing the OWA for iPhone or iPad apps won’t be blocked after implementing this measure.

Be advised there are already reports of issues with iOS 7.0 such as substantial reduction of battery life and slow devices. What’s far worse is that you can also bypass the lock screen, similar to the lock screen glitch in IOS 6.1.3. L’histoire se répète.

Update (21Sep): According to reports, iOS 7 allows you to make calls despite the lock. How’s that for a potential corporate smart phone.

Update (26sep): Apple has released security update iOS 7.0.2 (build 11A501, all devices) which fixes the lock screen glitch. Another good reason to block earlier iOS 7.0 / 7.0.1 versions, only allowing iOS 7.0.2 devices to retrieve company data.

OWA for iPhone and OWA for iPad are here!

imageToday, the Exchange team announced the immediate availability of the (free) OWA for iPhone and OWA for iPad apps. Exchange fellows Tony Redmond and Dave Stork already hinted earlier this month that something was about to happen in this area.

Users of the Windows 8 Mail app may find the look of the OWA apps to be very familiar:

A quick summary on the app features:

  • Stored credentials for automatic logins;
  • Push notifications;
  • Meeting reminders (even with app closed);
  • Voice activated actions (English only);
  • Contact sync for caller ID function;
  • Remote wipe capability (user data, when the app runs).

That last one is a great, much requested feature when Bring Your Own Device is practiced (apart from that it makes sense due to the sandboxing principle). When required the business can selectively wipe business data without touching your personal information, similar to a feature to be introduced with Windows 8.1 called Remote Business Data Removal.

Besides that you need an iPhone 4S or iPad 2 or higher running iOS 6 or later, the apps are currently only supported for Office 365 subscribers running the tenant on Wave15 (or later). There are reports of the apps working with on-premises Exchange 2013 but that’s unofficial. To find out which version your tenant is running, use Get-OrganizationConfig in a remote PowerShell session, e.g.

$session = New-PSSession –ConnectionUri https://ps.outlook.com/powershell –AllowRedirection –Authentication Basic –Credential (Get-Credential) –ConfigurationName Microsoft.Exchange
Import-PSSession $session
Get-OrganizationConfig | ft AdminDisplayVersion

image

My tenant is running on 15.0.698.10 (15 = Wave 15), so theoretically I’m good to be running OWA for iPhone or OWA for iPad. I say theoretically, as I don’t have any iPhone or iPad available for testing.

An app version for on-premises Exchange 2013 is expected to be released at a later date. More information on configuration and usage of the OWA apps on the Office 365 blog here.

The UC Architects Windows Phone App

Most of you listen to or at least are aware of our The UC Architects podcast. If not, The UC Architects is the world’s most popular community podcast on Exchange and Lync made by people with a passion for Microsoft Unified Communications.

CaptureNow, as of today and thanks to fellow Johan Veldhuis, you can keep track of new podcasts when travelling, check our Tweets or even download and listen to podcasts using the UC Architects Windows Phone App. The app is available for Windows Phone 7 and 8. More information on the app itself can be found on our The UC Architects website.

You can download the app here.

YAII (or Yet Another IOS Issue) (Update)

iPhone iOSL’Histoire se répète. After the meeting issues with iOS 6.0, which were fixed in 6.0.1, you could have assumed Apple learned a lesson. Unfortunately, there are again reports of misbehaving iOS devices; this they’re on iOS 6.1.

As reported by Exchange fellows Tony Redmond and Paul Robichaux today, there are reports iOS 6.1, released end of January, may generate excessive transaction log growth. A report on the F5 forum states the issue may lie in the improper handling of Meeting Responses by iOS 6.1 devices, causing some sort of loop.

Since Exchange is a business critical platform and excessive log growth can have severe consequences when not properly monitored (storage space running out, impact on replication or backup), it is recommended to take the following steps until the situation becomes more clear (and Apple releases a fix):

  • Inform iOS users and discourage them to upgrade at the moment (you can’t uninstall it). To create an inventory of iOS 6.1 users, use Steve Goodman’s Export-iOSDeviceStatistics script (available here) or use Get-ActiveSyncDevice, e.g.
    Get-ActiveSyncDevice | where {$_.DeviceOs -match “iOS 6.1″}
  • Consider implementing an access rule to block IOS 6.1 users (see below);
  • When experiencing the issue, report it to Apple.

When you want to block iOS 6.1 users, specifically the MeetingResponses, you need to filter on User Agent “^Apple.*1002.*” and check the URI for “Cmd=MeetingResponse” (so iOS 6.1 users can keep having e-mail but not send meeting responses). Your options and implementation depend on the components user in your organization:

  • You can block iOS 6.1 devices using Exchange 2010′s Allow/Block/Quarantine mechanism, e.g.
    New-ActiveSyncDeviceAccessRule -QueryString “iOS 6.1 10B142″ -Characteristic DeviceOS -AccessLevel Block
  • Alternatively, you can install and utilize the IIS Rewrite Module;
  • When running TMG/ISA, you can utilize the http filter to block iOS 6.1, i.e. select the ActiveSync publishing rule, Configure HTTP, tab Headers. Unfortunately, wildcards are not supported, so you need to enter each iOS6.1 User-Agent variation by using Add / Request headers and entering the exact string like (list not complete):
    • Apple-iPhone4C1/1002.142
    • Apple-iPad2C1/1002.141
    • Apple-iPad3C3/1002.141
  • F5 has guidance on creating a blocking iRule to block MeetingResponse requests for iOS devices on their forum here.

Generally speaking, like implementing Service Packs or Rollups straight after their release in a production environment is a bad idea, the same rule should apply to clients of all types. I know this might sound challenging with the whole Bring Your Own movement and the adoption of iPhones/iPads, I think blocking or quarantining newly released iOS versions and only allowing them after a few weeks (“incubation period”) can be a wise strategy. Also, this strategy can be part of your communications or house rules for end users when they connect their own or company devices to your corporate environment.

Update (11Feb): It is reported the issue won’t occur after deleting the partnership and setting it up again doing a full sync. To delete a partnership from Exchange’s perspective, use Remove-ActiveSyncDevice, e.g.

Get-ActiveSyncDeviceStatistics –Mailbox Olrik | Where {$_.DeviceOS –match “iOS 6.1”} | Remove-ActiveSyncDevice.

Note that the iOS 6.1.1 update released by Apple today is for iPhone 4S only and fixes 3G issues.

Update (12Feb): Microsoft published KB2814847. They added the option of mitigating the issue by introducing a throttling policy, which Exchange admins need to assign to iOS 6.1 users. Note that this only applies to Exchange 2010 and up and will only slow down the process of transaction log generation, but users can keep using their device. It’s then recommended to instruct iOS 6.1 users to restart their devices if their device complains it can’t connect. Looking at the article, Office 365 already has throttling in-place for all users.

Update (13Feb): Apple has published a support article as well (TS4532). Their suggestion; Turn calendars off, wait 10 seconds then turn calendars back on again. Yes, really. They mention it’s related to responding to recurring meeting exceptions and state a fix is in the works.

Update (15Feb): As it turns out, he meeting response issue isn’t the worst issue in iOS 6.1; apparently you can easily bypass the lock screen on iPhones due to a glitch in the emergency calling feature, allowing anyone to use your phone for calling or accessing your contacts.

Update (16Feb): Rumors are Apple will release iOS 6.1.2 early next week but before February, 20th.This update should fix this meeting bug as well as the lock screen issue.

Update (19Feb): Today, after more than 10 days after initial reports of the issue, Apple released iOS 6.1.2, which supposedly fixes the meeting bug which caused excessive transaction log generation and battery drain. Given Apple’s track record, I’d test this properly first in your environment before waving the green flag to all your iPhone and iPad users. Note that according to reports, the lock screen glitch hasn’t been fixed in 6.1.2.

Discontinued support of ActiveSync in GMail

TechTarget QuoteFew days ago, Stuart J. Johnston of TechTarget approached me and several other Exchange fellows to ask how we thought the discontinued support of ActiveSync in GMail, part of Google’s “Winter Cleaning” operation, would impact users. You can read Stuart’s article here.

For reference and because Stuart only used a single quote from my (I think) extensive response, I’ve included my take on the situation below. Interestingly, today it turns out Google lost an ActiveSync patent case against Microsoft in a British court. Exchange fellow Tony Redmond did a nice writeup on that case and his personal involvement in that case here.

PS: I’ve already asked Stuart to fix my last name in the quote.

Regarding the discontinued support of ActiveSync in GMail, I think impact on both the Exchange as well as the GMail population varies.

First of all, the measure is aimed at new, free GMail accounts. I don’t know exact numbers, but I can imagine the number of people still not having a free GMail account is relatively minimal. Also, EAS will remain available to paid accounts.

Second, EAS is a means – no end – to synchronize information like mail, contacts or agenda. Consumers will adapt and switch to alternative protocols (or plugins) to synchronize this information between their Google account and their device. I think the effect of the information exchange becoming less efficient and the lack of information push is negligible.

Thirdly, Android and iPhone – covering 85% over the smartphone market – provide apps specifically aimed at GMail or other Google services. For those not using Google’s apps, the end user experience may be affected and all the additional tools required to fully synchronize with desktops won’t help.

Worst off are Windows Phone users or Windows 8 users using the built-in Mail app (Surface RT). While the Windows Phone user base may be relatively small, the Windows 8 user base is growing and they are both forced to use IMAP, which only does mail and there are – AFAIK – no *DAV apps in the Store to synchronize calendar or contact information.

While I do understand Google’s case, which is probably more a cost reduction and (resource) focus shift measure rather than another act in the Google vs Microsoft war, I also believe there might be a fair chance of Google shooting itself in the foot by dropping EAS. Microsoft’s free outlook.com service keeps supporting EAS (not surprisingly) and Microsoft has already taken up on plugging outlook.com as the alternative for Google

Finally, I’m in favor of competition which drives innovation. The whole GMail versus Hotmail/Office365 is no exception. However, it gets annoying when vendors drop functionality end users are accustomed to, making them have to put energy into looking at solutions or alternatives, which may become tiresome at some point.

iOS6 issues with Exchange (updated)

Since the release of iOS6, several issues have been identified with this version when used in conjunction with Exchange:

  • Meeting Request where the device user becomes the meeting organizer, which can potentially enable attendees to cancel the meeting for everyone invited. This issue has been documented in KB2768774;
  • Autodiscover not working properly when the e-mail address doesn’t match the user’s UPN.

The Exchange Team published an article where they mentioned several suggestion to “mitigate” the issue; mitigate is quoted here, because some of the suggestions mentioned are in my opinion non-options in a corporate environment, like the suggestion to switch to IMAP/POP. Not only does that remove calendaring functionality, it’s also a lot of work and hassle for end users for the – I expect – short period before we see an iOS update from Apple, after which people can go back to using Exchange ActiveSync again.

How to deal with this issue in the – relatively short – period between now and the iOS 6 fix, depends on the risk your organization is willing to take. When you’re not willing to take any chances, you can block IOS 6 devices using Exchange’s Allow/Block/Quarantine (ABQ) feature or blocking them on the Reverse Proxy level, e.g. ISA or TMG; more information on how to accomplish the latter here. While being a rather draconic measure, it might prove a better temporary measure when compared to the suggestion to ask end users not to take action on calendars in iOS, which could be an accident waiting to happen.

As a more user friendly solution, I’ll gladly bring to your attention a script created by UC Architects fellow Steve Goodman, which can collect information on current iOS users in your environment. Then, with this information, you can selectively pick out iOS 6 devices and communicate the issues with their users until a fix is released. You can get the script here.

Note that there are reports of Apple currently testing IOS 6.0.1 and it is rumored the Meeting Request fix will be included.

Update, November 1st, 2012: Apple released IOS 6.0.1 which fixes the meeting request issue amongst other things (but not the Autodiscover issue). Update your IOS device Over The Air or using iTunes.

Review: iPhone with Exchange 2010: Business Integration & Deployment

A while back, I was asked if I wanted to review a book written by Exchange fellow Steve Goodman. The full title of the book is “iPhone with Microsoft Exchange Server 2010: Business Integration and Deployment” and it’s Steve’s first book. However, I didn’t take that into account when writing this short review.

image

Overall, the book is a well written blend of Exchange and iPhone related content. Now, I look at products called “iPhone and/with ..” with a certain amount of skepticism. In such cases I expect something of which a marketing department decided that adding “iPhone” to the title could increase sales or justify a higher price, all because iPhone sells.

However, when reading through the 290 pages I was pleasantly surprised the book touches iPhone related contents some Exchange administrators may have never experienced first hand, like using the iPhone Configuration Utility. From my experience, most customers treat an iPhone device for what they are, YAEASC (Yet Another Exchange ActiveSync Client).

From an Exchange perspective, the book is extensive and covers topics like server roles and Database Availability Groups, but doesn’t cover all topics and not in too much details. For example, the book mentions that you need to make arrangements in order to make the environment available via the internet, but a little guidance on reverse proxy settings or how the important autodiscover process works might be helpful.

Overall, the book does a good job of trying to cover the gray area between iPhones and Exchange server, and could be appealing to Apple shops wanting to implement Exchange or a customer with Exchange or Office 365 looking for ways to manage iPhone end user devices. If you’re looking for in-depth information on Exchange only or PowerShell/Exchange Management Shell, I’d recommend like “Microsoft Exchange Server 2010 Inside Out” by Tony Redmond or Microsoft Exchange 2010 PowerShell Cookbook by Mike Pfeiffer.

You can check for the book on Amazon here (Kindle version here).

ActiveSync, Intermediate Certificates and You

Recently, a customer called with ActiveSync issues. They had installed the certificate with the proper Subject and SAN entries on the Exchange server, but were unable to synchronize their Windows Phone 7 devices with Exchange 2010; iPhone and Android device encountered no issues.

A quick run of the Exchange Remote Connectivity Analyzer (ExRCA) showed the following:

Capture1 - Ano

As ExRCA discovered, not all certificates of the certificate chain were offered by the server. A quick inspection of the certificate showed the following certification path:

CertChain

In this example, the certificate authority (CA), GlobalSign, uses an intermediate CA, GlobalSign Domain Validation CA – G2, to delegate the process of creating UC certificates. Consequence is that the certificate of the root CA, in this example GlobalSign, as well as the certificate of the intermediate CA, here , must be present on the device or should be offered when setting up the connection so the client can validate them.

Inspection of the Exchange server showed that the intermediate certificate was properly installed on the Exchange server, after the customer imported the Personal Information Exchange File (.pfx) file, provided by the CA as part of the certificate package, which contained all certificates in the chain: root CA, intermediate CA and the UC certificate.

CertIntermediate

Then, investigation moved to the reverse proxy, in this case ISA Server 2006 SP1. It turned out the intermediate certificate on the ISA server, or rather the lack of it, was causing the issue. The customer had imported the individual UC certificate on the ISA server. Because the ISA server didn’t contain the intermediate certificate, it couldn’t send it to the client as part of the certificate chain. After importing the intermediate certificate on the ISA server, ActiveSync started working.

Generally speaking, Windows Mobile or Windows Phone devices don’t contain intermediate certificates so be sure to install them on your Exchange servers as well as on your reverse proxies. Checking and validating intermediate certificates is a client thing and in this case the intermediate CA was available on the non-Windows Phone devices which explained the difference in behavior between Windows Phone, iPhone and Android devices.

Note that, depending on your situation, you may have never seen the above issue before. |This could be the case when you’ve been using certificates directly provided a root CA so far. When selecting your CA, this might be something to take into account as not all mobile devices behave identical as you’ve seen. Also, although lifetime of root and intermediate certificates is quite long, it is something you should manage properly in your environment as you have to an additional certifiate to watch (which might expire or be revoked). Also, depending on volume and mobile costs, sending down extra traffic through the wire/air could be something to take into account. If you don’t think this could be an issue because certificates are relatively small, there’s a reason Mini OWA’s so popular in some regions. Distributing certificates to clients might become a better alternative in those circumstances.

Finally, I want to recommend the excellent SSL Certificate Management & Troubleshooting Tool, provided by DigiCert. It cannot only indicate potential certificate issues like these, or wrongly imported certificates (e.g. user store instead of computer store), but also fix them. As an alternative to ExRCA, you could use the online SSLchecker provided here.

Exchange ActiveSync and Inheritable Permissions issue

The issue and solution described here is by design, but not known by every customer so here’s my short write-up on this subject.

Recently, I was at a customer reporting issues with several users not being able to synchronize their mobile devices using ActiveSync. The customer was running Exchange 2010 SP1 and used various mobile devices, e.g. iPhones as well as Android phones and tablets. A quick look in the IIS logs revealed that devices were connecting properly, but they received HTTP return code 403 (forbidden):

2011-08-30 10:09:31 172.16.10.12 OPTIONS /Microsoft-Server-ActiveSync/default.eas User=XXXXX&DeviceId=d849cec9be024c828b9af73da93bb59b&DeviceType=htcbravo&Log=LdapC2_Error:UserPrincipalCouldNotBeFound_Dc:dc.domain.com_Budget:(D)Conn%3a1%2cHangingConn%3a0%2cAD%3a%24null%2f%24null%2f0%25%2cCAS%3a%24null%2f%24null%2f0%25%2cAB%3a%24null%2f%24null%2f0%25%2cRPC%3a%24null%2f%24null%2f0%25%2cFC%3a1000%2f0%2cPolicy%3aDefaultThrottlingPolicy%5Fe205201e-d418-409a-a15b-4b51baef9bf4%2cNorm%5bResources%3a(DC)dc.domain.com(Health%3a-1%25%2cHistLoad%3a0)%2c%5d_ 443 domain\XXXXX 62.140.137.149 Android-EAS/0.1 403 0 0 124

Another clue was provided by the eventlog, which revealed MSExchange ActiveSync was reporting error 1053:

ss

The remainder of the message reads: “Make sure the user has inherited permission granted to domain\Exchange Servers to allow List, Create child, Delete child of object type “msExchangeActiveSyncDevices” and doesn’t have any deny permissions blocking such operations”. What happens when setting up ActiveSync is that Exchange tries to create a container named ExchangeActiveSyncDevices below the user object in Active Directory and will store in that container an MsExchActiveSync object for each ActiveSync device. Apparently Exchange doesn’t have sufficient permissions to create these objects.

To fix this, open up Active Directory Users and Computers. Now, to be able to inspect the security settings, we first need to activate Advanced Features if not already set. To do this, from the View menu option, select Advanced Features.

Next, navigate to the user object experiencing the issue. Open up Properties, select the Security tab and click Advanced.

image

Notice the Include inheritable permissions from this object’s parent is not set, the reason for Exchange not having any permissions on the object.

To fix the issue, simply check Include inheritable permissions from this object’s parent and click OK. You’ll return to the previous window where you’ll notice the Exchange Server account is now granted permissions on the object:

image

At this point, ActiveSync will work and Exchange will be able to create MsExchActiveSync objects in the ExchangeActiveSyncDevices container:

image

Note that Include inheritable permissions from this object’s parent by default is not enabled for members of the protected groups, e.g. Domain Admins. In fact, every hour the DACL on members of protected groups will be reset and inheritable permissions will be removed. This process is called AdminSDHolder which is to prevent inappropriate changes from being made to protected groups, accidently or otherwise.  Michael B. Smith did a nice write-up on this subject here. This is also the reason why bypassing the AdminSDHolder limitation by manually granting Exchange permissions would be inappropriate.

To prevent this issue, it is recommend to follow an old, yet far from rusty administrator best practice, which is to use one account for day-to-day operations, e.g. work and e-mail, and another account for administrative purposes.

SSL client compatibility

Exchange fellow Jetze Mellema blogged (in Dutch) about a useful online check, which will allow you to check your current client – computer or smartphone – against a set of certificates from different vendors. The short – and more memorable and mobile friendly – URL for this test is as follows: http://m.ssltest.net.

The creator, SSL reseller FairSSL, also keep a total overview, which is located at http://www.ssltest.net/compare/sar.php. Note that the table’s titles are hard to read, but when hovering above the cells the corresponding product will be displayed.