2023年9月10日日曜日

Azure Arc対応サーバーをAzure Monitorに関連付ける その2

Azure Arc対応サーバーをAzure Monitorに関連付ける その1 がうまくいっていないので対策します。

Azure Policyの割り当てを進める中で、警告が出ておりました。

改めて該当Azure Policyの修復を確認しました。
設定時には、出ていなかったアクセス許可はあるものの、なにも割り当たっていない状態ですね。
割り当ての概要ページを見てみました。修復タスクが無効なまま。

色々調べまして、定義されたロールを使用してマネージド ID にアクセス許可を付与する が関係しているのかなと思い、トライします。

定義されたロールを使用してマネージド ID にアクセス許可を付与する  の1~6を進めました。7では「Azureに接続されたマシンのリソース管理者」を選ぶと仮定して進めます。で調べた割り当てIDで検索してみたのですが、出ない。。。

システムマネージドIDで無いほうが良いかも。

マネージドIDを作ってみます。

マネージドIDの作成完了。

改めて 定義されたロールを使用してマネージド ID にアクセス許可を付与する  の1~6を進めました。7では「Azureに接続されたマシンのリソース管理者」を選ぶと仮定しました。上記で作成したマネージドIDを指定します。

割り当てで、作成したユーザー割り当てマネージドIDに切り替えます。

この時点では、アクセス許可が表示されていないですね。「レビューと保存」をクリックします。
「保存」をクリックします。

改めて割り当ての修復を確認します。

アクセス許可が表示されないですね。ここが問題なのか、はたまた。。。

マネージドIDにより強力な権限を割り当ててみる、ポリシー割り当てを一度削除してリトライしてみるといったところを確認してみようかな。

Azure Arc対応サーバーをAzure Monitorに関連付ける その1

※すでにAzure Monitorは有効となっています。

Azure Arc対応サーバーをAzure Monitorを簡単に関連付ける方法があるとのことで、調べました。下記の方法が該当します。

Azure Arc 対応サーバー上の Azure Monitor エージェントのデプロイ オプション

Azure Arc 対応サーバーの VM 拡張機能を使用して監視エージェントを簡単にデプロイおよび管理する - Training | Microsoft Learn

  1. Azure Arc 対応サーバーの VM 拡張機能として直接
  2. Azure Policy のデプロイ
  3. Azure Automation の使用
展開方法としては、上記があります。単一の展開方法として1と大量展開方法として2を確認してみます。

Azure Arc 対応サーバーの VM 拡張機能として直接

Azure Arc 対応サーバー用の拡張機能の自動アップグレード に沿いたいと思いましたが、ちょっと違うかもしれないので、推測交えて進めます。
下記画面の「追加」をクリックします。
すると下記画面になりました。
「Azure Monitor Agnet for Windows」をクリック後、「次へ」をクリックします。
Proxy設定は、今回不要なので「確認と作成」をクリックします。
「作成」をクリックします。
しばらく待つと完了しました。
リソースの状態を確認します。
Azure Arc 対応サーバーの一覧からも、Azure Monitorが有効化(installed)されていることを確認しました。

Azure Policy のデプロイ

2023/09/10 追記 Azureポリシーとして割り当てるのは、「Windows Arc 対応マシンには Azure Monitor エージェントがインストールされている必要がある」ではなくて、「Azure Monitor エージェントを実行するように Windows Arc 対応マシンを構成する」のようです。「Azure Monitor エージェントを実行するように Windows Arc 対応マシンを構成する」には、deployIfNotExistsが定義されていました。詳しくは、Azure Arc対応サーバーをAzure Monitorに関連付ける その3 の試行錯誤をご覧ください。

Azure Policyから下記のポリシー(not イニシアティブ)をクリックします。


そうすると下記の画面になります。「割り当て」をクリックします。
「スコープ」でオンプレミスのマシンを関連付けてあるリソースグループを選択しました。他は特に指定しないので、「次へ」をクリックします。
特に変更しないので、「次へ」をクリックします。
非常時のパラメーターを確認してみます。
特に変更しないので、「次へ」をクリックします。
修復でマネージドIDを使用するよう構成し、マネージドIDとしてはシステム割り当てマネージドIDとします。システム割り当てマネージドIDは、Japan Eastとします。(リソースグループと同じ場所)
※2023/09/10追記 ここでロールの定義が含まれていない旨の警告が出ています。修復タスクと関連するかを調べています。
「次へ」をクリックします。
非準拠メッセージを設定し、「次へ」をクリックします。
パラメーターを確認後、「作成」をクリックします。
ジョブは完了しました。ただし有効化まで約30分かかるようです。
手動で展開した一台を除いて、armrg-east-japan-sshzk2016-SponsorリソースグループのほとんどでInstalledにはなっていません。ここからポリシーが割り当てられてMonitor Agentが使えるようになるまで30分ではなくさらにそれ以上時間がかかると推測します。
※起動しているのにオフラインのままなマシンもいくつかいますが。。。

ここまでで、単一の展開方法とAzure Policyを使った展開方法を確認しました。

https://learn.microsoft.com/ja-jp/azure/azure-arc/servers/concept-log-analytics-extension-deployment?WT.mc_id=AZ-MVP-5000440#next-steps

を確認したところAzure Monitorの仮想マシンを見ればよいようです。で開いてみました。

VM Insigthの有効化も必要そうな。。。

Azure Policyで展開したarmrg-east-japan-sshzk2016-Sponsorリソースグループかつ接続済みとなっているサーバーがInstalledになっているか、VM Insigthの有効化は別稿にまとめる予定です。

2023年9月3日日曜日

PowerShellのAksHciモジュール都合により、Az.ResourcesとAz.Accountsが複数バージョン並列配置せざるを得なかった

Az.StackHCI、Az.Resources、Az.ccountsを最新化するPowerShellスクリプト でPowerShellモジュールを最新化できたと思ったら、そうは問屋が卸さなかった。。。

PowerShellモジュールのAksHci 1.1.83は、Az.Resource 4.40、Az.Accounts 2.6.0を要求しています。。。
※あくまでも本校執筆時点の2023年9月3日での話です。AksHci がバージョンアップしたら状況は変わるかもしれません。

Import-Module -Name AksHci
後は、クラスターの全ノードでAz.ResourcesとAz.Accountsが複数バージョンの並列インストールとなりました。

2023/09/03追記

同じPowerShellモジュールを並列でインポートしたせいか、下記のエラーが発生しました。

PowerShellウィンドウをいったん閉じてから開きなおし、Az.Accounts 2.6.0、Az.Resource 4.4.0の順でインポート後、AksHciをインポートしました。結果、上記のエラーは収まった模様。

2023年9月2日土曜日

Windows Admin Center 2306のTool updates -> Improved Hyper-V virtual machine management その2

Windows Admin Center 2306のTool updates -> Improved Hyper-V virtual machine management その1 から続く

Windows Admin Center version 2306 is now generally available!

のTool updates -> Improved Hyper-V virtual machine managementの中から、下記についてみていきます。

  • Ability to move virtual machine between clusters
  • Ability to move virtual machine with storage
  • Ability to pop out a VM’s RDP session, so you don’t have to switch context and leave your current view

Ability to move virtual machine between clusters

「管理」から「移動」を選択します。
移行先で別のクラスターを選んでから、配置先のストレージを選びます。
設定項目を確認後、「移動」クリックしてしばらく待ちます。
上記画像の後、移行元の仮想マシンは、さっと消えてしまいますが、移行先にはなかなか出てこないので、失敗したと焦らず待ちましょう。しばらくすると仮想マシンマイグレーションの結果が表示されます。
仮想ハードディスクのパスを念のため確認しておきます。問題無いですね。

Ability to move virtual machine with storage

※移行先に仮想マシン名のフォルダーを作成しておいたほうが、変な配置にならずに済みます。フェールオーバークラスターマネージャーでストレージ移行をする場合とおんなじ感じです。

変な配置になってしまった例から記載します。

「管理」から「移動」を選択します。

c:\ClusterStorage\Volume2配下を選択して、「移動」をクリックします。
しばらく待つと結果が表示されます。
c:\ClusterStorage\Volume2配下にHyper-Vフォルダーを作成してそこへストレージ移行しました。。。
ということで、移行先に仮想マシン名のフォルダーを作成してから、移行先として指定し「移動」をクリックします。
結果が表示されます。
希望した配置になりました。

Ability to pop out a VM’s RDP session, so you don’t have to switch context and leave your current view

※対象の仮想マシンに対して、RDPやWinRMの許可設定、名前解決が必要です。念のため。
 同じADドメインがベストかもしれませんね。

仮想マシンを選択後、「接続」→「接続」→接続アイコンの右端を下図のように選択します。

認証情報を入力します。
リモートデスクトップ接続しました。この後、「Ctrl+Alt+Delを送信」をクリックすればログオンできます。

Windows Admin Center 2306のスケジュールされたタスク

タスクを編集するとエラーになりました。

GUIのタスクスケジューラだと、最後に認証を求められます。が、Windows Admin Centerのスケジュールされたタスク拡張は、認証を求められないからでしょう。



2023年8月26日土曜日

Az.StackHCI、Az.Resources、Az.ccountsを最新化するPowerShellスクリプト

Az.StackHCIモジュールのバージョン違いによる挙動なのか否か での気付き(凡ミスを繰り返したくない)をもとに、メンテナンスを簡素化することとしました。

元ネタは、Uninstall older versions of PowerShell after successful upgrade に記載がある古いPowerShellモジュールを削除するスクリプトです。

こちらをもとに、Update-Moduleをコードに追加、更新および古いモジュールを削除する対象としてAz.StackHCI、Az.ccounts、Az.Resourcesを指定した下記を作成しました。
※後ほどこの並びだとダメだと、スクリプトの動作確認で判明します。。。
太字部分が追加や変更したコードです。
$modules = @("Az.StackHCI", "Az.Accounts", "Az.Resources")
foreach($module in $modules)
{
    $current = Get-InstalledModule -Name $module -ErrorAction Ignore
    if (-not $current)
    {
        Write-Host $("[Module: $module] Is not installed, skipping")
        continue
    } else {
        update-module -Name $module -Force
    }
    Write-Host $("[Module: $module] Newest installed version is $($current.Version)")
    $versions = Get-InstalledModule -Name $module -AllVersions
    foreach($version in $versions)
    {
        if ($version.Version -eq $current.Version)
        {
            Write-Host $("[Module: $module] Skipping uninstall for version $($version.Version)")
            continue
        }
        Write-Host $("[Module: $module] Uninstalling version $($version.Version)")
        $version | Uninstall-Module -Force -Confirm:$false
    }
}

スクリプト実行前は、下記の通りでした。

スクリプト実行後は、下記の通りとなりました。Az.Resourcesのスペルミスを修正したので、2回実行しました。Az.Resourcesがデグレードしているので、まだ改良が必要かなぁ。。。

依存関係の関係で、"Az.StackHCI", "Az.Resources", "Az.Accounts"の順で処理しないとだめでした。あと"Az.Accounts"は、"Az.StackHCI"の依存関係に伴いインストールされますね。
でも、別環境では、下記の通り新しいバージョンを削除しているので、改良が必要です。。。

ということで現時点のコードを下記に貼っておきます。(上記の改良はまだ未反映)

$modules = @("Az.StackHCI", "Az.Resources", "Az.Accounts")
foreach($module in $modules)
{
    $current = Get-InstalledModule -Name $module -ErrorAction Ignore
    if (-not $current)
    {
        Write-Host $("[Module: $module] Is not installed, skipping")
        continue
    } else {
        update-module -Name $module -Force
    }
    Write-Host $("[Module: $module] Newest installed version is $($current.Version)")
    $versions = Get-InstalledModule -Name $module -AllVersions
    foreach($version in $versions)
    {
        if ($version.Version -eq $current.Version)
        {
            Write-Host $("[Module: $module] Skipping uninstall for version $($version.Version)")
            continue
        }
        Write-Host $("[Module: $module] Uninstalling version $($version.Version)")
        $version | Uninstall-Module -Force -Confirm:$false
    }
}

2023年8月19日土曜日

Az.StackHCIモジュールのバージョン違いによる挙動なのか否か

Register-AzStackHCIで同じようにAzure Stack HCIクラスターを登録したつもりが、リージョンで挙動が違った からの続き。
※後藤さんより、ご指摘いただきました。ありがとうございました。

East USリージョンに登録しているAzure Stack HCIクラスターのノードでGet-Moduleしてみました。


つづいてJapan Eastに登録しているAzure Stack HCIクラスターのノードでGet-Moduleしてみました。


East USリージョンに登録しているAzure Stack HCIクラスターは、Az.StackHCIモジュールのバージョンが古い。。。

East USリージョンに登録しているAzure Stack HCIクラスターは、Az.StackHCIモジュールを最新化しました。(Remove-Module、Uninstall-Module、Install-Moduleget-Module、Import-Module)

2.1.1と、さらに新しくなっているけど。。。

とりあえず、これでAzure Stack HCIを再登録しました。

Az.StackHCI V2系になったら、Azure Stack HCIクラスターもクラスターノードも同じAzureリソースグループに登録されました。

以上、見落としでお騒がせしました。Az.StackHCIのバージョン違いもちゃんと気にします。。。