SIDの確認方法とSIDが持つ数字の意味について
【SIDの確認コマンド】
> whoami /user
実行結果例(クローン元)
※一部数値を塗りつぶしています。
クローン元とクローンで確かにSIDは違うんですが、同じところも多いです。
クローン元のSID：S-1-5-21-3097704385-4090854038-3386600129-500
クローンのSID： S-1-5-21-2250159906-4095572251-131081047-500
※実際の数値に変更を加えています。
具体的には「S-1-5-21-……-500」の部分がクローン元とクローンで変わっていないことがわかります。
この「S-1-5-21-……-500」の部分は下記サイトで、
と紹介されています。
どういうことかというと、SIDはOSに一つではなくユーザ数分存在するということです。
本記事の最後にSIDを確認したときのログをのせますが、SIDの確認コマンドを実行した際、ユーザ名もともに表示されます。
以前の記事と同様の手順でSIDの変更を伴う仮想マシンのクローンを行った場合、変更されるのは下図における赤枠の部分だけということになります。
なお、「S-1-5-21-……-500」の部分がユーザの種類によってどう変わるのかは、先述の参照URLに記載されています。
忘れていなかったら、複数ユーザが作成されている環境での「whoami /user」実行結果を本記事にのせたいと思います。
仮想マシンのクローン作成時にSIDを変更する方法
途中までは通常のクローン作成と同じのため、説明は割愛します。
ここで、「オペレーティングシステムのカスタマイズ」にチェックを入れます。
赤丸の部分をクリックするとカスタマイズ仕様の新規作成ウィザードが表示されます。
あとは適宜、必要個所への入力を行います。
Customizing desktops with sysprep fails with the error: a specified parameter was not correct: \nspec.identity.userData.computerName (2009820)
管理者パスワードが変更できるのはクローン元となる仮想マシンの管理者パスワードがカラのときだけです。
タイムゾーンのデフォルトは日本になっていないため、注意が必要です。
(例)
ユーザー名:administrator@***.com
NetBIOS名にしたり、@以降を省略するのはおすすめしません。
ドメイン参加等がうまくいかない恐れがあります。
現バージョンでは確認していませんがバージョン５の時代にはそんなのもありました。
当時はなんでかわからなかったのですが、以下の方の記事で知りました。
そ、そうだったのか～…って感じです。
そういうこともあってカスタマイズ仕様は一時、全然使ってなかったです。
vSphere 5.0時代はNetBIOS名で失敗
ここにチェックが入っていることを必ず確認してください。
「完了」をクリックすると、新規カスタマイズ仕様の作成は完了です。
あとは、今作成したカスタマイズ仕様を選択した状態で「次へ」をクリックします。
「完了」をクリックするとクローン作成が始まります。
「監視」タブの「タスクおよびイベント」に「仮想マシン〇〇のカスタマイズが成功しました。」と表示されたことを確認してからログインしてください。
何か問題があった場合はログを確認します。ファイルパスは上記画像に記載されている通りです。
以下はログ内容の一部例です。
SIDが本当に変更されたかどうかの確認方法、およびSIDの命名？規則については次の記事で書きます。
Windowsの仮想マシンをクローンする際に気を付けること
WindowsOSはSID(Security Identifier)と呼ばれている一意のIDで管理されています。
SIDの存在を知らなければ、大体みんなひっかかる感じです。かかりました。
でも、実際問題が発生しないと気付かなかったりとか、不意に「SIDの重複神話」なんていうのを見つけて焦るんですよね…。焦りましたよ。
SIDの重複については問題のあるなし等、いろいろな情報がネット上に転がっていますが、私としてはやっぱり変えた方がいいと思ってます。
なんか怖いので…というのは理由になっていないため、ソースをのっけます。
あと、もうソース見つからなくて微妙な記憶なのですが、確かバージョン5.5U2でかつWindows Server 2012 R2？無印？を使用していたとき、かつvmxnet3を使用していたときにネットワークが再起動する(しかもいつ起こるかわからない)現象があったような…。
≪マイクロソフト≫
マシン SID の重複神話
「SIDの重複」の章をご参照ください。
≪VMware≫
"Windows が元の仮想マシンと同一のセキュリティ ID（SID）を持つ新しい仮想マシンまたはテンプレートを割り当てないように設定できます。これらのコンピュータが 1 つのドメイン内にあり、ドメイン ユーザー アカウントのみが使用される場合、SID が重複していても問題が発生することはありません。しかし、これらのコンピュータがワークグループの一部であったり、ローカル ユーザー アカウントを使用したりする場合、SID が重複しているとファイル アクセス コントロールが危険にさらされる場合があります。詳細は、Microsoft Windows オペレーティング システムのドキュメントを参照してください。"
参照元：http://pubs.vmware.com/vsphere-65/topic/com.vmware.vsphere.vm_admin.doc/GUID-1330EEEE-12D1-42FE-B647-E731A01B1A7D.html
次回は、クローン展開時にSIDを変更する方法を書きたいと思います。
仮想マシンの互換性のアップグレード(手動)
仮想マシンの互換性のアップグレード手順はすごく少なくて簡単ですが、重要なことが二つあります。
(1)対象の仮想マシンは電源を落とす必要があること。
(2)作業前に対象の仮想マシンのバックアップを取得しておくこと。
(2)はどの作業でも必要ですが、この作業だと特にそうです。実際、VMware Toolsのアップグレードなどとは異なり、警告がでます。
以下に、手順を記載します。
冒頭でも述べたように、警告が表示されるため「はい」をクリックします。
(バックアップ取得済みであることが前提です)
今回この仮想マシンはバージョン6.0から6.5の環境に移行してきたもののため、「ESXi 6.5以降」が選択されていることを確認し「OK」をクリックします。
ただ、念のためパワーオンして正常に稼働するかどうか確認する必要はあります。
なお、現在パワーオン中で次回シャットダウンしたときにしたい場合は最初の画像の選択肢にある「仮想マシンの互換性のアップグレードのスケジュール設定」をクリックすれば可能です。
個人的な意見としては自動よりは手動で、確認できるときにやった方が安心できますが、また気が向いたらやってみようかなと思ってます。
…実際の運用でも自動じゃなくて手動を使うんだろうなぁ…。
VMware Toolsのアップグレード(Windows)
vSphere環境(vCSA、ESXi等)をバージョンアップした際、仮想マシンのサマリ画面に以下のような警告が表示されます。
今回は手動で一台ずつバージョンアップする方法について記載しています。
本記事に記載しているのはバージョン6.0から6.5に移行した仮想マシンです。
今回は「対話形式のアップグレード」を選択し、「アップグレード」をクリックします。
なお、「自動アップグレード」を選択し、「アップグレード」をクリックした場合、一気に最後の画像の段階になり、アップグレード作業は終了です。
タスクバーに「VMware Toolsのインストールまたはアップグレードの開始」というタスク名が表示されるので、「ステータス」が「完了」になり、上記画像の「VMware Tools」の部分に「利用可能なアップグレード」と表示されなくなったことを確認してください。
中にある「setup64」をダブルクリックします。(64bitの場合。32bitの場合は「setup」)
再起動が完了すると、「VMware Tools」のバージョンが新しくなっていることが確認できます。
vSphere Web Clientでのライセンス適用方法
vSphere Web Clientでのライセンス適用方法について記載します。
ぼやっとした記憶ですが、バージョン5.1のころにESXiを期限切れにしてからライセンスを割り当ててvCenterに登録しようとしたら、どうしてもうまくいかなかった覚えがあります。
本記事ではvCenter Serverのライセンスを適用していますが、同様の方法でESXiなどの他の製品についてもライセンス適用できます。(ただし、vCenter Serverの管理下に入っているものに限ります)
バージョン6.0から6.5になってライセンス適用する際のUIが少し変わりましたが、それほど大きな違いはなかったです。
バージョン5.5まではvSphere Clientでライセンス適用していたので、バージョン6.0のときは少し手間取りましたが…。
大まかな流れ：ライセンスキーの登録→登録したライセンスキーの割り当て
【ライセンスキーの登録】
「ホーム＞管理＞ライセンス」のライセンスタブをクリックし、緑のプラスをクリックします。
水色の枠で囲われた部分にライセンスキーを入力し「次へ」をクリックします。
ライセンス名(任意)を入力し「次へ」をクリックします。
内容を確認し「完了」をクリックします。
登録したライセンスキーがリストに追加されます。
【登録したライセンスキーの割り当て 】
ライセンスタブから資産タブに移り、先ほど登録したライセンスキーを製品に割り当てます。
今回はvCenter Serverにライセンスを割り当てるため、「vCenter Serverシステム」にあるvCenter Serverを右クリックして「ライセンスを割り当て」を選択します。
（ESXiのときは「ホスト」から割り当て可能です)
先ほど登録したライセンスキーを選択し、「OK」をクリックします。
ライセンスキーを割り当てたことで、画面上部の警告は表示されなくなります。
また「製品」列の表示が「評価モード」から変更されていることが確認できます。
Horizon Viewで展開できる仮想デスクトップの種類
VMware社が提供しているHorizon Viewでは仮想デスクトップやアプリケーションの配布が可能です。
今回、Horizon Viewで配布できる仮想デスクトップの種類についてざっくりまとめてみました。
（ちょっと全体的に雑な感じがぬぐえないので、後々書き足したりするかもです）
Horizon Viewで配布できる仮想デスクトップには二種類あります。ユーザと仮想デスクトップが一対一で結びついているのと(VDIと呼ばせていただきます)とユーザと仮想デスクトップが多対一で結ばれているもの(RDSと呼ばせていただきます)です。
【VDIとRDSと違い】
≪VDI≫
・1人で1つのOS占有します。
・「障害が発生した仮想デスクトップ＝ユーザ数」が影響範囲です。
≪RDS≫
・1つのOSを複数のユーザで使用します。
・「障害が発生した仮想デスクトップ×該当仮想デスクトップを使用しているユーザ数」が影響範囲です。※1
・VDIと比べてMicrosoftのVDAライセンスコストが安い。※2
※1 仮想デスクトップに障害が発生≒RDSホストに障害が発生→RDSホスト1台に対し複数のユーザが結び付けられているため影響範囲が大きい(ただし、複数のRDSホストで構成されている環境の場合この限りではない)
※2 MicrosoftのVDAライセンスコストが安くなることにより、トータルのコストも安くなるかもしれませんが、仮想デスクトップ上にインストールするソフトウェアによってはRDSの方が高くなったり、そもそもRDSでは使用できなかったりするかもしれません。
【リモートデスクトップ接続とRDSについて】
WindowsOSのリモートデスクトップ接続でもユーザとOSを一対多で結びつけることはできますが、一つ利点をあげるとするならば、RDSではPCoIPやBlast Extremeでの接続が可能です。かなり雑に説明すると、リモートデスクトップ接続より効率的な画面転送ができるため出力が早いはず、です。
Horizon Viewでは長いこと(バージョン4から)PCoIPが使われてきたのですが、バージョン7になってVMware独自のプロトコルBlast Extremeが使えるようになりました。もしかすると、PCoIPからの切り替えの時期に入ってるのかもしれません。
徹底比較：VDIの「画面転送プロトコル」、主要3社の技術に違いは？
http://techtarget.itmedia.co.jp/tt/news/1605/31/news04.html
RDS ホストベースの公開デスクトップ/公開アプリケーション
https://blogs.vmware.com/jp-euc/2014/09/horizon-6-rds-hosted-part1.html
新卒2年目SE社員が贈る 仮想デスクトップのキソ！ 第１回 ～仮想デスクトップと Horizon 6 ( with View)～
https://blogs.vmware.com/jp-euc/2015/04/euc_kiso01.html
