memo.

カテゴリー: Windows

  • そろそろWindowsではSMB1.0でのアクセスが完全に廃止されそうだ

    Microsoftが、WindowsでのSMB1.0のサポート廃止が最終段階に入ったと発表したとのこと。

    「SMB 1.0」サポート廃止は最終段階 ～プレビュー版Windows 11 Homeで既定無効に
    https://forest.watch.impress.co.jp/docs/news/1404113.html

    Windows10 Proでは、機能追加でSMB1.0のClientを追加インストールしないと使えなかったが、Homeエディションでは、まだデフォルトでSMB1.０が使えていたようだ。このHomeエディションで、追加インストール必要なものになるとのこと。ここまでくると、あと1年後くらいにはSMB1.0インストール用のバイナリも提供されなくなりそうだ。

    SMB1.0が使えなくなるとどうなるか。古いWindowsの共有にアクセスできなくなったり、古いNASの共有にアクセスできなくなる。あとは、AD側でSMB1.0サポートがなくなると、古いWindowsからADの管理共有などへのアクセスができなくなるなどの影響があると思われる。古いWindows（Windows XPとかWindows Server 2003など）が残っている場合には注意しておく必要あり。

  • SQL Serverのデータベースコピーができる条件

    SQL Server Management Studio（SSMS）で、タスクからデータベースのコピーを選べるものと選べないものがある。ずっと、なんでなんだろうかと思っていた。やっと理由がわかった。SSMSからデータベースのコピーができないのは、そのデータベースがSQL ServerのExpress Editionだからだ。または、SQL ServerのStandard Editionであっても、SQL Server Agentのサービスが起動していないとき。

    SSMSでデータベースのコピーができるのは、以下の２つの条件を満たしているもののみ。

    • SQL ServerのStandard Edition以上（Express Editionではできない）
    • SQL Server Agentのサービスがコピー元とコピー先で起動していること。（起動していないと失敗する）

    SSMSのバージョンか、設定だと思っていたが、SSMSではなくて、SQL Serverの問題だった。

    参考URL

    https://docs.microsoft.com/ja-jp/sql/relational-databases/databases/use-the-copy-database-wizard?view=sql-server-ver15

  • SQL Server 2005から SQL Server 2019へのリンクサーバーの接続ができた

    前回、SQL Server 2019からSQL Server 2005へのリンクサーバーでの接続ができたので、今度はその逆を試した。Windows Server 2003の上のSQL Server 2005から、Windows Server 2022の上のSQL Server 2019に対して、リンクサーバーの設定をしたところ、接続でき、データの参照もできた。

    リンクサーバーの設定のとき、接続は「SQL Server」を選択して、接続した。

  • Windowsはメモリが不足するとファイルのコピーに失敗する

    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でExcelにログインするとTPMエラーがでる問題の対処

  • システムファイルチェックを実行してWindows10を修復する

    Windows10のOS動作が不安定の場合は、システムファイルチェックを実行して、修復を試す。

    1. コマンドプロンプトを管理者モードで開く。
    2. `sfc /scannow` コマンドを実行する。
    3. チェックと修復が行われ、結果が表示される。

    これで完了。

    参考：　
    https://support.microsoft.com/ja-jp/topic/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0-%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB-%E3%83%81%E3%82%A7%E3%83%83%E3%82%AB%E3%83%BC-%E3%83%84%E3%83%BC%E3%83%AB%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%A6%E4%B8%8D%E8%B6%B3%E3%81%BE%E3%81%9F%E3%81%AF%E7%A0%B4%E6%90%8D%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0-%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%92%E4%BF%AE%E5%BE%A9%E3%81%99%E3%82%8B-79aa86cb-ca52-166a-92a3-966e85d4094e

  • システムファイルチェックを実行してWindows10を修復する

    Windows10のOS動作が不安定の場合は、システムファイルチェックを実行して、修復を試す。

    1. コマンドプロンプトを管理者モードで開く。
    2. `sfc /scannow` コマンドを実行する。
    3. チェックと修復が行われ、結果が表示される。

    これで完了。

    参考

    https://support.microsoft.com/ja-jp/topic/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0-%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB-%E3%83%81%E3%82%A7%E3%83%83%E3%82%AB%E3%83%BC-%E3%83%84%E3%83%BC%E3%83%AB%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%A6%E4%B8%8D%E8%B6%B3%E3%81%BE%E3%81%9F%E3%81%AF%E7%A0%B4%E6%90%8D%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0-%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%92%E4%BF%AE%E5%BE%A9%E3%81%99%E3%82%8B-79aa86cb-ca52-166a-92a3-966e85d4094e

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

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

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

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