Windowsのローカルユーザーのパスワードをネットワーク越しに変更する
Ctrl+Del+Altからのパスワード変更画面で、ユーザー名をリモートコンピュータ名\ユーザー名とすると、ローカルPCアカウントと同じ要領でリモートPCのローカルアカウント（ややこしい）のパスワードを変えられるそうなんだけど、最近のWindowsでは以下のおまじないが必要だそう。
- コマンドプロンプトで以下のコマンドを実行（レジストリ追加）
REG ADD HKLM\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters /v NullSessionPipes /t REG_MULTI_SZ /d SAMR /fREG ADD HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RestrictRemoteSamAuditOnlyMode /t REG_DWORD /d 1 /f
- Windowsファイアウォールで「Netlogonサービス」を許可
ファイヤウォールの穴あけまで言及してるサイトが殆どなくて結構ハマった。
参考サイト
代替データストリームの取得はNtQueryInformationFile一択
C#でNTFSの代替データストリーム(Alternate Data Stream)を読み書きしたくなったので調べたことをメモ。正確な部分は把握しきれてないが、非公開関数であるNtQueryInformationFileで列挙するのが確実のようだ。
代替データストリームの取得（列挙）には以下の3つの方法がある。
- BackupRead関数を使う
- FindFirstStreamW関数, FindNextStreamW関数を使う (Windows Vista以降)
- NtQueryInformationFile関数を使う (非公開関数)
正攻法は1, 2で、調べた限りADSの読み書きを行う既存のC#ライブラリは、1のBackupRead/BackupWriteを使っている。
ところがどう言う訳か、BackupReadでは列挙されないストリームが存在しうる。dir /rやNirSoft AlternateStreamViewでは表示されるにも関わらずだ。NTFSによるアクセス権限の問題らしいが、詳しいことは分からない。
NtQueryInformationFileはアクセス権限を無視して情報を取得できるらしく、前述のdirやAlternateStreamViewはこのAPIを使っているのだろう。多分。
2の方法は試してないが、アクセス権を無視するオプションはないらしいので望み薄と思われる。
こちらの記事のC#でNtQueryInformationFileを使ったサンプルで、無事目的のADSが取得できることを確認。というわけで、非公開関数ではあるもののNtQueryInformationFileを使うのが確実っぽい。
参考サイト
PVEとConnectX-3とWindowsでSR-IOVが使えないのはMLNX_OFEDが古いせい
Proxmox VE 6.3のWindows 10ゲストでConnectX-3のSR-IOVが機能しないのは、PVE内蔵のmlx4ドライバが激古なのが原因のようだ。正確にはLinuxのインボックスドライバだが。
この状態だと、SR-IOVは有効でWindows側にVirtual Functionが生えているにもかかわらず、コード43となって、どうあがいてもデバイスが動かない。PVE側では以下のようなログが出る。
mlx4_core 0000:01:00.0: vhcr command:0x43 slave:1 failed with error:0, status -22 mlx4_core 0000:01:00.0: Received reset from slave:1
“Mellanox OFED for Linux Archived Bug Fixes”を眺めると、Internal Ref 1178129に、まさにそれっぽいバグが載っていた。
Description: Fixed an issue that prevented Windows virtual machines running over MLNX_OFED Linux hypervisors from operating ConnectX-3 IB ports.
When such failures occurred, the following message (or similar) appeared in the Linux HV message log when users attempted to start up a Windows VM running a ConnectX-3 VF:
“mlx4_core 0000:81:00.0: vhcr command 0x1a slave:1 in_param 0x793000 in_mod=0x210 op_mod=0x0 failed with error:0, status -22”
バグはIBポート、うちはEthポートという違いがあるが、状況としては極めて近い。この問題はMLNX_OFED v4.2-1.2.0.0で修正済みで、2021-02-10現在の最新版はv4.9-2.2.4.0 LTSであるから、とっくの昔に解決済みのハズである。
そんなバグに何で今更遭遇するの～？と思いきや、Linuxのインボックスドライバはなんとv4.0相当という事実が判明／(^o^)＼ Kernel.orgのBugzillaでも指摘されてるが、ガン無視の模様…。
しゃーないので自前ビルドしたら無事動いた。なんだよもう、めっちゃハマったやんけ！
それでも完全解決とはいかず、デバイスは動いているように見えるものの、なぜかパケットが流れない事がある。初期化系の何かっぽくて、何度かVMを再起動して一度通信できる状態になれば、途中で途絶する事はないのが不幸中の幸いではあるが。
もう1つ気になるのは「イーサネットの状態」のパケット数カウントが何かおかしいこと。受信パケットが常に0で、これが原因かわからんがVF経由だとiTunesでGracenoteへの接続に失敗する。virtio-netの方だと大丈夫なので、うちのネットワークがおかしい訳ではない。
SR-IOVまわりは情報があまりなくて、よう分からん。
(2021-12-07 追記)
WinOF v5.50.5400のKnown Issuesを眺めてたら、Internal Ref. 1297888にパケット数カウントがおかしい問題が思いっきり載っていた……というわけで、Windowsドライバのバグで確定。
回避策がN/Aなのでドライバ修正を待つしかないが、果たして更新されることはあるのだろうか。もうConnectX-3はLTSフェイズだしなぁ。ConnectX-4がお安く手に入ればいいんだけど。
記憶域のNTFSはアロケーションユニットサイズ大きめで作成する
Windowsの記憶域プール上にNTFSの仮想ボリュームを作る時は、そのアロケーションユニットサイズ a.k.a. クラスタサイズをよーく考える事。思わぬところでNTFSの最大容量制限に引っかかることになる。
というのも、NTFSのボリュームサイズは（容量）＝（アロケーションユニットサイズ）×（クラスタ数）の関係になっていて、1ボリュームあたりのクラスタ数は2^64-1個が上限となっている。すなわち、ボリュームの最大容量はアロケーションユニットサイズで決定され、ボリュームの最大容量との関係は下表となる。
| クラスタサイズ | 最大ボリュームサイズ |
|---|---|
| 4KB | 16TB |
| 8KB | 32TB |
| 16KB | 64TB |
| 32KB | 128TB |
| 64KB | 256TB |
（2020/12/01 追記）
家のWindows 10マシンで確認したところ、いつの間にかアロケーションユニットサイズとして128KB～2MBが追加されていた。Windows Serverでは2019で対応したっぽい。追加分は下表のとおり。
| クラスタサイズ | 最大ボリュームサイズ |
|---|---|
| 128KB | 512TB |
| 256KB | 1PB |
| 512KB | 2PB |
| 1MB | 4PB |
| 2MB | 8PB |
これだけ拡張されればNTFSもまだまだ行けるね！
2020-02-18現在、デフォルトクラスタサイズは昔から変わらず4KBのため、NTFSの1ボリューム≒1パーティションの最大サイズは16TBとなる。言うまでもないが、クラスタサイズを後から変更するのは無理。
一般的な使い方なら4KBでも十分だろうけど、容量拡張が容易な記憶域プールの場合、いとも簡単にこの最大ボリュームサイズ制限に引っかかってしまう。仮想ディスク上のNTFSボリュームを拡張すべく記憶域プールの容量を増やし、仮想ディスクを拡張し、いよいよNTFSパーティションを拡張だぜ！って段階で16TB制限に遭遇することとなり、マジ真顔状態となる。ありえねーよほんと……
16TBのHDDが現実的な値段で変えてしまう昨今、やろうと思えば一般のご家庭で一般的なM/Bでもって、16TB×8本で128TBの記憶域プールが作れてしまう。そう考えると、記憶域プール上のNTFSのクラスタサイズは64KB（ボリューム上限256TB）と、脳死対応をしてしまっていいのかも。あるいはNTFSを捨ててReFSに行ってしまうか。
アロケーションユニットサイズは、ボリュームにおけるデータの最小管理単位なので、無暗に大きくすると無駄が多く発生する可能性もあって悩ましいところ。
あー、10TBのデータをバックアップから復元するのめんどくせー。
Windows 10 1903のRDPが固まる問題はWDDMドライバ無効で回避できるっぽい
Windows 10 May 2019 Update（バージョン1903）において、Intel CPU内蔵GPUで動いているPCにリモートデスクトップ接続すると、リモデの画面が真っ黒になったりログインしています画面で固まったりする。WDDMドライバが何やら悪さしているらしく、グループポリシエディタでRDP時のWDDMグラフィックスドライバ使用を無効化すれば回避できるっぽい。
- グループポリシーエディターを起動する（検索窓にgpeditと入れるのが手っ取り早い）
- 以下のツリーたどり「リモートデスクトップ接続にWDDMグラフィックディスプレイドライバーを使用する」の設定を開く
- コンピューターの構成
- 管理用テンプレート
- Windowsコンポーネント
- リモートデスクトップサービス
- リモートデスクトップセッションホスト
- リモートセッション環境
- 「無効」にチェックを入れOKを押す
- Windowsを再起動する
公式には一部のIntel GPUでの問題とされているが、しょぼいGPU全般で起こるような気がするんですけど。自分が遭遇した限りでは、Intel GPU、VirtualBoxのVBoxVGA（アクセラレーションなし）、bhyveの各Windows環境で発生してるんですけど！
それどころか、言及されてるの見たことないけど、問題発生時は画面回りのみならずネットワーク周りも道連れに死んでる気がするんですけど！これも先の各環境で再現するんですけど！！超不便だし許さんぞMS……