vSAN環境で L3-vMotion を行うには?

CJです。

vSphere 6環境において L3経由での vMotionが行えること、知っていますか?

構成によって、L3 vMotionを使用するケースもあると思います。

今回はそういったことが、実際可能かどうか、せっかくなので vSAN環境上で試した結果を共有したいと思います。

 

まず、想定している検証の構成は以下のとおりです。

今回、表側の分散スイッチ経由で vMotionを行うテスト内容となります。合わせて dvPort は予め作成されていることを前提としています。

環境構成

・vCenter 1つの配下に、CLUSTERが 2つ(AとB)存在し、各クラスタは vSAN構成が有効になっています。

・CLUSTER_A(vSAN)上で動いている仮想マシン(CJ_VM01)が、L3経由で CLUSTER_Bへ vMotionを行います。

・L3は vyOSを利用します。

・Version 情報: vSAN 6.2、CentOS6 (CJ_VM01)、vyOS(1.1.7)

 

 

では、早速各パーツごとに設定を見ていきましょう。

仮想マシン (CJ_VM01)

普通にネットワークインターフェースに適切な IPアドレスの設定を行う。

クラスタA側のvyOS (CJ_vyOS1)

各インターフェースの設定を行い、その後スタティックルーティングを行う。

#vyOS設定後、#commit と #save も忘れずに~ (ここでは省略しています。)

クラスタB側のvyOS (CJ_VYOS2)

構成に合わせて各インターフェースの設定を行い、その後スタティックルーティングを行う。

VMkernelの追加 & TCP/IP スタック (vSphere)

vMotion用の VMkernelアダプタを両クラスタの各ESXi に追加する。

TCP/IP スタック設定で、vMotion 用 VMkernel のゲートウェイの設定を行う。

TCP/IP スタック (vMotion) に、IPv4 ゲートウェイが設定されていることがわかります。

これで、設定は完了です。 後は移行(vMotion)を試してみてください。

自分のテスト環境においては、vSANデータストアの移行を含め、仮想マシンが正常に vMotionができることが確認できました。

 

普段、vSphere 環境で vMotionは L2接続状態の環境で使うことが多いかと思いますが、移行のシナリオなど各自の状況によっては L3を経由するシナリオが出て来るかもしれないです。その際には、本記事が少しでもお役に立てればと思います。

 

[参考情報]

ESXi ホストの vMotion TCP/IP スタックへの vMotion トラフィックの配置
https://docs.vmware.com/jp/VMware-vSphere/6.0/com.vmware.vsphere.vcenterhost.doc/GUID-5211FD4B-256B-4D9F-B5A2-F697A814BF64.html

Configuring the vMotion TCP/IP Stack for Layer 3 vMotion Across ESXi Hosts

Configuring the vMotion TCP/IP Stack for Layer 3 vMotion Across ESXi Hosts

vSAN オンディスク フォーマットとは?

CJです。

vSANにはファイルシステムフォーマットがあり、それをオンディスクフォーマットと呼んでいるようです。 ところが、VMware 製品関連でよく聞き慣れているファイルシステム名としては、VMFS、VSANFSなどもあり、混乱しやすいのではないかと思います。そのため、今回はvSANにおけるファイルシステム名の違いを簡単に整理して共有したいと思います。

 

早速、簡単に比較表でまとめてみました。

上記表にあるバージョン情報をvSAN環境で確認するには、

vSphere Web Client上の “クラスタ > 管理 > 設定 > Virtual SAN 全般” から確認できます。(例. vSAN 6.2環境 : 3.0 の最新となっています。)

以下の通りに、RVC (Ruby vSphere Console) からもオンディスクフォーマットのバージョンが確認できます。

vsan.disks_stats localhost/DC名/computers/CLUSTER名

vsan.disks_info

ちなみに、RVCは以下のパスで起動できます。(例. Windows Server 12R2 環境)

C:\Program Files\VMware\vCenter Server\rvc\rvc.bat

以上、簡単ではありますが、オンディスクフォーマットのバージョンの違いおよびバージョンの確認方法の共有でした。 vSANのファイルシステム名で混乱している方、vSANバージョンアップを検討中でオンディスクフォーマットのバージョンを確認したい方などへ少しでも役に立てればと思います。

 

[参考情報]

VMFS-L
https://books.google.co.jp/books?id=GHI3DAAAQBAJ&pg=SA3-PA109&lpg=SA3-PA109&dq=VMFS-L&source=bl&ots=bCNuuvV9sn&sig=onPiESvJUUJs54RCzlNuZBjzioc&hl=ja&sa=X&ved=0ahUKEwiN2IXS6erVAhVBTLwKHe74DrIQ6AEISTAE#v=onepage&q=VMFS-L&f=false

VSANFS
https://www.packtpub.com/mapt/book/virtualization_and_cloud/9781784399252/9/ch09lvl1sec47/the-new-on-disk-format

vSAN オンディスク フォーマットのバージョンと互換性について (2147615)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2147615

vSAN 6.6.1 がリリースされました。

CJです。

先日、ESXi 6.5 Update 1 のリリースに合わせて、vSAN6.6.1 がリリースされました。

新機能としては、以下の3点が挙げられます。

  1. VMware Update Manager (VUM) に vSANが統合されました。 #VUMを通して通常の vSphere 環境と同じく vSANのバージョンアップなどを行うことができるようになりました。
  2. パフォーマンス診断ができるようになりました。
  3. vSANディスク上のLEDロケーターサポート向上 (HPE Gen-9 Controller : pass-through mode)

 

せっかくなので、以下 vSAN6.2 ~ 6.6.1 までの追加された新機能の一覧表を共有します。

vSAN の成長と伴う新機能の追加が今後も楽しみです。

 

[参考情報]

http://pubs.vmware.com/Release_Notes/jp/vsan/62/vmware-virtual-san-62-release-notes.html

http://pubs.vmware.com/Release_Notes/jp/vsan/65/vmware-virtual-san-65-release-notes.html

http://pubs.vmware.com/Release_Notes/jp/vsan/66/vmware-virtual-san-66-release-notes.html

https://docs.vmware.com/en/VMware-vSphere/6.5/rn/vmware-vsan-661-release-notes.html

vSAN ディスク故障時、適切なディスク交換手順とは?

CJです。

前回は、vSAN環境でディスク故障時に仮想マシンが受ける影響について共有しました。

今回は、その延長でディスク交換の適切なオペレーション方法を共有したいと思います。

 

まず、前提となる構成は以下の通りです。

前提構成 & 故障シナリオ

vSAN:6.2 All-flash

ホスト : 6台

DiskGroup: 1Group/ホスト

※安定の2重故障まで対応可能な RAID-6相当の構成です。(FTT=2, RAID-5/6 Erasure Coding)

故障シナリオ:キャパシティディスク1本が故障

 

適切なオペレーションの流れ

以下、ディスク故障から復旧まで、全体的な流れとなります。

詳細

ディスク故障発生

ディスク故障が発生した場合、以下のようにディスクが Absent 状態になります。

ESXi : メンテナンスモード

実はホストをメンテナンスモードにせずに、この後のディスクグループの削除なども行えるケースもありますが、ディスク故障時においてはまずホストをメンテナンスモードに変更することを強くお勧めします。

Virtual SAN データの移行オプションとしては、RAID-6相当の構成であること、別の空きディスクグループ (ストレージポリシーを守れる予備領域)が存在しないため、ここでは “データの移行なし” を選択しています。

故障ディスクが入っているホストがメンテナンスモードに変更されたら、次へ

GUI:対象 DiskGroup 削除

vSAN All-flash構成においては、キャッシュ または キャパシティどちらのディスクでも1本故障した場合は、そのディスクグループが使えなくなります。(vSAN 容量が減ります。)

この場合は、DiskGroupの再作成で復旧することが可能です。

参考:こちらの削除をCUIで行う場合は、以下のコマンドを活用してください。

esxcli vsan storage remove -u [DISKGROUPのUUID] –evacuation-mode=noAction

物理:DISK交換

ホストがメンテナンスモードに移っており、ディスクグループが削除されていれば vSAN上でのディスク交換準備は完了です。この後に、物理ディスクを交換してください。

環境に合わせて、RAID-0の設定が必要な場合は忘れずに設定してください。

GUI:対象 DiskGroup 作成

ディスク交換が完了したら、ディスクグループを再作成します。

その前に、All-flash構成のため、忘れず交換したディスクにフラッシュマークをつけましょう。

続いて、DiskGroup を再作成してください。

これでDISK故障から復旧となります。

確認

vSANはディスクグループが復旧したら、バックグラウンドで自動的に最同期が走ります。

Tip>

vSphere Web Client 上で、最同期が進んでいることが確認できますが、こちらの表示がうまく表示されない場合は、下記のRVC (黒い画面)画面での確認を試してみてください。

 

まとめ

一通り流れをみてみましたが、いかがでしょうか。

ディスクグループの削除などはオンラインでできるケースもあるため、実際ディスク故障時には間違ったオペレーションにより、vSANの想定外動作につながるケースもあると思います。

そのため、本記事を参考に少しでも適切な運用手順において、本記事が役に立てればと思います。

Tip>

より、安定した vSAN環境の運用を行いたい場合は、”2DISKGROUP/ホスト” をお勧めします。

 

[参考情報]

https://docs.vmware.com/en/VMware-vSphere/6.0/com.vmware.vsphere.virtualsan.doc/GUID-9A2DCE0B-CFA1-41C1-97CE-DA56A55426EA.html

vSAN ディスク故障時の仮想マシンの操作はどうなる?

CJです。

vSAN 環境において仮想マシンのデーターは ErasureCoding 機能により、RAID6相当の2重障害まで保護が可能です。 ところで、実際 DISK障害などが発生した際に、RAID6相当範囲内であれば仮想マシンはまったく何の影響もなく、使えるんでしょうか?

結論から伝えると、仮想マシンのデーターは保護されている状態ですが、一部の操作については影響を受けることとなります。

以下、実際仮想マシンが障害時 (DISK障害想定) に受ける影響の一覧表です。

#環境情報:ホスト6台のRAID6相当の構成、1DISKGROUP/ホスト。

こちらの表を少し補足すると、

RAID6相当の環境 (2重障害まで許容)で、稼動中の仮想マシンが1台、停止状態の仮想マシンが1台があり、この環境でキャパシティ用のDISK 1本が故障した際の動作を確認したものとなります。

スナップショット

スナップショットは作成も、復元も使えなくなります。取得してあったスナップショット削除することは可能です。

移行

同一 vsanDatastore でのホスト移行 (vMotion) は可能ですが、クラスタを跨いだ移行は基本できなくなります。

クローン作成

クローン作成もスナップショットも同じく使えなくなります。

設定の編集

当然といえば、当然ですが、仮想ディスクのサイズ変更はできなくなります。

#仮想マシンのネットワークアダプタ変更などは可能です。

なぜ、このように操作ができなくなるの?

これは vSANの構成による仕様のようです。

vSANは DISKが故障した際にリペアを試みる動きを行いますが、上記構成では代替となる空き領域がなくてリペアが完了できない状態です。 また、上記の操作を行うには vSAN内部で Component を作成する形となりますが、物理環境上 RAID6相当を満たせない状態のためです。

DISK障害時にも、上記の操作ができるようにするには?

お勧めはやはり、ホストごとに2つのDISKGROUPを持つことです。

そうすると DISK故障時に vSANが自動的にリペアを試みて空き領域(同一ホスト内の別DISKGROUP or 別ホストのDISKGROUP)があれば、障害状況が復旧となり、スナップショット・クローン作成などの操作もできるようになります。

※他の障害 or 構成によっては別の方法での対応が必要な場合もあります。

 

以上、vSANの動きを知り、日常の運用において少しでも役に立てればと思います。

 

[参考情報]

https://docs.vmware.com/en/VMware-vSphere/6.0/com.vmware.vsphere.virtualsan.doc/GUID-9A2DCE0B-CFA1-41C1-97CE-DA56A55426EA.html

vROps 6.6から vSAN 情報をみてみたら?

CJです。

最近、vRealize Operations Manager 6.6 (以下、vROps)がリリースされたこと、知っていますか?

リリース当日にはまだ日本語のリリースノートページが公開されていなかったですが、今現在は日本語のリリースノートも公開されています。今回はそのリリースノートの中で、個人的にもっとも気になる以下の2点について紹介したいと思います。

・新しい HTML5 ユーザー インターフェイスは、より簡単で一貫性のある使用環境を提供します。

・ネイティブな vSAN 管理機能の追加:

– 複数のストレッチ クラスタにわたって一元的に管理できます。

– フォーマンス、キャパシティ、ログ、構成、健全性など、vSAN のすべてを管理できます。

まずは、既存の vROps と今回のUIがどう変更されたかをみてみましょう。

何か雰囲気変わっていること、わかりますか?

画面が小さくてわかりにくかったかもしれないので、改めて vROps6.6 のみの画面をみるとこんな感じです。

すごく見やすくなっていますね。vROps は非常に情報量が多い製品でもあるため、このような感じで見やすくなっているのはとても嬉しいです。

HTML5の新しいUIの雰囲気がわかったと思いますので、早速 vSANのネイティブ管理は実際どんな感じかも見ていきましょう。

左メニューバーにデフォルトで vSAN関連メニューが表示されていることがわかります。

また、3番のようにクラスターの構成状態および健全ステータスが一目で把握できるようにビジュアル的(3番)にも工夫されています。

下にスクロールしてみると遅延・輻輳している状態(6~8番)についても、簡単に状況が把握できるようになっています。

それだけではなく、やはりvSANではホスト・ディスクループの状態も確認したいと思いますが、そういった項目(11~15番)も予め用意されていることがわかります。

vROps といえば、このようなヒートマップのイメージが強いかと思います。

きちんと vSANクラスタに対してもヒートマップが用意されています。

ここまでは、vSAN トラブルシューティング時に参考となりそうな情報でした。

が、これだけではありません。まだ続きます。。

vSAN はキャパシティの管理が日々の運用において、とても大事ですが、そのキャパシティ関連情報が大変わかりやすく、一目瞭然に整理されています。

最後に、リソース枯渇までの日数などまで表示してくれます。

一通りみてみましたが、いかがですか?

vSANのキャパシティ情報を確認するためには、多くの方が基本 vSphere Web Client に接続をしてみたり、トラブルシューティングの際は PowerCLI または RVC などを使って詳細を確認してきたかと思います。また、既存の vROps ではカスタマイズのダッシュボードをユーザーが直接作成したり、あるいは関連パックを適用して使ったりしてきたと思います。

vROps6.6を使えば、このような日々運用上の負担および迅速なリソース状況の把握など、vSAN環境をより効率よく運用できるかと思います。もし、これから vSAN環境の使用を検討中の方がいらっしゃったら、vROps6.6も合わせて検討いただければと思います。

#一緒にパッケージングされているサービスを使う手もあります。

[参考情報]

http://pubs.vmware.com/Release_Notes/jp/vrops/66/vrops-66-release-notes.html

vSAN RAID-6 構成の実態とは?

CJです。

vSANで RAID-6相当の構成が組めること、知っていますか?

vSAN6.2 より、Erasure codingがサポートされうようになって、RAID-6相当の構成ができるようになっています。今日はそのRAID-6構成の実態について軽く共有できればと思います。

本題に入る前に、RAID-6相当という言葉を使っていますが、それは物理サーバーのRAID構成とは異なるためです。vSAN上のRAID-6相当が適用される対象は、物理サーバーのRAIDコントローラーではなく、仮想マシン(以下、VM)であることです。

では、早速 RAID-6構成の実態をみてみましょう。

VMにRAID構成を適用するには、”仮想マシンストレージポリシー”にて、まず適用したいRAID-(1/5/6)構成情報を作成します。そのあとは、”VMに適用する”だけです。とてもシンプルです。

vSphere Web Client > ホーム > 仮想マシンストレージポリシー

RAID-6を構成するには、上記のように赤い四角のところを設定していただくだけです。

・許容する障害の数:2

・障害の許容方法:RAID-5/6 (Erasure Coding)

このように作成したVMストレージポリシーは、以下のように新規VM作成時に選択可能となります。

もし、既存動作中のVMのストレージポリシーを変更したい場合は、

VM > 管理 > ポリシー > 仮想マシンストレージポリシーの編集 にて設定変更が可能です。

次は、一歩深く中身の実態をみていきましょう。

vSAN上の RAID-6構成実態を簡単な絵にしたのが、次です。

 

・仮想マシンストレージポリシー (RAID-6) を作成しました。

・作成した仮想マシンストレージポリシーを VMに適用しました。

・VMはさらに VMホーム、VMDKなどの Object で構成されています。

・また、一つのObjectは 複数の Component で構成されています。

・この Component が ESXi ホスト6台に、きれいに分散されて保存されます。

実際、RAID-6構成になって、各ESXiサーバーに Component が分散されていることは、vSphere Web Client からも確認できます。次です。

VM > 監視 > ポリシー > Object (VMホーム) 選択

どうですか? GUI上からもコンプライアンスが守られていて、きちんと各ESXi 分散されているのが簡単に確認できますね。

まとめ

vSANのRAID-6構成、少し理解いただけましたか?

仮想マシンごとにRAID構成が適用可能であること。つまり、一つのvSAN環境で複数の RAID-(1/5/6) 構成を動かす (VMに適用する) ことができるのようになったのは、様々なユースケースにおいて今までとは違う柔軟な対応が可能になったのではないでしょうか?

その中でも、やはりRAID-6構成は、2重障害にも耐えれるのでとてもメリットは大きいと思います。ぜひ、vSAN環境を一度試してみてください。

 

[参考情報]

VSAN 6.2 Part 2 – RAID-5 and RAID-6 configurations

VMware セキュリティ情報を入手するには?

CJです。

VMware から必要に応じてセキュリティパッチが公開されていること、知っていますか?

そうなんです、当たり前かもしれないですが VMwareさんはきちんと脆弱性が見つかった場合は素早くパッチを提供してくれています。

仮想化環境だからこそ、仮想マシンからハイパーバイザーのコードが実行できたりする脆弱性などについては何より素早く対応したいところです。

今回はその脆弱性情報をいち早くキャッチアップできるように情報入手方法を共有できればと思います。

1.VMware Security Advisories サイトへアクセス

上記の空欄に、脆弱性情報を受け取るメールアドレスを登録するだけです!

2.実際、届いたメールをみてみましょう。

今年に入ってすでに数回情報が出ていますが、以下は3月に出た ESXi 関連情報です。

Serverity (Critical 可否)、Problem Description (内容)、対象となる VMware 製品情報がわかりやすい形でレポートされています。

この情報をベースに脆弱性対応を行うかどうかご自身の環境に合わせて判断してください。

3.対応方法について

基本的な対応としては、VMware さんよりパッチが配布されますので、公開され次第、検証後適用すれば大丈夫です。公開までの間は Workaround が先に公開される場合もありますので、そちらの優先対応も検討いただくのも効果的です。

#パッチも最新バージョンのものから公開されていく傾向があるようです。

#Workaroundの場合は以下のように、VMware さんのKBにて情報が公開されます。(上記脆弱性内容とは異なりますが、参考として。)

以上、VMware さんが提供してくれているセキュリティ情報の入手方法についての共有でした。vSphere 環境をお使いの方で、まだ脆弱性対応運用をどうしていくか迷っている方などに少しお役に立てれば嬉しいです。

 

[参考情報]

http://www.vmware.com/security/advisories.html

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2149816

最新の VMware PowerCLI をインストールには?

CJです。

vSphere環境を運用していると GUIもいいですが、やはりコマンドで操作したいケースもたくさんあります。その際に有効に使えるのが、VMware PowerCLI (以下、PowerCLI)ツールです。

ところで、最近 PowerCLIの入手方法が変わったこと、知ってますか?

今までだと、以下のようにVMwareサイト (myvmware)より、パッケージをダウンロードして、サーバーにインストールすることで該当のPowerCLIが使えました。

しかし、配布方法が、PowerCLI 6.5.1 バージョンより Microsoft PowerShell の配布モデル(PowerShell Gallery からインストールする方法)に合わせられているようです。

今回、PowerCLI 6.5.1 をインストールしたいサーバーは “Windows Server 2012 R2” を想定にしているとします。2012R2 では、デフォルトで WindowsPowerShell version 4 がインストールされていますが、このバージョンでは PowerCLI 6.5.1 をインストールするためのモジュールが入ってない状態です。そのため、まずは WindowsPowerShell バージョンを更新(4→5)し、その後に PowerCLI 6.5.1 をインストールする簡単な流れとなります。

では、早速スクリーンショットをベースで見ていきましょう。

1.まずは現在の Windwos PowerShell バージョン(ver.4) を確認しましょう。

$psversiontable.psversion コマンドにてバージョンが確認可能です。

2. Microsoft サイトより、Windows Management Framework 5.0をダウンロードします。

“Download” ボタンをクリックし、

“Win8.1AndW2K12R2-KB3134758-x64.msu”の Checkbox にCheckinしてファイルをダウンロードしてください。その後、ファイルを実行すると、

このように、”…インストールしますか?” とポップアップされます。

OSバージョンに互換性がないパッケージバージョンの場合は、次へ進めない旨のメッセージがポップアップされます。以降は、規約に同意して次へインストール進めていけばOKです。

3. インストール完了後、バージョンを確認すると ver.5 になっていることが確認できます。

4. これで VMware.PowerCLI がインストール可能な状態となりました。

以下のコマンドで PowerCLI モジュールがサーチできることを確認してください。

Find-Module -Name VMware.PowerCLI

5. VMware.PowerCLI モジュールも確認できましたし、次へローカルシステム上に使用可能な VMware モジュールがあるか確認します。

Get-Module VMware* -ListAvailable

では続いて、以下のコマンドにてモジュールをインストールしましょう。

Install-Module -Name VMware.PowerCLI

“…モジュールをインストールしますか?” と表示されたら “Y” でインストールへ進めてください。これで VMware PowerCLI 6.5.1 インストールが完了しました。

先ほどの 使用可能な VMware モジュールを確認してみると、いくつかのモジュールが表示されることが確認できるかと思います。

6. 最後に、vSAN 関連コマンドが表示されることも確認してみてください。

Get-Command -Name *vsan*

現時点の最新バージョンである PowerCLI 6.5.1 で追加された “Get-VsanView” などが表示されることも確認できます。

最新のPowerCLI (vSAN 関連機能など)を使いたいが、VMwareサイトでは見当たらず、迷っている方に少しでも役に立てればと思います。

 

[参考情報]

Welcome PowerCLI to the PowerShell Gallery – Install Process Updates

https://msdn.microsoft.com/en-us/powershell/scripting/setup/windows-powershell-system-requirements

 

Windows Server 2012 R2 画面共有 (シャドウ)

CJです。

Windows Server のシャドウ機能、知っていますか?

リモートデスクトップ画面を共有・制御できる機能です。もちろん、Windows Server にデフォルトに含まれている機能です。 こんなに便利なシャドウ機能が、Windows Server 2012 でなくなっていましたが、Windows Server 2012 R2で改めて組み込まれているそうです。

本日はその機能の有効化する方法を共有したいと思います。

また、本来は役割ごとにサーバーを分けることをお勧めしますが、テストなので 1台のサーバーですべての役割をインストールします。

・GOAL

Administrator権限を持っていないユーザー同士が、シャドウ機能を使ってRDP画面を共有する。

・手順

  1. Windows Server 2012 R2 サーバー 1台を準備し、Administrator ユーザーでRDP接続してください。(仮想マシンでもOK)
  2. RDP接続後、ユーザーの作成・パスワード変更、パソコン名変更などを行ってください。(こちらのテスト環境では、test01, test02, test03 ユーザーを作成します。)
  3. ここが大事です!現在、サーバーは WORKGROUP属になっていると思いますが、シャドウ機能を使うためには事前にドメインに参加しておく必要があります。そうしないと、後程リモートデスクトップサービス(以下、RDS)で、接続メニューが表示されなかったりします。はまるポイントとなりますので、ぜひこの辺はお役に立ってもらえるとうれしいです。
  4. では、ADドメインコントローラーの役割をインストールしてください。具体的なADの役割インストール方法については割愛します。途中、ドメインを指定するところがありますので、そちらはきちんとドメイン情報を入力してください。(こちらの環境では、cjtest.inernal というドメインにします。)
  5. ドメイン(cjtest.internal)に属している状態かと思います。そうすると、次はいよいよ 役割から RDSをインストールしてください。最初、標準か、RDSかという 2選択の画面が表示されると思いますが、RDSのところを選択して次へ進んください。そうすると、クリックスタート、セッションベースで順次進めていただければ特に問題なく、1台のサーバーに必要な役割がインストールされます。
  6. インストールが完了したら、ADユーザー管理のところより、シャドウ機能を使わせる予定のユーザーグループを作成し、ユーザーをグループに追加してください。(こちらの環境では、shadow というグループを作成し、test01, test02 ユーザーをメンバーとして登録します。)
  7. 実はこの時点でもう “シャドウ” 機能は使えるようになっています。test01 ユーザーでRDP接続し、Administratorユーザーで別のRDP接続を行っている状態とします。Administratorユーザーの ”サーバーマネージャ > RDS > コレクション > 接続”をみると現在接続中のユーザー一覧が確認できます。test01 のセッションを選択し、右クリックをすると、なんと “シャドウ” メニューが出てきます。
  8. ところが、今回のゴールはAdministrator権限を持っていないユーザー同士間でシャドウを使うことです。そのため、若干工夫する必要があります。管理者コマンドプロンプトを開いて、次のコマンドを入力してください。[入力コマンド:wmic /namespace:\\root\CIMV2\TerminalServices PATH Win32_TSPermissionsSetting WHERE (TerminalName=”RDP-Tcp”) CALL AddAccount “cjtest.internal\shadow”,2]
  9. これでユーザー同士のシャドウも可能となりました。実際接続を試してください。test01ユーザー側でコマンドプロンプトを開き、”query session” を入力すると、現在セッションがつながっている一覧が表示されます。そこでシャドウしたいユーザーのIDを確認してください。(こちらの環境では、test01から test02をシャドウします。)
  10. 次のコマンドでシャドウを実施してください。 “mstsc /shadow:3 /control” すると、制御リクエストが test02 ユーザーに表示されて、承諾すると以降は画面共有が始まります。

こんな感じで、画面共有ができるようになりました!

TIP

必要に応じてグループポリシーも変更するとより自分に適切な環境を作成できます。

[参考情報]

RDS 2012 R2 – User Support via Shadowing

https://community.spiceworks.com/topic/597125-server-2012-r2-remote-desktop-shadow