Microsoft Copilot for Microsoft 365（有償Copilot）を試している。TeamsのWeb会議のCopilotは、会議をホストしている組織のメンバーのみがアクセスできる。
自分が開催していない外部のTeamsのWeb会議に参加している場合は、CopilotのライセンスがあってもCopilotの起動すらもできない。TeamsでCopilotを使って、会議の要約などを行う場合は、必ず自分（もしくは自分の所属する組織のメンバー）が、会議のホストになる必要がある。
カテゴリー: 技術系memo
-
Google AppSheetのアプリを共有しようとしたらエラー
Google AppSheetで作成したアプリを共有しようとしたら、以下のエラーが出た。
Error: Policy violation: Error: Workspace AppSheet Core security violation: The app cannot be shared externally.: Learn more: https://support.google.com/a/answer/10447197#core-securityGoogle Workspaceの管理画面で、AppSheetの「AppSheet Core ライセンスのセキュリティ設定」を変更して無効にしないと、組織外への共有はできないとのこと。AppSheetを使い始めた時期によって、このセキュリティ設定のデフォルト値は異なるとのこと。
設定変更は以下。
1. Google Workspaceの管理画面にアクセスする（管理者である必要あり）。
2. アプリ → Google Workspace → AppSheet の順に開く。
3. 「AppSheet Core ライセンスのセキュリティ設定」を選択する。
4. 「AppSheet Core セキュリティを無効にする」を選択して、保存する。
設定変更後は、反映されるまで時間がかかるので待つ。
その後、Google AppSheetのアプリ側で、外部組織のユーザを招待して、利用できるのかを確認する。
-
CLIでvCenter Server Applianceのバージョンを調べるコマンド（APIコマンド）
CLIでvCenter Server Applianceのバージョンを調べるコマンド（APIコマンド）は、下記。SSHでログインした後に実行する。
com.vmware.appliance.version1.system.version.get実行例
Command> com.vmware.appliance.version1.system.version.get Version: Version: 8.0.2.00400 Product: VMware vCenter Server Build: 23929136 Type: vCenter Server with an embedded Platform Services Controller Summary: Patch for VMware vCenter Server 8.0 Releasedate: June 13, 2024 Installtime: 2024-07-11T02:22:34.170Z Command>セッション切れでの失敗例
Command> com.vmware.appliance.version1.system.version.get Session expired. Command> -
Microsoft TeamsでWebhookが廃止に。
MicrosoftがTeamsのOfficeコネクタの廃止を発表した。Officeコネクタの廃止により、Teamsで使っているWebhookが廃止になる。
・2024年8月14日で新規のWebhookアドレスの発行は終了。
・2024年10月1日からは、Webhookが使えなくなる（Officeコネクタが機能しなくなる）。
Webhook（Officeコネクタ）の廃止後は、実際には廃止前に、Power AutomateのWorkflowをTeamsに追加して、Teamsに投稿するワークフローを追加する。テンプレートから、Webhook要求をチャネル投稿するワークフローを追加すればよい。試してみたが、Webhook用のワークフローの作成は簡単だった。
TeamsにWorkflow機能を追加することで、従来のwebhookの代わりが作れることはわかった。もしたくさんのWebhookをTeamsで使っているとしたら、変更していく作業だけでも大変だ。
-
OpenSSHの脆弱性 ”regreSSHion”
OpenSSHの脆弱性 ”regreSSHion” (CVE-2024-6387 )。Linux系で新しいディストリビューションは、影響を受けてる。UbuntuやAmazon Linuxなどは対応されているので、アップデートを行えば対応される。 Ubuntuはapt updateでサクッと終わることは確認できた。脆弱性の先祖返りか。そういうこともあるよな。
あっちこっちサイトを見たけれど、piyologがわかりやすい。
-
ESXi8.0u2をインストールしたときにKB82794のワーニングが出た
VMware vSphere ESXi 6.7が動作していたサーバを初期化して、ESXi 8.0 u2 をクリーンインストールした。インストーラーを起動して、インストールを行ったときに、KB82794のWarningメッセージが表示された。Warningなので、Continueでインストールはできた（成功した）。
確認してみると、利用しているサーバのCPUのXeon Silver 4110（Skylake-SP）が、 ESU (End of Servicing Update) / EOSL (End of Servicing Lifetime) と発表されたため、ESXi 8.0.u2で非推奨になったとのこと。KB82794は、そのことが書かれたナレッジだった。
https://knowledge.broadcom.com/external/article?legacyId=82794
SkylakeシリーズのCPUは vSphere 8.0系統がサポートされているうちは大丈夫。次のバージョンでは、vSphereが対応してこないので、バージョンアップはできないかもしれない。
-
GitLabをaptでアップデートしたらエラー（Gitlab 17.1.0-ce）
今回のアップグレードは、Gitlab 17.0.1-ce から Gitlab 17.1.0-ce 。アップグレードパスとしては、問題はないはずだったのだが、下記のエラーが出た。
Running handlers: [2024-06-25T18:47:40+09:00] ERROR: Running exception handlers There was an error running gitlab-ctl reconfigure: redis_service[redis] (redis::enable line 19) had an error: RuntimeError: ruby_block[warn pending redis restart] (redis::enable line 88) had an error: RuntimeError: Execution of the command `/opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket INFO` failed with a non-zero exit code (1) stdout: stderr: Could not connect to Redis at /var/opt/gitlab/redis/redis.socket: No such file or directory Running handlers complete [2024-06-25T18:47:40+09:00] ERROR: Exception handlers complete Infra Phase failed. 11 resources updated in 37 seconds [2024-06-25T18:47:40+09:00] FATAL: Stacktrace dumped to /opt/gitlab/embedded/cookbooks/cache/cinc-stacktrace.out [2024-06-25T18:47:40+09:00] FATAL: --------------------------------------------------------------------------------------- [2024-06-25T18:47:40+09:00] FATAL: PLEASE PROVIDE THE CONTENTS OF THE stacktrace.out FILE (above) IF YOU FILE A BUG REPORT [2024-06-25T18:47:40+09:00] FATAL: --------------------------------------------------------------------------------------- [2024-06-25T18:47:40+09:00] FATAL: RuntimeError: redis_service[redis] (redis::enable line 19) had an error: RuntimeError: ruby_block[warn pending redis restart] (redis::enable line 88) had an error: RuntimeError: Execution of the command `/opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket INFO` failed with a non-zero exit code (1) stdout: stderr: Could not connect to Redis at /var/opt/gitlab/redis/redis.socket: No such file or directory === There was an error running gitlab-ctl reconfigure. Please check the output above for more details. === dpkg: パッケージ gitlab-ce の処理中にエラーが発生しました (--configure): installed gitlab-ce package post-installation script subprocess returned error exit status 1 xxd (2:8.1.2269-1ubuntu5.23) を設定しています ... vim-common (2:8.1.2269-1ubuntu5.23) を設定しています ... vim-tiny (2:8.1.2269-1ubuntu5.23) を設定しています ... dbus (1.12.16-2ubuntu2.3) のトリガを処理しています ... desktop-file-utils (0.24-1ubuntu3) のトリガを処理しています ... mime-support (3.64ubuntu1) のトリガを処理しています ... hicolor-icon-theme (0.17-2) のトリガを処理しています ... gnome-menus (3.36.0-1ubuntu1) のトリガを処理しています ... man-db (2.9.1-1) のトリガを処理しています ... 処理中にエラーが発生しました: gitlab-ce E: Sub-process /usr/bin/dpkg returned an error code (1) zen@LAB:~$もう一度、sudo apt upgrade を実行したところ、正常に終了した。
sudo gitlab-ctl restart を実行するように出ていたので、実行した。
GitLabのウェブ画面上からも確認したが、最新（17.1.0）にアップグレードができており、問題はなかった。
-
「vixエラーコード＝21009」でVMware Tools のインストールが失敗。
vCenter Serverから、VM（Windows Server）のVMware Toolsのバージョンアップをおこなったところ、「vixエラーコード＝21009」でVMware Tools のインストールが失敗した。その後、vCenter Serverの画面では、その仮想マシンは「VMware Toolsはインストールされていません」にかわった。
アンインストールは成功しているようで、仮想マシン上もVMware Toolsは無くなっていた。
対処方法
1. 念のため、VM（Windows Server）のVMware Toolsのインストールで利用されていたフォルダを削除。下記のフォルダを中身ごと削除する。アクセス権がないと言われるはずなので、アクセス権を取得してから削除する。
C:\Windows\Temp\vmware-SYSTEM
2. vCenter Serverから、VMware Toolsのインストールを実行する（仮想サーバ上に、VMware Toolsのインストーラーをマウントする）。
3. VMにログインして、VMware Toolsをインストールする。
-
SQL Server 2019からSQL Server 2005へのリンクサーバ経由でアクセスするプロシージャーがエラー
SQL Server 2019からSQL Server 2005へのリンクサーバ経由でアクセスするプロシージャーでエラーが発生した。
SQL ServerにSSMSでアクセスしてみると、リンクサーバーは存在する。リンクサーバーへの接続も問題なし。Select文でもリンクサーバー先のテーブルを参照できる。プロシージャーを実行すると、OLEDBのエラーが表示される。
リンク サーバー "サーバ名" の OLE DB プロバイダー "MSOLEDBSQL" から、メッセージ "トランザクションは既に暗黙的または明示的に、コミットまたは中止されています。" が返されました。 メッセージ 7391、レベル 16、状態 2、プロシージャ dbo.プロシージャー名、行 99 [バッチ開始行 2] リンク サーバー "サーバ名" の OLE DB プロバイダー "MSOLEDBSQL" で分散トランザクションを開始できなかったので、この操作を実行できませんでした。リンク サーバー "サーバ名" の OLE DB プロバイダー "MSOLEDBSQL" で分散トランザクションを開始できなかったので、この操作を実行できませんでした。状況をまとめると・・・
- SQL Server 2005もSQL Server 2019も稼働している。
- もともとはプロシージャーも正常に実行できていた。
- リンクサーバーの接続確認は問題なし
- Select文などを発行すると、正常にリンクサーバーのテーブルにアクセスできる。（Viewでも同様）
- プロシージャーは、失敗する。
- 分散トランザクションの設定はちゃんとできている（もともとは成功していた）。
- リンクサーバーの接続で使用するユーザはアクティブであり、パスワードも問題なし。
- 実行結果を見ていくと、ごくまれに成功しているときがある（SQL Serverへのコネクションは異なる）
いろいろと切り分けた結果、認証先？のAD（Active Directory）のOSバージョンによって、プロシージャーの実行が成功するか失敗するかが分かれていた。古いWindowsOSのADに問い合わせがいくと成功する。新しいOS（Windows Server 2022）だと失敗する。
Windows Server 2022のADに問い合わせされて、SQL Server 2005にアクセスされると、プロトコルとかセキュリティのキーセットの問題ではじかれて分散トランザクションが失敗して、タイムアウトになっているようだ。古いものは、互換性も無くなってきているので、きつい。
-
メモ： 「これdo台SAS (KD25/35SAS)」を使ってHDD消去をしたときの時間
「これdo台SAS (KD25/35SAS)」を使って、HPEのサーバ用HDDを消去した。
「HPE 900GB SAS 6G DP 10K」のディスクで、7回消去で14時間くらいで作業が終わった。
アメリカ国防総省(DoD)規格のDoD消去なら、３回なので半分くらいの6～7時間で終わる。
ログもUSBメモリに出力できるので、証明も残せる。消去はメニューを選んでボタンを押して、放置するだけ。機器廃棄のときに廃棄証明をとるにしても、事前の作業としてはちょうどいい。