Глава 3. Центральные службы инфраструктуры

Если мы собираемся обсуждать службы центральной инфраструктуры которые вам нужны чтобы собрать воедино вашу управляемую Microsoft сетевую среду, не будет лучшего места для начала чем роль вашего контроллера домена. Контроллер домена (domain controller), обычно называемый DC, является центральной точкой общения, неким видом центрального хаба, к которому осуществляется доступ, прежде чем имеет место практически любое сетевое взаимодействие. Простейший способ описать его, это контейнер хранения для всех идентификаций, происходящих в вашей сетевой среде. Имена пользователей, пароли, учётные записи компьютеров, группы компьютеров, серверы, группы и коллекции серверов, политики безопасности, службы репликации файлов и многие, многие другие вещи хранятся внутри и управляются DC. Если вы не планируете иметь Контроллер домена в качестве одного из самых первых серверов в вашей сетевой среде на основе Microsoft, вы можете даже не начинать строить эту сетевую среду. Они являются существенными для способа, которым наши компьютеры и устройства взаимодействуют друг с другом и с серверной инфраструктурой внутри нашей компании.

Если вы остановились в данном месте чтобы перейти к установке роли своего Контроллера домена на вашем сервере, вернитесь, пожалуйста, назад, так как не существует роли под названием контроллер домена. Роль, которая предоставляет все эти возможности называется Службами домена Active Directory (AD DS, Active Directory Domain Services). Именно эту роль вам необходимо установить на сервере. Установив эту роль, вам будет нужно включить ваш сервер в Контроллер домена. Цель работы DC заключается в создании этого каталога, или базы данных, элементов в вашей сетевой среде. Эта база данных называется Active Directory и является платформой, внутри которой вы выстраиваете иерархическую структуру для хранения объектов, таких как имена пользователей, пароли и учётные записи компьютеров. {Прим. пер.: рекомендуем ознакомиться с рецептом Настройка комбинации Контроллера домена, сервера DNS и сервера DHCP описывающим последовательность создания вашего первого сервера Контроллера домена.}

Когда вы создадите некий домен, в котором вы можете хранить эти учётные записи и устройства, вы сможете затем создавать учётные записи пользователей и пароли для ваших сотрудников чтобы применять их при аутентификации. Затем вы также присоедините свои другие серверы и компьютеры в этот домен с тем, чтобы вы могли принимать и получать преимущества от таких пользовательских полномочий. Наличие и подключение в домен являются секретным соусом, который делает возможным вам переходить с компьютера на компьютер внутри вашей компании и регистрироваться на каждом из них с вашими собственными именем и паролем, даже если вы никогда не регистрировались на этом компьютере ранее. Ещё более мощным является то, что он делает возможной аутентификацию приложениям с поддержкой AD напрямую в Active Directory когда им понадобится информация об аутентификации. Например, когда я, будучи пользователем домена, регистрируюсь на своём компьютере на работе со своими именем пользователя и паролем, работающий на моём компьютере Windows обращается к серверу контроллера домена и удостоверяется, что мой пароль верный. Когда он получит подтверждение что я в действительности тот, кем я представился, он выпускает маркер (token) аутентификации обратно на мой компьютер и я получаю возможность зарегистрироваться. Затем, после того как я вошёл на своё рабочее место и я открыл некое приложение, например, я открыл свой Outlook для доступа к своей электронной почте, эта программа электронной почты разработана для доступа к моему серверу электронной почты, называемому Exchange Server, и она выполняет аутентификацию на нём чтобы убедиться, что отображается именно мой почтовый ящик, причём не кому-бы то ни было ещё. Означает ли это, что я должен повторно ввести свои имя пользователя и пароль для Outlook или для какого- то другого приложения, которое я открываю на своём компьютере? Нет. И причина, по которой мне не нужно повторно подтверждать свои полномочия вновь и вновь заключается в том, что моё имя пользователя, моё компьютер, а также все сервера приложений, все они являются частью общего домена. Когда это выполняется, и это действует для большинства сетевых сред, мой маркер (token) аутентификации может совместно использоваться моими программами. Поэтому, после того как я единожды зарегистрировался на своём компьютере, мои приложения могут запускаться и открываться, а также передавать мои полномочия на сервер приложений, причём без какого либо дополнительного ввода от меня как от пользователя. Несомненно, было бы крайне разочаровывающей практикой если бы мы просили своих пользователей вводить пароли весь день, причём каждый день, всякий раз, когда они открывают те программы, которые им нужны чтобы выполнять свою работу.

Самый первый контроллер, который вы настроите в своей сетевой среде будет полностью редактируемым, способным принимать данные от подключённых к домену пользователей и от работающих внутри вашей сети компьютеров. На самом деле, большинство DC в вашей сетевой среде, скорее всего, будут полностью функциональными. Однако, стоит потратить минутку чтобы указать на возможность установки DC с ограниченной сферой называемый RODC (Read-only domain controller). В точности как и предписывает его название, RODC может выполнять только чтение данных из имеющегося у него каталога. RODC не могут осуществляться попытки выполнения записи изменений паролей в домене или создания нового пользователя. Где можно было бы воспользоваться преимуществами Контроллера домена с ограниченным доступом? Многие компании устанавливают их в офисах небольших подразделений или на площадках с меньшей безопасностью с тем, чтобы все локальные компьютеры на этой площадке всё ещё имели быстрый и простой доступ на чтение из данного домена и аутентификацию в нём, без потенциальной опасности безопасности того, что пользователь без соответствующей авторизации получит доступ к физическому серверу и осуществит манипуляции со всем доменом в своих грязных целях.

Active Directory сам по себе достаточно обширная тема чтобы обеспечить свою собственную книгу, и на самом деле существует много написанного по данной тематике. Теперь, когда у нас имеется базовое представление чем оно является и почему оно критически важно для среды Windows Server, давайте испачкаем свои руки применив некоторые из инструментов, которые устанавливают ваш контроллер домена в процессе настройки вашей роли AD DS.

Нет отдельного инструмента, который применяется для управления всеми гранями Active Directory. Так как это очень обширная технология, наша настройка всего каталога подразделяется между различными консолями управления. Давайте рассмотрим каждую из них, а также пару наиболее распространённых задач, которые вы сможете выполнять внутри этих инструментов. Некоторые из этих консолей управления могут запускаться на любых ваших серверах контроллера домена и, как мы уже видели в предыдущей главе, самый простой способ запустить эти консоли состоит в непосредственном старте из меню Tools в правом верхнем углу Диспетчера сервера (Server Manager).

Я начну с инструмента, который является последним в алфавитном порядке в списке инструментов Active Directory, так как он безоговорочно является тем, что в повседневной практике администратор сервера выполняет наиболее часто. AD Users and Computers является консолью, из которой создаются и управляются все имеющиеся учётные записи пользователей и компьютеров. Откройте её и вы увидите имя вашего домена в перечне в левом столбце. Раскройте своё имя домена и вы увидите ряд перечисленных здесь папок. Если вы откроете их в существующем контроллере домена сильно разросшейся сетевой среды, вы можете получить страницы и страницы перечисленных здесь папок. Если это новая среда, присутствует лишь пригоршня. Наиболее важно отметить здесь присутствие Computers и Users. Как то и диктовал бы здравый смысл, это контейнеры по умолчанию, в которых находятся новые учётные записи компьютеров и пользователей, которые присоединяются к домену, в котором они будут располагаться.

Хотя это окно и выглядит слегка похоже на File Explorer на дерево папок, эти "папки" на самом деле совсем не являются папками. Каждая иконка браслета цветной папки которую вы здесь видите называется OU (Organizational Unit, Подразделением). Подразделения являются структурными контейнерами, которые применяются внутри Active Directory для организации наших объектов и хранения их в имеющих смысл местах. В точности так же как и с папками в файловом сервере, вы можете создавать свою собственную иерархию Подразделений здесь, чтобы упорядочивать и манипулировать местоположением внутри Active Directory всех ваших присоединённых к домену сетевых объектов и устройств. На следующем снимке экрана вы можете заметить, что помимо наличия только Подразделений Computers и Users, я создал некоторые новые OU, содержащие подкатегории с тем, чтобы по мере того, как я наращиваю свою среду, я бы имел более структурированный и более организованный каталог.

Учётные записи пользователей

Теперь, когда у вас имеется новое Подразделение готовое упорядочивать наши объекты, давайте создадим нового пользователя. Скажем, у нас имеется новый Администратор сервера, выходящий на площадку и нам необходимо предоставить ему вход в Active Directory с тем, чтобы он мог начать свою работу. Просто пройдите в соответствующее Подразделение для его учётной записи чтобы разместить его, кликните правой кнопкой по этому OU и переместитесь в New | User. Затем нам будет представлен экран сбора информации об всех вещах, которые нужны AD чтобы создать такую новую учётную запись.

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

Группы безопасности

Другим полезным организационным элементом внутри Active Directory являются Security Groups (Группы безопасности). Мы можем делать некое отличие между различными типами и видами учётных записей пользователей и компьютеров при помощи Подразделений (OU), однако, что если в данной структуре нам требуется некоторое смешение? Возможно, у нас имеется сотрудник, который обрабатывает некоторые кадры, а также отвечает за учётные записи. Может быть существует вероятность, что мы настроили права на файлы и папки в наших файловых серверах таким образом, что только люди, являющиеся частью определённой группы имеют доступ на чтение и запись в определённые папки. Для Сьюзи из кадров нужно иметь доступ к папке платёжных ведомостей, однако Джиму из кадров нет. Создав Группы безопасности внутри Active Directory мы делаем возможным добавление и удаление определённых учётных записей пользователей, компьютеров или даже прочих групп таким же образом, как вы создаёте учётные записи пользователей, выбирая OU, в котором вы желаете расположить новую группу, затем кликнув правой кнопкой по этому Подразделению и переместившись в New | Group. Когда ваша группа создана, кликните правой кнопкой по ней и проследуйте в Properties. Затем вы можете кликнуть по закладке Members; именно сюда вы добавляете всех своих пользователей, которых вы хотите сделать участниками этой новой группы.

Предварительная наладка учётных записей компьютера

Хотя это и очень распространено применять Users и Computers Active Directory для создания новых учётных записей пользователей, намного менее распространено даже думать об открытии этого инструмента при подключении новых компьютеров в ваш домен. Это происходит происходит благодаря тому способу, которым настроено большинство доменов, а именно: для новых компьютеров допускается присоединение к домену без какой- либо предварительной настройки. Другими словами, раз уж некто знает имя пользователя и пароль, которые имеют административные права в домене, они могут могут располагаясь на этом локальном компьютере подсоединиться к вашей сетевой среде и пройти процесс подключения в домен на этом же компьютере. Он успешно присоединится к данному домену, а Active Directory автоматически создаст для него новый объект компьютера. Такая автоматическая генерация объектов компьютера помещает их внутри OU по умолчанию Computers, поэтому во многих сетях если вы кликаете по Подразделению Computers, вы увидите ряд перечисленных машин, и они могут даже содержать смесь как из настольных компьютеров, так и из серверов, которые были недавно присоединены к домену и не были перемещены пока в соответствующее, более подходящее Подразделение (OU). В моей развивающейся среде лаборатории я только что присоединил клиентский компьютер с названием Win10 и пару серверов именуемых CA1 и DC2 в свой домен.

Я ничего не делал перед этим в Active Directory для присоединения этих машин к данному домену, и поэтому мы можем видеть, что новые объекты компьютера всё ещё расположены внутри этого определённого по умолчанию контейнера Computers.

Допуск возможности новым учётным записям компьютера размещать себя внутри OU по умолчанию Computers обычно не является большой проблемой для систем клиентов, однако если вы позволите серверам автоматически создаваться в этой же самой папке, это может создать большие проблемы. Многие компании имеют политики безопасности на местах по всей сетевой среде, а эти политики часто создаются таким образом, что они будут автоматически применяться к любой учётной записи компьютера, размещаемой в обобщённом Подразделении (OU). Применение политик безопасности может быть великолепным способом для блокировки частей клиентских машин, к которым пользователи не должны иметь доступ или которые они не должны применять, однако, если вы невнимательно вызовете применение таких "блокирующих" политик к вашим новым серверам как только они подключаются к домену, вы можете фактически разрушить сервер даже до запуска его настроек. Доверьтесь мне, я это делал. И к сожалению ваши новые учётные записи сервера которые добавляются в Active Directory будут идентифицироваться и классифицироваться в точности так же, как любая клиентская рабочая станция которая добавляется в домен, поэтому вы не можете определять отличные контейнеры по умолчанию для серверов, потому что они являются сервером, а не обычной рабочей станцией.

Итак, что мы можем сделать, чтобы облегчить эту потенциальную проблему? Выполняйте предварительную подготовку (prestaging) учётной записи для ваших новых серверов. Вы даже можете предварительно готовить все новые учётные записи компьютеров, в качестве принципиального момента, однако я обычно вижу это требование только в крупных корпорациях. Предварительная подготовка учётной записи компьютера во многом аналогична созданию новой пользовательской учётной записи. Перед присоединением компьютера к данному домену, вы создаёте такую учётную запись для него внутри Active Directory.

Выполнив создание данного объекта до процесса подключения к домену, вы получаете возможность выбрать в каком подразделении (OU) будет расположен данный компьютер когда он подключится к этому домену. Затем вы можете обеспечить, что это Подразделение, которое будет или нет принимать настройки безопасности и политики, которые вы намерены иметь на месте такого нового компьютера или сервера. Я настоятельно рекомендую выполнять предварительное размещение учётных записей компьютера в Active Directory для всех новых серверов которые вы запускаете. Если вы будете следовать этой практике, даже если она не требуется на постоянной основе, вы создадите хороший обычай, который в определённый день убережёт вас от необходимости повторного построения сервера, который вы разрушили просто присоединяя его к своему домену.{Прим. пер.: см. дополнительные подробности в рецепте Предварительная подготовка учётной записи компьютера в Active Directory}

Эти инструменты обычно применяются только в средах большего размера, которые имеют более одного домена в рамках одной и той же сетевой среды. Компания может применять множество имён домена чтобы разделять ресурсы или службы, или же для лучшей организационной структуры своих серверов и пространств имён внутри всей компании. Существует также другой уровень в иерархической структуре Active Directory, о которой мы пока не говорили, и она называется лесом (forest). Лес обычно является верхним уровнем вашей структуры Active Directory с доменами и субдоменами приходящими под этот зонтик леса. Другой способ восприятия такого леса это ограничение вашей структуры AD. Если у вас имеется множество доменов в рамках отдельного леса, это не обязательно означает, что такие домены доверяют друг другу. Поэтому могут иметь, а могут и нет полномочия для доступа к ресурсам одного из прочих доменов на основании определённого уровня доверия, который существует между такими доменами. Когда у вас имеется домен и добавляются дочерние домены под ним, существуют автоматически помещаемые права между такими доменами, однако если у вас нет необходимости соединять некие домены вместе каким- либо иным способом отличным от установленных по умолчанию полномочий, именно Active Directory Domains and Trusts является тем инструментом управления, который вы применяете чтобы устанавливать и изменять такие полномочия доверия.

Растущие организации часто обнаруживают себя в положении, когда они нуждаются в постоянном управлении доверием домена как результат приобретения бизнеса. Если Contoso покупает Fabrikam, и обе компании имеют полностью функциональные среды домена, зачастую будет преимущественным работать с использованием процесса расширенной миграции, заключающимся в введением сотрудников Fabrikam в Active Directory Contoso, нежели испытать все потери, связанные с простым отключением сетевой среды Fabrikam. Поэтому, в течение определённого периода времени вы пожелаете работать в двух доменах одновременно и можете установить доверительные отношения между этими доменами, чтобы сделать это возможным.

Если вы обнаружите себя в положении, при котором необходима миграция домена какого- либо вида, существует доступный инструмент, который вы можете захотеть применить. Он называется ADMT (Active Directory Migration Tool) и может оказаться очень полезным в ситуации, подобной описанной выше. Если у вас есть интерес рассмотреть этот инструмент поближе, вы можете загрузить его по ссылке https://www.microsoft.com/en-us/download/details.aspx?id=19188.

Sites and Services является другим инструментом, который обычно применяется компаниями со значительными инфраструктурами Active Directory. Как и в случае с любым сервером, если наличие одного контроллера домена это хорошо, то наличие двух контроллеров домена это ещё лучше. Чем больше растёт ваша компания, то же самое происходит и с вашей инфраструктурой Active Directory. Прежде чем вы узнаете об этом, вы будете исследовать настройки серверов во втором местоположении, затем в третьем и так далее. При сетевой среде с централизованным доменом, наличие серверов контроллера домена на каждой значительной площадке является общей практикой, а вы вскоре будете наблюдать десятки серверов контроллера домена работающими в вашей сетевой среде.

Достаточно просто включать новые контроллеры домена и присоединять их в ваш существующий домен с тем, чтобы начать обслуживать пользователей и компьютеры. Более тяжёлая часть состоит в сохранении организации всего обмена и потоков, когда вы захотите сделать это. Если у вас имеется первичный центр обработки данных, в котором расположены основные серверы, у вас, вероятно, имеется множество DC на площадке в этом ЦОД. На самом деле, чтобы сделать ваш AD высоко доступным, существенно чтобы вы имели по крайней мере два контроллера домена. Однако затем вы строите новый офис, который значительно растёт, что делает существенной установку локального сервера DCв этом офисе также, с тем, чтобы компьютеры из этого офиса не осуществляли доступ через WAN (Wide Area Network, глобальную сетевую среду), чтобы выполнять всякий раз аутентификацию. Если вы раскрутили некий сервер в таком новом офисе и включили его в контроллер домена для вашей сетевой среды, это должно начать работать немедленно. Проблема состоит в том, что компьютеры клиентов не всегда настолько сообразительны, чтобы понять к какому именно DC им стоит обращаться. Вы теперь можете иметь компьютеры в удалённом офисе, которые всё ещё выполняют аутентификацию опять же в DC главного ЦОД. Что даже ещё хуже, вы, вероятно, также имеете компьютеры в головном офисе, которые теперь осуществляют доступ через WAN для аутентификации с вашим новым DC, который располагается в вашем же удалённом офисе, даже несмотря на то, что существуют DC прямо в локальной сетевой среде по соседству с ним!

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

Вот быстрый взгляд на Active Directory Sites and Services. Существует высокая вероятность того, что вы воспользуетесь этим инструментом в один из дней, если вы являетесь частью растущей организации:

Хотя инструменты, которые мы рассматривали критически важны для понимания и знакомства с ними чтобы управлять Active Directory, вы можете сказать, что их эстетический вид слегка устарел. Active Directory Administrative Center (Центр администрирования AD), с другой стороны, имеет более модернизированный интерфейс, который выглядит и воспринимается как Диспетчер сервера, который для нас всё более и более комфортным. Многие доступные в ADAC функции выполняют те же самые вещи, которые мы уже можем делать посредством прочих инструментов, однако он помещает эти функции в более структурированном интерфейсе который переносит наиболее употребимые функции вверх на поверхность и делает его более простым в работе.

Один великолепный пример находится прямо на странице запуска ADAC. Общая задача справочного стола в любой сетевой среде состоит в переустановке паролей для учётных записей пользователей. Будь то случай, когда пользователь забыл свой пароль, изменил его и допустил ошибку вводе, либо если вы сбросили пароль в процессе другого вида поиска неисправностей, переустановка пароля для учётной записи обычно drk.xftn множество кликов мышкой чтобы выполнить эту работу. Теперь здесь присутствует быстрая ссылка с названием Reset Password, отображённая прямо здесь, на главной странице Active Directory Administrative Center. Также полезной является функция Global Search, следующее справа за ним, в котором вы можете набрать нечто в поле поиска и он обыщет весь ваш каталог на предмет связанных с вашим поиском результатов.

Это другая распространённая задача в AD, которая ранее требовала множества кликов для своего выполнения.

Если вы кликните по имени своего домена в левом дереве навигации, вы погрузитесь немного глубже в общие возможности ADAC. Как вы можете видеть, перечисленная информация вытаскивается из Active Directory и выглядит как та же информация, которую вы могли бы наблюдать в AD Users and Computers. Это верно, за исключением того, что вместо необходимости кликать правой кнопкой мыши, теперь у вас имеется некое быстрое меню Tasks, доступное справа, которое может быстро запускать вам для исполнения эти функции. Также интересными являются ссылка для наращивания леса (forest) или уровня функциональности домена в этом экране. Чтобы сделать это при помощи классических инструментов, я наблюдал, что большинство администраторов выполняют это запуская AD Domains and Trusts. Таким образом, одним из крупных преимуществ самого нового инструмента ADAC является то, что он способен предоставить вам централизованное управляющее окно и консоли управления. Вы почувствовали общую тему на протяжении Windows Server 2016 с повсеместной централизацией управления?

Динамичное управление доступом

Помимо обучения старых псов новым фокусам, Active Directory Administrative Center также привносит некую новую функциональность в основную таблицу, которая не доступна нигде в классических инструментах. Если вы вновь взглянете на ваше дерево слева, вы обнаружите, что следующий раздел в списке это DAC (Dynamic Access Control, Динамичное управление доступом). Это технология, которая целиком посвящена безопасности и управлению вашими файлами, а именно, данных компании, которые вы должны усиленно сохранять и гарантировать, что они не попадут в плохие руки. DAC даёт вам возможность помечать файлы, тем самым классифицируя их для определённой группы использования. Затем вы можете создать политики Управления доступом (Access Control), которые определяют кто имеет доступ к этим помеченным определённым образом файлам. Другим мощным свойством Динамичного управления доступом является функциональность отчётов. Когда DAC установлена и работает в вашей среде, вы можете делать отчёты и расследования по своим файлам, например нахождение перечня людей, кто их них недавно осуществлял доступ к классифицированным документам.

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

Мы не можем свернуть обзор важных инструментов и компонентов Active Directory не упомянув RODC (Read-only domain controller, Контроллер домена, доступный только для чтения). Обычно, при установке новых контроллеров домена в вашей сетевой среде, вы добавляете конкретную роль, которая делает его обычным, записываемым, полностью функционирующим DC в вашей сетевой среде с тем, чтобы он мог выполнять все стороны такой роли DC. Существуют некоторые обстоятельства, при которых это не будет наилучшим вариантом использования, и в этом случае нам на помощь приходит RODC. Это не отдельная роль, однако совершенно другая настройка той же самой роли AD DS, которую увидите когда раскрутите её через окна мастера настройки в процессе конфигурации вашего нового контроллера домена. RODC является особым контроллером домена, в который вы не можете записывать новые данные. Он содержит кэшированные, доступные только для чтения определённые части и каталоги. Вы можете запросить RODC хранить копии всех ваших полномочий из вашего домена, или вы можете даже попросить его сохранять только выбранные полномочия, которые будут важными для данного определённого RODC. Причина применения RODC? Наиболее часто я наблюдаю ответвлённые офисы и DMZ. Если у вас имеется филиал меньшего размера, причём с меньшим же числом сотрудников, преимуществом для них может быть наличие локального контроллера домена с тем, чтобы выполнять процесс регистрации быстро и эффективно, но поскольку вы не можете по настоящему обеспечивать безопасность в этом небольшом офисе, вы бы не хотели иметь по крайней мере полностью надутый DC, с которым некто мог бы спокойно уйти.

Это может оказаться хорошим применением для RODC. Другим вариантом является применение внутри безопасной сетевой среды DMZ. Эти пограничные сетевые среды обычно проектируется для очень ограниченного доступа, так как они взаимодействуют с общедоступным Интернетом. Некоторым из ваших серверов и служб, расположенных внутри сетевой среды DMZ может понадобиться доступ к Active Directory, однако вы не желаете открывать канал взаимодействия из вашей DMZ к полному контроллеру домена в вашей сетевой среде. Вы можете остановиться на RODC внутри DMZ, имея его в виде кэша необходимой информации для обслуживания этих определённых серверов в вашей DMZ и сделать более безопасным среду домена или поддомена внутри такой сетевой среды.

В основанной на Windows Server и Active Directory сетевой среде, почти всегда имеет место то, что самый первичный набор компьютеров клиентов также основывается на операционных системах Microsoft Windows и что все эти машины присоединены к домену. Всеобщая настройка таким способом имеет значение не только с точки зрения изнутри Active Directory, но также делает возможной централизацию аутентификации по всем устройствам и приложениям, о чём мы уже говорили. Я знаю, что в паре приводимых мной ранее в этой книге примеров я упоминал нечто вроде: "А что если в компании имеется размещённая политика безопасности, которая ..." или "Убедитесь что ваши серверы не получают таких присутствующих политик безопасности, потому что ...". Итак, как бы то ни было, чем же являются эти магические "политики безопасности" и как мне их настраивать?

Это сила Групповой политики. Она позволяет вам создавать GPO (Group Policy Objects, объекты Групповой политики), содержащие установки и настройки, которые вы хотите применять к любым компьютерам или пользователям, в своём домене Active Directory. Когда вы создали и выстроили GPO с различными настройками, затем у вас имеется возможность руководить этой GPO в каком- либо выбранном вами направлении. Если у вас имеется политика, которую вы применяете ко всем своим настольным системам, вы можете указать их в соответствующих OU (Подразделениях) или группах в Active Directory. Или, может быть, вы создаёте GPO, которая применяется только к вашим компьютерам Windows 7 и вы можете осуществлять фильтрацию с тем, чтобы только эти системы воспринимали данную политику. А реальная магия состоит в том, что выпуск этих настроек происходит автоматически, просто благодаря тому, что эти компьютеры были подключены к вашему домену. Вам совсем нет нужды прикасаться к самим системам клиентов чтобы поместить их настройки через GPO.

Итак, ещё раз, я просматриваю весь перечень доступных ролей в своём Windows Server 2016 и я просто не вижу ничего с названием Group Policy. Опять верно, такого нет. На самом деле, если вы следовали за настройками нашей лаборатории на протяжении всей книги, вы уже имеете полностью функциональные групповые политики в вашей сетевой среде. Всё что нужно Групповой политике для работы, это являться частью Служб домена AD (AD DS, Active Directory Domain Services).

Таким образом, если у вас имеется в вашей сетевой среде некий контроллер домена, то у вас уже имеется Групповая политика на том же самом сервере, потому что вся информация используемая Групповой политикой хранится в этом каталоге. Так как установка роли AS DS это всё что нам нужно чтобы применять Групповую политику, и мы это уже выполнили в своём контроллере домена, давайте заскочим вперёд и посмотрим на некоторые вещи, которые позволят вам начать применение Групповой политики в вашей среде прямо сейчас. Я работал со многими компаниями малого бизнеса на протяжении многих лет, которые работают с Windows Server только потому, что все так поступают, верно? Кто- либо из тех ИТ парней или компаний, кто настраивал им этот сервер несомненно никогда не демонстрировал им ничего про GPO, и поэтому они имеют этот мощный инструмент просто лежащим в коробке с инструментами, причём неиспользуемыми и ожидающими своего высвобождения. Если вы ещё не применяете GPO, я хочу вам открыть этот ящик и дать ему выстрелить.

Первое что нам нужно понять, когда мы входим в свой контроллер домена, это что мы можем создавать объекты Групповой политики (GPO) и управлять ими. Как и в случае с любыми другими инструментами администрирования в Windows Server 2016, Диспетчер сервера является центральной платформой для открытия вашей консоли. Находясь внутри Диспетчера сервера кликните по меню Tools и выберите Group Policy Management.

Когда консоль раскроется, распахните имя своего Forest в дереве навигации слева, а затем также раскройте Domains и выберите имя своего домена. Внутри вы увидите некоторые выглядящие знакомыми объекты. Это перечень созданных вами ранее Подразделений (OU) и пара других папок наряду с вашими OU.

Вскорости мы обсудим почему перечень OU присутствует здесь, но в данный момент мы хотим сосредоточиться на определённом GPO, который обычно располагается поблизости от вершины этого списка, непосредственно под самим именем вашего домена. Он называется Default Domain Policy (политики домена по умолчанию). Этот GPO подключается к Active Directory в процессе установки по умолчанию и он применяется к каждому пользователю, который является частью вашего каталога домена. Так как этот GPO полностью включается сразу и применяется ко всем, для предприятия это обычное место приведения в жизнь глобальных политик паролей или правил безопасности, которые должны применяться к каждому.

Для любого GPO, который вы видите в своей консоли управления, если вы кликните правой кнопкой по этому GPO, а затем выберите Edit…, вы увидите новое открытое окно, причём этот редактор GPO все внутренние особенности такой политики. Это то место, в котором вы делаете любые настройки или установки, которые вы бы хотели, чтобы они были частью такого определённого GPO. Пройдите дальше и измените Default Domain Policy, а затем переместитесь в Computer Configuration | Policies | Windows Settings | Security Settings | Account Policies | Password Policy.

Здесь вы можете увидеть перечень различных параметров, доступных для изменения в Password Policy в рамках вашего домена. Двойной клик по любой из этих настроек позволит вам изменять её, причём это изменение немедленно вступает в действие на всех вашим включённых в домен компьютерах в вашей сетевой среде. Например, вы можете видеть, что значение по умолчанию для Minimum password length установлено в 7 characters. Многие компании уже прошли через множество обсуждений о своей политике записи в стандарте длины паролей в сетевой среде, а чтобы установить чтобы ваш новый каталог инфраструктуры принимал ваше решение вы просто изменяете значение этого поля.

Если вы просмотрите расположенное слева дерево Group Policy Management Editor, вы можете увидеть, что существует невероятно большое число установок и настроек, которое может быть выставлено через Групповую политику. Хотя Политика домена по умолчанию (Default Domain Policy) является очень быстрым и простым способом получения некоторых установок настроенных и выставленных для каждого, делая изменения в данной политике по умолчанию, тщательно выполняйте и выверяйте каждый шаг. Всякий раз, когда вы делаете изменения настройки в этом месте, помните, что они имеют воздействие на всех в вашем домене, включая и вас. Неоднократно вы будете создавать политики, которые не должны применяться ко всем, и в этих случаях, вам настоятельно рекомендуется быть в отдалении от такой Политики домена по умолчанию, а вместо этого установите GPO с новым названием для выполнения какой- либо задачи, пока вы не убедитесь что именно это вы пытаетесь ввести в действие.

Обычно наилучшей практикой является построение нового GPO в случае, когда вам необходимо применить некоторые настройки, однако лучше мы затратим ещё минуту и обсудим этот процесс. Для данного примера мы собираемся создать новый GPO, который подключает перечень заслуживающих доверия сайтов к Internet Explorer на наших настольных компьютерах. Если вы выполняете некоторое веб приложение в своей сетевой среде, которому, в свою очередь, необходимо выполнять управление JavaScript или ActiveX, или нечто подобное этому, может потребоваться, чтобы ваш вебсайт был частью перечня доверенных сайтов внутри Internet Explorer для его надлежащей работы. Вы можете вывести страницу инструкций для службы технической поддержкой с тем, чтобы выполнить это на каждом компьютере и заставить их потратить своё время для выполнения этого для каждого пользователя, который делает телефонный вызов, потому что не может осуществить доступ к приложению. Или же вы можете просто создать GPO, который сделает эти изменения для вас автоматически для каждого рабочего места и уберечь от всех этих телефонных вызовов. Это всего лишь один небольшой пример мощности процессов Групповой политики, однако это хороший пример, так как он является чем- то полезным, а также является способом погружения в GPO с тем, чтобы вы могли ощутить какой глубины могут достичь эти возможности.

Внутри своей консоли Group Policy Management кликните правой кнопкой по папке с именем Group Policy Objects и выберите New. Присвойте имя этому новому GPO, я назвал его Adding Trusted Sites, и затем кликните OK. Ваш новый GPO отобразит теперь список доступных GPO, однако он пока ещё не применён ни к каким или всем компьютерам. Перед тем, как мы назначим этот новый GPO для всех, давайте подключим в этот перечень доверенные сайты, чтобы данная политика содержала нашу информацию настроек. В настоящий момент она свободна от каких- либо установок.

Кликните правой кнопкой по своему новому GPO и выберите Edit…. Теперь переместитесь в Computer Configuration | Policies | Administrative Templates | Windows Components | Internet Explorer | Internet Control Panel | Security Page. Смотрите, я говорил вам что это залегает здесь!

Теперь кликните дважды по Site to Zone Assignment List и установите его в значение Enabled. Это сделает для вас возможным кликнуть по кнопке Show…, при помощи которой вы можете ввести вебсайты и присвоить им назначения зон. Каждая настройка GPO имеет хороший сопровождающий их текст пояснений, сообщающий вам в точности для чего предназначена данная конкретная настройка и что этот параметр означает. Как вы можете увидеть из текста для неё, чтобы установить мой сайт доверенным, мне необходимо дать ему значение назначения зоны равное 2. И просто ради развлечения, я добавил сайт, который я не хочу делать доступным для своих пользователей и присвоил ему значение зоны 4, так что badsite.contoso.com является членом запретной зоны сайтов на всех моих настольных компьютерах.

Мы всё сделали? Почти. Как только я кликну по кнопке OK, эти настройки сохранятся в моём объекте Групповой политики и будут готовы к развёртыванию, однако на данный момент времени я пока никому не назначил свой новый GPO, поэтому он пока находится в ожидании к применению.

Вернёмся вовнутрь консоли управления Групповой политикой, отыщем места, к которым вы хотите link (присоединить) этот новый GPO. Вы можете присоединить GPO к вершине домена аналогично тому, как работает Default Domain Policy (политика домена по умолчанию) и он будет затем применён ко всем расположенным ниже связям. Поэтому, в действительности, он начнёт применяться ко всем машинам в сетевой среде домена. Для данного конкретного примера мы бы не хотели столь глобального применения настроек доверенных сайтов (Trusted Site), поэтому вместо этого мы собираемся создать нашу ссылку только для определённого Подразделения (OU). Таким образом такой новый GPO будет применён только на тех машинах, которые хранятся внутри этого OU (Подразделения). Я хочу назначить этот GPO своему Подразделению Desktop Computers, которое я создал ранее. Поэтому я просто отыщу это Подразделение, кликну по нему правой кнопкой, а затем выберу Link an Existing GPO….

Теперь я вижу перечень своих GPO доступных для связывания. Выбираю нужный новый GPO Adding Trusted Sites и кликаю OK, и это всё! Новый GPO теперь присоединён к Подразделению Desktop Computers и применит эти настройки ко всем машинам, которые я разместил внутри этого Подразделения.

Теперь, когда вы создали некий GPO и связали его с определёнными Подразделениями (OU), у вас имеется достаточно информации чтобы на самом деле начать применять Групповую политику в своей среде. Применение связей для определения какие машины получают какие политики является наиболее распространённым методом, который я видел используемым администраторами, однако существует множество обстоятельств, при которых вы можете пожелать выполнить на один шаг больше. Что если у вас имеется некий новый GPO, а вы присоединили его ко всем Подразделениям, которые содержат все ваши настольные компьютеры, а после этого приняли решение, что некоторые из этих машин нуждаются в данной политике, а некоторые нет? Может оказаться головной болью разделение этих машин на два различных Подразделения только для цели данной политики, которую вы подключили. Именно здесь вступает в игру GPO Security Filtering (фильтрация безопасности GPO).

Фильтрация безопасности является возможностью отсеивать GPO для определённых объектов Active Directory. Для любого выбранного GPO в вашем каталоге вы можете установить фильтры с тем, чтобы данный GPO применялся только для определённых пользователей, определённых компьютеров или даже определённых групп пользователей либо компьютеров. Я обнаружил, что применение групп особенно полезно. Таким образом, для нашего следующего примера, в котором у нас имеется политика, применяющаяся только к некоторым настольным компьютерам, мы создадим новую Группу безопасности (Security Group) внутри Active Directory и добавим только такие компьютеры в данную группу. В будущем, если вам нужно изъять данную политику с некоторых компьютеров, или добавить её к новым компьютерам, вы просто добавите или удалите машины из самой этой группы, и вам вовсе не нужно изменять этот GPO.

Когда вы кликаете по GPO находясь внутри консоли управления Групповой политикой (GPMC), отображается раздел Security Filtering. Пройдите далее и кликните GPMC, а затем кликните на один из своих GPO. Справа вы увидите открытую область действия для данной политики. Раздел вверху отображает какие Links в настоящее время являются активными для данной политики, а нижняя половина экрана отображает ваш раздел Security Filtering. Здесь вы можете увидеть, что я присоединил свой GPO к имеющемуся Подразделению (OU) Desktop Computers, однако я установил дополнительный фильтр безопасности с тем, чтобы только машины, которые являются частью группы Accounting Computers в действительности получали настройки из моего GPO.

Если мы рассматриваем Active Directory как являющуюся наиболее распространённой и центральной ролью при выполнении наших сетевых функций, сосредоточенных вокруг Microsoft, тогда роль DNS (Domain Name System, служба имён домена) плавно перемещается на номер два. Я ещё не встречал системных администраторов, кото выбрал для развёртывания домен без развёртывания DNS в то же самое время, они всегда идут рука об руку.

DNS аналогичен Active Directory в том, что она является структурированной базой данных, которая часто хранится на серверах контроллера домена и автоматически распространяется в вашей сетевой среде на другие контроллеры домена/ сервера DNS. В то время как база данных AD содержит информацию о самих объектах домена, DNS отвечает за хранение и разрешение (resolve) всех имён в вашей сетевой среде. Что я имею в виду под именами? Всякий раз когда пользователь или компьютер пытаются установить контакт с любым ресурсом, обращаясь к нему по имени, DNS является платформой, ответственной за превращение этого имени во что- то ещё, чтобы их обмен достиг верного получателя. Как вы видите, путь, которым обмен исходит от клиента к серверу осуществляется через сеть, причём обычно через стек TCP/IP с использованием IP адресов для достижения получателя. Когда я открываю приложение на своём компьютере для доступа к некоторым данным, расположенным на сервере, я могу настроить это приложение так, чтобы оно взаимодействовало с моим сервером напрямую, применяя IP адрес сервера в этой сети. Если я подключу 10.0.0.15 в настройку своего приложения, оно будет успешно открываться. Если я настрою таким образом сотни различных компьютеров таким образом, когда все указывают на этот IP адрес, это будет прекрасно работать до определённого момента. Однако настанет день, когда по какой- либо причине будет необходимо изменить этот адрес. Или, возможно, я добавлю второй сервер для совместного использования при нагрузке и обработке моего возросшего обмена. Что делать теперь? Повторно посетить все пользовательские компьютеры и обновить используемый IP адрес? Естественно, нет. Это одна из причин, по которой DNS является критически важным для способа, которым мы проектируем и управляем нашей инфраструктурой. При использовании DNS мы можем применять имена вместо IP адресов. При помощи DNS моё приложение можно настроить на использование Server01, или как там ещё называется мой сервер, и если мне потребуется в дальнейшем изменить этот адрес, я просто изменю его внутри консоли DNS на обновлённый IP адрес и немедленно все компьютеры моих клиентов начнут разрешать Server01 новым IP адресом. Или я даже могу использовать более универсальное имя навроде Intranet и разрешать его по множеству различных серверов. Скоро мы обсудим это слегка более подробно.

Всякий раз когда компьютер делает вызов к серверу, или службе, или вебсайту, для разрешения этого имени в более удобный фрагмент информации применяется DNS чтобы успешно осуществить данное сетевое соединение. Это всё одинаково истинно как для внутренних, так и для внешних корпоративных сетей. На моём персональном ноутбуке, прямо сейчас, если я открою Internet Explorer и обращусь в нём к http://www.bing.com/, сервер DNS моего поставщика услуг Интернет разрешит http://www.bing.com/ в IP адрес во всемирном Интернете и и моя страница успешно откроется. Когда мы работаем внутри корпоративной сети, мы не хотим полагаться или доверять общедоступному поставщику услуг информацию о нашем внутреннем имени сервера и, следовательно, мы строим свои собственные серверы DNS внутри своей сетевой среды. Поскольку записи DNS внутри сетевой среды домена почти всегда разрешают имена в объекты, которые расположены внутри Active Directory, имеет смысл тесная связь DNS и AD DS. Это звучит правдоподобно в большинстве сетевых сред Microsoft, в которых очень распространённой практикой является установка обеих ролей, и AD DS, и DNS на ваших серверах контроллера домена.

Теперь, когда у нас имеется установленная роль нашего DNS на некотором сервере в нашей сети, мы можем начать применение её для создания записей DNS которые разрешают имена в соответствующие им IP адреса, или прочие части информации необходимые для маршрутизации нашего обмена во все сети. Предположим, что вы работаете в сетевой среде домена, и вы можете приятно удивиться, что ряд записей уже присутствует в DNS, даже несмотря на то, что вы не создавали никакие из них. Когда у вас совместно работают Active Directory и DNS, процесс подключения к домену, который вы выполняете со своими компьютерами и серверами самостоятельно регистрирует запись DNS в ходе этого процесса. Я ещё пока не создал никакие записи DNS в среде своей новой лаборатории, по крайней мере, целенаправленно и, тем не менее, когда я открываю свою консоль DNS Manager находясь внутри меню Tools Диспетчера сервера, я могу видеть некоторое количество уже существующих записей. Это происходит по той причине, что я когда присоединил каждую из этих машин в домен, они автоматически регистрировали эти записи для меня, чтобы такие новые серверы и клиенты немедленно разрешались в домене.

Запись хоста (A или AAAA)

Самый первый вид записи DNS, который мы будем рассматривать, является наиболее распространённым типом с которым мы будем работать. Запись хоста (host record) является записью, которая разрешает определённое имя в конкретный IP адрес. Достаточно просто, и для большинства устройств в вашей сетевой среде это будет просто вид записи, который существует для неё внутри DNS. Существует два различных класса записей хоста, о которых вы должны иметь представление, даже несмотря на то, что на протяжении по крайней мере ещё нескольких лет, вы будете скорее всего использовать одну из них. Два различных вида записей хоста называются A record и AAAA record, что произносится как Quad А. Какова разница между этими двумя? Записи A предназначены для адресов IPv4 и будут применяться в большинстве компаний на протяжении долгих лет. Записи AAAA обслуживают в точности для ту же самую цель разрешения имени в адрес IP, но будет полезна только если вы в своей сетевой среде используете IPv6.

На предыдущем снимке экрана вы могли заметить некоторые записи Host (A), которые были самостоятельно созданы когда эти машины присоединялись к нашему домену. У меня также имеется другой сервер, работающий в моей сетевой среде, который пока ещё не был включён в домен и по этой причине не был самостоятельно зарегистрирован в DNS. Этот сервер имеет имя ra1, однако, если я зарегистрируюсь в любой другой системе в своей сетевой среде, я не смогу взаимодействовать со своим сервером ra1, так как его имя пока не было подключено в DNS.

В настоящий момент я собираюсь остановиться на том, что я пока не буду присоединять эту коробку в свой домен, поэтому мы можем создать некую запись для него вручную и удостовериться, что я получу возможность разрешать это имя надлежащим образом после того, как выполню это. Вернёмся назад в Диспетчер DNS на моём сервере DNS, кликнем правой кнопкой по вашего домена имени находящегося в перечне папки Forward Lookup Zones (зон прямого просмотра), а затем выберем New Host (A or AAAA). Внутри этого экрана для создания новой записи хоста просто введите имя вашего сервера и его IP адрес, который настроен в его сетевом интерфейсе.

Теперь, когда мы создали такую новую запись, мы должны иметь возможность немедленно начать разрешение этого имени внутри нашей сетевой среды домена. Вернёмся обратно на машину клиента, с которой я пытался ранее выполнить ping к ra1, я попытаюсь выполнить эту команду снова, и в этот раз она выполнит разрешение и ответит успешно.

Запись псевдонима - CNAME

Другим полезным типом записи DNS является CNAME, или имеющая более распространённое в наши дни название запись псевдонима (alias record). Эта запись, которую вы можете создать, принимает некоторое имя и указывает его на другое имя. На первый взгляд звучит достаточно нелепо, так как в конце концов вы всё- таки собираетесь разрешить ваше окончательное имя в некий IP адрес чтобы получить обмен идущий по назначению однако цели записи псевдонима могут быть бескрайними. Хороший пример, рисующий полезность записи псевдонима состоит в работе некоторого веб сервера, который обслуживает вебсайты внутри вашей сетевой среды. Вместо того, чтобы заставлять всех своих пользователей запоминать URL навроде http://web1.contoso.local для осуществления доступа к вебсайту, мы можем создать запись псевдонима с названием Intranet и указать её на web1. Таким образом клиентскими компьютерами всегда может применяться более общая запись Intranet, которая является намного дружелюбным именем для запоминания вашими пользователями.

Помимо создания удачной пользовательской практики при помощи такой новой записи DNS, вы имеете созданной также некоторую административную гибкость, потому что вы легко можете менять серверные компоненты, которые работают под этой записью без необходимости регулировать какие- либо настройки на машинах клиентов или повторно обучать пользователей как осуществлять доступ к странице. Нужно поменять веб сервер? Нет проблем, просто укажите записи псевдонима новый. Есть потребность в добавлении другого веб сервера? Это также просто, так как мы можем создать множество записей псевдонимов, причём все они будут иметь имя Intranet и указывать их на различные веб сервера, которые выступают в внутри вашего окружения. Это создаёт очень простой способ балансировки нагрузки, поскольку DNS начинает выполнять карусельным методом (round-robin) обмен между различными веб серверами на основе такой записи Intranet.

Действительно, вместо продолжения разговора об этом, давайте попробуем. У меня имеется работающий в точности по этому URL вебсайт, однако на текущий момент я могу осуществлять к нему доступ только набирая http://web1.contoso.local. Внутри DNS я собираюсь создать запись псевдонима, которая перенаправит intranet в web1.

Теперь, когда я выполняю ping intranet, вы можете видеть, что он выполняет разрешение в мой сервер web1. А когда я осуществляю доступ к вебстранице, я могу просто набрать Intranet в своём блоке адреса внутри Internet Explorer чтобы запустить мою страницу. Вебсайт сам по себе не осведомлён о выполненном изменении имени, поэтому мне не нужно делать никаких изменений в своём вебсайте, все изменения выполняются только в DNS.

Запись почтового обмена

Третий тип записи DNS называется записью Mail Exchanger (MX). При наших каждодневных занятиях у вас нет необходимости встречать или настраивать записи MX примерно так же часто как записи A и CNAME, однако они важны для понимания. Запись MX описывает основу служб и доставки электронной почты. Всякий раз как имя домена следует за "@" в вашем адресе электронной почты, обрабатывающие это доменное имя сервера DNS должны содержать некую запись MX, сообщающую тот домен, который указывает на их службы электронной почты. Записи MX применяются только для общедоступных DNS для разрешения имён, происходящего во всемирном Интернете. Для компаний, размещающих свою собственную электронную почту на локальных серверах Exchange, ваши общедоступные сервера DNS будут содержать некую запись MX, которая указывает на ваше окружение Exchange. Для компаний, размещающих свою электронную почту в облачной службе, ваша общедоступная запись DNS должна будет содержать некую запись MX, которая отправляет обмен электронной почтой далее поставщику облачных услуг, который размещает ваши почтовые ящики.

Запись сервера имён

Существует ещё запись, с которой вы не будете связаны в делах ежедневно, но о которой вам следует знать для чего она предназначена. Запись Name Server (NS, Cервер имён) является идентификатором внутри зоны DNS, которая сообщает ей какие Сервера имён, а именно ваши сервера DNS, применять для авторизации в данной зоне. Если вы поищите имеющиеся записи NS перечисленные в вашем DNS прямо сейчас, вы осознаете, что он вызывает именно имена ваших серверов DNS в данной сетевой среде. Когда вы добавляете новый сервер DC/ DNS в свой домен, в вашу зону DNS будет автоматически добавляться новая запись NS.

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

Ipconfig /flushdns

Всего одно окончательное замечание перед тем как завершить данный раздел. Я произнес вещи навроде "теперь, когда я сделал это ..." или "немедленно вслед за этим изменением ..." и, если вы создаёте некоторые из своих собственных записей, вы можете заметить, что иногда это занимает некоторое время, пока ваши компьютеры клиентов распознают такие новые записи. Это является обычным поведением, а время, которое требуется прежде чем ваше изменение накатилось по всей вашей сетевой среде, будет целиком зависеть от того, насколько велика ваша сетевая среда и как настроены репликации Active Directory. Когда вы создаёте новую запись DNS в одном контроллере домена, ваша новая запись требует свой репликации по всем прочим DC в вашей сетевой среде. Этот процесс сам по себе может занять пару часов, если AD не настроены на быстрые репликации. Обычно это занимает всего лишь несколько минут. А после этого, когда данная новая запись существует на всех ваших серверах DC, вашим клиентам всё ещё может потребоваться немного времени для применения такой новой записи, потому что компьютеры клиентов в сетевой среде домена держатся в кэше данных DNS. Таким образом, они не должны обращаться к серверу DNS для каждого отдельного запроса разрешения имени.

Они могут более быстро обратиться к своему локальному кэшу чтобы просмотреть какая информация была зарегистрирована в их DNS серверах с момента их последнего обращения. Если вы пытаетесь немедленно проверить некую новую только что созданную запись DNS и она не работает, вы можете захотеть попробовать выполнить на своём компьютере клиента команду ipconfig /flushdns. Это заставит вашего клиента сбросить свои локальные кэшированные копии записей разрешения DNS и перейти к сбору новой информации, которая является текущей для вашего сервера DNS. После очистки вашего кэша искомая запись скорее всего начнёт работать надлежащим образом.

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

Статическая адресация просто является процессом настройки IP адресов вашей системы вручную, с применением ваших рук в качестве инструмента настройки чтобы подключить всю вашу информацию об IP адресе в соответствующие настройки этого устройства. Хотя это и является быстрым и простым способом для получения сетевого обмена между несколькими конечными точками, путём присвоения каждой из них IP адреса, он не масштабируется. Мы часто делаем для своих серверов статические адреса, как вариант гарантии того, что IP адреса не являются предметом для изменений, однако что касается стороны клиента или устройства? Даже в небольшой компании с 10 сотрудниками, каждая персона может иметь настольный компьютер и ноутбук, а также могут существовать сервера печати в сети, которым также необходимы IP адреса, а также вы можете иметь беспроводную сеть, в которой сотрудники, или даже гости, могут подключать свои телефоны и прочие устройства для получения доступа в интернет. Собираетесь ли вы вручную назначать IP адреса всем этим устройствам? Несомненно нет.

Наш ответ для этой задачи это DHCP (Dynamic Host Configuration Protocol). Этот разработанный в точности для решения нашей проблемы протокол предоставляет машинам и устройствам в вашей сетевой среде автоматически получать информацию адресации IP. Почти все пользователи и устройства по всему миру используют DHCP даже не осознавая это. Когда вы подключаете свой ноутбук или смартфон в к маршрутизатору Wi-Fi для получения доступа в Интернет, сервер DHCP предоставляет вам возможность маршрутизации вашего обмена через такую сетевую среду Wi-Fi назначая вам информацию IP адресации. Часто в случае общедоступного Wi-Fi ваш DHCP сервер на самом деле работает также и в качестве самого маршрутизатора, однако в нашем случае, когда Windows Server управляет всем центром обработки данных, службы DHCP размещаются на одном или более серверах в вашей сети.

В новой среде лаборатории Windows Serever 2016, которую я только что построил, до сих пор я назначал всем строящимся серверам IP адреса статически. Это начинает устаревать и тяжело отслеживать. Когда был настроен первый контроллер, на самом деле, я установил на нём роль DHCP сервера, но пока ещё не сообщил её ничего делать. Что же нужно DHCP серверу чтобы начать обрабатывать IP адреса? Он должен знать какие IP адреса, маска подсети, шлюз по умолчанию и адреса DNS сервера находятся внутри вашей сетевой среды с тем, чтобы он смог их паковать и начать выдавать эту информацию тем компьютерам, которые запрашивают её у него. Такой пакет информации внутри сервера DHCP называется областью видимости (сферой) DHCP, DHCP scope. Как только мы определим свою область видимости, наш DHCP сервер начнёт обрабатывать IP адреса из этой сферы для наших новых серверов и компьютеров которые ещё не имеют определённых им статических адресов.

Итак, нам опять нужно запустить инструментарий управления своего Windows Server 2016 и опять же, простейшим способом запустить это будет применение меню Tools внутри Диспетчера сервера. Пройдите далее и запустите консоль DHCP. Внутри вы увидите имя сервера, на котором запущен DHCP. Раскройте его и вы получите параметра как для IPv4, так и для IPv6. Да это означает, что вы можете применять данный сервер DHCP для обработки обоих видов адресов: и IPv4, а также и IPv6, для тех из вас, кто пробует IPv6 или планирует его применять в будущем. На текущий момент мы пока останемся со старыми добрыми IP4, и поэтому я могу кликнуть правой кнопкой по IPv4 и выбираю создать New Scope. Это запускает мастер New Scope Wizard, который проведёт вас через несколько фрагментов информации необходимой DHCP для чтобы создать сферу, которая будет готова начать обрабатывать IP адреса внутри вашей сетевой среды. Как только вы завершите создавать свою область видимости, она немедленно станет активной и все компьютеры в вашей сетевой среде, чьи NIC настроены на автоматическое получение адресов от DHCP сервера начнут их получать от этого нового сервера.

Теперь, когда наша новая сфера была создана, вы можете раскрыть эту область видимости внутри консоли DHCP и просмотреть некоторые дополнительные сведения о ней. Кликнув по папке Address Leases вы можете увидеть все адреса DHCP, которые обрабатываются этим сервером DHCP. Как вы можете увидеть на следующем снимке экрана, у меня имеется компьютер клиента Windows 10 в сетевой среде, которые не имеет статического адреса и поэтому захватывает некий адрес DHCP с моего DHCP сервера. Он получил самый первый адрес IP, который я определил в своей сфере, 10.0.0.100. Следующая машина, которая добивается захват некоторого IP адреса от этого сервера DHCP, получит 10.0.0.101, и так далее.

Назначение адресов из большого пула доступных IP адресов это великолепно, однако эти сдаваемые в аренду адреса имеют срок действия и изменчивы. Это означает, что компьютер, который имел сегодня 10.0.0.100, завтра может получить 10.0.0.125. С точки зрения настольного компьютера обычно это нормально, поскольку они обычно не заботятся о получаемых адресах IP. Но что, если в вашей сетевой среде имеются более постоянные средства, например, Windows Server, однако вы не желаете связываться со статической адресацией данного сервера. Это именно тот случай, когда в дело вступает DHCP reservations. Резервирование является действием, которое берёт отдельный адрес внутри вашей области видимости, и запоминает его под определённое устройство. Это устройство будет получать один и тот же адрес всякий раз, когда оно подключается к серверу DHCP, причём этот определённый адрес не будет выдаваться никакому другому устройству в вашей сетевой среде. Применяя резервирование внутри DHCP вы можете делать доступным для своего сервера DHCP обрабатывать назначение IP адресов даже своим непрерывно работающим серверам с тем, чтобы вам не приходилось вручную настраивать NIC для этих серверов, однако вы продолжаете сопровождать постоянно действующие IP адреса этих машин.

Вы можете просмотреть папку с названием Reservations в своей консоли DHCP. В настоящий момент в ней ничего не перечисляется, однако кликнув правой кнопкой по Reservations и выбрав New Reservation… мы создадим резервирование для себя. Давайте снова займёмся своим сервером web1. У меня имеется статический IP адрес, назначенный для web1, однако я вместо этого создам для него резервирование по адресу 10.0.0.115.

Стоп, стоп, стоп... заскочим назад в свой поезд. Большая часть информации на экране достаточно ясна, Однако как я получил эти адреса MAC? MAC address является физическим адресом в сети некоторой сетевой платы. Когда ваше сетевое оборудование пытается отправлять информацию по определённому адресу, или, как в нашем случае, DHCP серверу требуется выдать конкретный IP адрес определённому NIC в сервере, им необходим физический идентификатор для такой сетевой платы. Таким образом, MAC адрес является чем- то что является уникальным для данного NIC в моём сервере web1. Зарегистрировавшись на своём сервере web1 я могу выполнить ipconfig /all и обнаружить в непосредственном выводе перечисленный для моего NIC MAC адрес. Это именно то место, в котором я могу получить эту информацию. Именно таким образом DHCP принимает решение каким образом выполнять резервирование. Если некий сетевой интерфейс запрашивает у него какой- либо адрес DHCP, а MAC адрес этого устройства находится в этом списке резервирований, тогда данный DHCP сервер возвратит такой зарезервированный адрес назад данному устройству, вместо того, чтобы выдавать его из общего пула.

Теперь, когда создано наше резервирование DHCP, я проследую в настройки NIC своего сервера web1 и избавлюсь от всей своей информации статической адресации выбрав задаваемую по умолчанию опцию Obtain an IP address automatically. После того, как я это сделаю, web1 обратится к DHCP и запросит для себя адрес, и вы сможете обнаружить, что я получил зарезервированный адрес 10.0.0.115. Он всегда будет адресом для моего сервера web1 с этого момента и далее, пока я не изменю своё резервирование DHCP или каким- либо образом не поменяю MAC адрес web1. Это, возможно, может произойти, если я установлю новый NIC в web1.

Потребность в резервном копировании и, при возникновении необходимости, восстановления, к сожалению, всё ещё присутствует в Windows Server 2016. Я мечтаю о временах ,когда сервера будут 100% надёжны и стабильны на протяжении всего времени их жизни, вне зависимости от вирусов и мошеннического программного обеспечения, но сегодня не тот день. Хотя и существует большое количество доступных на рынке инструментов сторонних производителей, которые способны улучшить и автоматизировать вашу практику резервного копирования при управлении множеством серверов, тем не менее, у нас имеются возможности, приготовленные прямо в самой нашей операционной системе Windows Server 2016, и мы все должны быть знакомы с их применением.

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

Прежде чем мы сможем что- либо выполнить с резервными копиями, нам необходимо установить внутри Windows надлежащие свойства. Воспользовавшись своей ссылкой Add roles and features пройдите вслед за ней и установите функцию с названием Windows Server Backup. По окончанию установки данной функции вы сможете запустить консоль Windows Server Backup, которая доступна в меню Tools Диспетчера сервера. Зайдя в неё вы обнаружите некоторые Actions, перечисленные в правой стороне вашего экрана. Кликнув по действию Backup Schedule…, вы запустите мастер, который выполнит настройки нашего расписания программы резервного копирования.

Первый параметр, сквозь который вам необходимо пройти, это выбор того, что вы собираетесь копировать в резерв. Опция по умолчанию установлена в значение Full server, что выполнит резервное копирование всего в вашей операционной системе. Если вы желаете персонализировать объём данных, подлежащий резервному копированию, вы можете выбрать опцию Custom и выполнить действия с ней. Поскольку я имею доступным для себя большое дисковое пространство, я собираюсь следовать рекомендуемым путём создания полных резервных копий сервера.

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

Последний экран, в котором мы должны принять решение для своего резервного копирования по расписанию, это экран Specify Destination Type, в которм мы определяем местоположение, в котором должны храниться наши файлы резервных копий. Как вы можете увидеть, существует пара различных вариантов для сохранения резервных копий локально на физических жёстких дисках того же самого сервера, на котором вы настраиваете резервное копирование. Сохранение резервных копий на локальных, выделенных дисках или томах может иметь преимущество в силу увеличения скорости резервного копирования. Для серверов, которые вы пытаетесь резервно копировать в течение рабочих дней чтобы непрерывно поддерживать актуальными, вы могли бы, скорее всего, пожелать выбор локального резервного копирования с тем, чтобы такое резервное копирование происходило быстро и гладко. Другое преимущество применения локально подключённого диска для резервного копирования состоит в том, что вы можете создавать множество точек отката внутри своей схемы резервного копирования, сохраняя ценную информацию резервного копирования множества дней в случае, если вам необходимо будет выполнить откат на определённый момент времени. Однако, я нахожу, что большинство администраторов предпочитают хранить все свои файлы резервных копий централизованно, а это означает выбор третьей опции в данном экране, и она называется Back up to a shared network folder (Резервное копирование в совместно используемую папку). Выбрав данную опцию, мы можем определить некое местоположение в сети, например, файловый сервер или дисковое соответствие в NAS, и мы можем установить для всех наших различных серверов одно и то же местоположение для резервного копирования. Таким образом мы получаем централизованное, стандартное местоположение в котором, как мы знаем, хранятся все наши файлы резервных копий пока не настанет их черёд для изъятия и восстановления.

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

Когда вы выбрали получателя для своих резервных копий, и определили местоположение совместного сетевого ресурса, если он является вашим выбором, вы закончили работу с мастером. Ваши задания резервного копирования будут автоматически просыпаться в выделенное время, определённое в мастере и назавтра вы увидите новый файл резервной копии существующий для вашего сервера. Если вы нетерпеливы навроде меня и желаете увидеть работу задания резервного копирования прямо сейчас, мы можем пройтись другим доступным Action в вашей консоли Windows Server Backup с названием Backup Once… чтобы выполнить резервное копирование вручную немедленно.

Благодаря своей прилежности и сохранению хороших резервных копий ваших серверов, существует надежда, что вам никогда не понадобится в действительности применять эти файлы резервных копий для восстановления сервера. Однако, увы, временами случается когда сервер пошёл лесом, или внезапно были удалены некоторые данные и вы должны вновь посетить процесс восстановления данных или сервера целиком в вашей инфраструктуре. Если ваш сервер всё ещё включён и работает, процесс восстановления достаточно прост при исполнении из той же самой консоли Windows Server Backup. Откройте эту консоль, выберите Action, которое сообщает Recover….

Это запустит другой мастер, который проведёт нас процессом восстановления. Вначале мы определим местоположение своего файла резервной копии. Если у вас имеется выделенное местоположение резервных копий на вашем локальном сервере, его достаточно просто найти, в противном случае, как в моём примере, в котором мы определили сетевой общий ресурс, вы выбираете A backup stored on another location, а затем выбираете Remote shared folder чтобы сообщить где выполнять поиск этого файла резервной копии.

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

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

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

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

Восстановление изнутри консоли Windows прекрасная управляемая мастером практика, но если в нашем случае произошёл крах оборудования? Если вы не можете зайти в Windows, вы не сможете зайти и консоль Резервных копий Windows Server для начала процесса своего восстановления. В данном сучае мы всё еще можем применить созданный файл резервной копии, однако нам необходимо воспользоваться им в комбинации с установочным диском Windows Server 2016, с которого мы можем выполнить процесс восстановления.

Чтобы сделать всё интересным, я собираюсь разрушить свой собственный сервер. Это именно тот сервер, с которого мы выполнили резервное копирование несколько минут назад. Я внезапно удалил некоторые очень важные файлы в своём каталоге C:\Windows, ой! Теперь это всё, что я наблюдаю после попытки загрузить свой сервер.

Это не слишком дружественный экран для просмотра ранним утром! Раз уж я попал сюда и не имею возможности загрузить Windows, у меня нет шансов выполнить свой мастер восстановления. Что же делать? Загружаться с установочного DVD Windows Server 2016! Нет, я не хочу устанавливать Windows по новой, поскольку все мои программы и данные должы бы быть рабочими. Вместо этого, когда я получу свои окна установки, вы можете заметить, что в них присутствует опция в нижнем углу для Repair your computer. Выберите эту опцию для открытия параметров восстановления, которые доступны нам с установочного DVD.

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

Если вы полагаете, что сможете исправить какие- либо проблемы из Command Prompt (приглашения командной строки), выберите это параметр для самостоятельныъ действий по исправлению. В нашем случае я достаточно уверен, что я существенно прорядил свою операционную систему, поэтому я собираюсь выполнить полное System Image Recovery (восстановление образа системы) и нажимаю на эту кнопку.

Поскольку у вас имеется подключённый жёсткий диск, который содержит файл Резервной копии Windows Server, ваш мастер запускает и выводит информацию о вашей резервной копии. Так как я первоначально выбрал сохранение своей резервной копии в сетевое местоположение, я скопировал данные файлы резерной копии на некий диск и подключил его вторым диском к своему серверу. Мастер автоматически распознаёт такой файл резервной копии и отображает его на экране Select a system image backup (Выберите образ резервной копии системы).

Теперь просто нажав несколько раз на Next для прохождения по мастеру мой образ резервной копии восстанавливается назад на мой сервер.

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

Сохранение хороших и последних резервных копий критически важно для надёжной работы. Мне приходилось работать с несколькими системами, в которых администраторы выполняли некоторые резервные копии вручную после начальной настройки своих серверов, однако при этом никогда не выполняя установок по расписанию. Даже если данные на таком сервере никогда не изменялись, если вы являетесь частью некоторого домена, вы никогда не пожелаете делать этого. В случае падения вашего сервера и необходимости его восстановления, восстановление некоторой резервной копии в пределах устаревания на несколько дней обычно происходит великолепно. Однако, если вы восстанавливаете образ с шестимесячным возрастом, Windows сам по себе вернётся в рабочее состояние без каких- либо проблем, и все ваши данные будут присутствовать, однако за такой промежуток времени ваша учётная запись компьютера, скорее всего, окончательно устарела в синхронизации с вашим доменом, что вызовет ошибки аутентификации относительно ваших Контроллеров домена (DC). В некоторых случаях вы даже сможете выполнить глупые вещи типа отсоединения и повторного присоединения сервера к своему домену с последующим восстановлением образа для восстановления взаимодействия со своим доменом. Если бы у вас имелись регулярные резервные копии для восстановления, вам не пришлось бы решать такие задачи.

Скорее всего вы отметили, что многие применяемые нами внутри Windows Server 2016 консоли управления выглядят достаточно похожими. Что происходит под капотом этого числа консолей, так это то, что вы в действительности наблюдаете некую функцию оснастки, определённый набор инструментов, который защёлкивается внутри общего инструмента консоли под названием Microsoft Management Console, или более часто просто как MMC. На самом деле, вместо того, чтобы открывать все эти функции управления изнутри Диспетчера сервера, для многих из них можно просто набрать MMC переместившись в Start | Run или окне приглашения командной строки и выполнить общую консоль MMC. Отсюда вы можете кликнуть на меню File и выбрать Add/Remove Snap-in….

Выберите управляющую оснастку (snap-in) с которой вы желаете работать и добавьте её в свою консоль. Существует большое число функций управления, к которым можно осуществить доступ из стандартной консоли MMC, и даже определённыйе белее предпочтительные для MMC функции или единственный метод взаимодействия с некоторыми компонентами Windows. Например, позже в этой книге мы рассмотрим сертификаты, сохраняемые в Windows Server 2016, и мы будем применять MMC для некоторого такого взаимодействия.

Другой интересный способ открытия многих из консолей управления состоит в пямом использовании имени инструмента MSC. Некий файл MSC просто является сохранённым набором какого- то сеанса MSC. Существует множество хранимых в Wundows Server 2016 ярлыков по умолчанию. Если определённая консоль управления предоставляет возможность запуска из MSC, всё что вам необходимо, это набрать такое имя MSC переместившись либо в Start | Run, или в приглашение командной строки, и она будет запущена в определённую консоль управления без какой- либо необходимости открывать Диспетчер сервера. Поскольку я предпочитаю применять клавиатуру больше чем мышь, у меня всегда имеется открытое окно PowerShell или приглашения командной строки в каждой системе с которой я работаю и я могу достаточно быстро воспользоваться этим окном для открытия любой из своих административных консолей MSC. Давайте рассмотрим один пример с тем, чтобы вы в точности поняли как применять эту функциональность, а затем я приведу перечень наиболее общеупотребимых консолей MSC, которые я нахожу полезными для повседневной работы.

Откройте поднимающееся окно PowerShell, набрав WF.MSC и нажав Enter.

Откроется окно Windows Firewall with Advanced Security, и оно будет готово принимать ваши исходные данные. У нас нет нужды тыкаться через Control Panel или открывать обычное Windows Firewall, а затем кликать на ссулку Advanced Settings, что является обычным способом для получения этой консоли с применением мыши. Зная названия наших ярлыков MSC у нас есть возможность получения прямого маршрута к полной консоли WFAS, которую я часто применяю для проверок определённых правил или состояний межсетевого экрана.

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

Сейчас мы обсудили некоторые из ролей и компонентов внутри Windows Server 2016, которые вам необходимо применять и знать если вы хотите рабоать в истинной инфраструктуре на основе Microsoft. Active Directory, DNS и DHCP являюдся центральными службами лежащими в основе всей инфраструктуры и поддерживающие её. Основное понимание этих технологий существенно для любого администратора Windows Server. А исчерпывающее знание совместных способов работы этих инструментов откроет множество дверей для вашего развития в профессии ИТ. Почти все прочие доступные в Windows Server роли и функции поддерживаются или закрепляются этими центральными службами. Я надеюсь, что вам будет удобно в дальнейшем перемещаться внутри них, следуя примерам из данной главы. {Прим. пер.: также советуем ознакомиться с переводом рецептов этого же автора в Ch02.html">Главе 2, Ключевые задачи инфраструктуры из его сопутствующей Книги рецетов Windows Server 2016.}

Теперь мы продолжим путешествие по Windows Server 2016 в следующей главе с погружением в одну из самых жутких тем - по крайней мере для большинства сетевых администраторов - Сертификаты!