Exchange ActiveSync iOS and Android Device User Agent Strings

This list is no longer actively maintained, but will be left online for reference and comments.

Updated: April 2023.

iOS devices unfortunately do not register with ActiveSync or other tools with a logical clear human readable version number. Instead, they show up with strings like "Apple-iPhone3C1/902.206"  

Obviously, this makes discovery and reporting difficult.  To help ourselves, and the community at large, we now maintain this list of hardware and iOS versions for Apple gear.

Hardware Versions:

iPod2C1 = iPod Touch 2
iPod3C1 = iPod Touch 3
iPod4C1 = iPod Touch 4
iPod5C1 = iPod Touch 5

iPad1C1 = iPad 
iPad2C1 = iPad 2 WIFI 
iPad2C2 = iPad 2 WIFI + 3G 
iPad2C3 = iPad 2 WIFI + 3G CDMA 
iPad2C4 = iPad Mini - WIFI 
iPad2C5 = iPad Mini - WIFI + LTE
iPad3C1 = The New iPad (iPad 3)- WIFI
iPad3C2 = The New iPad (iPad 3) - WIFI + LTE 
iPad3C3 = iPad with Retina Display (iPad 4) - WIFI 
iPad3C4 = iPad with Retina Display (iPad 4) - WIFI + LTE  
iPad4C1 = iPad Air - WIFI 
iPad4C2 = iPad Air - WIFI + LTE 
iPad4C4 = iPad Mini with Retina Display - WIFI
iPad4C5 = iPad Mini with Retina Display - WIFI + LTE
iPad4C7 = iPad Mini 3 WIFI
iPad4C8 = iPad Mini 3 WIFI+LTE
iPad5C1 = iPad Mini 4 - WIFI
iPad5C2 = iPad Mini 4 - WIFI + LTE
iPad5C3 - iPad Air 2 - WIFI
iPad5C4 = iPad Air 2 = WIFI + LTE
iPad6C3 = iPad Pro (9.7") - WIFI
iPad6C4 = iPad Pro (9.7") - WIFI + LTE
iPad6C7 = iPad Pro (12.9") - WIFI
iPad6C8 = iPad Pro (12.9") - WIFI + LTE
iPad6C11 = iPad 5th Gen
iPad6C12 = iPad (9.7") 2017 - WIFI
iPad7C1 = iPad Pro (12.9") WIFI 2nd Gen
iPad7C2 = iPad Pro (12.9") WIFI + LTE 2nd Gen
iPad7C3 = iPad Pro (10.5") WIFI 2nd Gen
iPad7C4 = iPad Pro (10.5") WIFI + LTE 2nd Gen
iPad7C5 = iPad 6th Gen
iPad7C6 = iPad 6th Gen
iPad7C11 = iPad (10.2") 7th Gen WIFI
iPad7C12 = iPad (10.2") 7th Gen WIFI+LTE
iPad8C1 = iPad Pro (11")
iPad8C2 = iPad Pro (11")
iPad8C3 = iPad Pro (11")
iPad8C4 = iPad Pro (11")
iPad8C5 = iPad Pro (12.9") 3rd gen
iPad8C6 = iPad Pro (12.9") 3rd gen
iPad8C7 = iPad Pro (12.9") 3rd gen
iPad8C8 = iPad Pro (12.9") 3rd gen
iPad8C11 = iPad Pro - Wi-Fi 12.9", 4th gen
iPad8C12 = iPad Pro - Wi-Fi + Cellular 12.9", 4th Gen
iPad11C1 = iPad Mini 5
iPad11C2 = iPad Mini 5
iPad11C3 = iPad Air 3rd gen
iPad11C4 = iPad Air 3rd gen
iPad11C7 = iPad - WIFI+LTE 10.2", 8th Gen

iPhone1C2 = iPhone 3G 
iPhone2C1 = iPhone 3GS
iPhone3C1 = iPhone 4 GSM
iPhone3C2 = iPhone4 GSM
iPhone3C3 = iPhone 4 CDMA
iPhone4C1 = iPhone 4S
iPhone5C1 = iPhone 5 GSM/LTE
iPhone5C2 = iPhone 5 CDMA USA/China 
iPhone5C3 = iPhone 5C GSM/CDMA/Americas
iPhone5C4 = iPhone 5C Europe/Asia
iPhone6C1 = iPhone 5S GSM/CDMA/Americas
iPhone6C2 = iPhone 5S Europe/Asia
iPhone7C1 = iPhone 6 Plus
iPhone7C2 = iPhone 6
iPhone8C1 = iPhone 6S
iPhone8C2 = iPhone 6S Plus
iPhone8C4 = iPhone SE
iPhone9C1 = iPhone 7
iPhone9C2 = iPhone 7 Plus
iPhone9C3 = iPhone 7
iPhone9C4 = iPhone 7 Plus  
iPhone10C1 = iPhone 8
iPhone10C2 = iPhone 8 Plus 
iPhone10C3 = iPhone X 
iPhone10C4 = iPhone 8 
iPhone10C5 = iPhone 8 Plus 
iPhone10C6 = iPhone X
iPhone11C2 = iPhone XS
iPhone11C6 = iPhone XS Max
iphone11C8 = iPhone XR
iphone12C1 = iPhone 11
iphone12C3 = iPhone 11 Pro
iPhone12C5 = iPhone 11 Pro Max
iPhone12C8 = iPhone SE (Second Generation)
iPhone13C1 = iPhone 12 Mini
iPhone13C2 = iPhone 12 
iPhone13C3 = iPhone 12 Pro
iPhone13C5 = iPhone 12 Pro Max
iPhone14C2 = iPhone 13 Pro
iPhone14C3 = iPhone 13 Pro Max
iPhone14C4 = iPhone 13 Mini
iPhone14C5 = iPhone 13
iPhone14C6 = iPhone SE (Third Generation)
iPhone14C7 : iPhone 14
iPhone14C8 : iPhone 14 Plus
iPhone15C2 : iPhone 14 Pro
iPhone15C3 : iPhone 14 Pro Max

iPhone OS Versions:

508.11 = 2.2.1
701.341 = 3.0
701.400 = 3.0.1 
703.144 = 3.1 
704.11 = 3.1.2 
705.18 = 3.1.3  
702.367 = 3.2 (original iPad only) 
702.405 = 3.2.1 (original iPad only) 
702.500 = 3.2.2 (original iPad only) 

From this point forward, iPhone OS was renamed iOS.

iOS Versions:

801.293 = 4.0
801.306 = 4.0.1
801.400 = 4.0.2
802.117 = 4.1
802.118 = 4.1 
803.148 = 4.2.1 
803.14800001 = 4.2.1 
805.128 = 4.2.5 
805.200 = 4.2.6 
805.303 = 4.2.7 
805.401 = 4.2.8 
805.501 = 4.2.9 
805.600 = 4.2.10 
806.190 = 4.3 
806.191 = 4.3 
807.4 = 4.3.1 
808.7 = 4.3.2 
808.8 = 4.3.2 
810.2 = 4.3.3 
810.3 = 4.3.3 
811.2 = 4.3.4 
812.1 = 4.3.5
901.334 = 5.0 
901.40x = 5.0.1 
902.17x = 5.1 
902.206 = 5.1.1 
1001.40x = 6.0 
1001.52x = 6.0.1
1002.14x= 6.1 
1002.146 = 6.1.2 
1002.329 = 6.1.3 
1002.350 = 6.1.3  
1101.465 = 7.0 
1101.470=7.0.1 
1101.47000001=7.0.1 
1101.501=7.0.2 
1102.511 = 7.0.3 
1102.55400001 = 7.0.4 
1102.601 = 7.0.5 
1102.651 = 7.0.6 
1104.167 = 7.1 
1104.169 = 7.1 
1104.201 = 7.1.1 
1104.257 = 7.1.2 
1201.365 = 8.0 
1201.366 = 8.0.1 
1201.405 = 8.0.2 
1202.410/411 = 8.1 
1202.435/436 = 8.1.1 
1202.440/445 = 8.1.2 
1202.466 = 8.1.3 
1204.508 = 8.2 
1206.69 = 8.3 
1208.143 = 8.4 
1208.321 = 8.4.1  
1301.4xxxxxx = 9.0 betas 
1301.342 = 9.0 (older devices) 
1301.344 = 9.0 
1301.402 = 9.0.1 (older devices) 
1301.404 = 9.0.1 
1301.452 = 9.0.2 
1302.143 = 9.1 
1303.075 = 9.2 
1304.15= 9.2.1 
1305.5234xxxx = 9.3 betas 
1305.234 = 9.3 
1305.328 = 9.3.1 
1306.69 = 9.3.2 
1306.72 = 9.3.2 (iPad Pro only) 
1307.34 = 9.3.3 
1307.35 = 9.3.4 
1307.36 = 9.3.5 (important security fix)
1305.5xxx = 10.0 betas 
1401.403 = 10.0.1 
1401.456 = 10.0.2 
1402.72 = 10.1 
1402.100 = 10.1.1 
1403.92 = 10.2 
1404.27 = 10.2.1 
1405.277 = 10.3 
1405.304 = 10.3.1 
1406.89 = 10.3.2 
1406.8089 = 10.3.2 (iPad Pro) 
1407.60 = 10.3.3  
1501.5xxx = 11.0 betas 
1501.372 = 11.0 
1501.402 = 11.0.1 
1501.421 = 11.0.2  
1501.432 = 11.0.3 
1502.5xx = 11.1 betas
1502.93 = 11.1 
1502.150 = 11.1.1 
1502.202 = 11.1.2 
1503.5xx = 11.2 betas 
1503.114 = 11.2 
1503.153 = 11.2.1 
1503.202 = 11.2.2 
1504.60 = 11.2.5 
1504.100 = 11.2.6 
1505.216 = 11.3 
1505.302 = 11.3.1  
1506.79 = 11.4 
1507.77 = 11.4.1

1601.5xx = 12.0 betas
1601.366 = 12.0 
1601.405 = 12.0.1
1602.5xx = 12.1 betas
1602.92 = 12.1
1603.50 = 12.1.1
1604.39 = 12.1.3 
1604.57 = 12.1.4
1605.5xx = 12.2 betas
1605.227 = 12.2 
1606.5xx = 12.3 betas
1606.156 = 12.3
1606.203 = 12.3.1
1607.5xx = 12.4 betas
1607.77 = 12.4
1607.102 = 12.4.1
1607.114 = 12.4.2
1607.130 = 12.4.3
1607.140 = 12.4.4
1607.161 = 12.4.5
1607.183 = 12.4.6
1607.192 = 12.4.7
1607.201 = 12.4.8
1608.5   = 12.4.9
1608.20 = 12.5.0

1701.5xx = 13.0 betas
1701.577 = 13.0 
1701.58x = 13.1 betas
1701.844 = 13.1
1701.854 = 13.1.2 (latest devices)
1701.86x = 13.1.2
1702.5xx = 13.2 betas
1702.84 = 13.2 
1702.102 = 13.2.2 
1702.111 = 13.2.3 
1703.5xx = 13.3 betas
1703.54 = 13.3
1704.5xx = 13.3.1 beta
1705.255 = 13.4 
1705.262 = 13.4.1
1706.75 = 13.5
1706.80 = 13.5.1 
1707.68 = 13.6
1707.80 = 13.6.1
1708.35 = 13.7

1801.5xx = 14.0 betas
1801.373 = 14.0 
1801.393 = 14.0.1
1801.8395 = 14.1
1802.5xxx = 14.2 betas
1802.92 = 14.2
1803.66 = 14.3
1804.52 = 14.4
1804.61 = 14.4.4
1804.70 = 14.4.2
1805.199 = 14.5
1805.212 = 14.5.1
1806.72 = 14.6 
1807.69 - 14.7 
1807.82 = 14.7.1
1808.17 = 14.8

190x.5xx = 15.x betas
1901.346 = 15.0
1901.348 = 15.0.1
1902.74 = 15.1 
1902.81 = 15.1.1 
1903.63 = 15.2.1 
1904.50 = 15.3
1904.52 = 15.3.1
1905.241 = 15.4
1905.258 = 15.4.1
1906.77 = 15.5
1907.71 = 15.6
1907.82 = 15.6.1
1908.12 = 15.7
1908.117 = 15.7.1

2001.362 = 16.0
2001.380 = 16.0.2
2001.392 = 16.1 (depends on model of device)
2002.82 = 16.1 (depends on model of device)
2002.101 = 16.1.1
2002.110 = 16.1.2
2003.65 = 16.2
2004.47 = 16.3
2004.67 = 16.3.1
2005.247 = 16.4
2005.252 = 16.4.1 (current)

We've also had requests for some Android agents - particularly Samsung - which are proving equally as annoying to decipher.

Samsung encodes the Android OS version number at the end of their string, with zero padding.

SAMSUNG-SGH-I337M/101.403 indicates Android 4.3 
SAMSUNG-SGH-I317M/100.40102 indicates Android 4.1.2 etc.

Living Microsoft in an iPhone World

With the continued struggle of Windows Phone to get any kind of market traction, despite finally being mostly on par functionality wise, most of us in the Microsoft world have switched to using iOS or Android mobile hardware.

Surprisingly, these days, it's actually quite an easy coexistence.

Paul Thurrott recently discussed this very topic in an excellent blog post we recommend

Microsoft + iPhone

What surprised most about this article is just how many applications Microsoft makes for iOS. Well worth a read.

Apple iOS Devices can no longer access .local domain over VPN

Apple's software quality slide continues with this recent bug that has existed in all versions of iOS 8, and is thus far unacknowledged. This appears to be related to the rewrite of much of the network stack in current versions of iOS and OS X.   

While this previously worked in older versions of iOS (up to and including iOS 7), starting with recent versions if a VPN connection is established into  a corporate LAN - and that LAN uses the (very common) .local domain for their internal DNS - name resolution will completely fail. Thus, iPhones and iPads can no longer access any of the sites or applications that rely on the internal name resolution. It appears that this is purely a code bug that causes the DNS resolver on iOS to completely ignore the recursive responses for .local requests.

An extensive thread on Apple's support forums discusses this issue, with the usual crickets response from Cupertino.

The workaround that we've successfully implemented on several of our customer sites is to add a dummy DNS zone specifically for the "local" root zone.

For example, if the internal DNS (AD) name is myclient.local, an existing forward lookup zone will be in place for myclient.local. In order for resolution to now work correctly for iOS, add in a forward lookup zone for local. You can accept all the defaults when creating, and in most cases it will be AD integrated. Then, below this new zone, add a domain (subdomain) for myclient. It is worthwhile to add in name server records into this new zone, and in some cases (depending on the internal application) it may be necessary to add host or cname records under the new zone/domain as well.

As usual, let's hope Apple eventually gets around to fixing this one.

Smarter Room and Equipment Booking Response Emails in Exchange

Room and Equipment mailboxes are extremely useful in Exchange, especially when combined with the Resource Booking Attendant to automatically accept or reject invites.

What isn't well implemented is the ability to have the Booking Attendant respond with information that is relevant to the response.  Microsoft provide's the More Information option which allows the response to include some extra text, but this information is unfortunately sent with every response - accept, deny, or change.

For resources like conference call lines, or specialized meeting rooms with booking restrictions this can lead to confusion.  Why is the room denying my request, then sending me useful information about the room?  

Behold the Transport Rule

To work around this limitation, an administrator must instead turn to the flexibility of Transport Rules.  Transport Rules allow for the checking of the response type and then including more relevant information for the end user.  Why was my request denied? What do I do next? What do I need to know about the resource?

The trick to making these work is the Append Disclaimer Text Rule Action, which will then allow some basic HTML to be entered.  This will get appended to the response message from the Booking Attendant (below the canned information that Exchange adds).  One caveat is that due to the way Exchange and Outlook utilize embedded special messages for Calendar Response Emails, most HTML is stripped.  Therefore the disclaimer text should only use very simple HTML tags like <FONT>, <B>, <BR>, etc. Most notably Tables and CSS will be stripped. However, if all your users are using OWA instead of desktop Outlook, quite full featured HTML is allowed. YMMV.

Putting it all Together

1. Modify all of your Resource Mailboxes to remove any Add Additional Text settings under the Resource Information tab.
2. Create a new Transport Rule under Organization Configuration/Hub Transport.  One rule for each type of response is necessary.  i.e. "Room Booking Accepted" and "Room Booking Denied for Permissions" or "Room Booking Conflict"
3. For the Condition of the rule, choose the From People and When the Subject Field or Message Body Contains specific words.  Be sure NOT to choose the text patterns option, as this will not work for calendar responses.
4. Click on these new rule conditions in the bottom pane and select each of the Resource Mailboxes in the From settings.  Then, in the subject or body selection, type the exact phrase that is part of the appropriate built-in Exchange meeting response.  For example, "your request was accepted" (no quotes)
5. Click next, then choose Append disclaimer text and fallback to action if unable to apply for the Action.  Click in the bottom pane on append and enter the raw HTML for your response.  It is best to create and test the HTML elsewhere, than paste it into the box as there is no sort of preview or editor.
6. For the rest of the settings of the Transport Rule accept the defaults.  Finish and close the rule.
7. The responses should work within about 30 seconds of creating or modifying the rule
8. Repeat as necessary for different resource types and responses. 

Note, this works equally well for Office 365/Exchange 2013/Online, but obviously the steps are slightly different through Exchange Admin Center.  An additional item to keep in mind is that it is unfortunately not possible remove the embedded canned response text that Exchange always includes. We refer to this as the "above the line" text, as exchange puts a horizontal rule and "Sent by Microsoft Exchange Server..."

This method has been of tremendous value to many of our clients to get much more useful responses, and happier staff.

Need help configuring this in your environment? Is your Exchange server out of control?  Contact us today!

Resource Mailbox Responses Show in Plain Text

Here's another non-obvious gem that seems to have been slipping through the Exchange Team cracks for years now.

On Exchange 2010 if a Resource Mailbox (typically a meeting room) is set to send "Additional Text" in the "Resource Information" settings, the response will always arrive as Plain Text, even if it is configured with proper HTML.  However, this will only occur for users who are using Outlook 2010 or 2013 in online mode, rather than the preferred and standard cached mode.

This is a known issue with no current resolution.  It does not appear to affect Exchange 20103.

Additionally, due to the way this Resource Information text is wrapped in a special embedded calender response message, the formatting is VERY limited and non-standard; most HTML will not work correctly. It does, whoever, appear to work correctly with most HTML for users who receive the response via Outlook Web App (OWA).  Horribly inconsistent and frustrating.

Office 365 (Small) Business Plans now on par with Enterprise

Transport Rules in Office 365 Small Business 

Microsoft rolled out the consolidation and updates to their Office 365 plans back in October 2014, which was a huge step in the right direction for the service.

Not only did they simplify down to fewer plans (a rare move for Microsoft!), they also finally unified the administrative UI for all.  No longer will we have to remember obscure URLs (I'm looking at you Exchange Control Panel), or muddle our way through a mix of confusingly different admin sites.  On top of that, you can now have up to 300 mailboxes in the Business plans, and can mix and match Business, Enterprise and Standalone SKUs all in the same account.   FINALLY!

Somewhat lost in this news - but a very welcome change - is that the actual back-end infrastructure is now the same for all of the services.  That means Business customers now get virtually all the power as Enterprise customers.  Of particular interest is Transport Rules.  A glaring absence in previous Business plans, these are now fully available across the board.  You should drop everything and go enable a Transport Rule to "Block Executable Content" on ALL of your Office 365/Exchange Online domains.  This is a superb anti-malware step that makes every admin's life easier.

Now, in true Microsoft fashion, this transition couldn't be simple.  Everyone on an existing Small or Medium Business Plan will need to either manually force an upgrade to the new plans (and thus, we're assuming, get migrated behind the scenes to new infrastructure) or wait until October 2015!  

No problem, you say, we've got our old friend the Switch Plans Wizard. I like wizards!  Switch Plans will let you upgrade early, except when it won't.  Which seems to be most of the time.

Currently it won't work if there are ANY open service Incidents under the Service Status page. Additionally, upgrades to the new plans aren't available if you have more than one type of existing Plan.  Small Business and Small Business Premium? Nope.  Old P Plan mixed with newer Small Business Plan.  Nope.  

However, there does seem to be a workaround.  Pick your largest group of existing subscriptions and cancel the others temporarily  (i.e if you have 10 Small Business and 2 Small Business Premium subscriptions, keep the Small Business and cancel the Premium.)  Nothing will happen to your mailboxes or users.  The users and licenses will just temporarily go into a licensing holding pattern on Microsoft's side.   Users won't lose access or notice anything.  You will, however, get a temporary warning about license problems in the Admin Portal, though.

View fullsize

At this point the Switch Plans Wizard under the Billing section of the Portal should now allow you to upgrade your existing Small or Medium Business Plans to the equivalent Office 365 Business Essentials or Business Premium plans.

View fullsize

The New Plans

Just like that you'll be migrated and have a much more powerful and easy to administer service!  The bonus? They're cheaper, too.  Also - remember to then go back and purchase the equivalent new versions of the other licenses you cancelled.

Here's Microsoft's original blog post on the topic:
http://blogs.office.com/2014/07/09/evolving-office-365-plans-for-small-and-midsized-businesses/

 

Update:  We've clarified this process with a recent transition, and it's still far more complicated than it needs to be.  Microsoft really needs to make this simpler.
When removing multiple types of license to temporary consolidate down to a single license type, it will still take 30 days by default before the license type is "deprovisioned" from Microsoft's systems. Only after that time has passed can the Switch Plans wizard be used.  

It is possible, however, to open a ticket with Microsoft to have an "Expedited Deprovisioning" performed on a license.  This happens within 3 days, and requires filling out a special form, and you must first ensure that you have temporarily assigned a different license to all active users first, or there is risk of the users and mailboxes being deleted.

Need Office 365 Migration Help?  Want us to do the hard parts for you?  Contact us today.

Exchange Online (or EOP) Transport Rules and Distribution Groups

When creating a transport rule that is meant to apply to a Distribution Group in Exchange Online (or EOP or Exchange 2013 for that matter), often an administrator will attempt to use "The sender is" or "The sender address includes" or look for text in a the "To:" header.  

Unfortunately, none of these options will work due to the way that Exchange appears to first expand the Distribution Group, then checks the Transport Rules.

This information is non-obvious and buried in the Transport Rule Conditions documentation.

Symptoms of this issue are that the transport rule won't fire, and as a result any actions will be skipped.

So how do you work around this?  Use a condition of "The To or Cc box contains" in the rule, and it will correctly check for the SMTP address of the Distribution Group.  It does not appear possible, however, to check for a BCC to a DG.

Administrators must also be careful not to use "The Sender is a member of" or this rule will apply to all emails received by users who are a member of the list, which can have major negative effects.

On the other side of the Transport Rule fence is trying to use a Transport Rule Action of Forward or Redirect a message to a Distribution Group.  This will appear to work, then throw an error when the rule is saved:

The transport rule can’t be created because MyGroup@MyDomain.com, the recipient to be added by a rule action, is a distribution group. Transport rules can’t add distribution groups to messages.

This is a known issue, and the only workaround in this instance is to create a hidden Shared Mailbox.  Change this Shared Mailbox's Delivery Options to Forward mail to your Distribution Group only, then set the Transport Rule to Redirect or Forward to this new Shared Mailbox.  Clunky, but it works.