Quantcast
Channel: Ask CORE
Viewing all 590 articles
Browse latest View live

Windows 10 Anniversary Update (1607) へアップグレード後、.NET Framework 3.5を利用するアプリケーションが利用出来ない。

$
0
0

こんにちは、Windows プラットフォームサポートです。
Windows 10 Anniversary Update (1607) をご利用いただきありがとうございます。

Windows 10 Anniversary Update (1607) へのアップデートに伴い、.NET Framework 3.5を利用するアプリケーションが利用出来なくなったとのお問い合わせを頂いております。
今回の Blog では 対処方法についてご紹介させて頂きたいと思います。

– 事象
Windows 10 1511 から Windows 10 Anniversary Update (1607) へアップデートする際に、データやアプリケーションを引き継ぎますが、アップデート時のタイミングによって、.NET Framework 3.5 が引き継がれない事があります。
Windows 10 Anniversary Update (1607) にアップデート後、.NET Framework 3.5 を利用したアプリケーション実行時に、エラーとなったり .NET Framework 3.5 が要求された場合、本事象が発生している可能性が考えられます。

– 対処方法
お手数ではございますが、.NET Framework 3.5 の再有効化を実施くださいますようお願いいたします。

有効化するための 3 つの方法をご紹介いたします。
どの手順をご利用頂いても .NET Framework 3.5 を有効にできます。

コントロール パネルで .NET Framework 3.5 を有効にする
——————————————————————————–
コントロール パネルを使用して自分で .NET Framework 3.5 を有効にできます。
※ このオプションを使用するには、インターネット接続が必要です。

1. キーボードの Windows キー (Windows のロゴ) を押し、「Windows の機能」と入力して、Enter キーを押します。
[Windows の機能の有効化または無効化] ダイアログ ボックスが表示されます。
あるいは、[コントロール パネル] を開き、[プログラム] の項目をクリックし、[プログラムと機能] で [Windows の機能の有効化または無効化] をクリックします。

netfx3

2. .NET Framework 3.5 (.NET 2.0 および 3.0 を含む) チェック ボックスをオンにして [OK] をクリックし、メッセージが表示された場合はコンピューターを再起動します。

Dism コマンドで .NET Framework 3.5 を有効にする
——————————
Dism /online /enable-feature /featurename:NetFx3 /All
※ このオプションを使用するには、インターネット接続が必要です。

dismnetfx

PowerShell コマンドレットで .NET Framework 3.5 を有効にする
——————————
Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 –All
※ このオプションを使用するには、インターネット接続が必要です。

psnetfx

– 参考情報
Windows 8、Windows 8.1、および Windows 10 への .NET Framework 3.5 のインストール
https://msdn.microsoft.com/ja-jp/library/hh506443(v=vs.110).aspx

– 補足
Windows 10 Anniversary Update (1607) 公開後約 5ヶ月が経過し、先日 Current Branch for Business(CBB)の公開が宣言されました。
今月 (2017年 1月) 中に Windows Update から提供される予定となっております。
※ Windows Server Update Services (WSUS) をご利用の場合は、WSUS の設定によります。
– 参考情報
Windows 10 1607 is now a Current Branch for Business (CBB) release
https://blogs.technet.microsoft.com/windowsitpro/2016/11/29/windows-10-1607-is-now-a-current-branch-for-business-cbb-release/


Hyper-V 拡張セッションを使用した際の注意点について

$
0
0

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

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

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

blogimage4

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

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

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 10 Anniversary Update (1607) へアップグレード後、.NET Framework 3.5を利用するアプリケーションが利用出来ない。

$
0
0

こんにちは、Windows プラットフォームサポートです。
Windows 10 Anniversary Update (1607) をご利用いただきありがとうございます。

Windows 10 Anniversary Update (1607) へのアップデートに伴い、.NET Framework 3.5を利用するアプリケーションが利用出来なくなったとのお問い合わせを頂いております。
今回の Blog では 対処方法についてご紹介させて頂きたいと思います。

– 事象
Windows 10 1511 から Windows 10 Anniversary Update (1607) へアップデートする際に、データやアプリケーションを引き継ぎますが、アップデート時のタイミングによって、.NET Framework 3.5 が引き継がれない事があります。
Windows 10 Anniversary Update (1607) にアップデート後、.NET Framework 3.5 を利用したアプリケーション実行時に、エラーとなったり .NET Framework 3.5 が要求された場合、本事象が発生している可能性が考えられます。

– 対処方法
お手数ではございますが、.NET Framework 3.5 の再有効化を実施くださいますようお願いいたします。

有効化するための 3 つの方法をご紹介いたします。
どの手順をご利用頂いても .NET Framework 3.5 を有効にできます。

コントロール パネルで .NET Framework 3.5 を有効にする
——————————————————————————–
コントロール パネルを使用して自分で .NET Framework 3.5 を有効にできます。
※ このオプションを使用するには、インターネット接続が必要です。

1. キーボードの Windows キー (Windows のロゴ) を押し、「Windows の機能」と入力して、Enter キーを押します。
[Windows の機能の有効化または無効化] ダイアログ ボックスが表示されます。
あるいは、[コントロール パネル] を開き、[プログラム] の項目をクリックし、[プログラムと機能] で [Windows の機能の有効化または無効化] をクリックします。

netfx3

2. .NET Framework 3.5 (.NET 2.0 および 3.0 を含む) チェック ボックスをオンにして [OK] をクリックし、メッセージが表示された場合はコンピューターを再起動します。

Dism コマンドで .NET Framework 3.5 を有効にする
——————————
Dism /online /enable-feature /featurename:NetFx3 /All
※ このオプションを使用するには、インターネット接続が必要です。

dismnetfx

PowerShell コマンドレットで .NET Framework 3.5 を有効にする
——————————
Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 –All
※ このオプションを使用するには、インターネット接続が必要です。

psnetfx

– 参考情報
Windows 8、Windows 8.1、および Windows 10 への .NET Framework 3.5 のインストール
https://msdn.microsoft.com/ja-jp/library/hh506443(v=vs.110).aspx

– 補足
Windows 10 Anniversary Update (1607) 公開後約 5ヶ月が経過し、先日 Current Branch for Business(CBB)の公開が宣言されました。
今月 (2017年 1月) 中に Windows Update から提供される予定となっております。
※ Windows Server Update Services (WSUS) をご利用の場合は、WSUS の設定によります。
– 参考情報
Windows 10 1607 is now a Current Branch for Business (CBB) release
https://blogs.technet.microsoft.com/windowsitpro/2016/11/29/windows-10-1607-is-now-a-current-branch-for-business-cbb-release/

マスター イメージ作成時の更新の適用について

$
0
0

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

今回は、Windows 10 の環境でマスター イメージを作成する際の注意点として、累積的な更新プログラムの適用について記載いたします。

Windows 10 では弊社にお寄せいただく多数のお問い合せやご要望をもとに、様々なモジュールに修正を行い、その内容を適時 累積的な更新プログラムとして公開しております。
そのため、展開用のマスター イメージを作成いただく際には、まずはその時点の最新の累積的な更新プログラムを適用いただくことを強く推奨いたします。

モジュールを最新の状態に更新いただいた上で、カスタム イメージの作成や Sysprep の実行など、展開に必要な作業を実施いただくことで、累積的な更新プログラムで改善されている既知の問題をあらかじめ回避することが可能です。

なお、累積的な更新プログラムに含まれている品質向上の概要につきましては、以下の更新履歴をご参照ください。

Windows 10 および Windows Server 2016 の更新履歴
https://support.microsoft.com/ja-jp/help/12387/windows-10-update-history

また更新履歴では詳細に触れられていませんが、例えば 2016 年 9 月 に公開しました累積的な更新プログラムにおいては、マスター イメージの作成時の手順に起因して、イメージの展開後にスタート メニューを開けなくなるなど、展開時に特有の問題についての更新も含まれています。
上述のような問題の発生を避けるためにも、出来る限り、最新の累積的な更新プログラムを適用した形での検証、作業を実施してください。

注意事項

・Windows 10 のアップグレード

マスター イメージ作成時には、上記のように更新プログラムを適用いただきたいところですが、Windows 10 のバージョンが変更されるような機能更新 (アップグレード) を適用後の Sysprep の実施は推奨ではありません。

2015 年 11 月に公開されました Windows 10 (バージョン 1511) や、2016 年 8 月に公開されました Windows 10 (バージョン 1607) のマスター イメージを作成する場合には、それ以前のバージョンからのアップグレードは行わず、展開予定のバージョンのインストール メディアからのインストールを行った上で、累積的な更新プログラムの適用をご検討ください。

・インターネット接続について

Windows 10 (バージョン 1511) においてはインターネット接続をするとユーザーごとのストア アプリがインストール、更新され、その後の Sysprep 実行時に問題が発生する場合がありますので、ご注意ください。

Windows 10 (バージョン 1511) における Sysprep 実行時の注意点
https://blogs.technet.microsoft.com/askcorejp/2015/12/20/windows-10-1511-sysprep/

参考情報

Windows 7 や Windows 8.1 につきましても同様です。

Windows 7 SP1 および Windows Server 2008 R2 SP1 の更新履歴
https://support.microsoft.com/ja-jp/help/22801/windows-7-and-windows-server-2008-r2-update-history

Windows 8.1 および Windows Server 2012 R2 の更新履歴
https://support.microsoft.com/ja-jp/help/24717/windows-8-1-windows-server-2012-r2-update-history

Windows Server 2012 の更新履歴
https://support.microsoft.com/ja-jp/help/22811/windows-server-2012-update-history

Windows 10 Anniversary Update (1607) へアップグレード後、.NET Framework 3.5を利用するアプリケーションが利用出来ない。

$
0
0

こんにちは、Windows プラットフォームサポートです。
Windows 10 Anniversary Update (1607) をご利用いただきありがとうございます。

Windows 10 Anniversary Update (1607) へのアップデートに伴い、.NET Framework 3.5を利用するアプリケーションが利用出来なくなったとのお問い合わせを頂いております。
今回の Blog では 対処方法についてご紹介させて頂きたいと思います。

– 事象
Windows 10 1511 から Windows 10 Anniversary Update (1607) へアップデートする際に、データやアプリケーションを引き継ぎますが、アップデート時のタイミングによって、.NET Framework 3.5 が引き継がれない事があります。
Windows 10 Anniversary Update (1607) にアップデート後、.NET Framework 3.5 を利用したアプリケーション実行時に、エラーとなったり .NET Framework 3.5 が要求された場合、本事象が発生している可能性が考えられます。

– 対処方法
お手数ではございますが、.NET Framework 3.5 の再有効化を実施くださいますようお願いいたします。

有効化するための 3 つの方法をご紹介いたします。
どの手順をご利用頂いても .NET Framework 3.5 を有効にできます。

コントロール パネルで .NET Framework 3.5 を有効にする
——————————————————————————–
コントロール パネルを使用して自分で .NET Framework 3.5 を有効にできます。
※ このオプションを使用するには、インターネット接続が必要です。

1. キーボードの Windows キー (Windows のロゴ) を押し、「Windows の機能」と入力して、Enter キーを押します。
[Windows の機能の有効化または無効化] ダイアログ ボックスが表示されます。
あるいは、[コントロール パネル] を開き、[プログラム] の項目をクリックし、[プログラムと機能] で [Windows の機能の有効化または無効化] をクリックします。

netfx3

2. .NET Framework 3.5 (.NET 2.0 および 3.0 を含む) チェック ボックスをオンにして [OK] をクリックし、メッセージが表示された場合はコンピューターを再起動します。

Dism コマンドで .NET Framework 3.5 を有効にする
——————————
Dism /online /enable-feature /featurename:NetFx3 /All
※ このオプションを使用するには、インターネット接続が必要です。

dismnetfx

PowerShell コマンドレットで .NET Framework 3.5 を有効にする
——————————
Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 –All
※ このオプションを使用するには、インターネット接続が必要です。

psnetfx

– 参考情報
Windows 8、Windows 8.1、および Windows 10 への .NET Framework 3.5 のインストール
https://msdn.microsoft.com/ja-jp/library/hh506443(v=vs.110).aspx

– 補足
Windows 10 Anniversary Update (1607) 公開後約 5ヶ月が経過し、先日 Current Branch for Business(CBB)の公開が宣言されました。
今月 (2017年 1月) 中に Windows Update から提供される予定となっております。
※ Windows Server Update Services (WSUS) をご利用の場合は、WSUS の設定によります。
– 参考情報
Windows 10 1607 is now a Current Branch for Business (CBB) release
https://blogs.technet.microsoft.com/windowsitpro/2016/11/29/windows-10-1607-is-now-a-current-branch-for-business-cbb-release/

リモート デスクトップ サービス環境で使用するポートについて

$
0
0

皆さん、こんにちは。
今回は Windows Server 2012、Windows Server 2012 R2、Windows Server 2016 における、リモート デスクトップ サービス (セッション ベースと仮想マシン ベース (VDI)) で使用するポートについてご紹介します。

最近では、セキュリティ対策の一環として、ファイアウォールにて通信に使用するポートを制限されている環境も多いのではないでしょうか。
リモート デスクトップ サービスをお使いいただいている場合、どのポートを制限すればいいのか、お悩みの方もいらっしゃるかと思います。

リモート デスクトップ サービスでは、クライアント PC から接続を行う際に、既定で 3389 のポートを使用します。
それ以外にも、リモート デスクトップ サービスは複数の役割サービスにより構成されており、各コンポーネント間でも様々な通信を行っています。また、その通信の目的によって使用されるポートが異なります。

以下に表形式で、コンポーネント毎に受信に使用するポートとその目的について記載しております。
ぜひリモート デスクトップ サービスの構成の際に、ご参考にしていただければと思います。

(※ 構築の前提条件といたしまして、対象サーバーが Active Directory に参加している環境としています。)

architecture_rds

 

各役割サーバー間の通信で使用されるポート

各役割サーバー間の通信は、その目的によって使用するポートが異なります。役割ごとの使用するポートの一覧は以下の通りです。

RD 接続ブローカー 

発信

受信

サービス

ポート番号

目的

クライアント

RD 接続ブローカー

RDP

TCP|UDP : 3389 *1*2
標準の RDP のポートです。

RD Web アクセス

RD 接続ブローカー

Windows RPC

TCP : 5504 RD Web アクセスが RD 接続ブローカーから情報を取得するために使用します。

RD セッション ホスト

RD 接続ブローカー

Windows RPC

TCP : 135 RD セッションホストが、どのコレクションに参加しているか確認をするため、RPC での接続を行います。

Windows RPC

TCP :

49152 – 65535

(ランダム)

RPC 通信によりバインドされた一時ポートとして使用します。

RD 仮想化ホスト

RD 接続ブローカー

Windows RPC

TCP : 135 RD 仮想化ホスト環境にて、リモート デスクトップ サービスを構成する際に使用します。

Windows RPC

TCP :

49152 – 65535

(ランダム)

RPC 通信によりバインドされた一時ポートとして使用します。

RD ゲートウェイ

RD 接続ブローカー

RDP

TCP|UDP : 3389 *1*2
クライアントからの接続の際に使用します。

RD 接続ブローカー

WinRM

TCP : 5985

サーバー マネージャーや PowerShell 管理をするために使用します。

* 1 ホスト側にて、別のポート番号を設定することも可能です。
(Mac のリモート デスクトップ接続クライアントは、ポート 3389 のみをサポートします。)

* 2 リモート デスクトップ接続 (RemoteApp 含む) で、UDP : 3389 (受信側が RD ゲートウェイの場合はUDP : 3391)のポートが使用される通信につきましては、主に動画の再生など、画面処理が多く実施される場合となります。
既定では TCP と UDP の両方が有効になっており、接続品質やコンテンツの種類に応じて最適なトランスポートが自動選択されます。

RD Web アクセス 

発信

受信

サービス

ポート番号

目的

クライアント

RD Web アクセス

HTTPS(SSL)

TCP : 443 クライアントから RD Web アクセスのサイトにアクセスするために使用します。

RD Web アクセス

WinRM

TCP : 5985 サーバー マネージャーや PowerShell 管理のために使用します。
RD セッション ホスト 

発信

受信

サービス

ポート番号

目的

クライアント

RD セッション ホスト

RDP

TCP|UDP : 3389 *1*2
標準の RDP のポートです。

RD 接続ブローカー

RD セッション ホスト

RDP

TCP : 3389 リモート デスクトップ サービスまたは RemoteApp アプリケーションの画面や操作の通信を行うために使用します。

RDP

TCP : 3389 リモート デスクトップ サービスまたは RemoteApp アプリケーションの画面や操作の通信を行うために使用します。

Windows RPC

TCP : 135 RD セッションホストの死活監視のために使用します。

Windows RPC

TCP :

49152 – 65535

(ランダム)

RPC 通信によりバインドされた一時ポートとして使用します

SMB

TCP : 445 RemoteApp で公開するアプリケーションを指定する際に使用します。

(RD接続ブローカー以外のサーバー マネージャーで管理する場合、発信はそのサーバーとなります。)

RD ゲートウェイ

RD セッション ホスト

RDP

TCP|UDP : 3389 *1*2
RD ゲートウェイを経由したリモート接続を行う際に、リモート デスクトップ サービスまたは RemoteApp アプリケーションの画面や操作の通信を行うために使用します。

RD セッション ホスト

WinRM

TCP : 5985

サーバー マネージャーや Windows PowerShell 管理をするために使用します。

* 1 ホスト側にて、別のポート番号を設定することも可能です。
(Mac のリモート デスクトップ接続クライアントは、ポート 3389 のみをサポートします。)

* 2 リモート デスクトップ接続 (RemoteApp 含む) で、UDP : 3389 (受信側が RD ゲートウェイの場合はUDP : 3391)のポートが使用される通信につきましては、主に動画の再生など、画面処理が多く実施される場合となります。
既定では TCP と UDP の両方が有効になっており、接続品質やコンテンツの種類に応じて最適なトランスポートが自動選択されます。

RD 仮想化ホスト

発信

受信

アプリケーション プロトコル

ポート番号

目的

RD 接続ブローカー

RD 仮想化ホスト

SMB

TCP : 445 リモート デスクトップ仮想化ホスト エージェントを名前付きパイプ経由でリモート管理するために使用します。

Windows RPC

TCP : 135 リモート デスクトップ仮想化ホスト エージェントの管理のために使用されます。

Windows RPC

TCP :

49152 – 65535

(ランダム)

RPC 通信によりバインドされた一時ポートとして使用します。

RD 仮想化ホスト

WinRM

TCP : 5985

サーバー マネージャーや Windows PowerShell 管理をするために使用します。

RD ライセンス

発信

受信

アプリケーション プロトコル

ポート番号

目的

RD セッション ホスト

/ RD 仮想化ホスト

RD ライセンス

SMB

TCP : 445 クライアントの CAL を取得するために使用します

Windows RPC

TCP : 135 RD ライセンス診断のために RPC を使用します。

Windows RPC

TCP :

49152 – 65535

(ランダム)

RD ライセンス診断のために RPC を使用した際に、バインドされた一時ポートとして使用します

RD ライセンス

WinRM

TCP : 5985

サーバー マネージャーや PowerShell 管理のために使用します。

* RD ライセンス サーバーでは、主に RDS CAL の発行や、管理のために上記のポートを使用しています。

RD ゲートウェイ

発信

受信

アプリケーション プロトコル

ポート番号

目的

クライアント

RD ゲートウェイ

HTTPS(SSL)

TCP : 443 リモート デスクトップ サービス、または、RemoteApp アプリケーションの画面や操作の通信を行うために使用します。

RDP

UDP : 3391 *2*3
リモート デスクトップ、または、RemoteApp アプリケーションの画面や操作の UDP 通信を行うために使用します。

RD ゲートウェイ

WinRM

TCP : 5985 サーバー マネージャーや PowerShell 管理のために使用します

* 2 リモート デスクトップ接続 (RemoteApp 含む) で、UDP : 3389 (受信側が RD ゲートウェイの場合はUDP :
3391)のポートが使用される通信につきましては、主に動画の再生など、画面処理が多く実施される場合となります。
既定では TCP と UDP の両方が有効になっており、接続品質やコンテンツの種類に応じて最適なトランスポートが自動選択されます。

* 3 必須ではありません。

ファイルサーバー (ユーザー プロファイル ディスクを使用される場合)

発信

受信

アプリケーション プロトコル

ポート番号

目的

RD 接続ブローカー

ファイル サーバー

Windows RPC

TCP :

135

ユーザー プロファイル ディスクの設定時に “UVHD-template.vhdx” を作成するために使用します。

また、初回ログオン時にログオンしたユーザーの VHD ファイルを作成するために使用します。

Windows RPC

TCP :

49152 – 65535

(ランダム)

NetBIOS

TCP|UDP :

137 – 139

SMB

TCP : 445

RD セッション ホスト

ファイル サーバー

SMB

TCP : 445 既にプロファイルが作成されているユーザーがログオンし、VHD をマウント、ファイルの書き込み、アンマウントするために使用します。

仮想マシン

ファイル サーバー

SMB

TCP : 445 既にプロファイルが作成されているユーザーがログオンし、VHD をマウント、ファイルの書き込み、アンマウントするために使用します。
SQL Server

発信

受信

アプリケーション プロトコル

ポート番号

目的

RD 接続ブローカー

SQL Server (また、Azure SQL Database*)

TDS

TCP|UDP : 1433 RD 接続ブローカーのデータベース用に SQL Server (または、Azure SQL Database) を使用する場合に本ポートを使用します。

* Windows Server 2016 から使用できます。

また、各役割サーバーと Active Directory ドメイン コントローラー サーバー(DC)間の通信にも、サービスに応じたポートが必要です。
詳細は下記の弊社の公開情報をご参照ください。

ドメイン環境で使用されるポートについて

Microsoft サポート情報採取ツール (MSDT) の実行を行う際に 0x800B010A が発生する場合の対処方法について

$
0
0

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

今回は Windows Server 2008 R2 環境にて Microsoft サポート情報採取ツール (MSDT) の実行を行う際に 0x800B010A が発生する場合の対処方法についてご紹介いたします。

MSDT の詳細につきましては以下を参照ください。

マイクロソフト サポート診断パッケージについて

 

具体的な現象


Windows Server 2008 R2 環境にて Microsoft サポート情報採取ツール (MSDT) の実行を行う際に、以下の画像のようにエラー 0x800B010A が発生し、MSDT の実行に失敗します。

blog_0127

 

原因


Windows Update が行われていない環境などでは Microsoft Certificate Authority 2011 の証明書が存在しないため、MSDT の実行に失敗してしまいます。

 

解決策


Microsoft Certificate Authority 2011 証明書を MSDT を実行するマシンにインストールします。
※ 再起動は不要です。

1. 以下より、証明書 (MicrosoftRootCertificateAuthority2011.cer) をダウンロードします。
http://go.microsoft.com/fwlink/?LinkID=747875&clcid=0x409

2. 証明書 (MicrosoftRootCertificateAuthority2011.cer) を対象のマシンにコピーします。

3. 管理者にてログオンし、[スタート] -> [プログラムとファイルの検索] -> [certmgr.msc] を起動します。

blog02_0127

 

4. [信頼されたルート証明機関] を選択し、右クリックし、[すべてのタスク] -> [インポート] をクリックし “証明書のインポート ウィザード” を起動します。

blog03_0127

 

5. “証明書のインポート ウィザード” にてインポートするファイルにコピーした “MicrosoftRootCertificateAuthority2011.cer” を指定して [次へ] をクリックします。

blog04_0127

 

6. [証明書をすべての次のストアに配置する] にチェックがついていることを確認し [次へ] をクリックして進みます。

blog05_0127

 

7. “証明書のインポート ウィザードの完了” 画面にて以下の内容が表示されていることを確認して [完了] をクリックします。

——————————————————————
ユーザーが選択した証明書ストア: 信頼されたルート証明機関
内容: 証明書
ファイル名: MicrosoftRootCertificateAuthority2011.cer のパス名
——————————————————————

blog06_0127

 

8. セキュリティ警告のポップアップが表示されましたら、Thumbprint (拇印) が以下の内容であることを確認して [はい] をクリックします。

——————————————————————
Thumbprint (拇印): 8f43288a d272f310 3b6fb142 8485ea30 14c0bcfe
——————————————————————

blog08_0127

 

9. “正しくインポートされました。” というポップアップが表示されることを確認します。

blog07_0127

 

10. certmgr.msc の [信頼されたルート証明機関] の [証明書] に Microsoft Root Certificate Authority 2011 がインストールされていることを確認します。

blog09_0127

 
11. MSDT を実行し、ログが採取できることを確認します。

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

“Network List Service”が無効化されているとタスク スケジューラの管理コンソールでエラーが発生します

$
0
0

こんにちは。
Windows Platform サポートの丸山です。

本日は、タスク スケジューラーの管理コンソールで表示されるエラーの件について、ご紹介いたします。

■ 発生する事象について

Windows Vista や Windows Server 2008 以降の OS では、ネットワークの場所の管理のため、”Network List Service” というサービスが動作しておりますが、”Network List service” が無効化されている環境では、タスク スケジューラの管理コンソール画面で、タスクの条件を表示しようとすると、タスク スケジューラの管理コンソール画面にてエラーが発生し、スナップインがアンロードされてしまいます。

20161215a図:”Network List service” が無効化されている様子

20161215b図:タスク スケジューラの管理コンソールのエラー画面 (1)

20161215c図:タスク スケジューラの管理コンソールのエラー画面 (2)

20161215d図:タスク スケジューラの管理コンソールのエラー画面 (3)

■ 事象の回避策について

本事象は、”Network List Service” が無効化されており、”条件” タブの内容を表示するための情報の取得が失敗することで発生します。
“Network List Service” が無効化されている状況は、非推奨の状態となりますため、”Network List Service” のスタートアップの種類を “手動” または “自動” に変更してください。

20161215e図:”Network List service” のスタートアップの種類

寒い日が続きますので、風邪をひかぬよう、お気を付けください。
それではまた。


丸山 健一 (マルヤマ ケンイチ)
Windows プラットフォームサポート担当
日本マイクロソフト株式会社


MSGコマンドを利用してドメイン内のすべてのコンピューターにログオン中のユーザーへメッセージを送信する

$
0
0

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

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

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

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

img2

※ 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 (Storage) Server 2016をインストールして起動すると、サーバー マネージャーにDownloaded Maps Manager サービスの警告が表示される。

$
0
0

 

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

Windows (Storage) Server 2016 をインストール後、サーバー マネージャーのダッシュボード警告があるサービスとして、[Downloaded Maps Manager] が表示される事象について、ご紹介します。

 

[現象の内容]

サーバー マネージャーのダッシュボードに、赤色で警告が表示され、詳細として以下のように表示されます。

111

 

[現象の原因]

サーバー マネージャーでは、スタートアップの種類が [自動] または [自動 (遅延開始)] となっているサービスのうち、停止しているサービスがあると警告を表示します。

Downloaded Maps Managerサービスは、自動で開始した後、10 秒以内にこのサービスを利用するアプリケーションがない場合は自動的に停止するため、この停止に伴い警告が表示されます。

 

[現象の対処策]

この警告が表示されないようにするには、以下の手順で、サーバー マネージャー上の監視対象から Downloaded Maps Manager サービスを除外するか、サービスのスタートアップの種類を変更して自動で起動しないようにします。

 

—- (A) サーバー マネージャーの監視対象から外す方法

サービスの詳細画面で、監視する対象のサービスから Downloaded Maps Manager のチェックを外します。

112

 

—- (B) Downloaded Maps Managerサービスのスタートアップの種類を変更する方法

自動で開始されなくなるため、サーバー マネージャー上の監視対象から外れ、警告は表示されなくなります。ただし、サービスが無効の状態では、アプリケーションから地図へのアクセスはできなくなります。

 

[ファイル名を指定して実行] - [services.msc] - [Downloaded Maps Manager のプロパティ]

 

サービスの状態が [停止] となっていることを確認の上、スタートアップの種類を [無効] に変更します。

113

User Access Logging Service (UALSVC) と Data Sharing Service (DSSVC) を同時に開始できない問題について

$
0
0

こんにちは。
Windows Platform サポートの丸山です。

本日は、User Access Logging Service (UALSVC) または Data Sharing Service (DSSVC) の起動時の問題について、ご紹介します。

※2017/1/30 UPDATE : 本事象については、次期サーバー製品での対応が予定されております。

■ 発生する事象について

Windows Server 2016 には、標準で “User Access Logging service (UALSVC)” と、”Data Sharing Service (DSSVC)” が搭載されています。

20161216a図:User Access Logging Service (UALSVC)

20161216b図:Data Sharing Service (DSSVC)

しかしながら、これらのサービスを両方起動しようとすると、あとから起動しようとしたサービスの起動に失敗することが確認されています。

20161216c図:UALSVC を先に起動した場合

20161216d図:DSSVC を先に起動した場合

また、本問題により、System のイベント ログに以下のようなエラーが記録されることがあります。

20161216e図:エラーのイベントが記録される例

■ 確認されている回避策について

本事象は、UALSVC と DSSVC が内部で利用しているリソースの競合が原因となり、発生する問題です。
以下のコマンドのように、それぞれのサービスを個別のプロセスに分離することで、問題が回避できます。

Sc config ualsvc type= own
Sc config dssvc type= own

20161216f図:サービスの分離を行った場合

本ブログ記事が、少しでもお安に立てますと幸いです。


丸山 健一 (マルヤマ ケンイチ)
Windows プラットフォームサポート担当
日本マイクロソフト株式会社

MSGコマンドを利用してドメイン内のすべてのコンピューターにログオン中のユーザーへメッセージを送信する

$
0
0

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

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

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

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

img2

※ 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 (Storage) Server 2016 で、ネットワーク上のイメージからの回復時の資格情報の入力について

$
0
0
こんにちは、Windows Platform サポートです。 Windows (Storage) Server 2016 環境にて、Windows RE 環境から、ネットワーク上のイメージを指定して回復を行う場合、資格情報の入力の動作が以前のバージョンと異なるとのご申告をいただいております。 本記事では、資格情報の入力に際しての注意点についてご案内します。   [内容] Windows (Storage) Server 2016 環境にて、Windows RE 環境から、ネットワーク上のイメージを指定して回復を行う場合、資格情報の入力ダイアログにおいて、ユーザー名のみを入力した場合、以下のようなエラーが表示されます。   [原因] Windows (Storage) Server 2016 では、資格情報入力ダイアログにおいて、[ドメイン名] は既定で空欄となっており、以前のバージョンと異なりコンピュター名が自動入力された状態ではないため、上記の動作となります。   [回避策] Windows (Storage) Server 2016 では、資格情報入力ダイアログにユーザー名を入力する際、コンピューター名またはドメイン名を含む形で入力してください。 (例) “コンピューター名\ユーザー名” または “ドメイン名\ユーザー名”... Read more

Windows (Storage) Server 2016 で Windows Search サービスをご利用の場合の手順

$
0
0

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

Windows (Storage) Server 2016 では、 Windows Search サービスをご利用いただく際の手順が以前のバージョンから変わっています。

今回は、Windows (Storage) Server 2016 で Windows Search サービスをご利用いただく手順についてご案内します。

 

[内容]

Windows (Storage) Server 2016 にて、サーバー マネージャーの [役割と機能の追加] から [Windows Search サービス] の機能を追加しても、Windows Search サービスのスタートアップの種類が [無効] のままになります。

(なお、 Windows Search サービス自体は、 [役割と機能の追加] から追加しない場合でも、システムに初めからインストールされた状態となっております)

 

[原因]

Windows (Storage) Server 2016 では、[役割と機能の追加] から [Windows Search サービス] を追加した際の動作が変更されているためです。

 

[回避策]

当社では、この動作についての対応を検討中です。

現時点では、Windows (Storage) Server 2016 で Windows Search サービスの機能をご利用になる際は、[役割と機能の追加] を行うのではなく、サービスのスタートアップの種類を [自動 (遅延開始)] に変更いただくことで利用可能になります。

システム ファイルの監査と更新プログラムについて

$
0
0

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

今回はシステム ファイルの監査を設定する際の注意事項についてお伝えします。

[監査の機能]

監査の機能はシステムの動作を追跡するのに有効です。特にオブジェクト アクセスの監査の機能ではファイルやフォルダーへのアクセスについて監査できます。

セキュリティ監査の概要
https://technet.microsoft.com/ja-jp/library/dn319078(v=ws.11).aspx

オブジェクト アクセスの監査
https://technet.microsoft.com/ja-jp/library/mt634187(v=vs.85).aspx

ファイル、フォルダーの監査の機能は、以下の 2 つの設定によってご利用が可能となります。

  1. 監査ポリシーとしての設定
  2. ファイル、フォルダーへの監査の設定

今回のご紹介は項目 2 番のファイル、フォルダーに監査を設定する際の注意事項でございます。

[監査の設定]

通常、デスクトップなどの監査が設定されていない領域にファイルやフォルダーを作成しても監査の設定はなされません。一方、OS を構成するシステム ファイルでは既定で監査の設定が付与されていることが確認できます。

winload

ご利用いただく運用のシナリオによっては OS のシステム ファイルに対して監査の設定に追加、削除などの変更を行う場合がございます。この変更する操作自体は監査の機能のご利用用途としては、適切な内容でございます。

[更新プログラムの適用とその結果]

しかし、更新プログラムの適用によって該当のファイルに対して更新が行われた場合、事前に変更を行った監査の設定が元に戻ることがございます。更新プログラムの適用においては、更新対象となるファイルの情報を引き継ぐように動作いたしません。監査設定を戻すこと自体については意図的に設計された動作ではございませんが、更新プログラムの適用におけるファイルの置き換えなどの処理のため、動作の仕組みより結果的に発生する動作でございます。

[対処方法]

運用上のご要件により監査の設定を厳密に計画の上お使いいただいているお客様におかれましては、システム ファイルへの設定変更を監査の適用例としてご案内させていただいてる次第ではございますが、更新プログラムの適用を契機に監査の設定は復元されますため、更新プログラムの適用後は再度監査の設定を実施いただきますようお願い申し上げます。


Microsoft サポート情報採取ツール (MSDT) の実行を行う際に 0x800B010A が発生する場合の対処方法について

$
0
0

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

今回は Windows Server 2008 R2 環境にて Microsoft サポート情報採取ツール (MSDT) の実行を行う際に 0x800B010A が発生する場合の対処方法についてご紹介いたします。

MSDT の詳細につきましては以下を参照ください。

マイクロソフト サポート診断パッケージについて

 

具体的な現象


Windows Server 2008 R2 環境にて Microsoft サポート情報採取ツール (MSDT) の実行を行う際に、以下の画像のようにエラー 0x800B010A が発生し、MSDT の実行に失敗します。

blog_0127

 

原因


Windows Update が行われていない環境などでは Microsoft Certificate Authority 2011 の証明書が存在しないため、MSDT の実行に失敗してしまいます。

 

解決策


Microsoft Certificate Authority 2011 証明書を MSDT を実行するマシンにインストールします。
※ 再起動は不要です。

1. 以下より、証明書 (MicrosoftRootCertificateAuthority2011.cer) をダウンロードします。
http://go.microsoft.com/fwlink/?LinkID=747875&clcid=0x409

2. 証明書 (MicrosoftRootCertificateAuthority2011.cer) を対象のマシンにコピーします。

3. 管理者にてログオンし、[スタート] -> [プログラムとファイルの検索] -> [certmgr.msc] を起動します。

blog02_0127

 

4. [信頼されたルート証明機関] を選択し、右クリックし、[すべてのタスク] -> [インポート] をクリックし “証明書のインポート ウィザード” を起動します。

blog03_0127

 

5. “証明書のインポート ウィザード” にてインポートするファイルにコピーした “MicrosoftRootCertificateAuthority2011.cer” を指定して [次へ] をクリックします。

blog04_0127

 

6. [証明書をすべての次のストアに配置する] にチェックがついていることを確認し [次へ] をクリックして進みます。

blog05_0127

 

7. “証明書のインポート ウィザードの完了” 画面にて以下の内容が表示されていることを確認して [完了] をクリックします。

——————————————————————
ユーザーが選択した証明書ストア: 信頼されたルート証明機関
内容: 証明書
ファイル名: MicrosoftRootCertificateAuthority2011.cer のパス名
——————————————————————

blog06_0127

 

8. セキュリティ警告のポップアップが表示されましたら、Thumbprint (拇印) が以下の内容であることを確認して [はい] をクリックします。

——————————————————————
Thumbprint (拇印): 8f43288a d272f310 3b6fb142 8485ea30 14c0bcfe
——————————————————————

blog08_0127

 

9. “正しくインポートされました。” というポップアップが表示されることを確認します。

blog07_0127

 

10. certmgr.msc の [信頼されたルート証明機関] の [証明書] に Microsoft Root Certificate Authority 2011 がインストールされていることを確認します。

blog09_0127
11. MSDT を実行し、ログが採取できることを確認します。

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

MSGコマンドを利用してドメイン内のすべてのコンピューターにログオン中のユーザーへメッセージを送信する

$
0
0

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

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

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

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

img2

※ 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

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

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

佐々木 俊暢

ActiveX が自動的に削除されてしまう

$
0
0

こんにちは。Windows プラットフォーム サポートの加藤です。
本日は、 Windows10 において ActiveX が自動的に削除されてしまう現象についてご紹介いたします。

Windows 10 において ActiveX が自動的に削除されてしまう現象は、SilentCleanup タスクが実行されることで発生します。

Windows 8.1 までは、ディスク全体の容量に対して空き容量が 10 % を下回った場合にのみ SilentCleanup タスクが実施されていましたが、
Windows 10 では、ユーザーの利便性を向上させる意図から、システムが idle 状態に移行した場合にも、SilentCleanup タスクが実行されます。

SilentCleanup タスクでクリーンアップ対象となるフォルダは、Downloaded Program Files とTemporary Internet Files です。
ActiveX は、クリーンアップ対象となるフォルダ Downloaded Program Files に、既定でダウンロードされるため、本現象が発生します。
そのため、ActiveX が自動的に削除されてしまう現象は、3 つの方法のいずれかを実施することで、回避することができます。

  1. ActiveX のダウンロード先を変更する
  2. ActiveX のダウンロード先を SilentCleanup タスクのクリーンアップ対象から除外する
  3. SilentCleanup タスクを停止する

以下にて、それぞれの設定手順をご案内いたします。
 
 


1.  ActiveX のダウンロード先を変更する
  1. スタート ボタンを右クリックし、[ファイル名を指定して実行] を選択しウィンドウを表示する。
  2. “regedit” と入力し、[OK] ボタンをクリックする。
  3. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings レジストリのサブ キーを開く。
  4. ActiveXCache の値をダブル クリック。値にあるパスを新しい場所に変更し、[OK] をクリックする。
    ※ Downloaded Program Files と Temporary Internet Files 以外の場所を指定してください。
  5. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ActiveX Cache レジストリの
    サブ キーを開く。
  6. 0 の値をダブル クリック。手順 4 で指定したファイル パスと同じ値に変更し、[OK] をクリックする。
  7. 設定を反映するために IE を再起動する。

< 想定されるデメリット >
ActiveX を参照するアプリケーションがある場合、そのアプリケーションにも、変更後のパスを設定する必要があるかもしれません。
そのため、パスの変更を実施する場合には、ActiveX を参照するアプリケーションの開発元にも、パスの設定について確認をしてください。

 
 


2.  ActiveX のダウンロード先を SilentCleanup タスクのクリーンアップ対象から除外する
  1. コマンド プロンプトを管理者権限で実行する。
  2. 以下のコマンドを実行し、クリーンアップ設定を実施する。

    > cleanmgr /sageset:2

    ※ /sageset はクリーンアップ設定をするオプションで、0 ~ 65535 の保存番号を指定します。(上記例では 2 番)。
    クリーンアップ設定は /sageset で指定した保存番号に対し、削除対象となるフォルダを保存することができます。
    フォルダの選択は、手順 3 で実施します。
  3. 手順 2 の後、ディスク クリーンアップの設定画面が表示されたら、削除されるファイルから [ダウンロードされたプログラム ファイル] のチェックを外し、[OK] を選択する。
  4. タスク スケジューラを起動。
  5. タスク スケジューラの左ペインにある [タスク スケジューラ ライブラリ] より、[Microsoft] -> [Windows] -> [DiskCleanup] の順に選択する。
  6. 画面中央に SilentCleanup タスクが表示されたら、右クリックをし、[プロパティ] を選択する。
  7. プロパティ画面の [操作] タブを選択し、[編集] をクリックする。
  8. 引数の追加欄に、手順 1 で用意したクリーンアップ設定を以下のように指定し、[OK] をクリックする。

    /autoclean /sagerun:2 /d %systemdrive%

    ※ /sagerun は指定した設定番号(上記例では 2 番)を使用し cleanmgr を実行するオプションです。/sagerun で指定した保存番号に設定されたフォルダに対してクリーンアップ処理を実行します。
< 想定されるデメリット >
C:\Windows\Downloaded Program Files 配下の一時ファイル等、不要なファイルが自動的に削除されなくなります。
そのため、ディスク容量が逼迫している場合や一時ファイルの残存を回避したい場合は、定期的に不要なファイルを確認し手動、もしくはバッチ ファイル等でファイルを削除ください。

 
 


3.  SilentCleanup タスクを停止する
  1. コマンド プロンプトを管理者権限で実行する。
  2. 以下のコマンドを実行し、SilentCleanup タスクを無効化する。

    schtasks.exe /change /TN “\Microsoft\Windows\DiskCleanup\SilentCleanup” /Disable

< 想定されるデメリット >
SilentCleanup タスクを無効化した場合は、一時ファイル等、不要なファイルが自動的に削除されなくなります。
そのため、ディスク容量が逼迫している場合や一時ファイルの残存をさせてくない場合は、定期的に不要なファイルを確認し手動、もしくはバッチ ファイル等でファイルを削除ください。

 
 
このブログが皆様のお役に立てれば幸いです。

リモート デスクトップ サービス環境で使用するポートについて

$
0
0

皆さん、こんにちは。
今回は Windows Server 2012、Windows Server 2012 R2、Windows Server 2016 における、リモート デスクトップ サービス (セッション ベースと仮想マシン ベース (VDI)) で使用するポートについてご紹介します。

最近では、セキュリティ対策の一環として、ファイアウォールにて通信に使用するポートを制限されている環境も多いのではないでしょうか。
リモート デスクトップ サービスをお使いいただいている場合、どのポートを制限すればいいのか、お悩みの方もいらっしゃるかと思います。

リモート デスクトップ サービスでは、クライアント PC から接続を行う際に、既定で 3389 のポートを使用します。
それ以外にも、リモート デスクトップ サービスは複数の役割サービスにより構成されており、各コンポーネント間でも様々な通信を行っています。また、その通信の目的によって使用されるポートが異なります。

以下に表形式で、コンポーネント毎に受信に使用するポートとその目的について記載しております。
ぜひリモート デスクトップ サービスの構成の際に、ご参考にしていただければと思います。

(※ 構築の前提条件といたしまして、対象サーバーが Active Directory に参加している環境としています。)

architecture_rds

 

各役割サーバー間の通信で使用されるポート

各役割サーバー間の通信は、その目的によって使用するポートが異なります。役割ごとの使用するポートの一覧は以下の通りです。

RD 接続ブローカー 

発信

受信

サービス

ポート番号

目的

クライアント

RD 接続ブローカー

RDP

TCP|UDP : 3389 *1*2
標準の RDP のポートです。

RD Web アクセス

RD 接続ブローカー

Windows RPC

TCP : 5504 RD Web アクセスが RD 接続ブローカーから情報を取得するために使用します。

RD セッション ホスト

RD 接続ブローカー

Windows RPC

TCP : 135 RD セッションホストが、どのコレクションに参加しているか確認をするため、RPC での接続を行います。

Windows RPC

TCP :

49152 – 65535

(ランダム)

RPC 通信によりバインドされた一時ポートとして使用します。

RD 仮想化ホスト

RD 接続ブローカー

Windows RPC

TCP : 135 RD 仮想化ホスト環境にて、リモート デスクトップ サービスを構成する際に使用します。

Windows RPC

TCP :

49152 – 65535

(ランダム)

RPC 通信によりバインドされた一時ポートとして使用します。

RD ゲートウェイ

RD 接続ブローカー

RDP

TCP|UDP : 3389 *1*2
クライアントからの接続の際に使用します。

RD 接続ブローカー

WinRM

TCP : 5985

サーバー マネージャーや PowerShell 管理をするために使用します。

* 1 ホスト側にて、別のポート番号を設定することも可能です。
(Mac のリモート デスクトップ接続クライアントは、ポート 3389 のみをサポートします。)

* 2 リモート デスクトップ接続 (RemoteApp 含む) で、UDP : 3389 (受信側が RD ゲートウェイの場合はUDP : 3391)のポートが使用される通信につきましては、主に動画の再生など、画面処理が多く実施される場合となります。
既定では TCP と UDP の両方が有効になっており、接続品質やコンテンツの種類に応じて最適なトランスポートが自動選択されます。

RD Web アクセス 

発信

受信

サービス

ポート番号

目的

クライアント

RD Web アクセス

HTTPS(SSL)

TCP : 443 クライアントから RD Web アクセスのサイトにアクセスするために使用します。

RD Web アクセス

WinRM

TCP : 5985 サーバー マネージャーや PowerShell 管理のために使用します。
RD セッション ホスト 

発信

受信

サービス

ポート番号

目的

クライアント

RD セッション ホスト

RDP

TCP|UDP : 3389 *1*2
標準の RDP のポートです。

RD 接続ブローカー

RD セッション ホスト

RDP

TCP : 3389 リモート デスクトップ サービスまたは RemoteApp アプリケーションの画面や操作の通信を行うために使用します。

RDP

TCP : 3389 リモート デスクトップ サービスまたは RemoteApp アプリケーションの画面や操作の通信を行うために使用します。

Windows RPC

TCP : 135 RD セッションホストの死活監視のために使用します。

Windows RPC

TCP :

49152 – 65535

(ランダム)

RPC 通信によりバインドされた一時ポートとして使用します

SMB

TCP : 445 RemoteApp で公開するアプリケーションを指定する際に使用します。

(RD接続ブローカー以外のサーバー マネージャーで管理する場合、発信はそのサーバーとなります。)

RD ゲートウェイ

RD セッション ホスト

RDP

TCP|UDP : 3389 *1*2
RD ゲートウェイを経由したリモート接続を行う際に、リモート デスクトップ サービスまたは RemoteApp アプリケーションの画面や操作の通信を行うために使用します。

RD セッション ホスト

WinRM

TCP : 5985

サーバー マネージャーや Windows PowerShell 管理をするために使用します。

* 1 ホスト側にて、別のポート番号を設定することも可能です。
(Mac のリモート デスクトップ接続クライアントは、ポート 3389 のみをサポートします。)

* 2 リモート デスクトップ接続 (RemoteApp 含む) で、UDP : 3389 (受信側が RD ゲートウェイの場合はUDP : 3391)のポートが使用される通信につきましては、主に動画の再生など、画面処理が多く実施される場合となります。
既定では TCP と UDP の両方が有効になっており、接続品質やコンテンツの種類に応じて最適なトランスポートが自動選択されます。

RD 仮想化ホスト

発信

受信

アプリケーション プロトコル

ポート番号

目的

RD 接続ブローカー

RD 仮想化ホスト

SMB

TCP : 445 リモート デスクトップ仮想化ホスト エージェントを名前付きパイプ経由でリモート管理するために使用します。

Windows RPC

TCP : 135 リモート デスクトップ仮想化ホスト エージェントの管理のために使用されます。

Windows RPC

TCP :

49152 – 65535

(ランダム)

RPC 通信によりバインドされた一時ポートとして使用します。

RD 仮想化ホスト

WinRM

TCP : 5985

サーバー マネージャーや Windows PowerShell 管理をするために使用します。

RD ライセンス

発信

受信

アプリケーション プロトコル

ポート番号

目的

RD セッション ホスト

/ RD 仮想化ホスト

RD ライセンス

SMB

TCP : 445 クライアントの CAL を取得するために使用します

Windows RPC

TCP : 135 RD ライセンス診断のために RPC を使用します。

Windows RPC

TCP :

49152 – 65535

(ランダム)

RD ライセンス診断のために RPC を使用した際に、バインドされた一時ポートとして使用します

RD ライセンス

WinRM

TCP : 5985

サーバー マネージャーや PowerShell 管理のために使用します。

* RD ライセンス サーバーでは、主に RDS CAL の発行や、管理のために上記のポートを使用しています。

RD ゲートウェイ

発信

受信

アプリケーション プロトコル

ポート番号

目的

クライアント

RD ゲートウェイ

HTTPS(SSL)

TCP : 443 リモート デスクトップ サービス、または、RemoteApp アプリケーションの画面や操作の通信を行うために使用します。

RDP

UDP : 3391 *2*3
リモート デスクトップ、または、RemoteApp アプリケーションの画面や操作の UDP 通信を行うために使用します。

RD ゲートウェイ

WinRM

TCP : 5985 サーバー マネージャーや PowerShell 管理のために使用します

* 2 リモート デスクトップ接続 (RemoteApp 含む) で、UDP : 3389 (受信側が RD ゲートウェイの場合はUDP :
3391)のポートが使用される通信につきましては、主に動画の再生など、画面処理が多く実施される場合となります。
既定では TCP と UDP の両方が有効になっており、接続品質やコンテンツの種類に応じて最適なトランスポートが自動選択されます。

* 3 必須ではありません。

ファイルサーバー (ユーザー プロファイル ディスクを使用される場合)

発信

受信

アプリケーション プロトコル

ポート番号

目的

RD 接続ブローカー

ファイル サーバー

Windows RPC

TCP :

135

ユーザー プロファイル ディスクの設定時に “UVHD-template.vhdx” を作成するために使用します。

また、初回ログオン時にログオンしたユーザーの VHD ファイルを作成するために使用します。

Windows RPC

TCP :

49152 – 65535

(ランダム)

NetBIOS

TCP|UDP :

137 – 139

SMB

TCP : 445

RD セッション ホスト

ファイル サーバー

SMB

TCP : 445 既にプロファイルが作成されているユーザーがログオンし、VHD をマウント、ファイルの書き込み、アンマウントするために使用します。

仮想マシン

ファイル サーバー

SMB

TCP : 445 既にプロファイルが作成されているユーザーがログオンし、VHD をマウント、ファイルの書き込み、アンマウントするために使用します。
SQL Server

発信

受信

アプリケーション プロトコル

ポート番号

目的

RD 接続ブローカー

SQL Server (また、Azure SQL Database*)

TDS

TCP|UDP : 1433 RD 接続ブローカーのデータベース用に SQL Server (または、Azure SQL Database) を使用する場合に本ポートを使用します。

* Windows Server 2016 から使用できます。

また、各役割サーバーと Active Directory ドメイン コントローラー サーバー(DC)間の通信にも、サービスに応じたポートが必要です。
詳細は下記の弊社の公開情報をご参照ください。

ドメイン環境で使用されるポートについて

MSGコマンドを利用してドメイン内のすべてのコンピューターにログオン中のユーザーへメッセージを送信する

$
0
0

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

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

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

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

img2

※ 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

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

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

佐々木 俊暢

Viewing all 590 articles
Browse latest View live




Latest Images