Tw-city.info

IT Новости
2 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Резервный контроллер домена 2020

Настраиваем резервное копирование контроллеров домена Active Directory

В этой статье мы поговорим об особенностях резервного копирования контроллеров домена Active Directory, рассмотрим, как настроить автоматическое резервное копирование AD с помощью PowerShell и встроенных средств Windows Server.

Нужно ли бэкапить Active Directory?

Не раз слышал от знакомых администраторов мысль, что если у тебя несколько (5, 10 и т.д.) территориально разнесенных контроллеров домена Active Directory, то бэкапать AD вообще не нужно, т.к. при нескольких DC вы уже обеспечили высокую отказоустойчивость домена. Ведь в такой схеме вероятность одновременного выхода из строя всех DC стремится к 0, а если один контроллер домена упал, то быстрее развернуть новый DC на площадке, а старый удалить с помощью ntdsutil.

Однако в своей практике я встречался с различными сценариями, когда все контроллеры домена оказались повреждёнными: в одном случае все контроллеры домена (а их было более 20 штук в разных городах) оказались зашифрованными из-за перехвата пароля домена шифровальщиком через утилиту mimikatz (для предотвращения таких схем см. статьи “Защита Windows от mimikatz” и “Защита привилегированных групп администраторов”), в другом случае домен положила репликация поврежденного файла NTDS.DIT.

В общем, бэкапить AD можно и нужно. Как минимум вы должны регулярно создавать резервные копии ключевых контроллеров доменов, владельцев ролей FSMO (Flexible single-master operations). Вы можете получить список контролеров домена с ролями FSMO командой:

netdom query fsmo

Как проверить дату последнего бэкапа контроллера домена Active Directory?

Вы можете проверить, когда создавалась резервная копия текущего контроллера домена Active Directory с помощью утилиты repadmin:

В данном примере видно, что последний раз бэкап DC и разделов AD выполнялся 2017-02-18 18:01:32 (скорее всего он не делался с момента развертывания контроллера домена).

Вы можете получить статус по резервному копированию всех DC в домене командой:

Бэкап контроллера домена AD с помощью Windows Server Backup

Если у вас нет специального ПО для резервного копирования, вы можете использовать для создания резервных копий встроенный Windows Server Backup (этот компонент пришел на замену NTBackup). Вы можете настроить автоматическое задание резервного копирования в графическом интерфейсе Windows Server Backup, но у него будут ряд ограничений. Основной недостаток – новая резервная копия сервера всегда будет перезаписывать старую.

При создании резервной копии контроллера домена через WSB, вы создаете резервную копию Состояния системы (System State). В System State попадает база Active Directory (NTDS.DIT), объекты групповых политик, содержимое каталога SYSVOL, реестр, метаданные IIS, база AD CS, и другие системные файлы и ресурсы. Резервная копия создается через службу теневого копирования VSS.

Вы можете проверить, установлен ли компонент Windows Server Backup с помощью PowerShell командлета Get-WindowsFeature:

Если компонент WSB отсутствует, его можно установить с помощью PowerShell:

Add-Windowsfeature Windows-Server-Backup –Includeallsubfeature

Или установите его из Server Manager -> Features.

Я буду сохранять бэкап данного контроллера домена AD в сетевую папку на отдельном выделенном сервере для резевного копирования. Например, путь к каталогу будет таким \srvbak1backupdc01. Настроим NTFS разрешения на этой папке: предоставьте права чтения-записи в этот каталог только для Domain Admins и Domain Controllers.

Резервное копирование Active Directory с помощью PowerShell

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

Import-Module ServerManager
[string]$date = get-date -f ‘yyyy-MM-dd’
$path=”\srvbak1backupdc1”
$TargetUNC=$path+$date
$TestTargetUNC= Test-Path -Path $TargetUNC
if (!($TestTargetUNC))<
New-Item -Path $TargetUNC -ItemType directory
>
$WBadmin_cmd = «wbadmin.exe START BACKUP -backupTarget:$TargetUNC -systemState -noverify -vssCopy -quiet»
Invoke-Expression $WBadmin_cmd

Запустите данный скрипт. Должна появится консоль wbadmin с информацией о процессе создании резервной (теневой) копии диска:

Я открыл журнал ошибок WSB — C:WindowsLogsWindowsServerBackupBackup_Error-10-10-2019_08-30-24.log.

В файле содержится одна ошибка:

Забегая вперед, скажу, что проблема оказалась в некорректном пути в одном из драйверов VMWware Tools.

Чтобы исправить эту ошибку, откройте командную строку с правами администратора и выполните:

DiskShadow /L writers.txt
list writers detailed

После формирование списка наберите quit и откройте файл «C:WindowsSystem32writers.txt». Найдите в нем строку, содержащую “windows\”.

В моем случае найденная строка выглядит так:

Как вы видите, используется неверный путь к драйверу VSOCK.SYS.

Чтобы исправить путь, откройте редактор реестра и перейдите в раздел HKLMSYSTEMCurrentControlSetServicesvsock.

Измените значение ImagePath с
systemrootsystem32DRIVERSvsock.sys
на
System32DRIVERSvsock.sys

Запустите скрипт бэкапа еще раз.

Если бэкап выполнен успешно, в логе появятся сообщения:

Проверим даты последнего бэкапа на DC:

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

На сервере резевного копирования размер каталога с резервной копией контроллера домена занимает около 9 Гб. По сути на выходе вы получили vhdx файл, который можно использовать для восстановления ОС через WSB, или вы можете вручную смонтировать vhdx файл и скопировать из него нужные файлы или папки.

$WBadmin_cmd = «wbadmin start backup -backuptarget:$path -include:C:WindowsNTDSntds.dit -quiet»
Invoke-Expression $WBadmin_cmd

Размер такого бэкапа будет составлять всего 50-500 Мб в зависимости от размера базы AD.

Для автоматического выполнения бэкапа, нужно на DC создать скрипт c:psbackup_ad.ps1. Этот скрипт нужно запускать по расписанию через Task Sheduler. Вы можете создать задание планировщика из графического интерфейса или из PowerShell. Главное требование — задание должно запускать от имени SYSTEM с включенной опцией Run with highest privileges. Для ежедневного бэкапа контролера домена AD создайте следующее задание:

$Trigger= New-ScheduledTaskTrigger -At 01:00am -Daily
$User= «NT AUTHORITYSYSTEM»
$Action= New-ScheduledTaskAction -Execute «PowerShell.exe» -Argument «c:psbackup_ad.ps1»
Register-ScheduledTask -TaskName «StartupScript_PS» -Trigger $Trigger -User $User -Action $Action -RunLevel Highest –Force

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

PC360

Ремонт/настройка ПК и окружающих его устройств.

Установка резервного контроллера домена на Windows Server 2019.

В связи с очень сильной бюджетностью организации и отсутствием резервного сервера и даже резервных ПК, которые хранятся на складе и в любую минуту могут быть использованы, на один администраторский компьютер ADMIN-PC, с параметрами немного лучше, чем у всех остальных в сети, пришлось переносить сервера, на время ремонта основного сервера с несколькими виртуальными машинами. Виртуальные машины этот компьютер не потянет, поэтому решено было установить несколько ОС и запускать их по очереди. Одновременно они могут понадобиться только в аварийной ситуации и к тому же это на непродолжительное время. Рассмотрим установку нескольких ОС на один ПК и затем установим на него контроллер домена Windows Server 2019.

Читать еще:  Доверительные отношения между доменами 2020

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

Создаем по инструкции загрузочную флэшку с Windows Server 2019.

Вставляем загрузочную флэшку в USB-разъем. Запускаем ПК, через BootMenu выбираем флэшку и нажимаем загрузку с неё.

Выбираем Windows Server 2019 Standard (возможности рабочего стола).

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

После перезагрузки ПК система не отобразилась в диспетчере загружаемых ОС.

Нужно отметить, что до начала установки этой ОС в ADMIN-PC уже были установлены Windows 7, Windows 10 и Windows Server 2012. Запускаем любую из установленных ранее ОС. Если нет возможности запустить ни одну из операционных систем, тогда нужно править загрузчик вручную. Это отдельный случай.

Загрузив, допустим, Windows 7, скачиваем и запускаем программу для редактирования загрузки EasyBCD.

Выбираем пункт меню – Добавить запись.

Операционные системы – Windows.

Тип – Windows Vista/7/8, в бесплатной версии Win10 нет, поэтому оставляем так.

Имя – любое понятное для нас, латиницей.

Диск – указываем диск, на который начали устанавливать WinSrv2019.

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

В пункте меню «Редактировать меню загрузки» можно поправить отображаемое при загрузке имя ОС и отметить галочкой, какая система будет загружаться по умолчанию.

Нажимаем кнопку «Сохранить». Перезагружаем ПК и проверяем выполненные настройки. Выбираем из появившегося списка Windows Server 2019 и ждем пока завершится установка ОС.

По внешнему виду ОС очень похожа на Windows 10.

Переименовываем сервер. В нашей сети он будет известен как DCSERVER2. Антивирус можно не ставить т.к. есть встроенный Windows Defender.

Подключаем сервер в локальную сеть, назначаем статический IP-адрес. DNS от основного контроллера домена.

Переходим к настройке контроллера домена.

Запускаем диспетчер серверов, в панели мониторинга нажимаем – Добавить роли и компоненты. Откроется мастер добавления.

Перед началом работы >> Далее.

Тип установки – Установка ролей и компонентов >> Далее.

Выбор сервера – выбираем требуемый DCSERVER2 >> Далее.

Роли сервера – отмечаем галочками DNS-сервер и Доменные службы Active Directory >>Добавить компоненты >> Далее. DHCP в нашей сети не используется.

DNS, AD DS >> Далее.

Ждем установку, если понадобится перезагружаем сервер.

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

В первом пункте мастера настройки доменных служб Active Directory выбираем – Добавить контроллер домена в существующий домен.

Напротив надписи Домен нажимаем кнопку «Выбрать». Выбираем нужный домен, у нас SCRB.local. Вводим учетные данные администратора из домена. >>Далее.

Следующим пунктом придумываем пароль для режима восстановления служб каталогов DSRM. Можно оставить галочку напротив надписи Глобальный каталог. >>Далее.

Делегирование для этого DNS-сервера невозможно создать… >>Далее.

Дополнительные параметры – указываем источник репликации – основной контроллер домена DCSERVER.

Пути оставляем без изменения. >> Далее.

Параметры подготовки >> Далее.

Просматриваем выбранные параметры >> Далее.

Во время проверки предварительных данных вылез «подводный камень». Не выполнено одно или несколько предварительных требований. Исправьте ошибки и щелкните «Повторить проверку предварительных требований».

Критическая ошибка отмечена красным кружком с крестиком и звучит так:

Сбой проверки предварительных требований для подготовки Active Directory. Не удалось проверить, завершил ли хозяин схемы цикл репликации после последней перезагрузки.

Исключение: Недопустимое критическое расширение. Расширенное сообщение об ошибке сервера:8366. Расширенное сообщение сервера:000020AE: SvcErr: DSID-032103F9, problem 5010 (UNAVAIL_EXTENSION), data 8610.

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

Возможную причину сбоя см. в файле журнала ADPrep.log в каталоге C:Windowsdebugadpreplogs2019114122331-test.

Для устранения этой ошибки есть два варианта:

1.Устранить из домена все следы контроллера домена, с которым не прошла репликация.

2.Запустить этот контроллер домена, если он еще «живой», и подождать, пока пройдет репликация.

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

После запуска старого резервного контроллера домена на виртуальной машине проверка предварительных требований была пройдена. Жмем кнопку >>Установить.

Окно Результаты можно закрыть. Пройдет установка и сервер автоматически перезагрузится.

После перезагрузки в Active Directory – пользователи и компьютеры, можно увидеть новый контроллер домена DCSERVER2.

Контроллер домена работает. Можно проверить пользователей, они все на месте.

Переходим к удалению предыдущего резервного контроллера домена с ОС Windows Server 2008R2 (WIN-SRV-ST, третий в списке) для того, чтоб разобрать главный сервер на ремонт.

Дополнительный контроллер домена 2008 R2 к существующему домену под управлением 2003 R2

Структура организации следующая: есть домен для сотрудников под названием domain.int, есть также и его поддомен для других нужд – subdomain.domain.int. Возникла задача перевести существующий поддомен под управлением Windows Server 2003 R2 на Windows Server 2008 R2. Причем главный домен уже переведен.

Просто накатить сверху систему нельзя – 2003 R2 является 32-битной версией, а 2008 R2, соответственно, – 64-битная. А было бы здорово. Выбор невелик, поэтому решили сделать следующее:

  1. Устанавливаем дополнительный контроллер домена (КД) на Windows Server 2008 R2
  2. Новый контроллер должен иметь роли глобального каталога и DNS
  3. Проверяем работу и репликацию обоих контроллеров
  4. Указываем, что новый КД (2008) – хозяин операций
  5. Удаляем из схемы старый КД (2003)
  6. Проверяем работу и начинаем подготовку к настройке уже реально другого дополнительного КД, чтобы на выходе получить два КД под управлением 2008 R2
  7. Забываем, что когда-то у нас в сети был КД под управлением 2003 R2
Читать еще:  Настройка групповых политик домена

Почему решили перевести КД на другую схему, думаю, всем ясно. На дворе уже 2013 год, 2014 не за горами. Почему бы не воспользоваться проверенными и более новыми технологиями? Windows Server 2012 на момент написания статьи пока не вышел в релизе R2. А исходя из многолетнего опыта использования Microsoft, не стоит что-то внедрять на том, что вышло совсем недавно. К тому же немного бесит, что статей в интернете по новым продуктам мало. Именно поэтому сделали выбор на системе Windows Server 2008 R2. В данной статье я буду описывать последовательные действия для 1 и 2 пункта моего плана.

Что подвигло написать статью? Ответ прост: в интернете мало статей по субдоменам. И пускай ничего супер-естественного в настройке нет. Зато наши читатели узнают, что все проходит достаточно просто и последовательно, как по аналогии при лесе с одним доменом. А наш сайт любит хоть и маленькие, но все же эксклюзивы. К тому же, излагаться все будет просто и на обычном языке, понятным даже для самых маленьких админов.

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

Далее кликаем на установке новой роли и указываем, что нам надо “Доменные службы Active Directory”:

Начинаем установку этой роли:

Заметили, что автоматом поставился компонент .Net Framework 3.5? Поэтому после всех установок сразу “подхватываются” обновления:

Ну вот и все установилось. Даже не пришлось перезагружаться. Я начинаю приятно удивляться Microsoft. Посудите сами – одна из самых серьезных ролей и компонент только что установились, да еще и обновления, а перезагрузка не требуется. Заметили самую первую ошибку? Причина ошибки написана выше, а именно то, что надо бы настроить наш будущий КД:

Поэтому прямо оттуда или из режима командной строки запускаем утилиту DCPROMO.EXE:

Не надо нажимать нам “расширенный режим”. Делаем все по стандартно. По-хорошему, в лучших традициях Microsoft все должно быть по сценарию Далее+Далее+Финиш=Все_работает. Посмотрим как это будет дальше. Соглашаемся с первым окном приветствия:

Затем подсказываем мастеру, что у нас будет добавочный КД:

Затем прописываем имя домена. Можно главный domain.int, а можно и поддомен – subdomain.domain.int. И учетную запись администратора домена само собой. Вы же под ней и делаете?

Теперь главное не перепутать и указать уже точно, в каком домене будем работать. Нам надо поддомен subdomain.domain.int:

Ну вот… начинаются приключения. Так и знал:

Сам виноват, не подготовил домен для перехода. Зато все теперь последовательно все исправим. Идем на главный КД под управлением Windows Server 2003 R2 и вставляем туда диск с нашей системой 2008 R2. Я скопировал все утилиты на диск С, но это необязательно. Запускаем утилиту adprep /domainprep:

Вот я снова невнимательный. Утилита-то 64-битной версии. Поэтому пробуем на 32-битной редакции. Кажется получилось, хотя могли бы и вывести сообщение об успехе:

Теперь запускаем снова утилиту DCPROMO и проделываем все тоже самое. Вместо ошибки получаем следующее окно мастера. Значит та утилита все-таки помогла подготовить домен. Мастер нас спрашивает, какой точно сайт нам нужен. У меня их 3, у вас может быть другое количество. Название не спутаешь, поэтому с уверенностью кликаем “далее”:

Затем мастер спрашивает, добавить ли из будущему КД роли DNS и Global Catalog. Это пригодится будущем, поэтому соглашаемся. Пугаться не надо: в сети может быть несколько DNS и глобальных каталогов. Это, кстати, очень хорошо с точки зрения отказоустойчивости:

Системные папки для хранения баз данных Active Directory и другого оставляем по-умолчанию:

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

Кажется на этом наши настройки закончились. Нажимаем далее и ждем, пока все сделается:

Видим, что все установилось, поэтому смело перезагружаемся:

И на этом все. Репликация получилась, КД начал функционировать нормально. Еще совет для малоопытных админов – не торопитесь и делайте все последовательно. Могу также в качестве бонуса сообщить один нюанс. Загрузка КД и репликация с главным контроллером может происходить очень долго. Лично у нас все “поднялось” спустя несколько часов. Были моменты, когда казалось, что КД не работает как контроллер. Но мы набрались терпения и дождались результата. Все остальные действия моего плана выполнились практически без каких-либо происшествий. Их можно посмотреть в интернете, информации полно.

Друзья! Вступайте в нашу группу Вконтакте, чтобы не пропустить новые статьи! Хотите сказать спасибо? Ставьте Like, делайте репост! Это лучшая награда для меня от вас! Так я узнаю о том, что статьи подобного рода вам интересны и пишу чаще и с большим энтузиазмом!

Также, подписывайтесь на наш канал в YouTube! Видео выкладываются весьма регулярно и будет здорово увидеть что-то одним из первых!

Что собой представляет контроллер домена, доступный только для чтения (RODC)?

RODC — новый режим контроллера домена (DC) в Windows Server 2008. На таком DC можно сохранить экземпляр базы данных домена Active Directory (AD), доступный только для чтения, но его функциональность гораздо шире, чем у простого экземпляра базы данных, пригодного только для чтения. Основные функции RODC:

В. Что собой представляет контроллер домена, доступный только для чтения (RODC)?

О.

  • База данных AD Domain Services (AD DS) только для чтения. Приложения, которым нужен доступ только для чтения базы данных, могут использовать RODC; но все изменения необходимо выполнять на DC с возможностью чтения и записи (RWDC), а затем реплицировать на RODC.
  • Односторонняя репликация. Из RODC нельзя распространить ложные данные по остальному домену, даже если изменение сделано на RODC. Таким образом снижается опасность атаки против всей системы и сложность структуры репликации.
  • Конфигурация с набором фильтрованных атрибутов. Набор фильтрованных атрибутов не реплицируется ни на один RODC в лесе. Если RODC скомпрометирован и набор изменен, то в отличие от Windows Server 2003 DC, Server 2008 RWDC не реплицирует значения. Если возможно, лучше установить функциональный уровень леса Server 2008, запретив использование серверов Server 2003 в лесе, где они могут испортить данные. Кроме того, важно отметить, что нельзя добавлять критические системные атрибуты в набор фильтрованных атрибутов RODC.
  • Ограниченное кэширование учетных данных. RODC не хранит учетные данные пользователя или компьютера (за исключением учетной записи компьютера RODC). Получая запрос проверки подлинности, RODC передает его в RWDC. Затем RODC запрашивает копию учетных данных, чтобы в будущем самостоятельно обслуживать запрос. Если политика репликации пароля допускает кэширование учетных данных, то они будут записаны в кэш, и RODC сможет обслуживать запросы на регистрацию (пока учетные данные не изменятся).
  • Отделение возможностей администратора. RODC может назначать пользователей администраторами сервера, не предоставляя им прав в домене или на других DC.
  • DNS только для чтения. RODC DNS не позволяет обновлять клиентов и не регистрирует записи ресурсов имени службы.
  • Двухэтапная установка RODC. Первый этап установки выполняется администратором с учетными данными. Он создает учетную запись AD DS для RODC со всей информацией распределенной базы данных AD, в том числе именем учетной записи DC и местонахождением сайта. Затем администратор может указать пользователей и группы, которые могут выполнить второй этап установки, обычно удаленно. На втором этапе AD DS устанавливается на RODC, и учетная запись AD DS привязывается к серверу.
Читать еще:  Срок действия пароля в домене

RODC может реплицировать данные только с Windows Server 2008 RWDC, поэтому репликация из контроллеров домена Windows Server 2003 и других Windows Server 2008 RODC невозможна.

Поделитесь материалом с коллегами и друзьями

Контроллер домена Active Directory: плюсы и настройка

Основным элементом эффективной корпоративной сети является контроллер домена Active Directory, управляющий многими службами и дающий многие преимущества.

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

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

“Домен — базовая единица ИТ-инфраструктуры на базе ОС семейства Windows, логическое и физическое объединение серверов, компьютеров, оборудования и учетных записей пользователей.”

Контроллер домена (КД) — отдельный сервер с ОС Windows Server, на котором запущены службы Active Directory, делающие возможной работу большого количества ПО, требующего КД для администрирования. Примерами такого ПО является почтовый сервер Exchange, облачный пакет Office 365 и другие программные среды корпоративного уровня от компании Microsoft.

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

  • Развертывание терминального сервера. Терминальный сервер в облаке позволяет значительно сэкономить ресурсы и усилия, заменяя постоянное обновление офисных ПК единоразовой инвестицией в размещение “тонких клиентов” для подключения к мощному облачному серверу.
  • Повышенная безопасность. КД позволяет задавать политики создания паролей и заставлять пользователей применять более сложные пароли чем дата своего рождения, qwerty или 12345.
  • Централизованный контроль прав доступа. Вместо ручного обновления паролей на каждом компьютере отдельно, администратор КД может централизованно сменить все пароли за одну операцию с одного компьютера.
  • Централизованное управление групповыми политиками. Средства Active Directory позволяют создать групповые политики и задать права доступа к файлам, папкам и другим сетевым ресурсам для определенных групп пользователей. Это в разы упрощает настройку учетных записей новых пользователей или изменение параметров существующих профилей.
  • Сквозной вход. Active Directory поддерживает сквозной вход, когда при вводе своего логина и пароля для домена, пользователь автоматически подключается ко всем остальным службам типа почты и Office 365.
  • Создание шаблонов настройки компьютеров. Настройка каждого отдельного компьютера при добавлении его в корпоративную сеть может быть автоматизирована с помощью шаблонов. Например, с помощью специальных правил могут быть централизованно отключены CD-приводы или USB-порты, закрыты определенные сетевые порты и так далее. Таким образом, вместо ручной настройки новой рабочей станции, администратор просто включает ее в определенную группу, и все правила для этой группы применятся автоматически.

Как видите, настройка контроллера домена Active Directory несет многочисленные удобства и преимущества для бизнеса и организаций любого размера.

Когда внедрять контроллер домена Active Directory в корпоративную сеть?

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

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

  • Ошибочные настройки DNS-сервера, что приводит к ошибкам локации ресурсов в корпоративной сети и в сети Интернет
  • Некорректно настроенные группы безопасности, приводящие к ошибкам прав доступа пользователей к сетевым ресурсам
  • Некорректные версии ОС. Каждая версия Active Directory поддерживает определенные версии десктопных ОС Windows для тонких клиентов
  • Отсутствие или неправильная настройка автоматического копирования данных на резервный контроллер домена.

Чтобы использовать ресурсы вашей корпоративной сети максимально эффективно, безопасно и с наименьшими затратами средств и усилий, выбирайте только профессиональных поставщиков ИТ-услуг!

Ссылка на основную публикацию
ВсеИнструменты 220 Вольт
Adblock
detector
×
×