問題タブ [azure-automation]

ワークフローとネイティブ ps1 コマンドレットが埋め込まれたカスタム モジュールがあります。

このモジュールをインポートすると、コマンドレットのサブセットのみが抽出されたアクティビティとしてモジュールの下に表示されます。

モジュールはインポートを正常に完了しており、Available と表示されます。

特定の出力と考えられるメンバー固有のインポートエラーを見つけるために探す場所はありますか?

読み込みに失敗するコマンドレットは、アセンブリの一部として追加されたいくつかの新しい型に依存しています。読み込まれているコマンドレットも、そのアセンブリの型に依存しています。

さらに混乱を招くのは、このモジュールを ISE でローカルにインポートすると、すべてが正常に機能し、すべてのコマンドレットが利用可能/実行可能になることです。

さらに: ネイティブ PowerShell コマンドレットでこれを見たことがありますが、.ps1 内の (単一の) PowerShell ワークフロー アクティビティがサポートされていないようにも見えます。

さらに、ローカルで、.psd1 または .psm1 を使用してモジュールをロードするかどうかに応じて、異なる動作と結果の WRT 依存アセンブリのロードが発生することを確認しました。

特に、矛盾をローカルでトラブルシューティングしようとすると、「型が見つかりません」または「引数が 1 の ctor に対して複数のオーバーロードが見つかりました」というメッセージが多数表示されました (問題の型に 1 の ctor がないにもかかわらず)。 arg)[OutputType([typename])]などを介して参照される型のエラー。同じアセンブリの型に依存する OTHER コマンドレットが正常に検出された場合。

[編集]
テスト .psm1 からのローカル詳細出力

詳細: 関数 'sync-test' をインポートしています。
詳細: コマンドをワークフロー 'Sync-VsoGitRmRunbook' としてインポートしています。

AA では、sync-test (文字列出力を書き込む単純な Runbook) は正常に表示されますが、Sync-VsoGitRmRunbook は表示されません。

sync-test をワークフローに変換すると、インポートも停止するため、(モジュールにパッケージ化された C# クラスではなく) .ps1 ファイルとしてバンドルされているワークフロー アクティビティをエクスポートするモジュールには制限があると思われます。

[編集]
問題を再現するモジュールを作成しました。 https://github.com/JoeBrockhaus/AzureAutomationVsoGitSync

私はこれを数回見てきましたが、なぜそうなのかは不明です。まだロードされていないという単純な問題ではありません。たとえば、[削除] ボタンは、ブレードが完全にロードされるまで非アクティブになります (ブレードの上部にある小さな水平の進行状況インジケーターは通常どおり機能します)。

これは、ブラウザー/ポータル セッション、ユーザーなどの間で永続的です。

Runbook エディターでは、モジュールが読み込まれ、そのメンバーを表示するために展開できるように見えますが、このモジュールは最近更新されたため、実際に更新されたのか、それとも以前のモジュールのリストにすぎないのかを知る方法はありません。 . 「プロビジョニング」、「インポート」、または「抽出」で何かがおかしくて、ポータルがモジュールのブレードをレンダリングすることさえできない場合、私はすべてがカバーの下で A-OK であるとはほとんど信じていません。

さらに悪いことに、潜在的な問題を修正するために操作からの出力を調査する方法がありません。私のコード (またはポータル) に関する限り、モジュールは正常にアップロード、インポート、および抽出されませんでした。 、 実際に。

一部のシステム レベルのジョブがこれらのインポート/抽出を担当する必要があることに気付きました。これは、Automation アカウントのジョブ統計監視タイルがモジュールのインポート時にカウントをカウントアップするためですが、これらのファントム ジョブは実際には表示されません。ジョブ リストに表示されます (もちろん、それらを支えるランブックもそうではありません)。

ここでコードを使用する https://msdn.microsoft.com/en-us/library/jj919145.aspx

URL への SQL バックアップによって作成された BLOB のリースを解除して、remove-azurestorageblob を使用して古い BLOB を削除できるようにしようとしています。

これはオンプレミスでは夢のように機能しますが、Azure Automation で実行したいと考えています

ストレージ アセンブリをロードする必要がありますが、取得できないようです。

私はこの答えを見ました

https://social.msdn.microsoft.com/Forums/en-US/45251bdb-bb20-488c-a428-3ee1094fd568/referencing-microsoftwindowsazurestoragedll-and-creating-cloud-blob-client-using?forum=azureautomation

C:\modules フォルダーを使用してロードしようとしました

dll を検索するランブックを作成しました

c:\modules\global にある返されたパスを使用してロードしようとしましたが、常にエラーが発生し、アセンブリが見つかりませんでした

グラフィカル エディター UI ではワークフロー Runbook を追加できるように見えますが (ネイティブ PS は表示されません)、これにより GraphRunbook の定義/実行が中断されます。

Runbook をテストまたは発行しようとすると、画像にエラーが表示されます。(これも奇妙なことに、このエラー メッセージは前半がスペイン語、後半が英語の組み合わせで表示されています。)

Automation アカウントの他の Runbook は技術的にサポートされていません..まだですか?

テストコード:

パラメーターを使用して Runbook を追加した後、テスト ペインで、または発行後にジョブとして開始できません。

• これより前に存在した Runbook は、パラメーターを入力します。
• ISE でテスト ジョブを開始できません (単にポータル/ブラウザの問題ではありません)。
• ARM API からの GET は、空の Parameters プロパティを持つ Runbook を返します。

[CmdletBinding()][編集]指定したかどうかは問題ではないことをおそらく追加する必要があります。[/編集]

ストレージ アカウント内のすべてのコンテナーを別のストレージ アカウントの単一のコンテナーにコピーしようとしています。自分のマシンで問題なく動作するようになりましたが、Azure Automation を使用して自動化したいと考えています。

標準の PowerShell スクリプトを実行すると、すべての非同期呼び出しが同期的に発生します。これを解決するために、「Powershell Workflow」ランブックを追加してみました。これに関する問題は、AzureStorageContext. 問題は、コンテキストが文字列にシリアル化されるため、コンテキストを何にもバインドできないことです。

次のコードがあります。

これに対する標準的な回避策InlineScriptは、コンテキスト オブジェクトを必要とするすべての処理にブロックを使用することです。ただし、それを行うと、BLOB を並行してコピーする機能が失われます。

すべての BLOB のコピー コマンドを並行して開始しながら、Azure Automation でこれを行う方法はありますか?

Azure Automation Pull サーバーを使用して DSC 構成を VM に追加しようとしています。通常、環境変数を使用して現在のマシンの名前を取得できます$env:COMPUTERNAME。つまり、次のようにします。

ただし、Azure Automation を使用すると、現在のマシン名に関係なく、$env:COMPUTERNAME常にCLIENTが返されるようです。Azure Automation を使用しているときに、DSC 構成内の現在の VM の名前を動的に取得するための最善/最も推奨される方法は何ですか?

前もって感謝します。

よろしくお願いします、

トーマス

Azure ストレージに復元された既存の VM のバックアップを使用して VM 構成を自動化する方法についてサポートが必要です。

ここでのシナリオは、PowerShell を使用して (Azure バックアップを使用して) VM のセットをバックアップし、予約済み IP を使用してクラウド サービスに復元しています (ポータルを使用して予約済み IP を使用してクラウド サービスに VM バックアップを復元することはできません)。これを Azure Automation を使用して自動化したいと考えています。

ありがとう、マンモハン・シン