windows

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 Active Directryに参加していないWindow10をWSL2のUbuntu20.04にインストールしたAnsibleで操作する環境を構築しました。kerberos認証が必要ない分、AD参加済みの環境よりは簡単な手順でした。 手順 Windows 10 WSL2を有効にし、Ubuntu20.04をインストール リモート接続を受け付けるための設定(要管理者権限) Invoke-WebRequest -Uri https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1 -OutFile ConfigureRemotingForAnsible.ps1 powershell -ExecutionPolicy RemoteSigned .\ConfigureRemotingForAnsible.ps1 Ubuntu20.04 最新のAnsibleをインストール sudo apt update sudo apt install software-properties-common sudo apt-add-repository --yes --update ppa:ansible/ansible sudo apt install ansible https://docs.ansible.com/ansible/2.9_ja/installation_guide/intro_installation.html#ubuntu-ansible 以下のaptパッケージのインストール python3-pip gcc pip3で以下のPythonライブラリをインストール pywinrm inventory.ymlに以下の記述を記載 windows: hosts: 192.168.yy.yyy: ansible_connection: winrm ansible_user: user_name ansible_winrm_server_cert_validation: ignore ansible_winrm_transport: basic ansible_port: 5986 ansible -i inventory.yml 192.168.yyy.yyy -m win_ping が成功することを確認

TL;DR Active Directryに参加しているWindow10をWSL2のUbuntu20.04にインストールしたAnsibleで操作する環境を構築しました。複雑な手順が必要ですが、操作できることを確認しました。 手順 Windows 10 WSL2を有効にし、Ubuntu20.04をインストール リモート接続を受け付けるための設定(要管理者権限) Invoke-WebRequest -Uri https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1 -OutFile ConfigureRemotingForAnsible.ps1 powershell -ExecutionPolicy RemoteSigned .\ConfigureRemotingForAnsible.ps1 Ubuntu20.04 最新のAnsibleをインストール sudo apt update sudo apt install software-properties-common sudo apt-add-repository --yes --update ppa:ansible/ansible sudo apt install ansible https://docs.ansible.com/ansible/2.9_ja/installation_guide/intro_installation.html#ubuntu-ansible 以下のaptパッケージのインストール python3-pip gcc python-dev libkrb5-dev krb5-user pip3で以下のPythonライブラリをインストール pywinrm[kerberos] kerberos requests_kerberos pykerberos 以下の内容で/etc/krb5.confを修正 [libdefaults] default_realm = EXAMPLE.COM kdc_timesync = 1 ccache_type = 4 forwardable = true proxiable = true [realms] EXAMPLE.COM = { kdc = dc1....

TL;DR Hyper-Vでホストとゲストが通信できない場合、まず、Windowsの仮想NICができているか確認したほうが良いかも。 経緯 Hyper-Vでホストとゲストがどうしても通信できないということがありました。久々に利用したPCだったので設定がおかしくなってしまったのかも。 例えば外部スイッチにつないでホスト、ゲストともにゲートウェイまでは通信できるけどお互いへの通信ができない。別のPCからゲストへの通信はできる。 内部スイッチにつないでもだめ。 基本に立ち返ろうと、村嶋 修一氏のHyper-Vネットワークの基本を見たところ、外部ネットワークでホストと共有設定した場合、および内部ネットワークを作成した場合にホストに作成されるはずの仮想NICが無いことに気付きました。 http://www.vwnet.jp/windows/WS12R2/Hyper-V/Hyper-V_Network.htm いったんスイッチを再作成しようと思い、内部ネットワークのスイッチを削除。 が、外部ネットワークのスイッチはエラーで削除できない。 これは内部的におかしくなっていると判断。いったんHyper-Vをアンインストール。 が、仮想NICが1つだけ残ってしまい、コントロールパネルのネットワーク接続からは削除できない(グレーアウトされている)ためデバイスマネージャーからアンインストール。 その後、再起動を経て再度Hyper-Vをインストールしたところ、外部/内部ネットワークのスイッチ作成時にホスト上に対応した仮想NIC(スイッチ名が「ExternalSwitch」であれば「vEthernet(ExternalSwitch)」というNIC)が作成されていることが確認できました。 ゲスト-ホスト間の通信も問題なし。 トラブルシューティングは、目先のエラーメッセージから安直に検索するのではなく、技術的な基礎に立ち返って原因を下から追いかけることが大事ということを改めて認識しました。