• Публикация виртуальных машин в UAG

    Microsoft Forefront Unified Access Gateway (UAG) 2010 – очень интересное средство для публикации внутренних ресурсов для внешних (да и внутренних тоже) пользователей. Но вот есть в нем очень серьезный недостаток – нет никаких средств автоматизации процесса управления. Точнее так, средства автоматизации есть, в виде COM-интерфесов, но они недокументированы и понять, как они работают и какие параметры принимают, мне так и не удалось.
    • Репликация баз данных в SCCM 2012

      В этой статье я хотел бы рассказать о новом механизме репликации данных, появившемся в SCCM 2012. Статья не претендует на сверхточность или супердетальность описания этого процесса. Основное внимание будет уделено именно концепции механизма репликации, хотя некоторые детали, который на мой взгляд могут быть полезны, все-таки будут приведены.
      В SystemCenter2012 ConfigurationManager появился дополнительный способ репликации данных иерархии SCCM – репликация данных с помощью механизмов SQLServer. Достаточно оправданный ход со стороны Microsoft в сторону упрощения реализации этой задачи. В процессе репликации задействуется два важных механизма: DatabaseChangeTracking и SQLServerServiceBroker. Первый появился в SQLServer  2008, второй в SQLServer 2005. Видимо из-за отсутствия DatabaseChangeTrackingв SCCM 2007 (или 2007 R2) не было репликации с помощью SQLServer (хотя может и по другим причинам).
       
       
      Основные понятия.

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

      • DatabaseChangeTracking – механизм, который появился в SQL Server 2008. Предназначен для отслеживания изменений в таблицах SQL Server, предоставляет функции для работы с этими изменениями. Подробнее об этой функции можно почитать здесь – http://msdn.microsoft.com/en-us/library/bb933875.aspx.
      • SQLServerServiceBroker – механизм SQL Server, входящий в компонент Database Engine. Предназначен для обмена сообщениями в распределенных приложениях. Механизм пришел на смену MSMQ (Microsoft Message Queuing) и призван упростить задачу межпроцессного обмена информацией. Подробнее о Service Broker можно прочитать здесь – http://msdn.microsoft.com/en-us/library/ms166104(v=sql.100).aspx. Позже мы еще вернемся к Service Broker.
      • Типданныхдлярепликации: global, site, local, global_proxy. Локальные данные не реплицируются, глобальные данные реплицируются на всю иерархию, данные сайта реплицируются с основного (primary) сайта на центральный (central) сайт. Global_proxy – это подмножество глобальных данных. Тип этой репликации используется только между Primary и Secondary сайтами, поэтому, например, на CAS вы не найдете соответствующий код для репликации.

       

      ServiceBroker.

      Этот сервис пришел на смену MSMQ, упростив задачу межпроцессного обмена данными. ServiceBroker
      освобождает вас от рутиной работы и многое далает за вас. Он берет на себя такую работу как авторизация, аутентификация (за счет посредников конечно), доставка данных, хранение, уникальность, очередность и т.д. И причем все эти функции доступные через весьма простые программные интерфейсы и TSQL.
      Для работы с ServiceBroker (в том числе и в SCCM) используются следующие объекты:
      • Диалог (dialog) – можно сказать что это сессия TCP, не в прямом смысле конечно, но
        похоже. То есть также есть некоторые две стороны, которые обмениваются
        сообщениями. При этом обеспечивается гарантированная доставка, подтверждение,
        очередность. Сторона установившая диалог называется инициатор (initiator), отвечающая
        сторона – target.
      • Сообщения (Message) – этими объектами просходит обмен. Сообщения могут
        быть любого типа, от бинарных данных, до «правильного» XML или даже ServiceBroker может проверять
        сообщения с помощью XML-схемы.

      Для SCCM определены ряд сообщений, такие как, DRS_SyncStart, DRS_SyncEnd, DRS_SyncData и т.д. Всего определено порядка 30 сообщений. Например, определение основного сообщения репликации данных DRS_SyncStart выглядит так:

      CREATE MESSAGE TYPE [DRS_SyncData] AUTHORIZATION

      [dbo] VALIDATION = NONE

      • Контракты (Contracts) – эти объекты определяют типы сообщений, которые
        можно послать в диалоге, а также разрешенные типы сообщений для обоих сторон диалога. Например, можно ограничить отправку определенных сообщений, которые может послать только инициатор (initiator), тип сообщений которыми может ответить target или указать что сообщение может использоваться обеими сторонами.

      Для SCCM определены контракты по приоритетам репликации: CriticalPriority, HighPriority и т.д.

      К примеру, для репликации данных с приоритетом ниже среднего определен контракт LowNormalPriority:

      CREATE CONTRACT [LowNormalPriority]
      AUTHORIZATION [dbo] ([DRS_SchemaChange] SENT BY
      ANY,
      [DRS_StartMsgBuilder] SENT BY ANY,[DRS_SyncBinaryData] SENT BY ANY,[DRS_SyncBinaryDataCompressed] SENT BY ANY,[DRS_SyncComplete] SENT BY ANY,[DRS_SyncData] SENT BY ANY,[DRS_SyncDataCompressed] SENT BY ANY,[DRS_SyncEnd] SENT BY ANY,[DRS_SyncStart] SENT BY ANY)

      • Сервисы (Services) – Диалог между участниками происходит как раз с
        использованием сервисов. У сервисов есть имена и очереди сообщений. Можно
        представить что сервисы это почтовые адреса.

      Для SCCM используются такие сервисы как, ConfigMgrDRS_Site<код_сайта> (этот для репликации глобальных данных между сайтами), ConfigMGRDRSSite_Site<код_сайта (для репликации данные
      с областью site) или, например, ConfigMgrDrsMsgBuilder (используется для запуска репликации).

      Например, определение сервиса для репликации глобальных данных (в том числе и global_proxy):

      CREATE SERVICE [ConfigMgrDRS_SiteABC]
      AUTHORIZATION [dbo]
      ON QUEUE [dbo].[ConfigMgrDRSQueue]
      ([CriticalPriority],[HighPriority],[LowNormalPriority],[LowPriority],[NormalPriority])

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

      Для каждого сервиса созданы очереди. Так выглядит очередь для репликации глобальных данных сайта BCD:

      CREATE QUEUE [dbo].[ConfigMgrDRSQueue]WITH STATUS = ON , RETENTION = OFF ,
      POISON_MESSAGE_HANDLING (STATUS = ON)  ON [PRIMARY]

      А так – очередь для инициации репликации:

      CREATE QUEUE [dbo].[ConfigMgrDRSMsgBuilderQueue]

      WITH STATUS = ON , RETENTION = OFF ,
      ACTIVATION (
      STATUS = ON , PROCEDURE_NAME = [dbo].[spDRSMsgBuilderActivation] ,
      MAX_QUEUE_READERS = 5 , EXECUTE AS N’dbo’
      ),
      POISON_MESSAGE_HANDLING (STATUS = ON)  ON [PRIMARY]

      На этой очереди висит процедура spDRSMsgBuilderActivation, которая запускается если в очереди есть сообщения.

      • Маршруты (Routes).С помощью маршрутов определяется расположение целевого сервиса. Можно сравнить данный объект с типом записи SRV в DNS. Если целевой сервис на который отправляется сообщение находится на удаленной системе, то просматривается маршрут, который был создан для этого сервиса и в котором указан сетевой адрес и порт (адрес и порт ServiceBroker). Точнее сначала просматривается маршрут до целевого сервиса, а потом уже определяется что он на удаленной
        системе. Если маршрут не найден, то используется маршрут по умолчанию, который указывает на локальный экземпляр SQLServer.

      Для каждого сервиса определены маршруты. Например, для удаленного сайта создан маршрут ConfigMgrDRSRoute_SiteBCD, который указывает на удаленную систему:

      CREATE ROUTE [ConfigMgrDRSRoute_SiteBCD]
      AUTHORIZATION [dbo]
      WITH
      SERVICE_NAME  =
      N’ConfigMgrDRS_SiteBCD’ ,
      ADDRESS  =
      N’TCP://EF-CM12-02.cm12.local:4022′

      Теперь концептуально рассмотрим сам процесс обмена сообщениями в Service Broker.

      Диалог между сервисами происходит следующим образом:

      1) Приложение-инициатор начинает диалог:

      BEGIN DIALOG CONVERSATION @dialog_handle

      FROM SERVICE [ConfigMgrDRS_SiteABC]

      TO SERVICE ‘ConfigMgrDRS_SiteBCD’

      ON CONTRACT [NormalPriority]

      2) В @dialog_handle возвращается описатель этого диалога. Этот описатель используется для отправки и приема сообщений между участниками.

      3) Формируется сообщение. Способ формирования не имеет значение. Как формируются сообщения в SCCM будет описано чуть ниже.

      4) Далее, сформированное сообщение отправляется:

      SEND

      ON CONVERSATION @dialog_handle

      MESSAGE TYPE DRS_SyncData (@Message)

      5) Диалог и объекты служб (а также контракт) определяется по описателю. По маршруту определяется расположение сервисов.

      6) Сообщение отправляется целевому сервису.

      7) После приема на целевой стороне, сообщение попадает в очередь, которая привязана к сервису.

      8) Далее сообщение, вручную или с помощью ассоциированной с очередью хранимой процедурой, извлекается из очереди. Например, вот такой конструкцией:

      WAITFOR (

      RECEIVE TOP(1) @ReceivedMessageType=message_type_name,

         @ReplicationGroup=message_body,
         @ConversationHandle=conversation_handle

         FROM dbo.ConfigMgrDRSMsgBuilderQueue

                  ), TIMEOUT 5000

      9) Полученное сообщение обрабатывается.
      10) Может быть отправлено ответное сообщение.
      11) Диалог завершается конструкцией ENDCONVERSATION @DialogHandle

       
      Репликация SCCM.
      Обсудив принципы работы с ServiceBroker, можно переходить к принципам функционирования репликации в SCCM.
       
      Инициатор.
      1) Например, мы изменили границы (Boundary) в нашей иерархии. Процесс проходит через SMS-провайдер,
      попадает в базу, запускается ряд дополнительных потоков, таких как DatabaseNotification Monitor, HierarchyManager и т.д. На этом этапе данные зафиксированы в БД (в нашем случае в таблице BoundaryEX). Далее.
      2) [SMS_REPLICATION_CONFIGURATION_MONITOR]: Компонент MS_REPLICATION_CONFIGURATION_MONITOR запускает каждую минуту процедуру spDRSInitiateSynchronization (можно увидеть в логе rcmctrl.log).
       
       
      3) [spDRSInitiateSynchronization]: Процедура просматривает таблицу ReplicationData и получает все группы объектов репликации, которые не реплицировались определенный интервал времени (SyncInverval*60)
      и который в данный момент не реплицируются. Для глобальных данных определен интервал в 1 минуту, для данных сайта – 5 минут.
       
       
      Объекты Boundary относятся к группе 3 (столбец ID) с типом репликации global.
      4) [spDRSInitiateSynchronization]: Для каждой группы репликации формируется сообщение типа DRS_StartMsgBuilderс телом равным наименованию группы репликации (ReplicationGroup). Сообщение отправляется сервису  ConfigMgrDRSMsgBuilder (и от сервиса ConfigMgrDRSMsgBuilder). Это локальный сервис. Отправка сообщения происходит, если репликация инициируется с сервера в Primary сайте или область репликации не равна site. То есть это проверка, что CAS не должен отсылать данные с областью site другим сайтам (Primary).
      5) [ServiceBroker]: Сообщение попадает в очередь ConfigMgrDRSMsgBuilderQueue (ассоциирована с сервисом ConfigMgrDRSMsgBuilder). На очереде висит процедура spDRSMsgBuilderActivation.
      6) [spDRSMsgBuilderActivation]: Процедура spDRSMsgBuilderActivation сканирует очередь ConfigMgrDRSMsgBuilderQueue, вытаскивает сообщения с типом DRS_StartMsgBuilder и запускает другую процедуру – spDRSSendChangesForGroup.
       
       

      7) [spDRSSendChangesForGroup]: Это основная процедура для отправки изменений. В этой процедуре происходят различные проверки, получение описателей диалогов ServiceBrokerи т.д.
      8) [spDRSSendChangesForGroup]: Определяется максимальная версия данных в базе данных. Версию можно восприниматься как некий USN(UniqueSequenceNumber), который ассоциируется с изменениями. MaxVersion = CHANGE_TRACKING_CURRENT_VERSION().
      9)      [spDRSSendChangesForGroup]: Определяются последние версии (USN) отправленные в целевой сайти (а также полученные). Эти данные извлекаются из таблицыDRS_MessageActivity иDRS_MessageActivity_Sent.
      10) [spDRSSendChangesForGroup]: Дальше происходит определение статей (таблица ArticleData), которые необходимо реплицировать. Статьи в данном случае это таблицы (нас интересует BoundaryEx). У каждой статьи есть группа репликации (в нашем случае 3). С помощью функций DatabaseChangeTracking определяется USNстатьи и, если USN статьи больше чем USN последней отправленной репликации, то статья попадает под процесс репликации.
      11) [spDRSSendChangesForGroup]: Сами данные необходимые для репликации  (измененные с момента последней удачной репликации) определяется с помощью хранимой процедуры SCCM_RDS_spGet<Имя статьи>Changes в случае если область репликации равна  site или с помощью функции SCCM_DRS.fnGet<Имя статьи>Changes в ином случае. Процедуры spGet<Имя статьи> существуют только на первичном сайте (не standalone), поскольку CAS не реплицирует данные с областью site. Последнее предложение справедливо и для вторичного сайта.
      12) [fn|spGet<имя статьи>Changes]: В этой функции (или процедуре) используется обычная конструкция TSQL  fromCHANGETABLE(CHANGES <имя таблицы>). Измененные данные возвращаются в формате XML или бинарном виде (после сериализации процедурой spDRSSerializeQuery). Бинарный вид данных используется только для области репликации site. Почему именно так – сказать не могу. Для Secondary-сайта также используются функции формата fnGet<имя статьи>ChangesSec. В этих функциях происходит фильтрация данных, реплицируемых на вторичный сайт или со вторичного сайта. Также на вторичном сайте перед формированием данных из репликации исключаются некоторые статьи (типа global_proxy) (ArticleData.OptionalFlag & 0x2 = 0x2).
      13) [spDRSSendChangesForGroup]: Далее отправляется сообщение типа DRS_StartSync сервису ConfigMgrDRS_Site<код целевого сайта> или ConfigMgrDRSSite_Site<Код целевого сайта> (из процедуры spDRSSendStartMsg). ConfigMgrDRSSite_Site<Код целевого сайта> используется для данных типа site.
      14) [spDRSSendChangesForGroup]: Если есть данные (отличные от данных типа site) для репликации, то далее изменения формируются в сообщения и отправляются с помощью процедуры spDRSSendDataMsg. Если сжатие для группы репликации (ReplicationData.Flags & 1 = 1, в моем случае везде NULL, то есть сжатие не используется) включено и размер сообщения > 2КБ, то происходит сжатие даннных с помощью функции fnCompressData.  Если сжатые данные больше чем изначальные, то сжатие не используется. Если используется сжатие, то тип сообщения DRS_SyncDataCompressed, иначе тип сообщения DRS_SyncData. Служба для отправки
      ConfigMgrDRS_Site<код-целевого-сайта>.
      Вот так выглядит сообщение DRS_SyncData:
      <DRS_SyncData BuildNumber="7711" LastSyncVersionToSource="1221127" ThisVersion="77819" SyncID="1B102B82-71B2-4051-8B2A-15C41E430354" ReplicationGroupID="3" MessageID="4D06DD9F-CBE0-4907-8139-C06955926D4B">
      <Operation Type="I" TableName="BoundaryEx" Context="">
      <row BoundaryID="8" Name="" CreatedBy="CM12\Administrator" CreatedOn="2012-11-18T20:46:20" ModifiedBy="CM12\Administrator" ModifiedOn="2012-11-18T20:46:20" BoundaryType="0" Flags="0" Value="192.168.59.0"/>
      </Operation>
      </DRS_SyncData>
      15) [spDRSSentDataMsg или spDRSSentBinaryDataMsg]: Длягрупп2 и 3 сообщениялогируютсяпроцедуройspDRSInsertSentMessage втаблицуDRSSentMessage. Можно конечно попробовать изменить текст функции fnISLogDrsMessageDataOn(в тестовой среде конечно) для изучения репликации, но Microsoft позаботился об этом и каждую минуту запускается код, который изменяет текст некоторых объектов на исходный. Если хотите посмотреть на содержимое сообщений, то лучше убрать проверку непосредственно в хранимых процедурах spDRSSentDataMsg и spDRSSentBinaryDataMsg. Также можно вставить некий код логирования в процедуры spDRSSentStartMsg и SpDRSSentEndMsg.
      16) [spDRSSendChangesForGroup]: Если есть данные сайта (sitescope) для репликации, то используется отправка бинарных данных. Этот тип данных и тип сообщения используется только для репликации данных сайта и измененные данные извлекаются с помощью процедуры SCCM_DRS.spGet<имя статьи>Changes. Отправка данных происходит в отдельной процедуре spDRSSentBinaryDataMsg.
      17) [spDRSSentBinaryDataMsg]: Отправка бинарных данных происходит по тому же принципу. Проверяется
      необходимость сжатия для группы данных и отправка сообщения DRS_SyncBinaryDataCompressed или DRS_SyncBinaryData. Теми же самыми механизмами определяется необходимость логирования данных. Сервис
      используется другой –
      ConfigMgrDRSSite_Site<код сайта>. Secondary-сайт не реплицирует данные с областью site, поэтому такой сервис отсутствует на сервере баз данных вторичного сайта. В бинарном виде сообщение не очень презентабельно, а вот после десериализации выглядит как обычная таблица:
      Это таблица Summarizer_Components.
      18)  [spDRSSendChangesForGroup]: Диалог репликации завершается вызовом процедуры spDRSSentEndMsg, в которой отправляется сообщение типа DRS_SyncEnd.
      19) [spDRSSendChangesForGroup]: Далее происходит очистка различных временных таблиц и обновление статуса репликации в таблице DRS_MessageActivity_Sent. Эта таблица постоянно используется для определения текущего статуса и для обновления статуса по ходу выполнения процесса.
       
      На другой стороне.
       
      Что же происходит на принимающей стороне?
      С принимающей стороной немного сложнее, поскольку используется в основном код CRL. Это несколько усложняет анализ.
      1)      [SMS_REPLICATION_CONFIGURATION_MONITOR]: На стороне приема для обработки используется CRLхранимая процедура – spDRSActivation, которая определена в сборке messagehandlerservice.dll (можно найти в binкаталоге SCCM). Метод для вызова процедуры– ServiceProcedure из класса Microsoft.ConfigurationManager.DataReplicationService.MessageHandlerService.
      2) [messagehandlerservice.dll]: В этой же сборке определены дополнительные классы и их методы для работы с сообщениями репликации.
      3) [messagehandlerservice.dll]: Извлекается сообщение, парсится, определяется его тип, метод кодирования. Из сообщения извлекаются данные для изменения, определяется зависимость данных и выполняется соответствующая хранимая процедура для внесения изменений в целевые таблицы. Для операции Delete вызывается процедура SCCM_DRS.spDelete<имя таблицы>. Для операций Insert или Update вызывается хранимая
      процедура
      SCCM_DRS.spUpsert<имя таблицы>.
      4) [spDRSDelete|spDRSUpsert]: В этих процедурах определены дополнительные проверки и методы обнаружения конфликтов. Обнаруженные конфликты логируются в таблицу DRSConflictInfo. Данные для изменения вносятся в целевые таблицы.
      5) [messagehandlerservice.dll]: Из дополнительных полезностей можно отметить логирование сообщений процедурой  spDRSInsertReceivedMessage. Необходимость логирования определяется все той же функцией fnIsLogDrsMessageDataOn (логируются группы 2 и 3). Сообщения на этот раз сохраняются в таблице DRSReceivedMessages.
       
      Вместо заключения.
      Вместо заключения хотелось бы перечислить ряд дополнительных методов,  с помощью которых можно  получить сведения о репликации баз данных в SCCM 2012:
      1) Область Monitoring консоли управления ConfigManager. С помощью узла DatabaseReplication(и его контекстных команд) можно получить сведения о статуе репликации, запустить диагностику.
      2) ТаблицыDRS_MessageActivity, DRS_MessageActivity_Send, DRS_MessageActivity_Receive. Эти таблицы используются в процессе репликации для отслеживания статуса, а также для внесения сведений о ресультатах репликации. В таблицах есть поле для ошибок, возникающих в ходе репликации. Расшифровку этих ошибок можно поискать в соответствующих процедурах или функциях, запускаемых во время репликации. Большую часть сведений из этих таблиц можно получить с помощью консоли управления.
      3) Процедура spDiagDRS. Эта процедура запрашивает данные с разных таблиц (в том числе и с DRS_MessageActivity*) и отображает информацию о статусе (DRS_MessageActivity*), статьях (ArticleData), группах репликации (ReplicationData) и т.д.. Также отображаются сведения о ServiceBroker.
      4) Стандартный отчет ServiceBroker. В SQLManagementStudioдоступен отчет, отображающий статистику ServiceBroker. Для запуска необходимо открыть контекстное меню папочкиService Broker (вManagement Studio) ивыбратьReports > Standard Reports > Service Broker Statistics. Данный отчет отображает различные диаграммы,
      состояние и статистику сервисов и очередей. Также отображаются базовые сведения о производительности
      Service Broker.

      • Полностью виртуальная инфраструктура на Hyper-V

         

        В этой небольшой статье хотелось бы рассказать про свой опыт использования виртуализации инфраструктуры на базе Hyper-V из состава Windows Server 2008 R2. Статья будет также применима и к Windows Server 2008 (R1). А если конкретно, то хотелось бы рассказать про проблему полной виртуализации инфраструктуры. Под полной виртуальной инфраструктурой я подразумеваю среду, где Hyper-V развернут в конфигурации Failover Cluster и все серверы, включая контроллеры доменов, виртуализируется.

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

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

        Решение.

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

        Вернемся к нашей инфраструктуре. Мы все-таки развернули кластер Hyper-V, перенесли все серверы, в том числе и контроллеры доменов, в виртуальную среду. Физические серверы либо задействовали в качестве узлов кластера, либо полностью вывели из эксплуатации. Виртуальные машины разместили на Cluster Shared Volume (CSV), дабы задействовать замечательную функцию Live Migration.

        Получилось следующее:

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

        Включают электричество, хосты Hyper-V начинают грузиться, а вот виртуальные машины не стартуют. Это происходит по следующей причине. Виртуальные машины являются ресурсами кластера, служба ClusterSvc должна, в соответствии с зависимостью ресурсов, поочередно их поднять (перевести в online-режим). Но служба кластеров сама зависит от службы каталогов, контроллеры доменов которой являются ресурсами кластера. Получается замкнутый круг.

        Есть традиционные способы решения данной проблемы:

        Использовать хотя бы один физический сервер для контроллеров доменов. Согласитесь, что при текущей производительности серверов, не совсем целесообразно потратить на контроллер доменов 5-10 тыс. долларов (с последующей утилизацией раз в 3-5 лет). Для инфраструктур, характеризующих себя как централизованные и средние по размерам, хотелось бы максимально утилизировать вычислительные ресурсы, абстрагироваться от аппаратного обеспечения, и все это сделать с минимальными затратами. Децентрализованные инфраструктуры могут такой проблемы не ощущать.

        Использовать хост Hyper-V как контроллер доменов. То есть, развертываем роль ADDS на одном из узлов Hyper-V. Это уже лучше, чем первый случай, но все же есть некоторые проблемы:

        Проблема безопасности и проблема делегирования полномочий. Если развернуть RWDC на Hyper-V хосте, то трудно будет ограничить администратора среды виртуализации от возможности воздействовать на службу каталогов. Сразу скажу, что здесь можно долго спорить на эту тему, поскольку можно сказать, что если есть физический доступ к хосту, то без проблем можно получить доступ к виртуальным машинам. И это верно. Поэтому оставлю тему безопасности за рамками данной статьи. Возьмем за веру, что проблема с безопасностью все же есть в этом случае. Также можно установить RODC и это решит некоторые проблемы с безопасностью, но возникают другие проблемы. Update: чуть позже накопал, что RODC не поддерживается на узлах кластера.  http://support.microsoft.com/kb/281662/en-us

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

        Проблема с лицензированием. Конечно, с лицензированием проблем здесь нет, но вот у вас проблемы появятся. Если хост Hyper-V выполняет какую-либо роль кроме виртуализации, то вы лишаетесь возможности в полной мере покрыть хостовой лицензией запущенные экземпляры виртуальных машин. Например, в случае с Standard-лицензией вообще лишаетесь возможности использовать хостовую лицензию для лицензирования одной запущенной виртуальной машины, а в случае с Enterprise – одной. То есть с Enterprise-лицензией можете лицензировать запуск не 4х виртуальных машин, а только трех.

        В оригинале это звучит так:

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

         

        А теперь, как я решал данную проблему.

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

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

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

         

        Некоторые рекомендации (и даже требования):

         

        1. Создавайте виртуальные машины с контроллерами доменов на дисках, не являющихся кластерными ресурсами. Это могут быть как локальные диски (DAS), так и диски с СХД.
        2. Режим запуска виртуальных машин: Always Automatically Turn On The Virtual Machine или Automatically Turn On The Virtual Machine If It Was Running When The Physical Server Was Stopped
        3. Для службы кластеров (ClusterSvc) необходимо произвести настройки восстановления. Те, что на вкладке «Восстановление» свойств службы ClusterSvc оснастки Services.msc. Для всех сбоев необходимо указать перезапуск службы. Не могу сказать какие конкретно значения для «Перезапуск служб через:» вам подойдут, необходимо подбирать их индивидуально. Я использовал 3 минуты.
        4. Сократите интервал отображения меню восстановления. Настроить можно с помощью апплета «Система» панели управления.На самом деле я слукавил, когда чуть выше сказал, что все прекрасно стартует. Не совсем. Может возникнуть дополнительная проблема.

        Проблема №2.

        Дело в том, что есть еще одна взаимозависимость: служба каталогов от DNS и DNS от службы каталогов.

        Возникает она по следующей причине. Контроллер домена, при старте, пытается произвести репликацию своих контекстов именования (это при условии, что контроллер в лесу не один): пока не произведет репликацию, не будет выполнять свои функции. Служба DNS, желая при старте работать с самыми актуальными данными, откладывает загрузку интегрированных в AD зон, до момента, когда служба каталогов реплицирует данные и оповестит об этом службу DNS. Репликация AD, как известно, зависит от DNS: контроллер домена пытается получить IP-адреса своих партнеров по репликации с помощью DNS. А DNS в это время не работает, поскольку ждет AD. AD ждет DNS, DNS ждет AD. В свою очередь от DNS также зависит кластер и аутентификация. Через какое-то время служба каталогов все-таки даст добро службе DNS и та загрузит зоны. Этот timeout зависит от количества разделов, которые обслуживает контроллер доменов и примерно составляет 20 минут для 5 разделов (для контроллеров с 2008 R2 я наблюдал намного меньшую задержку – 5 минут).

        20 минут для кого-то могут быть вполне допустимы, а для кого-то нет. Попробуем решить эту проблему.

         

        Способы:

         

        1. Использовать в качестве DNS сервера сервер с другой площадки. Скорее всего, в этом случае у вас не должно возникнуть и первой проблемы.
        2. Установить дополнительный физический сервер с ролью DNS. Этот сервер будет обслуживать вторичную зону для _msdcs корневого домена и доменную зону локального домена (главная задача разрешить DSAGUID партнера по репликации в FQDN и FQDN в IP-адрес) Этот способ конечно не подходит. Мы вернулись опять к проблеме с физическим сервером. В этом случае проще сразу развернуть физический контроллер доменов.
        3. Установить роль DNS на хосте Hyper-V? Можно, но получаем те же проблемы, что и обсуждались чуть выше.
        4. Отключить начальную репликацию. Это делается установкой значения Repl Perform Initial Synchronizations в 0 для ключа:

        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.  Можно, но не рекомендуется. Не рекомендуется хотя бы по той причине, что таким образом происходит попытка решить проблему с существованием в лесу (или домене) нескольких FSMO. Лучше такой способ не использовать.

        Использовать не интегрированные в AD зоны (полностью или частично). Знаете да, какие преимущества дает хранение зон в AD? Если вам эти преимущества не нужны, то можете использовать и этот способ.

         

        Сделать так, чтобы имя партнера по репликации разрешалось без участия DNS-сервера. Как это можно сделать? Способов много. Дополнительно стоит сказать, что, начиная с Windows Server 2003 SP1, появилась функция name resolution fallback, на тот случай если не удастся разрешить DSAGUID контроллера домена. Цепочка следующая: GUID -> FQDN -> NETBIOS-имя. То есть, если не удается разрешить CNAME GUID, то происходит попытка разрешить FQDN, если и это не удается сделать, то происходит попытка получить IP по NETBIOS-имени.

         

        Поэтому проблему можно решить:

         

        • Использованием HOSTS-файла. В хост файл можно внести запись о партнере по репликации. Можно добавить как GUID._msdcs.<имя_корневого_домена>, так и FQDN:

        <IP-адрес партнера по репликации> <DSA GUID>._mcdcs.<имя корневого домена>
        <IP-адрес партнера по репликации> <FQDN партнера по репликации>

         

        • Использованием файла LMHOST. Внести в файл соответствующую запись NETBIOS.
        • Использованием WINS-сервера. Наверное, наиболее предпочтительный способ.
        • Использованием NETBIOS-широковещания для разрешения имени. Если контроллеры доменов в одном широковещательном домене и Netbios-over-TCPIP не отключен (включен по умолчанию), то с проблемой №2 вы вообще не должны столкнуться.

         

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

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

         

        Как установить Hyper-V кластер: http://lmgtfy.com/?q=how+to+install+hyper-v+cluster

        О первоначальной репликации: http://support.microsoft.com/kb/305476/en-us

        О проблеме загрузки DNS-зон: http://support.microsoft.com/kb/2001093/en-us

        LMHOSTS: http://support.microsoft.com/kb/101927/en-us

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

        • Windows Events мониторы в Operations Manager 2007 R2

          Собственно, речь в данной статье пойдет об Unit-мониторах (Unit Monitors), а если точнее, то о Windows Events мониторах.

          Мне кажется Windows Event мониторы в SCOM 2007 R2 достаточно интересны и к тому же этот функционал мало где описан. SCOM 2007 R2 дает возможность создать 5 типов мониторов (Рисунок 1), плюс по некоторым типам есть разнообразные настройки, принцип функционирования которых не всегда очевиден.

          • Миграция базовой инфраструктуры 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.: появилась вторая часть статьи – читаем.

              • PKI: Мифы о мифах

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

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

              • Главная Networks, Windows, Без рубрики, Новое Active Directory, Windows 2008 R2
                • Вопросы по Active Directory + Ответы

                  logo Нашел в себе силы написать ответы на вопросы. Старался как можно полнее и яснее ответить на эти вопросы. Но сами понимаете, это достаточно трудно, да и если все детально описывать, то получится очередной resource kit. Пытался больше сосредоточиться на вопросах связанных с логикой работы AD, на другие вопросы предоставил ссылки в конце статьи. Большинство решений по вопросам проверены на практике или на стендах, на другие отвечал с использованием теории или логики. Будем верить, что теория не врет. По неясным вопросам готов пояснить дополнительно в комментариях («Истина рождается в споре»).

                  • Взрыв мозга. Вопросы по Active Directory.

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

                  • Главная Networks, Security, Windows, Без рубрики, Новое Active Directory, Security
                    • Безопасность в Active Directory. Часть 2.

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