24H2罠シリーズの８ですｗ 前回のはこんな感じですｗ
BMAXのミニPCのおかげで、すばやく検証のトライアンドエラーができています。現場や設計の仕事の合間の隙間時間で検証しているのでなかなか進みが悪いんですが、ちょっと半日ほどどっぷり時間をかけることができたのでいろんな検証をしてみましたｗ
まず、検証結果ですが、いまだにうまくはいっていませんｗ 実はこの「24H2の罠」シリーズですが、微妙にアクセス数があって、24H2をアップデートしたせいでクライアントマシンがうまく動かないってい方が多いということがわかります。で、検証途中ですが、最初にお伝えしたいことがあってそれは、
クリーンインストールとアップデートインストールでは挙動が違う
ということです。まず、これが前提ですので、動いてるマシンと動かないマシンでは、おそらく大半の動いているマシンは「アップデートを繰り返しているマシン」ではないか？と思います。アップデートを繰り返すといっても、それは、WINDOWS10あるいはそれ以前からのマシンではないか？と思います。これはアップデートインストールでは、現状の環境を可能な限り引きずるようになってるからです。
ところが、そのようなアップデートを繰り返してもある日突然ダメなアップデートに遭遇するかもなんですが、それは、WINDOWS10のときでも結構なバージョンアップがあったときに問題になったわけで、特にネットワーク絡みだと「ポリシーの変更」とか「セキュリティの強化」が原因だったりします。
例えば、ある日突然、WINDOWS UPDATEが終わると、それまでアクセスできていた共有フォルダや、ネットワークドライブにアクセスするとこんなのが出てきますｗ これは、認証関係での変更がアップデートであったという証拠で、おそらく、この挙動を解消するのにかなり悩むと思います。
ネット上には、成功事例が数多くありますが、それは、ワークグループでの運用だったりで、Active Directory環境（以下、AD）ではないことが多く、残念ながら、実はあんまり参考にならなかったりしますｗ
ちなみに、今、解決できずに悩んでいる問題は、コンピュータがADドメインに登録され、ADユーザーでログオンしている（はず）なのに、先の「ネットワーク資格情報の入力」が出てくるというものです。この問題をググっていま行きついているのが、
「DC参照の際の、DNSベースの検出とNetBIOSベースの違い」
で、どうやら、WINDOWS11 24H2から、NetBIOSでのアクセスがポリシーや設定によりできなくなっているのがデフォルトだというところまで突き止めた次第です。ですので、その設定関係を変更したのですが、それでもうまくいかないというところで止まっています。
それで、これらを解決するためには、もしかすると、サーバ環境も最新のものにしなければならないのか？とも考え始めています。これには、結構、費用も、時間もかかってしまうので、お気軽に対応できるものではありません。まぁ、一応、現状でもそれなりに仕事上、マシンの動作に問題がでているわけではないのですが、それでも24H2にアップできないことで、将来的に支障をきたすことは予測されます。
できれば次くらいで、解決しました！という報告ができればいいなと思います。
