Глава 2. Ключевые задачи инфраструктуры

Существует ряд технологий Windows Server 2016, которые вам следует знать если вы планируете неизменно работать в среде Windows. Это такие технологии как AD DS (Active Directory Domain Services, Службы домена активного каталога), DNS (Domain Name System, Система имён домена) и DHCP (Dynamic Host Configuration Protocol, Протокол настройки динамических хостов). Если вы ещё не заметили, в мире Windows всё имеет свои аббревиатуры. На самом деле вы можете просто распознавать эти элементы по их сокращённым названиям и это нормально.

В любом случае никто не называет DHCP Протоколом настройки динамических хостов. Однако знаете ли вы как настроить эти службы и привести инфраструктуру Windows Server в рабочее состояние с нуля, при наличии только составных частей оборудования и диска установки Windows Server 2016 в качестве руководителя вашего пути? Это именно то зачем мы оказались в этом месте в это время. Я бы хотел проинструктировать вас в том как вы возьмёте свой первый сервер и превратите его во всё, что должно работать в сетевой среде Microsoft.

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

Структура каталога который сетевые среды Microsoft применяют для расположения своих учётных записей пользователей и компьютеров называется AD (Active Directory), а информация этого каталога контролируется и управляется серверами DC (Domain Controller, Контроллер домена). Две другие роли, которые почти всегда идут рука об руку с Active Directory это DNS и DHCP, и во многих сетевых средах эти три роли объединены в том сервере, где они располагаются. Целому ряду малых компаний приходится иметь дело с отдельным сервером содержащим все эти три роли, однако в последние годы виртуализация стала настолько простой, что почти у всех работают по крайней мере два DC для целей избыточности. И если вы собираетесь иметь два DC, вы можете также поместить в них обоих роли DNS и DHCP чтобы сделать эти службы также избыточными. Однако я забегаю вперёд. В данном рецепте давайте начнём строить эти службы устанавливая эти роли и настраивая их для первого раза: самый первый сервер DC/ DNS/ DHCP в нашей сети.

Единственное предварительное требование здесь это рабочий сервер Windows Server 2016, которым мы можем воспользоваться. Мы хотим его подключить в сетевую среду и иметь статический IP адрес с тем, чтобы когда вы добавите новые компьютеры в эту сетевую среду, у них была бы возможность взаимодействовать с этим доменом, который мы почти готовы создать. Кроме того, убедитесь что вы установили имя хоста данного сервера теперь. Когда вы создадите домен в этом контроллере, вы не сможете изменять это имя впоследствии.

Давайте настроим наш первый сервер DC/ DNS/ DHCP выполнив следующий набор инструкций:

Настройка вашего первого DC является существенной для наличия успешной сетевой среды Microsoft. Теперь, когда установлены роли для AD, DNS и DHCP, у нас имеется ядро инфраструктуры на своём месте для начала объединения компьютеров в домен, добавления пользователей в сетевую среду и круговорота некоторого сетевого обмена! Каждая из данных технологий достаточно глубока для гарантии своей собственной книги, поэтому не существует способа, которым мы можем охватить здесь всё. Я надеюсь, что данное руководство предоставит вам удобство включения таких критически важных функций в вашу собственную сетевую среду. Наличие возможности создавать сетевую среду с нуля является неоценимым снаряжением для администратора сервера.

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

AD является ядром вашей сетевой среды. Он связывает всё воедино! В качестве такового он делает чувствительным чтобы вы пожелали его по возможности иметь избыточным. В Windows Server 2016 создание вторичного DC настолько простое, что вы в действительности не имеете причин не делать сделать этого. Можете ли вы представить себе восстановление вашего каталога после однократного отказа оборудования когда у вас имеется 100 учётных записей пользователей и компьютеров, которые все являются частью домена, который только что отказал? А как вам 1000 или даже 10000 пользователей? Это может занять недели, чтобы вычистить всё и, вероятно, никогда не вернётся назад в точности на тот путь, каким он был ранее. Кроме того, пока вы застряли в середине этого простоя, у вас в наличии все виды неисправностей внутри вашей сетевой среды, так как учётные записи ваших пользователей и компьютеров полагаются на AD, который будет выключен. Приведём шаги для поднятия второго сервера в вашей сетевой среде и присоединения его к существующему домену который работает на первичном DC для создания нашего избыточного, вторичного DC. Чем больше становится ваша сетевая среда, тем больше серверов контроллеров домена вам понадобится иметь.

Для этого нам необходимы две машины Server 2016. Первая предполагается уже работающей с Active Directory и DNS, как мы установили такую в нашем предыдущем рецепте. Второй сервер работает, подключён к той же самой сети и имеет имя DC2.

Чтобы создать избыточный вторичный DC, выполните следующие шаги:

Создание избыточности для Active Directory критически важно для доступа в вашу сетевую среду. Оборудование отказывает, мы знаем это. Хорошая практика для любой компании состоит в работе двух DC с тем, чтобы всё продолжало работать в случае отказа сервера. Ещё лучшей практикой будет повторить этот этап ещё и создать больше DC, причём некоторые из них, возможно, на других площадках и, может быть, даже воспользоваться неким RODC ( Read-Only Domain Controllers) в ваших более мелких, менее защищённых площадках. Ознакомьтесь с информацией по следующей ссылке для получения некоторых дополнительных сведений по применению RODC в вашей среде: http://technet.microsoft.com/en-us/library/cc754719(v=ws.10).aspx.

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

В данном рецепте мы создадим некие OU (Organizational Units, Подразделения) внутри Active Directory и переместим наши существующие объекты в эти OU с тем, чтобы мы могли создать некую струтктуру.

В данном рецепте нам нужен некий DC, который является машиной Server 2016 с установленной ролью Службы домена Active Directory. А именно, я буду применять сервер DC1 который мы подготовили ранее в рецепте Настройка комбинации Контроллера домена, сервера DNS и сервера DHCP ранее.

Давайте работать комфортно с Подразделениями (OU), создав свои собственные следующим образом:

В действительности работа связанная с созданием Подразделений (OU) и перемещением объектов между ними совсем не является сложной. Что более важно сказать о данном рецепте, так это упомянуть о том, что вы задумываетесь о том как наилучшим образом организовать эти OU для вашей среды. Разбивая свои учётные записи компьютеров на чётко определённые группы, мы тем самым делаем возможным в будущем более простым способом обнаруживать сколько у нас работает веб- серверов, или делать некоторые быстрые отчёты по тому, сколько учётных записей пользователей у нас имеется в группе продаж. Мв даже сможем применять различные установки Групповых политик различным наборам компьютеров на основе того, к какому Подразделению (OU) они относятся. И отчёты, и установка применения могут быть значительно улучшены при хорошем применении Подразделений (OU) внутри AD.

Многие работающие в ИТ люди знакомы с применением команды ping для тестирования сетевой связи {Прим. пер.: подробнее см. раздел Ping Сетевого инструментария в нашем переводе Полного руководства Windows Server 2016}. Если вы пытаетесь проверить соединение между вашим компьютером и другим, вы можете выполнить ping из приглашения командной строки и протестировать есть или нет ответ. Это предполагает, что имеющиеся в ваших компьютерах и сетевых устройствах межсетевые экраны разрешают ping-у отвечать надлежащим образом, что обычно так и есть. Если вы находитесь внутри сетевой среды домена и выполняете ping к устройству по его имени, это имя разрешается (resolve) в некий IP адрес, который является соответствующим адресом устройства в вашей сетевой среде. Однако кто сообщает вашему компьютеру какой IP адрес соответствует какому имени? Именно здесь на арену выходит DNS. Всякий раз, когда ваш компьютер делает запрос для имени, будь то ping к другому компьютеру, или ваш клиент электронной почты Outlook запрашивает имя у сервера Exchange, ваш компьютер всегда находится на связи с серверами DNS вашей сетевой среды и запрашивает: "Как я могу получить это имя?".

DNS содержит перечень записей, которые сообщают всем компьютерам в вашей сетевой среде какой IP адрес соответствует какому имени. Ранее большинство основных типов записей DNS назывались записями Host (Хост). Когда такая запись Хоста разрешается в IPv4 адрес, например 192.168.0.1, она называется записью A. Когда запись Хоста разрешается в адрес IPv6, например, 2003:836b:2:8100::2, она называется записью AAAA. Это обычно произносится как quad A (четвёрка A). {Прим. пер.: подробности о сокращениях при написании адресов IPv6 см. раздел Введение в IPv6 Главы 5, Построение сетей Windows Server 2016 в нашем переводе Полного руководства Windows Server 2016}.

Понимание того, как создавать и искать неисправности записей Хоста в DNS это нечто, что необходимо знать каждому администратору сервера Windows. Давайте уделим минутку на создание и проверку одной из таких записей DNS с тем, чтобы мы получили из первых рук опыт того, как это всё вместе работает.

У нас имеется некий работающий DC, который также имеет установленную роль DNS. Это всё, что необходимо для создания записи DNS, однако мы также будем использовать клиентский компьютер Windows 10 и некий веб- сервер для выполнения тестирования разрешения имён.

Чтобы создать и проверить запись DNS, выполните следующие шаги:

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

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

Также в операционной системе Windows существует ещё пара других функций разрешения имён, которые могут вызывать необходимость разрешения имён перед тем, как запрос некоторого имени хоста будет получен от вашего сервера DNS. Например, если некто создал статическое имя и запись IP внутри файла host клиентского компьютера, оно будет разрешаться в такое определённый IP адрес вне зависимости от того, что имеется в сервере DNS. Это происходит по той причине, что файл host имеет приоритет над DNS. Кроме того, существует специальная таблица, называемая NRPT (Name Resolution Policy Table Таблицей политики разрешения имени), которая применяется клиентскими компьютерами DirectAccess и она работает аналогичным образом. Запросы на разрешение имён пропускаются сквозь ваш файл host и через вашу NRPT до того как они проделают свой путь к DNS. Если одна из упоминавшихся таблиц имеет некую запись для запрашиваемых имён, они будут разрешаться до того, как компьютер отправит этот запрос на соответствующий сервер DNS для его разрешения. Поэтому если у вас имеются проблемы с именем, которое не разрешается надлежащим образом, имейте в виду эти дополнительные элементы когда ищете ответ на свою задачу.

С рецептом Создание и использование в DNS записи CNAME.

Теперь, когда мы немного познакомились с передвижением внутри вашего инструментария управления DNS, мы собираемся создать и проверить другой тип записи. Он называется CNAME, и проще всего представлять себе его как запись псевдонима. Вместо того, чтобы брать имя DNS и указывать его на некий IP адрес, как мы это делали с записью хоста, применяя CNAME мы собираемся взять имя DNS и указать его на другое имя DNS! Зачем это нужно? Если вы размещаете множество служб на одном сервере, однако хотите чтобы с этими службами можно было связываться применяя различные имена, записи CNAME могут быть вашими лучшими друзьями!

Мы собираемся применять ту же самую среду, которую мы использовали для создания наших записей A в рецепте Создание в DNS записей A и AAAA. Именно работающий сервер DC/DNS, то место где мы намереваемся создать свои записи. А также WEB1, сервер, в котором мы размещаем веб-площадку и некоторые совместные файловые ресурсы. Ещё мы применяем клиента Windows 10 для проверки наших записей CNAME после их создания.

Для создания и проверки записи CNAME выполните следующие инструкции:

У нас в нашей среде имеется сервер WEB1. Существует веб-сайт, работающий на этом сервере. Также он размещает совместные файловые ресурсы, называемые SHARE. Создав пару скорых записей CNAME внутри DNS мы получили возможность предоставить пользователям возможность использования некоторых интуитивно понятных имён для доступа к данным ресурсам. Следуя предыдущим инструкциям мы экранировали действительное имя сервера от своих пользователей, сделав необходимость знать его названия ненужной. Экранирование внутренних имён хостов серверов также рассматривается во многих организациях как хороший практический способ повышения безопасности. {Прим. пер.: можно пройти ещё дальше в удобстве применения совместных файловых ресурсов при помощи Включения Распределённой файловой системы и Пространства имён}.

С рецептом Создание в DNS записей A и AAAA.

В рецептах Настройка комбинации Контроллера домена, сервера DNS и сервера DHCP мы установили на сервер с названием DC1 роль DHCP. Без некоторых настроек, однако, эта роль ничего сама по себе не делает. В большинстве компаний с которыми я работал, всем серверам статически назначается IP адрес, который вводится вручную в свойства его NIC. Таким образом эти сервера всегда остаются с одним и тем же IP адресом. А что будет с машинами клиентов, которые могут перемещаться, или даже входить в сетевую среду и покидать её? DHCP является механизмом, при помощи которого клиенты могут обращаться с запросом на получение информации IP адресации для той сетевой среды, к которой они в настоящее время подключены.

Таким образом пользователи или администраторы не должны беспокоиться о настройке установок IP на их клиентской машине, поскольку они настраиваются автоматически имеющимся сервером DHCP. Чтобы наш сервер DHCP начал обрабатывать IP адреса, нам необходимо настроить неуую сферу.

У нас имеется работающая машина Server 2016 с установленной ролью DHCP. Мы также выполним проверку с помощью клиентской машины Windows 10, чтобы убедиться, что она способна получать надлежащим образом от сервера информацию IP адреса.

Для создания и настройки области видимости DHCP для назначения адреса клиентским компьютерам выполните следующие шаги:

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

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

Мы будем использовать машину Windows Server 2016 в качестве нашего сервера DHCP, в которой мы создадим резервацию DHCP. Кроме того, мы используем наш сервер WEB1 в качестве приёмника данного резервирования выделения WEB1 IP адреса 10.0.0.85.

Чтобы предпринять резервирование DHCP для определённого сервера или ресурса, следуйте приводимым ниже инструкциям:

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

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

Допустим, вы заинтересованы в регулировках нового сервера удалённого доступа, который собирается применять DirectAccess. У вас имеется на месте некая политика домена, которая запрещает Межсетевой экран Windows на компьютерах, которые добавляются в имеющийся контейнер Computers. В этом случае если вы включите новый сервер удалённого доступа и просто подключите его в домен, он немедленно применит такую политику запрета Межсетевого экрана Windows, так как он не отличается от обычного клиентского компьютера из вашей сетевой среды. DirectAccess требует включения Межсетевого экрана Windows и таким образом вы на самом деле разрушите свой сервер ещё до того как начнёте его настраивать! Вы могли бы со временем обнаружить эту ошибку и переместить данный сервер в другое Подразделение (OU), которое не имеет такой расплющенной политики Межсетевого экрана; однако, это не обязательно означает, что все ваши изменения в политике вернутся на своё место. Вы всё ещё можете иметь проблему с этим сервером на постоянной основе.

Приведённый пример является причиной, по которой мы собираемся последовать данному рецепту. Если мы выполним предварительную подготовку учётной записи компьютера для своего нового сервера удалённого доступа, вы сможем выбирать где он будет располагаться внутри Active Directory даже до его подключения к домену. Предварительная подготовка Pre-staging является способом создания ваших объектов компьютера внутри Active Directory до того, как вы перейдёте к реальному компьютеру и кликните Join. Когда вы сделаете это, как только запрос на присоединение к домену поступит, Active Directory уже в точности знает куда поместить учётную запись этого компьютера. Таким образом, вы сможете гарантировать, что ваша учётная запись разместится внутри некоторого Подразделения (OU), которое не собирается применять обсуждавшуюся политику Межсетевого экрана и оставит новый сервер работающим надлежащим образом.

Мы воспользуемся DC Server 2016 для предварительной подготовки нужной нам учётной записи компьютера. Следуя предыдущему примеру, мы применим второй сервер который мы хотим подключить в свой домен и который мы планируем в будущем превратить в сервер удалённого доступа.

Чтобы выполнить предварительную подготовку учётной записи компьютера с тем, чтобы разместить его внутри AD, выполните следующие шаги:

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

Создание новой учётной записи пользователя в Active Directory достаточно стандартное занятие, однако выполнение его обычной манерой требует великого множества мышиных кликов. Как нам известно, PowerShell может применяться для выполнения чего угодно в рамках Windows Server 2016, однако не так много людей на самом деле в действительности делают это на постоянной основе, давайте воспользуемся этой распространённой задачей в качестве рецепта, который можно исполнять при помощи PowerShell вместо GUI.

Мы воспользуемся PowerShell в своём DC Windows Server 2016 с применением приглашения команд PowerShell:

Следуйте нижеперечисленному для создания новой учётной записи пользователя в Active Directory с применением приглашения командной строки PowerShell:

Применяя PowerShell мы в состоянии создавать новые учётные записи Active Directory прямо через командный интерфейс вместо регистрации в некоем сервере и запуске графического интерфейса чтобы выполнить эту распространённую задачу. Могут ли команды New-ADUser стать слишком длинными чтобы заполнить все необходимые атрибуты, которые вы хотели бы включить? Да. Однако, можно ли сохранять сценарий PowerShell и выполнять как использование cmdlet New-ADUser, сберегая ваше время при длительной работе? Абсолютно! Это может занять всего несколько минут на обдумывание и проверку чтобы получить ваш сценарий который бы указывал какую информацию вы бы хотели заполнять, однако когда вы создадите и сохраните этот сценарий, он может в дальнейшем он может быть быстро изменён и исполнен для создания новых учётных записей. Существует даже способ применять cmdlet New-ADUser для копирования из существующей учётной записи пользователя, когда она настроена в новую, что также может помочь сохранить вам некоторые время и энергию при создании учётной записи нового пользователя.

Не забудьте проверить следующую ссылку TechNet. Эта страница предоставит вам все возможные параметры и синтаксис которые могут понадобиться для выполнения аналогичных ваших сценариев New-ADUser. Существуют тонны параметров: http://technet.microsoft.com/en-us/library/ee617253.aspx.

Я обнаружил, что постоянно проверяю сервера на определение того сколько времени прошло в них с последнего перезапуска. Обычно это часть поиска неисправностей как-то связанных с определением того перезагружался ли сервер в качестве запланированного действия или что пошло не так и он выполнил перезагрузку самостоятельно в необычное время. На протяжении долгих лет я запускал Event Viewer, ожидал открытия его Sytem log с надеждой что они не были разрушены каким- либо образом, а затем отправлялся к полудню предыдущего дня, чтобы определить количество секунд, которое отработала данная система. Затем я доставал свой калькулятор и проводил вычисления того сколько дней/ часов назад это произошло. Слишком сложный путь! {Прим. пер.: боимся нарушить методику но, тем не менее, существует альтернатива в виде uptime.} К счастью мы можем обращаться к объектам WMI при помощи PowerShell, а там присутствует объект, который сообщит нам время последнего запуска данного сервера. При помощи нескольких строк включаемых в сценарий .ps1 мы можем самостоятельно создавать великолепные небольшие инструменты, которые будут выводить самое последнее время загрузки сервера. Давайте попробуем.

Мы применяем машину Windows Server 2016 для построения данного сценария.

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

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

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

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

'Check Boot Time.ps1' -ServerName DC1
 	   

Она запустит ваш сценарий и автоматически введёт DC1 в качестве имени сервера в качестве проверяемого сервера вместо остановки для запроса на ваш ввод данных.

{Прим. пер.: можно продвинуться далее и начать собирать данные и выполнять некие действия после их анализа при помощи систем подобных Zabbix.}