Быстрое получение сертификата


Недавно при настройке целой цепочки серверов для удаленного доступа пришлось по многу раз генерировать сертификаты с разными параметрами, пока все не заработало как надо. Не все возможно, как оказалось, сделать через визарды и оснастку управления сертификатами. К тому же одно и то же действие лучше автоматизировать.

Проблемы были решены с помощью стандартной утилиты командной строки certreq.exe (ее параметры) и командного файла:

·         Сначала запускаем оснастку mmc

·         Добавляем Certificates для Local Computer

·         Открываем раздел Local Computer\Certificate Enrollment Requests

·         Если там есть необработанные запросы, то удаляем их – это важно!

·         Открываем раздел Local Computer\Personal

·         Чистим его от старых и не нужных сертификатов

·         Открываем командную строку и последовательно выполняем команды (можно из командного файла):

certreq -new c:\tsg.inf c:\tsg.req

certreq -submit c:\tsg.req c:\tsg.cer

certreq -accept -machine c:\tsg.cer

После этого открываем оснастку управления нужной службы и выполняем привязку нашего сертификата стандартным образом.

Особо обращаю внимание, что надо чистить Local Computer\Certificate Enrollment Requests от старых запросов. Иначе сертификаты будут импортироваться, но без ключей!

Не всегда центр сертификатов бывает доступен. Например, когда сервер в DMZ или просто закрыт фаэрволом может даже собственным. Ничего страшного: запросы можно делать с любого другого компьютера. Главное указать Exportable = TRUE. Это даст нам возможность экспортировать сертификат вместе с ключом в файл .pfx, перенести его на целевой компьютер и импортировать. При импорте на целевом компьютере можно указать, что ключ не подлежит экспорту и тем самым уменьшить вероятность его компроментации.

Содержимое файла tsg.inf  создано на основе статьи KB321051:

[Version]

Signature=»$Windows NT$

[NewRequest]

Subject = «CN=server.domainname,OU=цех,O=фирма,L=город,S=регион,C=RU» ; must be the FQDN

;EncipherOnly = FALSE

Exportable = TRUE ; TRUE = Private key is exportable

KeyLength = 2048 ; Common key sizes: 512, 1024, 2048,

; 4096, 8192, 16384

KeySpec = 1 ; Key Exchange

;KeyUsage = 0xA0 ; Digital Signature, Key Encipherment

MachineKeySet = True

ProviderName = «Microsoft RSA SChannel Cryptographic Provider»

ProviderType = 12

RequestType = CMC

; Omit entire section if CA is an enterprise CA

[EnhancedKeyUsageExtension]

OID=1.3.6.1.5.5.7.3.1 ; Server Authentication

[RequestAttributes]

CertificateTemplate = WebServer ;Omit line if CA is a stand-alone CA

; SAN=»dns=server.domainname, dns=another.domainname»

 

Как вы можете видеть, есть закомментированная строчка для создания SAN сертификата (Subject Alternative Name) – далеко не всегда можно получить такой сертификат через визард.

Еще одно замечание про ISA 2006 SP1 и SAN сертификат. ISA 2006 SP1 полностью поддерживает SAN сертификаты. Но есть одна тонкость. Когда я сгенерировал сертификат как:

Subject = «CN=external.domainname»

SAN=»dns=internal.domainname”

Сервер ISA подхватил только имя, указанное в поле SAN! Правильно будет так:

Subject = «CN=external.domainname”

SAN=»dns= external.domainname,dns=internal.domainname”

 

Так с помощью утилиты certreq.exe мне удалось сэкономить немного своего времени. Надеюсь вам тоже. :-)

Реклама

Миграция с Exchange 2003 на Exchange 2010 – первые шаги


 

В прошлой статье Миграция с Exchange 2003 на Exchange 2010 – от сомнений к реализации я писал о том, почему пора мигрировать на Echange 2010. Теперь хочу рассказать о более конкретных вещах. О своем опыте и опыте других, с кем пришлось общаться.

Очевидное.

Многие ниже описанные вещи очевидны. Но мы чаще всего испытываем трудности именно на самых простых вещах: одна ошибка, вторая и путь обратно это уже лабиринт Минотавра. Только взгляд со стороны, чье-то мнение или опыт, помогает перешагнуть «непреодолимое» препятствие высотой в 5 см.

Первое это документация.

Качество документации мне понравилось. Она, конечно, не идеальна, но сделана добротно, хорошо структурирована, содержит практически все, что может пригодиться.

Прежде чем хоть что-то начать делать, обязательно просмотрите документацию, хотя бы бегло, чтобы понять где и что находится – потом это сэкономит вам кучу времени. Документация организована классическим для Microsoft способом:

·         Getting started

·         Planning

·         Deployment

·         Operations (такого раздела явно нет, но есть разделы с описанием настройки ролей, прав и т.п., которые собственно и образуют Operations)

·         Understanding – это подразделы в разных частях документации, название говорит само за себя: читайте, чтобы понять суть вещей. Именно из-за этих разделов стоит предварительно пролистать всю документацию.

Каждый раздел обязательно содержит что-то полезное, и этого не будет в других разделах. Поэтому не игнорируйте своим вниманием «неважные» разделы.

Подготовка.

Установка Exchange 2010 требует минимум:

·         доменконтроллеры Windows Server 2003 Standard Edition with Service Pack 1 (SP1)

·         и уровень леса Windows Server 2003 forest functionality mode .

Таким образом, установка возможна в достаточно старом домене – нет обязательного требования домена на Windows Server 2008 и обновления схемы до уровня 2008. Если у вас задача только мигрировать на Exchange 2010, то не надо беспокоиться: когда придет время вы спокойно мигрируете свои домен-контроллеры и схему на новую версию – Exchange 2010 будет работать.

В моем случае процесс шел практически одновременно. Я сначала обновил схему до уровня 2008. Проверил по логам, что все прошло гладко. Поднял один домен-контроллер 2008 R2. Потом была миграция на Excahnge 2010. А уже после полный переход на домен-контроллеры 2008 R2. Даже при таком «непоследовательном» подходе все прошло без катастроф.

Виртуализация.

Найти раздел по виртуализации непросто: Exchange 2010 System Requirements. Разобраться в нем нелегко: написал он несколько путано, но понять можно.

Виртуализировать можно все кроме роли Unified Messaging. Действительно у меня все роли легко поставились на виртуалки и вполне хорошо себя на них чувствуют. С учетом того, что Exchange 2010 предъявляет минимальные требования к дискам системы хранения, можно без опаски использовать сетевые хранилища iSCSI. Если же у вас выделенный сервер, то помните – официально поддерживаются SATA диски. При любой конфигурации можно не тратиться на дорогостоящие варианты хранилища. Даже не верится, что в Exchange 2010 настолько оптимизировали работу с хранилищами, но это действительно так. Самое интересное, что это сильно упрощает нам жизнь, когда приходится проектировать хранилище. Это мы ясно увидим ниже при расчете размера хранилища.

Особо надо отметить, что при использовании DAG на MailBox серверах нельзя использовать никакие «быстрые миграции» ни на Hyper-V (LM), ни на VMVare (HA):

1.       Answering Exchange Virtualization Questions and Addressing Misleading VMware Guidance

2.       http://technet.microsoft.com/en-us/library/aa996719.aspx

Это не только лишние затраты на лицензии VMVare, но и риск краха всей почтовой системы, т.к. конфигурация не тестировалась и не поддерживается Microsoft. Удивляет подход VMWare: они так обеднели, что готовы продавать бесполезное?

Также обратите внимание на расчет виртуальных процессоров. На одно физическое ядро должно приходиться не больше двух виртуальных процессоров распределенных в виртуальные машины с Exchange 2010. Почему так? Потому что тут кроется фундаментальный обман всех виртуальных платформ: при большом количестве виртуальных сущностей, даже если совокупная нагрузка вроде бы маленькая, но работает медленно – чудес не бывает, и тут издержки примерно такие же, как при многозадачности. Далее. В случае с Hyper-V хостовая система должна иметь достаточно виртуальных процессоров, чтобы обслуживать и себя, и все виртуальные машины с Exchange 2010. Примерное соотношение такое же 2 к 1. К сожалению, как мы видели, VMVare подходит неадекватно к виртуализации Exchange 2010, поэтому нет объективной информации о расчетах для этой платформы. И поэтому я рекомендую опираться на расчеты для Hyper-V и использовать при этом консервативный подход – прелести виртуализации это хорошо, но из одного физического процессора сделать два эквивалентных по мощности виртуальных и преодолеть все законы сохранения ей не под силу.

Еще один момент. Виртуальные машины с Exchange 2010 могут иметь много виртуальной памяти и, соответственно, большой файл свопинга. Когда рассчитываете размер хранилища, в котором будут храниться образы виртуальных машин (а файлы свопинга обычно лежат рядом), то не забудьте учесть эти расходы.

Объем системного диска виртуальный машины мной был выбран размером в 60 Гб. Расчет простой. Система, page-файл, дополнительные программное обеспечение и сам Exchange 2010 занимают около 20-25 Гб. Еще 15-20 Гб на системные расходы: установка обновлений, системные логи и т.п. Еще 20 Гб рабочее место Exchange 2010: очереди, логи и т.п.

Аппаратные ресурсы.

В документации есть разделы по расчету оборудования. Эта как раз та часть документации, которая размещена «нелогично» и часть информации надо искать. Раздел Performance and Scalability –> Understanding Exchange Performance   содержит информацию по расчету всех ролей, кроме MailBox. Для него персональный раздел: Planning and Deployment –>  Planning for Exchange 2010 – > Mailbox Server Storage Design

Там так все разжевано с примерами, что вопросов не должно возникнуть.

При расчетах учтите, что вам придется ставить антивирус, который потребует для себя процессорных ресурсов и оперативной памяти. При современных тенденциях развития антивирусы чрезвычайно прожорливы. Для расчета можно оценочно ориентироваться на требования Forefront Capacity planning for Forefront Protection 2010 for Exchange Server (Там же инструмент для расчетов).

После первых прикидок мне показалось, что расчеты имеют смысл только для больших инсталляций. Но потом понял, что их надо делать в любом случае: для меня было полезно узнать, сколько ресурсов платформы виртуализации скушает моя инсталяция Exchange.

Хранилище для почтовых ящиков

Расчеты дело хорошее, но рассчитывать можно исходя из разных предпосылок и разных критериев – получим разные результаты. Например, у вас размер базы 50 Гб и вам надо мигрировать на Exchange 2010 – вопрос: какой размер нового хранилища сделать? Расчет даст примерно 75 Гб (Mailbox Server Storage Design).

А реально? Надо же брать размер «на вырост». Рекомендуемый максимальных размер базы 100 Гб. Путь будет так. А вот дальше… Если пользоваться официальной методикой, то рекомендуемый размер хранилища получится 135-150 Гб. Но а если мы хотим сделать DAG? Значит нужно еще одно хранилище такого же размера. Будем использовать циклическое логирование с DAG? Тогда вроде можно сделать хранилище поменьше. Но использовать циклическое логирование при миграции почтовых ящиков с Exchange 2003 слишком рискованно. Значит все-таки побольше. Но тогда потери места будут большие. Сделать поменьше? Но при работе DAG может возникнуть отказ одной базы и как следствие рост  ее текущих логов… Вот и получается Гордеев узел.  

Решение: самое неприятное это переполнение хранилища (особенно при нештатной ситуации), а раз хранилище на дешевых дисках – вот этот главный фактор решения, то его можно сделать с запасом и на вырост, и на накопление логов без опасности потратить слишком большие деньги. Если принять время жизни реализуемой конфигурации не менее трех лет и соответствующий рост базы за это время до 100 Гб, то хранилища размером в 200 Гб будет достаточно для любых ситуаций и любых манипуляций (сжатие, восстановление…) с базой.

Как видите база с типичного, для времен Exchange 2003 сервера, SCSI винчестера размером в 72 Гб, переезжает на типичный на сегодняшний день SATA винчестер размером 300 Гб, при этом последний значительно выигрывает у своего предшественника относительно затрат – удельные затраты на Exchange 2010 ниже!

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

Замечание 1. DAG это двойной расход места в хранилищах.

Замечание 2. DAG с циклическим логированием требует столько же места как при обычном логировании: если синхронизация баз в кластере нарушится, то логи начнут копиться!

Размер базы

Как уже было отмечено, рекомендуемый максимальных размер базы 100 Гб. В тоже время максимальный размер базы 2 Тб.

Почему не надо делать большую базу? Да  просто с большим файлом все операции занимают много времени: одно дело скопировать 100 Гб, а другое 1 Тб. Тоже касается операций архивирования и восстановления, сжатия и прочих. Несколько пятиминутных операций на 100 гигабайтной базе вы можете сделать в обед, а на терабайтной базе тоже самое у вас займет всю ночь! Когда рассчитываете количество и размер баз, то учитывайте количество своих бессонных ночей.

Сеть.

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

Роли

Если число пользователей Exchange невелико (100-200), то можно установить все роли на одном сервере, аппаратном или виртуальном, кроме роли UM.

Если число пользователей больше 200, то становится оправданным разделение ролей для распределения нагрузки и увеличения надежности. Рекомендую схему CA/HUB + MB, т.е. разместить роли CA и HUB на одном сервере, а MB на другом. Схема CA+HUB/MB менее удачная, т.к. транспортный сервер никогда не пишет на локальный MB – только на удаленный, чтобы обеспечить транзакционность и гарантированную доставку письма.

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

Первое с чем придется столкнуться это балансировка роли CA: в то время как несколько MB уже есть по сути распределение нагрузки, с балансировкой подключений пользователей придется потрудиться, но это уже отдельная история.

 

На этом рассуждения о подготовке закончены и дальше речь пойдет о различных ситуациях, которые возникли при миграции с Exchange 2003 на Exchange 2010, и том, как они решались.

Анти NLB в ферме терминальных серверов


Почему «Анти NLB»? Потому что хочется развеять частое заблуждение о возможностях NLB  по балансировке нагрузки и обеспечению отказоустойчивости, в частности относительно терминальной фермы серверов.

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

И так обратимся к документации. Цитата из Network Load Balancing Step-by-Step Guide:

Using NLB with Terminal Services offers the benefits of increased availability, scalability, and load-balancing performance, as well as the ability to distribute a large number of Terminal Services clients over a group of terminal servers.

Думаю без перевода понятно как все круто. Только не все так круто на самом деле.

Давайте посмотрим на конфигурацию, когда несколько терминальных серверов в ферме объединены в NLB-кластер. Чтобы привязать клиента к определенному серверу в ферме, NLB использует affinity – привязку по ip-адресу клиента или по его сети класса C. Обратите внимание – это единственный критерий! – NLB никак не контролирует загрузку сетевых интерфейсов и тем более загрузку ресурсов сервера (процессор, память). Иначе говоря, балансировка нагрузки заключается просто в законе больших чисел: чем больше инициировано подключений из большего количество мест, тем равнее сессии будут разбросаны по серверам фермы. (Но при этом существует вероятность, что на одном сервере окажутся сессии, приложения в которых съедят все ресурсы процессора, на втором окажутся сессии с приложениями, которые займут всю память, а на третьем приложения будут забивать весь сетевой канал.)

У вас есть терминальная ферма, к которой подключаются сотни и тысячи клиентов с большой частотой? Если есть, то вы тоже не будете использовать NLB – вы купите аппаратный балансировщик для такого важного ресурса!

Еще один момент – availability. NLB обеспечивает доступность? Я бы сказал наоборот. NLB в  своих настройках имеет только номер порта, но совершенно ничего не знает о сервисе, который его обеспечивает! И если этот сервис не отвечает, «упал», на одном сервере в ферме, то NLB будет, как и прежде, направлять на этот сервер новые подключения, а клиенты не смогут с ним работать и очень долго (до ручной переконфигурации NLB)! Вот если упадет весь сервер (или хотя бы у него будет недоступен физически сетевой интерфейс), то NLB это обнаружит через несколько секунд, исключит сервер из кластера и не будет направлять на него новые подключения клиентов.

Ручная переконфигурация NLB, упомянутая выше, заключается в том, что нужен механизм (скрипт), который, во-первых, диагностирует отказ сервиса (может оказать очень сложной задачей, например, подключение по RDP-порту есть,  а сессия реально не создается (черный экран)), во-вторых, исключит сервер из кластера NLB (это можно сделать с помощью WMI).

Вот так и получается, что NLB это не совсем network load balancing и не совсем cluster всему, что написано в цитате выше, дословно верить нельзя – надо осознать, что такое NLB на самом деле.

Пойдем дальше и рассмотрим конфигурацию терминальной фермы с Remote Desktop Connection Broker. Для чего же там NLB?

Цитата из документации Network Load Balancing Step-by-Step Guide:

TS Session Broker enables you to load balance sessions between terminal servers in a farm. This functionality is provided by the TS Session Broker Load Balancing feature. However, this session-based load balancing feature requires a front-end load balancing mechanism to distribute the initial connection requests to the terminal server farm. You can use a load balancing mechanism such as DNS round robin, NLB or a hardware load balancer to distribute the initial connection requests.

Ого-го! Оказывается вся необходимость в NLB заключается в том, чтобы распределять между серверами терминальной фермы первичные запросы! А что такое первичный запрос? В ответ от терминального сервера клиент должен получить указание подключиться к брокеру, а уже тот даст клиенту адрес сервера в ферме, где будет создана сессия. Нагрузка, создаваемая первичным запросом, как видно, невелика, но ответ на первичный запрос критически важен.

Как было описано выше, такую работу NLB делает, но не слишком уж надежно, и что самое плохое при падении сервиса NLB не исключает сервер из кластера (нужны внешние средства, чтобы диагностировать ситуацию и исключить сервер из кластера или восстановить сервис). Другое дело DNS round robin с коротким временем жизни записи для имени фермы: клиент, попав на мертвый сервис, через некоторое время (30 секунд) все равно переключится на другой адрес! Получается, что конфигурация с DNS round robin не только проще в настройке, но и надежнее. А если ферма большая и хорошо нагруженная, то напрашивается вариант с аппаратным балансировщиком. (Хотя прежде чем его покупать, можно рассмотреть вариант выделенного редиректора в терминальной ферме: терминального сервера, единственной задачей которого будет прием первичных запросов на подключение от клиентов. Редиректор также можно резервировать не через NLB, а DNS round robin.)

Осталось сравнить обеспечение надежности, которое реализует NLB и сам Connection Broker. Проблемы с NLB мы уже знаем. Connection Broker работает более грамотно. Он контролирует приходящие редиректы от серверов фермы и таким образом понимает, что терминальный север жив и здоров. Если редиректов нет более 60 секунд (параметр TimeServerSilentBeforePing), то Connection Broker начинает пинговать терминальный сервер, и если несколько пингов подряд (параметр NumberFailedPingsBeforePurge) завершаются неудачно, Connection Broker исключает сервер из свой базы. Как видите Connection Broker работает гораздо умнее NLB.

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

Цитата из документации Remote Desktop Connection Broker:

RD Connection Broker supports load balancing and reconnection to existing sessions on virtual desktops, Remote Desktop sessions, and RemoteApp programs accessed by using RemoteApp and Desktop Connection.

Вот кто на самом деле делает действительно полезную и нужную работу по балансировке – распределению сессий между терминальными серверами в ферме и обеспечению доступности сервиса – reconnect клиентов и вывод из фермы недоступных серверов!

Хорошенько подумайте нужен ли вам NLB в терминальной ферме.

 Дополнение. Попался документ MSIT, в котором описан их опыт применения балансировки в терминальной ферме. Интересно, что они довольны обеими вариантами, но большую часть ферм перевели на Broker. http://technet.microsoft.com/en-us/library/cc304366.aspx

Миграция с Exchange 2003 на Exchange 2010 – от сомнений к реализации


Недавно мне пришлось выполнять миграцию с Exchange 2003 на Exchange 2010. После проведенной миграции хочется поделиться накопленным опытом.

На самом деле миграция была намного шире и затронула все компоненты инфраструктуры. Фактически происходила замена ПО 2003-го года на ПО 2010-го года. По мере «утряски» и «усушки» опыта постараюсь  делиться им в своем боге.

В этой статье я опишу только «Почему» — почему сегодня актуально внедрить Exchange Server 2010, а вместе с ним Lync Server 2010 и SharePoint Server 2010.

Причина миграции. Когда семь лет назад появился Exchange 2003, у меня не было сомнений ставить его на смену Exchange 2000 или нет: Exchange 2003 выглядел более солидно, надежно и удобно и быстро вытеснил Exchange 2000 из компаний. Аналогично можно сравнить Windows 2000 и XP: первая быстро ушла со сцены, а вторая до сих пор популярна. Такая же ситуация с Office 2000 и Office 2003 – второй используется в некоторых организациях и поныне, несмотря на более удобный Office 2007. Так и с Exchange – версия 2003-го года может поспорить с популярностью разве только с популярностью Exchange 5.5 в ее годы.

Когда появился Exchange 2007, я долго искал аргументы в пользу миграции на него с Exchange 2003. В конце-концов пришел к выводу, что смысла в миграции на него нет:  как почтовая система Exchange 2003 нас устраивает, а единственное, что было принципиально новым в Exchange 2007 это голосовая почта, но она не имела локализации и была исключительно англоязычной – основной аргумент для внедрения на англоязычном рынке для нас не годился. Рекомендация, которую я давал другим: закупка Exchange 2007 оправдана, если вы делаете новую инсталляцию или мигрируете с другой почтовой системы; если же у вас работает Exchange 2003, то мигрируйте на Exchange 2007, только если меняете оборудование и увеличиваете мощность почтовой системы.

Когда появился Exchange 2010, ничего принципиально не изменилось – обещанный русский голосовой модуль не вышел, и мне пришлось отложить на год миграцию моей почтовой системы с Exchange 2003, которая к этому моменту была уже физически изношена.

Вопрос о миграции встал на повестку дня, когда весной 2010 года появился Office 2010 с новым Outlook 2010, позволяющим использовать все возможности Exchange 2010. К тому же вышел Sharepoint 2010 с уникальным компонентом: WebApp – фактически встроенный Office! Все это вместе позволяло качественно по-новому построить коллективную работу, причем не только локально в офисе, но и удаленно.

Но только с выходом Exchange 2010 Service Pack 1 в августе 2010 года все сомнения и препятствия отпали: стал доступен русский голосовой пакет! Скажете мало? А разве любой вид нашей деятельности не связан с речью?! Человеку свойственно общаться и общаться именно с помощью речи, а никак-то иначе.

Но это еще не все. Сразу за выходом Exchange 2010 SP1 появился Lync Server 2010 RC (а следом и его RTM версия). Lync принес голосовые коммуникации на все офисные рабочие места. И это не просто телефония! Исследования показали, что в современных системах ip-телефонии из сотен функций пользователи используют от силы десять. Причина в том, что о них либо не знают, либо они трудно доступны (много кнопочек надо нажимать!). Интерфейс Lync устроен так, чтобы всеми функциями было максимально удобно и просто пользоваться. Также в свое время создавался интерфейс-лента Office 2007 – у вас все нужное для работы перед глазами, минимум щелчков мышкой.

Теперь решение от Microsoft обрело законченные черты: мы получаем интегрированное решение для всех видов коммуникаций – электронная почта (Outlook 2010 и Exchange 2010), мгновенные сообщения, аудио- и видеоконференции, телефония и голосовая почта (Lync 2010 и Exchange 2010), групповая работа (Office 2010 и Sharepoint Server 2010).

В настоящий момент сложилась уникальная ситуация: средние и крупные компании получили возможность приобрести всеобъемлющую платформу для автоматизации своей офисной деятельности от одной компании – Microsoft и за очень привлекательную цену! Огромное достоинство такого решения в обширной интеграции всех компонентов друг с другом. Альтернативы просто не существует: любое другое решение будет стоить не только ощутимо дороже при покупке, но и при внедрении и тем более при эксплуатации.

Идеала тоже не существует. Было бы глупо утверждать, что решения Microsoft совершенны и лишены недостатков. Посмотрим на состояние дел с другой стороны.

К сожалению выше перечисленные компоненты, размещенные в «Облаке», сейчас невозможно смело рекомендовать малым предприятиям  в России из-за слабой инфраструктуры и низкого уровня сервиса на уровне доступа к сети Интернет со стороны провайдеров, хотя для малых предприятий именно «облачные» решения наиболее привлекательны по стоимости владения.

Какие еще подводные камни нас ждут? Интеграция Office 2010 и Sharepoint Server 2010 имеет неудобные ограничения и работает только для стандартных компонентов, любые расширения стандартной функциональности требуют нетривиальных усилий. Такая ситуация была в предыдущих версиях и осталась сейчас. Несмотря на это популярность Sharepoint  стремительно растет! И причина этого в появлении в нем мощных компонентов: встроенная система управления содержимым и его публикацией, PerformancePoint(аналитика) и WebApp (Офис).

Lync Server 2010 только первое решение Microsoft претендующее на замену офисной телефонной станции и не сможет обеспечить «из коробки» все нюансы сигнализации и интеграции с другими элементами существующих телефонных сетей – нужны дополнительные решения партнеров. Видеоконференции также ограничены в видео рендеренге: мы  можем видеть только говорящего участника – для получения сложных картинок нужно дополнительное решение от партнеров. К тому же неизбежные ошибки первой версии… И тем не менее поддержка русского языка, единый клиент для всех видов коммуникаций, интеграция с Office и полнофункциональная телефония без сомнения приведут к широкому распространению Lync.

Exchange 2010, как и его предшественник Exchange 2007, имеет целый ряд подсистем трудных для понимания и настройки, его невозможно запустить одной кнопкой, особенно в сценариях миграции с других версий и сосуществования с ними.  Несмотря на уже годовое присутствие на рынке Exchange 2010, документация до сих пор неполная в некоторых разделах. Русский голосовой модуль Exchange 2010 работает, но как любая первая версия имеет недоработки и просто ошибки.

На этом с «лирикой» все. Если вы еще сомневаетесь, то пора отбросить сомнения и приступить к внедрению новых решений от Microsoft.