Блог Ярослава Никифорова

Кросспост на рабочий блог – http://blogs.lankey.ru/2009/11/07/ustanovka-razresheniya-video-v-microsoft-office-communicator/

Мы знаем, что для того, чтобы определить максимальное качество видео, разрешенное участникам видеозвонков в Office Communications Server, нужно задать параметр на закладке Video в настройках сервера Front-End.

Но, кроме этого, ограничение на максимальное качество видеокартинки задается и на клиенте – ключом реестра.

Вообще Office Communicator имеет такую интересную особенность, что в нем невозможно принудительно задать использование определенного видеоразрешения – можно лишь ограничить его сверху, или «порекомендовать», выбрав большой или маленький размер видео в окне звонка. И даже в таком случае, качество видео будет варьироваться прямо по ходу разговора, адаптируясь к скорости сети и мощности процессора.

За задание максимально разрешенного размера видеокартинки на клиенте ответственна ветка реестра HKEY_CURRENT_USER\Software\Microsoft\RTC\Quality, а именно – два находящихся в ней ключа типа DWORD – MaxAllowedSendVideoSize, и MaxAllowedReceiveVideoSize. Как следует из названия, первый ключ ограничивает максимальное качество отправляемой удаленному абоненту видеокартинки, второй ключ – максимальное качество принимаемой от удаленного абонента видеокартинки. Эксперименты показали, что ключи эти могут принимать следующие значения:

Кстати, по умолчанию этих ключей, да и всей ветки, в реестре нет – нужно ее создать. После задания этих ключей необходимо перезапустить Communicator.

Повторюсь – эти ключи не задают точный формат видео – задается лишь максимально разрешенный к использованию. Реальное качество картинки может меняться в течение разговора в зависимости от скорости сети и мощности процессора. Ну и конечно, вышеуказанные ключи влияют только на качество видеозвонка один на один – при конференции с тремя и более участниками качество видео всегда CIF (352×288).

Эксперименты показали, что видеозвонок в HD-качестве очень неплохо так загружает процессор компьютера – например, Core2 Duo 3,06 GHz в течение HD-звонка почти все время загружен на 80-85%.

Кросспост на рабочий блог – http://blogs.lankey.ru/2009/10/17/integracia-ocs-2007-r2-i-google-talk/.

Известно, что пользователи Office Communications Server 2007 R2, используя Office Communicator, могут общаться не только друг с другом, но и с клиентами других систем обмена сообщениями – AOL (и официальным ICQ), MSN Live Messenger, Yahoo – этот процесс называется федерация (federation). Пользователи видят таких клиентов в своем списке контактов, видят их состояние присутствия (так же, как и федеративные пользователи видят их состояние), и могут обмениваться текстовыми сообщениями.

Теперь количество интегрируемых с OCS систем увеличилось. Первого октября команда разработчиков Office Communications Server выпустила бесплатное дополнение для OCS 2007 R2 – XMPP Gateway, сервер для федерации с системами, работающими по протоколу Jabber – а это, например, Google Talk, или известный в России QIP.

Сервер XMPP Gateway устанавливается в сети периметра – той же самой, где находится сервер Edge. Сосуществовать с другими ролями OCS эта роль не может – для нее нужен отдельный сервер (или виртуальная машина). И, несмотря на то, что роль называется Gateway – она требует для работы лишь один сетевой интерфейс. Главное – чтобы XMPP Gateway мог связаться с сервером Edge по TCP-порту 5061, и с другими Jabber-серверами в Интернете по TCP-порту 5269. Второго мы можем добиться, например опубликовав порт 5269 на нашем внешнем firewall.

Обязательное требование к серверу XMPP Gateway – что он не должен быть членом домена, в котором развернут Office Communications Server. Рекомендуется, чтобы этот сервер просто принадлежал какой-либо рабочей группе.

Давайте попробуем развернуть эту роль и на практике посмотреть, как же можно связать пользователей Communicator и Google Talk:

[Читать целиком...]

Кросспост с рабочего блога – http://blogs.lankey.ru/2009/10/15/posle-obnovleniya-windows-ne-zapuskaetsya-ocs/.

14 октября была выпущена очередная порция критических обновлений операционных систем от Microsoft. Но после их установки на серверы Office Communications Server или Live Communications Server службы OCS/LCS не запускаются.

Проблема в обновлении KB974571 – «MS09-056: Vulnerabilities in CryptoAPI could allow spoofing». После установки этого обновления службы Front-End, Access Edge не запустятся.

Например, для Office Communications Server 2007 R2 в журнале событий появляются записи:

Event Type: Error
Event Source: OCS Server
Task Category: (1000)
Event ID: 12290
Description:
The evaluation period for Microsoft Office Communications Server 2007 R2 has expired. Please upgrade from the evaluation version to the full released version of the product.



Event Type: Error
Event Source: OCS Server
Task Category: (1000)
Event ID: 12299
Description:
The service is shutting down due to an internal error.
Error Code: C3E93C23 (SIPPROXY_E_INVALID_INSTALLATION_DATA)
Resolution:
Check the previous event log entries and resolve them. Restart the server. If the problem persists contact product support.


Решение: если вы еще не разворачивали обновления – не устанавливайте обновление KB974571. Если уже установили – деинсталлируйте это обновление.

Поскольку данное обновление имеет статус «Критическое» – его установка в дальнейшем крайне желательна. Ожидаем разрешения проблемы и свежего обновления от Microsoft.

Кросспост на рабочий блог – http://blogs.lankey.ru/2009/09/03/udalenie-staryx-rezervnyx-kopii-v-data-protection-manager-2007/

Все мы знаем продукт для резервного копирования данных от Microsoft – System Center Data Protection Manager 2007. Его основная задача – выполнять резервные копии и складировать их на подключенные к серверу жесткие диски. В дальнейшем для долговременного хранения данные могут быть перенесены на ленты, но основным местом хранения является жесткий диск. При создании группы хранения DPM сам разбивает выделенный ему диск на разделы, в зависимости от предполагаемого им размера резервных копий и частоты копирования.

Естественно, при создании группы защиты DPM спрашивает, каков срок хранения резервных копий для восстановления – recovery points. И, само собой, по истечении этого срока он должен удалять старые копии, чтобы на их место сохранять новые.

Но мы столкнулись с ситуацией, что старые резервные копии DPM не удаляет. Они так и копятся на диске – и, рано или поздно, наступает время, когда места под новую резервную копию уже не хватает, и DPM вываливается с ошибкой «Recovery Point Volume threshold exceeded».

[Читать целиком...]

Кросспост на рабочий блог – http://blogs.lankey.ru/2009/08/18/belye-spiski-v-exchange-2007/

Известно, что добавить адрес в черный список content-filtering’а Exchange можно через графическую консоль – пункты Sender Filtering и Recipient Filtering. А вот добавить запись в белый список через графическую консоль нельзя – можно только через PowerShell. За это отвечает команда Set-ContentFilterConfig.

При этом запись добавляется интересно – если просто выполнить эту команду, указав один нужный нам адрес – то текущий список адресов будет очищен, и указанный нами адрес в него занесется один. Следовательно, нам нужно: получить существующий список «белых» адресов, пополнить этот список нужным адресом, и загрузить его обратно в Exchange.

Решение для удобства можно оформить в виде скрипта, назвав его, например, add-wlemail.ps1:

Теперь можно запускать этот скрипт, указав в качестве параметра нужный нам адрес: .\add-wlemail.ps1 some-email@some-domain.ru

Этот скрипт занесет указанный нами e-mail в белый список и выведет на экран результирующий белый список адресов.

А вот другой скрипт – для занесения в белый список целых доменов – add-wldomain.ps1:

PS: Конечно, для того, чтобы эти скрипты работали, нужно либо снабдить их цифровой подписью, либо разрешить выполнение неподписанных скриптов командой Set-ExecutionPolicy Unrestricted.

Кросспост на рабочий блог – http://blogs.lankey.ru/2009/08/27/client-office-communications-server-dlya-iphone/

Случилось интересное – полку клиентов для Office Communications Server прибыло! Появился клиент для Apple iPhone, зовущийся iDialog, уже доступный для покупки через AppStore.

iDialog требует для работы iPhone или iPod с прошивкой 2.0 или выше. Поддерживается работа с OCS 2007 и OCS 2007 R2, как с корпоративной, так и с hosted-инфраструктурой. Взаимодействие клиента и серверов OCS происходит через роль Communicator Web Access Server.
[Читать целиком...]

В компании «ЛанКей», в которой я работаю, мы открыли наш рабочий блог: http://blogs.lankey.ru/, на котором некоторые сообщения пишу и я. Блог посвящен всему, чем занимается компания: Office Communications Server, Exchange, Windows, SharePoint, VMWare, Cisco, :)

Так что заходите!

Перевод статьи Outbound PSTN Calling from an OCS Response Group

[Читать целиком...]

Господа плагиаторы!

Если уж тырите текст с сайта – то либо ставьте ссылку на него, либо вычитывайте и убирайте все упоминания, не относящиеся к вашей компании.

Только что столкнулся с любопытной вещью: отказалась пускаться служба Exchange Unified Messaging, мотивируя это тем, что не может открыть endpoint для входящих SIP-соединений.

При просмотре netstat’ом выяснилось интересная вещь: запустившаяся ранее служба Exchange Information Store активно общалась с контроллером домена по LDAP, и открывала много новых исходящих TCP-соединений. А при открытии TCP-соединения драйвер выбирает случайный исходящий порт с номером больше 1024. И так получилось, что это случайно выбранное число и оказалось 5061.

Соответственно, при попытке открыть уже слушающее соединение на том же порту драйвер TCP/IP дал службе отлуп.

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

Пришлось тормозить службу Information Store, чтобы она «отпустила» порт 5061, запускать Unified Messaging, чтобы он взял под себя этот порт, и опять запускать Information Store, чтобы теперь уже ее активные «разговоры» с LDAP-сервером не заняли так нужный нам порт 5061.

Вообще, любопытная вещь. Она вытекает из самой реализации протокола TCP – когда протокол только создавался, для входящих соединений использовались как правило порты с номером меньше 1024, а порты выше 1024 как раз использовались в основном либо для исходящих соединений. Но сейчас получается, что очень много номеров выше 1024 тоже стали Well-known ports – они закреплены за определенными службами. А вот механизм выдачи порта для исходящего соединения остался тем же – любой в данный момент не занятый порт с номером больше 1024. И никто не знает, может этот порт через минуту понадобится другой службе уже как входящий.

UPD: нашел уже в TechNet’е – есть ключи реестра, позволяющие ограничить диапазон портов для исходящих соединений.