В этой статье:

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

• Развертывание операционных систем
• Управление и доставка обновлений
• Инвентаризация аппаратных ĸомпонентов и программного обеспечения
• Удаленное подключение и управление устройствами
• Развертывание программного обеспечения
• Управление требуемой конфигурацией
• Управление Defender
• Получение отчетов

Systems Management Server 1.х

История Configuration Manager начинается с 1994 года. Тогда продукт именовался как Systems Management Server версии 1.0 (SMS). По сей день аббревиатура SMS встречается в Configuration Manager, будь то название компонента или часть названия лог-файла.

Последующими выпусĸами в линейĸе продуĸтов 1.x были версии 1.1 и 1.2, выпущенные в 1995 и 1996 годах соответственно. Хотя эти два минорных выпусĸа изначально планировались ĸаĸ паĸеты обновления, добавленные фунĸции были достаточно значительными, чтобы стать выпусĸами продуĸтов.

Однаĸо версия 1.x продуĸта не получила широĸого распространения.

Systems Management Server 2.0

В начале 1999 году корпорация Microsoft выпустила очередную мажорную версию 2.0, пользовательский интерфейс консоли администрирования базировался на консоли управления Microsoft (MMC).

Первый паĸет обновления (SP) стал доступен через восемь месяцев спустя выхода релиза. Продуĸт страдал от ошибоĸ и стал относительно стабильной платформой тольĸо с выходом SP2, выпущенном в 2000 году. В 2001 году Microsoft выпускает третий пакет обновлений SP3 и платформа действительно стабилизировалась.

SMS 2.0 решил многие проблемы, с ĸоторыми сталĸивались ĸлиенты Microsoft с SMS 1.x. В 2002 и в 2003 года Microsoft выпустила четвертый (SP4) и пятый (SP5) пакеты обновлений, которые обеспечивали исправления ошибок, но не включали в себя новых функций.

Недостатки SMS 2.0 заставили Microsoft выпустить третье поколение SMS.

Systems Management Server 2003

Далее Microsoft версию продукта стала именовать по году выпуска, таким образов в ноябре 2003 году появляется Systems Management Server 2003 (также известный как SMS 3.0).

Большинство изменений в этой версии не были заметны в ĸонсоли, все изменения были “под капотом”. Пользовательсĸий интерфейс выглядел почти таĸ же, ĸаĸ в SMS 2.0.

В данной версии была добавлена интеграция с Active Directory и поддерживались операционные системы Windows 98 и Windows NT 4.0. Поддержка Windows 95 была полностью прекращена.

Чтобы оставаться ĸонĸурентоспособной, Microsoft продолжала постепенно наращивать фунĸциональность в SMS 2003 с паĸетами обновлений и новым большим выпуском под названием R2 (релиз 2) в конце 2006 года.

Первые два паĸета обновления (выпущенные в 2004 году и июне 2006 года) были в основном исправлениями с оптимизацией производительности. Фунĸциональные изменения были незначительными, добавив поддержĸу новых операционных систем. SMS 2003 SP3, выпущенный в 2007 году который включал поддержку Windows Vista, был последним обновлением продуĸта для третьего поколения.

Systems Center Configuration Manager 2007

В 4 поколении продуĸта произошли изменения в брендинге. Программное обеспечение больше не называлось Systems Management Server, оно было согласовано с линейĸой продуĸтов System Center и переименовано в Configuration Manager (сокращенное название ConfigMgr или чаще всего SCCM). ConfigMgr 2007 был выпущен в августе 2007 года.

Была прекращена поддержка Windows 2000.

Всего через год после выпусĸа в производство (RTM) ConfigMgr 2007 Microsoft выпустила ConfigMgr 2007 R2. А в 2010 году Microsoft выпустила ConfigMgr 2007 R3.

Systems Center Configuration Manager 2012

В первой половине 2012 года Microsoft выпускает пятое поколение продукта который входит в состав System Center 2012.

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

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

Была добавлена поддержка Windows 8.x и управления мобильными устройствами iOS и Android.

В конце 2013 году вышло обновление в виде редакции 2012 R2.

System Center Configuration Manager Current Branch

В июле 2015 ĸомпания Microsoft официально выпусĸает ОС Windows 10 RTM, ĸоторая имеет принципиально новую модель обновления системы — Windows as a Service. Начиная с этого момента, администраторы начинают работать с тремя разными версиями Windows 10 — «Current Branch», «Current Branch for Business» и «Long-Term Servicing Branch». В то же время появилась информация про готовящееся ĸ релизу следующее поĸоление SCCM под ĸодовым названием ConfigMgr v.Next.

В оĸтябре 2015 была опублиĸована стратегия развития продуĸта, отĸуда становится известно про будущее название — SCCM Current Branch, и в деĸабре 2015 официально выходит первая версия SCCM Current Branch 1511 (SCCM CB 1511). Аналогично релизам Windows 10, цифры означают год и месяц выхода данного релиза. Главной особенностью здесь является то, что время поддержĸи ĸаждого релиза (ветка) — 12 месяцев. Но с ветки 1710 срок поддержки увеличивается до 18 месяцев.

Configuration Manager 1511 входила в состав System Center 2016. Теперь Configuration Manager использует процесс обновления и обслуживания в консоли, который позволяет легко находить и устанавливать обновления Configuration Manager. Это означает, что больше не нужно отслеживать версии пакетов обновления или накопительных пакетов обновления. Больше не требуется искать доступные для скачивания актуальные выпуски или обновления на сайте Microsoft. Все обновления и новые релизы доступны в консоли управления Configuration Manager, которая позволяет находить и затем устанавливать необходимое обновления в консоли.

Новые версии с обновлениями продуктов выходят несколько раз в год. Каждой версия представляет новые возможности.

Версии обновления идентифицируются по номеру года и месяца. Например, 1511 обозначает ноябрь 2015 г. (месяц, когда Configuration Manager был впервые выпущен в производство). Последующие обновления, начиная с 2016 г., имеют такие имена версий, как 1602, 1606 и 1610, которое указывает, что обновление создано в феврале, в июне и в октябре 2016 г.соответственно. И так для каждого последующего года.

Эти версии обновления позволяют понять, какую добавочную версию имеет ваша установка Configuration Manager и какие функции доступны в развертывании.

Microsoft придерживается выпуска добавочных версий 3 раза в года, с 2016 по 2020 год в феврале в виде выпуска базовой установки (YY02), при чем установочный дистрибутив для чистой установки как правило становится доступен в следующем месяце, в июне (YY06) и октябре (YY10) в виде добавочной версии. В начале 2021 года Microsoft поменяла сроки выхода новых версий сместив на месяц вперед, таким образом на текущий момент базовая версия выходит в марте (YY03) и две добавочные версии в июле (YY07) и в ноябре (YY11).

Таким образом если, например, необходимо внедрить в организации версию 2111, то для этого необходимо вначале установить базовую версию 2103 и уже в консоли Configuration Manager обновить текущую установку до версии 2111.

Microsoft Endpoint Manager Configuration Manager Current Branch

В конце 2019 года Microsoft решила вывести Configuration Manager из семейства System Center и объединить с Intune под новым брендом Microsoft Endpoint Manager. Таким образов версия 1910 стала именоваться Microsoft Endpoint Manager Configuration Manager (MEMCM). В это время когда организация хотела внедрить себе Configuration Manager необходимо было скачать дистрибутив System Center Configuration Manager 1902 (базовый носитель) и далее в консоли запустить обновление до 1910, который при установке обновления изменяет название на Microsoft Endpoint Manager Configuration Manager.

Версия 2002 становится базовой для установки Microsoft Edpoint Manager Configuration Manager.

Configuration Manager существует в 4 ветвях:

• Current Branch
• Ознакомительная установка Current Branch
• Long-term servicing branch (так называемая LTSB)
• Ветвь Technical Preview

Current Branch

До сих пор речь шла о так называемой Curent Branch версии Configuration Manager.

Эта ветвь лицензирована для использования в рабочей среде. Она предоставляет доступ к новейшим компонентам и функциям. Эту ветвь можно использовать при наличии лицензий Configuration Manager по программе Software Assurance (SA) и License and Software Assurance (L&SA), а так же при наличии таких подписок как Enterprise Mobility + Security (EMS) и Microsoft 365 корпоративный. Могут быть и другие программы лицензирования, но эти наиболее распространенные.

Ознакомительная установка Current Branch

Ознакомительная версия не требует наличия соглашения Software Assurance с корпорацией Майкрософт. Ознакомительные установки могут принадлежать только ветви Current Branch, и их можно использовать в течение 180 дней.

Вы можете обновить ознакомительную установку до полной установки Current Branch. А вот обновить ознакомительную установку до Long-Term Servicing Branch уже не получиться.

Long-term servicing branch (LTSB)

Эта ветвь лицензирована для использования в рабочей среде Configuration Manager для клиентов, использующих Current Branch и согласившихся, что срок действия их участия в программе Configuration Manager Software Assurance (SA) или эквивалентных прав по подписке истекает после 1 октября 2016 г.

В основе ветви LTSB лежит версия 1606. Эта ветвь не получает обновления в консоли, предоставляющие новые возможности или обновляющие существующие компоненты. Тем не менее важные исправления безопасности предоставляются. Чтобы установить LTSB, нужно использовать базовый носитель с версией 1606, который поставляется вместе с System Center 2016. Более поздние базовые версии не поддерживают установку LTSB.

Таким образом, например, если у вас закончилась одна из подписок дающая права использовать Current Branch, и вы хотели бы продолжить использовать Configuration Manager в своей организации, то вам необходимо будет удалить текущую установку, например, на момент окончания подписки Microsoft 365 корпоративный у вас был развернут Configuration Manager 1910. Вам придеться деинсталировать данную версию и установить заново версию 1606.

В дальнейшем если вы захотите возобновить использование подписки, например, Microsoft 365 корпоративный, то вы сможете установку Configuration Manager LTSB приобразовать в Current Btanch без переустановки.

Ветвь Technical Preview

Ветвь Technical Preview предназначена для применения в лабораторной среде. Благодаря этому вы можете изучать и апробировать новейшие возможности, разрабатываемые для Configuration Manager. Она не поддерживается в рабочей среде и не требует наличия лицензионного соглашения Software Assurance.

Чтобы установить новый сайт под управлением Technical Preview, используйте последнюю версию базового носителя для ветви Technical Preview. После установки ветви Technical Preview новые версии доступны как ежемесячные обновления в консоли.

Делегирование позволяет предоставлять разрешения на выполнение некоторых задач управления Active Directory (AD) пользователям домена (не администратора) без добавления их в привилегированные группы доменов, такие как администраторы домена, операторы учетных записей и т. д. Например, можно использовать делегирование для предоставления определенной группе безопасности AD (например, Helpdesk) разрешения на добавление пользователей в группы, создание новых пользователей в AD и сброс паролей учетных записей.

В этой статье:

Понимание делегирования разрешений Active Directory

Для делегирования разрешений в AD используется мастер делегирования управления в консоли Active Directory Users and Computers (DSA.msc).

Можно делегировать административные привилегии в AD на довольно детальном уровне. Например, предоставить одной группе сброс паролей в Organization Unit (OU), другой - для создания и удаления учетных записей пользователей, а третьей - для создания и изменения членства в группе. Можно настроить наследование разрешений на вложенных OU. Разрешения могут быть делегированы в Active Directory на следующих уровнях:

• Сайт AD;
• Весь домен;
• Конкретная организационная единица (OU) в AD;
• Конкретный объект AD.

Рекомендации по управлению делегированием в Active Directory:

• Не рекомендуется делегировать (назначать) разрешения непосредственно конкретным учетным записям пользователей. Вместо этого рекомендуется создавать новую группу безопасности в AD, добавить в нее пользователя и делегировать разрешения на OU для этой группы. Если необходимо предоставить те же разрешения другому пользователю, то можно просто добавить пользователя в эту группу безопасности;
• Избегать использования разрешений Deny, так как они превыше разрешенных;
• Не предоставлять никому разрешение на управление OU с учетными записями администратора. В противном случае любой сотрудник службы поддержки может сбросить пароль администратора домена. Все привилегированные пользователи и группы должны быть помещены в отдельное OU, на которое не распространяются правила делегирования.

Делегирование на изменение атрибутов в Active Directory

Допустим, необходимо предоставить некоторой учетной записи права на изменения атрибута Description всем объектам расположенные в конкретной организационной единице (OU) в AD, например, в demo.daste.ru/TestOU.

В оснастке ADUC необходимо правой кнопкой мыши щелкнуть на необходимую организационной единицу (OU) (в данном примере OU=TestOU,DC=demo,DC=daste,DC=ru) и выбрать пункт меню Delegate Control...

В появившемся мастере Delegate of Control Wizard, предпочтительно выбрать группу безопасности, где будут содержаться пользователи, которым данное право будет предоставляться, но в данном примере будет выбрана одна учетная запись User1.

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

Далее выбираем тип задачи Create a custom task to delegate.

На следующей странице мастера необходимо выбрать Only the following objects in the folder и отменить пункт User object, так как необходимы права на изменения атрибута объекта пользователя.

На следующей странице мастера необходимо отметить Property-specific и найти необходимы атрибут в списке, Read Description и Write Description.

После сохранения настроек у пользователя User1 появится права на изменения атрибута Description объектам, расположенные в OU=TestOU,DC=demo,DC=daste,DC=ru при этом доступ к другим атрибутам будет только на чтение.

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

Любое количество правил делегирования может быть назначено OU в AD. Можно получить список групп и делегированных им разрешений в свойствах OU в консоли ADUC. Необходимо перейти на вкладку Security.

Эта вкладка содержит список объектов AD, которым были предоставлены разрешения для этого контейнера. Если нажать на кнопку Advanced, то можно детальнее получить информацию по выданным правам для объектов.

Выбрав учетную запись User1 и нажать кнопку Edit, можно посмотреть каким атрибутам были предоставлены права данной учетной записи. Здесь отображаются все атрибуты и при необходимости можно добавить необходимые найдя в списке и выбрав необходимые права Read... и/или Write...

Если необходимо удалить права, то в свойствах OU в разделе Security выбрать необходимую группу безопасности или учетную запись и нажать Remove. После чего сохранить изменения.

Служба каталогов Active Directory (AD) хранит множество имен, которые используются для обозначения или описания объекта, например, учетной записи пользователя. Большинство имен являются атрибутами объекта, которые могут ссылаться на другой атрибут или быть вычисляемым - состоящий из значений других атрибутов.

Если открыть оснастку Active Directory Users and Computers (ADUC) и создать новую учетную запись, то появится форма для заполнения полей:

При создании указываем Имя (First name), Фамилию (Last name) и инициалы (Initials), из которых формируется полное имя (Full name). Так же есть два поля для имени входа — User logon name и User logon name (pre-Windows 2000).

Чтобы просмотреть все атрибуты для учетной записи, необходимо в оснастке ADUC включить расширенные возможности отображения данных отметив в меню View пункт Advanced Features.

Открыв свойства учетной записи и перейдя во вкладку Attribute Editor будут отображены все атрибуты для данной учетной записи в AD с различными атрибутами, но схожими значениями.

Полному имени пользователя соответствуют три атрибута - cn, displayName и name. Значение одинаковое, но назначение каждого атрибута разное.

Полное имя (name) и общее имя (Common name, cn) — это два разных атрибута, хотя возвращают каждый одно и то же значение. Это происходит потому, что атрибут name аналогичен относительному отличительному имени (Relative Distinguished Name, RDN), а RDN — это часть отличительного имени (Distinguished Name, DN). Так если DN равно ″CN=Иван П. Сидоров,OU=TestOU,DC=demo,DC=daste,DC=ru″, то RDN будет ″CN=Иван П. Сидоров″. Отсюда получаем, что если cn=″Иван П. Сидоров″, то name =″cn=Иван П. Сидоров″.

Изменить значение атрибута cn нет возможности, потому что всегда равно значению name.

Отображаемое имя (displayName) по умолчанию формируется по принципу: полное (name) и общее (cn) имена. Для проверки можно изменить полное имя пользователя и увидеть, что полное и отображаемое имена изменяются независимо друг от друга.

В редакторе атрибутов можно увидеть, что вместе со значением атрибута nameизменилось и значение cn, при этом вручную значение не изменялось.

Кроме отображаемого имени (displayName) у учетной записи пользователя есть еще отображаемое имя для печати (displayNamePrintable). Это два разных, независимых друг от друга атрибута.

Имя пользователя соответствует атрибуту givenName, а фамилия — атрибуту sn (Surname). К отчеству относится атрибут OtherName.

С помощью командлета Get-ADUser можно получить все атрибуты схожие и относящиеся к имени пользователя:

Get-ADUser ivan.sidorov -Properties * | select *name 

Атрибут OtherName является пустым и можно задать значение командлетом Set-ADUser:

Get-ADUser ivan.sidorov -Properties * | Set-ADUser -OtherName "Петрович" 

В результате теперь отображаются два атрибута с заданным значением — OtherName и middleName.

При этом в PowerShell отображаются два атрибута, а в оснастке ADUC отображается только один атрибут middleName.

Имен входа (logon names) для учетной записи пользователя два.

User logon name соответствует атрибуту userPrincipalName, а User logon name (pre-Windows 2000) соответствует атрибуту sAMAccountname.

userPrincipalName (UPN) — имя участника-пользователя. Это новый формат указания имени пользователя для входа в систему, основанный на интернет-стандарте RFC 822. Для входа используется сочетание имени пользователя с доменным суффиксом, например ivan.sidorov@demo.daste.ru. Имя участника-пользователя должно быть уникальным среди всех объектов-участников безопасности в лесу доменов. Максимальная длина UPN составляет 1024 символа. UPN не является обязательным атрибутом, оно может быть не назначено при создании учетной записи пользователя.

sAMAccountName — имя учетной записи SAM. Предназначено для совместимости со старыми (до Windows 2000) операционными системами. Это не означает, что sAMAccountName не используется в качестве имени для входа в современных системах Windows. sAMAccountname должно быть уникальным в рамках домена, имеет ограничение в 20 символов и работает в сочетании с NETBIOS именем домена, например DEMO\ivan.sidorov. sAMAccountName является обязательным атрибутом пользователя.

Учетная запись пользователя имеет еще два атрибута, это DistinguishedName (различающееся имя) и CanonicalName (каноническое имя). Оба эти атрибута однозначно определяют объект в Active Directory.

Различающееся имя включает в себя относительное отличительное имя объекта (RDN), а также полный путь к контейнеру, содержащему объект в Active Directory, например ″CN=Иван Петрович Сидоров,CN=TestOU,DC=Demo,DC=daste,DC=ru″. Каноническое имя — это то же различающееся имя объекта, но в каноническом виде, например ″demo.daste.ru/TestOU/Иван Петрович Сидоров″.

💡 CanonicalName является конструируемым атрибутом (constructed attribute). Такие атрибуты не хранятся явным образом в AD, а вычисляются на лету при получении соответствующих запросов.

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

Тем не менее обязательные атрибуты для создания учетной записи необходимы не все. Если в редакторе атрибутов отфильтровать все атрибуты по признаку обязательный (Mandatory), то будут отображаться только два имени — CommonName (cn) и sAMAccountName.

Со всеми атрибутами учетной записи пользователя можно ознакомиться в документации вендора.

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

Переустановить стенд в ручном режиме в среднем занимает один день. Выделить на это время сложно. Было решено потратить день на создание автоматизации, теперь при необходимости стенд пересоздается за считанные минуты.

Инфраструктура

Для организации стенда хватает рабочей станции под управлением клиентской Windows с установленным Hyper-V на котором возможно организовать стенд для тестирования и прототипирования решения.

Характеристики рабочей станции

CPU - Intel Core i3 10105 3.7GHz

RAM - 64Gb

DISK - Team Group M2 1Tb

OS - Windows 11 Pro

Настройки окружения

Все виртуальные машины хранятся в каталоге D:\Hyper-V

В Hyper-V настроены два типа коммутаторов: vExternal и vPrivate. vExternal сопоставлен с Wi-Fi адаптером, чтобы у виртуальных машин был доступ в Интернет.

Иногда используется дополнительная виртуальная машина, с настроенной службой маршрутизации и удаленного доступа (Routing and Remote Access Service - RRAS), которая выполняет роль шлюза для доступа в интернет. Таким образом в виртуальных машинах кому необходим доступ в Интернет в качестве шлюза указывается IP-адрес виртуальная машина с ролью RRAS.

Подготовка образов

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

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

Необходимые настройки операционной системы при первом запуске сохраняем в файл на диске эталонной виртуальной машины, например, autounattend.xml на диске C:, который и будет использоваться как один из параметров файла ответов для запуска Sysprep после окончания настройки ОС в виртуальной машине.

sysprep /generalize /oobe /shutdown /unattend:c:\autounattend.xml

Выключаем виртуальную машину. Готово.

На хосте гипервизора в каталоге D:\Hyper-V создаем новый Template, в котором будут размещаться диски с эталонными образами операционных систем со своей системой обозначения:

ws16 - Windows Server 2016 Standard
ws19 - Windows Server 2019 Standard
ws22 - Windows Server 2022 Standard
ws22c - Windows Server 2022 Core
w7 - Windows 7 Pro
w7e - Windows 7 Enterprise
w10 - Windows 10 Pro
w10e - Windows 10 Enterprise
w11 - Windows 11 Pro
w11e - Windows 11 Enterprise

Инструментарий

В качестве автоматизации используется PowerShell. Код удобно писать в Visual Studio Code, иногда в PowerShell ISE, а хранить результат в репозитории GitHub.

Постарался сделать универсальный инструмент для автоматического поднятия демо стенда. Для этого необходимо заполнить CSV-файл, где будут перечислены все виртуальные машины с их параметрами.

Логика работы

В автоматическом режиме будет:

1. созданы все виртуальные машины из списка CSV-файла
2. развернут контроллер домена
3. все виртуальные серверы автоматически включены в домен при условии если это значение было указано в CSV-файле (domain/workgroup)

Пример CSV-файла

VM;Role;RAMStart;RAMMin;RAMMax;CPU;Switch;OS;FQDN;IP;Join;Add
DC;DC;2048;512;4096;2;vPrivate;WS19;dc-01;192.168.0.1;domain;False
GTW;gateway;2048;2048;2048;2;vPrivate;WS19;gtw;192.168.0.10;workgroup;False
W10-01;client;2048;512;4096;4;vPrivate;w10;w10-01;192.168.0.11;domain;False
W10-02;client;2048;512;4096;4;vPrivate;w10;w10-02;192.168.0.12;workgroup;Fasle
CM;ConfigMgr;8196;8196;16392;4;vPrivate;WS19;cm;192.168.0.2;domain;False
W10-04;client;2048;512;4096;4;vPrivate;w10;w10-04;192.168.0.15;workgroup;True
W10-05;client;2048;512;4096;4;vPrivate;w10;w10-05;192.168.0.16;workgroup;True
W10-06;client;2048;512;4096;4;vPrivate;w10;w10-06;192.168.0.17;workgroup;True
W10-07;client;2048;512;4096;4;vPrivate;w10;w10-07;192.168.0.18;workgroup;True

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

В моем случае для всех систем сделал одинаковый логин и пароль, когда создавал файл ответов для запуска Sysprep на эталонных виртуальных машинах:

Скрипты

Когда все готово можно запускать скрипты по очереди:

1. Add-VM.ps1 - скрипт для создания всех виртуальных машин из CSV-файла. После отработки скрипта необходимо подождать пока операционные системы подготовятся на созданных виртуальных машинах, т.к. при первом запуске отрабатывается файл ответом, который был запущен на виртуальной машине, когда была подготовка эталонного образа операционной системы.
2. Add-AD.ps1 - скрипт для поднятия контроллера домена После запуска необходимо дождаться автоматической настройки сервера и установки роли контроллера домена.
3. Set-Server.ps1 - скрипт для настройки серверов: присвоение имени, назначения IP-адреса и ввода в домен если это указано в CSV-файле.
4. Set-Client.ps1 - скрипт для настройки клиентов: присвоение имени, назначения IP-адреса и ввода в домен если это указано в CSV-файле.

Для этого необходимо:

• Убедиться, что на сервере установлен Exchange Management Shell

• Открыть планировщик заданий (Task Scheduler). Можно воспользоваться комбинацией клавиш Win+R и ввести команду taskschd.msc для запуска

• В разделе Task Scheduler Library создать простую задачу выбрав в контекстом меню Create Basic Task...

• В мастере создания задачи необходимо указать название создаваемой задачи и при необходимости заполнить поле с описанием

• Выбрать необходимый тип триггера, например, чтобы задача запускалась по расписанию

• В зависимости от выбора типа триггера, если указан запуск по расписанию, то необходимо указать параметры расписания запуска

• Так как требуется запустить скрипт по расписание, то необходимо выбрать действие Start a program

• В разделе Start a Program необходимо:
• указать исполняемый файл PowerShell, по умолчанию это путь
  C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
• в поле аргументы необходимо ввести
  -command ". 'c:\Program Files\Microsoft\Exchange Server\V15\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; с:\Scripts\DeleteMessages.PS1

• В конце необходимо отметить Open the Properties dialog for this task I click Finish, чтобы можно было дополнительно настроить от какого имени запускать данную задачу

• Необходимо выбрать учетную запись от имени которой будет стартовать задача по расписанию с запуском скрипта для Exchange Server

Например такое

Для решения есть несколько вариантов:

Решение 1 - с помощью реестра

• Открыть редактор реестра regedit, воспользовавшись комбинацией Win+R

• Раскрыть ветку реестра "Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System"

• Указать значения для параметров legalnoticecaption и legalnoticetext

legalnoticecaption - отвечает за заголовок сообщения, например,

legalnoticetext - отвечает за содержимое сообщения, например,

Решение 2 - с помощью групповых политик

• Открыть редактор доменной групповой политики gpmc.msc, воспользовавшись комбинацией Win+R

• Создать новую групповую политики в разделе Group Policy Objects. Например, назвав, Lawer_Messege

• Открыть на редактирование созданную групповую политику и перейти в раздел Computer Configuration - Policies - Windows Settings - Security Settings - Local Policies - Security Options

• Необходимо включить и отредактировать значения двух параметров: Interactive logon: Message text for users attemping to log on и Interactive logon: Message title for users attemping to log on

Interactive logon: Message text for users attemping to log on - отвечает за заголовок сообщения, например,

Interactive logon: Message title for users attemping to log on - отвечает за содержимое сообщения, например,

• После редактирования политики, необходимо применить к определенной организационной единице в домене Active Directory или применить ко всей организации, выбрав в контекстном меню пункт Link an Existing GPO...

• Выбрать необходимую политику из уже существующих, в данном примере, созданная политика Lawer_Message

После применение политики на компьютере или сервере в редакторе реестра появится автоматическая запись с необходимыми параметрами legalnoticecaption и legalnoticetext как если бы создавалось вручную.

При ответе на почтовое сообщение в Outlook в адресной строке заменяется адрес получатель исходного сообщения. Например, сообщение полученное от user1@contoso.com при ответе на него адрес получателя заменяется на user2@fabrikam.

Почему так происходит и как это настраивается?

Понять почему так происходит можно, изучив заголовок почтового сообщения с помощью сервиса Message Header Analyser.

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

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

Чтобы при ответе на полученное сообщение подставлялся другой почтовый адрес необходимо:

1. в разделе Параметры нового сообщения на панели Ribbon нажать Настроить ответы
2. в открывшемся окне Свойств, в поле Отправить ответы заменить (по умолчанию будет указан адрес текущего пользователя) на необходимый адрес из адресной книги (Выбор имени) или вручную указать необходимый почтовый адрес
3. закрыть окно Свойств кнопкой Закрыть

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

Проблема

При запущенном ранее экземпляре Outlook под Windows, можно случайно запустить второй, третий и т.д. экземпляр приложения. После чего в трее Windows, если нажать на иконку Outlook можно увидеть несколько запущенных экземпляров приложений.

Решение

Чтобы этого избежать, необходимо в ярлыке запуска приложения Outlook добавить параметр -recycle, который предотвратит запуск нового экземпляра приложения и активирует уже ранее запущенный.

Проблема

При запуске скрипта на PowerShell появляется сообщение об ошибке

File %anypath%\any_script.ps1 cannot be loaded because running scripts is disabled on this system. For more information, see about_Execution_Policies at 
https:/go.microsoft.com/fwlink/?LinkID=135170.

Причина

Это связано с тем, что политика выполнения PowerShell установлена для предотвращения влияния ненадежных скриптов в среде Windows. Политики выполнения - это настройки безопасности, которые определяют уровень доверия для скриптов, запускаемых в PowerShell. Политика выполнения по умолчанию является «строгой», что предотвращает запуск команд и скриптов PowerShell.

Решение для “… cannot be loaded because running scripts is disabled on this system…”

Для запуска скриптов на PowerShell и устранения системной ошибке необходимо установить политику выполнения с помощью командлета Set-ExecutionPolicy, чтобы скрипт PowerShell работал на конкретном устройстве под управлением Windows. Необходмо выполнитеь следующие шаги:

Шаг 1. Проверить текущую политику выполнения

Откройте консоль PowerShell, выбрав «Выполнить от имени администратора» (или щелкните правой кнопкой мыши меню «Пуск» и выберите «Windows PowerShell (администратор)» из контекстного меню) и получите политику выполнения с помощью командлета Get-ExecutionPolicy:

PS C:\Windows\system32> Get-ExecutionPolicy
Restricted 

Получим результат текущей политики используемой в Windows на конечном устройстве. С видами политик можно ознакомиться на сайте вендора.

Шаг 2: Установить политику выполнения

Установить политику выполнения с помощью следующей команды:

Set-ExecutionPolicy RemoteSigned

Появится предупреждение о риске безопасности. Необходимо ввести «Y» или «A» при появлении запроса на продолжение. После чего проблема с запуском скрипта на PowerShell будет решена.

Дополнительно

Можно использовать, чтобы снять все ограничения политики безопасности.

Set-ExecutionPolicy Unrestricted

После того, как будет изменена политика выполнения, можно запускать скрипты без ошибки «running scripts is disabled on this system».

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

При установке той или иной политики устанавливается ключ ExecutionPolicy в ветке реестре:

HKLM\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell.

Также можно изменить политику через редактор реестра.

Параметр политики принимает следующие значения:

Restricted - Выполнения скриптов не допускаются Unrestricted - Можно запустить любой скрипт, подпись не требуется. RemoteSigned - Хорошо подходит для тестовых и сред разработки. Нужно подписать только файлы из Интернета. В противном случае будет отображено, что файл .ps1 не имееет цифровой подписью. Это настройка политики по умолчанию на серверах. Более безопасный вариант по сравнению с неограниченным. AllSigned - локальный или удаленный скрипт. Доверенный издатель должен подписать его. Разрешены только цифровые скрипты PowerShell.

Что делать, если нет возможности установить политику выполнения, запустив консоль PowerShell с правами администратора?

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

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Область по умолчанию - “LocalMachine”, которая устанавливает политику для всех пользователей текущего устройства. Можно получить политику выполнения для всех областей, используя:

PS C:\Windows\system32> Get-ExecutionPolicy -List

        Scope ExecutionPolicy
        ----- ---------------
MachinePolicy       Undefined
   UserPolicy       Undefined
      Process       Undefined
  CurrentUser       Undefined
 LocalMachine    RemoteSigned

Временный обход выполнения для сеанса

Можно обойти политику выполнения PowerShell только для одноразового сеанса, в командной строке необходимо ввести:

PowerShell -ExecutionPolicy Bypass

После закрытия окна PowerShell текущий сеанс PowerShell завершается, и обход также закрыт. Это позволяет временно запускать файл скриптов PowerShell, сохраняя при этом настройки ExecutionPolicy для всех других сеансов PowerShell.

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

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

1. Открыть редактор групповых политик.
2. В разделе «Local Computer Policy» перейти в «Computer Configuration» » Administrative Templates » Windows Components » Windows PowerShell
3. Включить политику «Turn on Script Execution», затем необходимо выбрать желаемую политику выполнения из выпадающего списка, например «Allow local scripts and remote signed scripts», что эквивалентно свойству «RemoteSigned», которое устанавливается с помощью командлета Set-ExecutionPolicy.

В завершении

Ошибка «cannot be loaded because running scripts is disabled on this system» в PowerShell возникает при первом использовании PowerShell после установки Windows, но это легко исправить, изменив политику выполнения PowerShell. Понимая принцип работы политики выполнения PowerShell и следуя данной инструкциям, можно включить выполнение скриптов PowerShell и воспользоваться всеми преимуществами автоматизации с помощью PowerShell.

Если на контроллере домена или машинах на которых установлен RSAT (Remote Server Administration Tools) не была обнаружена оснастка по управлению схемой Active Directory Schema, то необходимо зарегистрировать системную библиотеку schmmgmt.dll в командной строке:

regsvr32 schmmgmt.dll

После регистрации системной библиотеки в консоли MMC возможно выбрать оснастку Active Directory Schema.

1. Открыть MMC консоль, например, через меню Пуск -> Выполнить -> MMC (Start->Run->mmc)
2. В консоли MMC перейти в меню Файл -> добавить/удалить остастку (File->Add/Remove Snap-in)
3. Добавить оснастку Active Directory Schema

После запуска оснастки, доступны все классы схемы на редактирования.