Тони Редмонд в Windows IT Pro затронул хорошую тему ограничений для Outlook в режиме кеширования. В режиме кеширования Outlook работает с локальным ost-файлом, который периодически синхронизируется с почтовым ящиком на сервере Exchange. Это накладывает некоторые ограничения на рабочее окружение.

  1. Не смотря на то, что поддерживаемый размер ost-файла составляет 50Гб, если его фактический размер превышает уже несколько гигабайт и находится он не на SSD-диске, то работать в Outlook будет крайне некомфортно. То есть, если мы имеем большой почтовый ящик, синхронизируем в ost-файл больше нескольких гигабайт данных, имеет смысл размещать ost-файл на SSD-диске.
  2. Если в конкретной папке в почтовом ящике находится большее 100 000 объектов и все эти объекты синхронизировались в ost-файл, это будет сказываться на производительности Outlook в худшую сторону. Так что лучше не копить в рабочих папках больше 100 000 объектов.
  3. Если в конкретном почтовом ящике находится большее 500 папок, то это так же будет сказываться на производительности Outlook в худшую сторону. Стоит ограничивать себя при создании папок в почтовом ящике.
  4. Начиная с Outlook 2010 в режиме кеширования в ost-файл так же попадают объекты из дополнительных почтовых ящиков, которые подключены в почтовом профиле вручную либо через функцию автоподключения. Эти объекты так же участвуют в лимитах, указанных в пп.2-3.

Снижение производительности может выглядеть как:

  • задержка в обновлении содержимого папок внутри почтового ящика (выглядит как задержка в доставке писем)
  • невозможность отобразить содержимое определённых папок внутри почтового ящика
  • различные ошибки при синхронизации почтового ящика
  • задержка при запуске Outlook

Всё вышеописанное касается всех современных клиентов Outlook: 2010, 2013 и 2016.

Интересные ссылки:
The downside of being a filer and other reasons why Outlook’s cached limits might bite you
Outlook performance issues when there are too many items or folders in a Cached mode .ost or .pst file folder
By default, shared mail folders are downloaded in Cached mode in Outlook 2010 and later versions
Performance problems when you try to access folders in a secondary mailbox in Outlook

Очередная встреча UC² под номером 12 состоится 29 марта во вторник, как обычно с 18-00 до 21-00. Встреча будет проходить в Технологическом Центре Microsoft (MTC) и транслироваться средствами Skype for Business Online. А вот кто будет выступать:

  1. Журавлев Александр (UC Lab), “Рабочие нагрузки Skype for Business 2015”
    В докладе будут рассмотрены темы:
    – маршрутизация трафика Skype for Business 2015
    – используемы порты и протоколы Skype for Business 2015
    – моделирование и симуляция трафика Skype for Business 2015. решения Microsoft
    – моделирование и симуляция трафика Skype for Business 2015. решения IXIA (совместно с Владимиром Назаренко)
  2. Николай Муравлянников (Microsoft), “Гибридный голос в Skype For Business”
    Доклад будет посвящен Облачной АТС от Майкрософт с упором на гибридный голос. Во время первой половины сессии мы  ознакомимся с  вариантами Облачной АТС от Майкрософт, рассмотрим сценарии применения различных опций в зависимости от потребностей заказчика. Вторая часть доклада будет посвящена подключению локальной телефонии к Облачной АТС, мы рассмотрим в деталях подключение через существующий пул серверов Skype For Business/Lync  и с помощью Skype For Business Cloud Connector Edition (новая редакция Skype For Business).

Регистрация на встречу как обычно тут.

Обновление. Запись доступна по ссылке:
UC². Встреча №12. Николай Муравлянников. Гибридный голос в SFB

Цели мониторинга

Managed Availability framework вырос из опыта мониторинга облачного решения Exchange Online средствами пакета управления для Exchange 2010 в OpsMgr. Опыт использования пакета управления показал, что он избыточен, из более чем тысячи алертов полезными в Exchange Online оказались только 150. Остальные были в итоге отключены.

Из облачного решения так же растёт необходимость мониторинга доступности со стороны конечных потребителей сервиса. С точки зрения потребителя сервис не доступен только тогда, когда он не может его использовать. Остальные случаи ему не интересны. То есть в первую очередь мы должны наблюдать доступность сервиса со стороны клиента. Внутренние поломки, не влияющие на доступность клиентов к сервису менее интересны и не так важны.

Из последнего важное следствие. Все поломки, ведущие к недоступности сервиса для клиента, необходимо исправлять максимально быстро, желательно автоматически, без привлечения операторов системы. Поэтому система мониторинга должна быть направлена на восстановление доступности сервиса и только потом на выяснение причин недоступности.

Поэтому Managed Availability – решение, позволяющее автоматически восстанавливать части системы после сбоев, а не обычная система мониторинга, которая, обычно, завязана на действия оператора. Кроме этого MA тесно интегрировано с механизмом обеспечения высокой доступности Exchange.

Managed Availability измеряет три ключевых аспекта системы – доступность, подключения пользователей (обычно, в виде измерения задержек ответа от сервисов, обеспечивающих клиентские подключения) и возникающие ошибки.

Самое важное отличие от предыдущих систем – Managed Availability не нацелен на выявление ключевой причины сбоя. Основная задача – максимально снизить недоступность сервиса для клиента. То есть получить ответы на следующие вопросы:

  • Availability: Может ли пользователь подключиться к сервису?
  • Latency: Насколько успешно пользователь работает с сервисом?
  • Errors: Способен ли пользователь выполнить те действия, который он хочет выполнить?

Continue Reading »