Horizon AgentとSQL Serverのセキュリティについて

今回は実際に客先で起きた事象とその解決方法をご紹介します。

一般的にVDIは、同じ業務を行う社員向けにいくつかのマスターイメージを作成した仮想マシンを大量に展開する形が非常に多いです。
しかし、業務によっては特定の人しか利用しないアプリケーションもあることから、それらは、カスタムのマスターを作成したり、そのアプリケーション利用者専用の仮想マシンを手動で作成し1対1で割り当てるケースなどもあります。
今回はこの後者である、特定のアプリケーション用の仮想マシンをメンテナンス中の遭遇した内容です。

こちらの環境では会計担当者が専用の会計アプリケーションを利用しており、会計専用のデスクトップを手動で作成し、専用の会計アプリケーションをインストールしていました。
（いわゆるスタンドアロンアプリケーションとして会計アプリケーションを利用）
導入当初は、Horiozon 6.2で運用しており問題なく動作していましたが、メンテナンスのタイミングで、Horiozn Agent7.4にアップグレードを行い、Windows Updateなどのメンテナンスを行った後、リリースを行ったら、会計アプリケーションからデーターベースに接続ができなくなり、アプリケーションが起動できなくなったという報告を受けました。

アプリケーションを起動すると「データーベースに接続できませんでした」とだけ表示され、ログは特に出力されません。

このアプリケーションは、クライアントが操作するアプリケーションの中にSQLServer 2012 Expressがインストールされており、ローカルホストでアプリケーションとデーターベースが通信をしているアプリケーションでした。

ただ、サービスを見てみると、SQLServerのインスタンスは正常起動しており、
SQLServer Management Studioからはきちんと接続でき、DBとしては正しく起動している状況でした。

こうなると、SQLServerのインスタンス名指定間違いや、DBとAPサーバー間のFirewallによる通信制御を考えてしまいますが、そもそもスタンドアロンでの運用ですし、インスタンス名も特に変更をしていません。

ためしに、Horizon Agentをアンインストールしたところ、アプリケーションは何事もなかったように起動しました。

さて、ここで考えられるのは、Horizon View Agentのインストールすることによって、何らかの影響が生じているということです。

長い前置きでしたが、実はHorizon Agentの新しいバージョン（Ver7以降）に関しては、低レベルの暗号化を無効にするレジストリーキーが記載されます。
それは、Horizon ClientとHorizon Agentの間でですよね？と思われがちですが、実はOSに影響を与える部分のレジストリも変更されます。

今回のSQLServer Express 2012は、TLS1.0が必要だったのですが、これがHorizon Agentによって無効化され、アプリケーションがデーターベースと接続できなくなったというのが原因でした。

では、解決方法をお知らせいたします。

レジストリで以下を変更します。

HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥Control¥SecurityProviders¥SCHANNEL¥Protocols¥TLS1.0¥Server

に、以下の値を作成します（すでにある場合は変更します）

Enabled ：1 (DWORD32Bit)

変更をWindowsを再起動すると、アプリケーションは正しくデーターベースと接続できるようになります。
※そのほか、SSL3.0などの制御もこのレジストリから行います。

やや古めなアプリケーションの場合、このようにHorizon Agentのセキュリティ回りの影響を受ける可能性がありますので、その場合このようなワークアラウンドで切り抜けるしかないですね。

もし、SQLServer系のアプリケーション利用で、Horizon Agentをバージョンアップした際にアプリケーションが動作しなくなった場合は、一度確認をしてみましょう。

参考
https://docs.microsoft.com/ja-jp/windows-server/identity/ad-fs/operations/manage-ssl-protocols-in-ad-fs

NSX for vSphere 6.3.2 リリースとバグフィックス内容について

NSX for vSphere 6.3.2が2017/6/8にリリースされました。
今回はバグフィックスが中心ですが、かなり大きな修正が入っております。もし、NSX6.3.0や6.3.1を利用されているのであれば、積極的にバージョンアップをしたほうが良いと思われるような内容も多く含まれています。

実際にNSX6.3.2のリリースノート（今日時点では英語ですが）を日本語でまとめてみましたので、それをもとに重要な個所を見ていきたいと思います。（重要と思われる修正番号を赤色にしています）

（参考）NSX for vSphere 6.3.2リリースノート
http://pubs.vmware.com/Release_Notes/en/nsx/6.3.2/releasenotes_nsx_vsphere_632.html

--- NSX for vSphere 6.3.2 Release Notes ---

◆NSX 6.3.2の一般的な解決済みの問題
修正済みの問題1839275
ハードウェアVTEPスイッチの背後にある物理サーバーとの接続が失われる
ホストVMにデータプレーンとコントロールプレーンの両方が存在し、すべてのネットワークケーブルの物理的な断線によってコントロールプレーンがダウンすると、仮想マシンはハードウェアVTEPスイッチと接続された物理サーバーとの接続を失います。


◆インストールとアップグレードNSX 6.3.2で解決された問題
修正済みの問題1811218
ホスト再起動後に、NSX以外の設定済みvSphere Distributed Switches（VDS）のVMKernelポートが接続を失う。
複数のVDSを持つホストでは、NSXで設定されたVDSのVTEP VMKernelポートと同じdvPort IDを持つ場合、非NSXでのdvSwitchのVMKernelポートはホストの再起動後に接続を失います。
詳細については、VMwareのKB:2149116を参照してください。

修正済みの問題1850690
ゲストのイントロスペクションUSVMがディスクがいっぱいと報告される
VMware NSX for vSphere 6.3.x環境のGuest Introsepction VMにて、/var/logのディスクスペースがいっぱいになっているか、空き容量が少ないというアラートが表示されます。vRealize Operations Managerまたは仮想マシンのディスク容量を追跡するその他の監視ツールでも、同じアラートが表示されます。
↓
★これは、DeepSecurityなどとのエージェントレスアンチウイルスをしていた場合において影響する問題です。Guest Introspection VAのディスク空き容量が少ないとアラートが出た場合は、まずはNSXのバージョンを確認しましょう。

修正済みの問題1854519
VLANからブリッジドVXLANへの移行後、north-west間の接続が失われます
VMネットワークがVLANからDLR上のブリッジのVXLANに切り替わると、VMへの入力トラフィックは失われます。 6.3.2で修正。


◆NSX 6.3.2で解決されたNSXマネージャの問題

修正済みの問題1814683
複数のHTTPスレッドが認可チェックにスタックしたときにNSXマネージャが応答しなくなる
NSXマネージャが応答しなくなり、再起動する必要があります。


◆NSX 6.3.2におけるネットワークとエッジサービスの解決済みの問題
修正済みの問題1681063
一部のエッジゲートウェイのVPNトンネルステータスがvCloud Directorに正確に反映されていない
vCloud Director（vCD）とNSXは、IPSec VPNトンネルのさまざまなステータスを表示します。 vCDは、トラフィックが流れていてもIPSecトンネルをDOWNとして表示されます。

修正済みの問題1827643
コントローラダウンイベント中のユニキャストフラッディング
コントローラダウンイベントが発生すると、コントローラが停止した直後に、すべてのL3データパケットがその論理スイッチ上のすべてのVTEPに送信されます。
これは、デフォルトのL2 MACエージングタイムがL3 ARPタイムアウトよりも短く、コントローラが使用中のMACテーブルエントリをリフレッシュするために使用できないためです。フラッディングは、その負荷に耐えられない場合NICで送信リセットを引き起こす可能性があります。
これにより、ハートビートプロトコルのパケットドロップが発生し、HAアプリケーションが影響を受ける可能性があります。
たとえば、NSX EdgeアプライアンスとHAを有効にしたDLRは、DLRとECMP ESGの間のOSPFにつながるスプリットブレイン状況に陥り、フラップします。

修正済みの問題1793575
IPハッシュチーミングが選択されている場合、すべてのNSXトラフィックが1つのNICから出力される
NSXポートグループがIPハッシュチーミングポリシー（スタティックEtherChannelまたはLACP）で設定されている場合、
これらのポートグループからのすべてのトラフィックは単一のNICから出力されます。
これによりトラフィックの損失は発生しませんが、使用可能なすべてのリンクにネットワーク負荷が分散されません。
NICの使用が失敗すると、すべてのNSXポートグループがチーム内の別のアクティブなNICにフェールオーバーします。
入力トラフィックは影響を受けず、使用可能なすべてのリンクで受信できます。 6.3.2で修正。
↓
★NSXの設定を行う場合、LACPやイーサチャネル（LAG)を利用している場合が多いかと思いますので、こちらも要チェックです。

修正済みの問題1812445
重複したARP応答を持つ分散論理ルーター(DLR)の物理MACアドレス(PMAC)によってL2VPNブリッジテーブルが影響受ける
ホスト上のL2VPNサーバのvxlanトランクポートは、宛先MACがpMACであるクライアント仮想マシンから送信されたARP応答をドロップしません。これにより、ブリッジ上のMACテーブルがトラフィックを低下させます。

修正済みの問題1806934
OpenswanのCVE-2015-3240によりサービス拒否（DoS）
3.15より前のlibreswanのIKEデーモンとNSSを使用して構築された2.6.45より前のOpenswanは、リモートの攻撃者がIKEパケットのKEペイロードのゼロDH g ^ x値を使ってサービス拒否（アサーションエラーとデーモンの再起動） ができる脆弱性があります。
↓
★Edge Service Gatewayを利用して、IPSECトンネル（VPN)を張っている場合は、こちらの脆弱性に該当しますので、バージョンアップを検討してください

修正済みの問題1811884
論理スイッチがUniversal Synchronization Service（Replicator）ホストで削除されない
Universal Synchronization Service（Replicator）ホストの論理スイッチを削除することはできません。

修正済みの問題1803220
コントローラとホスト間の接続が切断されたときにCDO対応ホストへのVXLAN接続が失われる
Controller Disconnected Operation（CDO）機能により、コントローラクラスタ全体がダウン/到達不能になったときにVXLAN接続が保証されます。
ただし、コントローラクラスタが稼働中でもホストとの接続が失われた場合、コントローラに接続されている他のホストからそのホストに送信されるデータプレーントラフィックは引き続き廃棄されることがあります。
この状態が発生すると、ホストはVNIごとのVTEPリストから削除され、リモートホストから送信されたARPは破棄されます。
コントローラとの接続が失われたホストからのトラフィックの場合、CDO機能により、適切な宛先に確実に到達できるようになります。

修正済みの問題1817673
DLR LIF IPが変更され、以前のIPがVMに割り当てられたときにESXiホストがクラッシュし、ルーティングの問題が発生する
ブリッジがアクティブなホストでパープルスクリーンが表示されます。 IPアドレスが以前のDLR LIFのIPアドレスであるVMと通信するとき、すべてのホストでDLRルーティングの問題が発生します。
↓
VXLAN - VLANブリッジを行っている場合、注意が必要です。

修正済みの問題1825416
フェンス付きvAppのは、vSphere 6.3.xを含むためNSXにアップグレードした後、vCloud Directorでは8.20で失敗します
vCloud Director 8.20でNSX 6.3.xおよびNSX Edge Gatewayを6.3.xにアップグレードすると、フェンス済みvAppが失敗し、フェンス付きネットワーク内の仮想マシンがゲートウェイと通信できなくなります。

修正済みの問題1842337
ECMP ESGのDLR ARP解決に失敗しました。
ECMPのDLRでのARP解決は失敗し、North-Southトラフィックに影響を与えます。

修正済みの問題1834837
VIX通信モードで動作しているすべてのvCNSエッジ（バージョン5.5.4）およびNSXエッジ（6.1.xおよび6.2.x）は、ストレージvMotion後に管理不能になる
MessageBusを通信モードとして実行しているNSXエッジは影響を受けません。
↓
Veeamなどのバックアップソフトウェアで、VIXを利用している場合、こちらに該当する可能性がありますので、こちらも環境によっては注意が必要です。

修正済みの問題1798469
ハイアベイラビリティのステータスが正しく表示されていても、一部のNSXエッジがスプリットブレインシナリオに入ることがある
HAメカニズムの競合状態により、NSX 6.2.5以降にアップグレードされた一部のNSXエッジは、「ハイアベイラビリティステータス」が正しく表示されていてもスプリットブレインシナリオになる可能性があります。 これは、エッジの再デプロイ後にも発生する可能性があります。
↓
Edge Service GatewayをHAモードで利用している場合、こちらも症状が出る可能性がありますので、ESGを利用されている方は、お早目のバージョンアップをお勧めします。

修正済みの問題1828060
強制同期操作中にトラフィックが多い状態でNSX Edgeに接続の問題が発生することがある。
NSX Edgeは、Force Sync操作中にトラフィックが多い場合に接続の問題が発生する可能性があります。


◆NSX 6.3.2におけるセキュリティサービスの解決済みの問題
修正済みの問題1798537
ESXi（vsfwd）のDFWコントローラプロセスでメモリが不足することがある
DFW構成で大量のルールまたは大きなサイズのセキュリティグループが存在する環境では、ESXi（vsfwd）上のDFWコントローラプロセスがメモリ不足になり、ルールをデータパスに公開できません。
↓
分散ファイアーウォールに多くのルールを書く場合、また、Service Composer等で大量のグループオブジェクトを作成している場合には該当する可能性があります。

修正済みの問題1853106
認証がチェックされていないか、PSKモードのIPsec VPNのIPsec設定の変更が変更された場合、UIでエラーが発生する
証明書ベースの認証でIPsec VPNのPSKモード認証がチェックされていないか変更されている場合、「グローバル設定」タブの「証明書と秘密を読み込めませんでした：002忘れた秘密」というエラーが表示されます。

修正済みの問題1725524
Hostdを再起動すると、RabbitMQを使用してデータを送信しているときにvsfwdがクラッシュすることがある
hostdプロセスを再起動する操作によって、vsfwdの接続が再確立されます。 一部のスレッドが古いチャネルを使用してデータを送信している間に、メインスレッドが古い接続をクリアしているときにvsfwdがクラッシュする可能性があります。

修正済みの問題点1800196
Broadcast MACアドレスを持つ多数のIPパケットがDistributed Firewallの拒否ルールと一致するとVMkernelのログ記録が停止する
分散ファイアウォールは、拒否パケットをユニキャストMACアドレスにのみ送信します。 ブロードキャストMACアドレスを持つIPパケットが拒否ルールと一致する場合、拒否パケットは送信されません。 ただし、このイベントはvmkernel.logに記録されます。 ネットワークがこのトラフィックでいっぱいになると、vmkernel.logはログストレスによってメッセージを廃棄し、ログは停止します。 ブロードキャストMACアドレスを持つパケットの拒否は、デバッグがイネーブルの場合にのみロギングされるようになりました。 6.3.2で修正。 ブロードキャストMACアドレスを持つパケットの拒否は、デバッグがイネーブルになっている場合にのみ記録されるようになりました。
↓
ブロードキャスト通信とMACアドレスベースでのフィルターを利用している場合、ログが出なくなる恐れがありますので、こちらも要注意です。

修正済みの問題1807152
VMを1つのクラスタから別の新たに準備されたクラスタに移動すると、appliedToという仮想ワイヤを持つルールはVMに適用されません。
新しいクラスタをデータセンターに追加すると、[仮想ワイヤとして適用]を持つルールのクラスタリストは更新されません。 したがって、VMが古いクラスタから新しく準備されたクラスタに移行されるとき、ルールは適用されません。


修正済みの問題1812467
ネストされたSGの大文字小文字を使用する大規模なVMでのコンテナの更新で、ホストの更新が長く遅延する
ホストにSGがネスト化された大規模なVMがある場合、1回のインベントリ変更によってコンテナの更新がフラッシュされ、最終的にホストに変更が反映されるまでに非常に遅れが生じます。

修正済みの問題1847880
特定のクラスタ内のホストからVIBをアンロードすると、「vmkload_mod：モジュールvsipを削除できません：モジュールの消費されたリソース数がゼロではありません」というエラーが表示される。
VIBのアンインストールがトリガーされ、他のNSX VIBがアンインストールされると、コマンド”esxcli software vib list | grep vsip”にはまだインストールされているesx-vsipが表示されます。

修正済みの問題1812792
分割されたTCPハンドシェイクに関連するDFWパケットの廃棄。
分散ファイアウォールは分割されたTCPハンドシェイクを適切に処理しません。 ウインドウ計算が不正確であるため、今後のパケットドロップにつながるウインドウスケールオプションは無視されます。 これは、最初のSYN ACKパケットが失われ、SYNの再送信によって、分割されたTCPハンドシェイクを引き起こしたチャレンジACKが生成されたために発生していました。

リリースノートにおける、修正情報は、以上となります。

NSX6.3は、Linuxベースのアンチウイルス機能など新機能もありますが、既存機能のブラッシュアップがなされているバージョンとなります。
6.3.2では、かなりのバグが修正されていますので、本番環境でもNSX 6.3.2を利用してもよい状況になったと思います。既存で、NSX6.3.1以下をご利用の方は、ぜひお早目の6.3.2へのバージョンアップをお勧めします。

NSX6.3からの新機能セッションタイムアウトについて

NSX for vSphere 6.3の１つ大きな仕様変更が、分散ファイアーウォール機能にセッションタイムアウト機能がついたことです。
本来ファイアーウォールですから、一定時間利用していないポートを閉じるというのがセキュリティ上好ましいのですが、NSX6.2まではそのような機能実装はなくどちらかというとL3スイッチのような感じのACLで動作していた感があります。
今回のセッションタイマー機能は、まさに「ファイアーウォール」としては必要な機能が導入されたということになります。
このセッションタイマーについて紹介します。

まず、このセッションタイマー設定は、vSphere Web ClientのNetwork and Security→ファイアーウォールの画面から、新たに追加された"設定"タブ"を開きます。

ポリシーは、新規で追加可能ですので、自由にポリシーを作成できます。

まず各タイムアウト値ですが、TCP/UDP/ICMPで各パラメーターの設定が可能です。

ポリシーで設定できるパラメーターと範囲は以下の通りです。

TCP	説明
最初のパケット (First Packet)	最初のパケットが送信された後の、接続のタイムアウト値です。デフォルトは 120 秒です。 設定範囲：10～4320000
開く (Open)	2 番目のパケットが転送された後の、接続のタイムアウト値です。デフォルトは 30 秒です。 設定範囲：10～4320000
Established	接続が完全に確立された後の、接続のタイムアウト値です。 設定範囲：120～4320000
Closing	最初の FIN が送信された後の、接続のタイムアウト値です。デフォルトは 120 秒です。 設定範囲：10～4320000
Fin Wait	両方の FIN が交換され、接続が閉じられた後の、接続のタイムアウト値です。デフォルトは 45 秒です。 設定範囲：10～4320000
Closed	1 つのエンドポイントが RST を送信した後の、接続のタイムアウト値です。デフォルトは 20 秒です。 設定範囲：10～4320000
UDP	説明
最初のパケット (First Packet)	最初のパケットが送信された後の、接続のタイムアウト値です。これは、新しい UDP フローの最初のタイムアウトになります。 設定範囲：10～4320000
単一 (Single)	送信元ホストが複数のパケットを送信し、宛先ホストが送り返さなかった場合の、接続のタイムアウト値です。 設定範囲：10～4320000
複数 (Multiple)	両方のホストがパケットを送信した場合の、接続のタイムアウト値です。 設定範囲：10～4320000
ICMP	説明
最初のパケット (First Packet)	最初のパケットが送信された後の、接続のタイムアウト値です。これは、新しい ICMP フローの最初のタイムアウトになります。 設定範囲：10～4320000
応答エラー (Error reply)	ICMP パケットへの応答で ICMP エラーが返された後の、接続のタイムアウト値です。 設定範囲：10～4320000

（参考）セッションタイマー
http://pubs.vmware.com/nsx-63/index.jsp#com.vmware.nsx.admin.doc/GUID-0A88046C-D77B-4380-99C3-A631A93E4999.html

なお、設定範囲はVMware提供のドキュメントには、設定できる範囲が記載されていませんが、画面上に設定範囲外の値を入力すると、設定できる範囲が表示されます。

また、このパラメーターの適用範囲は、「仮想マシン」と「vNIC」の2つから選択可能です。
仮想マシンの場合は、ポリシーに対して、仮想マシンを選択する形となります。

一方で、vNICの場合、仮想マシンから仮想NICを選択する形となります。

仮想NICごとにタイムアウトパラメーターを変更することが可能ですので、DBサーバーとアプリケーションサーバーのコネクションプールによる接続などが行われている場合、柔軟な設定が可能となります。

ちなみに、複数のポリシーを作成することが可能ですが、1つの仮想マシンや仮想NICなどのオブジェクトを複数のポリシーに適用させることはできません。1つのオブジェクト（仮想マシンまたは仮想NIC）は、かならず1つのポリシーにしか属せないという制約があります。なお、すでに別のポリシーが適用されたものを別のポリシーに二重で適用しようとした場合、「仮想マシンvNICはすでに別のタイマーの一部として設定されています。[解決]をクリックして、選択されたリストから削除してください」とエラー画面が表示されます。

ただし、タイムアウト値を「0」つまりタイムアウトさせないという設定はできませんので、注意が必要です。NSX6.3にアップデートした場合は、重要な仕様変更ですので、注意が必要です。

Edge Service Gatewayのファイアーウォールタイムアウト値について

ファイアーウォールにおいて、一定時間無通信だったポートを閉じるという機能は必要不可欠な機能ですが、このタイムアウト値は各ファイアーウォール機器によってまちまちです。では、NSX for vSphereで提供されるEdge Service Gatewayのタイムアウト値はどのようになっているのでしょうか？

これは、KB2101275にて掲載されています。

（参考）vCNS/NSX Edge Firewall TCP Timeout Values
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2101275

こちらをもとに確認していきたいともいます。
まず、このKBは、vShield EdgeとNSXのEdge Serviceと同一で記載されています。ここで重要なのはAPIバージョンです。NSXで提供されるEdge Service Gatewayは、API4.0が搭載されていることが、以下の表からわかります。

APIバージョン

リリースバージョン	APIバージョン	設定の永続性
vCNS 5.1.2 and earlier	Not supported	-
vCNS 5.1.3 and later	api/3.0	No
vCNS 5.5.1 and later	api/3.0	No
NSX for vSphere 6.0 and later	api/4.0	Yes

設定の永続性とは、Edge Service Gatewayを再デプロイしたり、バージョンアップをした際に、以前に設定したパラメーターが引き継がれるかという意味になります。

各タイムアウト値は以下の通りとなります。

Protocol/State	(Version 4.0) Inactivity Timeout (seconds) ※NSXのEdge Service Gateway	(Version 3.0) Inactivity Timeout (seconds) ※vShiled Edge 5.5.1/5.1.3
TCP Open (SYS-SENT, SYN-RCVD states)	30	30
TCP Established	3,600	3,600
TCP Close (TIME-WAIT, FIN_WAIT states)	30	20
UDP	60	30
ICMP/ICMPv6	10	10
All other protocols	120	120

このパラメーターは、REST APIをコールすることで変更することができます。

NSXの場合、NSX ManagerにREST APIを発行します。

APIURL:https://nsx-manager/api/4.0/edges/{edgeId}/firewall/config/global

メソッド: PUT

送信するXML

<globalConfig> <!-- Optional -->...
  <tcpTimeoutOpen>30</tcpTimeoutOpen> <!-- Optional. Defaults to 30 -->
  <tcpTimeoutEstablished>3600</tcpTimeoutEstablished> <!-- Optional. Defaults to 3600 -->
  <tcpTimeoutClose>30</tcpTimeoutClose> <!-- Optional. Defaults to 30 -->
  <udpTimeout>60</udpTimeout> <!-- Optional. Defaults to 60 -->
  <icmpTimeout>10</icmpTimeout> <!-- Optional. Defaults to 10 -->
  <icmp6Timeout>10</icmp6Timeout> <!-- Optional. Defaults to 10 -->
  <ipGenericTimeout>120</ipGenericTimeout> <!-- Optional. Defaults to 120 -->
</globalConfig>

アプリケーション利用で、知らないうちにセッションが切られて業務アプリケーションが異常終了したなどのトラブルを防ぐためにも、ファイアーウォールのタイムアウト値には、気を配ったうえでのネットワーク設計をお勧めします。

VCP-NVのすすめとメリットをご紹介

今日は、VCP-NVの取得メリットについて自分の経験を交えてご紹介をしたいと思います。

私自身、プリセースルという立場のため、NSXに興味があるとか、NSX導入したメリットを知りたいというお客様に対して、どのようにNSX for vSphereを導入するとメリットがあるかや、正しいインプリメント（導入）のお手伝いをすることが仕事だったりします。

NSX for vSphereは、ネットワークの仮想化という言葉でひとくくりにされてしまうことが多いですが、VXLANによるデーターセンター間のL2延伸や、分散ファイアーウォールによるマイクロセグメンテーション、Edge Service Gatewaが提供する高度なロードバランサー機能（ADC）やSSL-VPNなどの様々な機能を持ち合わせており、単純にNSXを導入ししたいというお客様にとっても、どの機能を使いたいかでエディションを含め大きく変わることがありますし、提案する側としては、幅広いNSX for vSphereの機能を一通り把握しておく必要があります。
NSXは、様々なコンポーネントがありますが、実際の導入作業においては、あまり意識せずとも導入できてしまうというのが実情です。ただ、トラブルや想定していない事項が発生した際には、このコンポーネントの詳細な動作を理解しておく必要があり、この理解具合を確認するという観点においてもVCP-NVは大変有益なものと私自身思っています。

私自身は、VCP-NVを取得する形で、NSX for vSphereの機能や特にVX-LANのメリットや導入時の注意点を習得することができました。

VX-LANによるネットワークのL2延伸は、大変魅力的ですが、このVX-LANには、既存の物理ネットワークに対して極力影響をなくし、仮想的なネットワークを作成し、マルチテナントや場所的な問題を解決するためのソリューションですが、VX-LANを実際に導入するために、あらかじめ押さえておくべき事項がいくつかあります。

このあたりの実践的な導入における注意点が、VCP-NVの問題としてよく登場しますので、VCP-NVを取得またVCP-NV取得へ向けての学習をすることで、VXLANの根本やUWA役割などの、NSXのコンポーネントと役割をしっかりと学習することができます。

これは、NSXを導入後におけるトラブルにおいても非常に有効です。

実際にNSX導入後においてトラブル相談を受けるケースもありますが、その際に必要なことは、VTEPの動作とNSX Controllerの動きをしっかりと理解していれば、なにも難しいことではないのですが、このあたりの理解や動きを習得するためには、VCP-NV取得に向けての勉強は大変に役立ったと感じています。

また、NSXにおいては、分散スイッチの導入が基本必須となりますが、分散スイッチのメリットをわかりつつも標準スイッチで構成されている現場を多く見ますが、NSXを学習すると、vDSの機能やメリットも今一度おさらいすることができます。VCP-DCVにおいては、vDSの概要は少ししか触れられませんが、VCP-NVにおいては、vDSの内容もしっかり出てきますので、vDSがより身近になると思います。

また、今まで仮想化を中心としたサーバーエンジニアにとっても、ネットワークという基礎概念とネットワークの仮想化を学ぶ大変良い材料になると思います。

ぜひ、仮想ネットワークの世界に踏み出す一歩として、VCP-NVの取得にチャレンジをされてみてはいかがでしょうか？

Windows10のSysprep時注意点

世間では、Windows10も一般化し企業での導入も普及期に入りWin7からの移行のケースも増えてきたかと思います。
Windows10には、様々なエディションが有りアップデートプログラムの適用について、様々なパターンを選ぶことができるようになっています。

さて、Windows10で一般的なVLKイメージで展開する際に、まずゴールドイメージにWindows Updateを施した後に、Horizon View側で展開の設定を行うかと思います。
この際に、Sysprep経由での展開時に失敗することがあります。

実際に手動でWindows10のゴールドイメージにsysprepをかけようとしても、以下のようなエラーが出て正しくsysprep自体が動作しません。
 

実際に、C:\Windows\System32\Sysprep\Panther\setupact.logを見ると以下のようなエラーが出ています。

2017-04-02 16:25:16, Error SYSPRP Package Microsoft.MicrosoftSolitaireCollection_3.9.5100.0_x64__8wekyb3d8bbwe was installed for a user, but not provisioned for all users. This package will not function properly in the sysprep image.
2017-04-02 16:25:16, Error SYSPRP Failed to remove apps for the current user: 0x80073cf2.
2017-04-02 16:25:16, Error SYSPRP Exit code of RemoveAllApps thread was 0x3cf2.
2017-04-02 16:25:16, Error [0x0f0082] SYSPRP ActionPlatform::LaunchModule: Failure occurred while executing 'SysprepGeneralizeValidate' from C:\Windows\System32\AppxSysprep.dll; dwRet = 0x3cf2
2017-04-02 16:25:16, Error SYSPRP SysprepSession::Validate: Error in validating actions from C:\Windows\System32\Sysprep\ActionFiles\Generalize.xml; dwRet = 0x3cf2
2017-04-02 16:25:16, Error SYSPRP RunPlatformActions:Failed while validating SysprepSession actions; dwRet = 0x3cf2
2017-04-02 16:25:16, Error [0x0f0070] SYSPRP RunExternalDlls:An error occurred while running registry sysprep DLLs, halting sysprep execution. dwRet = 0x3cf2
2017-04-02 16:25:16, Error [0x0f00d8] SYSPRP WinMain:Hit failure while pre-validate sysprep generalize internal providers; hr = 0x80073cf2

さて、これはWindows Updateによりストアアプリの変更がおこなわれてしまうことによる弊害のようです。

実際には以下の情報が参考になります。

(参考)Windows 10 (バージョン 1511) における Sysprep 実行時の注意点
https://blogs.technet.microsoft.com/askcorejp/2015/12/20/windows-10-1511-sysprep/

こちらの中で紹介があるとおり、グループポリシーの変更行うことで対応が可能なようです。
私が検証する限り、1611ビルドのWindow10 Proのメディアに対して、Windows Update後に以下の対応を行ってもsysprepは成功しましたので、誤ってWindows Updateをかけてしまった後でもマスターの再作成は不要だと思います。


では回避法の手順を、おさらいしておきましょう。
※グループポリシーといえども、今回はClientOSのマスターであるためドメインに参加する前と考え、AD側での適用ではなく、クライアントOS本体のポリシー（ローカルコンピューターポリシー）を変更します。

1.まずは、該当のWindows10 Clientからファイル名を指定して実行をクリックします。

2.実行アプリケーションに「gpedit.msc」を入れて起動します。

3. [ローカルコンピューターポリシー]→[Windows コンポーネント]→[クラウド コンテンツ]の順にツリーを奨めていきます。

4.「Microsoft コンシューマー エクスペリエンスを無効にする」をダブルクリックします。

5.オプション選択画面が表示されますので、「有効」を選択し、OKをクリックします。

6.パラメーターが有効になっていることを確認し、ローカルグループポリシーエディタを終了します。

7.最後にコマンドプロンプトから「gpupdate」を実行し、ポリシーを反映させます。

これで、完了です。
この後は、sysprepを実行すると、正常に処理が完了します。

Horizon Viewのマスターとして利用する際に、Quickprepではなく、Sysprepを利用する場合は、あらかじめこの作業を行っておきましょう。

VCP6-NV 取得の薦め その２

前回は、VCP6-NVを取得するためのプロセスをご紹介しました。


では、実際にVCP6-NVを取得するためにはどのような勉強をすればよいのでしょうか？

一応ですが私もVCP6-NVホルダーですので、資格取得までのことをお伝えしたいと思います。

私自身も当然ながら仕事の中でVMware NSXを扱うことが多く、さすがに無免許では・・・と思いながら取得したのが、私の受験の理由だったりしますが。
（昔からそうですが試験というのはあまりうれしいものではないので）


さて、まず問題の傾向ですがVMware NSX for vSphereという製品自体が、かなり多くの機能が実装されているので、その基本機能や機能実装についてはある程度頭に入れておく必要があるでしょう。また、NSXの特徴でもあるネットワーク仮想化機能はしっかりと押さえておきましょう。
VXLANについては詳細に動きを把握することや、DLRによるルーティングの動作なども押さえておきましょう。

ここで大事なことは、NSXは、vSphere上で動作するネットワーク仮想化製品であるということです。NSXを利用する上で必要不可欠な分散スイッチ（vDS）やvmkernelなどのvSphereの基本を押さえておかないと、うわべだけの机上だけのVXLANスキルだけだと、おそらく難しいのではないかと思います。

ネットワーク全体の設計スキルも問われますが、NSXにおける制限事項等も押さえておく必要があります。

とはいえ、実際に触る機器もないケースが多いでしょうから、是非VMwareのHands On Laboを利用して、思いっきりさわり倒すことがまず大事だと思います。


では、VCP6-NVを取得するまでの押さえておきたいプロセスをまとめておきます。

＜その１＞
Hands On Laboをさわりたおして、動きや操作手順、感覚を学ぶ
おすすめコース
HOL-1703-SDC-1 - VMware NSX: Introduction and Feature Tour


＜その２＞
リリースノートとドキュメントを読んで、制限事項やアップグレードの制限、操作手順などの条件を確認する

• NSX6.2.6リリースノート
• NSX6.2ドキュメントセンター

＜その３＞
基本的なネットワークのスキルを身につける。
スイッチ＋ルーティングはもちろん、ダイナミックルーティングやVPNの仕組み（特にIPSEC）、ネットワークの基本設計（Leaf & Spineの考え方や、North - South通信とEast - West通信など）

＜その４＞
もし、VMware Partner Network(VPN)に加盟している会社に所属している場合は、Partner Centralから、VSP-NVとVTSP-NVをあらかじめ取得しておく。（ここで結構基本的なスキルが取得できます）

＜その５＞
体調を整えて、試験に臨む。



ちなみに試験は500万点中300点合格（6割）です。
問題ごとに点数が異なるため1問何点という配分は、わかりません。
問題は選択式で、複数の回答を求めるもののほうが得点配分が高く、制限事項等をもとめるような単一の回答は得点配分が低いという話を聞いたことがあります。

上記の手順をしっかり行っておけば、すくなからず合格点には行けると思います。


新年度で新しいことを始めたりチャレンジしたいと思う時期ですので、是非、VCP6-NVにチャレンジしてみてください！