この前、しらべようとしたときに、ちょっと止まったのでメモしておく。
■メモ
・各機能レベルで有効になる機能に関する付録
http://technet.microsoft.com/ja-jp/library/cc771132%28v=ws.10%29.aspx
・Windows 2000 混在モードは、Windows Server 2003 R2まで。
Windows Server 2008 からは、Windows 2000 ネイティブ。
Windows 2000 Server の起動した時間を調べるには、
イベントビューアを開いて、システムのログから、
イベントが開始された日時を調べる。
（Windows 2000 には、systeminfoコマンドがないので。）
今時・・・Windows 2000 とは思うが、
あっちこっちに残っているから忘れないように。
早くなくなるといいな。
2014年12月のWindows Update でInternet Explorer 11の
JavaScriptの解釈というか挙動が変わっている。
自分がハマったのは、子画面で選択した値を親画面の特定の場所入れる
という挙動で、あたい戻しができなくなった。
子画面側で値を選択した時に、親画面の別の場所にフォーカスが
当たっており、値が表示されない。
（そんな挙動が悪いといえば、そうなのだが・・・）
問題の発生時点を切り分けて行くと、2014年12月のWindows Update
を適用したかどうかで、挙動が変わっていた。
このUpdateに含まれていたIEのUpdateプログラムをアンインストールで、
もとの挙動に戻ることも確認できた。
なので、今回のUpdateが悪さをしていることは間違いなし。
IEのバージョンが変わるタイミングで、JavaScriptの挙動やCSS解釈が
変わるというのは割と良くある話だが、、、
月例のUpdate変わられてしまうと、なかなか打つ手がない。
ちなみに、影響を受けたのは、IE11のみ。
Windows 7、Windows 8の両方のIE11で発生する。
IE10の場合は、Windows Updateを行っても動作は変わらなかった。
IEのバージョンをみると、
11.0.15 ・・・ このバージョンがアウト。障害にあたる。
11.0.14 ・・・ このバージョンはセーフ（Windows Update前）。
だった。
忘れそうなので、メモとして。
Windows Server 2008 R2環境で、Powershellをリモート実行している。この環境で、稀にPowershellがリターンコード“-65536”を返して、異常終了する。
状況としては、リモート実行先のPowershellでスクリプトが動作しその動作で落ちるのではなく、そもそもリモート先でPowershellのスクリプトが実行されていない状態。呼び出し（起動）に失敗したときに、コード“-65536”が返されている。
Powershellのコード“-65536”は、リモート実行先でPowershellの起動に失敗した際に返されるエラーコード。
もし、必ずこのコードが返ってくる場合は、Windowsサーバで、Powershellのリモート実行が許可されていない可能性がある。また、64bit環境の場合は、32bitと64bitの両方にPowershellが入っていて、起動するPowershellのパスが間違っているなど。64bit実行なのに、32bitのPowershellが呼び出されているなど。
Windows のディスク管理は、Windows標準のディスクマネジャーだけと思いがちだが、
別のツールに変更されていることがある。
たとえば、Veritas Storage Foundationがインストールされている場合、
Windows標準のディスクマネジャー（ディスク管理ツール）は使えない。
「コンピューターの管理」から「記憶域」「ディスクの管理」を見ると、Veritasの表示がある。
標準ツールではないので、便利な部分もあるが、扱いにくい部分（癖）もある。
一長一短だが、現場では、設定されているツールを使うだけ。
実際にディスクの管理を行おうとした時に、標準ツール以外の可能性があるので、注意。
NTFS上で扱えるファイル数が最大でどのくらいなのかが気になって調べてみた。
１つのNTFSのボリュームで扱えるのは、4,294,967,295個（2^32-1個）のファイル。
ざくっと42億個のファイル。
ちなみに、1ファイルの最大サイズは、16TB-64KB。
| １つのボリュームの最大ファイル数 | 4,294,967,295個 |
| 1つの最大サイズ | 16TB-64KB |
http://technet.microsoft.com/ja-jp/library/cc766145%28v=ws.10%29.aspx
HPの便利なサーバツールのiLO。
電源のON/OFFやハードウェアの状態などの確認やコンソールの確認もできるので重宝するツールだ。
設定したiLOには、ブラウザを使ってアクセスするのだが、
企業の中には運用端末経由じゃないとアクセスできないようにネットワーク設計されていたり、
ルールとして縛られていたりする。
その運用端末がWindowsでログインするユーザが一般ユーザの権限しかない場合、
iLOの画面はIEからアクセスできて表示できるが、ログインIDとパスワードを入れて、
OKをクリックしても、次の画面に進まないことがある。
iLOの画面を開くときに、スクリプトの実行が云々という警告がでるので、
インターネットオプションから信頼済みサイトに登録して、
スクリプトを実行できるようにする（している）。
それでも、ログインできない時の話。
その場合は、ログインをしているユーザの権限を疑う。
リモートデスクトップなどで、運用をするためのユーザを使っている場合、
ポリシーとして弱い権限しか割り当てていないことがある。
（会社によると思うが・・・）
その場合、画面の見た目上は、スクリプトが動くように錯覚するが、
実際はWindowsによりスクリプトの実行が禁止されており動いていない。
切り分けとして、WindowsのAdministratorやAdministrator権限をもったユーザを使い、
iLOにアクセスして、ログインを試す。
Administrator権限を持ったユーザの環境からアクセスしログインできれば、
使用していたユーザの権限が足りないということ。
試した環境は、Windows Server 2008以降、iLO3、iLO4。
Windowsは、管理用としてCドライブがデフォルトで共有されており、
アクセス方法を知っていれば、管理者ユーザあれば直接Cドライブを参照できる。
アクセス方法は以下。
\\ホスト名（コンピュータ名）\c$
これで、指定したホストのCドライブにアクセスできる。
アクセスする際には、管理者ユーザのIDとPWが必要。
いっつも、cと$の順番とかを忘れるので。
ちなみに、このCドライブの共有は「管理共有」や「デフォルト共有」と呼び、
共有フォルダは「管理共有フォルダ」と呼ぶ。
共有設定を切ってもOKだが、管理ツールを使っている場合は、
この管理共有フォルダを使っているので不具合がでる。
Windows にNICが2つ（ネットワークが2つ）あり、別々のネットワークにつながっているとき、特定の宛先（通信先）だけ、特定のネットワークから通信を行い時がある。
通信は、基本的にデフォルトゲートから外部に出ていくようになっている。同じセグメントの通信でなければ、ルーティング（経路制御）を行う必要がある。その時に、Windowsに設定するスタティックルートを追加する方法。
■現在の経路情報を表示する
コマンドプロンプトで以下のコマンドを実行する
ROUTE PRINT
固定ルートがある場合は、“ROUTE PRINT”の固定ルートに経路情報の記載がある。
C:\>ROUTE PRINT
===========================================================================
インターフェイス一覧
12...b8 6b 23 b2 d2 1c ......Intel(R) 82579V Gigabit Network Connection
11...48 d2 24 c2 19 25 ......Atheros AR946x Wireless Network Adapter
1...........................Software Loopback Interface 1
18...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
19...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
15...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
46...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #3
===========================================================================
IPv4 ルート テーブル
===========================================================================
アクティブ ルート:
ネットワーク宛先 ネットマスク ゲートウェイ インターフェイ
ス メトリック
0.0.0.0 0.0.0.0 192.168.43.1 192.168.43.127 25
127.0.0.0 255.0.0.0 リンク上 127.0.0.1 306
127.0.0.1 255.255.255.255 リンク上 127.0.0.1 306
127.255.255.255 255.255.255.255 リンク上 127.0.0.1 306
192.168.43.0 255.255.255.0 リンク上 192.168.43.127 281
～～～省略～～～
===========================================================================
固定ルート:
なし
～～～省略～～～
■ルーティング情報を追加する（経路情報を追加する）
経路情報は、以下のコマンドで追加する
route add -p [宛先のネットワーク] mask [サブネットマスク] [ゲートウェイアドレス] metric [優先順位]
経路追加は、route add コマンドで追加できる。”-p”オプションを付けることで、Windows再起動後も有効な静的なルートを追加できる。（-pを付けない場合は、再起動すると経路情報が消える、route print時にも表示されない）
例：デフォルトゲートを別のネットワークが持っている場合に192.168.100.0/24 宛の通信を、192.168.43.1のゲートウェイに送りたい場合
route add -p 192.168.100.0 mask 255.255.255.0 192.168.43.1 metric 1
■ルーティング情報を削除する（経路情報を削除する）
route delete -p [宛先のネットワーク] mask [サブネットマスク] [ゲートウェイアドレス] metric [優先順位]
経路削除は、route delete コマンドで削除できる。
例：上で設定した経路情報を削除する
route delete -p 192.168.100.0 mask 255.255.255.0 192.168.43.1 metric 1
Windowsもコマンドを使えば、いろいろとできる。情報が少なくて、一見するとかゆいところに手が届きにくいけど。
VMware ESX上のWindows仮想マシンをコピー（複製）して、新しくWindows仮想マシンを作成したところ、NICの1つが正常に動作していないという現象が発生した。
具体的には、仮想マシンのWindowsに2つのNICを設定しており、デフォルトゲートに指定されているネットワークは正しく動作していたが、もう１つのネットワークは自分以外との通信ができない状態で、外部からの応答もしない状態だった。
この状態で、NICの問題と気が付くまでに時間がかかった。と、いうのも、デフォルトゲートを指定できないネットワークだったので、Windowsのルーティングの問題なのか、そもそもVMware ESX側のネットワークの問題だったのかの切り分けが大変だった。かつ閉鎖的なネットワークだったので、ネットワーク内の確認がめんどくさかった。
ルーティングの問題かどうかは、同一セグメントの機器に対しても、PINGの応答がなかったので、ルーティングでは無さそうという区切りをつけられた。問題を簡潔にするため、静的なルートはすべて削除もした。
次に、一応、Windows Firewallの設定を見直して、Firewallの機能をオフにしたり、明示的に穴をあけて試したが、応答なし。
次に、ネットワーク機器の設定にVLANの確認をしていった結果、正常（予定委していた通り）であることを確認した。
これで、残るはWindows自体なので、念のためSYSPREPをかけ、ネットワークの再設定をしたが状況は変わらなかった。ここまで来ると、該当のNICが腐っている（壊れている）としか思えない。なので、VMware ESX上で、新しくネットワークを１つ追加した。Windows上で、使えていないNICは設定を消して無効化して、新しく追加したNICに設定を行った。新しく追加したNICでは、ちゃんとネットワークの通信ができた。
状況から考えると、元の仮想マシンからコピーした際にNIC情報が壊れたのではないか、もしくはWindows内部で何かおかしくなったのではないか、ということ。
仮想マシンをコピーして、ネットワークがうまく動作していないときには、新しく作りなおす（追加しなおす）のがよい。