移動に３日ぐらいかけて大量のファイルを移動させたら、残りゼロのまま１時間以上処理が終わりませんでした（何してるのか不明だが待てば終わる）。少ない量でもゼロになってから少し待たされると思いますが、ファイルの転送量に比例してこの後処理の時間は長くなるように思います。
それにしても「残り５秒」とかトラブってるのかそうで無いのか判断に困る、こういう表示が不安になるんですよマイクロソフトさん。あと転送速度も 1.37GB/s とかあり得ない表示になってるし、転送中も「残り２日以上」「残り17時間」などと行ったり来たり、当てにならない表示はするくせに「今どのディレクトリを作業しているのか」といった必要な情報は表示してくれないんですよね。
あと、処理開始前にファイル数カウントアップするの止めてもらえませんかね。数十万～百万ファイルもあると、それだけで１時間とか平気で待たされてしまいます、Windows 最悪です。
先月か今月（2019年9月）のマンスリーアップデートは他の不具合でロールバックして適用していないのだけども、問題が無かった環境でもタスクスケジューラで不具合を発見して、もう最悪なんですけど...。ひとつは実行ユーザーの設定の問題、もうひとつは subst と組み合わせた際の問題、いずれも対処可能です。
ログインしていなくても実行される設定では実行ユーザを設定すると思いますが、このようなタスクはユーザを変更しなくても、もう一度入力しないと適用できません。恐らく「コンピュータ名￥ユーザ名」と復元すべきところを「ユーザ名」としたバグではないかと思います。前の状態がどうだったかは知りませんが、少なくともユーザ名を変更しないときは再入力を求められることは無かったと思います。
subst コマンドで仮想ドライブ化したドライブに置いたプログラムを実行できなくなりました。「ディレクトリが見つかりません」となります。
そもそも Windows10 ではコマンド実行による subst はできなくなりました。しかし「Windows 10で「subst」コマンドは使えない? 」の記事にあるようにレジストリを設定して回避可能です。この記事では、２つの方法が紹介されていますが、１番目の方法ではタスクスケジューラで前述のエラーになります。今のところ、２番目の方法ではタスクスケジューラでの動作も問題ありません。
先月の Windows Update では、仮想マシンにリモートデスクトップ出来なくなり、今月のは NAS とのファイル転送がおかしい。NAS のファイルを移動しようとしたら途中でフリーズし、キャンセルも何も効かなくなった。explorer を強制終了させ、[新しいタスクの実行]から再起動してみたが、ファイルの操作が異常に重たい。フォルダも数分待たないと開かない。PC 自体を再起動させ、もう一度ファイル移動させるが、すぐにまた重くなる。フォルダの表示、ファイルのリネーム、その他すべての動作が重い、重い、重い！！
この記事書き始める前にリネームしたのに、今もまだ処理が終了してない。タスクマネージャーで見ると、エクスプローラーが２つ「応答なし」になっている。今ようやくリネーム処理が終わったが、もう１個のフォルダ表示は緑のプログレスバーが止まってる（１０個くらいしかファイル無いのに！）。間違いない。Windows10 は史上最悪の糞OS だ。
書き終えてアップデートを元に戻そうと再起動したら、いつまで経っても終わらない。強制リセットしようにも、ハードディスクにずっとアクセスあるし、なんなんこれ。もう５分以上掛かってるので、ノーパソで続き書いてるけど、まだ終わらんな。ハードディスクのアクセス断続的になってきたんで、強制リセット掛けて自動修復モードへ移行。なんかもう、やり慣れて自動修復職人になってきた。
ちなみに自動修復は、手動でメニューを選んで進めなければならんので自動なんかじゃない。しかも非常に時間が掛かるので、まーやりたくない。修復が終わっても、起動が遅くデスクトップまで行ってもデバイスの接続音やらなんやらで、要するに Windows Update 後の起動と同じ。こうやって Windows10 は我々から時間を奪っていく。
最新の品質更新プログラムのアンインストール後に元に戻ったのを確認し、即行で Windows Update を停止しました。これで１ヵ月は大丈夫なはずですが、８月末みたいな緊急アップデートみたいなのがあると、勝手にやるみたいなんだよな。同じように１ヵ月停止にしたはずの環境が、勝手に再起動掛かってて不具合再発みたいなのあった気がする。とにかく最近の Windows Update の品質は最悪だと言わざるを得ない。
また Windows10 か、もういい加減にしてくれと言いたくなる。少し前にリモートデスクトップでブラックスクリーンになり操作不能になるというのがあったばかりだが、今度はいっさいの接続を受け付けなくなるので深刻だ。まあ、今回は VMware ESXi の仮想マシンで起きているので「VMware SVGA 3D」とかが悪いのかもと「Microsoft 基本ディスプレイアダプター」に変更してみても状況は変わらず。
いずれも時々繋がることもあるが、非常に時間が掛かったり、コンソール側の画面がブラックやダークブルーになり（マウスカーソルは表示されるが動かない）VMware 側で CPU 使用率が振り切れ、コンソール側からもログイン不能になる。この状態になるとリセットするしかなくなるのだが、繰り返しこれらの操作をしているとそれすら不能になり、ESXi ホストマシンを再起動しないと回復できなくなる。
Microsoft か VMware が修正プログラムを出してくれるまでは、アップデートはしないほうが良さそう。Windows10 はこういうトラブルが本当に多い。
今回のアップデート、ネットワーク関係がおかしいと思う。ファイルサーバからコピーしている最中に重くなり、リモートデスクトップが次々に切断され、最終的にこうなりました。しかも、エラー情報の収集が 100% に達しても再起動しないので、強制リセットするしか無かった。
大型アップデートだけでなく、毎月のセキュリティアップデートでもトラブルが発生するなら、とても安心して Windows10 を使っていられない。来年、Windows7 のサポートが終わったら、この糞 OS を使うしかないと思うと嫌になって来る。
アップデートをアンインストールして解決したと思っていたら、ネットワーク関係がどうも怪しい。複数のファイルをコピーしようとすると１個目が終わると止まって「タイムアウトしました」というメッセージが表示されたりする。
酷いのはネットワーク越しにファイルを移動させた場合。エラーのせいで移動元にも移動先にもファイルが無くなり消えてしまった。幸いバックアップがあったから良かったものの、そうで無かった場合は冷や汗ものだった。
あれから１ヵ月経って、再び Windows アップデートが掛かり、同じ症状に陥りました。今回は、すぐにリセット×３で自動修復（メニュー操作なし）で回復できましたが、同様に１ヵ月更新停止していた Windows10 仮想マシンが数日置きに何台かあるので気が滅入ります。
ちなみに、ESXi 6.7 update 3 にアップデートしてみましたが改善しませんでした。新しく仮想マシンを作ってクリーンインストールしても再現するので、現在の最新アップデートを適用した Windows10 で不具合が起きています。色々と試してみて分かってきたことがあるので共有しておきます。
最後のリンク先の記事の様子だと、８月のアップデートからではなく少し以前からある事象のようです。その記事にあるとおり、リモートデスクトップを終了するときはサインアウトするぐらいしか無く、誤って切断してしまうと一発アウトという厳しい状況です。仮想マシンの用途として、長い処理や定期的な処理を実行させているので、そもそもサインアウトはダメです。やはり「アップデートをアンインストールして自動更新を１ヵ月停止させる」という対策しか、今のところありません。
なお、リモートデスクトップを諦めるなら、VMware Remote Console を使うという手があると思います。こちらは、ESXi のコンソールを単独のアプリケーションのように表示するツールになっていて、プロトコルとしてインストールされます。通常は ESXi の管理サイトから起動するのですが、バッチファイルで通常のアプリケーションのように起動させることができます（別記事で紹介しようと思います）。
この問題には関係無さそうですが KB45172211 が原因で「VMware ワークステーションの機能に問題を抱えている」と書いてある記事を見つけました。斜め読みした感じでは VMware ワークステーションが動かないっぽいです。
中古で買ったパソコンの回復ドライブを作成しようと思い、Windows10 が示した 8GB の USB メモリを用意したんですが、半分ぐらい進んだ時点で「エラーが発生しました」とかで失敗してしまいました。理由も何も示されないのは、もはや Windows10 の伝統芸能なんでしょうか。
結論から言うと容量不足なわけで、16GB の USB メモリに作成し直したところ 9.18GB ほど必要だったことが分かりました。 ちなみに、失敗した USB メモリを見てみると約半分ぐらい容量が残っていて、これだけ見ると容量不足と気が付きにくいんでは無いでしょうか。恐らくは、初期の Windows10 は 8GB に収まっており、あのメッセージは固定テキストで実装されているんだと思いますね。準備に結構時間が掛かっているにも関わらず、正確な見積もり容量すら計算していないとか、相変わらずお粗末な OS ですよね。
Windows アップデートを昼間やると仕事にならんので、昨日の夜にやったわけですよ。アップデートを開くと累積アップデートの 1803 と 1809 があがってて、1803 のアップデート完了で再起動になった。かなり待たされたが、時間のことでとやかく言うつもりはない。再起動後、念のため更新プログラムのチェックを行うと、1809 のアップデートが始まった。いっぺんにやってくれないのか、と思いつつ処理を待っていると...。
C: ドライブの容量不足で、何やら解決手段のようなダイアログが表示された。それを見ると、STEP1 C: のクリーアップ、STEP2 他のドライブを使用、みたいな内容でクリーンアップも限界そうだったので、他のドライブを指定して続行を選んでみた。その後再起動が掛かり、ブルーバックで更新処理が続行される画面になるが、ここからいっこうに進まない。ずっと０％のままだったが、１時間くらい経ったころようやく動きはじめ２０％超えくらいまで確認して放っておいた。更に１時間ほど経っても終わってない、何気にメッセージを見てみたら「元の状態に復元しています...」とある。
これなんだよ Windows10。ちなみに、指定した他のドライブは 200GB ほど空きがあったし、ダイアログで○マークも付いていたので問題無かったはず。結局、1803 の１時間に、1809 の２時間＋復元２時間、５時間以上も掛かってアップデートに失敗しやがった。しかも、どういう理由でコケたのか、解決方法は何なのか、何も提示されない。さ・ら・に・「更新プログラムの操作にどの程度満足していますか？」とか無神経に聞いてきやがった。
前から Windows 10 が嫌いで仕方ないんですが、今日また嫌いになる出来事が...。それはファイルの関連付け、今までこんなことで苦労なんてしたことがありませんし、解決できない、原因も分からない、えーそんなバカなというような感じです。
今まで愛用していたテキストエディタ（ちなみに terapad）がさすがに古くなって少々改善したい点もあったことから、重い腰をあげて notepad++ に移行することにしました。こういったツールはポータブル版（インストーラなしでコピーして配置するだけで使用できる）に決めているので、zip 版を用意しました。
解凍したファイルを配置して、ファイルの関連付けを notepad++ に変更するだけでいいはずなんですが、どうやっても関連付けることができません。
こんな感じでやって諦めました。レジストリを確認しながらGUI操作をしたり原因を追究しようとはしましたが、怪しい一点のみを除いて訳が分かりません。とにかく、エラーも出ないしまったく変化しないしで、ほとほと疲れました。
これについて、ひとつだけ成功した環境がありました。レジストリを見比べたりしても原因が掴めず悩んでいたところ「再起動が必要です」というメッセージが出て「あー」ってなったんですよね。他の失敗環境ではアップデート済みでしたので、今月のアップデートを適用したかしてないかの違いでは無いか、と。今までもアップデートがらみで色々あった Windows 10 ですから十分あり得ると思われます。
追記：別の未アップデート環境で試したところ何の問題もありませんでした。来月以降のアップデートで修正されることを期待します。
こんなアップデートの度に不具合でゴタゴタする OS は未だかつてありませんでした。マイクロソフトもようやく気付き始めたのか、アップデートサイクルを見直す動きもあるみたいです。はっきり言って余計な機能が多いし、かつてのようにビジネス向けとパーソナル向けで分けてやって欲しいですね。最近ので言えば、Windows 7 をビジネス向けに延長サポートしつつ、Windows 10 はパーソナル向け、というのが理想形な気がいたします。アップデートに３時間以上も掛かるのに仕事ではとても使えないっすよ。
Windows10 が最新版にアップグレードできない問題を解消するために、ESXi をアップグレードすることにしました。下位バージョンの 5.5 で問題無いことと、NIC も外した最小構成でもダメだったことから、6.0u1 固有の問題が疑われました。
概ね下記の手順になります。アップグレードによって、ファイルシステムのサポートが終了したりするので、事前に調査しておきましょう。メジャーバージョン同士でもクライアントがウェブベースになったりしていますので、注意が必要です。
my vmware から、製品名を "ESXi (Embedded and Installable)"、バージョンを選んでファイルを検索します。リストには、"update-from-esxi6.5-6.5_update02" など update の付いたものがあります。恐らく、update 付きのものはそこまでの更新ファイルをまとめたもの、付かないものは差分と思われますので、内容をよく確認して差分ファイルも必要か判断してください。
まずアップデートファイルの内容（プロファイル名）を確認します。今回のファイルは下記の内容でしたが、日付の違いと後ろの "s" はよく分からないのですが、"ESXi-6.5.0-20180502001-standard " を入れることにしました。
esxcli software sources profile list \ -d /vmfs/volumes/hdd/update-from-esxi6.5-6.5_update02.zip Name Vendor Acceptance Level -------------------------------- ------------ ---------------- ESXi-6.5.0-20180501001s-standard VMware, Inc. PartnerSupported ESXi-6.5.0-20180501001s-no-tools VMware, Inc. PartnerSupported ESXi-6.5.0-20180502001-no-tools VMware, Inc. PartnerSupported ESXi-6.5.0-20180502001-standard VMware, Inc. PartnerSupported
調べたプロファイル名を指定して、アップデートコマンドを発行します。ファイル変更を行わない "--dry-run" オプションもあるので、動作を確認する場合は指定してください。
esxcli software profile update \ -p ESXi-6.5.0-20180502001-standard \ -d /vmfs/volumes/hdd/update-from-esxi6.5-6.5_update02.zip
更新作業は一瞬で終わりますので、ホストを再起動して適用されたか確認をします。今回は懸念していた問題は何も無く、あっという間に最新版にアップグレードできてしまいました。
全ての仮想マシンを停止するので、今までアップグレードしてきませんでしたが、案外簡単に時間もかからずアップグレードできることが分かりました。しかし、いつもこんなうまく行くとは限りませんから、バックアップシステムがあると安心だなと思いました。iSCSI だとロードバランサみたいにバックアップシステムを使うことはできませんが、NFS ならそういった構成もありかなと思います。
さっそく Windows 10 のアップグレードを試したところ、ブルースクリーン＆ロールバックは発生せず、問題なく April 2018 Update を適用することができました。結論としては「ESXi6.0u1 のホスト環境では Windows 10 1603 以降の仮想マシンは動作しない」ということでした。
相変わらずサイトが分かりにくいので my vmware から、アップデートファイルのダウンロードページまでのパスをメモしておきます。5.5からアップグレードする場合、いったん6.0に上げてから6.7へと２段階で行います。
メジャーバージョンを上げたためか、ライセンスキーの更新も必要なようでした。この取得先も分かりにくかったので同様にメモしておきます。
タイトル通りなのですが、私の ESXi6.0u1 の環境では Windows10 が Windows Update や更新アシスタンスによるアップデート、インストールメディアから起動、いずれも "KMODE EXCEPTION NOT HANDLED" のブルースクリーンになりロールバックされてしまいます。そんな訳で Windows7 を使い続けて来たのですが、そろそろ Windows10 の環境も無いと困るので重い腰を上げて調査しています。最初に断っておきますが、まだ解決できておらず何の参考にもならない記事になります。
あまり面倒なことはしたくないので、今まではクリーンインストールしかしていませんでした。しかし、iSCSI や特殊デバイスをパススルーしていたり、あまりダウンさせたくない VM も動いているのでアップグレードを検討しています。手順はそれほど難しいものでは無さそうですが、いろいろと不安材料があります。
NIC についてはクリーンインストールでもバージョンによって入らなかったりするので、非常に不安です。そもそも Windows 10 1511 のときも突然ネットに繋がらなくなったりして、不安定だったので Windows7 を使っていた経緯があります。今回、真っ先に NIC を疑ったわけですが、デバイスを外してもダメなので無関係と思われ、その検証をする前は Intel の NIC を増設しようとしていました。
仮想マシンはすべて iSCSI に入っているので、最悪クリーンインストールしても消えることは無いはずですが、オペミスや再設定が不安（めったにやらない手順なので）です。また、特殊デバイスのパススルー設定もやりたくない作業ですので、アップグレードを選択します。
問題があった場合はたぶん戻せないので、そうなったらクリーンインストールやむなし、ということで。今回、互換性とWebベースの管理画面を避けたいという点を考慮して、6.0u3 へアップグレードしようと思っています。これが成功して Windows 10 1803 が動けば良し、ダメなら 6.5 へ更に上げ、それに失敗したらクリーンインストールということにします。Webベースになったのは 6.0u2 からでしたので、いっきに 6.5u2 にアップグレードすることにしました。
中途半端ですみません。作業したらまた記事にします。
長期間使用していなかった Windows10（仮想マシン）を起動したところ、予想どおり延々と Windows アップデートになりました。あいかわらずユーザーの意思を無視して、問答無用にアップデートを始めてしまうのも予想通り。しかし、今回違ったのは Windows Update では無く「Windows 10 更新アシスタンス」というものが現れたという点。
前にも書いたけど、Windows 10 の何がダメかって同じような機能やメニューが複数ある点であると思います。なんでまた Windows Update ではだめなんだと思いつつ、待てば更新終わるだろうとこの時は思っていました。ところが、何回アップデートしても再起動のときにブルースクリーンになってやり直し。Windows Update では最新版と出ますが、更新アシスタンスでは 10586 から 16299 に更新する必要があると出る。どっちが正しいのか知りませんが、今のところ解決方法が無いし、ネットで調べる気力も無いので封印しようと思います。
どうやら、Windows 10 というのはこまめにアップデートして最新版を追っかけておかないとだめな OS らしいです。一回のアップデートに数時間かかるようなアップデートを勝手に初めてしまう酷さ、そのアップデートもまともに終了しない検証不足のまま平気でリリースする質の低さ、糞 OS にも程があります。史上最低な Windows の称号を 10 に送ろう。
１日置いて気力が回復したので解決方法を調査してみました。マイクロソフトから「Windows Update トラブルシューティングツール」というものが提供されているのでこちらを実行してみました。更新アシスタンス実行後の再起動でエラーになる現象は解消したのですが、再起動後も 10586 のままです。更新アシスタンスをアンインストールし、しばらく待っているとゾンビと言われているように復活、また問答無用でアップデートが始まりました。つづく。
だめでした～。再起動時に停止しなくなっただけで、ブルースクリーンになってもログオン画面まで行くみたいです（ようは気づかなかっただけ）。アップデート失敗しているので 10586 のままなのか。こんな糞 OS 使うの嫌だな～。
それからいろいろ試してみましたが、何をやっても「KMODE EXCEPTION NOT HANDLED」となって更新に失敗してしまいます。このエラー、デバイスドライバ関係らしいので VMware Tools などの MS 以外のサービスをすべて停止した、クリーンブートを試してみたりしても改善できませんでした。
もうクリーンインストールしか道は残されていないと思いますので、ここでアップデート作業は断念します。
ほぼ同じ環境で随時アップデートしていた仮想マシンでは最新の 16299 になっていることから、大型アップデートを順次行っていれば問題なかった可能性があります。そうであれば非常にデキの悪い OS だと思います。