2013/10/02 追記
こんにちは。Windows テクノロジーサポートの新川です。
以前、下記のブログ ポストにてDynamic Cache Service というツールをご案内させていただきました。
リソース不足について–番外編1 (64bit 環境での注意点)
http://blogs.technet.com/b/askcorejp/archive/2009/12/29/1-64bit.aspx
ツールには、Readme やソースコードがついているものの、機能が複雑で、最低限利用するためにはどの設定が必要か分からないというお話をいただく事が多いため、Dynamic Cache Service を使用するための手順をご案内します。
- 利用方法
1. まずは以下の URL より DynCache.zip をダウンロードし展開します。
Microsoft Windows Dynamic Cache Service
http://www.microsoft.com/downloads/details.aspx?FamilyID=e24ade0a-5efe-43c8-b9c3-5d0ecb2f39af&displaylang=en
2. retail フォルダにあるアーキテクチャのディレクトリ (i386/amd64/ia64) から、適用環境とマッチする DynCache.exe をC:\WINDOWS\System32 にコピーします。
3. DynCache.exe をサービスとして登録するために管理者権限で起動したコマンドプロンプトから下記のコマンドを実行します。
sc create DynCache binpath= %SystemRoot%\System32\DynCache.exe start= auto type= own DisplayName= "Dynamic Cache Service"
注意：
オプション "binpath" "start" "type" "DisplayName" と "=" の間にスペースを入れないようご注意ください。
オプション "binpat=" "start=" "type=" "DisplayName=" の後には半角スペースが必要となりますので、ご注意ください。
4. DynCache の設定を行うレジストリ (DynCache.reg) をダブル クリックし、インポートします。
5. サービスを開始します。[スタート] -> [管理ツール] -> [サービス] へ移動し、"Dynamic Cache Service" を開始します。
6. システム キャッシュの上限値を設定するためレジストリ値を変更します。
最低限変更すべき箇所は、以下になります。
キー: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DynCache\Parameters
値: MaxSystemCacheMBytes
型: REG_DWORD
データ: (以下の 3 通りの指定方法)
0 = 物理メモリ容量の 90% (既定値)
1-99 = 物理 RAM 容量の割合 (単位 %)
> 200 = システム キャッシュの最大値 (単位 MB)
(100 ~ 199 を指定した場合は 200 MB が設定されます)
例えば、70 と入力した場合、物理メモリ容量の 70% が制限値として設定されます。
1024 と入力した場合、1024MB が制限値として設定されます。
環境にもよりますが、まずは上限値を 70 (物理メモリの 70%) 程度に設定し、それでも問題が改善しない場合には 50 (物理メモリの 50%) などといった形で調整ください。
MaxSystemCacheMBytes 値を小さく設定しすぎると、不必要なキャッシュの整理処理が行われ、システム負荷を生じさせる可能性があります。
また、DynCache は定期的 (既定値 60 秒) にレジストリの変更を監視しており、 設定変更が検知されると変更を自動的にシステムに反映させます。そのため、値の設定変更後サービスやシステムの再起動は必要ありません。
- アンインストール方法
サービスの登録を削除するためには、次のコマンドを管理者権限で実行します。
sc stop DynCache
sc delete DynCache
こんにちは、Windows テクノロジー サポートの高山です。
Windows Server 2008 フェールオーバー クラスタ (WSFC) ではデザインが
大幅に変更されていますが、今回はその中でもよくお問い合わせをいただく、
ファイル シェア スコーピングの導入についてご説明します。
- ファイルシェア スコーピングの機能について
従来のクラスタ サービス（MSCS） においては、仮想サーバー名や、サーバー名を
ブラウズした場合、ローカルおよびクラスタ化されているすべてのファイル共有が
区別なく表示され、アクセスできました。それに対して、WSFC ではファイル シェア
スコーピングの導入により、ネットワーク名を基にクラスタのファイル共有を
リクエストしているのか、ローカルのファイル共有をリクエストしているのかを
判断して、表示、アクセス制御が行われます。
ネットワーク名によるアクセス
クラスタの仮想サーバー名でアクセスした場合であれば、その仮想サーバーの
グループに所属しているクラスタファイル共有が返されますし、ローカルの
サーバー名であれば、そのローカルのファイル共有のみが返されます。
<<注意>>
ファイル共有を直接指定してアクセスする場合は、以下のように正しい
ネットワーク名を指定する必要があります。
- OK
\\<クラスタ仮想サーバー名>\<クラスタファイル共有>
\\<ローカルサーバー名>\<ローカルファイル共有>
- NG
\\<クラスタ仮想サーバー名>\<ローカルファイル共有>
\\<ローカルサーバー名>\<クラスタファイル共有>
IP アドレスによるアクセス
IP アドレスを指定した場合については、クラスタ化されていないローカルの
ファイル共有のみが返されます。 WSFC でのクラスタ上のファイル共有への
アクセスは、仮想サーバー名 (ネットワーク名) を使用したアクセスのみが
サポートされており、クライアントから、クラスタの共有ファイルへは、
仮想サーバー名を使用したアクセスを行っていただく必要があります。
WSFC にて、仮想サーバーに対する IP アドレスを使用したアクセスが
できないというお問い合わせをいただくことが多いのですが、上記のとおり、
クラスタ上のファイル共有と、ローカルサーバー上のファイル共有にて、
それぞれ適切なアクセス制御を行うための仕様変更となります。
別名によるアクセス
仮想サーバー名 (ネットワーク名) を基にアクセス制御が行われている為、
以下の様な方法を用いた複数の名前によるアクセスは許可されません。
・ １ つの IP アドレスに対して複数のネットワーク名リソースを作成する ・ DNS サーバー上でクラスタの仮想 IP と任意のホスト名を関連づけた A レコードを複数作成する ・ DNS サーバー上で別名 (CNAME) レコードを作成する
これらの方法は MSCS では有効であった方法も含まれておりますので、
MSCS から WSFC への移行の際にはその運用についてご注意ください。
複数の仮想サーバー名で同じ共有フォルダーにアクセスさせたい場合は、
複数の Client Access Point (IP アドレス ＆ ネットワーク名) を作成し、
作成したそれぞれの仮想サーバー名に対し、対象の共有フォルダーを追加します。
これにより、１つの共有フォルダーに対し、ファイルサーバーが複数、設定され、
それぞれの仮想サーバー名を介したアクセスが可能になります。
- 参考情報
File Share 'Scoping' in Windows Server 2008 Failover Clusters
http://blogs.technet.com/b/askcore/archive/2009/01/09/file-share-scoping-in-windows-server-2008-failover-clusters.aspx
こんにちは、Windows テクノロジーサポートの高山です。
Windows Server 2008 のフェールオーバー クラスタ（WSFC） 環境において、
ウイルス対策ソフトウェアのスキャンの対象から除外すべきフォルダーについて
ご案内いたします。
クラスタ環境においては、リソースの状態や、グループの構成などクラスタの
構成情報に変更があった場合は、速やかにクラスタ内のノードに対して、
情報の同期が行われます。
しかしながら、情報の同期が行われる際に、ウイルス対策ソフトウェアにより
クラスタの構成情報を保持しているフォルダー内でスキャンが行われていると、
更新されるべきクラスタ関連のファイルがロックされ、クラスタサービスによる
ファイルへの適切なアクセスが妨害される場合があります。
このような状況が発生した場合、ノード間の情報の同期が正常に行われないため、
異常が検知され、フェールオーバーが発生したり、クラスタサービスの起動に
失敗するなどの現象が発生いたします。
そのため、ご利用されているクラスタ環境のクォーラム構成のタイプに応じて、
クラスタの構成情報が保持されている以下のフォルダーに関しましては、
ウィルス スキャンの対象から除外されることを推奨いたします。
・ノードおよびディスクマジョリティの環境の場合
========================================
- 各ノードの C:\Windows\Cluster フォルダー
- 監視ディスクの Cluster フォルダー
・ノードおよびファイル共有マジョリティの環境の場合
- 監視用ファイル共有の共有フォルダー
・ノードマジョリティの環境の場合
・マジョリティなし ディスクのみの環境の場合
- Quorum ディスクの Cluster フォルダー
<補足>
今回はクラスタ環境の運用の観点で、推奨事項を記載しております。
ご使用のウイルス対策ソフトウェアにより行われるスキャンから、
これらのフォルダーの除外を実行した際に生じるリスクについては
別途、お客様環境にて評価いただきますようお願いいたします。
こんにちは。Windows テクノロジー サポートの戸田です。
Windows Server 2008 クラスタ環境では「フェールオーバー クラスタ管理」 ( R2 の場合には「フェールオーバー クラスター マネージャー」)コンソールから共有ディスクのドライブ文字変更が可能です。
しかし、Windows Server 2003 クラスタ環境の場合、「クラスタ アドミニストレータ」ではその様なメニューはありません。
Windows Server 2003 クラスタ環境で共有ディスクのドライブ文字を変更するには、対象の物理ディスク リソースを所有するノードで「ディスクの管理」画面からドライブ文字を変更します。この手順は非クラスタ環境のローカル ディスクと全く同様で、オープン ハンドルが無ければすぐに反映されます。
クラスタ環境であることは、あまり意識する必要はありません。ドライブ文字の変更を行った物理ディスク リソース (を含むグループ) を他のノードに移動すると、移動先のノードでディスクのオンライン時に自動で変更後のドライブ文字が割り当てられます。
ただし、この操作ではリソース名は変更されないので、リソース名は必要に応じて「クラスタ アドミニストレータ」等から変更してください。
また、クラスタ環境に限った話ではなく、ドライブ文字を変更する際には、古いドライブ文字を使用するリソースなどが無い (あるいは新しいドライブ文字を参照するよう変更し、オフライン状態である) ことを確認の上、変更作業を実施してください。
複数のノードで構成されるクラスタでは、クラスタで使用する (図のようにネットワークのプロパティで、「このネットワークでのクラスター ネットワーク通信を許可する」が選択されている)ネットワーク毎に、ハートビートと呼ばれるパケットの送受信が行われ、ノード間の相互接続が正常であるかどうかの確認を行っています。
このハートビートの送受信で問題が発生する場合、そのネットワークの状態は「障害」や「到達不能」などに変化します(正常時は「稼働中」です)。
クラスタをご利用のお客様から、「ネットワークの経路で問題が無いにも係わらず、クラスタ上でネットワークの問題が検知された」とのお問い合わせを頂くことがあります。もし、ご利用のクラスタ環境でこのような現象が発生した場合、まずは切り分けとして Scalable Networking Pack の無効化について、是非検討してみてください。
Scalable Networking Pack についての詳細は以下の記事をご覧ください。
予期せぬ挙動が!? 新機能 Scalable Networking Pack をご存知ですか? http://blogs.technet.com/b/jpntsblog/archive/2010/03/23/scalable-networking-pack.aspx
Scalable Networking Pack を有効にしている場合、ノード間の相互接続に様々な問題が発生することがあります。もし、ネットワーク経路に問題が見つからないにも関わらず、ネットワークの状態が安定しない場合には、Windows のネットワークの視点から Scalable Networking Pack の無効化をお試しください。
こんにちは。Windows テクノロジー サポートの高橋です。
今回は Windows Vista 以降の OS (Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2) で Sysprep を実行した際にドメインへ自動参加させるための方法について紹介したいと思います。
Windows AIK をご利用の方であれば、応答ファイルの Microsoft-Windows-UnattendJoin コンポーネントを使用してドメインへの参加が自動化できることをご存知かも知れません。ただし、このコンポーネントは specialize パスで処理されるため、ミニ セットアップ中 (oobeSystem パス) に入力したコンピューター名ではなく、セットアップ中に一時的に割り当てられたコンピューター名でドメインへの参加が行われてしまいます。
注: Windows Server 2008 R2 では、ミニ セットアップ中にコンピューター名を入力するように構成することはできません。このため、Windows Server 2008 R2 については応答ファイルの Microsoft-Windows-UnattendJoin コンポーネントを使用してドメインへ参加させても、上述の問題は発生しません。ユーザー指定の任意のコンピューター名を設定するには、セットアップ完了後にコンピューター名を変更する必要があります。
従いまして、Microsoft-Windows-Shell-Setup コンポーネントの ComputerName プロパティで明示的にコンピューター名を指定するか、または '*' を指定して自動生成されたコンピューター名を使用する場合以外、応答ファイルによるドメインへの参加は期待通り動作しません。言い換えますと、ミニ セットアップ中に入力したコンピューター名が反映された形でドメイン参加を行う場合、応答ファイルの Microsoft-Windows-UnattendJoin コンポーネントを使用することはできません。
上記につきましては、以下のサポート技術情報に記載させていた だいている通り、想定された動作であり、 Microsoft-Windows-UnattendJoin コンポーネントの制限事項となります。
回避策としては、上記サポート技術情報に記載されている通り、Microsoft-Windows-Shell-Setup コンポーネントの FirstLogonCommands を構成し、コンピューターをドメインに参加させるスクリプトを実行させる、という方法が一つの方法となります。ただし、運用上 FirstLogonCommands が使用できない (セットアップ完了後、管理者権限を持ったアカウントでログオンを行う事が保証されない) 場合や、ユーザー側に処理を見せたくない場合もあると思います。そこで、ここでは SetupComplete.cmd を利用した方法を紹介したいと思います。
SetupComplete.cmd の利用方法そのものにつきましては、以前安達が公開させていただいた以下のポストをご参照下さい。
ドメインへの参加自体は、KB944353 同様 Win32_ComputerSystem WMI クラスの JoinDomainOrWorkgroup メソッドを利用しますが、ここではバッチ ファイルから直接呼び出すため、wmic.exe コマンドライン ユーティリティを使用します。 wmic.exe を使用して JoinDomainOrWorkgroup メソッドを呼び出すための書式は以下の通りです。
ここで、<ドメイン名> は参加させたいドメイン名、<ユーザー名> および <パスワード> はドメイン参加の際に使用する認証情報、 <OU> は所属させたい OU 名 (省略可能)、<オプション> はドメイン参加時のオプション (省略時は 1) です。 JoinDomainOrWorkgroup メソッドの詳細につきましては、JoinDomainOrWorkgroup Method of the Win32_ComputerSystem Class をご参照下さい。
以下は、TestDomain.local.com ドメインの TestOU OU へ参加させる場合のサンプルです。
※ AccountOU パラメータで OU を指定する場合、Distinguished Name の区切り文字に ',' (カンマ) ではなく ';' (セミコロン) を使用してください。カンマを使用すると wmic.exe がコマンド パラメータの区切り文字として認識してしまうため、コマンドが期待通り動作しません (2014/2/26 修正)。
なお、上記内容の SetupComplete.cmd ファイルをそのまま残すと、ドメイン参加に使用したアカウント情報が他のユーザーから参照できてしまいます。SetupComplete.cmd 実行完了時に同ファイルを削除するようにするには、 SetupComplete.cmd の最後に以下の一行を入れます。
以上、Sysprep を使用して OS を展開する際の参考にしていただければ幸いです。
今回は Windows Vista 以降の OS (Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2) で Sysprep を実行した際にビルトイン Administrator のアカウント名を変更する方法について紹介したいと思います。
Windows では [アカウント: Administrator アカウント名の変更] ポリシーを構成することでローカル ビルトイン Administrator のアカウント名を変更することができます。ただし、この設定は Sysprep を実行すると失われてしまい、ビルトイン Administrator のアカウント名は既定の Administrator へ戻ってしまいます。
このため、ビルトイン Administrator のアカウント名を変更した状態で運用するには、 Sysprep 実行後に再度アカウント名を変更する必要があります。今回は、これを SetupComplete.cmd を利用して自動化する方法について紹介します。
アカウント名の変更は、Win32_UserAccount WMI クラスの Rename メソッドを利用しますが、ここではバッチ ファイルから直接呼び出すため、wmic.exe コマンドライン ユーティリティを使用します。 wmic.exe を使用してローカル ビルトイン Administrator のアカウント名を変更する場合の書式は以下の通りです。
ここで、<名前> は新しいアカウント名です。 Rename メソッドの詳細につきましては、Rename Method of the Win32_UserAccount Class をご参照下さい。
以下は、"Admin" へアカウント名を変更する場合のサンプルです。
なお、Windows Vista および Windows 7 では Sysprep の実行に伴い、ビルトイン Administrator アカウントが無効化されてしまいます。Sysprep 実行後に再度ビルトイン Administrator アカウントを有効化するには、以下のコマンドを実行します。
もちろん、このコマンドも SetupComplete.cmd に記述することができます。前述のアカウント名変更と実行は前後して構いませんが、もしアカウント名変更後にアカウントを有効化する場合は、上記コマンド内の "Administrator" を変更後のアカウント名に変更する必要がある点にご注意下さい。
今回はユーザーのキー入力なしに CD/DVD から起動するする方法について紹介したいと思います。
Windows Vista 以降の OS (Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2) のインストール CD/DVD、または Windows AIK 等で作成した Windows PE 起動 CD/DVD から起動しようとする際、以下のようなメッセージが表示されます (有効なディスク パーティションが無い場合等、表示されない場合もあります)。
このキー入力要求は意図しない CD/DVD からの起動を防ぐには有効ですが、場合によってはこのメッセージを出さずに CD/DVD から起動したい場合があります。
これを実現するには、CD/DVD に含まれている \boot\bootfix.bin ファイルを削除した上で、改めて ISO イメージを作成し、CD/DVD に書き込みを行います。
Windows AIK に含まれる CopyPE.cmd でフォルダ階層を作成している場合には、 ISO\boot\bootfix.bin ファイルを削除した上で oscdimg.exe を実行して ISO ファイルを作成します。
OS のインストール CD/DVD を変更する際には、一旦 CD/DVD の内容を HDD 等にコピーし、 boot\bootfix.bin を削除した上で oscdimg.exe 等を使用して ISO ファイルを作成し、CD/DVD に書き込みを行います。
CD/DVD を使用して多数のコンピューターを一度にセットアップしたい時等、こちらの方法をご参照いただければ幸いです。
今回は oscdimg.exe を使用して 4.5 GB 超の ISO ファイルを作成する際の注意点についてお伝えしたいと思います。
Windows AIK に付属する oscdimg.exe を使用して、ISO ファイルを作成することができます。作成される ISO ファイルは既定で CDFS が使用されますが、規格上 CDFS は 4.5 GB までのメディア サイズしか想定されていません。このため、oscdimg.exe を使用して 4.5 GB 超の ISO ファイルを作成した場合、一見正常に作成されたように見えますが、実際にメディアに書き込むと、一部のファイルが破損した状態になります。
このため、oscdimg.exe を使用して 4.5 GB 超の ISO ファイルを作成する場合には、明示的に UDF ファイル システムを使用するように指定する必要があります。具体的には、-u1 または -u2、および必要に応じて-udfverxxx オプションを指定します。各オプションの意味は以下の通りです (詳細は oscdimg -help UDF コマンドを実行してオンライン ヘルプをご参照下さい)。
また、起動可能な 4.5 GB 超の ISO ファイルを作成する場合 (-b オプションを指定する場合)、起動に必要なブート ファイル群がイメージの先頭に配置されるよう、明示的に指定する必要があります。具体的には、ブート ファイル群を記述したテキスト ファイルを -yo オプションで指定します。
上記を満たすコマンド実行例は以下の通りです。
bootorder.txt は、boot フォルダ配下のファイルおよび sources\boot.wim ファイルへのパスを 1 行 1 ファイルとして記載します。以下は日本語環境の場合の例です。
以上、4.5 GB を超えるサイズの ISO ファイルを作成される際にご留意いただければ幸いです。