VMwareのゲストOSを、Windows10からWindows11へアップグレード

 VMwareのゲストOSを、Windows10からWindows11へアップグレードしました。

・VMware workstation proのバージョンを、17に更新。

・仮想マシンのバージョン（ハードウェアの互換性）を17.xに変更。

・仮想マシンの「アクセスコントロール」項目で、暗号化。

・仮想マシンに、「Trusted Platform Module」を追加。

この状態で、仮想マシンのWindows10を起動する。

Windows PC 正常性チェックを行うと、Windows11をインストール可能と表示される。

これで、数日待つと、Windows Updateが、Windows11のインストールを促してくる。

1台目は、このまま、Updateで、Windows11へ更新できましたが、2台目は、いつまで待っても、Windows11がインストールできる状態になりませんでした。

仕方ないので、MicrosoftのHPで、"Windows 11 Installation Assistant"を検索して、ソフトウェアをダウンロードしました。

このソフトウェアを使って、Windows11へアップグレードしました。

ゲストOSでのWindows11の第一印象、ソフトの起動が、かなり、遅くなりました。

暗号化を無効にした方が良いかもしれません。

VMware Workstation 17 Pro 17.0.1 不具合

 VMware Workstation 17 Proを、17.0.1に更新したところ、不具合が発生しました。

仮想マシンに、Ubuntuを使っていますが、LANをブリッジに設定すると、ネットワークが繋がりません。

NATに変更すれば繋がります。

ブリッジ接続の場合、静的に設定すれば繋がるという情報もあります。

VMwareは、定期的に、この不具合が発生して困ります。

Thunderbird で、gmailを受信できなくなった

 メールソフトのThunderbirdで、gmailの受信ができなくなりました。

セキュリティで、はじかれるようです。

ブラウザで、gmailにアクセスすると、メールが届いていて、セキュリティではじかれた形跡がありました。

gmailのサーバー設定は、昔、設定した状態で使い続けていました。

おそらく、今年になって、古い設定でのアクセスを禁止したのでしょう。

サーバー設定を、新しい方法（OAuth2）に、変更しました。

（サーバー名も変更）

受信を行うと、ブラウザが開き、gmailのログインが促されました。

この後、3つの選択肢が表示され、これは、意味が分かりません。

とりあえず、真ん中の選択肢を選んだのが良くなかったのか、面倒なことになりました。

通常なら、パスワードを入力すれば、大丈夫だったのですが、スマートフォンのgmailアプリを使うように指示されました。

スマートフォンを持っていないと、設定できなくなったのでしょうか？

たぶん、アクセス記録に、iPhoneでのアクセスがあることから、こちらによる認証を優先したのだと思います。しかし、そうでなかったら、スマートフォンを持っていないと、今後は、Thunderbirdを利用できなくなります。

不安になったので、Supportページを見ました。

しかし、Gmailアカウントの設定方法は、youtube動画が、エラーを出していて、見ることができません。

これは、私と同じような状態になった人が、調べにきて、アクセスが集中しているのかもしれません。

仕方なく、もう一度、スマートフォンを用意して、設定をやり直しました。

Thunderbirdで受信を行うと、ブラウザが開きますから、ログインします。

次に、スマートフォンのgmailアプリを開きます。ブラウザのgmailを使ってはいけません。

すると、説明にあったように、数字の選択を指示されますから、正しい数字を選択しました。

これで、認証が行われ、無事に、設定を終えました。

Tunderbirdで、gmailを扱えるようになりました。

Windows11 マルチディスプレイで、ソフトを動かせない

 Windows11に移行できるパソコンは、全て、Windows10から移行しました。

残っているのは、ハードウェアの要件を満たさないものだけです。

Windows11にして、困ったこと。

ノートパソコンに外付けのモニタを繋ぎ、マルチディスプレイにしています。

外出先では、ノートパソコンのみとなります。

マルチディスプレイで、外付けのモニタ側に、ソフトを表示していると、ノートパソコンのみとなったとき、表示エリアから外れてしまい、ソフトが起動しているのに見えない状態になることがあります。

Windows10の時は、昔は、このような仕様でしたが、最近では、強制的にノートパソコン側のモニタに移動させるようになっていました。

それが、Windows11では、元に戻ってしまったようです。

Windows11では、マルチディスプレイ周りの設定が増えていますので、設定を変更すると良いのかもしれません。

このようなことになったとき、隠れてしまったソフトを、表示エリアに戻す方法は、

・下のタスクバーに表示されるソフトに、カーソルを合わせ、右クリックメニューから、「移動」を選択。カーソルで移動させる。

・下のタスクバーに表示されるソフトに、カーソルを合わせ、ソフトを選択。Shift+Win+カーソルキーの組み合わせで、動かす。

この2つの方法がありますが、これに対応していないソフトもあります。

こうなると、モニタを繋ぐ方法しか思いつきません。

OneDrive 接続に失敗 0x8004de40

 OneDriveでエラーが発生しました。

OneDriveに接続するときに問題が発生しました

インターネット接続を確認し、もう一度やり直してください。

エラーコード　0x8004de40

エラーコードは忘れましたが、こういったエラーは、しばしば発生しています。

経験的に、businessの方が、よく発生しているような気がします。

ノートパソコン（Windows10）と、デスクトップ（Windows11）で、同時発生。

今回は、デスクトップは、放置で解決。

ノートパソコンは、OSの更新で解決。

原因は謎です。

Windows10の更新 OneDriveで困った

 Windows10の更新がありました。

ダイアログで、OneDriveの項目があり、うっかり、設定を選択してしまいました。

私は、ノートパソコン、デスクトップ、仮想マシンと、複数のWindows10や、Windows11を持っています。

それぞれのデスクトップやドキュメントは、その環境に合わせた状態にしているのに、OneDriveをインストールすると、勝手に、共通にしようとしてきて困ります。

今回、Windows10の更新時に、メッセージが表示され、ブラウザの設定、Micorsoft365の購入などの画面が、次々に表示されました。

この中で、うっかり、OneDriveを持っているので、「利用する」という設定を選び、どうやら、OneDriveの設定が、初期化されてしまったようです。

デスクトップには、他の環境のアイコンが並び、OneDriveでは、競合が発生している様子。

だから、「こんな機能、デフォルトにするなよ」と、いつものように、怒りが。

OneDriveの設定変更と、競合の解決という、余計な手間が増えました。

それだけなら良かったのですが、大事なデータが消されてしまいました。

docker mysql用docker-compose.ymlの記述

 私なりのmysql用のdocker-compose.ymlの記述を決めました。

ここに至る経緯は、なかなか大変でした。

ファイル構成

docker-compose.yml

mysql/Dockerfile

mysql/mysql.env

mysql/conf/my.cnf

mysql/init/01_create_tables.sql

mysql.env

MYSQL_ROOT_HOST=%

MYSQL_ROOT_PASSWORD=パスワード

MYSQL_USER=ユーザー名

MYSQL_PASSWORD=パスワード

MYSQL_DATABASE=データベース名

docker-compose.yml

一部、抜粋

services:

  mysql:

    build:

      context: .

      dockerfile: ./mysql/Dockerfile

    container_name: コンテナ名

    env_file: ./mysql/mysql.env

    environment:

      - TZ=Asia/Tokyo

    expose: 

      - "3306"

    restart: always

    volumes:

      - mysqldata:/var/lib/mysql

Dockerfile

FROM mysql:8.0

COPY ./mysql/conf/* /etc/mysql/conf.d/

COPY ./mysql/init/* /docker-entrypoint-initdb.d/

ファイルの扱い

最初、Dockerfileを用意せず、docker-compose.ymlファイルのvolumesに、my.cnfファイルなどを記述していました。

例えば、

./mysql/conf:/etc/mysql/conf.d/:ro

この場合、コンテナ起動時に、my.cnfファイルが読まれず、エラーが発生しました。

ファイルのパーミッションを変更するか、コンテナ内のmysqlユーザーのUIDを、ファイル所有者と一致させるかすれば、エラーを回避できます。

しかし、この方法は、docker-compose buildを実行する前に、ファイルパーミッションの変更作業か、ファイル所有者のUIDを.envファイルに書き込む手間が必要になります。

後者は、工夫すれば、不要かもしれません。

windowsのWSLで開発し、linuxで実行することを考え、このあたりの処理を不要にするため、コンテナ内に、ファイルをコピーする方法で回避しました。

文字コードの設定

mysqlのコンテナでは、文字コードをutf8mb4に変更する必要があります。

mysql 8.0では、デフォルトの文字コードだと思っていましたが、コンテナでは、latain1になるので、設定変更が必要でした。

この変更は、my.cnfファイルを用意するか、docker-compose.ymlのcommand項目で設定できます。

my.cnfファイルの方が見やすくなるため、こちらの方法を採用しました。

他にも、ポートの公開方法、タイムゾーンの設定など、方法が複数ある中で、上記の記述を選びました。