Windows プラットフォーム サポートの 佐々木 俊暢 です。

管理者からユーザーに対して業務連絡や緊急の告知を行う際にメーリングリストやメッセンジャーなどを利用した方法が用いられることがありますが、ユーザーがメールやメッセンジャーに気づかず、連絡が行き届かないことがありますね。

もっと、リアルタイムに確実なメッセージの伝達を行いたい！という管理者様のために、Windows 標準コマンドである、MSG コマンドを利用した、ユーザーへのメッセージの通知方法をご紹介させていただきます。

MSG コマンドでは、以下のようなメッセージをユーザーに通知することができます。(OS により、表示フォーマットが異なります。)

※ MSG コマンドのメッセージ表示画面は最前面に表示されるため、他のウィンドウを開いているユーザーに気づいてもらいやすくなります。

なお、MSG コマンドには以下のような注意事項がございます。

注意事項:

1. すべてのコンピューターに対してメッセージを送ることはできません。1 台のコンピューターに対してのみメッセージ送信が可能です。
2. このコマンドの実行には管理者権限が必要です。
3. 初期値では、受信したメッセージは 60 秒間だけ画面に表示されます。/TIME:秒 オプションを指定することで、表示時間を変更することは可能です。

MSG コマンドはメッセージを送信するコンピューターを 1 台しか指定することができないため、複数のコンピューターに通知するためには MSG コマンドのみでは実現することができません。
そのため、複数のコンピューターに通知を行うためにはスクリプティングを行うなどの工夫が必要になります。

今回は PowerShell を用いた複数のコンピューターに対して、MSG コマンドでメッセージを送付する方法をご紹介させていただきます。

PowerShell を用いて、ドメイン内のすべてのコンピューターに対して、MSG コマンドでメッセージを送信する方法。

前提条件:

1. MSG コマンドは、ドメイン コントローラーから、管理者の権限を持ったユーザーから送信します。
2. MSG コマンドでメッセージを送付する対象のコンピューターはドメインに参加しているコンピューターとします。
3. メッセージの表示対象は、ログオン中のユーザーとします。

実際複数のコンピューターに対して、MSG コマンドの送信を行う前に、1 台のコンピューターに対して、期待するメッセージが送信できるか確認しましょう。

(1) MSG コマンドの送信確認

ドメイン コントローラーに管理者権限を持つユーザーでログオンし、コマンド プロンプトから、以下のコマンドを実行します。
メッセージの送信対象のコンピューター名は、COMPUTER-001 とします。

msg /server:COMPUTER-001 * this is test message.

COMPUTER-001 にメッセージが表示されない場合には、メッセージを受ける側のコンピューターで以下の内容を確認してください。

[1] レジストリを変更する

1. Win + R キーを押下し、[ファイル名を指定して実行] から “regedit” を実行し、[レジストリ エディター] を起動します。
2. 左側のペインで、以下のレジストリを展開します。
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
3. 右側のペインで [AllowRemoteRPC] をダブル クリックして開き、[値のデータ] を “1” に変更し、[OK] ボタンをクリックして閉じます。(*)
4. [レジストリ エディター] を終了し、コンピューターを再起動します。

(*) 手順: 3 のレジストリが存在しない場合、新規に作成して追加することで同様の動作が可能です。

[2] リモート設定を変更する

1. Win + R キーを押下し、[ファイル名を指定して実行] から “sysdm.cpl” を実行し、[システムの詳細設定] を開きます。
2. [システムの詳細設定] で [リモート] タブをクリックします。
3. [リモート デスクトップ] 枠内で次の設定をチェックします。
   “[ネットワーク レベル認証でリモート デスクトップを実行しているコンピューターからのみ接続を許可する (推奨)]”
4. [OK] ボタンをクリックします。

[3] ファイアウォールを変更する

1. Win + R キーを押下し、[ファイル名を指定して実行] から “wf.msc” を実行し、[セキュリティが強化された Windows ファイアウォール] 画面を開きます。
2. [受信側の規則] の [リモート イベントのログ管理 (NP 受信)] を右クリックし、[規則の有効化] をクリックします。

1台のコンピューターに対し送信できましたら、次は複数のコンピューターに対し送信しましょう。

(2) ドメイン内のすべてのコンピューターでログオンしているユーザーにメッセージを送信する。

PowerShell を用いて、ドメイン コントローラーから、ドメインに参加しているすべてのコンピューター名を取得し、取得したコンピューター名のコンピューターに対して、ブロードキャストでメッセージを送信します。

以下にサンプル スクリプトをご紹介します。
拡張子を .ps1 としてファイルに保存し、管理者として実行します。

foreach($str_name in Get-ADComputer -Filter “*” | Select-Object “Name”){
$prams = “/SERVER:” + $str_name.Name + ” * /TIME:60″
$msg = (Get-Content -Path C:\msg.txt) -join “`r`n”
Start-Process -FilePath msg -ArgumentList $prams, $msg
}

上記のサンプル スクリプトについて、以下のとおり解説します。

Get-ADComputer コマンドレットを用いて、ドメイン内に参加しているすべてのコンピューター名を取得しています。
※ Get-ADComputer のオプションを利用し、検索対象のコンピューターを絞り込むことで、運用上の利便性が上がると思います。
foreach($str_name in Get-ADComputer -Filter “*” | Select-Object “Name”){

/SERVER オプションで、コンピューター名を指定し、/TIME: オプションでメッセージの表示時間を 60 秒間に指定しています。
※ /TIME: で指定するメッセージの表示時間を引数で指定できるように編集すると、運用上の利便性が上がると思います。$prams = $prams = “/SERVER:” + $str_name.Name + ” * /TIME:60″

送信メッセージは、C:\msg.txt に保存されているテキスト ファイルの内容を指定しています。
※ 送信メッセージを保存したファイルのパスを、引数で指定できるように編集すると、運用上の利便性が上がると思います。
$msg = (Get-Content -Path C:\msg.txt) -join “`r`n”

取得したコンピューター名に対して、MSG コマンドでメッセージを送信しています。
Start-Process -FilePath msg -ArgumentList $prams, $msg

補足 1:
PowerShell のスクリプト実行時に以下のようなエラーが表示される場合には、Set-ExecutionPolicy コマンドにて、スクリプトの実行ポリシーを変更してください。

*** スクリプト実行時のエラー
.\<スクリプト名>.ps1 : このシステムではスクリプトの実行が無効になっているため、ファイル <スクリプト ファイルパス> を読み込むことができません。詳細については、「about_Execution_Policies」(http://go.microsoft.com/fwlink/?LinkID=135170) を参照し
てください。
発生場所 行:1 文字:1
+ .\<スクリプト名>.ps1
+ ~~~~~~~~~~
+ CategoryInfo : セキュリティ エラー: (: ) []、PSSecurityException
+ FullyQualifiedErrorId : UnauthorizedAccess

Set-ExecutionPolicy コマンドレットの使用
https://technet.microsoft.com/ja-jp/library/ee176961.aspx

補足 2:
Get-ADComputer コマンドレットのオプションを利用して、用途に合わせたコンピューター検索をご検討いただけます。
以下のコマンド ラインでは、OU 単位でのコンピューター名の検索ができます。

Get-ADComputer -Filter “*” -SearchBase “OU=test_ou,DC=contoso,DC=com” | Select-Object “Name”

Get-ADComputer
https://technet.microsoft.com/en-us/library/ee617192.aspx

今回ご紹介させていただきましたユーザーへのメッセージの送信方法が、管理者様の環境運用の一助となりましたら幸いでございます。

近頃は寒暖の差の激しい季節になって参りました。
みなさまも、体調には十分をお気をつけて、お身体ご自愛ください。

佐々木 俊暢

こんにちは。Windows プラットフォーム サポートの伊藤です。
Hyper-V の拡張セッション モードを使用している状況で shutdown コマンドを使用する際などの注意点についてご案内します。

拡張セッション モードは Windows 8.1 及び Windows Server 2012 R2 から Hyper-V に追加された機能で、この機能を使用することでプリンター、クリップボード、仮想マシン への接続に使っているコンピューターの ローカル ドライブなどのローカル リソースを使用できます。
本モードは仮想マシンに接続する際に提供される対話型のセッション エクスペリエンス を強化したものとなっており、 リモート デスクトップ接続と同様にゲスト OS のリモート デスクトップ サービス（RDS）を使用して接続します。

その為、リモート セッションで接続した際に使用不可となっている、オプションの選択画面への移行が Hyper-V の拡張セッション モードを使用した際のセッションでは同様に行うことが出来ません。

拡張セッションでは shutdown コマンドの /o オプションを指定して実行した場合では「パラメーターが間違っています。(87) 」
というエラーとなり、shiftキーを押しながら電源メニューの再起動をクリックした場合では何も実行されない動作となりますのでご注意ください。
　　　
使用している仮想マシン接続が拡張セッション モードを使用しているかどうかは以下の箇所から確認することができ、
拡張セッション モードを使用している場合はチェックが入っている状態となります。

※　補足

リモートセッション：リモート デスクトップなどリモートでサーバー等に接続した際のセッションの事を指します。
コンソールセッション：物理コンソールで接続した際のセッションの事を指します。

Use local resources on Hyper-V virtual machine with VMConnect
https://technet.microsoft.com/windows-server-docs/compute/hyper-v/learn-more/Use-local-resources-on-Hyper-V-virtual-machine-with-VMConnect

Windows Platform サポートのかとうです。

Windows 8 から「Windows ストア アプリ」という新しいタイプのアプリケーションが登場しました。

Windows ストア アプリは、Windows ストアから、好きなアプリを選んでインストールすることができますが、Windows ストアを介さずとも、直接コンピュータにインストールすることができます。

この方法を、Windows ストア アプリのサイドローディングといいます。

開発した Windows ストア アプリや、あらかじめ Windows Store for Buisiness から入手した Windows ストア アプリのパッケージをインストールするときに、ご利用いただけます。

Windows ストア アプリのインストール方法

お手元に、Windows ストア アプリのインストールパッケージをご用意ください。
.appxbundle もしくは、.appx の拡張子のファイルです。

Sway アプリのインストールパッケージの例です。

インストールの前に、インストールするコンピュータの設定を変更します。

Windows 10 の場合、設定 – 更新とセキュリティ – 開発者向け を開いて、「サイドロードアプリ」を選択してください。

設定が終わったら、インストールをおこないます。

Windows PowerShell のコマンドひとつでインストールできます！ 2 通りの方法があります。

１．このコンピュータにログオンするユーザー全てにインストールしたい時

コマンド実行後、各ユーザーが次回ログオンするときにインストールされます。 新規に作成したユーザーにもインストールされます。

※ このコマンドは、管理者権限での実行が必要です。

※   依存関係のパッケージが無い場合は、DependencyPath オプションは省略してください。

パターン1： Windows Store for business からダウンロードしたインストールパッケージをインストールする場合

あらかじめ、ライセンスファイルもダウンロードします。 ライセンスファイルを適用してインストールします。

WindowsPowerShell を起動して、以下のコマンドを入力してください。

DISM.exe /Online /Add-ProvisionedAppxPackage /PackagePath:”< Windows ストア アプリのインストールパッケージのパス>” /LicensePath:“<ライセンスファイルのパス>”  /DependencyPath <依存関係のあるパッケージのパス>

(コマンド例)

DISM.exe /Online /Add-ProvisionedAppxPackage /PackagePath:”C:\test\test.appxbundle” /LicensePath:“C:\test\test_LicenseFile.xml” /DependencyPath c:\test\dependency.appxbundle

パターン2：ライセンスファイルの指定をスキップしてアプリパッケージをインストールする場合

ライセンスファイルの適用をスキップします。この場合、起動時にオンラインで認証が必要です。

WindowsPowerShell を起動して、以下のコマンドを入力してください。

DISM.exe /Online /Add-ProvisionedAppxPackage /PackagePath:” < Windows ストア アプリのインストールパッケージのパス>” /SkipLicense /DependencyPath <依存関係のあるパッケージのパス>

(コマンド例)

DISM.exe /Online /Add-ProvisionedAppxPackage /PackagePath:”C:\test\test.appxbundle” /SkipLicense /DependencyPath c:\test\dependency.appxbundle

2．今ログオンしているユーザーにだけ、インストールしたい時

Add-AppxPackage -path < Windows ストア アプリのインストールパッケージのパス> -DependencyPath <依存関係のあるパッケージのパス>

(コマンド例)

Add-AppxPackage -path c:\test\test.appxbundle -DependencyPath c:\test\dependency.appxbundle

Add-AppxPackage と Add-ProvisionedAppxPackageの違いって？

そもそも、なぜ 2 種類のコマンドがあるのでしょうか？

Windows ストア アプリには、

端末にインストールするアプリ（プロビジョニングされたWindowsストアアプリ）(A)

と、

ユーザーごとにインストールされるアプリ (B)

との 2 種類があります。

(A)  端末にインストールするアプリ（プロビジョニングされたストア アプリ）

端末ごとにアプリのパッケージがインストールされるため、サイドローディング後、 ユーザーがログオン時に、端末ごとにインストール済みのアプリパッケージをもとに、 ユーザーごとにWindowsストア アプリがインストールされます。

Windowsストア アプリの卵のようなもので、これをインストールするコマンドが DISM.exe /Online /Add-ProvisionedAppxPackage です。

(B)  ユーザーごとにインストールされるアプリ

ユーザー毎にインストールされたWindowsストア アプリを指します。

これをインストールするコマンドが Add-AppxPackage です。

話はそれましたが、アプリの一覧に、インストールした Windows ストア アプリが表示されたでしょうか？

インストールしたアプリをアンインストールしたい場合は、こちらを参照ください。

Windows ストア アプリのアンインストール

(1) DISM.exe /Online /Add-ProvisionedAppxPackage コマンドでインストールした場合

端末にインストールしたストア アプリのパッケージを削除します。

(手順)

1. WindowsPowerShell を管理者として起動し、以下のコマンドを実行します。

プロビジョニング パッケージの一覧が表示されます。

DISM.exe /online /get-ProvisionedAppxPackages

2．表示されたプロビジョニング パッケージの一覧から “パッケージ名” を確認します。

(例) Sway

パッケージ名 : Microsoft.Office.Sway_2015.7870.45131.0_neutral_~_8wekyb3d8bbwe

3. 以下のコマンドを実行して、プロビジョニング パッケージを削除します。

(書式)

DISM.exe /Online /Remove-ProvisionedAppxPackage /PackageName:＜パッケージ名＞

(例)Sway

DISM.exe /Online /Remove-ProvisionedAppxPackage /PackageName:Microsoft.Office.Sway_2015.7870.45131.0_neutral_~_8wekyb3d8bbwe

(2) Add-AppxPackage コマンドでインストールした場合

Add-AppxPackage コマンドでインストールしたユーザーそれぞれのログオンして、アンインストールします。

(手順)

1.PowerShell を起動し、以下のコマンドを実行します(管理者権限で実行する必要はございません)。 ユーザーごとのパッケージの一覧が表示されます。

Get-AppxPackage

2. 表示されたユーザーごとのパッケージの一覧から  “Name” (表示名) を確認します。

(例)Sway

Name : Microsoft.Office.Sway

3.  以下のコマンドを実行して、ユーザーごとのパッケージを削除します。

(書式)

Get-AppxPackage -Name ＜Name (表示名)＞ | Remove-AppxPackage

(例)Sway

Get-AppxPackage -Name Microsoft.Office.Sway | Remove-AppxPackage

(注意) DISM.exe /Online /Add-ProvisionedAppxPackage コマンドでインストールしたアプリを上記の方法でアンインストールを実行することはできますが、 再サインイン時に、端末に残っているストア アプリのパッケージから再度インストールされてしまいます。

DISM.exe /Online /Add-ProvisionedAppxPackage コマンドでインストールしたアプリは、

DISM.exe /Online /Remove-ProvisionedAppxPackage でアンインストールしてください。

Windows ストア アプリがインストールできないときのトラブルシューティング

Q1 : DISM.exe /Online /Add-ProvisionedAppxPackage　コマンドでインストールしたのに、アプリの一覧に表示されません。なぜでしょうか？

A1 : アプリのインストールに時間がかかる場合があります。

一度サインアウトして、再度サインインしても表示されない場合、Add-AppxPackage コマンドでインストールしてみてください。

Q2 : いちど、Add-AppxPackage コマンドでインストールしたのですが、アプリを右クリックして “アンインストール” をクリックすると、消えてしてしまいました。もう一度インストールできますか？

A2 : はい、アンインストールしてしまっても、Add-AppxPackage コマンドで再度インストールできます！

Q3: 再度インストールしようとしたら、エラーが出力されてインストールできません。

A3 : 例えば、以下のようなエラーが出力された時の対処法についてご案内します。

エラー：15611 は、すでにインストールされているのに、同じアプリをインストールしようとしたときに表示されるエラーです。

今回の例ですと、Add-AppxPackage コマンドで、まったく同じバージョンのWindowsストア アプリを上書きしてインストールしようとしたときに表示されました。

表示にもある通り、インストールしようとしたアプリのバージョンが、既にインストールされているWindowsストア アプリよりも上のバージョンのアプリをインストールするか、全てのユーザーからアプリをアンインストールすると、再度インストールすることができます。

全てのユーザーからアプリをアンインストールする場合、それぞれのユーザーでログオンして、

get-appxpackage -name < Windowsストア アプリ名> | remove-appxpackage

を実行してください。

少し古い記事ですが、技術情報もありますので、ご参照ください。

DISM を使ったアプリのサイドローディング

https://technet.microsoft.com/library/hh852635.aspx

Windows ストア アプリのサイドローディングでお困りの時に、お役に立てたら幸いです♪

Windows プラットフォーム サポートの 佐々木 俊暢 です。

管理者からユーザーに対して業務連絡や緊急の告知を行う際にメーリングリストやメッセンジャーなどを利用した方法が用いられることがありますが、ユーザーがメールやメッセンジャーに気づかず、連絡が行き届かないことがありますね。

もっと、リアルタイムに確実なメッセージの伝達を行いたい！という管理者様のために、Windows 標準コマンドである、MSG コマンドを利用した、ユーザーへのメッセージの通知方法をご紹介させていただきます。

MSG コマンドでは、以下のようなメッセージをユーザーに通知することができます。(OS により、表示フォーマットが異なります。)

※ MSG コマンドのメッセージ表示画面は最前面に表示されるため、他のウィンドウを開いているユーザーに気づいてもらいやすくなります。

なお、MSG コマンドには以下のような注意事項がございます。

注意事項:

1. すべてのコンピューターに対してメッセージを送ることはできません。1 台のコンピューターに対してのみメッセージ送信が可能です。
2. このコマンドの実行には管理者権限が必要です。
3. 初期値では、受信したメッセージは 60 秒間だけ画面に表示されます。/TIME:秒 オプションを指定することで、表示時間を変更することは可能です。

MSG コマンドはメッセージを送信するコンピューターを 1 台しか指定することができないため、複数のコンピューターに通知するためには MSG コマンドのみでは実現することができません。
そのため、複数のコンピューターに通知を行うためにはスクリプティングを行うなどの工夫が必要になります。

今回は PowerShell を用いた複数のコンピューターに対して、MSG コマンドでメッセージを送付する方法をご紹介させていただきます。

PowerShell を用いて、ドメイン内のすべてのコンピューターに対して、MSG コマンドでメッセージを送信する方法。

前提条件:

1. MSG コマンドは、ドメイン コントローラーから、管理者の権限を持ったユーザーから送信します。
2. MSG コマンドでメッセージを送付する対象のコンピューターはドメインに参加しているコンピューターとします。
3. メッセージの表示対象は、ログオン中のユーザーとします。

実際複数のコンピューターに対して、MSG コマンドの送信を行う前に、1 台のコンピューターに対して、期待するメッセージが送信できるか確認しましょう。

(1) MSG コマンドの送信確認

ドメイン コントローラーに管理者権限を持つユーザーでログオンし、コマンド プロンプトから、以下のコマンドを実行します。
メッセージの送信対象のコンピューター名は、COMPUTER-001 とします。

msg /server:COMPUTER-001 * this is test message.

COMPUTER-001 にメッセージが表示されない場合には、メッセージを受ける側のコンピューターで以下の内容を確認してください。

[1] レジストリを変更する

1. Win + R キーを押下し、[ファイル名を指定して実行] から “regedit” を実行し、[レジストリ エディター] を起動します。
2. 左側のペインで、以下のレジストリを展開します。
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
3. 右側のペインで [AllowRemoteRPC] をダブル クリックして開き、[値のデータ] を “1” に変更し、[OK] ボタンをクリックして閉じます。(*)
4. [レジストリ エディター] を終了し、コンピューターを再起動します。

(*) 手順: 3 のレジストリが存在しない場合、新規に作成して追加することで同様の動作が可能です。

[2] リモート設定を変更する

1. Win + R キーを押下し、[ファイル名を指定して実行] から “sysdm.cpl” を実行し、[システムの詳細設定] を開きます。
2. [システムの詳細設定] で [リモート] タブをクリックします。
3. [リモート デスクトップ] 枠内で次の設定をチェックします。
   “[ネットワーク レベル認証でリモート デスクトップを実行しているコンピューターからのみ接続を許可する (推奨)]”
4. [OK] ボタンをクリックします。

[3] ファイアウォールを変更する

1. Win + R キーを押下し、[ファイル名を指定して実行] から “wf.msc” を実行し、[セキュリティが強化された Windows ファイアウォール] 画面を開きます。
2. [受信側の規則] の [リモート イベントのログ管理 (NP 受信)] を右クリックし、[規則の有効化] をクリックします。

1台のコンピューターに対し送信できましたら、次は複数のコンピューターに対し送信しましょう。

(2) ドメイン内のすべてのコンピューターでログオンしているユーザーにメッセージを送信する。

PowerShell を用いて、ドメイン コントローラーから、ドメインに参加しているすべてのコンピューター名を取得し、取得したコンピューター名のコンピューターに対して、ブロードキャストでメッセージを送信します。

以下にサンプル スクリプトをご紹介します。
拡張子を .ps1 としてファイルに保存し、管理者として実行します。

foreach($str_name in Get-ADComputer -Filter “*” | Select-Object “Name”){
$prams = “/SERVER:” + $str_name.Name + ” * /TIME:60″
$msg = (Get-Content -Path C:\msg.txt) -join “`r`n”
Start-Process -FilePath msg -ArgumentList $prams, $msg
}

上記のサンプル スクリプトについて、以下のとおり解説します。

Get-ADComputer コマンドレットを用いて、ドメイン内に参加しているすべてのコンピューター名を取得しています。
※ Get-ADComputer のオプションを利用し、検索対象のコンピューターを絞り込むことで、運用上の利便性が上がると思います。
foreach($str_name in Get-ADComputer -Filter “*” | Select-Object “Name”){

/SERVER オプションで、コンピューター名を指定し、/TIME: オプションでメッセージの表示時間を 60 秒間に指定しています。
※ /TIME: で指定するメッセージの表示時間を引数で指定できるように編集すると、運用上の利便性が上がると思います。$prams = $prams = “/SERVER:” + $str_name.Name + ” * /TIME:60″

送信メッセージは、C:\msg.txt に保存されているテキスト ファイルの内容を指定しています。
※ 送信メッセージを保存したファイルのパスを、引数で指定できるように編集すると、運用上の利便性が上がると思います。
$msg = (Get-Content -Path C:\msg.txt) -join “`r`n”

取得したコンピューター名に対して、MSG コマンドでメッセージを送信しています。
Start-Process -FilePath msg -ArgumentList $prams, $msg

補足 1:
PowerShell のスクリプト実行時に以下のようなエラーが表示される場合には、Set-ExecutionPolicy コマンドにて、スクリプトの実行ポリシーを変更してください。

*** スクリプト実行時のエラー
.\<スクリプト名>.ps1 : このシステムではスクリプトの実行が無効になっているため、ファイル <スクリプト ファイルパス> を読み込むことができません。詳細については、「about_Execution_Policies」(http://go.microsoft.com/fwlink/?LinkID=135170) を参照し
てください。
発生場所 行:1 文字:1
+ .\<スクリプト名>.ps1
+ ~~~~~~~~~~
+ CategoryInfo : セキュリティ エラー: (: ) []、PSSecurityException
+ FullyQualifiedErrorId : UnauthorizedAccess

Set-ExecutionPolicy コマンドレットの使用
https://technet.microsoft.com/ja-jp/library/ee176961.aspx

補足 2:
Get-ADComputer コマンドレットのオプションを利用して、用途に合わせたコンピューター検索をご検討いただけます。
以下のコマンド ラインでは、OU 単位でのコンピューター名の検索ができます。

Get-ADComputer -Filter “*” -SearchBase “OU=test_ou,DC=contoso,DC=com” | Select-Object “Name”

Get-ADComputer
https://technet.microsoft.com/en-us/library/ee617192.aspx

今回ご紹介させていただきましたユーザーへのメッセージの送信方法が、管理者様の環境運用の一助となりましたら幸いでございます。

近頃は寒暖の差の激しい季節になって参りました。
みなさまも、体調には十分をお気をつけて、お身体ご自愛ください。

佐々木 俊暢

こんにちは、Windows プラットフォーム サポートの鎌滝です。
今回は、Hyper-V レプリカ機能のフェールオーバーとレプリケーションの反転についてご紹介いたします。

最近、お問い合わせをいただく中で、フェールオーバーは実施されたものの、レプリケーションの反転が行われていない状況を
多数お伺いすることが多いため、本ブログでは、”フェールオーバー” だけでなく、”レプリケーションの反転” についても、
あわせてご紹介させていただきます。

Hyper-V レプリカは、Windows Server 2012 以降の Hyper-V 環境で利用可能となった仮想マシンのレプリケーション ソリューションです。
定期的に仮想マシンのデータのコピーを別の Hyper-V ホストに送信し、業務提供中の Hyper-V ホスト ( プライマリ サーバー ) が災害などで利用できなくなった場合でも、レプリカ サーバーで複製されたデータを利用して仮想マシンを起動し、業務を継続することができます。

このように、Hyper-V レプリカ機能のフェールオーバーは、主に災害対策などの目的で利用される機能のため、
ホスト OS の障害時に自動でフェールオーバーを実行する機能ではありません。
Hyper-V レプリカ機能のフェールオーバーの実行は、人が判断する必要があります。
 
Hyper-V レプリカのフェールオーバーには “計画フェールオーバー” と計画外の”フェールオーバー” の 2 種類があります。
 

計画フェールオーバー

データセンターの計画停電や物理サーバーのメンテナンスなど、計画されたサーバーの停止時に行われるフェールオーバーで、プライマリ サーバーとレプリカ サーバーのどちらも利用可能な状態で行います。
プライマリ サーバーの最新の状態をレプリカ サーバーに送り、データの損失なくフェールオーバーを行うことが可能です。

計画外フェールオーバー

プライマリ サーバーがダウン状態の際に行われるフェールオーバーで、レプリカ サーバーにすでに送られたデータを利用して行います。Hyper-V レプリカでは、複数の回復ポイントを維持することができます。
フェールオーバーの際、どの回復ポイントを利用するかを選択できますが、選択した回復ポイントから現在にいたるまでにプライマリ サーバーで行われた更新は、レプリカ サーバー側に反映されないため、最新の回復ポイントを選択した場合でも、データの損失が発生します。

 
この 2 種類のフェールオーバーのうち、本ブログでは、計画外フェールオーバーと、それに伴うレプリケーションの反転の
具体的な処理内容についてご紹介いたします。
 
計画フェールオーバーについては、Hyper-V レプリカ機能のフェールオーバーとレプリケーションの反転 ( 計画フェールオーバー編 ) をご参照ください。
 
 

Start-VMFailover -VMName $VMName -ComputerName $Replic

(2) 仮想マシンの起動

Start-VM -VMName $VMName -ComputerName $Replica

(3) フェールオーバーの完了

Complete-VMFailover -VMName $VMName -ComputerName $Replica

 
以下は、プライマリ サーバーの復旧後に実施
 
(4) レプリカ モードの反転 (プライマリ サーバー)

Set-VMReplication -VMName $VMName -AsReplica -ComputerName $Primary

(5) レプリケーションの反転

Set-VMReplication -VMName $VMName -Reverse -ReplicaServerName $Primary -ComputerName $Replica

(6) レプリケーションの再開

Start-VMInitialReplication -VMName $VMName -ComputerName $Replica

※ 変数はそれぞれ以下の値を設定します。
　$VMName = フェールオーバー対象の VM 名
　$Primary = プライマリ サーバー名
　$Replica = レプリカ サーバー名

 
 
本操作を GUI で行った場合、レプリカ サーバーにて仮想マシンの右クリックのレプリケーション メニューから、”フェールオーバー” を実行すると、PowerShell コマンドレットの場合の (1) (2) が実行されます。
この時点では、まだ “フェールオーバー” が完了していないため、メニューから “フェールオーバーの取り消し” を実施することができます。
 
しかし、PowerShell コマンドレットの (3) もしくは GUI 操作の “回復ポイントの削除” を実行することで、レプリカ サーバー側で業務提供することが決定されたことになり、フェールオーバーの取り消しを行うことができなくなります。
 
また、フェールオーバー後、レプリケーションの反転を GUI から行った場合、(3) – (6) の操作が実施されます。
このときの注意点として、本操作は 1 つの GUI 操作にて複数の処理を実施する操作であるため、なんらかの原因でレプリケーションの反転に失敗した場合においても、いくつかの操作がすでに実行されている場合があります。
本操作の失敗時には、レプリケーションの反転ウィザードを “キャンセル” する必要がありますが、すでに一部の処理が実行されているため、その後にフェールオーバーの取り消しなどを行った場合でも、レプリケーションの開始に失敗します。
まずは、レプリケーションの反転が失敗した要因を解消してから、再度レプリケーションの反転を行ってください。

これらの操作がすべて完了した時点で、プライマリ サーバーとレプリカ サーバーの役割が入れ替わります。
再度、プライマリ サーバーとレプリカ サーバーの役割を反転させるためには、計画フェールオーバーを実施する必要があります。
計画フェールオーバーについては、Hyper-V レプリカ機能のフェールオーバーとレプリケーションの反転 ( 計画フェールオーバー編 ) にて紹介しておりますので、こちらもご参考としていただければ幸いです。
 
 

こんにちは、Windows プラットフォーム サポートの鎌滝です。
今回は、前回に引き続き、Hyper-V レプリカ機能のフェールオーバーとレプリケーションの反転についてご紹介いたします。
 
Hyper-V レプリカのフェールオーバーには、“計画フェールオーバー” と計画外の”フェールオーバー” の 2 種類があります。
本ブログでは、”計画フェールオーバー” とその反転の具体的な処理内容についてご紹介いたします。
 
なお、Hyper-V レプリカの概要と計画外の “フェールオーバー” については、前回の記事
Hyper-V レプリカ機能のフェールオーバーとレプリケーションの反転 (計画外フェールオーバー編) をご参照ください。
 
 

Stop-VM $VMName -ComputerName $Primary

(2) 計画フェールオーバーの準備 (プライマリ サーバー)

Start-VMFailover -VMName $VMName -ComputerName $Primary -Prepare

(3) 計画フェールオーバーの実行 (レプリカ サーバー)

Start-VMFailover -VMName $VMName -ComputerName $Replica

(4) (オプション) フェールオーバーの完了 (レプリカ サーバー)

Complete-VMFailover -VMName $VMName -ComputerName $Replica

(5) 仮想マシンの起動 (レプリカ サーバー)

Start-VM -VMName $VMName -ComputerName $Replica

(6) レプリケーションの反転 (レプリカ サーバー)

Set-VMReplication -VMName $VMName -Reverse -ReplicaServerName $Primary -ComputerName $Replica

※ 変数はそれぞれ以下の値を設定します。
$VMName = フェールオーバー対象の VM 名
$Primary = プライマリ サーバー名
$Replica = レプリカ サーバー名

 
 
本操作を GUI で実行する場合、まず、GUIもしくはPowerShell コマンドレットで (1) の作業を行ったのち、プライマリ サーバーに仮想マシン上で右クリックし、レプリケーション メニューから、”計画フェールオーバー” を実行してください。
 
その後、(2) (3) (5) (6) の作業は、GUIですべての処理を一括で行うことも、処理の一部を行うことも可能で、
計画フェールオーバーのウィザードのチェック ボックスから、以下のオプションを選択することで、処理工程を選択します。

□ フェールオーバー後にレプリケーションの方向を反転する

本チェック ボックスをオンにした場合は、(6) までの処理が実行されます。

□ フェールオーバー後にレプリカ仮想マシンを起動する

本チェック ボックスをオンにした場合は、(5) までの処理が実行されます。このチェック ボックスは、既定でオンになっています。

全てのチェック ボックスがオフの場合は、(2) (3) の処理のみが実行されます。
 
(4) はオプションであり、実施しない場合でも (6) のレプリケーションの反転 (レプリカ サーバー) を実施した際に、内部で実行されます。
 
計画フェールオーバーのウィザードで、既定通りの処理を実行すると、(2) (3) (5) までの処理が行われます。
そのまま、(6) を実施しなくても、レプリカ サーバー側で業務を提供することは可能ですが、回復ポイントの情報が残されたままとなり、差分仮想ディスク (avhd/avhdx) が作成された状態となります。
万が一、フェールオーバー後、レプリケーションの反転前に、レプリカ サーバー側での稼働が長くなることが予想される場合は、予期せず差分仮想ディスクが大きくなることを防ぐためにも、(4) を行う運用をご検討ください。
ただし、(4) を行った時点で、フェールオーバーの取り消しができなくなる点については、あらかじめご留意ください。
 
既定通りの処理 (2) (3) (5) の場合は、計画フェールオーバーを取り消すことが可能です。
この場合は、プライマリ サーバー側から右クリックのレプリケーション メニューから “計画フェールオーバーの取り消し” 、および、レプリカ サーバー側から右クリックのレプリケーション メニューから “フェールオーバーの取り消し” と、両サーバーで取り消しを行ってください。
 
 

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

[参考情報]
Hyper-V Replica Troubleshooting Guide

こんにちは、Windows Platform サポートです。

Windows (Storage) Server 2016のデータ重複除去機能における、最小経過日数の既定値についてご説明します。

[最小経過日数について]

データ重複除去を有効化する際、何日経過したファイルをデータ重複除去の最適化対象にするかを指定する、最小経過日数の値を入力します。このとき、使用法の種類ごとに、最小経過日数の既定値として想定されている値は、下記のとおりです。

(*)　Windows (Storage) Server 2016で追加されました

上記表のとおり、「仮想化バックアップサーバー」の場合、最小経過日数の既定値は0日となることが想定されています。0日となっている理由は、バックアップデータが格納されたVHDXファイルは、作成後には頻繁に書き換えられることがないため、即座にデータ重複除去を実施しても問題ないためです。

[現象の内容]

掲題の現象について説明します。

Windows (Storage) Server 2016 のサーバーマネージャーにて、ボリュームに対して初めてデータ重複除去の有効化の操作を実施する際、「仮想化バックアップ サーバー」を選択すると、既定値として最小経過日数 = 3日と表示されます。これは前項の想定とは異なる値です。

[現象の原因]

本事象は、サーバーマネージャーにて、初めてデータ重複除去を有効化する際に「仮想化バックアップ サーバー」モードを選択すると、既定では最小経過日数 = 0 日 となることが想定されているところ、それ以外の選択モードである「汎用ファイル サーバー」や「仮想デスクトップ　インフラストラクチャ (VDI) サーバー」と同じく、最小経過日数 = 3 日となっているという、サーバーマネージャーの不具合です。

[現象の対処策]

回避策といたしましては、使用法の種類を 「仮想化バックアップ サーバー」に選択いただいた際には、ファイルの最小経過期間の値を「3」から「0」へと変更いただくことにより、想定された既定値に設定することが可能となります。また、「3」、「0」 以外の任意の値をご指定いただくことも可能です。

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

今回は Hyper-V 環境のホスト OS からの VSS を利用した仮想マシン バックアップ失敗のお話です。
バックアップが仮想マシン内部の VSS Writer の影響で失敗した後、失敗の原因を取り除いたにもかかわらず再度バックアップが失敗する事象についてご紹介いたします。

バックアップ失敗直後の再バックアップが 1 回のみ失敗する事象のため、通常運用で実施している手順でのバックアップが何らかの原因で失敗してしまった後、失敗した原因の対処をしたはずなのに直後のバックアップがまた失敗してしまったとき、もう一度バックアップをリトライすると成功する可能性があります。

このブログを読んでいただいているという状況から、既に対処後のバックアップに失敗した後の可能性も高いと思いますので、次回以降のご参考としていただければ幸いです。

以下に詳細をお伝えいたします。

1. 現象

データベース製品などが稼働している仮想マシン環境では、バックアップ時にバックアップ データの整合性を保つために、VSS Writer を利用してスナップショットが作成されます。

ホスト OS から仮想マシンをバックアップした場合、ホスト OS の Hyper-V VSS Writer から仮想マシン内部の VSS にスナップショットの作成要求が送られ、仮想マシン内部の VSS Writer を利用したスナップショットが作成されます。

何らかの原因により、仮想マシン内部の VSS Writer を利用したスナップショットの取得に失敗し、ホスト OS からの仮想マシン バックアップが異常終了した場合、異常終了後にスナップショットの取得に失敗した原因を取り除いても、次のバックアップに失敗いたします。

ホスト OS のアプリケーションのイベント ログに、以下のログが記録されます。
このログは、初回の仮想マシン内部の VSS Writer の影響で失敗したとき、失敗の原因を取り除いた後のバックアップが失敗したときの両方に記録されます。

なお、2 回目の失敗以降に再度バックアップを取得すると、そのバックアップは成功いたします。

2. 原因

Hyper-V 環境でホスト OS からのバックアップを取得した場合、仮想マシン内の統合サービスの 1 つである vmicvss サービスが仮想マシン内のスナップショット作成処理を行います。

初回の仮想マシン内部の VSS Writer が原因でスナップショットに失敗する場合、vmicvss サービスが呼び出す内部関数内で発行した PrepareForBackup の処理は、VSS Writer がエラー 0x800423f4 を返したことにより、後続のスナップショットの作成処理を行わずに、Hyper-V VSS Writer にもエラー 0x800423f4 が返されます。

その際に PrepareForBackup 中の VSS Writer からエラーが返されるより前の処理により、スナップショットの内部カウント値 (仮想マシン内でスナップショットが作成されるボリューム数のカウンター) がカウント アップされますが、エラー終了時に本カウント値をクリアする処理が存在しないため、本処理の終了後もスナップショットの内部カウント値が維持されます。

その後、失敗の原因を取り除いたのちに、再度バックアップを取得した際に、この残されたスナップショットの内部カウント値を利用し、再度仮想マシン内のボリューム数分カウント アップを行うため、スナップショットの内部カウント値は (仮想マシン内のボリューム数)× 2 となりますが、実際に作成されるスナップショットは仮想マシン内のボリューム数分しか存在しないために、残りの数のボリュームの作成完了を待ち、タイムアウトが発生することが原因で、Hyper-V VSS Writer がエラーとなります。

そのため、VSS を利用したホスト OS からの仮想マシン バックアップ操作も失敗いたします。

なお、PrepareForBackup の処理がスナップショットの作成まで進み、タイムアウトで失敗した場合は、スナップショットの内部カウント値のクリア処理が行われますので、次回以降のバックアップは問題なく取得可能です。

3. 回避策

本事象は、vmicvss サービスが呼び出す PrepareForBackup が仮想マシン内部の VSS Writer のエラーで終了した場合に、スナップショットの内部カウント値のクリアを行わないことが原因となります。

スナップショットの内部カウント値のクリアは vmicvss サービスの再起動でも実施されます。また、仮想マシンの再起動も同様に有効な対処の 1 つとなります。

そのため、仮想マシン内部の VSS Writer が原因でホスト OS からのバックアップが失敗した場合は、次回のバックアップの実行前に以下の手順にて手動で vmicvss サービスの再起動を実施ください。

本手順はバックアップの再実行前に仮想マシン内部より実行します。

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

こんにちは、Windows Platform サポートの眞尾です。

ファイル サーバー リソース マネージャー (FSRM) を使用した環境では、クォータで設定した通知しきい値を超過した場合にレポートを生成することが可能ですが注意点がございます。
今回は、このクォータの通知しきい値を超過した場合のレポート生成設定の注意点についてご案内いたします。

FSRM のクォータ設定では、クォータ上限の 85% などの “通知のしきい値” を超過した場合、クォータ設定されたフォルダーのレポートを生成することが可能です。
生成するレポートとして、以下の 9 種類のレポートを設定時に選択可能です。

• クォータの使用率
• ファイル グループごとのファイル
• ファイル スクリーン処理の監査
• プロパティごとのファイル
• 最近アクセスされていないファイル
• 最近アクセスしたファイル
• 重複しているファイル
• 所有者ごとのファイル
• 大きいサイズのファイル

しかし、[プロパティごとのファイル] のレポートはクォータの “通知のしきい値” を超過した際に生成することができません。
生成するレポートは複数選択可能ですが、[プロパティごとのファイル] を選択した場合、他のレポートの生成も阻害し、選択した全てのレポートが生成されません。
この際以下のエラーが Application イベントログに記録されます。

そのため、”通知のしきい値” を超過した際に生成するレポートには、[プロパティごとのファイル] を選択しないようご注意ください。
(設定時に下図の [プロパティごとのファイル] を選択しないようにご注意ください。)

なお、[プロパティごとのファイル] のレポートは、[記憶域レポートの管理] から設定するスケジュールされたレポート、または [レポートを今すぐ生成する] で生成可能です。

[プロパティごとのファイル] については、クォータの “通知のしきい値” を超過した場合ではなく、定期的なスケジュール実行または手動でレポートを生成ください。

参考情報
====================
▼クォータの “通知のしきい値” からレポートを生成する設定方法は、以下をご参照ください。
クォータ
https://technet.microsoft.com/ja-jp/library/cc730788(v=ws.11).aspx#BKMK_Quotas

クォータのプロパティ
https://technet.microsoft.com/ja-jp/library/cc753326(v=ws.11).aspx

しきい値のプロパティ
https://technet.microsoft.com/ja-jp/library/cc732248(v=ws.11).aspx
([レポート] タブを参照)

▼定期的なスケジュール実行からレポートを生成する設定方法は、以下をご参照ください。
レポートのセットをスケジュールする
https://technet.microsoft.com/ja-jp/library/cc730927(v=ws.11).aspx

▼プロパティごとのファイルのレポートの生成については、以下をご参照ください。
Classifying files based on location and content using the File Classification Infrastructure (FCI) in Windows Server 2008 R2
https://blogs.technet.microsoft.com/filecab/2009/05/11/classifying-files-based-on-location-and-content-using-the-file-classification-infrastructure-fci-in-windows-server-2008-r2/

こんにちは。Windows プラットフォーム サポートの野村です。
 
今回は、Hyper-V クラスター環境において、クラスターに登録した仮想マシンがある特定のノードへ移動できなくなる事象についてご紹介いたします。
 
 
Hyper-V クラスターにおいて、ノード間での仮想マシンの移動は基本的に成功するにも関わらず、ある特定のノードへの移動時のみ失敗してしまう事象が発生したとの報告がございました。

この時、下記のエラーがイベント ログ (System、Microsoft-Windows-Hyper-V-Config-Admin) に記録されます。
 
 

▼補足
上記 Microsoft-Windows-Hyper-V-Config-Admin ログにはイベント ビューアーを開いて、左側ペインにて以下のように展開すれば確認可能です。

[アプリケーションとサービス ログ]
   – [Microsoft]
      – [Windows]
         – [Hyper-V-Config]

 
 
エラー コード 0x43 と 0x80070043 は ERROR_BAD_NET_NAME (ネットワーク名が見つかりません) を意味しており、エラーの内容からも仮想マシンの格納先へのアクセスに問題が生じている状況のように思えます。
 
しかしながら、上記のエラー コードが記録されても、各 Hyper-V クラスターのノードから移動できなかった可能マシンの格納先にアクセスができる場合がございます。(実際に格納先へアクセスできなかった場合は、ネットワークで問題が生じている可能性がございます。)
 
 
この場合は、まず各 Hyper-V クラスターのノードの Hyper-V マネージャーをご確認ください。
もし、複数のノードの Hyper-V マネージャーにて、クラスターに登録されている同一の仮想マシンが確認できた場合、その重複が原因で仮想マシンの移動に失敗している可能性がございます。
 
通常であれば、複数の Hyper-V マネージャーで同一の仮想マシンが表示されることはございません。
 
予期せぬフェールオーバーやシャットダウンで、仮想マシンの移動後に、移動元のノードに仮想マシンの情報が残存してしまう事象が報告されております。この場合、仮想マシンの移動に失敗するとの報告がございます。(下記参考情報をご参照ください。)
 
▼参考情報
– Hyper-V フェールオーバー クラスター環境で VM の移動後に、移動元のノードに VM の情報が残ってしまう
https://blogs.technet.microsoft.com/askcorejp/2015/06/15/hyper-v-vm-2/
 
 
この場合は、該当の仮想マシンが動作していないノードの Hyper-V マネージャーにて、仮想マシンを削除すれば復旧可能でございます。不要な仮想マシンを削除後は、仮想マシンのノード間の移動が可能となったかどうかご確認ください。
(誤って該当の仮想マシンが動作しているノードで削除処理を実行しないよう注意してください。)
 
 
エラー コード 0x43 と 0x80070043 の内容 (ネットワーク名が見つかりません) から、ネットワーク観点での障害が発生したように考えられますが、上述のようにネットワークが要因でなく、不要な仮想マシンの情報が残存している場合がございます。
上記の事象が発生したしましたら、ネットワーク観点だけでなく、念のため各ノードの Hyper-V マネージャーにて、複数のノードで同一の仮想マシンが表示されていないかご確認いただきますようお願いいたします。
 
 
本ブログが皆様のお役に立てれば、幸いでございます。

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

今回は、3rd Party 製の仮想基盤上における Windows OS サポート可否状況についてご紹介いたします。

多くのユーザー様にて、多様なベンダー様の仮想基盤上で弊社の OS をご利用いただいておられます。各仮想基盤上への環境の導入や移行に際しまして、該当仮想基盤上における OS のサポート状況を確認する必要がございますが、弊社では下記の参考情報に纏めさせていただいております。

下記 URL にアクセスして、左側ペインにある [Products] より、各 OS および各ベンダー様が提供されておられる仮想基盤上におけるサポートの情報を確認することが可能でございます。

▼ 参考情報
– Server Virtualization Validation Program
https://www.windowsservercatalog.com/svvp.aspx?svvppage=svvp.htm

 

3rd Party 製の仮想基盤上における OS のサポート可否決定のプロセスといたしましては、まず各ベンダー様にて対象の OS が問題なく動作可能かどうか十分なテストを実施されます。そして、そのテスト結果を弊社に送付いただき、テスト結果を基に該当の仮想基盤上でのサポート可否につきまして前述の弊社サイトに公開いたします。

その際、下記参考情報に記載があるように、最新 OS が動作確認のテストをクリアすれば、その最新 OS のみならず、それよりも下位のバージョンでMicrosoft がサポートを提供している OS につきましても該当の仮想基盤上にて
サポート対象となります。
(ex. Windows Server 2016 がサポート OS ならば、Window Server 2012 R2、Windows Server 2012、Windows Server 2008 R2 や Windows Server 2008 もサポートされます。)

※ サポート期間内の OS のみでございます (本ブログは 2017 年 3 月 13 日に公開いたしました)。Windows Server 2003 等の既にサポート期限が切れた OS はサポート対象ではございません。

▼ 参考情報
– Server Virtualization Validation Program FAQ
https://www.windowsservercatalog.com/svvp.aspx?svvppage=svvpfaq.htm
—— 抜粋 ——
If a software company validates Windows Server 2012 R2 or later versions of Windows Server, are earlier versions of Windows Server supported?

When a vendor validates their virtualization solution with the latest version of Windows Server, then Windows Server 2012, Windows Server 2008 R2, Windows Server 2008 and subsequent service packs are also supported.
————

なお、各ベンダー様にて、それぞれの仮想基盤のアップグレード等が日進月歩で実施されており、弊社の公開情報では最新のサポート状況が 100% 反映されていない可能性もございます。

念のため、各ベンダー様が提供されておられる各仮想基盤における Windows OS のサポート情報につきましても、ご確認いただくことをお勧めいたします。

本ブログが皆様のお役に立てれば、幸いでございます。

こんにちは、Windows Platform サポートです。

Windows 10 バージョン 1607 環境でシステムのシャットダウンを実行時、explorer.exe が異常終了する可能性がございます。
この際には 次のアプリケーションエラーが表示された後、システムがシャットダウンするという動作となります。

explorer.exe – アプリケーション エラー

< メモリ アドレス > の命令が < メモリ アドレス > のメモリを参照しました。メモリが 「< written 又は read >」になることはできませんでした。
プログラムを終了するには [OK] をクリックしてください

explorer.exe の終了処理では WM_DESTROY メッセージが発行され、保有している様々な資源が開放されます。
現象発生時は複数のスレッドから WM_DESTROY メッセージが発行されますが、その際に想定していないタイミングでメッセージの処理が実行されて explorer.exe がクラッシュします。

本現象は複数のスレッドからのメッセージ発行及び処理のタイミングに依存して発生する
潜在的な explorer.exe の不具合ですが、特定の環境下で発生し、全ての環境で発生する現象ではございません。
また、本現象はシャットダウン処理の過程で 発生しており、データが破損する等のシステムへの影響はございません。

本現象については現在調査中ですので、調査が終了次第、改めてご案内します。

皆さん、こんにちは。

今回は RemoteApp で複数のウィンドウを使用中に、ウィンドウの重なり等が正常に表示されない問題についてご紹介させていただきます。

例えば、クライアントマシン上から見ますと、RemoteApp によるウィンドウ A がアクティブですが、非アクティブ RemoteApp によるウィンドウ B が上に表示されてしまうような問題です。
以下の画像では RemoteApp の IE 2 つのウィンドウがあります。ウィンドウ A (緑枠) が、最小化などのアイコンがアクティブとなっていますが、最小化などのアイコンがグレーアウトしている非アクティブのウィンドウ B (赤枠) が上に表示されています。

このような場合、Alt キー+ Tab キーなどによりウィンドウの表示順を切り替えれば、表示が正常に戻ります。

また、各 OS では以下のような修正が公開されておりますので、適用いただけますと幸いです。
・RemoteApp サーバー側 (Windows Server 2012 R2)
タイトル : RemoteApp のウィンドウが表示されなくなり、Windows 8.1 または Windows Server 2012 R2 のウィンドウ間で切り替えると、画面がちらつく
URL: https://support.microsoft.com/ja-jp/help/3103000/remoteapp-windows-disappear-and-screen-flickers-when-you-switch-between-windows-in-windows-8.1-or-windows-server-2012-r2

・RemoteApp クライアント側 (RDC 8.1)
タイトル: Windows で RemoteApp のウィンドウの背面に印刷設定] ウィンドウが表示されます。
URL: https://support.microsoft.com/ja-jp/help/3036965/printing-preferences-window-appears-behind-a-remoteapp-window-in-windows

・RemoteApp サーバー側 (Windows Server 2012)
タイトル : Windows で、RemoteApp でショートカット メニュー項目上にマウス ポインターを移動するとショートカット メニュー項目がちらつく
URL: https://support.microsoft.com/ja-jp/help/2925336/shortcut-menu-items-flicker-as-you-move-the-mouse-pointer-over-them-in-a-remoteapp-in-windows

・RemoteApp クライアント側 (RDC 8.0)
タイトル : RemoteApp program pop-up window is hidden in Windows
URL: https://support.microsoft.com/ja-jp/help/2964832/remoteapp-program-pop-up-window-is-hidden-in-windows

なお、現時点で Windows Server 2016 でも同様の問題が報告されておりますので、情報のアップデートがありましたら、追記させていただきます。

こんにちは。 Windows デバイス サポート担当です。

本記事では、Windows 10 デバイスで、 起動時にBitLocker の回復パスワードの入力を繰り返し求められ、OS を起動できない場合の復旧手順をご案内します。

＜現象の内容＞

Windows 10 デバイスの起動時に、BitLocker 回復パスワードの入力を求められ、正しい回復パスワードを入力しても、再起動後に再度回復パスワードの入力を求められるため、Windows を起動することができません。

この際、デバイスによっては起動画面が赤くなるなど変化がある場合があります。

＜発生原因＞

BitLocker が有効な状態で、TPM またはセキュア ブートを有効から無効に変更されると、セキュリティ保護のため上記現象が発生します。

＜解決策＞

TPM または セキュア ブートを有効に戻すことで現象が解消し、Windows が起動できるようになります。具体的な方法については、ご利用の端末の操作方法を参照してください。

例えば、当社の Surface 3 デバイスでは、以下の手順で復旧させることができます。

1. BitLocker 回復パスワードの入力画面で、電源ボタンを長押しし、Surface を一度シャットダウンします。
2. 音量ボタン + を押しながら電源ボタンを押して Surface を起動し、Surface ロゴが表示されたら電源ボタンを離します。
3. UEFI メニューが起動したら、Trusted Platform Module (TPM) 及び Secure Boot Control の設定を確認します。
4. Trusted Platform Module (TPM) 及び Secure Boot Control で、 [Disabled] になっているものがある場合は、[Enabled] に変更します。
5. Secure Boot Control の下に Install All Factory Default Keys と表示されている場合は、選択してセキュア ブート キーをインストールします。
6. 設定後、 Exit Setup を選択して UEFI メニューを終了し、Windows が正常に起動することを確認します。

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

今回は VSS Hardware Provider と VSS を利用したバックアップが失敗するお話です。

現在ご利用いただいている環境の中に外部ストレージの機能を利用したバックアップを
実施している環境があるかと思います。

この外部ストレージのバックアップ機能に Windows で提供している VSS と連携した
バックアップ機能もあります。VSS によりデータの静止点を作成し、その静止点のデータを
ストレージの機能でバックアップする機能です。

VSS とストレージの機能を連携するため、各ストレージ ベンダ様から VSS Hardware Provider
と呼ばれるモジュールが提供されています。この VSS Hardware Provider と VSS を利用した
バックアップがファイル システムの不具合により失敗してしまう場合があります。

以下に詳細を記載いたします。

1. 現象
———————————————————————————
VSS Hardware Provider を使用して VSS スナップショットを作成すると、
LUN の無効化処理に失敗し、バックアップ処理が失敗する場合があります。

また、本事象は NTFS でフォーマットされたボリュームにおいて発生しますが、
Cluster Shared Volumes (CSV) を対象としたバックアップ処理で発生しやすいことが確認
できています。

2. 原因
———————————————————————————
ファイル システムの TxF (Transactional NTFS) リソースマネージャの内部処理が
正しく行われないために発生します。

バックアップ処理の中で、VSS スナップショット ボリュームに対するロック処理や
オフライン処理などの制御を行いますが、その過程において TxF リソースマネージャの
内部処理が不正であるため、正しい制御が行えず、バックアップが失敗します。

3. 解決策
———————————————————————————
この問題を解決するための修正プログラムを含んだロールアップ プログラムが提供されています。
以下を適用することにより事象が改善するかご確認いただければと存じます。

文書番号 : 4015550
タイトル : April 18, 2017—KB4015553 (Preview of Monthly Rollup)
https://support.microsoft.com/en-us/help/4015553/windows-8-1-windows-server-2012-r2-update-kb4015553

現時点では Windows Server 2012 R2 のみですが、Windows Server 2016 についても今後提供予定です。

※Windows Server 2016 の修正プログラムについては 2017 年 6 月頃を予定しています。
(2017 年 4 月時点)

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

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

Windows 10 バージョン 1703 において、パスワード変更時のダイアログで、スクロールバーを操作できないという問題が報告されています。

現象の説明

Windows 10 バージョン 1703 において、[Ctrl] – [Alt] – [Del] を押してから、パスワードの変更を選択いただきますと、パスワードの変更画面に遷移しますが、このパスワード変更画面において、パスワード入力ボックスの右側にあるスクロールバーが操作できない問題が確認できております。

スクロールバー自体は表示されるのですが、Thumb パーツ (つまみ) が表示されないため、スクロールバーを操作することができません。
画面解像度によっては、パスワードの確認入力項目まで全ての項目が表示されるため問題ありませんが、画面解像度が小さい場合や、スマートカードをご利用の際は、入力項目が隠れてしまい、項目入力が困難になることがあります。

本現象は Windows 10 バージョン 1703 のみで確認されており、Windows 10 バージョン 1607 以前の OS では確認されておりません。

以下は Windows 10 バージョン 1607 のパスワード変更画面です。

以下は、Windows 10バージョン 1703 のパスワード変更画面です。スクロールバーの操作ができません。

現在の状況

弊社では現在この問題の解決にむけて、調査を進めております。

現象の回避方法

スクロールバーの Thumb パーツ (つまみ) を表示させる方法は確認できておりませんが、各項目の入力自体は可能ですので、Tab キーにより項目を進めていただき、入力いただきますようお願いいたします。

項目を進める場合は Tab キーを押します。
戻る場合は Shift + Tab キーを押します。

本問題に対する修正は、Windows 10 バージョン 1703 に含まれています。また、Windows 10 バージョン 1607 では以下の更新プログラムにて修正済みのため、修正の適用をご検討ください。

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

企業内で Windows 10 をご利用頂いているお客様は最新の Windows 10 の適用に向けて、ドライバーやアプリケーションについて動作の検証などを実施頂いていることかと存じます。
マイクロソフトではセキュリティの観点からも、最新のWindows 10 を利用いただくことをお勧めしますが、ここでは最新の Windows 10 にアップデート後、何らかの事情でいったん以前のバージョンに戻されたい場合に、ご利用頂ける手順についてご紹介いたします。

なお、先日 Windows 10 について、年 2 回 3 月と 9 月を目標に機能アップデートを公開することに変更いたしましたので、合わせてご紹介いたします。

Windows と Office のリリース スケジュールがよりわかりやすくシンプルに
https://blogs.windows.com/japan/2017/04/21/windows-office-align-feature-release-schedules-benefit-customers/

今回は、2017 年 4 月に公開されました Windows 10 Creators Update (バージョン 1703) を例に以前のバージョンの Windows 10 に戻す手順についてご紹介いたします。
Windows 10 Anniversary Update (バージョン 1607) でも有効な手順となります。
アプリやドライバーの検証、社内展開にあたっての検証の際などにご活用いただけると幸いです。

– 注意
最新の Windows 10 から以前の Windows 10 に戻すための条件 (一例) です。
こちらを満たさないと、以前のバージョンの Windows 10 へ戻すことができません。

・ 最新のWindows 10 へアップグレード後 10 日以上経過していないこと。
・ アップグレード後、windows.old フォルダーと $windows.~bt フォルダーの内容がすべて保持されていること。
・ ディスク クリーンアップによって、[以前の Windows のインストール] 、[一時 Windows インストール ファイル] が削除されていないこと。
・ アップグレード後に追加したユーザー アカウントを削除していること。
・ Windows 10 サインインにパスワードを使っていた場合は、そのパスワードを知っていること。

– 手順
1. 画面左下、Windows マークをクリックし、[設定] ボタンをクリックします。

2. [Windows の設定] 画面で、 [更新とセキュリティ] をクリックします。

3. [更新とセキュリティ] 画面で、[回復] をクリックします。

4. [回復] 画面で、以前のバーションの Windows 10 に戻す項目の [開始] をクリックします。

5. [以前のバージョンに戻す理由をお聞かせください] 画面では、戻す理由について入力にご協力お願いします。

6. [更新プログラムをチェックします？] 画面が表示されます。更新プログラムを適用する事で問題が解決する場合もございますので、[更新プログラムのチェック] もご検討ください。

7. [知っておくべきこと] 画面では以前のバージョンの Windows 10 に戻す場合の注意事項が表示されます。

8. [ロックアウトされないようにご注意ください] 画面では、パスワードの警告が表示されます。以前のバージョンの Windows 10 で利用していたパスワードが分かることを確認ください。

9. [このビルドをお試しいただきありがとうございます] 画面が表示されます。これより先に進むと以前のバージョンの Windows 10 に戻すことをキャンセルできなくなります。

10. 以前のバージョンの Windows 10 に戻すための処理が開始されます。このまましばらくお待ちください。

作業完了後以前ご利用頂いておりました、Windows 10 に戻ります。

– 参考情報
“- 注意” の項目に関する条件を満たさない場合以下のような状態となり、環境を維持したまま、以前のバーションの Windows 10 に戻すことは出来ません。
・ [開始] ボタンがグレイアウトする。
・ [以前のバーションの Windows 10 に戻す] の項目自体が表示されない。
・ [以前のバーションの Windows 10 に戻す] を実行後エラーとなる。
(例: $windows.~bt フォルダーが存在しない場合)

これからも Windows 10 をよろしくお願いします。

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

Windows Server 2016 の Get-PhysicalDisk、または Get-StorageEnclosure コマンドレットの実行結果は 物理ディスクのエンクロージャー番号を返しません。この動作は想定された動作となります。

Windows Server 2016 Datacenter で導入された Storage Spaces Direct (S2D) は、
業界標準のサーバーとローカルで接続されているドライブを使用して、従来の SAN や NAS システムよりも低コストで可用性と拡張性が高い記憶域を作成することが可能です。

この Storage Spaces Direct (S2D) では、OS のクラスタリング機能を用いて記憶域スペースがクラスター化されますが、クラスター内の任意のエンクロージャーに関連付けられているエンクロージャー番号はノード間で異なります。
このため、Powershellの Get-PhysicalDisk、Get-StorageEnclosure コマンドレットでは
エンクロージャー番号の結果を返さない動作となるように変更されました。

Windows Server 2016 でエンクロージャー番号を取得する際には以下のコマンドを実行してください。
Get-StorageEnclosureStorageNodeView

コマンド情報、およびについては以下のページをご参照ください。

[参考情報]
Get-StorageEnclosureStorageNodeView
Windows Server 2016 の記憶域スペース ダイレクト