見出し画像

Windowsボタンが押せなくなる不具合に対応した話(完結編

本記事は前回のWindowsボタンが押せなくなる不具合の原因がやっと判明し根本対応含め対処方法ができたというものになります。
前回の記事は下記をご覧ください。

はじめに:結局21H2でも解決せず

前回の記事で21H2へのアップデートを行いWindowsOS上の重要なプロセスを修復する事で暫くは平穏な状況でしたが、夏期休暇に入り21H2でも同様の症状を発現する端末がついに出現…。
結局は根本原因を叩かない事にはこの問題は解決できないと認識、この1ヶ月ほど色々と対処した内容をまとめて行こうと思います。

そもそも何が起きていたのか?

そもそも今回起きていた現象をもう一度振り返ると
大まかには3つの現象が発生しておりました。

1.Outlook(Windowsアプリ版)が全く起動しなくなる
2.Teams(Widnowsアプリ版)にログインできなくなる
3.Windowsボタンを押しても反応しなくなる
※細かいことを言うとタスクバー関連の挙動がおかしくなる

3が一番特徴的な症状かもしれません。
その部分についてはもう少し細かい話をすると前回も記載したようにStartMenuExperienceHost.exeというプロセスが何らかの要因によって正常に立ち上がらなくなる事で起きているようです。

コイツですね。

1と2だけであればWindowsUpdate後によくある不具合の可能性もありますので、状況によってはロールバックで解決できますので今回の現象の重要な切り分けとしてはやはり3になるのかなと思います。

では結局何が原因だったか?

結論から言うとAzureADの他要素認証が原因でした。
弊社の場合は条件付きアクセスにて一定環境下のみ他要素認証をパスして認証を許可しているのですが、他要素認証を既に求められている状況下で、先程記載した一定環境下に入った場合、表示されていた他要素認証の画面が解除、さらに既に端末情報が記憶されている場合はそのままログインされてしまうのが確認されました…。

※ちなみにここでは
多要素認証:複数の要素を使った認証
他要素認証:IDパスワード以外の要素での認証
という定義で話してます
うん、判りづらいので後で修正します…。

通常であればこのように定期的に多要素認証が行われますが…
一定環境下に入ってしまうと
表示されていた他要素の認証が消えた上に
元々端末情報が記憶されている場合
パスワード部分はスルーしてそのままログインできてしまう。

ただし、アクセスできたからといって他要素認証をパスしている訳ではないので、そのまま他要素認証を一定期間行わずに放置しておくと条件付きアクセス側との兼ね合いで今回のような現象が発動する事がわかりました…。

ここにたどり着いた理由

ここにたどり着いた理由として

1.以前単純なプロファイルの作り直しだけでは改善しなかった
2.月曜日や連休後にこれらの症状を訴える人が増加した
3.比較的リテラシーの高い人、逆にPCが苦手な人では起きなかった。

上記3つの原因から推測を行い解決に至りました。
まずは1の時点で365も絡んだ障害であると睨んではおりましたが2、3の症状を見てある意味「真っ当に使っている人」では起きない事から認証周りが怪しい→そういえば皆PC起動時にすぐに多要素認証が入るはずだが、やってるんだろうか?→やっぱりやってなかった…。
というのが判明した形です。

ではどうしたら解決するの?

原因がわかれば解決方法は至ってシンプルです。
もう一度条件付きアクセスに設定されたどのアプリ、システムでも構いませんので他要素認証を出現させてちゃんと認証すれば解決できました。

何故クラウド認証側の他要素認証通過でOS側であるWindowsボタンが正常に動くようになるのか?のカラクリは結局わかりませんでしたが今日びクラウドシステム側とOSが非常に強く結びついているのだなぁと強く実感するトラブルでした。

ここまで来るのに長かったので…

解決に至るまでプロファイル修正やIntuneリタイア→再登録など結構色々な対処療法(過去の記事参照)を実施してしまった為に、AzureAD側の登録情報がちょっとおかしな事になっている端末がポツポツ出ておりこれらの対応を終わらせて初めて終息と言えそうです…もう少しかかりそうだな…。

最後に

条件付きアクセスでの設定トラブルは色々な記事を見てきましたが、先程も書いたようにまさかOS挙動側に影響するとは…というのは本当に新たな知見を得た想いです。
レアなトラブルとは思いますがもし同様の現象が出たときは参考にしてみてください。

この記事が気に入ったらサポートをしてみませんか?