Windows 10 ver 1803 のクリーンインストール（WinRE 問題を回避しながら、シンプルなパーティション構成で）

以下の投稿や投稿の中にある @IT さんの記事で書いたように、Windows 10 バージョン 1803 (April 2018 Update）をインストールメディアからベアメタル PC にクリーンインストールした場合、Windows 10 に”すべてお任せ”しちゃうと、Windows 回復環境（WinRE）が C:\Recovery\WindowsRE にセットアップされてしまうという問題の、さらに補足。

Windows 10 の追加の OEM パーティションの謎（が解けたかも）（2018/08/09）

Windows 10 バージョン 1709 以前をクリーンインストールする場合も、機能更新後に追加の回復（OEM）パーティションが追加されるのを避けるには、以下の成功した手順でインストールするといいかも。

Windows Sysinternals 更新情報（2018 年 8 月 8 日）－ Autoruns v13.90 → v13.91

Autoruns v13.91 がリリースされていました。https://live.sysinternals.com/files によると 8 月 8 日に公開されたようです。Sysinternals のサイト（→ https://docs.microsoft.com/en-us/sysinternals/downloads/autoruns）や公式ブログ（→ https://blogs.technet.microsoft.com/b/sysinternals/）には情報なし（8/13 現在）。なので、何が変わったのか不明（たぶん v13.90 のバグ修正だと思いますが）。

前回の更新：
Windows Sysinternals 最新情報（Sysmon v8.0, Autoruns v13.90) (2018/07/06）

Windows 10 の追加の OEM パーティションの謎（が解けたかも）

@IT さんの以下の記事を書きました。Windows 10 バージョン 1803 になって、回復（OEM）パーティションが空になったり、余計に追加されたりすることがある件、謎が解けた気がする。というか、新規インストールのテストすらせずに、インストールメディアを公開しちゃっているのかしらん。

Windows 10の回復パーティションから消えた「WinRE」の行方
[URL] http://www.atmarkit.co.jp/ait/articles/1808/09/news027.html

この記事では、最新（2018年7月版）のWindows 10 ver 1803 の新規インストールで回復パーティションが空になる件について考察していますが、Windows 10 へのアップグレード（1709 以前でも）で OEM パーティションが追加される（UEFI ベースのシステムの場合は2つ目の）理由について補足。

（独り言）今月の予測可能な Windows Update パッチデーは 8/15

以下、独り言。

あすたらびすたエメットさん

＠IT さんに、2018年7月31日にサポートが終了した EMET の記事を書きました。

@IT > お疲れさま、そしてサヨウナラ、エメット（EMET）さん
 [URL] http://www.atmarkit.co.jp/ait/articles/1808/07/news009.html

記事を書いたときには、EMET のサイトと EMET 5.52 のダウンロード サイトは生きていましたが、本日（8/7）、英語の EMET サイトが消え、Microsoft Security Response Center に飛ばされるように。（8/8 追記、日本語サイトも消えました）

EMET 日本語サイトと ダウンロード サイトはまだ生きてます。EMET 5.52 のインストーラーが入用の方は、お急ぎを。そのうち消えるかも。→ https://aka.ms/emetdownload
（注：EMET は完全にサポートが終了した製品です）

インストール済みの Office 2013/2016 を識別できるかもしれないスクリプト（注：テストは不十分）

インストールされている Office 2013 および Office 2016 を検出しようと思って作ったスクリプト「OfficeMsiOrC2r.ps1」。

（こ、こいつ動くぞ→）

クイック実行（Click To Run、C2R）かWindowsインストーラー（MSI）か、32 ビット Office か 64 ビット Office かを識別しようとがんばったもの）。

ちゃんと動かないかもしれないので、あくまでも参考として。無保証。

インストール済みの .NET Framework バージョンを識別するスクリプト (v2)

（※8/2 追記：適当に書いたやつを ScriptCenterにアップしたので、その後、もろもろの修正版 Version 2.1 に差し替えました）

以下のドキュメントに説明されていることを、PowerShell スクリプト（get-dotnetver.ps1）にしてみた。.NET Framework 4.5 以降の出力結果の表現は、以下のドキュメントのママ。.NET Framework 1.0 はどうなっているのかよくわからないので省略。

How to: Determine which .NET Framework versions are installed
 [URL] https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed 

Get-DotNetVer.ps1 （8/2 Version 2.1）のダウンロードはこちらから。

TechNet Script Center > Determine which .NET Framework versions are installed by PowerShell (※08/02 に修正版 v2.0 に更新）


.NET Framework のサポートのライフサイクルについてはこちらで確認。
Lifecycle FAQ -- .NET Framework 
[URL] https://support.microsoft.com/en-us/help/17455/  

8/2 追記)
.NET Framework 4.5 以降がインストールされているときの .NET Framework 2-4 のバージョン 4 の出力は意味がないので、これを消すように修正版 v2.1 を ScriptCenter にアップしました。

注：.NET Framework 4.0 と .NET Framework 1.0/1.1 の PC でどうなるかテストしてません。いずれもサポート終了バージョンなので、知りません。