前回、SQL Server 2019からSQL Server 2005へのリンクサーバーでの接続ができたので、今度はその逆を試した。Windows Server 2003の上のSQL Server 2005から、Windows Server 2022の上のSQL Server 2019に対して、リンクサーバーの設定をしたところ、接続でき、データの参照もできた。
リンクサーバーの設定のとき、接続は「SQL Server」を選択して、接続した。
カテゴリー: Windows
-
Windowsはメモリが不足するとファイルのコピーに失敗する
Windowsはメモリが不足するとファイルのコピーに失敗する。そしてロールバックして、途中までのものも消える。
遅いネットワークで、別のサーバからのデータのコピーで、単一の大きなファイルだったので、時間がかかって、結果的にメモリが足りなくなって、失敗した。メモリも増えているので、レアケースになっているのかもしれないけれど。やはりメモリの空きは重要だ。
-
.NET Core 3.1をAzure上でサポート期間後も使い続けられるのか？
LTSの .NET Core 3.1が2022年12月3日に延長サポートが終了する。オンプレミスの環境ならば、自己責任で使い続けられるのだが、Azure上だとどうなるのかが気になり調べていた。それでやっと見つけたのが、下記の記事だ。
https://azure.microsoft.com/ja-jp/updates/netcore31/
2022年12月3日を過ぎても、Functions でホストされているアプリケーションは引き続き実行され、アプリケーションは影響を受けないとのこと。いきなり使えなくなるということはなさそうだ。サポート切れ後に、新しく.Net Core 3.1でデプロイできるのかどうかは不明だが、この書き方だと当面は大丈夫そうではある。
しかし、Azure側の推奨としては、「潜在的なサービスの中断やセキュリティの脆弱性を回避するには、2022 年 12 月 3 日までに、Functions アプリケーションをランタイム バージョン 4.x (.NET 6 を使用する)に更新」することが求められている。何かセキュリティ的な問題が発生した場合には、短い期間で.NET Core 3.1のアプリケーションの実行が打ち切られるということもあり得るということ。さっさとLTSの.NET6に移行しろということだ。
Azure App Serviceのインスタンスでも、App Service でホストされているアプリケーションは引き続き実行され、既存のワークロードには影響しないとのこと。ただし、同じように.NET6への移行が推奨されている。
-
VMware vCenter Converter Standalone 6.2 でWindows Server 2003 の変換がエラーになる。
VMware vCenter Converter Standalone 6.2 でWindows Server 2003 を仮想マシンに変換しようとしたところ、Agentのデプロイで「Error code: 1,603」でエラーになった。
サポート範囲を調べてみると、Windows Server 2003は、Windows Server 2003 R2 SP2がサポート対象で、R2が付かないバージョンはサポート対象外だった。
サポート外だが、無理やりP2Vできなかと、Converter Agentだけのインストールをためしてみたが、サービスをオンにするところで、失敗してロールバックした。
調べてみると、VMware vCenter Converter Standalone 5.0 であれば、無印のWindows Server 2003にインストール可能。試してみたところ、5.0であればインストールはできた（過去にインストーラーを取得しておいてよかった）。しかし、VMware vCenter Converter Standalone 6.2からの接続は、接続経路の暗号化方式の不一致により、エラーになった。
今度は、vCenter Converter Standalone 5.0 から、ESXi6.7に対して、P2V先を指定してみたが、これも通信時の暗号方式の問題で接続できずエラーになった。
Veeam Backupのエージェントを、Windows Server 2003（無印）にいれて、イメージバックアップして、そのイメージを仮想マシンとして復元する方法も試した。Veeam BackupもVersion 9.5でも.net frameworkのバージョンが古すぎて、Windows Server 2003（無印）にエージェントのインストールができず。イメージバックアップを取得して、仮想マシンとしてリストアする方法についても失敗した。
そのため、vCenter Converter Standalone 5.0を使って、Windows Server 2003（無印）を一度、VMware Workstation形式の仮想ファイルに変換した。次に、このVMware Workstation形式のファイルを、vCenter Converter Standalone 6.2で指定し、V2V（Virtual to Virtual）で、ESXi6.7に対して保存した。これで、なんとかP2Vは成功した。ネットワークの設定などは、変わっているため、仮想マシンの設定を編集して、新しくネットワークインターフェースの割り当てを行った。これで無事にWindows Server 2003（無印）のP2Vは完了した。
仮想化すれば延命はできるが、物理サーバとして存在していると、そもそもP2Vでの仮想化の対象外になってしまう。延命するのであれば、早めに仮想化しておく必要がある。というのが、今回の教訓になった。
-
Windows10 ver.21H2でOfficeツールへのログインでTPMのエラーがでる。
クリーンインストールした直後のWindows10 Ver.21H2で、Officeツール（Microsoft 365のWordやExcelなど）にログインすると、TPMのエラーが出てログインできない。エラーの内容は下記。
問題が発生しました ご使用のコンピュータのトラステッドプラットフォームモジュールが正しく機能していません。このエラーが解決しない場合は、システム管理者に連絡して、エラーコード 80090034 をお知らせください。 サーバメッセージ： 暗号化に失敗しました
試したことは・・・
- これの対処として、PCを工場出荷状態に戻して再セットアップしたり、TPMのクリアなども行ったが、解決できなかった。
- M365のアカウントも作り直してみたが、関係なし。
- エラーになったユーザで、別のPCでログインすると問題なし。
- PCのローカルアカウントでログインすると、M365アカウントでログインできるが、Active Directoryのユーザだと、このエラーが発生する。
- BitLockerでドライブを暗号してみたが、M365のアカウントのログインではエラーになる。BitLockerの暗号化は正常に終了しているのに。
最初は1台だけだったのだが、同じセットアップで、かつ別メーカーのPCでも、同じ現象が発生することがわかった。2台で同時に発生しているので、TPMの故障という可能性は薄くなった。
さらに切り分けていった結果、2022年1月のWindows Update（つまり今月のWindows Update）で配信されていた「KB5009543」をアンインストールして、WordやExcelからM365アカウントでログインすると正常にログインできた。PCを再起動させてみたが、再起動後もログインされた状態はキープされており、問題がなかった。
Windows10の21H2で、AD環境で、2022年1月のWindows Updateで、KB5009543が適用されており、新規にM365のアカウントで、Officeにログインをするときに発生する問題と思われる。Windows Updateは厄介だ。
このM365でアカウントでログインするときのTPMのエラーの調査だけで、先週から何時間というか何日使ったことことだろうか。Windows Updateは厄介だ。最新版にして、これなので、辛い。
追記。
Windows11でも同じことが発生して、そちらはWindows Updateのアンインストールでは解消しなかった。かわりに、レジストリキーの変更で回避できる。レジストリキーでの対処は、Windows10でも有効だった。方法は下記。
-
システムファイルチェックを実行してWindows10を修復する
Windows10のOS動作が不安定の場合は、システムファイルチェックを実行して、修復を試す。
- コマンドプロンプトを管理者モードで開く。
- `sfc /scannow` コマンドを実行する。
- チェックと修復が行われ、結果が表示される。
これで完了。
-
システムファイルチェックを実行してWindows10を修復する
Windows10のOS動作が不安定の場合は、システムファイルチェックを実行して、修復を試す。
- コマンドプロンプトを管理者モードで開く。
- `sfc /scannow` コマンドを実行する。
- チェックと修復が行われ、結果が表示される。
これで完了。
参考
-
Windows11からWindows2000にリモートデスクトップ接続ができた
テストができる環境があったので、Windows11のリモートデスクトップクライアントを使って、Windows2000にリモートデスクトップ接続を試してみた。試したところ、あっさりと接続ができた。
Windows Server 2003にも、Windows11からリモートデスクトップ接続はできた。
UIは変わっているけれど、いまのところWindows10と大差がない感じだ。Windows11は、レガシーなシステムの管理にも使えそうでよかった。
-
Windows11をドメイン参加させる
基本的には、Windows10のときと大して変わらない。「システムのプロパティ」を開くまでの手順が変わる。
- スタートアイコンを右クリックして、「設定」をクリックする
- 「システム」が開くので、一番の下にある「バージョン情報」をクリックする
- 「ドメインまたはワークグループ」をクリックする
- 「システムのプロパティ」が開くので、「変更」をクリックする。
- ドメインを指定し（もしくはワークグループを指定する）、「OK」をクリックする。
- OSを再起動する。
なお、「バージョン情報」は、エクスプローラーからPCを右クリックして、プロパティでも開くことができる。
-
AD機能レベルがWindows2000ネイティブでも、Windows Server 2022は参加できた
Active Directoryのドメインの機能レベルが「Windows 2000 ネイティブ」のADに対して、Windows Server 2022をドメイン参加させることができた。
Windows Server 2022が参加できたADのレベル
- ドメイン機能レベル： Windows 2000 ネイティブ
- フォレストの機能レベル： Windows 2000
AD上でも、追加したサーバは、Windows Server 2022として表示されていた。ADの機能レベルは、かなり古いので、グループポリシーにはないものが多いので、Windows Server 2022をグループポリシーで管理しきることはできないので、注意は必要。
しかし、Windows 2000 ネイティブであっても、Windows Server 2022はADに参加させられるし、ADのユーザでWindows Server 2022にログオンすることもできる。