【Management】Windows Update Powershell Module (1)

久しぶりに Windows Update をスクリプトから実行しようかなぁと思って PowerShell のコマンドレットを探していたら、標準では提供されていないんですねぇ。全く気づいておりませんでした。 となると、VBScript のように Microsoft.Update.Session を呼び出すしかないものかと思っていると、なんと便利なモジュールが提供されていました。 Windows Update PowerShell Module http://gallery.technet.microsoft.com/scriptcenter/2d191bcd-3308-4edd-9de2-88dff796b0bc さっそく使ってみましょう。 まずはダウンロードして ZIP ファイルを開いてみてください。PSWindowsUpdate フォルダが格納されているはずです。この中にこのモジュールを構成するスクリプト群が格納されています。 これらのファイルは「インターネットゾーンからダウンロードしたファイル」なので、必ず「ブロックの解除」を実行しておきましょう。でないと実行できません。 【PowerShell】一括で「ブロックを解除」する ~ Windows PowerShell 編 その1 http://blogs.technet.com/b/junichia/archive/2012/01/13/3475162.aspx 【PowerShell】「ブロックを解除」するためのメソッドを追加してみる http://blogs.technet.com/b/junichia/archive/2012/01/15/3475439.aspx 【Management】一括で「ブロックを解除」する streams コマンド編 http://blogs.technet.com/b/junichia/archive/2012/01/12/3475091.aspx ブロック解除が完了したら、PSWindowsUpdate フォルダを、PowerShell のモジュール用フォルダに保存します。 モジュール用フォルダの場所を確認するには、以下のように PowerShell コンソールから環境変数 PSModulePath を確認します。 PS C:\windows\system32> $env:PSModulePath C:\Users\junichia\Documents\WindowsPowerShell\Modules;C:\windows\system32\WindowsPowerSh ell\v1.0\Modules\;C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\ (参考)Windows PowerShell: Windows PowerShell…


【問題】この人はだれでしょう?

ちょっと面倒な連載が続いたので、今回は遊びます。 「マイクロソフトが大好きで、自ら MS 人事マニアであると自負されている方」向けに問題です。 この方は誰でしょう? わかりました? ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ 答えは、Steve Guggenheimer(スティーブ グッゲンハイマー)です。 え?それは誰かって?群馬県とは関係ありません。 私が所属している部門が「日本マイクロソフト株式会社 デベロッパー&プラットフォーム エバンジェリズム」なのですが、その親玉である Microsoft Corporation Developer & Platform Evangelism の親分です。我々から見れば、とーっても偉い人なわけです。はい。 でもって、我々エバンジェリストの最上級をあらわす、Chief Evangelist でもあります。 世界中のさまざまなカンファレンスのキーノートに登壇しているので、ご覧になったことがある方も多いかもしれませんし、6月の BUILD に参加される方は、そこでお目にかかることになるでしょう。 そんな彼が日本にやってきて、登壇する日があります。 それも、BUILD はかなり高価なカンファレンスですが、これは無償です。 Chief Evangelist…

1

【IAM】DAC その5 ~ Dynamic Access Control のアーキテクチャ(3) - PAC と Kerberos Pre-authentication(RFC 6113)による拡張

なんだかどんどん深みにはまりつつある ダイナミックアクセス制御の解説シリーズです。。。でもお好きな方にはたまらないですよね(と信じつつ)。 2013 年 7 月以降には、DAC Deep Dive 1日コースのセミナーを開催しようかと考えております。東京以外でも開催したいのので、ぜひご要望をお寄せくださいませ。 さて、前回までの投稿は以下の通りです。 【IAM】ダイナミックアクセス制御(DAC)を理解するための解説&演習手順書 http://blogs.technet.com/b/junichia/archive/2012/12/17/3541225.aspx 【IAM】DAC その 1 ~ グループベース RBAC の破たん? http://blogs.technet.com/b/junichia/archive/2013/03/29/3561744.aspx 【IAM】DAC その 2 ~ なぜ企業のアクセス管理に DAC が必要なのか http://blogs.technet.com/b/junichia/archive/2013/04/01/3562095.aspx 【IAM】DAC その 3 ~ Dynamic Access Control のアーキテクチャ(1) http://blogs.technet.com/b/junichia/archive/2013/05/07/3571125.aspx 【IAM】DAC その 4 ~ Dynamic Access Control のアーキテクチャ(2) ー FSRM が必要な理由 http://blogs.technet.com/b/junichia/archive/2013/05/10/3571884.aspx 前回は「なぜダイナミック アクセス 制御」に「FSRM(File Server Resource Manager」が必要なのか?について解説しました。その中で、DAC…


【IAM】DAC その4 ~ Dynamic Access Control のアーキテクチャ(2) ー FSRM が必要な理由

Windows Server 2012 から利用可能になった ダイナミックアクセス制御 に関して、細々と掲載を続けるシリーズです。前回までの投稿は以下の通りです。 【IAM】ダイナミックアクセス制御(DAC)を理解するための解説&演習手順書 http://blogs.technet.com/b/junichia/archive/2012/12/17/3541225.aspx 【IAM】DAC その1 ~ グループベース RBAC の破たん? http://blogs.technet.com/b/junichia/archive/2013/03/29/3561744.aspx 【IAM】DAC その2 ~ なぜ企業のアクセス管理に DAC が必要なのか http://blogs.technet.com/b/junichia/archive/2013/04/01/3562095.aspx 【IAM】DAC その3~Dynamic Access Control のアーキテクチャ(1) http://blogs.technet.com/b/junichia/archive/2013/05/07/3571125.aspx 今回は、DAC を利用するのにファイルサーバー側に FSRM(ファイルサーバー リソースマネージャー)が必要な理由について解説しておきたいと思います。 FSRM(ファイルサーバー リソースマネージャー)は既にご存知かと思いますが、念のために紹介しておきます。詳細は以下を参照ください。 ファイル サーバー リソース マネージャーの概要 http://technet.microsoft.com/ja-jp/library/hh831701.aspx FSRM はもともと Windows Server 2003 R2 で初めて実装されました。それが 2008 → 2008 R2 →2012 と進化し続け、今に至っています。 FSRM はひとことで言えばストレージをより高度かつ合理的に管理するための機能セットです。Windows Server…


【IAM】DAC その3~Dynamic Access Control のアーキテクチャ(1)

以前の投稿につづき、今回は Windows Servevr 2012 が提供する DAC のアーキテクチャについて解説します。この辺をご理解いただくと、多くのエンジニアの方に「おぉ、やってみたい」と思っていただけるかと。   【IAM】ダイナミックアクセス制御(DAC)を理解するための解説&演習手順書 http://blogs.technet.com/b/junichia/archive/2012/12/17/3541225.aspx 【IAM】 DAC その1 ~ グループベース RBAC の破たん? http://blogs.technet.com/b/junichia/archive/2013/03/29/3561744.aspx 【IAM】 DAC その 2 ~ なぜ企業のアクセス管理に DAC が必要なのか http://blogs.technet.com/b/junichia/archive/2013/04/01/3562095.aspx まずは以前の投稿でも使用した以下の図をご覧ください。DAC では「リソース側の属性」と「ID 側の属性」のマッチングを行い、条件が合致したときにアクセス権が適用されます。 ちょっと運用イメージが想像しずらいでしょうか? 現実の世界にもこのような仕組みは存在しています。例えば"ある種の結婚相談所"を思い浮かべてみてください。 あくまでも私の想像ですが、結婚相談所の場合、女性は出会いたい男性の属性を事前に定義しておく必要があるのでしょう(たぶん)。結構相談所側は、女性の要求と、条件に合致した男性から女性へのコンタクト権限(アクセスルール)を定義しておきます。もちろん、このときアクセスルールにはある程度女性側のニーズを反映させる必要があるので、複数のルールを作成しておく必要があるかもしれません。男性はどういった女性が登録されているかは把握可能ではあるものの、アクセスルールに合致しなければインスタントメッセージさえも送ることは不可能です。 このモデルでは、結婚相談所が両者のニーズの中間地点でアクセス管理を行っています。もし結婚相談所によるアクセス管理が無かったとしたら、一切のアクセス制御は女性自身が行う必要があります。これはとても面倒です。 えっと何の話でしたっけ?あ、DACですね。DAC に話を戻しましょう。 DAC によるアクセス管理の全体像をざくっと図にすると以下の通りです。 ここで3人の主要な登場人物について理解しておきましょう。 ソース アクセスポリシー リソース ソースとは、リソースにアクセスする主体を指します。つまり、ユーザーやデバイスのことです。ソースは Active Directory ドメインに定義されたオブジェクトであり、ldap 属性を持っています。 リソースとはファイルサーバー上の”フォルダ”や”ファイル”のことです。リソースには「分類属性」と呼ばれる特別な属性を定義することができ、これを使用してアクセス可能なソースを制限することができます。 アクセスポリシーとは、その名の通りアクセスを制御するためのポリシーです。正式日本語名称「集約型アクセスポリシー(Central Access Policy)」と呼ばれ、その名称から”集中管理された”アクセスポリシーであることがわかります。「集中管理」が何を意味するかといえば、もちろん「Active Directory ドメイン による集中管理」のことです。 上の図を、さらに詳しく書いたのが以下の図です。…