ども。
8月が終わってしまいますね、担当ちゅんです。
本日の記事は長文です。申し訳ありません。
先日から手掛けている教育用PCのSSD化ですが、一般的なPCとは違うところに「授業支援ソフト」の導入というのがあります。先生用PCから生徒用PCを一斉に操作したりできるもので、これがないと授業ができません。このソフトは通常、PCの導入時に業者さんが設定してくれるもので私は一から展開したことがありませんでした。今回は全てを自営で行っているので再導入も自分でやらなければなりません。
ですが、やってみれば特に難しい設定はありませんでした。セットアップディスクから機能をインストールしていくだけで、あっさりとリモート操作が可能になりました。やればできるものです。
このソフトが動作するようになると、生徒用PCの設定作業の効率はグンと上がります。40台あるPCを全台同じように動かしながら、設定などを行っていきます。
全ての作業を終え、最終チェック。授業支援ソフトから生徒用PCを一斉にシャットダウンしてみます。見事、全てのPCの電源が切れました。次に一斉に起動してみます・・・が、これがうまく動きません。PCの電源をオフの状態からオンの状態にするにはPCの「Wake On LAN（WOL）」という機能を使うのですが、電源を切ったPCのNIC（LANケーブルの差込口）を見てみるとランプが消灯しており通電していないようです。これではいくら電源オンの信号（マジックパケット）を投げても電源など入りません。
ちなみに、BIOSの設定ではちゃんとWake On LAN関係の機能はEnabledにしてありましたし、ありがちなミスであるWindows10の「高速スタートアップ機能」は無効にしてありました。そうなると怪しいのはデバイスのネットワークアダプタ。デバイスマネージャからネットワークアダプタのプロパティを開き、詳細設定を確認してみます。しかし、いくら探してもWOLの設定らしきものは見当たりません。当たり前ですがドライバ自体はWindows10が標準で持っているものでちゃんと認識しています。
ここからが解決編です。実は、その「Windows10が標準で持っているドライバ」こそが大きな罠でした。このドライバ、普通に使えますし通信するだけならば何の問題もないのですが、WOLを使おうとした場合は設定ができない仕様です。
結局、Intelのサイトからドライバをダウンロードし、これを導入することでようやくWOLの設定が現れました。片っ端から「有効」にしてPCをシャットダウンしてみると、ちゃんとNICにランプが点灯し、WOLも動作するようになりました。気をつけなければならない点としては、Intelのサイトにあるドライバはバージョンによって対応しているアダプタが異なります。今回のケースでは最新版のドライバではインストールできず、少し前のバージョンに意図的に落とす必要がありました。
※ちなみに、標準ドライバのNICの設定の中にVLANが無い理由もこれと同じみたいです。
電源オフ時のハードウェアの動作って、私はてっきりBIOSがつかさどっているものとばかり思っていました。Windows上でドライバを入れ替えることでWOLの動作が変わるという点は驚きでした。古いパソコンをリビルドしてWindows10にするときにはドライバには気をつけましょう。
ドライバを入れ終わった後のNIC。ちゃんとランプが点灯していますね。
（投稿者：ちゅん）
とても参考になりました。
ありがとうございますm(_ _)m
自宅趣味環境で、新PCから旧PCをリモート操作できる環境のところ、旧PCをWOL対応にし、離れた場所に設置したいところでした。
スリープ状態からの復帰というところまでは素直に達成できたのですが、シャットダウンさせるとうまくいかない。
使用頻度、節電マインド上の都合から、スリープや休止は使いたくない思いもありました。
旧PCはIntel製のNICだったので、ちゅんさんと同様の事象が発生し、同様に最新ドライバの取得とインストールで解決できました。
また、＠ITmediaの記事から、OS起因な事情も合わせて知ったところです。
ちゅんさんの記事がなければ、自宅内をテクテクあるいて電源ボタンを押しに行く生活からは抜け出せなかったと思います。
ありがとうございました。
コメントいただきありがとうございます！
お役に立てたようでうれしいです！
WoL絡みの問題では、恥ずかしながらB社現役時代、某地方でPC教室用PCに多く導入されたNICとスイッチとケーブルの組み合わせで調査と対策効果確認に携わったことがあります。
この時は、オンボードNICがないPCにPCIの1000BASE-T NICを入れた構成（古い話なので、オンボードNICがない廉価なPCがあったのか、オンボードNICが100BASE-TXだったのか、憶えていませんが）で、スイッチもB社製だったので、全く逃げ場がない状況でした。
結局、原因は、採用していたチップベンダ提供の起動時設定値が不適切だったというもの。
チップベンダ側で複数準備していたWoL起動時のリンク設定ストラテジーを、別のものに変更して対処できました。
この「WoL起動時のリンク設定ストラテジー」はNICの基板上にある小さなメモリチップ内にあって起動時にロードしてNICチップを設定するもので、特殊なツールを使って書き換えができました。
調査開始したのは梅雨の走りぐらいの時期で、対策版の適用は（幸い）夏休みの終盤。
導入された小中学校を数日かけて5人ぐらいのメンバで回って対処した記憶があります。
OnBoardNICでのWoLについても、起動時に待機状態をデフォルトとするか、デフォルトでは待機しないとするか、PCセットベンダによってもまちまちでした。
そして、その設定変更も、チップドライバ内に用意された設定用IOを通して書き込むことになります。
そのIOを省略されたドライバでは、設定ができないことになります。
OSのInBOXドライバ、この件でのIntelドライバの例にもあるように、不具合が内在されたままであったり、機能削減がされていたり、注意が必要ですが、一般には信頼されてしまっているので、「原因がInBOXドライバであった」という報告も、受け入れられ難いことがありますね。
VLAN対応のドライバに変更し、レジストリ内の関連する項目を追加設定すると、WireSharkでtaggedフレームをtag付で採取できるようになります。
ところで、WoL待機時のリンク状態は、多くの場合デフォルトが10BASE-T（半二重）です。
もっと以前には、このことが、思わぬ事態を引き起こしていたこともありました。