Tiny11は 英語版 Windows11 Pro 22H2 から基本動作に不要なファイル・常駐物をそぎ落とした省スペース・省メモリにカスタマイズしたものだそうです。

ベースはWin11 22H2とのこと

独自カスタム版ですので、ライセンスは別途Win Proライセンスが必要ですし、マイクロソフトの保証はありません。
ただ、WIn7 Pro以降のライセンスが余っていれば、そこからアップグレードも可能です

また、Win11の必須要件も削除されているので、古いＰＣのような要件を満たさないでも稼働できます。
・BIOS（UEFI非対応PC）
・CPUがCore i 第８世代以下
・TPM（ハードウェア暗号化モジュール）なし
・MSアカウント強制なし

それと、軽量版をうたっていることもあり、メモリ2GBでも動作するということで、Win7機モデルの古いＰＣでも稼働できそうです。
Win11を試してみたいという方にはいいかもしれません。

なお、日本語化もできましたので、やり方も説明します。

---

Tiny11のインストールですが、まずはインストール用のISOファイルを取得します。
現状では、以下のURLからダウンロードできます。
https://archive.org/details/tiny-11_202302

今回は、VMware ESXi上のVMにテストしていますが、
CPU2コア、メモリ２GB、BIOS、ゲストOS:Win10x64モデルのVM上にインストールしてみます。

ISOからブートします。
ベースが英語版Win11ですが、セットアップ時の時間設定やキーボードなどはJapaneseが指定可能です（IMEが使えるので日本語入力もできます）。

インストールはあっさり完了します。英語版ですので、現時点ではまだメッセージはすべて英語になります。

今回は仮想マシンに入れたので、この後、VMware toolsも導入しています。

---

インストール後、日本語に挑戦してみます。

メニューからのSettingsを選択します

「Time & Language」->「Language & region」を選択します。

「Add a language」をクリックします。をクリックします。

「choose a alanguage to installl」にJapanと入力すると、日本語が選択できますので、「Next」をクリックします。

・「Set as my Windows display language」にチェックを入れて、「Install」をクリックします。

インストールが完了するまで待ちます。

インストールが完了したら、Windows display languageが日本語になりますので、
メッセージ通り一度サインアウトして、再度ログインします。

表示が日本語化されました。

もちろんIMEも入っているので、日本語入力も可能です。

なお、日本語はされましたが、一部操作については、うまくいかない場合もあるようです。
私が試した段階では、ユーザのプロパティが選択しても詳細画面が表示されませんでした。（英語表記に戻せば表示できました。）

その後、Windows Updateを実施してみますが、縮小化の影響か、アップデートできないものがありました。
なので、現状お試し用途で済ませたほうがいいかもしれません。

この時点での起動後7分経過後のメモリ使用量は2.0GB中1.0GB程度まで下がりました。
（コミットメモリは1.2GB）

---

ベースとしては、WIn11 Proですので、RDPのサーバ(接続元)としても動作も可能です。

注意点として、Tiny11インストール時点では、Edgeがインストールされていませんので、
自分でEdgeやChromeをインストールする必要があります。

また、WinSxSという過去のWindowsとの互換性を保ったり、新機能の実装などに使用している機能を削除してDisk使用量を削減しているとのことなので、その辺は注意が必要かもしれません。

現時点では、Windows Updateに失敗するなど少し動作に癖がありますが、
Microsoft Defender も稼働していますし、これから洗練されていくことを期待してみたいと思います。

(追記)
Tiny11_b2が公開されていました。(サイト)
ただし、Internet Archiveのログインしないとダウンロードできないようになっていました。登録すれば、b1も含めてダウンロードできます。

ただ、tiny11_b2.isoを利用してインストールしてみたところ、Win11の制限チェックに引っかかりました。また、b1からb2へのアップグレードはできないとのことです。
(VMware ESXi6.0のHWバージョン11で確認)

tiny11 b2(no sysreq).isoを利用すれば、要件に合わないPCにもインストールできるようですので、後で試してみる予定です。

長年利用しているノートＰＣである「GALLERIA QF970HG」の調子がすこぶる悪い。

Driver Power State FailureやPage faultが頻発するようになってきた。
Driver Power State Failureは、ドライバの更新でちょっと落ちついたが、その分Page faultが頻発してしまうように。

このＰＣは操作コンソール用なので、調子が悪くなっても再起動すればいいのだが、
（メインサービスは、別部屋で稼働させている別サーバ[Z820 Xen E5-2687W x2 , MEM 256GB のESXi]で処理しているので)
そろそろ、CPU性能2倍になるノートが出始めたので、安定できなさそうであれば新PC購入も検討しないとという段階なのだが、現状性能的に困っていないというのも事実だったりもする。

Windows標準のメモリチェックしても、特に問題は見つからなかったので、難儀していたのだが、Memtest64を1晩回したら特定のパターンでのみエラーを検知。
1枚ずつ調査したら、４枚中２枚でエラーという悲惨な状況でした。

とりあえず、エラーの出たメモリモジュール2枚を外してメモリ16GBで稼働中
現状は安定稼働しているので、新ＰＣ導入はもう少し後になりそうだ・・・。

ただ、このモデルのメモリの交換は結構癖があり、情報がぜんぜん見つからなかったので改めて調査したので健忘録としてメモ。

---

GALLERIA QF970HGのスペックは以下の通り(私の使用しているモデル)
ドスパラの17インチゲーミングノート GALLERIA（ガレリア） QF970HG レビュー

・17.3インチ液晶(1920×1080)
・インテル Core i7-4710MQ (4Core/HT対応/定格2.50GHz/TB時最大3.50GHz)
・32GB DDR3 SO-DIMM (PC3-12800/8GBx4/デュアルチャネル)
・GPU Intel HD 4600 + NVIDIA GeForce GTX970M 6GB
・SSD MSATA 256GBx1
・HDD 2.5インチ 2TBx1
・BD-Reドライブ

色々調べてみると、この機種はMSIのGT70というゲーミングPCをドスパラがカスタマイズイズしたもののようだ。
大きな違いだと、
GT70（20Dモデル）だと、CPUが4700MQ、GPUがGeforce GTX780Mが、
QF970HGの場合は、CPUが4810MG、GPUがGeforce GTX970Mになっています。

これは、ビデオカードがMXM規格という交換可能なモジュールとして搭載されているので、CPUだけでなくいろいろなGPUに対応できるので、ドスパラにもGALLERIA QF970HGの兄弟機として、GTX980Mを搭載した「QF980HG」というモデルもあります。

---

分解方法ですが、MSI GT70としての分解説動画がyoutubeにいくつかあるので、参考になります。

How to Replace Laptop Motherboard | MSI GT70

MSI GT70 MS-1762 disassemble to clean cooling system and detect graphic card problem

MSI GAMING G Series GT70 MS-1763 Laptop dc power jack repair fix charge port broken socket

Take Apart MSI GT70 Gaming Laptop

この機種は比較的メンテナンス性はいいほうですが、メモリ交換についてはちょっと注意が必要です。

このモデルはメモリモジュールが４枚付けられるモデルなのですが、２枚はキーボード裏からアクセス。残り２枚は背面カバーを開けたところからアクセスです。

キーボード裏のメモリは、以下のようにアクセスします。
・背面カバーのキーボードマークがついたねじを外します。
・キーボード上部の境目に５か所ほどくぼみがあるので、そこにマイナスドライバを突っ込んでキーボードの上部にあるのパネル（電源ボタンなどがあるパネル）を外します。
・キーボード上部が５か所のネジで止まっているのネジを外して、上方向にスライドさせると取り外せます（ケーブルを外す必要はありませんが、注意してください）。
・キーボードの裏側にある２枚のシートをめくると、メモリモジュールにアクセスできます。

背面カバー側のメモリは、以下のようにアクセスします。

• 背面カバーのネジを外すと、メモリモジュールスロットが見えます
  ただし、GPUのヒートパイプが邪魔をして、メモリモジュールの取り外しができませんので、以下の手順でGPUのヒートシンクと、CPUのヒートシンクを外す必要があります。
  • ファンモジュールがあるので、ネジを１つ外して、ファンモジュールを取り外します（ケーブルも外します）。
  • GPUのヒートシンクネジ（４つ）とCPUのヒートシンクネジ（３つ）を外すと、GPU,CPUのヒートシンクが外れます（GPUだけでも外れますが耐熱ゴムでくっついているので一緒に取り外したほうがいいです）。
  • これで、メモリモジュールの取り外しができます。
    （元に戻す際は、GPU,CPUの塗り直しをしたほうがいいかもしれません。）

---

その他保守情報

背面カバー＆ファンモジュール取り外し後の状態：

BIOS設定画面表示：
PC起動直後にDEL連打

起動メディア選択：
PC起動直後にF11連打

バッテリの型番：
BTY-M6D　（まだAmazonなどで入手できます）

メモリモジュール種類：
DDR3L 1600(12800) SODIMM (1.35V) 最大４枚まで(8GBｘ4=32GB)

MSATAスロット：
３つまで搭載可？

2.5インチHDD：
1つまで搭載可

ファンモジュール：
PABD19735BM-N273

MXM GPUモジュール：
AMAZONに、GT70用のGTX1060のMXMモジュールがありました（GPU性能は1.4倍くらいになるようだけど・・・）
ただ、BIOS側のサポートも必要になるようなので、動くかどうかは賭けですね。

vSphere esxi5.5, 6.0, 6.5等にCPUの脆弱性の対策パッチを適応すると、CPUの脆弱性（Spectre、Meltdown、及びL1 Terminal Fault）の対策（緩和策）が実施されます。
これは、投機的実行の制御メカニズムを利用するためのフレームワーク、またはCPUのマイクロコードにて対策用の命令を追加することで対応しているようです。
（詳細：ブランチ ターゲット インジェクションに対するハイパーバイザーアシストによるゲストの軽減 (52085)）

• ESXi 6.5：ESXi650-201803401-BG* および ESXi650-201803402-BG**
• ESXi 6.0：ESXi600-201803401-BG* および ESXi600-201803402-BG**
• ESXi 5.5：ESXi550-201803401-BG* および ESXi550-201803402-BG**

* これらの ESXi パッチは、ゲスト OS が新しい投機的実行の制御メカニズムを利用するためのフレームワークを提供します。これらのパッチにはマイクロコードは含まれません。

**これらの ESXi パッチは、Sandy Bridge DTからKaby Lakeのマイクロコードの更新を適用します。これらのパッチには、前述のフレームワークは含まれていません。

ただし、vMotionを利用する場合などで、EVCを定期していても対策済のESXiと未対策のESXiとの間で稼働中のVMを移動したりする場合はうまく移行ができないときがあります。
（送信元ホストに Spectre/Meltdown の緩和のためのパッチが適用されており、試行された宛先ホストにはパッチが適用されていない場合等で発生します。）

また、vCenter 5.5U3h, vCenter 6.0U3e, vCenter6.5U1g以降などでは、対策済で、
同一クラスター内で対策済のESXiと未対策のESXiが混在している場合は、脆弱性の緩和策を無効化することで不具合が起こりにくいようになっているようです。

ただし、複数のクラスタを作成している場合や、拡張リンクモードなどを利用している場合等は、緩和策が有効になっているものと無効になっているものが混在する可能性があり、結果vMotionが正しくできない場合があります。

このため強制的に、パッチが適応されたＥＳＸでも、脆弱性緩和策を無効化する方法があったので紹介します。（もちろんお勧めしません）

あと、あまりに古いCPU（Sandy Bridgeより前のCPU世代等）を利用している場合には、対策パッチを適応しても効果がない可能性もあるので、その場合にも有効かもしれません。
（OSの速度低下デメリット解消にも使えるかもしれません）

あとこの脆弱性緩和策（Hypervisor-Assisted Guest Mitigation）は、VMのHWバージョンが9以上出る必要があるようです。

　

VM単位で設定する場合

対象VMのVMXに以下の行を追加します。

featMask.vm.cpuid.stibp = “Max:0”
featMask.vm.cpuid.ibrs = “Max:0”
featMask.vm.cpuid.ibpb = “Max:0”
featMask.vm.cpuid.stibp = “Max:0”
featMask.vm.cpuid.fcmo = “Max:0”

なお、vSphere Clientからだと、仮想マシンを右クリックし、[設定の編集(Edit Settings)] > [仮想マシン オプション(VM Options)] > [詳細(Advanced)] > [構成パラメータ(Configuration Parameters)] – [構成の編集(Edit Configuration)] の順にクリックすることでも設定可能です。
（この場合、設定値は、Max:0 と””を外したものを設定します。）

ESXi単位で設定する場合

対象ESXにSSHなどでコンソールに入り、/etc/vmware/config ファイルに以下の行を追記または該当行を修正します。

featMask.evc.cpuid.IBPB = “Val:0”
featMask.evc.cpuid.IBRS = “Val:0”
featMask.evc.cpuid.STIBP = “Val:0”
featMask.evc.cpuid.SSBD = “Val:0”
featMask.evc.cpuid.FCMD = “Val:0”

なお、vCenterでEVCが有効になったクラスタにESXiを追加、削除したときには、この設定が上書き（または削除）される可能性がありますので、ご注意ください。
また、ESXiを再起動しても、vCenterから接続されてクラスタに追加された段階で設定が元に戻りますので、再設定が必要です。（永続的にできるかどうかは未確認）
クラスタにあるESXiがすべて対策済パッチ適応済の場合のみ、脆弱性緩和策が有効になります。（なお脆弱性緩和策が有効になったクラスタには、対策済パッチ未適応のESXiは追加できません。）

また、脆弱性緩和策を無効化したESXiの場合は、ESXiのサマリに警告が表示される場合があるようです。この場合は、ESXiのシステムの詳細設定で以下のように設定します。
名前　：UserVars.SuppressHyperthreadWarning
設定値：1

参考

ブランチ ターゲット インジェクションに対するハイパーバイザーアシストによるゲストの軽減 (52085)

同じ構成の ESXi ホストの EVC クラスタ間での vMotion による移行が失敗する (67666)

8.1 CPUの脆弱性への対応 – 8.1.4 留意事項