読者です 読者をやめる 読者になる 読者になる

もっふもっふにしてやんよ!

勉強会行った話9割、手を動かした話1割。

標準インストールされているWindows ストアアプリが英語表記になってしまう問題とその対処法

はじめに

・当方で対応したのは0x80070057エラーでアップデートが出来なかった場合です。 ・対処法として考えられるものを列挙したので、マイクロソフト社のソースと一緒にご参考とまで。 ・最終的に、原因特定にはいたっていません。 再起動したら直りました。

対処法

対処法に入る前に1点だけ。ストアアプリはWINHTTP通信を使用するため、そこに起因する問題(netsh winhttp proxyや、FW等々)を事前に疑いましょう。

1. マイクロソフト社公式のトラブルシューティングツールを実行する

まずはコレを試しましょう。

Windows アプリのトラブルシューティング ツールを実行する

尚、コレを試すと「アカウントにログインしていません」と怒られました。(間違いなくそうじゃねえ!)

2. アプリの削除、再インストール

以下に示されている通り、PowerShellを使ってアプリの再インストールを行います。

answers.microsoft.com

万が一ストアアプリを常用している場合は、各アプリが保持している設定などがどう扱われるかをご確認ください。

3. なんかよくわからないけど再起動する!!

上記を実行した結果、結局治らなかったのでとりあえず再起動したところ、再起動毎にいくつかのストアアプリにアップデートがかかり、アップデートが掛かったものから英語表記から日本語表記に戻りました。

結論

Windowsの挙動は不思議なものばかりですね。今回は再起動したら直りましたが、再発する可能性も十分に考えられます。

対処の中で、プロキシのログなども確認しましたが、マイクロソフト社サーバーから403の返事が返ってきてたりこなかったりで謎ですし、端末のIEから通常モードのブラウジングではmicrosoft.comに接続できなかったのにInPrivateだと接続できたりと、謎です。

何かご存知の情報があればコメントしていただければ非常に助かります。

参考情報

Preview版での情報なので実施の際はスルーしましたが、Swayに手順が示されています。情報源は以下より。

answers.microsoft.com

社内のフェデレーションユーザーがOffice365にアクセスできない場合の対処法

クライアント端末を見ると、以下のイベントが記録されます。 CertificateServicesClient-CertEnroll

Microsoft-Windows-CertificateServicesClient-CertEnroll

イベントIDは87が記録されます。

結論を書いておくと、セキュリティ上の制約によりADFSサービスへアクセスはできていたんですが、ADFSサービスからの応答を拒否していました。(こんな事例滅多にないみたいで、イベント87の資料が英語でも日本語でも全然無いので参考になれば・・・)

基本的には、下記ガイドの9ページ~12ページに示される認証フローに従い、障害切り分けを行いました。

Microsoft Office 365 自習書 AD FS によるシングル サインオン環境構築ステップ バイ ステップ ガイド https://www.microsoft.com/ja-jp/download/details.aspx?id=28716

今回は、社内ネットワークに当たるので、以下の①~⑨のどこかということになります。(9ページより引用)

f:id:moffumoffu:20170222002014j:plainf:id:moffumoffu:20170222002017j:plain

ADFSサービスのエラー画面は到達するので、①~④のDNS名前解決までは基本的に問題ありません。そのため、ADFSサービスのログを解析しました。フェデレーションサービスが全てダウンしている場合は、以下のトラブルシュートが参考になります。

フェデレーション ユーザーが Office 365 ウェブリソースにサインインしようとすると、ブラウザーに AD FS Web ページが表示されない https://support.microsoft.com/ja-jp/help/2419389/internet-browser-can-t-display-the-ad-fs-webpage-when-a-federated-user-tries-to-sign-in-to-office-365,-azure,-or-intune

Ad FS 2.0 のエラー: このページを表示できません https://support.microsoft.com/ja-jp/help/3044971/adfs-2.0-error-this-page-cannot-be-displayed

ADFSサービスのログは、サーバーマネージャからも見ることは出来ますが、イベントビューワーで見ることも出来ます。基本的に、正常系から異常系全てのログが混在しているので、必要に応じてフィルタをかけましょう。

blogs.msdn.microsoft.com

ADFSサービスにアクセス ( https://login.microsoftonline.com/ から、メールアドレスを入力した後に表示されるの画面にたどり着いた際)した場合、ADFSサーバにリクエストの受信、リクエストの検証、レスポンスの送信という3つのログが出力されるので、それを元にアクセス元IPなどの情報を集めます。 (メールアドレスを tesutodayo@contoso.com みたいに出鱈目なユーザIDを指定してあげると、ログの解析が楽になります。)

ここでエラーログが出力されていなければ問題ありません。事実、サーバーは「俺は正常にレスポンスを返したぞ」と主張しているので、ADFSサービスからクライアント端末までのどこかでレスポンスが落ちたことがわかります。ロードバランサやプロキシサーバなどを介している場合は、そちらのログを追うといいかもしれません。

そんなわけで、問題を切り分けた結果、クライアント端末しか疑いようが無かったため、色々とセキュリティ関連のソフトウェアをオフにして正常に接続が出来ることを確認しました。灯台元暗しというやつですね。

責任範囲ってどういうことなんだろう。とかの話。

雑記

今日起こった話なので、忘れないうちに取り留めなく書きます。

  • 事象:結合試験のあるテストが通らなかった
  • 原因:単体設計書に載っていないあるステータスの変更がなされていないことが原因だった

この二点を考えたとき、まず私の中では 過去の設計書にない部分は私の責任ではない という気持ちでした(現行踏襲で設計するということだったので)。

しかし、プロジェクトチーム全体で考えたとき、 お客様に正常に動くものを納品する という立場で考えると、確かに責任範囲は自身にもあるのだと教わりました。

DevOpsの考え方にも似ていますが、 最終的に何を目標にしているか という意識は確かに大事ですし、犯人探しをしても、対外的にはプロジェクトの責任者が負う形なので仕方がない話です。

しかし、つらみを感じる部分として、 設計書に記載のない内容がシステムの稼動に必要である ということの根本原因は、報告がなされていない設計や変更がある ということのはずです。

これは、システム屋さんとしてはどうにもならない部分(だと思う)ので、私一人では小さなことかも知れませんが、なるべく後の人が困らないように、そういったものは全て伝えられるように頑張りたいと思います。

ほんとにInfrastracture as a Codeしたみ高いですよね・・・

そんなわけで、今日は残業をしてつかれました。おやすみなさい。