WinRM over HTTPSとWindows Admin Center

Windows Admin Center（以降、WACと略します。）のセットアップウィザードにおいて、管理対象への接続をWinRM over HTTPSへ指定する方法があります。

管理対象でWinRM over HTTPSを構成するには、管理対象に証明書のインストールした上で、

HTTPS 用に WINRM を構成する方法

に沿って構成します。実際の構成は、上記に記載の通り、下記を実行します。

winrm quickconfig -transport:https

上記のとおり構成されていれば、HTTPS用のリスナーが増えています。

しかしこれだけでは不足してます。試したり調べた結果としては、下記が必要です。

1. Windows Defender Firewallにて5986/tcpの開放が必要です。既定では、WinRM over HTTP用である5985のルールしかないです。
2. 証明書のサブジェクト（おそらくSAN）も管理対象のホスト名、FQDNに沿っている必要があります。証明書にはFQDNだけ指定した場合、ホスト名で接続するとエラーになります。（後ほど画面を貼ります）

シンプルに確認したかったので、FQDNをサブジェクトとSANに指定した証明書がインストール済みのWindows Admin Center自体で確認しました。管理対象への接続をWinRM over HTTPSとする方法としては、

• 前述の通り、セットアップウィザードの途中で設定する
• セットアップ後にSet-WACWinRmOverHttpsを用いて有効化
  WinRM over HTTPからWinRM over HTTPSへ切り替えることしかできず、設定変更は不可逆です。Set-WACWinRmOverHttpsは、-Enabledと有効するオプションのみで、逆がないのです。$falseなど試してみましたが、効きませんでした。
  

があります。

今回は、WACをアンインストールし、再インストール時にセットアップウィザードにてWinRM over HTTPSを指定しました。ここで、接続確認しても、管理対象にはつながりません。前述の通り、WinRM over HTTP用のWindows Defender Firewallルールしかないためです。

よってWinRM over HTTPS用の5986/tcpの開放ルールを作りました。

証明書は、FQDNで構成したと前に述べましたが、ホスト名で管理対象につなぐとエラーになります。

接続リストのFQDNを追加後、

接続すると、問題無くつながります。

補足ですが、管理対象への接続をWinRM over HTTPSと指定したWACは、WinRM over HTTPのみとなっている管理対象には接続できません。まず接続リストへの追加時に警告が出ます。

そもそも証明書も用意していないので、HTTPS用リスナーも未構成です。Windows Defender Firewallルールも無いため、結果的に接続もできません。

管理対象への接続をWinRM over HTTPと指定したWACは、WinRM over HTTPSを有効化した管理対象にも接続できます。これは、HTTPSリスナーではなく、HTTPリスナーを使用するためです。前述の通り、HTTPSリスナーとHTTPリスナーがある故です。

Network ATCのGlobal Cluster Overridesも出力してみる

Network ATCのSet-NetIntentによりOverridesを追加してみる

では、Global Cluster Overridesを出力していないことを思い出し、調べつつ生成AIからPowerShellコードを出力してもらいました。

# -----------------------------

# Dump Network ATC intents + Global overrides (Cluster + Proxy)

# -----------------------------

# インテント別Overrides（既存ロジックを最適化：Get-NetIntent呼び出しを1回に）

$intentNames = (Get-NetIntent).IntentName

foreach ($name in $intentNames) {

    $i = Get-NetIntent -Name $name

    "`n===== Intent: $($i.IntentName) / Type: $($i.IntentType) ====="

    "AdapterAdvancedParametersOverride:"; $i.AdapterAdvancedParametersOverride

    "RssConfigOverride:";                $i.RssConfigOverride

    "QosPolicyOverride:";                $i.QosPolicyOverride

    "SwitchConfigOverride:";             $i.SwitchConfigOverride

    "IPOverride:";                       $i.IPOverride

    "NetAdapterCommonProperties:";       $i.NetAdapterCommonProperties

}

# --- Global overrides を取得（globalintent相当） ---

$g = Get-NetIntent -GlobalOverrides | Where-Object IntentType -eq 'Global'

"`n===== Global Overrides (globalintent) ====="

$g | Format-List ProxyOverride, ClusterOverride, ResourceContentVersion, IntentName, Scope, IntentType, InstanceId, ObjectVersion

# -----------------------------

# 1) Global Cluster Overrides (New-NetIntentGlobalClusterOverrides 相当)

# -----------------------------

$clusterProps = @(

  'EnableNetworkNaming',

  'EnableLiveMigrationNetworkSelection',

  'EnableVirtualMachineMigrationPerformanceSelection',

  'VirtualMachineMigrationPerformanceOption',

  'MaximumVirtualMachineMigrations',

  'MaximumSMBMigrationBandwidthInGbps'

)

"`n===== Global Cluster Overrides (ClusterOverride) ====="

$g.ClusterOverride | Select-Object $clusterProps | Format-List

# -----------------------------

# 2) Global Proxy Overrides (New-NetIntentGlobalProxyOverrides 相当)

#    -ProxyServer / -ProxyBypass / -AutoDetect / -AutoConfigUrl

# -----------------------------

$proxyPropCandidates = @(

  'ProxyServer',     # New-NetIntentGlobalProxyOverrides -ProxyServer

  'ProxyBypass',     # New-NetIntentGlobalProxyOverrides -ProxyBypass

  'AutoDetect',      # New-NetIntentGlobalProxyOverrides -AutoDetect

  'AutoConfigUrl'    # New-NetIntentGlobalProxyOverrides -AutoConfigUrl

)

"`n===== Global Proxy Overrides (ProxyOverride) ====="

# ProxyOverride は環境によりプロパティ名が揺れる可能性があるため、

# 「存在するプロパティだけ」出すようにしています。

if ($null -eq $g.ProxyOverride) {

    Write-Warning "ProxyOverride が null です（未設定/既定の可能性）。"

} else {

    $existing = $proxyPropCandidates | Where-Object { $g.ProxyOverride.PSObject.Properties.Name -contains $_ }

    if ($existing.Count -eq 0) {

        # 期待の名前で取れない場合は全出力して原因特定

        Write-Warning "ProxyOverride に期待プロパティ($($proxyPropCandidates -join ', '))が見つかりません。全プロパティを表示します。"

        $g.ProxyOverride | Format-List *

    } else {

        $g.ProxyOverride | Select-Object $existing | Format-List

    }

}

これをNestedなWindows Server 2025 S2D上で実行しました。NetDirect=RDMAとSR-IOVは無効化が確認できました。

Global Cluster Overridesは、特段設定してないので何も出てきませんが、項目としては大丈夫です。

なお物理サーバーで値が出ているのは確認済みです。

Azure Local のRack Aware/multi-rack deploymentsで要求されるリソースプロバイダーの確認と登録 その3

Azure Local のRack Aware/multi-rack deploymentsで要求されるリソースプロバイダーの登録状況を確認する

の続きです。

そろそろ登録しようと思い、上記のスクリプトを実行して登録状況を再確認しました。

未登録のリソースプロバイダーがわかりました。下記のコマンドを使います。

az provider register --namespace Microsoft.HybridNetwork
az provider register --namespace Microsoft.ManagedNetworkFabric
az provider register --namespace Microsoft.NetworkCloud
az provider register --namespace Microsoft.Relay
az provider register --namespace Microsoft.NexusIdentity

実行例は下記のとおりです。

上記のスクリプトを再実行して登録状況を表示しました。目的は達成です。

Azure Local のRack Aware/multi-rack deploymentsで要求されるリソースプロバイダーの登録状況を確認する

Prerequisites for multi-rack deployments of Azure Local (preview) - Register resource providers

を読んでいまして、Azure Localの通常デプロイにはないリソースプロバイダーがあるなと。とりあえず、未登録のものを知りたいので、chatGPTとやりとりすること数回。結果、

$subscriptionId = "あなたのサブスクリプションID"
Select-AzSubscription -SubscriptionId $subscriptionId
$providers = @(
  "Microsoft.AzureArcData",
  "Microsoft.Compute",
  "Microsoft.AzureStackHCI",
  "Microsoft.ContainerService",
  "Microsoft.ExtendedLocation",
  "Microsoft.GuestConfiguration",
  "Microsoft.HybridCompute",
  "Microsoft.HybridConnectivity",
  "Microsoft.HybridContainerService",
  "Microsoft.HybridNetwork",
  "Microsoft.Insights",
  "Microsoft.Keyvault",
  "Microsoft.Kubernetes",
  "Microsoft.KubernetesConfiguration",
  "Microsoft.ManagedIdentity",
  "Microsoft.ManagedNetworkFabric",
  "Microsoft.Network",
  "Microsoft.NetworkCloud",
  "Microsoft.OperationalInsights",
  "Microsoft.OperationsManagement",
  "Microsoft.Relay",
  "Microsoft.ResourceConnector",
  "Microsoft.Resources",
  "Microsoft.Storage",
  "Microsoft.NexusIdentity"
)
$providers |
ForEach-Object {
    $rp = Get-AzResourceProvider -ProviderNamespace $_ -ErrorAction SilentlyContinue
    if ($null -eq $rp) {
        [PSCustomObject]@{
            Provider = $_
            Status   = "NotFound"
        }
    }
    else {
        [PSCustomObject]@{
            Provider = $_
            Status   = ($rp | Select-Object -First 1).RegistrationState
        }
    }
} |
Format-Table -AutoSize

が出来上がりました。出力結果は下記の通りなのですが、しばらく待つ必要がありますのでご注意ください。

別途、未登録のリソースプロバイダーを登録するように改良もできますね。

Windows Server ＆ Cloud User Group Japan 第47回 勉強会セッション動画「Windows Admin Center 2410のPowerShell概要」

 

Windows Server ＆ Cloud User Group Japan 第47回 勉強会資料「Windows Admin Center 2410のPowerShell概要」

Windows Admin Center 2410のPowerShell概要_PowerShell Overview for Windows Admin Center 2410 by @sshzk

アジェンダは下記の通りです。

PowerShellコマンドレットの比較概要
構成管理関連コマンドレット
接続管理関連コマンドレット
拡張関連コマンドレット
管理関連コマンドレット
移行関連コマンドレット
PowerShellTools関連コマンドレット
まとめ
参考情報
---
Comparison of PowerShell cmdlets
Configuration Management Cmdlets
Connection Management Cmdlets
Extensibility Cmdlets
Management Cmdlets
Migration Cmdlets
PowerShell Tools Cmdlets
Summary
Reference Information

Public Preview of AI Shellのパブリックプレビュー その4

Public Preview of AI Shellのパブリックプレビュー その3 の続き。

AI ShellからAzure OpenAIを使う準備を調べています。

注）Azure OpenAIは、パブリックエンドポイントで試しています。別途プライベートエンドポイントも試す予定です。

az login --tenantでテナントIDを指定してAzureへ接続後の状態から進めます。

Start-AIShellにてAI Shellを起動後、「openai-gpt」を選んで続行します。

そうすると「/agent config」で構成を編集して「/refresh」せよとあるので、そちらを対応します。

エディターの選択画面が出ました。メモ帳を選んで「Just once」をクリックし続行します。

構成ファイルが開きました。

あとで気づくのですが、/*と*/で複数行コメントアウトになっています。これに気付かず必要な設定をしたつもりで、アクティブとする名前を指定したもののエラーを連発しました。

/*と*/で複数行コメントアウトを外したものの、今度はAzure OpenAIのモデルが新しすぎるために動かないということになりました。

gpt-4oでモデルをデプロイします。

「/agent config」で構成を編集して「/refresh」を実施しました。構成エラーは解消したと思われたのでプロンプトを入力したところ、API Keyが違うといわれてエラー。モデルのキーを与えていますが、そちらではないようです。

まだ理解不足のようなので、いったんCopilot in Azureに切り替えられるかを試します。「/agent use azure」で切り替えできます。

プロンプトを与えて動作確認したところ問題ないですね。

ということで、Azure OpenAIへの接続を改めてトライすることとします。キーとエンドポイントのキーを入れてみます。

プロンプトを与えてみたけど、API Keyのエラー。エラーメッセージをよく見てみるとOpenAI自体のキーを入れる必要がありました。

OpenAI自体のキーを生成します。

「/agent config」でOpenAI自体のキーを構成に記載して「/refresh」を実施しました。クォータに引っ掛かりましたが、OpenAI自体のキーを構成に記載するので良いと確認できました。

OpenAI自体のクォータを解除しないと先に進まない（そういえば課金プランは申し込んでないw）ので、確認はいったんここまでにしておきます。

2025/05/25 追記
AI Shellの使用方法については、下記をご参照ください。
Get started with AI Shell

Windows Server 2025に含まれるwingetを使ってPowerShell 7をインストール

Windows Server 2025にPowerShell 7をインストールしたくて、調べました。結果、

WinGet (推奨) を使用して PowerShell をインストールする

を確認しました。MSIなどでインストールするのかと思いましたが、Windows Server 2025からwingetを使う方法がありました。wingetは、Windows 11や最新バージョンのWindows 10で使えるそうですね。

WinGet (推奨) を使用して PowerShell をインストールする

に沿って「winget search Microsoft.PowerShell」を使いPowerShellのパッケージを検索してみます。

WinGet (推奨) を使用して PowerShell をインストールするに記載通り、通常版とプレビュー版の両方が表示されましたね。

続いて「winget install --id Microsoft.PowerShell --source winget」を使いPowerShell 7.5.1をインストールします。

ちなみに、「winget help」を実行すれば、--proxyオプションを使えることがわかりますね。

Public Preview of AI Shellのパブリックプレビュー その3

Public Preview of AI Shellのパブリックプレビュー その2 からの続き。

前回は、AI ShellのバックエンドとしてCopilot in Azureを指定しました。

では、同じプロンプトを与えるCopilot in Azureと、AI ShellのバックエンドとしてCopilot in Azureを指定した場合は、同じなのか違うのかを見ていきます。

結論としては、回答が違いました。同じなのが良いのかという点に関しては言及を避けますが、こういう結果になることがあると思っておくのが現状良いかもしれませんね。

「Azure リソースの正常性を確認する方法を教えてください。」というプロンプトを与えた場合

Copilot in Azure

AI ShellのバックエンドとしてCopilot in Azureを指定

興味深いのは、日本語のプロンプトを解釈し結果は英語を返してくれました。

「How do I convert ARM template to Bicep?」というプロンプトを与えた場合

Copilot in Azure

こちらはなぜかうまく出なかったです。

AI ShellのバックエンドとしてCopilot in Azureを指定

こちらは具体的な方法を言及しようとしていると思えました。ということで、もう少し具体的なプロンプトが提示されたのでそれも試してみることにしました。

「How do I use Bicep CLI to convert ARM templates?」というプロンプトを与えた場合

Copilot in Azure

Bicep CLIをインストールしてから、ARM templatesをBicepにデコンパイルする方法を紹介されました。

AI ShellのバックエンドとしてCopilot in Azureを指定

こちらも、Bicep CLIをインストールしてから、ARM templatesをBicepにデコンパイルする方法を紹介されました。

追伸
日本語環境でも、Copilot in Azureが使えるようになりましたね。

Public Preview of AI Shellのパブリックプレビュー その2

Public Preview of AI Shellのパブリックプレビュー からの続き。

※ちなみに、Azure PowerShellからAzureに接続するパターンも試しましたがNGでした。

Public Preview of AI Shellのパブリックプレビュー に掲載している画像にあるのですが、Azure CLIで接続しないとだめのようですね。

この環境には、Azure CLIがインストールされていないのでそこから始めました。

インストールしたのは良いが、パスが通っていないのでやむを得ず再起動。（今にして思えば、サインイン/ログオンし直しで良かったような）

複数サブスクリプションあるため、az loginだけだとだめでございます。

az login --tenantでテナントIDを指定してAzureへ接続します。

Announcing the Public Preview of AI Shell の記事に戻りまして、Start-AIShellにてAI Shellを起動します。

Copilot in Azure を選びました。

無事に認証が通っています。

サンプルのプロンプトを入れてみました。問題なく動いたようです！

exitでAI Shellを終了できます。