none
Exchange ActiveSync Device ID Format RRS feed

  • Question

  • What is the format of the "device ID" URL parameter used in Exchange ActiveSync?

    Specifically, what are the legal characters and minimum/maximum lengths?

    I used to have an older document (for version 12.1) that defined this.  The latest "open protocol" document specifications, however, do NOT specify these attributes.  I tried an arbitrary URL-safe string but unfortunately I got a DeviceIdInvalidOrMissing sync status (108).

    Please do not reply with "the server accepts anything" because I know for a fact this is not true for ActiveSync versions earlier than 14.0 (i.e. Exchange 2003 & Exchange 2007).

    Monday, October 29, 2012 11:10 PM

Answers

  • Actually, the device ID has a little bit more "structure" to it than just a length.  I found an old PDF titled "Microsoft Exchange ActiveSync Client Protocol" from 2008 (given to me directly from Microsoft), which defines the device ID as follows:

    "ID for the device. This ID must be globally unique. It can be any string of letters and digits up to 32 characters long. The first four characters should represent the name of the company that creates the synchronization client software and should be alphabetical. The following characters can be any combination of letters and digits that is unique for all devices from the company. For example, they can list the device model and serial number. The device ID must use 7-bit ASCII."

    The current "open source" documentation is fairly lacking regarding this field.

    • Marked as answer by NashRaghavan Monday, November 5, 2012 8:33 PM
    Monday, November 5, 2012 8:32 PM
  • Nash,

    Are you saying that your testing with 12.1 has revealed something other than what I've stated?  According to my testing and the Exchange team's confirmation, the requirements that you've cited from your pdf file are no longer in effect for the Open Specifications published on MSDN. 

    Tom

    Tuesday, December 4, 2012 7:15 AM
    Moderator

All replies

  • Hi NashRaghavan,

    Thanks for the question about the format of the device ID parameter in Exchange ActiveSync.  I believe you are specifically referring to the DeviceId= field in the HTTP POST header like below:

    POST /Microsoft-Server-ActiveSync?Cmd=Sync&User=DeviceUser&DeviceId=v140Device&DeviceType=SmartPhone HTTP/1.1

    This is from [MS-ASHTTP] 2.2.1.1.1.1 Base64 Encoded Query Value and 2.2.1.1.1.2.3 Device ID, depending on which encoding you're using:

    In the former:

    "Device ID length (1 byte): An integer that specifies the length of the Device IDfield. A value
    of 0 indicates that the Device IDfield is absent.

    Device ID (variable): A string or a GUIDthat identifies the device. For details, see section
    2.2.1.1.1.2.3. The length of this field is specified by the Device ID lengthfield."

    And in the latter:

    "The device ID is specified by the device-id-specABNF rule portion of the plain text query value. The value, represented by the device-id ABNF rule, is a string that specifies the device. Each device MUST have a unique device ID string. Each request from the device MUST include the same device ID string."

    Does that answer your question?

    If not, please supply an example of your POST and I can investigate further for you.

    Best regards,
    Tom Jebo
    Escalation Engineer
    Microsoft Open Specifications

     

     

     

    Tuesday, October 30, 2012 12:52 AM
    Moderator
  • I'm posting using DeviceId= in the URL (not Base64 encoded), like so:

    https://myserver.com/Microsoft-Server-ActiveSync?Cmd=FolderSync&User=myuser&DeviceId=1234567ABCDEFGHIJKLMNOPQRSTUVWXYZ&DeviceType=mydevice

    When doing so with the exact same DeviceID, I get a status "108" when attempting to perform a FolderSync.

    Unfortunately the device-id-specABNF does not specify the DeviceID format.  I'm specifically looking for:

    - Minimum & Maximum number of allowed characters

    - What is consider a legal character

    - Any particular required form (i.e. certain parts of the device ID are reserved for special meanings)

    Friday, November 2, 2012 5:53 PM
  • It looks the specification is almost accurate.  The one thing that my testing (and review of code) reveals is that it's missing a length constraint.  It only allows 32 digits.  Specifically, you can use any unique combination of alphanumeric characters between 0x21 and 0x7E up to 32 characters in length.  So, if you follow along with the current specification:

    MS-ASHTTP 2.2.1.1.1.2.3 Device ID (and related sections) says:
    "The device ID is specified by the device-id-specABNF rule portion of the plain text query value. "

    2.2.1.1.1.2 "Plain Text Query Value" says:
    "The Augmented Backus-Naur Form (ABNF)notation ([RFC5234]) is used to specify the format
    of the plain text query value."

    and

    "device-id-spec = "DeviceId=" device-id"

    and

    "device-id = 1*VCHAR"

    http://www.ietf.org/rfc/rfc5234.txt says:

             VCHAR          =  %x21-7E
                                    ; visible (printing) characters

    Which is:

    0000h: 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30  !"#$%&'()*+,-./0
    0010h: 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40  123456789:;<=>?@
    0020h: 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50  ABCDEFGHIJKLMNOP
    0030h: 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60  QRSTUVWXYZ[\]^_`
    0040h: 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70  abcdefghijklmnop
    0050h: 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E            qrstuvwxyz{|}~

    And then simply add the restriction that the DeviceId not exceed 32 characters, you should avoid the status 108.

    Your example, 1234567ABCDEFGHIJKLMNOPQRSTUVWXYZ is too long.  1234567ABCDEFGHIJKLMNOPQRSTUVWXY works for me.  I will submit a request to the writers to clarify the specification for [MS-ASHTTP] 2.2.1.1.1.2.3 "Device ID"

    Thanks,

    Tom


    Saturday, November 3, 2012 1:07 AM
    Moderator
  • Actually, the device ID has a little bit more "structure" to it than just a length.  I found an old PDF titled "Microsoft Exchange ActiveSync Client Protocol" from 2008 (given to me directly from Microsoft), which defines the device ID as follows:

    "ID for the device. This ID must be globally unique. It can be any string of letters and digits up to 32 characters long. The first four characters should represent the name of the company that creates the synchronization client software and should be alphabetical. The following characters can be any combination of letters and digits that is unique for all devices from the company. For example, they can list the device model and serial number. The device ID must use 7-bit ASCII."

    The current "open source" documentation is fairly lacking regarding this field.

    • Marked as answer by NashRaghavan Monday, November 5, 2012 8:33 PM
    Monday, November 5, 2012 8:32 PM
  • Hi NashRaghavan,

    I'm checking with the Exchange team to try to nail down what missing and what is correct.  In the case of your test device id, shortened to 32 characters, you can see that the first four characters are not alphabetical, even if you assume they are text representations of hexadecimal bytes.  And yet it still works in my testing.  Perhaps that's because of the "should" in the excerpt you shared.   I'll let you know as soon as I have more information to share.

    Thanks,

    Tom

    Monday, November 5, 2012 8:52 PM
    Moderator
  • Did you test with EAS versions 2.5 and 12.1 as well?

    I've noticed that newer versions (i.e. 14.1) tend to be less strict in many areas of the protocol.

    Monday, November 5, 2012 9:32 PM
  • No, but I'm checking on 12.1 as well.  EAS 2.5 is not covered by the Open Specifications.

    Tom

    Monday, November 5, 2012 9:51 PM
    Moderator
  • Nash,

    Are you saying that your testing with 12.1 has revealed something other than what I've stated?  According to my testing and the Exchange team's confirmation, the requirements that you've cited from your pdf file are no longer in effect for the Open Specifications published on MSDN. 

    Tom

    Tuesday, December 4, 2012 7:15 AM
    Moderator