Функция для загрузки обновлений из Microsoft Update Catalog

На прошлой неделе, я случайно сделал функцию, загружающую файлы обновлений из Microsoft Update Catalog. Зачем это нужно? Как её применить в реальной жизни?
Например, вы собираете образ операционной системы для последующего его распространения. Наверняка, вы хотите, чтобы этот образ содержал в себе уже все доступные на сегодняшний день обновления: это поможет не только повысить безопасность машин на этапе установки но и сократит время настройки системы после развёртывания.
Для Windows Server 2012 R2 и более ранних ОС, вам придётся загрузить и интегрировать несколько десятков обновлений, но вы не можете быть уверены, какие именно исправления требуются для вашего установочного образа (ISO Windows Server 2012 R2 выпускался, по крайней мере, 3 раза). Единственный точный путь определить это — установить компьютер с этого образа, подключить к Интернету и проверить доступные обновления через Microsoft Update.
В PowerShell обновления проверяются так:

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

Для того, чтобы интегрировать обновление в установочный образ, нужно как-то получить его .msu- или .cab-файл. К сожалению, из объекта $SearchResult невозможно извлечь ссылки для загрузки таких файлов (во всяком случае, мне об этом ничего не известно). И вот с этим на и поможет функция Get-WUFilebyID:
Во первых, мы извлечём список идентификаторов обновлений из объекта $SearchResult:

А затем, по очереди, передадим эти идентификаторы в функцию:

В параметре -SearchCriteria нужно указать для какого продукта загружать обновления.

В итоге, вы получите все файлы обновлений (по умолчанию, в текущем каталоге. Переопределяется параметром -DestinationDirectory) и сможете их интегрировать при помощи командлета Add-WindowsPackage

Если вы не хотите загружать файлов, а только получить ссылки на них, используйте переключатель -LinksOnly.

Функция покрыта тестами и доступна на GitHub. Вопросы и предложения приветствуются: вы можете либо оставить их прямо здесь в комментариях, либо на GitHub в разделе Issues.

Новые возможности для сценария синхронизации DNS

Привет!
Сорри за задержку с постами: я переезжал из Москвы на Кипр, где теперь живу и работаю.
Я всё ещё заканчиваю следующую часть саги о разворачивании инфраструктуры из командной строки, но тут, для выполнения рабочих задач, мне потребовалось добавить новую функциональность в мой сценарий синхронизации DNS-зон и я не могу вами ими не поделиться:

  1. Появились режимы запросов к NS. Пока их всего два:
    • «1» — Скрипт попытается найти авторитативные nameserver’ы для зоны и дальше, для разрешения имён из неё, будет использовать именно их.
    • «0» — Скрипт будет использовать nameserver, указанный в конфигурационном файле, как обычно.

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

  2. Из-за необходимости использовать авторитативные DNS-серверы, скрипт обзавёлся ещё одной функцией: теперь можно указывать в конфиге не только IP-адреса, но и DNS-имена. Так что, колонки «IntIP» и «ExtIP» теперь называются «IntNS» и «ExtNS».
  3. Ну и ещё, т.к. это было довольно просто сделать: вы можете оставить колонку ExtNS пустой — тогда для этой зоны сценарий будет использовать DNS-серверы, используемые операционной системой.

Вот таблица, как все эти новые функции работают вместе:

Режим Тип ExtNS Результат
0 IP-адрес Имена в зоне разрешаются через NS на IP-адресе ExtNS.
1 IP-адрес IP-адрес ExtNS используется для того, чтобы найти авторитативные NS для зоны.
Далее, первый авторитативный nameserver из списка используется для разрешения имён в зоне.
0 DNS-имя DNS-серверы операционной системы используются для разрешения имени ExtNS в IP-адрес.
Далее, этот IP-адрес используется для разрешения имён в зоне.
1 DNS-имя DNS-серверы операционной системы используются для разрешения имени ExtNS в IP-адрес.
Далее, этот IP-адрес используется для того, чтобы найти авторитативные NS для зоны.
Далее, первый авторитативный nameserver из списка используется для разрешения имён в зоне.
0 Empty
1 Empty DNS-серверы операционной системы используются для того, чтобы найти авторитативные NS для зоны.
Далее, первый авторитативный nameserver из списка используется для разрешения имён в зоне.

Обратите внимание, что режим запроса влияет только на ExtNS, но не на внутренний сервер. Вот таблица состояний для «IntNS»:

Тип IntNS Результат
IP-адрес Запросы отправляются на этот IP-алрес, как обычно.
DNS-имя DNS-серверы операционной системы используются для разрешения имени IntNS в IP-адрес.
Далее, все запросы отправляются на этот IP-адрес.
Empty Возникает ошибка. Event ID 52.

Как обычно, забирайте последнюю версию с GitHub`а!

Небольшое обновление к моему сценарию синхронизации DNS

Я только что опубликовал небольшое обновление к моему сценарию синхронизации DNS-записей. Обновление включает в себя:

  1. Исправлена проблема, когда записи более низкого уровня мешали обновлять запись более высокого уровня.
  2. Время начала и конца теперь отформатированны одинаково.
  3. Но самое заметное для пользователей изменение это, конечно, переименование: теперь скрипт называется Sync-DNSZones, в соответствии со стандартом именования функций в PowerShell.

Если вы выполните командлет Get-Verb без параметров, вы увидите, что в его выводе нет слова «Synchronize» — вот почему я переименовал скрипт. Не забудьте также переименовать файлы «-NS» и «-REC» соответственно.

Проверяем дату на различные условия с помощью PowerShell

Несколько недель назад, мой друг Rich Mawdsley задал вопрос в нашей Slack-команде Windows-администраторов: как определить, что сегодня именно второй вторник месяца? Обнаружилось, что в PowerShell нет встроенного метода для ответа на такой вопрос. Вот почему, сегодня я представляю вам функцию, предназначение которой — проверять дату на определённые условия. Функция определяет:

  • Является ли дата днём недели определённого номера в этом месяце: Например, 4-й понедельник, второй вторник, последнее воскресенье и т.п.
  • Входит ли дата в определённый квартал.
  • Является ли заданная дата началом или концом квартала.
  • Последний ли это день месяца и т.д.

Возвращает функция всего лишь булево значение: $true, если дата удовлетворяет заданным условиям, $false если не удовлетворяет. Больше никаких данных о переданной ей дате функция не рассказывает.

Ниже представлен сам код, а его последнюю версию вы всегда можете найти на моём GitHub:

Функция покрыта тестами (результаты вы можете посмотреть здесь), но не полностью — в будущем я определённо улучшу их. И да, тесты работают — они помогли мне найти несколько ошибок 😉

Кстати, если вы никогда раньше не писали тесты для PowerShell, самое время начать: вот это Введение в тестирование с помощью Pester Jakub Jares`а очень поможет вам — вы начнёте писать тесты ещё до окончания лекции.

Строим высоко-доступную Windows-инфраструктуру в командной строке. AD DS. Часть 2-я — Пост-конфигурация

В предыдущей части — Building Highly-Available Windows Infrastructure: Command-line Style. AD DS. Part 1 — Installation

Вступление

В этом посте мы займёмся пост-конфигурацией Active Directory: Мы определим зоны безопасности, которые в дальнейшем станут краеугольными камнями в вопросе делегирования разрешений, и ограничим добавление объектов в домен. Также, мы немного донастроим службу DNS.


Читать далее Строим высоко-доступную Windows-инфраструктуру в командной строке. AD DS. Часть 2-я — Пост-конфигурация

Строим высоко-доступную Windows-инфраструктуру в командной строке. AD DS. Часть 1-я — Установка

Вступление

По сей день, Active Directory Domain Services (AD DS) остаются ядром Windows-инфраструктуры. С каждым релизом Windows Server, AD DS получает новые возможности , сохраняя превосзходную обратную совместимость. Windows Server 2016 привносит следующие улучшения в AD DS:

В этой статье мы заложим краеугольный камень нашей будущей инфраструктуры: высоко-доступный экземпляр AD DS из двух контроллеров домена. Схема будет простейшей: два обычных контроллера домена в одном сайте.


Читать далее Строим высоко-доступную Windows-инфраструктуру в командной строке. AD DS. Часть 1-я — Установка

Строим высоко-доступную Windows-инфраструктуру в командной строке

Несколько месяцев назад была выпущена Windows Server 2016. В этом релизе Microsoft произвела 2 существенных изменения в вариантах установки Windows Server:

  • Появился Nano Server.
  • Установка «Server with a GUI» теперь включает «desktop experience» и называется соответствующе: «Server with Desktop Experience». Т.к. не существует поддерживаемого способа удалить компоненты desktop experience, Это должно мотивировать ИТ-администраторов использовать Server Core, вместо версии с графическим интерфейсом.

Т.е. всё за то, чтобы прекратить, наконец-то, использовать графический интерфейс при управлении Windows Server и начать полноценно работать в командной строке.
Этот пост — первый в серии о том, как построить свою собственную высоко-доступную инфраструктуру на Windows, используя исключительно PowerShell (и немного других утилит командной строки). В идеале я планирую обсудить следующее:

  • Active Directory Domain Services,
  • Active Directory Certificate Services,
  • Desired State Configuration,
  • Key Management Services,
  • DHCP,
  • SCDPM,
  • SCCM,
  • Exchange Server,
  • And, possibly, S4B Server, as well.

Пока я не могу говорить об управлении и развёртывании Hyper-V, т.к. вся моя инфраструктура полностью виртуальная и, к сожалению, хостовые машины работают под управлением Windows Server 2012 R2.

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

И первая часть уже здесь! Строим высоко-доступную Windows-инфраструктуру в командной строке. AD DS. Часть 1-я — Установка

Большая переработка Synchronize-DNSZones.ps1

Сегодня я закончил серьёзную переработку моего сценария синхронизации DNS-зон Synchronize-DNSZones (больше о нём вы можете прочитать здесь). Основной причиной для переработки, являлось добавление поддержки записей на уровне непосредственно самой зоны. Для того, чтобы делать это эффективно, я разбил большой кусок кода на несколько функций (и вижу, что можно его подробить ещё).
В связи с новой функциональностью, появились и новые предупреждения:
55 — DNS-zone creation is not yet supported. (И не думаю, что когда-либо будет поддерживаться)
72 — Function New-DnsRecord failed.
82 — Cannot import DNSClient PowerShell module.

В процессе переработки я, наконец-то, заменил все глаголы в именах функций на одобренные (см. Get-Verb). Имя самого сценария я изменю чуть позже.
Исправил ситуацию с возвращением функцией Receive-DnsData пустого ответа.
Исправил опечатки, некорректную обработку ошибок, немного улучшил комментарии.
Также, вернул на место забытое объявление переменной $SMTPCc.

В будущем планирую добавить поддержку ShouldProcess (WhatIf).

Ваши пулл-реквесты и сообщения о проблемах приветствуются!

Презентация LAPS

Как я писал ранее, в декабре я выступал на IT Pro UG с докладом о LAPS.
Видео, наконец-то, обработано и доступно:

Саму презентацию вы можете скачать здесь.

После доклада задали пару вопросов:
Q: Передаётся ли пароль открытым текстом по сети в момент его обновления или считывания утилитой?
A: Нет, LDAP-соединение в таких случаях защищается при помощи SASL. Однако же, если при установке соединения в собственных средствах/скриптах вы явно укажете LDAP_OPT_ENCRYPT = 0 или будете использовать ldap_simple_bind без TLS/SSL, тогда всё будет передаваться открытым текстом.

Q: Почему бы вообще локальные учетки не отключать? При каком бизнес-сценарии нам понадобится управлять их паролями?
A: Например, в том случае, если машина потеряла домен и надо получить к ней доступ с минимальными изменениями (без перезагрузок, оффлайн-сброса пароля и т.п.). Кеш доменного пароля толже может не помочь в таком сценарии, если на машине не сохранён ни один из известных — с LAPS можно быть более уверенным, что доступ к системе получишь.

Google Glazier

Ого, Google только что выложил штуку для автоматической установки Windows. Штука написана на питоне и называется Glazier (стекольщик). Образы ОС в ней строятся на основании конфигурационных файлов, написанных на YAML — можно их хранить в системе контроля версий и очень удобно отслеживать изменения, откатываться и т.д.

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

Распространяется по лицензии Apache 2.0, пулл реквесты приветствуются.