先日 Excel PowerShell Tool を使って Hyper-V を管理してみましたが、
同様の仕組みを VMware に移植してしてみました。

VMware のハイパーバイザーは有料だと思い込んでいたのですが、
VMware vSphere Hypervisor(ESXi) は無料で利用できると知りました。
このような美味しいシステムを知らずにいたとはお恥ずかしい…

PowerShell 用のコマンド群 VMware vSphere PowerCLI も用意されています。
これはもう PS Tool で利用するしか! と思ったのですが、結構大きな問題が出ました。

VSTO のアプリケーションドメインは、アセンブリのシャドウコピーを利用する設定になっています。
この状態で Runspace を作り、Add-PSSnapin "VMware.VimAutomation.Core" を実行すると、
VMware 関連の DLL もシャドウコピーが作られてしまい、スナップインが機能しません。
SharePoint 用のスナップイン等、GAC に登録されているアセンブリにはシャドウコピーが発動しないのですが、
VMware のコマンドレットには厳密名が付与されていないので GAC には登録出来ません。

さて困った…
シャドウコピーしなくても殆ど問題は無いはず(それどころかシャドウコピーで障害が発生する)なので、
シャドウコピーを作らない PS Tool を(無理やり)作ったところ、ちゃんと動いてくれました。
VMware vSphere PowerCLI は GAC に登録するべき製品だと思うのですが、とりあえず良しとしましょう。

このバージョンの PS Tool はVSTOの設定を無効にしているので副作用が予想されます。
暫くテストをした後に公開しようと思っていますが、そんなの全然大丈夫な方はご連絡ください。

無料とはいえ ESXi は高機能です。
Hyper-V の気楽さはありませんが、本格的な運用には痒い所に手が届く感じでしょうか?
この際だからもっと強力な運用スクリプトを書いてみようかな～

SharePoint 2010 には多数の専用コマンドレットが用意されています。
これらをインストールしたサーバー上で使う時には問題が出ませんが、外部のPCからリモートで、
つまり WinRM 経由で呼び出すと何かと不具合が出ます。

先日作った、Get-SPDocumentPage.ps1 というスクリプトファイルがあります。
これを普通に起動すると… 

普通に動きますww  しかし、Invoke-Command -ComputerName xx で呼び出すと…

なにやら不穏なエラーが返ります。 しかもこのエラー、時々内容が変わります。

いろいろ調べてみたところ、PowerShell をリモート経由で呼び出す場合、SharePoint 用のコマンドレットのような大規模なものは
メモリー不足に陥りやすい事が判明しました。 回避するには WSMan プロバイダーの設定を変更してやる必要があります。

WSman:\localhost\shell に移動して、 MaxMemoryPerShellMB の値を大きくしてやります。
初期値が 150 なので 1024 にしてみました。

これで余裕が生まれ、リモートコマンドが成功します。

Invoke-Command でリモート実行すると、自動的に PSComputerName, RunspaceId というプロパティが追加されます。
便利な様で意外に邪魔だったりします。

Invoke-Command 時に -Credential オプションを指定せず、実行ユーザーの認証情報を使いたい場合には
Credential Security Provider の設定をする必要があります。 

クライアントPCで
> Enable-WSManCredSSP -role client -DelegateComputer sp2010    (※sp2010 はサーバー名)
サーバーで
> Enable-WSManCredSSP -role server

としてやればOKですが、セキュリティレベルの低下に繋がるので要注意です。

これで Excel PowerShell Tool から SharePoint 2010 を管理する準備が出来ました。

PowerGUI は PowerShell スクリプトの開発にとても役に立つツールです。
しかし SharePoint 2010 がインストールされた環境にうっかり .Net Framework 4 を入れてしまうと悲しい思いをします。

これは先日の Excel PowerShell Tool の件と同様で、Runspace を作る際の CLR が4.0.xx になるからです。
しかし、exe の場合は app.config の編集でこの問題を回避出来ます。

PowerGUI の場合、C:\Program Files (x86)\PowerGUI\ScriptEditor.exe.config を編集します。

先頭の方にある上の行が邪魔をしています。
本当はこれは 「わざわざ CLR V4 を利用する」 指定なんですが、SharePoint 2010 の場合はこれが災いを招きます。

すっきりしまた… これで SharePoint のコマンドレットも動いてくれます。
PS Tool の場合もこれで回避できると思ったのですが、VSTO 自体が Framework 4 必須なのでうまくいきませんでした...orz

SharePoint は機能は豊富ですが、今ひとつ使いにくいのは GUI が遅くメニューが深いからでしょうか?
せめて HTML を直接編集出来れば…と思い、コツコツ作っているのが ↓ です。

これは "チームサイト" の HTML を抽出したものです。

SharePoint では Webパーツの組み合わせで素早くページを作れますが、HTMLで編集するにはこれが邪魔になります。
<div class="ms-xxxxxxx"> なんかで挿入される Web パーツはページのHTMLからは把握出来ません。
といっても、 Webパーツで HTML 記述するのはコンテンツエディター位なので、それに限定すればHTMLの抽出は可能です。
あとはそれを Excel に落としてやれば好きに出来ますねww 

多くのサイトに設置されている 「いいね」や「Tweet」ボタンを設置してみました。
当ブログは BlogEngine.Net を使っているので、使えそうな拡張機能を探してみると･･･

AddThis for BE2.5 - 2.2.0.0

AddThis は多くのブックマークボタンをサポートしていますが、今回は FB と Twitter に限定です。
BlogEngine の拡張は C# ソースを置くだけなので(改造も含め)すごく便利ですね。 

追記:
テストしたら、Twitter は日本語URLに未対応だったので削除です

追記2:
どうも動きがしっくりこないのでOFFにしました。
BlogEngine.Net もバージョンアップしているので、切替時に再挑戦してみます。 

追記３:
別の方法で Facebook の "いいね" を付けてみました。 

SharePoint 2010 は .Net Framework 4.0 ではサポートされないわけですがうまく回避出来ません。

Excel PowerShell Tool は Visual Studio 2012 の VSTO で作成していますが、
このバージョンでは Framewwok 4.0 以降しか選択出来ません。
そこで作成された dll から Runspace (≒PowerShell) を作ると、CLR 4.0 が選ばれてしまうのです...

 ← CLRVersion に注目!

dll.config の設定や、アウトプロセスで PowerShell を呼び出す等の技を試してみましたが、うまく行きません。
うまく行ったとしても、Framework 4.0 に加え WMF3.0 も必須になるので本末転倒です。
(※アウトプロセス起動はWMF3.0からの機能) 

いろいろ考えたのですが、PS Tool を PowerShell 2.0 と 3.0 用で分けるのが良いと判断しています。
そのためには Visual Studio 2010 に再登場願わなければ…
PowerShell 3.0 は、Framework 4 + WMF3.0 が必須なのでWin7/Server 2008R2 では追加インストールとなりますが、
Win8/Server 2012 の時代だし問題ないでしょう。

それより、WMF3.0 を入れた環境で、あえて PowerShell 2.0 を使う…といった場合に問題が出そうです。 
PowerShell のバージョンを選択できるメニューを追加するなりで対処できるつもりですが、そんなに需要はないでしょうww
それよりも PS Tool にコンソール機能をつけるとかをやりたいです。 

追記:
ちょっと考えてみれば、PS Tool を SharePoint 2010 の環境で動かす必要は全くないですね。
Invoke-Command をリモートから投げてやればOKじゃないです...orz
SharePoint PC に開発環境を入れるのが当たり前になっていたので基本を忘れていました。
Invoke-Command の戻り値は多少癖がありますが、PowerShell のバージョン毎に PS Tool を作るより全然楽です。