全然話が変わるのですが、slideshare（スライドシェア）ってご存知ですか？
Junichi Anno Presentations
PPT や PDF なんかをインターネット上で共有するのに、とても便利なサイトです。私も、セミナー資料で外部に公開できるものは、このサイトで公開しています。
ただ、ちょっと困ったことがあります。
それは、PowerPoint 2010 で作成したプレゼンテーションがうまくアップロードできないことがあります。
私の経験上、うまくいかない条件は以下の通りです。
じゃぁ...ということでアニメーションを片っ端から��除すればよいのですが、例えば300ページもある資料のアニメーションをちまちま削除するのは超面倒くさい！
ということで、スクリプトで一気に処理することにします。
今回は、ものぐさして VBScript を使いました。拡張子、.vbs で保存してください。
On Error Resume Next
'ファイル名をフルパスで指定 PPTFileName = "c:\tmp\ADFS2_ACSV2_Azure_StepByStep_v2.2_Update1_NoAnime.pptx"
ppSaveAsPresentation = 1 ppSaveAsPowerPoint7 = 2 ppSaveAsPowerPoint4 = 3 ppSaveAsPowerPoint3 = 4 ppSaveAsTemplate = 5 ppSaveAsRTF = 6 ppSaveAsShow = 7 ppSaveAsAddIn = 8 ppSaveAsPowerPoint4FarEast = 10 ppSaveAsDefault = 11 ppSaveAsHTML = 12 ppSaveAsHTMLv3 = 13 ppSaveAsHTMLDual = 14 ppSaveAsMetaFile = 15 ppSaveAsGIF = 16 ppSaveAsJPG = 17 ppSaveAsPNG = 18 ppSaveAsBMP = 19 msoFalse = 0 msoTrue = -1 msoTriStateMixed = -2
'PowerPoint起動 Set objPPT = CreateObject("Powerpoint.Application") objPPT.Visible = True
'ファイルオープン Set objPresentation = objPPT.Presentations.Open(PPTFileName)
Wscript.Echo "ファイル名:" & pptFileName Wscript.Echo "スライド数:" & objPresentation.Slides.Count
flgDeleted = False
'スライドを1枚1枚確認 For I = 1 To objPresentation.Slides.Count
strTitle = objPresentation.Slides(i).Shapes(1).TextFrame.TextRange.Text strSlideNumber = objPresentation.Slides(i).SlideNumber strNumOfAnimationItems = objPresentation.Slides(i).TimeLine.MainSequence.Count
'もしアニメーションが含まれていれば全部削除 If objPresentation.Slides(i).TimeLine.MainSequence.Count <> 0 Then flgDeleted = True Wscript.Echo strSlideNumber & ":" & strTitle WScript.Echo " " & strNumOfAnimationItems & " 個のアニメーションを削除します" For j = objPresentation.Slides(i).TimeLine.MainSequence.Count To 1 Step -1 objPresentation.Slides(i).TimeLine.MainSequence(j).Delete Next End If
Next
If flgDeleted = True Then '名前を付けて保存。このとき、フォントの埋め込みは解除（msoFalse） objPresentation.SaveCopyAs PPTFileName & ".アニメ削除済.pptx",ppSaveAsDefault,msoFalse Else WScript.Echo "アニメーションは存在しませんでした" End If
objPresentation.Close objPPT.quit
Wscript.Quit
かなり手抜きのスクリプトですが、参考までに。
IT Pro の皆さん。クラウドには着手しましたか？といっても、そんな余裕とか無い方が多いはずです。
勉強しようと思っても、なんだか開発者向けのドキュメントばかりで、じゃぁ、インフラSEはどうしたらいいんだよと思ったりもしていらっしゃるかと。
そんな悩みと苦情にお答えするために、本日以下のドキュメントを公開しました。
IT Pro (IT 担当者) のための Windows Azure Platform 運用管理ガイド 1.0
あちこちに散らばった情報をこのドキュメントに集め、IT Pro が資料探しで時間を浪費することの無いように構成にしたつもりです。視点は完全にIT Pro なので、ところどころに開発者との調整事項等が記載されていたりもします。
...ただ、あまりもページ数が多くて一気に公開できなかったので、以下のスケジュールで公開予定です。すみません...。
6月末には、一括ダウンロードできるようにしますので、しばらくお待ちくださいませ。
このドキュメントには、多くの皆さまにご協力いただいていており、当執筆活動にはほぼ無償で参加していただいてます。Twitter を使用されている方であれば、おそらくご存知の方々です。
Twitter @normalian
割と普通 という名前でコミュニティ活動中。Windows Azure の CTP から萌え続け、血のつながらない娘が育ったような気分で生温かい目を向ける昨今。クラウディアとの結婚をもくろむ Windows Azure MVP。妄想は激しいですが、腕は確かです。 ブログ: http://d.hatena.ne.jp/waritohutsu
Twitter @bird982000
通称 鳥兄者。都内に出没する永遠のエンジニア見習い。趣味で MS 技術をたしなみ中。WINGS プロジェクトで記事も書いたりしています。 ブログ: http://d.hatena.ne.jp/bird982000/
Twitter @Masayuki_Ozawa
本名 小澤 真之。都内の SIer に勤務し、主に社内のマイクロソフト製品の技術支援に従事。VM Role であんなことやこんなことができないかと、えっちらほっちらしている夢追い人。 ブログ: http://engineermemo.wordpress.com/
Twitter @kamebuchi
本名 亀渕 景司。開発からインフラまで何でもこいな、なんちゃってオールラウンダー。今日も玉石混淆織り交ぜながら、いわれなき 2 つ名を返上すべく活動中。 ブログ: http://buchizo.wordpress.com/
Twitter @zhuky7
本名 高井 一輝。普段はシステム設計から運用管理まで担当する何でも屋。ハイレベルな執筆陣に囲まれて、プレッシャーに耐えながら日々勉強中。 ブログ: 整備中につき秘密
Twitter @twmoris
本名 森島政人。地方に済む生粋のソフトウェア開発者だったはずなのに、現在クラウド エンジニアまっしぐら。 非 IT Pro なのに、IT Pro 向け解説させていただく貴重な機会を与えて頂き、勉強の日々。
Twitter @SQLAzureJP
本名 大和屋 貴仁。世界でも数少ない SQL Azure MVP の 1 人。SQL Azure Migration Wizard の日本語化を推進するなど、海外エンジニアとの関わりも多い。 ブログ: http://sqlazure.jp/b/
先日の投稿で紹介した資料には、Windows Azure AppFabric Access Contorol Service を使用して、外部のアイデンティティプロバイダーからセキュリティトークンを受け取る方法をステップバイステップで紹介しています。
資料：AD FS 2.0 と Windows Azuer AppFabric ACS V2 を使用した SSO の構築 第2.2版
まだまだ書き足りないことがあるので、BLOGを通じて少しずつ解説を加えていきます。ある程度たまったら資料をアップデートします。
さて。以前の投稿で「クレームタイプ（要求の種類）」の話をしました。クレームタイプによってクレームが識別されるので注意しましょう...というお話でした。クレームタイプの話をしたのは理由があります。
【IDM】AD FS や ACS を触るならば クレームタイプ（Claim Type、要求の種類）について理解しておくのが吉です
クレームタイプを理解しておくことの重要性を痛感するのは、身近な例では AD FS と Windows Azure AppFabric ACS の連携時です。つまり、以下のような環境ですね。
数字は、この環境におけるセキュリティトークンの流れを示したものです。
軽く解説しておきましょう。
① AD FS からセキュリティトークンが発行される ② ブラウザを経由して AppFabric ACS にセキュリティトークンが渡される ③ ACS が変換ルールを使ってセキュリティトークンを精査し、新しいセキュリティトークンを発行 ④ 新セキュリティトークンがブラウザに返される ⑤ ブラウザは新セキュリティトークンをアプリケーションに渡す
このとき、皆さんに強く意識していただきたいのは、③ です。
AD FS から発行されたセキュリティトークンは、ACS によって分解され、クレームの中身がチェックされます。このチェックに関するルールが、「クレームルール（Claim Rule）」と呼ばれるものです。以下の図はセキュリティトークンが ③ を通過するイメージを描いたものです。
AD FS によって発行されたセキュリティトークンは ACS に取り込まれたあと、以下のロジックでクレームルールが実行されます。
IF {
・セキュリティトークンを発行したアイデンティティプロバイダーは合っているか？ and ・入力されたクレームタイプは正しいか？ and ・クレームタイプに格納されている値は正しいか？
} Then { ・発行するクレームタイプ ・発行するクレームタイプに入力する値 }
} Then {
・発行するクレームタイプ ・発行するクレームタイプに入力する値
}
このロジックを通過して発行されたクレームルールが、再度セキュリティトークンとしてACSによって署名され、ブラウザを経由してアプリケーションに渡されます。
....ということは....このルールに定義されていないクレームタイプは、アプリケーションに渡すことができません。
いくら、AD FS の設定画面でクレームの定義を行っても、ACS のルールに合致しなければACSを通過することができないわけですね。この問題に最も直面しやすいのは、AD FS で独自に「要求記述」を定義したときです。
AD FS と ACS の信頼関係を結ぶときには、AD FS のメタデータを ACS に読み込ませます。メタデータには AD FS で使用可能なクレームタイプが記述されており、ACS のクレームルール設定画面で「ルールの生成（Generate）」を実行すると、メタデータから読み込まれたクレームタイプが自動的にルールとして定義されます。
一度信頼関係を構築した後、新たに要求記述を定義したとしましょう。例えば、以下の「部署」「従業員番号」「会社名」「国」は後から定義したクレームタイプです。
AD FS 側のクレームルールで「国」を定義しても、ACS 側のクレームルールに「国」が記載されていなければ、ACS はクレームを受け取ることができません。
ではどうするかといえば、ACS のクレームルールに手動でクレームタイプを定義する必要があります。
以下は、ACS のクレームルール定義画面のうち、入力側のクレームルールを定義する部分です。見づらくてすいません。
① はクレームの発行元（Identity Provider）です。発行元が異なると真っ先にはじかれるので正しい発行元を指定してください。
② はクレームタイプです。もともとどこにも定義されていないので、自分で記述する必要があります。ここでは、以下のように記述しています。
http://schemas.tf.com/claims/co
もちろんこの値は、AD FS の要求記述に定義した値と同じものです。当然です。
ちなみに、最後に「/（スラッシュ）」を入れてしまうと、エラーが発生し、なぜか二度とルールを開けなくなるので気を付けてください！！ http://schemas.tf.com/claims/co/
③ は②で指定したクレームタイプに入っているはずの値です。個々で指定した値に合致しなければ、IF文は True にならないので、新しいクレームは発行されません。今回は、Any を選択しているので「なんでもOK」という意味になります。
以下の画面は発行ルール部分です。これも見づらくてすんません。
④ では発行先のクレームタイプです。今回は入力と同じクレームタイプを指定しました。ちなみに、入ってきたものをそのまんまスルーする場合には、「Pass through input claims type」を選択してもOKです。
⑤ は発行先のクレームタイプに格納する値です。今回は入ってきた値をそのままスルーするので「Pass through input claim value」を選択しています。
以上の設定を行っておくと、以下のようにアプリケーション側で独自のクレームタイプを取得することができるようになります。
ACSに登録した AD FS のメタデータは後から入れ替えることもできるので、AD FS の新しいメタデータを再度ACSに取込み、ルールを再生成（Generate）してもOKです。
（参考）【Azure for IT Pro】Azure AppFabric ACS で、入力クレームを無条件スルーするための設定
前回、以下の投稿をしました。
AD FS で独自に定義したクレームタイプを Windows Azure AppFabric ACS で受けとる
ACS との信頼関係を構築した後に AD FS 2.0 で独自に定義したクレームタイプは、ACS 側に手動でクレームルールを定義してあげないと ACS で受け取れません...という話です。詳細は投稿をご覧ください。
それを踏まえて、1つ疑問が出てきます。
「面倒だから、何でもかんでも無条件で受け取れるようにできないものかね？」
はい、ACS のクレームルールで定義すれば、できます。
以下の画面は ACS で新しいクレームルールを定義する画面（入力方向のクレームタイプ部分）です。
Input claim type に「Any」を、Input claim value にも「Any」を設定しています。つまり、どんなクレームタイプでも、そこにどんな値が入っていてもスルーする...という意味です。
出力方向も同様に、以下のように設定すれば、入力方向のクレームタイプをそのまま出力方向のクレームタイプとしてスルーします。
この設定が1つ入っていると、他のルールは全く意味を持ちません。
なぜならば、このルールによって全てのクレームタイプがスルーされてしまうからです。
便利ではありますが、使い方に注意しないと、思わぬトラブルのもとになります。
わたしのような者の Blog を読んでくださるのは 99.9 % が男性だと思いますが、数少ない 0.1 %の女性に質問です。
上記の質問のうち、10番にマルが付いた方にお勧めの勉強会があります。
2011年7月9日開催 Azure女子部勉強会#1 : ATND
女子限定 30 名のみの Windows Azure Platform 勉強会です。当然、男子禁制です。
Windows Azure Platform について１から勉強することができる貴重な機会ですので、是非参加をご検討ください！
これを読んだ男性諸氏へ。近隣の同僚女性にご案内いただければ幸いです。
*** IT Pro のための Windows Azure 運用管理ガイド 1.0 公開中 *** IT Pro (IT 担当者) のための Windows Azure Platform 運用管理ガイド 1.0
Windows Azure の運用を考えるとき、Upgrade Domain（アップグレード ドメイン）という考え方があることは結構有名ですが、Fault Domain（フォールトドメイン）については意外と知られていません。
Windows Azure Platform のデータセンターには大量のマシンが設置されています。データセンターは、それはそれは広いスペースが用意されているわけですが、全てがペディスタルタイプで平置きしてあるはずもなく、1Uタイプのサーバーがラックに搭載されています。
IT Pro がハードウェアの構成を考えるとき、真っ先に気にかけるのが「単一障害点（Single of Failer）」が存在しないか....ということです。
当然、Windows Azure Platform をの設計者も同じことを考えました。それが Fault Domain です。
Fault Domain とは、「物理的な障害が及ぶ領域」のことです。「Domain」とは「領域」を意味しています。
詳細は明かされていませんが、Fault Domain の最小の単位は「ラック」であると言われています（必ずしもラックと1:1に対応しているわけではありません）。ラックには、Hyper-V のホストとなるノードが数十台積まれており、それらを束ねるスイッチや電源ユニットが設置されています。
Windows Azure 上にサービスを展開する場合、マイクロソフトは「複数のインスタンス」を用意してくださいとお願いしていますが、これらのインスタンスがどれか1つのラックに集中してしまうと、ラックの中の何らかの機構が破損することによってサービス全体が停止してしまうことになります。
そこで、Windows Azure Platform が誇る Fabric Controller（ファブリックコントローラー）は、インスタンスが最低 2 つの Fault Domain に分散されるように配置します。この「最低2つ」という表現についてはいろいろと疑問の余地があるかと思いますが、実を言えば詳細が公開されていません。いずれにしても、ハードウェア障害によってサービスが完全に停止することは回避されるような設計がなされている...ということです。
この、Fault Domain の考え方は、ノードのメンテナンスの際にも適用されます。つまり、Hyper-V ホストに障害修正やセキュリティパッチを適用しなければならない場合にも、この Fault Domain 単位に処理が行われるため、サービスの停止を回避することができます。
つづき 【Azure for IT Pro】インスタンスごとの Fault Domain を PowerShell で確認する
先の投稿で Fault Domain について書きました。
【Azure for IT Pro】Fault Domain を知っていますか？
その中で、「ロールは最低 2 つの Fault Domain に分散される」と書いたものの、正味なところいくつに分散されるのだろう...という疑問をお持ちかと思います。
そこで、試しに通常のサブスクリプションの上限である 20個のロールインスタンスを展開し、それぞれがどのように Fault Domain に分散されているかを確認してみることにします。
サービスを展開する際に、リモートデスクトップを有効にしておいてください。
展開したロールインスタンスのうち、どれか1つのリモートデスクトップサービスにログオンします。
（参考）【Azure for ITPro】Widnows Azure にリモートデスクトップで入り込むための手順 (1)
スタートメニューの [Run（ファイル名を指定して実行）] から PowerShell を起動し、以下のように「Microsoft.WindowsAzure.ServiceRuntime」を読み込んでください。
ためしに、Get-Command を使用して正しく読み込めたかどうかを確認しておきましょう。
PS C:\> Get-Command -PSSnapin Microsoft.WindowsAzure.ServiceRuntime
CommandType Name Definition ----------- ---- ---------- Cmdlet Get-ConfigurationSetting Get-ConfigurationSetting [-N... Cmdlet Get-LocalResource Get-LocalResource [-Name] <S... Cmdlet Get-RoleInstance Get-RoleInstance [-Role <Str... Cmdlet Set-RoleInstanceStatus Set-RoleInstanceStatus -Busy...
確認できたら、何も考えず Get-RoleInstance と入力してください。
PS D:\Users\junichia> Get-RoleInstance
Id Role UpdateDomain FaultDomain -- ---- ------------ ----------- WebRole1_IN_0 WebRole1 0 0 WebRole1_IN_1 WebRole1 1 1 WebRole1_IN_2 WebRole1 2 0 WebRole1_IN_3 WebRole1 3 1 WebRole1_IN_4 WebRole1 4 0 WebRole1_IN_5 WebRole1 0 1 WebRole1_IN_6 WebRole1 1 0 WebRole1_IN_7 WebRole1 2 1 WebRole1_IN_8 WebRole1 3 0 WebRole1_IN_9 WebRole1 4 1 WebRole1_IN_10 WebRole1 1 0 WebRole1_IN_11 WebRole1 2 1 WebRole1_IN_12 WebRole1 3 0 WebRole1_IN_13 WebRole1 4 1 WebRole1_IN_14 WebRole1 0 0 WebRole1_IN_15 WebRole1 1 1 WebRole1_IN_16 WebRole1 2 0 WebRole1_IN_17 WebRole1 3 1 WebRole1_IN_18 WebRole1 4 0 WebRole1_IN_19 WebRole1 0 1
Fault Domain の行を見てみると、それぞれのロールインスタンスに割り当てられた Fault Domain の番号が表示されていることがわかります。
これを見る限りでは、どうやら...2つの分散されているようです。
FaultDomain#0 が障害やメンテナンスで停止した場合でも、FaultDomain#1 によってサービスが維持されるということですね。
つづき 【Azure for IT Pro】インスタンスごとの Fault Domain を PowerShell で確認する その2
前回、前々回と以下の投稿をしました。
前回は Web Role だけ20個でしたが、今度はこんな構成にしてみました。
前回の投稿と同様、リモートデスクトップにログオンして、PowerShell の Get-RoleInstance コマンドレットで分散状況を表示してみます。
Id Role UpdateDomain FaultDomain -- ---- ------------ ----------- WebRole1_IN_0 WebRole1 0 0 WebRole1_IN_1 WebRole1 1 1 WebRole1_IN_2 WebRole1 2 0 WebRole1_IN_3 WebRole1 3 1 WebRole1_IN_4 WebRole1 4 0 WebRole1_IN_5 WebRole1 0 1 WebRole1_IN_6 WebRole1 1 0 WebRole1_IN_7 WebRole1 2 1 WebRole1_IN_8 WebRole1 3 0 WebRole1_IN_9 WebRole1 4 1 WorkerRole1_IN_0 WorkerRole1 0 0 WorkerRole1_IN_1 WorkerRole1 1 1 WorkerRole1_IN_2 WorkerRole1 2 0 WorkerRole1_IN_3 WorkerRole1 3 1 WorkerRole1_IN_4 WorkerRole1 4 0 WorkerRole1_IN_5 WorkerRole1 0 1 WorkerRole1_IN_6 WorkerRole1 1 0
ちょっとわかりずらいので、図にしてみると以下の通りです。
Webロールも、Worker ロールも、一方に偏ることなくきれいに分散していることがわかります。
仮に、Fault Domain #0 が死んだとしても、Fault Domain #1 でサービスを継続できることがわかります。
*** IT Pro のための Windows Azure 運用管理ガイド 1.0 公開 *** IT Pro (IT 担当者) のための Windows Azure Platform 運用管理ガイド 1.0
*** 6/15 Windows Azure Platform 最新情報 をお届けする 無償セミナー*** Windows Azure Platform 最新情報 2011 年 6 月版 & そろそろリアルな運用についても考えてみよう
***7/9 女子限定 クラウド勉強会*** Azure 女子部 勉強会 申込み
Windows Azure を使用したことがある方であればご存知の通り、Windows Azure には展開したホストサービスに自動的に修正プログラムを適用する機能が用意されています。
以下の画面は、Windows Azure の管理ポータルで、ホストサービスの「Configure OS」を開いたところです。OS Version が [Automaric] に設定されていることがわかります。
ただし、オンプレミスにおける Windows Update とは仕組みが全く異なる点に注意しなければなりません。
オンプレミスでは、修正プログラムは以下のように適用されます。当たり前ですよね。誰でも知ってます。
では、Windows Azure ではどのように修正プログラムが適用されるのか...。図にすると、以下のような感じです。
修正プログラムが適用される...というよりも、「修正プログラムが適用されたOSに置き換えられる」と言ったほうが正確でしょう。Windows Azure 管理ポータルで「Configure OS」の OS Version をプルダウンすると、以下のようにGuest OSに多くのバージョンが用意されていることがわかります。それぞれの違いは、修正パッチやインストールされているSDKのバージョンです。
上の図では、アプリケーション部分がそのまま「横滑り」するようなイメージで書かれていますが、実際にはこれまでの Guest VM が破棄され、新しい「OSイメージ」と「アプリケーションイメージ」が再展開されます。
以下をご覧ください。これは、Guest VM を構成している VHD です。Guest VM を構成する VHD は全部で3つあり、OS 本体はD:ドライブに、開発したアプリケーションは E: ドライブにマウントされています。C:ドライブには構成情報や診断ログ等が格納されています。
これら 3つの VHD にはいずれも差分VHDが設定されており、運用中に発生した変更は差分VHDに書き込まれます。
ここで、Guest VM の OS バージョンをアップグレード（またはダウングレード）したとしましょう。古いOSイメージ（VHD）は破棄され、新しい OSイメージがファブリックコントローラーから Guest VM の領域に複製されてきます。さらに、アプリケーションが格納されている E: ドライブも同時に破棄され、キャッシュされているアプリケーションイメージが再展開されます。つまり、D: ドライブと E: ドライブに書き込まれた情報は、この時点ですべて廃棄されます。ただし、C: ドライブは差分VHDも含め、そのまま維持されます。
こうした動作を抑えておくことは、IT Pro にとっても開発者にとっても、非常に重要です。
アプリケーションを展開した後、リモートデスクトップで入り込んで OS の設定を変更したとしても、OS がアップグレードされると変更点はきれいさっぱり無くなります。アプリケーションの Web.config ファイルも同様です。
こうした仕様に対処するため、「スタートアップタスク」と呼ばれる仕組みが用意されています。スタートアップタスクについては、IT Pro (IT 担当者) のための Windows Azure Platform 運用管理ガイド 1.0 をご覧ください（6月10日公開予定です！）。
前回の投稿で、Guest VM のアップデートが与える影響について触れ、記事の中で、「C:」ドライブだけは Guest VM のアップグレード時にも維持されると書きました。
【Azure for IT Pro】自動更新がホストサービスに与える影響について
C:ドライブは診断ログや構成ファイルなどが保存されている、非常に重要なドライブです。
では、C: ドライブはどんな時でも維持され続けるのでしょうか？
残念ながら、答えは NO です。
その理由は、Guest VM がのっている Host OS やサーバー自身が死んでしまうことがあるからです。
その場合は、Fabric Controller が新たなサーバーを用意し、そこに今までと同じバージョンの Guest VM を展開し、さらにアリケーションも展開してくれます。よって、サービスは継続されます。
ただし、これまでローカルストレージに蓄積してきたデータはすべてなくなります。そうならないように、大切なデータは永続的なストレージ、すなわち、Winodws Azure ストレージまたは SQL Azure に保存しておかなければなりません。
Windows Azure ストレージ および SQL Azure は、自動的に複製が3つ作成されているため、いずれかが破損してしまっても残りの2つに複製が残されています。ロードバランサーは3つの複製それぞれへの経路を自動的に設定してくれるので、利用者がストレージの生死を意識する必要はありません。もちろん、複製のうちのいずれかが破損してしまった場合にも、ロードバランサーは自動的に経路を設定しなおしてくれます。
IT Pro が Windows Azure をインフラの一部として設計する場合に肝に銘じなければならないのは、以下の 3 点です。
以下の表は、各種シチュエーションにおけるローカルストレージの状態を一覧にしたものです。
前回の投稿からかなり時間が経ってしまいました。
【Azure for IT Pro】Windows Azure Service Management（WASM） コマンドレット 使い始め
WASMにはさまざまなコマンドレットが用意されているのですが、今回は診断モニタに関するコマンドレットをご紹介します。
Windows Azure のログは、診断モニタと呼ばれる機構により収集されて、ローカルのストレージを介してから Windows Azure ストレージに転送されるようになっています。
事前に、Visual Studio で以下の設定を行っておけば、細かな設定は後から PowrShell コマンドレットを使用して変更することができます。設定にあたっては、Windows Azure ストレージのアカウントとアクセスキーが必要なので、事前に準備しておきましょう。
診断モニタを使用して収集可能な診断ログは以下の5種類です。
ログのタイプ
備考
まず手始めに、指定したロールに設定されている診断ログの情報をかたっぱしから取得してみましょう。
まずは、以下のスクリプトを拡張子 .PS1 で保存してください。その際、赤で示した部分はご自身の環境の値を設定してください。
## Windows Azure Management Tools を読み込む Add-PSSnapin AzureManagementToolsSnapIn
## Windows Azure の サブスクリプションID、サービス名、Deployment ID、ロール名 $SubscriptionID="caf29b8c-26de-431d-xxxx-xxxxxxxxxxxx" $serviceName = "tfazureforitpro" $deployid = "d8316264497849f4xxxxxxxxxxxxxxx" $Role = "WebRole1"
## 格納先となるWindows Azure ストレージのアカウント名とキー $storage = "xxxxxxxxxxxxxxx" $key = "vHcvyMEyG63MzfWpxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxt8NMoPk4wp7kZJ4pWw=="
## 診断モニタが有効なロールインスタンスを取得して、それぞれの診断ログの設定値を取得する $RoleInstances = Get-DiagnosticAwareRoleInstances $Role -DeploymentId $deployid -StorageAccountName $storage -StorageAccountKey $key
$RoleInstances | foreach {
$InstanceID = $_
Write-Host "**************" $InstanceID "**************"
write-host "--- DiagnosticInfrastructureLogs ---" $Config = Get-DiagnosticConfiguration -RoleName $Role -InstanceId $InstanceID -StorageAccountName $storage -StorageAccountKey $key -BufferName DiagnosticInfrastructureLogs -DeploymentId $deployId $Config | FL
write-host "--- Directories ---" $Config = Get-DiagnosticConfiguration -RoleName $Role -InstanceId $InstanceID -StorageAccountName $storage -StorageAccountKey $key -BufferName Directories -DeploymentId $deployId $Config |FL $config.DataSources |FL
write-host "--- Logs ---" $Config = Get-DiagnosticConfiguration -RoleName $Role -InstanceId $InstanceID -StorageAccountName $storage -StorageAccountKey $key -BufferName Logs -DeploymentId $deployId $Config | FL
write-host "--- PerformanceCounters ---" $Config = Get-DiagnosticConfiguration -RoleName $Role -InstanceId $InstanceID -StorageAccountName $storage -StorageAccountKey $key -BufferName PerformanceCounters -DeploymentId $deployId $Config |FL $Config.DataSources | FL
write-host "--- WindowsEventLogs ---" $Config = Get-DiagnosticConfiguration -RoleName $Role -InstanceId $InstanceID -StorageAccountName $storage -StorageAccountKey $key -BufferName WindowsEventLogs -DeploymentId $deployId $Config | FL $config.DataSources |FL }
PowerShell のコンソールを開いてスクリプトを実行すると、$Role に指定したロールに含まれるすべてのロールインスタンスから設定情報を取得して画面に表示します（表示データを全く整形していないので見ずらいと思いますが）。
使用しているコマンドレットは2種類です。
Get-DiagnosticAwareRoleInstances は指定したロール（$Role）に含まれている診断モニターが正常に動作しているロールイスタンスの一覧を返します。
返されたロールインスタンスの一覧を Foreach を使用して１つづつ取り出し、Get-DiagnosticConfiguration で各診断ログの設定情報を収集しています。ログの設定を行う場合には、ログのタイプごとにコマンドレットが用意されているのですが、情報を収集する場合にはこのコマンドレットに引数として –BufferName <ログのタイプ> を指定します。
Get-DiagnosticConfiguration からの戻り値は $Config という変数に格納していますが、PerformanceCounters や Directories のように複数の値（パフォーマンスカウンターやログが格納されているディレクトリ）を持つ者は DataSources プロパティを使用すると詳細な中身を確認することができます。DataSources プロパティは、設定を行う際にも使用するので覚えておいてください。
出力結果例を以下に示します。
************** WebRole1_IN_0 ************** --- DiagnosticInfrastructureLogs ---
ScheduledTransferLogLevelFilter : Verbose ScheduledTransferPeriod : 00:10:00 BufferQuotaInMB : 1024
--- Directories ---
DataSources : {Microsoft.WindowsAzure.Diagnostics.DirectoryConfiguration, Microsoft.WindowsAzure.Diagnostics.DirectoryConfiguration, Microsoft.WindowsAzure.Diagnostics.DirectoryConfiguration} ScheduledTransferPeriod : 00:10:00 BufferQuotaInMB : 1024
Path : C:\Resources\directory\d8316264497849f4891e25fc3943ca09.WebRole1.DiagnosticStore\FailedReqLogFiles\Web Container : wad-iis-failed-logfiles DirectoryQuotaInMB : 1024
Path : C:\Resources\directory\d8316264497849f4891e25fc3943ca09.WebRole1.DiagnosticStore\LogFiles\Web Container : wad-iis-logfiles DirectoryQuotaInMB : 1024
Path : C:\test Container : tflogs DirectoryQuotaInMB : 1024
--- Logs ---
ScheduledTransferLogLevelFilter : Undefined ScheduledTransferPeriod : 00:10:00 BufferQuotaInMB : 1024
--- PerformanceCounters ---
DataSources : {Microsoft.WindowsAzure.Diagnostics.PerformanceCounterConfiguration, Microsoft.WindowsAzure.Diagnostics.PerformanceCounterConfiguration, Microsoft.WindowsAzure.Diagnostics.PerformanceCounterConfiguration} ScheduledTransferPeriod : 00:10:00 BufferQuotaInMB : 1024
SampleRate : 00:01:00 CounterSpecifier : \Processor(_Total)\% Processor Time
SampleRate : 00:01:00 CounterSpecifier : \Memory\Available Mbytes
SampleRate : 00:01:00 CounterSpecifier : \ASP.NET Applications(__Total__)\Requests/Sec
--- WindowsEventLogs ---
DataSources : {System!*, Application!*, Security!*} ScheduledTransferLogLevelFilter : Verbose ScheduledTransferPeriod : 00:10:00 BufferQuotaInMB : 1024
System!* Application!* Security!*
つづきは以下で IT Pro (IT 担当者) のための Windows Azure Platform 運用管理ガイド 1.0 PowerShell による管理の自動化
2011/6/16 修正 Auth 2.0 用の Extension が公開されていることを失念していました
WIF（Winodws Identity Foundation）がビールの次に大好きだ！という WIF マニアの皆さま。お待たせしました。
待ちに待ったコンポーネントがリリースされました。
WIF(Windows Identity Foundation） Extension for SAML 2.0 Protocol です。
ダウンロードの詳細 | Microsoft Connect
Protocol ですよ！ Token Format ではありません。
これまでも、Token Format は SAML 2.0 をサポートしていました。が、それを乗せるプロトコルは、WS-*だったんですねぇ。
しかし、今日からは違います。
少なくとも、「WIF は SAML 2.0 に対応する気があるようだ！」と言えるのです。
WIF フリークの皆さまには、これまで本当につらい思いをさせてしまいました。
ちなみに、AD FS 2.0 は SAML 2.0 プロトコルに対応しています。
なので、今後は MS コンポーネントだけで SAML 2.0 を使用したアプリケーションが構築できます。
参考までに、2011年6月時点の MS 製品の各種プロトコルへの対応状況を以下にまとめておきます。
プロトコル
残るは ACS ですねぇ。
参考サイト Announcing the WIF Extension for SAML 2.0 Protocol Community Technology Preview! - Claims-Based Identity Blog - Site Home - MSDN Blogs