Главная Windows, Без рубрики, Новое Active Directory, PowerShell, Windows 2008 R2
  • Типовые задачи администрирования AD с использованием PowerShell

    monolisa-ascii_thumbВсем администраторам Active Directory периодически приходится сталкиваться с рутинными задачами, которые хотелось бы так или иначе автоматизировать. Как правило, это делается с использованием скриптов на наиболее известных языках программирования: VBScript, Jscript, PowerShell. Последний я считаю наиболее удобным. Благодаря некоторым из его особенностей те же процедуры, которые занимают в VBScript десяток строк и требуют понимания работы WMI, LDAP и еще многих китайских слов – в PowerShell занимает всего пять строк и требуют всего лишь знания программирования на уровне школьных уроков информатики. В настоящей статье мы рассмотрим типовые задачи администрирования Active Directory, и их автоматизацию с помощью PowerShell.

    P.S. Статья рассчитана на полных, или почти полных «чайников», пару раз видевших или где-то слышавших о PowerShell. На звание Терминатора не претендую, по сему просьба ногами не пинать.

     

    Общие положения

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

    В первую очередь, необходимо заметить, что для того, чтобы все нормально работало – необходимо иметь хотя бы один контроллер домена Windows Server 2008 R2 с установленной компонентой ActiveDirectory Web Services. Увы и ах, Windows Server 2003 уходит на свалку истории. Для работы с модулем ad_powershell необходимо установить Remote Server Administration Tools, его так же можно установить на рабочем компьютере и запускать скрипты оттуда. Разумеется, ОС на компьютере должна быть не ниже Windows 7. На контроллерах домена Windows Server 2008 R2 необходимые компоненты уже установлены.
    Перед тем, как выполнять скрипты – необходимо установить политику выполнения скриптов. По умолчанию, в целях безопасности включена политика Restricted, что означает, что на данном компьютере вообще запрещен запуск любых PowerShell-скриптов. О том, какие еще бывают политики выполнения – можно почитать в мануале:

    Get-Help Set-ExecutionPolicy –Detailed

    В нашем случае я рекомендую установить политику RemoteSigned, что позволит запускать любые собственноручно написанные скрипты, при этом запуск скриптов, скачанных из Интернета будет возможен только при наличии цифровой подписи с доверенным сертификатом. Запустите оболочку PowerShell с правами администратора (Run as Administrator) и выполните команду

    Set-ExecutionPolicy RemoteSigned

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

    Теперь можно проверить работу скриптов – написать простейший скрипт «Hello World!». Я предпочитаю пользоваться PowerShell ISE, хотя можно писать и в простейшем Notepad’е. PowerShell ISE – удобная среда програмирования для PowerShell с возможностью отладки. Входит в состав ОС Wondows 7 и 2008 R2. Вобщем, рекомендую.

    image

    Теперь переходим непосредственно к автоматизации. Для того, чтобы создать объекты в Active Directory, или изменить какие-либо свойства, нам необходим список объектов со всеми необходимыми параметрами. Например, список пользователей может содержать следующие парамеры: Имя, Фамилия, Логин, Пароль. Проще всего для этого использовать CSV-файл. CSV – это текстовый файл, содержащий список объектов (например – пользователей), с разделением параметров каким-либо символом (как правило, это запятая «,», хотя может быть и точка с запятой, знак табуляции и т.д.). Каждый объект обозначается одной строчкой. Так же, первая строчка может содержать список параметров.

     

    Пример:

     

    Name;Surname;Login;Password

    Ivan,Ivanov;i.ivanov;p@ssw0rd1

    Petr,Petrov;p.petrov;p@ssw0rd2

    Sidor;Sidorov;s.sidorov;p@ssw0rd3

     

    Чтобы получить список объектов из CSV-файла, используется командлет Import-CSV:

    $Users = Import-CSV “c:\temp\users.csv”

    Такой файл можно создать и в блокноте, но проще всего будет использовать Microsoft Excel. В Excel необходимо при сохранении файла выбрать формат CSV. Интересно, что Excel при сохранении в формат CSV в качестве разделителя использует знак “;”, хотя вроде бы написано «CSV (разделители – запятые)». PowerShell же по умолчанию считает, что в качестве разделителя используется запятая («,»). Чтобы наш скрипт работал корректно – необходимо либо заменить в CSV-файле все точки с запятой на запятые (используя автозамену в блокноте) либо же, что на мой взгляд правильнее – указать в скрипте использовать точку с запятой в качестве разделителя:

    $Users = Import-CSV “c:\temp\users.csv” –Delimiter “;”

    Чтобы проверить, как прошел импорт – можно посмотреть, что хранится в переменной $Users.

    image

    Как видим, в переменной $Users теперь хранится массив объектов с параметрами Name, Surname, Login, Password. Эти параметры можно использовать для создания учетных записей пользователей в AD.

    Прежде чем приступить к работе с Active Directory, необходимо произвести импорт соответствующего модуля в PowerShell. Только после этого появятся команды для работы с AD:

    Import-Module ActiveDirectory

    Эту строку можно (и даже нужно) вставлять в начало всех скриптов – чтобы не вводить эту команду вручную.

     

    Создание учетных записей пользователей

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

    Для нашего примера, в качестве списка пользователей будем брать CSV-файл со следующими полями:

     

    • Name – имя пользователя
    • Surname – фамилия пользователя
    • Password – пароль
    • OU – организационное подразделение, где будет находиться пользователь (вида Contoso_Users/Fin/Accounting)

     

    Вначале нам нужно импортировать пользователей из списка:

    $Users = Import-CSV $1 –Delimiter “;”

    Параметр $1 означает, что в качестве пути к CSV-файлу будет использоваться первый по счету параметр командной строки. Запускаться скрипт будет следующим образом:

    PS C:\Users\admin > Add_Users.ps1 c:\temp\users.csv

    Далее нам нужно пройтись по всему массиву пользователей из списка:

    Foreach($CurrentUser in $Users) {

    Знак открытой фигурной скобки означает начало цикла. Этот цикл проходит по всем объектам списка, и прискаивает текущий объект переменной $CurrentUser.

    Затем, для упрощения – присвоим значения соответствующих полей отдельным переменным:

     

    $Name = $CurrentUser.Name

    $Surname = $CurrentUser.Surname

    $Password = $CurrentUser.Password

    $OU = $CurrentUser.OU

     

    Для того, чтобы задать пароль пользователю – необходимо перевести его в шифрованный формат SecureString:

    $SecurePwd = ConvertTo-SecureString -AsPlainText -Force -String $Password

    Так же, OU нам нужно перевести в формат, соответствующий стандарту LDAP (для примера выше: “OU=Accounting,OU= Fin,OU= Contoso_Users,DC=contoso,DC=com”).

     

    Для этого вначале разделим строку $OU на отдельные составляющие:

    $OUTmp = $OU –Split “/”

     

    В результате переменная $OUTmp будет содержать массив из всех элементов пути:

    PS C:\Users\admin> $OUTmp

    Contoso_Users

    Fin

    Accounting

     

    Далее, используя командлет Foreach-Object, получим из нашего массива первую часть LDAP-пути:

     

    $Path = “” #незабудьте проинициализировать переменную!

    $OUTmp | ForEach-Object {$Path = "OU=$_," + $Path}

     

    В переменной $Path появляется первая часть LDAP-пути:

     

    PS C:\Users\admin> $Path

    OU=Accounting,OU=Fin,OU=Contoso_Users,

     

    Теперь нам нужно получить полный путь, добавив к пути домен:

     

    $Path += “DC=contoso,DC=com”

    Получили полный LDAP-путь:

    PS C:\Users\admin> $Path

    OU=Accounting,OU=Fin,OU=Contoso_Users,DC=contoso,DC=com

     

    Теперь сформируем дисплейное имя пользователя, его логин, User Principal Name.

     

    $Login = $Name[0] + “.” + $Surname #логин формируется из первой буквы имени и фамилии, например: i.ivanov

    $Displayname = $Name + “ “ + $Surname #Дисплейное имя: Ivan Ivanov

    $UserPrincipalName = $Login + “@contoso.com

     

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

     

    New-ADUser $Displayname –SamAccountName $Login –UserPrincipalName $UserPrincipalName -DisplayName $DisplayName -AccountPassword $SecurePwd -ChangePasswordAtLogon 1 -Path $Path

    Здесь, в принципе, все параметры понятны. Параметр -ChangePasswordAtLogon 1 означает, что пользователю будет предложено сменить пароль сразу после логина.

    По умолчанию в PowerShell, в отличие от стандартного визарда в оснастке ActiveDirectory Users And Computers учетные записи только что созданных пользователей будут отключены (Disabled). Поэтому сразу после создания учетные записи нужно включить:

    Enable-ADAccount $Login

    Теперь нужно закрыть цикл знаком «}». Можно сохранять скрипт и пробовать.

    Готовый скрипт будет выглядеть следующим образом:

     

    Import-Module ActiveDirectory

    $Users = Import-CSV $1 –Delimiter “;”

    Foreach($CurrentUser in $Users) {

    $Name = $CurrentUser.Name

    $Surname = $CurrentUser.Surname

    $Password = $CurrentUser.Password

    $OU = $CurrentUser.OU

    $SecurePwd = ConvertTo-SecureString -AsPlainText -Force -String $Password

    $OUTmp = $OU –Split “/”

    $Path = “” #незабудьте проинициализировать переменную!

    $OUTmp | ForEach-Object {$Path = "OU=$_," + $Path}

    $Path += “DC=contoso,DC=com”

    $Login = $Name[0] + “.” + $Surname

    $Displayname = $Name + “ “ + $Surname #в кавычках – пробел!

    $UserPrincipalName = $Login + “@contoso.com”

    New-ADUser $Displayname –SamAccountName $Login –UserPrincipalName $UserPrincipalName -DisplayName $DisplayName -AccountPassword $SecurePwd -ChangePasswordAtLogon 1 -Path $Path

    Enable-ADAccount $Login

    }

     

    Создание учетных записей компьютеров

    Как известно, для работы с Active Directory перво-наперво необходимо вводить компьютеры в домен. Сделать это можно двумя способами:

    · Мышкой – самый известный способ, через «Свойства» «Моего компьютера». Легко и просто.

    · Командой netdom join. Тоже несложно, и можно использовать в скриптах.

    У первого способа есть существенный недостаток: учетные записи компьютеров создаются в дефолтном OU Computers. В организациях же, как правило имеются разные OU для разных типов компьютеров (сервер, десктоп, ноутбук), а так же отдельные OU для разных отделов/департаментов/и т.д., с различными групповыми политиками, действующими для разных OU. Поэтому после ввода компьютеров в домен необходимо переносить учетные записи компьютеров вручную в соответствующий OU, а затем перезагружать компьютер еще раз, чтобы на нем применились все необходимые политики. При использовании команды netdom можно указать нужное OU, но набирать все это с клавиатуры – та еще задачка, особенно – когда компьютеров много, и особенно, что часто бывают – задачку эту поручают простым эникейщикам. Где-то в какой-то букве обязательно ошибется.

    Самый лучший выход из этой ситуации – создать учетные записи компьютеров заранее, в соответствующих OU. Тогда компьютер сразу после ввода в домен и перезагрузки применит все соответствующие политики.

    Разумеется, учетные записи компьютеров, как и пользователей, можно создавать и вручную. Но, поскольку мы – админы, а не эникейщики – будем использовать PowerShell.

    Для учетных записей, как и для компьютеров, используем CSV-файл

    ComputerName;OU

    Server1;Cnotoso_Computers/Servers

    Server2;Cnotoso_Computers/Servers

    Desktop1;Cnotoso_Computers/Desktops

    Desktop2;Cnotoso_Computers/Desktops

    Desktop3;Cnotoso_Computers/Desktops

    Laptop1;Cnotoso_Computers/Laptops

     

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

     

    Import-Module ActiveDirectory

    $Computers = Import-CSV $1 –Delimiter “;”

    Foreach($CurrentComputer in $Computers) {

    $ComputerName = $CurrentComputer.ComputerName

    $OU = $CurrentComputer.OU

    $OUTmp = $OU –Split “/”

    $Path = “” #незабудьте проинициализировать переменную!

    $OUTmp | ForEach-Object {$Path = "OU=$_," + $Path}

    $Path += “DC=contoso,DC=com”

    New-ADComputer –Name $ComputerName –Path $Path

    }

     

    Массовый сброс паролей

    Иногда бывает необходимо массово сбросить пароли у множества пользователей.

    Структура CSV-файла:

    • Login – логин пользователя
    • NewPassword – новый пароль

    Import-Module ActiveDirectory

    $Users = Import-CSV $1 –Delimiter “;”

    Foreach($CurrentUser in $Users) {

    $Login = $CurrentUser.Login

    $NewPassword = $CurrentUser.NewPassword

    $SecurePwd = ConvertTo-SecureString -AsPlainText -Force -String $Password

    Set-ADAccountPassword –Identity $Login –Reset –NewPassword $SecurePwd

    }

     

    Массовое изменение параметров

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

     

    • Имя
    • Фамилия
    • E-Mail
    • Телефон
    • Организация (у компании несколько юр.лиц)
    • Должность

     

    Из нее мы создаем CSV-файл с полями:

     

    • Name
    • Surname
    • E-Mail
    • Phone
    • Organization
    • JobTitle

     

    Скрипт будет следующего вида:

     

    Import-Module ActiveDirectory

    $Users = Import-CSV $1 –Delimiter “;”

    Foreach($CurrentUser in $Users) {

    $Name = $CurrentUser.Name

    $Surname = $CurrentUser.Surname

    $Email = $CurrentUser.E-Mail

    $Phone = $CurrentUser.Phone

    $Organization = $CurrentUser.Organization

    $JobTitle = $CurrentUser.JobTitle

    $Login = (Get-ADuser –Filter {GivenName –eq $Name –and Surname –eq $Surname}).SamAccountName #ищем юзера с заданным именем и фамилией и возвращаем его логин

    Set-ADUser $Login –EmailAddress $Email –MobilePhone $Phone –Company $Organization –Title $JobTitle

    }

     

    Заключение

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

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

    Например:

     

    • Добавить обработку ошибок (например, если пользователь с таким именем уже существует, или наоборот – не существует) – конструкции типа try… catch…
    • Автоматическую генерацию паролей заданной длины и сложности
    • Вывод логинов с автоматически сгенерированными праолями для только что созданных учетных записей в CSV-файл – командлет Export-CSV

     

    Ресурсы

    Эти ресурсы очень сильно помогут в изучении PowerShell. Во всяком случае мне они помогли.

    Надеюсь, эта статья была вам полезна, и кто-то, кто раньше боялся консоли – перестанет ее бояться. Улыбка

    Александр Косивченко

    • Как не нужно называть домены Active Directory

      45074Выбор имени домена задача несложная, но как показывает жизнь достаточно часто после запуска dcpromo имя домена генерируется случайным образом. Вроде и ничего страшного, домен работает, принтеры печатают, 1С открывается. Но увы есть ряд ситуаций, когда генерация случайным образом имени, если не выйдет вам боком, то хлопот однозначно добавит. В этой небольшой заметке я попытаюсь рассказать о том, как не стоит именовать ваши домены и почему. Информация хоть и известная, но реальная жизнь показывает, что ошибки в именовании просто повальные.  А поскольку процедура переименования домена это ит-шное садо-мазо, лучше все делать изначально правильно.

    • Главная Virtualization, Windows, Без рубрики, Новое Hyper-V, Windows Server 2012, вебинар
      • Вебинар TechNet: Windows Server 2012 Hyper-V Replica

        Presentation_RightBox210 мая сего года в 17:00 по московскому времени пройдет вебинар TechNet, в рамках которого я расскажу о новой технологии, которая появляется в Windows Server 2012: Hyper-V Replica. Эта технология позволяет осуществлять репликацию виртуальных машин между географически разнесенными площадками, что позволяет повысить отказоустойчивость. При этом не требуется покупки какого-либо дополнительного оборудования или программного обеспечения, в отличие от существующих решений вроде Veeam Backup & Replication или репликации на уровне СХД.

        • Что год грядущий нам готовит? Краткий whatsnew по Hyper-V 3.0

          Догоним и перегоним!

          clip_image002Совсем недавно, на конференции Build было проанонсировано новое поколение ОС от Microsoft: Windows 8 и серверная ОС Windows Server 8. Среди прочих нововведений в Windows Server 8 присутствует новая версия гипервизора Hyper-V 3.0. И – это уже стало доброй традицией – в каждой новой версии гипервизора появляются все новые и новые фичи. Не побоюсь этого слова, я был удивлен, узнав, сколько же всего нового появилось в Hyper-V 3.0: это и одновременная миграция нескольких виртуальных машин, и Storage Live Migration, и репликация, и ресурсные пулы и многое другое. Надо сказать, что это еще даже не бета-версия, а только Developer Preview, поэтому какие фичи будут реализованы, какие – нет, и как именно это будет работать – пока невозможно сказать. Тем не менее, мы посмотрим, что нам показывают сейчас. Заранее извиняюсь за сумбур и отсутствие картинок – делать полноценный обзор пока не вижу смысла. Во всяком случае до выхода публичной бета-версии.

           

          Так и What’s, собственно говоря, new?

          Нововведений, как уже было отмечено – просто масса. Среди них:

          • Виртуальной машине можно назначить больше 4х виртуальных процессоров. Официально заявлено – до 32. Так же официально заявлено, что виртуальным машинам можно будет выделять до 512 Гб памяти.
          • Прямой «проброс» PCI-устройств в виртуальные машины (SR-IOV). Теоретически это позволит виртуальным машинам работать с устройствами, в частности, сетевыми адаптерами напрямую. Опять же теоретически – это может повысить производительность и использовать внутри виртуальных машин «специфический» функционал устройств, доступный только с использованием нативных драйверов. Как это будет работать на самом деле – посмотрим.
          • Выделение ресурсов виртуальным машинам через пулы – Resource Pools, аналогично как у VMware. Теперь можно не бояться, что одна виртуальная машина «съест» всю полосу пропускания сетевого интерфейса или Fibre Channel-адаптера.
          • При удалении снапшотов виртуальных машин операция объединения (Merging) теперь происходит «на лету» и не требует завершения работы гостевой ОС.
          • Second Level Page File – очень странное нововведение – своп памяти для виртуальных машин на уровне гипервизора. Не так давно Microsoft официально открещивалась от такой технологии, называя ее вредной – действительно, это может привести к «интересным» ситуациям. Поскольку гипервизор «не знает», как использует память гостевая ОС – в своп могут попасть страницы памяти ядра. Или же гостевая ОС может выгрузить в своп те страницы памяти, которые уже были выгружены в своп самим гипервизором. Такие «курьезы» могут привести к непредсказуемым последствиям – от падения производительности до «синего экрана смерти» в гостевой ОС. Остается лишь надеяться, что Microsoft все это учтет, и каким-то образом сможет избежать таких ситуаций. Возможно, посредством интеграционных компонент гипервизор сможет определять, какие страницы можно свопить, а какие – нет, а гостевая ОС будет «знать», какие страницы уже попали в Second Level Swap.

          Подсистема хранения данных

          Самое заметное из нововведений здесь – это появление виртуального Fibre Channel HBA. Теперь LUN’ы можно презентовать от СХД виртуальным машинам напрямую без использования passtrough-дисков. Виртуальные FC HBA, в свою очередь, можно объединять в виртуальные SAN-сети и привязывать к определенным физическим HBA. Это, в частности, позволяет без особых ухищрений реализовывать отказоустойчивую кластеризацию на уровне гостевых ОС.

          Помимо этого, появился новый формат файлов виртуальных дисков – VHDX. Их объем может достигать 16 Тб (против 2 Тб у стандартных VHD), так же заявляется устойчивость к сбоям питания.

          Еще стоит упомянуть поддержку Offloaded Data Transfer (ODX). Тоже достойная внимания фича: если раньше при копировании блоков данных внутри одного LUN’а или между LUN’ами одной СХД приходилось сначала считывать блок, передавать его по SAN, а затем передавать его обратно для записи – то теперь в этом отпадает необходимость: копирование блоков осуществляется внутри СХД, не нагружая и без того загруженную SAN-сеть и HBA.

          Ну и самое интересное: теперь файлы виртуальных дисков могут находиться на SMB-шарах. Это может пригодиться тем, кому не по карману «полноценная SAN». Хотя я, если честно, не знаю, для чего это может пригодиться, когда в комплект Windows Server 8 входит бесплатный Microsoft iSCSI Software Target. Тем не менее, это работает – я проверял.

          Сетевая подсистема

          Множество нововведений касается сетевой подсистемы. Самая главная новость: компания Cisco Systems заявляет о разработке виртуального коммутатора Nexus 1000V для Hyper-V 3.0. До сих пор эта уникальная фича была эксклюзивом для VMware. Теперь же она появится и у Microsoft, и это означает официальное признание того факта, что Microsoft Hyper-V все-таки «созрел» для Enterprise, что бы там ни говорили конкуренты.

          Сами виртуальные коммутаторы в Hyper-V 3.0 стали более функциональными. Теперь они поддерживают так называемые расширения (Extensions). Расширения – это специальные модули, разрабатываемые как Microsoft, так и сторонними разработчиками, позволяющие перехватывать или фильтровать трафик, проходящий через виртуальный коммутатор. К примеру, можно использовать стандартный Microsoft Network Monitor для анализа трафика на уровне виртуального коммутатора. А расширение Windows Filtering Platform позволяет фильтровать трафик с помощью правил Windows Firewall. Вскоре после релиза Windows Server 8 появится виртуальный коммутатор Cisco Nexus 1000V, о котором уже говорилось, и скорее всего следующая версия Forefront Threat Management Gateway тоже будет работать с расширениями для виртуальных коммутаторов.

          Отказоустойчивость и надежность

          Так же, ряд нововведений коснулся отказоустойчивости и надежности. В частности, заявляется, что failover-кластер теперь может содержать до 63 узлов и до 4000 виртуальных машин. Проверить это мне, увы, не удалось по очевидным причинам.

          Что же касается Live Migration – тут есть целых три новости.

          • Одновременная миграция нескольких виртуальных машин. До нынешнего времени виртуальные машины могут мигрировать между серверами только поочередно. Если запущена миграция одной из виртуалок – придется дожидаться ее окончания, и только потом мигрировать следующую. В Hyper-V 3.0 можно задать число виртуальных машин, которые могут мигрировать одновременно. Верхний предел вроде как не ограничивается – в любом случае, проще будет упереться в «потолок» пропускной способности сети.
          • Для Live Migration теперь не требуется объединение серверов в отказоустойчивый кластер. До настоящего времени использование кластеров было необходимым требованием для Live Migration. Теперь это не требуется. Более того, не нужно покупать дорогие системы хранения данных или настраивать программный iSCSI Target – достаточно разместить файлы виртуальных дисков на SMB-шаре.
          • Наконец-таки она появилась и у Microsoft – Live Storage Migration. Теперь и у Microsoft появилась возможность перемещать не только память виртуальных машин между серверами, но и перемещать файлы виртуальных дисков из одной локации в другую без простоев гостевой ОС. Если виртуальных дисков несколько – можно выбрать, какие из них куда перемещать.

          И есть еще одна новая фича – Hyper-V Replica. Эта фича позволяет периодически реплицировать файлы виртуальной машины на другой сервер Hyper-V, и в случае необходимости – например, при аппаратном сбое или сбое питания – запустить реплику как полноценную виртуальную машину. Так же реплики позволяют делать откат состояния виртуальной машины – по аналогии со снапшотами, что тоже может оказаться полезным. Репликация осуществляется инкрементно (реплицируются только те блоки данных, которые изменились с момента последней репликации) с интервалом раз в час. Разумеется, этот интервал можно изменить. При создании реплик используется технология Volume Shadow Copy (VSS), поэтому копия получается консистентной. Это особенно важно, если внутри виртуальной машины используются, в частности, базы данных.

          Заключение

          Вот, собственно, такой кратенький обзор у меня получился. Прошу прощения за уровень 100 и за отсутствие скриншотов и вообще за стиль статьи «галопом по европам», но пока не вышла хотя бы публичная бета – я наверное воздержусь от глубокого копания. Все еще может измениться и не один раз. Какие-то из описанных фич возможно и выкинут, какие-то останутся, но будут работать по-другому, а возможно добавят что-то новое. Тем не менее, можно составить примерное представление – чего можно ожидать от Hyper-V 3.0. Меня не могут не радовать темпы роста функционала Hyper-V, и если раньше он заметно проигрывал конкурентам – то теперь имеются все шансы значительно сократить это отставание, и это признают уже даже такие гиганты, как Cisco Systems. От себя могу только пожелать удачи Microsoft, и пусть через год они нас не разочаруют!

          • Ресурсы по Poweshell

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

          • Главная Security, Windows, Без рубрики, Новое Active Directory, Security
            • Аудит Active Directory с «человеческим лицом».

              seo-auditБольшинство начинающих системных администраторов считают, что аудит – это слово, имеющее отношение к бухгалтерии, финансам, но уж никак не к информационным технологиям. Их мнение в корне меняется, когда они начинают работать в средних и крупных организациях, где количество администраторов может измеряться десятками. В таких случаях аудит становится страховкой для системного администратора, позволяющей при возникновении форс-мажоров спасти как собственную зарплату, так и в ряде ситуаций – карьеру.

              • Миграция базовой инфраструктуры Microsoft. Часть 2.

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

                Первую часть можно найти здесь.

                Аутентификация.

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

                Для миграции из одного домена в другой, будет достаточно внешних односторонних доверительных отношений, так, чтобы исходный домен доверял целевому. Исходный -> целевой. В такой конфигурации смигрированные системы смогут получать доступ (аутентифицироваться) к еще несмигрированным системам. А если у нас есть системы, которые взаимодействуют друг с другом, то мы должны такие системы мигрировать как группу, одной порцией.

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

                Помимо определения направления, вам необходимо определить тип доверительных отношений. Внешние доверительные отношения могут создаваться между лесами и доменами (non-Windows Kerberos-сферы – третий тип, но к нам он не относится).

                Если уровни лесов Windows Server 2003 или выше, то мы можем создать доверительные отношения уровня леса. Такие доверительные отношения создаются в корневых доменах леса и являются транзитивными на уровне корневых доменов. Это означает, что все домены из одного леса, будут доверять доменам другого (доверяемого) леса. На уровне лесов, если брать их как единый объект, транзитивности нет.

                Если уровень леса ниже Windows Server 2003 и повысить его нельзя ни при каких условиях, то придется создавать внешние доверительные отношения между доменами. Минус по сравнению с доверием между лесами очевиден – таких доверительных отношений необходимо создать больше.

                Способов создания доверительных отношений достаточно много: оснастка Active Directory Domains and Trusts, скрипты, утилита netdom, использование различных API (Win32 API, классы .Net Framework) и т.д.

                Стоит отметить, что утилита netdom не умеет создавать доверительные отношения между лесами, поэтому вам придется воспользоваться другими способами. Самый простой из них это оснастка Active Directory Domain and Trusts. Подробнее о создании доверительных отношений на уровне леса – http://technet.microsoft.com/en-us/library/cc780479%28WS.10%29.aspx.

                А вот для создания доверительных отношений между доменами netdom подойдет.

                Создаем односторонние доверительные отношения:

                Netdom trust “source.com” /d:”target.com” /ud:”администратор target.com” /pd:”пароль администратора target.com” /uo:”администратор source.com” /po:”пароль администратора source.com” /add

                Добавляем /twoway и получаем двухсторонние доверительные отношения:

                Netdom trust “source.com” /d:”target.com” /ud:”администратор target.com” /pd:”пароль администратора target.com” /uo:”администратор source.com” /po:”пароль администратора source.com” /add /twoway

                Основными структурами защиты доступа к данным, таким как файлы, принтеры, реестр, являются избирательные списки контроля доступа – DACL (Discretionary Access Control List). Элементы из DACL описывают уровень доступа, который будут иметь участники безопасности при обращении к защищенным данным. Участники безопасности представлены в виде идентификаторов безопасности– SID (Security Identifier). В Active Directory такие идентификаторы есть у объектов групп, пользователей, компьютеров. При миграции, в целевой инфраструктуре создаются новые учетные записи с новыми идентификаторами безопасности (далее основной SID). И получается, что доступ к данным у учетных записей с новыми SIDами должен пропасть. Но есть возможность перенести старые идентификаторы, сохранив их в атрибуте SIDHistory (назовем их вторичными SIDами). Контроль доступа к данным учитывает оба типа SIDов. Доступ к данным в этом случае должен сохраниться.

                С одной стороны SIDHistory штука хорошая, с другой стороны создает определенные проблемы с безопасностью. Получается, что сисадмин из доверяемого домена может прописать в SIDHistory идентификатор полномочной учетной записи из доверяющего домена, и тем самым, получит доступ к каким-либо важным данным. Чтобы от этого защититься, придумали функционал фильтрации SIDов. Первый – фильтрация только SIDHistory, а второй, более строгий – фильтрация всех «инородных» SIDов. Инородными считаются идентификаторы, не относящиеся к доверяемому домену.

                Для доверительных отношений на уровне лесов (forest trusts) определена только фильтрация вторичных SIDов, для внешних доверительных отношений (external trusts) фильтрация всех «неродных SIDов».

                В случае с внешними доверительными отношениями к фильтруемым SIDам будут относиться идентификаторы из SIDHistory и идентификаторы универсальных групп. Такое поведение называют карантином (Quarantine). Включается этот карантин для всех внешних доверительных отношений, создаваемых на контроллерах домена под управлением Windows Server 2000 SP4 или выше.

                Почему возникают проблемы с универсальными группами? Происходит это по причине того, что пользователь может быть членом универсальных групп  из любого домена в пределах леса. Соответственно, если пользователь входит в универсальную группу из другого домена, то в TGT-referral попадут SIDы других доменов. Структуры TGT относятся к аутентификации по протоколу Kerberos. В этих структурах находятся списки идентификаторов пользователя (первичных и вторичных), а также список  идентификаторов групп (первичных и вторичных) членом которых является пользователь. TGT-referral относятся к структурам Kerberos, которые пересылаются в другой домен. Во время создания доверительных отношений создаются TDO-объекты (Trusted Domain Objects). В этих объектах содержится информация об идентификаторе доверяющего домена. Принимающий домен (доверяющий) на основе информации из TDO, производит фильтрацию SID, удаляя из TGT-referral все SID не относящиеся к доверяемому домену.

                Фильтрация применяется и к аутентификации по протоколу NTLM. Сам процесс аутентификации NTLM несколько отличается от Kerberos.

                А почему с forest trust нет проблем с универсальными группами? Это не происходит, потому что в TDO-объектах доверительных отношений уровня леса (forest trust) хранятся идентификаторы безопасности каждого домена доверяемого леса. Соответственно идентификаторы универсальных групп будут входить в этот список и отфильтровываться не будут. А что случится с SIDHistory, сформированным в результате миграции внутри леса (intraforest migration)? За счет все той же информации из TDO, такие идентификаторы будут считаться родными (только в случае с forest trust), поэтому проблем не возникнет. Получается, что поведение фильтрации EnableSidHistory не совсем соответствует своему названию. Название «карантин» (Quarantine) все же больше подходит, по крайней мере предназначение тоже самое – фильтрация всех неродных SIDов.

                Подробнее о нецелевом использовании SIDHistory – http://gexeg.blogspot.com/2009/12/active-directory.html

                Подробнее о работе доверительных отношений – http://technet.microsoft.com/ru-ru/library/cc738955%28v=ws.10%29.aspx

                Подробнее о протоколе Kerberos – http://technet.microsoft.com/ru-ru/library/cc739058%28v=WS.10%29.aspx

                Подробнее о протоколе NTLM – http://davenport.sourceforge.net/ntlm.html

                Отдельное спасибо читателю, ник которого Argon. Указал на ошибку с фильтрацией SID, что заставило меня разобраться в этом раз и навсегда 🙂

                Существует множество инструментов, которые позволяют мигрировать объекты безопасности Active Directory, сохраняя SID в SIDHistory. Вот некоторые из них: ADMT, sidhist.vbs, sidewalk.exe. Две последние утилиты из набора Support Tools. Все  эти инструменты используют функцию DsAddSidHistory из библиотеки Ntdsapi.dll. Функция документированная. Описана здесь – http://msdn.microsoft.com/en-us/library/ms675918(VS.85).aspx

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

                Вы выбрали для себя необходимый инструмент миграции и готовы начать работы. Перед началом миграции необходимо отключить фильтрацию SIDов.

                Отключить фильтрацию можно с помощью утилиты netdom. Если у вас доверительные отношения между лесами (forest trust), то необходимо выполнить следующую команду:

                Netdom trust source.com /d:target.com /ud:”администратор target.com” /pd:”пароль администратора target.com” /uo:”администратор source.com” /po:”пароль администратора source.com” /EnableSidHistory:yes

                Если необходимо проверить статус фильтрации SID введите туже самую команду, но без параметра yes:

                Netdom trust source.com /d:target.com /ud:”администратор target.com” /pd:”пароль администратора target.com” /uo:”администратор source.com” /po:”пароль администратора source.com” /EnableSidHistory

                Если у вас внешние доверительные отношения (external trust), то поможет следующая команда (/Quarantine:no):

                Netdom trust source.com /d:target.com /ud:”администратор target.com” /pd:”пароль администратора target.com” /uo:”администратор source.com” /po:”пароль администратора source.com” /Quarantine:no

                Проверить статус можно с помощью параметра /Quarantine без значения no:

                Netdom trust source.com /d:target.com /ud:”администратор target.com” /pd:”пароль администратора target.com” /uo:”администратор source.com” /po:”пароль администратора source.com” /Quarantine

                Перечисленные команды отключают фильтрацию SID на ресурсной стороне. То есть на той стороне, где находятся ресурсы, к которым необходимо получить доступ. Мы это сделали на стороне source.com.

                Но у нас есть  системы из source.com, которые могут обращаться к смигрированным ресурсам в домене target.com. Нужно ли отключать фильтрацию SID в этом случае? Скорее всего, да. Во-первых, исходный домен мог когда-то уже участвовать в процессе миграции (между лесами – cross-forest). У учетных записей этого домена заполнен атрибут SIDHistory, SIDы которого участвуют в назначении прав на ресурсы. Во-вторых, пользователи (или компьютеры) могут быть членами универсальных групп.

                Тут применяются те же самые правила:

                • если доверительные отношения между лесами (forest trust), то необходимо отключать фильтрацию SID с помощью параметра /EnableSidHistory:yes;
                • если доверительные отношения между доменами (external trust), то необходимо отключать фильтрацию SID с помощью параметра /Quarantine:no.

                А что если, по каким-то причинам, нам нельзя мигрировать вторичные SIDы или отключать фильтрацию (или и то и другое)? Решение этой задачи есть. Но при этом сам процесс миграции меняется, становится более сложным в реализации, по сравнению с традиционным. Если всё-таки есть возможность отключить фильтрацию на время миграции и переносить SIDы, то лучше это сделать. Подробнее об особенностях миграции в такой конфигурации поговорим немного позже.

                Подробнее о фильтрации SID:

                http://technet.microsoft.com/en-us/library/cc772816%28WS.10%29.aspx (Disable SID filter quarantining)

                http://technet.microsoft.com/ru-ru/library/cc772633%28WS.10%29.aspx (Configuring SID Filtering Settings)

                О создании внешних доверительных отношений – http://technet.microsoft.com/en-us/library/cc738617%28WS.10%29.aspx

                О синтаксисе netdom trust – http://technet.microsoft.com/en-us/library/cc835085%28WS.10%29.aspx.

                Необходимые порты TCP/IP для создания доверительных отношений (а также  их дальнейшей работы) – http://technet.microsoft.com/ru-ru/library/cc756944%28WS.10%29.aspx

                Окружение пользователя.

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

                Перемещаемые профили (roaming profiles) пользуются большим спросом. Плюсов от их использования очень много, минусов практически нет. Но при миграции возникают определенные трудности использования этого функционала. Если конкретнее, то перемещаемые профили пользователей не загружаются между лесами. Это означает, что если пользователь из одного леса зайдет на рабочую станцию (или сервер) в другом лесу, то он получит пустой рабочий стол. Его перемещаемый профиль не загрузится. Более того, не отработают и групповые политики назначенные пользователю в его «родном» домене или лесу. Такое поведение наблюдается, начиная с Windows 2000 SP4.

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

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

                Чтобы включить обработку групповых политик пользователей и загрузку перемещаемых профилей между лесами, необходимо сделать следующее:

                1)      В домене исходного леса создайте групповую политику.

                2)      С помощью административных шаблонов установите значение параметра Computer Configuration\Administrative Templates\System\Group Policy\Allow Cross-Forest User Policy and Roaming Profiles в значение Enabled.

                3)      Полезно будет отключить конфигурацию пользователя, поскольку она не используется.

                4)      Необходимо продумать фильтрацию групповой политики. Будет это на основе иерархии, по группам безопасности или фильтрами WMI, решать вам. Но хотелось бы еще раз отметить, что данные настройки должны распространяться на компьютеры. Если будете использовать фильтрацию по группам, то делайте это универсальными или глобальными группами, поскольку в многодоменной среде есть особенности использования доменнолокальных групп при назначении прав на объекты каталога.

                5)      Если доменов в лесу несколько, то необходимо, либо создать несколько объектов групповых политик и повторить перечисленные выше действия, либо привязать существующую групповую политику. Лучше создавать дополнительные, иначе будет труднее отлавливать ошибки.

                Те же действия, с 1 по 5, необходимо проделать в целевом лесу. Хотелось бы отметить, что в целевом домене это может не понадобиться, если у вас есть ограничения на создание доверительных отношений. Эти ограничения описаны в разделе аутентификация, выше.

                В описании к административным шаблонам указано, что настройка Allow Cross-Forest User Policy and Roaming Profiles относится только к Windows Server 2003 и выше, но на самом деле, работает для Windows 2000 SP4 и выше. Для более низких версий, описанной проблемы не возникает – профили загружаются в любом случае.

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

                Подробнее об управлении групповыми политиками можно почитать здесь – http://technet.microsoft.com/en-us/library/cc784283%28WS.10%29.aspx

                Про перемещаемые профили и Windows 2000 с SP4 – http://support.microsoft.com/kb/823862
                Дополнительные сведения  для Windows Server 2003 – http://technet.microsoft.com/en-us/library/cc757395%28WS.10%29.aspx

                Еще раз напомню, где находится первая часть. Здесь.

                Ефимов Геннадий, MCP.

                • Миграция базовой инфраструктуры Microsoft. Часть 1.

                  Введение.

                  Тема миграции базовой инфраструктуры Microsoft не нова. Но полной и самодостаточной информации о проведении этого процесса очень мало, если не сказать, что такой информации вообще нет. На просторах сети Интернет можно найти очень много статей, описывающих процесс миграции, но все эти статьи являются какими-то «огрызками» и полной картины не раскрывают. Если говорить о миграции на новые платформы, то здесь информации еще меньше.

                  Мне хотелось бы раскрыть эту тему в большем объеме, рассказать об особенностях миграции в реальных инфраструктурах. Будет учитываться специфика работы различных информационных систем, как такие системы необходимо мигрировать, в какой последовательности.

                  Одной статьи для рассмотрения материала не хватит (или это будет очень большая статья), поэтому будет несколько статей. Конечный объем материала пока не известен. Писать буду по мере возможностей, постараюсь не затягивать с этим процессом.

                  Что будем считать базовой инфраструктурой, и что в нее будет входить?

                  • Служба каталогов Active Directory. По праву AD можно назвать ключевым компонентом в базовой инфраструктуре;
                  • DNS;
                  • DHCP;
                  • WINS;
                  • Файловые серверы;
                  • Принт-серверы;
                  • Терминальные серверы и фермы терминальных серверов;
                  • DFS и ее элементы;

                  Сейчас все больше и больше организаций используют Exchange-сервер в качестве средства объединенных коммуникаций. Exchange напрямую зависит от Active Directory, и миграция службы каталогов безусловно повлияет на работу Exchange-пользователей. Документация по миграции Active Directory есть, но в этой документации не описывается процесс миграции AD совместно с Exchange. В свою очередь, в других документах описывается миграция Exchange, но она не рассматривается совместно с миграцией Active Directory. Примерно туже самую картину я наблюдал на проектах, в которых участвовало несколько архитекторов – один по AD, второй по Exchange. Зачастую их действия не были согласованы – миграция двух систем проходила несколько изолировано, особенности совместной миграции не учитывались. Получалось, что одна система (архитектор) мешала другой (другому).

                  Есть определенные особенности миграции серверов Microsoft SQL Server. Включим в миграцию и их.

                  Что будем считать миграцией? Миграцией будем считать перенос ресурсов из одного или нескольких лесов в целевой лес. Такая модель чаще всего встречается на практике.

                  Сам процесс миграции это только полдела (скорее всего даже меньше). Миграция процесс сложный, долгий, включает в себя множество задач, распределенных во времени, выполнение которых позволит добиться какого-то результата, достичь поставленных целей. Я фактически назвал определение понятия проект. Для выполнения проекта требуется определенный подход. Методологий по управлению проектами много, тема большая, в этой статье рассматриваться не будет. Хорошие рекомендации по управлению проектами даны в методологии MSF (Microsoft Solution Framework). Некоторые считают, что эта модель подходит только для разработчиков и к инфраструктурным проектам не относится. На самом деле это не так. Материал методологии хорошо подходит и к инфраструктурным проектам, необходимо только немного поабстрагировать. В этой методологии не будет описано «как и что делать», в ней не будет жестких правил ведения проектов, но в ней даются ценные советы, которые вам помогут выполнить любой проект, не только ITшный.

                  Также в проектировании помогут стандарты, например, ГОСТы.
                  Из них вам также необходимо выбрать определенные рекомендации, которые вам помогут выполнить проект успешно. Найти ГОСТы для автоматизированных систем можно здесь – http://www.rugost.com/index.php?option=com_content&task=category&sectionid=6&id=22&Itemid=53

                  Например, я для себя выработал некую методику, являющуюся гибридом ГОСТов и методологии MSF. Применяю ее на практике.

                  Некоторые рекомендации по ведению проектов, а точнее по управлению проектной группой, можно подчерпнуть из книги Страуструпа «Язык программирования С++», второе и третье издание. В этой книге есть отдельная глава, посвященная проектированию.

                  Контролировать ход проекта вам поможет Microsoft Project. Есть хорошая книга Гультяева А.К. по управлению проектами в Microsoft Project. Советую прочесть.

                  Исходные данные.

                  Какие у нас есть исходные данные?

                  У нас есть исходная инфраструктура, состоящая из одного леса и нескольких доменов.

                  Имя корневого домена – source.com/SOURCE. Дочерний домен – child1.source.com/CHILD1. Версии контроллеров доменов в source.com – Windows Server 2003 с SP2, в child1 – Windows 2000 Server с SP4. В доменах работают несколько пользователей. Рабочие станции – 2000, XP, Vista, Windows 7. Есть серверы Windows 2000 Server, Windows Server 2003/2008R1/2008R2.

                  В каждом домене установлен Exchange-сервер версии 2003 с SP2. Если на Exchange-сервере не установлен SP2, то необходимо это сделать до миграции почтовых ящиков пользователей. Exchange 2010 поддерживает миграцию почтовых ящиков только с версий Exchange Server 2003 SP2 и Exchange Server 2007 SP2.

                  Есть определенные требования к версиям контроллеров доменов при миграции почты на Exchange Server 2010 (или на Exchange 2007). Об этих особенностях немного позже.

                  Мы уже спроектировали целевую инфраструктуру и даже ее внедрили. В качестве целевой инфраструктуры будет выступать домен target.com/TARGET. Версия контроллеров доменов Windows Server 2008 R2.

                  На отдельном сервере установлен Exchange Server 2010. На этом сервере установлены все роли, а точнее роли Hub, CAS и Mailbox. За обработку внешней почты сейчас отвечает один из серверов в исходном домене. После миграции эту роль на себя возьмет еще один сервер в новой инфраструктуре – Exchange Server 2010 с ролью Edge Transport.

                  У нас также будут разные типы серверов в исходном домене. Нам их тоже придется мигрировать в новую инфраструктуру. О миграции серверов немного позже.

                  Интеграция.

                  Миграция является процессом достаточно долгим и сам процесс подразумевает долгосрочное сосуществование двух систем – старой и новой.

                  Поэтому нам необходимо интегрировать нашу текущую инфраструктуру с целевой.

                  Разрешение имен.

                  С чего начать интеграцию? Лучше всего с настройки разрешения имен между инфраструктурами. Нам необходимо, чтобы смигрированные ресурсы могли разрешать имена несмигрированных ресурсов, и наоборот. Наиболее популярные механизмы разрешения имен в Windows-сетях – это DNS и NETBIOS.

                  Будем считать, что DNS-серверы развернуты на контроллерах доменов. Обслуживают эти DNS-серверы зоны для своего раздела и зону _msdcs.корневой_домен_леса. Зоны интегрированы в Active Directory.

                  Как правило, хватает настройки разрешения только DNS-имен между инфраструктурами.

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

                  Рассмотрим первый способ – пересылки:

                  В общем-то, ничто нам не мешает использовать этот механизм. Сначала мы настраиваем в исходном домене пересылку для целевого домена. Для пересылки мы указываем ближайшие DNS-серверы целевого домена. Что означает ближайшие? Как правило, в многодоменной среде, для региональной площадки выделяется отдельный домен (в нашем случае это child1.source.com). Сейчас конечно от такой модели стараются отходить и переходить к однодоменной модели. Но не считайте однодоменную модель каким-либо правилом. Иногда она может вам не подойти. Все зависит от требований. При миграции в новый домен, компьютеры будут регистрировать A-записи на локальных контроллерах домена, то есть на контроллерах домена той же физической площадки, что и в исходном лесу (при условии, что мы правильно настроили конфигурацию сетевой карты клиентов DNS; об этом чуть позже). Поэтому было бы правильным настроить  пересылку именно на эти локальные контроллеры доменов.

                  В целевом домене мы проделываем тоже самое – настраиваем пересылку для исходного домена между ближайшими DNS-серверами.

                  Если исходные DNS-серверы – Windows 2000, необходимо использовать вторичные зоны или продумать способ разрешения имен совместно с глобальными пересылками на DNS-серверы целевого домена.

                  Начиная с  Windows Server 2008, появилась возможность реплицировать записи пересылок между DNS-серверами. Можно воспользоваться этим механизмом, чтобы не делать одну и туже работу несколько раз.

                  Второй механизм – использование вторичных зон:

                  Здесь мы разрешаем пересылку зоны между серверами исходного и целевого доменов. Создаем вторичные зоны: на исходных DNS-серверах вторичные зоны для целевого домена, на целевых для исходного домена. В качестве master-сервера используем ближайший DNS-сервер. Настраиваем оповещение при изменениях. Число изменений до оповещения – 1.

                  Третий способ – использование зон-заглушек:

                  Этот функционал появился в Windows Server 2003. С помощью зон-заглушек мы можем получать информацию об авторитетных DNS-серверах – NS- и A-записи серверов, обслуживающих указанную зону. Причем, эта информация  будет еще и динамически обновляться.

                  В общем-то, способ отличный, но для нашего примера подходит лишь частично. DNS-серверы из домена child1 получат NS/A-записи для всех DNS-серверов домена target.com (случаи с DisallowNSAutoCreation не будем рассматривать). Для разрешения имен, они также будут обращаться к одному из этих NS-серверов. Когда мы смигрируем компьютер в новый домен, он зарегистрируется на «новом», ближайшем DNS-сервере. Еще несмигрированные компьютеры будут обращаться к старым DNS-серверам, а те в свою очередь на какой-то DNS-сервер из нового домена. На какой? Успеет ли новая A-запись для смигрированного компьютера реплицироваться на этот какой-то DNS-сервер? Ответить на этот вопрос трудно. Поэтому зоны-заглушки из старого домена в новый, для нашей конфигурации, не подойдут. А вот в противоположную сторону мы их можем использовать.

                  Начиная с Windows Server 2008 R1, у нас есть возможность реплицировать зоны этого типа между DNS-серверами. Стоит воспользоваться этой возможность, тем более целевой лес у нас Windows Server 2008 R2.

                  Хотелось бы отметить несколько плюсов и минусов этих трех способов.

                  Способ с пересылками достаточно прост в конфигурации, при этом трафик передачи зоны равен нулю. Но трафик запросов больше, чем у вторичных зон. Есть некоторые ограничения при миграции с Windows Server 2000: нет поддержки условных пересылок. Также есть проблемы с актуальностью данных. Например, если какая-то запись изменится, скажем, поменялся IP-адрес компьютера, то изменения будут отражены на пересылающей стороне только после истечения срока кэширования записи и при повторном запросе. Это касается и способа с зонами-заглушками. Что не скажешь о вторичных зонах, где информация более актуальна (при условии настройки оповещений при изменении).

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

                  Вариант с зонами-заглушками имеет практически те же плюсы и минусы, что и способ с пересылками.

                  Три способа. Какой лучше? Способ с пересылками является наиболее простым. Зоны-заглушки можно использоваться лишь частично. Второй способ является более сложным, а значит, увеличивается вероятность отказа. На вопрос я так и не ответил. Решайте сами.

                  Если между взаимодействующими системами (клиентами, DNS-серверами), есть брандмауэры, нам необходимо разрешить трафик DNS – 53 TCP/UDP.

                  Подробнее об управлении серверов DNS – http://technet.microsoft.com/en-us/library/cc794771%28WS.10%29.aspx

                  Теперь немного о разрешении NETBIOS-имен. Основным способом разрешения имен в системах Windows 2000 и выше является DNS, но есть приложения, которые до сих пор используют NETBIOS-функции и короткие имена. Microsoft сделала определенный шаг, чтобы избавиться от этого. Теперь, начиная с Vista/Win2008, NETBIOS-функции не поддерживаются. Надеюсь, что в скором времени мы избавимся от NETBIOS-имен навсегда. Но отсутствие поддержки вовсе не означает, что такие приложения не будут работать в лесах Windows 2008 R2. Использование NETBIOS-имен также продолжается.

                  Есть три способа разрешения NETBIOS-имен: файлы LMHOSTS, широковещательные рассылки и WINS-серверы.

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

                  1) Перенести инфраструктуру WINS после миграции ресурсов Active Directory:

                  2) Настроить репликацию между новыми и старыми WINS-серверами, переключить компьютеры на новую инфраструктуру до миграции ресурсов AD:

                  3) Как и второй способ, но компьютеры переключаем после миграции в новый лес:

                  Первый и третий способ хорош тем, что мы не сталкиваемся с проблемами актуальности и сходимости данных. Все компьютеры направлены на одни и те же WINS-серверы (смигрированные и несмигрированные компьютеры), а значит, имеется единая точка, как обновления ресурсов, так и их разрешения. Затем нам придется настраивать репликацию между инфраструктурами (или для третьего способы мы уже это сделали) и, когда все ресурсы перенесены, необходимо переключить компьютеры на новые серверы. Если переключить все компьютеры за один раз, то наверняка столкнемся с некоторыми проблемами при разрешении имен. Гарантировать переключение всех компьютеров вряд ли можно в большой инфраструктуре. А если переключать порциями, то увеличится время миграции.

                  Лучше столкнуться с проблемами в меньших масштабах и решать их (предотвращать) по мере поступления. Как раз это второй способ. Мы сначала настраиваем репликацию между старым и новым лесом, а затем, перед миграцией, порциями (слотами), переключаем компьютеры на новые WINS-серверы. В этой конфигурации несмигрированные ресурсы смотрят на одни серверы, смигрированные на другие. Возникает проблема с латентностью репликации данных между этими системами. Но, как я говорил, новые системы предпочитают DNS, поэтому мы вряд ли столкнемся с проблемами. А если и столкнемся, то, скорее всего, на небольшой части компьютеров.

                  У нас есть возможность интегрировать DNS с WINS’ом – сделать для DNS-зоны WINS-просмотр. Нужно ли это делать для миграции? Лучше не стоит. Это лишнее усложнение, которое чревато ошибками и вероятность отказа сложных систем все же больше, чем у простых. Если говорить о реальных проблемах, то могут возникнуть ошибки при аутентификации по протоколу Kerberos. И вот почему. Например, пользователь запрашивает некоторую службу по короткому имени – SERVICE01. Подставляется некий суффикс и имя получается длинное – SERVICE01.target.com. Далее запрос отправляется на DNS-сервер, в котором для зоны target.com настроен обзор в WINS. Если DNS не находит в зоне target.com указанной записи, он отбросит доменные метки и запросит у WINS’а запись SERVICE01. WINS ответит IP-адресом. Но из какого домена эта запись? WINS – система плоских имен, поэтому неизвестно. DNS-сервер вернет пользователю ответ: SERVICE01.target.com=IP-адрес. IP-адрес будет, скорее всего, правильным – пинги пустить можно. Но вот что, если пользователь хотел обратиться к службе из старого леса – service01.source.com. Тут как раз и могут возникнуть проблемы при поиске службы по ServicePrincipalName. В результате могут возникнуть проблемы с аутентификацией по протоколу Kerberos.

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

                  Как поступить, если мы решили настраивать репликацию базы WINS между инфраструктурами? Реплицировать ли базу только между  ближайшими WINS-серверами или это будет смешанная репликация?

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

                  Если репликация используется только внутри домена, то настройте репликацию в пределах физической площадки – между серверами из старого домена и серверами той же площадки нового домена.

                  Требования к открытию портов TCP/IP, используемых WINS-серверами – http://technet.microsoft.com/ru-ru/library/cc784026%28WS.10%29.aspx.

                  Подробнее об управлении сервером WINS – http://technet.microsoft.com/en-us/library/cc739183%28WS.10%29.aspx.

                  Разрешению имен стоит уделить особое внимание. Причем, не только при миграции. Ошибки, связанные с разрешением имен, составляют 80-90% от общего количества (если не брать в расчет ошибки ИТ-специалистов).

                  На этом настройка разрешения имен не заканчивается. Мы будем и далее обсуждать эту тему.

                  В следующей статье мы продолжим интеграцию наших инфраструктур.

                  Ефимов Геннадий

                  P.S.: появилась вторая часть статьи – читаем.

                • Главная Virtualization, Windows, Без рубрики, Новое CSV, Hyper-V, Virtualization
                  • Hyper-V R2: Cluster Shared Volumes, Direct IO, Redirected IO

                    defragment-cluster-drives-200X200Cluster Shared Volume – это, по сути, надстройка над NTFS, позволяющая двум и более узлам кластера одновременно осуществлять запись в один и тот же физический LUN. Дело в том, что у каждого общего ресурса кластера всегда имеется узел-владелец (Owner). Для дисковых ресурсов, право на запись есть только у узла-владельца, и поэтому для того, чтобы запускать виртуальные машины одновременно на нескольких узлах кластера, и безболезненно мигрировать их с одного узла на другой – приходилось создавать отдельный LUN для каждой виртуальной машины. Это сильно усложняло администрирование, особенно когда виртуальными машинами и системами хранения данных управляли разные администраторы. CSV же позволяет нескольким узлам осуществлять запись в один физический LUN одновременно, так что можно хранить все VHD на одном и том же LUN’е, а виртуальные машины запускать на разных узлах. О том, как использовать CSV, я уже расказывал в своих более ранних статьях. Здесь я расскажу об особенностях работы CSV, а именно – о режиме прямого и перенаправленного ввода-вывода (Direct/Redirected IO).

                  • Главная Virtualization, Windows, Без рубрики, Новое Hyper-V, виртуализация
                    • Настройки виртуальных процессоров в Hyper-V

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

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