MSFCのハートビートはUDP

コメントを残す

相変わらず、MSFCの仕込みをコツコツと行っています。

さて、そこでこんな文章を見つけました。

フェールオーバー クラスタリング
http://technet.microsoft.com/ja-jp/library/cc725923(WS.10).aspx

***** 以下抜粋 *****

ネットワークのその他の機能強化により信頼性の向上を実現する。
ネットワーク機能の強化により、ネットワーク名と関連 IP アドレスの間の依存関係を細かく調整でき、片方の IP アドレス (両方ではなく) だけで、ネットワーク名が使用できるようになります。
また、各ノードが使用可能であることを確認するために “ハートビート” を送受信するときに、信頼性の低いユーザー ダイアグラム プロトコル (UDP) ではなく、伝送制御プロトコル (TCP) を使用します。

***** ここまで *****

え～、Windows Server 2008 からハートビートはTCPに変わったのか？しかし、ネットワークキャプチャをしてみるとハートビートの通信では、UDP のユニキャスト (ポート : 3343) を用いていることが確認できました。

もしかして、TCPにするモードがあって知らないだけ？

しょうがないのでテクニカルサポートに連絡して、調べてもらいました。以下は結果になります。

***** 以下抜粋 *****

[回答]

お問い合わせ頂きました内容について回答致します。
弊社資料および、実機での確認結果を報告致します。
クラスタにノードが参加する際に (Join Process) TCP を使用し、参加後のハートビートの通信では、UDP のユニキャスト (ポート : 3343) を用います。
Technet サイトにつきましては、”Windows Server 2008 Failover Clustering Architecture Overview” に記載されている通り、ハートビートは、UDP (3343) を使用し、クラスタの参加時に TCP を使用することになります。
お寄せ頂いております上記公開情報については、誤解を招く記事となっておりますことを深くお詫び申し上げます。
記事につきましては、担当部署にフィードバックさせて頂きます。

***** ここまで *****

ということで、今まで通りハートビートはUDPを使用することになります。更に、ネットワークにおいて以前はプライベート、パブリック、混合というネットワークが存在していましたが、MSFCでは用語が変わりました。プライベートはノード間の通信に使用し、パブリックはMSCS（Windows Server 2003）でいうところの混合になりますので、クライアントとクラスタ間通信及びノード間通信を行います。

このことから、ハートビートを特定のネットワークでのみ使用したいという設定はできません。利用可能なあらゆるネットワークを使用してハートビートを送りつける仕様になっています。

7月16日修正

そして、今までのクラスタにおける「パブリック(クライアントアクセスのみ)」の設定、つまり、クライアントとのやり取りだけに使用したいという設定はできなくなりました。逆にいうとノード間通信には使用させたくないになります。また、ハートビートに使用されるネットワークに関しては、これは今までと同じで、クラスタで利用可能なすべてのネットワークが使用されます。

私の理解が間違っていました。ハートビートはもとよりクラスタで利用可能なすべてのネットワークが使用されていたんですね。

久しぶりに書籍の紹介

コメントを残す

Windows Server 2008 R2テクノロジ入門 (マイクロソフト公式解説書)

この書籍はいいですね。電車の中で読んでます。たまに知らないことが書いてあるのでためになります。

Microsoftのクラウドコンピューティング Windows Azure入門

クラウドとは何ぞや？そしてAzureとは何ぞや？ということから知りたい場合はいいかも・・・あとプログラミングについての記述がありますが私には何のことやら理解できませんでした（笑）とにかく、クラウドについての初めの一歩としてはいいですね

PowerShellによるWindowsサーバ管理術

PowerShellを使用した管理方法が紹介されています。知らなくちゃいけないと思い購入したのですが・・・PowerShellを使う機会が少ないんですよね（笑）ただ、この本の著者は5人いるのですが、3人は面識があるので熟読しなくては

ひと目でわかるMicrosoft Windows Server 2008ターミナルサービス (マイクロソフト公式解説書)

ターミナルサービスにおいてまんべんなく知識を習得できる書籍になります。試験番号：70-659（TS: Windows Server 2008 R2, Server Virtualization）対策に熟読しました。

Mastering Virtual Machine Manager 2008 R2

久しぶりに洋書を購入しました。というか、SCVMM R2に関する書籍はこれしかないのでしょうがなく・・・英語は読めないのですが雰囲気でなんとなく理解しようとしています。

MSFCの優先所有者と実行可能な所有者の関係

コメントを残す

WS000000

クラスタグループにおいて優先する所有者という設定があります。これは主に、フェールオーバー順やフェールバックの戻り先を設定するために使用します。ただし、優先所有者として指定されなかったノードにフェールオーバーしないわけではないことに注意が必要です。

仮に8ノードのクラスタがあったとします。そのうち、NodeA→NodeB→NodeCの順に優先所有者の設定を行います。順にNodeAがダウンするとNodeBへフェールオーバー、NodeBがダウンするとNodeCへフェールオーバー、NodeCがダウンするとランダムなノードへフェールオーバーということになります。

WS000003

実行可能な所有者という設定があります。リソースの詳細なポリシーに存在するものです。これはどのような時に使用するのか？

優先所有者

仮に4ノードクラスタが存在しています。この時NodeDが待機系だとします。いわゆるActive / Active / Active / Passive (AAAP)の構成です。この時はまず優先所有者でNodeAに対してはNodeAとNodeDにチェックを入れます。こうすれば待機系のマシンにフェールオーバーしてくれますね。しかし、この設定だけだと仮にNodeDがダウンすると他のノードにフェールオーバーしてしまいます。そこで「実行可能な所有者」の設定が生きてきます。この「実行可能な所有者」はまさにそのノードでしか実行を許しません。よって確実に待機系ノードでのみ実行させる場合には優先所有者の設定と同時に、実行可能な所有者の設定も行います。

しかし、この設定もNodeDが障害を起こすと困ります。そこで、待機系ノードを複数台用意します。そうすれば、懸念材料が少なくなります。が、ここでまたまた問題が・・・待機系ノードにフェールオーバー後に、他のノードも同じ待機系ノードにフェールオーバーしてくる可能性がありますね。

こんなときは「AntiAffinityClassNames」を使用します。

参考：ホット スペア サポートのための Windows クラスタ グループ構成方法

cluster group “<グループ名>” /prop AntiAffinityClassNames=”<一意の識別名>”

この設定はグループに対して行うもので、AntiAffinityClassNamesに同じ名前がある場合には、それを除く優先所有者の設定が使用されます。ですので仮に、NodeDとNodeEが待機系ノードで、NodeDにグループAがフェールオーバーしてきます。その後グループBがフェールオーバーして来たとします。

グループBの設定は優先所有者がNodeB、NodeD、NodeEの順番で、なおかつ実行可能な所有者も同様です。この場合、まずNodeDに対してフェールオーバーしようとしますが、グループAとグループBに対してAntiAffinityClassNamesに同じ名前を設定してある場合は、NodeDを除外した優先所有者が使用されます（NodeDにグループAがいるため）

よって、優先所有者のNodeEが使用されることになります。

AntiAffinityClassNamesの動作は、絶対ではありません。なぜなら、もし同じ名前しかなかった場合はその中でフェールオーバーします。ですので、この設定は優先所有者の拡張版と捉えることができますね。

あくまでも強制力を持たせるのは、実行可能な所有者の設定になります。

Windows Server 2008 と Vista におけるNAP検証

コメントを残す

演習環境として、Windows Server 2008 と Vista SP1 があり、NAPの検証を同僚が行いましたのでその結果をUPしておきます。

NAP正常性ポリシーの制御の検証

NAP正常性ポリシーの設定が不適切だった場合、準拠でも非準拠でもないクライアントが存在する。そのような場合、どういった制御になるのかDHCP NAPで検証した。

■テスト１
SHV・・・F/Wが有効であること
正常性ポリシー
・Compliant・・・すべてにパス
・NonCompliant・・１つ以上にパス
※これは、すべて失敗のクライアントは準拠でも非準拠でもなくなる設定。
ネットワークポリシー
Compliant-FULLが一番上、次がNonCompliant-Restrictedの順。

⇒クライアント側で
F/W有効
→制限なしのIPアドレスもらえる
F/W無効
→IPアドレスもらえない。APIPAのアドレスになる。
（すべて失敗のクライアントなので、準拠でも非準拠でもなくなるため、
IPアドレスがもらえない。予想どおり。）

■テスト２
SHV・・・F/Wが有効であること
正常性ポリシー
・Compliant・・・すべてにパス
・NonCompliant・・すべてにパス
※これは、わざと準拠と非準拠を同条件にした設定。
ネットワークポリシー
Compliant-FULLが一番上、次がNonCompliant-Restrictedの順。

⇒クライアント側で
F/W有効
→制限なしのIPアドレス
F/W無効
→IPアドレスもらえない。APIPAのアドレスになる。

この結果は、ネットワークポリシーの順序で変わる。
ネットワークポリシー
NonCompliant-Restrictedが一番上、次がCompliant-FULLの順だと。

⇒クライアント側で
F/W有効
→制限ありのIPアドレス
F/W無効
→IPアドレスもらえない。APIPAのアドレスになる。

■テスト３
SHV・・・F/Wが有効であること
ウイルス対策ソフトが有効であること
正常性ポリシー
・Compliant・・・すべてにパス
・NonCompliant・・１つ以上にパス
※これは、すべて失敗のクライアントは準拠でも非準拠でもなくなる設定。
ネットワークポリシー
Compliant-FULLが一番上、次がNonCompliant-Restrictedの順。

⇒クライアント側で
F/W有効　＆　ウイルス対策なし
→IPアドレスもらえない。APIPAのアドレスになる。
（これはヘン。F/W：パス　＆　ウイルス：失敗だから、「１つ以上に
パス」に合致する。それなのに制限ありのIPアドレスがもらえない。）
F/W無効　＆　ウイルス対策なし
→IPアドレスもらえない。APIPAのアドレスになる。
（こちらは予想どおり）

■テスト４
SHV・・・F/Wが有効であること
ウイルス対策ソフトが有効であること
正常性ポリシー
・Compliant・・・すべてにパス
・NonCompliant・・すべてに失敗
※これは、部分的にパスのクライアントは準拠でも非準拠でもなくなる設定。
ネットワークポリシー
Compliant-FULLが一番上、次がNonCompliant-Restrictedの順。

⇒クライアント側で
F/W有効　＆　ウイルス対策なし
→制限ありのIPアドレス
（これもヘン。F/W：パス　＆　ウイルス：失敗だから、「すべてに失敗」
ではないのに、制限ありのIPアドレスがもらえてしまう。）
F/W無効　＆　ウイルス対策なし
→制限ありのIPアドレス
（こちらは予想どおり）

■テスト５
SHV・・・F/Wが有効であること
ウイルス対策ソフトが有効であること
正常性ポリシー
・Compliant・・・１つ以上にパス
・NonCompliant・・すべてに失敗
※これは、矛盾する設定ではない。
ネットワークポリシー
Compliant-FULLが一番上、次がNonCompliant-Restrictedの順。

⇒クライアント側で
F/W有効　＆　ウイルス対策なし
→制限ありのIPアドレス
（やはりヘン。F/W：パス　＆　ウイルス：失敗だから、「１つ以上に
パス」に合致する。それなのに制限なしにならない。）
F/W無効　＆　ウイルス対策なし
→制限ありのIPアドレス
（こちらは「すべてに失敗」に合致するから、予想どおり）

まとめ

正常性ポリシーの設定が悪く、準拠でも非準拠でもないクライアントができてしまうと、それらは制限付きどころか、通信そのものができない。
問題は、「一部のチェックに失敗」しているだけのクライアントを「すべてに失敗」で把握してしまっていることだ。NAPでは「一部のチェックに失敗」のクライアントの制御に問題があると考えられる。

ただし最新のOSやサービスパックを使用しての検証ではないので現状では解決しているか不明

MSFCのサポートノード数

3件の返信

今回はどうでもいいこと？なんですが今度クラスタの講義を担当することになったので仕込中

そこで肝心要のMSFCのサポートノード数を調べるのに手間取ってしまいました

Windows Server 2008 技術仕様では

– Windows Web Server 2008 ： 使用不可
– Windows Server 2008 Standard ： 使用不可
– Windows Server 2008 Enterprise ： 16
– Windows Server 2008 Datacenter ： 16
– Windows Server 2008 for Itanium-based Systems ： 8

なのですが、とある資料に32ビットは8ノードと書いてあったんです。しかしなかなか裏が取れない

しょうがないので高添さん（MSエバンジェリスト）に聞いちゃいました（笑）

Maximum number of supported nodes in a cluster
http://support.microsoft.com/kb/288778

ばっちり書いてあります

Operating System Number of nodes Storage
Windows NT 4.0 Enterprise Edition
Windows 2000 Advanced Server
Windows 2000 Datacenter Server
Windows Server 2003, Enterprise Edition
Windows Server 2003, Enterprise x64 Edition
Windows Server 2003, Datacenter Edition
Windows Server 2003, Datacenter x64 Edition		 1-2 SCSI
Windows NT 4.0 Enterprise Edition
Windows 2000 Advanced Server		 1-2 Fibre Channel
Windows 2000 Datacenter Server 1-4 Fibre Channel
Windows Server 2003, Enterprise Edition
Windows Server 2003, Enterprise x64 Edition
Windows Server 2003, Enterprise Edition for Itanium-based Systems
Windows Server 2003, Datacenter Edition
Windows Server 2003, Datacenter x64 Edition
Windows Server 2003, Datacenter Edition for Itanium-based Systems
Windows Server 2008, Enterprise Edition
Windows Server 2008, Enterprise Edition for Itanium-based Systems
Windows Server 2008, Datacenter Edition
Windows Server 2008, Datacenter Edition for Itanium-based Systems		 1-8 Fibre Channel, iSCSI, or SAS
Windows Server 2008, Enterprise x64 Edition
Windows Server 2008, Datacenter x64 Edition		 1-16 Fibre Channel, iSCSI, or SAS

ということで、OSのx86とx64による違いが明確に判ります。

x86のW2008のMSFCでは最高8ノードになります。ですので日本語のサイトはちょっと誤解を招くかもしれませんね。

外付けUSBドライブからWindows7の起動

コメントを残す

基本的に外付けUSBからのOS起動はできませんでしたが、VHDブートを使用することによって起動できることが確認できました。

作成するには前提として、Windows7 or Windows Server 2008 R2 がインストールしてある

以下手順

  1. インストールDVDから起動
  2. 今すぐインストールを行うの次の画面、インストール先を選ぶ画面で　Shift+F10
  3. コマンドプロンプトを呼び出し、これからWindows7をインストールするドライブにVHDを作成する（たいていDドライブ）
  4. フォルダを作成する
    mkdir D:VHD
  5. VHD作成
    Diskpart
    create vdisk file=D:VHDWin7.vhd maximum=12288 type=fixed
  6. 作成したVHDをマウントする
    attach vdisk
  7. Diskpartを終了させ、止めていたインストール画面にALT+TABで戻る
  8. 最新の情報に更新を行い、マウントしたVHDが表示されているのを確認する
  9. VHDへのインストールを選択し、エラー表示を無視してインストールを行う
  10. インストール終了後デュアルブートになっているので、そのままWindowsが起動するのを待つ
  11. VHDから起動したWindowsのレジストリを修正する（regedit→USB関連の起動を自動にする）
    HKEY_LOCAL_MACHINE/SYSTEM/ControlSet001/Services/usbehci
    Startの値を0
    Groupの値をSystem Bus ExtenderHKEY_LOCAL_MACHINE/SYSTEM/ControlSet001/Services/usbhub
    Startの値を0
    Groupの値をSystem Bus Extender

    HKEY_LOCAL_MACHINE/SYSTEM/ControlSet001/Services/usbstor
    Startの値を0
    Groupの値を新規作成し、値をSystem Bus Extender
    TagのDWORD値を新規作成し、値を3

    HKEY_LOCAL_MACHINE/SYSTEM/ControlSet001/Services/usbuhci
    Startの値を0
    Groupの値をSystem Bus Extender
    ※ControlSet001以外にControlSetがある場合は全て変更する

    修正後VHDブートしたWindowsはシャットダウンする

  12. ここからインストールした内蔵HDDのWindowsから操作を行う。インストールDVDも使用するのでDVDをドライブにいれておく。
    外付けUSBを繋ぎ、コマンドプロンプトを起動
    diskpart
    select disk 1
    Clean
    create partition primary
    assign letter=Z
  13. Z:ドライブとしてマウントした外付けUSBの直下にD:ドライブにあるwin7.vhdをコピーする
  14. 外付けUSBディスクにブートローダーを書き込む（BootsectはインストールDVDのBootフォルダの中にある）
    Bootsect /nt60 z: /force /mbr
  15. Windows7のVHDファイルにブートローダー情報を書き込むため、VHDをR：ドライブとしてマウントする
    diskpart
    select vdisk file=Z:Win7.vhd
    attach vdisk
    assign letter=R
    exit
  16. ブート情報をマウントしたWindows7のVHDファイルに書き込む
    bcdboot R:windows /s z:
    Rは外付けUSBからマウントしたVHDのドライブレター
    Zは外付けUSBのドライブレター
  17. 外付けUSBに書き込んだBCDを修正する
    BCDEditは管理者権限でないと変更できないので、cmdをShiftを押しながら右クリックでcmdを管理者から起動を選ぶ
    BCDEdit /STORE R:BootBCD /set {default} description “USB Win7”
    BCDEdit /STORE R:BootBCD /set {default} local ja-JP
    BCDEdit /STORE R:BootBCD /set {default} detecthal on
    BCDEdit /STORE R:BootBCD /set {Bootmgr} local ja-JP/store で外部のBCD修正、ブートファイルの書き込みを行うとデフォルトでen-USなのでja-JPへ変更
    detecthal onでハードウェアの情報を検出する
  18. マウントしたVHDをアンマウントする
    diskpart
    select vdisk file=Z:Win7.vhd
    detach vdisk
    exit
  19. 再起動してUSBからブートできるようにBIOS設定後、USBデバイスからブートでUSBにあるVHDからWindows7が起動する
  20. 外付けUSBディスクのVHDからブートしたWindowsのUSB関連のレジストリが元に戻っている場合があるので、11のレジストリを再度見直しを行う
  21. アクセサリ＞システムツール＞ディスクデフラグツールより自動実行を無効にする
  22. システムのプロパティのシステムの保護タブの構成＞システムの保護を無効にする
  23. 完了

サービスアカウントの新機能

コメントを残す

Windows Server 2008 R2テクノロジ入門 (マイクロソフト公式解説書) という書籍を読んでいたら、管理されたサービスアカウントなるものが新機能として追加されたことが書いてありました。これは知らなかったので調べてみました。

参考：サービス アカウントの新機能

Windows Server 2003 よりサービス専用アカウントとして、Local Service、Network Serviceというアカウントが追加されセキュアでローカルなサービスアカウントを使用できるようになりました。

よって、Windows Server 2003では

  1. Network Service
  2. Local Service
  3. 自分で作成したサービスアカウント
  4. Local System

の順にサービスアカウントを適用して試すことが推奨となっていましたね

Windows Server 2008 R2の新機能として、「管理されたサービス アカウント」と「仮想アカウント」の 2 種類の新しいサービス アカウントを使用できるようになりました。

管理されたサービス アカウント

ここでのポイントは3の自分で作成するサービスアカウントのことを指しています

例えば今までは、ドメインアカウント（もしくはローカルアカウント）を使用してサービスアカウントにしますが、ユーザー権限の割り当てを使用して最低限のセキュリティ設定を行う必要がありました。更に、パスワードの問題がありました。それはサービスアカウントのパスワード変更には多大な労力が発生していたことです。仮にサービスアカウントのパスワードを変更しようと思うと、ADのユーザー設定からパスワードを変更し、サービスの画面からサービスアカウントのパスワードを変更する必要がありました。そのようなことがあるので、多くの場合は無期限パスワードにしていた経緯があります。しかし、これはセキュリティの面から考えると脅威として認識しておく必要がありました。

今回の新機能である、「管理されたサービス アカウント」を使用すると、パスワードは定期的に自動変更されます。このメリットとして、ADのユーザーアカウントとサービスのパスワードの変更が自動的に反映されることになります。さらに対話的なWindows ログオンに使用することができないので、セキュリティ的にも強固になります。

作成方法

ADユーザーとコンピューターを使用して作成することはできません。このアカウントはPowerShellを使用する必要があります。

WS000087

具体的なコマンドとしては

New-ADServiceAccount <アカウント名＞

プロパティを見るには

Get-ADServiceAccount <アカウント名＞

オブジェクトはADユーザーとコンピューターのManaged Service Accountコンテナに存在します。

このアカウントをドメインメンバーで使用するためには

Install-ADServiceAccount –Identity ‘<アカウント名＞’

を使用してインストールする必要があります。そして、通常のユーザーオブジェクトと同様に設定することができます。その際のパスワードはNull（空欄）にする。

仮想アカウント

参考URLを読むと次のように記載がありました。

以下抜粋

仮想アカウントを使用すると、パスワード管理を行わなくても済み、ドメイン環境内のコンピューターのアカウントの資格情報を使用してサービスがネットワークにアクセスできるようになるため、サービス管理が簡単になります。

ここまで

これって、何を言っているの？ということで、よくわからないのでいろいろ調べてみると・・・・以下のようなことがわかりました。

Windows7とWindows Server 2008 R2では仮想アカウントというアカウントが導入された。

このアカウントは、ビルトインの「Network Service」アカウントを使用するサービスのログを追跡できるようにすることを目的としたものである。

「Network Service」アカウントはW2003で導入された。このアカウントは従来の「LocalSystem」アカウントに代わるものとして使用され、ローカルマシンに対しては完全なローカルシステム権限を持ち、ネットワークアクセスに関してはコンピュータアカウントの資格情報を使用する。

ところで、「Network Service」アカウントを使用するサービスが、数多くマシン上に構成されている場合、各サービスが実際何のリソースにアクセスし、何の操作を実行しているのか追跡することはほぼ無理である。なぜなら、それらすべてのサービスが「Network Service」アカウントを使用しているため、どのサービスのログか区別できないからである。

仮想アカウントは、サービスのインスタンスごとに一意となる「Network Service」アカウントの作成をエミュレートする。つまり、同じサービスであっても別インスタンスであれば、それぞれ別の「Network Service」アカウントとなる形である。これによりサービスごとの監査やログ追跡が容易になる。

ということになりますね。

システム要件

Windows Server 2008 R2 にドメインコントローラーがインストールしてあること。ただし、必ずしも最新のドメイン機能レベルでなくてもよい。ポイントとしてはR2の新機能が使用できるようにスキーマ拡張が行われていればよい。

＊例外としてはDCがR2以外で、R2のスキーマ拡張が行われている場合は「管理されたサービスアカウント」を使用することはできるが、定期的なパスワード変更などは行われないので手動で行う必要があるとあるが、これって無理では（DCで変更されたパスワードが判らないと思う）・・・

まとめ

「管理されたサービスアカウント」は、自分で作成するサービスアカウントのセキュリティ機能向上を目的として使用され、「仮想アカウント」はNetwork Serviceアカウントの監査やログ追跡を容易にさせる目的で使用される

SCVMM 2008 R2 での P2V で気がついたこと

コメントを残す

SCVMM 2008 R2 を使うようになって気がついたことがあります。

1.　動作が軽くなった

これはかなりよくなりました。今までは、たとえるなら「もっさり」動作していました。またアイコンをクリックして起動するまでに1分以上かかっていたこともありましたが、かなり改善されたのはよかったです。

2.　ホストの追加でエラーが少なくなった

以前はホストの追加でのエラーが頻繁に起こっていました。原因は追加ホストでのFWがうまく設定できないことにあったのですが、R2になってここら辺の処理が改善されたようです。

3.　PV2の際に使用されるポートが変わった

P2V using System Center Virtual Machine Manager 2008 may fail with error 3154 (0x8099319E)
http://blogs.technet.com/scvmm/archive/2009/05/28/p2v-using-system-center-virtual-machine-manager-2008-may-fail-with-error-3154-0x8099319e.aspx

ここにも情報がありました

以前はBITSが443ポートを使用していましたので、P2Vの際に対象ホストが443を使用していた場合はエージェントがそれを使ってしまうのでホスト側でもともと443使用していたアプリは動作しませんでした。その際はSCVMM側でポートの変更を行うことによって対処可能でした。

しかし、R2では40443がデフォルトポートになっているので以前のような心配はしなくて済むようになりました

これ、先日講義を行っていて初めて気がつきました。

説明をしていて、netstat –n で確認してもらったらポートが変わっている！

いや～、些細なこと？ですがいい方向に変わっていますね。

AdminSDHolderに関して検証する

コメントを残す

Technet フォーラム や 国井さんのブログを読んでいて、AdminSDHolderについての話が書いてありました。おはずかしながら、私はその存在自体知りませんでした。そもそもAdminSDHolderって何から勉強してみました。

シナリオから

AdminSDHolder

まずはOU1というOUを作成し、User1とUser2が存在します。OU_Adminsグループに対して委任の設定を行い、OU1の管理者とする。その際にOU1内のユーザーパスワードリセットの権限を付与した。

ou1adminはOU_adminsのメンバーなのでOU1の管理者である。よって、User1及びUser2のパスワードリセットができるはず・・・

しかし、実際にはUser2のパスワードリセットができない

このようなシナリオがあります。

これはなぜ？ということろから話を始めます。

実はUser2がAccount Operatorsのメンバーになっていることが原因なんです。

これは管理者グループのメンバーに対して、1時間に1回PDCエミュレーターがSDPROP(Security Descriptor PROPagator)という機能を利用してAdminSDHolderオブジェクトのアクセス許可を管理者グループのアクセス許可にコピーすることによるものです。

＊AdminSDHolderオブジェクトは、管理者グループに対するアクセス許可を管理しています。そのことから管理者グループのアクセス許可設定は、通常のアクセス許可画面から設定することができません。

AdminSDHolderオブジェクトはActive DirectoryドメインパーティションのSystemコンテナの中にあります。そのセキュリティ設定が管理者グループのアクセス権のひな型になるのです。

WS000082

よって、このアクセス権が管理者グループにコピーされます。

WS000083

では管理者グループとは一体どのグループかというと、グループの属性にAdminCountという属性がありますが、この属性値が1になっているグループが対象になります

これは国井さんのブログで紹介されていました～

ADFind
http://joeware.net/freetools/tools/adfind/index.htm

WS000086

このようなコマンドをたたくと

Using server: london.contoso.com:389
Directory: Windows Server 2008 R2

dn:CN=Administrator,CN=Users,DC=contoso,DC=com

dn:CN=Administrators,CN=Builtin,DC=contoso,DC=com

dn:CN=Print Operators,CN=Builtin,DC=contoso,DC=com

dn:CN=Backup Operators,CN=Builtin,DC=contoso,DC=com

dn:CN=Replicator,CN=Builtin,DC=contoso,DC=com

dn:CN=krbtgt,CN=Users,DC=contoso,DC=com

dn:CN=Domain Controllers,CN=Users,DC=contoso,DC=com

dn:CN=Schema Admins,CN=Users,DC=contoso,DC=com

dn:CN=Enterprise Admins,CN=Users,DC=contoso,DC=com

dn:CN=Domain Admins,CN=Users,DC=contoso,DC=com

dn:CN=Server Operators,CN=Builtin,DC=contoso,DC=com

dn:CN=Account Operators,CN=Builtin,DC=contoso,DC=com

dn:CN=Read-only Domain Controllers,CN=Users,DC=contoso,DC=com

dn:CN=clientpush,OU=SCCM,DC=contoso,DC=com

dn:CN=user2,OU=OU1,DC=contoso,DC=com

dn:CN=ac1user,OU=OU1,DC=contoso,DC=com


16 Objects returned

このような結果が・・・ユーザーも入っていますが、管理者グループの一員になるとAdminCount=1となり、アクセス権もコピーされるということになります。

ちなみにUser1とUser2の属性を比べてみます

WS000085 WS000084

User2のadminCount属性が1になっていることが確認できます。

このような理屈によって、上記シナリオのような現象が起きているのですね！

さて、次のシナリオとしてはOU_Adminsの権限が管理者グループのユーザーに対して継承されないので、これをどうするか？

どうしてもOU管理者に管理者グループのユーザーも管理させたい場合にはAdminSDHolderに対して権限を付与する必要があります。今回の例ではこんな感じですね。

dsacls.exe CN=AdminSDHolder,CN=System,DC=contoso,DC=com /g contosoou1_admins:CA;”Reset Password”;

ただし、考慮しなくてはいけないのが全ての管理者グループにこの権限がコピーされることです。更にadministratorがもしこのOU1に存在する場合は、administratorのパスワードリセットもできてしまうということ。このようなリスクを認識して運用する必要がありますね。

ですので、通常はこのAdminSDHolderの権限変更は行わないと考えます。

更に注意点があります。

今回の例では、User2をAccount OperatorsのメンバーからはずせばUser1と同様にパスワードリセットができるはずですが、これができません。なぜなら、adminCount属性が変わらず、継承もブロックされたままだからです。

委任されたアクセス許可を利用できず継承が自動的に無効になる
http://support.microsoft.com/default.aspx/kb/817433/ja

一旦管理者グループに入れたユーザーは、単に管理者グループから削除しても元に戻らないので、上記KBに書いてあるような方法を使用して元に戻す必要があります。

コアパーキングに関して（その後アップデート情報）

1件のフィードバック

コアパーキングに関して

以前投稿しましたが、その後気になる情報が出てきましたので書き留めておきます。

まず、コアパーキングとは消費電力を削減するテクノロジーになります。このテクノロジーを使用するためにはCPU及びOSの対応が必要になります。

OSではWindows Server 2008 R2からコアパーキングをサポートしたので、CPUがサポートしていれば自動的に使用してくれるので便利ですね～なんて紹介をしました。

しかし、コアパーキングを含む電源管理が原因で、Hyper-V環境でのトラブルが発生している模様です。

具体的な現象としては、Hyper-Vの仮想端末が突然ブルースクリーンになるとか・・・です

You receive a “Stop 0x0000007E” error on the first restart after you enable Hyper-V on a Windows Server 2008 R2-based computer
http://support.microsoft.com/kb/974598/en-us

Stop error message on an Intel Xeon 5500 series processor-based computer that is running Windows Server 2008 R2 and that has the Hyper-V role installed: “0x00000101 – CLOCK_WATCHDOG_TIMEOUT”
http://support.microsoft.com/kb/975530/en-us

特に問題なのはNehalemにおける問題として修正プログラムがあがっているのですが、それでも駄目という場合があるらしい

ちなみに対象プロセッサーとしては以下のものが報告されています

  • Intel Xeon Processor 5500
  • Intel Core i7-800
  • Intel Core i5-700

ですので、落ち着くまでにはまだ時間がかかりそうな予感です

では対処方法としてはどうすればいいのか？

これはBIOSの設定で、C-State を無効にすることによって、結果的にOSでのコアパーキング機能を無効化すればいいようです。

ちなみにちょっと調べてみたのですが、電源管理ではACPIのC-StateとP-Stateがありますが、どんな機能何だろう？

C-Stateは各コアのアクティブなプロセスがなくなりアイドル状態になったときにその状態を遷移させて（C0～C6）、アイドル時の消費電力を0Wに限りなく近づけることにより消費電力を削減する機能。

P-Stateとは何か？そもそも各CPUは複数のP-Stateが存在し、プロセッサの動作周波数と電圧が決まっており，コアごとにP-Stateを切り替えられます。よって、動作周波数を下げれば電圧も下がり、消費電力も下がるということになります。

たとえば、クアッドコアAMD Opteron 2356 プロセッサ（2.30GHz）には、P0（2.30GHz）、P1（2.0GHz）、P2（1.7GHz）、P3（1.4GHz）、P4（1.15GHz）の5段階ものP-Stateが存在するので、サーバーの負荷状況に応じて動的にP-Stateを切り替えれば，消費電力も削減できますね。

しかし、クロックを落とす＝パフォーマンスを低下させるので、負荷の軽い時間帯だけ落とすといった限定的な使い方になると思われます。

よって、トータルな電源管理であるACPIでは、C-StateとP-Stateを組み合わせてパフォーマンスと消費電力のバランスを取っているということになりますね。

＊ここら辺の話は、様々な情報を組み合わせて私なりの理解となりますので間違っていた場合は指摘いただければ幸いです

さて、ちょっとネガティブな情報でしたが、ポジティブ情報も書いておきます。これは実際にCTCの杵島さんに聞いたお話ですがPen4 ベースの Xeon 系のサーバーで消費電力を比べるとアイドル時で約4割近く消費電力は下がるそうです。杵島さんが参加された最新CPUの検証結果がIntelよりダウンロードできます。

クリックして322956-001JA.pdfにアクセス

2010年9月6日追記

An update rollup package for the Hyper-V role in Windows Server 2008 R2: August 24, 2010
http://support.microsoft.com/kb/2264080/en-us

これらの問題の修正プログラムが出たようです。