Azure Automation でモジュールを管理する

[アーティクル]
10/01/2024

Note

2025 年 2 月 1 日以降、Azure Automation は、AzureRM モジュールを使用するすべての Runbook の実行を "停止" します。 2024 年 11 月 1 日以降、AzureRM モジュールを使用して新しい Runbook を作成することはできません。 AzureRM PowerShell モジュールは、2024 年 2 月 29 日の時点で正式に非推奨になりました。サポートと更新情報が継続されるように、AzureRM モジュールから Az PowerShell モジュールに移行することをお勧めします。 AzureRM モジュールは引き続き機能しますが、保守やサポートはされなくなり、AzureRM の使用継続はユーザー自身の責任になります。詳細については、移行リソースで Az モジュールへの移行に関するガイダンスを参照してください。

Azure Automation では、複数の PowerShell モジュールを使用して、Runbook と DSC 構成の DSC リソースでコマンドレットを有効にすることができます。サポートされているモジュールは次のとおりです。

Azure PowerShell Az.Automation。
Azure PowerShell AzureRM.Automation。
その他の PowerShell モジュール。
内部の Orchestrator.AssetManagement.Cmdlets モジュール。
Python 2 モジュール。
作成したカスタムモジュール。

Automation アカウントを作成すると、Azure Automation は既定で一部のモジュールをインポートします。「既定のモジュール」を参照してください。

重要

新しいランタイム環境エクスペリエンスでジョブ実行環境を構成できるようにすると、モジュールとパッケージを管理できます。新しいエクスペリエンスでは、[モジュール] と [パッケージ] のブレードは使用できません。モジュールとパッケージを管理するには、「ランタイム環境と関連する Runbook を管理する」を参照してください。

サンドボックス

Automation が Runbook と DSC コンパイルジョブを実行すると、モジュールがサンドボックスに読み込まれ、そこで Runbook を実行し、DSC 構成をコンパイルできるようになります。また、Automation は、DSC リソースを自動的に DSC プルサーバー上のモジュールに配置します。マシンは、DSC 構成を適用するときに、そのリソースをプルできます。

クラウドサンドボックスでは、最大 48 のシステム呼び出しがサポートされ、他のすべての呼び出しはセキュリティ上の理由で制限されます。資格情報の管理や一部のネットワークなどのその他の機能は、クラウドサンドボックスではサポートされません。

含まれるモジュールとコマンドレットの数が多いため、サポートされていない呼び出しを行うコマンドレットを事前に把握することは困難です。一般的に、コマンドレットのうち、昇格されたアクセス権を必要とするもの、パラメーターとして資格情報を必要とするもの、ネットワークに関連するものには問題が見られます。 AIPService PowerShell モジュールの Connect-AipService や DNSClient モジュールの Resolve-DnsName など、フルスタックのネットワーク操作を実行するコマンドレットは、サンドボックスではサポートされません。

これらは、サンドボックスに関する既知の制限事項です。推奨される対処法は、Hybrid Runbook Worker をデプロイすること、または Azure Functions を使用することです。

重要

Az モジュールを使用して実行するように設計されたスクリプトには、キーワード "AzureRm" を含めないでください。たとえコメントであっても、このキーワードを含めると、AzureRm が読み込まれ、Az モジュールと競合する可能性があります。

既定のモジュール

新しい Automation アカウントにはすべて、最新バージョンの PowerShell Az モジュールが既定でインポートされています。 Az モジュールは AzureRM の置き換えであり、Azure で使用するための推奨されるモジュールです。新しい Automation アカウントの既定のモジュールには、既存の 24 の AzureRM モジュールと 60 以上の Az モジュールが含まれています。

Automation アカウントのユーザーがモジュールを最新の Az モジュールに更新するためのネイティブオプションがあります。この操作では、すべてのモジュール依存関係をバックエンドで処理するため、モジュールを手動で更新したり、Runbook を実行して Azure モジュールを更新したりする手間が省けます。

既存の Automation アカウントに AzureRM モジュールしかない場合は、[Az モジュールの更新] オプションにより、ユーザーが選択したバージョンの Az モジュールで Automation アカウントが更新されます。

既存の Automation アカウントに AzureRM と一部の Az モジュールがある場合は、そのオプションにより、残りの Az モジュールがその Automation アカウントにインポートされます。既存の Az モジュールが優先されるため、更新操作でこれらのモジュールは更新されません。これは、Runbook によって使用されているモジュールを誤って更新することで、モジュールの更新操作が Runbook の実行エラーを発生させることがないようにするためです。このシナリオで推奨される方法は、まず既存の Az モジュールを削除し、その後に更新操作を実行して、最新の Az モジュールが Automation アカウントにインポートされるようにすることです。既定ではインポートされない、このようなモジュールの種類は [カスタム] と呼ばれます。 [カスタム] モジュールは、常に既定のモジュールより優先されます。

例: Az モジュール 6.3.0 によって提供されるバージョン 2.3.0 でインポートされた Az.Aks モジュールが既にあり、Az モジュールを最新の 6.4.0 バージョンに更新しようとしているとします。更新操作では、Az.Aks を除き、すべての Az モジュールが 6.4.0 パッケージからインポートされます。最新バージョンの Az.Aks を使用するには、まず既存のモジュールを削除し、その後に更新操作を実行します。あるいは、「Az モジュールをインポートする」の説明に従って、このモジュールを個別に更新して、別のバージョンの特定のモジュールをインポートすることもできます。

次の表は、Automation アカウントを作成したときに Azure Automation によって既定でインポートされるモジュールの一覧を示しています。 Automation を使用してこれらのモジュールの新しいバージョンをインポートできます。ただし、新しいバージョンを削除した場合でも、Automation アカウントから元のバージョンを削除することはできません。

既定のモジュールは、グローバルモジュールとも呼ばれます。 Azure portal で、アカウントが作成されたときにインポートされたモジュールを表示すると、[グローバルモジュール] プロパティが true になります。

Azure portal のグローバルモジュールプロパティのスクリーンショット

Note

Start/Stop VMs during off-hours のデプロイに使用される Automation アカウントでモジュールおよび Runbook を変更することはお勧めしません

モジュール名	Version
Az.*	PowerShell ギャラリーの [パッケージの詳細] にある完全な一覧を参照
AuditPolicyDsc	1.1.0.0
Azure	1.0.3
Azure.Storage	1.0.3
AzureRM.Automation	1.0.3
AzureRM.Compute	1.2.1
AzureRM.Profile	1.0.3
AzureRM.Resources	1.0.3
AzureRM.Sql	1.0.3
AzureRM.Storage	1.0.3
ComputerManagementDsc	5.0.0.0
GPRegistryPolicyParser	0.2
Microsoft.PowerShell.Core	0
Microsoft.PowerShell.Diagnostics
Microsoft.PowerShell.Management
Microsoft.PowerShell.Security
Microsoft.PowerShell.Utility
Microsoft.WSMan.Management
Orchestrator.AssetManagement.Cmdlets	1
PSDscResources	2.9.0.0
SecurityPolicyDsc	2.1.0.0
StateConfigCompositeResources	1
xDSCDomainjoin	1.1
xPowerShellExecutionPolicy	1.1.0.0
xRemoteDesktopAdmin	1.1.0.0

内部コマンドレット

Azure Automation では、Azure サンドボックス環境内または Windows Hybrid Runbook Worker 上で Runbook を実行する場合にのみ利用可能な内部コマンドレットがサポートされています。内部モジュール Orchestrator.AssetManagement.Cmdlets は、Windows Hybrid Runbook Worker ロールがマシンにインストールされるときに、既定で Automation アカウントにインストールされます。

次の表では、内部コマンドレットを定義しています。これらのコマンドレットは、Automation アカウントリソースを操作するために Azure PowerShell コマンドレットの代わりに使用するように設計されています。それらは、暗号化された変数、資格情報、および暗号化された接続からシークレットを取得できます。

名前	説明
Get-AutomationCertificate	`Get-AutomationCertificate [-Name] <string> [<CommonParameters>]`
Get-AutomationConnection	`Get-AutomationConnection [-Name] <string> [-DoNotDecrypt] [<CommonParameters>]`
Get-AutomationPSCredential	`Get-AutomationPSCredential [-Name] <string> [<CommonParameters>]`
Get-AutomationVariable	`Get-AutomationVariable [-Name] <string> [-DoNotDecrypt] [<CommonParameters>]`
Set-AutomationVariable	`Set-AutomationVariable [-Name] <string> -Value <Object> [<CommonParameters>]`
Start-AutomationRunbook	`Start-AutomationRunbook [-Name] <string> [-Parameters <IDictionary>] [-RunOn <string>] [-JobId <guid>] [<CommonParameters>]`
Wait-AutomationJob	`Wait-AutomationJob -Id <guid[]> [-TimeoutInMinutes <int>] [-DelayInSeconds <int>] [-OutputJobsTransitionedToRunning] [<CommonParameters>]`

内部コマンドレットの名前付けは、Az および AzureRM コマンドレットの場合と異なることに注意してください。内部コマンドレット名には、名詞に Azure や Az などの単語は含まれませんが、Automation という語が使用されます。 Azure サンドボックスまたは Windows Hybrid Runbook Worker では、Runbook の実行中に Az または AzureRM コマンドレットの代わりにこれらを使用することをお勧めします。これは、必要なパラメーターが減り、実行中にジョブのコンテキストで実行されるためです。

Runbook のコンテキスト外で Automation リソースを操作する場合には Az または AzureRM コマンドレットの使用してください。

Python モジュール

Azure Automation では、Python 2 Runbook を作成できます。 Python モジュールについては、「Azure Automation で Python 2 パッケージを管理する」を参照してください。

カスタムモジュール

Azure Automation は、Runbook と DSC 構成で使用するために作成するカスタム PowerShell モジュールをサポートしています。カスタムモジュールの 1 つの種類は、必要に応じて、モジュールコマンドレットのカスタム機能を定義するメタデータのファイルを含む統合モジュールです。統合モジュールの使用例については、「接続の種類の追加」を参照してください。

Azure Automation は、カスタムモジュールをインポートしてそのコマンドレットを利用可能にすることができます。バックグラウンドでは、他のモジュールと同じように、モジュールを格納し、Azure サンドボックスで使用します。

Az モジュールへの移行

このセクションでは、Automation で Az モジュールに移行する方法について説明します。詳細については、Azure PowerShell を AzureRM から Az に移行するを参照してください。

AzureRM モジュールと Az モジュールを同じ Automation アカウントで実行することはお勧めできません。 AzureRM から Az に移行することが確実である場合は、完全な移行を完全にコミットすることをお勧めします。 Automation では、多くの場合、起動時間を節約するために Automation アカウントのサンドボックスが再利用されます。モジュールの完全な移行を行っていない場合、AzureRM モジュールのみを使用するジョブを開始し、次に Az モジュールのみを使用する別のジョブを開始することになります。サンドボックスは間もなくクラッシュし、モジュールに互換性がないことを示すエラーが返されます。このような状況では、特定の Runbook または構成ではクラッシュがランダムに発生します。

Note

新しい Automation アカウントを作成すると、Az モジュールへの移行後でも、Automation によって引き続き AzureRM モジュールが既定でインストールされます。

モジュールを移行する前に Runbook と DSC 構成をテストする

Az モジュールに移行する前に、別の Automation アカウントですべての Runbook と DSC 構成を必ずテストしてください。

AzureRM モジュールが使用されるすべての Runbook を停止してスケジュールを解除する

AzureRM モジュールを使用する既存の Runbook または DSC 構成を決して実行しないようにするために、影響を受けるすべての Runbook と構成を停止し、スケジュールを解除する必要があります。まず、各 Runbook または DSC 構成と、それぞれのスケジュールを別々に確認して、必要に応じて、後で項目を確実に再スケジュールできるようにします。

スケジュールを削除する準備ができたら、Azure portal または Remove-AzureRmAutomationSchedule コマンドレットのいずれかを使用できます。スケジュールの削除に関するページを参照してください。

AzureRM モジュールを削除する

Az モジュールをインポートする前に、AzureRM モジュールを削除することができます。ただし、これを行うと、ソース管理の同期が中断され、まだスケジュールされているスクリプトが失敗する可能性があります。モジュールを削除することに決めたら、「AzureRM のアンインストール」を参照してください。

Az モジュールをインポートする

Automation アカウントに Az モジュールをインポートしても、Runbook で使用される PowerShell セッションにそのモジュールが自動的にインポートされることはありません。モジュールは、次の状況で PowerShell セッションにインポートされます。

Runbook がモジュールからコマンドレットを呼び出したとき。
Runbook で Import-Module コマンドレットを使用してモジュールが明示的にインポートされたとき。
Runbook で using module ステートメントを使用してモジュールが明示的にインポートされたとき。 using ステートメントは、Windows PowerShell 5.0 以降でサポートされており、クラスと列挙型のインポートをサポートしています。
Runbook が別の依存モジュールをインポートするとき。

Az モジュールを Automation アカウントにインポートするには、Azure portal を使用します。 Az.Accounts には他の Az モジュールが依存しているため、必ず他のモジュールの前にこのモジュールをインポートするようにしてください。

Note

PowerShell 7.1 (プレビュー) のサポートの導入に伴い、[ギャラリーの参照] オプションが次のように変更されました。

[プロセスオートメーション]>[モジュール] ブレードで [ギャラリーの参照] を使用できます。
[モジュール] ページには、[モジュールバージョン] と [ランタイムバージョン] という 2 つの新しい列が表示されます

Azure portal にサインインします。
Automation アカウントを検索して選択します。
[Automation アカウント] ページで、一覧からお使いの Automation アカウントを選択します。
Automation アカウントから、[共有リソース] の [モジュール] を選択します。
[モジュールの追加] を選択します。 [モジュールの追加] ページでは、次のいずれかのオプションを選択できます。
1. [ファイルの参照] - ローカルコンピューターからファイルを選択します。
2. [ギャラリーで参照] - ギャラリーから既存のモジュールを参照して選択できます。
[選択] をクリックしてモジュールを選択します。
[ランタイムバージョン] を選択し、[インポート] をクリックします。
[モジュール] ページの Automation アカウントの下で、インポートされたモジュールを表示することができます。

このインポートは、インポートするモジュールを PowerShell ギャラリーで検索して行うこともできます。モジュールを見つけたら、それを選択し、[Azure Automation] タブを選択して [Azure Automation にデプロイする] を選択します。

PowerShell ギャラリーからモジュールを直接インポートする画面のスクリーンショット。

Runbook をテストする

Az モジュールを Automation アカウントにインポートしたら、その新しいモジュールを使用できるように Runbook および DSC 構成の編集を開始することができます。新しいコマンドレットを使用するという Runbook の変更をテストする 1 つの方法として、Runbook の先頭で Enable-AzureRmAlias -Scope Process コマンドを使用できます。このコマンドを Runbook に追加することで、変更なしでスクリプトを実行できます。

モジュールを作成する

Azure Automation で使用するカスタム PowerShell モジュールを作成するときは、このセクションの考慮事項に従うことをお勧めします。インポート用にモジュールを準備するには、少なくとも、モジュールフォルダーと同じ名前の .psd1、.psm1、または PowerShell モジュールの .dll ファイルを作成する必要があります。次に、Azure Automation が 1 つのファイルとしてインポートできるように、モジュールフォルダーを zip 形式に圧縮します。 .zip パッケージは、含まれているモジュールフォルダーと同じ名前にする必要があります。

PowerShell モジュールの作成の詳細については、「PowerShell スクリプトモジュールを記述する方法」を参照してください。

バージョンフォルダー

PowerShell のサイドバイサイドのモジュールバージョン管理では、PowerShell 内で複数のバージョンのモジュールを使用できます。これは特定のバージョンの PowerShell モジュールに対してのみテストされて動作する古いスクリプトがあるが、他のスクリプトについては同じ PowerShell モジュールの新しいバージョンが必要な場合に便利です。

複数のバージョンが含まれるように PowerShell モジュールを構築するには、モジュールフォルダーを作成し、このモジュールフォルダー内に、使用可能にするモジュールのバージョンごとのフォルダーを作成します。次の例では、TestModule というモジュール内に、1.0.0 と 2.0.0 の 2 つのバージョンがあります。

TestModule
   1.0.0
   2.0.0

各バージョンのフォルダー内で、モジュールを構成する PowerShell の .psm1、.psd1、または PowerShell モジュールの .dll ファイルをそれぞれのバージョンのフォルダーにコピーします。 Azure Automation が 1 つの .zip ファイルとしてインポートできるように、モジュールフォルダーを zip 形式に圧縮します。 Automation はインポートされたモジュールのバージョンの 1 つしか表示しませんが、モジュールパッケージにモジュールのサイドバイサイドバージョンが含まれている場合は、これらはすべて Runbook や DSC 構成内で使用できます。

Automation では、同じパッケージ内のサイドバイサイドバージョンを含むモジュールがサポートされますが、モジュールパッケージインポート全体で複数のバージョンのモジュールを使用することはサポートされていません。たとえば、バージョン 1 と 2 を含むモジュール A を Automation アカウントにインポートします。後で、バージョン 3 と 4 を含むようにモジュール A を更新し、Automation アカウントにインポートすると、すべての Runbook または DSC 構成内でバージョン 3 と 4 のみが使用できます。 1、2、3、4 のすべてのバージョンを使用できるようにする必要がある場合、インポートする .zip ファイルにバージョン 1、2、3、4 が含まれている必要があります。

Runbook 間で同じモジュールの異なるバージョンを使用する場合は、Import-Module コマンドレットを使用して -RequiredVersion <version> パラメーターを含めることで、Runbook で使用するバージョンを常に宣言する必要があります。使用するバージョンが最新バージョンであってもそうです。これは、Runbook ジョブは同じサンドボックス内で実行できるためです。サンドボックス内の以前のジョブによって指定されていたため、特定のバージョン番号のモジュールがサンドボックスに既に明示的に読み込まれている場合、そのサンドボックスの後続のジョブでは、そのモジュールの最新バージョンが自動的に読み込まれることはありません。これは、その一部のバージョンが既にサンドボックスに読み込まれているためです。

DSC リソースの場合は、次のコマンドを使用して特定のバージョンを指定します。

Import-DscResource -ModuleName <ModuleName> -ModuleVersion <version>

ヘルプ情報

モジュール内のすべてのコマンドレットの概要、説明、ヘルプ URI を含める。 PowerShell では、Get-Help コマンドレットを使用して、コマンドレットのヘルプ情報を定義できます。次の例では、.psm1 モジュールファイルで概要およびヘルプ URI を定義する方法を示します。

<#
     .SYNOPSIS
      Gets a Contoso User account
#>
function Get-ContosoUser {
[CmdletBinding](DefaultParameterSetName='UseConnectionObject', `
HelpUri='https://www.contoso.com/docs/information')]
[OutputType([String])]
param(
   [Parameter(ParameterSetName='UserAccount', Mandatory=true)]
   [ValidateNotNullOrEmpty()]
   [string]
   $UserName,

   [Parameter(ParameterSetName='UserAccount', Mandatory=true)]
   [ValidateNotNullOrEmpty()]
   [string]
   $Password,

   [Parameter(ParameterSetName='ConnectionObject', Mandatory=true)]
   [ValidateNotNullOrEmpty()]
   [Hashtable]
   $Connection
)

switch ($PSCmdlet.ParameterSetName) {
   "UserAccount" {
      $cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $UserName, $Password
      Connect-Contoso -Credential $cred
   }
   "ConnectionObject" {
      Connect-Contoso -Connection $Connection
  }
}
}

この情報を指定すると、PowerShell コンソールで Get-Help コマンドレットを使用してヘルプテキストを表示できます。このテキストは、Azure portal にも表示されます。

統合モジュールのヘルプのスクリーンショット

接続の種類

モジュールから外部サービスに接続する場合は、カスタム統合モジュールを使用して、接続の種類を定義します。モジュール内の各コマンドレットはその接続の種類 (接続オブジェクト) のインスタンスをパラメーターとして受け取ります。ユーザーは、コマンドレットを呼び出すたびに、接続資産のパラメーターをそのコマンドレットの対応するパラメーターにマップします。

Azure portal でカスタム接続を使用する

次の Runbook 例は、ContosoConnection という Contoso 接続資産を使用して Contoso リソースにアクセスし、外部サービスからデータを返します。次の例では、フィールドが PSCredential オブジェクトの UserName および Password プロパティにマップされ、続いてコマンドレットに渡されます。

$contosoConnection = Get-AutomationConnection -Name 'ContosoConnection'

$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $contosoConnection.UserName, $contosoConnection.Password
Connect-Contoso -Credential $cred
}

この動作を行うためのより簡単で優れた方法は、接続オブジェクトをコマンドレットに直接渡すというものです。

$contosoConnection = Get-AutomationConnection -Name 'ContosoConnection'

Connect-Contoso -Connection $contosoConnection
}

コマンドレットを似た動作にするには、パラメーターの接続フィールドではなく、接続オブジェクトをパラメーターとして直接受け取ることができるようにします。 Automation を使用していないユーザーが、接続オブジェクトとして機能するハッシュテーブルを作成することなく、コマンドレットを呼び出すことができるようにするには、通常、それぞれにパラメーターセットが必要です。接続フィールドのプロパティを渡すために、パラメーターセット UserAccount が使用されます。 ConnectionObject を使用すると、接続をそのまま渡すことができます。

出力の種類

モジュール内のすべてのコマンドレットの出力の種類を定義します。コマンドレットの出力の種類を定義すると、設計時の IntelliSense で、作成時のコマンドレットの出力プロパティを判断できます。この方法は、設計時の知識がモジュールでの容易なユーザーエクスペリエンスの鍵となる、Runbook のグラフィカルな作成時に特に役立ちます。

[OutputType([<MyOutputType>])] を追加します。MyOutputType は有効な種類です。 OutputType の詳細については、「関数の OutputTypeAttribute の概要」を参照してください。次のコードは、OutputType をコマンドレットに追加する例です。

function Get-ContosoUser {
[OutputType([String])]
param(
   [string]
   $Parameter1
)
# <script location here>
}

グラフィカルな Runbook 出力の種類のスクリーンショット

この動作は、PowerShell 統合サービス環境のコマンドレットの出力の "先行入力" 機能と似ていますが、実行する必要はありません。

POSH IntelliSense のスクリーンショット

コマンドレットの状態

モジュール内のすべてのコマンドレットをステートレスにします。複数の Runbook ジョブは、同じ AppDomain および同じプロセスとサンドボックスで同時に実行できます。これらのレベルで共有された状態がある場合、ジョブが互いに影響し合うことがあります。この動作は、断続的で診断の難しい問題を招く可能性があります。悪い例を次に示します。

$globalNum = 0
function Set-GlobalNum {
   param(
       [int] $num
   )

   $globalNum = $num
}
function Get-GlobalNumTimesTwo {
   $output = $globalNum * 2

   $output
}

モジュールの依存関係

xcopy を使用してコピーできるパッケージにモジュールが完全に含まれていることを確認します。 Automation のモジュールは、Runbook を実行するときに Automation の Sandbox に配布されます。モジュールは、それらを実行するホストとは独立して動作する必要があります。

モジュールパッケージを zip 形式で圧縮して移動できるようにし、別のホストの PowerShell 環境にインポートしたときに通常通りに機能する状態にする必要があります。これを行うには、モジュールが Automation にインポートされるときに、zip 形式のモジュールフォルダーの外部にあるファイルに依存していないことを確認します。

モジュールは、ホスト上の独自のレジストリ設定に依存しないようにする必要があります。例としては、製品のインストール時に行われる設定があります。

モジュールファイルのパス

モジュール内のすべてのファイルが、140 文字未満のパスであることを確認します。長さが 140 文字を超えるパスを使用すると、Runbook のインポートで問題が発生します。 Automation では、Import-Module を使用してパスサイズが 140 文字を超えるファイルを PowerShell セッションにインポートすることはできません。

モジュールをインポートする

このセクションでは、Automation アカウントにモジュールをインポートできるいくつかの方法を定義します。

Azure portal でモジュールをインポートする

Azure portal でモジュールをインポートするには:

ポータルで、 [Automation アカウント] を検索して選択します。
[Automation アカウント] ページで、一覧からお使いの Automation アカウントを選択します。
[共有リソース] の下にある [モジュール] を選択します。
[モジュールの追加] を選択します。
モジュールを含む .zip ファイルを選択します。
[OK] を選択してプロセスのインポートを開始します。

PowerShell を使用してモジュールをインポートする

New-AzAutomationModule コマンドレットを使用して、モジュールを Automation アカウントにインポートできます。このコマンドレットは、モジュールの .zip パッケージの URL を受け取ります。

New-AzAutomationModule -Name <ModuleName> -ContentLinkUri <ModuleUri> -ResourceGroupName <ResourceGroupName> -AutomationAccountName <AutomationAccountName>

同じコマンドレットを使用して、PowerShell ギャラリーからモジュールを直接インポートすることもできます。必ず PowerShell ギャラリーから ModuleName と ModuleVersion を取得してください。

$moduleName = <ModuleName>
$moduleVersion = <ModuleVersion>
New-AzAutomationModule -AutomationAccountName <AutomationAccountName> -ResourceGroupName <ResourceGroupName> -Name $moduleName -ContentLinkUri "https://www.powershellgallery.com/api/v2/package/$moduleName/$moduleVersion"

PowerShell ギャラリーからモジュールをインポートする

PowerShell ギャラリーモジュールは、ギャラリーから、または Automation アカウントから直接インポートできます。

PowerShell ギャラリーから直接モジュールをインポートするには:

https://www.powershellgallery.com に移動し、インポートするモジュールを検索します。
[インストールオプション] の下にある [Azure Automation] タブで [Deploy to Azure Automation]\(Azure Automation にデプロイする\) を選択します。このアクションにより Azure portal が開きます。
[インポート] ページで、Automation アカウントを選択し、[OK] を選択します。

PowerShell ギャラリーのインポートモジュールのスクリーンショット

PowerShell ギャラリーモジュールを Automation アカウントから直接インポートするには:

ポータルで、[Automation アカウント] を検索して選択します。
[Automation アカウント] ページで、一覧からお使いの Automation アカウントを選択します。
[共有リソース] の下にある [モジュール] を選択します。
[ギャラリーの参照] を選択し、ギャラリーでモジュールを検索します。
インポートするモジュールを選択し、[インポート] を選択します。
[OK] を選択してインポートプロセスを開始します。

Azure portal から PowerShell ギャラリーモジュールをインポートする画面のスクリーンショット

モジュールを削除する

モジュールに問題がある、またはモジュールの以前のバージョンにロールバックする必要がある場合は、そのモジュールを Automation アカウントから削除できます。 Automation アカウントを作成するときにインポートされた既定のモジュールの元のバージョンを削除することはできません。削除するモジュールが既定のモジュールのいずれかの新しいバージョンである場合、Automation アカウントを使用してインストールされたバージョンにロールバックします。それ以外の場合、Automation アカウントから削除したモジュールはすべて削除されます。

Azure portal でモジュールを削除する

Azure portal でモジュールを削除するには:

ポータルで、[Automation アカウント] を検索して選択します。
[Automation アカウント] ページで、一覧からお使いの Automation アカウントを選択します。
[共有リソース] の下にある [モジュール] を選択します。
削除するモジュールを選択します。
[モジュール] ページで、[削除] を選択します。このモジュールが既定のモジュールのいずれかである場合、Automation アカウントが作成されたときに存在していたバージョンにロールバックされます。

PowerShell を使用してモジュールを削除する

PowerShell を使用してモジュールを削除するには、次のコマンドを実行します。

Remove-AzAutomationModule -Name <moduleName> -AutomationAccountName <automationAccountName> -ResourceGroupName <resourceGroupName>

次のステップ

Azure PowerShell モジュールの使用方法の詳細については、「Azure PowerShell の概要」をご覧ください。
PowerShell モジュールの作成の詳細については、「Windows PowerShell モジュールの作成」をご覧ください。

次の方法で共有

Azure Automation でモジュールを管理する

サンドボックス

既定のモジュール

内部コマンドレット

Python モジュール

カスタムモジュール

Az モジュールへの移行

モジュールを移行する前に Runbook と DSC 構成をテストする

AzureRM モジュールが使用されるすべての Runbook を停止してスケジュールを解除する

AzureRM モジュールを削除する

Az モジュールをインポートする

Runbook をテストする

モジュールを作成する

バージョンフォルダー

ヘルプ情報

接続の種類

出力の種類

コマンドレットの状態

モジュールの依存関係

モジュールファイルのパス

モジュールをインポートする

Azure portal でモジュールをインポートする

PowerShell を使用してモジュールをインポートする

PowerShell ギャラリーからモジュールをインポートする

モジュールを削除する

Azure portal でモジュールを削除する

PowerShell を使用してモジュールを削除する

次のステップ

フィードバック

その他のリソース

次の方法で共有

Azure Automation でモジュールを管理する

サンドボックス

既定のモジュール

内部コマンドレット

Python モジュール

カスタム モジュール

Az モジュールへの移行

モジュールを移行する前に Runbook と DSC 構成をテストする

AzureRM モジュールが使用されるすべての Runbook を停止してスケジュールを解除する

AzureRM モジュールを削除する

Az モジュールをインポートする

Runbook をテストする

モジュールを作成する

バージョン フォルダー

ヘルプ情報

接続の種類

出力の種類

コマンドレットの状態

モジュールの依存関係

モジュール ファイルのパス

モジュールをインポートする

Azure portal でモジュールをインポートする

PowerShell を使用してモジュールをインポートする

PowerShell ギャラリーからモジュールをインポートする

モジュールを削除する

Azure portal でモジュールを削除する

PowerShell を使用してモジュールを削除する

次のステップ

フィードバック

その他のリソース

カスタムモジュール

バージョンフォルダー

モジュールファイルのパス