Так вийшло в нашій організації, що інфраструктуру треба було робити швидко, а на покупку ліцензій потрібен час. Тому було вирішено використати образи Windows Server 2012R2 Evaluation, після тестового періоду вже ліцензувати. Тоді ще ніхто не знав, що не можна просто так взяти, прописати ліцензію Standard у релізі Evaluation, і на виході отримати ліцензійний Standard, інакше, думаю, спочатку все-таки купили ліцензії. Але робити нічого, що маємо, з тим і працюємо. Отже.

Завдання:після покупки ліцензій Microsoft на Windows Server 2012R2 Standard необхідно активувати їх на наших серверах. Приступаємо.

Під час виконання завдання було виявлено проблему. Так як спочатку ми встановлювали Windows Server 2012R2 Standard Evaluation, то при спробі прописати ключ для Standard – сервер каже, що йому цей ключ не підходить. Почали пошук вирішення проблеми перекладу сервера з версії Evaluation до Standard. Відповідь було знайдено на сайті microsoft у статті TechNet.

Частково стаття допомогла вирішити проблему. Ми змогли змінити версію на трьох фізичних серверах та активувати їх нашими ліцензіями. Але, на жаль, не все так просто складалося з контролерами домену. У вищезазначеній статті прямим текстом говориться, що контролери домену НЕМОЖЛИВО перевести з випуску Evaluation до Standard. Нам же це необхідно зробити в самі найкоротший термін, т.к. кількість можливих /rearm у PDC закінчилася, а днів до закінчення ознайомлювальної версії залишилося менше 3 днів.

Варіанту вирішення питання я бачив два. Або по черзі між BDC і PDC передавати права власника схеми та інші ролі, знижувати до рядових серверів і потім піднімати назад. Але ідею цього доменного волейболу я відмів, тому що просто робив усе це вперше і боявся поламати.

Тому було вирішено піднімати новий сервер, підвищувати до контролера домену і передавати йому господаря схеми, а потім вимикати старий PDC і призначати його новий IP, цей варіант тоді мені здався простіше і безпечніше. Зауважу, що після описаних нижче подій, я, як і раніше, вважаю це гарним рішенням, за Крайній мірівсе пройшло без ексцесів, інакше стаття мала зовсім інший заголовок, або її не було б зовсім.

Схему можна відтворити без проблем протягом робочого дня. Залишалося півтора дня, так що, мріяти про те, як я все це робитиму часу не було, треба було терміново приступати. Далі по пунктах.

1. Створюємо нову віртуальну машинуз параметрами, що відповідають поточному PDC. Бажано створити на фізичному сервері, на якому немає інших контролерів домену, але це якщо у вас кілька гіпервізорів, як у моєму випадку, якщо ні, то це не принципово, питання лише у відмовостійкості. Ну а якщо ви працюєте не з гіпервізорами, а з реальними серверами, то стійкість до відмови PDC і BDC річ і так само собою зрозуміла.

2. Встановлюємо Windows Server 2012R2. Вибираємо випуск Standard із графічним інтерфейсом. Налаштовуємо TCP/IP і перейменовуємо сервер відповідно до стандартних найменувань в IT інфраструктурі.

3. Після встановлення в диспетчері серверів включаємо нові ролі. Нас цікавить AD, DNS та інші ролі та компоненти, що використовуються на поточних домен-контролерах.

4. Підвищуємо сервер до контролера домену. Проходить реплікація між основним контролером домену та новим.

5. Передаємо ролі господаря схеми зі старого DC на новий.
Для цього заходимо на контролер домену, якому призначатимуться ролі FSMO, запускаємо командний рядок, і вводимо команди у наведеній нижче послідовності:

ntdsutil
roles
connections
connect to server<имя сервера PDC>
q

Успішно підключившись до сервера, ми отримаємо запрошення до управління ролями (FSMO maintenance) і можемо приступати до передачі ролей:

transfer naming master- Передача ролі господаря доменних імен.
transfer infrastructure master- передача ролі господаря інфраструктури;
transfer rid master- передача ролі господаря RID;
transfer schema master- передача ролі господаря схеми;
transfer pdc- передача ролі емулятора PDC

Для завершення роботи Ntdsutil вводимо команду q.

6. Після передачі господаря схеми дивимось системний журналі dcdiag щодо помилок. Їх не повинно бути. Якщо є, виправляємо. (я зіткнувся з помилкою dns, де сервер скаржився на неправильно вказані сервера пересилання. У цей же день я дізнався, що в серверах пересилання DNS не повинен бути вказаний сервер, на якому встановлено DNS (зазвичай вказують сервера DNS-провайдераі Yandex (Google), що загалом логічно, це по суті породжує петлю в DNS.

7. Якщо помилки виправлені, або їх немає. Приступаємо до змін IP-адрес. Призначаємо старому PDC будь-яку вільну IP-адресу в мережі, а новому PDC призначаємо адресу старого.

8. Знову перевіряємо на помилки. Проводимо тести. Вимикаємо старий PDC та BDC. Перевіряємо можливість авторизації у домені. Потім залишаємо включеним тільки BDC, перевіряємо чи він бере на себе роль контролера домену у разі недоступності PDC.

9. Якщо всі випробування проходять успішно. Можна знищувати старий PDC і братися за зміну версії BDC.

10. У нашому випадку старий PDC все ще не можна було викинути на смітник так як на ньому функціонувала роль простору імен DFS, а ми не знали, як її реплікувати на новий сервер.

11. Все виявилося дуже просто. Входимо до графічного оснащення «Керування DFS». У «Просторі імен» додаємо існуючі простори імен, потім кожному простору імен додаємо сервер простору імен і взагалі все. Корінь dfsавтоматично разом із посиланнями на мережеві ресурси з'являється на c:\ і все працює. Про всяк випадок перевіряємо роботу вимкненням старого PDC. Спочатку мережні ресурси будуть недоступні (DFS потрібно 300 секунд для реплікації). Через 5 хвилин мережні ресурси знову мають стати доступними.

12. Залишаємо старий PDC вимкненим і через якийсь час знижуємо до рядового сервера і після видаляємо. Можна звичайно й одразу, але мені було страшно, і я до останнього не вірив, що все вийшло без проблем.

PS:Усі вищеописані дії проводилися після уважного вивчення книги Windows server 2012R2 - Повне керівництво. Зокрема глав присвячених саме AD, DNS і DFS, а як і контролерам домену. Без розуміння та планування до цих дій краще не приступати, т.к. можна втратити робочу інфраструктуру.

Сподіваюся, для когось ця стаття виявиться корисною та потрібною. Дякую за увагу!

Будучи добре знайомим із малим бізнесом зсередини, мене завжди цікавили такі питання. Поясніть, чому працівник повинен користуватися на робочому комп'ютері тим браузером, який подобається сісадміну? Або взяти будь-яке інше програмне забезпечення, наприклад, той самий архіватор, поштовий клієнт, клієнт миттєвих повідомлень… Це я плавно натякаю на стандартизацію, причому не за ознаками особистої симпатії сисадміну, а за ознаками достатності функціоналу, вартості обслуговування та підтримки цих програмних продуктів. Почнемо вважати ІТ точною наукою, а не ремеслом, коли кожен робить так, як у нього виходить. Знову ж таки, з цим у малому бізнесі теж дуже багато проблем. Уявіть, що компанія в нелегкий кризовий час змінює кількох таких адміністраторів, що робити в такій ситуації бідним користувачам? Постійно переучуватись?

Давайте подивимося з іншого боку. Будь-який керівник повинен розуміти, що він зараз відбувається в компанії (у тому числі і в ІТ). Це необхідно для відстеження поточної ситуації, для оперативного реагування на виникнення різноманітних проблем. Але це розуміння є важливішим для стратегічного планування. Адже, маючи міцний і надійний фундамент, ми можемо будувати будинок на 3 поверхи або на 5, робити дах різної форми, балкони або зимовий сад. Так само і в ІТ, маємо надійну основу – можемо надалі використовувати більш складні продукти та технології для вирішення бізнес-завдань.

У першій статті й ​​йтиметься про такий фундамент – служби Active Directory. Саме вони покликані стати міцним фундаментом ІТ-інфраструктури компанії будь-якого розміру та будь-якого напряму діяльності. Що це таке? Ось давайте про це і поговоримо.

А розмову почнемо з простих понять– домену та служби Active Directory.

Домен– це основна адміністративна одиниця в мережній інфраструктурі підприємства, до якої входять усі мережеві об'єкти, такі як користувачі, комп'ютери, принтери, загальні ресурсиі багато іншого. Сукупність таких доменів називається лісом.

Служби Active Directory (служби активного каталогу) є розподілену базу даних, яка містить всі об'єкти домену. Доменне середовище Active Directory є єдиною точкою автентифікації та авторизації користувачів та додатків у масштабах підприємства. Саме з організації домену та розгортання служб Active Directory починається побудова ІТ-інфраструктури підприємства.

База даних Active Directory зберігається на виділених серверах – контролерах домену. Служби Active Directory є роллю серверних операційних систем Microsoft Windows Server. Служби Active Directory мають широкі можливостімасштабування. У лісі Active Directory може бути створено понад 2 мільярди об'єктів, що дозволяє впроваджувати службу каталогів у компаніях із сотнями тисяч комп'ютерів та користувачів. Ієрархічна структурадоменів дозволяє гнучко масштабувати ІТ-інфраструктуру на всі філії та регіональні підрозділи компаній. Для кожної філії або підрозділу компанії може бути створений окремий домен зі своїми політиками, своїми користувачами та групами. До кожного дочірнього домену можуть бути делеговані адміністративні повноваження місцевим системним адміністраторам. При цьому дочірні домени підпорядковуються батьківським.

Крім того, служби Active Directory дозволяють налаштувати довірчі відносиниміж доменними лісами. Кожна компанія має власний ліс доменів, кожен із яких має власні ресурси. Але іноді буває потрібно надати доступ до своїх корпоративним ресурсамспівробітникам іншої компанії – робота з загальними документамита додатками в рамках спільного проекту. Для цього між лісами організацій можна налаштувати довірчі стосунки, що дозволить співробітникам однієї організації авторизуватись у домені іншої.

Для забезпечення стійкості до служби Active Directory необхідно розгорнути два або більше контролерів домену в кожному домені. Між контролерами домену забезпечується автоматична реплікація всіх змін. У разі виходу з ладу одного з контролерів домену працездатність мережі не порушується, адже продовжують працювати. Додатковий рівеньвідмовостійкість забезпечує розміщення серверів DNS на контролерах домену в Active Directory, що дозволяє в кожному домені отримати кілька серверів DNS, які обслуговують основну зону домену. І у разі відмови одного з DNS серверов, продовжать працювати інші. Про роль і значущість серверів DNS в ІТ-інфраструктурі ми ще поговоримо в одній із статей циклу.

Але це все технічні аспективпровадження та підтримки працездатності служб Active Directory. Давайте поговоримо про ті переваги, які отримує компанія, відмовляючись від однорангової мережі з використанням робочих груп.

1. Єдина точка аутентифікації

У робочій групіна кожному комп'ютері чи сервері доведеться вручну додавати повний списоккористувачів, яким потрібно мережевий доступ. Якщо раптом один із співробітників захоче змінити свій пароль, його потрібно буде поміняти на всіх комп'ютерах і серверах. Добре, якщо мережа складається із 10 комп'ютерів, але якщо їх більше? При використанні домену Active Directory всі облікові записи користувачів зберігаються в одній базі даних, і всі комп'ютери звертаються до неї за авторизацією. Усі користувачі домену включаються до відповідних груп, наприклад, «Бухгалтерія», «Фінансовий відділ». Достатньо один раз задати дозволи для тих чи інших груп, і всі користувачі отримають відповідний доступ до документів та додатків. Якщо в компанію приходить новий співробітник, для нього створюється обліковий запис, який включається до відповідної групи, співробітник отримує доступ до всіх ресурсів мережі, до яких йому повинен бути дозволений доступ. Якщо співробітник звільняється, достатньо заблокувати – і він відразу втратить доступ до всіх ресурсів (комп'ютерів, документів, додатків).

2. Єдина точка управління політиками

У робочій групі всі комп'ютери є рівноправними. Жоден із комп'ютерів не може керувати іншим, неможливо проконтролювати дотримання єдиних політик, правил безпеки. При використанні єдиного каталогу Active Directory, всі користувачі та комп'ютери ієрархічно розподіляються за організаційним підрозділам, до кожного з яких застосовуються єдині групові політики. Політики дають змогу встановити єдині параметри та параметри безпеки для групи комп'ютерів та користувачів. При додаванні до домену нового комп'ютера або користувача він автоматично отримує настройки, що відповідають прийнятим корпоративним стандартам. За допомогою політик можна централізовано призначити користувачам мережні принтери, встановити необхідні програми, встановити параметри безпеки браузера, налаштувати програми Microsoft Office.

3. Підвищений рівень інформаційної безпеки

Використання служб Active Directory значно підвищує рівень безпеки мережі. По-перше – це єдине та захищене сховище облікових записів. У доменному середовищі всі паролі доменних користувачів зберігаються на виділених серверах контролерах домену, які зазвичай захищені від зовнішнього доступу. По-друге, при використанні доменного середовища для аутентифікації використовується протокол Kerberos, який значно безпечніший за NTLM, що використовується в робочих групах.

4. Інтеграція з корпоративними додаткамита обладнанням

Великою перевагою служб Active Directory є відповідність стандарту LDAP, який підтримується іншими системами, наприклад, поштовими серверами(Exchange Server), проксі-серверами (ISA Server, TMG). Причому це не обов'язково тільки продукти Microsoft. Перевага такої інтеграції полягає в тому, що користувачу не потрібно пам'ятати велика кількістьлогінів та паролів для доступу до того чи іншого додатку, у всіх додатках користувач має одні й ті самі облікові дані – його автентифікація відбувається в єдиному каталозі Active Directory. Windows Server для інтеграції з Active Directory надає протокол RADIUS, який підтримується великою кількістю мережевого обладнання. Таким чином, можна, наприклад, забезпечити аутентифікацію доменних користувачів при підключенні з VPN ззовні, використання Wi-Fiточок доступу в компанії.

5. Єдине сховищеконфігурації додатків

Деякі програми зберігають свою конфігурацію в Active Directory, наприклад, Exchange Server. Розгортання служби каталогів Active Directory є обов'язковою умовоюдо роботи цих додатків. Зберігання конфігурації програм у службі каталогів є вигідним з точки зору гнучкості та надійності. Наприклад, у випадку повної відмови сервера Exchange, вся його конфігурація залишиться недоторканою. Для відновлення працездатності корпоративної пошти, достатньо буде інсталювати Exchange Server в режимі відновлення.

Підбиваючи підсумки, хочеться ще раз акцентувати увагу на тому, що служби Active Directory є серцем ІТ-інфраструктури підприємства. У разі відмови вся мережа, всі сервери, робота всіх користувачів будуть паралізовані. Ніхто не зможе увійти в комп'ютер, отримати доступ до своїх документів та програм. Тому служба каталогів має бути ретельно спроектована та розгорнута, з урахуванням усіх можливих нюансів, наприклад, пропускну здатністьканалів між філіями або офісами компанії (від цього залежить швидкість входу користувачів в систему, а також обмін даними між контролерами домену).

UPD:Створив відеоканал на youtube куди поступово викладаю навчальні відео по всіх областях ІТ, в яких добре розуміюся, підписуйтесь: http://www.youtube.com/user/itsemaev

UPD2:Мікрософт традиційно змінює звичний синаксис у командному рядку, тому ролі у кожний версії Windows Server може звучати по-різному. Вони взагалі тепер не fsmo називаються, а operation masters. Так ось, для коректних команд у консолі після fsmo maintenance напишіть просто? і він вам покаже доступні команди.

У мене в квітневий журнал "Системний адміністратор" взяли статтю на тему "Безболісна заміна застарілого або контролера домену, що відмовив, на базі Windows Server"

І навіть сто доларів заплатили і дали пакет із мізками)) Я тепер Онотоле.

Безболісна заміна застарілого або контролера домену, що відмовив, на базі Windows Server.(кому раптом треба - картинки надішлю)

Якщо ваш контролер домену вийшов з ладу або повністю застарів і вимагає заміни - не поспішайте планувати провести найближчі вихідні за створенням нового домену на новому сервері і копітким перенесенням в нього користувацьких машин. Грамотне керуваннярезервним контролером домену допоможе швидко та безболісно замінити попередній сервер.

Практично кожен адміністратор, який працює із серверами на базі Windows, рано чи пізно стикається з необхідністю заміни повністю застарілого основного контролера домену, подальший апгрейд якого більше не має сенсу, на новий і більш відповідний сучасним вимогам. Бувають ситуації і гірше - контролер домену просто приходить у непридатність через поломки на фізичному рівні, а резервні копії та образи застаріли, або загубилися
В принципі опис процедури заміни одного контролера домену на інший можна знайти на різних форумах, але інформація дається уривками і, як правило, застосовна тільки до конкретної ситуації, Проте фактичного рішення дає. Крім того, навіть вдосталь начитавшись форумів, баз знань та інших ресурсів на англійською- я зміг грамотно провести процедуру заміни контролера домену без помилок лише з третього чи вчетвертого разу.
Таким чином, я хочу навести поетапну інструкціюзаміни контролера домену незалежно від того чи працездатний він чи ні. Єдина різниця полягає в тому, що при контролері, що «впав», ця стаття допоможе тільки якщо ви заздалегідь подбали і розгорнули резервний контролердомену.

Підготовка серверів до підвищення/зниження ролі

Сама процедура створення резервного контролера домену елементарна – ми просто запускаємо на будь-якому сервері мережі майстер dcpromo. За допомогою майстра dcpromo створюємо контролер домену у існуючому домені. В результаті виконаних маніпуляцій ми отримуємо розгорнуту службу каталогів AD на нашому додатковому сервері(я називатиму його pserver, а основний контролер - dcserver).
Далі, якщо dcpromo сам не запропонував – запускаємо встановлення DNSсервера. Жодних налаштувань змінювати не треба, зону створювати також не треба - вона зберігається в AD, і всі записи автоматично реплікуються на резервний контролер. Увага - основна зона DNS з'явиться тільки після реплікації, для прискорення якої сервер можна перезавантажити. У налаштуваннях TCP/IP мережної карти резервного контролера домену адресою первинного DNS сервера має бути вказана ip-адреса основного контролера домену.
Тепер можна легко перевірити працездатність резервного контролера домену pserver. Ми можемо створити користувача домену як на основному, так і на резервному контролері домену. Відразу після створення він з'являється на дублюючому сервері, але десь протягом хвилини (поки відбувається реплікація) - він показаний як відключений, після чого починає відображатися однаково на обох контролерах.
На перший погляд усі дії зі створення справної схеми взаємодії кількох контролерів домену виконані, і тепер, у разі виходу з ладу «основного» контролера домену, «резервні» контролери автоматично виконуватимуть його функції. Однак, хоча різниця між «основним» та «резервним» контролерами домену чисто номінальна, «основний» контролер домену має низку особливостей (ролі FSMO), про які не варто забувати. Таким чином, вищенаведених операцій для нормального функціонування служби каталогів при відмові «основного» контролера домену недостатньо, і дії, які треба зробити для грамотної передачі/захоплення ролі основного контролера домену будуть описані нижче.

Трохи теорії

Потрібно знати, що контролери домену Active Directory виконують кілька видів ролей. Ці ролі називаються FSMO (Flexible single-master operations):
- Schema Master(Господар схеми) - роль відповідає за можливість зміни схеми - наприклад, розгортання Exchange server або ISA server. Якщо власник ролі буде недоступний – схему існуючого доменуви змінити не зможете;
- Domain Naming Master (Господар операції іменування доменів) - роль необхідна в тому випадку, якщо у вашому доменному лісі є кілька доменів або піддоменів. Без неї не вдасться створювати та видаляти домени в єдиному доменному лісі;
- Relative ID Master (Господар відносних ідентифікаторів) – відповідає за створення унікального ID для кожного об'єкта AD;
- Primary Domain Controller Emulator (Емулятор основного контролера домену) – саме він відповідає за роботу з обліковими записами користувачів та політику безпеки. Відсутність зв'язку з ним дозволяє входити робочі станції зі старим паролем, який не можна змінити, якщо контролер домену «упав»;
- Infrastructure Master (Господар Інфраструктури) - роль відповідає за передачу інформації про об'єкти AD іншим контролерам домену в рамках всього лісу.
Про ці ролі досить докладно написано у багатьох базах знань, але основну роль практично завжди забувають - це роль Global Catalog (Глобального Каталогу). За фактом, цей каталог просто запускає LDAP сервіс на порту 3268, але саме його недоступність не дозволить доменним користувачамвходити у систему. Що примітно - роль глобального каталогуможуть мати всі контролери домену одночасно.

Фактично можна зробити висновок - якщо у вас примітивний домен на 30-50 машин, без розширеної інфраструктури, що не включає піддомени - то відсутність доступу до власника/власників перших двох ролей ви можете не помітити. Крім того, мені кілька разів траплялися організації, які працюють більше рокувзагалі без контролера домену, але у доменній інфраструктурі. Тобто всі права були роздані давно, при працюючому контролері домену, і не потребували зміни, паролі користувачі собі не змінювали і спокійно працювали.

Визначення поточних власників ролей fsmo.

Уточнюю - ми грамотно хочемо замінити контролер домену, не втративши жодних можливостей. У тому випадку, якщо в домені два або більше контролерів, нам необхідно з'ясувати, хто є володарем кожної з ролей fsmo. Це досить просто зробити, використовуючи такі команди:

dsquery server -hasfsmo schema
dsquery server - hasfsmo name
dsquery server - hasfsmo rid
dsquery server - hasfsmo pdc
dsquery server - hasfsmo infr
dsquery server -forest -isgc

Кожна з команд виводить нам інформацію про те, хто є власником ролі, що запитується (рис.1). У нашому випадку власник всіх ролей - основний контролер домену dcserver.

Добровільна передача ролей fsmo за допомогою консолей Active Directory.

Вся інформація, необхідна передачі ролі основного контролера домену ми маємо. Приступаємо: для початку потрібно переконатися в тому, що наш обліковий запис входить до груп «Адміністратори домену», «Адміністратори схеми» та «Адміністратори підприємства», а потім розпочати традиційним методомпередачі ролей fsmo - керування доменом через консолі Active Directory.

Для передачі ролі "господаря іменування домену" виконуємо такі кроки:
- відкриваємо Active Directory Домени і Довіра на тому контролері домену, з якого ми хочемо передати роль. Якщо ми працюємо з AD на тому контролері домену, якому хочемо передати роль, то наступний пункт пропускаємо;
- клацаємо правою кнопкоюмиші на значку Active Directory — домени та довіра та вибираємо команду Підключення до контролера домену. Вибираємо той контролер домену, якому хочемо передати роль;
- клацаємо правою кнопкою миші компонент Active Directory - домени та довіру та вибираємо команду Господарі операцій;
- у діалоговому вікні Зміна господаря операцій натискаємо кнопку Змінити (рис. 2).
- після ствердної відповіді на запит, що спливає, отримуємо успішно передану роль.

Аналогічно, за допомогою консолі «Active Directory – користувачі та комп'ютери» можна передати ролі «господар RID», «основний контролер домену» та «господар інфраструктури».

Для передачі ролі «власника схеми» необхідно попередньо зареєструвати в системі бібліотеку управління схемою Active Directory:

Після того як всі ролі передані залишається розібратися з опцією, що залишилася - зберігачем глобального каталогу. Заходимо в Active Directory: «Сайти та Служби», сайт за замовчуванням, сервера, знаходимо контролер домену, що став основним, і у властивостях його NTDS settings ставимо галочку навпроти global catalog. (Рис. 3)

Підсумок – ми поміняли господарів ролей для нашого домену. Кому потрібно остаточно позбавитися старого контролера домену - знижуємо його до рядового сервера. Однак простота виконаних дій окупається тим, що їх виконання у низці ситуацій неможливе, або закінчується помилкою. У таких випадках нам допоможе ntdsutil.exe.

Добровільна передача ролей fsmo за допомогою ntdsutil.exe консолей.

На випадок, якщо передача ролей fsmo за допомогою консолей AD не вдалося, Microsoft створив дуже зручну утиліту - ntdsutil.exe - програма обслуговування каталогу Active Directory. Цей інструмент дозволяє виконувати надзвичайно корисні дії- аж до відновлення всієї бази даних AD із резервної копії, яку ця утиліта сама створила під час останньої змінив AD. З усіма її можливостями можна ознайомитись у базі знань Microsoft(Код статті: 255504). У даному випадкуми говоримо про те, що утиліта ntdsutil.exe дозволяє як передавати ролі, так і відбирати їх.
Якщо хочемо передати роль від існуючого «основного» контролера домену до «резервного» - ми заходимо у систему на «основний» контролер і починаємо передавати ролі (команда transfer).
Якщо у нас з якихось причин відсутній основний контролер домену, або ми не можемо увійти під адміністративним обліковим записом – ми входимо в систему на резервний контролер домену і починаємо «відбирати» ролі (команда seize).

Отже, перший випадок - основний контролер домену існує і функціонує нормально. Тоді ми заходимо на основний контролер домену та набираємо наступні команди:

ntdsutil.exe
roles
connections
connect to server имя_сервера (того кому хочемо віддати роль)
q

Якщо вискакують помилки - потрібно перевірити зв'язок із тим контролером домену, якого ми намагаємося підключитися. Якщо помилок немає - значить ми успішно підключилися до вказаного контролера домену з правами користувача, від імені якого вводимо команди.
Повний список команд доступний після запиту fsmo maintenance стандартним знаком? . Настав час передавати ролі. Я відразу, не замислюючись, вирішив передавати ролі в тому порядку, в якому вони вказані в інструкції до ntdsutil і прийшов до того, що не зміг передати роль господаря інфраструктури. Мені у відповідь на запит про передачу ролі поверталася помилка: «неможливо зв'язатися з поточним власником ролі fsmo». Я довго шукав інформацію в мережі і виявив, що більшість людей, що дійшли до етапу передачі ролей, стикаються з цією помилкою. Частина з них намагається відібрати цю роль примусово (не виходить), частина залишає все як є - і живе без цієї ролі.
Я ж шляхом спроб і помилок з'ясував, що при передачі ролей у даному порядкугарантується коректне завершення всіх кроків:
- господар ідентифікаторів;
- господар схеми;
- господар іменування;
- господар інфраструктури;
- Контролер домену;

Після успішного підключення до сервера ми отримуємо запрошення до управління ролями (fsmo maintenance) і можемо почати передавати ролі:
- transfer domain naming master
- transfer infrastructure master
- transfer rid master
- transfer schema master
- transfer pdc master

Після виконання кожної команди має виходити запит про те, чи дійсно ми хочемо передати вказану роль. вказаному серверу. Результат успішного виконання команди показаний на рис.4.

Роль зберігача глобального каталогу передається способом, описаним у попередньому розділі.

Примусове надання ролей fsmo за допомогою ntdsutil.exe.

Другий випадок - ми хочемо надати нашому резервному контролеру домену роль основного. У цьому випадку нічого не змінюється - єдина різниця в тому, що ми проводимо всі операції з використанням команди seize, але вже на тому сервері, якому хочемо передати ролі для присвоєння ролі.

seize domain naming master
seize infrastructure master
seize rid master
seize schema master
seize pdc

Зверніть увагу - якщо ви відібрали роль у контролера домену, який відсутній у Наразі, то при його появі в мережі контролери почнуть конфліктувати і проблем у функціонуванні домену вам не уникнути.

Робота над помилками.

Найголовніше, що не слід забувати - новий основний контролер домену сам собі налаштування TCP/IP не виправить: йому адресою первинного DNS сервера тепер бажано (а якщо старий контролер домену + DNS сервер будуть відсутні, то обов'язково) вказати 127.0.0.1 .
При цьому якщо у вас є DHCP сервер, то потрібно змусити його видавати адресою первинного DNS сервера ip вашого нового сервера, якщо DHCP немає - пройтися по всіх машинах і прописати їм цей первинний DNS вручну. Як варіант, можна призначити новому контролеру домену той же ip, що був у старого.

Тепер необхідно перевірити як все працює і позбавитися основних помилок. Для цього я пропоную на обох контролерах стерти всі події зі збереженням журналів у папку з іншими резервними копіямиі перезавантажити всі сервери.
Після їхнього включення уважно аналізуємо всі журнали подій на факт появи попереджень та помилок.

Найпоширенішим попередженням, після передачі ролей fsmo, є повідомлення про те, що «msdtc не може коректно обробити підвищення/зниження ролі контролера домену».
Виправляється просто: у меню «Адміністрування» знаходимо «Служби
компонентів». Там розкриваємо "Служби компонентів", "Комп'ютери", відкриваємо властивості розділу "Мій комп'ютер", шукаємо там "MS DTC" і тиснемо там "Налаштування безпеки". Там дозволяємо "Доступ до мережі DTC" і тиснемо ОК. Служба буде перезапущена та попередження зникне.

Прикладом помилки може бути повідомлення у тому, що основна DNS зона може бути завантажена, чи DNS сервер не бачить контролер домену.
Розібратися в проблемах функціонування домену можна за допомогою утиліти (рис. 5):

Встановити цю утиліту можна з оригінального диска Windows 2003 із папки /support/tools. Утиліта дозволяє перевірити працездатність всіх служб контролера домену, кожен етап повинен закінчуватися словами successfully passed. Якщо у вас виходить failed (найчастіше це тести connection або systemlog), то помилку можна спробувати вилікувати в автоматичному режимі:

dcdiag /v /fix

Як правило, всі помилки, пов'язані з DNS, повинні зникнути. Якщо ні – користуємось утилітою перевірки стану всіх мережевих служб:

І її корисним інструментомусунення помилок:

netdiag /v /fix

Якщо і після цього залишаються помилки пов'язані з DNS - найпростіше видалити з нього всі зони та створити вручну. Це досить просто - головне створити основну зону на ім'я домену, що зберігається в Active Directory і реплікується на всі контролери домену в мережі.
Більше детальну інформаціюпро помилки DNS дасть ще одна команда:

dcdiag /test:dns

По закінченню виконаних робіт у мене пішло десь 30 хвилин на з'ясування причини появи ряду попереджень - я розібрався з синхронізацією часу, архівацією глобального каталогу та іншими речами, до яких раніше не доходили руки. Тепер все працює як годинник – найголовніше не забудьте завести резервний контролер домену, якщо ви хочете видалити старий контролер домену з мережі.

Як мовиться "раптом звідки ні візьмись з'явився ........", ні чого не віщувало біди, але тут почав глючити основний контролер домену, і поки він ще дихав вирішив делегувати права основного домену на інший.

Для передачі ролі "господаря іменування домену" виконуємо такі кроки:

Після того як всі ролі передані залишається розібратися з опцією, що залишилася – зберігачем глобального каталогу. Заходимо в Directory: «Сайти та Служби», сайт за замовчуванням, сервера, знаходимо контролер домену, що став основним, і у властивостях його NTDS settings ставимо галочку навпроти global catalog. (Рис. 3)

результат – ми змінили власників ролей для нашого домену. Кому потрібно остаточно позбутися старого контролера домену - знижуємо його до рядового сервера. Однак простота виконаних дій окупається тим, що їх виконання у низці ситуацій неможливе, або закінчується помилкою. У таких випадках нам допоможе ntdsutil.exe.

Добровільна передача ролей fsmo при консолях ntdsutil.exe.

На випадок, якщо передача ролей fsmo при консолях AD не вдалося, створив дуже зручну утиліту - ntdsutil.exe - обслуговування каталогу Directory. Цей інструмент дозволяє виконувати надзвичайно дії – аж до всієї бази даних AD із резервної копії, яку ця сама створила під час останньої зміни AD. З усіма її можливостями ознайомитись у знаннях (Код статті: 255504). В даному випадку ми говоримо про те, що ntdsutil.exe дозволяє передавати ролі, так і «відбирати» їх.

Якщо ми хочемо передати роль від існуючого «основного» контролера домену до «резервного» – ми заходимо на «основний» контролер і починаємо передавати ролі (команда transfer).

Якщо у нас з якихось причин відсутній основний контролер домену, або ми не можемо увійти під адміністративний обліковий – ми входимо до резервного контролера домену і починаємо «відбирати» ролі (команда seize).

Отже, випадок – основний контролер домену існує і функціонує нормально. Тоді ми заходимо на основний контролер домену та набираємо наступні команди:

ntdsutil.exe

connect to имя_сервера (того кому хочемо віддати роль)

Якщо вискакують помилки – потрібен зв'язок із тим контролером домену, якого ми намагаємося підключитися. Якщо помилок немає – ми успішно підключилися до вказаного контролера домену з правами того користувача, від імені якого вводимо команди.

Повний список доступний запит fsmo maintenance стандартним знаком? . Настав час передавати ролі. Я відразу, не замислюючись, вирішив передавати ролі в тому порядку, в якому вони вказані в інструкції до ntdsutil і прийшов до того, що не зміг передати роль господаря інфраструктури. Мені у відповідь на запит про передачу ролі поверталася помилка: «неможливо зв'язатися з поточним власником ролі fsmo». Я довго шукав інформацію в і виявив, що більшість людей, що дійшли до етапу передачі ролей, стикаються з цією помилкою. Частина з них намагається відібрати цю роль примусово (не виходить), частина залишає все як є - і живе без цієї ролі.

Я ж шляхом спроб і помилок з'ясував, що при передачі ролей у даному порядку гарантується коректне завершення всіх кроків:

Господар ідентифікаторів;

Власник схеми;

Господар іменування;

Хазяїн інфраструктури;

Контролер домену;

Після успішного сервера ми отримуємо запрошення до управління ролями (fsmo maintenance), і можемо почати передавати ролі:

- transfer domain naming master

Transfer infrastructure master

Transfer rid master

Transfer schema master

Transfer pdc master

Після виконання кожної повинен виходити запит про те – чи ми хочемо передати зазначену роль зазначеному серверу. Результат успішного виконання показаний на (рис.4).

Роль зберігача глобального каталогу передається способом, описаним у попередньому розділі.

Примусове надання ролей fsmo при ntdsutil.exe.

Другий випадок – ми хочемо надати нашому резервному контролеру домену роль основного. У цьому випадку нічого не змінюється - єдина різниця в тому, що ми проводимо всі операції з використанням seize, але вже на тому сервері, якому хочемо передати ролі для присвоєння ролі.

seize naming master

seize infrastructure master

seize rid master

seize schema master

Зверніть увагу - якщо ви відібрали роль у контролера домену, який відсутній в даний момент, то при його появі в контролери почнуть конфліктувати, і проблем у функціонуванні домену вам не уникнути.

Робота над помилками.

Найголовніше, про що не слід забувати – новий основний контролер домену сам собі TCP/IP не виправить: йому адресою первинного DNS тепер бажано (а якщо старий контролер домену + DNS будуть відсутні, то обов'язково) вказати 127.0.0.1. вас є DHCP сервер, то потрібно змусити його видавати адресою первинного DNS ip вашого нового сервера, якщо DHCP немає - пройтися по всіх машинах і прописати їм цей первинний DNS вручну. Як варіант, призначити новому контролеру домену той же ip що був у старого. Тепер необхідно як все працює і позбавитися основних помилок. Для цього я пропоную на обох контролерах стерти всі події зі збереженням журналів в папку з іншими резервними копіями і перезавантажити всі сервери.Після їх включення уважно всі журнали подій на факт появи попереджень і помилок. , Що «msdtc не може коректно обробити підвищення / зниження ролі контролера домену, що відбулося». Виправляється просто: в з оригінального

Якщо і цього залишаються помилки пов'язані з DNS - всього видалити з нього всі зони і створити вручну. Це досить просто - головне створити основну зону на ім'я домену, що зберігається в і реплікується на всі контролери домену в мережі.

Більш детальну інформацію про помилки DNS надасть ще одна команда:

dcdiag /test:dns

Після закінчення виконаних робіт у мене пішло десь 30 хвилин на з'ясування причини появи ряду попереджень - я розібрався з синхронізацією часу, архівацією глобального каталогу та іншими речами, до яких раніше не доходили руки. Тепер все працює як годинник - найголовніше не забудьте завести резервний контролер домену, якщо ви хочете видалити старий контролер домену з мережі.

Щоб не вдаватися в велике число спеціальних термінів, контролери доменів є серверами, які підтримують роботу Active Directory. Вони зберігають інформацію про облікові записи користувачів та комп'ютерів, що входять до домену, схему, а також власну копію бази даних Active Directory, яка підтримує запис. Крім цього, контролери домену виступають у ролі центрального компонента безпеки домену. Подібна організація дозволяє гнучко налаштовувати безпекові політики в рамках корпоративної мережі, а також дозволяти, або навпаки, забороняти певним групамкористувачів доступ до тих чи інших ресурсів.

Основні функції контролера домену:

• Зберігання повної копії інформації Active Directory, яка відноситься до конкретного домену, управління та реплікація даної інформації на інші контролери, що входять до цього домену;
• Реплікація інформації каталогу, що стосується всіх об'єктів домену Active Directory;
• Вирішення конфліктів реплікації, коли той самий атрибут був змінений на різних контролерах до моменту ініціалізації реплікації.

Переваги для бізнесу

Переваги централізованої системина базі контролерів домену:

1. Єдина база даних для автентифікації.Контролер домену зберігає всі облікові записи в одній базі даних і кожен користувач, що входить до домену комп'ютера, звертається до контролера домену для входу в систему. Поділ користувачів за відповідними групами дозволяє спростити організацію розподіленого доступу до документів та додатків. Таким чином, при появі нового співробітника достатньо створити для нього обліковий запису відповідній групі та співробітник автоматично отримає доступ до всіх необхідних мережевим ресурсамта пристроям. Під час відходу співробітника достатньо заблокувати його обліковий запис для відкликання всіх доступів.
2. Єдина точка управління політиками.Контролер домену дозволяє розподіляти облікові записи комп'ютерів та користувачів по організаційним підрозділам та застосовувати до них різні групові політики, визначаючи налаштування та параметри безпеки для групи комп'ютерів та користувачів (напр. мережевим принтерам, набір необхідних програм, налаштування браузера тощо). Таким чином, при додаванні в домен нового комп'ютера або користувача він автоматично отримає всі налаштування та доступи, визначені для того чи іншого підрозділу.
3. Безпека.Гнучке налаштування процедур аутентифікації та авторизації, разом із централізованим управлінням дозволяють значно підвищити безпеку IT-інфраструктури в рамках організації. Крім цього, фізично контролер домену встановлюється у спеціальному місці, захищеному від зовнішнього доступу.
4. Спрощена інтеграція коїться з іншими сервісами.Використання контролера домену як єдиної точки автентифікації дозволяє користувачам використовувати один і той же обліковий запис під час роботи з додатковими інструментами та службами (напр. поштові служби, офісні програми, проксі-сервери, месенджери і т.д).

Налаштування

Контролер домену на базі доменної служби Active Directory є ключовим елементомІТ-інфраструктури, що забезпечує контроль доступу, а також захист даних у рамках організації. Від коректного налаштування контролера домену залежить функціонування не тільки самого контролера домену, але також і Active Directory в цілому (наприклад, поширення політик безпеки та правил доступу), що впливає на роботу всіх супутніх служб і сервісів, а також визначає рівень безпеки. Вибирайте найкращих розробників у розділі.