Windowsのドライバが何故か組み込まれなくなってしまったら。

 今回は稀に突然発症するWindowsの病気、「何故かドライバがインストールされない病」のネタでも。
 何でこんなネタを出したかというと、自分の端末が喰らってしまったから。

 ◇

 まず、この症状の解説から。

 「ある日突然、それまで使えていたUSB等の機器が認識されなくなった」

 これが病状。
 ってさらっと書いているが、これ結構致命的で、使い方次第ではこうなったらPCが役立たずになってしまうことも珍しくない。
 例えばUSBメモリなんかが、昨日まで使えていたのに今日突然使えなくなった、とか。
 まぁメモリ程度なら兎も角、データ山盛HDDなんかだとかなりシャレにならないことに。

 なので、ここからは原因切り分けを開始ということで。
 まずは、デバイスマネージャを起動。この時、

 「何故か使えないデバイスが「ほかのデバイス」というトコに繋がっているように見える」

 この状況の場合、この病気の可能性が高い。
 逆に、そもそもデバイスが見えていない場合はハードウェア故障の確率の方がかなり高い。
 次にイベントビューアをチェック。

 「「Windowsログ」「システム」の中に「情報」として「イベント20001」が「UserPnp」から出力されている」
 「「ドライバー NULL Driverをインストールするプロセス」というメッセージが見える」

 上記状況にヒットしてしまった場合、ほぼ100%今回の病気ですな。

 ◇

 さて、この病気の原因なのだが。

 一言で言うと、HDD上のドライバ情報またはドライバ本体が壊れてしまった為。

 Windowsには悪い癖があって、この「ドライバ情報」というのは意外と壊れ易い。
 そしてこの「ドライバ情報」が壊れてしまうと、ドライバ本体まで使えなくなってしまう。
 更に悪いことに、この状態でドライバ自体を修復や再インストールしようとしても「ドライバは問題ありません」とか言われて蹴飛ばされてしまったりする。

 #ちなみにドライバ情報にはキャッシュ(のようなもの)があるので、そのキャッシュが捨てられて再構成されるまではドライバ情報が壊れていても特に問題は発生しない。なので、実はとっくの昔に壊れていたものがある日突然明るみに、というパターンは少なくない。

 こんな状況を打破するには、要するに壊れたドライバ情報を修復するしかない。
 修復手法は2ステップ。

 但し以降に書くこの方法、システムが壊れかけている場合はとどめを刺すことになる可能性があるので、システムフルバックアップを必ず取ってから実行すること。
 一見治っているように見えて実は他のトコが巻き添えで壊れた、なんてことも実際あるので。

 #たまに「取り敢えずコレ打て」的な書き方を見かけるが、取り敢えずで打つ程安全なコマンドではないよ念のため。

 ◇

 まずは事前準備。

 chkdsk /f C:
 (Windows10では chkdsk /f /offlinescanandfix C:)

 システム障害が起こっている環境ではかなりの確率でシステムドライブに論理エラーが出ていることが多い。
 それを放置したまま次の作業を進めてしまうと更に傷口を広げてしまう可能性があるので、まずはそこを潰しておく。
 但しこのコマンドの時点で既に打つ手なし状態だと判明する確率も実はそこまで低くはなかったりする。

 #ちなみに物理エラーが疑われるなら/rで。環境次第ではやったら時間はかかるが、そういうモノ。

 そして軽い方から。コマンドプロンプトから以下のコマンドを打つ。

 sfc /scannow

 Windowsのシステム修復機能を起動して、壊れているコンポーネント情報を修正するコマンド。
 修復はあまり期待出来ないが、エラーが出たら基本的に何処か壊れている。
 ちなみに環境にもよるが30分とか普通にかかる。

 Windows7迄の場合はここまで。
 Windows8以降では次のdismコマンドも打っておく。
 こちらはWindowsのImageを掃除するコマンド。
 詳細は横に置いておくとして、これもそこそこ時間かかる。

 DISM /Online /Cleanup-image /Restorehealth

 で、上記2つのコマンドを実行した後、再起動。
 その結果・・・改善することもあるが、環境よっては却って悪化することも。
 その場合は諦めて次へ。

 ◇

 次に、手間のかかる方。
 まずこの手法を使う場合、

 ・正常なドライバ
 ・空きHDD
 ・WindowsのインストールDVD

 この3点が存在することが大前提。
 ではこれらで何をするかというと、

 1. 現在の問題あるHDDを取り外し、空きHDDを取り付ける。
 2. Windowsをインストールして起動出来るようにする。
 3. 問題あるHDDを接続し、問題あるWindowsパーティションを見えるようにする。
 4. パーティション内からドライバの格納先を探し、インストール直後の正常なドライバで全て上書きする。
 5. 環境を戻してデバイスを認識させる。

 こうなる。
 ちなみに5.のデバイス認識では通常より時間がかかることがあるがそれは正常。

 以下、4のステップの詳細。

 ・ドライバの保存場所は大体のマシンでC:¥Windows¥System32¥DriverStore¥FileRepository。
  この下にドライバ毎にフォルダが切られていて、このフォルダ名=ドライバのinfファイル名。

 ・このドライバ毎フォルダ内にはinfと対になるsysファイルやdllファイルが保存されている。
  何かの拍子でこの中のファイルが壊れたり不整合を起こしてしまうと、ドライバのインストール不良になってしまう。

 ・Windows標準ドライバでこの症状が出た場合、同一Windowsの正常な環境からフォルダ内ファイルまるごと全コピーで上書きしてしまうのが簡単。
  サードパーティ製ドライバならドライバディスクやインターネットからコピーして入れ直す。

 ・そのままだと上書き出来ない場合は、一旦ファイル・フォルダの所有者を自分に変えてから権限を付けると作業可能。
  ローカルの管理者権限を持っていれば所有者の変更だけは出来るので、所有者変更→権限付加、の2ステップ。
  勿論作業後は元通りにしておくこと。

 ◇

 以上、こんな作業でWindowsでの「デバイス認識しない問題」「ドライバが何故か入らない問題」の大多数は片付く。

 勿論これで全部直るワケではなく、例えばレジストリが壊れていたりするともっと大事で、そこまでいってしまうと再インストールの方が幸せになれる。
 だがレジストリ自体の不整合は最近はかなり発生しづらくなっている一方、DriverStore以下のファイル不整合は相変わらず発生し易いので、大多数はドライバの不整合だけ直せばどうにかなるのではないかと。

 とまぁこんな感じで、今回はここまで。

Share

リモート デスクトップ サービスは別にビジーではありません。

 今回のネタは、時々「あ~やっちまった」となるお話。

 Windows Serverでログインしたまま(そして大抵は何かアプリを動かしたまま)のセッションに再接続しようとすると、たまにこんなエラーが出て接続させてくれないことがある。

 「リモート デスクトップ サービスが現在ビジー状態のため、実行しようとしている操作を完了できません。しばらくたってからもう一度試してください。他のユーザーはログオンできます。」

 ちなみに英語版のエラーメッセージはコレ。

 「The task you are trying to do can’t be completed because Remote Desktop Services is currently busy. Please try again in a few minutes. Other users should still be able to log on.」

 この問題が出てしまった時の対処法は、

 「Adminユーザーでログインして該当ユーザーを強制ログアウト」

 これが一番。というか、実質的にはコレしかない。

 え、保存していないデータ?セッション切る前に保存していなかった方が悪い。
 だってWindowsよ?いつ落ちてもおかしくないでしょ?それぐらい覚悟してるよね?

 ・・・え、鬼畜過ぎるって?
 でもこんな風に割り切りでもしないとどうにもならないのも事実なワケで。
 さくっと強制ログアウトしてしまいましょ。

 ◇

 さて、頻度は低いとはいえ一度ブチ当たってしまうと状況次第では(精神的、或いは時間的)ダメージが結構大きいこのトラブル。
 一番アレなところは、エラーメッセージが実態を全く正しく表していないことなのではないかと。

 というのは、殆どの場合、問題なのはTermSvcs(Remote Desktop Services)ではなく、その上のセッションで動いているCsrss.exeがセッション接続要求に応えなかったからなんですな。

 そもそもcsrss.exeって何かと言われると、カーネルとアプリケーション間のやりとり(システムコール等)を仲立ちするシステムサービス。Windows起動と共に開始され、サービス開始に失敗する(或いはユーザが間違って停止させる)とBSODで即落ちする、Windowsの基幹部品の一つ。
 なので、アプリが起動する際には必ずこのcsrss.exeとのプロセス間通信が発生しているし、ユーザーがログイン・ログアウトする際、セッションが接続・解放される際にも然り、と。

 ところが、デスクトップ用に作られてあまりセッション切断のことを考慮していないアプリがあると、セッションが切断された際にアプリとcsrss.exeの間でデッドロックが発生してしまうそうな。状況的には、カーネル側に対してはセッション切断を完了しているが、アプリ側のセッション切断完了は待ち続けているという。
 仮にcsrss.exeがアプリにセッション切断を強制したらアプリが即ハングする可能性もあるので、さすがにそういう仕様にはなっていない。

 この状態でもシステムコール等は正常に出来るし、アプリ自体は特に問題無く動き続けるが、csrss.exeの方は「セッション完了待ち」ステータスで居続ける為、新しいセッション接続要求に対して対応することが出来なくなってしまう。

 #ちなみにWindowsServer2008/R2にはこのデッドロックが頻発する不具合(バグ?)があり、修正パッチが出ているものの、これも根本解決ではなくタイミング調整等でデッドロック頻度を下げているだけ、の模様。

 ◇

 それじゃコレ、正しくお行儀良くセッション切断するアプリなら問題無いか、というとそう簡単な話でもないようで。
 何しろ「純正」MS製のOffice等でもこのデッドロック状態が発生することがある、という話はぼろぼろ出てきているので。

 不具合発生頻度が結構高くよくネタとして出てくるのはOutlookで、デカいメールボックスを抱えているようなユーザー。
 Outlookのプログラム自体はこのセッション切断を考慮していないワケではないようなのだが、メールボックスに対して検索等の操作中だったり、裏でインデックシングが動いているような状況で切断すると、アプリ側のセッション切断がシステム側の要求に対して間に合わず、デッドロック状態に陥ることがある模様。

 他にも、たまたまIO要求が高い状態でセッション切断すると、通常なら一瞬で終わる筈の処理がIOに引っ張られて待ち行列に入ってしまい、結果的にタイムアウトしてデッドロック状態になるというハメに陥ることも。

 ◇

 ということで、元々「シングルセッション」「全権限制約無し」「起動中にセッション切断・再接続なんて考慮外」という世界で動いていたWindowsのデスクトップアプリを、Server上で動かすってのは意外とリスキーである、というお話でしたとさ。

 まぁ自分の場合は「あっちゃーまたかよ」で済むので特に対策もせず使い続けているが、そういうのが許されない状況だったら、悪いことは言いません。
 Server上でデスクトップアプリを動かすなんてことはやめといた方がいいです、はい。
 そしてどうしてもデスクトップアプリを起動しなくてはいけなくなったら、終了するまでセッションはそのままで。

 P.S.
 個人的には出来はそんなに悪くないと思っているNT6.3カーネルなのだが、その中でも恐らく手癖として最悪なのがコレ

 「IOのプライオリティが高い割に、IOと要求スレッドの並列化が十分になされていない」

 ではないかと。
 結果として、該当スレッドの処理内容とは関係無い筈のIOの待ちでスレッドが何故か一時停止したり、平行稼働出来る筈のIOが何故か順次稼働になってしまったり。
 プライオリティを上げないとIO性能が頭打ちになるのは目に見えていたのでこの変更自体は正解だと思っているが(これからコンシューマーでもNVMe等が普通になっていくだろうし)、伴ってもう少し改善すべき箇所もある気がするのよね。

Share

UEFI bootでディスクのSerial Noを変えて起動しなくなったら。

 検証用に大量の物理・仮想マシンを並べたりする時によく使われる、クローニングという手法。
 仮想マシンだと特に簡単にコピー出来るので、さくっと出来て嬉しいことが多い反面、気をつけなくてはいけないこともあるワケで。
 そんな中には、従来のBIOS環境だと気にする必要が無かった、UEFI環境ならではのネタもあるワケです。

 そんな中で今回ネタにするのは、割とありがちな「ディスクのシリアルID書き換えたら起動しなくなった」という話。
 自分も初めてやらかした時は「あちゃ~」という感じだったので。

 ◇

 まず、前提。

 状況:

 UEFIで起動する環境でブートドライブのシリアル番号を変更すると起動しなくなる。

 解決策:

 Step1:bcdbootで修理する。
 Step2:それで駄目なら、bootrecで修理する。

 当方が色々やらかした範囲では、ブートドライブのシリアル変更のみならbcdbootの自動修復で100%回復している。
 何も考えずに直してくれるのでこれが一番ラク。
 但し万が一これがコケた時に備えて、後で本来正当なbootrecのやり方もメモっておく。

 ◇

 以下、まずはbcdbootでやる方法。

 1:
 起動がコケてるマシンをWindows Install DVD(またはUSBメモリ等)で起動し、コマンドプロンプトを開く。

 システムによってはInstall DVDよりも起動優先度が高いデバイスが存在する為、必要ならばBIOS(UEFI)画面に入って起動優先度を変更する。
 DVDから起動したらインストールオプションから左下「コンピューターを修復する」を選択し、「トラブルシューティング」→「詳細オプション」→「コマンドプロンプト」。

 2:
 diskpartでWindows SystemのあるボリュームにC:を割り当てる。

 select disk 0
 → list volume
 → 一覧からWindows本体が入っているパーティションの番号をチェックし、select volume 番号
   (例えばselect volume 3)
   大抵の場合Infoに「ブート」と入っている
 → assign letter=C:
 → exit

 3:
 bcdbootでC:から起動するエントリを作成する。

 bcdboot C:¥Windows /l ja-JP

 4:
 DVDを抜いてシステムを再起動する。

 以上。
 実はこのうち3.のC:を割り当てる作業をせず、4.でオプション無のままでbcdbootコマンドを打つだけでも、結構な確率で起動する状態に戻せる。
 とはいえ時々コケることもあるので、ドライブレターを振っておいた方が幸せな模様。

 ◇

 それでは次に、bootrecコマンドを使う場合。
 以下の例は修復フルセット。

 1:
 起動がコケてるマシンをWindows Install DVD(またはUSBメモリ等)で起動し、コマンドプロンプトを開く。

 2:
 diskpartでWindows SystemのあるボリュームにC:を割り当てる。

 3:
 diskpartでBoot PartitionにF:を割り当てる。

 select disk 0
 → list volume
 → 一覧からBootパーティションの番号をチェックし、select volume 番号
   (例えばselect volume 0)
   大抵の場合Labelは「システムで予約済み」、Infoに「システム」と入っている
 → assign letter=F:
 → exit

 4:
 Bootフォルダに入ってbootrecコマンドで再構築する

 F:
 → 環境依存で以下のうちどれか、dir等でBootフォルダを探す
   cd ¥EFI¥Microsoft¥Boot
   cd ¥ESD¥Windows¥EFI¥Microsoft¥Boot
   cd ¥Boot
 → bootrec /fixboot
 → bootrec /fixmbr
 → bootrec /rebuildbcd

 5:
 DVDを抜いてシステムを再起動する。

 ◇

 以上、こんな感じでほぼ何とかなる筈。

 ちなみにマルチブート構成ではrebuildbcdで複数のWindowsが認識され自動でエントリに追加される筈だが、時々取りこぼしも出る模様。
 所詮自動修復なので、その辺りは手修正しましょうということで。

 あと、シリアル書換でなくトラブル対応でも良く出てくるbootrec /fixbootだが、そういう場合はWindows Systemの入っているボリューム(上の例だとC:)がActiveにマークされていることを確認することをお忘れ無く。Systemの入っているボリュームがActiveになっていないとこのコマンドはエラーになってくれるので。

Share

Active Directoryのドメイン名を変更してみる(注:とってもやりたくない)。

 タイトルがアレだが、本音でもある。

 WindowsのActive Directoryは一応ドメイン名の変更がサポートされているし、必要なツール一式もWindowsに標準で入っているので作業が出来ない訳ではない。・・・が、本音ではやりたくないのよコレ、大体何か起こるし。

 ということで、今回は取り敢えず自分がやった作業記録っぽいものを以下に。
 日本語で手順一式が書かれたページはあまり無いようなので、もしかしたら誰かの役に立つかも、的なノリで。

 ◆事前準備

 1◇兎に角、全てのAD間のレプリケーションが正常に走っていることを確認する。

 個人的な経験からして、見落としがちなのが、片方向はOKだが反対方向はNGというパターン。
 以下のコマンド、全てのサーバでレプリケーションが常時正しく行われているかどうか確認しましょう。

 repadmin /showrepl [ADサーバ名]

 もし「失敗しました。」なんて出ている場合で、且つ「ネットワークが物理的に切れていない」「名前解決がコケてない」となると、大体はRPC絡みでトラブっているので、その場合は取り敢えずパスワードリセットで。

 netdom /resetpwd /Server:[サーバ名] /UserD:[ドメイン名]¥[ドメイン管理者名] /PasswordD:[パスワード]

 ADサーバの中に1箇所でもレプリケーション不良があった場合、一見正常に見えるサーバも含めて全てのサーバでパスワードリセットをかけた方が良い模様。というか、そうしないとレプリケーションが復活しなかったことも。
 で、パスワードリセットが正常に働けば、止まっていたレプリケーションが流れ始める筈なので、一休みしてから再度repadminでステータスを確認すればOKの筈。

 ・・・これで駄目だと結構面倒臭い、というかそもそもADが危険な状態の可能性が高いので、ドメイン名変更云々の前に現ドメインを修復して健全にしてからね、と。

 2◇可能であればGC(グローバルカタログ)をプライマリの1つに減らす。

 GCのレプリケーションは時間がかかるせいかどうか、GCが複数ある状態での作業だと思わぬエラーが発生したりする確率が高い「気がする」。
 なので、この作業を始める前にプライマリの1つ以外は全てGCの役割を外し、作業が終わってたら再度GCに設定すれば良い・・・と「思われる」。

 #動作原理だけ考えれば、レプリケーションさえ常時問題無いならばGCの設定がど~かなんて一切関係ありませんが、という話の筈なのだけど。

 ◆作業開始

 1◇現在の設定のエクスポートとリストの修正

 rendom /list

 このコマンドを打つとカレントの下にDomainlist.xmlというファイルが作成されるので、コレを適当テキストエディタで開く。

 <DNSname>現在のADドメイン名</DNSName>
 <NetBiosName>現在のADドメイン名のNetBIOS名</NetBiosName>

 という項目が複数あるので、このADドメイン名とNetBIOS名を変更後のものに書き換える。
 ちなみに

 <NetBiosName></NetBiosName>

 という風に項目があるが値が入っていない箇所はそのまま放置でOK。

 2◇新ドメイン名のロードと同期

 rendom /upload

 これで、現在のADサーバに変更された設定がアップロードされる。

 ♯と同時にドメイン名変更用の特別モードに入るので、再度設定変更をアップロードすることは出来なくなる。

 repadmin /syncall /e /d /P

 これで、全てのADサーバに変更された設定を同期させる。

 但しこれ、/Pが付いているので「同期要求」であることに注意。
 片方向のレプリケーションが正常で反対方向のレプリケーションがエラー、なんて状況だと、実はレプリケーションエラーなのにこのコマンドでエラーが出なかったりする。理由は簡単、同期要求だけは正常に伝達出来ているので。
 なので、先程も出した /showrepl コマンドできちんと同期出来ていることを確認しましょう、と。

 3◇更新準備と更新開始

 設定同期が完了したら、以下のコマンドで更新準備開始。

 rendom /prepare

 ローカルはすぐ終わるだろうが、リモートサーバ等ではたまに待たされることも。
 また、レブリレーションが終わっていなければ当然エラーになるので、細い回線越しのサーバがあるような環境では少し待ってあげるのも吉。
 ちなみに、何度コマンド打っても特に問題無いですよ。

 そして、全てのサーバが準備完了なったら、全てのADサーバが自動再起動しても問題無いことを確認して以下のコマンドでアップデート実行。

 rendom /execute

 エラーが無ければ自動的に全てのADサーバで再起動がかかります、はい。

 4◇設定修正

 ポリシー周り等、自動で更新されない箇所を修正しましょう。

 gpfixup /olddns:古ドメイン /newdns:新ドメイン
 gpfixup /oldnb:古ドメイン /newnb:新ドメイン

 ここで一旦、再び全てのADサーバを再起動。

 5◇DNS名修正

 プライマリDNSが自動で修正されないことがあるので、その場合は手動で修正する。
 GUIから新ドメインの前方参照ゾーンを「Active Directory統合」で作成。

 新ドメイン
 _msdcs.新ドメイン

 ゾーンさえ作成すればあとはADが勝手にレコードを作ってくれるし、セカンダリDNS以降はまぁ待っていれば複製されるかと。
 新ドメインのゾーンが作成されていることを確認して、ここで更に全てのADサーバを再起動。

 再起動後、既に用済みの旧ドメインの前方参照ゾーンは削除する。削除完了後再度再起動。

 ・・・何度も再起動していていい加減にしろ的な感想も出てくると思われるが、この辺りはホスト名他色々書き換わっている関係で、面倒でも素直に再起動した方が良い模様。省略すると後で「アレこれ反映されてない」的な場面に出くわすことも。
 また、再起動してから実際に新しい設定が反映され始めるまで、最低でも10分程度は待った方がいいというも当然ということで。

 6◇ホスト名修正

 再起動&反映待ち完了後、「フルコンピュータ名」が

 サーバ名.新ドメイン

 に正しくなっていることを確認。普通は修正されている筈だが、もしなっていなければ修正する。
 例によって「コンピュータ名/ドメイン名の変更」から「詳細」ボタンを押して「このコンピューターのプライマリ DNSサフィックス」を書き換え。

 7◇後片付け

 AD上のゴミ片付けコマンドを入力。

 rendom /clean

 特に問題が無ければ、一連の作業完了コマンドを入力。

 rendom /end

 これでADがドメイン名変更用の特別モードから通常モードへ移行するので、作業完了、と。

 ◆クライアントは

 入り直すタイミングで新ドメイン名が反映される。
 但しクライアントキャッシュ上では旧ドメイン名が残ってしまっているので、変更直後の最初のログインだけは、電源投入直後の表示されるログインユーザー履歴からはログイン出来ない。

 ◆◆◆

 ・・・まぁこんな感じですか。

 作業として大したことは無いのだが、うっかりレプリケーションエラーが出てしまうと変更作業自体が止まってしまうので大変ですな。

 それでは、今回はこんなところで。

Share

Microsoft Windowsのスタートメニューは何処へ行く。

 今回はWindowsの迷走っぷりについて少しぶ~垂れてみる。

 まず、最近ではWindows8.1 Update3は出ないという話が有力に。代わりに従来Update3と言われていたスタートメニューを実装した代物はWindows 9として登場し、更に8.1から9へは無償アップデートするとか。

 巷では有力だというこの話だが、個人的にソレってはどうなんだろうという印象が拭えないのですよ。

 いやね、いくらイメージ戦略的に8が大失敗なので早く看板を9に掛け替えたいってのは分かるのだけど。
 だからといってスタートメニュー「復活」だけで9を名乗ってしまうの?と。その程度だったら8.2で十分でしょ、と。Windows 1.0なUIだって変わらないようだし。

 とはいえ、こんなイメージ戦略なんて実にどうでもいい話ぐらい、本当の問題はビジネス側にあると思うのですよ、自分はね。

 一つは、Windows Serverとの兼ね合いの話。従来通り、同一カーネルでクライアントとサーバで世代を揃えるってなら、Windows Serverの方も2012 R2から2014に更新するしか無いですよね。で、これも無償アップデートにするの?と。

 何故って、スタートメニューなんてクライアント的理由や、細かい拡張・バグフィックスだけでサーバOSのアップデート料金を取るというのはいくらMSでも無理な話。コストに敏感なクライアントの皆様、今時その程度じゃカネ払ってくれないですよ。
 更に、そもそもエンタープライズの世界ではソフトウェア更新なんて最も嫌われる作業で、ソレを頻繁に繰り返すラピッドリリースとエンタープライズとの相性はとてつもなく悪い。
 仮にライセンスそのものは2014へ無償アップデートがされたとしても、ドライバ絡みやソフトウェアサポートの関係でアップデートが不可欠なんてことになった日には、エンタープライズユーザからは非難囂々の筈。

 ♯世間ではXP問題が過去のモノになろうとしているが(実態としてはまだまだ解消されていない)、ビジネス用途では更にWindows Server 2003問題というヤツがありましてね。

 もう一つは、ここで8.1→9のアップデートを無料にしてしまうと、今後MicrosoftのOSの更新はずっとタダ、という印象が出来てしまう恐れがあること。
 普通に考えてOSの開発費用をOSの売上から賄えなくなるので、これMicrosoftにとっては由々しき事態だと思うのだが。

 ここで仮にクライアントだけタダです、Server OSではおカネいただきます、なんてことブチかましたら、エンタープライズのクラウドシフトが加速するだけだろうし。AmazonやらGoogleやらが手ぐすね引いて待ち構えてまっせ。
 そしてそれは間違いなく、将来のMSの売り上げを減らす方向にしか働かないと思うのですよ。

 巷ではAndroidやMac OS/iOSと比べてOS費用が云々という言われ方もするが、事実上ハードウェアのオマケのMac OSやiOS、端末屋サイドから見れば塵も積もれば的にカネのかかるAndroidとはそもそもビジネススキームが違うので、当分MSはWindows OS単体で売り上げを作って開発費を賄わないとやっていけないので。

 ◇

 ・・・ということで、自分的には多分これが一番安全なのではないかと。

 ・Windows 8.2で一旦スタートメニューを無償提供し、8系はここで打ち止め。
 ・WindowsServer 2012はR3でWindows 8.2と同期を取り、2012系もここで打ち止め。

 ・Windows 9は更に新しい機能を実装して「有償でもアップデートしたくなる」OSに仕立てる。
 ・Windows Serve 2016(?)も同じく。

 ♯個人的には更にDeepに使い物になる第4世代Hyper-Vと、記憶域プールの単体ストレージ並の機能拡張を期待。MSFC不要の物理マシン跨ぎなHyper-V VMの自動Fail Over、5層ぐらいの自動&手動ストレージ階層化、RAMDISK作成&ホットデータキャッシング、無停止ボリュームスナップショット、ボリューム遠隔同期辺りは標準サポートして欲しいですな。いい加減単体ストレージ箱ど~にかしてくれ。

 というか、MicrosoftがこれからもWindowsのメジャーアップデート=有料というセンに踏み留まりたいのならこれしか無いと思うのだが。

 ・・・しかしまぁ、いかんせん、どうなることやら。

Share