Amazonで1万5千円だったタッチ対応モバイル液晶を買ったらペンタブにもなった件


twitterでAmazonで1万5千円だったタッチ対応モバイル液晶を買ってメーカー名のロゴを剥がしたらLenovoと書いてあった、というのを見た。

注意:この記事は既にワコムAESペンを持っている人を対象に書いています。(AESペンは6千円~1万円ちょいで買えます)

<今回届いた液晶はLenovoのペン対応タッチパネル液晶でしたが、Amazonのレビューを見るとLenovoのロゴがないものもあるようです。その場合ペン動作がするのかどうかは不明です。たぶんガラス部分に印字されてないバージョンなだけだとは思いますが…>

調べて見ると、Lenovoが保守用に販売している液晶を流用してモバイル液晶のケースに入れたものらしい。

興味を持ったので探してみると発見

表示は21999円となっているが、7/14 7/31 8/31までクーポンで7000円引きとなっていて 14999円である。

Visual Beat モバイルモニターモバイルディスプレイ13.3インチ FHD 1080p 2024/01/25現在 15999円

じゃあ、Lenovoの何の製品で使われているのか?

「13.3インチ」「10点タッチ」あたりで調べて見るとLenovo ThinkPad Yoga 730あたりで使われているやつじゃないかなーとあたりを付けた。

もし、この液晶であるならワコムAESペンが使えるはずなのでは?ということで買ってみた。

裏面にはVESAマウント用の穴もある。

まずは普通にHDMIモニタとして使えることを確認

続いて気になる左下のシールを剥がしてみます。

Lenovo!

続いてタブレットとしてつなげてみます。

Type-C 1本でディスプレイ出力もできるDisplayPort Alternate Mode対応のノートパソコンなどは「通信用C」とパソコンをType-Cケーブルで繋ぎます。「電源用C」にUSB PD電源アダプタをつなげるとパソコンへの電源供給も可能です。

HDMI出力しかないパソコンに繋いで液晶タブレットとして使うには、まず、「通信用C」と「パソコン」を「Type-Cコネクタ<=>Aコネクタ」のケーブルで繋ぎます。
繋いだあとで、miniHDMIケーブルをさすとパソコン側で認識してくれます。

なお、HDMI接続でタブレットとして使おうとした場合、おかしなUSBデバイス認識となる場合があります。その場合はケーブルを抜いて30秒程度放置したあと、USBケーブルから先に繋いで見てください。

(おそらく、Type-Cケーブル1本で繋ぐと誤認されてしまってDisplayPort Alternate Mode用に内部設定を変えて通信を行おうとするもののネゴシエーションに失敗しておかしなUSBデバイスになっている。)

次に、Windows 10の場合、Windows Inkの設定を変更して、「ペンの使用中はタッチ入力を無視する」にチェックを入れておくといいと思います。(ペンで操作中に画面に手が当たると、手で操作した、という扱いになるため)

この設定項目がない場合は後述のWacomのドライバを追加インストールすると現れると思いますので、インストール後に設定してください。

さて、この液晶タブレット、ワコムのAESペンが使えます。

これは「Wacom One」、「raytrektabなど一部のWindows タブレット」、「Samsung のタブレット(Sペン)」「BOOXのAndroidタブレット」と互換性があるペンです。

すみません↑の記述は誤認していました。

Bamboo Ink が入手しやすいものとなります。

うちにあったWACOM Bamboo Ink CS321AKをAESモードにして試してみます。

kritaで試してみたのですが、少し遅めな反応ですね。

他にDELL アクティブペン PN556W/750-AANM でも動きました。(PN556Wは電池が単6と特殊なボタン電池2個が必要なのでお薦めしません)

いま入手できて、単6電池1本で動くあたり、となるとBamboo Ink(CS323AG0C) か DELL アクティブペン PN5122W あたりが良さそうに見えます。

USB充電式としてはBamboo Ink Plus CS322AK0C ですかね

Wacomの販売ページ
 USB充電式「Bamboo Ink Plus CS322AK0C」12,650円
 単6電池1本式「Bamboo Ink 2nd generation CS323AG0C」 6,050円

ヨドバシでの販売ページ
 USB充電式「ワコム WACOM CS322AK0C [Bamboo Ink Plus]」 10,800円
 単6電池1本式「ワコム WACOM CS323AG0C [Bamboo Ink]」 5,830円

aliexpressで見つけた謎のType-Cコネクタで充電できるStylus Penも動作しました
 買ったセラー「PN556W 2048 Rechargeable Stylus Pen for Dell Latitude 7285 7390 7400/ for HP Elite X2 1012 G1 G2 G3 G4 G5 G6 1020 EliteBook」$14.79
 その他のセラー「Active Stylus Digital Stylus Pen Pressure Sensitivity Stylus Pen for HP Elite X2 1012 G1 G2 G3 G4 G5 EliteBook」$14.25

なお、ペンが全然反応しない、という場合は、Windowsのディスプレイ設定を開いてタブレット側を「メインディスプレイ」にしてみてください。(うちは1枚目のディスプレイがタッチ操作対応だったのでこれを設定しないとうまく動きませんでした)

どちらの番号がタブレットなのか分からない場合は「識別」をクリックすると画面上に番号が表示されますので、それで判断してください。

選択したあと、下の方にある「マルチディスプレイ」のところにある「これをメインディスプレイにする」にチェックを入れます。

無事ペンも使えるようになった状態というのは、Windows Ink / Tablet APIのタブレットとして動作している、という状態です。

これは最近の絵描きソフトであればだいたい対応している動作モードです。

ここにワコムが提供している「Wacom Components Driver version: 7.7-61」をインストールすると、SAI ver1などのWinTab API対応の古めのソフトも動くようになります。

2023/08/15追記:設定状況によっては「Lenovo Pen Settings Driver」じゃないと認識しない場合があるようです。(version 7.7-111にて遭遇)

また、インストールすることによりデバイスの認識も変わります。

デバイスのインスタンスパスを一部公開

Wacom Components DriverにはAESペンの細かい設定を行えるソフトもインストールされます。

このため、他に使用している液晶タブレットが無い場合や、Wintab.dllの競合問題が発生しないような場合は、できる限りインストールしておいた方がいいと思います。

なお、普通の液晶ペンタブレットだとペンの位置と画面上のカーソルの位置を合わせるためのキャリブレーション用のソフトウェアがありますが、そういったものが無いようです。(見つけられなかった)

人間側で補正する必要があるので繊細な人には向かないかもしれません。

Oracle Cloud上のLinuxサーバからOracle Cloudのオブジェクトストレージをs3fsを使ってファイルシステムとして使う


Oracle Cloud上で運用しているファイルサーバのディスク使用率がいつのまにか96%を超えていた。

え?と思って調べてみたら、外部コンテンツを取り込む際に、コンテンツのバージョンも残しておこうと軽い気持ちで設定したgitが容量を使っていた。

遅くてもいいや、ということで、使っていない50GBのオブジェクトストレージ領域をs3fsでファイルシステムとして使うこととした。

参考文献
s3fs配布元
・Oracle Cloud Infrastructure Blog「Mounting an Object Storage Bucket as File System on Oracle Linux
・Oracle Cloud Infrastructureドキュメント「Amazon S3互換API
・Cloudii「Oracle Cloud オブジェクトストレージをOracle Linuxのファイルシステムとして直接マウントする方法。

基本的には、Oracle Cloud Infrastructure Blogの記述通りにやるだけなのだが、いろいろ勘違いしていて上手くいかなかった。

手順0: Oracle Cloud上でバケット作成

Oracle blog上では手順に書かれていないので手順0として書きます。

オブジェクトストレージにてバケットの作成を行います。

バケット作成後にバケットの詳細を確認し、一般のところにある「ネームスペース」もあとで使用します。

手順1: s3fs-fuseをインストール

epelを有効にしている状態であれば、「yum install s3fs-fuse」を実行するだけでインストール完了。

# yum install s3fs-fuse
読み込んだプラグイン:langpacks, ulninfo
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> パッケージ s3fs-fuse.x86_64 0:1.91-1.el7 を インストール
--> 依存性の処理をしています: fuse >= 2.8.4 のパッケージ: s3fs-fuse-1.91-1.el7.x86_64
--> 依存性の処理をしています: fuse-libs >= 2.8.4 のパッケージ: s3fs-fuse-1.91-1.el7.x86_64
--> 依存性の処理をしています: libfuse.so.2(FUSE_2.2)(64bit) のパッケージ: s3fs-fuse-1.91-1.el7.x86_64
--> 依存性の処理をしています: libfuse.so.2(FUSE_2.5)(64bit) のパッケージ: s3fs-fuse-1.91-1.el7.x86_64
--> 依存性の処理をしています: libfuse.so.2(FUSE_2.6)(64bit) のパッケージ: s3fs-fuse-1.91-1.el7.x86_64
--> 依存性の処理をしています: libfuse.so.2(FUSE_2.8)(64bit) のパッケージ: s3fs-fuse-1.91-1.el7.x86_64
--> 依存性の処理をしています: libfuse.so.2()(64bit) のパッケージ: s3fs-fuse-1.91-1.el7.x86_64
--> トランザクションの確認を実行しています。
---> パッケージ fuse.x86_64 0:2.9.4-1.0.9.el7 を インストール
---> パッケージ fuse-libs.x86_64 0:2.9.4-1.0.9.el7 を インストール
--> 依存性解決を終了しました。

依存性を解決しました

===================================================================================================================================
 Package                     アーキテクチャー         バージョン                        リポジトリー                          容量
===================================================================================================================================
インストール中:
 s3fs-fuse                   x86_64                   1.91-1.el7                        ol7_developer_EPEL                   257 k
依存性関連でのインストールをします:
 fuse                        x86_64                   2.9.4-1.0.9.el7                   ol7_latest                            88 k
 fuse-libs                   x86_64                   2.9.4-1.0.9.el7                   ol7_latest                            97 k

トランザクションの要約
===================================================================================================================================
インストール  1 パッケージ (+2 個の依存関係のパッケージ)

総ダウンロード容量: 442 k
インストール容量: 1.1 M
Is this ok [y/d/N]: y
Downloading packages:
<略>
インストール:
  s3fs-fuse.x86_64 0:1.91-1.el7

依存性関連をインストールしました:
  fuse.x86_64 0:2.9.4-1.0.9.el7                                 fuse-libs.x86_64 0:2.9.4-1.0.9.el7

完了しました!
#

手順2: 認証情報の設定

Oracle Cloudにログインした状態で右上のユーザアイコンから[プロファイル]-[ユーザー設定]を選択します。

画面が変わって、下の方にある[リソース]-[顧客秘密キー]を選択します。

この「顧客秘密キー」がS3 compatibleとして使う場合の認証情報となります。

「秘密キーの生成」をクリックして、何か名前を決めて作成します。

次の画面で表示される「生成されたキー」は「SECRET_ACCESS_KEY」として使いますので、かならず「コピー」してください。

これを忘れた場合は再作成する必要があります。

なお、キーはこんな感じですね。

で・・・Oracle blogだとACCESS_KEY_IDは何を使えばいいのかハッキリ書いていないので、しばらく名前として設定したs3-accessを使ってアクセスを試みていました。

正しくは上記の「アクセスキー」のところの文字列を使います。

Oracle blogでは下記の様に個人ユーザのディレクトリに認証情報を配置しています。

$ echo ACCESS_KEY_ID:SECRET_ACCESS_KEY > ${HOME}/.passwd-s3fs
$ chmod 600 ${HOME}/.passwd-s3fs

今回は個人用ではなく起動時から使えるような形にしたいので /etc/passwd-s3fs として設定しました。

# echo ~b66e06:KZyW~~~BDho= >  /etc/passwd-s3fs 
# chmod 600  /etc/passwd-s3fs 
#

手順3: マウントする

Oracle blogでは個人権限でマウントするための下記が書かれています。

$ s3fs [bucket] [destination directory] -o endpoint=[region] -o passwd_file=${HOME}/.passwd-s3fs -o url=https://[namespace].compat.objectstorage.[region].oraclecloud.com/ -onomultipart -o use_path_request_style

最初はアクセスできることを検証するため、このコマンドで実行します。

各要素は以下のようになっています。

[bucket]=手順0で作成したバケット名
[destination directory]=ローカルLinuxのマウントポイント
[namespace]=手順0で作成したバケットの詳細で確認できるネームスペース

テストとしてホームディレクトリ内にあるs3fsというディレクトリにマウントするべく実行

$ s3fs tw~t ./s3fs -o endpoint=us-phoenix-1 -o passwd_file=/etc/passwd-s3fs -o url=https://ax~b7.compat.objectstorage.us-phoenix-1.oraclecloud.com -onomultipart -o use_path_request_style
fuse: failed to exec fusermount: Permission denied
$

これはfusermountに権限がないためマウントできないというもので、下記で対処します。

$ sudo chmod a+x /usr/bin/fusermount
$ 

再実行

$ s3fs tw~t ./s3fs -o endpoint=us-phoenix-1 -o passwd_file=/etc/passwd-s3fs -o url=https://ax~b7.compat.objectstorage.us-phoenix-1.oraclecloud.com -onomultipart -o use_path_request_style
$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         460M     0  460M    0% /dev
tmpfs            486M  380K  486M    1% /dev/shm
tmpfs            486M   19M  467M    4% /run
tmpfs            486M     0  486M    0% /sys/fs/cgroup
/dev/sda3         39G   37G  2.0G   95% /
/dev/sda1        200M  7.4M  193M    4% /boot/efi
tmpfs             98M     0   98M    0% /run/user/0
tmpfs             98M     0   98M    0% /run/user/993
tmpfs             98M     0   98M    0% /run/user/1001
$

マウントされていない??/var/log/messages を確認すると認証情報の関連でマウントに失敗していました。

Jul  9 23:07:06 oralinux s3fs[22545]: s3fs version 1.91(unknown) : s3fs -o endpoint=us-phoenix-1 -o passwd_file=/etc/passwd-s3fs -o url=https://ax~fb7.compat.objectstorage.us-phoenix-1.oraclecloud.com -onomultipart -o use_path_request_style twsearch-git ./s3fs
Jul  9 23:07:06 oralinux  s3fs[22545]: Loaded mime information from /etc/mime.types
Jul  9 23:07:06 oralinux  s3fs[22546]: init v1.91(commit:unknown) with OpenSSL
Jul  9 23:07:06 oralinux  s3fs[22546]: s3fs.cpp:s3fs_check_service(3572): Failed to connect by sigv4, so retry to connect by signature version 2.
Jul  9 23:07:06 oralinux  s3fs[22546]: s3fs.cpp:s3fs_check_service(3584): Bad Request(host=https://ax~fb7.compat.objectstorage.us-phoenix-1.oraclecloud.com) - result of checking service.

これは /etc/passwd-s3fsに書いた access-key定義が誤っていた場合のログです。

修正して再実行すると今度はマウントできました。

$ s3fs tw~t ./s3fs -o endpoint=us-phoenix-1 -o passwd_file=/etc/passwd-s3fs -o url=https://ax~b7.compat.objectstorage.us-phoenix-1.oraclecloud.com -onomultipart -o use_path_request_style
$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         460M     0  460M    0% /dev
tmpfs            486M  400K  486M    1% /dev/shm
tmpfs            486M   19M  467M    4% /run
tmpfs            486M     0  486M    0% /sys/fs/cgroup
/dev/sda3         39G   37G  1.9G   96% /
/dev/sda1        200M  7.4M  193M    4% /boot/efi
tmpfs             98M     0   98M    0% /run/user/0
tmpfs             98M     0   98M    0% /run/user/993
tmpfs             98M     0   98M    0% /run/user/1001
s3fs              16E     0   16E    0% /home/users/s3fs
$

成功した場合は /var/log/messagesは下記の様な感じでした

Jul  9 23:30:18 oralinux s3fs[23933]: s3fs version 1.91(unknown) : s3fs -o endpoint=us-phoenix-1 -o passwd_file=/etc/passwd-s3fs -o url=https://ax~fb7.compat.objectstorage.us-phoenix-1.oraclecloud.com -onomultipart -o use_path_request_style twsearch-git ./s3fs
Jul  9 23:30:18 oralinux s3fs[23933]: Loaded mime information from /etc/mime.types
Jul  9 23:30:18 oralinux s3fs[23936]: init v1.91(commit:unknown) with OpenSSL
Jul  9 23:30:26 oralinux systemd: Configuration file /etc/systemd/system/oracle-cloud-agent.service is marked executable. Please remove executable permission bits. Proceeding anyway.

ただ、この設定だとs3fsを実行したユーザだけがアクセスでき、他のユーザではアクセスできません。

これは「allow_other」というオプションをつけることでアクセスできるようになります。

手順4: /etc/fstab に書く

再起動してもマウントされるようにするには /etc/fstab に書きます。 (/etc/rc.local とかに書く、という手順は不適切です)

上記で使った例であれば /etc/fstab に下記の様に書きます。

tw~it /home/users/s3fs fuse.s3fs use_path_request_style,url=https://axd~fb7.compat.objectstorage.us-phoenix-1.oraclecloud.com,use_path_request_style,_netdev,allow_other

これで、再起動してもマウントされるようになりました。

Windows Server 2008 SP2のWindows Updateがうまくいかない件への対処策 2022/07/07版


検証用にWindows Server 2008 SP2 (64bit)環境を新規でつくろうとすると、2022/07/07時点ではかなり面倒でした。

問題点1: ルート証明書が期限切れで使えないものばかりなのでhttps通信ができない
問題点2: Windows Updateの仕組みが古いためWindows Updateで更新プログラムが取得出来ない
問題点3: Internet Explorer 9のインストーラの入手方法が分かりづらい
問題点4: Windows Updateができるようになっても10~30個ぐらい残したところでそれ以上進まないように見える

また、 WSUS Offline Update というオフライン適用のためのソフトがあります。

これのESR version 11.9.1 は Windows Server 2008 に対応しているので、アップデートISOを作成することができます。しかし、実行してみると証明書のエラーによりスクリプト処理が失敗しパッチの適用ができません。(ルート証明書の更新とWindows Updateの対応は行われます)

このような状況下でいかにしてWindows Updateを行うか、ということを検証しました。

問題点1: ルート証明書が期限切れで使えないものばかりなのでhttps通信ができない

これはかなり深刻な問題です。

詳細は「初期インストール状態のWindows Server 2008 SP2のルート証明書を更新する 2022/07/07版」を参照のこと

ルート証明書の問題だけを対処するのであれば上記記事の手順を実行なのですが、後述の問題点2を解決すると同時に問題点1も解決されます。

問題点2: Windows Updateの仕組みが古いためWindows Updateで更新プログラムが取得出来ない

Windows Updateを実行すると「新しい更新プログラムを検索できませんでした」「エラーコード 80072EFD」で失敗します。

こちらはルート証明書の問題とWindows Updateの仕組みが古いための合わせ技です。(Windows UpdateサイトがTLS1.0/1.1アクセスを廃止したことなどが影響)

いろいろ調査したところ、更新プログラムを適用することでWindows Updateが可能になった。

なお、毎回再起動が求められるが、6個適用してから再起動でも問題なかった。

(1個目) KB3205638

KB3205638は何故かWindows Server 2008 for x64-Based System用だけない けどVista x64用の windows6.0-kb3205638-x64_a52aaa009ee56ca941e21a6009c00bc4c88cbb7c.msu が適用できた。再起動はしない。

(2個目) Windows Server 2008 for x64-Based Systems 用セキュリティ更新プログラム (KB4012583)

windows6.0-kb4012583-x64_f63c9a85aa877d86c886e432560fdcfad53b752d.msu を適用。再起動はしない。

(3個目) Windows Server 2008 for x64-Based Systems 用セキュリティ更新プログラム (KB4022887)

windows6.0-kb4022887-x64_18ce762c6a6b021444844fff1bf787a137f384dd.msu を適用。再起動はしない。

(4個目) Windows Server 2008 for x64-Based Systems 用セキュリティ更新プログラム (KB4022883)

windows6.0-kb4022883-x64_ca51e3905658274dc222d06096f9f63e9f70bac2.msu を適用。再起動はしない。

(5個目) Windows Server 2008 for x64-Based Systems 用セキュリティ更新プログラム (KB4493730)

windows6.0-kb4493730-x64_5cb91f4e9000383f061b80f88feffdf228c2443c.msu を適用。再起動はしない。

(6個目) 2019-09 x64 ベース システム用 Windows Server 2008 のセキュリティ更新プログラム (KB4474419)

windows6.0-kb4474419-v4-x64_09cb148f6ef10779d7352b7269d66a7f23019207.msu を適用

そして、再起動実施。

これでWindows Updateが可能となる。

問題点3: Internet Explorer 9のインストーラの入手方法が分かりづらい

Windows Updateが実行できる状態になればWindows Updateからインストールを行うことはできます。

Internet Explorer 9だけを取り急ぎインストールしたい場合、ダウンロードURLとインストールに必要な前提条件が非常に分かりづらい状態となっています。

詳細は「Windows Server 2008 SP2にInternet Explorer 9をインストールする 2022/07/06版」を参照してもらうとして、最低限必要なことだけはここに書きます。

(1個目) KB2117917

windows6.0-kb2117917-x64_655a21758801e9648702791d7bf30f81b58884b3.msu を適用。再起動はしない。

(2個目) KB2506014

windows6.0-kb2506014-x64_e4a62be05adf6d07841dd3df49fb5d63d1d3ba05.msu を適用。再起動はしない。

(3個目) KB971512

windows6.0-kb971512-x64_0b329b985437c6c572529e5fd0042b9d54aeaa0c.msu を適用。再起動はしない。

(4個目) KB2999226

windows6.0-kb2999226-x64_0befbb0b78588f7c9f17ead1da3abeda2b6f4c7f.msu を適用

再起動を実施。

(5個目) Internet Explorer 9をインストール

Microsoft Updateカタログで「Internet Explorer 9 2008用」を検索して3ページ目に出てくる「x64 ベース システム Windows Server 2008 用 Windows Internet Explorer 9」から「wu-ie9-windowsvista-x64_f599c02e7e1ea8a4e1029f0e49418a8be8416367.exe」を適用してインストール。

再起動を実施。

問題点4: Windows Updateができるようになっても10~30個ぐらい残したところでそれ以上進まないように見える

Internet Explorer 9をインストールしている場合、残り29個ぐらいのところでそれ以上更新バーが動かなくなる。

内部処理に問題があるようで、複数回実施しても似たような箇所で止まります。

ここで「インストールの停止」をクリックしてもうまく停止されませんでした。

いろいろ検証したところ、止まったように見える表示のままWindows OSの再起動を行うことで、処理が進むことが多い様なことがわかりました。ただ、処理に結構時間がかかるようで1時間程度は見込んでください。

再起動が完了すると、だいたい30個ぐらいが未適用な状態となっています。

引き続きWindows Updateを行って最新としてください。

ただ、この停止処理がうまく動かない状態で再起動もできない状態となることも多かったです。そのような場合は電源を強制オフするしかなくなるのですが、その場合は、ロールバック処理が行われました。

穏当に実行するのであれば、Windows Updateを行う際、日付順でソートして、新しいものから30個ぐらいを非適用とすることで現象を回避できるようです。

いろいろ検証した結果、2017/09/12 より後の日付の更新を全て除外することでWindows Updateで止まることはなくなりました。

初期インストール状態のWindows Server 2008 SP2のルート証明書を更新する 2022/07/07版


2022/07/07時点でWindows Server 2008 SP2を新規インストールすると、OSが持っているルート証明書の有効期限が1つ残りして他は切れています。

この結果、何がおこるかと言えば、Windows Update に失敗します。

これはWindows Updateは SSL証明書を使用する https通信を利用していて、いま残っているルート証明書だけでは目的とするサイトにアクセスできないために発生しています。

WIndows Server 2008 R2であればルート証明書の更新プログラムが提供されているのですが、Windows Server 2008には有りません。

いろいろ調べていくとASHER TOOLSの「Root Certificate Updater」というのを発見しました。

こちらPower Shellスクリプトとして作成されており github にてソースコードが公開されています → https://github.com/asheroto/Root-Certificate-Updater

内容を確認すると至って簡単で、要約すると以下を実行しているだけです。

rem 信頼できるルート証明書をダウンロード
certutil -urlcache -f http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab authrootstl.cab

rem 信頼されていない証明書をダウンロード
certutil -urlcache -f http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab disallowedcertstl.cab

rem ダウンロードしたcabファイルを展開
expand authrootstl.cab -R .\
expand disallowedcertstl.cab -R .\

rem 証明書を登録
certutil -addstore -f root authroot.stl
certutil -addstore -f disallowed disallowedcert.stl

実際に実行してみます。

Microsoft Windows [Version 6.0.6002]
Copyright (c) 2006 Microsoft Corporation.  All rights reserved.

C:\Users\Administrator>mkdir t

C:\Users\Administrator>cd t

C:\Users\Administrator\t>certutil -urlcache -f http://ctldl.windowsupdate.com/ms
download/update/v3/static/trustedr/en/authrootstl.cab authrootstl.cab
****  Online  ****
CertUtil: -URLCache コマンドは正常に完了しました。

C:\Users\Administrator\t>certutil -urlcache -f http://ctldl.windowsupdate.com/ms
download/update/v3/static/trustedr/en/disallowedcertstl.cab disallowedcertstl.ca
b
****  Online  ****
CertUtil: -URLCache コマンドは正常に完了しました。

C:\Users\Administrator\t>expand authrootstl.cab -R .\
Microsoft (R) File Expansion Utility  Version 6.0.6001.18000
Copyright (c) Microsoft Corporation. All rights reserved.

.\authroot.stl を展開キューに追加しています

ファイルを解凍しています...

ファイルの解凍が完了しました...

C:\Users\Administrator\t>expand disallowedcertstl.cab -R .\
Microsoft (R) File Expansion Utility  Version 6.0.6001.18000
Copyright (c) Microsoft Corporation. All rights reserved.

.\disallowedcert.stl を展開キューに追加しています

ファイルを解凍しています...

ファイルの解凍が完了しました...

C:\Users\Administrator\t>certutil -addstore -f root authroot.stl
root
証明書 "CN=Microsoft Certificate List CA 2011, O=Microsoft Corporation, L=Redmon
d, S=Washington, C=US" がストアに追加されました。
証明書 "CN=Microsoft Certificate Trust List Publisher, O=Microsoft Corporation,
L=Redmond, S=Washington, C=US" がストアに追加されました。
CertUtil: -addstore コマンドは正常に完了しました。

C:\Users\Administrator\t>certutil -addstore -f disallowed disallowedcert.stl
disallowed
証明書 "CN=Microsoft Certificate List CA 2011, O=Microsoft Corporation, L=Redmon
d, S=Washington, C=US" がストアに追加されました。
証明書 "CN=Microsoft Certificate Trust List Publisher, O=Microsoft Corporation,
L=Redmond, S=Washington, C=US" がストアに追加されました。
CertUtil: -addstore コマンドは正常に完了しました。

C:\Users\Administrator\t>

実行後はOSの再起動が必須です。

再起動後 certmgr.msc を実行して確認すると有効期限が切れていない証明書が増えています。

これでWindows Updateもうまくいことでしょう!

あれ?

次!

エラーコード 80072efeで検索すると「Windows Server 2008 R2 でWindows Updateが実行できない」というのを発見

こちらはWindows Server 2008 R2の事例ですが、「トランスポート層セキュリティ 1.0 および 1.1 の無効化」によりTLS1.0/TLS1.1アクセスが廃止されたためにアクセスできないのでは?という推測から対処を行っているが、KB3140245 はWindows Server 2008に対応して折らず、またレジストリを設定してみても状況は変わらない。

お手上げになったのでとりあえずWSUS Offline Updateを適用してみて、何のパッチが増えたのかを確認

まず、ルート証明書が増えている

しかし、WSUS Offline Update実行中にKB???? といったファイルが8個ぐらい適用されたような感じだったのに、更新履歴にはない

しかし、Windows Updateはできるようになった。

WSUS Offline Updateのログは %SystemRoot%\wsusofflineupdate.log にあるので確認してみる

2022/07/07 17:23:37.24 - Info: Started service 'Windows Update' (wuauserv)
2022/07/07 17:23:39.39 - Info: Installed ..\w60-x64\glb\windows6.0-kb3205638-x64_e32da6effffd299aaacb0f293602c7e55832bfad.cab
2022/07/07 17:23:45.73 - Info: Installed ..\w60-x64\glb\windows6.0-kb4012583-x64_e881e527ca32b3c47b008fd42ea1ecc87c017a71.cab
2022/07/07 17:23:47.38 - Info: Installed ..\w60-x64\glb\windows6.0-kb4022887-x64_fb2bd4b42ea68149eeffc1ef53bb469345c36f26.cab
2022/07/07 17:23:49.11 - Info: Installed ..\w60-x64\glb\windows6.0-kb4022883-x64_519ce72edf20b1a75c181362d75e13a22242f455.cab
2022/07/07 17:23:53.48 - Info: Installed ..\w60-x64\glb\windows6.0-kb4493730-x64_de2cd401093a5c42254c7bd69349821ad10341ff.cab
2022/07/07 17:24:32.75 - Info: Installed ..\w60-x64\glb\windows6.0-kb4474419-v4-x64_a5f1b40e6afb4874248c3a71583010b4b7d4512e.cab
2022/07/07 17:25:47.35 - Info: Installed ..\w60-x64\glb\windows6.0-kb4537830-x64_b91926b46eb406b6a52766e7fc8c88e4255a192c.cab
2022/07/07 17:26:50.90 - Info: Installed ..\w60-x64\glb\ie9-windows6.0-kb4525106-x64_72d91f2712d4a944b285407f774db20298b19624.cab
2022/07/07 17:26:50.93 - Info: Installed 8 updates
2022/07/07 17:26:50.93 - Info: Installed Windows Update scan prerequisites
2022/07/07 17:26:50.93 - Info: Installation successful (Updates pending)
2022/07/07 17:26:50.95 - Info: Ending WSUS Offline Update

Windows Updateを適用するために上記8個の更新を適用しているらしい。

とりあえず、Windows Server 2008 SP2+Internet Explorer 9インストール直後という状態にもどしてから、下記をダウンロードして順に適用してみた。

KB3205638は何故かWindows Server 2008 for x64-Based System用だけない けどVista x64用で適用できた

Windows Server 2008 for x64-Based Systems 用セキュリティ更新プログラム (KB4012583)

Windows Server 2008 for x64-Based Systems 用セキュリティ更新プログラム (KB4022887)

Windows Server 2008 for x64-Based Systems 用セキュリティ更新プログラム (KB4022883)

Windows Server 2008 for x64-Based Systems 用セキュリティ更新プログラム (KB4493730)

2019-09 x64 ベース システム用 Windows Server 2008 のセキュリティ更新プログラム (KB4474419)

2020-02×64 ベース システム用 Windows Server 2008 サービス スタック更新プログラム (KB4537830)2019-11×64 ベース システム Windows Server 2008 用 Internet Explorer 9 の累積的なセキュリティ更新プログラム (KB4525106) は下記の様なメッセージが出て適用失敗。おそらく証明書更新関連の問題している。

再起動後、Windows Update履歴を確認すると下記の状態となっている。

certmgr.mscを確認すると、Microsoft関連のルート証明書が追加されているのを確認。

また、Windows Updateもできるようになっていた。

コピーしてきた仮想マシンがThe specified feature is not supported by this versionで起動できない


なんか生き残っていたvSphere 5.5上で動いていたvSphere仮想マシンを新vSphere環境に移行したいけど、費用かけないいい方法は無い?という相談があった。

ある程度作業ができる人なので「仮想マシン止めてからsshでESXiにログインして、仮想マシンが入ったディレクトリをまるごとscpでコピーすればいいんじゃないですか?」と提案した。

で・・・やってみたけど、仮想マシンのパワーオンに失敗したけど、なんだろ?という質問が・・・

すべてのディスクを列挙できません。指定された機能はこのバージョンではサポートされていません

というエラーとのこと。

こういうのは英語で探さないと情報がでてこないけど、正しいのがわからないので、とりあえず「not support this version」あたりの単語から https://kb.vmware.com/ で検索して情報捜索。

Failed to power on virtual machine (82542)
 仮想マシンのパワーオンに失敗する場合のまとめ

“The specified feature is not supported by this version” error creating a snapshot in a vSAN environment (83381)
 vSANとVMFS6とでサポートしている機能に差があることで、特定のデータストアで起動できない、という事例

Migrating a VM to a VSAN datastore fails (82801)
 VSANに移行しようとして失敗する際にvmfssparseのエラーなどがでている

どうやらデータストアのファイルシステムと、仮想マシンのスナップショット周りでなにかがある、というのが見えてきた。

その観点で調査継続

VMFS でのスナップショットのフォーマット

VMFS5で2TB未満の仮想ディスクのスナップショットはVMFSsparseフォーマット
VMFS5で2TB以上の仮想ディスクのスナップショットは SEsparseフォーマット
VMFS6の仮想ディスクスナップショットは全てSEsparseフォーマット

Virtual Machines running on an SEsparse snapshot may report guest data inconsistencies (59216)

VMFS5データストアとNFSデータストアでは、2TB以上の仮想ディスクはSEsparse形式

ということが判明した。

このことから、起動しなかった仮想マシンではスナップショットが使われいたのではないか?という仮説となった。

確認してもらうと確かにスナップショットが使われていたとのこと。

対処方法としては、「新環境にNFSデータストアがあるのであればそこに移動させた後であれば起動できる」一度起動したあとであればstorage vmotionを使ってVMFS6データストアに移動できる。

もしくは、スナップショットを消してから移行を行う、ということとなった。