Debug połączeń ActiveSync

4 października 2016 at 09:26

Prawie każdy update urządzeń z jabłkiem na obudowie – na potrzeby wpisu: I-shit’ów 😉 skutkuje mniejszymi bądź większymi problemami z połączeniem lub szybkością działania poczty na tych urządzeniach. Z racji, że w jabłuszkach zakochane są zwłaszcza osoby na wysokich stanowiskach to każde takie zgłoszenie urasta do rangi mega problemu… i zaczyna się debug oraz przysłowiowe „udowodnij, że nie jesteś słoniem”… Nie ważne, że poczta działa poprawnie na Windows Phone, na Androidzie, na Apple-sraple I-shit w wersji 9.3.5 – ale nie działa poprawnie na nowym super wypasionym I-shit 7 za kila tysięcy – jak to jest możliwe? To na pewno Wasze serwery poczty… brzmi znajomo co? 😉

A ile osób sprawdziło, że nowy Apple-sraple usunął wsparcie dla połączeń PPTP? Że zdalny wipe z poziomu ActiveSynca już się nie uda, bo trzeba korzystać z dedykowanego MDM’a lub konta Apple i można by tu mnożyć przykłady… Nieważne – trzeba jednak udowadniać, że nie jest się słoniem i że „u nas działa”, więc zaczynamy:

  • Włączamy debug ActiveSync’a na skrzynce użytkwonika korzystającego z Active Sync’a:

  • Odtwarzamy „problemy”, wolne działanie poczty etc. na urządzeniu
  • Wysyłamy logi na swoją skrzynkę i szukamy błędów (których nie ma :) )

Na maile dostaniemy łady log w formie pseudo-XML’owej

Zawierającej dane takie jak czas połączenia, serwer, żądanie HTTP, adresy IP, porty, czas i status odpowiedzi etc:

„RequestTime :
10/03/2016 14:52:47
ServerName :
ExchangeServer01
AssemblyVersion :
15.01.0466.033
Identifier :
75752F81

RequestHeader :
POST /Microsoft-Server-ActiveSync/Proxy/default.eas?User=(null)&DeviceId=FL2ZHCCJ910RV2T1U7D51JPN60&DeviceType=iPhone&Cmd=Sync HTTP/1.1

Content-Length: 76
Content-Type: application/vnd.ms-sync.wbxml
Accept: */*
Accept-Encoding: gzip
Accept-Language: pl-pl
Authorization: ********
Host: ExchangeServer01.mkrzanowicz.it:444
User-Agent: Apple-iPhone7C2/1401.456
X-Forwarded-For: 192.168.168.66
X-Forwarded-Port: 49218

X-MS-EdgeIP:
X-ExCompId: ClientAccessFrontEnd
X-MS-PolicyKey: 306812734
MS-ASProtocolVersion: 16.0
X-OriginalRequestHost: activesync.mkrzanowicz.it
X-OriginalRequestHostSchemePort: 443:https:activesync.mkrzanowicz.it
X-MSExchangeActivityCtx: V=1.0.0.0;Id=a7dc44e3-d578-415f-a61f-9abb77588cf3;C=;P=
X-EAS-Proxy: S-1-5-21-97693321195-85389361127-9500123224-52104,MKRZANOWICZ\mkrzanowicz
msExchProxyUri: https://activesync.mkrzanowicz.it/Microsoft-Server-ActiveSync?User=(null)&DeviceId=FL2ZHCCJ910RV2T1U7D51JPN60&DeviceType=iPhone&Cmd=Sync
X-IsFromCafe: 1
X-SourceCafeServer: ExchangeServer02.mkrzanowicz.it
X-CommonAccessToken: XXX

A następnie jest sekcja zawierająca samo żądanie np:

„RequestBody :
<?xml version=”1.0″ encoding=”utf-8″ ?>
<Sync xmlns=”AirSync:”>
<Collections>
<Collection>
<SyncKey>1993381246</SyncKey>
<CollectionId>20</CollectionId>
<GetChanges>0</GetChanges>
<Options>
<FilterType>4</FilterType>
<BodyPreference xmlns=”AirSyncBase:”>
<Type>4</Type>
</BodyPreference>
</Options>
<Commands>
<Change>
<ServerId>20:406</ServerId>
<ApplicationData>
<Read xmlns=”Email:”>1</Read>
</ApplicationData>
</Change>
</Commands>
</Collection>
</Collections>
</Sync>”

Później stan i status odpowiedzi:

AccessState :
Allowed

AccessStateReason :
Global

ResponseHeader :
HTTP/1.1 200 OK
MS-Server-ActiveSync: 15.1

Więc mamy już odpowiedź HTTP 200 OK, czyli zgodnie z oczekiwaniem, teraz jeszcze musimy zobaczyć kiedy została wygenerowana odpowiedź:

ResponseTime :
10/03/2016 14:52:47

No i jeśli przyszła w tej samej sekundzie to już mamy poważny argument udowadniający, że „nie jesteśmy słoniem” :)

Jeśli to nie wystarczy to możemy się zagłębiać w sekcji „ResponseBody :” i sprawdzać odpowiedzi, szukać błędów, ale generalnie powyższa szybka analiza powinna być wystarczająca.

Gdybyście byli zainteresowani dalszą inwestygacją to polecam zajrzeć an bloga: https://blogs.technet.microsoft.com/exchange/2013/10/04/under-the-hood-exchange-activesync-mailbox-log-analysis/

Jeśli ważne osoby w organizacji nadal nie wierzą, że nie jesteśmy słoniem a ich I-shity za kilka tysięcy złotych przecież są tak super, że nie mogą mieć problemów same w sobie :) – to pozostaje nam jeszcze przejrzenie:

  1. Throttling Policies ( Get-ThrottlingPolicy, Get-ThrottlingPolicyAssociation) + przejrzenie event logów pod kątem ewentualnego odrzucania kolejnych połączeń
  2. Logów IIS’a
  3. Podłączenie IShit’a do Komputerka tej samej firmy, zmapowanie wirtualnego interfejsu i przechwycenie ruchu sieciowego zgodnie z opisem np na tej stronie: http://useyourloaf.com/blog/remote-packet-capture-for-ios-devices/

I życzę wszystkim z całego serca żebyście rozwiązywali problemy, które faktycznie występują, które generują błędy a nie tracili czas na udowadnianie, że wszystko działa poprawnie, bo nie tędy droga, a niestety in więcej I-badziewia, tym więcej podobnych akcji… :(