オンプレ環境からAzureに端末を移行する方法ですが、Azure MigrateというAzureネイティブのツールがあります。物理マシンをはじめ、Hyper-VとVMware上のVMもAzure環境に移行することができます。特に移行端末は多数の場合はより便利だと思います。
また、VMwareのVMなら「エージェントレス」と「エージェントベース」の2種類の移行方式があります。前者はVMware側のVMにエージェント（アプリ）をインストールせずにより簡単に移行できます。
今回はオンプレ（自宅環境）にある物理マシンをIaaSのAzure VMへの移行手順を書きます。次回以降はオンプレのVMware VMをAzure VMに移行する手順（エージェントレスとエージェントベース）も記事にする予定です。
■ Azure Migrateとは
Azure MigrateはMicrosoft Azureが提供する移行用ツールとして機能は大きく評価と移行の２つがあります。
評価は移行対象マシンのAzureへの移行可否の判断、移行後のVMのサイジング、費用見積、移行マシン間の依存関係等を移行前に評価する機能です。
移行は対象マシンの検出からAzure VMへのデプロイまで一覧の作業を一貫して実施する機能です。ちなみに、評価で生成されたVMサイジングの結果はVMをデプロイする時に利用できるので、移行時にマシンごとにVMのスペックを手動で設定する手間を省けるので、とても便利です。※もちろん評価を実施せず、移行のみを実行することは可能です。
===========================
Azure Migrate公式ドキュメント
===========================
さて、早速はじめましょう！
まずは作業実施の前提条件と事前準備の説明です。
■ 前提条件
1.自宅環境にある物理マシン（1台）をAzure VM（IaaS）に移行します。
2.自宅環境とAzureは通信可能です。ここから
3.移行ツールはAzure Migrateのみ使用します。
4.移行の通信はAzure PrivateEndpoint（APE）で行います。
5.Azure Migrateアプライアンスサーバ（AMA）と移行対象の物理マシンは通信可能です。
6.Azure側の操作はすべてAzure Portal上で行います。
■ ネットワーク構成
自宅環境とAzure間はS2S VPNで繋がるが、Azure側はHub&Spokeの構成です。
自宅とAzureのSpokeVNETの通信はAFW（Azure Firewall）を経由します。
移行時に使用するAPE、Key vault、Storage Account、Private DNS ZoneはAzure Migrateツールが自動作成するがSpokeVNETおよびそのVNETのSubnetに配置します。
※各VNET、Subnet、AFW、VPN Gatewayは事前に作成と疎通検証を済ませておきます。（各リソースの作成手順はここで割愛します）
 |
|---|
※赤い線は通信ルートを示すものです。
■ 通信イメージ
物理マシン、Azure Migrate アプライアンス（AMA）とAzure Migrate Portal間の通信ポートと通信データは下記通りです。
 |
|---|
■ お勧めの事前準備
1.Migrate関連リソース用のResource Groupの作成
※移行後の関連リソースの削除だが、専用RGにまとめておくと削除しやすいため
2.命名ルールの決定
※移行関連リソースを認識しやすくするため
ここからはAzure Migrateを使って、移行対象マシンの評価を行う手順をStepに分けてについて説明します。
【Step1】- Azure Migrateのプロジェクトの作成
1. Azure Migrateのメイン画面を開き、プロジェクトを作成します。
 |
|---|
↓
 |
|---|
↓
 |
|---|
2. 必要情報を入力して、最後に「Create」をクリックして作成します。
- Resource groupは事前に作成したものを選択
- 「Advanced」の入力項目を入力
-- Private Endpointで接続
（※Azure MigrateはPublic EndpointとPrivate Endpointの両方をサポートするが、実際に企業はオンプレ環境とAzureをS2S VPNまたはExpressRouteで接続するケースが多いので、Internet経由せずにPrivate Endpointで繋がることを想定して、今回もPrivate Endpointで接続します。
-- 「disable public network access」について：Private Endpointで接続を選択すると、この項目が表示されますが、Internetからの接続を無効にするかの項目です。Azure Migrateは一部のサードパーティーの移行ツールをサポートしているが、それらのツールはInternet接続が必要の場合があるので、"No"にしたほうがいいです。しかし、今回はAzure Migrateのみ使うし、S2S VPNで2環境を接続済みなので、"Yes"にしてみましょう。
-- VNETとSubnetを事前に作成したものを選択
 |
|---|
↓
 |
|---|
3. 作成後にAzure Migrateのホーム画面は以下通りです。
- プロジェクトは作成時に入力したプロジェクト名になっています。複数プロジェクトを作ることが可能なので、プロジェクト間の切り替えはプロジェクト名のところをクリックして、プルダウンメニューから選びます。
- カテゴリは大きく「Assessment」（評価）と「Migration」（移行）の２つです
（この記事は「評価」について記載します）
 |
|---|
 |
|---|
【Step2】- 物理マシンを検出するためのAzure Migrate アプライアンス（AMA）のインストール
Azure Migrate アプライアンスの公式ドキュメント
移行対象の物理マシンの情報をAzure Migrateプロジェクトに連携するために対象マシンとAzure Migrate間の仲介役としてAMAをオンプレ側のサーバにインストールする必要があります。これからこのAMAをインストールします。
1. Azure Migrateの「Assessment Tool」の「Discover」をクリックします。
 |
|---|
↓
- AMAの導入以外にCSVをアップロードする方法もあります
- AMAをインストールするサーバの種類を選択するが、今回は物理マシンの移行なのでPhysicalを選択します。
 |
|---|
<1.プロジェクトキーを生成する>
AMAをAzure Migrateのプロジェクトに紐づけるためにAMAをインストールする際に入力が必要のプロジェクトキーを生成します。
- AMA名を入力
- 「Generate Key」をクリック（生成するには時間がかかります：実績約10分ほど）
- プロジェクトキーが生成されたことを確認
 |
|---|
注意
AMAは複数作成が可能ですが、それぞれにユニークなプロジェクトキーが必要です。
一度Discoverの画面を閉じ、再度開くと新しいプロジェクトキーの生成が可能になります。一方で、生成済みのプロジェクトキーは「Generate Key」の横にある"Manage existing appliances"をクリックしたら確認できます。
 |
|---|
<2.AMAスクリプトのダウンロード>
AMAのスクリプトをダウンロードします。
 |
|---|
↓
500MBほどのサイズなので、可能ならAMAをインストールするサーバでダウンロードしたほうがいいかもしれないです。
 |
|---|
注意
＜これ以降のStep2およびStep3の操作はAMAをインストールするサーバ上で行います＞
<3. Azure Migrate アプライアンス（AMA）のインストール>
AMAをインストールするサーバ（AMAサーバ）の前提条件等はこちらで確認できます。
 |
|---|
↓
ZIPファイルを解凍して、フォルダにあるReadMeを開きます。
 |
|---|
↓
Powershellを管理者モードで起動し、ReadMEの#4に記載されているコマンドを実行します。
実行するスクリプトは"AzureMigrateInstaller.ps1"という名前ですが、Powershellでスクリプトのフルパス※を入れて実行します。
※環境変数にフォルダパスの設定がないと、パスを見つからないため
 |
|---|
↓
もし、同じサーバに既に別のAMAが入っているなら、下記赤文字の部分が表示されますが、"Y"を押すと以前のAMAを自動的に削除してくれます。
 |
|---|
↓
次は順次に質問を答えていきます。
- 今回は物理マシンの移行なので 3．Physical or other（AWS、GCP、Xen、etc.）を選択
- 今回はUS政府でもChinaでもないので、1. Azure Publicを選択
- 今回はPrivate Endpoint経由で接続するので、2. set up an appliance for a Migrate project created with private endpoint connectivity.
※Private Endpoint経由での接続の場合、AMAサーバは必ずPrivate Endpointが到達可能なネット環境に配置されていることが前提です。
ここまでの入力を確認し、問題なければ、最後の質問で"Y"を答えたら、インストールが開始します。
 |
|---|
↓
 |
|---|
↓
インストール終了（"You may use..."というメッセージは最後に表示されます）
 |
|---|
【Step3】- Private EndpointのDNS情報の登録
Private EndpointでAMAをAzure Migrateに接続する場合、Private EndpointのFQDNの名前解決が必要です。それらの情報をAzure Migrate上でダウンロードできます。ダウンロードしたDNS情報をDNSサーバまたはAMAサーバのhostsファイルに入れます。
今回はhostsファイルに追加する方法を記載します。
注意
DNS情報を正確に登録しないと、Step4のところでPrivate Endpointと正常に接続できないエラーが発生しますので、必ず登録しておきましょう。
1. Azure Migrateの「Assessment tools」の「Overview」(概要)をクリックします。
 |
|---|
2. サイドメニューの「Properties」をクリックします。
 |
|---|
3. スクールダウンして「Download DNS settings」をクリックしてダウンロードします。
 |
|---|
4. ダウンロードしたDNS情報（txt）をhostsファイルに追加します。hostsファイルは"C:\Windows\System32\drivers\etc"に配置されています。
※hostsファイルは読み取専用のため、一旦他の場所にコピーし、更新してから元ファイルを上書きする方法で対応します。
 |
|---|
↓
 |
|---|
↓
 |
|---|
5. AMAサーバを再起動します。
【Step4】- AMAサーバをAzure Migrateに登録
1. AMAを起動します。
AMAを入れた後、AMAサーバのデスクトップに生成された「Azure Migrate Appliance Configuration Manager」をダブルクリック
 |
|---|
↓
下記画面が表示されます。
 |
|---|
2. プロジェクトキーを入力します。
少しスクールダウンして、プロジェクトキーを入力します。
 |
|---|
（まだ覚えていますか？（笑）、プロジェクトキー、、、どこかであったような、、、気がして、、、Azure Migrateで生成したものです↓）
 |
|---|
↓
プロジェクトキーを入力し「検証」をクリックしたら、プロジェクトキーの認証が行われます。検証が成功したら、"Azure Migrateプロジェクトキーが検証されました"のコメントが表示されます。
 |
|---|
3. AMAの自動更新状態をチェックします。
プロジェクトキーが検証されたら、AMAの状態チェックを自動的に行われます。今回の結果は下記通り、状態の利用はできないとの表示があったが、青字の「アプライアンスサービスの表示」をクリックしたら、すべてのサービスのバージョンは最新になっていることを確認できます。状態は"停止済み"のエージェントがありますが、初回起動のためこれで問題ありません。後続の登録が全部済ませたら、"実行中"になります。
 |
|---|
↓
 |
|---|
4. Azureへのログインをします。
ログインボタンをクリックしたら、下記図の通りにAzureへのログインを行います。
 |
|---|
↓
下記ダイアログが表示されたら、「コードのコピーとログイン」をクリックし進めます。
 |
|---|
↓
なぜか先ほど表示されたコードの入力を求められるが（あんまり意味がないではと思っているが、、、）、まぁ、ペーストし「次へ」をクリックします。
 |
|---|
↓
Azureにログインするアカウントを選択または入力します。
そのアカウントに必要なロールは下記の公式ドキュメントに記載しています。
 |
|---|
今回は「サブスクリプション所有者」のロールを持つアカウントを使います。
 |
|---|
↓
ログイン後に下記メッセージが表示されたら、そのタブを閉じても大丈夫です。
 |
|---|
↓
アプライアンス画面に戻ると、Private Endpointでの接続を選んだ場合は「DNSでの名前解決を正確に設定しましょう」という注意喚起のダイアログが表示されます。
注意
Step3で説明したPrivate Endpointの名前解決の対応が完了しなかった場合は下記メッセージが表示されます。「エラーの詳細」をクリックし、エラー内容を確認できます。
 |
|---|
↓
 |
|---|
↓
接続は完了したら下記メッセージが表示されます。
 |
|---|
注意
Step4まで登録した情報に変更があった場合は下記「前提条件の再実行」をクリックし更新を行う必要があります。
 |
|---|
ここまでAMAサーバの情報をAzure Migrateに登録できました。ここからは移行対象となる物理マシンをAMAサーバ経由でAzure Migrateに登録する手順となります。
【Step5】- 物理マシンの資格情報（ログイン情報）の登録
登録するのは物理マシンにログインできるアカウント情報と物理マシンへの接続情報の両方です。
下記画面の「2．資格情報と検出ソースの管理」エリアの操作になります。
 |
|---|
1.「資格情報の追加」ボタンをクリックします。
 |
|---|
2. 物理マシンの資格情報（ログイン情報）を入力し「保存」をクリックします。
※今回はWindows Serverの移行を想定します。移行対象が複数台の場合はそれぞれマシンの資格情報を全部登録する必要があります。同じ資格情報を使用する場合は登録が1回で大丈夫です。
 |
|---|
3. 登録済みの情報は下記のように表示されます。
 |
|---|
【Step6】- 物理マシンの接続情報の登録
物理マシンへの接続情報の登録となります。
1. 手順2の「検出ソースの追加」をクリックします。
 |
|---|
2. 追加方法を選択し、接続情報を入力します。
※追加方法は「単一の項目を追加する」、「複数の項目を追加する」、「CSVのインポート」の3つがあり、対象マシンは大量にある場合は指定のCSVフォーマットに必要な情報を記入しアップロードしたほうが楽かもしれないが、今回は1台のみなので、「単一の項目を追加する」を選択します。
 |
|---|
↓
＜単一の項目の追加＞
マシンのタイプとIP(or FQDN)、先ほど登録した資格情報を選択し最後に「保存」をクリックします。
 |
|---|
注意
ここでAMAサーバと物理マシン間に通信が発生しますが、ポート5985を使うので、ポートの開放を忘れずに。
ポートの通信不可や資格情報の誤り、もしくは別の理由で下記のように検証が失敗したケースがありますが、この場合は"Validation failed"をクリックし失敗の理由を確認できます。再度検証を行うには「再検証」をクリックします。
 |
|---|
 |
|---|
実際に作業中に発生した２つのエラーと解決方法はこの記事の最後に記載があります。
↓
問題なく検証が終わったら、下記のように表示されます。
 |
|---|
3. 物理マシンにWeb AppsまたはSQL Serverが入っている場合はそれらの機能の検出も可能ですが、特になければ「これらの機能・・・これは後で変更できます）」のチェックをOFFにします。（今回の物理マシンにはこれらの機能はないのでOFFにします）
 |
|---|
【Step7】- 物理マシンの検出
マシンの資格情報と詳細情報（IPアドレスと資格情報のログイン可否の検証）を登録しました。次はこれらの情報を使って、対象マシンの情報を抽出しAzure Migrateに登録する作業を実施します。
1. 「検出の開始」をクリックします。
 |
|---|
↓
Private Endpointを使用する場合は下記メッセージが表示されます。
 |
|---|
↓
検出対象の台数と1台当たりの所要時間の記載がありますが、ネット環境と物理マシンのスペック等の要素によって所要時間は変わります。数分以上かかうのがほとんどです。
 |
|---|
↓
実際に5分ほど待っていましたが、下記メッセージが表示され検出は完了しました。
 |
|---|
↓
マシン登録のところを確認したら、「状態」は"Discovery Initiated"になっていたことがわかります。
 |
|---|
【Step8】- 物理マシンの登録結果の確認
AMAサーバ上の作業は一旦これで終わります。次はAzure PortalのAzure Migrateに移り、登録したマシンの情報を確認します。
1. Azure Migrate Portalへアクセスします。
Azure Migrate Portalのプロジェクトのホーム画面の全体はこんな感じになっています。
 |
|---|
↓
評価ツールのところを見ると、「検出済みサーバー」は"1"になっています。OSディストリビューションのWindowsも"1"になっています。評価アプライアンス（AMAサーバ）は1台なので"1"になっています。
 |
|---|
2. 検出された物理マシンを確認します。
「検出済みサーバ」の"1"をクリックし、検出済みサーバの一覧に登録した物理マシンの情報を確認します。
 |
|---|
↓
ご覧の通り、一部項目のステータスは"検出中"、"検証が進行中"となっていますので、基本はAMAを閉じず、AMAサーバと物理マシンの電源をONのままにしておいてください。
 |
|---|
【Step9】- 「ビジネスケース」と「依存関係の分析」について
1. 「ビジネスケース」
「ビジネスケースの構築」は一定規模の移行PJTをまとめて管理、進行するための便利なツールですが、今回は評価手順のおさらいなので割愛させていただきます。
 |
|---|
 |
|---|
2. 「依存関係の分析」
移行はほとんどの場合において対象マシンは複数台があり、かつ場合によってはサーバ間の依存関係は十分に把握できていない可能性があります。この機能は登録済みの対象マシン間の依存関係の分析を行えます。
※あくまでもAzure Migrateが検知可能な範囲の分析であるため、必ず管理者や使用者など関係者が持っている依存関係情報とクロスチェックを行ってください！
初めて評価対象マシンを登録した後、依存関係の分析は自動的に行うようになっているため、「依存関係の分析」の「サーバの追加」をクリックしても、対象サーバの選択は非活性になっています。
 |
|---|
↓
※AMAサーバは複数台がある場合は「アプライアンスを選択する」のプルダウンメニューからAMAサーバを選択します。また、依存関係の分析は選択台数の数によって時間がかかることがあります。
 |
|---|
【Step10】- 評価
「評価」はAzure VM以外にAzure SQL、App ServerまたはAVS（Azure VMware Solution）として移行するケースの評価も可能です。今回はオンプレ → VMなので、"Azure VM"を選択します。
 |
|---|
1. 評価の種類と検出ソースを選択します。
「評価の種類」は前述と同じくAzure VM以外にAzure SQL、App ServerまたはAVS（Azure VMware Solution）として移行するケースの評価も可能ですが、ここでは"Azure VM"を選択します。
 |
|---|
↓
「検出ソース」はアプライアンスから検出されたマシンと直接にインポートされたマシンの2択があるが、今回はAMAサーバ経由で登録したため、前者を選びます。
 |
|---|
2. 評価の設定をします。
ここは移行対象マシンをAzure上に移行した後のVMのスペックや費用などの情報を評価するための設定を行います。同じマシンに対して設定条件を変えて、いろんなシチュエーションで何回も評価が可能です。
「編集」をクリックします。
 |
|---|
↓
条件を設定します。
 |
|---|
↓
ここでいくつの項目を説明します。
1). 「ストレージの種類」
 |
|---|
Azure VMで使用するディスクの種類のことで選択肢は3つあるが、最初からこれを使うと決めていたら、その選択だけにチェックを入れるが、評価に任せるなら3つともチェックを入れて構いません。
2). 「節約オプション」
 |
|---|
これはAzureに詳しくない人はわかりにくい項目ですが、節約オプションは所謂リザーブドインスタンス（Reserved Instance）のことです。予め1年または3年の利用権を事前に予約（確保）することで割引を適用できるサービスです。
特にその予定がなければ、一旦"なし"で構いません。
3). 「VMサイズ」
 |
|---|
Azure VMのサイズ（スペック）を評価する際にパフォーマンスベースに基づくか、純粋にオンプレミスのスペックに基づくかの違いです。二者の違いは下記MS公式ドキュメントの記載があります。
また、各項目名の横にある"！"にカーソルを合わせると説明が表示されます。
 |
|---|
4). 「オファーまたはライセンス プログラム」
Azure VMを格納するサブスクリプションはEA契約に紐づいていれば、"EA契約"を選択します。
 |
|---|
EA契約と紐づいていないサブスクリプションにAzure VMを置く場合は"従量課金制"または"pay as you go Dev/Test"のどっちかを選択します。
 |
|---|
5). 「Azure ハイブリッド特典」
 |
|---|
有効なWindows ServerのライセンスをAzure VMに適用する場合にはこの項目を"はい"を設定します。（結構な割引になります！）
例として下記のように設定して、「保存」します。
 |
|---|
3. 評価を実施します。
「評価するサーバの選択」をクリックします。
 |
|---|
↓
必要情報を入力し「評価の確認と作成」をクリックします。
 |
|---|
↓
「評価の作成」をクリックします。
 |
|---|
↓
「通知」に下記メッセージが表示されますが、評価結果が出るまで時間がかかることがあります。
 |
|---|
↓
Azure Migrateの「最新の情報に更新」をクリックします。
 |
|---|
↓
評価が終わったら、下記通りにカテゴリ「評価」の「合計」に数字が"1"になります。評価は複数回実施されていた場合は評価結果の合計数が表示されます。
 |
|---|
4. 評価結果を確認します。
カテゴリ「評価」の合計またはAzure VMの数字をクリックし評価結果の一覧画面に移動します。先ほど作った評価の結果は出力されていたことを確認できます。
 |
|---|
一番右側の項目「信頼度の評価」ですが、現時点で物理サーバの評価に適用されていないので、"適用できません"と表示されています。また、信頼度の内訳と信頼度を向上する方法は下記公式ドキュメントに記載されています。
↓
評価結果をクリックし結果を表示します。
 |
|---|
まずは「概要」欄にAzureへの対応性（移行可否）、移行後のVMの月額とストレージ（タイプを含む）の月額の3つのグラフがあります。下方に評価結果の月額総費用が表示されています。
VMの月額にはストレージの月額は含まれているが、なぜ金額を別表示にしているかというと、あくまでも個人的の考えですが、VMを停止した場合、CPUやメモリ等の従量課金分は発生しないが、ストレージの従量課金は常に発生します。つまり、VMを1か月フル稼働の場合はVMの月額が発生するが、1か月フル非稼働にしてもストレージ分の月額は発生するため、金額を別々に記載し、わかりやすくするためかと思っています。
↓
サイドメニュー「Azure 対応性」にて評価結果のAzure VMの詳細を確認できます。VMのスペックと移行する場合の前提条件（条件付き）、推奨される移行ツールとブート方式の記載もあります。
 |
|---|
↓
サイドメニュー「コスト詳細」にて月額費用の詳細も確認できます。要注意なのはグラフの方のコンピューティングコストはAzure ハイブリッド特典抜きの純粋の月額費用です。右下の赤枠はAzureハイブリッド特典を適用後の月額費用になります。
 |
|---|
↓
評価結果はエクスポートすることは可能です。また、「設定」で条件を変更し、「再計算」で計算しなおすことも可能です。
 |
|---|
まとめ
今回はオンプレ環境にある物理マシンをAzure Migrateへの登録、評価の手順をまとめましたが、いかがでしょうか？
初回の設定として手順はそれなりにありますが、AMAサーバを一度設定できたら、1台のAMAサーバは最大1000台のマシンの移行を対応できますので、1000台サーバを手動での移行と比較したら楽の方かもしれないですね。
では、次回は実際に移行の方の手順をまとめてみたいと思います。
Reference
移行対象マシン認証時に発生したエラーのトラブルシューティング
■ WinRM（Windows Resource Management）に到達不可に関するエラー
 |
|---|
WinRMは移行対象マシンの認証時に必要です。このエラーの原因は大きく以下3つを考えられます。
- 資格情報として選択したユーザは移行対象マシンのユーザグループ「Remote Management Users」に所属していないか、そもそもそのグループ自体が存在ないか
- そもそもWinRMは立ち上がっていない
- FWかProxyサーバの設定によってWinRMとの通信(port:5985)は拒否されている
では、それぞれの原因の対策方法を説明します。
1. ユーザグループ「Remote Management Users」にユーザを登録します。
1). 移行対象マシンにてWindowsマークを右クリックし、「コンピュータの管理」をクリックします。
 |
|---|
2). サイドメニューの「ローカルユーザとグループ」→「グループ」に移動します。
→「Remote Management Users」の存在有無を確認。なければ、グループを新規作成します。
 |
|---|
3). グループに入って、資格情報として選択したユーザはグループに所属しているかどうかを確認。所属していなければ追加します。
 |
|---|
2. WinRMを立ち上げます
WinRMはサービスの１つとしてマシン起動時に立ち上がるかしないかの設定が可能です。マシンによってはマシン起動時にWinRMを起動しない設定になっている可能性もあるので、設定を確認して起動時の自動起動をONにしておきます。
1). 移行対象マシンにてWinキー＋Rをクリックし、実行コマンドに「services.msc」を実行します。
 |
|---|
2). サービス一覧から「Windows Remote Management」の状態を確認します。「実行中」以外の場合は手動で起動します。
 |
|---|
↓
「開始」をクリックします。
 |
|---|
↓
サービスの状態は"実行中"になっていることを確認します。
 |
|---|
3. WinRMの通信port:5985を穴あけします。
FWまたはProxyを利用の場合、port:5985の通信を許可する必要があります。ここではWindows Defenderでの穴あけの設定を説明します。サードパーティーの製品の場合は製品の手順に合わせて対応してください。
1). 移行対象マシンでWinキーをクリックし、"fire"を検索します。結果から「ファイアウォールの状態の確認」を選択します。表示された画面にて"接続済み"のネットワークを確認してください（覚えてくださいｗ）※下記画面の場合は「パブリック ネットワーク」になります。
 |
|---|
2). 移行対象マシンでWinキーをクリックし、"security"を検索します。結果から「セキュリティが強化されたWindows Defenderファイアウォール」を選択します。
 |
|---|
3). サイドメニューの「受信の規則」にて「Windows リモート管理（HTTP受信）」を特定してください。ここで同じ名前の項目は２つがあるが、#1で覚えていたネットワーク（今回はパブリック ネットワーク）の方の項目を有効にします。
 |
|---|
↓
 |
|---|
↓
 |
|---|
■ The WMI service returned an 'access denied' error.（ WMI サービスはアクセス拒否エラーを返しました"）というエラー
 |
|---|
このエラーはMS公式ドキュメントのトラブルシューティングにも記載があります。
詳細はドキュメントをご参考ください
以上