Windows server 2008 r2 перенос домена

Windows Server 2008 and Windows Server 2008 R2 Operating system reached the end of their support cycle on the 14th of January 2020. Because of this many organizations wanted to migrate away from these legacy operating systems. End-of-life operating systems have a direct impact on various industry compliances, IT audits, Penetration tests, and so on. Even business does not have a business requirement to upgrade, end of life operating system leaves no choice but to upgrade.

In the past, I did a similar blog post covering migration AD from Windows Server 2008 to Windows Server 2016. Microsoft released Windows Server 2022 recently (Aug 2021) and I thought it good to demonstrate how we can migrate AD from 2008 R2 to the newest. AD migrations from other operating systems (newer than Windows Server 2008R2) also follow a similar process. 

What is New in Active Directory?

AD DS’ improvements are bond to its forest and domain functional levels. Upgrading the operating system or adding domain controllers that run Windows Server 2022 to an existing AD infrastructure isn’t going to upgrade the forest and domain functional levels automatically. We need to upgrade it manually once older domain controllers are decommissioned. There was a big difference with Windows Server 2019 when it comes to forest and domain functional levels. With each and every Windows Server release up to Windows Server 2016, had a new forest and domain functional level. But with Windows Server 2019 there were NO new forest or domain functional levels. It is the same with Windows Server 2022. The maximum forest and domain functional level we can choose still is Windows Server 2016.

Active Directory Domain Services was first introduced to the world with Windows Server 2000. For more than 21 years, AD DS helps organizations to manage digital identities. However, the modern access management requirements are complicated. Businesses are using more and more cloud services now. The majority of the workforce is still working from home and accessing sensitive corporate data via unsecured networks. Most software vendors are moving into SaaS model. Cybercrimes are skyrocketing and identity protection is at stake. To address these requirements, we need to go beyond legacy access management. Azure Active Directory is a cloud-based, managed, Identity as a Service (IDaaS) provider, which can provide world-class security, strong authentication, and seamless collaboration. So, it does make sense why there are no significant changes to on-premises AD anymore.

One of the key themes of Windows Server 2022 is «security». Advanced multi-layer security in Windows Server 2022 provides comprehensive protection against modern threats. This also adds an additional layer of security to roles run on Windows Server 2022 including Active Directory. For more details about these security features please refer to https://docs.microsoft.com/en-us/windows-server/get-started/whats-new-in-windows-server-2022

Active Directory Migration Check List

Migrating FSMO roles to a new server and upgrading forest and domain functional levels doesn’t take more than few minutes but when it comes to migration there are few other things we need to consider. Therefore, I have summarized the AD DS Migration process with the following checklist.

• Evaluate the business requirements for Active Directory migration.
• Perform an audit on the existing Active Directory infrastructure to verify its health.
• Create a detailed implementation plan.
• Prepare the physical/virtual resources for the domain controller.
• Install Windows Server 2022 Standard/Datacenter.
• Patch the servers with the latest Windows updates.
• Assign a dedicated IP address to the domain controller.
• Install the AD DS role.
• Migrate the application and server roles from the existing domain controllers.
• Migrate the FSMO roles to the new domain controllers.
• Add new domain controllers to the existing monitoring system.
• Add new domain controllers to the existing DR solution.
• Decommission the old domain controllers (all).
• Raise the domain and forest functional levels.
• Perform ongoing maintenance (Group Policy review, new-feature implementations, identifying and fixing Active Directory infrastructure issues, and more)

Most Common Questions About Active Directory Migrations

Below I listed some of the most common questions I get about AD migration,

• Can I keep the same IP address for the PDC? Yes, you can. Active Directory fully supports IP address changes. Once FSMO role migration is completed, you can swap the IP addresses of Domain Controllers.
• Can I downgrade forest/domain functional levels? If you required you can do so but this is not a recommended approach. From Windows Server 2008 R2, we can downgrade forest/domain functional levels.
• Do I need to migrate the DNS role? No, it is part of the AD. When you add a new domain controller, you can make it as a DNS server too.
• Do I need to change SYSVOL replication from FRS to DFS? If your domain is built based on Windows server 2008 or Windows Server 2008 R2, you are already using DFS for SYSVOL replication. If you originally migrated from Windows server 2003, it’s more likely you are still using FRS. In that case, before migration, you need to change the SYSVOL replication method from FRS to DFS. I already have a blog post covering this topic https://www.rebeladmin.com/2015/04/step-by-step-guide-for-upgrading-sysvol-replication-to-dfsr-distr…
• Can I keep Windows 2008 R2 Domain Controllers and upgrade forest and domain functional level to Windows Server 2016? No, you can’t. Before forest and domain functional level upgrade, you need to decommission Windows server 2008 R2 domain controllers.

Design topology

As per the following diagram, the rebeladmin.net domain has two domain controllers:

As explained in the above illustration, The FSMO role holder DC08 is a Windows Server 2008 R2 Domain Controller. The domain and forest functional levels currently operate in Windows Server 2008 R2. A new domain controller with Windows Server 2022(DC22) will be introduced and will be the new FSMO role holder for the domain. Once the FSMO role migration is complete, the domain controller running Windows Server 2008 R2 will be decommissioned. After that, the forest and domain functional levels will be raised to Windows Server 2016.

When you introduce new domain controllers to existing infrastructure, it is recommended that you introduce the forest root level first and then go to the domain tree levels.

Prepare Windows Server 2022 Domain Controller

We need to do few things to prepare the new Windows Server 2022 before we migrate the FSMO roles.

1. After the OS installation and Patching process is completed, go ahead and join the new Windows Server 2022 to the existing domain.
2. In Windows Server 2022, it is recommended to use PowerShell 7 instead of native Windows PowerShell. Please go to https://aka.ms/PSWindows for more information. At the time this article was written, the latest version was 7.1.4.
3. In the previous section, I mentioned before migration we need to make sure SYSVOL is using DFSR instead of FRS. To verify that, Log in to the DC08 domain controller (Windows Server 2008 R2) as a Domain Admin. Then run dfsrmig /getmigrationstate command in Powershell. If the command returns state as «eliminated», it means DFSR is already in use for SYSVOL replication. If it is not, we must migrate SYSVOL replication to DFSR as Windows Server 2022 does not support FRS replication. FRS to DFSR migration steps are covered in a blog post I have written and it can access via https://www.rebeladmin.com/2015/04/step-by-step-guide-for-upgrading-sysvol-replication-to-dfsr-distr…    

  In this demo environment, the Domain controller already using DFSR.

Add Windows server 2022 Domain Controller

As the next part of the configuration, we need to make DC22 an Additional Domain Controller. To do that,

1. Log in to the server as an enterprise administrator.
2. Verify the static IP address allocation using ipconfig /all.
3. Launch the PowerShell 7 Console as an Administrator.
4. Before the configuration process, we need to install the AD DS Role in the given server. To do that we can use the following command.

  Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

1. Configure the new server as an additional domain controller using,

Install-ADDSDomainController

-CreateDnsDelegation:$false

-InstallDns:$true

-DomainName «rebeladmin.net»

-SiteName «Default-First-Site-Name»

-ReplicationSourceDC «DC08.rebeladmin.net»

-DatabasePath «C:WindowsNTDS»

-LogPath «C:WindowsNTDS»

-SysvolPath «C:WindowsSYSVOL»

-Force:$true

Note – There are no line breaks for the command and I have listed it as above to allow readers to focus on the parameters.

The following table explains the PowerShell arguments and what it will do.

Once execute the command it will ask for SafeModeAdministrator Password. Please use a complex password to proceed. This will be used for DSRM.

FSMO Role Migration

Now we have the new domain controller. The next step is to migrate FSMO roles from DC08 to the new domain controller.

1. After the server is rebooted, log back in as an administrator. and run the following commands to verify the current FSMO role holder.

         Get-ADDomain | Select-Object InfrastructureMaster, RIDMaster, PDCEmulator

         Get-ADForest | Select-Object DomainNamingMaster, SchemaMaster 

  As we can see all five FSMO roles currently belong to DC08 (Windows Server 2008 R2) Domain Controller.

1. Migrate all five FSMO roles to the new domain controller by running the following command in DC02 server:

Move-ADDirectoryServerOperationMasterRole -Identity DC22 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster

         In the preceding command, DC22 is the domain controller running Windows Server 2022.

1. Once we’re done, we can verify the new FSMO role holder using the following command:

         Get-ADDomain | Select-Object InfrastructureMaster, RIDMaster, PDCEmulator

         Get-ADForest | Select-Object DomainNamingMaster, SchemaMaster 

         As expected, Now FSMO roles are successfully moved to DC22 Domain Controller (Windows Server 2022)

Decommission Old Domain Controller

Before we upgrade forest and domain functional levels, first we need to decommission the old DC which is running with windows server 2008 R2.

To do that,

1. Log in to old DC as enterprise administrator
2. Go to Run | dcpromo
3. It will open up the dcpromo wizard. Click on Next to continue.

1. On the next page also click on Next as it is not the last domain controller.

1. In the Remove DNS Delegation page keep the default selection and click on Next.

1. Then the system will prompt for credentials. Provide Domain Admin credentials here.

         On the next page, type a new password for the local administrator account.

1. In summary, page, click on Next to complete the process.

1. Once the process is completed, reboot the server.

         If its Windows Server 2012 or above we can use Uninstall-ADDSDomainController -DemoteOperationMasterRole —                               RemoveApplicationPartition to uninstall AD DS

Raise Domain and Forest Functional level

After you demote your last domain controller running with windows server 2008 R2, we can raise Domain and Forest Functional level to windows server 2016 (Windows server 2022 is the same).

To upgrade the domain functional level, we can use the following PowerShell command in the Windows server 2022 domain controller.

Set-ADDomainMode -identity rebeladmin.net -DomainMode Windows2016Domain

To upgrade forest functional level, use the following command:

Set-ADForestMode -Identity rebeladmin.net -ForestMode Windows2016Forest

Now, we have completed the migration from AD DS 2008 R2 to AD DS 2022. The same steps apply when you’re migrating from Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, and Windows Server 2019.

Verification

Although the migration is complete, we still need to verify whether it’s completed successfully. The following command will show the current domain functional level of the domain after the migration:

Get-ADDomain | fl Name,DomainMode

The following command will show the current forest functional level of the domain after migration:

Get-ADForest | fl Name,ForestMode

You can also use the following command to verify the forest & domain functional level updates:

Get-EventLog -LogName ‘Directory Service’ | where {$_.eventID -eq 2039 -or $_.eventID -eq 2040} | Format-List

The following screenshot shows events 2039 and 2040 in the Directory Service log, which verify the forest and domain functional level updates:

Event ID 1458 verifies the transfer of the FSMO roles:

Get-EventLog -LogName ‘Directory Service’ | where {$_.eventID -eq 1458} | Format-List

We can use the following command to verify the list of domain controllers and make sure that the old domain controller is gone:

Get-ADDomainController -Filter * | Format-Table Name, IPv4Address

This marks the end of this blog post. Hope now you know how to migrate Active Directory from Windows Server 2008 R2 to Windows Server 2022. 

Апр 12, 2019 23:33

Active Directory Migration – In this blog, we’ll move the roles on our Server2008 (Windows Server 2008 R2 SP1) AD server to Server2019 (new Windows Server 2019 Standard).

Before proceeding to migrate an Active Directory from Windows Server 2008 R2 to Windows Server 2019, you want to first install Windows Server 2019 on a replacement machine which can then be promoted to Active Directory Server 2019.

Install Windows Server 2019.

How to Install Windows Server 2019, Click here

Rename Windows Server 2019.

How to rename Windows Server 2019, Click here

Configure the IP Addresses in Server 2019.

The next step is to configure the IP and the DNS Addresses on the new server.

                           Windows Server 2008
R2    
      Windows Server 2019

Computer Name:             Server2008                            Server2019

Domain Name:             
xpertstec.local

IP Address (Static):          10.0.0.20                                
10.0.0.22

Subnet Mask:               
255.255.255.0                            255.255.255.0

Default Gateway:            10.0.0.1                                   10.0.0.1

Preferred DNS Server:   10.0.0.20                                 10.0.0.20

Active Directory Migration 2008

1- First, let’s have a glance at my environment. we have a domain controller xpertstec.local which is installed on Windows Server 2008 R2.

Raise the Forest Functional Levels and Domain Functional Levels in Windows Server 2008 R2.

2- Click Start and select Administrative Tools and then Active Directory Domains and Trusts.

3- Right click on Active Directory Domains and Trusts and choose Raise Forest Functional Level.

4- Select an available forest functional level “Windows Server 2008 R2 and click Raise.

5- Now click on OK.

6- The forest functional level was raised successfully so click on ok.

Now Raising the Function Level of the Domain

7- Right click on the Domain name (xpertstec.local) and click Raise Domain Functional Level.

8- It has already got raised the Domain Functional Level to Windows Server 2008 R2 so click on close.

9- Now type the Netdom query fsmo command to check which server has installed FSMO roles.

10- DNS Manager.

Active Directory Migration Steps

Join Windows Server 2019 to an Active Directory Domain.

How to Join Windows Server 2019 to an Active Directory Domain, Click here

Now sign in Windows Server 2019 with the domain administrator account.

Create Additional Domain Controller (ADC) In Windows Server 2019

How to Create Additional Domain Controller (ADC) In Windows Server 2019 so Click here

11- Now have a look at my active directory Domain Controllers  Server2008. We can now see that our server Server2019 is in the domain role.

Transferring the Flexible Single
Master Operations (FSMO) Role

I have a Windows Server 2008 Domain Controller (server2008) and have a further Windows Server 2019 domain controller (Server2019). To finish the migration. We’d like to transfer 5 FSMO roles to the new domain controller.

1. Schema Master
2. Domain Naming Master
3. PDC
4. RID pool manager
5. Infrastructure Master

12- To find which server is currently holding FSMO then run the following command. netdom query fsmo

The FSMO roles are currently with the Windows Server 2008 R2 Active Directory domain controller (server2008)

Using Active Directory Schema snap-in to transfer the Schema Master role 13- Open Command Prompt in administrative mode and type regsvr32 schmmgmt.dll and then click on ok.

Operations Master Roles Tranfer

14- On the Server2019 server, open Active Directory Users and Computers, right click domain xpertstec.local and then click Operations Masters.

15- On the Operations Masters, Select the RID tab and select the Change button.

16- Now click Yes.

17- The operations master role was successfully transferred so click ok.

18- Now you can verify that Operation master now transferred to our new Server Server2019.xpertstec.local

19- On the Operations Masters, select the PDC tab and then click the change button.

20- Now click Yes.

21- The operations master role was successfully transferred, then click ok.

22- Now you can verify that Operation master now transferred to our new Server Server2019.xpertstec.local

23- On the Operations Masters, select the Infrastructure tab and click on change button.

24- Then click Yes.

25- The operations master role was successfully transferred, then click ok.

26- Now you can verify that Operation master now transferred to our new Server Server2019.xpertstec.local

27- Open Server Manager and select Tools and then click Active Directory Domains and Trusts.

28- Right click on Active Directory Domains and Trusts and then select change active directory domain controller.

29- Select this Domain Controller or AD LDS Instance and click on the domain controller that you want to be the schema master role and then click ok.

Transfer Domain Master Role

30- Right click Active Directory Domains and Trusts and then select Operations Master.

31- Now click on Change

32- then click Yes.

33- The operations master was successfully transferred then click ok.

34- Confirmed the domain naming operation master role and click on Close.

35- Now we need to move our Schema Master role, so we need to register the schmmgmt.dll open command prompt and run the command below.

Regsvr32.exe C: windows system32 schmmgmt.dll

The process was completed successfully so click on ok.

36- Open Microsoft Management Console mmc type mmc and then hit enter.

Console

37- Select the File tab and then select Add/Remove Snap-in.

38- From the left side, under Available Snap-ins, Select Active Directory Schema, click Add button and then click ok.

39- Right click Active Directory Schema, and then select Change Active Directory Domain Controller.

40- Select this Domain Controller or AD LDS Instance, click on the domain controller that you want to be the schema master role and then click on ok.

41- Now click OK.

42- In the console1, right click Active Directory Schema (Server2019.xpertstec.local) and then select Operations Master.

43- Select the Change button.

44- then click Yes.

45- The active directory schema Operations Master successfully transferred then click ok.

46- Now confirm your current schema master which is Server2019 and then click Close.

47- Now run the Netdom query fsmo command, so we can now see that our roles have been moved to our Windows Server 2019 Additional Domain Controller.

48- Now change the DNS address of our additional Domain Controller server to be the IP address of our Windows Server 2019 Domain Controller server.

After completing Active Directory Migration, Now the ultimate step is to get rid of (uninstalling) server2008 Active Directory domain controller.

Remove Active Directory Domain Controller 2008

49- Open command prompt Type dcpromo and then hit Enter.

50- Click Next.

51- The Active Directory domain controller has the global catalog service, make sure your primary DC also has the service enabled and click on ok.

52- Confirmed that the delete this domain, because this server is the last domain controller in the domain, is UNCHECKED and then click next.

53- Type a password for the new Administrator account on this server and click next.

54- Review the remove active directory domain services Summary and click Next.

55- Check the Reboot on completion box to restart the server after the service has been removed

56- After rebooting server2008 DC. Now log in with the local administrator account and then open Server Manager.

57- In Server Manager click Roles under Roles Summary and click Remove Roles.

58- Remove active directory domain controller 2008 Roles wizard, click next.

59- Uncheck Active Directory Domain Services and DNS Server box and click next.

60- Click Remove.

61- Now click Close.

62- Do you want to restart now so click on Yes.

63- After rebooting server Log back to server2008, active directory domain services removal succeeded and click Close.

64- Disjoin the machine from the domain

Join to Workgroup

In the Server Manager, under Server Summary and click Change System Properties.

65- On the System Properties and click the change button.

66- Select Workgroup type in a workgroup name and then click on ok.

67- After leaving the domain Warning message so click ok.

68- Welcome to the workgroup and click on ok.

69- Click OK to restart the server.

70- System Properties, click Close.

71- Click Restart Now or Restart Later and shut down this server.

Like and subscribe our YouTube channel to watch updated videos.

For more information click here

В этой статье мы поговорим о процедуре обновления домена с версии Windows Server 2008 R2 до Windows Server 2012 с последующим понижением роли старого контроллера домена до рядового сервера AD.

Итак, что имеется:

• Домен Active Directory как минимум с одним контроллером домена на Windows Server 2008 R2
• Уровень леса и домена AD должен быть как минимум Windows Server 2003
• Дополнительный рядовой сервер домена с Windows Server 2012 , который в дальнейшем станет контроллером домена (как включить сервер в домен подробно описано в статье Как включить Windows в домен).
• Учетная запись с правами администратора домена, схемы и леса.

Прежде чем добавлять новый контроллер домена на Windows 2012 необходимо обновить схему домена и леса. Классически подготовка и повышение уровня домена осуществлялась вручную с помощью утилиты Adprep.exe. В документации новой серверной платформы от Microsoft указано, что при повышении первого сервера с Windows Server 2012 до уровня контроллера домена, повышение уровня домена происходит автоматически при установке роли AD DS на первый сервер Windows 2012 в домене. Так что, теоретически, для подготовки домена ничего делать не нужно.

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

Обновление схемы AD до Windows Server 2012 с помощью adprep

Для обновления схемы нам понадобится утилита adprep.exe, взять которую можно в каталоге supportadprep на диске с дистрибутивом Windows Server 2012. Данная утилита бывает только 64-разрадной (утилиты adprep32.exe больше не существует), соответственно, запустить ее можно будет только на 64 разрядном контроллере домена.

Необходимо скопировать утилиту на текущий DC с ролью Schema Master (Хозяин схемы) и в командной строке с правами администратора выполнить команду подготовки леса к установке нового DC на Windows Server 2012:

adprep /forestprep

Версия схемы Active Directory в Windows Server 2012 — 56.

Далее обновим схему домена:

adprep /domainprep

Далее осталось дожидаться окончания репликации изменений в схеме по всему лесу и проверить существующие контроллеры домена на наличие ошибок. Если все прошло хорошо – продолжаем. Пришла пора развернуть контроллер домена на Windows Server 2012.

Установка контроллер домена на Windows Server 2012

Первой интересной новостью является тот факт, что знакомой администраторам утилиты DCPROMO, позволяющей добавить или удалить контроллер домена в AD больше не существует. При ее запуске появляется окно, в котором сообщается, что мастер установки Active Directory Domain Services перемещен в консоль Server Manager.

Что ж, откроем консоль Server Manager и установим роль Active Directory Domain Services (Внимание! Установка роли автоматически не означает тот факт, что сервер стал контроллером домена, роль нужно сначала настроить)

После окончания установки роли появится окно, в котором сообщается, что сервер готов стать контроллером домена, для чего нужно нажать на ссылку “Promote this server to domain controller” (далее мы рассмотрим только значимые шаги мастера создания нового контроллера домена).

Затем нужно указать, что данный контроллер домена будет добавлен в уже существующий домен (Add a domain controller to an existing domain), указать имя домен и учетную запись из-под которой будет проводится операция.

Затем укажите, что данный контроллер домена будет содержать роли GC (Global Catalog) и DNS сервера. Также укажите пароль восстановления DSRM (Directory Services Restore Mode) и, если необходимо имя сайта, к которому будет относиться данный контроллер домена.

В разделе “Paths” указываются пути к базе Active Directory (NTDS), файлам логов и каталогу SYSVOL. Учтите, что данные каталоги должны находиться на разделе с файловой системой NTFS, тома с новой файловой системой Windows Server 2012 — Resilient File System (ReFS) – использовать для этих целей нельзя!

По окончании работы мастера установки роли AD DS, сервер нужно перезагрузить. После перезагрузки вы получаете новый контроллер домена с ОС Windows Server 2012.

Удаление старого контроллера домена на Windows Server 2008 R2

Прежде, чем понизить роль старого контроллера домена с Windows Server 2008 R2 до рядового сервера, нужно перенести все FSMO роли на новый контроллер домена .

Процедура переноса ролей FSMO с одного контролера домена на другой нами уже рассматривалась, подробнее с ней можно познакомится в статье Передача ролей FSMO в Active Directory. Процедуру можно осуществить через графический GUI (проще) или из командной строки с помощью утилиты ntdsutil

После передачи роли FSMO PDC Emulator, необходимо настроить синхронизацию времени на новом контроллере домена с внешним сервером (с которым время синхронизировалось ранее). Подробно процедура настройки синхронизации времени на PDC описана в статье: Синхронизация времени с внешним NTP сервером в Windows 2008 R2 . Формат команды примерно такой (ntp_server_adress – адрес NTP сервера):

w32tm /config /manualpeerlist:ntp_server_adress /syncfromflags:manual /reliable:yes /update

После того, как все роли FSMO перенесены на новый DC Windows Server 2012, убедитесь, что домен работает корректно: проверьте прохождение репликации AD, журналы DNS и AD на наличие ошибки. Не забудьте в настройках сетевой карты на новом сервере в качестве предпочтительного DNS сервера указать собственный адрес.

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

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

Домен из которого необходимо произвести миграцию:

1. Имя домена: SOURCE-WIN.RU
2. Контроллер домена: DC-WIN-SOURCE.SOURCE-WIN.RU
3. IP адрес КД: 192.168.20.2
4. IP адрес DNS: 192.168.20.2

Домен в который необходимо произвести миграцию:

1. Имя домена: DEST.LOC
2. Контроллер домена: DEST-DC-03.DEST.LOC
3. IP адрес КД: 192.168.20.103
4. IP адрес DNS: 192.168.20.103

Разрешаем передачу зон из одного домена в другой.

В исходном домене:

В домене назначения:

Добавляем строку разрешения передачи зон в файл /etc/named.conf раздел otions и перезапускаем сервер DNS (у нас установлен BIND9 в связке с Samba 4)

allow-transfer { 192.168.20.2; };

Перезапускаем BIND

systemctl restart named

Создание дополнительных зон для обоих доменов.

В исходном домене:

В домене назначения:

Добавляем описание зоны в файл /etc/named.conf

zone "source-win.ru" {
                type slave;
                file "slaves/source-win.ru";
                masters {
                             192.168.20.2;
                             };
};

Перезапускаем BIND

systemctl restart named

Добавляем домен source-win.ru в список доменов поиска в файле /etc/resolv.conf

Проверяем корректность настроек:

В обоих доменах должны корректно разрешаться имена контроллеров домена (как короткие, так и полные).

Для успешной миграции из домена Windows в домен Samba в последнем нам нужно иметь «прокладку» в виде контроллера домена на Windows 2008 R2

Добавление контроллера домена Windows 2008 R2 в домен Samba DC

Процедура установки контроллера домена Windows 2008 R2 ничем не отличается от установки в стандартном окружении Windows. Есть тонкости настройки, которые мы и рассмотрим.

Т.к. DFS-R в домене Samba не работают, то свежеподнятый контроллер домена будет несколько «инвалидным» (отсутствуют сетевые шары NETLOGON и SYSVOL). Исправляем эту ситуацию.

Для синхронизации SYSVOL на контроллере домена Windows необходимо использовать утилиту ROBOCOPY.

Открываем оснастку taskschd.msc

По нажатию правой клавишей «Task Scheduler Library» выбираем «Create Task»

Вводим имя задания. Например «SysVol Replication»

Устанавливаем «Run whether user is logged on or not»

На вкладке «Triggers» создаем новое расписание

На вкладке «Actions» создаем само задание.

В поле «Action» выбираем»Start programm»

В поле «Program/script» указываем полный путь к файлу «robocopy.exe»

В поле «Add arguments (optional)» указываем параметры для старта программы: \dest-dc-01sysvoldest.loc c:windowssysvoldomain /mir /sec

Дважды нажимаем «Ok», вводим пароль администратора домена и ждем первого срабатывания задания. После этого проверяем папку  C:Windows|SYSVOLdomain

Важно: данная утилита является однонаправленной. Т.е. содержимое папки \dest-dc-01sysvoldest.loc копируется на КД windows, но не наоборот.

Содержимое SYSVOL синхронизировалось. Но т.к. DFS-R на windows в домене Samba не работает, Windows думает, что репликация отсутствует и не показывает шары NETLOGON и SYSVOL. Для включения этих шар в реестре Windows достаточно изменить один ключ:

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParameters]

изменяем «SysVolReady» с «0» на «1» и перезагружаем сервер. После перезагрузки шары NETLOGON и SYSVOL появятся на этом сервере.

Далее необходимо на этот контроллер домена передать все роли. Передача осуществляется стандартными средствами. Чуть подробнее о трех ролях: «SchemaMaster», «DomainDnsMaster», «ForestDnsMaster»

Для передачи роли «SchemaMaster» необходимо на КД Windows зарегистрировать один файл:

regsvr32 schmmgmt.dll

После этого открыть mmc и добавить оснастку «Active Directory Schema» и в ней уже стандартным способом передать требуемую роль.

Для передачи «DomainDnsMaster» и «ForestDnsMaster» требуется оснастка ADSI Edit

Открываем оснастку и выбираем точку соединения: DC=DomainDnsZones,DC=dest,DC=loc

Для «ForestDnsMaster» соответственно: DC=ForestDnsZones,DC=dest,DC=loc

Открываем в правом окне элемент CN=Infrastructure и изменяем параметр fSMORoleOwner. Находим имя сервера текущего хозяина и меняем его на имя сервера КД windows.

Создание доверительных отношений между доменами.

В исходном домене необходимо открыть оснастку «Active Directory — домены и доверие».

Открыть свойства домена.

Перейти на вкладку «Отношения доверия» и нажать на «Создать отношения доверия»

После этого запустится мастер создания доверительных отношений.

В первом окне запроса вводим имя нашего домена, куда будет производится миграция.

Тип доверия выбираем «Доверие леса»

Указываем двухстороннее направление отношения доверия.

Говорим, что отношение доверия необходимо создать в обоих доменах

Задаем имя и пароль пользователя в удаленном домене, обладающего правами администратора домена

Остальные шаги оставляем без изменений.

В итоге получили двухсторонние доверительные отношения между доменами.

Подготовка доменов к миграции.

Для проведения миграции из одного домена в другой нам необходимо иметь в целевом домене рабочую станцию с установленной ОС Windows, начиная с версии 7. На рабочей станции необходимо установить пакет remote Server Administrator Tools (RSAT) для соответствующей версии Windows.

С помощью оснастки «Active Directory — пользователи и компьютеры» создаем необходимую структуру OU для нашего нового домена.

Для успешной миграции объектов из исходного домена в новый домен необходим пакет ADMT версии не ниже 3.2 и утилита миграции паролей PWDMIG. Обе утилиты можно взять в свободном доступе на сайте Microsoft. Для установки ADMT необходимо установить на рабочую станцию MS SQLExpress 2008 SP1.

Этапы установки пропущу, т.к. там все достаточно просто.

Включение политики аудита.

Необходимо настроить политику аудита в обоих доменах.

Для этого лучше всего настроить новую групповую политику и привязать ее к OU Domain Controllers. В режиме редактирования политики раскрываем ветку Computer Configuration-Polices-Windows settings-Security-Local-Audit и устанавливаем политики «Audit account management» в Success и Failure, и «Audit directory service access» в Success.

Включение фильтрации SID:

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

В целевом домене:

netdom trust dest.loc /domain:source-win.ru /quarantine:No /userD:administrator/passwordD:Pass

В исходном домене:

netdom trust source-win.ru /domain:dest;loc /quarantine:No /userD:administrator/passwordD:Pass

Права и ограничения.

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

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

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

1. Старый способ — «конфигурация компьютера — конфигурация Windows — Параметры безопасности — Группы с ограниченным доступом»
2. Способ поновей. Более гибкий и продвинутый — «конфигурация компьютера — настройка — Параметры панели управления — Локальные пользователи и группы»

Установка PES.

Для миграции паролей требуется утилита Password Export Server (PES). Скачивается с официального сайта Microsoft вместе с утилитой ADMT. Устанавливать PES необходимо в домене-источнике (source-win.ru), используя при установке ключ, сгенерированный на компьютере целевого домена (dest.loc), на котором установлена утилита ADMT. Формат команды:

admt key /option:create /sourcedomain: /keyfile: /keypassword:{|*

Получившийся файл переносим на КД в исходном домене. При установке PES указываем путь на этот файл, и пароль, если указывали его при генерации ключа. Появляется служба с ручным режимом запуска. Рекомендуется запускать её только при миграции. Небольшая тонкость: установку PES необходимо производить на КД исходного домена ТОЛЬКО из командной строки, открытой от имени администратора. Иначе установщик не сможет установить сгенерированный файл. После установки заходим в оснастку «Службы», находим вновь созданную службу «Password Export Server Service». Открываем свойства этой службы. Режим запуска стоит «Вручную». Эту службу необходимо будет запустить на этапе переноса пользователей и паролей. Самое главное: на вкладке «Вход в систему» необходимо настроить запуск этой службы от имени пользователя целевого домена, который будет производить миграцию.

Делегация прав истории SID

Заходим в «AD — Пользователи и компьютеры» в домене источнике. Правый щелчок на корень доменного дерева, там «Делегирование управления». Стартует мастер делегирования. В нём на первом шаге «Далее», на втором выбираем нужного нам админа, на третьем шаге «Создать особую задачу для делегирования», на четвертом переключатель в верхнем положении «этой папки, существующим в ней объектам …», а вот на пятом шаге нужно поставить птичку на пункте «Миграция журналов SID»

Включение «SID History on a trust»

Для включения «SID History on a trust» необходимо выполнить в обоих доменах команду:

netdom trust {FQDN.domain.name} /domain:{FQDN.domain.name} /enableSIDhistory:yes

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

Миграция домена.

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

В исходном домене создаём локальную группу SourceDomain$$$. Пользователей в эту группу добавлять не нужно.  Эта группа необходима для включения аудита и дальнейшей проверки благополучной миграции SID.

Открываем консоль ADMT. В открывшейся оснастке правой кнопкой на Active Directory Migration Tools — Group Account Migration Wizard.

В открывшемся мастере в окне Domain Selection выбираем источник минрации «source-win.ru» и целевой домен «dest.loc»:

 На следующем окне выбираем «Select groups from domain»:

Нажимаем «Add» и выбираем группу SourceDomain$$$

Далее назначаем OU в цедевом домене, куда следует поместить эту группу:

В следующем окне выбираем «Migrate group SIDs to target domain». С остальных пунктов выбор снимаем.

 Вводим учетные данные пользователя с правами администратора домена в исходном домене:

На следующем шаге «Object Property Exclusion» оставляем все без изменения (ничего не выбрано)

На шаге «Conflict Management» отмечаем «Do not migrate source object if a conflict is detected in the target domain»

Жмем «Далее» «Готово». Наблюдаем за результатом.

После миграции просматриваем лог на предмет ошибок и предупреждений (не ленимся). Проверяем пункт «Migrate Security Identifiers» — должен стоять yes.

В логах может встретиться предупреждение о несовпадении схем доменов, и то что некоторые атрибуты не перенесутся. Это получается из-за несовпадений схемы (например схема в исходном домене была расширена MS Exchange). Ошибка не критична, но лучше сразу выяснить, что ее вызывает.

Миграция служебных учетных записей.

Мастер миграции служебных записей (Service Account Migration Wizard) проверяет серевера, указанные администратором, на наличие служб, работающих под доменным учётными записями. Пароли таких записей не мигрируют. Для миграции: в оснастке ADMT выбираем пункт Service Account Migration Wizard. Далее выполняем следующую последовательность действий:

Выбираем исходный и целевой домен:

Выбираем обновление информации для сервисных учетных записей.

На следующих шагах выбираем Select computers from domain. В пункте Service Account Selection, добавляем учётные записи из исходного домена, которые хотим мигрировать.

В открывшемся окне Agent Actions, выбираем пункт Run pre-check and agent operation, и запускаем Start. После окончания обязательно просмотреть лог миграции и Agent Detail на наличие ошибок и предупреждений.

По окончании работы агента жмем «Close».

В открывшемся окне «Service Account Information» выбираем любые учётные записи, которые не были отмечены как служебные, и жмём «Skip/Include»

Завершаем миграцию нажатием «Finish»

Миграция групп.

Следующим этапом идёт миграция глобальных групп. (стоит сразу отметить, что встроенные группы не мигрируют). При дальнейшей миграции пользователей, членство в группах будет восстановлено автоматически.
Для миграции так же, как и в прошлых пункатх, открываем ADMT, выбираем «Group Account Migration Wizard».

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

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

В окне «Group Option» оставляем только «Migrate Group SIDs to target domain». С остальных пунктов снимаем выделение.

Вводим логин и пароль доменного администратора источника.

В окне обработки конфликтов выбираем «Do not migrate source object if a conflict is detected in the target domain».

Жмем «Далее» и «Готово». Наблюдаем за состоянием миграции.

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

Миграция учетных данных пользователей

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

В консоле ADMT, выбираем пункт «User Account Migration Wizard».

Первые шаги такие же, как и для миграции групп. В окне «User Selection Option» выбираем «Select user from domain». Выбираем пользователей исходного домена и указываем контейнер, куда следует поместить учетные записи в новом домене.

В окне «Password option» выбираем «Do not update passwords for existing users» и «Generate complex passwords», для генерации пароля.

В «Target Account State» отмечаем «Disable target accounts», для отключения перенесенных записей в целевом домене. Включаем опцию «Migrate user SIDs to target domains»

Вводим учетные данные администратора исходного домена.

В «User Options» отмечаем пункты «Translate roaming profiles» и «Fix users’ group memberships», с остальных пунктов выделение снимаем.

В окне «Object Property Exclusion» снимаем выбор (если он есть) «Exclude specific object properties from migration»

В окне обработки конфликтов выбираем «Do not migrate object if conflict is detected in the target domain»

Жмем «Далее» и «Готово». Смотрим результат и лог миграции.

Перенос локальных профилей.

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

На момент переноса профилей, и миграции ПК не должно быть активных пользовательских сессий. Для переноса (трансляции) профилей: в оснастке ADMT, выбираем пункт «Security Translation Wizard»

 На этапе «Computer Selection» выбираем пункт «Select from domain» и добавляем необходимые ПК.

В окне «Translate object» отмечаем только «User profiles»

В окне «Security Translation Option» выбираем «Replace»

В открывшемся окне Agent Dialog выбираем «Run pre-check and agent operation». Жмем «Start» и ждем пока агент установится на выбранные компьютеры и закончит работу. После этого не забываем смотреть логи на наличие ошибок и при необходимости исправляем их.

Миграция ПК

Открываем ADMT, выбираем пункт Computer Migration Wizard

В окне «Computer Selection и Organization Unit» выбираем пункт «Select from domain», и добавляем необходимые ПК. Переходим на следующий пункт и выбираем подразделение, куда будут помещены компьютеры.

В окнах «Translate Objects» и «Security Translation Options» устанавливаем «Local ghroups» и «User rights».

В окне «Security Translation Option» устанавливаем  «Add»

В «Computer Options» устанавливаем время, через которое компьютер уйдет в перезагрузку

В окне исключений ничего не выбираем.

В окне обработки конфликтов выбираем «Do not migrate source object if a conflict is detected in the target domain», что бы исключить перезапись объектов, если они уже существуют.

Жмем «Готово». Наблюдаем результат и смотрим логи.

В открывшемся окне «Agent Dialog» выбираем пункт «Run pre-check and agent operation» и запускаем и смотрим за результатом

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

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

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

В окне «User Selection» выбираем пользователей, чьи ПК были перенесены на предыдущем шаге.

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

В окне «Password Option» указываем «Migrate passwords», снимаем выделение с «Do not update passwords for existing users» и указываем сервер PES (настраивалось ранее).

В окне «Account Transition Options» включаем целевую учетную запись «Enable target accounts» и выключаем запись в домене источнике «Disable source accounts». Отмечаем пукнт «Migrate user SIDs to target domain», для копирования истории SID в целевой домен.

Вводим учетные данные администратора домена источника.

В окне «User options», отмечаем пункты «Translate roaming profiles» (перенос перемещаемых профилей), «Update user rights» (обновление прав пользователей), «Fix users’ group memberships» (исправить членство в группах). Убрать галочку с пункта «Migrate associated user groups».

В окне исключений ничего не выделяем.

В обработке конфликтов отмечаем пункт «Migrate and merge conflicting objects» (мигрировать и объединить конфликтующие объекты). Убираем галочки с пунктов «Before merging remove user rights for existing target accounts» (перед объединением (слиянием) — очистить матрицу прав пользователя), и «Move merged objects to specified target Organizational Unit» (переместить объект после объединения в указанное организационное подразделение).

Жмем «Готово». Смотрим за процессом. По окончании смотрим логи на наличие ошибок. Если они есть — исправляем и повторяем миграцию.

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

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

Миграция серверов

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

В первую очередь в домене-источнике создадим копию текущих групповых политик с помощью консоли GPMC. Для этого запустите консоль gpmc.msc, перейдите в раздел Group Policy Objects и в контекстном меню выберите пункт Backup Up All (Архивировать все…).

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

Нажимаем кнопку «Архивировать» и смотрим за процессом создания архива. После завершения создания архива нужно внимательно прочитать окно «Состояние» на предмет выявления ошибок. Если ошибки есть, то их следует исправитть и повторить создание архива.

В каталоге с резервной копией должны появится несколько каталогов, соответствующих содержимому доменного каталога с политиками (\source-win.ruSYSVOLdomainPolicies).

Следующий шаг – импорт политик в домен назначения. Прежде, чем приступить к переносу, нужно избавиться в старых политиках о любых упоминаниях или ссылок на ресурсы исходного домена (ссылки на домен, его объекты, SID-ы и пр.), исправив их на значения нового домена. Для этого нам понадобится утилита Migration Table Editor, которая входит в состав консоли GPMC.

Копируем папку с архивом групповых политик на ПК в новом домене (на котором будем производить работы) и запускаем оснастку «Управление групповыми политиками», переходим на уровень Group Policy Objects. В контекстном меню выбераем пункт Open Migration Table Editor (Открыть редактор таблиц миграции) (утилиту можно запустить вручную, находится она тут: C:WindowsSystem32mtedit.exe).

В открывшемся окне утилиты выбираем меню Tools -> Populate from Backup (Сервис -> Заполнить из архивной копии). Указываем папку с содержимым архива групповых политик, выбираем политики, которые нужно обработать и нажимаем Ok.

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

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

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

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

В окне Migrating References выберите опцию Using this migration table to map them in the destination GPO, и укажите путь к ранее созданному файлу .migtable. Нажмите Next, после чего должен осуществится процесс импорта настроек старой политики в новую по правилам, указанным в файле миграции.

Таким же способом нужно перенести все оставшиеся политики. Осталось привязать перенесенные политики к нужным OU, предварительно протестировав их работу на тестовых пользователях/компьютерах.

Удаление контролера домена Windows AD из домена Samba AD

Для удаления нашего промежуточного контролера домена на Windows необходимо предпринять следующие шаги:

1. В оснастке «Домены и доверия» удаляем доверительные отношения между старым и новым доменами.
2. Удаляем «ведомую» (secondary) зону старого домена.
3. В оснастке «Сайты и службы» в свойствах «NTDC Settings» удаляемого контролера домена снимаем галочку «Глобальный каталог»
4. Передаем семь ролей на остающиеся контролеры домена. Передача ролей описывалась в этой статье выше.
5. После того, как все роли переданы, удаляем контролер домена командой DCPROMO. Если удаление не удалось, то делаем принудительное удаление с параметром /forceremoval
6. Если удаление контролера домена пришлось делать принудительно, то на любом контролере домена Samba AD выполняем следующую команду:

   samba-tool domain demote --remove-other-dead-server=dest-dc-03

7. После этого во всех оснастках Active Directory проверяем наличие оставшихся следов удаляемого сервера. Если они есть, то лучше всего запустить на ПК с Windows скрипт от Microsoft:

   REM    ========================================================== 
   REM                GUI Metadata Cleanup Utility 
   REM             Written By Clay Perrine 
   REM                          Version 2.5 
   REM    ========================================================== 
   REM     This tool is furnished "AS IS". NO warranty is expressed or Implied. 
    
   on error resume next 
   dim objRoot,oDC,sPath,outval,oDCSelect,objConfiguration,objContainer,errval,ODCPath,ckdcPath,myObj,comparename 
    
   rem =======This gets the name of the computer that the script is run on ====== 
    
   Set sh = CreateObject("WScript.Shell") 
   key= "HKEY_LOCAL_MACHINE" 
   computerName = sh.RegRead(key & "SYSTEMCurrentControlSetControlComputerNameComputerNameComputerName") 
    
   rem === Get the default naming context of the domain==== 
    
   set objRoot=GetObject("LDAP://RootDSE") 
   sPath = "LDAP://OU=Domain Controllers," & objRoot.Get("defaultNamingContext") 
    
   rem === Get the list of domain controllers==== 
    
   Set objConfiguration = GetObject(sPath) 
   For Each objContainer in objConfiguration 
       outval = outval & vbtab &  objContainer.Name & VBCRLF 
   Next 
   outval = Replace(outval, "CN=", "") 
    
   rem ==Retrieve the name of the broken DC from the user and verify it's not this DC.=== 
    
   oDCSelect= InputBox (outval," Enter the computer name to be removed","") 
   comparename = UCase(oDCSelect) 
    
   if comparename = computerName then 
       msgbox "The Domain Controller you entered is the machine that is running this script." & vbcrlf & _ 
           "You cannot clean up the metadata for the machine that is running the script!",,"Metadata Cleanup Utility Error." 
       wscript.quit 
   End If 
    
   sPath = "LDAP://OU=Domain Controllers," & objRoot.Get("defaultNamingContext") 
   Set objConfiguration = GetObject(sPath) 
    
   For Each objContainer in objConfiguration 
       Err.Clear 
       ckdcPath = "LDAP://" & "CN=" & oDCSelect & ",OU=Domain Controllers," & objRoot.Get("defaultNamingContext") 
       set myObj=GetObject(ckdcPath) 
       If err.number <>0 Then 
           errval= 1 
       End If 
   Next 
    
   If errval = 1 then 
       msgbox "The Domain Controller you entered was not found in the Active Directory",,"Metadata Cleanup Utility Error." 
       wscript.quit 
   End If 
    
   abort = msgbox ("You are about to remove all metadata for the server " & oDCSelect & "! Are you sure?",4404,"WARNING!!") 
   if abort <> 6 then 
       msgbox "Metadata Cleanup Aborted.",,"Metadata Cleanup Utility Error." 
       wscript.quit 
   end if 
    
   oDCSelect = "CN=" & oDCSelect 
   ODCPath ="LDAP://" & oDCselect & ",OU=Domain Controllers," & objRoot.Get("defaultNamingContext") 
   sSitelist = "LDAP://CN=Sites,CN=Configuration," & objRoot.Get("defaultNamingContext") 
   Set objConfiguration = GetObject(sSitelist) 
   For Each objContainer in objConfiguration 
       Err.Clear 
       sitePath = "LDAP://" & oDCSelect & ",CN=Servers," &  objContainer.Name & ",CN=Sites,CN=Configuration," & _ 
           objRoot.Get("defaultNamingContext") 
       set myObj=GetObject(sitePath) 
       If err.number = 0 Then 
           siteval = sitePath 
       End If     
   Next 
    
   sFRSSysvolList = "LDAP://CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System," & _ 
       objRoot.Get("defaultNamingContext") 
   Set objConfiguration = GetObject(sFRSSysvolList) 
    
   For Each objContainer in objConfiguration 
       Err.Clear 
       SYSVOLPath = "LDAP://" & oDCSelect & ",CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System," & _ 
           objRoot.Get("defaultNamingContext") 
       set myObj=GetObject(SYSVOLPath) 
       If err.number = 0 Then 
           SYSVOLval = SYSVOLPath 
       End If 
   Next 
    
   SiteList = Replace(sSitelist, "LDAP://", "") 
   VarSitelist = "LDAP://CN=Sites,CN=Configuration," & objRoot.Get("defaultNamingContext") 
   Set SiteConfiguration = GetObject(VarSitelist) 
    
   For Each SiteContainer in SiteConfiguration 
       Sitevar = SiteContainer.Name 
       VarPath ="LDAP://OU=Domain Controllers," & objRoot.Get("defaultNamingContext") 
       Set DCConfiguration = GetObject(VarPath) 
       For Each DomContainer in DCConfiguration 
           DCVar = DomContainer.Name 
           strFromServer = "" 
           NTDSPATH =  DCVar & ",CN=Servers," & SiteVar & "," & SiteList 
           GuidPath = "LDAP://CN=NTDS Settings,"& NTDSPATH  
           Set objCheck = GetObject(NTDSPATH) 
           For Each CheckContainer in objCheck 
   rem ====check for valid site paths ======================= 
               ldapntdspath = "LDAP://" & NTDSPATH 
               Err.Clear 
               set exists=GetObject(ldapntdspath) 
               If err.number = 0 Then 
                   Set oGuidGet = GetObject(GuidPath) 
                   For Each objContainer in oGuidGet 
                       oGuid = objContainer.Name 
                       oGuidPath = "LDAP://" & oGuid & ",CN=NTDS Settings," & NTDSPATH   
                       Set objSitelink = GetObject(oGuidPath) 
                       objSiteLink.GetInfo 
                       strFromServer = objSiteLink.Get("fromServer") 
                       ispresent = Instr(1,strFromServer,oDCSelect,1) 
    
                       if ispresent <> 0 then 
                           Set objReplLinkVal = GetObject(oGuidPath) 
                           objReplLinkVal.DeleteObject(0) 
                       end if 
                   next 
    
                   sitedelval = "CN=" & comparename & ",CN=Servers," & SiteVar & "," & SiteList 
                   if sitedelval = ntdspath then 
                       Set objguidpath = GetObject(guidpath) 
                       objguidpath.DeleteObject(0) 
                       Set objntdspath = GetObject(ldapntdspath) 
                       objntdspath.DeleteObject(0) 
                   end if 
               End If 
           next 
       next 
   next 
   Set AccountObject = GetObject(ckdcPath) 
   temp=Accountobject.Get ("userAccountControl") 
   AccountObject.Put "userAccountControl", "4096" 
   AccountObject.SetInfo 
   Set objFRSSysvol = GetObject(SYSVOLval) 
   objFRSSysvol.DeleteObject(0) 
   Set objComputer = GetObject(ckdcPath) 
   objComputer.DeleteObject(0) 
   Set objConfig = GetObject(siteval) 
   objConfig.DeleteObject(0) 
   oDCSelect = Replace(oDCSelect, "CN=", "") 
   msgval = "Metadata Cleanup Completed for " & oDCSelect 
   msgbox  msgval,,"Notice." 
   wscript.quit
   

   Впрочем я рекомендую запустить этот скрипт в любом случае. При запуске скрипт покажет список контролеров домена, присутствующих в AD. Если удаляемого контролера домена в списке нет, то все Ок. Можно жать «Отмена». Если в списке имя удаляемого контролера домена присутствует, то набираем его и запускаем скрипт. В процессе работы этого скрипта в AD очищаются все метаданные удаляемого контролера домена.

8. И последним шагом нужно сделать проверку и ремонт (если требуется) базы данных AD:

   samba-tool dbcheck --fix --yes
   

В итоге по программе «импортозамещения» мы имеем работающий домен Active Directory со всеми пользователями и настройками старого домена.

Вчера получил вопрос от одного из коллег по миграции домена на платформе Windows 2008R2. К сожалению (а скорей к радости) нам еще не довелось заниматься миграцией на платформе Windows 2008 (делали это на 2003 платформе с моим коллегой Александром, но не все прошло гладко, я писал об этом, где-то здесь), но вопрос не остался незамеченным, и я решил вдаться поглубже в тему. В процессе изучения мне понравился вот этот материал: http://sqrnotes.blogspot.com/2010/09/admt-32.html

с этого сайта я и добавлю себе в блог для информации:

Миграция домена ADMT 3.2

12.07.2012 —

Posted by |
ms windows server 2008