Windows Server 2022で新しく作成したActive Directory(AD)のドメイン機能レベルはWindows Server 2016。
Windows Server 2019やWindows Server 2022では新しく、ドメイン機能レベルは追加されていないため、機能レベルはWindows Server 2016で作成される。
Windows Server 2022で新しく作成したActive Directory(AD)のドメイン機能レベルはWindows Server 2016。
Windows Server 2019やWindows Server 2022では新しく、ドメイン機能レベルは追加されていないため、機能レベルはWindows Server 2016で作成される。
タイトルのままではあるが、Windows11からWindows Server 2003 R2上のSQL Server 2005にODBC接続できない。
セキュリティの関係で接続できない。ODBCドライバのバージョンを古いものに変えてもできないので、OSレベルでのセキュリティの問題で接続できない。
Windowsから、WSL(WSL2含む)のLinuxの領域にエクスプローラーでアクセスすることができる。
エクスプローラーからアクセスするには、アドレスバーに、`\\wsl$`と入力して、Enterキーを押すと表示される。WSLの領域はネットワークドライブとして、アクセスされる。
\\wsl$
インストールした環境名を続けて入力することで、ルート以下のフォルダを表示できる。
\\wsl$\Ubuntu
エクスプローラーで開いた後は、ファイルの書き込みや読み出しも可能。ただ、Linuxのシステム領域などはいじらないほうがいい。
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.0が使えていたようだ。このHomeエディションで、追加インストール必要なものになるとのこと。ここまでくると、あと1年後くらいにはSMB1.0インストール用のバイナリも提供されなくなりそうだ。
SMB1.0が使えなくなるとどうなるか。古いWindowsの共有にアクセスできなくなったり、古いNASの共有にアクセスできなくなる。あとは、AD側でSMB1.0サポートがなくなると、古いWindowsからADの管理共有などへのアクセスができなくなるなどの影響があると思われる。古いWindows(Windows XPとかWindows Server 2003など)が残っている場合には注意しておく必要あり。
クリーンインストールした直後のWindows10 Ver.21H2で、Officeツール(Microsoft 365のWordやExcelなど)にログインすると、TPMのエラーが出てログインできない。エラーの内容は下記。
問題が発生しました
ご使用のコンピュータのトラステッドプラットフォームモジュールが正しく機能していません。このエラーが解決しない場合は、システム管理者に連絡して、エラーコード 80090034 をお知らせください。
サーバメッセージ: 暗号化に失敗しました
試したことは・・・
最初は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は厄介だ。
分散仮想スイッチは、vCenter Serverに設定されるリソース。そのため、vCenter Serverをリプレイスするときに、前の設定を引きつながない場合には、再設定が必要になる。
分散仮想スイッチは、ESXiのホストやクラスタの設定ではないので、注意が必要。忘れるのでメモ。
vROpsのサイジングのガイドライン。ガイドラインでの大きな指針は、CPU数とメモリサイズ。これが監視対象となるホストの数とゲストの数から、サイジングされる。データを保管するHDDサイズについては載っていない。HDDというかVMDKは追加できるから、ということだろう。
vRealize Operations 8.5 Sizing Guidelines (85062) (vmware.com)
https://kb.vmware.com/s/article/85062
Redmineで、ユーザを消したら、消したユーザの担当していたものが、担当者の欄が空白(表示されない)になった。アカウントを消すと、ユーザ情報も消えるから、チケットの表示も変わるのね。Redmineはユーザの削除じゃなくて、停止にしておかないと、過去のチケットなどをみるときに不具合がでると。
学んだ。
企業の標準ブラウザをどうするかについて考えてみた。個人的な見解だが、先に結論から書くと・・・
でよいと思う。
標準ブラウザをChromeとEdgeのどちらにするか、ということについてはデバイスおよびブラウザでの設定の同期(お気に入りやパスワードなど)をどうするかが中心になる。
これは、設定の同期を許可するかどうかを、ログインするアカウントの管理で行うことができる。ここが2つのブラウザの大きな差というか特徴になる。
例えば、M365BPやE1以上を使っており、Google Workspaceを使っていないなら、たぶん、Edgeの方が管理性がよい。かつ、グループポリシーなどで、Edgeの設定も変えることができる。MacやAndroidの場合は、グループポリシーは使えなくとも、Edgeは提供されるので、同じような環境にすることもできる。Windowsで環境が組まれているのであれば、Edgeの方がよい。
ただ、Windows10の管理で、古いバージョンのWindows10がいる場合は、個別にインストールしていかなければならない手間があるので、そこは最初の手間が必要だ。
逆に、Google Workspaceを使っているのであれば、Chromeの方が使いやすくなる。あとは、Chromebookを採用したりして、企業管理を行う場合もChromeの方がよい。ChromeにはChrome Enterpriseというバージョンが存在し、セキュリティ設定などを行うことができるが、別にライセンスを購入する必要があるなど、不明瞭な部分が多い。
あと共通して言えることは、ChromeもEdgeもリリースが1か月~2か月で、どんどん新しいバージョンがリリースされていく。そのため、PC側は常に新しいバージョンにしなければならないということ。基本的には、自動更新をONにしておくことで、新しいバージョンになっていく。Edgeの場合も、Windows Updateとは独立してバージョンが上がっていく。そのため、特定バージョンに固定して、使い続けるのは困難だということ(他のブラウザ、Firefoxなどもどんどん新しくなる。)。アップデートのタイミングもあるので、最新を含む直近2世代のバージョンがよい。
インターネットにつながず、イントラ環境でのみ使うPCがあり、ウェブシステムがあったときには、なかなか厳しい。固定できなくもないが、次に環境を作るときに、そのバージョンをインストールできるとは限らない。
それから常に新しいバージョンのブラウザになるということは、サポートされるJavaScriptのバージョンも変化する。機能追加されていく分には、よいのですが、マレに機能削除が行われる。そのため、パッケージを導入している場合には、最新のパッチを当て続ける必要がある。自社開発の場合には、影響の見極めが必要になる。例えば、2010年ごろは、Chromeで、JavaScriptのShowModalDialogが使えたが、2014年とかに廃止が発表され、数年後につかえなくなった。アプリのリリース時には、Chromeでテストをしていても、時がたつと使えなくなるものも出てくる。なので、システム運用側も、それなりの覚悟が必要になる。特に利用期間の長いシステムがある場合には・・・。ここは、どちらを選ぶかというよりも、ChromeかEdgeかを考えるときには、そのアップデートのスピードに対応した運用や見直しが必要なってくることを意識する必要がある。
ブラウザのデフォルトの検索エンジンは、Edgeであっても、Googleに変更することができるので、そこは柔軟になった。
標準ブラウザが、ChromeかEdgeかは、使っているプロダクト(Google WorkspaceかM365か)やOSによって、選択するのが良い。
ファイルオーナーを変えてもFTPログインなしでWordpressのアップデートができない。そんなはずはないと思い、いろいろとチェックしたら、wp-config.phpに、過去にFTPの代わりにSSH2でアップデートをするために加えたFS_METHODの指定があった。これが邪魔をしていたようで、消したところ、FTPのユーザを聞かれずにアップデートができるようになった。
/** SSH SFTP Updater **/
define('FS_METHOD', 'ssh2');
設定を変えようと思ったのは、SSH2でのアップデートが失敗するようになったのが原因。プラグインの過去の設定と競合して、機能しなくなるとは。コンフィグまでちゃんと見直す必要はある。