Миграция сервера dhcp c windows server 2008 r2 на отказоустойчивую конфигурацию dhcp failover из двух серверов на базе windows server 2012 r2

DHCP failover overview

In Windows Server 2008 R2, there are two high availability options available for DHCP Server deployment. Each of these options is associated with some challenges.

1. DHCP in a Windows failover cluster. This option places the DHCP server in a cluster with an additional server configured with the DHCP service that assumes the load if the primary DHCP server fails. The clustering deployment option uses a single shared storage. This makes the storage a single point of failure, and requires additional investment in redundancy for storage. In addition, clustering involves relatively complex setup and maintenance.

2. Split scope DHCP. Split scope DHCP uses two independent DHCP servers that share responsibility for a scope. Typically 70% of the addresses in the scope are assigned to the primary server and the remaining 30% are assigned to the backup server. If clients cannot reach the primary server then they can get an IP configuration from the secondary server. Split scope deployment does not provide IP address continuity and is unusable in scenarios where the scope is already running at high utilization of address space, which is very common with Internet Protocol version 4 (IPv4).

DHCP failover in Windows Server 2012 enables administrators to deploy a highly resilient DHCP service to support a large enterprise without the challenges of the options discussed earlier. The main goals of the feature are the following:

• Provide DHCP service availability at all times on the enterprise network.

• If a DHCP server is no longer reachable, the DHCP client is able to extend the lease on its current IP address by contacting another DHCP server on the enterprise network.

The DHCP server failover feature provides the ability to have two DHCP servers provide IP addresses and option configuration to the same subnet or scope, providing for continuous availability of DHCP service to clients. The two DHCP servers replicate lease information between them, allowing one server to assume responsibility for servicing of clients for the entire subnet when the other server is unavailable. It is also possible to configure failover in a load-balancing configuration with client requests distributed between the two servers in a failover relationship.

DHCP failover in Windows Server 2012 provides support for a maximum of two DHCP servers, and the failover relationship is limited to IPv4 scopes and subnets. Network nodes using Internet Protocol version 6 (IPv6) typically determine their own IPv6 address using stateless IP auto configuration. In this mode, the DHCP server delivers only the DHCP option configuration, and the server does not maintain any lease state information. A high availability deployment for stateless DHCPv6 is possible by simply setting up two servers with identical option configuration. Even in a stateful DHCPv6 deployment, the scopes do not run under high address utilization, which makes split scope a viable solution for high availability.

Deploying DHCP policies

A common reason to deploy DHCP policies is to provide unique settings to different types of devices on the network. Two common methods used to identify device type include:

1. Vendor class: A text string is sent in option 60 by most DHCP clients that identifies the vendor and therefore the type of the device.

2. MAC address prefix: The first three bytes of a MAC address is called the organizationally unique identifier (OUI), and can be used to identify the vendor or manufacturer of a device.

For example, you might decide to group DHCP clients on the network by device type. After assigning IP address ranges to devices, you can configure your router to handle network traffic from each IP address range differently. In effect, you can configure network access control for a class of devices using DHCP policies. You might also manage network traffic by configuring route options such as default gateway (option 003) and classless static routes (option 121) based on device type.

It is often desirable to configure a short lease duration for wireless devices, and grant a longer lease to wired devices. Since wireless access points are typically capable of behaving as a DHCP relay agent, or are connected to a DHCP relay, they can provide DHCP option 82 (DHCP relay agent). Presence of a specific value in the relay agent option can therefore indicate that the DHCP client is a wireless device.

With DHCP policies, you can configure a policy with a condition based on the relay agent information option value that identifies wireless clients and provides a shorter lease duration. Other DHCP clients in the scope will continue to be provided with the longer lease duration configured at the scope level.

These scenarios and others are discussed in detail in this guide.

View or edit properties of the failover configuration

After you configure a failover relationship on a DHCP server, details for the failover relationship are displayed in the DHCP console.

To view or edit properties of the failover relationship

1. On DHCP1 or DHCP2, in the DHCP console, right-click the Contoso-scope1 DHCP scope and then click Properties.

2. Click the Failover tab and review the information displayed. Verify that Normal is displayed next to State of this Server and also next to State of Partner Server.

3. Note that you can edit or delete the failover relationship.

4. Click Edit and review properties of the failover relationship that are available to edit.

5. Leave the dialog box open for the following procedure.

Edit properties of the failover relationship and demonstrate hot standby mode

To demonstrate hot standby mode, the DHCP Server service on one of the failover partners will be stopped.

To edit properties of the failover relationship and demonstrate hot standby mode

1. On DHCP1 or DHCP2, in the DHCP console, right-click the Contoso-scope1 DHCP scope and then click Properties.

2. Click the Failover tab.

3. Click Edit and then choose Hot Standby Mode.

4. Depending on which DHCP server you are configuring, the local server will be assigned either Active or Standby status. The status is displayed next to Role of this server.

   Tip

   The server that is designated to be Active in hot standby mode is the server that you used to create the failover relationship.

5. Click OK twice and then wait 2 minutes for the DHCP lease on Client1 to renew.

6. On Client1, type ipconfig /all at the Windows PowerShell prompt and verify that the server that is assigned as Active is supplying an IP addresses configuration to Client1.

7. In the DHCP console on the DHCP server that is marked as Active for the hot standby failover relationship and is currently supplying an IP address to Client1, right-click the server name, point to All Tasks, and then click Stop.

8. Verify that the DHCP service is stopped on the active DHCP server.

9. Wait for the DHCP lease to renew on Client1, type ipconfig /all at the Windows PowerShell prompt, and verify that the standby DHCP server is supplying an IP address to Client1.

Hot standby mode

In hot standby mode, two servers operate in a failover relationship where an active server is responsible for leasing IP addresses and configuration information to all clients in a scope or subnet. The secondary server assumes this responsibility if the primary server becomes unavailable. A server is primary or secondary in the context of a subnet. For instance, a server that has the role of a primary for a given subnet could be a secondary server for another subnet.

Hot standby mode of operation is best suited to deployments where a central office or data center server acts as a standby backup server to a server at a remote site, which is local to the DHCP clients (ex: hub and spoke deployment). In such deployments, it is undesirable to have a remote standby server service any clients unless the local DHCP server becomes unavailable. The figure below is an example of a hub and spoke deployment.

Делегирование прав на DHCP на контроллере домена

Если вы зайдете на контроллере домена в оснастку «Управление компьютером», то вы не обнаружите там возможность посмотреть и изменить членство в локальных группах, там убрана такая возможность, но если запустить PowerShell или открыть командную строку, и ввести команду:

net localgroup

То вы увидите, что группы все же присутствуют на контроллере. Среди них есть две необходимые:

• Администраторы DHCP — дает полные права управление на данный сервис
• Пользователи DHCP — Дает права только для чтения

Кстати если вы попытаетесь подключиться через Windows Admin Center, то увидите ошибку «Этот инструмент нельзя использовать при подключении к контроллеру домена.»

Чтобы добавить нужного вам сотрудника или группу пользователей в эти группы, вам необходимо открыть оснастку «Active Directory — Пользователи и компьютеры» ADUC. Перейти там в контейнер «Users» и найти там встроенные группы:

• Администраторы DHCP — Сюда я добавлю пользователя Барбоскина Геннадия
• Пользователи DHCP — Сюда добавлю пользователя домовенка Бубу

Проверяем права через оснастку DHCP, которую вы можете добавить через установку пакета RSAT. Первым я проверю права для Барбоскина Геннадия, у него они должны быть полные. Как видно, я могу перезапускать сервис и изменять настройки области.

Теперь посмотрим появились ли права у Бубы. Как видим поля активные,

но при сохранении изменений вам будет выводиться, что «Отказано в доступе».

What this guide does not provide

The following scenarios are not supported or are beyond the scope of this guide.

• Clustering scenarios are not supported by this migration process. For more information about migrating DHCP Server in a cluster environment, see Migrating DHCP to a Cluster Running Windows Server 2008 R2 Step-by-Step Guide (https://go.microsoft.com/fwlink/?LinkId=140512) on the Windows Server TechCenter.

  Also see Migrate to DHCP Failover. DHCP failover is a new option for DHCP high availability, introduced in Windows Server 2012.

• Upgrading roles on the same computer is out of scope for this guide.

• Scenarios in which the new operating system is installed on existing server hardware by using the Upgrade option during setup (in-place upgrades) are not covered in this guide.

• Migrating more than one server role is not covered in this guide.

How DHCP PBA works

DHCP policies are rules that you can define for DHCP clients. You can define a single policy, or several. Characteristics of DHCP policies include:

• Policy level: Polices can apply at the server level or the scope level. Server level policies are processed for all DHCP client requests received by the server. Scope level policies are processed only for DHCP client requests that apply to a specific scope.

• Processing order: Each policy has an associated processing order that is unique within a server or scope. Policies with a lower numbered processing order are evaluated before higher number policies. If both scope and server level policies apply to a client, the scope level policies are always processed before any server level policies.

• Conditions: The conditions specified in a policy enable you to evaluate clients based on fields that are present in the DHCP client request. If a client request matches the conditions in the policy, the settings associated with a policy will be applied to the client by the DHCP server when it responds to the DHCP request.

• Settings: Settings are network configuration parameters (ex: IP address, options, lease duration) that are provided to DHCP clients in the DHCP server response. Settings enable you to group clients by applying the same set of network parameters to them.

• Enabled/Disabled: Policies at the scope or server level can also be enabled or disabled. A policy that is disabled is skipped when processing incoming DHCP client requests.

To create a policy at the server level using the Windows interface, open the DHCP console, navigate to IPv4, right-click Policies and then click New Policy.

If other server level policies exist, they are displayed in the details pane and can be modified by right-clicking the policy and then clicking Move Up, Move Down, Disable, Enable, Delete, or Properties.

To create a policy at the scope level using the Windows interface, open the DHCP console, navigate to an IPv4 scope, right-click Policies and then click New Policy. If other scope level policies exist, they are displayed along with any server level policies that exist. You can modify existing scope level policies by right-clicking them. You cannot modify a server level policy at the scope level.

You must provide a unique policy name when creating a new policy. A policy description is optional. A policy must have at least one condition.

Policy settings are optional, but DNS settings are included by default so it is not possible to have a policy with no settings. To view DNS settings for a policy, right-click the policy, click Properties, and then click the DNS tab.

Why DHCP PBA?

Consider the following scenarios:

1. A subnet has a mix of different types of clients: desktop computers, printers, IP phones, and other devices. You want different types of clients to get IP addresses from different IP address ranges within the subnet. This is possible using DHCP policies if the devices have different vendors. For example:

   • Printers can get IP addresses from 10.10.10.1 to 10.10.10.9.

   • IP phones can get IP addresses from 10.10.10.10 to 10.10.10.49.

   • Desktop computers can be assigned IP addresses from 10.10.10.50 to 10.10.10.239.

   • Additional devices can be assigned IP addresses of 10.10.10.240 to 10.10.10.254.

   By specifying a different IP address range for different device types, you can more easily identify and manage devices on the network.

2. In a subnet which has a mix of wired and mobile computers, you might want to assign a shorter, 4 hour lease duration to mobile computers and longer, 4 day lease duration to wired computers.

3. You want to control who gets access to the network by providing a DHCP lease to only a known set of clients based on MAC address.

4. Employees bring in their own devices such as smartphones and tablets to work and you want to manage network traffic or control network access based on device type.

5. You want to provide a different set of scope options to different types of devices. For example, IP phones can get a different Boot Server Host Name (TFTP server) and Bootfile Name option.

DHCP policies provide a very useful tool to achieve these goals. See the following example.

In this example:

• Subnet A contains DHCP client devices of several different types including workstations, printers, and IP phones.

• A DHCP server on another subnet is configured to provide leases to these devices from scope A.

• Polices are configured at the scope level to control IP address range and at the server level to specify lease duration.

DHCP client requests are processed as follows:

1. A client on subnet A submits a DHCPREQUEST that is sent to the DHCP server via DHCP relay.

2. The client’s vendor class and MAC prefix are included in the DHCPREQUEST packet along with the gateway IP address (GIADDR).

3. The DHCP server uses the GIADDR to determine that the client requires a lease from scope A, and begins processing policies in that scope.

4. Since scope B does not apply, these policies are ignored.

5. Based on the vendor class and MAC prefix values provided, the client request matches conditions of policy A3.

6. After all scope polices are processed, server level policies are processed and the client also matches conditions of policy 1.

7. After all policies are processed, the DHCP server returns an IP address configuration to the client using the settings specified in policies A3 and 1.

Based on the client’s MAC address it is determined that the device is a printer (it matches policy A3). It is assigned the first available IP address in the IP address range 10.10.10.1 to 10.10.10.9, with a lease duration of 14 days.

In Windows Server 2008 R2 and previous operating systems, if you want to specify the IP address range for a specific set of clients or devices, or assign different option values based on device type, the only way to achieve this is to configure a scope with individual reservations. This method can require high effort, and is difficult to manage on an ongoing basis.

DHCP policies in Windows Server 2012 provide much more flexibility to assign unique IP addresses and options to specific DHCP clients in a single subnet, or in multiple subnets.

Note

See Policy processing to understand how settings are applied when they are configured in multiple policies, in reservations, at the scope level, or at the server level.

Conclusion

DHCP failover provides high availability of DHCP services without the challenges of clustering or split scope DHCP. Benefits of DHCP failover include:

1. Simple: A wizard is provided to create DHCP failover relationships between DHCP servers. The wizard automatically replicates scopes and settings from the primary server to the failover partner.

2. Flexible: DHCP failover can also be configured for load balancing, with client requests distributed between both DHCP servers in a failover relationship based on the values you choose.

3. Seamless: DHCP servers share lease information, allowing one server to assume responsibility for servicing of clients if the other server is unavailable. DHCP clients can keep the same IP address when a lease is renewed, even if the lease is issued by a different DHCP server.

Настройка службы DHCP

После установки службы DHCP и ее начала необходимо создать область. Область — это диапазон допустимых IP-адресов, доступных для аренды клиентских компьютеров DHCP в сети. Корпорация Майкрософт рекомендует, чтобы каждый сервер DHCP в вашей среде был по крайней мере одним областью, которая не пересекалась ни с одним другим сервером DHCP в вашей среде. В Windows Server 2003 серверы DHCP в домене на основе Active Directory должны быть разрешены, чтобы предотвратить выход в интернет неугдаваемого сервера DHCP. Любой Windows Сервер DHCP Server 2003, который определяет себя как несанкционированный, не будет управлять клиентами.

Создание новой области

1. Нажмите кнопку Начните, указать на программы, указать на административные средства, а затем нажмите кнопку DHCP.
2. В дереве консоли щелкните правой кнопкой мыши сервер DHCP, на котором необходимо создать новую область DHCP, а затем нажмите кнопку New Scope.
3. В Мастере новых областей нажмите кнопку Далее, а затем введите имя и описание области. Имя может быть любым, кто вам нужен, но оно должно быть достаточно описательным, чтобы можно было определить цель области в сети (например, можно использовать имя, например «Административные клиентские адреса»). Нажмите кнопку «Далее».
4. Введите диапазон адресов, которые можно арендовать в рамках этой области. Например, используйте ряд IP-адресов от начального IP-адреса 192.168.100.1 до конечного адреса 192.168.100.100. Поскольку эти адреса даются клиентам, все они должны быть допустимы для вашей сети и не используются в настоящее время. Если вы хотите использовать другую подсетевую маску, введите новую подсетевую маску. Нажмите кнопку «Далее».
5. Введите любые IP-адреса, которые необходимо исключить из введенного диапазона. Эти адреса включают любой из указанных в шаге 4 диапазона адресов, которые, возможно, уже были статически назначены различным компьютерам в организации. Как правило, контроллеры домена, веб-серверы, серверы DHCP, серверы системы доменных имен (DNS) и другие серверы имеют статически заданные IP-адреса. Нажмите кнопку «Далее».
6. Введите количество дней, часов и минут до истечения срока аренды IP-адресов из этой области. Он определяет, как долго клиент может держать арендованный адрес без его продления. Нажмите кнопку Далее, а затем нажмите кнопку Да, я хочу настроить эти параметры сейчас, чтобы расширить мастер включить параметры для наиболее распространенных параметров DHCP. Нажмите кнопку «Далее».
7. Введите IP-адрес шлюза по умолчанию, который должен использоваться клиентами, которые получают IP-адрес из этой области. Щелкните Добавить, чтобы добавить адрес шлюза по умолчанию в списке, а затем нажмите кнопку Далее.
8. Если вы используете DNS-серверы в сети, введите доменное имя организации в поле Родительский домен. Введите имя DNS-сервера и нажмите кнопку Разрешить, чтобы убедиться, что сервер DHCP может связаться с DNS-сервером и определить его адрес. Щелкните Добавить, чтобы включить этот сервер в список DNS-серверов, которые назначены клиентам DHCP. Нажмите кнопку Далее и выполните те же действия. Если вы используете сервер службы Windows (WINS), добавив его имя и IP-адрес, нажмите кнопку Далее.
9. Нажмите кнопку Да, я хочу активировать эту область сейчас, чтобы активировать область и разрешить клиентам получать аренды из нее, а затем нажмите кнопку Далее.
10. Нажмите кнопку «Готово».
11. В дереве консоли щелкните имя сервера и нажмите кнопку Авторизуя в меню Действия.

Настройка сервера для подключения по RDP

Чтобы к VDS можно было подключаться по RDP, должны быть установлены следующие роли и компоненты:

• Службы удаленных рабочих столов.

• Лицензирование удаленных рабочих столов

• Узел сеансов удаленных рабочих столов

• Шлюз удаленных рабочих столов

Все эти роли и компоненты мы установили в предыдущем разделе. Теперь нужно настроить групповую политику.

1. Открываем «Поиск» на панели инструментов.

2. Находим и открываем редактор групповых политик — gpedit.msc.

3. Переходим на ветку «Конфигурация компьютера» — «Административные шаблоны» — «Компоненты Windows» — «Службы удаленных рабочих столов» — «Узел сеансов удаленных рабочих столов» — «Лицензирование».

4. Разворачиваем пункт «Использовать указанные серверы лицензирования удаленных рабочих столов».

5. В строке «Использовать серверы лицензий» указываем имя или адрес своего сервера.

6. Возвращаемся обратно в раздел «Лицензирование» и открываем пункт «Задать режим лицензирования».

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

После настройки групповых политик переходим к самому лицензированию.

1. Открываем «Панель управления».

2. Переходим в раздел «Администрирование» — Remote Desktop Services — «Диспетчер лицензирования». 

3. Кликаем по серверу правой кнопкой и нажимаем «Активировать».

4. Выбираем метод подключения «Авто».

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

6. Запускаем мастер установки лицензий.

7. Выбираем программу лицензирования, по которой была приобретена лицензия.

8. Вводим ключ активации, который получили после покупки лицензии.

9. Указываем количество пользователей/устройств, если оно не определилось автоматически.

10. Нажимаем «Готово», чтобы завершить работу мастера установки лицензий.

Затем нужно вернуться в раздел «Администрирование» — Remote Desktop Services — «Диспетчер лицензирования» и посмотреть, активирован ли сервер. Если да, значит, настройка успешно завершена. 

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

Supported migration scenarios

This guide gives you the instructions to migrate an existing DHCP server to a server that is running Windows Server 2012 R2. This guide does not contain instructions for migration when the source server is running multiple roles. If your server is running multiple roles, we recommend that you design a custom migration procedure specific to your server environment based on the information provided in other role migration guides. Migration guides for additional roles are available on the Windows Server 2012 TechCenter (https://technet.microsoft.com/library/jj134039.aspx).

Warning

If the source server is running multiple roles, some migration steps in this guide, such as those for computer name and IP configuration, can cause other roles that are running on the source server to fail.

This guide provides instructions only for migrating DHCP data and settings from a server that is being replaced by an x64-based server running Windows Server 2012 R2.

Impact of migration on other computers in the enterprise

During migration, the source DHCP server might not be available. Therefore, client computers will not be able to obtain IP addresses from this DHCP server. We recommend that you maintain or create an auxiliary DHCP server so that client computers can obtain IP addresses while you migrate the primary DHCP server.

Be aware that if you choose to perform the migration without any auxiliary DHCP servers, all clients with valid leases must keep using those leases. If a lease for an existing client expires, that client will not be able to obtain an IP address. In addition, any new client that connects to the network will not be able to obtain an IP address when the single-source DHCP server is not available.