Windowsのローカルディスク（Ｃドライブ）の容量が枯渇してきたので、調べたところ、「wbxcache」のフォルダが数GBの容量を使っていた。
容量をたくさん使っていたwbxcacheのフォルダパス
%USERPROFILE%\AppData\Local\WebEx\wbxcacheこのフォルダは、ウェブ会議ツールの、Cisco WebEXのキャッシュのフォルダだった。このフォルダの中は、キャッシュ情報だけとのこと。エクスプローラーで選択して、削除する。
カテゴリー: Windows
-
Windows11からWindows Server 2003上のSQL ServerにODBC接続できない。
タイトルのままではあるが、Windows11からWindows Server 2003 R2上のSQL Server 2005にODBC接続できない。
セキュリティの関係で接続できない。ODBCドライバのバージョンを古いものに変えてもできないので、OSレベルでのセキュリティの問題で接続できない。
-
Powershellで大容量ファイルの中身をクリア（消す）する方法
Windowsの端末（Windowsサーバ）で、ログファイルを消さずに、中身だけを消して、クリアにしたかった。Linuxだと、catコマンドを使って、空データで上書きをやっている。Windowsだと、catコマンドがないので、できず。Powershellで、同じようになる方法を調べた。
Powershellを使って、ファイルの中身だけをクリアする（消す）には、Clear-Contentコマンドレットを使用する。Clear-Itemだとファイル自体を消してしまうが、Clear-Contentは、ファイルを残したまま、中身のみを削除する。
Clear-Content ファイル名実行例）
PS C:\apache2\logs> dir ディレクトリ: C:\apache2\logs Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 2023/06/12 14:17 754742089 access.log -a--- 2023/06/12 14:12 754741796 access.log.1 PS C:\apache2\logs> Clear-Content .\access.log PS C:\apache2\logs> dir ディレクトリ: C:\apache2\logs Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 2023/06/12 14:19 0 access.log -a--- 2023/06/12 14:12 754741796 access.log.1 PS C:\apache2\logs> dir ディレクトリ: C:\apache2\logs Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 2023/06/12 14:20 240 access.log -a--- 2023/06/12 14:12 754741796 access.log.1なお、Windows Server 2008 R2でもClear-Contentは使えたので、環境を選ばずに使えそうだ。
-
WSL2のUbuntuのイメージ保存場所
WSL2で、実際のデータがどこにあるのか気になって調べたので、メモ。
デフォルト設定では、ユーザアカウントの「AppData¥Local¥Packages¥」の下に、フォルダ分けされて保存されていく。WSL2の場合は、「ext4.vhdx」で保存されるのだが、WSL1でLinuxを展開して、WSL2に変換した場合は、下記のように「rootfs」フォルダの下にファイルが展開される。WSL（WSL1）の場合も同じフォルダだ。
C:\Users\%USER%\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs※ %USER% の部分は、自分のユーザ名に置き換えてアクセスする。
最初からWSL2の場合は、vhdxファイルで下記のフォルダに展開されているはず。
C:\Users\%USER%\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\参考： https://learn.microsoft.com/en-us/windows/wsl/disk-space
-
PowerShell ISEでps1のファイルを開くと文字化けする
Windows10のPowerShell ISEで、ps1ファイル（PowerShellのスクリプトファイル）を開くと、文字化けする。日本語のコメント部分が文字化けするので使いにくい。対処方法を調べてみたのだが。
PowerShell ISEの読み込み時のデフォルトの文字コードは、ShiftJISである。この読み込み時のデフォルトの文字コードを変更することはできない。OSの文字コードではなくて、PowerShell ISEのデフォルト設定であるため。
ps1ファイルに、BOM付でUTF-8指定されている場合には、開いても文字化けせず、UTF-8としてファイルを開いてくれる。
Windows10は、現在はメモ帳などで作成したファイルにBOMを付けていない。デフォルトはUTF-8で、BOMなしはUTF-8解釈されるし、それで保存される。
PowerShellのスクリプトファイルを作成するときは、保存するときに拡張子を .ps1 で保存するだけではなく、オプションとして、BOMで文字コードをUTF-8指定で保存する必要がある。もし、.ps1ファイルをPowerShell ISEで開くときに文字化けする場合は、一度、メモ帳などで開き、BOM付で保存しなおす必要がある。
なんと厄介な。Powershell ISE は標準でインストールされているので実行時したりするときに便利だったのだけど。
-
急にNpgsqlからAzure Database for PostgreSQLへの接続ができなくなった
急に.NET6（.NET 3.1～7も）のNpgsqlからAzure Database for PostgreSQLへの接続ができなくなった。
アプリケーション側からみると、Azure側のPostgreSQLに強制切断されているようにみえるログが出ている。
---> Npgsql.NpgsqlException (0x80004005): Exception while writing to stream ---> System.IO.IOException: Unable to write data to the transport connection: 既存の接続はリモート ホストに強制的に切断されました。. ---> System.Net.Sockets.SocketException (10054): 既存の接続はリモート ホストに強制的に切断されました。 at System.Net.Sockets.NetworkStream.Write(Byte[] buffer, Int32 offset, Int32 count)こうなると、通常考えるのは、AzureのPostgreSQLで、コネクション数があふれているとか、高負荷状態とか、DBaaSの制約（PostgreSQL設定の外側）が原因じゃないかということ。これを１つ１つ調べていくと、異常なし。Azure側には問題が見当たらず。DBのログをAzureの管理ページがダウンロードして確認してみると、下記のログがあり。
could not receive data from client: An existing connection was forcibly closed by the remote host.AzureのPostgreSQLからみると、クライアント側が切断しているとのこと。
調べてみると、「Azure Database for PostgreSQL Single server」は、ルート証明書が変更されていることがわかった。.NETで、Ngpsqlを使っている場合は、「Baltimore CyberTrust Root」と「DigiCert Global Root G2」が使うWindows（Windows Server含む）にインストールされている必要があるとのこと。ルート証明書の確認をすると、「DigiCert Global Root G2」が存在していなかった。これが原因なので、下記のマイクロソフトの内容に従い、確認して作業した。
Understanding the changes in the Root CA change for Azure Database for PostgreSQL Single server
https://learn.microsoft.com/en-us/azure/postgresql/single-server/concepts-certificate-rotation#what-do-i-need-to-do-to-maintain-connectivity今回足りていなかったのは、「DigiCert Global Root G2」なので、Digicertのサイトからルート証明書をダウンロードした。
https://www.digicert.com/kb/digicert-root-certificates.htm#roots
（「Download DER/CRT」をクリックして、CRTファイルをダウンロード）CRTファイルを、ルート証明書が足りていないサーバに持っていき、ダブルクリックして、ウィザードからルート証明書をインストールした。配置場所は自動選択させることでルートのところにインストールされた。
なお、ルート証明書のインストール後のOS再起動はしなくても、ルート証明書を使い始めた。
-
Windowsのライセンス認証で「0xc004e028」エラーがでた。
Windows Server 2022のライセンス認証を行ったところ、下記のエラーが発生した。
We can't activate Windows on this device right now. You can try activatating again later or go to the Store to buy genuine Windows. (0xc004e028)
今はライセンス認証のアクティベーションができなかった、あとでもう一度アクティベーションを行ってほしい、という内容のエラー。もう一度、アクティベーションを行おうと、システムの詳細情報をみてみると、ちゃんとライセンス認証されていた。
-
SQL ServerのDBを読み取り専用にする方法
SQL Serverのデータベースを読み取り専用（リードオンリー）する、または解除するには、次のことを行う。
1. SQL Server Management Studio (SSMS) を使い、管理権限のあるユーザで接続する。
2. 対象のDBを選択して、右クリックして、プロパティを開く。
3. オプションを開く。
4. 「状態」の中にある「読み取り専用データベース」の項目を探す。
5. 「読み取り専用」にする場合は、プルダウンで「True」を選択する。読み取り専用を解除する場合は「False」を選択する。
6. 「OK」をクリックする。これを行うと、一度、該当DBへのすべての接続が切断されるので注意すること。
-
Windows Server 2022のインストールディスクを作る場合は、DVD-R DLで。
久しぶりに物理サーバに、Windows Serverをインストールした。今の最新OSのWindows Server 2022をインストールするために、ISOファイルを落としたのだが、これのサイズが、5.31GBあった。DVD-Rだと、4.3GBの容量なので作成することができない。そのため、Windows Server 2022のインストールディスクを作るために、DVD-R DLのディスクを買いにいった。
普通のDVD-Rだと、Windows Server 2022は容量が足りずに焼くことができないので注意。買いに行く前にISOファイルのサイズを確認したのでよかった。
-
APT攻撃やマルウェアを防ぐツールをテストするときに使えるツールのメモ。
APT攻撃やマルウェアを防ぐアンチウィルスやEDRツールなどをテストしたいときに、使えるツールのメモ。
下記に公開されているツールを、コマンドで実行すれば検知されるかどうかがわかるとのこと。
APTシミュレーター：システムが APT 攻撃の被害者であるかのように見せるためのツールセット
https://github.com/NextronSystems/APTSimulatorまだ、試せていないので、余裕ができたら試してみたい。