カテゴリー: Windows

Windows UpdateのログはC:\Windows\Logs\CBS\CBS.LOGに保存されているのでErrorとなっている場所を検索してみます。

2016-11-08 03:10:52, Info CBS Perf: Doqe: Install started.
2016-11-08 03:10:52, Info CBS Doqe: [Forward] Installing driver updates, Count 5
2016-11-08 03:10:52, Info CBS INSTALL index: 0, phase: 1, result 0, inf: usb.inf
2016-11-08 03:10:52, Info CBS INSTALL index: 1, phase: 1, result 0, inf: usbport.inf
2016-11-08 03:10:52, Info CBS INSTALL index: 2, phase: 1, result 0, inf: tpm.inf
2016-11-08 03:10:52, Info CBS INSTALL index: 3, phase: 1, result 0, inf: disk.inf
2016-11-08 03:10:52, Info CBS INSTALL index: 4, phase: 1, result 5, inf: usbstor.inf
2016-11-08 03:10:52, Info CBS Progress: UI message updated. Operation type: Update. Stage: 1 out of 1. Percent progress: 9.
2016-11-08 03:10:52, Info CBS DriverUpdateInstallUpdates failed [HRESULT = 0x80070005 - E_ACCESSDENIED]
2016-11-08 03:10:52, Error CBS Doqe: Failed installing driver updates [HRESULT = 0x80070005 - E_ACCESSDENIED]
2016-11-08 03:10:52, Info CBS Perf: Doqe: Install ended.
2016-11-08 03:10:52, Info CBS Failed installing driver updates [HRESULT = 0x80070005 - E_ACCESSDENIED]
2016-11-08 03:10:52, Error CBS Shtd: Failed while processing non-critical driver operations queue. [HRESULT = 0x80070005 - E_ACCESSDENIED]
＜＜中略＞＞
2016-11-08 03:12:31, Info CSI 0000000b Creating NT transaction (seq 1), objectname [6]"(null)"
2016-11-08 03:12:31, Info CSI 0000000c Created NT transaction (seq 1) result 0x00000000, handle @0x414
2016-11-08 03:12:32, Info CSI 0000000d@2016/11/7:18:12:32.241 CSI perf trace:
CSIPERF:TXCOMMIT;1222683
2016-11-08 03:12:32, Error CBS Doqe: Marked package Package_1_for_KB3139398~31bf3856ad364e35~x86~~6.1.1.1 as failed. [HRESULT = 0x00000000 - S_OK]
2016-11-08 03:12:32, Info CBS Clearing HangDetect value

「Doqe: Failed installing driver updates [HRESULT = 0x80070005 – E_ACCESSDENIED]」とあり、E_ACCESSDENIED（アクセス件がありません）というエラーで終わっていることが分かります。さらに手前の行を追っていく「Info CBS INSTALL index: 4, phase: 1, result 5, inf: usbstor.inf」と、usbstor.infのINSTALLのresultコードが５になっており正常に終了していません。

C:\Windows\usbstor.infのプロパティを開きセキュリティタブのアクセス権を開いてみると・・・SYSTEMとAdministratorsのアクセスを拒否する設定になっていました。アクセス権の拒否のチェックを外してあげると・・・正常に更新する事ができました。

ずっとWindows10にてWindows Updateに失敗が続くので、未適用も増えている対応することにした。C:\Windows\Logs\CBS\CBS.LOGを確認してみるとKB3197954でエラーが発生している。

Google等で検索してみると、WindowsUpdateのサイズが大きいために途中でエラーとなってしまい終わらないことがあるとの情報を見つける。そこでWindows Download CenterからKB3197954をダウンロードしてインストールを試みた。しかし残念ながら進捗が60%ぐらいまで進んだ後、遅々として終わらず、OSを強制的に再起動する。

過去のWindowsUpdateに失敗している可能性もあるが、ロールアップパッケージとなってしまったが故に原因の特定が難しい。以前なら修正される内容から、関連しそうな過去のUpdateにあたりを付けてアンインストールできたのだが、ロールアップパッケージとなったためにそれは出来ない。となると、過去のWindowsUpdateで適用したものを順に消してみるしかない。

スタートメニューから「設定→更新とセキュリティ→Windows Update→更新の履歴→更新プログラムをアンインストールする」に進んでみると、なんとKB3197954がインストール済み更新プログラム一覧の中に載っている。どうやらKB3197954のインストールが正常に完了していないために、KB3197954を繰り返し検出してはエラーとなっていたようだ。

KB3197954をアンインストールした後、あらためて先ほどダウンロードしたKB3197954をインストルしたところ今度は正常に完了。その後のWindows Updateでも問題は発生していないので、大丈夫そうです。

Windows 7のリモートデスクトップを有効にして、ドメインユーザーがログインを許可するには次のようにグループポリシーで設定します。

まずリモートデスクトップサービスを有効にするため、グループポリシーの以下の項目を設定します。

• 「コンピューターの構成/ポリシー/管理用テンプレート/Windows コンポーネント/リモート デスクトップ サービス/リモート デスクトップ セッション ホスト/セキュリティ」にある「リモート接続にネットワーク レベル認証を使用したユーザー認証を必要とする」を有効にする。
• 「コンピューターの構成/ポリシー/管理用テンプレート/Windows コンポーネント/リモート デスクトップ サービス/リモート デスクトップ セッション ホスト/接続」にある「ユーザーがリモート デスクトップ サービスを使ってリモート接続することを許可する」を有効にする。
• 「コンピューターの構成/ポリシー/Windows の設定/セキュリティの設定/システム サービス」にある「Remote Desktop Services」を自動にする。

これだけだとドメインユーザーではリモートデスクトップではログイン出来ません。ドメインユーザーがリモートデスクチップ経由でログイン出来るようにするには、クライアントPCのRemote Desktop Usersローカルグループにドメインのユーザーを追加しておく必要があります。

「コンピューターの構成/ポリシー/Windows の設定/セキュリティの設定/ローカル ポリシー/ユーザー権利の割り当て」にある「リモート デスクトップ サービスを使ったログオンを許可」を設定すれば接続出来るように思うかもしれませんが、実際に設定してもログインする事は出来ません。あくまでRemote Desktop Usersローカルグループに追加する必要があるようです。

グループポリシーのローカルアカウント設定ではBuiltin Groupへのユーザー追加は行えないので、ログインスクリプトからnet localgroupでユーザーの追加を行うことになります。

以下のようなバッチファイルをスタートアップスクリプトに登録します。

net localgroup "Remote Desktop Users" [ドメイン名]\[ユーザーID] /ADD

 

Windows Essentialsのサポート終了に伴いWindows Live Mailも使うことが出来なくなります。Windows LiveMailからMicrosoft Oiifceに付属するOutlookへのデータ移行の手順です。

メールデータを移行する詳細な手順は下のURLを参照して下さい。Outlook 2010となっていますが、Outlook 2013以降でも同様の手順でメールデータを移行できます。
Windows Live メールから Outlook 2010 または Outlook 2007 にメッセージを移行する方法
ただし、若干わかりにくいところがあるので、実際に発生したトラブルも踏まえて補足しておきます。

Outlook 2013を起動した状態で、Windows LiveMailからのエクスポートを行います。Outlook 2013を終了した状態だと上手く動作しない恐れがあります。

メッセージのエクスポートの時に「全てのフォルダー」だと正常に動作せず、ゴミ箱をエクスポートした時点で止まってしまいました。「選択されたフォルダー」を選び、移行するフォルダーを指示した方が良さそうです。

住所録を移行する手順は下記のURLを参照して下さい。特に問題は無いと思います。
Windows Live メールの電子メール、連絡先、および予定表のデータを Outlook にエクスポートする

Windows Server 2012R2にSharePoint 2013 Foundationをインストールしようとすると、.NET Framework 4.5がインストール済みにもかかわらず、.NET Framework 4.5がインストールされていない旨のメッセージが表示され、インストールを継続できない。これはWindows Updateで適用された.NET Framework 4.6等より新しいバージョンの.NET Frameworkがインストールされている場合に、正常に環境を認識できないためにおこる。
この現象はSharePointに限らず、.NET Framework 4.5を使用するソフトウェアのインストールで広く発生するらしい。
解決のためには「コントロールパネル→プログラムと機能→インストールされた更新プログラム」から、NET Framewrok 4.6に相当するKB3045563、4.5.2に相当するKB2901907、4.5.1に相当するKB2859818をアンインストールする。
アンインストールした後にSharePoint 2013 Foundationのインストールを行い、その後にあらためてWindows Updateの適用を行い.NET Framework 4.6のインストールを行えばよい。
参考：
SharePoint 2013 Setup error if the .NET Framework 4.6 is installed
.NET Framework 4.6 がインストールされた環境でWindows SDK for Windows 7 and .NET Framework 4 の Visual C++ Compilers がインストールできない

フォトを初めとする、初期インストールされていたWindowsストアアプリが一切起動しなくなってしまった。起動すると「このアプリを開けません。フォトで問題が見つかりました。修復または再インストールについてはシステム管理者に問い合わせて下さい。」と表示される。
いくつかのサイトを参考にした結果、以下のような対応を試してみた。

WSRESETの実行

管理者権限でコマンドプロンプトを開き、WSRESET.EXEを起動する。WSRESETはWindowsストアの機能を初期化するコマンドです。これで復旧する例もあるようですが、復元しませんでした。

sfc /scannnowの実行

sfcは誤ってシステムファイルが変更されたりファイルが壊れてしまった場合、WindowsUpdate等の実行時に自動的に作成されているバックアップファイルを使用して、システムを復元するコマンドです。ですが特に異常は見つからず、状況は変わりませんでした。

dism /online /cleanup-image /restorehealthの実行

dismはWindowsを複数台にインストールする場合などに、OSの構成を自動化するためのツールです。コントロールパネルの「Windowsの機能の有効化または無効化」が対応します。この修復機能でWindowsの機能の有効化が上手く出来ていない場合には正常に戻るはずです。ですが特に異常は見つからず、状況は変わりませんでした。

Get-AppxPackageの実行

Powersehllを管理者権限で開き「Get-AppxPackage -AllUsers| Foreach {Add-AppxPackage -DisableDevelopmentMode -Register “$($_.InstallLocation)\AppxManifest.xml”}」を実行します。「Get-AppxPackage」はインストール済みのWindowsストアアプリを列挙するコマンドです。続く「Add-AppxPackage」で列挙したWindowsストアアプリを再インストールしています。
このコマンドを実行するといくつか「リソースが現在使用中であるため、パッケージをインストールできませんでした。」「新しいバージョンが既にインストールされていたため、パッケージをインストールできませんでした。」「パス ‘C:\AppxManifest.xml’ が存在しないため検出できません。 」と言ったエラーが表示されます。「もしやこのエラーが・・・と思ったのですが」詳細を調べてみると原因ではなさそうです。この方法でも状況は変わりませんでした。

システムの復元

システムの復元はWindows Updateやアプリケーションのインストールが行われる前に、自動的に作成されるレジストリ及びファイルのバックアップです。コントロールパネルの「システム」から「システムの保護」を選び、システムの復元ボタンを押して起動します。・・・ですが、残念な事に途中でエラーが発生して復元することが出来ませんでした。

システムの再インストール

残る手段はシステムの再インストールです。Windows 10ではスタートメニューの「設定」から「更新とセキュリティ」を選び「回復」タブを選択すると「このPCを初期状態に戻す」と言う項目があります。これを開始すると「データを残したまま再インストールする」か「データも破棄して再インストールする」かを選べますので「データを残したまま再インストールする」に進みます。以前のOSよりも手軽に再インストールできるようになっているのは良いのですが・・・これって解決方法じゃないよなぁ。

「WSUS 管理コンソールは、リモート API 経由で WSUS サーバーに接続できませんでした。 」と表示されて、Windows System Update Service（WSUS）の管理コンソールに接続できなくなった場合の対処方法です。

表示だけの問題であれば「%appdata%\Microsoft\MMC\」の下にあるwsusファイルを削除することにより、コンソールの保存される設定を削除することで接続出来るようになります。もしIIS、SQL、および Update Servicesが停止している場合には、サーバー上でこれらのサービスを起動します。それでも接続出来ない場合、WSUSのデータベースが破損している可能性があります。

WSUSはSQLServerでデータを管理しています。この時に使われるSQLServerはOSの機能の一つとして組み込まれているため導入にあたって意識することはありません。OSがフリーズした場合など、SQLServerが正常にシャットダウンできなかった場合は、起動後にデータベースの自動復旧を試みます。自動復旧に極端に時間がかかっている場合や、自動復旧中にエラーが発生すると、WSUSの管理コンソールが応答しない状態になります。

SQLServer Management Studioをインストールして接続先に’\\.\pipe\MICROSOFT##WID\tsql\query’を指定するとWSUSが使用しているSQLServerに接続出来ます。SUSDBと言うインスタンスがWSUSのデータベースです。修復中の場合は気長に待って下さい。修復に失敗している場合には手動で修復を試みるか、WSUSのサービスを再インストールすることになります。ただ・・・現実問題として、DBCC CHECKDBで修復したとしても整合性が失われる可能性が高く、OSのバックアップがない場合にはWSUSサービスの再インストールが現実解になるかと思います。

WSUSのサービスを再インストール場合、通常ならばサーバーマネージャーの「役割と機能の削除」からWSUS関連サービスを削除した後、OSを再起動すれば済みます。ですがSQLServerのSUSDBが破損しているため、サーバーマネージャーから削除しただけではデータベースの削除に失敗します。WSUSサービスを削除した後に、SQLServer Management Studioからデータベースを強制的に削除してください。また合わせて「更新プログラムの格納場所」となっているフォルダも削除します。

その後、あらためて「役割と機能の追加」からWSUSを導入すると正常に動作するようになります。もちろん必然的にWSUSの諸設定は失われますので、再度設定し直すことになります。コンピューターも一切登録されていない状態に戻りますが、クライアントPC側で次回WindowsUpdateが実施されるタイミングで再び追加されるので、追加されるのを待つことになります。

http://ophcrack.sourceforge.net/tables.php
ふと、今ならどの程度の長さのパスワードが妥当なのかなと思い見てみた。

ophcrackは有名なWindowsのログインパスワード解析ソフトです。レインボーテーブルというデータベースを使用することで効率よくパスワードの解析を行い、ターゲットとなるWindowsのハードディスクを接続した状態で起動すると数分～数時間でパスワードを調べてくれます。

提供されているレインボーテーブルで一番大きな物は Vista_eightXLで$949で販売されています。このテーブルを使えばWindowsのログインパスワードで大文字、小文字、数字、記号 を使ったパスワードの場合、８文字までは、短時間で解析可能って事になります。つまり、大文字、小文字、数字、記号 を使った場合は、最低でも9文字以上のパスワードにしないと気休めにもならないことを意味します。

会社のグループポリシーとしてパスワードを定める場合も９文字で良いのかというと、そこは微妙なところです。大文字、小文字、数字、記号 を使った良くある（クラック用のパスワード辞書に載ってるような）パスワードの場合、12文字まで対応したレインボーテーブルが提供されているからです。グループポリシーで「 複雑さの要件を満たす必要がある」に設定したとしても、 大文字、小文字、数字、記号のうち3種類以上を使うことを要求するだけで、パスワード辞書に載っているようなパスワードを設定出来なくなるわけではありません。最低でも13文字以上のパスワードを義務づけないと容易にクラック出来るパスワードを使われる可能性を排除できない事になります。

でも現実問題として13文字以上で大文字、小文字、数字、記号を使ったパスワードを諳んじたり、頻繁に入力するのはかなり厳しいですよね。現実的なところで、多要素認証でのローカルログイン導入が必須となりつつあるって事かな。Windows10なら顔認証とか、スマホ連携とか標準で対応できるしね。