about_PowerShell_Config
簡単な説明
レジストリ構成を置き換える PowerShell の構成ファイル。
詳細な説明
この powershell.config.json
ファイルには、PowerShell の構成設定が含まれています。 PowerShell は起動時にこの構成を読み込みます。 設定は実行時に変更することもできます。 以前は、これらの設定は PowerShell 用 Windows レジストリに格納されていましたが、macOS と Linux で構成を有効にするファイルに含まれるようになりました。
設定の概要
ファイルには powershell.config.json
、次のキーを含めることができます。
DisableImplicitWinCompat
WindowsPowerShellCompatibilityModuleDenyList
WindowsPowerShellCompatibilityNoClobberModuleList
ExperimentalFeatures
LogChannels
LogIdentity
LogKeywords
LogLevel
Microsoft.PowerShell:ExecutionPolicy
PSModulePath
PowerShellPolicies
ExecutionPolicy
ConsoleSessionConfiguration
ModuleLogging
ProtectedEventLogging
ScriptBlockLogging
ScriptExecution
Transcription
UpdatableHelp
すべてのキーがすべてのプラットフォームに適用されるわけではありません。 キーPowerShellPolicies
には、ウィンドウ グループ ポリシーによって管理される設定をミラーするサブキーが含まれています。 これらのサブキーは、JSON ファイルのルート レベルで定義されている場合、すべてのプラットフォームにも適用されます。
警告
構成ファイル内の認識されないキーまたは無効な値は無視されます。 ファイルに powershell.config.json
無効な JSON が含まれている場合、PowerShell は対話型セッションを開始できません。 この場合は、構成ファイルを修正する必要があります。
構成スコープ
構成設定は、すべてのユーザーまたは個々のユーザー レベルで定義できます。
AllUsers (共有) の構成
powershell.config.json
ディレクトリ内のファイルは、$PSHOME
その PowerShell インストールから実行されているすべての PowerShell セッションの構成を定義します。
Note
場所は $PSHOME
、実行中のSystem.Management.Automation.dll アセンブリと同じディレクトリとして定義されます。 これは、ホストされている PowerShell SDK インスタンスにも適用されます。
CurrentUser (ユーザー単位) の構成
ユーザー スコープ構成ディレクトリにファイルを配置することで、ユーザーごとに PowerShell を構成することもできます。 ユーザー構成ディレクトリは、コマンド Split-Path $PROFILE.CurrentUserCurrentHost
を使用してプラットフォーム間で見つけることができます。
スコープの優先順位
Windows では、Windows グループ ポリシーによって管理される設定が、構成ファイルの設定よりも優先されます。 グループ ポリシーは、Windows 以外のプラットフォームには存在しません。
グループ ポリシーの後、AllUsers レベルで定義された設定は、CurrentUser レベルで定義されている設定よりも優先されます。
Windows 固有の設定
次の設定は、Windows プラットフォームにのみ適用されます。
DisableImplicitWinCompat
WindowsPowerShellCompatibilityModuleDenyList
WindowsPowerShellCompatibilityNoClobberModuleList
ExecutionPolicy
PowerShellPolicies
DisableImplicitWinCompat
この設定に true
設定すると、Windows PowerShell 互換性機能が無効になります。 Windows PowerShell 互換性により、PowerShell 7 は互換性モードで Windows PowerShell 5.1 モジュールを読み込むことができます。
詳細については、「about_Windows_PowerShell_Compatibility」を参照してください。
WindowsPowerShellCompatibilityModuleDenyList
この設定は、Windows PowerShell 互換性機能への参加から除外するモジュール名の配列です。
詳細については、「about_Windows_PowerShell_Compatibility」を参照してください。
WindowsPowerShellCompatibilityNoClobberModuleList
この設定はモジュール名の配列であり、Windows PowerShell 5.1 バージョンのモジュールを読み込んでは使用できません。
詳細については、「about_Windows_PowerShell_Compatibility」を参照してください。
ExecutionPolicy
重要
この構成は、Windows プラットフォームでのみ適用されます。
PowerShell セッションの実行ポリシーを構成し、実行できるスクリプトを決定します。 既定では、PowerShell は既存の実行ポリシーを使用します。
AllUsers 構成の場合、LocalMachine 実行ポリシーが設定されます。 CurrentUser 構成の場合、CurrentUser 実行ポリシーが設定されます。
次の例では、PowerShell の実行ポリシーを RemoteSigned
.
{
"Microsoft.PowerShell:ExecutionPolicy": "RemoteSigned"
}
詳細については、「about_Execution_Policies」を参照してください。
PowerShellPolicies
Windows には、グループ ポリシーで管理できるいくつかの設定があります。 通常、これらの設定は Windows レジストリに格納されます。 これらの設定は、ファイル内で powershell.config.json
定義することもできます。
これは PowerShellPolicies
、さまざまなポリシー設定のキーと値のペアを含む JSON オブジェクトです。 これらのポリシー設定は、オブジェクトの外部 PowerShellPolicies
にある JSON ファイルのルート レベルで一覧表示することもできます。 この設定には、次のサブキーを含めることができます。
ConsoleSessionConfiguration
ModuleLogging
ProtectedEventLogging
ScriptBlockLogging
ScriptExecution
Transcription
UpdatableHelp
この ScriptExecution
設定は、PowerShell 実行ポリシーを設定するために使用されます。
これは、上記の ExecutionPolicy
設定よりも優先されます。
例:
{
"PowerShellPolicies": {
"ScriptExecution": {
"ExecutionPolicy": "RemoteSigned"
}
}
}
その他のポリシー設定の説明については、「共通構成設定」セクションの説明を参照してください。
Windows では、PowerShell はレジストリ内の設定を検索します。 レジストリで見つかったすべての設定が優先されます。 次に、PowerShell は JSON 構成を読み取ります。 レジストリで定義されていない設定 PowerShellPolicies
は、JSON 構成のルート レベルで見つかった設定よりも優先されます。
詳細については、「about_Group_Policy_Settings」をご覧ください。
Windows 以外のプラットフォームの設定
次の設定は、Linux および macOS プラットフォームにのみ適用されます。
Linux および macOS 用に PowerShell のログ記録を構成するには、次のキーを使用します。
LogChannels
LogIdentity
LogKeywords
LogLevel
Windows 以外のシステムの PowerShell ログの詳細については、「about_Logging_Non-Windows」を参照してください。
一般的な構成設定
次の設定は、サポートされているすべてのプラットフォームで使用できます。
ConsoleSessionConfiguration
ExperimentalFeatures
ModuleLogging
ProtectedEventLogging
PSModulePath
ScriptBlockLogging
ScriptExecution
Transcription
UpdatableHelp
ConsoleSessionConfiguration
この設定では、すべての PowerShell セッションに使用するセッション構成を指定します。 既定の PowerShell リモート処理エンドポイントや、特定のユーザー ロール機能を持つカスタム エンドポイントなど、ローカル コンピューターに登録されている任意のエンドポイントを指定できます。
このキーには、次の 2 つのサブキーが含まれています。
EnableConsoleSessionConfiguration
- セッション構成を有効にするには、値を 〘 に設定しますtrue
。 この値の既定値はfalse
です。ConsoleSessionConfigurationName
- PowerShell を実行する構成エンドポイントの名前を指定します。 既定では、セッションは定義されていません。
{
"ConsoleSessionConfiguration": {
"EnableConsoleSessionConfiguration": false,
"ConsoleSessionConfigurationName" : []
}
}
詳細については、「about_Session_Configurations」を参照してください。
ExperimentalFeatures
PowerShell で有効にする実験用機能の名前。 既定値は空の配列です。
次の例では、PowerShell の起動時に PSCommandNotFoundSuggestion および PSSubsystemPluginModel の試験的機能を有効にします。
例:
{
"ExperimentalFeatures": [
"PSCommandNotFoundSuggestion",
"PSSubsystemPluginModel"
]
}
試験的特徴の詳細については、「試験的特徴の使用」を参照してください。
ModuleLogging
この設定は、PowerShell モジュールのログ記録の動作を制御します。 この設定には、次の 2 つのサブキーが含まれています。
EnableModuleLogging
- セッション構成を有効にするには、値を 〘 に設定しますtrue
。 有効にすると、指定したモジュールのメンバーのパイプライン実行イベントが PowerShell ログ ファイルに記録されます。ModuleNames
- ログに記録するモジュールの名前を指定します。
例:
{
"ModuleLogging": {
"EnableModuleLogging": true,
"ModuleNames" : [
"PSReadLine",
"PowerShellGet"
]
}
}
ProtectedEventLogging
この設定では、保護されたイベント ログを構成できます。 この設定には、次の 2 つのサブキーが含まれています。
EnableProtectedEventLogging
- このポリシー設定を有効にした場合、それをサポートするコンポーネントは、指定した証明書を使用してログ データを暗号化してからログに書き込みます。 データは、暗号化メッセージ構文 (CMS) 標準を使用して暗号化されます。 証明書の秘密キーにアクセスできる場合は、これらの暗号化されたメッセージの暗号化を解除するために使用Unprotect-CmsMessage
できます。EncryptionCertificate
- 暗号化に使用する証明書の名前の一覧を提供します。
例:
{
"ProtectedEventLogging": {
"EnableProtectedEventLogging": false,
"EncryptionCertificate": [
"Joe"
]
}
}
PSModulePath
この PowerShell セッションの PSModulePath
設定をオーバーライドします。 現在のユーザーの構成の場合は、CurrentUser モジュールパスを設定します。 構成がすべてのユーザーに対する場合は、AllUsers モジュールパスを設定します。
警告
ここで AllUsers または CurrentUser モジュール パスを構成しても、Install-Module などの PowerShellGet コマンドレットのスコープ付きインストール場所は変更されません。 これらのコマンドレットでは、常に既定のモジュール パスが使用されます。
値が設定されていない場合、PowerShell では、それぞれのモジュール パス設定に既定値が使用されます。 これらの既定値の詳細については、「about_PSModulePath」を参照してください。
この設定では、Windows コマンド シェルで許可されているのと同じ方法で、"%HOME%\Documents\PowerShell\Modules"
環境変数を文字間%
に埋め込むことで使用できます。 この構文は、Linux および macOS にも適用されます。 次の例を参照してください。
この例では、 PSModulePath
Windows 環境の構成を示します。
{
"PSModulePath": "C:\\Program Files\\PowerShell\\6\\Modules"
}
この例では、 PSModulePath
macOS または Linux 環境の構成を示します。
{
"PSModulePath": "/opt/powershell/6/Modules"
}
この例では、環境変数を構成に埋め込む方法を PSModulePath
示します。 環境変数とディレクトリ区切り記号をHOME
/
使用すると、この構文は Windows、macOS、Linux で動作します。
{
"PSModulePath": "%HOME%/Documents/PowerShell/Modules"
}
この例では、macOS と Linux でのみ動作する環境変数を使用します。
{
"PSModulePath": "%XDG_CONFIG_HOME%/powershell/Modules"
}
Note
PowerShell 変数を構成に PSModulePath
埋め込むことはありません。
PSModulePath
Linux および macOS の構成では、大文字と小文字が区別されます。 構成では、 PSModulePath
プラットフォームに対して有効なディレクトリ区切り記号を使用する必要があります。 macOS と Linux では、これは /
意味します。 Windows では、両方 /
とも \
動作します。
ScriptBlockLogging
この設定では、すべての PowerShell スクリプト入力のログ記録を制御します。 この設定には、次の 2 つのサブキーが含まれています。
EnableScriptBlockLogging
- このポリシー設定を有効にした場合、PowerShell は、対話形式で呼び出された場合でも、自動化を介して呼び出された場合でも、コマンド、スクリプト ブロック、関数、スクリプトの処理をログに記録します。EnableScriptBlockInvocationLogging
- スクリプト ブロックの開始イベントと停止イベントのログ記録を有効にします。
例:
"ScriptBlockLogging": {
"EnableScriptBlockInvocationLogging": true,
"EnableScriptBlockLogging": false
}
文字起こし
このポリシー設定では、テキスト ベースのトランスクリプトで PowerShell コマンドの入力と出力をキャプチャできます。 このポリシー設定を有効にした場合、PowerShell はすべての PowerShell セッションで文字起こしを有効にします。
この設定は、PowerShell での文字起こしのしくみを制御します。 この設定には、次の 3 つのサブキーが含まれています。
EnableTranscripting
- この設定を有効にすると、PowerShell によって、構成された場所に文字起こしログ ファイルが作成されます。EnableInvocationHeader
- 既定では、PowerShell には文字起こしログ ファイルの先頭にヘッダーが含まれています。 この設定を使用して、ヘッダーを無効にすることができます。OutputDirectory
- この設定を使用すると、既定の場所ではなく中央の場所に文字起こしログ ファイルを収集できます。
例:
{
"Transcription": {
"EnableTranscripting": true,
"EnableInvocationHeader": true,
"OutputDirectory": "c:\\tmp"
}
}
詳細については、「開始-トランスクリプト」を参照してください。
UpdatableHelp
このポリシー設定では、コマンドレットの SourcePath パラメーターの既定値をUpdate-Help
設定できます。 この既定値は、SourcePath パラメーターを使用して別の値を指定することでオーバーライドできます。
例:
{
"UpdatableHelp": {
"DefaultSourcePath": "f:\\temp"
}
}
PowerShell
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示