古いWindows（Windows Server 2008 R2） のPowershell（Ver 2.0）で、メールを送付すると、「-Encoding」でUTF8を指定していても文字化けする事象に遭遇した。
Powershellのスクリプトは、Windows10で、VS Codeを使って書き、文字コードはUTF8にしている。そこで開発したスクリプトファイルを、古いWindowsに持って行って実行する。実行は問題なくできるのだが、そのスクリプトから送られてくるメールが文字化けしてしまう。
Powershellのスクリプトファイル（.ps1）をみてみると、BOMなしで保存されている。これをBOMありで保存しなおして、古いWindows環境で実行してみると、文字化けが解消した。古いWindows環境のメモ帳では、文字化けせずに開けたが、Powershellの実行環境だと、BOMがないとSJISで開いているようで、ここで文字化けが発生している。
Powershellのスクリプトを作成するときは、UTFの場合は、BOMありで保存する。
Powershellがコード: -1073741502で異常終了することがある。一度、発生すると同じときに実行されているPowershellも立て続けに同じコードで落ちる。
これを調べてみると、下記の内容が見つかる。
“0xC0000142” or “-1073741502” Stop error when many PowerShell scripts call the Console.Write method or when you try to start many console applications on a PowerShell console in Windows 7 or in Windows Server 2008 R2
https://support.microsoft.com/en-us/topic/-0xc0000142-or-1073741502-stop-error-when-many-powershell-scripts-call-the-console-write-method-or-when-you-try-to-start-many-console-applications-on-a-powershell-console-in-windows-7-or-in-windows-server-2008-r2-19f475a2-cbe9-c463-a2b4-b7fe7a1d236d
Microsoft.powershell.consolehost.dllファイルのエラーが原因で発生しているようで、多くのコンソールがPowershellから開かれることによってリークが発生して、このエラーになる。時間がたつことで、一時的におさまるので、またPowershellの実行ができるようになる。（これも実際の挙動と一致するのでこれだろう）
修正パッチもあるみたいないので、該当OSならば、パッチを当てるのもよさそうだ。
負荷の高いVMのバックアップをとる場合は、Veeam Backupがバックアップ時に取得するスナップショット以外は、無い方がいい。すでにスナップショットがある場合は、下記のような挙動になることがあり、システム不安定につながる。
絶対になるわけではなく、Veeam BackupがvSphere上（ESXi上）でVMのスナップショットをとるときにOS側の挙動が不安定になったときに発生する。Veeam BackupでVMのバックアップを取得するときに不具合があるときは、対象VMのスナップショットの有無を確認したほうがいい。
通常のままでは、Windows Server 2022のActive Directory（機能レベル Windows Server 2016）にWindows 2000やWindows 2000 Serverを参加させることはできない。AD参加時のセキュリティの不一致によるため。
無理やりWindows Server 2022のADにWindows 2000を参加させるためには、以下のことを行い、セキュリティレベルを下げる必要がある。
1. 「secpol.msc」と入力して、ローカルセキュリティ設定を起動する。
2. 「ローカルポリシー」＞「セキュリティオプション」＞「ネットワーク セキュリティ」＞「LAN Manager 認証レベル」の順に選択開く。
3. 「LMとNTML応答を送信する」を選択して、適用する。
1. Powershellを管理者として実行する。
2. `Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol` を入力して、実行する。
3. OSを再起動する。
セキュリティは、かなり下がるので、Windows 2000はAD参加させないほうがいい。Windows Server 2003も同じ方法で参加できるはず。
久しぶりにWindows10で、WSLを起動したところ、”wsl.exe –update” を実行するようにというメッセージが表示された。
これは、従来のWSLから、Microsoft Store版（ストア版）のWSLにアップデートするコマンドだった。実行しないという選択もないので、実行した。
wsl.exe --update実際に実行してみると、下記のようになる。「Linux 用 Windows サブシステム はインストールされました。」を表示されれば成功。念のため、”wsl.exe –version” を実行し、結果が取得できれば、ストア版への更新ができている。
PS C:\Users\zen> wsl.exe --update
インストール中: Linux 用 Windows サブシステム
Linux 用 Windows サブシステム はインストールされました。
PS C:\Users\zen>
PS C:\Users\zen> wsl --version
WSL バージョン: 2.0.9.0
カーネル バージョン: 5.15.133.1-1
WSLg バージョン: 1.0.59
MSRDC バージョン: 1.2.4677
Direct3D バージョン: 1.611.1-81528511
DXCore バージョン: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows バージョン: 10.0.19045.3930
PS C:\Users\zen>FSMOの確認や移動で、「Active Directory スキーマ」を確認するために、MMCに追加しようしたときに「スナップインの追加と削除」に表示されなかった。（OSは、Windows Server 2022）
「Active Directory スキーマ」は、コマンドで「schmmgmt.dll」を追加しないと表示されない。環境は、Windows Server 2022のActive Directory。
ADサーバにログオンして、Powershellを起動して、以下のコマンドを実行する。
regsvr32.exe schmmgmt.dll追加に成功すると、ポップアップでメッセージが表示される。OSの再起動は不要。
MMCで「スナップインの追加と削除」を表示すると、下図のように追加されている。
ADサーバにログインして、管理者モードのPowershellで以下のコマンドを実行する。
netdom /query fsmo実行例
PS C:\Users\administrator.TD> netdom /query fsmo
スキーマ マスター ACTIVE2.td.xenos.jp
ドメイン名前付けマスター ACTIVE2.td.xenos.jp
PDC ACTIVE2.td.xenos.co.jp
RID プール マネージャー ACTIVE2.td.xenos.jp
インフラストラクチャ マスター ACTIVE2.td.xenos.jp
コマンドは正しく完了しました。
PS C:\Users\administrator.TD>Windows Server 2022のADでも変わらず、このコマンドでOKだった。
Surface Pro 7（Windows 10 22H2）で、2024年1月のWindows UpdateのKB5034441が、コード 0x80070643でエラーになる。
回復領域のサイズ不足で、このエラーが発生するとのこと。対応は手動で、回復領域を拡張する必要があるとのこと。Surface Pro 7は、ディスク領域とかは初期状態から変えていないのだが。この問題に直面する人は多そう。めんどくさいな。
参考： https://forest.watch.impress.co.jp/docs/news/1560171.html
利用中のWindows PCの挙動が怪しいときは、システムファイルチェッカーを使ってみる。ファイルの破損等が問題の場合は、システムファイルチェッカーを使うことで修復が行われ、システムが安定する可能性がある。
1. Windows Updateを行って最新の状態にする。
2. コマンドプロンプトを管理者モードで起動する（右クリックして「管理者として起動する」を選択する）。
3. `DISM.exe /Online /Cleanup-image /Restorehealth` を実行する。
4. ３の部分が正常実行されたら、次に `sfc /scannow` を実行する。
5. なにか問題があれば自動修復された旨が表示される。
実行例は下図。
JP1 Network Node Manager（JP1 NNM）に送信されてきたトラップ（SNMP Trap）を表示するのは、nnmtrapdump.ovplコマンドをCLIで実行する。実行すると、結果がコンソールに表示される。件数が多いことが想定されるので、標準出力をつかって、ファイルに書き出す方がよい。
オプションのパラメータを指定することで、期間や送信元のIPアドレスで絞り込むことができる。
例）
C:\Program Files (x86)\Hitachi\Cm2NNMi\bin>nnmtrapdump.ovpl -from 2023-08-30T00:00:00 -to 2023-08-30T23:59:59 -source xxx.xxx.xxx.xxx参考： https://itpfdoc.hitachi.co.jp/manuals/3021/30213E0230/NNMS0621.HTM