exchange powershell запуск скрипта
Exchange powershell запуск скрипта
Вопрос
Имеется Exchange 2013 CU6. Установлен на Windows 2012 R2
Есть скрипт PS1, содержание скрипта
т.е. скрипт устанавливает политику Default для всех пользователей группы OtherUsers
Пробовал запускать так
Не удалось сохранить журнал аудита администратора для этого вызова командлета.
Организация: First Organization
Cmdlet Name: Set-CASMailbox
Object Modified: AFA.local/Users/User1
Parameter: OwaMailboxPolicy = default
Parameter: Identity = User1
Run Date: 2014-12-11T09:21:17
OriginatingServer: NM (15.00.0995.012)
в System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
в System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
в Microsoft.Exchange.SoapWebClient.EWS.ExchangeServiceBinding.GetFolder(GetFolderType GetFolder1)
в Microsoft.Exchange.Data.ApplicationLogic.EwsAuditClient.<>c__DisplayClasse. b__6()
в Microsoft.Exchange.Data.ApplicationLogic.EwsAuditClient.CallEwsWithRetries(LID lid, Func`1 delegateEwsCall, Func`3 responseMessageProcessor, Func`3 responseErrorProcessor)
в Microsoft.Exchange.Data.ApplicationLogic.EwsAuditClient.CallEwsWithRetries(LID lid, Func`1 delegateEwsCall, Func`3 responseMessageProcessor, Func`3 responseErrorProcessor)
в Microsoft.Exchange.Data.ApplicationLogic.EwsAuditClient.CheckAndCreateWellKnownFolder(DistinguishedFolderIdNameType parentFolder, DistinguishedFolderIdNameType targetFolder, FolderIdType& targetFolderId)
в Microsoft.Exchange.ProvisioningAgent.EwsAuditLogger..ctor(ExchangePrincipal principal)
в Microsoft.Exchange.ProvisioningAgent.AuditLoggerFactory.Create(ExchangePrincipal principal, ArbitrationMailboxStatus status)
в Microsoft.Exchange.ProvisioningAgent.AdminLogProvisioningHandler.WriteAuditRecord(Stopwatch stopwatch)
Подключение к серверам Exchange Server с помощью удаленной оболочки PowerShell
Если на вашем локальном компьютере не установлены средства управления Exchange, вы можете с помощью Windows PowerShell создать удаленный сеанс PowerShell на сервере Exchange Server. Эта простая процедура состоит из трех шагов: сначала вы вводите учетные данные, затем предоставляете необходимые параметры подключения, после чего импортируете командлеты Exchange в локальный сеанс Windows PowerShell, чтобы использовать их в дальнейшем.
Рекомендуем использовать командную консоль Exchange на любом компьютере, предназначенном для активного администрирования серверов Exchange Server. Командную консоль Exchange можно получить, установив средства управления Exchange. Дополнительные сведения см. в статьях Установка средств управления Exchange Server и Открытие командной консоли Exchange. Для получения дополнительных сведений о командной консоли Exchange см. статью Exchange Server PowerShell (командная консоль Exchange).
Командлет Get-ExchangeCertificate не полностью поддерживает удаленную оболочку PowerShell. Вместо этого мы рекомендуем использовать командную консоль Exchange, чтобы получить все свойства этого командлета.
Что нужно знать перед началом работы?
Предполагаемое время для завершения: менее пяти минут.
После подключения управление наличием доступа к командлетам и параметрам осуществляется путем управления доступом на основе ролей (RBAC). Дополнительные сведения см. в статье Разрешения Exchange Server.
Ниже приведены версии Windows, которые можно использовать.
Чтобы запускать сценарии, необходимо настроить Windows PowerShell. По умолчанию это приложение не настроено. При попытке подключения появится указанная ниже ошибка.
Файлы невозможно загрузить, поскольку выполнение сценариев в этой системе отключено. Предоставьте действительный сертификат для подписи файлов.
Чтобы требовать подпись надежного издателя для всех сценариев PowerShell, загружаемых из Интернета, выполните следующую команду в окне Windows PowerShell с повышенными привилегиями (окно Windows PowerShell, которое открывается с помощью параметра Запуск от имени администратора).
Дополнительные сведения о политиках выполнения см. в статье Сведения о политиках выполнения.
Возникли проблемы? Обратитесь за помощью к участникам форума Exchange Server.
Подключение к удаленному серверу Exchange
На локальном компьютере откройте Windows PowerShell и запустите следующую команду:
В открывшемся диалоговом окне Запрос учетных данных Windows PowerShell введите имя участника-пользователя (UPN) (например, chris@contoso.com ) и пароль, а затем нажмите кнопку OK.
Замените полным доменным именем сервера Exchange Server (например, mailbox01.contoso.com ) и выполните следующую команду:
Выполните следующую команду:
По завершении настройки отключите удаленный сеанс PowerShell. Если закрыть окно оболочки Windows PowerShell, не выполнив отключение сеанса, можно исчерпать лимит доступных сеансов удаленной оболочки PowerShell. Кроме того, вам придется дождаться окончания срока действия сеансов. Чтобы отключить удаленный сеанс PowerShell, выполните следующую команду.
Как убедиться, что все получилось?
После шага 3 командлеты Exchange импортируются в локальный сеанс Windows PowerShell и отображаются в индикаторе выполнения. Если при этом не возникают ошибки, подключение успешно установлено. Чтобы выполнить быструю проверку, запустите командлет Exchange (например, Get-Mailbox) и просмотрите результаты его выполнения.
Если возникают ошибки, просмотрите список возможных причин ниже.
Распространенная проблема — неправильный пароль. Еще раз повторите три описанные выше шага, уделив особое внимание первому из них, когда вводится имя пользователя и пароль.
Для учетной записи, которую вы используете для подключения к серверу Exchange Server, необходимо включить удаленный доступ к PowerShell. Дополнительные сведения см. в статье Управление удаленным доступом к PowerShell для серверов Exchange Server.
Между локальным компьютером и сервером Exchange Server необходимо открыть трафик для TCP-порта 80. Вполне вероятно, что он уже открыт, но в этом следует убедиться, если в вашей организации действует политика ограниченного доступа к сети.
См. также
В этом статье используются командлеты Windows PowerShell. Дополнительные сведения об этих командлетах см. в следующих статьях.
Подключение и управление Exchange Online с помощью PowerShell
PowerShell это основное средство администрирования как on-premises организаций Exchange Server, так и облачного Exchange Online в Microsoft 365. В этой статье мы покажем, как установить PowerShell модуль Exchange Online PowerShell v2 (EXO V2) в Windows, как подключиться к вашем тенанту Exchange Online и управлять ящиками и другими почтовыми объектами в Micrtosoft 365.
Установка модуля Exchange Online PowerShell V2 (EXO V2))
Для установки модуля Exchange Online PowerShell в Windows нужна версия PowerShell 5.x (PowerShell Core поддерживается, начиная с версии модуля ExchangeOnlineManagement 2.0.4).
Настройки политики запуска скриптов PowerShell на компьютере должны разрешать запуск локальных PS файлов:
Установите и обновите модуль PowershellGet:
Для установки модуля EXOv2 (ExchangeOnlineManagement) из галереи скриптов PowerShell для всех пользователей компьютера, выполните:
Теперь модуль можно импортировать в сессию:
Проверьте, что модуль установлен. Также отображается его версия (2.0.5 в моем случае):
Для обновления модуля EXOv2 используйте команду:
Подключение к Exchange Online с помощью PowerShell
Для подключения к вашему тенанту Microsoft 365 с помощью модуля Exchange Online, исопльзуется командлет Connect-ExchangeOnline. Например, можно указать UPN пользователя с правами глобального администратора тенанта:
Укажите пароль пользователя и подтвердите вход через MFA (удобнее всего использовать приложение Microsoft Authenticator на смартфоне).
Сформированный URL и код нужно использовать для аутентификации на другом компьютере с браузером.
Или используйте параметр –InlineCredential для интерактивного ввода пароля в консоли.
Если у вашего аккаунта есть доступ к нескольким тенантам Azure, можно указать имя с помощью параметра DelegatedOrganization:
Если для аккаунта отключен Modern Authentication, можно подключится так:
Вы можете проверить, что в системе есть активное подключение к Exchange Online так:
Get-PSSession| ft –AutoSize
В нашем примере подключение к outlook.office365.com активно (State=Opened)
После завершения работы с Exchange Online не забывайте корректно закрывать свою сессию с помощью командлета Disconnect-ExchangeOnline. Дело в том, что Exchange Online поддерживает максимум 5 одновременных PowerShell сессий. Если вы попробуете открыть шестую сессию, появится ошибка:
Следующий код можно использовать в ваших PowerShell скриптах для проверки, что подключение к Exchange Online через модуль EXOv2 уже активно. Это позволит избежать создания лишних удаленных PowerShell сессий к Microsoft 365.
Управление Exchange Online с помощью командлетов модуля ExchangeOnlineManagement
Список доступных командлетов в модуле EXO v2 можно вывести командой:
На данный момент доступно 23 командлета:
Можно вывести список ящиков в вашем тенанте Exchange или информацию о конкретном ящике:
Get-EXOMailbox |ft
Get-EXOMailbox kbuldogov
Вывести пользователей, у которых разрешен POP и IMAP доступ:
Вывести размер всех ящиков:
Размеры всех общих ящиков:
Обратите внимание, что в модуле ExchangeOnlineManagement нет, например, командлета Set-Mailbox. Дело в том, что остальные доступные командлеты Exchange Online (более 750) импортируются в вашу PowerShell сессию после подключения к тенанту. Сначала вам нужно получить имя сессии:
Get-PSSession| select ConfigurationName,CurrentModuleName
По сгенерированному имени сессии можно получить список доступных командлетов:
Т.е. чтобы изменить SMTP адрес пользователя, можно использовать команду:
Exchange Management Shell: возможно все!
Powershell как инструмент администрирования Microsoft Exchange Server впервые появился в версии продукта 2007, уже 5 лет назад. С тех пор сфера его применения в Exchange Server становится только шире, а введение Powershell remoting открыло совершенно новые возможности для администраторов.
Сисадмины осваивают этот скриптовый язык, но положение, в котором они находятся, совсем не одинаковое. Кто-то мигрирует свой сервер с 2003 на 2010 и для них Powershell — настоящий вызов. Администраторы 2007 и 2010, как минимум, открывали Exchange Management Shell (EMS) и экспериментировали с ним. Например, в таких рутинных задачах как сбор сведений о конфигурации или изменении свойств почтового ящика. Некоторые после этих попыток сбегают обратно в комфорт Exchange Management Console (EMC).
Те, кто его не используют, или используют недостаточно, лишают себя великолепной возможности исследовать и использовать на практике постоянно пополняющийся мир скриптов, выполняя на своих серверах такие задачи, которые ранее выполнить было просто невозможно.
Не секрет, что Powershell способен существенно улучшить некоторые аспекты управления серверами, заполняя белые пятна, оставленные Microsoft.
Примеров использования Powershell для выполнения крайне важных с точки зрения администрирования задач очень много –
Например, когда я ранее работал в большом американском провайдере серьезной проблемой была высокая RPC Latency на CAS серверах, возникавшая из-за проблем с определенными версиями iOS. Проверка нагрузки CAS серверов путем мониторинга числа активных подключений, определение клиента, используемого при подключении, экспорт нужной информации и компиляция html репортов – все это выполнялось на Powershell и оказывало колоссальную помощь.
Powershell, наверное, не самый простой язык. В Exchange Server 2010 SP1 – более полутысячи командлетов и на их изучение уйдет время. Несмотря на это, преимущества его использования в будущем – совершенно точно окупятся.
В статье я рассмотрю несколько ценных для системного администратора сценариев использования Exchange Management Shell. Подчеркну, что цель статьи – не осветить все (да это и невозможно!), а показать – что Powershell для нас, фанатов Microsoft Exchange Server, действительно все.
1. Создание отчетов и их экспорт
Get-Mailbox | Select-Object Name,WhenCreated | Out-File c:\xfer\report.txt
Надо сказать, что наряду с «правильным» для Powershell командлетом Out-File также действует и олдскульный –
[PS] C:\Windows\system32>Get-Mailbox | Select-Object Name,WhenCreated > c:\xfer\report.txt
2. Массовое создание пользователей из CSV файла
Еще один типичный сценарий администрирования Exchange – массовое создание пользователей из CSV файла.Может использоваться при миграции пользователей из другого окружения, при слияниях компаний или просто большом найме новых сотрудников. Для этого сценария типично использование CSV файлов. Для начала нужно подготовить CSV файл. Если администратор имеет желание облегчить себе задачу по последующему изменению атрибутов пользователей, то логично предусмотреть все заранее. При миграции или переезде пользователей с ActiveDirectory-based окружения, экспортирование нужных AD атрибутов пользователей позволит быстро их создать на новом месте, в новой ActiveDirectory.
Экспортируем через get-user, производим выборку по нужным атрибутам и передаем полученный результат в CSV файл.
Теперь у нас есть полностью готовый к последующему импорту CSV файл. В большинстве случаев хватает такого набора информации в CSV файле:
Lastname,Firstname,Name,UserPrincipalName,Password
Наш файл, готовый к импорту в ActiveDirectory, импортируем туда такой командой, меняя под себя требуемые переменные —
Import-CSV c:\xfer\our_import.csv | ForEach-Object
3. Как удалить «плохое» сообщение из всех почтовых ящиков сразу?
Когда-то в своей практике я столкнулся с интересным (и крайне срочным!) запросом пользователя, который требовал удалить из почтовых ящиков всех сотрудников организации (более 200) одно письмо с крайне чувствительной для компании информацией, которое послал на общий список рассылки уволенный ранее сотрудник.
Приведенный ниже командлет позволяет реализовать поиск по ящикам требуемого аккаунта и убрать нежелательное сообщение. В сценарии ниже для примера задана тема письма, почтовый ящик куда мы складываем «плохое» сообщение и целевая папка.
4. Проверяем размер почтовых баз
По сравнению с Exchange 2007 в последней версии Exchange сервера эта операция осуществляется существенно удобнее. Обновленный командлет Get-MailboxDatabase позволяет получить практически любую информацию.
Получаем базы с именем, сервером, статусом монтирования и размерами:
5. Почтовый клиент и почтовые ящики
Exchange 2010 позволяет оперировать клиентским доступом к почтовым ящикам на основе версии клиента Outlook и метода доступа в почтовый ящик.
Существует несколько возможностей ограничить доступ по различным критериям. Например, мы хотим не давать возможность соединения по RPC over HTTPS —
А таким мы не дадим использовать пользователям версии Outlook старее, чем 2003.
Вот так можно получить красивую информацию по почтовым ящикам с заданного аккаунта и экспортировать ее в Excel:
6. Клиентский доступ
В Exchange Management Shell имеется достаточное количество командлетов, которые системные администраторы могут использовать для траблшутинга наиболее типичных проблем, которые могут возникнуть в процессе эксплуатации продакшен среды.
При трудностях с залогиниванием в почтовый ящик на выручку придет командлет Test-MapiConnectivity, который можно использовать с различными параметрами.
Или в определенный почтовый ящик —
Test-MAPIConnectivity –Identity Vorobyaninov@RK.downtime.ru
Или на определенном сервере —
Проблемы с RPC соединениями диагностируется с использованием командлета Test-OutlookConnectivity. Главным отличием от предыдущего командлета является необходимость указания пароля тестируемого пользователя.
Поскольку серверная роль CAS в Exchange 2010 предоставляет доступ по большому количеству протоколов, то вполне естественно, что создатели Microsoft Exchange Server 2010 позаботились о том, чтобы недостатка в нужных командлетах не было:
Test-ActiveSyncConnectivity — тестирует ActiveSync протокол;
Test-CalendarConnectivity – тестирование доступности календаря;
Test-EcpConnectivity – валидация виртуальной директории ECP на выбранном CAS сервере
Test-ImapConnectivity – проверка статуса сервиса IMAP и возможности клиентского подключения по данному протоколу
Test-OutlookWebServices – проверка корректности информации, выдаваемой пользователю сервисом AutoDiscover
Test-OwaConnectivity – валидация виртуальной директории OWA на указанном CAS сервере
Test-WebServicesConnectivity – проверка Exchange Web Services, которые используются, например, Outlook for Mac, Mac Mail и еще некоторыми клиентами.
Таковы всего несколько сценариев, в которых может использоваться Exchange Management Shell, реальная работа с ним и работа с Exchange 2010 открывают двери в этот мир гораздо шире. И чем больше системный администратор узнает о нем, тем больше он опирается на него в своей повседневной работе – сложно не оценить потрясающие возможности скриптования и автоматизации операций, которые несет этот язык.
about_Scripts
Краткое описание
Описание запуска и записи скриптов в PowerShell.
Подробное описание
Выполнение сценария во многом похоже на выполнение командлета. Введите путь и имя файла скрипта и используйте параметры для отправки данных и задания параметров. Сценарии можно запускать на компьютере или в удаленном сеансе на другом компьютере.
Написание сценария сохраняет команду для последующего использования и упрощает совместное использование с другими пользователями. Что самое важное, это позволяет выполнять команды просто путем ввода пути скрипта и имени файла. Скрипты могут быть простыми как одной командой в файле, так и сложной программой.
Сценарии имеют дополнительные функции, такие как #Requires Специальный комментарий, использование параметров, поддержка разделов данных и цифровая подпись для обеспечения безопасности. Также можно написать разделы справки для скриптов и для любых функций в скрипте.
Выполнение сценария
перед запуском скрипта на Windows необходимо изменить политику выполнения PowerShell по умолчанию. политика выполнения не применяется к PowerShell, работающему на платформах, отличных от Windows.
Политика выполнения по умолчанию Restricted предотвращает выполнение всех скриптов, включая скрипты, которые вы пишете на локальном компьютере. Подробнее см. в разделе about_Execution_Policies.
Политика выполнения сохраняется в реестре, поэтому ее необходимо изменить только один раз на каждом компьютере.
Чтобы изменить политику выполнения, используйте следующую процедуру.
В командной строке введите:
Изменение вступает в силу немедленно.
Чтобы выполнить сценарий, введите полное имя файла скрипта и полный путь к нему.
Например, чтобы запустить сценарий Get-ServiceLog.ps1 в каталоге C:\Scripts, введите:
Например, чтобы запустить сценарий ServicesLog.ps1 в локальном каталоге, введите:
Если у скрипта есть параметры, введите параметры и значения параметров после имени файла скрипта.
Например, следующая команда использует параметр ServiceName скрипта Get-ServiceLog, чтобы запросить журнал действия службы удаленного управления Windows.
В качестве функции безопасности PowerShell не выполняет сценарии при двойном щелчке значка скрипта в проводнике или при вводе имени сценария без полного пути, даже если сценарий находится в текущем каталоге. Дополнительные сведения о выполнении команд и сценариев в PowerShell см. в разделе about_Command_Precedence.
Запуск с помощью PowerShell
Начиная с PowerShell 3,0 можно запускать сценарии из проводника.
Чтобы использовать функцию «Запуск с помощью PowerShell», сделайте следующее:
Запустите проводник, щелкните правой кнопкой мыши имя файла скрипта и выберите команду «запустить с помощью PowerShell».
Функция «запустить с помощью PowerShell» предназначена для выполнения скриптов, которые не имеют обязательных параметров и не возвращают выходные данные в командную строку.
Дополнительные сведения см. в разделе about_Run_With_PowerShell.
Выполнение сценариев на других компьютерах
Чтобы запустить сценарий на одном или нескольких удаленных компьютерах, используйте параметр FilePath Invoke-Command командлета.
Следующая команда запускает Get-ServiceLog.ps1 сценарий на удаленных компьютерах с именем Server01 и Server02.
Получить справку по сценариям
Командлет Get-Help получает разделы справки для скриптов, а также для командлетов и других типов команд. Чтобы получить раздел справки для скрипта, введите, Get-Help за которым следует путь и имя файла скрипта. Если путь к скрипту находится в Path переменной среды, путь можно опустить.
Например, чтобы получить справку по сценарию ServicesLog.ps1, введите:
Написание сценария
Скрипт может содержать любые допустимые команды PowerShell, в том числе отдельные команды, команды, использующие конвейер, функции и управляющие структуры, такие как операторы If и циклы for.
Следующий пример представляет собой простой сценарий, который получает службы, работающие в текущей системе, и сохраняет их в файл журнала. Имя файла журнала создается с текущей даты.
Параметры в скриптах
Чтобы определить параметры в скрипте, используйте инструкцию param. Param Инструкция должна быть первой инструкцией в скрипте, за исключением комментариев и любых #Require инструкций.
Параметры сценария работают как параметры функции. Значения параметров доступны для всех команд в скрипте. Все функции параметров функций, включая атрибут Parameter и его именованные аргументы, также допустимы в скриптах.
При выполнении скрипта пользователи заменяют параметры после имени скрипта.
Чтобы выполнить этот скрипт, введите имя параметра после имени скрипта. Пример:
Дополнительные сведения о инструкции Param и параметрах функции см. в разделе about_Functions и about_Functions_Advanced_Parameters.
Написание справки для сценариев
Раздел справки для скрипта можно написать с помощью любого из двух следующих методов.
Comment-Based справки по сценариям
Создайте раздел справки, используя специальные ключевые слова в комментариях. Чтобы создать справку на основе комментариев для сценария, необходимо поместить комментарии в начало или в конец файла скрипта. Дополнительные сведения о справке на основе комментариев см. в разделе about_Comment_Based_Help.
XML-Based справки по сценариям
Создайте раздел справки на основе XML, например тип, который обычно создается для командлетов. При преобразовании разделов справки на несколько языков требуется справка на основе XML.
Чтобы связать скрипт с разделом справки на основе XML, используйте. Ключевое слово комментария справки Екстерналхелп. Дополнительные сведения о ключевом слове Екстерналхелп см. в разделе about_Comment_Based_Help. Дополнительные сведения о справке на основе XML см. в разделе как написать справку по командлетам.
Возврат значения выхода
Область скрипта и источники с точкой
Каждый скрипт выполняется в отдельной области. Функции, переменные, псевдонимы и диски, созданные в сценарии, существуют только в области скрипта. Доступ к этим элементам или их значениям в области, в которой выполняется скрипт, невозможен.
Чтобы выполнить скрипт в другой области, можно указать область, например Global или local, или создать точку для скрипта.
Функция «с точкой» позволяет запускать скрипт в текущей области, а не в области скрипта. При запуске скрипта, который имеет точку с точкой, команды в скрипте выполняются так, будто были введены в командной строке. Функции, переменные, псевдонимы и диски, создаваемые сценарием, создаются в области, в которой выполняется работа. После выполнения скрипта можно использовать созданные элементы и получить доступ к их значениям в сеансе.
Чтобы создать точку скрипта для исходного кода, введите точку (.) и пробел перед путем к сценарию.
или диспетчер конфигурации служб
После UtilityFunctions.ps1 выполнения скрипта функции и переменные, создаваемые сценарием, добавляются в текущую область.
Дополнительные сведения об области действия см. в разделе about_Scopes.
Скрипты в модулях
Модуль — это набор связанных ресурсов PowerShell, которые можно распространять как единое целое. Вы можете использовать модули для организации скриптов, функций и других ресурсов. Можно также использовать модули для распространения кода среди других пользователей и получения кода из надежных источников.
Можно включить скрипты в модули или создать модуль скрипта, который представляет собой модуль, полностью или в основном содержащий скрипт и вспомогательные ресурсы. Модуль скрипта — это просто сценарий с расширением файла PSM1.
Дополнительные сведения о модулях см. в разделе about_Modules.
Другие функции сценариев
В PowerShell есть много полезных функций, которые можно использовать в скриптах.
#Requires — Можно использовать #Requires инструкцию, чтобы предотвратить выполнение скрипта без указанных модулей или оснасток и заданную версию PowerShell. Дополнительные сведения см. в разделе about_Requires.
$PSCommandPath — Содержит полный путь и имя выполняемого скрипта. Этот параметр допустим во всех скриптах. Эта автоматическая переменная появилась в PowerShell 3,0.
Пскоммандпас содержит полный путь и имя скрипта, который вызывал или вызывает текущий скрипт.
PSScriptRoot содержит каталог скрипта, вызвавшего или вызвавшего текущий скрипт.
Разделы данных. Вы можете использовать Data ключевое слово для разделения данных из логики в скриптах. Разделы данных также могут упростить локализацию. Дополнительные сведения см. в разделе about_Data_Sections и about_Script_Internationalization.
Подпись скрипта. Вы можете добавить цифровую подпись к сценарию. В зависимости от политики выполнения можно использовать цифровые подписи для ограничения выполнения скриптов, которые могут включать ненадежные команды. Дополнительные сведения см. в разделе about_Execution_Policies и about_Signing.