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

Для создания тестовой учетной записи можно воспользоваться командлетом 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, чего мы собственно и добивались:

Что делать? Если обратить внимание на приведённый выше скриншот, то можно увидеть, что среди пользователей SCCM есть встроенная учётная запись SYSTEM. В следующем узле Rights, можно убедиться, что учётная запись SYSTEM имеет полные административные права на управление SCCM. Соответственно осталось войти под учётной записью SYSTEM, запустить консоль управления System Center Configuration Manager Console и добавить себя в администраторы SCCM.

Но как войти под учётной записью SYSTEM? В данном случае может помочь известная утилита от Марка Русиновича – psexec, которая входит в набор PSTools. Распаковываем архив и запускаем:

psexec -s -i mmc.exe

Ключ -i делает интерактивный вывод приложения в данный сеанс, а ключ -s запускает приложение под учётной записью SYSTEM. Далее в открышемся окне Microsoft Management Console, нажимаем меню File, Open… и открываем оснастку управления SCCM, которая находится по следующему пути: C:\Program Files (x86)\Microsoft Configuration Manager\AdminUI\bin\adminconsole.msc.

Обращаем внимание, что теперь в контекстном меню узла Site Database…\Security Rights\Users доступно меню «Manage ConfigMgr Users». Соответственно, теперь уже по стандартной процедуре, добавляем новую учётную запись и предаставляем ей необходимые административные права на управление System Center Configuration Manager.

]]> http://www.lankey.ru/blog/2012/01/28/restore-admin-rights-to-sccm-console/feed/ 0 http://www.lankey.ru/blog/2011/12/16/%d0%bd%d0%b0%d1%81%d1%82%d1%80%d0%be%d0%b9%d0%ba%d0%b0-dynamic-vpn-%d0%bd%d0%b0-%d0%bc%d0%b5%d0%b6%d1%81%d0%b5%d1%82%d0%b5%d0%b2%d0%be%d0%bc-%d1%8d%d0%ba%d1%80%d0%b0%d0%bd%d0%b5-juniper-srx100/ http://www.lankey.ru/blog/2011/12/16/%d0%bd%d0%b0%d1%81%d1%82%d1%80%d0%be%d0%b9%d0%ba%d0%b0-dynamic-vpn-%d0%bd%d0%b0-%d0%bc%d0%b5%d0%b6%d1%81%d0%b5%d1%82%d0%b5%d0%b2%d0%be%d0%bc-%d1%8d%d0%ba%d1%80%d0%b0%d0%bd%d0%b5-juniper-srx100/#comments Fri, 16 Dec 2011 09:47:37 +0000 Александр Ульянов http://www.lankey.ru/blog/?p=833 Ни для кого не секрет, что VPN является наиболее распространенной технологией для удаленного доступа к ресурсам сети. Использование уже существующей инфраструктуры Интернета значительно снижает затраты компании, при этом, не подвергая риску безопасность передаваемой  по сети информации.

Традиционно организация удаленного доступа через VPN осуществляется с помощью клиентского программного обеспечения, которое требуется вручную установить на все компьютеры удаленных пользователей. Сотрудникам необходимо самим найти и установить нужное программное обеспечение, зачастую на эти действия затрачивается много рабочего времени, особенно если сотрудник является неопытным пользователем ПК. Для бизнеса, где велико число удаленных пользователей, такая ситуация неприемлема. С целью решения этой проблемы, вендоры(Cisco, Juniper) разработали решение, которое автоматически инициирует установку VPN клиента на компьютер пользователя через веб-браузер. На оборудовании Juniper таким решением является Dynamic VPN. Клиентская программа, устанавливаемая через Dynamic VPN на компьютеры пользователей – Juniper Networks Access Manager (JNAM).

В рассмотренном ниже примере описана настройка Dynamic VPN на межсетевом экране Juniper SRX100 с версией Junos 10.2R3.10. Интерфейс fe-0/0/0 – внешний интерфейс межсетевого экрана с ip адресом 81.94.41.236, fe-0/0/1 – внутренний интерфейс. Стоит отметить, что настройка различается для некоторых версий Junos.

Топология сети приведена на рисунке 1.

Рис. 1. Топология сети

Настройка Juniper Dynamic VPN для Junos версии 10.3 и ниже:

Шаг 1. Настройка доступа.
При подключении по Juniper Dynamic VPN требуется аутентификация пользователей. Для этого прописываем профили пользователей на межсетевом экране (вместо межсетевого экрана аутентификацию можно связать с сервером RADIUS, в этом примере RADIUS не используется). На межсетевом экране созданы 2 профиля: user1 и user2.

root# show access
profile user-auth-profile {
  client user1 {
    firewall-user {
      password «$9$U7DkmPfQ9A0k.Qn/AIR»; ## SECRET-DATA
    }
  }
  client user2 {
    firewall-user {
      password «$9$ruxlMLXx-24ZM8-wY4ji»; ## SECRET-DATA
    }
  }
}
firewall-authentication {
  web-authentication {
    default-profile user-auth-profile;
  }
}

Шаг 2. Настройка HTTPS
Необходимо включить HTTPS на внешнем интерфейсе(по умолчанию он включен только на внутренних интерфейсах), в противном случае пользователь не сможет подключиться через веб-браузер и пройти аутентификацию. Внешним интерфейсом служит fe-0/0/0. Важно: по умолчанию на внешнем интерфейсе стоит ограничение на входящий траффик. Это ограничение требуется изменить для успешного доступа по VPN(в примере нет ограничений на входящий траффик).

root# show system services web-management https
system-generated-certificate;
interface [ vlan.0 fe-0/0/0.0];

Шаг 3. Настройка IKE/IPSEC
Задаем параметры обоих фаз для установления IPsec туннеля. IKE шлюз и VPN должны быть прописаны для каждого пользователя. В нашем примере 2 пользователя, следовательно настраиваем 2 IKE шлюза. Важно: максимальное количество пользователей ограничено лицензией.

IKE(Phase1):

root# show security ike
traceoptions {                            //файл логов (создаем для отслеживания неполадок)
  file vpnike1 size 1m;
  flag all;
  flag ike;
  flag policy-manager;
  level 15;
}
proposal phase1-prop {
  authentication-method pre-shared-keys;
  dh-group group2;
  authentication-algorithm sha1;      //алгоритм хеширования
  encryption-algorithm 3des-cbc;    //алгоритм шифрования
}
policy ike-pol {
  mode aggressive;
  proposals phase1-prop;
  pre-shared-key ascii-text «$9$N5-w2g4JHqfwYJDiqzF»; ## SECRET-DATA
}
gateway dyn-gw-piter {
  ike-policy ike-pol;
  dynamic hostname piter;
  external-interface fe-0/0/0.0;
  xauth access-profile user-auth-profile; //при аутентификации используем созданный профиль user-auth-profile
}
gateway dyn-gw-moscow {
  ike-policy ike-pol;
  dynamic hostname moscow;
  external-interface fe-0/0/0.0;
  xauth access-profile user-auth-profile; //при аутентификации используем созданный профиль user-auth-profile
}

IKE(Phase2):

root# show security ipsec
proposal phase2-prop {
  protocol esp;
  authentication-algorithm hmac-sha1-96;
  encryption-algorithm 3des-cbc;
}
policy ipsec-pol {
  perfect-forward-secrecy {
    keys group2;
  }
  proposals phase2-prop;
}
vpn dynamic-vpn-piter {
  ike {
    gateway dyn-gw-piter;
    ipsec-policy ipsec-pol;
  }
}
vpn dynamic-vpn-moscow {
  ike {
    gateway dyn-gw-moscow;
    ipsec-policy ipsec-pol;
  }
}

Шаг 4. Настройка Dynamic VPN
На этом шаге настройки требуется прописать сети или хосты, доступ к которым осуществляется через VPN. В нашем случае это сеть 192.168.50.0/23. Другими словами траффик от пользователей user1 и user2 в сеть 192.168.50.0/23 будет зашифрован.

root# show security dynamic-vpn
access-profile user-auth-profile;      
clients {
  client1 {
    remote-protected-resources {
      192.168.50.0/23;
    }
    remote-exceptions {
      0.0.0.0/0;
    }

  ipsec-vpn dynamic-vpn-piter;
  user {
    user1;
  }
}
  client2 {
    remote-protected-resources {
      192.168.50.0/23;
    }
    remote-exceptions {
      0.0.0.0/0;
    }
    ipsec-vpn dynamic-vpn-moscow;
    user {
      user2;
    }
  }
}

Шаг 5. Настройка политики безопасности
Заключительный шаг представляет собой настройку политики доступа для входящего на внешний интерфейс траффика. Выбор политики безопасности происходит в зависимости от установленного VPN туннеля.

root# show security policies from-zone untrust to-zone trust
policy vpn-piter {
  match {
    source-address any;
    destination-address any;
    application any;
  }
  then {
    permit {
     tunnel {
      ipsec-vpn dynamic-vpn-piter;
     }
    }
  }
}
policy vpn-moscow {
  match {
    source-address any;
    destination-address any;
    application any;
  }
  then {
    permit {
     tunnel {
      ipsec-vpn dynamic-vpn-moscow;
     }
    }
  }
}

Шаг 6. Подключение удаленного пользователя
Настройка межсетевого экрана завершена, теперь протестируем Dynamic VPN. Запускаем браузер на клиентской машине и вводим адрес: https://81.94.41.236/dynamic-vpn. В качестве ip используем адрес внешнего интерфейса межсетевого экрана. Если все настроено верно, должна появиться следующая страница:

Вводим пару логин/пароль одного из прописанных на межсетевом экране пользователей. После аутентификации межсетевой экран определяет установлено ли клиентское программное обеспечение(Junpier Networks Access Manager), если ПО не установлено будет инициирована автоматическая загрузка JNAM(на клиентском компьютере должна быть установлена Java). По каким-то причинам загрузка не запустилась – есть возможность скачать JNAM по ссылке отображаемой на странице.

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

VPN туннель устанавливается как только пользователь примет сертификат и повторно введет пару логин/пароль.

Когда в поле status отображается “Connected”, можно смело заходить на внутренние ресурсы компании, не беспокоясь о безопасности соединения.

Среди нововведений в Windows Server 8 – и новая версия гипервизора, Hyper-V 3.0, снабженная новыми возможностями. Виртуальные машины в Hyper-V 3.0 будут поддерживать больше 16 виртуальных процессоров, и бОльший объем оперативной памяти.

Судя по информации о возможностях новой версии-конкурента VMware vSphere 5, максимальное количество поддерживаемых виртуальных процессоров вряд ли будет меньше 32.

Также появилась интересная возможность Hyper-V Replica – возможность онлайновой репликации работающей виртуальной машины по сети на другой сервер, даже расположенный в удаленной локации. Все, что для этого требуется – сетевое соединение.

На скриншотах видеодемонстрации видно, что для создания реплики достаточно указать удаленный Hyper-V-сервер, на который будет производиться репликация, и выбрать тип аутентификации – как Windows Integrated, так и по сертификатам (что, возможно, позволит реплицировать виртуальные машины на хост, находящийся в совершенно отдельном лесу Active Directory, без доверенных отношений). Передаваемые по сети данные могут сжиматься. Также, можно выбрать, какие конкретно виртуальные диски нужно реплицировать.

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

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

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

Возможнось Hyper-V Replica не зависит от используемого железа, систем хранения и сетевых подключений, и является чисто программной. Вероятно, Hyper-V Replica схожа с технологией репликации, реализованной программными решениями DoubleTake, рассказ о которых еще предстоит в нашем блоге.

Полностью видео о Windows Server 8 и Hyper-V Replica можно посмотреть здесь, примерно на 37й минуте.

Итак, что же появляется нового в новой версии VMware vSphere 5?

• Основой и платной, и бесплатной версии продукта теперь является один гипервизор – ESXi. VMware делает упор на его небольшой размер и производительность.
• vSphere Auto Deploy – новая модель распространения гипервизоров на железо, и установки патчей. Распространение работает с использованием PXE-Boot, загрузки специально подготовленного образа и файлов ответов с профилем хоста на сервер, и автоматического подключения его к vCenter. Таким образом, можно быстро, по сети, установить группу хостов виртуализации.
• Новая версия виртуальной машины – Virtual Machine version 8, включающая в себя новое виртуальное оборудование – поддержку 3D графики, например для Aero (правда, без использования аппаратного ускорения), и устройства USB 3.0.
• В качестве гостевой операционной системы поддерживается Mac OS X Server 10.6 – правда, к сожалению, не везде, а только на определенном оборудовании Apple Xserve.
• Storage DRS – автоматическое распределение хранения виртуальных машин в зависимости от нагрузки на системы хранения.
• Обновление файловой системы VMFS5 – поддержка LUN-ов больше 2 Тб.
• Поддерживается vMotion поверх сетей с высокими задержками.
• Поддержка до 32 виртуальных процессоров и до 1 Тб памяти на виртуальную машину.
• vSphere Web Client – несмотря на использование гипервизора ESXi, к нему возможен доступ из браузера.
• vCenter Server Virtual Appliance – работа сервера vCenter в качестве виртуальной машины на базе Linux.
• Поддержка виртуальными машинами считывателей смарт-карт.
• Swap to SSD – возможность разместить файл подкачки на дисках SSD, что, из-за их скорости, может сделать привлекательнее и быстрее memory overcommit.

Новое в лицензировании:

• Уменьшилось количество редакций vSphere – исчезла редакция Advanced. Так что остались только Standard, Enterprise и Enterprise Plus. Интересно, что ряд новых возможностей vSphere 5, описанных выше, будет доступен только в самой дорогой vSphere Enterprise Plus.
• Исчез лимит процессорной лицензии на количество ядер – теперь процессорная лицензия покрывает неограниченное количество ядер в одном процессоре. Сделано явно «на вырост», к требованиям прогресса
• Также исчезло лицензионное ограничение на максимальный объем физической памяти на хосте, бывшее в версии 4.
• В лицензирование добавилось понятие vRAM Entitlement – покрываемый объем общей виртуальной оперативной памяти. То есть, в организации лицензированы должны быть не только используемые хостами VMware процессоры, но и объем памяти, занимаемый всеми запущенными виртуальными машинами на всех хостах. Каждая процессорная лицензия уже включает в себя некоторый объем vRAM – например, лицензия Enterprise Plus включает в себя 48 Гб vRAM. Если виртуальные машины превышают включенный в лицензии объем, то необходимо приобретение дополнительных лицензий. Например, если есть два хоста виртуализации, каждый с одним процессором, но на каждом хосте виртуальными машинами используется по 60 Гб оперативной памяти – то две лицензии Enterprise Plus на процессор суммарно дадут объем vRAM только 96 Гб, что не покрывает общий объем в 120 Гб виртуальных машин, и потребуется докупка лицензий.
• Бесплатный гипервизор включает в себя vRAM entitlement только 8 Гб, то есть, бесплатно можно будет запустить виртуальных машин только на 8 Гб оперативной памяти суммарно.
• Проверка на соответствие vRAM Entitlement не является жесткой – только в версиях vSphere Essentials существует жесткое ограничение, не позволяющее превысить vRAM и запустить машин больше, чем лицензировано. В остальных версиях VMware будет ограничиваться срабатыванием Alert-а о том, что инфраструктура не соответствует лицензированию.

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

Если мы говорим об обычных телефонах, определить местоположение звонящего несложно – определяем, с какого номера / порта он звонит, и знаем (по таблице портов), где он находится. Гораздо интереснее, когда речь заходит об IP-телефонии. Клиент IP-телефонии (а особенно Lync) не привязан к конкретному месту – он может сегодня залогиниться с этого компьютера, через 10 минут, работая по WiFi, уйти в другой конец здания, или вообще, сидеть подключенным из дома через Edge Server или даже VPN.

Поэтому задача автоматического определения местоположения становится гораздо интереснее.

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

Одним из компонентов роли Front-End сервера Lync является служба Location Information Server. Location Information Server получает данные от пользователя, и в зависимости от настроенных параметров, определяет его местонахождение. Управляется Location Information Server исключительно из PowerShell – в графической консоли управления Lync данных опций нет.

Команды PowerShell, относящиеся к серверу местоположений, имеют вид *-CsLis*, с префиксом LIS.

Сервер LIS определяет местоположение пользователя, сравнивая полученные от него данные со своей базой данных – хранящейся на back-end сервере пула, в SQL-базе данных lis. Соответственно, базу требуется заполнить правильными данными.

Сервер LIS при определении местоположения учитывает следующие данные, возвращаемые пользователем:

• Его IP-адрес, а если точнее, IP-подсеть
• BSSID беспроводной точки доступа, если клиент Lync подключен к сети по WiFi
• Порт коммутатора, если клиент Lync подключен к сети проводом
• MAC-адрес коммутатора

Также, если клиент подключен по VPN, это тоже будет учтено при обработке местоположения.

Информация о беспроводных точках доступа заносится командой Set-CsLisWirelessAccessPoint, о коммутаторах – Set-CsLisSwitch, о портах коммутаторов – Set-CsLisPort, и о подсетях – Set-CsLisSubnet.

Примечание: BSSID – это беспроводной MAC-адрес конкретной точки доступа, выглядящий как шесть байт – точно так же, как MAC-адрес сетевой карты или коммутатора. Несколько точек доступа могут иметь одно имя сети (SSID), но они всегда будут иметь разный BSSID.

Например, мы знаем, что у нас есть некая беспроводная точка доступа с BSSID 01-02-03-04-05-06, которая расположена в здании офиса по адресу Москва, Нагорный проезд, дом 7Б, на четвертом этаже. Добавим информацию об этой точке и ее местоположении в базу Location Information Server:

Set-CsLisWirelessAccessPoint -BSSID 01-02-03-04-05-06 -Description "Точка доступа 4 этаж" -Location "Четвертый этаж" -CompanyName "ООО НашаМегаКомпания" -HouseNumber 7 -HouseNumberSuffix "Б" -StreetName "Нагорный" -StreetSuffix "проезд" -PreDirectional "" -PostDirectional "" -City "Москва" -Country "RU"

После внесений изменений в базу LIS эти изменения необходимо опубликовать:

Publish-CsLisConfiguration

Пример выполнения такой команды приведен на скриншоте:

Теперь, когда клиент Lync подключится в сеть, будучи подключенным к этой беспроводной точке доступа – в клиенте автоматически появится строчка «Четвертый этаж», которую мы задали в поле Location. Ну а если клиент будет подключен не к этой беспроводной точке – строчки местоположения автоматически не появится

Например, в моем Lync автоматически отобразилось, что в момент, когда был сделан этот скриншот, я нахожусь в офисе:

Решение на данный момент: деинсталлировать апдейт 2449742. Ждем какого-нибудь исправления от Microsoft.

UPD: Проблема признана командой разработчиков Exchange, пока решение то же – не ставить данный апдейт.

UPD 2: Проблема решена, Microsoft выпустил исправление.

В Exchange Server 2007 и  Exchange Server 2010 RTM для удаления определённого письма из всех ящиков можно было воспользоваться командлетом Export-Mailbox:

Get-Mailbox -resultsize unlimited | Export-Mailbox -SubjectKeywords «Фотки со вчерашней вечеринки» -Deletecontent -confirm:$false

Но в Exchange 2010 sp1 командлет Export-Mailbox отсутствует, вместо него появился командлет New-MailboxExportRequest, который не позволяет удалить письмо из ящика. Тем не менее, сделать групповое удаление, всё же возможно, воспользовавшись командлетом  Search-Mailbox:

Get-Mailbox -resultsize unlimited | Search-Mailbox -SearchQuery ‘Subject:»Фотки со вчерашней вечеринки»‘ -DeleteContent -confirm:$false

После выполнения данной команды, произойдёт удаление всех писем с темой «Фотки со вчерашней вечеринки» из всех почтовых ящиков Exchange.

Какие сразу приходят в голову варианты решения: 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 лучше всего брать в Ашане, там дешевле)

После этих манипуляций принтеры появлялись на клиентских ПК, но не работали, так как 64-битные драйверы с сервера конечно же не подходили:

Казалось бы, что может быть проще? Идем добавлять дополнительные драйверы на сервер, и получаем следующую ошибку:

Все дело в том, что дополнительные драйверы с отличающейся архитектурой нужно добавлять с хоста той же архитектуры. Пробуем добавить из-под ХР:

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

Оказалось, что при добавлении дополнительных драйверов их названия должны быть полностью идентичными. В нашем случае на сервере были установлены драйверы с названием HP LaserJet 1505n, а 32-битная версия называлась HP LaserJet  P1500 Series PCL5e, потому ничего и не работало. В случае с более новыми принтерами проблема решается скачиванием с сайта производителя  одинаковых драйверов для х32 и х64. Но и тут все было не так просто, мало того, что для 2008 сервера не было драйверов с таким же названием, так мы еще и не имели возможности поменять драйвер на ХР, потому что в этом случае одно очень важное приложение распечатывало страницы некорректно. К тому же у НР все официальные драйвера идут с приставкой series, поэтому даже если бы была возможность использовать другие драйвера на клиентах, то ничего бы не вышло.  Было сделано много предложений, как быть в такой ситуации, но в итоге сработало переименование драйверов в inf-файле. Файл выглядел так:

Сначала я попробовал изменить наименования драйвера только в секции, относящейся к русскоязычному CAB-файлу, но это результатов не дало. После этого я изменил в файле все записи HP LaserJet P1500 Series PCL5e на HP LaserJet 1505n.

Затем добавил драйвер из-под ХР, уже при добавлении было видно, что фокус сработал, оставалось понять, сработает ли это на сервере:

Смотрим результат на сервере:

Все получилось. После этих манипуляций принтеры инсталировались вместе с драйверами.