четверг, 14 мая 2015 г.

Виды федераций (federation) сервера Microsoft Lync

1. Динамическая федерация (dynamic federation) - если у вас и вашего абонента сервер Lync развернут и опубликован правильно, есть все необходимые записи в DNS, SSL сертификаты доверенные для обеих сторон, включен режим динамического обнаружения партнерских организаций (по умолчанию да) и имя fqdn вашего edge сервера совпадает с вашей почтой, то федерация будет установлена автоматически. Достаточно просто в клиенте добавить человека по его e-mail и можно общаться.
У этой схемы есть правда ряд ограничений, но в большинстве случаев вы с ними не столкнетесь.
 
2. Улучшенная федерация (enhanced federation) - в этом случае администратору придется явно указать имя домена партнерской организации. Адрес edge по прежнему должен совпадать с доменом. Этот вид федерации снимает ограничения, присутствующие в динамической федерации.
 
3. Прямая федерация (direct federation) - это то случай когда имя домена получателя и доменное имя edge сервера совсем не совпадают. Можно указать имя домена и адрес сервера. Все плюсы улучшенной федерации присутствуют.
 
Резюмируем: Если у вас и партнера есть правлиьно развернутый Lync  - вы можете общаться - федерация построится сама!
 
Материалы для чтения с пояснениями механизмов работы:
https://technet.microsoft.com/en-us/library/gg195674(v=ocs.14).aspx https://technet.microsoft.com/en-us/library/gg425908(v=ocs.15).aspxhttps://technet.microsoft.com/en-us/library/gg398359(v=ocs.15).aspx - здесь рассказывается как оградить ваших пользователей от сообщений от федеративных адресатов, если это нужно на per user основе.
 

вторник, 2 декабря 2014 г.

Как привязать к сертификат к ключам, если к ним уже привязан другой сертификат

Ситуация:
Сотрудник создал ключевую пару и запрос на сертификат для веб-сервера IIS. Сертификат направили в во внешний удостоверяющий центр, заплатили деньги и стали ждать изготовления. Тем временем сотрудник засомневался в правильности запроса и никому не говоря, на внутреннем УЦ по этому запросу изготовил сертификат. Установил его на сервер и проверил что все корректно работает. И спокойно стал ждать прихода заказанного сертификата. Естественно, что когда пришел заказанный сертификат, установить его в систему стало невозможно. Потому что ключевая пара уже была связана с внутренним сертификатом и новый сертификат система просто устанавливала в хранилище, не связывая его ни с какими ключами. Ситуация хуже не придумаешь, деньги заплачены, сертификат есть, а результат совсем не тот что ожидали. Казалось бы все, надо повторять все по новой, но почему бы не попробовать?

Задача: разорвать существующую связь между закрытым ключом и сертификатом. И связать этот закрытый ключ с новым сертификатом.

Решение: решение как это не удивительно оказалось очень простым и основано на особенности Windows, сохранять закрытые ключи сертификатов. Если вы оказались в подобной ситуации, то алгоритм действий следующий:
1. Я сделали экспорт сертификата и закрытого ключа на сторонний сервер (только для того чтобы не повредить рабочую систему).
2. Установил на нем pfx контейнер с неправильным сертификатом в системе.
3. Удалил неправильный сертификат. Самый важный нюанс в том, что при этом закрытый ключ НЕ УДАЛЯЕТСЯ. Удаляется только сертификат.
4. Дальше установил правильный сертификат. Он естественно не получил связки с закрытым ключом. Скопировал серийный номер сертификата.
5. Дальше с помощью команды
certutil -repairstore My "серийный номер правильного сертификата без пробелов"

восстановил связь закрытого ключа  и сертификата.
6. Вуаля - наш новый сертификат и закрытый ключ связаны! И можно снова пользоваться.


Дополнительная информация, которая может пригодится в подобных ситуациях:
1. Machine Certificate Key File Artifacts

2. How to assign a private key to a new certificate after you use the Certificates snap-in to delete the original certificate in Internet Information Services


P.S. Это полезный момент, но стоит серьезно подумать о дополнительных мероприятиях по зачистке ключей, при необходимости.

понедельник, 24 ноября 2014 г.

sketchUcation

Весьма полезный ресурс по SketchUp.
Помимо большого количества обучающих материалов и примеров, содержит постоянно обновляемую и наверное самое большую базу дополнительных модулей для Sketchup. Не знаю кому как, а я пользуюсь ей чаще чем родным Extension Warehouse.
Их собственный модуль Plugin Store позволяет очень удобно работать со всей базой доп. модулей, включая создание своих наборов модулей их автоматическую установку, обновление и прочее.



Вышел, новый Sketchup 2015

После продажи проекта Sketchup компании Timble, были опасения, что развитие продукта или пойдет другим путем или постепенно прекратится. Однако этот тот самый случай, когда опасения не оправдались.
Недавно вышел новый Sketchup 2015, на мой вкус самое интересное в нем это 64 битная версия, что позволяет ему работать с существенно большими моделями. Полный список изменений можно найти здесь.

четверг, 16 января 2014 г.

Exchange 2003 - SMTP коннекторы - создание резервного маршрута отправки сообщений

Часто в больших организациях встречается задача организовать доставку почтовых сообщений между серверами на разных территориальных площадках. Обычно в этом случае настраивают отправку сообщений через внутреннюю сеть по каналам передачи данных, явно указывая ip адрес почтового сервера получателя либо с использованием DNS. Для этого стандартно создают smtp-коннектор с указанием конкретного адресного пространства.