カテゴリー: Windows

  • .NET Core 3.1をAzure上でサポート期間後も使い続けられるのか?

    LTSの .NET Core 3.1が2022年12月3日に延長サポートが終了する。オンプレミスの環境ならば、自己責任で使い続けられるのだが、Azure上だとどうなるのかが気になり調べていた。それでやっと見つけたのが、下記の記事だ。

    https://azure.microsoft.com/ja-jp/updates/extended-support-for-microsoft-net-core-31-will-end-on-3-december-2022/

    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でも有効だった。方法は下記。

  • Windows11からWindows2000にリモートデスクトップ接続ができた

    テストができる環境があったので、Windows11のリモートデスクトップクライアントを使って、Windows2000にリモートデスクトップ接続を試してみた。試したところ、あっさりと接続ができた。

    Windows Server 2003にも、Windows11からリモートデスクトップ接続はできた。

    UIは変わっているけれど、いまのところWindows10と大差がない感じだ。Windows11は、レガシーなシステムの管理にも使えそうでよかった。

  • Windows11をドメイン参加させる

    基本的には、Windows10のときと大して変わらない。「システムのプロパティ」を開くまでの手順が変わる。

    1. スタートアイコンを右クリックして、「設定」をクリックする
    2. 「システム」が開くので、一番の下にある「バージョン情報」をクリックする
    3. 「ドメインまたはワークグループ」をクリックする
    4. 「システムのプロパティ」が開くので、「変更」をクリックする。
    5. ドメインを指定し(もしくはワークグループを指定する)、「OK」をクリックする。
    6. 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にログオンすることもできる。

  • AD機能レベルがWindows2000ネイティブでも、Windows 11は参加できた

    AD機能レベルがWindows2000ネイティブでも、Windows 11は参加できた。ADのアカウントでのログインなどは問題なし。グループポリシーは、古いままなので、Windows11を完全に制御することはできない。とりあえず、ユーザの管理というだけであれば問題なし。

    Active Directoryの互換性というか吸収力の高さはすごい。グループポリシーとか新機能を気にしなければ使い続けられる。切替タイミングがないというのも困りものだが。

  • Windows Server 2022をインストールしたときの注意など

    Windows Server 2022 Standard をクリーンインストールしたときの注意点や、バージョン情報など。

    インストールは、ほぼWindows Server 2019と変わらないが、インストール時にインストールするオペレーティングシステムを選ぶ画面がある。ここで、「Windows Server 2022 Standard」と「Windows Server 2022 Standard (デスクトップ エクスペリエンス)」を選択する必要があるのだが、Windows10のようにGUIでグラフィカルに操作する場合は、後者の「Windows Server 2022 Standard (デスクトップ エクスペリエンス)」を選択する。そうしなと、Server Coreのようになってしまう。

    デスクトップエクスペリエンスでインストールすると、ほぼWindows10と同じような環境になる。

    インストールしたあとのバージョンは、「バージョン 21H2 (OSビルド )」になる。

    それから、デフォルトでChromium Edgeがインストールされている。一応、IE11も単体で起動できた。なので、EdgeのIEモードを使わなくても、IE11が開ける。