Scripting

ものすごく長いタイトルになってしまいましたが、今回は管理者権限を持たないユーザーにどのように管理者権限を持たせるか、というお話です。 実際の案件の中では以下のような状況が頻繁にあります。 - エンドユーザーの端末にソフトウェアをインストールさせたい、あるいは管理者権限が無いとできない設定変更をさせたい - でも、エンドユーザーのアカウントには管理者権限がない - エンドユーザーに操作をしてもらうことは可能だけど、管理者のID、パスワードは教えたくない(セキュリティ上の問題) やりたいことは簡単なんですけど、「エンドユーザーには教えずに」ということを実現させようと思うと中々大変です。 理想の状況 このようなことは頻繁にあるものなので、これらを簡単に実現するツールが全端末に仕込まれている状況が理想的です。これを実現する製品は多数存在しています。有名なところだと以下のようなものでしょうか。(私が仕事でよく扱っているものなので、偏ってるかもしれません。) - [System Center Configuration Manager : ホーム](http://www.microsoft.com/japan/systemcenter/configmgr/default.mspx) - [IT資産管理 ツール QND Plus ｜ クオリティ](http://www.quality.co.jp/products/QND/) - [LanScope Cat6 トップページ](http://www.motex.co.jp/cat6/index.html) - [BigFix, Inc. | Faster, Smarter Systems Management](http://www.bigfix.com/) もっとも、これらの製品は総合的な管理ツールになっているので、今回話題にしていることだけをしたいような時に導入するようなものでもないです。お値段も結構しますし…、ということでこういった製品が導入されていない企業も数多くあります。特に日本企業には多い印象です。話で聞くところによると米国企業はほとんどなにかしら導入しているらしいですけれども。 Active Directoryのグループポリシーを使う方法 製品が導入されていない状況でこれを実現する方法として、まずADのGPOを使う方法があります。 ソフトウェアインストール 例えばソフトウェア配布なら「ソフトウェアインストール」を使うことができます。 ただ、これがなかなか曲者でして、以下の制限事項があります。 - インストールできるのはmsiパッケージのみ(setup.exeなどは無理) - 「コンピューターの構成」-「ソフトウェアインストール」で構成した場合ローカルのSYSTEM権限で実行される - 「ユーザーの構成」-「ソフトウェアインストール」で構成した場合ログオンユーザーの権限で実行される(今回の場合使えない) - インストールに成功したのか、失敗したのか、どの程度の進捗なのか等を管理者が把握できない 1.の制限により、そもそもこの機能では配布できないことが結構あります。2.の制限があるのでパッケージの置き場所はドメインユーザー以外もアクセス可能にしなくてはいけませんし、都合の悪いことにそもそもSYSTEM権限ではインストールが成功しないソフトウェアが結構存在します。そして、4の制限があるので、トラッキングができません。 というわけで、やってみてうまく動けばそれでいいのですが、結構なケースでこの方法が取れないことがあります。 スタートアップスクリプト 「ソフトウェアインストール」が使えない場合、あるいはそもそもソフトウェアインストールではない場合にはスタートアップスクリプトを使うこともできます。 これであれば自分でロジックを作り込めるのでsetup.exe等の実行ファイルであってもキックすることができます。また、成功、失敗等の把握はどうにでもできます。簡単にやるなら、例えばインストールログを共有フォルダに保存させるようなロジックにしてしまえばいいでしょう。 ですが、以下の制限事項は同じです。 - 「コンピューターの構成」-「ソフトウェアインストール」で構成した場合ローカルのSYSTEM権限で実行される - 「ユーザーの構成」-「ソフトウェアインストール」で構成した場合ログオンユーザーの権限で実行される(今回の場合使えない)コンピューターの構成に仕込んでみて、ローカルのSYSTEM権限のみでうまく行くことを祈ることになります。 このようにADを使う方法はどのパターンでも確実に成功するわけではありません。そして、そもそも論としてはADに参加しているクライアントでなければこの方法は取れないわけです。 その他の方法 他の方法としては以下のようなものがあります。どれも完全なソリューションではないですが・・・。 ...

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として記述しなくてはいけないというところにかなりの不満とめんどくささがありますが、他にやりようがないようなので仕方なくこの方法で行っています。 ...

私はWindowsServer管理者としてはスクリプトくらいはたしなみとしてできなくてはいけないと考えています。自動化できるものは自動化して仕事を楽にしなくてはいけません。 Dos時代のバッチファイルでは融通が利かなさすぎるし、現状のWindowsでスクリプトといえば、既定の状態で使える「WSH」くらいしか実質的な選択肢がありません。perlやrubyが好きなのでそれがいいと言っても、業務用のPCに追加でスクリプトエンジンをもれなくインストールして回るのは現実的に難しいのです。 WSH自体の説明、解説は以下のあたりが詳しいです。 Windows Script WSHを始めよう － ＠IT Windows Script Host Laboratory サンプルとしては以下のサイトがよくまとまっていて重宝します。 スクリプト センター 書籍としては以下の本が具体的なサンプルとして便利に使えます。かなり初心者向けの本ではありますけれども。 WSHクイックリファレンス 第2版 羽山 博 言語としてはVBScript、JScriptが規定の状態で使用できます。どちらがいいとは一概には言えませんがWindowsの業務の中ではVBScriptが使われることが多いようです。おそらくVBやOfficeアプリケーションでのVBAとの言語としての類似性や書ける人数の多さに起因しているものと思います（あくまでも私のまわり限定の話ですし、個人的な予想ですけれども。） 将来的にはPowerShellがこの地位を取って替わる予定ですが、市場に出回っているほぼすべての端末に規定の状態でインストールされるようになるまではWSHが主流の状態が続くものと思われます。例外はExchangeServer2007をはじめとしたPowerShell前提のサーバー製品です。これらに関しては必ずPowerShellでの管理が可能であり、これが既に主流になっていると感じています。