Возможности профилей

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

Интерпретатор команд определяет следующие четыре различных профиля.

• Профиль, применяющийся ко всем интерпретаторам команд и пользователям компьютера.
• Профиль, применяющийся ко всем пользователям и только к интерпретатору команд Microsoft PowerShell.
• Профиль, применяющийся к текущему пользователю и ко всем интерпретаторам команд.
• Профиль, применяющийся к текущему пользователю и только к интерпретатору команд Microsoft PowerShell.

Концепция «все интерпретаторы команд» может показаться немного запутанной. Терминология восходит к определенным ранним концепциям разработки Windows PowerShell, которые в действительности не связаны с окончательными продуктами. Сегодня более подходящим будет термин «все размещения».

Интерпретаторы команд, размещения и профили

Как вы видите, Windows PowerShell, по сути, — это набор сборок Microsoft .NET Framework. Эту часть интерпретатора команд я называю механизмом Windows PowerShell, поскольку она содержит функциональные возможности, которые, как правило, и рассматривают как Windows PowerShell. Хотя для пользователей отсутствует встроенный способ взаимодействия с этим механизмом. Для использования интерпретатора команд механизм должен быть загружен размещающим приложением (или размещением).

Одним из таких размещений является приложение powershell.exe, с которым вы, вероятно, привыкли работать. Другим узлом является приложение gpowershell.exe, включенное в версию CTP Windows PowerShell 2.0. Это взаимоотношение между размещениями и интепретаторами команд не настолько простое, как мое описание, но мое упрощенное объяснение охватывает поведение, которое вы видите.

Важно понимать, что при взаимодействии с интерпретатором команд через текстовый интерфейс командной строки, вероятно, используется размещение powershell.exe. Это относится даже к случаям запуска интерпретатора команд с помощью ярлыка, установленного другим приложением, например, командной консолью Exchange. Командная консоль Exchange — это не другой интерпретатор команд или приложение размещения. Скорее это обычное размещение powershell.exe, запущенное с помощью ярлыка, определяющего набор оснасток и сценариев для предварительной загрузки. Эти оснастки обеспечивают работу функциональности управления Exchange в интерпретаторе команд. Но по-прежнему используется этот же интерпретатор команд.

Профили для размещения powershell.exe (в Windows Vista) размещаются в следующих местах:

• %windir%\system32\WindowsPowerShell\v1.0\profile.ps1 Это профиль для всех пользователей компьютера и для всех интерпретаторов команд.
• %windir%\system32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1 Это профиль для всех пользователей компьютера, но только для интерпретатора команд Microsoft.PowerShell.
• %UserProfile%\Documents\WindowsPowerShell\profile.ps1 Это профиль только для текущего пользователя и для всех интерпретаторов команд.
• %UserProfile%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 Это профиль только для текущего пользователя и только для интерпретатора команд Microsoft.PowerShell.

Эти профили не созданы по умолчанию. Они существуют, только если вы создали их.

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

Самый простой способ отследить все это — открыть интерпретатор команд, ввести $profile и нажать клавишу «Ввод». Будет выведен полный путь, который интерпретатор команд пытается использовать в качестве, как я полагаю, «основного» профиля (профиль интерпретатора команд для определенного пользователя). Затем можно создать или изменить этот сценарий, и он будет выполняться при каждом запуске интерпретатора команд.

Использование профиля

Одним из наиболее распространенных способов использования профиля является определение пользовательских псевдонимов, как я предложил ранее. Или можно добавить пользовательские накопители PSDrive (по сути, это подключенные диски, существующие только в Windows PowerShell). Менее распространенным способом является создание определенного рода административного интерпретатора команд для выполнения всех необходимых задач управления на основе используемых в среде программных продуктов. Для объяснения концепции административного интерпретатора команд сначала необходимо предоставить определенные базовые сведения.

Группа разработки корпорации Майкрософт, занимающаяся созданием Windows PowerShell, отвечает за множество других основных технологий управления, включая консоль управления Microsoft (MMC). Консоль MMC представляет хороший аналог работы Windows PowerShell. При запуске mmc.exe открывается пустая консоль, что недостаточно хорошо. Для создания функциональной консоли добавляются оснастки MMC.

После настройки консоли нужным образом она сохраняется в файле с расширением MSC. Этот сохраненный файл консоли позволяет в любое время быстро перезагрузить пользовательскую консоль.

Вместо создания пользовательских консолей MMC множество администраторов просто полагаются на консоли, установленные вместе с управляемыми ими продуктами. Например, Exchange Server создает консоль, содержащую только оснастку Exchange Server. «Пользователи и компьютеры Active Directory» — другая предварительно созданная консоль с одной оснасткой.

Windows PowerShell работает почти аналогичным образом. Значок командной консоли Exchange, установленный вместе со средствами управления Exchange Server 2007, в действительности является ярлыком для powershell.exe с инструкциями на загрузку файла консоли. Файлы консоли интерпретатора команд имеют расширения .psc1 и содержат список оснасток для предварительной загрузки (так же, как файл MSC содержит список оснасток, предварительно загружаемых MMC). Однако вы не ограничены использованием этих предварительно созданных консолей интерпретатора команд. Можно создать пользовательскую консоль так же, как и при использовании консоли MMC, и использовать ее для выполнения всех задач управления. Профили играют ключевую роль в обеспечении этой возможности.

Создание пользовательской консоли

Создание пользовательской консоли следует начать с поиска полных имен всех оснасток, с которыми необходимо работать. Убедитесь, что на компьютере установлены все необходимые средства управления. Затем в Windows PowerShell выполните команду Get-PSSnapin –registered. Будет выведен список всех зарегистрированных, но пока не загруженных оснасток. После этого создайте или отредактируйте соответствующий профиль Windows PowerShell. Добавьте команды Add-PSSnapin для загрузки всех оснасток, которые должны быть всегда доступны. В их число могут входить оснастки для Exchange Server, продуктов System Center, и оснастки сторонних производителей, например, PowerShell Community Extensions. Затем сохраните профиль (не забудьте создать цифровую подпись для профиля, если это требуется политикой выполнения Windows PowerShell) и закройте интерпретатор команд. Снова откройте интерпретатор команд, и он автоматически загрузит все указанные в профиле оснастки.

Другой способ заключается в загрузке всех оснасток в интерпретатор команд (используя Add-PSSnapin и имена оснасток) и последующем выполнении команды Export-Console для создания файла консоли .psc1, содержащего все используемые в настоящий момент оснастки. Затем можно использовать этот файл консоли .psc1 для создания нового ярлыка Windows PowerShell, в котором указывается параметр PSConsoleFile и пользовательский файл .psc1. После ярлык будет использовать консоль, автоматически загружая все указанные оснастки.

Другие приемы работы с профилями

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

1. Я выполняю Get-Credential для моей учетной записи администратора домена, сохраняя результаты в переменной с именем $cred. Это делает переменную $cred доступной в интерпретаторе команд. Затем я могу передать ее параметру –credential различные командлеты, например, Get-WmiObject. Поскольку в переменной $cred сохраняется пароль, я могу использовать эти командлеты без появления запроса на ввод пароля.
2. Я выполняю команду Cd C:\, чтобы интерпретатор команд был запущена в корневом каталоге диска C: компьютера.
3. Я выполняю New-Alias в командлете Out-File для создания псевдонима с именем «of». Благодаря этому можно использовать «of» вместо «Out-File». Я часто использую этот псевдоним, так что наличие определенного краткого псевдонима очень удобно.

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

Я определяю пользовательскую функцию с именем Ping-Address, принимающую имя компьютера или IP-адрес и возвращающую значение True или False в зависимости от того, отвечает ли компьютер на команду ping. Я часто использую эту функцию в работе, поэтому ее определение в моем профиле делает ее глобально доступной в интерпретаторе команд.

Командлет месяца: Get-WmiObject

Проницательный наблюдатель может заметить, что этот командлет уже рассматривался ранее, но я хочу продемонстрировать предоставляемую им полезную уловку. Я часто вижу, как администраторы пытаются получить информацию инструментария управления Windows (WMI) от нескольких компьютеров, имена которых указаны в текстовом файле, с помощью следующего метода:

Get-Content c:\computers.txt | ForEach-Object 
  { Get-WmiObject Win32_Service –comp $_ }

Хотя этот способ успешно работает, в действительности он не требуется, поскольку Get-WmiObject может принимать массив имен компьютеров для параметра –computerName. Для достижения аналогичного эффекта можно использовать следующее:

Get-WmiObject Win32_Service –comp (Get-Content
  c:\computers.txt)

Заключение команды Get-Content в скобки вызывает выполнение интерпретатором команды и размещение результата, массива имен компьютеров, в параметре –computerName.

Будьте внимательные при работе с профилями!

Помните, что powershell.exe — это не единственное приложение, загружающее профили Microsoft.PowerShell или профили всех интерпретаторов команд. Множество интегрированных сред разработки (IDE), предоставляющих поддержку Windows PowerShell, включая PrimalScript компании SAPIEN Technologies, PowerGUI компании Quest Software и PowerShell Plus компании ShellTools, также загружают эти же профили для предоставления возможностей, аналогичных предоставляемым размещением powershell.exe.

Большой профиль, загружающий множество оснасток, может привести к снижению скорости запуска приложений из-за наличия множества команд для механизма Windows PowerShell, которые должны выполняться для обеспечения возможности размещения приложения. Более того, даже powershell.exe может загружаться долго, если должен быть выполнен очень большой сценарий профиля.

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

Профили Windows PowerShell могут значительно повышать удобство использования интерпретатора команд. Но необходимо помнить, что при злоумышленном изменении профилей вредоносным кодом они также могут причинить значительный ущерб. Можно защитить профили путем использования цифровой подписи и настройки Windows PowerShell на использование политики выполнения AllSigned или путем изменения разрешений для файлов NTFS всех ваших профилей, чтобы они не могли быть изменены учетными записями обычных пользователей.