Быстрое обновление OAB в Exchange 2010


Иногда возникает необходимость быстро перестроить автономную адресную книгу. Выполнить это можно следующей последовательностью действий:

  1. Обновить OAB командой EMS:
    Update-OfflineAddressbook «offline address book»
    (либо Get-OfflineAddressbook | Update-OfflineAddressbook)
  2. В командной строке перезапустить сервис  Microsoft Exchange System Attendant на сервере почтовых ящиков, который назначен для генерации OAB:
    net stop MSExchangeSA & net start MSExchangeSA
  3. Выполнить в EMS команду
    Update-FileDistributionService  CASServerName
    (либо Get-ClientAccessServer | Update-FileDistributionService )
    или в командной строке перезапустить Microsoft Exchange File Distribution на каждом CAS  сервере
    net stop MSExchangeFDS & net start MSExchangeFDS.

Теперь остается в Outlook загрузить обновления адресной книги. Для Outlook 2010 на ленте выбираем Send/Receive, затем Send/Receive Groups и Download Address Book.

Конечно не следует этим злоупотреблять, особенно при больших нагрузках на серверы Exchange.

Полезные ссылки:

  1. Move the Offline Address Book Generation Process to Another Server
  2. Update the Offline Address Book

Быстрое обновление адресной книги Lync


При настройке Lync Server 2010 нет времени сутками ждать обновления автономной адресной книги на клиенте: внес изменения – сразу проверил. Ниже описано как этого добиться. (Конечно не следует это делать в рабочей среде и на всех клиентах!)

Есть три шага:

  1. Загрузка сведений о пользователях из AD в SQL базы Lync
  2. Перестроение файлов автономной адресной книги Lync
  3. Загрузка изменений автономной адресной книги Lync или ее полной версии на клиент

Шаг 1 вполняется сервером Lync автоматически каждую минуту – значение по умолчанию параметра ReplicationCycleInterval.

Посмотреть можно командлетом Get-CsUserReplicatorConfiguration, а установить Set-CsUserReplicatorConfiguration.

Если вы изменили значение по умолчанию, например, на час, то вам придется выполнить командлет Update-CsUserDatabase (в версии 2007/R2 мы делали abserver.exe –RegenUR), чтобы загрузить изменения, которые вы внесли в контакты пользователей.

Шаг 2 также выполняется сервером Lync автоматически – значение по умолчанию: раз в сутки в 1.30 ночи.

Это значение параметра RunTimeOfDay. Посмотреть параметр можно командлетом Get-CsAddressBookConfiguration, а установить Set-CsAddressBookConfiguration.

Сам процесс полного перестроения файлов автономной адресной книги выполняется командлетом Update-CsAddressBook (в версии 2007/R2 мы делали abserver.exe –SyncNow).

Правда сразу файлы не перестраиваются: командлет выставляет только флаг, который проверяется процессом abserver раз в 5 минут – значение по умолчанию.  Это значение параметра SynchronizePollingInterval. (В документации этот процесс не прописан явно!) Через 5 минут в EventLog можно будет увидеть сообщения о перестройке адресной книги. (Event ID 21005,21010,21056).

Шаг 3 выполняется клиентом Lync аналогично Communicator 2007/R2: автономная адресная книга (целиком или только обновления) загружается после старта клиента со случайным смешением от 0 до 60 минут раз в сутки. Нам нужно выставить ключ реестра GalDownloadInitialDelay (HKEY_CURRENT_USER\Software\Policies\Microsoft\Communicator)равным DWORD = 0, чтобы загрузка выполнилась сразу после старта клиента.

Либо можно удалить ранее загруженные файлы автономной адресной книги. Они расположены в профиле пользователя по пути:

%userprofile%\AppData\Local\Microsoft\Communicator\<имя профиля>

(для XP путь %userprofile%\Local Settings\Application Data\Microsoft\Communicator\<имя профиля>)

Заключение: остается сказать – верните все измененные параметры на место после окончания отладки! J

Опыт миграции на Sep 12.1


Хочу поделиться опытом миграции на SEP 12.1.

Так как документации мы не читаем J, а разработчики нам отвечают нам тем же: не пишут ее (да есть такое у Symantec – в документации одно, а на деле другое), то грабли собираются косяками.

И так после установки сервера SEPM 12.1 сразу возникла проблема с пустыми страницами Home, Monitors и Reports. «Ха!», – глубокомысленно подумал я и решил, что надо подкрутить те же параметры, что и раньше Консоль SEP 11: «unable to communicate with the reporting component». Но не тут-то было: выяснилось, что в Sep 12.1 больше не используется IIS! Вместо него Apache и все тот же PHP. Видимо разработчики решили таким образом обеспечить большую кроссплатформенность. Не знаю насколько они в этом приуспели, но новые глюки потребителям добавили.

После плясок с бубном выяснилось, что в этой версии не работает Windows аутентификация с SQL сервером! После перехода на SQL аутентификацию консоль SEPM 12.1 запустилась в нормальном режиме.

Далее после настройки и запуска LiveUpdate все время в журнале «LuAll.exe finished with return code 2». Поиск в Интернете показал, что проблема с прокси. Оказалось, что в текущей версии не работает Windows аутентификация с ISA/TMG! Как только переключил настройки и сделал анонимный выход в Интернет для сервера SEPM, пошла закачка обновлений.

Во время всех этих плясок выяснилось, что SEMP теперь требует установки лицензии и последующей ее активации! Иначе работает в триальном режиме 60 дней. При решении выше описанных проблем у меня было подозрение, что консоль не работает без активации. Но выяснилось, что это не так. Выяснилось ценой одной активированной лицензии J.

Но это еще не всё! Т.к. я размещал базу на MS SQL 2008 R2, то решил поставить последню версию клиента SQL на сервер SEPM – да, такой клиент необходим, если вы решили разместить базу на MS SQL. Тут оказалось, что если раньше можно взять в дистрибутиве MS SQL или на сайте Microsoft небольшой автономный пакет и установить его, то в этом случае фокус неудался: помимо клиента для работы SEMP 12.1 нужны дополнительные утилиты из дистрибутива MS SQL (в частности bcp.exe). Поэтому пришлось запускать установку MS SQL и выбирать для установки два компонента: Connectivity Tools и Management Tools в полном объеме.

Но и это еще не все! Фаэрвол. Ну это не новое, но если переезжать с Windows Server 2003 на Windows Server 2008 R2, то не забудьте про него J Вот описание портов http://www.symantec.com/connect/forums/sep-port-clarification

Но и это еще не все мои злоключения J Пока я пытался побороть клюки SEPM, уже шел процесс миграции клиентов по второму методу (репликация) статьи http://www.symantec.com/business/support/index?page=content&id=TECH104389 Тут я упустил разницу портов: новая версия использзует порт 8014, а старая порт 80. Часть клиентов успешно мигрировала на новый сервер. Потом когда мне потребовалось вернуть их обратно, чтобы переустановить новый сервер, был изменен приоритет серверов на обратный и … клиенты заблокировались! – они пытались поблючиться на порт 8014 к старому серверу вместо порта 80. И не туды и не сюды… Переустановка клиентов? Ужас! Нашел статью http://www.symantec.com/business/support/index?page=content&id=TECH92556 Первый метод переустановки не сработал, второй требовал обращения в тех.поддержку. Нашел другую статью http://www.symantec.com/business/support/index?page=content&id=TECH90761 Хоть и ручной метод, но все же быстрее чем полная переустановка. И опять облом: при нажатии на кнопку Импорт клиенты сказали, что функция заблокирована.

Что ж, база знаний Symantec выдала еще одну статью (на самом деле этих статей там на одну и ту же тему очень много – если бы такая база знаний была у Microsoft, то ее бы просто смешали с землей!) http://service1.symantec.com/SUPPORT/ent-security.nsf/2326c6a13572aeb788257363002b62aa/13669c4f8319b89e882574e5004e7328?OpenDocument Отлично! Берем утилиту SylinkDrop.exe, берем SyLink.xml со старого сервера, как описано в статье, обновляем клиента – не сработало L Странно. Находим еще одну статью http://www.symantec.com/business/support/index?page=content&id=TECH157585 Оказывается местоположение файла SyLink.xml в версии 12.1 изменилось! Берем утилиту SylinkDrop.exe старой версии (версии клиентов) – Ура! Клиент похватил новые настройки, подключился к старому серверу и закачал обновления.

Теперь осталось выполнить эту операцию для всех пострадавших клиентов. К счастью это уже поле не Symantec: выкладываем SylinkDrop.exe и SyLink.xml на шару, делаем политику с логон скриптом (у SylinkDrop.exe есть ключи запуска!) – после перезагрузки компьютеров они успешно подхватили настройки, подключились к старому серверу SEPM и обновились.

Мне осталось только заново установить и настроить сервер SEPM 12.1 с учетом накопленного опыта и снова мигрировать на него клиентов.

Вместо заключения

Я работал с антивирусом от Symantec уже много лет. Версия SAV 8, а потом версия SAV 9, поражали своей стабильностью, скоростью работы и простотой. Версия 10 подозрительно отяжалела, но работала сносно.

Когда же мы обновились до версии 11, пользователи взвыли: компьютеры стали медленно грузиться и медленно работать. Выкручивание параметров и настроек не сильно помогало. Надежда на обновления не оправдалась: SP, MR и т.п. выходили регулярно, но сути не меняли – антивирус пожирал львиную долю ресурсов компьютера. Более того сами обновления выходили с такими багами, что тут же перевыпускась заново! К тому же очередной MR мог оказаться несовместимым с предыдущими версиями! – а это приводило к проблемам автоматической установки обновлений: после установки такого обновления приходилось сносить клиента и ставить его с нуля.

Да… что-то сломалось несколько лет к команде SEP.

Честно говоря, это уже достало. И я планировал перейти на Forefront. Но анонс версии SEP 12.1 внушил надежду, что ситуация исправится: Symantec обещал, что клиент станет намного умнее и шустрее. Сейчас буду наблюдать за пользователями: если жалобы на тормознутость компьютеров продолжатся, то придется вплотную заняться тестированием Forefront. Кстати на Exchange сервер он показал себя достойной заменой Symantec – работает шустро и стабильно, а главное качественно фильтрует спам. А вот Symantec пока надежд не оправдывает…

Если у вас есть полезный опыт – Welcome! – пишите в комментариях или оставляйте ссылки на свои статьи.