MicrosoftがWindows環境におけるVBScript（VBS）を非推奨にすると発表した。将来的には、VBScriptの実行環境が削除されるとのこと。
「VBScript」は非推奨に、将来のWindowsリリースで削除
https://forest.watch.impress.co.jp/docs/news/1537619.html
しぶとく残ると思われていたIE11も廃止されたので、VBScriptも確実に削除されるだろう。いずれ出るであろうWindows 12は、削除されていてもおかしくはないかも。そう考えると、明確な言及はないけれど、2，3年くらいで無くなるという覚悟が必要そうだ。
また、小まめにGitLab CEのアップデートをやり忘れて、apt updateでのアップデートでエラーになった。今回は、GitLab CE 16.2から、GitLab CE １6.4.1へのアップデートだ。
apt upgradeで発生したエラー（一部抜粋）は下記。
gitlab preinstall: It seems you are upgrading from 16.2 to 16.4.
gitlab preinstall: It is required to upgrade to the latest 16.3.x version first before proceeding.
gitlab preinstall: Please follow the upgrade documentation at https://docs.gitlab.com/ee/update/index.html#upgrade-paths
dpkg: アーカイブ /tmp/apt-dpkg-install-33WUrh/15-gitlab-ce_16.4.1-ce.0_amd64.deb の処理中にエラーが発生しました (--unpack):
new gitlab-ce package pre-installation script subprocess returned error exit status 1
処理中にエラーが発生しました:
/tmp/apt-dpkg-install-33WUrh/15-gitlab-ce_16.4.1-ce.0_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)まずは、GitLabのサイトで、アップグレードできるパスを調べる。
これによると、一度、16.3.5にアップグレードしてから、この時点の最新にアップグレードする必要があるとのこと。
アップグレードパス ： 16.2 → 16.3.5 → 16.4.1
これを実行したコマンドは下記。段階的にアップデートして、最後に、GitLabを再起動する。
sudo apt update
sudo apt upgrade gitlab-ce=16.3.5-ce.0
sudo apt upgrade gitlab-ce=16.4.1-ce.0
sudo gitlab-ctl restart何度もやっているので、作業自体はこなれた感じだ。
タイトルのままだが、systeminfoは、Windows XPから追加されたコマンド。Windows 2000（Windows 2000 Server）には、systeminfoがないので注意。
SQL Serverで、個別のデータベースに対して、権限を与えても、SQL Server エージェントのジョブの部分はSQL Server Management Studio（SSMS）には、「SQL Server エージェント」も「ジョブ」も表示されない。これの権限は、データベースの権限とは別につける必要がある。
SQL Serverのジョブ（SQL Server エージェント）に権限を付ける一番簡単な方法は、以下の操作でsysadmin権限の付与を行う。
これで権限が付与されるので、権限を与えたユーザで、SSMSで接続して、「SQL Server エージェント」と「ジョブ」が表示されることを確認する。
もし、SQL Server エージェントだけの権限を与える必要がある場合は、データベースの「msdb」にあるロールを割り当てる。
選択できるロールの概要は以下。
SQLAgentUserRole
→SSMSで接続したときに、SQL Serverエージェントが表示される。
表示されるのは、接続ユーザの権限があるもののみ。
SQLAgentReaderRole
→SSMSで接続したときに、SQL Serverエージェントが表示される。
他のユーザのSQL Serverのジョブも表示される。
メニューで、ジョブが実行できるように見えるが、実行すると権限がないものはエラーになる。
SQLAgentOperatorRole
→SSMSで接続したときに、SQL Serverエージェントが表示される。
SQL Serverのジョブの表示や実行ができる。
Windows Server 2022で作成したAD（機能レベル2016）に、Windows 2000 Serverを参加させようとしたが、エラーによりドメインに参加できなかった。
ドメイン "xxxxxx.domain" に参加中に次のエラーが発生しました：
指定されたネットワーク名は利用できません。原因は、CIFSなどのプロトコルのバージョンが低いもの（セキュリティリスクがあるもの）を許可していないためと思われる。参加できるかどうかの実験だったので、通常状態ではWindows Server 2022で作成したADに、Windows 2000 Serverは参加できない、という結果が出たので満足。
Veeam Backup＆ Replicationで設定できるイミュータブル期間（データの変更を禁止する不変期間）を調べてみた。
https://helpcenter.veeam.com/jp/docs/backup/vsphere/hardened_repository.html?ver=110
バックアップファイルは、構成された期間（最小7日、最大— 9999）の間イミュータブルになります。イミュータビリティ期間は、アクティブなバックアップチェーンに対してのみ延長されます。 バックアップに複数のチェーンがある場合、Veeam Backup & Replicationは、チェーン内の古いバックアップのイミュータビリティを延ばしません。
https://helpcenter.veeam.com/jp/docs/backup/vsphere/hardened_repository.html?ver=110
上記がVeeamのサイトにあるので、イミュータブル期間の最大期間は、9999日。無限にはできない。年にすると、 27.38年になる。
SQL Serverでストアドプロシージャの一覧を表示するためには、「INFORMATION_SCHEMA」の「ROUTINES」ビューを参照する。’ROUTINE_TYPE’で’PROCEDURE’ を指定することでプロシージャのみに絞り込める。絞り込みを行わない場合は、FUNCTION なども表示される。
■プロシージャのみで絞り込み
SELECT
*
FROM
INFORMATION_SCHEMA.ROUTINES
WHERE
ROUTINE_TYPE = 'PROCEDURE'
ORDER BY
SPECIFIC_CATALOG, SPECIFIC_SCHEMA, SPECIFIC_NAME■プロシージャだけでなく、ファンクションも表示する
SELECT
*
FROM
INFORMATION_SCHEMA.ROUTINES
ORDER BY
SPECIFIC_CATALOG, SPECIFIC_SCHEMA, SPECIFIC_NAME■必要なものだけ表示する
SELECT
SPECIFIC_CATALOG, SPECIFIC_SCHEMA, SPECIFIC_NAME, ROUTINE_CATALOG, ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE
FROM
INFORMATION_SCHEMA.ROUTINES
ORDER BY
SPECIFIC_CATALOG, SPECIFIC_SCHEMA, SPECIFIC_NAME参考：
INFORMATION_SCHEMA.ROUTINES の説明
現在のデータベースの現在のユーザーがアクセスできるストアド プロシージャと関数ごとに、1 行のデータを返します。 戻り値を記述する列は、関数にのみ適用されます。 ストアド プロシージャの場合、これらの列は NULL になります。
1台のサーバに、データの保存先を含めたVeeam Backup ＆ Replicatiion 11の全機能をインストールするときに必要なメモリサイズを計算する。同時に実行するタスクの数により、必要なメモリとCPUのコア数が変わる。4タスクを同時に動かす想定。
4タスクを同時実行する、1台構成のVeeamのメモリとCPU
■メモリサイズ
基本 4GB
コンソール 0GB（2GB ‐ 2GB）
プロキシサーバ 6GB（2GB x 4タスク ‐ 2GB）
バックアップリポジトリサーバ 10GB（4GB ＋ 2GB x 4タスク ‐2GB）
※1台に複数機能を入れる場合には、1機能あたり、2GBを引けるとのこと
※バックアップリポジトリを分割すると、半分の10GBで済む。その場合は、バックアップリポジトリサーバは、12GBのメモリが必要になる想定。
合計 20GB
■CPUのコア数
基本 4コア
プロキシサーバ 4コア（1コア x 4タスク）
合計 8コア
ここでの計算が漏れている可能性もあるため、余剰でメモリを割り当てられるのであれば、もっと多いメモリサイズを割り当てた方がよい。
参考： https://helpcenter.veeam.com/jp/archive/backup/110/vsphere/system_requirements.html
1台のサーバに、データの保存先を含めたVeeam Backup ＆ Replicatiion 12の全機能をインストールするときに必要なメモリサイズを計算する。同時に実行するタスクの数により、必要なメモリとCPUのコア数が変わる。4タスクを同時に動かす想定。
なお、バージョン12では、バックアッププロキシでの複数タスクの実行で消費されるメモリが少なくなっている。
4タスクを同時実行する、1台構成のVeeamのメモリとCPU
■メモリサイズ
基本 6GB（4GB ＋ 0.5GB x4タスク）
コンソール 0GB（2GB ‐ 2GB）
プロキシサーバ 2GB（2GB + 0.5GB x 4タスク ‐ 2GB）
バックアップリポジトリサーバ 6GB（4GB ＋ 1GB x 4タスク ‐2GB）
※1台に複数機能を入れる場合には、1機能あたり、2GBを引けるとのこと
合計 14GB
■CPUのコア数
基本 4コア
プロキシサーバ 4コア（1コア x 4タスク）
合計 8コア
ここでの計算が漏れている可能性もあるため、余剰でメモリを割り当てられるのであれば、もっと多いメモリサイズを割り当てた方がよい。
参考：
https://helpcenter.veeam.com/docs/backup/vsphere/system_requirements.html?ver=120
ファイルサーバのデータ移行をしていて、共有からアクセスするとアクセス権のないファイルやフォルダが表示されない（アクセス権のないファイルやフォルダが見えない）、という状況があった。
気になって調べてみると、SMBのプロトコルバージョンやCIFSバージョンの問題ではなく、Windowsのフォルダ設定で、「アクセス許可設定に基づいた列挙を有効にする」の設定にチェックが入っている（オンになっている）と、アクセス権のないフォルダやファイルは表示されなくなる。設定中に、オンにしてしまっていたようだ。「アクセス許可設定に基づいた列挙を有効にする」の設定のチェックボックスでチェックを外して保存すれば、アクセス権のないフォルダやファイルも見えるようになる。
「アクセス許可設定に基づいた列挙を有効にする」の設定は以下。
１．「サーバーマネージャー」を開く
２．サイドメニューから「ファイル サービスと記憶域サービス」を開く
３．サイドメニューから「共有」を開く
４．表示された共有一覧から、対象の共有名を選んで、右クリックからプロパティを開く
５．プロパティの中の「設定」を開く
６．「アクセス許可設定に基づいた列挙を有効にする」を確認する、必要に応じて、チェックのオン・オフを行う
Windows Server 2022の既定値も調べてみたが、「アクセス許可設定に基づいた列挙を有効にする」（Access Based Enumeration）は、既定値はオフ。
なお、マイクロソフトのドキュメントによると、「一部の環境では、アクセス ベースの列挙を有効にすると、サーバーの CPU 使用率が高くなり、ユーザーの応答時間が遅くなります。」とのことなので、特別な要件がなければ、オフの方がよさそうだ。
参考：