none
CAS Array непредвиденно закрывает подключения RRS feed

  • Вопрос

  • День добрый.

    После перезагрузки серверов CAS Array возникили проблемы со временем сессий в OWA. Пользователи начали отваливаться от сессий и возвращаться на окно ввода логин/пароля. OWA опубликован через TMG Standalone Array. В логах TMG следующая запись:

    Failed Connection Attempt Servername 11.04.2012 16:34:02 
    Log type: Web Proxy (Reverse) 
    Status: 10054 Удаленный хост принудительно разорвал существующее подключение.  
    Rule: OWA 
    Source: Internal (SourceIP:34669) 
    Destination: Local Host (CAS Array IP:443) 
    Request: GET http://mail.contoso.com/OWA/ev.owa?UA=0&oeh=1&ns=PendingRequest&ev=PendingNotificationRequest&canary=14f1c0a836564c8e9a9611d18d4449afn=h0wf7ex9 
    Filter information: Req ID: 12d7ca2f; Compression: client=Yes, server=No, compress rate=0% decompress rate=0% ; FBA cookie: exists=yes, valid=yes, updated=no, logged off=no, client type=private, user activity=yes 
    Protocol: https 
    User: (LDAP)User 
     Additional information 
    Client agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:11.0) Gecko/20100101 Firefox/11.0
    Object source: Internet (Source is the Internet. Object was added to the cache.)
    Cache info: 0x610c0000 (Response includes the CACHE-CONTROL: NO-CACHE or PRAGMA: NO-CACHE header. Response includes the CACHE-CONTROL: NO-STORE header. Response includes the EXPIRES header. Response includes the TRANSFER-ENCODING header. Response should not be cached.)
    Processing time: 158968 MIME type: text/html; charset=UTF-8
     
    Подскажите как выявить причину закрытия CAS Array' ем  соединений. Мониторинг системы через SCOM не показывает никаких ошибок.
    11 апреля 2012 г. 14:31

Ответы

  •  Проблема решена.

    Виноваты были не CAS'ы а все таки TMG. В следствии незнаю каких катаклизмов на TMG Array не собрался NLB. Оба сервера хостили общий NLB адрес, но при этом абсолютно не видели что в NLB находится втрой член. То есть вроде как в одной подсети было 2 NLB по одному члену и с  одним общим IP. В следствии чего наблюдались разрывы соединений.

    Всем спасибо за помощь.

    • Помечено в качестве ответа Sidorenko Andrey 13 апреля 2012 г. 8:54
    13 апреля 2012 г. 8:54

Все ответы

  • Добрый вечер,

    А на CAS серверах есть какие-нибудь события, касательно timeout_ов?

    Tweaking Outlook Web Access timeout options

    Time Out! for Outlook Web Access


    MCTS: Microsoft Exchange Server 2007/2010 | MCSA


    11 апреля 2012 г. 18:01
  • Не подскажите случаем где можно просмотреть данные события ? в логах IIS ничего нет.

    По поводу увеличения времени сессий через реест, то время увеличено на TMG listener. На CAS серверах ничего не менялось. Однако ключей ответственных за таймаут нет.

    11 апреля 2012 г. 20:36
  • Не подскажите случаем где можно просмотреть данные события ? в логах IIS ничего нет.


    В Application Logs, на CAS серверах когда сессия OWA отключаетcя, события какие-нибудь есть?

    MCTS: Microsoft Exchange Server 2007/2010 | MCSA

    11 апреля 2012 г. 20:45
  • В Appliction logs никаких событий нет.

    12 апреля 2012 г. 8:05
  • А если не через TMG, а локально подключаться к OWA, то сессия так же завершается через некоторое время?

    Сазонов Илья http://isazonov.wordpress.com/


    12 апреля 2012 г. 13:40
    Модератор
  • На внутреннем имени CAS Array включена встроенная проверка, соответственно пользователь полюбому переподключается.
    12 апреля 2012 г. 14:43
  • А он переподключается? В логах это видно. Мне кажется, что тут все нормально должно быть.

    Тогда если у вас TMG настроен на те же виртуальные директории, что и внутренние подключения пользователей, то проблема в настройках TMG - вероятно там стоит ограничение на длительность сессии.


    Сазонов Илья http://isazonov.wordpress.com/

    13 апреля 2012 г. 2:03
    Модератор
  •  Проблема решена.

    Виноваты были не CAS'ы а все таки TMG. В следствии незнаю каких катаклизмов на TMG Array не собрался NLB. Оба сервера хостили общий NLB адрес, но при этом абсолютно не видели что в NLB находится втрой член. То есть вроде как в одной подсети было 2 NLB по одному члену и с  одним общим IP. В следствии чего наблюдались разрывы соединений.

    Всем спасибо за помощь.

    • Помечено в качестве ответа Sidorenko Andrey 13 апреля 2012 г. 8:54
    13 апреля 2012 г. 8:54