System Center Operations Manager 2007 R2 CU4へのアップデート

OpsMgr 2007 R2 CU4 Ships!
http://blogs.msdn.com/b/scxplat/archive/2011/02/01/opsmgr-2007-r2-cu4-ships.aspx
で見つけたので、時間に余裕があった時にアップデートしてみました。

手順は、以下のページに載っています（なぜ英語かと言われれば、機械翻訳の日本語があまりにあれだったので）。
System Center Operations Manager 2007 R2 Cumulative Update
http://support.microsoft.com/kb/2449679/en-us

まずは、
Installation steps
から。

SystemCenterOperationsManager2007-R2CU4-KB2449679-X86-X64-IA64-JPN.msi

をダウンロードし、実行してみた。
こんな順番で、まずCU4のアップデートパッケージをインストールします。






仮想マシンだからなのか、セットアップランチャーが起動してくるまで1時間ぐらいかかる(>_<)

セットアップランチャーから、

"Run Server Update"をクリックして実行する。



CU3の時のようなトラブルもなく、CU4へのアップデート自体が成功した。
が、（CU3に続いて）なぜかアップデートがとまらなくなる。
しょうがないので、もともとのセットアップランチャーを停止してみた。
��セットアップランチャーの画像は以下の通り）


結果、ようやくアップデートが止まった。
しかし、CU3と同じ様なトラブルに見舞われるのはどうしたものだろうか。。。

さて次は、
Manual operations that must be performed after you update the Root Management Server and Data Warehouse
を実施する。

SQLUpdateフォルダは、どこかと言うと、

このインストールフォルダの配下の"KB2449679"配下のフォルダ

にCU4_Database.sqlとCU4_DataWarehouse.sqlがあります。
CU4_Database.sqlはOperationsManagerデータベース、CU4_DataWarehouse.sqlはOperationsManagerDWデータベースをそれぞれ選択して、SQLスクリプトを実行します。


次は
Import the management packs
を実施する。
今回の環境だと
C:\Program Files (x86)\System Center 2007 R2 Hotfix Utility\KB2449679\ManagementPacks
に更新用の管理パックがあるので、これをインポートします。



次は、
Install Linux/UNIX management packs and update Linux/UNIX agents
を実施する。
インストール済みの Linux/UNIX management packsよりも微妙にバージョンが新しいことを確認したので、
SCOMCrossPlatformCU3MP.msi
をダウンロードした。


このマネジメントパックのをインストールします。






インストールがおわったら、管理コンソールからインポートします。



無事終了したので、管理コンソールからエージェントの更新を行います。
検出ウィザードで確認したところ、最新のものが入っているという。
Linuxマシンにログインして、
rpm -qa |grep scx
したところ、
scx-1.0.4-265
になっていた。
C:\Program Files\System Center Operations Manager 2007\AgentManagement\UnixAgents
にLinux/UNIXのエージェントが入っているので確認したところ、確かに最新は、scx-1.0.4-265で間違いなし。


後は、Windowsのエージェントをアップデートしていくことになります。
管理→デバイスの管理→保留の管理
にエージェントの更新対象がリストアップしているので、そこからやるのが早道です。

以上。

iOS 4.3.3で曲順やアーティスト順の並びが直った

iOS 4.3.2直後は、こんな感じで、もうどういう順でソートされているんじゃいと思わず突っ込みたくなる状態でした。
アーティスト順だと、一見正しいようにも見えますが、か行でB'zは、ないよねぇ。

曲順もまた同様なり。


今日、4.3.3にバージョンアップしてみた。
アーティスト順は、ちゃんと直りました。アーティスト名に読み仮名を入れていないので、こんなもんでしょう。

曲順も正しく並ぶようになりました。


Appleの迅速な対応に感謝。でもこのバグはリリース版にしてはちょっとありえない気がしますねぇ。

ADFSのLDAP属性

ADFSというか、Active DirectoryのLDAP属性は、ここに一覧があります。
http://msdn.microsoft.com/en-us/library/ms675090(v=VS.85).aspx

ADSIエディターなどで表示される属性は、LDAP表示名（Ldap-Display-Name）と呼ばれるもののようですね。
E-Mail-Addressだとこういう感じの内容で書かれています。

IdPとSPを連携させてクレーム対応アプリケーションを試してみた

IdP側のSTSで認証して属性ストアからメールアドレスをセキュリティトークンとしてもらい、SP側のSTSでそのメールアドレスに対応する役職をセキュリティトークンに追加する動作を試してみました。

アプリケーションにアクセスしてからの一連の動作は、以下の図のようになります。


そして、それぞれどのような信頼関係や属性ストアがあるかは、以下の図の通りです。

注）IdP側STSからActive Directoryに対する"要求プロバイダー信頼"、"属性ストア"は、AD FS 2.0の構成時に合わせて作られています。

今回は、以下のものを設定しています。
(1)IdP側STSから、SP側STSに対する"証明書利用者信頼"
(2)SP側STSから、役割(役職)ストアに対する"属性ストア"
　これは、SQL Server 2008 R2 Express上に作ったデータベースです。
　DBMSに対する属性ストアの接続については、日本マイクロソフトの安納さんのブログ記事を参考にしています。
　【IDM】AD FS 2.0 で属性ストアとしてSQL Server を使用する
　ただ、SQL Server 2008 R2 Expressの場合は、
　　server=ホスト名\sqlexpress
　としてやる必要がありますね。
　参考：　SQL Server Express ユーザー インスタンスへの接続 (ADO.NET)
(3)SP側STSで認証しないように、Web.configを以下のように変更します。
　localAuthenticationTypesタグの要素をコメントアウトすると、このADFSで認証しない様になります。

<localAuthenticationTypes>
<!-- add name="Integrated" page="auth/integrated/" />
<add name="Forms" page="FormsSignIn.aspx" />
<add name="TlsClient" page="auth/sslclient/" />
<add name="Basic" page="auth/basic/" / -->
</localAuthenticationTypes>

(4)SP側STSから、IdP側STSに対する"要求プロバイダー信頼"
(5)SP側STSから、クレーム対応アプリケーションに対する"証明書利用者信頼"

では、(1)、(4)、(5)の要求規則セットと要求規則についても書いておきます。
(1)は、"発行承認規則"に以下の要求規則を定義しました。

メールアドレス属性を名前というクレームに入れて発行してます。

(4)は、"受け付け変換規則"に以下の要求規則を定義しました。

名前というクレームをパススルーしてます。

(5)は、"発行承認規則"に二つの規則を定義しました。
　一つ目は、名前というクレームを発行してます。

名前というクレームをパススルーしてます。

二つ目は、カスタム規則で、名前（メールアドレス）に応じた役職（役割）をSP側STSに設定した属性ストアから取り出して発行します。

ここは、SQL文をカスタム規則に書いて、クレームとして発行しています。

ということで、参考になれば幸いです。

参考）
【セミナー資料】AD FS 2.0 を使用して Windows Azure との SSO を実現しよう V1.1
【IDM】AD FS 2.0 カスタムルール（カスタム規則）の作り方 1/2
【IDM】AD FS 2.0 カスタムルール（カスタム規則）の作り方 2/2
BoF-09 Silverlight and WIF /TechEd Japan 2010
IdM実験室

ログオンしているユーザー情報から、そのユーザーが格納されているOUまで移動するPowerShellコード

ログオンしているユーザー情報から、そのユーザーが格納されているOUまで移動するPowerShellコードを書いてみたので、晒しておきます。
制御の委任が行われていれば、cd $DNPATH 以降で、新規にユーザーを作成するなどの処理が実行できます。
実行にあたっては、PowerShellのActive Directoryモジュールが必要です。
・Windows Server 2008 R2は、"機能の追加"で追加しましょう。
・Windows 7は、RSATのダウンロードとインストールが必要です。
ただこのコード、あまり深く考えていないところがあるので、複数のグループで制御の委任を受けているユーザーはどうするのかとか、administratorだとこれまずいのじゃという点、多々留意点があります。

Windows Server 2008 R2の信頼関係ウィザード

マイナーネタ第二弾
Windows Server 2008 R2の信頼関係ウィザードです。
まあ、もしかしたらWindows Server 2008も同じウィザードが使えるかもしれませんけど、確認していません。

一番のトピックは、片方のドメインから、両方のドメインに対する信頼関係の設定ができること。
��もちろん、両方のドメインの管理者パスワードを教えたくない等、セキュリティ的な懸念事項がある場合は、従来通り別々に設定できます）

信頼される側（ユーザーアカウントなどを使いたい）ドメインは、"exsshzk.local"とします。
信頼する側（リソースにアクセスさせたい）ドメインは、"exsshzk2.local"とします。

信頼関係の設定では、双方のドメインを名前解決できる必要があります。今となっては、DNSが一番良いですが、HOSTSファイルでも良いかと（もしかしてまだLMHOSTSでも良い？！）。
新機能が使えるので、信頼される側のドメインで、信頼関係の設定をまとめて行うことにします。
信頼関係の設定は、従来通り、ドメインの信頼関係（名前が正しくないかも、違っていたら後日修正します）で行います。

ドメインの信頼関係]でプロパティを表示させると以下のような画面が表示されます。
ここで、[信頼]タブにある[新しい信頼]ボタンを押してやります。


[新しい信頼ウィザード]が起動します。


信頼する側のドメイン名を入力します。


ここでは、自動的に信頼関係を推移させることはしないので、[外部の信頼]をチェックしています。
自動的に信頼関係を推移させたい場合は[フォレストの信頼]をチェックすれば良いです。


信頼関係の方向を指定します。
ここでは、信頼される側のユーザーアカウントから、信頼する側のリソースへのアクセスを許可するだけにしたいので、[一方向:入力方向]を指定します。


信頼の対象ですが、ここが新機能なんですよね？！
今回は信頼される側からすべての設定を行いたいので、[このドメインと指定されたドメインの両方]を選択します。


[このドメインと指定されたドメインの両方]を選択したので、指定されたドメイン=信頼される側 のドメイン管理者名とそのパスワードを入力します。


今回は、テスト環境で両方とも私が管理していますので、[ドメイン全体の認証]を選択しました。
組織が違う場合は、[認証の選択]を選択すれば良いです。


設定内容の確認画面です。


信頼関係について、設定完了した旨のメッセージが出ています。


これは、入力方向の信頼関係ができているかをきちんと確認するためのものです。
今回は省きました（本来はやったほうが良いです）。


ここで、[新しい信頼ウィザード]が完了します。


このようなダイアログが表示されます。
内容を読んで[OK]ボタンを押します。


信頼される側のドメインでは、以下のように設定されています。


信頼する側のドメインでは、以下のように設定されています。


ということで、信頼関係の確立も少し手間が減ったといえますね。