ThinAppのパッケージングの際に
先日のVMUのVDI会でThinAppの説明をいただいた際に、意外と知られていなかったようなので触れてみます。
仮想化放浪記で手順が公開されているので詳細は省きますが、"Show entry points used for debugging"を有効化によりcmd.exeとregedit.exeが表示されるが、動作検証時以外は無効を推奨とあります。
◆仮想化放浪記
http://makoiin.blogspot.jp/2014/12/thinapp.html
もちろん、高セキュリティが求められる環境やThinAppのパッケージの更新と配布が維持できるのであれば問題ありませんが、一人社内SEで手が足りない！という方にはこの
"Show entry points used for debugging"で表示される項目が非常に便利です。
パッケージ作成画面終了後、ThinAppのプロジェクトフォルダにあるPackage.iniの末尾に[cmd.exe]と記載された行以降を編集します。
この際の注意点としてcmd.exeのままにするとThinAppのパッケージ内なのか通常のWindowsのcmd.exeなのか区別がつかないので[cmd.exe]に接頭語としてvirtualの"v"とかThinAppの"TA"とか[TAcmd.exe]のように適当につけましょう。
ビルドするとThinAppのポインタ(exe)とdat以外に[TAcmd.exe]と[TAregedit.exe]が生成しますので、何かあればこの[TAcmd.exe]を実行してコマンドでSandBoxに設定を追加する事ができます。
また、生成したポインタ(exe)をそのまま提供せずにバッチかVBScriptでポインタを実行する形にする事を推奨します。こうする事で、このバッチやVBscriptに[TAcmd.exe]を利用したアップデート用のスクリプトを仕込んでおくと、パッケージされたThinAppに対してパッチを適用する事ができます。
イメージとしてはThinAppでOffice2013がパッケージされている場合にServicePackを適用したいケースでTHcmd.exe にサービスパックを適用してからポインタで起動するようにするケース(こんな大きなアップデートは推奨できませんが)や、ThinAppでパッケージしたもののドメイン不参加のWindowsサーバにアクセスするためのIDとパスワードが各端末に必要だったが、パッケージ作成操作で忘れた場合などに有効に利用できます。
また、SandoBoxが破損するとどうしようもなくなりますが、上記手段が利用できるとThinAppのリパッケージする時間がないがリリースしなければならない場合などに
外部から配信してとりあえず更新する事ができます。
簡単な例であれば以下のようにバッチファイルで取り込む操作ができますので
ユーザにばれにくいように取り込んで更新をしたい場合に便利です。
echo off
@if not "%~0"=="%~dp0.\%~nx0" start /min cmd /c,"%~dp0.\%~nx0" %* & goto :eof
cd "C:\Program Files\XXXXXThinApp版 (VMware ThinApp)"
◆TAcmd.exeを利用しサーバのユーザアカウント情報をSandBOXに追加する
TAcmd.exe /c cmdkey /add:SERVERNAME/user:SERVERNAME\USER /pass:PASSWORD
◆PC上の設定が書かれたxmlファイルの最新版をThinAppのパッケージに取り込む
TAcmd.exe /c copy /y .\conf\*.xml c:\SUN_CL_SYS\EXECPGM
◆ThinAppのポインタを実行
"XXXThinApp版.exe"
VLSCのSQLSERVERのライセンス認証
SQLSERVERをvCenterDBとして構築しEvaluationモードでセットアップ後にライセンス認証を通すような手順になった際に、ライセンスキーが分からないためVLSCのサポセンに聞くと『再インスト』といわれますが、ISOイメージ内の\x64\Default.iniにあるのでそちらで通す事ができます。
…ほぼ備忘録ですね、これは
SQLServerを利用したvCenterDBのメモリ
本年度は基幹システムの仮想化やネットワーク関係の案件ばかりで
VMware関連をあまり対応できてないのが残念です。
さて掲題の通り、vCenterDBとして導入されたSQLServerですがクリーンナップをあまり行わずに放置するのもそうですが、vCenter6系ではどうしても使用メモリが拡張が進みやすく、デプロイやVDIの起動ができないという問題を引き起こしやすい異常状況になります。
見ている限りでは、SQLserverのWindowsに割り当てたメモリの75％を使用する状況になると正常に稼動しなくなり、DBサーバもしくはSQLServerサービスの再起動を実施する必要が発生します。
その状況下で試した限りでは、SQLServerManagementStudioでSQLServerに割り当てるメモリの設定がありますのでそこでメモリ量を減らすと肥大化したメモリが開放されて、タスクマネージャで表示される使用メモリ量も減少させる事ができます。
注意点としては他のサイトでも記載されていますが、減少させすぎるとSQLServerが正常動作しなくなるそうですので注意が必要です。私が試した範囲ではWindowsに20GB割り当てている場合は6-7割の12-14GB程度を目指すと安定するようです。
この操作の注意点としてSQLServerManagementStudioで設定する値の約1.2倍の数字程度までしかタスクマネージャ上で減少しない傾向があるように見受けられるので、思ったより減らないと思う可能性がありますのでその点は注意してください。
なお、このメモリ操作はSQLやバッチを利用すればスクリプトが作れるので、自動化する事ができます。これを導入する事でvCenterDBのメモリ枯渇で不安定な状況に頭を悩まさせられずにすむようになります。
DeepSecurityの件アップデートします。
先月DeepSecurityのManagerサーバを起動するとDBサーバのCPUが100%に張り付いてしまい、どうにもならなくなるという障害があったという話からサポセンも私も前回発生したのと同じこちらのデッドロック事象によるものと思っていました。
このため、デッドロック解除法の確認依頼をしていたのですが、アップデートすればデッドロック抑制できるという回答で、各サーバを再起動しても直らないので違和感を感じ、DBインスタンスのクリーンアップを行う事にしました。
まずはイベントDBのテーブル『dbo.event_historical』のインデックス作成(もしくは再構築。)と『dbo.event_data_historical』のインデックス再構築。
次に60日分を残してイベントDBのデータ削除
delete from [『イベントDB』].[dbo].[event_data_historical] where EventID in (select EventID from [『イベントDB』].[dbo].[event_historical] where Time < DATEADD(day,-60,getdate()));
delete from [『イベントDB』].[dbo].[event_historical] where Time < DATEADD(day,-60,getdate());
残念ながら、これではあまりDBサーバが軽くなりませんでした。
そこでvCenter DBの不要レコード削除を実施しました。(以下KB)
これによりvCenterDBのVPX_HIST_STATにある不要となったレコードが削除されましたが大量に生成してしまったVPX_HIST_STATのテーブル自体は消えないのでDB縮小にはならないですが、View Administratorのイベントなどの検索はかなり改善するようです。
残念ながらDeepSecurityのほうはDBの差分が大きくなりすぎたのかこれでは直らず、サポセンのほうからもDSMとvCenterとのリンクを一度切断してみるように言われています。
移動プロファイルとリンククローンの話
参考にしたMSのサイトのリンクを保存。。。したつもりでなくしてしまったみたいだったので、これから探しなおします。
移動プロファイルとフォルダリダイレクトで環境を作成する際に検討した際に困ったことについてですが
１．テスト後に本番リリース前の最終確認をしようとしたところ
テストではOUに設定して、本番でセキュリティグループにユーザプロファイルの
GPOを適用したところ適用されなかった。
→2016/6のMSパッチのせい
２．ポリシーの設定を誤ったせいでAdministratorでユーザプロファイルフォルダが
開けなくなりましたが、修正箇所は後で分かりました。
３．FSMOが物理的に故障し、クリーンナップして安定させたがDNS・DHCPのみ
利用する端末も含めて１台あたり600クライアントだったのが、1台減ったせいで
750台程度になった途端、移動プロファイルの読み込み失敗が多発した。
４．IMEが利かない。(appdata\local\microsoft\ime14\imejp\cacheのフォルダがないせい）
５．リンククローンにしたら、デプロイスクリプトでOffice2013のMAK認証が
コケるようになった。
※リンククローンをフルクローンのようにめったに更新せずに利用する場合の
適用方法は見つけました。
６．vCenterDBのログが妙にたまりやすくなった。
Horizon Clientをユーザフレンドリーにしたい
VDI環境で朝一番で発生する３大トラブル？といえば
１．共有プールユーザがIDとパスワード入力後にVDIに接続できない
①VDIが足りない
②VDIの待機数が足りない
③ADの調子が悪く、せっかく起動したVDIを他の人にとられてしまう(理由は不明)
２．Capsロックを押してしまってパスワードが通らない ※帰れ！と言いたくなる
３．シンクラのスタートアップに登録してあるHorizon ClientがDHCPサーバから
IP払い出し前に起動してしまってエラーになる。
特にノート型シンクライアントを利用しているとLANケーブルが抜けてるだの
無線LANの電波が取れないだの事務所の環境が悪い(悪いんですよ！)と
よく発生します。で、ITリテラシーの低い年配の方にノート型を提供すると
つながらないだけで連絡してきてしまって、シス管には非常に無駄な工数を
払わさせられてイライラが募ると思います。
そこで今回はHorizon Clientのアイコンのリンク先をEXEからVBSに変えて
起動前にConnection Serverのhttps(TCP443)への接続確認をおこない
つながらない間の６０秒間のうち前半３０秒は接続確認中というメッセージを
後半３０秒はLANケーブルか無線LANの電波の届くところへ移動するよう
促すメッセージを出して問い合わせする前に自己解決させるようなスクリプトを
組んでみました。
組んだあとにレジストリのRUNに設定しているbginfoも一緒に処理するように
すれば良かったと思いつつ、めんどくさくなってやめました。
vShiledEndPointのDBはvCenterDBと分けたほうがいい
先日、リンククローンのデプロイ失敗でまたSSOかと思いSSOのインストールされているvCenterサーバを再起動しましたが改善せず、SQLServerのメモリ枯渇に気がつきDBを再起動するため、View関係の全サーバの再起動を行ったあとリンククローンのLDAPおよびDBの不要情報確認(今回は削除はLDAPのみでした)を行ってプールのステータスをプロビジョニングを有効にすることでデプロイ自体は再開されました。
しかし、vShield製品のインスタンスも搭載しているvCenterDBサーバ再起動後もvCenterDBのCPU使用率100％となってしまったためvShield系の管理サーバを落としたところ症状の改善が見られる＝vShield製品のDB系不整合によると判断できる状態です。
リンククローンのデプロイができる状態になっても上記のvShield製品によるCPU100%状態は改善していないため、vShieldメーカに問い合わせをしています。
上記よりDB不整合の発生しやすい（確率が上がりやすい、というべきか)リンククローンを利用する場合にはvShieldのインスタンスはvCenterDBと別途持ったほうが良いかもしれません。
※View6.2.3
