スクリーンセーバーからの復帰に失敗するとき

本Tipsは

  • Windows10
  • ディスプレイドライバとしてIntel(R) HD Graphicsを使用している
  • 復帰時にパスワード入力を要求するように設定している
  • サービスとしてIntel(R) HD Graphics Control Panel Service(igfxCUIService)が動いている

状態で、

  1. スクリーンセーバー画面になっている または 省電力でディスプレイが落ちている
  2. Ctrl-Alt-Del押下
  3. 画面がフラッシュするが、パスワード入力画面に遷移せず、一切の操作ができなくなる

場合の対処法となります。

Step1(グラフィックスドライバの更新)

  1. 対象機に該当する最新版のIntel HD Graphicsのドライバーをダウンロードします
  2. 圧縮ファイルの場合、ダウンロードファイルの『プロパティ』で『ブロックの解除』を行ってから展開します
  3. PCをネットワークから切断します(有線/無線両方)
    ※ドライバーがネットワーク経由で再インストールされるのを防ぐため
  4. コントロールパネルの『プログラムのアンインストール』を開き、『インテル(R)グラフィックス・ドライバー』という項目をクリック、アンインストールします
  5. 再起動を要求された場合は再起動します
  6. デバイスマネージャーを開き、『ディスプレイアダプター』を開き、『Microsoft基本ディスプレイアダプター』になっていることを確認します
    ここでインテルのドライバーが残っている場合は、
    1. 当該ドライバーをダブルクリックします
    2. 『プロパティ』→『ドライバータブ』→『削除』と進みます
    3. 『このデバイスのドライバーソフトウェアを削除する』にチェックを入れ、『OK』をクリックします
    4. 念のためPCを再起動します
    5. 更にインテルのドライバーが残っている場合、『Microsoft基本ディスプレイアダプター』になるまで削除→再起動を繰り返します
  7. ダウンロードしたドライバーをインストールします

Step2(怪しいサービスを停止)

  1. Intel(R) HD Graphics Control Panel Serviceのスタートアップの種類を記録し、サービスを停止、スタートアップを無効化します
  2. 念のためPCを再起動します

これで様子を見て改善しない場合は、Step2で停止したigfxCUIServiceのスタートアップを元に戻して下さい。

ドライバーのアップデート(WindowsUpdateや手動)、OS自体のWindowsUpdateによって事象が再発するようになった場合は、この手順をふたたび試してみて下さい。

QUALYS SSL LABSのSSL Server Testで合格するために

QUALYS SSL LABSのSSL Server Testで合格するために気をつけておいた方が良いかと思われる、先日の『WebサイトのSSL化の時には中間証明書にも気をつけてあげて下さい』対応の時にも参考にした自分用メモです(最初にこれらのページにお世話になったのは、2018年5月6日という記録が残っていました)。

GCP上にDNSゾーンを一括処理で作ってみる

  • 緊急にDNSサーバを立ち上げなければならない場合を想定して作成しました
  • 『事前準備』と『作業環境構築』は(やっておいて損は無いので)事前に準備しておいて下さい
  • 『ゾーン作成』以降がイベント発生時の作業となります
  • CLIで流し込む方法を主に書いてあります
  • 2019/04時点での手順書です
  • whoisの更新は自由に出来るものとします

事前準備

Googleアカウントを作成します。

GCPコンソールにログインし、プロジェクトだけ作成しておいて下さい。

このテキストでは『my_zone』とします。

作業環境構築

WindowsPCを想定しています。

Node.jsやPythonを入れるのが面倒環境依存を排除するため、WSLで作成します。

ゾーン作成

GUIから可です。

CLIの場合は、(外部公開/非公開設定がbetaのみのため)betaコマンドで作成します。

gcloud beta dns managed-zones create --dns-name="my_domain." --visibility=public --description=my_zone my_zone
# ドメイン名
#   my_domain
# 外部公開
#   する
# ゾーン名
#   my_zone

ゾーン内容のフラッシュ

# 一括削除はCLIから行います
touch empty-file
gcloud dns record-sets import -z my_zone --delete-all-existing empty-file

ゾーンの削除

# ゾーンをクリアしてから削除します
touch empty-file
gcloud dns record-sets import -z my_zone --delete-all-existing empty-file
gcloud dns managed-zones delete my_zone

レコード一括追加

gcloud dns record-sets transaction start   -z=my_zone
gcloud dns record-sets transaction add     -z=my_zone --name="ns1.my_domain."  --type=A     --ttl=300 "192.168.0.1"
gcloud dns record-sets transaction add     -z=my_zone --name="ns2.my_domain."  --type=A     --ttl=300 "192.168.0.2"
gcloud dns record-sets transaction add     -z=my_zone --name="www.my_domain."  --type=A     --ttl=300 "192.168.0.3"
gcloud dns record-sets transaction add     -z=my_zone --name="mx1.my_domain."  --type=A     --ttl=300 "192.168.0.4"
gcloud dns record-sets transaction add     -z=my_zone --name="mx2.my_domain."  --type=A     --ttl=300 "192.168.0.5"
gcloud dns record-sets transaction add     -z=my_zone --name="test.my_domain." --type=CNAME --ttl=300 "www.my_domain."
gcloud dns record-sets transaction add     -z=my_zone --name="my_domain."      --type=MX    --ttl=300 "10 mx1.my_domain." "100 mx2.my_domain."
gcloud dns record-sets transaction execute -z=my_zone

レコード一括追加中断

# 一括処理中にエラーが出たり誤りを見付けた時
# 一旦中断しないと以後の作業に差し支えが出ます
gcloud dns record-sets transaction abort -z=my_zone

Windows10側からWSLファイルシステム内へアクセスしてみるテスト

ビルド18342から、WSL側のファイルシステムへのアクセスが可能になったようです。

で、試してみたのですが、一瞬躓いたので、メモしておきます。

条件

  • WSLは予め起動しておくこと
  • 仮想ネットワークホスト『wsl$』だけではアクセスができない
    ディストリビューション名まで指定する必要あり

実行結果

C:\>wslconfig /list
Windows Subsystem for Linux ディストリビューション:
Legacy (既定)
WLinux
Ubuntu-18.04

C:\>dir \\wsl$
ファイル名、ディレクトリ名、またはボリューム ラベルの構文が間違っています。

C:\>dir \\wsl$\Legacy
 ドライブ \\wsl$\Legacy のボリューム ラベルがありません。
 ボリューム シリアル番号は 0000-0000 です

 \\wsl$\Legacy のディレクトリ

2018/02/23  14:13    <DIR>          .
2018/02/23  14:13    <DIR>          ..
2018/05/14  11:16    <DIR>          bin
2017/03/30  18:59    <DIR>          boot
1970/01/01  09:00    <DIR>          cache
1970/01/01  09:00    <DIR>          data
2019/05/30  09:02    <DIR>          dev
2019/05/30  09:02    <DIR>          etc
2018/02/23  14:21    <DIR>          home
1970/01/01  09:00           591,344 init
2018/02/23  14:35    <DIR>          lib
2018/02/23  14:32    <DIR>          lib64
2017/03/30  18:55    <DIR>          media
2018/02/23  14:13    <DIR>          mnt
2017/03/30  18:55    <DIR>          opt
2019/05/30  09:02    <DIR>          proc
2018/05/14  11:30    <DIR>          root
2019/05/30  09:02    <DIR>          run
2019/05/29  07:57    <DIR>          sbin
2017/02/24  22:24    <DIR>          snap
2017/03/30  18:55    <DIR>          srv
2019/05/30  09:02    <DIR>          sys
2018/05/14  11:19    <DIR>          tmp
2017/03/30  18:55    <DIR>          usr
2017/03/30  18:58    <DIR>          var
               1 個のファイル             591,344 バイト
              24 個のディレクトリ  41,269,194,752 バイトの空き領域

C:\>
エクスプローラーのURL欄にwsl$と入力したところ
エクスプローラーのURL欄にwsl$と入力したところ
そこからUbuntu-18.04を選んだところ
そこからUbuntu-18.04を選んだところ

ネットワークドライブに再接続できませんでした

Windows 10 May 2019 Update 1903 (19H1)にしたところ、net use /persistent:yes で行っているネットワークドライブへの接続が出来なくなってしまいました。

但し、全数起こるわけではなく、現象が出る個体と出ない個体があるようです。

ネットワークドライブに再接続できませんでした
ネットワークドライブに再接続できませんでした

近日中にパッチが出るかも知れませんが、2019/05/22更新のマイクロソフトのページを参考に、対応しました。

Web 共有にマップされているネットワーク ドライブにアクセスしようとするときに”ユーザーが認証されていないというエラー
“User has not been authenticated”error when you try to access a network drive that’s mapped to a web share

処置

次のように設定されているものとします。

net use x: \\CIFS_Server\path password /user:username /persistent:yes
  1. レジストリエディタを起動します
  2. 次のサブキーに移動します
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
    値を追加するレジストリの位置
    値を追加するレジストリの位置
  3. Parametersを右クリックした状態で、新規→複数行文字列値、と進みます
    複数行文字列値を挿入
    複数行文字列値を挿入
  4. 『新しい値 #1』という項目が出来るので、『AuthForwardServerList』という名前に変更します
  5. 『AuthForwardServerList』をダブルクリックします
  6. 値のデータとして、『https://CIFS_Server』を入力します
    値を挿入
    値を挿入
  7. OKボタンを押下します
  8. レジストリエディタを終了します
  9. ネットワークドライブを再接続します
    net use x: /delete
    net use x: \\CIFS_Server\path password /user:username /persistent:yes
  10. OSを再起動して動作を確認します

うまく行くといいですね…。


2019.06.05追記
この処置を行ってうまく行った数日後、再度『ネットワークドライブに~』が出たときは、エクスプローラから×印が付いたネットワークドライブに(切断や再マウント処理をせずに)アクセスしてみてください。そのまま繋がると思います。

2019.06.12追記
2019年6月パッチのKB4503293で改善されるかと思ったのですが、やはり『ネットワークドライブに~』が出てしまい、コマンドプロンプト側からのアクセスが出来ない状態です(エクスプローラ側から一旦アクセスすれば、使えるようですが)。