Главная Security, Без рубрики, Новое Security, Windows Server 2008
  • Аудит файловых серверов. Полный контроль.

    Search

    Не так давно я писал статью об аудите Active Directory Domain Services средствами «человеческого» решения – NetWrix AD Change Reporter. Думаю всем прекрасно понятно, что аудит штука важная, нужная и увы не заканчивающаяся службой каталогов. Несмотря на 21 век файловые сервера живее всех живых и подавляющий процент файлов с данными хранится именно на них, что в свою очередь требует от ит четких ответов на следующие вопросы.

  • Главная Windows, Без рубрики, Новое IIS, Windows 2008 R2, Windows Server 2008
    • Установка и первоначальная настройка Joomla на Windows Web Server 2008

      Итак, почему Web Server 2008? Все очень просто, во-первых,  Web Server 2008 содержит роль  (IIS 7.0) необходимую для корректной работы Joomla. Во-вторых,  Internet Information Services 7 – это безопасная, управляемая и расширяемая платформа для веб-сайтов. На одном сервере с IIS можно устанавливать ASP.NET и PHP веб-приложения.  В третьих, IIS бесплатен, в редакции Windows Web Server 2008 не требуются лицензии клиентского доступа (лицензия требуется только на сервер). В четвертых, на нем могут работать самые распространенные  веб-приложения, и их довольно-таки много, это WordPress, Drupal, Moodle, nopCommerce, DotNetNuke Community, Wiki и другие. Легкость и быстрота установки, надежность и защищенность – все это говорит в пользу использования IIS.

    • Главная Virtualization, Windows, Без рубрики, Новое Virtualization, Windows 2008 R2, Windows Server 2008
      • Виртуализация сервера приложений 1С с аппаратным ключом

        13f561e539d0

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

        Многие знают, что для работы сервера приложений 1С необходим аппаратный HASP-ключ, выпускаемый в формате LPT-переходника или USB-донгла. В отношении виртуализации у компании 1С мнение весьма специфичное – раньше представители компании заявляли о невозможности работы сервера в виртуальной среде, а теперь предлагают приобрести программный ключ защиты вместе с новым комплектом ПО за 40000р.

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

      • Главная Windows, Без рубрики, Новое Office, Windows 2008 R2, Windows 7, Windows Server 2008, Общее, Пятничная тема
        • MS Office Vs OpenOffice: использование ресурсов компьютера

          8502 Зачастую сторонники Open Source движения в сравнениях своих решений с продукцией Microsoft используют превосходную степень «быстрее, выше сильнее» опуская технические детали. Не буду распыляться и попытаюсь опровергнуть утверждение, говорящее, что Open Office работает быстрее Microsoft Office 2007/2010 и лучше подходит для всего спектра компьютеров, среди которых встречаются и устаревшие модели со скромным процессором и количеством памяти.  Так ли это?

          Целью являлось тестирование производительности трех продуктов. Для чистоты эксперимента производительность тестировалась как с «родными» документами Word и Excel, так и с «родными» документами Writer и Calc.

           

        • Главная Windows, Без рубрики, Новое Windows 2008 R2, Windows Server 2008
          • TS Easy Print на практике

            imageВ качестве альтернативы использования традиционной системы печати в Windows 2008 появилась технология TS Easy Print, позволяющая избежать установки драйверов для перенаправленных принтеров на терминальном сервере. Благодаря этому значительно повышается стабильность работы как службы диспетчера очереди печати, так и всего терминального сервера в целом.

            Внедрение TS Easy Print не требуется дополнительной установки серверной и клиентской части. Достаточно лишь наличие на рабочей станции клиента удаленного рабочего стола версии 6.1 (или старше) и .NET Framework 3.0 SP1 (или старше).

            Статья разделена на два основных раздела.

            Первая часть посвящена способам настройки и управления технологией TS Easy Print при помощи групповых политик и консоли управления печатью.

            Во втором разделе собран практический опыт автора по использованию TS Easy Print, а также приведен ряд примеров из форумов Microsoft Technet.

            Настройка

            Для управления настройками печати на терминальном сервере в Windows Server 2008 существует несколько групповых политик. Найти их можно в следующем контейнере:

            Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Printer Redirection.

            В русскоязычном интерфейсе это

            Конфигурация компьютера\Административные шаблоны\Компоненты Windows\Службы терминалов\Сервер терминалов\Перенаправление принтеров (рис. 1).

            image

            Рис. 1. Групповые политики для управления перенаправленным принтерами

            Рассмотрим каждую из них более подробно.

            Таблица 1: Политики управления печатью на терминальных серверах

            Групповая политика (в скобках представлен

            русский вариант названия)

            Описание функциональности
            Do not set default client printer to be default printer in a session

            (Не устанавливать используемый по умолчанию

            принтер клиента в качестве принтера для сеанса)

            Определяет будет ли принтер по умолчанию на клиенте автоматически установлен как принтер по умолчанию в терминальной сессии. Если этот параметр не задан, пользователь может самостоятельно задать принтер по умолчанию в терминальной сессии.
            Do not allow client printer redirection

            (Не разрешать перенаправление клиентских принтеров)

            Позволяет запретить подключение клиентских принтеров к терминальной сессии. Включение этой политики отключает перенаправление принтеров.
            Specify terminal server fallback printer driver behavior

            (Задать поведение сервера терминалов при

            выборе резервного драйвера принтера)

            Не смотря на существование этой политики использовать её можно только на Windows Server 2003.
            Use Terminal Services Easy Print driver first

            (использовать в первую очередь драйвер принтера

            Easy Print служб терминалов)

            Если эта политика включена или не настроена, сервер терминалов сначала попытается использовать драйвер принтера TS Easy Print для установки всех клиентских принтеров. Если по какой-либо причине драйвер TS Easy Print не доступен, используется драйвер принтера на терминальном сервере, соответствующий принтеру на клиентском компьютере. Если драйвер не найден на терминальном сервере, этот принтер не может быть перенаправлен.
            Redirect only the default client printer (Перенаправлять

            только используемы по умолчанию принтер клиента)

            Включает перенаправление только принтера по умолчанию. Остальные принтеры не перенаправляются.

            Политики

            Use Terminal Services Easy Print Driver First

            и

            Redirect Only The Default Client Printer

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

            User Configuration\Policies\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Printer Redirection.

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

            Однако, даже не смотря на то, что системный администратор не может видеть принтеры других пользователей, есть обходной маневр для получения информации о перенаправленных принтерах и выполнения с ними ряда административных задач. Члены группы «Print Operators» («Операторы печати») могут увидеть все перенаправленные принтеры в консоли управления печатью «Print Management Console» и панели управления принтерами. Для этого необходимо выполнить следующие действия.

            1. Добавить себя в группу «Print Operators».

            2. Установить роль «Print Services» на сервер.

            3. Запустить консоль «Print Management».

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

            1. Открыть консоль управления печатью и щелкнуть правой клавишей мыши по выбранному принтеру.

            2. Выбрать «Properties».

            3. Перейти на закладку «Security».

            4. Нажать «Advanced».

            5. Перейти на закладку «Owner» (рис. 2).

            image

            Рис. 2. Захват прав владельца

            6. Выбрать «Print Operators» и дважды нажать «Ок».

            7. Закрыть все окна управления принтером.

            8. Заново открыть окно свойств принтера.

            9. Перейти на закладку «Security»

            10. Добавить группе «Print Operators» право «Manage Printer».

            image

            Рис. 3. Добавление прав управления

            Члены группы Print Operators должны использовать право Manage Printers только для выполнения следующих задач:

            · удаление перенаправленного принтера;

            · открытие очереди печати перенаправленных принтеров;

            · управление заданиями на печать для перенаправленных принтеров.

            Остальные действия, такие как переименование, установка для принтера свойств по умолчанию и предпочтений печати не поддерживаются.

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

            Особенности практического использования

            В этой части я хотел бы рассказать о проблемах которые могут возникнуть в процессе использования технологии TS Easy Print и способах их решения. Информация представлена в виде описания проблемы и возможного способа её решения. По возможности, проблема проиллюстрирована примерами из форумов Microsoft Technet.

            Проблема 1. Нестабильность службы диспетчера очереди печати

            Основной предпосылкой внедрения TS Easy Print являются сбои в службе диспетчера очереди печати при использовании драйверов для принтеров на терминальном сервере. Эта проблема также актуальна и в «смешанной» среде. Если на терминальном сервере параллельно используются как TS Easy Print, так и традиционная система печати, проблемы могут только усугубиться. Это связано с тем, что при перезапуске службы диспетчера очереди печати, перенаправленные принтеры переходят в состояние offline и становятся недоступными для печати. Для наиболее быстрого решения этой проблемы требуется переподключение терминального сеанса. Всё это вызывает массу негативных отзывов (пример на форумах Microsoft Technet) со стороны конечных пользователей.

            В качестве глобального решения этой проблемы можно рассмотреть полное удаление драйверов принтеров и сопутствующих им элементов с терминального сервера. Однако и эта операция может вызвать массу проблем (пример на форумах Microsoft Technet), так как вместе с драйверами принтеров могут удалиться драйвера Terminal Services Easy Print и Microsoft XPS Document Writer. Без них перенаправление принтеров по технологии TS Easy Print работать не будет.

            В связи с этим, необходимо крайне осторожно относиться к удалению драйверов на терминальном сервере при помощи специальных утилит:

            · KB2000007;

            · KB324757.

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

            Альтернативным способом является ручное удаление драйверов. Это делается следующим образом.

            1. Перейти в «Панель Управления».

            2. Выбрать «Принтеры»

            3. Щелкнуть «Свойства Сервера» (рис. 4)

            image

            Рис. 4. Свойства сервера печати

            4. Перейти на закладку «Драйверы» (рис .5)

            image

            Рис. 5. Драйверы принтеров

            5. Поочередно удалить все драйверы кроме Terminal Services Easy Print и Microsoft XPS Document Writer.

            Кроме того, можно дополнительно удалить данные из реестра и файловой системы. Более подробную информацию об этом можно получить в статье Print Spooler Crash Troubleshooting Steps.

            Если терминальные сервера находятся терминальной ферме, и для соединения с ними используется ключ /admin, то при проверке нужно учитывать, что при таком типе подключения TS Easy Print не работает по умолчанию (KB947723).

            Проблема 2. Печать «иероглифов» на перенаправленных принтерах»

            При печати по технологии TS Easy Print могут отображаться «иероглифы». Обычно это вызывается старой версией .Net Framework. Установка более новой версии данного программного продукта может решить данную проблему. Данная проблема актуальна для старых версий клиентских операционных систем. Для Windows 7 дополнительная установка .Net Framework необязательна.

            Проблема 3. Перенаправление принтеров не работает

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

            HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\rdpwd\fEnablePrintRDR.

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

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

            Для решения нужно дать права modify для группы everyone на папку: C:\Windows\System32\spool или воспользоваться статьей KB968605.

            Проблема 5. Снижение скорости печати

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

            Проблема 6. Не все принтеры перенаправляются в терминальную сессию

            По умолчанию число перенаправляемых принтеров ограничено 20. Это поведение можно исправить добавив в раздел реестра

            HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services

            ключ MaxPrintersPerSession и задав в нем максимальное число перенаправляемых принтеров.

            Проблема 7. Поддержка тонких клиентов

            Одним из основных минусов технологии TS Easy Print являются требования к версии клиента удаленного рабочего стола и установке .Net Framework. Достаточно много тонких клиентов (особенно произведенных несколько лет назад) не имеют достаточно дискового пространства для использования операционной системы, содержащей данные программные продукты. Для остальных можно воспользоваться новой версией Windows Embedded 2009.

            Заключение

            В статье рассмотрена практическая сторона использования технологии TS Easy Print. Особое внимание уделено проблемам, которые могут возникнуть при переходе на новую систему печати. Не смотря на достаточно большое число перечисленных проблем, следует отметить, что технология TS Easy Print уже зарекомендовала себя с самой лучшей стороны и может быть использована в производственных целях. В качестве альтернативы TS Easy Print могут использоваться сторонние программные продукты (например, ThinPrint). Однако следует учитывать, что большинство таких продуктов платные и требуют установки дополнительного программного обеспечения.

            Дополнительные ресурсы

            · Windows Server 2008 Terminal Services Resource Kit

            · Terminal Services Printing

            · Terminal Server Easy Print

            · WS2008: Terminal Services Printing

            · Introducing Terminal Services Easy Print: Part 1

            · WS2008: Terminal Services Architecture

            · Using Remote Desktop Easy Print in Windows 7 and Windows Server 2008 R2

            · Terminal Services Printer Redirection

            · Printer Redirection

            · Print Spooler Crash Troubleshooting Steps

          • Главная Windows, Без рубрики, Новое EasyPrint, Windows 2008 R2, Windows Server 2008
            • Сравнение TS Easy Print и традиционной системы печати

              clip_image002В Windows Server 2008 появилась относительно новая технология печати на перенаправленных принтерах из терминальных сессий – TS Easy Print. С её помощью можно избавиться от необходимости установки и использования драйверов для принтеров на терминальных серверах. В результате этого значительно улучшается стабильность службы диспетчера очереди печати и как следствие удобство работы для конечных пользователей. В статье предлагается сравнительный обзор алгоритмов работы традиционной модели системы печати и технологии TS Easy Print. Представленная информация собрана из немногочисленных публичных источников, приведенных в конце статьи. В связи с этим, автор заранее просит прощения в случае неверной интерпретации доступной ему информации.

            • Главная Windows, Без рубрики, Новое Active Directory, Windows 2008 R2, Windows Server 2008
              • Репликация Active Directory: Разговор на «Ты» (Продолжение)

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

                Межсайтовая репликация

                И вот ваша фирма обзавелась несколькими филиалами, каждый из которых имеет свое территориальное местоположение. Естественно эти офисы выделены в отдельные подсети, которые соединены WAN каналами и произведена настройка маршрутизации. Как быть в такой ситуации? Можно оставить все контроллеры в одном офисе и тогда клиентам не останется ничего кроме общения с контроллерами доменов по WAN-каналам. Конечно, данный трафик можно шифровать, используя IPsec, но как быть в случае падения WAN канала. Ведь при недоступности контроллера домена клиенты не смогут войти в сеть и начать работу в домене.

              • Главная Networks, Virtualization, Без рубрики Hyper-V, VLAN, Windows Server 2008
                • Hyper-V, VLAN и все-все-все.

                  title

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

                  На одном физическом сервере мы поднимали инфраструктуру из виртуальных машин, две из которых должны были работать во внутренней сети, а две других должны были быть подключены к внешним сетям (у нас подходит два канала от двух провайдеров). В качестве платформы виртуализации использовался Hyper-V на Windows Server 2008 Enterprise. Использование Enterprise редакции для платформы виртуализации позволяет по одной лицензии на хостовую машину установить еще 4 виртуальных сервера Windows Server 2008, что весьма выгодно в плане стоимости.

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

                  Сценарий, который мы применили, был достаточно прост:

                  base shema

                  На свитче создаются два VLAN, соответствующие двум провайдерам. В каждый VLAN добавляются access порты, в которые подключены провода, идущие от провайдеров, и то оборудование, которое должно смотреть в них напрямую (в данном случае, один служебный сервер, пара VPN железок и IP камера). Далее создается один транковый порт, в который подключается провод, идущий на хостовую машину. Через вторую сетевую карту хостовая машина имеет доступ к локальной сети. Таким образом, получается жесткое разделение сред и контроль над подключенным сетевым оборудованием.

                  Теперь о реализации.

                  В качестве свитча используется AT 9448T. Это управляемый 48 портовый свитч. Самый простой способ произвести настройку – подключиться через консольный порт тем же Putty. Достаточно просто выбрать вариант serial и установить скорость 115200. Появится черный экран, где надо будет нажать Enter, после чего появится приглашение. На всякий случай – стандартный логин/пароль у Телесинов – manager/friend (на старых свитчах, например, он был manager/Ctrl + ati).

                  Стандартный интерфейс настройки выглядит так:

                  at1

                  Однако, можно переключиться и в режим CLI, нажав C, как написано в меню (чтобы вернуться обратно, необходимо набрать команду menu). Мне больше нравится интерфейс с меню, для повседневных операций он удобнее.

                  Чтобы создать VLAN, необходимо зайти в меню VLAN Configuration, а там в Configure VLANs. Это меню позволяет создавать/изменять/удалять VLAN’ы. Сейчас необходимо создать. Для этого надо выбрать пункт Create VLAN и в появившемся меню настроить нужные параметры:

                  at2

                  Чтобы изменить параметр, необходимо нажать цифру, соответствующую нужному пункту.

                  После того, как все настроено, необходимо нажать C – Create VLAN.

                  Соответственно, Tagged Ports – порты на которых трафик маркируется, Untagged Ports – обычные порты, которые не маркируют трафик, то есть обычный access port.

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

                  Результат настройки приведен на рисунке:

                  at3

                  Теперь стоит сохранить конфигурацию. Для этого в главном меню надо нажать S – Save Configuration (этот пункт появляется после внесения изменений в конфигурацию). Дополнительно стоит включить RSTP (полезный протокол, например, позволит защититься от петель, он настраивается в меню Spanning Tree Configuration), настроить интерфейс (настраивается в меню System Administartion -> System Configuration), что позволит использовать SSH (настраивается в Security and Services), собирать информацию со свитча по SNMP (настраивается в System Administartion -> SNMP Configuration ). Но это все уже отдельная тема.

                  Следующий этап настройки – научить виртуальные машины общаться с нашим свитчом.

                  Для этого необходимо скачать с сайта производителя сетевой карты последнюю версию драйверов и утилит. В нашем случае это Intel Pro 1000 PM. Поэтому отправляемся на сайт Интела в раздел загрузки (http://downloadcenter.intel.com/default.aspx?lang=rus&iid=subhdr-RU+downloads) и выбираем нужное устройство. Качаем пакет (он называется Intel Ethernet Connections CD – http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&ProdId=3019&DwnldID=18664&lang=rus). Он несет в себе последнюю версию драйверов, набор PROSet и ANS (advanced network services). После установки перезагрузка не требуется. Теперь PROSet не имеет отдельного меню и значка в трее, он интегрируется в диспетчер задач.

                  Общие просетовские настройки:

                  proset1

                  Работа с VLAN:

                  proset2

                  Работа с teams:

                  proset3

                  Также, тут есть одна интересная тонкость.

                  ans1

                  ans2

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

                  Поэтому, если адаптер используется Hyper-V, нужно убрать с него привязку, чтобы можно было произвести конфигурацию. Единственное, отвязывать интерфейсы надо аккуратно, желательно имея возможность физического доступа, если что-то пойдет не так. Самый идеальный вариант – IP KVM. У Dell, например, есть замечательная штука – iDRAC, которая дает полное удаленное управление физическим сервером.

                  Собственно, теперь для выполнения нашей задачи необходимо создать два VLAN. Для этого на соответствующей вкладке PROSet необходимо нажать New и указать тот VID, который мы дали соответствующему VLAN’у при настройке свитча. После добавления обоих VLAN’ов будут созданы два виртуальных адаптера, которые уже можно будет забиндить виртуальным машинам.

                  В результате получится следующая картина:

                  adapters

                  На ней:

                  cbs и trunk – два физических адаптера. cbs – подключен к внутренней сети, trunk – к транковому порту на свитче.

                  cbs_virtual – виртуальный адаптер, созданный в диспетчере виртуальной сети Hyper-V, который подключается к виртуальным машинам.

                  VLAN_comcor и VLAN_tascom – соответственно виртуальные адаптеры, которые созданы при помощи PROSet на адаптере trunk и промаркированы соответствующими тегами.

                  virtual_comcor и virtual_tascom – также виртуальные адаптеры, созданные в диспетчере виртуальной сети Hyper-V, которые подключаются к виртуальным машинам.

                  Теперь приведу иллюстрацию глазами диспетчера виртуальной сети Hyper-V:

                  manager

                  Таким образом, для Hyper-V существует три сетевых адаптера, которые он может дать виртуальным машинам.

                  И уже финальный шаг – привязка адаптера к виртуальной машине:

                  web

                  Здесь необходимо также указать VID того VLAN’а, к которому подключен данный интерфейс.

                  Таким образом, получается, что данный сетевой адаптер подключен к транковому каналу и на основе маркировки кадров он определяется как входящий в VLAN, к которому подключен провайдер Комкор. Однако виртуальная машина ничего об этом не знает, для нее существует только линк до роутера провайдера.

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

                  За сим все 🙂

                  Отдельно, огромная благодарность Руслану Карманову и его УЦ “Advanced training”, без их ICND1,2 было бы сильно грустно во всем этом разбираться. Естественно, это неприкрытая реклама углубленного курса  CCNA 😉

                • Главная Windows, Без рубрики, Новое Remote Desktop, Windows Server 2008
                  • TS Session Broker

                    images Terminal Services Session Broker (посредник сеансов служб терминалов) – служба, позволяющая объединить несколько терминальных серверов в ферму. В предыдущей версии операционной системы подобной функциональностью обладала служба Terminal Server Session Directory. Она позволяла восстанавливать незавершенные сеансы при повторном соединении пользователя. В Windows Server 2008 эта служба была переименована, а также в ней добавился функционал по балансировке подключений. С помощью TS Session Broker можно обеспечить не только равномерную (по числу сессий) нагрузку на терминальные сервера, но и задать удельный вес сервера в ферме. Это позволяет направить большее число сессий на более производительные серверы.

                  • Главная Windows, Без рубрики, Новое Active Directory, Group Policy, Windows 2008 R2, Windows Server 2008
                    • Репликация Active Directory: Разговор на «Ты»

                      logoОдна из главных рекомендаций Microsoft касательно Active Directory Domain Services (ADDS) говорит о необходимости развертывания в производственной среде минимум двух контроллеров домена. Реальная же жизнь показывает, что в средних и крупных компаниях количество контроллеров может достигать нескольких десятков и даже сотен. Когда системный администратор начинает работать в крупной сети на базе ADDS одной из самых важных забот становится репликация Active Directory.

                       

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

                      Впервые появившись в Windows Server 2000 технология Active Directory (это прежде всего транзакционная база данных содержащая информацию об объектах вашей сети и глубоко интегрированная с системой безопасности Windows) более чем за 9 лет претерпела некоторые изменения, но даже в Windows Server 2008 R2 работает на хорошо зарекомендовавшем себя движке Extensible Storage Engine ( ESE ). Если верить расчетам масштабируемости, данного решения должно хватить даже сетям с несколькими миллионами объектов, а вырасти база, может до 16 террабайт. Сердцем Active Directory является файл NTDS.DIT в котором, собственно говоря, вся информация и хранится. При добавлении второго и последующих контроллеров домена происходит создание копии данного файла, и размещение ее на введенном в строй новом контроллере. Т.е можно сделать четкий вывод: каждый контроллер домена хранит свою версию файла NTDS.DIT.

                      Важно понимать, что при открытии оснастки для работы с Active Directory, а это может быть Active Directory Пользователи и Компьютеры или как вариант Active Directory Сайты и Сервисы, вы всегда подключаетесь к конкретному контроллеру домена и при желании можете выбрать с каким контроллером работать – это означает, что выработаете с конкретной версией базы данных, которая в данный момент может отличаться от других копий. Естественно создавая учетную запись либо меняя конфигурацию, изменения вносятся только в один файл NTDS.DIT, который находится на контроллере, куда подключена оснастка (или любой другой инструмент управления). После внесения изменений критически важно оповестить другие контроллеры об изменениях и новых данных и как можно скорее произвести синхронизацию. В Active Directory этот процесс синхронизации называется репликацией и в дальнейшем я буду использовать именно этот термин. Особенно важно помнить эти факты, когда вы занимаетесь решением проблем с репликацией Active Directory и вносите изменения в контекст конфигурации AD. Это происходит тоже на конкретном контроллере и с конкретным файлом NTDS.DIT.

                      Физически NTDS.DIT это просто один файл, но логически он состоит из нескольких разделов (иногда их называют контекстами именования или контекстами репликации), каждый из которых содержит определенную информацию и реплицируется по-своему.

                      Раздел «Schema» – хранит в себе схему ActiveDirectory, которая описывает, какие объекты могут быть созданы, и что они из себя будут представлять. Меняется реже всего, как правило, при переходе контроллеров на новую операционную систему либо при установке в организации почтовой системы Exchange. Процесс изменения базы данных в контексте схемы чаще всего называют расширением схемы и это не случайно, т.к. отменить эти изменения (например, удалить созданные в этом контексте объекты) невозможно. Репликация раздела осуществляется на все контроллеры домена в лесу Active Directory. Единственный раздел, чья репликация не является мультимастерной. Репликация раздела «Schema» всегда односторонняя и выполняется от контроллера домена, владеющего ролью FSMO Хозяин Схемы, на все оставшиеся контроллеры домена. (Впоследствии оставшиеся контроллеры домена реплицируют информацию своим репликационным партнерам, но источником обновления в  этой цепочке репликации всегда будет Хозяин схемы)

                      image

                      Рис. 1 Разделы базы Active Directory

                      Раздел «Configuration» – содержит информацию о конфигурации Active Directory, в частности описывает, какие и сколько доменов создано, как они между собой связанны, сколько существует сайтов, какие сервисы доступны в организации и просто системные настройки службы каталогов такие как квоты, политики LDAP-запросов, правила неточного поиска, разрешения имен объектов и т.п.. Раздел реплицируется между всеми контроллерами доменов в лесу и может быть изменен на любом контроллере домена. Изменения данного раздела связаны с конфигурированием и настройкой самой Active Directory.

                      Раздел «Domain» – или доменный. Все учетные записи пользователей, группы безопасности, организационные подразделения, объекты компьютеров и принтеров создаются и хранятся в данном разделе. Реплицируется раздел только между контролерами домена в том домене к которому принадлежит контроллер. Получается, что в организациях, имеющих несколько доменов, в каждом домене будет свой раздел «Domain».

                      Разделы «Application» – опциональные разделы. Зона репликации зависит от настройки. Как правило, создается два Application раздела, это ForestDNSZones и DomainDNSZones.

                      · ForestDNSZones – хранит SRV и CNAME записи для Леса AD и реплицируется на все контроллеры домена в лесу, являющиеся DNS серверами.

                      · DomainDNSZones – содержит DNS записи для зоны домена. Реплицируется на все контроллеры домена с установленным на них DNS сервером.

                      Посмотреть на каждый раздел каталога и данные в нем хранящиеся можно через утилиты ADSI Edit AdExplorer и LDP.exe. Утилиту (AdExplorer) можно скачать с сайта Microsoft, она входит в комплект утилит Sysinternals. А LDP.exe становится доступна после установки на контроллер домена Windows Support Tools. Следует отметить, что данный комплект не потерял своей актуальности и после выхода Windows Server 2008.

                      image

                      Рис. 2 Выбор раздела для подключения в утилите LDP.exe

                      Теперь важно уяснить следующее, когда клиент аутентифицируется на контроллере домена, и применяются групповые политики, образуется трафик (85 Кб на вход станции в домен (с Default Domain Policy) и 75Кб на вход пользователя (тоже с Default Domain Policy)). Более того репликация изменений между контроллерами доменов порождает свой репликационный трафик. Этим трафиком нужно управлять, представьте себе, что организация и естественно ваш домен Active Directory располагается в двух городах связанных WAN каналом и однажды все пользователи филиала в Ростове-на-Дону начнут обращаться к контроллеру, расположенному в центральном Московском офисе. А контроллеры домена начнут реплицировать информацию в любое время и по первому желанию. Минимум с чем Вам придется столкнуться это высокая утилизация WAN канала и медленный вход пользователей в домен.

                      Поэтому в Active Directory введено понятие Сайтов. Сайт это логическое объединение контроллеров домена и клиентов для управления служебным трафиком службы каталогов. Если ваш Лес Active Directory не распространяется за пределы одного сегмента локальной сети, следовательно, вы работаете с односайтовой структурой. Именно она является дефолтной и именно с неё мы начнем разговор.

                      При создании Active Directory и поднятии (имеется ввиду процедура dcpromo) первого контроллера домена формируется сайт по-умолчанию с именем «Default-First-Site-Namе». Если не создавать дополнительных сайтов и придерживаться односайтовой структуры, все новые контроллеры будут попадать в данных сайт. После появления второго и последующих контроллеров должны образоваться Репликационные связи (connection objects), указывающие на то какой контроллер и откуда должен реплицировать изменения. Посмотреть эти связи можно через оснастку «Active Directory Сайты и Службы».

                      На Рис.3 открыта оснастка «ActiveDirectoryСайты и Службы» и по имеющейся информации можно сказать, что в данном примере имеется единственный сайт по-умолчанию, в котором находится два контроллера домена Server1 и Server2. А так же, что Server1 имеет партнера по репликации Server2 и реплицирует с него изменения. Без наличия данных связей репликации между контроллерами работать не будет.

                      Нередки случаи когда системные администраторы, установив новый контроллер домена, не находят у него данных связей и начинают создавать их руками. Это распространенная ошибка. За создание связей, базируясь на определенной логике, отвечает служба KCC (Knowledge Consistency Checker). Созданию связей самостоятельно чревато возникновением ошибок и дальнейшей путаницей. Для тех же, кто не хочет ждать, пока KCC справится с задачей, существует способ ее поторопить.

                      image

                      Рис. 3 Свойства Репликационной связи.

                      Для этого необходимо использовать утилиту Repadmin с ключом kcc. Синтаксис будет выглядеть следующим образом:

                      repadmin /kcc server1.itband.ru (Вместо server1.itband.ru вы укажете FQDN вашего сервера)

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

                      repadmin /kccsite: «Default-First-Site-Name» (Если имя сайта было изменено «Default-First-Site-Name» заменяется реальны именем)

                      Можно так же запустить процесс генерации топологии на всех контроллерах леса командой repadmin /kcc *. Большинство опций команды repadmin поддерживают ключ /async, который дает задание контроллеру домена и при этом не ожидает его завершения.

                      Без административного вмешательства служба KCC стартует на каждом контроллере домена раз в 15 минут и в случае необходимости добавляет или удаляет лишние репликационные связи (учтите, что связи, созданные вручную, не управляются KCC). Логика создания связей в рамках одного сайта кажется довольно простой, каждый контроллер не реплицируется с каждым, служба KCC всегда пытается создать кольцо репликации, причем по мере добавления новых контроллеров кольцо будет расширяться. Расширение не бесконечно, при создании связей существует «правило трех прыжков». Это значит, что между двумя контроллерами домена при репликации не может быть больше трех посредников.

                      image

                      Рис. 4 Принцип создание связей репликации службой KCC

                      Как только число контроллеров достигнет 8 штук, правило «трех прыжков» приведет к тому, что служба KCC выполнит «ход конем» и добавит дополнительные прямые связи, тем самым сокращая расстояние между двумя любыми контроллерами до допустимого значения «максимум в три прыжка». Данная ситуация хорошо проиллюстрирована на рисунке 4. Создание связей между контроллерами расположенными в разных сайтах выполняется с учетом топологии сайтов, сайт-линков и мостов между сайт-линками. Подробнее о построении межсайтовой репликации читайте в разделе «межсайтовая репликация». Следует отметить, что кольцо при построении топологии репликации строиться независимо для каждого контекста репликации (раздела Active Directory) далее эти кольца накладываются друг на друга и выясняется, где можно вместо нескольких репликационных связей – обойтись одной.

                      Внутрисайтовая репликация начинается, когда в Active Directory происходит изменение, это может быть изменение атрибута или создание учетной записи. Контроллер домена, в базе которого произошли изменения, ожидает 15 секунд, а затем отправляет ближайшему партнеру репликации уведомление о том, что на нем произошло какое-то обновление. При наличии двух и более партнеров по репликации, последующие уведомления отправляются каждому партнеру с 3-секундной задержкой (Верно для уровня леса Windows 2003 и выше, для Windows 2000 первичная задержка составляет 300 секунд, а последующие 45 секунд). После получения уведомления об изменении партнер репликации проверяет возможность репликации и список обновлений и выполняет процесс репликации с тем контроллером, который прислал уведомление. Трех секундная задержка предотвращает чрезмерную загрузку из-за одновременных запросов обновлений от множества партнеров по репликации. Периоды нотификаций можно настроить командой repadmin /notifyopt.

                      Следует обратить особое внимание читателей, что процесс репликации ВСЕГДА происходит в режиме pull, т.е. «стягивания» изменений и новых объектов, но не в режиме push. Это связано с тем, что только контроллер хозяин файла NTDS.DIT имеет право в нем что-то изменять и отвечает за целостность своей БД. Из этого так же следует, что ВСЕ линки репликации которые, создаются в ручную или службой KCC имеют однонаправленную природу, т.е. логически обозначают входящий поток репликационной информации.

                      Некоторые изменения реплицируются без 15-секундной задержки. Такая репликация, называемая срочной (urgent replication). В события ее вызывающие входят блокировки учетных записей, изменение пароля учетной записи. В официальных документах присутствует путаница. По сути это не репликация вовсе и механизм передачи этих изменений в коре отличается от процесса репликации. Хотя в качестве транспорта используется тоже протокол RPC. Такая репликация выполняется не обычным механизмом репликации, а специальными вызовами RPC. По сути это запросы аналогичные изменению объектов через ADSI. В зависимости от режима работы леса список событий может меняться.

                      Если внимательно присмотреться к свойствам репликационной связи, то можно найти расписание репликации, по умолчанию оно установлено на ежечасный запуск. Возникает вопрос: Зачем еще одно расписание если есть система уведомлений?

                      image

                      Рис. 5 Расписание репликации

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

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

                      repadmin /replicate server2.itband.ru server1. itband.ru dc=itband,dc=ru

                      С ключем /replicate необходимо задать куда (server2.itband.ru ) и с какого контроллера (server1.itband.ru ) должны реплицироваться данные, а также какой раздел каталога нужно реплицировать (dc=itband,dc=ru).

                      Запустить репликацию всех разделов Active Directory в рамках всего леса (в рамках существующей топологии) довольно легко, для это следует выполнить: Repadmin /syncall /AeS. Учтите, что в крупных сетях такой запуск репликации может вызвать серьезный поток трафика, который пойдет не только по скоростным каналам.

                      Алгоритм распространения изменений

                      Теперь необходимо разобраться, как после получения репликационного уведомления от партнера контроллер домена решит: Есть или нет изменения необходимые для репликации ? Если есть то, какие объекты или их отдельные атрибуты должны быть прореплицированы. Алгоритм выглядит следующим образом.

                      Любой контроллер домена ведет некий счетчик называемый «highestCommittedUSN», который увеличивается на единицу при любом атомарном изменении базы Active Directory. При этом у каждого контроллера домена этот счетчик свой и между контроллерами его значения не совпадают. Например, в 9 утра значение «highestCommittedUSN» у контроллера DC1 было равно 14879, а в 6 вечера 14896. Это значит, что за прошедшее время в базе этого контроллера произошло 17 изменений. Посмотреть значение «highestCommittedUSN» можно с помощью утилиты ldp просто подключившись к нужному контроллеру домена. При подключении выводиться состояние динамического системного объекта RootDSE, среди атрибутов которого как раз и присутствует «highestCommittedUSN».

                      image

                      Рис. 6 Просмотр значения «highestCommittedUSN» на контроллере домена.

                      После проведенной репликации каждый контроллер домена кэширует значения «highestCommittedUSN» своих репликационных партнеров. И когда в последствии контроллер домена DC1 получит уведомление от контроллера DC2 в нем будет информация о текущем «highestCommittedUSN» DC2. Контроллеру DC1 останется только сравнить текущий «highestCommittedUSN» с тем, который он закэшировал во время прошлой репликации. Если он вырос : значит в базе DC2 произошли изменения и необходимо произвести репликацию. Если остался прежним, то в ней нет необходимости.

                      Таблица, в которой хранится информация о «highestCommittedUSN» репликационных партнеров называется вектором обновления или «up-to-date vector». Посмотреть ее можно с помощью утилиты repadmin.

                      repadmin /showutdvec dc1 dc=lab,dc=itband,dc=ru

                      Default-First-Site-Name\DC2 @ USN 16667 @ Time 2009-09-21 01:24:15

                      Default-First-Site-Name\DC1 @ USN 20704 @ Time 2009-09-21 01:31:25

                      В данном примере результатом будет вывод значений «highestCommittedUSN» репликационных партнеров DC1 (а также актуальный USN его самого), при этом это будут значения, о которых DC1 знает, в действительности уже они могли вырасти по причине внесения изменения в базу на тех контроллерах. Следует помнить, что «highestCommittedUSN» увеличивается как после изменений внесенных в базу непосредственно на контроллере, так и после изменений прореплицированных с других контроллеров.

                      image

                      Рис. 7 Просмотр вектора обновлений на контроллере DC1.

                      Есть одно но, сам по себе «up-to-date vector» отвечает на вопрос «Были ли изменения?». Этого недостаточно, необходимо вычислить что изменилось. Давайте рассмотрим данный механизм на примере.

                      В нашей сети находится два синхронизированных контроллера домена (DC1и DC2 ). До изменений «highestCommittedUSN» у DC1 равен 20902, а у DC2 16940. На контроллере DC1 создается учетная запись пользователя Федя Рашпин. После создания учетной записи «highestCommittedUSN» на DC1 стал показывать 20909. Это говорит о том, что было произведено 7 изменений. Напоминаю, что считаются атомарные изменения, т.е создание учетной записи можно разложить на само создание плюс изменение ряда атрибутов, которые выполняет оснастка Active Directory Users and Computers.

                      Если подключиться через LDP.exe к нашему объекту пользователь, то можно увидеть два атрибута uSNCreated и uSNChanged.

                       

                      image

                      Рис. 8 Просмотр атрибутов uSNCreated и uSNChanged для учетной записи.

                      uSNCreated будет говорить, какой «highestCommittedUSN» был в момент создания объекта на данном контроллере, а uSNChanged в момент последнего изменения. Получается, что первый показатель (uSNCreated) будет оставаться неизменным, а второй в свою очередь (uSNChanged) по мере обновлений объекта будет расти. Важно понимать, что uSNCreated и uSNChanged на каждом контроллере домена у объекта будут свои.

                      Посмотрим на пользователя Федя через утилиту repadmin. Для получения служебной информации, используемой при репликации задействуем ключ /showmeta.

                      repadmin /showmeta “CN=Федя Рашпин,OU=testou,DC=lab,DC=itband,DC=ru”

                      При этом нас интересует информация с каждого контроллера. Но начнем с DC1.

                      image

                      Рис. 9 Вывод метаданных о созданном пользователе на DC1.

                      Какую же информацию нам дает repadmin (Рис. 9). Данный список не что иное, как объект пользователя, разложенный по атрибутам.

                      По каждому атрибуту можно увидеть:

                      · Loc.USN это «highestCommittedUSN» контроллера DC1 в момент внесения последних изменений.

                      · Originating DC говорит о том, на каком контроллере были произведены последние действия с этим атрибутом, т.е откуда пошло распространение.

                      · Org.Usn это «highestCommittedUSN» контроллера автора изменений в момент внесения последних.

                      · Ver – версия атрибута, растет на единицу при каждом его изменении (локально или в результате репликации).

                      · Attribute – непосредственно название самого атрибута.

                      Взглянув на эту таблицу можно сделать вывод, что пользователь «Федя Рашпин» был создан (или изменен) на контроллере домена DC1, при этом увидеть, что «highestCommittedUSN» DC1 в процессе создания учетной записи рос от 20904 до 20909. (Org.USN)

                      Совпадение колонок Loc.USN и Org.USN говорит о том, что запуск repadmin /showmeta произведен на контроллере домена, который был автором изменений. Если выполнить тоже самое на втором контроллере, результат будет несколько другой.

                      image

                      Рис. 10 Вывод метаданных о созданном пользователе на DC2.

                      На DC2 четко просматривается, что автором всех изменений (кроме одного) был DC1 и его «highestCommittedUSN» (Org.Usn) в момент изменения каждого атрибута. А также «highestCommittedUSN» в момент внесения обновлений в базу контроллера DC2. (Loc.USN)

                      А вот теперь пора сделать небольшой вывод:

                      Когда контроллер домена рассылает репликационным партнерам уведомления об обновлении базы, он сообщает свой текущий «highestCommittedUSN». Партнер, получивший это уведомление, сравнивает этот «highestCommittedUSN» с тем, что он запомнил с прошлой процедуры репликации. Если он вырос, значит необходимо запускать репликацию. Например: DC2 получил от DC1 уведомление и текущий «highestCommittedUSN» равный 20912, он сравнивает с известным ему значением 20850. Делает вывод о необходимости репликации и запрашивает изменения, произошедшие в период роста «highestCommittedUSN» с 20850 до 20912.

                      DC1 осуществляет выборку из своей базы. Для этого просматривается Loc.USN и те атрибуты, которые менялись в заданном диапазоне «highestCommittedUSN» реплицируются на DC2.

                      Решение конфликтов

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

                      Правило первое: Можно было заметить в метаданных репликации параметр Ver. Как уже было сказано, он увеличивается на единицу каждый раз при изменении атрибута. Если сразу на двух контроллерах происходит изменение атрибута, в первую очередь будет произведено сравнение номера версии. Атрибут, имеющий более высокий номер версии, является приоритетным. И именно его значение будет использоваться.

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

                      В такой ситуации будет задействован скрытый контейнер LostAndFound, получить доступ, к которому можно только переключив оснастку «Active Directory – пользователи и компьютеры» в расширенный режим.

                      image

                      Рис. 11 Контейнер LostAndFound.

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

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

                      image

                      Рис. 12 Автоматическое разрешение конфликта

                      Большим преимуществом с точки зрения репликации является переход на режим работы домена Windows Server 2003 и более поздние. В них изменилась процедура репликации атрибутов типа «linked-valued» (пример «Членство в группах»). При добавлении разных пользователей на разных контроллерах в одну и туже группу результатом будет членство всхе добавленных пользователей в составе этой группы. В случае с Windows 2000 состав группы при таком конфликте определялся бы по ее членству на том контроллере, на котором изменения в группе были бы сделаны позже по времени.

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

                       

                      Илья Рудь

                      Константин Леонтьев

                      http://kleontiv.spaces.live.com/

                      Статья опубликована в журнале “Системный администратор” от 01.2010