Windows11を使っていると、突然「おすすめ」の通知設定が画面右下に出てきて鬱陶しいという話。
Windows 10あたりからUIがちょいちょい変わるので、設定箇所がどこかサクッと見つからないのも困りもの。
2025年5月段階だと、下記手順で無効化設定するのが一番早い気がする。
- タスクバー右下の日時を右クリック -> [通知設定] をクリック

2. 「おすすめ」をオフに変更

以上でマイクロソフトの広告は出てこなくなるかと。
ActiveDirectoryのグループポリシーを用いて、配下PCに対して特定のURLのみChromeからアクセスできるようにする手順をまとめてみた。
Windows Server 2025 Standard
・特定のURLのみブラウザでアクセスを許可
・それ以外のURLはすべてブロック
・ADのグループポリシーを使って実現
https://enterprise.google.com/chrome/chrome-browser/#downloadからADMXテンプレートをダウンロードし任意の場所に解凍
<下準備>
下図のとおり、管理用テンプレートがセントラルストアになっていない場合は、事前にC:\Windows\PolicyDefinitionsをC:\Windows\SYSVOL\domain\Policiesにコピーしてセントラルストア化しておく。セントラルストアにすることで、各ADごとに管理用テンプレートの設定を行わずに済む。
1.先の手順で解凍したadmxフォルダ内の「ja-JP」と「chrome.admx」をC:\Windows\SYSVOL\domain\Policiesフォルダ下にコピー
2.ADのグループポリシー管理エディターを開く
3.適当なGPOを作成
4.[コンピュータの構成] – [ポリシー] – [管理用テンプレート]をクリックし、「Google Chrome」が存在することを確認
ChromeブラウザからアクセスできるURLを設定する。
1.[コンピューターの構成] – [ポリシー] – [管理用テンプレート] – [Google Chrome] – [URLのリストへのアクセスを許可する] を開く
2.「有効」にチェックを入れ、アクセス許可
許可リストに入っていないURLはすべてブロックするようにする。
1.[コンピューターの構成] – [ポリシー] – [管理用テンプレート] – [Google Chrome] – [URLのリストへのアクセスをブロックする] を開く
2.ブロックするURLリストを列挙する。
・http://*
・https://*
以上で、アクセス許可をしたURLのみChromeから接続できるようになる。Edgeも同様にテンプレートを落として設定すれば対応可能。
ブロックの設定で「*」を入れると不具合が出まくった…
この設定を入れるとChromeの各機能が呼び出せなくなり、例えば印刷プレビューが起動しなくなる。これを回避するために許可リストのほうに「Chrome://*」を追加すると、印刷プレビューは起動するようになるも、肝心のプレビュー画面が表示されない状態。おそらく、「Javascript」か「custom_scheme」あたりが影響していると思われるが(未検証)、いずれにせよ予期せぬトラブルが発生しがち。
というわけで、単純にURLをブロックしたいだけならhttps縛りにしたほうが事故が発生しなくてよい。
SharePoint OnlineをPowerShellで操作する方法はいくつかあるけれど、Invoke-Webrequestを使わずやってみる。
バッチ処理が前提のため、まずEntra IDからSharePoint Online操作用のアプリを登録する。
■ 必要な設定項目のみ抜粋
[構成されたアクセス許可]
・Microsoft Graphから「アプリケーションの許可」
・Files.ReadWrite.All
・Sites.Read.All
[証明書とシークレット]
自己証明書の作成とThumbprintの取得
$certname = "spo-test"
$crt = New-SelfSignedCertificate -Subject "CN=$certname" -CertStoreLocation "Cert:\CurrentUser\My" -KeyExportPolicy Exportable -KeySpec Signature -KeyLength 2048 -KeyAlgorithm RSA -HashAlgorithm SHA256 -NotAfter(Get-Date).AddYears(20)
$crt | select Thumbprint
先の手順で作成した証明書をアップロード
実際にPowerShellを使ってSharePoint Onlineにファイルをアップロードしてみる。
例)サイト名:テストサイトのドキュメントにあるテストフォルダにローカルのhoge.txtファイルをアップロード
$uploadFile = "C:\folder\hoge.txt"
$fileName = "hoge.txt"
try {
Connect-MgGraph -ClientId "先の手順で作成したアプリ登録のClient ID" -CertificateThumbprint "先の手順で取得したThumbprint" -NoWelcome
Write-Host "[Info] SPOに接続しました"
} catch {
Write-Host "[Error] SPOに接続できませんでした"
exit
}
$SiteID = Get-MgSite -Search "テストサイト" | Select-Object -ExpandProperty Id
$driveID = (Get-MgSiteDrive -SiteId $siteID | Where-Object {$_.Name -eq "ドキュメント"}).Id
$documentDriveItemID = (Get-MgDriveItemChild -DriveId $driveID -DriveItemId "root" | Where-Object {$_.Name -eq "ドキュメント"}).Id
$uploadFolderID = (Get-MgDriveItemChild -DriveId $driveID -DriveItemId $documentDriveItemID | Where-Object {$_.Name -eq "テストフォルダ"}).Id
$driveItemID = $uploadFolderID+":/"+$fileName+":"
try {
Set-MgDriveItemContent -DriveId $driveID -DriveItemId $driveItemID -InFile $uploadFile
} catch {
Write-Host "[Error] SPOにアップロードできませんでした"
}
Disconnect-MgGraph
Set-MgDriveItemContentのリファレンスマニュアルの説明が少なすぎて使い方がわからなかった…
DriveItemIdの引数、素直に考えるとそのままDriveItem IDを入力すればよいと思いきや、それだとダメ
実際のところは…
DriveItem ID+ “:/”+アップロードする際の任意のファイル名+”:”
こんなのわからないって…
10年近く使い続けてきたMicroserver Gen8。動いていたOSもWindows Server 2012R2とEOSLなのでこの機会にハードウェアごと一新しようと思い、Microserver Gen10 Plus v2を購入。
定番のHPEの箱。構成は最小モデル。どのみち中身を換装するので…
換装パーツはXeon E2336とメモリ64GB(32Gx2)。
ちょうどGen11が販売され始めた時期だけど、Gen10のチップセットはC252なのでこのパーツ構成。なお、Xeon E-2336なのはCPUの冷却がヒートシンクだけので、TDP65Wで収まるもので最上位という理由。
ストレージは写真を撮り忘れたので格納後。
SSDx2、HDDx2。SSDはMicroserver Gen10用専用マウントケージを使用。なくても適当な汎用ケージで問題ないことは確認済。HDDはそのまま取付。ただし、専用品ではないので差し込む際、コネクタの位置合わせにちょっと手こずる。また、取り外す際、青色のレバーを使えない。
起動ドライブはSSD USBメモリ。
これらのパーツを取付。
Gen8と同様に背面からボードを引き抜いて作業できるので作業性はよい。
なお、SSD USBメモリには汎用のヒートシンクを取付。
せっかくなのでCPUのベンチマーク。OSはWindows Server 2022。
まずは初期で乗っていたPentium Gold G6405のシングルコアをCINEBENCHで計測。
Pentium Gold G6405のマルチコア。
つづいてXeon E-2336のシングルコア。
Xeon E-2336のマルチコア。
さすがに比べ物にならない…
C262チップセットだと起動ドライブにNVMeを使えたりとより各パフォーマンスはさらに向上するけど、まぁ、通常利用だと特に不満はなし。
最後にMicroserver Gen8との対比。
Microserver Gen8の半分のサイズ!
ACアダプタ駆動だし”一般”のご家庭に設置できるレベルです。
タイトルがすべてだけど、2024年2月現在、Windows Server 2022の下記バージョンのWSL2はミラーモードもブリッジモードもDNSトンネリングもサポートしてません…
現状、細かいことをしたいなら素直にWindows 11ないし素のLinuxを使えという話ですね。
$ uname -r
5.15.133.1-microsoft-standard-WSL2
[wsl2]
networkingMode=mirrored
dnsTunneling=true
wsl: ミラー化されたネットワーク モードはサポートされていません。NAT ネットワークにフォールバックします
wsl: DNS トンネリングはサポートされていません
[wsl2]
networkingMode=bridged
vmSwitch=External
dhcp=true
wsl
ネットワークを構成できませんでした (networkingMode Bridged)。ネットワークを無効にするには、C:\Users\username\.wslconfigで 'wsl2.networkingMode=None' を設定します
Error code: Wsl/Service/CreateInstance/CreateVm/ConfigureNetworking/HCS/0x8037010d
ディスクのパフォーマンステストをして、いろいろとディスク交換していたら突如、Windowsが起動しなくなってしまった。
SATAコントローラのPort3,4のディスク交換だと問題なかったのに、Port1,2を変えた途端
これですよ(涙
いろいろと格闘してみるも、この時点では原因を完全につかみ切れなく、面倒になって、クリーンインストールすることに。
ところが、クリーンインストールをしようとしたところ…
Port5に挿したSSDしか認識していない。この状態で「Next」を押しても上記の通り、new partionを作成できない旨の警告が出て先に進めず。
ここからは推測だけど
以上のあたりをつけて、Windows 11でPoolとして作成したディスクをUSB接続し、いったんPoolを削除。
4本がんばって削除…
無事、インストール画面でディスクが見えた。と同時に各ディスクにMSR領域がちゃんと確保されていることを確認(なのに、なぜ起動できなかった???)
⇒ このMSR領域はPoolのためのものではないかと推測
すっきりさせた状態でインストール。
Windows Server 2022をインストール後にディスク管理を見てみると…
予想通り、ディスク0(Port1)の先頭にブートローダらしきものが書き込まれてる!
ということで、突然Windows 2022が起動しなくなったのは元々Port1に挿していたHDDを新しいHDDに入れ替えたことで、ブートローダが消えちゃった為ということがほぼ判明…
つまり、同時にMicroserver Gen8でPort5にSSDを挿してWindowsをインストールする場合はPort1にディスクを挿しておく必要があり(正確にはPort5だけだったらそれでもokですが、普通Port1~4を使わないという選択肢はないですよね…)、Port1のディスクを抜くとブートローダを見失うので、OSが起動しなくなるというわけか。
これって、MicoroServer Gen8の運用でよく見られるUSBメモリにブートローダを入れて、そこからシステムが入ったディスクを読みに行かせるテクニック以外にも、Port1の先頭にブートローダ領域を作ってやり、そこにブートローダを突っ込むことでLinux等も運用できるのではないかということでもあるよね…(検証はしませんが)
これで一件落着と思いきや、よく見たら
ディスク0、MBRで2TBしか認識してない(涙
MicroServer Gen8がBIOSにしか対応してないからWindows Server 2022がブートローダ領域を格納するディスク0をGPTではなくMBRで作成したのね…
ということはやはり、Windowsもディスクをフルに使うためにはUSBメモリを挿してそこにブートローダを突っ込むという選択しかなさそう…
まずは筐体内部のUSBポートにUSBメモリを挿入。
もったいないけどこちらを使用。
続いてbcdbootコマンドでブートローダをUSBメモリに書き込み。
bcdboot C:\Windows /s D: /f ALL
書き込まれたことを確認。ここから意図的にPort1のディスクを抜いてUSBメモリでWindowsが起動すれば完璧!(USB Memory KeyのBootを有効に)
無事、起動!!
長旅でした…
ファイルサーバ:Windows Server 2022 Standard
ベンチマーク実行PC:Windows 11
接続:双方共に10Gbps
SSDを追加購入。前回と同じSanDiskのSDSSDH3-2T00-G25。
今回から仮想ディスクを記憶域階層で作成。SSD2台のミラーとHDD2台のミラーを合わせて作成。
ミラー遅い… シンプルに比べたら当然遅いし、パリティに比べても結構遅い。パフォーマンスのSSDがあまり仕事してない?
ちょっとどうしたものかと悩んだあと、ReFSでもテストしてみることに。
ReFSが思ったよりも速い!! これなら十分。
続いて、ライトバックキャッシュを4GBに増やしてどうなるかテスト。
ライトバックキャッシュはGUIからだと1GB固定となり、任意の値を設定できないので、PowerShellから仮想ディスクを作る。
$SSD階層 = New-StorageTier -StoragePoolFriendlyName "Pool" -FriendlyName "SSD_Tier" -MediaType SSD
$HDD階層 = New-StorageTier -StoragePoolFriendlyName "Pool" -FriendlyName "HDD_Tier" -MediaType HDD
New-Volume -StoragePoolFriendlyName "Pool" -FriendlyName "Test" -AccessPath "E:" -ResiliencySettingName "Mirror" -ProvisioningType "Fixed" -StorageTiers $SSD階層,$HDD階層 -StorageTierSizes 190GB,290GB -FileSystem NTFS -WriteCacheSize 4GB
New-Volume -StoragePoolFriendlyName "Pool" -FriendlyName "Test" -AccessPath "E:" -ResiliencySettingName "Mirror" -ProvisioningType "Fixed"
ライトバックキャッシュ1GBと変わりなし…
ReFSでもライトバックキャッシュ増量による恩恵はなさそう。
最初のテストで気になったそもそもHDD遅すぎじゃない?という疑問に対する答えを出すためにHDDも追加で買ってみた。
Western DigitalのWD60EFAX-EC。Red Plusの6TBモデル。もうちょっと大きいサイズでもよかったけどそんなに容量いらないので。
Red Plus速い! NTFSでもなかなかの速度。
続いてReFS。こちらは、ランダム4kのQ32でちょっと良くなったくらいで目立った向上はなし。NTFSに比べると正直、HDDの性能向上による恩恵は少ない感じ。
というわけで、いろいろベンチマークを取った結果、初となるReFSで運用することに決定!
新規に構築したWindows Server 2022に現行ファイルサーバ(Windows Server 2012 R2)からrobocopyでデータ移行してみたもののどうにも遅い気が…
というわけで、一度ベンチマークを取ってみたところ…
Writeがめちゃくちゃ遅い(涙
というわけでチューニングの旅です。
物理ディスクはクローゼットの中でホコリをかぶっていたWestern DigitalのWD30EZRX 3TBディスク4本。
仮想ディスクの作成は下記のコマンドで実行。
New-VirtualDisk -StoragePoolFriendlyName "Pool" -FriendlyName "VirtualDisk1" -ResiliencySettingName Parity -Size 20TB -ProvisioningType Thin -NumberOfColumns 4
うーん、上図のとおりWriteが遅い… Thinで作ったから???
ということで固定で作ってみる。
New-VirtualDisk -StoragePoolFriendlyName "Pool" -FriendlyName "VirtualDisk1" -ResiliencySettingName Parity -Size 6TB
全体的に速くなったけど、やっぱりWriteが…
使ってるHDDがイマイチなんだろうか。
というわけで、記憶域階層を試して見ようと思って、SSDを1台だけ購入。1台しかないのでミラーではなくシンプル構成で。なお、追加したSSDはSanDiskのSSDH3-2T00-G25。
あと3.5インチ変換に裸族のインナー CRIN2535。こちら、アイネックスのHDD変換マウンタを最初に買ったら、MicroServer Gen8のHDDマウンタに取り付けた際、SATAの差し口が本体と合わなくて使えないという凡ミスをおかして買い直すはめに…
ともあれ結果の方は…
予想通り、速くなった!
チューニングというかもはや物理換装をやってるだけだけど、もう少し続く
遅ればせながらようやくWindows Server 2022 Standardを購入したのでMicorserver Gen8にインストールをしてみたところ、すんなりいかなかったので備忘録。
※ 小難しいことをちょっとやりましたが、結果的には何も考えなくインストール可能です
まず、Windows Server 2022もWindows 11同様、購入したDVDインストールメディアからだとUEFI環境必須の模様。
所謂レガシーBIOSしか搭載していないMicroserverでインストールしようとすると下記の通り0x80300024のエラーが表示され、先に進めず。
方法としてはMicroserver Gen8でUEFIを有効にするか、インストールメディアをレガシーBIOS対応のものに作り替えるかの2択かなと思い、前者をちょっと調べるも古い機種だし新しいSystem BIOSもリリースされていないようなので断念。
ということで、Windows Server 2022をRegacy BIOSでインストールする方法を検討。
といっても、まぁ、Windows 11のノウハウがそのまま使えるだろうと思い、RufusでWindows Serverのイメージをゴニョゴニョやってみた。
Rufusの設定は上記の通り。ポイントはイメージオプション、パーティション構成、ターゲットシステムの3点。
できあがったUSBメモリをMicroserver に挿して起動し…
POST画面でF11を選択し…
ブートドライブの選択画面で”3″のUSBドライブキーを選択してやると…
無事ロードに成功!
ここから[次へ(N)] をクリックすると
無事、インストールが進み…
OSの起動に成功!!
というわけで、レガシーBIOSでWindows Server 2022をインストールする手順そのものはクリア。
■ 後日談
購入したDVDディスクはレガシーBIOS版だった…
改めて実行すると…
すんなりインストール出来てしまった。
というわけで、どうやら公式サイトからダウンロードできる体験版はUEFIなのに対し、今回購入したFPP版はBIOSっぽい。