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

Для создания тестовой учетной записи можно воспользоваться командлетом new-TestCasConnectivityUser.ps1, который распологается в каталоге scripts (находится в корне инсталяционной дирректории Exchange Server).

Скрипт достаточно простой и принимает в качестве параметров подразделение, в котором будет создана учетная запись, пароль и диалплан (это нужно при наличии роли UM).

Однако после запуска данного скрипта, можно столкнуться с проблемой:

Обычно, данная ошибка бывает вызвана наличием контейнера, в название которого входит »Users». Информации по этой проблеме достаточно много и легко можно найти решение. Например – http://www.zerohoursleep.com/2010/10/new-testcasconnectivityuser-ps1-fails-with-verify-that-ou-users-exists/.

Однако возможна и более неоднозначная ситуация.

Рассмотрим детальнее скрипт:

$mailboxDatabaseName = $null;

get-MailboxDatabase -server $mailboxServer | foreach {$mailboxDatabaseName = $_.Guid.ToString()}

if ($mailboxDatabaseName -ne $null)

{

write-host $new_testcasuser_LocalizedStrings.res_0000 $exchangeServer.Fqdn

if ($Prompt -eq $true)

{

read-host $new_testcasuser_LocalizedStrings.res_PromptToQuitOrContinue

}

new-Mailbox -Name:$UserName -Alias:$UserName -UserPrincipalName:$UserPrincipalName -SamAccountName:$SamAccountName -Password:$SecurePassword -Database:$mailboxDatabaseName -OrganizationalUnit:$OrganizationalUnit -ErrorVariable err -ErrorAction SilentlyContinue

$newUser = get-Mailbox $UserPrincipalName -ErrorAction SilentlyContinue

if ($newUser -eq $null)

{

$err = «Mailbox could not be created. Verify that OU ( $OrganizationalUnit ) exists and that password meets complexity requirements.»

}

}

Как видно из приведенного отрывка скрипта, при создании нового пользователя, для указания базы, в которой пользователь создается, используется цикл foreach, на вход которому подается список баз.

В результате возможна хитрая ситуация:

На данном скриншоте видно, что учетная запись будет создана в базе a1_db.

Однако данная база в данный момент не смонтирована:

То есть скрипт пытается создать почтовый ящик в отмонтированной базе, что, естественно, заканчивается ошибкой.

Собственно, тут есть два пути. Первый это смонтировать базу. Второй – немного подправить скрипт.

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

В этом случае достаточно после строки

get-MailboxDatabase -server $mailboxServer | foreach {$mailboxDatabaseName = $_.Guid.ToString()}

добавить

$mailboxDatabaseName = «MyMDB»

(правда не стоит забывать, что скрипт подписанный)

После этого скрипт отработает нормально и можно будет наконец воспользоваться командлетом Test-OutlookWebServices, чего мы собственно и добивались:

Какие сразу приходят в голову варианты решения: 1) Microsoft Transporter Suite и 2) Notes Migrator for Exchange от Quest Software (продаётся от 250 лицензий). Как вы думаете, какой из этих вариантов правильный? Мы то знали ответ, но решили поэксперементировать, и выбрали вариант №1, да и платить за лишние 50 лицензий Quest не хотелось. Об этом мы конечно потом несколько раз пожалели, но зато есть о чём написать).

Как известно Microsoft Transporter Suite поддерживает только Exchange 2007 и не поддерживает Exchange 2010. А поскольку наш лес уже подготовлен под Exchange 2010, значит Exchange 2007 мы тут уже не поставим. Поэтому мы решили поставить в отдельному лесу Exchange 2007,  а затем смигрировать из него ящики в Exchange 2010 путём Cross-Forest миграции.

Мигрируем Lotus на Exchange 2007.

Пошаговых инструкций писать не буду, в интернете их полно, но почему-то нигде не сказано про подводные камни, поэтому я сделаю акцент лишь на некоторых моментах. Ну соответственно ставим новый контроллер домена в отдельном лесу, ставим на него же Exchange 2007 sp3. Скачиваем и ставим  Transporter Suite (64-битный). Скачиваем и ставим IBM Lotus Notes 8.5 RUS (триал скачивается бесплатно после регистрации). Запускаем Lotus Notes и настраиваем его на подключение к Lotus Domino серверу под административной учетной записью.

1) Разрешаем имперсонализацию пользователей в каталоге EWS, чтобы Transporter Suite мог под административной учётной записью импортировать почту в ящики пользователей:

Общий вид команды:

Add-ADPermission -Identity (get-exchangeserver).DistinguishedName -User (Get-User -Identity Administrator | select-object).identity -extendedRight ms-Exch-EPI-Impersonation

ну или в частности:

Add-ADPermission -Identity ‘CN=EXCH2K7,OU=Domain Controllers,DC=domain,DC=local’ -User ‘domain\Administrator’ -ExtendedRights ms-Exch-EPI-Impersonation

2) Увеличиваем длину HTTP запроса. По умолчанию максимальный размер запроса равен 4 МБ, соответственно ни одно  письмо большего размера не смигрируется. Поэтому увеличиваем данное значение. Для этого правим файл web.config виртуальной директории в IIS   \EWS. Находим там строчку <httpRuntime maxRequestLength= «4096″>  и правим её на большее значение, скажем на «102400″, что равняется 100 МБ. Я рекомендую редактировать эти параметры не вручную, через блокнот, а через расширения консоли IIS Manager, так меньше вероятность допустить ошибки и испортить файл конфигурации. Расширение консоли IIS 7 можно скачать по ссылке. Соответственно после установки расширения, для правки запускаем IIS Manager, раскрываем Sites\Default Web Site\EWS, справа в консоли запускаем Configuration Editor, в разделе Section выбираем: system.web/httpRuntime, правим параметр maxRequestLength и нажимаем Apply.

3) Увеличиваем таймаут соединений. Для этого в IIS Manager выбираем Default Web Site, справа в консоли выбираем Limits и задаём большее значение, скажем 300 с.

После внесения изменений перезапускаем IIS:

iisreset /noforce

3) Синхронизируем каталог Lotus Domino с Active Directory. Запускаем Microsoft Transporter for Lotus Domino Console, нажимаем Enter Domino Credential, вводим пароль администратора домино. Раскрываем Migrate\Directory\Users. Выбираем всех пользователей и нажимаем Migrate Selected Users. Задаём OU для новых пользователей и пароль, можно сразу выбрать создать ящик в Exchange 2007.

4) Мигрируем ящики Lotus в Exchange 2007.  Запускаем Microsoft Transporter for Lotus Domino Console, переходим Migrate\Mailboxes, выбираем все ящики и нажимаем Migrate Selected Mailboxes. Теоретически процесс должен был бы занять несколько часов и завершиться полной миграцией всех ящиков, но не всё оказалось так просто. На миграции примерно 10-го из 200 ящиков вылетела ошибка System.OutOfMemoryException и миграция прекратилась. Мы попробовали повторно запустить процесс, временно пропустив данный ящик, но вскоре снова получили аналогичную ошибку. Иногда вылетала ошибка вида типа Pipe has been ended. Поискав решения данной проблемы мы выяснили, что это ошибка в коде самого Transporter Suite, и она неисправима! Ошибка возникает вследствие переполнения буфера памяти при миграции ящиков, содержащих письма большого объёма. При миграции Transporter Suite сначала определёнными порциями извлекает письма из Lotus Domino, и затем их через EWS инжектирует в ящик Exchange. Вся эта порция писем до процесса инжектирования хранится в памяти. Мы пробовали увеличивать объём памяти сервера до 12 ГБ, но и это не помогло, Transporter Suite занимал всю память сервера и завершался с ошибкой. Ждать исправления данной ошибки от Microsoft – бесполезно, ввиду того, что разработка продукта давно прекращена и он снят с поддержки.

В итоге мы сначала выполнили миграцию всех ящиков, которые мигрировались без ошибок, выписывая имена ящиков, миграция которых вызывала ошибку. Причем после каждой ошибки процесс миграции приходилось запускать заново, заново вводить Domino Credentials, т.к. иногда вылетал сам процесс Transporter Suite , иногда с ошибкой вылетал процесс Notes-клиента. В итоге, через дня 3 мы смигрировали 170 ящиков из 200. Соответственно получили 30 ящиков, миграция которых завершалась с ошибкой. Чтобы выполнить их миграцию, мы решили: во-первых мигрировать ящики по одному, а во вторых, в пределах одного ящика мигрировать письма порциями, а именно разбивая по датам. Для этого мы воспользовались следующей командой:

Move-DominoMailbox ‘user@lotus-domain.com’ -TargetMailboxDatabase ‘EXCH2007\First Storage Group\Mailbox Database’ -EmailStart 01.01.2001 -EmailEnd 31.12.2005

затем

Move-DominoMailbox ‘user@lotus-domain.com’ -TargetMailboxDatabase ‘EXCH2007\First Storage Group\Mailbox Database’ -EmailStart 01.01.2006 -EmailEnd 31.12.2008

и т.д.

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

Мигрируем Exchange 2007 на Exchange 2010.

Для начала нам нужно было развернуть в организации Exchange 2010. При установке которого мы столкнулись с рядом проблем, а именно сервер уже когда-то был развёрнут, а затем неправильно удалён. При установке выдавалась ошибка Database is Mandatory. Одна из проблем заключалась в том, что у всех пользователей остались атрибуты Exchange, ссылающиеся на старый сервер. Чтобы их удалить разом у всех пользователей, мы воспользовались бесплатными PowerShell командлетами от Quest Software – ActiveRoles Management Shell for Active Directory, которые можно скачать по ссылке. Для этого выполнили команды:

$userlist = Get-QADUser -IncludeAllProperties
$userlist | ForEach { Set-QADUser $_ -ObjectAttributes @{msexchmailboxguid=»; msexchhomeservername=»; legacyexchangedn=»; mail=»; mailnickname=»; msexchmailboxsecuritydescriptor=»; msexchpoliciesincluded=»; msexchrecipientdisplaytype=»; msexchrecipienttypedetails=»; msexchumdtmfmap=»; msexchuseraccountcontrol=»; msexchversion=» } }

После установки Exchange 2010 sp1, можно было приступать к процессу миграции. Существует несколько путей кросс-доменной миграции Exchange 2007 на Exchange 2010 sp1. И многое зависит от начальных условий, так, например в нашем случае можно было сначала установить во временном лесу (где развёрнут Exchange 2007) CAS сервер под управлением Exchange 2010, а затем выполнить миграцию между лесами. Можно было мигрировать и напрямую с Exchange 2007, но с соответствующей подготовкой атрибутов всех пользователей в конечном лесу. Причем процесс связан с использованием Microsoft Identity Lifecycle Manager и различных скриптов. Также в нашем случае особенность заключалась в том, что в конечном лесу уже были созданы все пользователи и ящики. В общем мы решили не заморачиваться, на синхронизации атрибутов, а пойти наиболее простым с нашей точки зрения путём, и выполнить миграцию через старые добрые .pst – файлы.

Для этого сначала выполнили экспорт всех ящиков в .pst – файлы на Exchange 2007. Напоминаю, что командлет Export-Mailbox можно использовать только в 32-х разрядной версии Exchange 2007, требуется развернуть 32-х битный сервер, например Windows Server 2008 x86, скачать и развернуть Exchange Server 2007 sp3 x86, скачать и развенуть Outlook 2007/2010 x86. После чего с данного сервера можно будет выполнять:

get-mailbox | Export-Mailbox -PSTFolderPath z:\

После завершения процесса экспорта, на диске z:\ (=\\fs\exported_mailboxes) мы получим 200 .pst файлов вида aliace.pst. Затем выполняем импорт данных файлов в ящики Exchange 2010. Соответственно предварительно в Exchange 2010 мы создали ящики для всех необходимых пользователей. Для запуска самого процесса импорта нужно выполнить следующую команду:

Dir \\fs\Exported_Mailboxes\*.pst | %{ New-MailboxImportRequest -Name ImportPST -BatchName ImportPST_Bulk -Mailbox $_.BaseName -FilePath $_.FullName}

отследить состояние процесса миграции можно при помощи командлета Get-MailboxImportRequest, а после завершения процесса, лучше все очереди очистить командлетом Remove-MailboxImportRequest.

В общем-то после завершения процесса все ящики будут смигрированы, и предварительно можно было бы сказать, что задача выполнена. Есть правда в этом процессе небольшая особенность. А именно, именование папок внутри ящика. Эти имена создаются при первом подключении пользователя к ящику, либо при помощи Outlook, либо при помощи OWA. Соответственно,  если пользователь при первом подключении использовал русскую версию Outlook 2010, то и папки у него будут называться Входящие, Отправленные, Удалённые и т.п., а если английскую, то Inbox, Send Items, Deleted и т.д. Аналогично и при подключении через OWA, там зависит от языка, выбранного в браузере и выбора самого пользователя. И к сожалению, никакими средствами централизовано для всех это не задашь. Но мы попытались использовать некий work around.

Задание русских имён папок Outlook для всех почтовых ящиков Exchange.

1) Даём системному администратору права на все ящики Exchange:

Get-Mailbox | Add-MailboxPermission -user Administrator -AccessRights FullAccess

2) На OWA Virtual Directory ставим встроенную аутентификацию так, чтобы запуская Internet Explorer под администратором и открывая OWA, у нас не спрашивало логин и пароль, а автоматически попадало в ящик администратора.

3)  Задаём язык по умолчанию для клиентов OWA.

Set-OwaVirtualDirectory -identity «Owa (Default Web Site)» -LogonAndErrorLanguage 1049 -DefaultClientLanguage 1049

get-mailbox | set-mailbox -Languages «ru-RU»

4) Заходим в каждый ящик, через OWA под администратором при помощи браузера, где языком по умолчанию выбран русский.

get-mailbox | foreach-object -process {start iexplore.exe «https://exch2010/owa/$_@domain.com»; start-sleep 5; taskkill /im iexplore.exe}

Данная команда последовательно выводит весь список ящиков, запуская для каждого ящика Internet Explorer с параметром https://exch2010/owa/aliace@domain.com, после 5 секунд ожидания, процесс Internet Explorer убивается, и затем открывается новый ящик. По сути каждый раз происходит вход в ящик пользователя под администратором.

Перевод входящей почты на Exchange 2010.

Когда были завершены все описанные выше действия, мы предоставили пользователям доступ к почтовой системе через OWA, а также всем установили и настроили Outlook 2010 и попросили пользователей, ознакомиться с новой почтовой системой и проверить, корректно ли были смигрированы все их данные (за исключением последнего месяца). Всё время, пока у нас шёл процесс миграции вся входящая почта продолжала приходить в Lotus Domino. Когда пользователи ознакомились с новой системой электронной почты и убедились, что всё смигрировано верно, было решено переключить входящую почту на Exchange. Все пользователи были проинформированы, что c понедельника они начинают использовать Outlook и Lotus будет более недоступен. В пятницу вечером мы изменили публикацию 25-го порта на TMG 2010 и вся внешняя почта стала приходить на Exchange Server. Теперь нам оставалось только домигрировать ту почту, которая пришла в ящики пользователей с начала нашего процесса миграции. Для этого, выполняем туже самую последовательность действий, но везде задаём интервал только за последний месяц. Сначала мигрируем из Lotus Domino в Exchange 2007:

Get-DominoMailbox | Move-DominoMailbox -TargetMailboxDatabase ‘EXCH2007\First Storage Group\Mailbox Database’ -EmailStart 01.01.2011 -EmailEnd 31.01.2011

затем выгружаем из Exchange 2007 в .pst файлы:

get-mailbox | Export-Mailbox -PSTFolderPath z:\ -StartDate 01.01.2011 -EndDate 31.01.2011 -confirm:$false

затем импортируем в Exchange 2010:

Dir \\fs\Exported_Mailboxes\*.pst | %{ New-MailboxImportRequest -Name ImportPST -BatchName ImportPST_Bulk -Mailbox $_.BaseName -FilePath $_.FullName}

По завершению этой операции, казалось бы, что все дела сделаны и наши мучения закончились, но оказалось, что это не так. Оказывается вся новая почта, которая пришла за последний месяц, смигрировалась в ящики пользователей под английскими именами папок. Т.е. у каждого пользователя в ящике оказалось по 2 экземпляра каждой папки – на русском и на английском: «Входящие» и «Inbox», «Отправленные»  и «Sent Items» и т.д. – Причем выглядела эта ситуация очень удручающе! 200 ящиков! Удалять ящики и выполнять миграцию заново мы уже не могли, 1 – это долго, 2 – у пользователей уже поприходили в ящики новые письма, которых нет в Lotus. Кроме того в русских и в английских папках были дубликаты, т.к. процесс миграции был долгий и одни ящики мигрировались неделю назад, а другие месяц назад, а последняя миграция делалась за 1 месяц для всех. Если бы миграция была произведена в нужные папки, то был бы произведён процесс слияния и дубликатов бы не возникло.

В общем времени особо долго думать у нас не было и мы решили удалить все английские папки и мигрировать данные за последний месяц заново. Соответственно возник вопрос, как наиболее быстро удалить необходимые папки из 200 почтовых ящиков. Если покопаться на MSDN и иметь навыки программиста, то можно было быстро написать программку для Exchange Web Services, но мы (видимо не имея навыков программиста) пошли немного другим путём, а именно решили использовать бесплатную библиотеку RDO, которую можно скачать по ссылке. Собственно скачиваем архив и распаковываем его в Windows\System32, после чего выполняем regsvr32 Redemption64.dll.

Затем создаём следующий PowerShell скрипт Delete_Folders.ps1:

$rdo = new-object -com Redemption.RDOSession
$aliace = echo($_.BaseName+»@domain.com»)
$rdo.LogonExchangeMailbox(«$aliace»,»exch2010″)#$rdo.CurrentUser.name
$test = $rdo.Stores.DefaultStore.IPMRootFolder.folders | where { ($_.name -eq «Drafts» ) -or ($_.name -eq «Inbox») -or ($_.name -eq «Junk E-Mail») -or ($_.name -eq «Notes») -or ($_.name -eq «Outbox») -or ($_.name -eq «Sent Items»)}
foreach ($test in $test) {$test.delete()}
$rdo.logoff()

Затем выполняем:

$users = Dir \\fs\Exported_Mailboxes\new\*.pst
$users | foreach {.\Delete_Folders.ps1}

Вкратце поясню. Данный скрипт удалит папки Inbox, Outbox, Notes, Junk E-Mail, Drafts и Sent Items из всех ящиков, .pst файлы которых лежат в папке \\fs\Exported_Mailboxes\new\.

Собственно после этого, производим повторный процесс миграции писем, пришедших в Lotus за последний месяц, но теперь делаем это немного по другому, а именно указываем из какой папки и в какую мигрировать письма:

Мигрируем из папки «Inbox» в папку «Входящие». В Exchange все папки имеют системные имена, которые не зависят от языка. Так, например, папка «Входящие» имеет системное имя #Inbox#:

Dir \\fs\Exported_Mailboxes\new\*.pst | %{ New-MailboxImportRequest -Name ImportPST -BatchName ImportPST_Bulk -Mailbox $_.BaseName -FilePath $_.FullName -ConflictResolutionOption KeepLatestItem -SourceRootFolder «Inbox» -TargetRootFolder «#Inbox#»}

Мигрируем из папки «Sent Items» в папку «Отправленные». Папка «Отправленные» имеет системное имя #SentItems#:

Dir \\exch2007\Exported_Mailboxes\new\*.pst | %{ New-MailboxImportRequest -Name ImportPST -BatchName ImportPST_Bulk -Mailbox $_.BaseName -FilePath $_.FullName -ConflictResolutionOption KeepLatestItem -SourceRootFolder «Sent Items» -TargetRootFolder «#SentItems#»}

После данной процедуры, все письма попали в нужные папки. И в общем-то процесс миграции был завершён, но некоторые пользователи нам создали дополнительные трудности, а именно, забыв выполнить процедуру синхронизации своих адресных книг, ввиду чего они остались без личных контактов. Проблема заключается в том, что  Lotus Notes по умолчанию хранит все личные контакты пользователей в .nsf-файлах на локальных компьютерах пользователей. Для синхронизации контактов на сервер каждый пользователь должен в Lotus Notes запустить Synchronize Address Book из меню Actions, о чем сотрудники были проинформированы. Но естественно, как это всегда бывает, часть пользователей эту задачу проигнорировали и опомнились только после завершения всех процедур миграции. Соответственно для некоторых пользователей отдельно пришлось домигрировать личные контакты.

Миграция контактов.

Мигрируем всё, кроме элементов почты из Lotus на Exchange 2007:

Get-DominoMailbox | Move-DominoMailbox -TargetMailboxDatabase ‘EXCH2007\First Storage Group\Mailbox Database’ -ExcludeEmail -ExcludeSchedule -ExcludeTask

Мигрируем контакты из Exchange 2007 в .pst, чтобы сэкономить время, мигрируем лишь пользователей из списка users_wo_contacts.txt, Соответсвенно мигрируем только папку «Contacts»:

more users_wo_contacts.txt | Export-Mailbox -PSTFolderPath z:\contacts -IncludeFolders «\Contacts»

Импортируем контакты в Exchange 2010:

Dir \\fs\Exported_Mailboxes\Contacts\*.pst | %{ New-MailboxImportRequest -Name ImportPST -BatchName ImportPST_Bulk -Mailbox $_.BaseName -FilePath $_.FullName -ConflictResolutionOption KeepLatestItem -SourceRootFolder «Contacts» -TargetRootFolder «#Contacts#»}

На этом наш проект в общем-то был завершён.

Кто-то, прочитав данную заметку, возможно спросит, а не пробовали ли мы мигрировать с использованием Exchange Server 2003, который имел встроенный Connector for Lotus Notes, и я отвечу, что да пробовали – и это ещё хуже! Во-первых Exchange Server 2003 плохо понимает письма в формате HTML и при миграции переделывает их в формат RTF, при этом перегаживая всё форматирование, во-вторых он плохо разбирает кодировку и почти все письма отображаются иероглифами (хотя это можно обойти используя прямую миграцию в .pst, а затем импорт .pst файлов в Exchange 2007, используя библиотеки Outlook 2007) и в третьих Exchange 2003 не может создавать .pst файлы больше 2-х ГБ. Но если всё же кто-то, вдруг, решится мигрировать, используя Exchange 2003 и прямой экспорт в .pst, есть небольшой совет: По умолчанию Exchange 2003 при миграции из Lotus все .pst файлы защищает паролем, причем у каждого .pst-файла пароль свой. Соответствие .pst-файлов и паролей хранится в текстовом файле в тойже директории, где и сами pst-шники. Но это очень неудобно для дальнейшего использования, в частности для операций пакетного импорта файлов. Чтобы .pst файлы экспортировались без паролей, нужно установить специальный патч на Exchange 2003, патч можно скачать по ссылке. Патч ставится только на Exchange 2003 sp1. После установки патча, нужно в разделе реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\MSExchangeMailMig, создать ключ CreateWithoutPassword типа REG_DWORD со значением «1″.

Подытожив, хочу дать несколько советов:

1 – используйте платные средства миграции, например Notes Migrator for Exchange от Quest Software;

2 – тщательно всё планируйте и тестируйте до миграции в рабочей среде;

3 – почаще делайте бэкапы. Если у вас используется система виртуализации, то можно использовать снапшоты;

4 –  Adrenaline Rush лучше всего брать в Ашане, там дешевле)

Год был достаточно тяжёлый, ввиду всемирного экономического спада, который конечно же затронул и сектор ИТ. И если наше подразделение, занимающееся ИТ-аутсорсингом пострадало меньше всего, поддержка ИТ-инфраструктуры нужна всегда, без неё, как без воздуха), то отделу инфраструктурных решений пришлось намного тяжелее. В конце 2008, в начале 2009 года многие заказчики заморозили все ИТ-проекты, возникали проблемы с оплатой уже завершённых проектов. Приход новых клиентов тоже значительно сократился, компании не собирались вкладываться даже в те ИТ-решения, которые призваны сокращать затраты и оптимизировать бизнес-процессы. Поскольку компании не были готовы ждать возврата инвестиций, не имея уверенности в завтрашнем дне. И основывались в основном на быстрых методах сокращения затрат, такие как массовые сокращения сотрудников и закрытие нерентабельных подразделений. Но к концу года ситуация стала налаживаться, увеличился приток клиентов, с нами начали расплачиваться должники.

Но главное, что появившееся у нас свободное время в первой половине 2009 года мы не потратили зря. Всё наше свободное время было потрачено на обучение и сертификацию инженеров, а также на развитие новых направлений. За 2009 год мы получили 5 новых компетенций Microsoft, открыли наш технический блог, а также выполнили ряд достаточно больших проектов по внедрению Exchange Server 2007 и Exchange Server 2010, внедрили системы виртуализации серверов на базе Hyper-V в том числе в кластерных конфигурациях, завершили несколько проектов по внедрению Office Communications Server 2007 R2 (включая интеграцию с телефонией), а также множество проектов по внедрению доменов  Active Directory, систем резервного копирования, систем управления Интернет-трафиком и т.д. На появление новых проектов во много положительно сказался выход новых продуктов от Microsoft, таких как: Exchange Server 2010, Windows Server 2008 R2, Threat Management Gateway (TMG) 2010.

Надеемся, что в 2010 году закончится мировой финансовый кризис, и начнётся всеобщий экономический подъём, который принесёт нам новых заказчиков, а мы своим заказчикам подарим новые ИТ-решения.

Всех с новым 2010 годом!