tech

TL;DR Windows 11 22H2より印刷設定ダイアログで「設定」ベースの「Win32アプリケーションから印刷しています」という画面が表示されるようになった。 レジストリの設定変更により旧ダイアログに戻せる 経緯 VisualStudio(C#)のプログラムでReportViewerを使っているところがあります。印刷時に以下の設定が必要で、プログラムからこれらを設定していました。 プリンター名 用紙設定 トレイ(手差しトレイを使用) 印刷設定画面を経由しますが、上記が設定済みのため何も変更せずに実行すれば正しく印刷されていました。 Windows 11にバージョンアップ後、印刷設定画面がWindowsの「設定」ベースのモダンな感じに変わってしまい、上記の設定が引き継がれなくなってしまいました。 色々調べたところ、レジストリを以下のように設定すればもとの印刷ダイアログに戻るということがわかり、実際確認できました。 ハイブ: HKEY_CURRENT_USER キーのパス: SOFTWARE\Microsoft\Print\UnifiedPrintDialog 値の名前: PreferLegacyPrintDialog 値の種類: REG_DWORD 値のデータ: 1 [参考] https://answers.microsoft.com/ja-jp/windows/forum/all/win-32/77e2e4de-9d07-4ee9-9967-3c3aa3d60ede AD環境ですべての端末に反映したかったので、グループポリシーの[ユーザーの構成]-[基本設定]-[Windowsの設定]-[レジストリ]にて上記の項目を「更新」で登録し、全ユーザーに配布したところ、症状が解消されました。 配布対象にはWindows10の利用者もいましたが、問題なく利用できています。

TL;DR Windows 11でChrome Remote Desktopを利用して別PCに接続すると、右側のShiftキーの信号が接続先に渡らない。 「以前のバージョンのMicrosoft IMEを有効にする」を有効にすると解消される。 経緯 Windows 11のPCよりChrone Remote Dekstopで別のWindowsに接続時、なぜかパスワード認証が通らない事象が発生。 入力した内容を確認すると、一部大文字で入力したはずの文字が小文字のまま。意図せず小文字となった文字は一部。どうも、キーボードの右側のShiftキーを使って大文字にしようとしている文字が小文字になっていると判明。 ググってみると、いくつかの場所で報告されている Right shift not recognised when using Chrome Remote Desktop #1631(mRemoteNG) Chromeリモートデスクトップで右Shiftキーが効かない(まめのプラモデル工房) Chrome Remote Desktopのキーマップ設定で右Shiftを左Shiftにマップしたが、解消せず。PowerToysで解消するという記事もあったが、それだけのためにインストールするのも… と思い、Windows IMEの設定を以前のバージョンに戻したところ、症状が解消した。 mRemoteNGのサイトに本障害が報告されたのが2019年なので、もう解消する気はないのかもしれない… Google側はMicrosoft IMEの問題と認識し、Microsoftは逆、とかかな…

TL;DR Zabbixは6.0よりhistoryテーブルに主キーを使うようになりました。server,frontendのパフォーマンス向上とテーブルサイズ削減が見込めるようです。 https://www.zabbix.com/whats_new_6_0#performance_improvements 公式のDockerコンテナを運用している場合、DBコンテナは別なので/usr/share/zabbix-sql-scripts/mysql/history_pk_prepare.sqlがなく、以下から取得したところ、うまくいきました。 https://git.zabbix.com/projects/ZT/repos/rsm-scripts/browse/database/mysql/history_pk_prepare.sql 経緯 Zabbixのダッシュボードのシステム情報に、「データベースのヒストリテーブルが主キーを使用: いいえ」と表示されていることに気づきました。 調べたところ、Zabbix 6.0よりhistoryテーブルの主キーの使用に対応しているとのことでした。 https://www.zabbix.com/whats_new_6_0#performance_improvements 新規に6.0以降をインストールすれば自動で主キーが設定されるが、以前のバージョンのアップグレードの場合は手動で対応する必要があるようです。 https://www.zabbix.com/documentation/6.0/en/manual/appendix/install/db_primary_keys 弊社の環境は公式のDockerコンテナで運用してて、DBはMariaDBの公式Dockerコンテナを使用しています。「MySQL 8.0+ with mysqlsh」の手順に従って進めたところ、途中で指定されている「/usr/share/zabbix-sql-scripts/mysql/history_pk_prepare.sql」が見つかりません。 この手順は1つのサーバーにweb,server,DBをインストールする想定と思われます。公式のDockerコンテナのweb,serverをマウントしてファイル名で検索しても見つからず。 単体のZabbixサーバを構築してファイルを取り出すのも面倒だったのでいろいろ検索し、公式のリポジトリと思われる以下よりダウンロードして流し込んだところ、うまくいきました。 https://git.zabbix.com/projects/ZT/repos/rsm-scripts/browse/database/mysql/history_pk_prepare.sql

TL;DR 2023年5月2日15:00現在、Office 365の最新のExcelで半角カナのファイル名をつけ、OneDrive同期対象のフォルダで開くと毎回保護ビューになる不具合があるようです。 やはりファイル名に半角カナは避けたほうが良いのかもしれません… 経緯 利用者より、自分の場合だけExcelファイルを開くと毎回保護ビューになるとのこと。試してみると、ファイルサーバ上で開く際には初回に保護ビューとなり、「編集を有効にする」をクリックすると以降は保護ビューにはならない。が、どうもインターネットからダウンロードしたファイルではないっぽいのが気になる。なぜ保護ビューに? このファイルを、OneDriveで同期しているデスクトップで開くと、初回だけでなく、毎回保護ビューになる。「編集を有効にする」をクリックしても。 7-zipがMark-of-the-Webに対応したニュースは知っていたので、これが原因だろうとあたりをつけ、再現を試みるもどうにもダメ。Mark-of-the-Webの場合はエクスプローラーでファイルのプロパティに「Security」の項目が追加されチェックボックスが表示されるはずが、表示されない… https://www.bleepingcomputer.com/news/microsoft/7-zip-now-supports-windows-mark-of-the-web-security-feature/ Excelにて保護ビューのチェックボックスのうち、「インターネットから取得したファイルに対して、保護ビューを有効にする」のチェックをしたときのみ発生するので、Mark-of-the-Webと絡んでいそうなものなのだが、上記の通りファイルのプロパティには該当の項目が表示されない。 まさかとは思ったが、念のためと思い、ファイル名に含まれている半角カナを削除したところ問題が解消…マジか… 検証したところ、半角カナがファイル名に含まれると発生する、発生するのはExcelのみ、かつ2023/5/2 15:00時点で最新の 2304(build 16327.20214)で発生することまで突き止められた。(たまたま社内にあった、古いバージョンのExcelでは発生しなかった) 同様の症状がWebでは見つからなかったので、現時点で未解決の問題と判断。利用者には半角カナを全角カナに変えることでの暫定対応を指示。Win+FでFeedback Hubにて報告した。 1日つぶれてしまった…

TL;DR SQLは明らかにあっているのに動作が遅い、与えるパラメータによって変わるといった状況ではEXPLAINで実行計画を確認しましょう 意図しない駆動順になっていることがあります 経緯 仕事での話のため詳細なSQLの内容はかけないが、MariaDB(10.6.12)でざっくりと以下のようなSQLで特定の伝票番号を指定した場合に応答が遅くてタイムアウトする事象が発生ました。 SELECT ... FROM ( ( A INNER JOIN B ON B.PRODUCT_CD = A.PRODUCT_CD ) LEFT OUTER JOIN C ON C.CUSTOMER_CD = A.CUSTOMER_CD C.PRODUCT_CD = A.PRODUCT_CD AND C.SIZE = A.SIZE ) LEFT OUTER JOIN C AS D ON D.CUSTOMER_CD = A.CUSTOMER_CD D.PRODUCT_CD = A.PRODUCT_CD AND D.SIZE = 0 WHERE A.SLIP_NO = 123456789 本当はもっと多数のテーブルをJOINしていましたが、最小限の要素だけ引っ張ってきてます。 それぞれの結合条件は主キーを使用しています。 で、WHERE句に指定した伝票番号が特定の番号の場合に、応答が返ってこずにタイムアウトになる事象が発生しました。ほかの伝票番号を指定するとすぐ返ってくるので、SQLに文法エラーはないです。 最後のC AS Dの外部結合を外すとすぐ帰ってくるのですが、そもそもこのテーブルの結合条件にマッチするデータがないので、この伝票番号の場合にデータが多くなる、というわけでもないです。 今までこの手の問題に当たったことがなかったので使わずに済んでいた、これまで避けていたEXPLAIN文を使って実行計画を見てみました。 すると、駆動表が以下の順番になっていました。 A(PK) C(PK) D(PK) B(Null) カッコ内はキーです。A,C,Dは主キーで結合できていますが、BはNULLとなってしまっていました。 ここからは推測になりますが、テーブルB,C,DのいずれもテーブルAから結合できるので、統計データの不足なども絡んだ結果、上記のような結合順になったのではないかと考えています。...