Wsh

主にインフラエンジニアからみて、過去から現在までの流れ…のようなものを私が見えている範囲で記載してみました。昨今はクラウド化の流れと相まって非常に高度な自動化やインフラのコード化まで実現可能となっており例えば「スクリプトも書いたことありません」という人に対してどの領域から飛び込んでもらうのが効率的か…をちょっと悩んでいます。 もうコーディングレスで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はインフラ管理者がいらないという意味ではなく、極力インフラの面倒を見なくていいアーキテクチャを採用する、くらいの意味で捉えています。 ...

特定ディレクトリ以下のファイルオブジェクトを取得するサンプルコードです。 [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でレジストリをいじるのが非常に面倒なことを改めて知って衝撃をうけちゃいました。 サブキーの列挙ができない キーの存在判定ができない レジストリキーのリネームができない なんでもっと機能ないんでしょうね?よく理解出来ないです。 サブキーの列挙はWMIでやりました。 {{' F E u n n d c e S S S C C R G t c e e e o o e e F i h t t t n n g t u o o s s . C n n L S R t t E h c " o e e n i t G G c r g H T u l i e e a v K A m d o t t t i = E R K N n C C o c Y G e o h h r e S _ E y d i i e C T e l l = = r U K H d d v R E K = N N C L i R Y E o o r o c E Y S d d e c e N = _ u e e a a . T C b ( t t G _ " U K r C e o e U r R e e a O r t S e R y g l b . ( E g E P l j C " R P N a e e o S a T t d c n t = t _ h " t n d h U ) ( e R & " S " c e H E W t g 8 R b S P 0 , e e r 0 m r o 0 r S v v 0 e c e " 0 g r r ) 0 P i ( 1 a p v t t b h i N , n u g l S . l u S S b W t K b r e e i y m n L g o , c a " t r o o r o " t ) \ d e f a u l t " ) ‘}} ...

ものすごく長いタイトルになってしまいましたが、今回は管理者権限を持たないユーザーにどのように管理者権限を持たせるか、というお話です。 実際の案件の中では以下のような状況が頻繁にあります。 - エンドユーザーの端末にソフトウェアをインストールさせたい、あるいは管理者権限が無いとできない設定変更をさせたい - でも、エンドユーザーのアカウントには管理者権限がない - エンドユーザーに操作をしてもらうことは可能だけど、管理者の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のUnitTestに関してVBAUnit以外にもScriptUnit, ComUnitという使えそうなものがあることを発見。日本人で使っている人はほぼいないみたいだけど試してみてよさそうな方を使っていこうと思います。 xt1.org » ScriptUnit – Christian Mogensen writes software and dreams of droids COMUnit: A Unit Testing Framework for COM

仕事を楽にするために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での管理が可能であり、これが既に主流になっていると感じています。

WSHでUnitテストがしたいです。どうにかしてしたい。VBAUnitを使うしかないかなぁ・・・。移植仕様かなぁ・・・。

今まで無くて不便だなぁと、VBAにはCollectionオブジェクトがあるのになぁと思っていたのですが、今日再度調べてみたら、WSHにもDictionaryオブジェクトがあることに気がつきました。ヘルプはこちら。 ヘルプはちゃんと読まなくちゃだめですね・・・。