VBScript

主にインフラエンジニアからみて、過去から現在までの流れ…のようなものを私が見えている範囲で記載してみました。昨今はクラウド化の流れと相まって非常に高度な自動化やインフラのコード化まで実現可能となっており例えば「スクリプトも書いたことありません」という人に対してどの領域から飛び込んでもらうのが効率的か…をちょっと悩んでいます。 もうコーディングレスでLogic Appとかそういうところに飛び込んでもらった方がはやいのかもしれないし、仮想基盤のことやWindows, Linuxの中の事はすっ飛ばしてTerraformとかコンテナとかそこに注力するところから入って必要が出たところで仮想マシン内部の処理に入ったほうがいいのかもしれません。でも、現実的にはシェルスクリプトとかPowerShellスクリプトの基礎とかは抑えておかないとだめかもしれないし・・・。結構悩ましい所です。 - 昔はバッチファイルやシェルスクリプトで繰り返し実施する作業の効率化がありました。 - その後Windows的にはWSHの時代があり、vbscriptでスクリプトを書いたひとも多かったと思います。 - その後Microsoft的にはコマンド毎にオプションが違ったりコマンドがなかったりすることを解決し、全て統一するものとしてPowerShellを生み出しました。(私の大好きな[Jeffery Snover](https://twitter.com/jsnover)さんの仕事です。) - これでMicrosoft系はPowerShellで全てオブジェクト指向の管理となりました。(バックグラウンドにあるのは.net framework) - 一方UNIX系は当初からなんでもかんでもテキストであるという思想でした。 - MicrosoftはPowerShellを標準として様々な製品を開発しました。GUIではできないことでもPowerShellでなら操作できる。GUIで操作しても裏ではPowerShellコマンドが自動生成されてそれが実行されている…というものも多くありました。(結果、仕方がなくPowerShellを使うようになった方も多いと思います。) - Microsoftはクラウドサービスにもその流れを取り入れました。PowerShellにてクラウドサービスの管理も行うことになりました。 - Chef, Puppetなどに代表されるような冪等性を備えた仕組みが登場してきました。(Infrastructure as code, Configuration as code) 何度実行しても「記載した望むべき状態になる」ことを特徴とします。 - これ以前は「これを実行したらこうなる、やって見る前に状態を確認して、やってみて、やった結果を確認する」というような作業の流れを記述するようなイメージでした。 - MicrosoftもPowerShell DSCにて冪等性を持つフレームワークを提供しました。 - Microsoftのオープンソース指向が進む中でよりマルチプラットフォーム化を意識した取り組みがなされるようになっていきます。 - PowerShellの継続開発が打ち切られ、PowerShellCoreに舵がきられます。PowerShellCoreはWindowsだけではなく、Linux, Mac等でも動作するマルチプラットフォームなPowerShellです。(バックグラウンドにあるのは.net core) - AzureにもCloudShellの機能がつき、ポータル上でもコードで制御できるようになります。これまでのAzure PowerShellよりも先にAzure CLI(UNIX系の文化)の方が先に搭載されました。Azure管理はPowerShellよりもCLIの方が優先されるようになってきています。 - クラウドサービスも普及する中で、大規模な環境ではもう個別に１台づつターミナルで作業するなり、RDPではいってGUIで操作するなりすることが現実的に不可能な規模になりました。このような環境ではコードで全てを制御可能な環境にすることは必須条件となりました。 - WindowsもWindows Server Coreが出てGUIがなくなり、さらにNano Serverにてどんどん軽量化していきます。 - Windows Server 2016, 2019となると継続的に進化するモデルはGUIが利用できなくなりました。 - 更に軽量化を推し進める中で仮想マシンではなく、コンテナに大きくトレンドが傾きます。 - コンテナの標準であるDockerはDockerfileというコンテナをコードで定義できる機構を備えています。 - クラウドサービスも冪等性をもったテンプレートにて展開可能な構造となります。AzureであればARMテンプレート、AWSであればCloud formationなど。 - ARMテンプレート、Cloud formationによるInfrastructre as Codeと仮想マシンの内部を構成するChef, Puppet, AnsibleのようなConfiguration as Codeによって仮想マシンベースの環境構築の完全自動化が可能となりました。 - ARMテンプレート、Cloud formationによるInfrastructre as CodeとDockerによるコンテナコントロールで完全自動化が可能となりました。 - 複数のコンテナプラットフォーム自体のコントロールという観点ではKubernetesが標準化してきています。 - AWSLambda, Azure Fuctionsのようなインフラ自体を意識せずアプリケーションロジックのみを記載すればそれでおしまいとなるようなサービスも出てきました。ここではInfrastructure as CodeやConfiguration as Codeすら必要ない世界があります。(これですべてまかなえるわけでもないですが) - DevOpsという流れもありますが、NoOpsに向かう流れの方が強そうに感じています。(私の感想) ※NoOpsはインフラ管理者がいらないという意味ではなく、極力インフラの面倒を見なくていいアーキテクチャを採用する、くらいの意味で捉えています。 ...

SCOMで監視をしているとスクリプトのデバックをしたくなることがあります。実際に自分でスクリプトを動かしてみて動作を確認したり、直接スクリプトを参照して内部ロジックを確認したり…。 これを行うにはまず、該当のモニターのタイムアウトを1秒とかに設定してしまって、意図的にタイムアウトさせてしまい、その情報をイベントログに記録させてしまうのが一番早いです(おそらく)。 これでタイムアウトを短くしてしまえば、タイムアウトした時に、イベントログにタイムアウトしたスクリプト名やその時の引数等が記録されます。 あとはスクリプトファイルを捕まえてあげれば自由にデバッグできるようになります。 エージェント側で実際のスクリプトを確認します。 C:\Program Files\System Center Operations Manager\Agent\Health Service State このディレクトリ以下に実際のスクリプト等が格納されているのでコマンドプロンプトにてサブディレクトリも含めてスクリプト検索を行います。ゲートウェイが存在している環境では別のディレクトリに格納されていると思います。 dir /b /s *.vbs このようにスクリプト一覧が出力されますので、目的のスクリプトを確保することができます。 また、SCOMサーバー側でも管理パックをエクスポートすることで定義を確認する方法もあります。 SCOM PowerShellから以下のコマンドで管理パックをエクスポートして、中身に対してスクリプト名で検索をかけるとよいでしょう。 Get-SCOMManagementPack | Export-SCOMManagementPack -path c:\mp たとえば、GetSQL2012DBFilesFreeSpace.vbsであれば以下のようになります。 目的のものが手に入ったら、あとは、コマンドプロンプトで実際にスクリプトに正しい引数を与えながらデバッグを実行することになります。スクリプトをコピーしてprintfデバッグをしてもよいですし、環境が許せばデバッグ実行をするのもよいでしょう。 vbscriptであればcscriptに//Xオプションをつけることでデバッグ実行ができます。もちろんその場合にはデバッガーが環境に入っていないといけません。 c:\tmp>cscript /? Microsoft (R) Windows Script Host Version 5.8 Copyright (C) Microsoft Corporation. All rights reserved. Usage: CScript scriptname.extension [option…] [arguments…] Options: //B Batch mode: Suppresses script errors and prompts from displaying //D Enable Active Debugging //E:engine Use engine for executing script //H:CScript Changes the default script host to CScript.exe //H:WScript Changes the default script host to WScript.exe (default) //I Interactive mode (default, opposite of //B) //Job:xxxx Execute a WSF job //Logo Display logo (default) //Nologo Prevent logo display: No banner will be shown at execution time //S Save current command line options for this user //T:nn Time out in seconds: Maximum time a script is permitted to run //X Execute script in debugger //U Use Unicode for redirected I/O from the console ...

UACが有効な環境では管理者権限が必要な操作をスクリプトから実行させようとすると失敗します。これを回避するためにはきちんと「昇格」させてあげなければいけません。 VBScriptで昇格させる方法はかなり前に以下の日記に書きました。 - [Windows VistaでのWSH(VBScript)の管理者権限への昇格方法 - ebi's diary - インフラエンジニアの子育てなどの日記(2008-08-13)](http://ebi.dyndns.biz/diary/20080813.html) 同様にPowerShellでも昇格させたい場合にはStart-Processの-Verbオプションに「RunAs」という引数を渡すことで実現可能です。ヘルプにも以下のように書かれています。 Starts a PowerShell process with “Run as Administrator” permissions. PS C:>start-process powershell.exe -verb runas VBScript, PowerShellそれぞれの私が良く使用するスニペットを貼り付けておきます。どちらも自分で書いたのではなく、どこかのコードを参考にさせてもらったものだったと思いますが、失念してしまいました・・・。 vbscript PowerShell

SCCM自体ほぼリアルタイムに反応するようなシステムではなく、設定が反映されるまでに長い時間がかかってしまいます。ですが、そういう環境でも「なるべく早く設定を反映したい、結果を得たい」という時にはクライアント側でアクションをキックする、ということができます。 クライアントアクションは以下のように多数存在しています。 クライアントコンピューター上で1台ずつすべて操作をするのも大変なので、スクリプトでキックできると素敵です。これはCPAPPLET.CPAppletMgrというCOMオブジェクトを使うことで可能です。以下、VBScriptとPowerShellのスクリプト例です。 [gist id=“4942879”] [gist id=“4942874”] 参考になれば幸いです。

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SCCMのクライアントアクションをスクリプトで実行する方法 | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/02/16/sccm%E3%81%AE%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E3%82%A2%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%97%E3%83%88%E3%81%A7%E5%AE%9F%E8%A1%8C/)

特定ディレクトリ以下のファイルオブジェクトを取得するサンプルコードです。 [gist]https://gist.github.com/2716715[/gist] 再帰関数内でオブジェクトを新規に作成してそれを返り値として返すことがなかなかうまくいかなかったので、外部のスコープで定義したScripting.Dictionaryオブジェクトに値を追加する実装で妥協しました……。

レジストリへの値設定スクリプトです。事前に値を確認し、変更の必要があることを確認し、書き込み、きちんと書き込めたかどうか確認しています。 WindowsVista, 7, 2008, 2008 R2でUACが有効な場合には管理者権限があっても書き込みに失敗してしまうので、事前に昇格をおこなってから実行させる必要があります。 - [Windows VistaでのWSH(VBScript)の管理者権限への昇格方法 - ebi's diary(2008-08-13)](http://ebi.dyndns.biz/diary/20080813.html#p01) [gist]https://gist.github.com/2601725[/gist]

VBScriptでちょっとしたスクリプトを書き捨てることは今までにかなりしてきましたが、そろそろPowerShellに本格的に移行できる感じになってきました。とはいえまだまだVBScirptの出番もあると思いますので、今まで書き捨ててきたスクリプトの中で特に「毎回同じこと書いてるなー」と感じるような処理についてgistに上げつつ共有できるようにして行きたいと思います。 まずは、どのスクリプトでもほぼ必ず行うファイルへのログ出力処理です。 [gist]https://gist.github.com/2586011[/gist]

WSHスクリプト(VBScript)でライブラリをインクルードするでライブラリをインクルードして…という話を書きましたが、実際に自分でライブラリ的なものを作成してくと、その品質保持が重要になってきます。私は品質保持のためにはxUnitを使ってユニットテストを自動化するのがよいと思っています。 ユニットテスト自体の内容は以下のあたりで確認してみてください。 xUnit - Wikipedia ＠IT：連載：快適なXPドライビングのすすめ 第4回 JUnit 実践講座 で、JavaならJUnit、C#ならNUnitなど非常にメジャーなテスティングフレームワークがある一方で、WSH用には…というと、ほとんど見つけられないというのが現状です。私も長い間ことあるたびに探してみたりしたのですが結局ずっと見つけられずにいて、かなりストレスがたまっていました。(自分で作ればいいのでしょうけれども、そこまでの力と気力が…) ですが、以下のサイトにてこの辺りのことが書かれていました。 UJS/UnitTestFramework - |▽￣)ノ なページ再帰 - livedoor Wiki（ウィキ） このサイトで直接書かれているのはJScriptに関する事です。Javascript用のテスティングフレームワークでそのまま使えるものがある、ということのようです。 さらにScriptUnitに関しては明確にVBScriptとJScriptへの対応を謳っています。 This works well enough for VBScript and JScript, but ActiveState PerlScript doesn’t work as well. ということで、ScriptUnitを用いてWSHで書いたライブラリをテストする方法を実際にこれから試してみようと思います。 (後日追記予定)

仕事を楽にするためにWSHを使いこなすでWSHの必要性について書きましたが、実際にWSHでいろいろとスクリプトを書いていくと、当たり前のようにライブラリが欲しくなります。インターネット上で探してもめぼしいライブラリは見つからないというのが現状だと思います。（もしも良いライブラリを知っている人がいたら教えてください!） そこで仕方なく（?）自分でライブラリを整備しています。具体的にはVBScriptでクラスを作成し、それを利用するスクリプトを拡張子.wsfで作成し、インクルードさせるようにしています。 具体的な記述内容は以下のようになります。 " m a i n " > " V B S c r i p t " s r c = " V B S L i b . c l a s s " " V B S c r i p t " > ' こ こ が ス ク リ プ ト の 本 体 VBSLib.classファイルにクラスが定義されている、というわけです。インクルードするだけのためにわざわざwsfファイルにしてXMLとして記述しなくてはいけないというところにかなりの不満とめんどくささがありますが、他にやりようがないようなので仕方なくこの方法で行っています。 ...