Microsoft.com の内部事情ASP.NET の管理と委任

Jeff Toews

Microsoft.com の Web インフラストラクチャは、ほぼ全体が .NET Framework 2.0 で実行されています。Microsoft.com 運用チームの Web 管理に関する主な課題は ASP.NET を適切に構成することです。チームでは、設定を完璧な状態に近づけるために微調整しながら多くのことを学習してきました。

構成設定を正しく行うには、web.config ファイルと machine.config ファイル内のさまざまな構成セクションについての十分な実用的な知識と、これらの設定の意味を理解する必要があります。設定とその重要性について理解する適切な方法は、例を見ることです。このコラムでは、チームが経験から学んだことからメリットを得られるように、Microsoft.com を運用するサーバーの構成から得た構成のヒントをいくつか紹介します。

1. コンパイル スイッチの適切な設定

ASP.NET ベースのアプリケーションを運用環境に展開するときは、アプリケーションの web.config ファイルで、次のように誤って (または故意に) compilation の debug 属性を true に設定したままにしないことが重要です。

<compilation debug="true" />

多くの Web アプリケーションを管理するアクセス頻度の高い環境では、ASP.NET の構成制御メカニズムを使用して、この問題が発生しないようにできます (このメカニズムについては、この後すぐに詳しく説明します)。

次のように、各 .aspx ページ固有の debug 属性が true に設定されないようにすることも重要です。

<%@ Page debug="true" %>

大量のページを発行するアクセス頻度の高い環境では、ページを発行する前にこの設定をすべての .aspx ページから削除できると考えることは、あまり現実的ではありません。このようなことが起こらないようにする包括的な方法が必要です。

Web アプリケーションをこの設定でコンパイルすると、リリース用のバイナリではなくデバッグ用のバイナリになります。そのうえ、コードが最適化されず、パフォーマンスが低下します。さらに、デバッグの設定でタイムアウトしないようになっているため、ASP.NET 要求はタイムアウトしません。運用環境でデバッグ バージョンを使用することは、ハッカーに侵入のチャンスを与えているようなものです。

さいわい、Microsoft® .NET Framework 2.0 には、web.config ファイルまたは特定のページの属性での指示に関係なく、デバッグ機能、トレース出力、および (ローカル ホストとリモート クライアントの両方で) ASP.NET エラー メッセージの表示を無効にするよう ASP.NET に指示する、machine.config 用の新しい展開設定があります。以下にこのコードを示します。

<configuration>
    <system.web>
          <deployment retail="true"/>
    </system.web>
</configuration>

上記の最後の 2 つのメリット (トレース出力の無効化とリモートでの詳細 ASP.NET エラー メッセージの無効化) は、実際に採用すべきセキュリティ上のベスト プラクティスであることに注意してください。これを採用しないと、自分のアプリケーションの内部のしくみが世界中に公開され、悪用されることになります。

ここで、もう 1 つ重要な点について説明します。<location allowOverride="false"> 内でルート web.config ファイルの <system.web><compilation> の debug 属性をロックすることや、lockItems 属性を使用することで、アプリケーション構成階層の下位層に位置する web.config ファイルでデバッグ設定が有効にされることを防ぐことができます。ただし、これによって各 .aspx ページのページ属性の debug モードが有効にならないというわけではありません。ASP.NET のデバッグ機能をすべてのレベルで完全に無効にする唯一の方法は、deployment retail スイッチを使用することです。

deployment retail スイッチを true に設定することは、おそらく、アプリケーションを常に可能な限り最高のパフォーマンスで実行し、セキュリティ情報が漏れないようにするために、正式な運用サーバーを使用しているすべての企業が採用すべきベスト プラクティスです。既に述べたように、このスイッチは ASP.NET チームに寄せられたフィードバックを受けて導入された、ASP.NET 2.0 の新しいスイッチです。

逆に、開発者が Web アプリケーションをデバッグする必要のある社内の非運用環境では、deployment retail の設定を使用しないでください。単に非運用環境のルート web.config ファイルに <compilation debug="false"> を設定し、各アプリケーションの web.config ファイルまたは .aspx のページ属性がこの値よりも優先されることを許可します。

2. ASP.NET 2.0 における中程度の信頼の使用

Microsoft.com の多くのサイトに行ったように、サイトやアプリケーションを ASP.NET 2.0 に移行した後でも、完全な信頼または高度な信頼のレベルを使用している場合は、中程度の信頼にするとどのようなことが可能になるかを見てみます。たとえば、制限付きの WebPermission は、アプリケーションの通信を <trust> 要素で定義する 1 つのアドレスまたはアドレスの範囲に限定します。これにより、リモートで呼び出すことができる承認済みの外部サイトとアドレス範囲のリストを制御および管理できます。このことは、セキュリティ上の大きなメリットになります。

中程度の信頼では、FileIOPermission も制限されます。つまり、アプリケーションのコードからは仮想ディレクトリ階層内のファイルにしかアクセスできません。中程度の信頼では、各アプリケーションの仮想ディレクトリ階層のみに、Read、Write、Append、および PathDiscovery のアクセス許可が既定で与えられます。これにより、ファイルへのランダムな I/O アクセスがなくなります。この設定は、多くのアプリケーションがホストされている共有 Web 環境では極めて重要です。

もう 1 つのメリットは、アンマネージ コードの特権が除去されることです。つまり、レガシ コンポーネントの使用を防ぐことができます。これは、Aspcompat ページ属性を使用できないようにする、これまでにわかっている最も簡単な方法です (Aspcompat を true に設定すると、ページのパフォーマンスが低下する場合があります)。

ASP.NET 2.0 での中程度の信頼は、管理者が以前の既定の各制限にユーザー定義の例外を作成できるようにする機能について大きな柔軟性があります。ASP.NET 1.1 にはこのような柔軟性はありません。また、ASP.NET 2.0 を使用した中程度の信頼の実行では、ASP.NET 1.1 を使用した場合に比べて、Microsoft SQL Server™ データベースへのアクセスが容易です。

したがって、同一サーバー上で複数のアプリケーションをホストする場合、コード アクセス セキュリティと中程度の信頼レベルを使用することで、アプリケーションの分離を実現できます。ルート web.config ファイルで (<location allowOverride="false"> タグを使用して) 信頼レベルを設定およびロックすることで、サーバー上のすべての Web アプリケーションに対してセキュリティ ポリシーを確立することができます。図 1 に示すように allowOverride="false" を設定することで、各開発者が、アプリケーションの web.config ファイルに設定された中程度の信頼ポリシー設定をオーバーライドできなくなります。

Figure 1 信頼の設定

<configuration>
    <location allowOverride="false">
        <system.web>
            <securityPolicy>
                <trustLevel name="Full" policyFile="internal" />
                <trustLevel name="High" policyFile="web_hightrust.config" />
                <trustLevel name="Medium" policyFile="web_mediumtrust.config" />
                <trustLevel name="Low"  policyFile="web_lowtrust.config" />
                <trustLevel name="Minimal" policyFile="web_minimaltrust.config" />
            </securityPolicy>
            <trust level="Medium" originUrl="" />
        </system.web>
    </location>
</configuration>

ASP.NET 2.0 での中程度の信頼の使用方法の詳細については、「How To: ASP.NET 2.0 で中程度の信頼を使用する方法」を参照してください。

3. 特定の種類のファイルのダウンロード制限

サーバーには、絶対に悪人の手に渡らないようにすべき種類のファイルがあります。さいわい、ASP.NET では、ASP.NET アプリケーションで使用されているいくつかの異なる種類のファイルの要求を阻止および中止するように既定で構成されています。このようなファイルには、.config ファイルや、アプリケーションのソース コードを格納する .cs ファイルがあります。ASP.NET では、両方の種類のファイルを System.Web.HttpForbiddenHandler と関連付けることで、こうしたファイルのプライバシーを確保します。このハンドラが呼び出されると、ファイルを要求したユーザーにエラーを返します。実際、この方法を使用してすべての種類のファイルを制限できます。

たとえば、Microsoft.com サイトで次のエントリをルート web.config ファイルの <system.web><httpHandlers> セクションに追加すると、ファイルの種類 .asmx は許可されません。

<add path="*.asmx" verb="*" type=
    "System.Web.HttpForbiddenHandler" />

ご覧のように、<httpHandlers> 要素の中で <add> サブ タグを使用し、ブロックする必要のあるファイルの種類を追加指定できます。次に、verb 属性を "*" に設定することで、指定したファイルの種類に対して、すべての種類の HTTP 要求がブロックされることを指定しています。その後、path 属性を、ブロックするファイルの種類と一致するワイルドカード文字で定義します。たとえば、"*.mdb" と指定できます。最後に、type 属性を "System.Web.HttpForbiddenHandler" に設定します。

4. アセンブリ参照を追加する際の注意点

.NET Framework を実行する各 Web サーバーには、グローバル アセンブリ キャッシュ (GAC) という、コンピュータ全体で使用されるコード キャッシュがあります。GAC は、コンピュータ上の複数のアプリケーションで共有するように特別に指定されたアセンブリを格納します。Web サーバー上のサイトの大多数がアセンブリにアクセスするわけではなくても、いくつかの異なるアプリケーションでアセンブリを参照する必要がある場合は、これらを GAC に追加することをお勧めします。これによりパフォーマンスやリソースが大幅に低下することはなく、サーバー中に散在する共有アセンブリが各アプリケーションの /bin フォルダに存在する状態にはならず、集中的なバージョン管理を実行できるメリットが得られます。

ただし、アセンブリ参照をルート web.config に追加するタイミングの条件は、アセンブリを GAC に配置するタイミングを決める条件よりもはるかに厳しくする必要があります。各アプリケーションで、まったくグローバルではないコンポーネント用のアプリケーションの web.config ファイルの中でアセンブリ参照を追加すると、これらのアセンブリ参照をルート web.config ファイルで宣言するよりもパフォーマンスが大幅に向上します。コンパイラでは不要なアセンブリを読み込む時間が必要ないので、これらのアセンブリを使用しない Web サーバー上のすべてのアプリケーションで、ページの読み込み時間が大幅に短縮されます。単にアセンブリは GAC 内に常駐するので、ASP.NET コンパイラはアプリケーションのアセンブリを読み込みません。アセンブリ参照がアプリケーション ドメインまたはアプリケーション スコープの上位に存在する場合のみ、コンパイラがアセンブリを読み込みます。そのため Microsoft.com では、アプリケーションの開発者が、すべての Microsoft.com 環境用のアプリケーションの web.config ファイルの <configuration><system.web><compilation><assemblies> 要素をオーバーライドできます。

具体的には、Microsoft.com の運用環境およびステージング環境のルート web.config ファイルでは、<system.web><compilation> ノードのすべての属性 (debug、explicit、defaultLanguage など) と、このノードの <assemblies> 要素を除くすべての要素 (buildProviders、expressionBuilders など) がロックされています。

<compilation debug="false" 
    explicit="true" defaultLanguage="vb" 
    numRecompilesBeforeAppRestart="500" 
    lockAttributes="*" lockAllElementsExcept=
        "assemblies" >

社内の非運用環境では、ルート web.config ファイルで <system.web><compilation> セクションがロックされていますが、アプリケーションの発行者が具体的に <assemblies> 要素をオーバーライドすることや、(トラブルシューティングとデバッグを有効にするために) debug="false" をオーバーライドすることも許可されています。

<compilation debug="false" explicit="true"
    defaultLanguage="vb" 
    numRecompilesBeforeAppRestart="500" 
    lockAllAttributesExcept="debug" 
    lockAllElementsExcept="assemblies" >

この記事で使用したロックに関する属性は、ASP.NET 2.0 の新しい属性であることに注意してください。また、これらの属性の詳細情報とその使用例については、「セクションの要素によって継承される全般属性」を参照してください。

5. 手動で設定した MaxConnection 値の削除

ほぼすべての Microsoft.com Web サイトには、リモート Web サービス クラスタの呼び出しを行う ASP.NET アプリケーションがあります。1 つの Web サーバーからリモート Web サービスを同時に呼び出せる最大数は、machine.config ファイル内の <connectionManagement> 要素の maxConnection 属性によって決まります。ASP.NET 1.1 では、maxConnection の値が既定で 2 に設定されていました。この古い既定の maxConnection 値は、Microsoft.com のようなサイトには低すぎました。このサイトには、リモート Web サービスの呼び出しを行う何百もの異なるアプリケーションが存在するためです。この設定のため、リモート Web サービスの呼び出しが完了するのを待機する間、ASP.NET 要求がキューに登録されていました (perfmon カウンタの ASP.NET\Requests Queued を使用して、キューに登録されている ASP.NET の要求数を表示できます)。リモート Web サービスの呼び出しをより多く同時に実行できるようにするために (その結果、サイトのアプリケーションのパフォーマンスを向上するために)、4 プロセッサ Web サーバーの maxConnection 値を 40 に増やしていました (maxConnection の一般的な推奨値は CPU 数の 12 倍ですが、特定の状況に合わせて調節してください)。

ただし、ASP.NET 2.0 では maxConnection が自動的に拡張および設定されるようになったため、この属性を手動で構成する必要はなくなりました。これは、machine.config 内の processModel タグに新しい構成セクションが追加されたためです (processModel 要素の詳細については、「processModel 要素 (ASP.NET 設定スキーマ)」を参照してください)。

<system.web>
    <processModel autoConfig="true" />
</system.web>  

machine.config 内で autoConfig が有効になっている状態 (既定の設定) では、ASP.NET によって maxConnection パラメータの値が 12n ("n" は CPU 数) に設定されます。**autoConfig を有効にすることで、maxWorkerThreads パラメータと maxIoThreads パラメータは 100、minFreeThreads パラメータは 88n、minLocalRequestFreeThreads パラメータは 76n、minWorkerThreads は 50 に設定されます。

これらのパラメータに手動で設定されたすべての値は autoConfig によって置き換えられるので、ASP.NET 2.0 で autoConfig を使用して自動的に maxConnection 値と上記のその他の属性を拡張および設定する場合は、必ず手動で設定した値を事前に削除してください。このことは、(maxConnection を明示的に設定する必要がある) ASP.NET 1.1 から ASP.NET 2.0 に移行するときに覚えておく必要のあることです。

また、autoConfig によって設定される maxConnection 値と前に列挙したその他の属性の値はある程度任意になっており、すべてのインスタンスに対して確実に機能しない場合がありますが、これらの制限はほぼすべての Microsoft.com アプリケーションで十分に機能することがわかりました。

maxConnection 値を手動で調整する必要があると判断した場合は、その値を増やすことによって CPU 使用率が増加することに注意する必要があります。アプリケーションで Web サービスの呼び出しを待機することにならず、より多くの着信要求が ASP.NET によって処理されるため、CPU 使用率が増加します。もちろん、maxConnection 属性は、ローカル Web サービスの呼び出しではなくリモート Web サービスの呼び出しのみに影響を与えることを覚えておいてください。

6. ハンドルされない例外についての注意点

ASP.NET 1.1 の Web サイトまたはアプリケーションを ASP.NET 2.0 に移植するとき、ハンドルされない例外の既定のポリシーに関する主な変更点を認識しておくと非常に便利です。.NET Framework 1.1 および .NET Framework 1.0 では、マネージ スレッド上のハンドルされない例外は無視されました。アプリケーションの実行を継続するため、これらの例外は多くの場合非表示のままでした。デバッガをアタッチして例外をキャッチしない限り、異常は確認できませんでした。ただし、ASP.NET 2.0 では、ハンドルされない例外がスローされると、ASP.NET ベースのアプリケーションは予期せず終了します。古い既定の例外処理のポリシーによって以前表示されないようになっていた、ハンドルされない例外が多く存在する場合は、サイトまたはアプリケーションの可用性に深刻な影響を与えることがあります。

この問題を解決する最適な方法は、(アプリケーションに本来あってはならない) ハンドルされない例外のテストと削除をすべて行うことです。ただし、例外の発生場所の特定が困難になる可能性がある非常に大きなアプリケーション、または徹底した個別のテストを実行できない多くのレガシ アプリケーションを移行する必要がある場合は、他にも方法があります。チームでは Microsoft.com Web サイトを ASP.NET 2.0 に移行するとき、ASP.NET 1.1 および ASP.NET 1.0で発生するハンドルされない例外のポリシーを既定の動作に戻しました。

従来の既定の例外処理動作を有効にするには、aspnet.config ファイルに次のコードを追加します。

<configuration>
    <runtime>
        <legacyUnhandledExceptionPolicy 
            enabled="true" />
    </runtime>
</configuration>

コードは次の 2 つのフォルダに配置します。

%WINDIR%\Microsoft.NET\Framework\v2.0.50727 (x86 システムまたは SYSWOW64 システム) および %WINDIR%\Microsoft.NET\Framework64\v2.0.50727 (x64 システム)

この変更により、本質的に .NET Framework の動作が古い 1.1 および 1.0 の動作に戻ることになります。結局は、実際はバグがあるアプリケーションの問題を隠しているだけなので、これは一時的な解決方法と考えてください。ただし、この方法は、ワーカー プロセスが突然終了することが原因で発生する可用性の問題を回避するには非常に便利です。この動作の変更の詳細については、「.NET Framework 2.0 で、ハンドルされない例外によって ASP.NET ベースのアプリケーションが突然終了する」を参照してください。

7. プロキシ サーバーの適切な構成

Web サーバー管理者は、machine.config ファイルの <configuration><system.net><defaultProxy> 要素を構成することで、インターネットへの HTTP 要求に使用するプロキシ サーバーを指定できます。

Micrsoft.com の運用環境では、(ファイアウォール クライアントがインストールされていないため) <defaultProxy> の値をシステム既定のプロキシを使用するように構成し、<location allowOverride="false"> タグを使用して、アプリケーションの開発者によって <defaultProxy> 要素がオーバーライドされないようにしています。これは、アプリケーションの開発者が、誤って内部のプロキシ サーバーを使用して web.config ファイルを発行する可能性があるためです。

<configuration>
    <location allowOverride="false">
       <system.net>
          <defaultProxy>
              <proxy usesystemdefault="true" />
          </defaultProxy>
       </system.net>
    </location>
</configuration>

Microsoft.com の社内の非運用環境およびステージング環境では、usesystemdefault 属性を false に、bypassonlocal を true に設定し、プロキシの bypasslist を追加しています (図 2 を参照)。bypasslist には、指定されたプロキシを使用しないアドレスを表す正規表現のリストを記述します。さらに、このセクションは <location allowOverride="false"> タグ内にあるため、開発者が web.config ファイルで独自のプロキシ サーバーを指定できないようになっています (多くの場合これらのプロキシ サーバーは内部的に使用されるので、これらの呼び出しはページが運用環境に発行されたら終了します)。非運用環境またはステージング環境でプロキシ サーバーを指定すると、必ず運用時に ASP.NET エラーが発生します。そのため、開発者はこの構成を運用環境に発行する前に削除する必要があります。

Figure 2 Bypasslist の設定

<configuration>
    <location allowOverride="false">
        <system.net>
             <defaultProxy>
                <proxy
usesystemdefault="false"
proxyaddress = "http://proxy.server.foo.com:80"
bypassonlocal = "true" />

                <bypasslist>
<add address="10\.*"/>
<add address="dns\.foo\.com" />
<add address="name1\.name2\.foo\.com" />
                </bypasslist>
            </defaultProxy>
        </system.net>
    </location>
</configuration>

8. すべてのユーザーにカスタム エラーを表示しない方法

既に述べたように、運用環境では Web サーバーから詳細な ASP.NET エラー メッセージをリモートで返すことができないようにすることが不可欠です。

Microsoft.com の運用環境およびステージング環境のルート web.config ファイルでは、リモート クライアントにカスタム エラーが表示され、(Web サーバーの管理者によるトラブルシューティングを可能にするために) ローカル ホストに ASP.NET エラーが表示されるように、<configuration><system.web><customErrors> の mode 属性が RemoteOnly に設定されています。<customErrors> 要素は、allowOverride="false" が設定された <location> タグ内にあることに注意してください (図 3 を参照)。これは、各アプリケーションの所有者が誤って (故意に) mode="Off" を設定し、詳細な ASP.NET エラー メッセージをインターネット上に出力しないようにするためです。

Figure 3 エラー メッセージの表示防止

&lt;configuration&gt;
    &lt;location allowOverride=&quot;false&quot;&gt;
        &lt;system.web&gt;
            &lt;customErrors mode=&quot;RemoteOnly&quot; defaultRedirect=
                   &quot;/errorpages/generic_customerror.aspx&quot;&gt;
                &lt;error statusCode=&quot;404&quot; redirect=&quot;/errorpages/filenotfound_customerror.aspx&quot; /&gt;
            &lt;/customErrors&gt;
        &lt;/system.web&gt;
    &lt;/location&gt;
&lt;configuration&gt;

また、前述のように、machine.config ファイルで <deployment retail="true"/> スイッチを使用すると、詳細な ASP.NET エラー メッセージをリモート クライアントとローカル ホストに表示する機能が両方とも無効になることを忘れないでください。いずれにせよ、この deployment retail スイッチは ASP.NET 2.0 を実行している場合にこれらのエラー メッセージを無効にする主な方法です (ASP.NET の例外の詳細については、アプリケーション イベント ログを確認してください)。

Microsoft.com の社内の非運用環境のルート web.config ファイルでは、常に ASP.NET エラーがローカルホストとリモート クライアントの両方に表示されるように、<customErrors> の mode 属性が "Off" に設定されています。これは、デバッグとトラブルシューティングを実行できるようにするためです。また、カスタム エラー ページは構成していません。

<configuration>
    <location allowOverride="false">
        <system.web>
            <customErrors mode="Off" />
        </system.web>
    </location>
<configuration>

9. トレースを有効化する場合

ASP.NET のトレースは ASP.NET ページの実行中に生成され、Web 要求、ページのコントロール ツリー、およびページのライフサイクルや制御におけるさまざまな段階の実行に関する興味深い詳細情報をキャプチャします。また、ページの開発者がトレースに書き込むことができるカスタム メッセージが表示されることもあります。このトレースは、アプリケーションのトレース ビューア内でトレースされた要求一覧の一部として、トレースまたは検査されているページから返される出力に追加されることがあります。この機能は、主に社内の非運用環境での開発時のデバッグ シナリオを対象としており、運用展開に使用しないようにする必要があります。

Microsoft.com の運用環境およびステージング環境のルート web.config ファイルでは、Web ページにトレース情報を出力する機能が無効になるように、<configuration><system.web><trace> の enabled 属性が "false" に設定されています。<trace> 要素は、allowOverride="false" が設定された <location> タグ内にあることに注意してください。これは、各アプリケーションの所有者が誤って (故意に) enabled="true" を設定し、詳細な ASP.NET のトレース情報をインターネットに出力しないようにするためです。

<configuration>
    <location allowOverride="false">
        <system.web>
              <trace enabled="false" localOnly="true"
              pageOutput="false" requestLimit="10" traceMode="SortByTime" />
        </system.web>
    </location>
<configuration>

<system.web><trace>

前述のように、machine.config ファイルで <deployment retail="true"/> スイッチを使用しても、Web ページに ASP.NET のトレースを出力する機能が無効になります。このスイッチは .NET Framework 2.0 を実行している場合はトレース出力を無効にする主な方法です。

確実に、外部に公開される運用環境でトレースを誤って有効にしないようにするために、Microsoft.com ではルート web.config ファイルから実際の trace.axd ハンドラを削除するか、次のようにコメントにしています。

<!--
<add path="trace.axd" verb="*" type=
    "System.Web.Handlers.TraceHandler"
    validate="True" />
-->

10. Web ファームのセッション状態の無効化

Microsoft.com のすべての Web サイトは、(クラスタ内のすべてのサーバーの要求の配布も許可するために) 現在アフィニティを使用しないネットワーク負荷分散 (NLB) を使用してクラスタ化されています。そのため、同じサーバーで特定のアプリケーションのすべて要求が処理される保証はありません。その結果、アプリケーションの開発者による Session プロパティの使用を防ぐために、ASP.NET セッション状態モジュールが無効になります。状態を管理する必要があるアプリケーションの開発者には、ViewState を使用することをお勧めします。ViewState は、ページのコード内の構造で状態を管理するため、サーバー リソースを使用しません。

Web サーバーでセッション状態を無効にするには、次の子ノードを <httpModules> ノードから削除するだけです。

<add name="Session" type=
    "System.Web.SessionState.
    SessionStateModule"/>

ASP.NET 構成ファイル (machine.config ファイル、ルート web.config ファイル、および各アプリケーションの web.config ファイル) を見たことや使用したことがあるという前提で説明してきましたが、そうでない場合は、「ASP.NET クイックスタート チュートリアル」(http://ja.gotdotnet.com/quickstart/aspplus/doc/configformat.aspx) が役立つでしょう。

この記事では、ASP.NET 2.0 の構成システムには非常に便利な機能が多く含まれるようになったことも説明しています。これらの機能により、lockItems 属性および lockCollections 属性を使用して、管理者は構成の個々の要素と属性をロックできます。これらの属性と使用法については、「セクションの要素によって継承される全般属性」を参照してください。

Jeff Toews は、ワシントン州 Redmond を拠点とする Microsoft.com 運用チームのメンバを 6 年間務めているシステム エンジニアリング マネージャです。技術的な質問やコメントがあれば、mscomblg@microsoft.com (英語のみ) までお寄せください。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.