前回までは、Microsoftネットワークを構成する個々の要素に付いて解説を行なってきたが、今回はそれらの応用として、トラヒックのチューニングを取り上げてみた。特にダイヤルアップ環境で問題となる不要なパケットによる発呼を抑止するためのポイントについて、今までの復習も兼ねて解説を行なっていきたい。なお復習という位置づけ上過去のセミナーと重複する記述が出て来てしまうがご了承頂きたい。
Microsoftネットワークは、ダイヤルアップのような間欠的な接続を、そもそも考慮していない。ここまでのセミナで述べたように、デフォルトでは、利用者が何の操作も行なっていなくても十数分毎に何らかのパケットが飛び交っている。 このままでは、ISDN環境のようなダイヤルアップ環境では、コストがかさんでしまい到底利用できないので、チューニングが必須である(注1)。
今回は、こうしたダイヤルアップ環境を念頭に置き、トラヒック回数の制御を中心にトラヒック量の制御や関連するノウハウの紹介などを行なっていきたい。 実際Microsoftネットワークでは何もしていなくてもデフォルトではかなりの量の通信が行なわれている。図1はMicrosoftが自社ネットワークのトラヒックを調査したとされる資料である。
ブラウザ: 51% 12分間隔で4つのサーバー通知(注2)を送信 BDC3台、12分間隔でブラウズリストを交換 ディレクトリサービス: %31% 1時間2件の変更で39,400バイト、BDC3台 WINS複製: 8% 1時間に3レコード変更して32,400バイト 信頼関係: 5% 1日7回セッションを確立 ディレクトリ複製サービス: 4% 1日に2ファイル変更で26,000バイト DNS: 1% 1時間に1回、6レコードのゾーン転送
注2: これはLocal Master Announcementのことである。
これは、BDCが3台のネットワークにおけるトラヒック量を測定したものとされている。無論この割合が全てのケースで当てはまるわけではないが、参考にはなるだろう。以下この図に現れる各要素を中心に考察を進めていく。
WANトラヒックのチューニングを行なう上で、ブラウジング機能の設定は必須である。 セミナ第2回で解説したように、複数セグメントにわたるブラウズリストの統合を行なう際には、DMBとLMB(注3)との間でデフォルト12分間隔の定期的な通信が行なわれる。 この間隔はMasterPeriodicity(注4)というレジストリの値を修正することで変更できるため、直接的には各LMBでこの値を修正すればよい。接続はLMB側から行なうため、DMBでの修正は不要である。
注3: DMB - Domain Master Browser、LMB - Local Master Browserの略。詳細な説明についてはセミナ第4回を参照のこと。
なお当然であるが、ブラウズリストの更新間隔を延ばせば、マシンの起動、停止にともなうブラウズリストの変更が別セグメントに反映される際のタイムラグが大きくなることになる。このため、いわゆる「見えるけどアクセスできない、見えないがアクセスできる」という現象が定常的に発生することには留意しておく必要がある。
LMBのレジストリを修正するにはLMBマシンを特定する必要がある。しかし、セミナ第3、4回でも述べたようにデフォルトではLMBとなりうるマシンが不定(注5)のため、クライアントマシンも含めた全てのポテンシャルブラウザ(注6)のマシンのレジストリを修正する必要がある。
注5: もちろん全くランダムではない。詳細はセミナ第3回のブラウザ選定に関する記述を参照されたい。
注6: ポテンシャルブラウザに付いてはセミナ第3回の説明を参照のこと。
既にネットワーク全体でシステムポリシーを利用しており、Windows 9xマシン(注7)も含めた全てのマシンのレジストリを一括書き換え可能な場合は、これも不可能ではないが、大半の場合レジストリの一括書き換えは困難であろう。
注7: Windows 9xマシンとはWindows 95、Windows 98、Windows Meマシンの総称として用いている。
従って、筆者は現実的な対策としてLMBとなるマシンを何台かのマシンに固定してしまうことを推奨したい。
LMBを固定することで、LMB変更時に発生するブラウズリストへの登録依頼等の無駄なパケットが低減される他、設定が正しく行なわれているマシンをLMBとして常時稼働させることで、予期しないマシンがLMBとなることで発生するブラウズリスト関連のトラブルを未然に防止することもできる。
表xx1の通り、BDCが存在するセグメントに付いてはブラウザ選定の仕様上BDC起動時にブラウザ選定が行なわれてBDCが勝利する為(注8)、特に手を加える必要はない。注意すべきはドメインコントローラ(注9)以外のWindows NT/2000 Server(注9)は Windows NT Workstation/Windows 2000 Professional(注9)と基本的に同じ優先度であることだ。この為、単純に各セグメントにWindows NT/2000 Serverを配置しただけではLMBは固定できない。
注8: ドメインコントローラがブラウザ選定を強制的に行なって勝利するための仕組みについては、セミナ第3回を参照のこと。
| ドメインコントローラ | 0x20 = 32 |
| その他のWindows NT | 0x10 = 16 |
| Windows 9x/WfWg(注10) | 0x1 = 1 |
| Samba | 0〜255(注11) |
注10: Windows for WorkgroupsというWindows 3.11にネットワーク機能を付加した製品の略称。日本語版は発売されなかった。
注11: os levelというパラメータで任意に設定が可能。Samba 2.0.6以降のデフォルト値は20、それ以前のデフォルト値は1である。
第2回で述べたように、LMBにしたいマシンのIsDomainMaster(注12)を設定することにより優先度を向上させるとともに、マシン起動時にブラウザ選定を強制することにより、LMBがそのマシンになることを保証する必要がある。
問題なのは、クライアントマシンしか存在しないセグメントだ。クライアントマシンは利用者の不在時などは電源が切られていることが想定されるため、LMBの固定が事実上不可能である。ブラウジング的な観点からはどれか1台のマシンを「LMBサーバ」として24時間運転することを推奨する。もちろんLMBになれなければ意味がないので、Windows NTが存在するセグメントでは、いずれかのWindows NTマシンのレジストリを修正してこの役に就ける必要がある(注13)。
注13: 表xx1の通り、Windows NTマシンは常にブラウザ選定基準がWindows 9xより高いためである。
LMBの固定を行なう別の方法として、不要なポテンシャルブラウザのマシンを非ブラウザにしてしまう方法もある。
デフォルトではWindows NT WorkstationやMicrosoftネットワーク共有サービスをインストールしたWindows 9xマシン等、ファイルサーバ機能を持つ全てのマシンはクライアントマシンとして利用していてもポテンシャルブラウザとして構成される。
サーバ機能を停止することも可能であるが(注14)、特にWindows NTマシンでは停止した場合の弊害も大きいため(注15)、一概に推奨できるものではない。
注14: Windows NTではServerサービスを停止させる。Windows 9xでは「Microsoftネットワーク共有サービス」をアンインストールする。
注15: そのWindows NTマシンをリモートから管理する為の機能の大半が利用できなくなる。
通常はサーバ機能を維持したまま非ブラウザとして機能させる方式が推奨される。Windows NTマシンではMaintainServerList(注16)をNoにする。
Windows 9xマシンでは「Microsoftネットワーク共有サービス」のプロパティにある「ブラウズマスタ」を「無効」にすればよい(注17)。
なお、セミナ第3回で述べたように、Windows NTマシンではNET CONFIG SERVER /HIDDEN:YESで「ネットワークコンピュータ」上への表示を抑止できる。ただし、この場合ブラウザとしての能力自体は通常の場合と変らないので注意して欲しい。
最後の手としてブラウジング機能を使わない運用も考えられる。
Windows NTマシンの場合はComputer Browserサービスを停止させることでサーバ機能は有効なままブラウジング機能を無効にできる。Windows 9xマシンについては、基本的にはMicrosoftネットワーク共有サービスをアンインストールする必要があるが、前述したブラウズマスタの設定を無効にしておくことでも、マスタブラウザとなるマシンが存在しなければ無効にしたのと同じ結果になる。
ファイルサーバにアクセスしたり、NTドメインにログオンしたりする上で、ブラウジングは必須機能ではないので、一般の利用者にとってはネットワークコンピュータの機能が利用できなくなる他は目立った不具合はない(注18)。
注18: 管理ツールなどでも接続先のコンピュータを一覧から選択することが出来なくなり、直接コンピュータ名を入力する必要が発生する。
一般の利用者がアクセスする必要があるサーバマシンや共有フォルダは通常数箇所であろう。この程度であれば、
ブラウジングについで名前解決関連のトラヒックについて見ていこう。図2にセミナ第2回で説明した名前解決順に付いて再掲する。以下この図を適宜参照してほしい。
まず、問題にしたいのはDNSへの問い合わせである。NetBIOS名の名前解決にDNSを利用する設定の場合、間違って名前を入力ミスすると、DNSへの問い合わせが発生してしまい、多くの場合WAN越しのトラヒックが発生してしまう(注20)。
注20: DNSではインターネット上の名前解決を可能とするためにフォワーダ機能などを用いて自サーバで解決できなかった名前を別のDNSサーバに問い合わせる設定を行なう運用が多い。
そもそもDNSでは一部のNetBIOS名しか解決できないため、DNSが有効になっていてもMicrosoft/ネットワークの機能は維持できない上に、名前解決のトラブルシューティングが複雑になる点も無視できない。従って、筆者としては特別な理由がない限りNetBIOS名の解決にDNSを利用することはやめ、DNSへの問い合わせも無効にすることを強く推奨する。これには連載第2回で述べたように設定を修正すれば良い(注21)。
注21: Q137368: How to Disable NetBIOS Name Resolution on DNS を参照のこと
なお、この設定を行なうとhostsファイルによるNetBIOS名の解決機能も同時に無効になる。hostsによる解決もDNSと同様の理由で混乱を避ける意味で無効になることがむしろ好ましいといえる。
セミナ第2回ではB,P,M,Hというノードタイプについて言及した。通常はWINSクライアントであればHノード、それ以外はBノードとなる。Bノードは名前解決にブロードキャスト、HノードはWINSサーバに問い合わせて解決できなければブロードキャストという方式だ。一般的にはWINSサーバへの問い合わせが推奨されるが、必ずしも常にそうだとは限らない。
図3のような環境で、CL1が同一セグメントのCL2の名前解決を行なおうとしている場合を考えてみよう。なおLMHOSTSファイルは設定しておらず、直前にCL2に対する通信は行なっていないとする(注22)。Hノードの場合はWINSサーバWINSSRVへの問い合わせが発生する。もしWINSサーバがWAN越しの場合はこの度にWANトラヒックが発生してしまう。しかしマシンをMノードとして構成していた場合は、先にブロードキャストで名前解決を行なうため、こうしたケースでセグメント外へのトラヒックを抑止することが可能である。
注22: 直前に通信が行なわれていた場合にはNetBIOSネーム・キャッシュ中のデータが用いられる。
このようにNetBIOSを用いた通信のほとんどが同一セグメント内に閉じている環境では、Mノードの利用を検討してみるとよいだろう。ノードタイプの変更は NodeType というレジストリ(注23)で行なう。なおDHCPクライアントの場合はDHCPサーバで設定する。
ただし、Mノードを用いてもユーザーがタイプミスを行なっただけでWINSへの問い合わせが発生してしまうので、ダイヤルアップ環境などで発呼を可能な限り押えたい場合は、やはりBノードに設定した上でLMHOSTSファイルに頼らざるをえないだろう。
ところで、基本的に各マシンに対して配布する必要があるLMHOSTSファイルであるが、#INCLUDEという構文を利用することで、別のマシン上のLMHOSTSを取り込むことが可能になるため、図4のようにLMHOSTS配布サーバ上のファイルを更新するだけで各クライアント上の名前解決の設定を更新することも可能ではある。無論LMHOSTSファイルサーバとの間にはトラヒックが発生するため、参照するLMHOSTSサーバはWAN越しにならないようにする必要があろう。
LMHOSTS配布サーバ
Client [LMHOSTS ]
[LMHOSTS ]
#INCLUDE
Client
[LMHOSTS ]
#INCLUDE
Client
[LMHOSTS ]
#INCLUDE
しかし、この機能を利用する際はLMHOSTS配布サーバ側に特殊な設定が必要である。まずは Q121281: LMHOSTS #Include Directives Requires Null Session Support を参照して頂きたいが、誰もログオンしていない時点でリモートマシンのLMHOSTSを取得するためにNULLセッションが用いられるため、NULLセッションで接続が可能なように、LMHOSTS配布サーバ側の設定を修正しないといけない。更に、Q233193: LMHOSTS File Referenced in #INCLUDE Is Not Parsed at Startup by Windows 95/98 Clientsの記述に従い、NULLセッションでの接続でもアクセスできるように、LMHOSTSファイルは誰でも読みとり可能にしておく必要がある。
図5はWindows NT 4.0 SP3のWINSクライアント上でNET VIEW \\1.3.5.7890123456というコマンドを発行したときのキャプチャである。見ての通り、フレーム1〜5で「JSPNRMPTGSBSSDIR」という意味不明な文字列の名前解決を行なおうとしているのが分かる。この現象は16文字以上の文字列をNetBIOS名として解決させようとした際に発生することがある(注24)。しかし筆者も様々な名前解決で試みたものの、確実に再現させる方法を見付けることが出来ていない。
注24: 関連する技術情報として「J040908: [NT]RASサービスが2秒ごとに Name Query をブロードキャスト」がある。
契機は良く分からないがこの文字列の名前解決を行なおうとしていることをよく見掛ける。契機が不明なため場あたり的な対応ではあるが、LMHOSTSなどにダミーのエントリを作成しておくことで、問い合わせは抑止できる。例えば図6: のようなエントリをLMHOSTS中に記述しておくことで、この不可解な名前解決のトラヒックを実質的に抑止できる。
WINSサーバ同士の複製は、もともとWAN環境を想定した仕様になっているため、設定も容易である。WINSマネージャを用いて[オプション] -[設定] から「パートナー」を選択することで、図7のダイアログが表示されるので、ここで複製の間隔を設定すれば良い(。もちろん各複製パートナー毎に同様の設定を個別に行うこともできる(注25)。
注25: 複製パートナー毎の設定は、[複製パートナー]の画面から行なう。
一見して分かる通り複製のタイミングを固定できるのはプル複製のみである。プッシュ複製では、一定数の更新情報が発生した時点が複製トリガとなるため、複製のタイミング自体は制御できない。
従ってプッシュパートナーに付いては大規模なWINSデータベースの改変が行なわれた際の緊急複製ととらえ、通常プル複製の周期内では発生しないような規模の値を設定しておくか、そもそもプルパートナーの設定だけしか行なわないのがよいであろう。
プルパートナーだけの設定でも複製自体は行なわれる。また緊急時には手作業でプッシュ複製を行なうことも可能なため、実用上特に支障はない。
次に認証時に発生するパケットに付いて、トラヒック削減の方策を紹介しよう。
PDCとBDC間の認証データベース(SAM)の同期はドメインを維持していく上で必須の作業であるため、停止することは不可能であるが、工夫することでトラヒックの発生回数は制御できる。SAMの同期に関しては多数のパラメータがあり非常に複雑である。
まず、考慮するのは変更ログのサイズである。
変更ログは前回解説したように、PDCの持つSAM(注27)に対する更新履歴を保存しておくものである。このファイルがいっぱいになると古い履歴から順に上書きされていく。
BDCが同期要求を行なった際に、必要な更新情報が変更ログから既に消去されていた場合は通常の部分同期と呼ばれる差分更新ではなく、PDCのSAMの全内容が複製される完全同期が行なわれることになる。どのような同期が行なわれているかはドメインコントローラのイベントログを確認することで分かる。図10のようなID5717が出力されていた場合は完全同期が行なわれている。
完全同期は差分転送だけを行なう部分転送とは比較にならない程のトラヒック(通常各BDC毎に数MB〜十数MB)を必要とするため、可能な限り避けるべきである。その為にはレジストリ ChangeLogSize(注27)の値を大きくして変更ログのサイズを大きくすれば良い。サイズが大きくなると差分同期を必要となる回数も減少するので一石二鳥である。デフォルト値は64KBだが、1MB程度にしておいた方がよいであろう。
PDCはPulseというレジストリの間隔毎に自分のSAMを調査し、BDCに同期を行なう必要ありと判断するとPulseConcurrencyで設定された台数のBDCに対して同期要求を送信する。この間隔はデフォルト5分で、台数は10台である。5分という間隔はBDCとの同期を可能な限り保つという目的には都合が良いが、頻繁にSAMの変更が行なわれるネットワークではPDCとBDCとの間に頻繁に同期の為の通信が行なわれ、間にISDN回線が存在するとその度に回線が接続されることになる。 この為、WAN経由の複製が発生する場合はせめて1時間程度まで間隔を広げておきたい所である。これはPDC上の Pulse(注28) というレジストリで行なう。最高48時間まで設定できるが、あまり大きくすると必要な変更ログが上書きされて完全同期が行なわれてしまい、却ってトラヒックが増加してしまう可能性がある。なお大規模なドメインには一度に同期を行なえるBDCの数はデフォルト10台であることも考慮する必要がある。もちろんこの値もPDC上でPulseConcurrency(注29)というレジストリの値を修正することで変更できるがマシンや回線の処理能力以上には増やしても意味がない。
また、間隔を長くした場合PDCとBDCの間の情報が一致していない期間が長くなることにも注意して欲しい。これはパスワードを更新したにも関わらず古いパスワードでなとログオン出来ない、新規作成アカウントの情報がBDCに反映されないため、PDCに認証がパススルーされてしまう等の形で表面化する。 なお、同期要求はPulseMaximum(注30)というレジストリで設定された間隔(デフォルト2時間)毎にBDC側からも行なわれる。Pulseの値を増加した場合、こちらの値もそれに合わせて増加させるべきであろう。Pulseによる同期が正常に動作していれば、BDCからの同期要求は不要であるため、この値は最大値の1日にしておけばよいであろう。
変更ログサイズを変更した場合は、タイムアウトの値にも注意を払う必要がある。BDCはPDCが同期要求を行なったときにPDCのPulseTimeout1というレジストリ(注31)の値(デフォルト10秒)以内に応答を行なう必要がある。またその後実際の転送が始まってからはPulseTimeout2というレジストリの値(注32)以内(デフォルト300秒)に転送を完了する必要がある。低速回線の環境で変更ログサイズを大きくしているときは、この値を大きくしておかないと、タイムアウトしてしまいSAMの同期が破綻してしまう。
なお一回あたりの同期要求の転送量を制御するReplicationGovernorというレジストリ(注33)も存在するが、筆者はこのパラメータを変更する必要を感じたことがない。
以上同期トラヒックの制御に関するレジストリに付いて一通り解説した。言い訳じみてしまうが、これらのパラメータの設定に単純な解はない。利用可能な回線容量、単位時間あたりのSAMの変更量、クライアントやBDCの台数等の値を元にシステム毎に決定する必要がある(注34)。
前回でのセミナでも記述した通り、コンピュータアカウントのパスワードはデフォルトで1週間毎に変更され、変更のタイミングでPDCに対する通信が発生する。1週間毎とはいえ、クライアント数が数千台に達するネットワークではこの通信量も無視できない頻度になる。 例えば、ドメインに700台のマシンが参加していた場合平均1日100台のマシンのパスワードが変更される。これだけで1時間あたり5回程度のパスワード変更が発生するため、最悪の場合、回線が切断されないという状態に陥ってしまう。 この変更を停止するためにはDisablePasswordChange(注35)を1に設定する。
また、Windows NT 4.0 SP4以降ではMaximumPasswordAgeというレジストリ(注36)を変更することで間隔を変更することも可能である。関連する技術情報として「J043619: [NT] ドメインでのコンピュータアカウントの複製による影響」を参照されたい。
この変更を停止したり間隔を大きくしたりすれば、当然セキュリティが低下する。とはいえ通常のサイトでは利用者のパスワードを1週間毎に変更しているところはまずないであろうし、コンピュータアカウントのパスワードの変更を停止しても、実際に不正を行なうにはかなり高度な技術が必要であり、通常より簡単な攻撃方法がある中で敢えてこの点を突いた攻撃は考えにくい。従って筆者としてはトラヒック上問題であればパスワードの変更は停止してしまって構わないと考える(注37)。
パススルー認証にも注意が必要である。第5回のセミナで説明したように、パススルー認証の場合認証要求を受け取ったサーバが、更にパススルー先の認証サーバに対して通信を行なうことになる。この場合直接的には何も行なっていないマシンが突然パケットを送出するように見えるため、こうした機構を知らないと原因の追求が非常に困難である。
このパケットはパススルー認証の度に発生するため、ネットワーク構成によってはISDN回線が不定期に頻繁に接続するという自体を引き起こす。対処策としては信頼関係をやめるかWAN越しにならない位置に信頼しているドメインのドメインコントローラを配置した上で、そのサーバに問い合わせが優先的に行なわれるように名前解決の方法を工夫するしかない。
いずれにしてもWAN越しのパススルー認証が発生する可能性のあるネットワークでは細心の注意が必要である。
ここまでのカテゴリーに入らないポイントについて解説する。なお本セミナーではOS以外のアプリケーションについては言及していないが当然利用するアプリケーション毎にトラヒックに関する考察が必要である。またいくらシステムレベルでのトラヒックの抑制を行なっても利用者が常時リモートのサーバにあるファイルにアクセスしていては何の意味もない。このためトラヒック抑止の為には、最終的には一般の利用者に対する教育と運用ルールの確立が省けない。
ISDNなどのダイヤルアップ環境で特に問題となるのがSMBセッションがクローズされるタイミングである。ユーザーやアプリケーションがリモートファイルを参照するなどして作成したSMBセッションは、明示的にクローズされることがなく、タイムアウトによりクローズされる。タイムアウトまでの時間はクライアント側がKeepConnというレジストリ(デフォルト10分)(注38)、サーバ側はxxというレジストリの値(注39)(デフォルトxx分)で制御されるため、結果としてデフォルトでは最後の通信が行なわれてから10分経過するとクライアント側から切断処理が行なわれる。例えばDMBとLMBとの間で12分毎に行なわれるブラウズリストの交換の場合、デフォルトでは図11のようなタイミングで通信が行なわれているはずである。
図11: 0分後 ブラウズリスト交換 10分後 SMB session logoff (KeepConnによるタイムアウト) 12分後 次のブラウズリスト交換 22分後 SMB session logoff (KeepConnによるタイムアウト) ...
この仕様のため、1,2分程度の無通信状態で回線を切断することが多いISDN環境ではSMBセッションのクローズ処理の為だけに再度回線の接続が行なわれてしまい、余分な回線料金がかかってしまう。回線の利用形態やダイヤルアップルータ側の設定とも関連するが、こうした環境ではKeepConnの値を20〜30程度にするとよいであろう。これにより同一呼内でSMBセッションのクローズ処理も行なうことができる。
なお、セッションはなるべくクライアント側から切断した方がよいので、KeepConnの値がAutoDisconnetの値よりも小さくなるように設定すること。
しかし、この方法でも各呼毎に数十秒は無意味な通信時間が発生してしまう。遠距離などでこの時間も短縮したい場合は、逆にKeepConnの値を非常に長くしてしまう運用も考えられる。
例えば、通常1日に1回業務で接続する場合、KeepConnを129600(1.5日)程度にすれば、接続がタイムアウトする前に再度SMBセッションを用いた通信が行なわれ、切断タイマがリセットされるため、結果としてSMBセッションのクローズ処理は行なわれない。
ただし、この方式を用いる場合Serverサービスに対して常時多数のSMBセッションが開かれた状態になる。パフォーマンス的にあまり問題はない筈であるが、1日、あるいは1週間に1回等のタイミングで全セッションを強制的に切断するなどの対応(注40)を行なった方がよい。
注40: NET SESSION /DISCONNECT /Y コマンドを AT コマンドなどで実行すれば良い。
なおドライブマッピングを行なった場合は、そもそもKeepConnの値は無関係であり手作業でマッピングを削除するまでログオフも行なわれない。そのため予め必要なリソースに対してドライブをマッピングしておくことで無駄なSMBセッションのパケットを抑止することも可能である。
Windows NT/2000 ServerにはライセンスサービスというCAL(注41)を管理するシステムが存在しておりデフォルトで有効になっている。
筆者はこれは無効にすることを強く主張するが、その最大の理由は「ライセンスを正しくカウントできない」ということに尽きる(注42)が、トラヒック上も無効にした方がよい。
注42: ライセンスサービスの技術的な問題点に付いては次号で解説する予定である。
ライセンス情報はPDCに集約され、ドメイン単位で管理されるため、このサービスを有効にしているとデフォルトで24時間毎にBDC、メンバーサーバからPDCに対してライセンス情報の同期のためトラヒックが発生する(注43)。
注43: 複数ドメインのライセンス情報を統合するため、PDCからエンタープライズサー バという役割のマシンに複製する設定をしていた場合、更にPDCとエンタープライズサーバ間の複製トラヒックも発生する。
なお、PDCと接続できない場合は15分毎に接続のリトライが行なわれてしまう為、注意が必要である。
ライセンスサービスを停止するには、各マシンのLicense Logging Serviceを停止すれば良い。なお蛇足だが、ライセンスサービスが動作していようといまいと必要なCALの数が変わることはない。CALは必要数をきちんと購入する必要がある。
知っていれば当り前であるが、認証が発生するタイミングとして忘れがちなものにscheduleサービスから起動されたジョブがリモートのマシンにアクセスする際に発生する認証がある。特に頻繁にジョブが起動する場合、そのたびに認証が発生するので注意して欲しい。
今回は内容がら多少取り留めなくなってしまったが、トラヒック削減に関して一通り筆者の知っている限りのノウハウを詰め込んでみた。
本セミナーもいよいよ次が最終回である。
最終回では、Firewallとの関係や、これまでの集大成としてWindows 2000の登場を踏まえた今後のMicrosoftネットワークの展望をはじめ、今まで記述する機会のなかった雑多なノウハウ、TIPSについて触れる予定である。
Microsoft ネットワークを主テーマとして扱った書籍については、OA系や開発系に比べると少ないものの、それなりに多くの書籍が出版されている。よくどの書籍を読めばよいかという質問を受けるので、筆者が参考にしているものを紹介しよう。
筆者は実際にMicrosoft のサポート業務をそれなりに長期間行ってきているが、Microsoft ネットワークに関してはこれ以外の書籍は殆んど利用していない。もちろん MSDN や TechNet 等の電子的な情報は活用している。リソースキットも英語版であれば MSDN 中に同梱されているので、とりあえず MSDN で検索を行い、英語のリソースキットの情報が見つかったら、対応する翻訳を探して読むようなことも行っている。
これらの書籍は入門書ではないので、内容を理解できるようになるまでにはある程度経験や知識の積み上げが必要であろう。しかし、Microsoft ネットワークのエキスパートを目指すのであれば、ここに挙げた書籍は内容を理解するまで熟読することを強く推奨する。
