いつも弊社製品をご利用いただきまして誠にありがとうございます。Windows プラットフォーム サポートの濵谷です。

今回はよくお問い合わせいただくWindows 10 上の .NET Framework 3.5 有効化の方法についてご紹介いたします。

.NET Framework 3.5 について

.NET Framework 3.5 は、Windows 8.1 以降既定のインストールでは有効化されません。

また、OS を標準設定でインストールされた Windows には .NET Framework 3.5 を有効化するためのソースとなるファイルが存在しておりませんので、インターネット上もしくはインストール メディアから用意する必要がございます。

[オンライン環境での .NET Framework 3.5 有効化について]

Windows Update に直接繋がる環境であれば、コントロール パネル内の簡単な操作で有効にする事が出来ます。
Windows Update サイトへの接続を制限している環境については、以下 [オフラインでの .NET Framework 3.5 有効化について] をご参照ください。

[オフライン環境での .NET Framework 3.5 有効化について]

インターネットに接続出来ない、Windows Update サイトに接続出来ない等のオフライン環境でインストールする際には、Windows のインストール ディスクもしくはインストール ISO （インストール イメージ ファイル） をソース ファイル として用います。

ISO 内 \sources\sxs フォルダーにある .NET Framework 3.5 のソース ファイルを DISM コマンドによりインストール ソース ファイルとして指定します。
※ インストール ディスク、インストール ISO はセットアップ時に利用されたお客様の環境に適切なメディアをご使用ください。

インストール手順

.NET Framework 3.5 のインストール手順は 2 種類あります。

1 つ目はコントロール パネルより、Windows 10 にインストールする方法です。( Windows Update に直接接続できる環境で利用します。)

1. コントロール パネルより、.NET Frameworkを有効にする。
—————————-
1-1　コントロール パネルのプログラムを選択し、プログラムと機能の中の
「 Windows の機能の有効化または無効化」を選択します。

1-2　有効化する場合は、.NET framework 3.5 のチェック ボックスをオンにします。

2 つ目はコマンドによって、Windows 10 にインストールする方法です。（Windows Updateに直接接続できない環境などで利用します。）

2. Dism コマンドにより、.NET Framework 3.5 を有効化する。
—————————-
2-1 上述の［オフラインでの .NET Framework 3.5 のインストール ソースについて］の部分で紹介したインストール メディアを用意します。

2-2　インストール メディアをドライブ（例 D: ）にセットして、管理者としてコマンド プロンプトを実行します。

C:\Windows\system32>Dism /online /enable-feature /featurename:NetFX3 /all /Source:D:\sources\sxs\ /limitaccess

2-3コントロール パネルを開き、プログラムと機能の中の「 Windows の機能の有効化または無効化」を
選択し、.NET Framework 3.5 が有効化されているかを確認します。

参考情報

Windows 8、Windows 8.1、および Windows 10 への .NET Framework 3.5 のインストール
https://docs.microsoft.com/ja-jp/dotnet/framework/install/dotnet-35-windows-10

展開イメージのサービスと管理 ( DISM ) を使用して .NET Framework 3.5 を展開する
https://msdn.microsoft.com/ja-jp/library/windows/hardware/dn898529(v=vs.85).aspx

DISM とは
https://msdn.microsoft.com/ja-jp/library/windows/hardware/dn938351(v=vs.85).aspx

.NET Framework 3.5 を有効化する手順について ( Windows Server 2012 R2 )
https://blogs.technet.microsoft.com/askcorejp/2018/09/11/enable_net35/

Windows 10 上の .NET Framework 3.5 有効化の際の一助となりましたら幸いです。

なお、本ブログは予告なく変更される場合がございますのでご了承下さい。

いつも弊社製品をご利用いただき誠にありがとうございます。
Windows プラットフォーム サポートの濵谷です。
今回はよくお問い合わせいただく、更新プログラムの適用後の手動クリーンアップによって、コマンド プロンプト上でエラー メッセージ ｢ Error2 ( 指定されたファイルが見つかりません ) ｣ が表示される現象をご紹介します。またそれに付随して、クリーンアップを実行すると、20 % で完了となる現象に関しましてもご紹介します。

Windows Update のクリーンアップについて

Windows Update のクリーンアップを実行すると、過去にインストールされ、不要になった更新プログラムの情報が削除されます。
削除されるのは、システム側で差分の状態をチェックして、消去しても問題がないと判断した更新プログラムの情報のみが削除されます。
クリーンアップは、コマンド プロンプト上で、以下のコマンドを入力することで実行することができます。

> Dism /online /Cleanup-Image /StartComponentCleanup

クリーンアップを実行すると、エラー 2 が表示される

［現象］
Windows Server 2016 および Windows 10上で、更新プログラムを適用後にクリーンアップを実行すると、エラー メッセージ ｢ Error2 ( 指定されたファイルが見つかりません ) ｣ が表示されます。

［解決法］
本事象は、コマンド プロンプト上では ｢ Error2 ( 指定されたファイルが見つかりません ) ｣ と表示されますがクリーンアップ自体の動作そのものは正常に完了しております。

この失敗と表示される動作はクリーンアップの際に、不要となった更新プログラムを削除する処理で起きるのではなく、処理の一環として、C:\Windows\Logs\CBS 配下に「 CbsPersist_<日時>.log 」 がある時に、cab 形式に圧縮し、「 CbsPersist_<日時>.cab 」 とする際の内部動作に問題があるために起こります。

［回避策］
本事象は上記の通り、実際にクリーンアップの段階で何か問題が発生しているわけではありませんので、特に必要ございません。

［注意事項］
本事象は Windows 10 の バージョン 1607 まで起こりうる事象であり、 バージョン 1703 以降では修正されております。
また、大変申し訳ございませんが、バージョン 1703 以前は修正される予定はございません。

クリーンアップを実行すると、20 % で完了となる

［現象］
｢ Dism /online /Cleanup-Image /StartComponentCleanup｣コマンドを二度以上再実施すると、上記でご説明した「エラー 2 」にはなりませんが、別の既知の問題により ｢ 進捗が 20 % で完了｣ となる可能性がございます。
この現象は ｢ StartComponentCleanup ｣ で何も実施するものがない時、コマンド プロンプト上で進捗が 20 % まで進み、そのまま完了となります。
この現象も 20 % という表示上だけで、実際は完了しているため実害はありません。

［参考資料］

Windows Update のクリーンアップ について
https://blogs.technet.microsoft.com/askcorejp/2013/12/08/windows-update/

WinSxS フォルダーのクリーンアップ
https://msdn.microsoft.com/ja-jp/library/windows/hardware/dn898501(v=vs.85).aspx

Windows 10 および Windows Server 2016 上のクリーンアップ実行の際の一助となりましたら幸いです。

なお、本ブログは予告なく変更される場合がございますのでご了承下さい。

こんにちは。

日本マイクロソフト株式会社 高谷です。
今回は、次期 Windows Server に追加される Windows Subsystem for Linux (WSL) の機能について簡単なご紹介させていただきたいと思います。

■ Windows Subsystem for Linux (WSL) とは

.
Windows で Linux 向けのプログラムをそのまま実行できる機能です。
クライアント OS では Windows 10 (1709) 、サーバー OS では Windows Server 2019 (2018年秋リリース予定) で新機能として追加されています。

■ Windows Subsystem for Linux (WSL) でできること

.
その名の通り、Windows Server 上でLinux のシェル (Bash) を動作させることができますので、Windows Server 上で Linux のコマンドやツールを用いた開発、Windows ファイルの操作などを行うことができます。

Windows から Linux 環境のアプリケーションを呼び出すことも、逆に、Linux 環境から Windows のアプリケーションを呼び出すこともできます。

用途に応じたディストリビューションを Windows 上にインストールして利用する方式をとりますが、Ubuntu や SUSE など複数のディストリビューションを同時にインストールし、並行して起動させることも可能です。

現在は CUI (Bash) のみ提供しており、GUI は提供していません。

参考) ディストリビューションとは？
Linux の OS の種類のこと。同じ Linux でも複数の種類があり実装が異なる。
RedHat や CentOS、Ubuntu、SUSE など。

■ 導入の方法について

.
Windows Server への導入方法については以下の公開情報がありますので、こちらをもとにご説明をします。

公開情報)
“Windows Server Installation Guide” (英語のみ)
https://docs.microsoft.com/ja-jp/windows/wsl/install-on-server

(1) まずは機能をインストールする必要があります。

1. 管理者権限で Windows PowerShell を起動します。
2. 以下のコマンドを実行します。

……….> Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

3. サーバーを再起動します。

(2) 必要なディストリビューションをダウンロードします。

Microsoft ストアからダウンロードできるものも多数あります。必要に応じてダウンロードください。
※ 以下の弊社サイトからもダウンロード可能です。
本ブログでは、弊社サイトからダウンロードした Ubuntu を例に説明します。

“Manually download WSL distro packages”
https://docs.microsoft.com/ja-jp/windows/wsl/install-manual

(3) ディストリビューションのインストールを行います。

1. ダウンロードしたディストリビューションを解凍します。Windows PowerShell を利用の場合は、以下のコマンドを参考に実行ください。解凍場所は、システム ドライブ(C ドライブ) 内に実施ください。例) C:\Distros\Ubuntu 配下

……….>Rename-Item ~/Ubuntu.appx ~/Ubuntu.zip
....……>Expand-Archive ~/Ubuntu.zip ~/Ubuntu

※ Microsoft ストアからダウンロードした場合は、解凍のステップがなく自動的にインストールされます。

2. 解凍したディストリビューションのインストールを行います。

※ ubuntu の場合、ubuntu.exe ファイルを実行してインストールを行います。

(4) 初期設定を行います。初期設定が完了して、インストールも完了となります。

1. [スタート] メニューから [ubuntu] を起動します。環境によっては数分かかります。
2. ユーザー名とパスワードを登録します。
3. 必要に応じて以下のコマンドでディストリビューションをアップデートください。

……….> sudo apt update && sudo apt upgrade

※ Windows によって勝手にアップデートされることはございません。

ユーザー様にてアップデートを実施ください。
初期設定の手順についても公開情報がございますので、詳細はこちらを参照ください。

“Initializing a newly installed distro” (英語のみ)
https://docs.microsoft.com/en-us/windows/wsl/initialize-distro

■ Windows Subsystem for Linux (WSL) の管理

.
WSLの管理にはwslconfig.exe コマンドが用意されています。コマンド プロンプトを起動し、オプションなしで wslconfig を実行すると、コマンドのヘルプが表示されます。

wslconfig /l でインストールされているLinuxディストリビューションの一覧を表示されます。ディストリビューションの右側に “(既定)” と付いているものは、wslやbashと実行するだけで起動ができる既定のディストリビューションです。

以下の図では、Ubuntu と SUSE Linux Enterprise Server (SLES) の2 つのディストリビューションがインストールされており、既定は Ubuntu となっていることが確認できます。

wslconfig /s <Linuxディストリビューション名> で、既定のディストリビューションを変更可能です。

Linuxディストリビューションを起動するには、wslconfig /l で確認できるLinuxディストリビューション名を入力するか、wsl や bash コマンドを入力します。

wsl もしくは bash と入力した場合は、既定に設定されたディストリビューションが起動します。

また、ディストリビューションを起動しなくても、wsl <Linuxコマンド> もしくは bash <Linuxコマンド> で、Windows のコマンド プロンプト上に Linux コマンドの出力結果を表示可能です。

ディストリビューションのアンインストールは wslconfig /u <Linuxディストリビューション名> コマンドで可能です。アンインストールすると wslconfig /l で一覧に表示されなくなります。

■ その他の関連公開情報

.
– 参考情報
“Windows Subsystem for Linux Overview (英語のみ)”
https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-overview/

こちらのサイトでは、Windows Subsystem for Linux のシステム アーキテクチャの説明があります。

– 参考情報
“Windows Subsystem for Linux Documentation (英語のみ)”
https://docs.microsoft.com/en-us/windows/wsl/about

弊社公開情報がまとめられております。

いかがでしたでしょうか。
本ブログが少しでも皆様のお役に立てますと幸いです。

こんにちは。Windows サポート チームの沖です。

今回は、Windows 10 Version 1703 (RS2) 以前のバージョンから、Windows 10 Version 1709 (RS3) もしくは Windows 10 Version 1803 (RS4) へ機能アップデートをすることにより、UWPアプリで以下の事象が発生する場合があるという報告をいくつか受けておりますため、本ブログでは事象が発生した場合にお試し頂きたい手順をご紹介させて頂きます。

– タイルにピン留めできない。
– タイルのレイアウトがインポートできない。
– タスクバーにピン留めできない。
– タイルの右クリックで表示されるメニューに[スタートからピン留めを外す]のメニューがない、などメニューが不正。
– [設定]が起動できない。
※ 歯車アイコンから起動できない、右クリックから[設定]から起動できない、両方から起動できない。
– アイコンの表示が不正/タイルの表示が黒くなるなど不正。
– スタートメニューにアイコンが表示されない。
– ストアアプリをクリックしても起動しない。
– ストアアプリをクリックして起動しても直ぐに強制終了する。

尚、Windows 10 1809 (RS5) には既に本修正が含まれているため、1809 (RS5) 以降への機能アップデートでは発生しませんためご安心ください。

原因

Windows 10 Version 1703 以前と Windows 10 Version 1709 以降では、UWP アプリと [スタート] メニューが使用する内部的な情報の保持の方法に大きな差がございます。
Windows 10 Version 1703 以前では、 [スタート] パネル上のタイルの情報やアプリケーションの一覧情報は “Tile Data Layer” と呼ばれるユーザーごとのローカル キャッシュに独立して存在しておりましたが、Windows 10 Version 1709 以降では“Central State Repository” と呼ばれる全てのアプリ、パッケージ、タイル情報を集約して管理するデータベースを使用するよう変更が行われました。

そのため、Version 1703 以前の Windows 10 を Version 1709 または 1803 へ機能アップデートいただく際には、アップデートのプロセス内で “Tile Data Layer” 上の情報を“Central State Repository” に移行する処理が行われます。
この移行は、機能アップデートが完了しユーザーが初回サインインを行った際に行われますが、同時に、ユーザーとUWPアプリの関連付けも発生します。この二つの処理が偶発的に重なった結果 “Central State Repository” 上に重複したデータが登録されることがございます。
これにより、タイル情報やスタート メニューのアプリケーションの一覧とユーザーの一意な関係性が破壊され、データベースの制約に違反する状態となるため“Central State Repository” を完了することができなくなり、本事象に至る場合があることを確認しております。

発生する条件

これまでに寄せられているお問い合わせより、Windows 10 のマスタ イメージを作成する際に CopyProfile オプションを使用していると、比較的発生しやすい傾向がございます。
しかしながら、誠に恐れ入りますが、現時点で本事象が発生する明確な条件については弊社でも確認が出来ておりません。

本事象に合致していることの確認方法

本事象に合致している場合には、例えば、イベント ログへ以下のようなエラー コード 0x87AF0813 (SQLITE_E_CONSTRAINT_UNIQUE) を含むイベントが記録されます。

イベント例 1:
===============
ログの名前:         Microsoft-Windows-AppXDeploymentServer/Operational
ソース:           Microsoft-Windows-AppXDeployment-Server
イベント ID:       401
タスクのカテゴリ:      (3)
レベル:           エラー
キーワード:         AppXDeploymentServer Keyword
説明:
エラー 0x87AF0813 が発生したため、 (AppxBundleManifest.xml)  からのパッケージ Microsoft.WindowsCalculator_2018.402.631.0_neutral_~_8wekyb3d8bbwe に対する展開 Register 操作 (ターゲット ボリューム C:) に失敗しました。アプリの展開に関する問題の診断については、http://go.microsoft.com/fwlink/?LinkId=235160 を参照してください。

イベント例 2:
===============
ログの名前:         Microsoft-Windows-StateRepository/Operational
ソース:           Microsoft-Windows-StateRepository
イベント ID:       100
タスクのカテゴリ:      (1)
レベル:           エラー
キーワード:         StateRepository Keyword
説明:
エラー 0x87AF0813: [sqlite3_step] #5 Database 2899A309DC0: Statement 2899C3DC940 OK: Try 1 (0ms) UNIQUE constraint failed: PrimaryTileUser.TileUniqueId, PrimaryTileUser._WorkId : SQL INSERT INTO PrimaryTileUser (_Revision, _WorkId, _Created, _Modified, PrimaryTile, User, State, TileUniqueId, _Dictionary) VALUES(?,?,?,?,?,?,?,?,?);

イベント例 3:
===============
ログの名前:         Microsoft-Windows-AppReadiness/Admin
ソース:           Microsoft-Windows-AppReadiness
イベント ID:       12
タスクのカテゴリ:      (6)
レベル:           エラー
キーワード:         (128)
説明:
ユーザー ‘testuser01’ に対する Appx プレビュー タイルの生成に失敗しました: 。(結果: SQLITE_CONSTRAINT_UNIQUE)

イベント例 4:
===============
ログの名前:         Microsoft-Windows-AppReadiness/Operational
ソース:           Microsoft-Windows-AppReadiness
イベント ID:       11
タスクのカテゴリ:      (6)
レベル:           警告
キーワード:         (128)
説明:
例外が検出されました: SQLITE_CONSTRAINT_UNIQUE。

事象が発生した場合の対処

本事象が発生致しましたら、以下 2 つの操作をお試し頂きますようお願いいたします。

  (1) 機能アップデート後のバージョンごとの以下以降の更新プログラムをご適用ください。
以下更新プログラムを適用後にログオンするユーザーについては、本ブログの冒頭でご紹介した事象が修正されておりますため適用により問題が発生しなくなるかご確認頂きますようお願いいたします。

※※※ 注意点 ※※※
      機能アップデート後、以下の更新プログラムを適用する前にログオンを行ったユーザーについては、更新プログラムを適用しても事象が改善されない場合がございます。その場合には “更新プログラム適用後の操作” の手順を実施頂きますようお願いいたします。

▼ Windows 10 1709 の場合

September 26, 2018—KB4457136 (OS Build 16299.699)
https://support.microsoft.com/en-us/help/4457136

▼ Windows 10 1803 の場合

September 26, 2018—KB4458469 (OS Build 17134.320)
https://support.microsoft.com/en-us/help/4458469

  (2) 更新プログラム適用後の操作

更新プログラムの適用を行っても引き続き、事象が発生しているユーザーにつきましては以下をお試し頂きますようお願いいたします。
アプリの再登録による復旧手順は事象の発生状況より下記の記載の通り複数ございます。
まずは方法 1　より順に実行いただいて都度アプリが起動できた場合には以降の手順実施は不要です。

————————————————————
*方法1：UWP アプリの再インストール

// 特定の UWP アプリに対して実行する場合

1.PowerShellを起動(ユーザ権限)
2.以下のコマンドを実行
$repairePacakages = @(“Microsoft.WindowsCalculator”, “Microsoft.MicrosoftStickyNotes”) $repairePacakages | ForEach-Object {
$PhotosManifestPath = (Get-AppxPackage -Name $_).InstallLocation + “\Appxmanifest.xml”
Add-AppxPackage -Path $PhotosManifestPath -Register -DisableDevelopmentMode }
※ Microsoft.WindowsCalculator や Microsoft.MicrosoftStickyNotesは、Get-AppxPackage | ForEach-Object {$_.Name}で表示される名称を指定します。
// すべての UWP アプリに対して実行する方法

既に貴社でもお試し頂いております以下コマンドを実行することで再インストールを行うことが可能です。

Get-AppXPackage | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register “$($_.InstallLocation)\AppXManifest.xml”}

————————————————————

*方法2：UWP アプリのパッケージから再インストール
(上書きインストール相当。アプリケーションによっては保存されているデータが上書きにより削除される可能性がございます。)

// 特定の UWP アプリに対して実行する場合
1.PowerShellを起動(ユーザ権限)
2.以下のコマンドを実行
$repairePacakages = @(“Microsoft.WindowsCalculator”, “Microsoft.MicrosoftStickyNotes”) $repairePacakages | ForEach-Object {
Add-AppxPackage -MainPackage (Get-AppxPackage -Name $_).PackageFullName }
※ Microsoft.WindowsCalculator や Microsoft.MicrosoftStickyNotesは、Get-AppxPackage | ForEach-Object {$_.Name}で表示される名称を指定します。

// すべての UWP アプリに対して実行する方法

1.PowerShellを起動(ユーザ権限)
2.以下のコマンドを実行
Get-AppXPackage |  Foreach {Add-AppxPackage -MainPackage $_.PackageFullName}

————————————————————
*方法3：アプリケーションの起動に伴う登録

例として電卓及び、StickyNotes に関する手順となります。
以下実行すると電卓と StickyNotes が起動されます。
そのため、本手順を実施頂く場合には UWP アプリをご指定頂くようお願いいたします。

1.PowerShellを起動(ユーザ権限)
2.以下のコマンドを実行
$repairePacakages = @(“Microsoft.WindowsCalculator”, “Microsoft.MicrosoftStickyNotes”) $repairePacakages | ForEach-Object {
$repaireFamilyName = (Get-AppxPackage -Name $_).PackageFamilyName
$repaireApplication = (Get-AppxPackage -Name $_ | Get-AppxPackageManifest).Package.Applications.Application.Id
Start-Process Shell:AppsFolder\”$repaireFamilyName”!”$repaireApplication”
}

————————————————————

*方法４：UWP アプリをインストール済みパッケージから削除してから再インストール

以下手順では、インストール済みの UWP アプリを削除後、プロビジョニング パッケージより
再度インストールを行う方法となります。

  ※本手順では UWP アプリを削除して、再インストールを行います。
  ※インストールを行った後に、次回の UWP アプリのアップデートが行われるまではスタート メニュー上で英語表記となる可能性がございますため、予めご了承ください。

// 特定の UWP アプリに対して実行する場合

1.PowerShellを起動(管理者権限)
2.以下のコマンドを実行
$repairePacakages = @(“Microsoft.WindowsCalculator”, “Microsoft.MicrosoftStickyNotes”) $repairePacakages | ForEach-Object {
Get-AppxPackage -Name $_ | Remove-AppxPackage
$reinstallPackage = $_
Get-AppxProvisionedPackage -Online | Where-Object {if ($_.DisplayName -like $reinstallPackage){$repairePackageName=$_.PackageName}}
Add-AppxPackage -MainPackage $repairePackageName } ※ 英語版になりますが、次回のアップデート時に、日本語リソースがインストールされます。

// インストールされているすべての UWP アプリに対して実行する方法

以下は、インストールされている UWP アプリをすべて削除してから、プロビジョニング
パッケージより再度インストールする方法となります。
そのため、プロビジョニング パッケージに含まれていないパッケージ (ユーザーが個別に
インストールした UWP アプリなど。)は再インストールされません。

$repairePacakages = get-appxpackage
$repairePacakages | ForEach-Object {
Get-AppxPackage -Name $_ | Remove-AppxPackage
$reinstallPackage = $_.Name
Get-AppxProvisionedPackage -Online | Where-Object {if ($_.DisplayName -like $reinstallPackage){$repairePackageName=$_.PackageName}}
Add-AppxPackage -MainPackage $repairePackageName }

————————————————————

その他の対処方法

上記更新プログラム (KB4457136/KB4458469) を機能アップデートを行うインストール イメージに統合 (あらかじめ含まれた状態) することで当初より本事象が発生しないよう、未然に防げる可能性がございます。
そのため、アップデートを実施されます際は上記の更新プログラムを統合頂いたインストール イメージでの機能アップデートをご検討頂けますと幸いでございます。

以上の通りお伝えいたします。
弊社製品の問題によりご迷惑をお掛け致しますことを重ねてお詫び申し上げます。

こんにちは、日本マイクロソフト Windows サポート チームです。

マイクロソフトでは、Windows Server の標準のバックアップ ソフトウェアとして、
Windows Server バックアップの機能が提供されており、様々なお客様にご使用
いただいております。

今回は、この Windows Server バックアップで取得対象のボリュームに PageFile.sys が
配置されていた場合のリストア時の注意点 (発生し得るエラー) や動作についてご説明したい
と思います。

なお、今回は特定のシナリオに沿った内容となりますが、Windows Server バックアップについては、
さまざまな公開情報がリリースされていますので、基本的な動作や付随する機能などについては、
その他の情報も、ぜひご確認ください。

-公開情報
Windows Server バックアップにおける容量と世代管理について
https://blogs.technet.microsoft.com/askcorejp/2016/05/27/windows_server_backup_space_management/

ボリューム シャドウ コピー サービス (VSS) について
https://blogs.technet.microsoft.com/askcorejp/2018/08/15/aboutvss/

================================
■ 今回のエラー発生の流れ・手順
================================
上述しました通り、今回はバックアップ対象のデータ ボリュームに PageFile.sys が配置されて
いる事に起因して、発生する可能性があるエラーを中心にご説明したいと思います。

発生条件は至ってシンプルで、どの環境でも発生する可能性がありますが、弊社では以下の
ような構成で事象を再現させてみました。以下の手順に沿って、PageFile.sys が配置されている
ボリュームのバックアップ データを復元すると、事象としては 100 % 発生します。

[構成]
——
//Windows Server 2012 R2
//バックアップ対象 : D:\ (ボリューム単位)
//バックアップ格納先 : E:\
//ページファイル配置場所 : C:\pagefile.sys と D:\pagefile.sys

[再現手順]
———–
1) [サーバー マネージャー] – [Windows Server バックアップ] – [ローカル バックアップ]
– [単発バックアップ] の順にバックアップ ウィザードを進めて、まずはリストアに使用する
バックアップ データを作成します。(バックアップ対象は PageFile.sys が配置された
ボリュームを選択します)

2) [別のオプション] – [カスタム] – [項目の追加] から [ボリューム (D:)] に
チェックボックスを入れて、[OK] ボタンを押下します。

3) [次へ] を押下してバックアップ格納先を [ローカル ドライブ] – [ボリューム (E:)]
と設定して、バックアップ処理を開始します。

4) バックアップ処理の完了後、[Windows Server バックアップ] の右ペインの [回復] から、
回復ウィザードを開始します。

5) [このサーバー] を選択して [バックアップの日付の選択] から、リストア対象の
日付および時間帯をカレンダー情報から選択します。

6) 復元方法として [ボリューム] を選択して、復元対象のチェックを入れて
[回復先ボリューム] も [ボリューム (D:)] を選択します。

7）回復先ボリュームの現在のデータが失われる旨のポップ アップ表示されますので、
[はい (Y)] を押下して、操作を進めて [回復 (R)] ボタンから処理を実行します。

※ すると、今回のエラー シナリオとなる以下の “アクセス拒否” を示すエラーが
Windows Server バックアップ GUI 上で出力されて、復元処理が失敗します。

なお、上記の各エラーは上記ステップの 6) で “ファイルおよびフォルダー” の
復元方法を選択した場合には出力されず、正常に処理が完了します。

============================
■ 今回のエラー発生のシナリオ
============================
このエラー発生時の処理および操作時の動作状況を、ログを採取して確認してみると、
以下のように各リストア処理が実行されており、復元方法の選択によって若干の
違いが確認できました。そして、この違いによりエラーの出力可否が判断されて
いました。

<ボリューム単位のリストア時>
—————————–
ボリューム単位の復元では、復元対象のボリュームをディスマウントした上で
リストア操作が実施されていました。しかし、そもそも Windows OS では PageFile.sys が
配置されているボリュームはディスマウント処理が実施できません。(“アクセス拒否” で失敗します)

このため、上述の “アクセス拒否” エラーが発生していました。

<ファイルおよびフォルダー単位のリストア時>
—————————————–
一方、ファイルおよびフォルダー単位のリストア操作では、ボリュームのディスマウント
処理は実行されません。そのため、ボリューム単位でリストアした際に確認できた “アクセス拒否” の
エラーが出力されない動作となっていました。

なお、Windows Server バックアップを使用したバックアップおよび、リストア処理では
Pagefile.sys などをバックアップおよびリストア対象外から除く既定動作が組み込まれておりますので、
(“FilesNotToBackup [以下公開情報]” をご存知の方もいるかもしれません)、いずれのバックアップ操作
およびリストアにおいても PageFile.sys がリストアされる事はありません。

Registry Keys and Values for Backup and Restore
https://docs.microsoft.com/en-us/windows/desktop/backup/registry-keys-for-backup-and-restore
(抜粋 : The FilesNotToBackup registry key specifies the names of the files and directories that
backup applications should not backup or restore.)

ただし、ボリューム単位でリストアした場合には、ボリュームをディスマウントした上で復元を行いますので、
上記エラーの影響を受ける形となります。

[参考情報]
ボリューム単位のリストアでは、復元後に除外対象 (“FilesNotToBackup” 対象) のファイルを復元先
ボリュームから削除する事で “FilesNotToBackup” を実現しており、ファイルおよびフォルダー単位で
リストアした場合には、そもそも除外対象をバックアップ時点で対象に含まない事により、”FilesNotToBackup”
設定を実現しています。

今回の直接的なエラー発生要因は、ボリューム単位でのリストア時の動作に、対象ボリュームの
ディスマウントが実装されている事となりますが、”FilesNotToBackup” の挙動についても併せて
確認が出来ましたので、ご参考までにご紹介いたします。

========================================
■ 有効なリストア手法 (回避策) について
========================================
上述しました通り、回復対象ボリュームに PageFile.sys が存在している場合には、ディスマウント処理にて
失敗する状況が確認できていますので、一旦対象ボリュームから PageFile.sys を削除した後、回復操作を
ご実施いただく事で今回のエラーを回避する事が可能です。(※ 回復完了後には、改めて PageFile.sys を
ご設定ください)

以下に手順をおまとめいたしますので、同様な事象に遭遇した際には、ぜひご確認・ご対応いただければ
と思います。

手順:
——
1) [マイコンピュータ] のプロパティから、[システムの詳細設定] – [詳細設定] タブ –
[パフォーマンス] 内の [設定] を開き、さらに [詳細設定] タブを選択します。

2) [仮想メモリ] 欄の [変更] を押下して、復元対象ボリュームを選択の上、
[ページング ファイルなし] にチェックを入れて、すぐ右の [設定] を押下します。

3) [OK] を連続して押下して、再起動を促すポップアップ通りに、システムを
再起動します。

4) OS 起動後に、対象ボリュームに PageFile.sys が無い事を確認し、Windows Server バックアップ
GUI から、ボリューム単位で回復操作を実施します。

5) 回復完了後には、改めて上記 1) から 3）の順に展開して、対象ボリュームに
ページング ファイルを設定ください。([カスタム サイズ] から [初期サイズ] と
[最大サイズ] を入力して、すぐ右の [設定] を押下します。設定の反映には
再起動が必要となりますので、ポップアップなどに従いシステムを再起動ください)

※ なお、リストア時に “ファイルおよびフォルダー単位” で復元いただく事で
今回のエラー自体は発生する事なく、対象ボリュームをリストアする事が可能です。

ただし、もし対象ボリューム上のデータを何らかのアプリケーションが使用していた場合や、
これらデータが PageFile.sys 上に配置されている場合には、リストア操作 (ファイルの
変更が突如行われる事) によって、予期しないエラーが発生する可能性も考えられますので、
ここでは一度 PageFile.sys を削除する手順を含めて、ご案内しています。

以上が、PageFile.sys が配置されたバックアップおよびリストアに関するエラー発生時の
状況と対処策のまとめとなります。本ブログが少しでも皆様のお役に立ちますと幸いです。

-その他、参考情報 (ブログ情報) のご紹介
Windows Server バックアップでのリストアディスクの選択について
https://blogs.technet.microsoft.com/askcorejp/2018/04/03/backuprestoredisk/

リストア時に エラー : 0x80042412 (VSS_E_ASRERROR_RDISK_FOR_SYSTEM_DISK_NOT_FOUND) が発生する事象について
https://blogs.technet.microsoft.com/askcorejp/2018/08/06/%E3%83%AA%E3%82%B9%E3%83%88%E3%82%A2%E6%99%82%E3%81%AB-%E3%82%A8%E3%83%A9%E3%83%BC-0x80042412-vss_e_asrerror_rdisk_for_system_disk_not_found-%E3%81%8C%E7%99%BA%E7%94%9F%E3%81%99%E3%82%8B%E4%BA%8B/

Windows Server バックアップにおける容量と世代管理について
https://blogs.technet.microsoft.com/askcorejp/2016/05/27/windows_server_backup_space_management/

ボリューム シャドウ コピー サービス (VSS) について
https://blogs.technet.microsoft.com/askcorejp/2018/08/15/aboutvss/

こんにちは、Windows プラットフォームサポート 宮崎です。

本日は更新プログラムのインストール時にエラー 0x8000FFFF が発生してインストールが失敗する事象について紹介いたします。

1. 現象

Windows 7, Windows Server 2008 R2 で更新プログラムの適用を行う際に 0x8000FFFF のエラーが記録されインストールに失敗することがあります。

2. 原因

最新のサービス スタックの更新プログラム KB3177467 がインストールされていないためです。

3. 対処策

KB3177467 をインストールします。

4. 補足

4-1. 0x8000FFFF のエラーの対処方法について

本事象は適用する更新プログラムに関わらず発生する可能性がありますが既知の問題として 2018 年 9 月 11 日の更新プログラムの公開情報にて記載しました。

この事象は発生する場合と発生しない場合があります。この事象が発生せずに適用が完了したデバイスは対処は必要ありません。エラーが発生しても更新プログラムが適用できない動作以外の影響はありません。

KB3177467 は “排他的なインストールが必要” である更新プログラムとして提供しています。スタンドアロンインストーラー以外のインストール方法 (Windows Update, WSUS, SCCM) からインストールする場合において、他の更新プログラムが適用対象として検出される場合、KB3177467 がインストール対象として表示されずに他の更新プログラムを先に検出・適用します。そのため、以下のどちらかを対処策として実施してください。

• エラーが発生したデバイスは KB3177467 のスタンドアロンインストーラーを入手し、適用してください。
• WSUS や SCCM を使っている環境でエラーを防ぐためにはあらかじめ KB3177467 のみを配信し KB3177467 のインストールが完了した段階で、他の更新プログラムを配信してください。

4-2. KB3177467 をスタンドアロン インストーラーでインストールする時の注意点

スタンドアロンインストーラーを用いて KB3177467 をインストールする際に他の更新プログラムと同時にインストールを行いますと、再起動後に”Windows を構成するための準備中” から画面が進まない動作が発生します。この問題を回避するためには、以下の作業のどちらかを行います。

• KB3177467 を先にインストールします。
• 画面が進まない状態はインストールは完了していますが、画面の遷移に至らない問題です。KB3177467 の技術情報に記載の通り、Ctrl+Alt+Delete キーを押下し、ログオン画面に進みます。

4-3. KB3177467 のリリースについて

9 月 12 日以降に公開された以下の更新プログラムには “この更新プログラムをインストールする前に” の項目で KB3177467 をインストールすることを紹介しています。KB3177467 は以下の更新プログラムを提供するための前提条件ではありません。しかし、マシンによっては 0x8000FFFF のエラーが発生する可能性がありますので、事前に KB3177467 をインストールすることを推奨します。

KB3177467 は分類を “重要な更新” から “セキュリティ問題の修正プログラム” として再リリースしました。これは分類の変更までであり、すでに KB3177467 を適用している場合、新たな作業は不要となります。

Windows Update で定期的に更新しているデバイスや、WSUS で KB3177467 を含めて配信している環境ではすでに適用される更新プログラムとはなります。上記に該当しない環境では、KB3177467 を各マシンに適用することをお勧めします。

本記事におきましては予告なく内容を変更させていただくことがあります。
今後、情報のアップデートがあれば、本ブログにて引き続き情報を提供いたします。

こんにちは。

Windows プラットフォーム サポート担当の佐々木です。
今回は、UEFI Boot 環境のWindows 10 において、OS 用のハードディスクの RAID 1を構成する手順についてご説明させていただきたいと思います。

BIOS に代わるファームウェア (UEFI) に対応したWindows Server 2008 以降のバージョンでは、2 TB 以上の容量をサポートできる GPT ディスクから OS の起動が可能になります。
本ブログでは、ディスクの耐障害性を高めるため、 UEFI Boot 環境でダイナミックディスクの RAID 1を構成する手順について説明いたします。
 

■　RAID 1 (ミラーリング)とは？

RAID 1とは、ディスクの破損に備え、同じデータを２本のディスクに書き込む方式のことです。「ミラーリング」と呼ばれることもあります。
同じ内容のディスクを２本用意しておくことにより、１本のディスクが破損した場合でももう１本のディスクから OS を起動することができます。
つまり RAID 1を組むことにより、ディスクの耐障害性を高めることにつながります。
 

■　 HDD の種類

HDD の扱いには、ベーシック ディスクとダイナミック ディスクがあります。

〇ベーシックディスク
パーティションを4つまで作成でき、プライマリ パーティション(3 つまで)と拡張パーティション(1 つのみ)によって構成されています。
ベーシック ディスクでは、ソフトウェア RAID を構成することができません。

〇ダイナミック ディスク
シンプルボリューム、スパンボリューム、ストライプボリューム、ミラーボリュームの４種類のボリュームを作成できます。
ダイナミック ディスクでは、ソフトウェア RAID を構成することができます。

※ベーシック ディスクからダイナミック ディスクに変換した場合は、データを残したままの状態でベーシック ディスクに戻すことはできません。
 

■　事前準備

既存のディスク( Windows 10がインストールされたもの)に加えて、新規のディスクを1本追加接続してください。
既存ディスクをディスク 0、追加したディスクをディスク 1としてご説明をいたします。
今回は、ディスク 0のデータをディスク 1にミラーし、新規で作成するディスク 1のみで OS が起動できるよう設定を行います。

※お使いの PC のディスク構造は、『ディスクの管理』画面にて確認できます。

※RAID 1を構成する前のディスク構造

※RAID 1を構成した後のディスク構造

■　対象 OS

• Windows 10

UEFI Boot 環境でダイナミック ディスクの RAID 1 を構成する手順は、おおまかに以下の5ステップで構成されます。

1. 新規ディスクを GPT フォーマットに変換
2. 回復パーティションを作成
3. EFI システム パーティションを作成
4. ディスクをダイナミック ディスクに変換し、ミラーを構成
5. BCD (ブート構成データ)の修正

それぞれの具体的な手順については、次回以降のブログでご説明させていただきます。

〇ステップ 1 からステップ 4 まで
UEFI Boot 環境でダイナミック ディスクの RAID 1 (ミラーリング)を組む方法 2 / 3
〇ステップ 5
UEFI Boot 環境でダイナミック ディスクの RAID 1 (ミラーリング)を組む方法 3 / 3

いかがでしたでしょうか。
本ブログが少しでも皆様のお役に立てれば幸いです。

こんにちは。

Windows プラットフォーム サポート担当の佐々木です。
今回は、UEFI Boot 環境のWindows 10 において、OS 用のハードディスクの RAID 1を構成する具体的な手順についてご説明させていただきたいと思います。
本ブログでは、ディスクをダイナミック ディスクに変換し、システム ボリュームをコピーするところまでの手順をご説明をさせていただきます。

前回のブログ
UEFI Boot 環境でダイナミック ディスクの RAID 1 (ミラーリング)を組む方法 1 / 3

■　作業手順

1. まずは新規ディスク(ディスク 1)を GPT フォーマットに変換します。

1-1. 管理者コマンドプロンプトを起動します。
1-2. Diskpart.exe を実行し、 Diskpart ユーティリティーを起動します。
1-3. 以下のコマンドを順番に実行します。

Select disk 0
Select partition 1
※ディスク 0の回復パーティションを選択しています。

Detail partition
※ディスク0の回復パーティションの GUID を記憶しておきます。（種類の項目）

Select disk 1
Convert mbr
Convert gpt
※ここまででディスク 1の GPT フォーマットへの変換が完了しました。

2. 続いて回復用パーティションを作成します。

2-1. 以下のコマンドを順番に実行します。

Select partition 1
Create partition primary size=300
Format fs=ntfs quick label=recovery
※ディスク1上に新たな回復用のパーティション/ボリュームを作成しております。

Select partition 1
Select me 4
※ たった今作成したパーティション上の回復ボリュームを選択しています。

Set id=identifier
※ identifier には 1-3. で確認したディスク 0 の回復パーティションの GUID を入力します。

※『ディスクの管理画面』にてディスク 1に回復パーティションが作成されていることが確認できます。

3. ボリュームの内容をコピーするため、ボリュームにドライブ文字を割り当てます。

3-1. 以下のコマンドを順番に実行します。

Select disk 0
Select partition 1
Assign letter=q
※ディスク 0 上の回復パーティション上のボリュームに、レター Q を割り当てています。
Select disk 1
Select partition 1
Select me 4
Assign letter=r
※ディスク 1 上の回復パーティション上のボリュームに、レター R を割り当てています。

4. OS 起動のための EFI システムパーティションを作成し、内容をコピーします。

4-1. EFI システム パーティションを作成するため、以下のコマンドを実行します。

Select disk 1
Create partition efi size=100
====================================================================================
※ もし4K セクタを使用している場合には、EFIサイズを260に設定してください。
以下のコマンドを実行し、『セクタあたりのバイト数』を確認することにより、お使いの PC のセクタを確認することができます。
fsutil fsinfo ntfsinfo C:
====================================================================================
Format fs=fat32 quick
assign letter=t
※ディスク 1 上の EFI システム パーティション上のボリュームに、レター T を割り当てています。

select disk 0
select partition 2
assign letter=s
※ディスク 0 上の EFI システム パーティション上のボリュームに、レター S を割り当てています。

4-2. ディスク 0 の EFI システム パーティションの内容を、ディスク 1 に作成したEFI システム パーティションにコピーします。

新たに管理者権限のコマンド プロンプトを起動し、以下のコマンドを実行します。
robocopy.exe s:\ t:\ * /e /copyall /dcopy:t /xf BCD.* /xd “System me Information”
※ S ドライブの内容を T ドライブにコピーしています。

5. ディスクをダイナミックディスクに変換し、システム ボリュームをミラーします。

5-1. 手順 4-1.まで使用していた Diskpart ユーティリティー画面にて、以下のコマンドを順番に実行します。

Select disk 1
Convert dynamic
Select disk 0
Convert dynamic

5-2. 続いて以下のコマンドを実行し、システム ボリュームをコピーします。

select me=c
add disk=1 wait
※ 同期にしばらく時間がかかります。そのままお待ちください。

※完了すると、成功したメッセージが表示されます。

次回のブログでは、作成したEFI システムパーティションの BCD (ブート構成情報)を訂正し、
新規に作成したディスクから OS の起動をさせるまでの手順についてご説明させていただきたいと思います。

いかがでしたでしょうか。
本ブログが少しでも皆様のお役に立てば、幸いです。

こんにちは。

Windows プラットフォーム サポート担当の佐々木です。
今回は、UEFI Boot 環境のWindows 10 において、OS 用のハードディスクの RAID 1を構成する具体的な手順についてご説明させていただきたいと思います。
本ブログでは、ディスクをダイナミック ディスクに変換し、システム ボリュームをコピーするところまでの手順をご説明をさせていただきます。

■　作業手順

1. まずは新規ディスク(ディスク 1)を GPT フォーマットに変換します。

1-1. 管理者コマンドプロンプトを起動します。
1-2. Diskpart.exe を実行し、 Diskpart ユーティリティーを起動します。
1-3. 以下のコマンドを順番に実行します。

Select disk 0
Select partition 1
※ディスク 0の回復パーティションを選択しています。

Detail partition
※ディスク0の回復パーティションの GUID を記憶しておきます。（種類の項目）

Select disk 1
Convert mbr
Convert gpt
※ここまででディスク 1の GPT フォーマットへの変換が完了しました。

2. 続いて回復用パーティションを作成します。

2-1. 以下のコマンドを順番に実行します。

Select partition 1
Create partition primary size=300
Format fs=ntfs quick label=recovery
※ディスク1上に新たな回復用のパーティション/ボリュームを作成しております。

Select partition 1
Select me 4
※ たった今作成したパーティション上の回復ボリュームを選択しています。

Set id=identifier
※ identifier には 1-3. で確認したディスク 0 の回復パーティションの GUID を入力します。

※『ディスクの管理画面』にてディスク 1に回復パーティションが作成されていることが確認できます。

3. ボリュームの内容をコピーするため、ボリュームにドライブ文字を割り当てます。

3-1. 以下のコマンドを順番に実行します。

Select disk 0
Select partition 1
Assign letter=q
※ディスク 0 上の回復パーティション上のボリュームに、レター Q を割り当てています。
Select disk 1
Select partition 1
Select me 4
Assign letter=r
※ディスク 1 上の回復パーティション上のボリュームに、レター R を割り当てています。

4. OS 起動のための EFI システムパーティションを作成し、内容をコピーします。

4-1. EFI システム パーティションを作成するため、以下のコマンドを実行します。

Select disk 1
Create partition efi size=100
====================================================================================
※ もし4K セクタを使用している場合には、EFIサイズを260に設定してください。
以下のコマンドを実行し、『セクタあたりのバイト数』を確認することにより、お使いの PC のセクタを確認することができます。
fsutil fsinfo ntfsinfo C:
====================================================================================
Format fs=fat32 quick
assign letter=t
※ディスク 1 上の EFI システム パーティション上のボリュームに、レター T を割り当てています。

select disk 0
select partition 2
assign letter=s
※ディスク 0 上の EFI システム パーティション上のボリュームに、レター S を割り当てています。

4-2. ディスク 0 の EFI システム パーティションの内容を、ディスク 1 に作成したEFI システム パーティションにコピーします。

新たに管理者権限のコマンド プロンプトを起動し、以下のコマンドを実行します。
robocopy.exe s:\ t:\ * /e /copyall /dcopy:t /xf BCD.* /xd “System me Information”
※ S ドライブの内容を T ドライブにコピーしています。

5. ディスクをダイナミックディスクに変換し、システム ボリュームをミラーします。

5-1. 手順 4-1.まで使用していた Diskpart ユーティリティー画面にて、以下のコマンドを順番に実行します。

Select disk 1
Convert dynamic
Select disk 0
Convert dynamic

5-2. 続いて以下のコマンドを実行し、システム ボリュームをコピーします。

select me=c
add disk=1 wait
※ 同期にしばらく時間がかかります。そのままお待ちください。

※完了すると、成功したメッセージが表示されます。

次回のブログでは、作成したEFI システムパーティションの BCD (ブート構成情報)を訂正し、
新規に作成したディスクから OS の起動をさせるまでの手順についてご説明させていただきたいと思います。
UEFI Boot 環境でダイナミック ディスクの RAID 1 (ミラーリング)を組む方法 3 / 3

前回のブログ
UEFI Boot 環境でダイナミック ディスクの RAID 1 (ミラーリング)を組む方法 1 / 3

いかがでしたでしょうか。
本ブログが少しでも皆様のお役に立てば、幸いです。

こんにちは。

Windows プラットフォーム サポート担当の佐々木です。
今回は、UEFI Boot 環境のWindows 10 において、前回のブログで作成した EFI システム パーティションの BCD を訂正し、
新規に作成したディスクから OS の起動をさせるまでの手順についてご説明させていただきたいと思います。

前回までのブログ
UEFI Boot 環境でダイナミック ディスクの RAID 1 (ミラーリング)を組む方法 1 / 3
UEFI Boot 環境でダイナミック ディスクの RAID 1 (ミラーリング)を組む方法 2 / 3

■　BCD (ブート構成データ)とは?

OS の起動に関する情報が埋め込まれたデータのことです。
BCDEdit.exe というコマンドツールから BCD を編集することができます。

1. BCD を修正する。

1-1. 管理者権限でコマンド プロンプトを起動し、以下のコマンドを順番に実行します。

bcdedit.exe /enum all

(I) 表示された一覧から、 詳細に Windows Boot Manager または Windows Boot Manager – Primary Disk と記載のある Windows Boot Manager の GUID を記憶します。

(II)bcdedit.exe /copy { identifier} /d “Windows Boot Manager – Secondary Disk”
※ identifier には (I) のコマンドの結果で記憶した GUIDを入力します。

bcdedit.exe /set { identifier} device partition=t:
※ identifier には (II) のコマンドの結果で記憶した GUIDを入力します。

Bcdedit.exe /enum all

(III) 表示された一覧から、 詳細に Windows Resume Application – secondary plex と記載のある “休止状態からの再開” のGUID を記憶します。

(IV) 表示された一覧から、 詳細に Windows 10 – secondary plex と記載のある “ Windows ブートローダー” のGUID を記憶します。
Bcdedit.exe /export t:\EFI\Microsoft\boot\BCD
Bcdedit.exe /store s:\EFI\Microsoft\Boot\BCD /delete { identifier}
※ identifier には (III) のコマンドの結果で記憶した GUID を入力します。

Bcdedit.exe /store s:\EFI\Microsoft\Boot\BCD /delete { identifier}
※ identifier には (IV) のコマンドの結果で記憶した GUID を入力します。

Bcdedit.exe /store t:\EFI\Microsoft\boot\BCD /enum all
(V) 表示された一覧から、”Device Options” のGUID を記憶します。

(VI) 表示された一覧から、 詳細に Windows Recovery Environment と記載のある “Windows Boot Loader” のGUID を記憶します。

(VII) 表示された一覧から、 詳細に Windows Resume Application と記載のある “休止状態からの再開” のGUID を記憶します。

(VIII) 表示された一覧から、 詳細に Windows 10 と記載のある “Windows Boot Loader” のGUID を記憶します。

(IX) 表示された一覧から、 詳細に Windows Boot Manager – Primary Disk と記載のある “Windows Boot Manager” のGUID を記憶します。

(X) 表示された一覧から、 詳細に Resume Application – secondary plex と記載のある “休止状態からの再開” のGUID を記憶します。

(XI) 表示された一覧から、 詳細にWindows 10 – secondary plex と記載のある “Windows Boot Loader” のGUID を記憶します。

(XII) 表示された一覧から、 詳細にWindows Boot Manager – secondary disk と記載のある “Windows Boot Manager” のGUID を記憶します。

Bcdedit.exe /store t:\EFI\Microsoft\boot\BCD /set { identifier} ramdisksdidevice partition=r:
※ identifier には (V) のコマンドの結果で記憶した GUID を入力します。

Bcdedit.exe /store t:\EFI\Microsoft\boot\BCD /set {memdiag} device partition=t:
bcdedit.exe /store t:\EFI\Microsoft\boot\BCD /set { identifier1} device ramdisk=[r:]\Recovery\WindowsRE\Winre.wim { identifier2}
※ identifier1 には (VI) のコマンドの結果で記憶した GUID を入力します。
※ identifier2 には (V) のコマンドの結果で記憶した GUID を入力します。

bcdedit.exe /store t:\EFI\Microsoft\boot\BCD /set { identifier1} osdevice ramdisk=[r:]\Recovery\WindowsRE\Winre.wim { identifier2}
※ identifier1 には (VI) のコマンドの結果で記憶した GUID を入力します。
※ identifier2 には (V) のコマンドの結果で記憶した GUID を入力します。

bcdedit.exe /store t:\EFI\Microsoft\boot\BCD /delete { identifier}
※ identifier には (VII) のコマンドの結果で記憶した GUID を入力します。

bcdedit.exe /store t:\EFI\Microsoft\boot\BCD /delete { identifier}
※ identifier には (VIII) のコマンドの結果で記憶した GUID を入力します。

bcdedit.exe /store t:\EFI\Microsoft\boot\BCD /delete { identifier} /f
※ identifier には (IX)のコマンドの結果で記憶した GUID を入力します。

bcdedit.exe /store t:\EFI\Microsoft\boot\BCD /set { identifier} description “Windows Resume Application”
※ identifier には (X) のコマンドの結果で記憶した GUID を入力します。

bcdedit.exe /store t:\EFI\Microsoft\boot\BCD /set { identifier} description “Windows 10”
※ identifier には (XI) のコマンドの結果で記憶した GUID を入力します。

bcdedit.exe /store t:\EFI\Microsoft\boot\BCD /set { identifier1} resumeobject { identifier2}
※ identifier1 には (XI) のコマンドの結果で記憶した GUID を入力します。
※ identifier2 には (X) のコマンドの結果で記憶した GUID を入力します。

bcdedit.exe /store t:\EFI\Microsoft\boot\BCD /set { identifier1} recoverysequence { identifier2}
※ identifier1 には (XI) のコマンドの結果で記憶した GUID を入力します。
※ identifier2 には (VI) のコマンドの結果で記憶した GUID を入力します。

bcdedit.exe /store t:\EFI\Microsoft\boot\BCD /set { identifier1} default { identifier2}
※ identifier1 には (XII) のコマンドの結果で記記憶した GUID を入力します。
※ identifier2 には (XI) のコマンドの結果で記憶した GUID を入力します。

bcdedit.exe /store t:\EFI\Microsoft\boot\BCD /set { identifier1} resumeobject { identifier2}
※ identifier1 には (XII) のコマンドの結果で記憶した GUID を入力します。
※ identifier2 には (X) のコマンドの結果で記憶した GUID を入力します。

1-2. ディスク 1 上のセカンダリ プレックスの情報を更新するため以下のコマンドを実行します。

bcdedit.exe /enum all
(I) 表示された一覧から、 詳細にWindows Boot Manager – secondary disk と記載のある “Windows Boot Manager” のGUID を記憶します。

bcdedit.exe /set {fwbootmgr} displayorder { identifier} /addfirst
※ identifier には (I) のコマンドの結果で記憶したGUID を入力します。

1-3. システムを再起動するため、以下のコマンドを実行します。
shutdown.exe /r /t 0

1-4. 再起動完了後、管理者コマンドプロンプトで Diskpart ユーティリティーを起動し、以下のコマンドを順に実行します。
Select disk 0
Select partition 2
Assign letter=s
※ ディスク 0 上の EFI システム パーティションにレター S を割り当てています。

Select disk 1
List partition
※ 表示された一覧から、 EFI システム パーティションの番号を記憶します。

Select partition X
※ X…1つ前のコマンドで確認した EFI システム パーティションの番号を指定します。

Assign letter=t
※ ディスク 1 上の EFI システム パーティションにレター T を割り当てています。

1-5. 新たな管理者権限のコマンド プロンプトを起動し、以下のコマンドを順番に実行します。
bcdedit.exe /store s:\EFI\Microsoft\boot\BCD /enum all
(I) 表示された一覧から、 詳細に Windows Boot Manager – secondary disk と記載のある “Windows Boot Manager” のGUID を記憶します。

Bcdedit.exe /store s:\EFI\Microsoft\boot\BCD /delete { identifier }
※ identifier には (I) のコマンドの結果で記憶していた、GUID を入力します。

bcdedit.exe /enum all
(II) 表示された一覧から、 詳細に Windows Boot Manager – Primary Disk と記載のある “Firmware Application {101fffff}” のGUID を記憶します。

bcdedit.exe /set {fwbootmgr} displayorder { identifier } /addfirst
※ identifier には (II) のコマンドの結果で記憶したGUID を入力します。

bcdboot c:\windows

bcdedit /enum firmware
(III) 表示された一覧から、 詳細に Windows Boot Manager – secondary disk と記載のある “Windows Boot Manager” のGUID を記憶します。

bcdedit /delete { identifier }
※ identifier には (III) のコマンドの結果で記憶した GUID を入力します。

bcdedit /set {bootmgr} description “Windows Boot Manager – Secondary Disk”
bcdedit /enum firmware
(IV) 表示された一覧から、 詳細に Windows Boot Manager – Primary Disk と記載のある “Firmware Application {101fffff}” のGUID を記憶します。

bcdedit.exe /set {fwbootmgr} displayorder { identifier } /addfirst
※ identifier には (IV) のコマンドの結果で記憶した GUID を入力します。

1-6. システムを再起動します。以下のコマンドを実行します。
shutdown.exe /r /t 0

以上でダイナミックディスクの RAID 1を構成する手順は完了です。
ディスク 0を取り外し、新たに作成したディスク 1から OS の起動が可能かお試しください。
※以下の画像のように起動できれば、ディスクのミラーリングに成功しています。

いかがでしたでしょうか。
本ブログが少しでも皆様のお役に立てば幸いです。

－ 参考情報

Virtual Disk Service is transitioning to Windows Storage Management API
https://msdn.microsoft.com/ja-jp/windows/compatibility/vds-is-transitioning-to-windows-storage-management-api

こんにちは。

Windows プラットフォーム サポート担当の佐々木です。
今回は、クォータを設定したボリュームのバックアップを Windows Server バックアップで取る際に警告がでる事象についてご説明させていただきます。

■クォータ設定とは？

複数のユーザが共有するコンピュータにおいて、各ユーザが自由に利用できるハードディスクの容量の上限を設定することです。
OS の機能として提供されており、ファイル サーバー リソース マネージャー(FSRM) という機能の中のひとつです。

詳しくは以下のリンクをご参照ください。
ファイル サーバー リソース マネージャー(FSRM)の概要

■発生事象

Windows Server バックアップを利用したバックアップで、クォータを設定したボリュームに対し、
フォルダ指定や除外設定をしてバックアップを開始すると『バックアップを完了しましたが、警告が発生しました。』という警告が出る事象が発生します。

＜Windows Server バックアップのログに記載されるエラー内容＞

E:\System Volume Information\SRM\quota.md のバックアップで書込み操作中にエラーが発生しました:　エラー [0x80070020] プロセスはファイルにアクセスできません。別のプロセスが使用中です。

※エラー内容は、以下の手順で確認することができます。

①ローカル バックアップ画面左下の『詳細を表示』をクリックします。

②以下のような画面が表示されるので、左下の『失敗したすべてのファイルの一覧を表示する』をクリックします。

③メモ帳が立ち上がり、エラー内容が確認できます。

■弊社で確認した環境

Windows Server 2012

■発生条件

本事象が発生する条件は、以下の2パターンに限定されます。

＜パターン１＞
Windows Server バックアップで、クォータが設定されたボリューム内のファイルを指定してバックアップを取得する場合

＜パターン２＞
Windows Server バックアップで、クォータが設定されたボリューム内のファイルをバックアップ対象外に指定して、ボリュームのバックアップを取得する場合

※クォータを設定していても、サーバー全体をバックアップする場合や、ボリューム内のファイルをバックアップ対象から除外設定せずに丸ごとバックアップする場合は、この事象は発生しません。

■結論

バックアップ時に警告が表示されますが、バックアップとして問題はございません。
整合性のあるバックアップ データですので、リストアも可能です。
クォータ設定にも影響はございませんので、ご安心ください。

この警告を表示させないようにするためには、発生条件となるバックアップの取得方法を避けていただきますようお願いいたします。

■参考）検証

＜警告が発生する事象の再現手順＞

①クォータを設定したボリュームに対し、フォルダ指定や除外設定をかけて Windows Server バックアップを開始します。

※今回は、ボリューム E にクォータを設定しています。
※バックアップは、ボリューム E の test_folder2 フォルダを除外してバックアップを取得します。
　除外・選択するファイルやフォルダは任意です。

②バックアップ完了時、状態欄に、『バックアップを完了しましたが、警告が発生しました。』という警告がでます。

＜リストアの手順＞

①発生した警告を無視し、バックアップデータをリストアします。
完了すると以下のように表示されます。

②リストアが完了したボリュームを見ると、バックアップデータが正しく回復されていることが確認できます。

いかがでしたでしょうか。
本ブログが少しでも皆様のお役に立てば幸いです。

こんにちは。

Windows プラットフォーム サポート担当の佐々木です。
今回は、Hyper-V レプリカと Windows Server バックアップを併用する際に、レプリケーションが停止する事象についてご案内させていただきます。

■レプリケーションとは？

コンピュータやソフトウェアの管理するデータと同じ内容のレプリカ(複製)を作成することです。
ホストサーバのデータ情報と作成したレプリカの内容を定期的に同期するため、万が一ホストサーバに障害が発生した場合でも、
作成したレプリカからシステムを稼働し続けることができます。
そのため、レプリケーションを行うことでシステムの高可用性を高めることにつながります。

■Hyper-V レプリカとは？

Hyper -V レプリカは、 Windows Server 2012から実装された Hyper-V の機能の一部です。
Hyper-V ホストで作成した仮想マシンでHyper-Vレプリカの機能を有効にすると、
Hyper-Vホストの仮想マシンのレプリカがHyper-V レプリカに作成され、随時レプリケーションを行うことができます。

■対象 OS

Windows Server 2012
Windows Server 2012 R2
Windows Server 2016

■Hyper-V レプリカと Windows Server バックアップを併用する際の注意点

Windows Server 標準の Windows Server バックアップでは Hyper-V レプリカ環境のバックアップには対応しておりません。

そのため、Hyper-V レプリカでレプリケーションを行っている際に
Windows Server バックアップにて仮想マシンのバックアップを実行すると
Hyper-V レプリカとHyper-V ホストのレプリケーションが切断される事象が発生することがございます。

■対応策

Hyper-V レプリカに対応したバックアップアプリケーションのご利用をご検討ください。
弊社製品では、System Center Data Protection Manager (DPM) 2012 R2 以降のバージョンから対応しております。

また、以下の２点を考慮することで回避することができます。

①バックアップの開始前にレプリケーションを一時停止する。
②バックアップ完了後、レプリケーションを再開する。

※レプリケーションの再開 / 一時停止は、以下の PowerShellコマンドにより実行することができます。

レプリケーションの再開　　：Resume-VMReplication
レプリケーションの一時停止：Suspend-VMReplication

参考:

Hyper-V 仮想マシンのバックアップ
https://docs.microsoft.com/ja-jp/system-center/dpm/back-up-hyper-v-virtual-machines?view=sc-dpm-1807

Suspend-VMReplication
https://docs.microsoft.com/en-us/powershell/module/hyper-v/suspend-vmreplication

Resume-VMReplication
https://docs.microsoft.com/en-us/powershell/module/hyper-v/resume-vmreplication


いかがでしたでしょうか。
本ブログが少しでも皆様のお役に立つと幸いです。

本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

こんにちは。Windows プラットフォーム サポート担当の沖です。

今回は、Windows Server 2016にて UWP アプリケーションに関する Windows ファイアウォールのルールが肥大化する問題について、本 Blog でご紹介します。

Symptom
—————————————————

RDS 環境で以下のような事象が発生している場合には、RDS 環境の Windows ファイアウォールのルールが本 Blog でご紹介するような状態となっていないか確認ください。

・ログオン遅延
・サーバーハング
・パフォーマンスの劣化
・ログイン時の黒い画面表示 (デスクトップの表示までに時間がかかる)
・スタートメニューまたはCortanaを起動できない
・Internet Explorer を起動できない

また、本問題の発生時に、以下のようなイベントが記録されることがあります。
————————————
Source: Microsoft-Windows-AppModel-Runtime
Date:
Event ID: 21
Task Category: None
Level: Error
Keywords: (70368744177664),AppContainer
Description: CreateAppContainerProfile failed for AppContainer Microsoft.Windows.ShellExperienceHost_cw5n1h2txyewy with error 0x800705AA.
————————————
Source: Microsoft-Windows-AppModel-Runtime
Date:
Event ID: 21
Task Category: None
Level: Error
Keywords: (70368744177664),AppContainer
Description: CreateAppContainerProfile failed for AppContainer Microsoft.Windows.Cortana_cw5n1h2txyewy with error 0x800705AA.
————————————

Condition
—————————————————

ユーザーがログオフするタイミングでユーザープロファイルが削除され、次回ログオン時にユーザープロファイルが新規で作成される環境で発生し得ます。
例えば、以下のような場合です。

パターン 1: 移動ユーザー プロファイルを使用し、且つ以下のポリシーを設定している場合
[コンピューターの管理]
– [管理用テンプレート]
– [システム]
– [ユーザー プロファイル]
– [一時記憶された移動プロファイルのコピーを削除する]

パターン 2 : RDS 環境にて、User Profile Disk を使用している場合

Cause
—————————————————

ユーザープロファイルの新規作成時に UWP アプリケーションに関する Windows ファイアウォール ルールが作成されますが、ユーザープロファイルの削除時にはそれらの Windows ファイアウォール ルールが削除されません。
これにより、ログオフ時にユーザープロファイルが削除される環境では、UWP アプリケーションに関する Windows ファイアウォール ルールがログオンの度に重複して追加され、以下のレジストリが肥大化していきます。
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable\System

以下は Windows Server 2016 で、Cortana、アカウント、職場または学校のアカウントに関するルールが重複して追加された場合の例です。

Workaround
—————————————————

Windows Server 2016 で、ユーザープロファイルの削除時にそのユーザーに関する Windows ファイアウォール ルールを削除する動作に変更するための更新プログラムの公開を予定しています。
更新プログラムを公開次第、本ブログを更新する予定です。

また、Windows Server 2012 R2 でも、UWP アプリケーションを利用している環境では、本問題が発生する可能性があります。
もし問題が発生した場合には、以下のようにレジストリのバックアップ後、レジストリを削除して改善するか確認ください。

– レジストリのエクスポート
reg export “HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable\System” fw.reg

– レジストリの削除
reg delete HKLM\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable\System /va

Update History
—————————————————

2018/10/24 : 本 Blog の公開

本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。

こんにちは、日本マイクロソフト Windows サポート チームです。
今回は Windows 10 バージョン 1803 以降で変更になったグループ ポリシーの “アプリのプライバシー” 設定をご案内します。

現象

Windows 10 バージョン 1803 以降の環境で、”アプリのプライバシー” 配下に用意されたグループ ポリシー (図1 参照) を利用した場合、
Universal Windows Platform (UWP) アプリ以外のデスクトップ アプリケーションに対してもこのアクセスの制限が生じます。

図1. “アプリのプライバシー” 配下のグループポリシー一覧

具体例) グループ ポリシーより以下のようなアクセス制限を行います

[コンピューターの構成]
– 管理用テンプレート
– Windows コンポーネント
– アプリのプライバシー

Windows アプリでカメラにアクセスする : 有効
Windows アプリでマイクにアクセスする : 有効
全てのアプリの既定値 : 強制的に拒否

上記の設定後、例えばデスクトップ アプリケーションである “Skype for Business” にて、
カメラやマイクのアクセスを試みても本制限によりアクセスが拒否されます。

原因

この動作は、バージョン 1803 にて、プライバシー制御に対するセキュリティ強化に伴い、変更が行われました。

回避策

Windows 10 バージョン 1709 以前までの動作と同じように構成する (UWP のみアクセスを禁止し、
デスクトップ アプリケーションに対してはアクセスを許可する) には、以下のいずれかの対応をご実施ください。

回避策 1 : インストール済みのストア アプリのカメラ/マイクへのアクセスを禁止し、デスクトップ アプリケーションに対してはアクセスを許可する方法
===============================================================================

影響 : 本設定の実施後、新たにストア アプリをインストールして使用することができなくなります。

1. 以下のグループポリシーを構成し、ストア アプリのインストールを拒否する設定を行います

[コンピューターの構成]
– 管理用テンプレート
– Windows コンポーネント
– アプリパッケージの展開

信頼できるすべてのアプリのインストールを許可する : “無効”

※事前に本設定を行うことにより、ユーザーが後からインストールしたストア アプリ経由でカメラ/マイクへのアクセスが行われないようにします。

2. システム全体でカメラ/マイクへのアクセスを許可する設定を行います。
※ マイクも同様に設定します

[コンピューターの構成]
– 管理用テンプレート
– Windows コンポーネント
– アプリのプライバシー
– Windows アプリでカメラにアクセスする

全てのアプリの既定値 : 強制的に許可

3. ストア アプリのカメラ/マイクへのアクセスを禁止します。(※ マイクも同様に設定します)

[コンピューターの構成]
– 管理用テンプレート
– Windows コンポーネント
– アプリのプライバシー
– Windows アプリでカメラにアクセスする

これらの特定のアプリを強制的に拒否 : 以下の手順に従い、拒否するパッケージ ファミリ名 (PFN) を登録します。(各 PFN 名間はセミコロンで区切ります)

– パッケージ ファミリ名の確認方法
a. 管理者権限の PowerShell より、以下のコマンドを実行します。

Get-AppxPackage | ? {$_.IsFramework -ne $true} | fl Name, PackageFamilyName

b. 出力される一覧より、プライバシー設定にて表示されるカメラにアクセスできるアプリのパッケージ ファミリ名を確認します。

4. システムを再起動します。

回避策 2 : ストア アプリの起動を禁止し、デスクトップ アプリケーションに対してカメラ/マイクへのアクセスを許可する方法
================================================================================

影響 : 本設定を行うことによりストア アプリが使用できなくなります。
注意事項 : 本設定は Windows 10 Pro Edition へ適用することはできません。
Windows 10 Pro をクライアント端末としてご利用の場合には、上記 “回避策 1” をご利用ください。

1. 以下のグループ ポリシーを構成し、ストア アプリの起動を禁止します。

[コンピューターの構成]
– 管理用テンプレート
– Windows コンポーネント
– ストア

Microsoft Store のすべてのアプリを無効にする : 有効

2. 以下の設定にて、プライバシー設定を許可、又は未構成にします。

[コンピューターの構成]
– 管理用テンプレート
– Windows コンポーネント
– アプリのプライバシー

Windows アプリでカメラにアクセスする : 有効
Windows アプリでマイクにアクセスする : 有効
全てのアプリの既定値 : 強制的に許可

3. システムを再起動します。

いかがでしたでしょうか。本ブログが少しでも皆様のお役に立てますと幸いです。

本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。

こんにちは、Windows プラットフォーム サポートです。

VSS (ボリューム シャドウ コピー サービス) をご利用の環境で、シャドウ コピーを保存するための記憶域を、
別ボリュームに設定できないという事象についてご説明します。

■ VSS のボリューム サイズ制限

シャドウ コピー対象のボリュームと、シャドウ コピーを保存するための記憶域

どちらも、ボリューム サイズに制限がございます。

64 TB 未満のボリュームをご利用ください。

■ VSS とは？

ボリューム シャドウ コピー サービス（VSS）は、ボリュームの静止点であるシャドウ コピーを作成するサービスです。
このシャドウ コピーをもとにバックアップを作成したり、そのまま保管して古いファイルを復元できるようにするなどの
用途で利用されます。

※ 詳細は、ボリューム シャドウ コピー サービス (VSS) についてのブログをご参照ください。

■ シャドウ コピーの記憶域とは？

シャドウ コピーは、ボリュームの差分データを指します。
シャドウ コピーの記憶域は、この差分データを保存するための領域です。

シャドウ コピーを利用したバックアップを実行すると、シャドウ コピーの記憶域が設定され、シャドウ コピーが作成されます。

多くの場合は、シャドウ コピーを取得するボリュームに、シャドウ コピーの記憶域が設定されます。

（バックアップ ソフトウエアの動作に依存しますので、例外もございます。）

■ シャドウ コピーの記憶域のボリューム設定を変更するシナリオ

ボリュームのデータ更新量が多い環境では、差分データが大きくなる傾向にあります。
シャドウ コピーが作成されるボリュームで、容量の枯渇が懸念される場合に、シャドウ コピーの記憶域を、別のボリュームに設定変更したいというシナリオがあると思います。

また、VSS に関するエラーが発生し、対処策として、シャドウ コピーの記憶域を、別のボリュームに設定を変更するケースもあります。

※ VSS のエラーと記憶域の移動については、VolSnap 33 が大量に出てしまう問題についてのブログをご参照ください。

■ シャドウ コピーの記憶域のボリューム設定確認

シャドウ コピーの記憶域ボリュームは、以下のコマンドで確認することができます。

”シャドウ コピーの記憶域ボリューム” の項目を確認します。

>vssadmin list shadowStorage

表示結果の例）
————————————————————————————————-
シャドウ コピーの記憶域関連付け
ボリューム: (C:)file://%3f/Volume%7baaa12345-2233-4455-k1ds-00lt6ye7651mb9%7d/
シャドウ コピーの記憶域ボリューム: (D:)file://%3f/Volume%7baaa12345-2233-4455-k1ds-00lt6ye7651mb9%7d/
シャドウ コピーの記憶域の使用領域: 0 B (0%)
シャドウ コピーの記憶域の割り当て領域: 0 B (0%)
シャドウ コピーの記憶域の最大領域: 544.887 GB (9 %)
————————————————————————————————-

この場合は、C ドライブのシャドウ コピーが、D ドライブに保存されています。

C ドライブが、シャドウ コピーを取得するボリュームです。

D ドライブが、シャドウ コピーの記憶域のボリュームとして設定されています。

■ シャドウ コピーの記憶域のボリューム設定を変更できない事象

シャドウ コピーの記憶域を配置するボリュームは、GUI や コマンドで設定を変更することができます。
その際、以下のように、シャドウ コピーの記憶域に設定したいボリュームに、設定できないケースがあります。

＜コマンドで設定する手順＞
vssadmin コマンドで、C ドライブのシャドウ コピー記憶域を、E ドライブに設定する例です。
コマンド：vssadmin add shadowstorage /for=C: /on=E: /Maxsize=10%

参考：Vssadmin add shadowstorage

＜コマンドで設定に失敗したときの表示例＞
”エラー：指定されたボリュームのシャドウ コピーはサポートされておりません。” というエラーが表示され、設定できない場合がございます。

＜GUI で設定する手順＞
エクスプローラのプロパティーから、”シャドウ コピー” タブを開きます。
シャドウ コピーの記憶域があるボリュームを選択し、[設定] をクリックします。

＜GUI で設定に失敗したときの表示例＞
プルダウンメニューから、シャドウ コピーの記憶域に設定したいボリュームを選択する際、
特定のドライブ（今回はE ドライブ）が表示されない場合がございます。

■ 原因と対処

シャドウ コピーの記憶域を設定するボリュームは、64 TB 未満という制限があります。（正確には、64 TB – 16 KB までです。）
64 TB 以上のボリュームにシャドウ コピーの記憶域を設定しようとすると、上記のように設定できません。

上記の設定では、E ドライブを 70 TB に設定しています。

シャドウ コピーの記憶域を設定する際は、移動先のボリュームも64 TB 未満のボリュームをご利用ください。

■ （補足 1 ）64 TB 未満なのに、シャドウ コピーの記憶域のボリュームに設定できない

シャドウ コピーの記憶域に設定できない条件は、ボリュームサイズ以外にもあります。

設定のボリュームが、以下の条件に該当している場合も、同様にシャドウ コピーの記憶域に設定できません。

こちらも併せてご確認ください。

１．ネストしたボリューム

例えば、親ボリュームが存在するマウント ボリュームなどです。

２．暗号化されたボリューム

３．ボリュームのセクタ サイズが、シャドウ コピーを取得するボリュームより大きい

             –  ボリュームのセクタ サイズ確認方法

             コマンド プロンプトを管理者権限で起動して、fsutil fsinfo ntfsinfo <ドライブ文字>: を入力します。

             “セクターあたりのバイト数” の値を確認します。表示例では 512 です。

             表示例)
                                 NTFS ボリューム シリアル番号 : 0x740618640618299e
                                  バージョン : 3.1
                                  セクター数 : 0x000000007fffe7ff
                                  総セクター数 : 0x0000000003ffff3f
                                  空きクラスター数 : 0x00000000014e8152
                                  総予約数 : 0x0000000000000000
                                  セクターあたりのバイト数 : 512
                                  クラスターあたりのバイト数 : 16384
                                  ファイル セグメントあたりのバイト数 : 4096
                                  ファイル セグメントあたりのクラスター数 : 0

４．System アカウントにクォータが設定がされている

             – クォータ設定の確認方法

             エクスプローラで、該当のボリュームを右クリックし、”クォータ” タブを選択します。

             クォータ エントリをクリックし、”＜ボリューム名＞ のクォータ エントリ” を表示します。

             以下のように、ログオン名に “NT AUTHORITY\SYSTEM” があり、”ディスクの領域を制限する”

             と表示されていましたら、System アカウントでクォータが設定されています。

（表示例）

■（補足 2 ） VSS のボリューム サイズ 制限 公開情報について

今回は、シャドウ コピーの記憶域の ”保存先ボリューム” について、サイズの制限をご紹介しました。

シャドウ コピーを ”取得するボリューム” についても、同様に 64 TB 未満というサイズの制限があります。

シャドウ コピーを取得するボリュームとは、vssadmin list shadowStorage コマンドでは”ボリューム”の項目に該当します。

こちらは、公開情報がございますので、ご参照ください。

（公開情報）

          Usability limit for Volume Shadow Copy Service (VSS) in Windows

（公開情報の抜粋）

          Microsoft does not support VSS on volumes larger than 64 TB.

いかがでしたでしょうか。
本ブログが少しでも皆様のお役に立てましたら幸いです。

こんにちは、Windows プラットフォーム サポート 横瀬です。

今回は Windows Server 2016 におけるデータ ドライブ (C ドライブと同じディスク上の別パーティション) に
付与されるアクセス権限の注意事項について、ご紹介します。

この情報が、お客様の運用のご参考となれば幸いです。

現在 Windows Server 2016 のイメージ作成を実施いただいているお客様より Sysprep の実行前後で、
一部のデータ ドライブのアクセス権限が変わってしまう。とのお問い合わせをいただいています。

具体的には、以下のような変化です。

■ Windows Server 2016 の D ドライブ (Sysprep 前)

C:\>icacls D:\
D:\ BUILTIN\Administrators:(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(OI)(CI)(F)
CREATOR OWNER:(OI)(CI)(IO)(F)
BUILTIN\Users:(OI)(CI)(RX)
BUILTIN\Users:(CI)(AD)
BUILTIN\Users:(CI)(IO)(WD)
Everyone:(RX)

■ Windows Server 2016 の D ドライブ (Sysprep 後)

C:\>icacls D:\
D:\ BUILTIN\Administrators:(F)
BUILTIN\Administrators:(OI)(CI)(IO)(F)
NT AUTHORITY\SYSTEM:(F)
NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
NT AUTHORITY\Authenticated Users:(M)
NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(M)
BUILTIN\Users:(RX)
BUILTIN\Users:(OI)(CI)(IO)(GR,GE)

この動作は Windows Server 2016 の Sysprep.exe 及び、関連モジュールのデザイン変更に伴うもので、
現行 Windows Server 2016 における想定された動作となります。

Windows Server 2016 では Sysprep.exe 及び、その関連モジュールに修正が加えられ、
その際、セキュリティ強化を考慮し既定のアクセス権限が見直されている経緯があります。

この影響を受けるドライブは C ドライブと同じディスク上に存在するドライブのみで、
C ドライブと異なるディスク上のドライブは影響を受けません。

Windows Server 2016 をご利用で且つ、C ドライブが配置されるディスク上に、別パーティションを作成し
データ ドライブを構成する際には Sysprep の実行前後で、既定のアクセス権限が異なることをご留意ください。

なお、上記の動作を変更させるグループ ポリシーや、レジストリ キーはないため、この動作において
影響を受ける可能性がある環境では、前述のアクセス権限を変更することをご検討ください。

データ ドライブについて、既定のアクセス権限を変更いただくことは、サポート対象範囲内です。

【 補足 】

前述のように Sysprep の実行前後でアクセス権限が変化するケースがありますが、もう 1 つ、データ ドライブを
作成する方法によっても、既定のアクセス権限が異なるケースがありますので、補足情報として、紹介します。

この動作は Windows Server 2012 R2 と Windows Server 2016 におけるもので、弊社製品における想定された動作です。

データ ドライブを作成する方法として、Windows インストール時に作成する場合と Windows インストール後、縮小処理等を利用して
作成する場合の 2 パターンがあります。

Windows インストール時に作成した場合、既定のアクセス権限は以下となります。

▼ Windows Server 2012 R2 (インストール時に作成)
Windows Server 2016 (インストール時に作成)

C:\>icacls D:\
D:\ BUILTIN\Administrators:(F)
BUILTIN\Administrators:(OI)(CI)(IO)(F)
NT AUTHORITY\SYSTEM:(F)
NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
NT AUTHORITY\Authenticated Users:(M)
NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(M)
BUILTIN\Users:(RX)
BUILTIN\Users:(OI)(CI)(IO)(GR,GE)

Windows インストール後に作成すると、既定のアクセス権限は以下となります。

▼ Windows Server 2012 R2 (インストールした後に作成)
Windows Server 2016 (インストールした後に作成)

C:\>icacls D:\
D:\ BUILTIN\Administrators:(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(OI)(CI)(F)
CREATOR OWNER:(OI)(CI)(IO)(F)
BUILTIN\Users:(OI)(CI)(RX)
BUILTIN\Users:(CI)(AD)
BUILTIN\Users:(CI)(IO)(WD)
Everyone:(RX)

以上となります。

なお、本ブログは予告なく変更される場合がございますので、ご了承ください。

こんにちは、Windows プラットフォーム サポートの加藤です。

Windows Server バックアップを利用する環境では、ディスク容量確保のために、シャドウ コピーの削除が必要となる場合があります。

バックアップの世代管理にはシャドウ コピーが使われているため、標準ではバックアップ取得先にシャドウ コピーが作成されます。シャドウ コピーのデータ量はボリュームの変更量に依存するため、場合によっては、バックアップ取得先のディスク使用量を逼迫させる要因になります。

今回は、コマンドによる、Windows Server バックアップの世代管理に用いられるシャドウ コピーの削除手順についてご紹介いたします。

※　ただし、シャドウ コピーは 1 世代ごとに差分データを管理しているため、ディスク容量確保のためには。最も古い世代から削除対象の世代までのデータを削除する必要がございます。
 

Windows Server バックアップのシャドウ コピーとは

Windows Server バックアップでは、常にバックアップ先に最新のバックアップ データが上書き保存されていくため、古いバージョンのバックアップをシャドウ コピーによって管理しています。
シャドウ コピーには、用途に応じていくつかの種類があり、Windows Server バックアップ実行時 (wbadmin コマンドを用いたバックアップ実行時) に、バックアップ先に自動で作成されるシャドウ コピーは、DataVolumeRollback 属性です。

この属性は、共有フォルダーのシャドウ コピーを削除する際に用いる vssadmin delete shadows では削除できないシャドウ コピーであり、diskshadow コマンドや wbadmin delete backup コマンドを用いて削除する必要があります。シャドウ コピー自体は vssadmin list shadows コマンドから確認することができます。
 

[タイトル] Windows Server バックアップにおける容量と世代管理について
[URL] https://blogs.technet.microsoft.com/askcorejp/2016/05/27/windows_server_backup_space_management/

Windows Server バックアップのシャドウ コピーの削除方法

上記の通り、バックアップのシャドウ コピーは、diskshadow コマンドや wbadmin delete backup コマンドを用いて削除を行います。
 

■　それぞれのコマンドによる削除の特徴

diskshadow コマンドと wbadmin delete backup コマンドの特徴、および、メリット・デメリットを、下記にまとめます。
 

diskshadow コマンド
[特徴] シャドウ コピーの種類にかかわらず削除を行うことができる
[メリット] シャドウ コピーの一括削除を行う際には便利
[デメリット] バックアップのリストアを行う際のカタログ データは削除されないため、
リストアできる世代の一覧に削除した世代が残り続ける。
(削除した世代は、リストアに失敗する)
 

wbadmin delete backup コマンド
[特徴] バックアップの世代を削除することができる
[メリット] シャドウ コピーとカタログ データの両方を削除することができる
[デメリット] Windows Server 2012 以降の OS から使用することができる
既知の不具合がある。
 

なお、各 OS 上で各コマンドを実行した際の動作について、下記にまとめます。

■　diskshadow コマンドによる削除について

diskshadow ユーティリティはシャドウコピーを作成するボリューム シャドウ コピー サービス (VSS) によって提供されている機能をコマンドラインから操作するためのツールです。

diskshadow ユーティリティの delete shadows コマンドでは、共有フォルダーのシャドウ コピーや DataVolumeRollback 属性のシャドウ コピーを含めた、属性に関係なくすべてのシャドウ コピーを削除することが可能です。
具体的には、保管しているすべてのシャドウ コピーを削除したり、最も古い世代のシャドウ コピーのみを削除したり、特定の世代を指定して削除を行うことができます。

ただし、このコマンドによって DataVolumeRollback 属性のシャドウ コピーの削除を行った場合、Windows Server バックアップにて作成されるバックアップのカタログからは削除されず、”回復” を行うバックアップのバージョン一覧に表示された状態となります。
これにより、すでに存在しないシャドウ コピーのバックアップが選択可能となってしまい、リストアを行おうとした場合は失敗します。

また、最も古い世代のシャドウ コピー以外を削除した場合に関しては、削除した世代以前のシャドウ コピーからのデータのリストアに、削除対象のシャドウ コピーのデータが必要となるため、実データは残った状態となりますが、削除処理を行ったシャドウ コピーに関する情報と実データの紐づきは削除されるため、リストアはできません。
そのため、空き容量確保の目的で最も古いシャドウコピー以外を削除することは、有用ではございませんのでご注意ください。
 

————————————————
1. 管理者権限にてコマンド プロンプトを起動します。
2. diskshadow と入力し diskshadow ユーティリティを起動します。
3. delete shadows SET コマンドを利用します。

実行例) すべてのシャドウ コピーを削除
delete shadows all

実行例) <セット ID> パラメーターで指定したシャドウ コピー セット内のシャドウ コピーを削除
delete shadows set <セット ID>

実行例) <シャドウ ID> パラメーターで指定したシャドウ コピーを削除
delete shadows id <シャドウ ID>

Delete shadow /? にてオプションの確認が可能です。
<セット ID> や <シャドウ ID> に指定する値は list shadows all コマンドにて確認できます。
————————————————
 

[タイトル] delete shadows
[URL] https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/delete-shadows

■　wbadmin コマンドによる削除について

wbadmin delete backup コマンドは、1 つ以上の Wondows Server バックアップを削除するために利用するコマンドです。
Windows Server 2012 から wbadmin コマンドに delete backup コマンドが追加され、バックアップの世代管理用のシャドウ コピーと、Windows Server バックアップのカタログ情報を同時に削除することが可能になりました。

Windows Server 2016 のバックアップを取得する際に、wbadmin delete backup
コマンドを用いることで、世代管理を行うことが可能でございます。
弊社検証環境でも世代管理が行えることを確認いたしました。
 

————————————————
該当コマンド: wbadmin delete backup -<オプション>

実行例) 新しいものから ３ つのバックアップを保持して残りを削除
wbadmin delete backup -keepVersions:3

実行例) 指定したバージョンのバックアップを削除
wbadmin delete backup -version:03/31/2006-10:00

実行例) F ドライブの最も古いバックアップを削除
wbadmin delete backup -backupTarget:f: -deleteOldest
————————————————
 

ただし、このコマンドの実行において、コマンドの後に指定するオプションの 組み合わせによって、既知の不具合が発生することが報告されています。
 

■　wbadmin delete backup コマンド実行時の注意事項

wbadmin delete backup コマンド実行時に、オプション keepversions:1 と -backupTarget を指定してコマンドを実行する場合、最新世代のバックアップ以外の 古い世代のバックアップをすべて削除することが可能ですが、これにより、 バックアップデータを格納しているフォルダー自体が消失するという既知の不具合があります。

加えて、最新世代のバックアップのデータを保持しているシャドウ コピーが何らかの原因で削除されてしまった場合、すべてのバックアップのデータが消失し、障害時にリストアができなくなる可能性があります。

後述いたしますが、シャドウ コピーは差分を1世代ごとに管理しているため、特定のタイミングに復元する場合、復元したいタイミングのシャドウコピーに至る前のすべてのシャドウ コピーが必要になります。
そのため、ディスク上の最新世代のシャドウ コピーのデータが削除されてしまうと、それ以前のシャドウ コピーの復元が不可能になります。

この不具合に対する対処方法としては、オプション -keepversions と -backupTarget を指定してコマンドを実行する場合、-keepversions の値を 2 以上に設定する必要があります。

詳細な情報に関しましては、下記の公開情報をご参照ください。
 

なお、Windows Server 2008 R2 および Windows Server 2012 以降の OS における、それぞれのコマンド実行時の挙動に関しては、弊社環境にて検証を行った結果を次回のブログにてご紹介いたします。
[続編] コマンドによるバックアップの過去の世代の削除手順 2/2

いかがでしたでしょうか。
本ブログが少しでも皆様のお役に立てば幸いです。

こんにちは、Windows プラットフォーム サポートの加藤です。

前回、コマンドによる Windows Server バックアップの世代管理に用いられるシャドウ コピーの削除手順についてご紹介いたしました。
今回は、弊社環境にて検証を行った、Windows Server 2008 R2 および Windows Server 2012 以降の OS における、それぞれのコマンド実行時の挙動についてご紹介いたします。

なお、前回のブログは、下記よりご参照いただけます。
[前編] コマンドによるバックアップの過去の世代の削除手順 1/2
 

[参考] 検証

■　検証事項

• バックアップを 3 世代分取得し、diskshadow コマンドにて、2 世代目のバックアップのシャドウ コピーを削除
  → “回復” のカタログの内容とリストアが可能かどうかを確認する
• バックアップを 3 世代分取得し、wbadmin delete backup コマンドにて、2 世代目のバックアップを削除
  → “回復” のカタログの内容を確認する

■　Windows Server 2008 R2

diskshadow コマンド
→ シャドウコピーを消してもカタログは残り続ける

(1) 3 世代分の Windows Server バックアップ取得後、以下のように正常にバックアップが取得できていることを確認します。

(2) diskshadow コマンドにて、上記の 3 世代のバックアップのうち、2 世代目のシャドウ コピーを削除します。
※ シャドウ コピーはバックアップ完了後に取得されるため、バックアップ完了時刻よりも後の時間に作成されます。

(3) Windows Server バックアップの [回復] より、リストア可能な世代 (カタログ) を確認します。
以下の画像より、(2) で削除した世代もリストア可能な世代として表示されていることが確認できます。

(4) Windows Server バックアップの [回復] より、(2) で削除した世代のリストアを試みると、下記のようなメッセージが表示され、リストアに失敗します。

これより、diskshadow コマンドによるバックアップのシャドウ コピーが削除を行った場合は、バックアップのリストアを行う際のカタログ データは削除されていないことが確認できます。
 

wbadmin delete backup コマンド

前回のブログでご紹介した通り、Windows Server 2008 R2 では、wbadmin delete backup コマンドを使用することができません。

 

■　Windows Server 2012 以降 (2012 / 2012R2 / 2016)

diskshadow コマンド

(1) 3 世代分の Windows Server バックアップ取得後、以下のように正常にバックアップが取得できていることを確認します。

(2) diskshadow コマンドにて、上記の 3 世代のバックアップのうち、2 世代目のシャドウ コピーを削除します。

(3) Windows Server バックアップの [回復] より、リストア可能な世代 (カタログ) を確認します。
以下の画像より、(2) で削除した世代もリストア可能な世代として表示されていることが確認できます。

(4) Windows Server バックアップの [回復] より、(2) で削除した世代のリストアを試みると、下記のようなメッセージが表示され、リストアに失敗します。




 

wbadmin delete backup コマンド

(1) 3 世代分の Windows Server バックアップ取得後、以下のように正常にバックアップが取得できていることを確認します。

(2) wbadmin delete backup コマンドにて、上記の 3 世代のバックアップのうち、2 世代目のシャドウ コピーを削除します。

(3) Windows Server バックアップの [回復] より、リストア可能な世代 (カタログ) を確認します。
以下の画像より、(2) で削除した世代は、カタログからも削除されていることが確認できます。

 

いかがでしたでしょうか。
本ブログが少しでも皆様のお役に立てば幸いです。

こんにちは。Windows プラットフォーム サポートです。
2018 年 8 月更新プログラム (KB4343887) を適用した Windows Server 2016 Hyper-V ホストから未適用の環境に対して仮想マシンのライブマイグレーションを実行すると、イベントログに Hyper-V-VMMS ID:24004 が記録され失敗する場合がございます。

—————————————
ログの名前: Microsoft-Windows-Hyper-V-VMMS/Admin
ソース: Hyper-V-VMMS
日付: XXXX/XX/XX XX:XX:XX
イベント ID: 24004
タスクのカテゴリ: なし
レベル: エラー
キーワード: N/A
ユーザー: SYSTEM
コンピューター: XXXXXXXX
説明:
仮想マシン ‘XXXX’ は、物理コンピューター ‘XXXX’ でサポートされていないプロセッサー固有の機能を使用しています。
異なるプロセッサーを持つ物理コンピューターにこの仮想マシンを移行できるようにするには、仮想マシン設定を変更して、
仮想マシンで使用されるプロセッサー機能を制限します。(仮想マシン ID XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX)
—————————————

※ 仮想マシンの設定でプロセッサの互換性を有効化した後も、同じエラーログ (ID:24004) が記録されて失敗します。

本事象は、以下の条件に全て該当する場合に発生いたします。

[条件]
Hyper-V ホストの条件:
– Windows Server 2016 Hyper-V クラスター環境
– ハードウェア側ファームウェアにプロセッサのマイクロコード修正 (CVE-2018-3639、CVE-2018-3640 への対策) を導入

仮想マシンの条件:
– 2018 年 8 月更新プログラム (KB4343887) を適用した環境で新規作成した仮想マシン、もしくはコールドブートした仮想マシン

シナリオ:
– 2018 年 8 月更新プログラムを適用した Hyper-V ホスト (KB4343887) から未適用の Hyper-V ホストへライブマイグレーションを行う

[原因]
8 月の更新プログラムではハイパーバイザーでサポートする CPU 機能が追加されており、その結果適用 Hyper-V 環境と未適用の Hyper-V 環境で使用する CPU 機能に差が生じます。
CPU の機能レベルに差が生じている場合、移動先でプロセッサの新しい命令セットに対応できず、ライブマイグレーションに失敗する場合があります。

なお、8 月の更新プログラムで追加された CPU 機能は、仮想マシンの設定であるプロセッサの互換性を有効にした場合も失敗します。これは、追加された CPU 機能は互換性リストに含まれる機能であるためです。

[対処]
クラスター環境では、全クラスター ノードでソフトウェア更新プログラム含めて同一構成であることを推奨しております。
そのため、更新プログラム未適用の環境に、対象の更新プログラムを適用いただくことで対処可能です。

直ぐに更新プログラムを適用できない場合には、以下の手順で、仮想マシンに対する CPU 機能レベルを制限する方法で対処可能でございます。

1. Hyper-V ホストにて管理者権限のコマンドプロンプトを起動します。

2. 以下のコマンドを実行します。

reg add “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization” /v MinVmVersionForCpuBasedMitigations /t REG_SZ /d “9.0” /f

[参考情報]
Protecting guest virtual machines from CVE-2017-5715 (branch target injection)
https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/CVE-2017-5715-and-hyper-v-vms

本 Blog が少しでも皆様のお役に立てれば幸いです。