「Server」カテゴリーアーカイブ

Link Value Replicationの件

2件の返信

現在、Windows Server 2008 のAD設計のコース準備をしています。

そこでこんな記述があって悩んでいました。

・AD DSを復元するときの考慮事項というのがあり、削除後にAuthoritative restoreによって復元したユーザーオブジェクトのグループメンバシップの復元は、いつLVRを実装したかによって異なる

ん？なにが言いたいの？ということで調べてみるとこんな情報が・・

Authoritative restore issue with LVR enabled attributes

障害回復: Active Directory ユーザーとグループ

これらの情報から整理すると

■復元における問題

Authoritative restoreによる復元ではオブジェクトが持つ前方リンクを元の状態にきちんと戻すことができない。この問題は[W2000]のフォレスト機能レベルで運用していたフォレストを[W2003]のフォレスト機能レベルにアップした場合にのみ起こる。

特に、削除されたグループメンバーシップを回復するためにグループオブジェクトのAuthoritative restoreを行っても、[W2003]のフォレスト機能レベルにアップグレードする前に作成されたグループメンバシップ情報は復元されない

■シナリオ

AD管理者は１つのグループのメンバーから複数のユーザーを削除した(ユーザー自体の削除ではない。あくまでもグループメンバーからの削除)。ところがこれがミスオペだとわかり、管理者は元の状態に戻さなければならなくなった。

■管理者はどうすれば良いか

この状況から回復させる一つの方法は次の通り。

本番環境からは隔離された別のマシンにシステム状態の復元を行う。こうすれば、他のDCから複製により上書きされることは無い。

そして、ポイントはグループメンバーシップを復元するためにNtdsutilによって作成されるldfファイルを使用することだ。Ntdsutilによって作成されるldfファイルを本番環境に転送し、そして復元のためにインポートする。

■そもそもこんなことが起こらないようにする

フォレスト機能レベルがWindows server 2003以前に作成されたグループはLVRが有効になっても新しいレプリケーション メタデータが自動的に適用されるわけではない。あくまでもフォレスト機能レベルがWindows server 2003になってLVRが有効の状態でグループにユーザーを追加した時に、新しいレプリケーション メタデータが自動的に適用されることになる。

ここが問題になる。ということはAuthoritative restoreによる復元でグループを復元したとしても、ユーザー情報は復活しないということになる。

ということで、フォレスト機能レベルをWindows server 2003に上げたら、全てのグループのユーザーを入れなおす作業をしておいたほうがいいことになります。これはldifdeコマンドで簡単にできるでしょう。

グループのユーザーの数が少なければ手作業でもそんなに大変ではないのであまり問題にはならないかな？

あと2008ならADデータベースマウントツール（dsamain.exe）を使うことによって過去のスナップショットからグループの情報を参照できるので最悪の事態は避けられると思われます。

App-VをWindows Server 2008 R2に入れた際に起きるトラブル？

コメントを残す

先日 MDOP 2010 Refresh を Windows Server 2008 R2 に新たに環境を作成しなおしました。

App-Vに関してはサーバーはバージョンアップはされていないので4.5 SP1が入っています。クライアント及びシーケンサーがApp-V 4.6となっています。これでやっとOffice 2010 RTMが正式サポートされました（64Bit版のOSに対しても）

そして普通にサーバー設定も終わり何事もなかったのですが・・・

サーバーを再起動すると次のようなことが起こりました。

App-Vのコンソールを起動するとこのような画面が出てOKをクリックすると次の画面になります。

WS000038

が～ん

WS000039

これでOKを押しても画面は起動するのですが、サーバーには接続しません。よって、操作が全くできなくなるのです。

たまたまこのようなことが起こったのかな～なんてあまり気にしていなかったのですが先日TFのイベントで同様のことが起こっていることを聞きました

その際にもしかしたらSP2が出ているのでそれを適用すると直るかも・・・という話がでたので試してみました

ビンゴです。SP2を適用したら正常にApp-Vのコンソールが起動しました。

WS000040

ということで、 MDOP 2010 Refreshを使用してApp-VをR2に導入する際には、必ずApp-Vの最新のサービスパックを適用しましょう！

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日修正

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

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

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ノードになります。ですので日本語のサイトはちょっと誤解を招くかもしれませんね。

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

コメントを残す

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アカウントの監査やログ追跡を容易にさせる目的で使用される

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

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

Hyper-V環境でのウイルス対策

コメントを残す

さて、実際にHyper-V環境を構築して運用している企業も増えてきたと思われます。

その際に意外と盲点なのが、ウイルス対策はどうするの？

マイクロソフトとしては、ホスト及びゲスト両方にウイルス対策ソフトを入れて対処してね～と言っていたような。

しかし、調べてみるとホストOSにたいしてウイルス対策ソフトをインストールした際のトラブルが起きていることが判明

現象でいうと、仮想マシンが突然消えてなくなるとか、起動しなくなるとか、見えなくなるとか・・・

Virtual PC Guy’s Blog
http://blogs.msdn.com/virtual_pc_guy/archive/2009/03/17/antivirus-and-hyper-v-or-why-can-t-i-start-my-virtual-machine.aspx

このブログでは対策としては次の2点が述べられています

  • ホストOSに対してウイルス対策ソフトをインストールしない
  • ウイルス対策ソフトをインストールするのであれば除外設定などを確実におこなう

ホストOSに対してウイルス対策ソフトをインストールしないのもネットワーク構成をきちんと行うのであればありかな？と私は考えます。それはホストOSと仮想マシンが利用するネットワークを分けて、管理OSが使用するネットワークはクリーンなネットワークを使用する。一部のウイルス対策ソフトをインストールすることによるパフォーマンスの低下という問題が発生しないのが大きなメリットですね。ただし、ウイルスに対するリスクを認識して運用する。

除外設定などを具体的に行う方法に関しては、マイクロソフトの情報がありました。

http://support.microsoft.com/kb/961804

ではどのように構成すればいいのか？

ウイルス対策ソフトウェア内のリアルタイム スキャン コンポーネントで次のディレクトリおよびファイルが除外されるように構成します。

  • 既定の仮想マシン構成ディレクトリ (C:ProgramDataMicrosoftWindowsHyper-V)
  • カスタム仮想マシン構成ディレクトリ
  • 既定の仮想ハード ディスク ドライブ ディレクトリ (C:UsersPublicDocumentsHyper-VVirtual Hard Disks)
  • カスタム仮想ハード ディスク ドライブ ディレクトリ
  • スナップショット ディレクトリ
  • Vmms.exe
  • Vmwp.exe

となっています。

もしくは、仮想ディスクファイル（VHD、AVHD)とvmms.exe、vmwp.exeの除外でも同じことですね。

念のためディレクトリの除外とファイルの除外両方を行っておけばいいですね。

これらの設定を行わずに運用するとかなり痛い目にあうようですのでどんなウイルス対策ソフトを使用していても、設定を行ってください。