Operations Lab.

Windows Server 2016 TP3 の FailoverClusters モジュール

leave a comment »

8/19 に Windows Server 2016 TP3 Build 10514 が公開されました。

FailoverClusters モジュールをロードできるように修復する

Windows Server 2016 TP3 インストール直後の状態では、FailoverClusters モジュールが壊れているため、PowerShell からフェイルオーバークラスターの管理を行う事ができません。Failover Clustering 用のモジュールをロードできるようするには、モジュールファイルを修正する必要があります。

モジュールファイルを修正する PowerShell スクリプトを作成しましたので、載せておきます。ご利用は自己責任で!

ファイルを適当な場所にダウンロードして、管理者権限で実行してください。

Written by kazu

2015/08/24 at 22:09

ネットワークの場所を「プライベート」に変更する

leave a comment »

いつも忘れるのでメモ。

PS C:\> Get-NetConnectionProfile | ? NetworkCategory -eq "Public" | Set-NetConnectionProfile -NetworkCategory "Private"

 

管理者権限に昇格して実行することを忘れずに。

ドメインネットワークは良いとして、ストレージ通信用やハートビート用のネットワークは忘れずに Private へ変更する。

Written by kazu

2015/03/12 at 13:00

ログインユーザーの一覧を表示するワンライナー(PowerShell)

leave a comment »

現在ホストにログインしているアカウント(ドメイン名およびユーザー名)と、ログインタイプ(ログイン方法)を表示するワンライナー。ワンライナーにする必要は全く無いのですが。(コピペしやすい、くらいのメリットしかない。)

Get-CimInstance -ClassName Win32_LoggedOnUser | %{ $o = New-Object PSObject | select Domain,User,LogonType; $o.Domain, $o.User, $o.LogonType = $_.Antecedent.Domain, $_.Antecedent.Name, @{ 0 = "System Reserved (System Account)"; 2 = "Interactive"; 3 = "Network"; 4 = "Batch"; 5 = "Service"; 6 = "Proxy"; 7 = "Unlock"; 8 = "NetworkCleartext"; 9 = "NewCredentials"; 10 = "RemoteInteractive"; 11 = "CachedInteractive"; 12 = "CachedRemoteInteractive"; 13 = "CachedUnlock" }[[int]((Get-CimInstance -ClassName Win32_LogonSession -Filter "LogonId=$($_.Dependent.LogonId)").LogonType)]; $o } | ft * -AutoSize

Domain    User            LogonType
------    ----            ---------
SVVNTP201 SYSTEM          System Reserved (System Account)
SVVNTP201 LOCAL SERVICE   Service
SVVNTP201 NETWORK SERVICE Service
CONTOSO   test01          RemoteInteractive
CONTOSO   test01          Network
CONTOSO   test02          Interactive
CONTOSO   test03          Network
CONTOSO   test03          Network
SVVNTP201 Administrator   RemoteInteractive
SVVNTP201 Administrator   Network
SVVNTP201 Administrator   Network
SVVNTP201 Administrator   Network
SVVNTP201 ANONYMOUS LOGON Network
SVVNTP201 DWM-1           Interactive
SVVNTP201 DWM-2           Interactive
SVVNTP201 DWM-3           Interactive

Interactive は、ローカルから GUI でログインした場合や「別のユーザーとして実行」で cmd.exe 等を起動した場合、RemoteInteractive は RDP(Remote Desktop Service / Terminal Service)、Network はネットワーク経由でのログオン(WinRM を使用した PowerShell Remoting を含む)。

Written by kazu

2015/02/09 at 21:13

PowerShell の $a –eq $b と $b –eq $a は同じ結果とは限らない

leave a comment »

一言で言うと、タイトルの通りなのですが。他の言語を使用している方は、(普段使っている言語によっては)違和感があるかもしれません。

もともと、PowerShell の –eq 演算子は、配列(リスト)に適用したときと値型(Scalar Value)に適用したときで動作が異なります。が、値型同士の比較であっても、結果が異なる場合があります。

PS C:\> $true -eq 10
True
PS C:\> 10 -eq $true
False

$true は bool 型、10 は int 型で、ともに値型ですが、上記の通り異なる結果になります。これは、Boolean や Null ($null)と数値を比較した場合、右側のオペランド(被演算子)が左オペランドの型へ暗黙的にキャストされるためです。ですので、上の例は、以下と同等になります。

PS C:\> [bool]10
True
PS C:\> $true -eq [bool]10
True
PS C:\> [int]$true
1
PS C:\> 10 -eq [int]$true
False

ちなみに、通常の数値型(int や double 等)を –eq 演算子で比較した場合は、左オペランドの型へキャストされるのではなく、左右のオペランドのうち精度の高い型や範囲の広い型へキャストされます。(つまり、必ず左オペランドの型へキャストされるわけではありません。)

PS C:\> 10 -eq 10.1
False
PS C:\> 10.1 -eq 10
False
参考

Written by kazu

2015/01/31 at 11:30

PowerShell で「続行しますか?」に「中断」を選択するとどうなるか

leave a comment »

文字通り「中断」されるのですが、「中断」って何?というお話。

例えば、Enable-PSRemoting コマンドレットをオプションなしで実行すると、以下の通り確認のプロンプトが表示されます。

PS C:\> Enable-PSRemoting

WinRM クイック構成
Windows リモート管理 (WinRM) サービスを使用して、このコンピューターのリモート管理を有効にするコマンド
"Set-WSManQuickConfig" を実行します。
 これには、次の処理が含まれます:
    1. WinRM サービスを開始または (既に開始されている場合は) 再起動します。
    2. WinRM サービスのスタートアップの種類を [自動] に設定します。
    3. どの IP アドレスでも要求を受け付けるリスナーを作成します。
    4. WS-Management トラフィック用の Windows ファイアウォールの受信規則の例外を有効にします (HTTP のみ)。

続行しますか?
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ (既定値は "Y"):

続行する場合は「はい」、続行しない場合(キャンセルする場合)は「いいえ」を選択すればよいのですが、それ以外に「中断」が選択できます。(なお、基本的には「すべて続行」は「すべてはい」、「すべて無視」は「すべていいえ」と同等です。)

「中断」を選択した場合は以下の様になります。

続行しますか?
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ (既定値は "Y"): S
PS C:\>>

一見、「いいえ」と何が違うのかわかりませんが、よく見るとプロンプトの「>」の数が異なります。

実は(と言うほどでもないですが)、「中断」はコマンドの実行を保留したまま、シェルのプロンプトを表示します。(ネストされたシェルを呼び出します。)コマンドの実行は保留されているため、exit でプロンプトから抜けると、先程中断した(選択を保留した)個所から再開されます。

PS C:\>> Get-Service WinRM

Status   Name               DisplayName
------   ----               -----------
Running  WinRM              Windows Remote Management (WS-Manag...


PS C:\>> Get-Item WSMan:\localhost\Client\TrustedHosts


   WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Client

Type            Name                           SourceOfValue   Value
----            ----                           -------------   -----
System.String   TrustedHosts                                   *


PS C:\>> exit

WinRM クイック構成
Windows リモート管理 (WinRM) サービスを使用して、このコンピューターのリモート管理を有効にするコマンド
"Set-WSManQuickConfig" を実行します。
 これには、次の処理が含まれます:
    1. WinRM サービスを開始または (既に開始されている場合は) 再起動します。
    2. WinRM サービスのスタートアップの種類を [自動] に設定します。
    3. どの IP アドレスでも要求を受け付けるリスナーを作成します。
    4. WS-Management トラフィック用の Windows ファイアウォールの受信規則の例外を有効にします (HTTP のみ)。

続行しますか?
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ (既定値は "Y"):

「中断」は、上記の様に、コマンドの実行途中で、選択を一時的に保留し、別のコマンドレットを実行(して状態の確認などを行う)際に使用します。

なお、何度も(ネストされている中でさらに)中断すると、プロンプトの「>」の数が増えていきます。(昔は増えない仕様だった気がするのですが…。)いずれにせよ、何度も中断すると、戻ってきたときにいったい何の処理中だったのか訳が分からなくなるので、複数中断しないほうが良いと思います。

PS C:\> Enable-PSRemoting

WinRM クイック構成
Windows リモート管理 (WinRM) サービスを使用して、このコンピューターのリモート管理を有効にするコマンド
"Set-WSManQuickConfig" を実行します。
 これには、次の処理が含まれます:
    1. WinRM サービスを開始または (既に開始されている場合は) 再起動します。
    2. WinRM サービスのスタートアップの種類を [自動] に設定します。
    3. どの IP アドレスでも要求を受け付けるリスナーを作成します。
    4. WS-Management トラフィック用の Windows ファイアウォールの受信規則の例外を有効にします (HTTP のみ)。

続行しますか?
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ (既定値は "Y"): S
PS C:\>>
PS C:\>> Enable-PSRemoting

確認
この操作を実行しますか?
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ (既定値は "Y"): S
PS C:\>>>
PS C:\>>> Enable-PSRemoting

確認
この操作を実行しますか?
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ (既定値は "Y"): S
PS C:\>>>>
PS C:\>>>> exit

確認
この操作を実行しますか?
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ (既定値は "Y"): L

確認
この操作を実行しますか?
対象 "" に対して操作 "" を実行しています。
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ (既定値は "Y"): L
PS C:\>>> exit

確認
この操作を実行しますか?
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ (既定値は "Y"): L

確認
この操作を実行しますか?
対象 "" に対して操作 "" を実行しています。
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ (既定値は "Y"): L
PS C:\>> exit

WinRM クイック構成
Windows リモート管理 (WinRM) サービスを使用して、このコンピューターのリモート管理を有効にするコマンド
"Set-WSManQuickConfig" を実行します。
 これには、次の処理が含まれます:
    1. WinRM サービスを開始または (既に開始されている場合は) 再起動します。
    2. WinRM サービスのスタートアップの種類を [自動] に設定します。
    3. どの IP アドレスでも要求を受け付けるリスナーを作成します。
    4. WS-Management トラフィック用の Windows ファイアウォールの受信規則の例外を有効にします (HTTP のみ)。

続行しますか?
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ (既定値は "Y"): L

確認
この操作を実行しますか?
対象 "名前: microsoft.powershell SDDL:
O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;RM)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)。選択したユーザーがこのコンピューターに対して
Windows PowerShell コマンドをリモートで実行できるようにします。" に対して操作 "Set-PSSessionConfiguration"
を実行しています。
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ (既定値は "Y"): L
PS C:\>

「いいえ」で一旦処理をキャンセルし、確認後に改めてコマンドを実行してもよい状況であれば、「中断」は使わないほうが良いでしょう。その方が分かりやすく、オペレーションミスの可能性も低くなるはずです。

Written by kazu

2015/01/25 at 21:43

PowerShell でコード署名用の証明書を作成する

with one comment

この Post は PowerShell Advent Calendar 2014 の 12/16 分です。

PowerShell 3.0 からは PKI モジュールに含まれる New-SelfSignedCertificate コマンドレットで自己証明書を作成できるようになりました。検証用証明書の作成に makecert.exe コマンドを利用(用意)しなくてもよくなったため大変便利ですが、New-SelfSignedCertificate で作成した証明書はコード署名には利用できません。

PS C:\> New-SelfSignedCertificate -DnsName test@operationslab.local -CertStoreLocation Cert:\CurrentUser\My

    ディレクトリ: Microsoft.PowerShell.Security\Certificate::CurrentUser\My

Thumbprint                                Subject
----------                                -------
A9E494C41DFD461E94EB3C11790AD11B50F8E5DA  CN=test@operationslab.local

# 自己証明書が作成、保管されます
PS C:\> Get-ChildItem Cert:\CurrentUser\My

    ディレクトリ: Microsoft.PowerShell.Security\Certificate::CurrentUser\My

Thumbprint                                Subject
----------                                -------
A9E494C41DFD461E94EB3C11790AD11B50F8E5DA  CN=test@operationslab.local

# コード署名に利用可能な証明書はありません
PS C:\> Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert
PS C:\>

about_Signing のヘルプ項目には以下のような記述があり、あたかも New-SelfSignedCertificate で新規に作成した証明書を使用して PowerShell スクリプトに署名できそうですが、実際にはできません。これは、証明書の利用用途として「コード署名」が指定されていないためです。

CREATE A SELF-SIGNED CERTIFICATE

——————————–

To create a self-signed certificate in use the New-SelfSignedCertificate cmdlet in the PKI module. This module is introduced in Windows PowerShell 3.0 and is included in Windows 8 and Windows Server 2012. For more information, see the help topic for the New-SelfSignedCertificate cmdlet.

New-SelfSignedCertificate のヘルプを参照すると、以下のパラメータで証明書が構成される旨が記載されています。

  • Subject: Empty
  • Key: RSA 2048
  • EKUs: Client Authentication and Server Authentication
  • Key Usage: Digital Signature, Key Encipherment (a0)
  • Validity Period: One year

このうち、Subject については New-SelfSignedCertificate の DnsName オプションで上書きできますが、その他のパラメータは上書きできません。(CloneCert で複製を行った場合を除きます。)

コード署名を行うためには、EKU(Enhanced Key Usage)に「コード署名(Code Signing)」が含まれている必要があるため、New-SelfSignedCertificate は利用できません。

about_Signing では自己証明書を作成するもう一つの方法として makecert.exe が紹介されていますが、makecert.exe のためだけに Windows SDK をインストールするのは大変手間がかかります。(時間とディスク容量も。)外部コマンドを利用せず証明書を作成する方法はいくつかありますが、COM(Component Object Model)を利用する方法が一番簡単そうでしたので、今回は COM を使います。

※正直、COM は好きではないですが…。開発者ではないのと、レガシー感が払拭できないので…。

以下のコードを実行すると、CurrentUser\My 証明書ストアにコード署名用の証明書が作成されます。(サブジェクトやフレンドり名は適宜読み替えてください。)

# サブジェクト
$subject = "CN=admin@operationslab.local"

# フレンドリ名
$fn = "Operations Lab Code Signing"

# Enhanced Key Usage
# 日本語環境の場合は、日本語又はOIDで指定
# 複数指定する場合は、カンマ区切り(配列)
# $EKU = [Security.Cryptography.Oid[]]("サーバー認証", "クライアント認証")
$eku = [Security.Cryptography.Oid[]]"コード署名"

# Key Usage
# 日本語環境であっても、英語指定
# 複数指定する場合は、カンマ区切りの文字列
$ku = [Security.Cryptography.X509Certificates.X509KeyUsageFlags]"KeyEncipherment, DigitalSignature"

# 有効期限
# NotBefore
$start = [DateTime]::Now.AddDays(-1)
# NotAfter
$end = $start.AddYears(1)


# アルゴリズムと鍵長
$provider = "Microsoft Enhanced Cryptographic Provider v1.0"
$kalgo = [Security.Cryptography.Oid]"RSA"
$klength = 2048
$halgo = [Security.Cryptography.Oid]"SHA1"

# X509KeySpec
# 1: The key can be used to encrypt (including key exchange) or sign depending on the algorithm. For RSA algorithms, if this value is set, the key can be used for both signing and encryption.
# 2: The key can be used for signing.
$kspec = 1

# 保存先
# 現在のユーザーの「個人」証明書ストアに保存
$slocation = [Security.Cryptography.X509Certificates.StoreLocation]"CurrentUser"
$sname = [Security.Cryptography.X509Certificates.StoreName]"My"

$oidlist = New-Object -ComObject X509Enrollment.CObjectIDs
$eku | % {
    $o = New-Object -ComObject X509Enrollment.CObjectID
    $o.InitializeFromValue($_.Value)
    $oidlist.Add($o)
}

$x509eku = New-Object -ComObject X509Enrollment.CX509ExtensionEnhancedKeyUsage
$x509eku.InitializeEncode($oidlist)

$x509ku = New-Object -ComObject X509Enrollment.CX509ExtensionKeyUsage
$x509ku.InitializeEncode([int]$ku)
$x509ku.Critical = $true

$algo = New-Object -ComObject X509Enrollment.CObjectId
$algo.InitializeFromValue($kalgo.Value)

$key = New-Object -ComObject X509Enrollment.CX509PrivateKey
$key.ProviderName = $provider
$key.Algorithm = $algo
$key.Length = $klength
$key.KeySpec = $kspec
$key.ExportPolicy = 0
$key.MachineContext = $false
$key.Create()

$dn = New-Object -ComObject X509Enrollment.CX500DistinguishedName
$dn.Encode($subject, 0)

$hash = New-Object -ComObject X509Enrollment.CObjectId
$hash.InitializeFromValue($halgo.Value)

$req = New-Object -ComObject X509Enrollment.CX509CertificateRequestCertificate
$req.InitializeFromPrivateKey(1, $key, "")
$req.Subject = $dn
$req.Issuer = $dn
$req.NotBefore = $start
$req.NotAfter = $end
$req.SignatureInformation.HashAlgorithm = $hash
$req.X509Extensions.Add($x509eku)
$req.X509Extensions.Add($x509ku)
$req.Encode()

$enroll = New-Object -ComObject X509Enrollment.CX509enrollment
$enroll.InitializeFromRequest($req)
$enroll.CertificateFriendlyName = $fn
$enroll.InstallResponse(2, $enroll.CreateRequest(1), 1, "")

一番のハマり所は、EKU を [Security.Cryptography.Oid[]] にキャストする際、日本語環境では日本語の用途名を指定する必要があるところでしょうか。英語環境の場合は英語で指定する必要があります。分かりやすさのために EKU を文字列からキャストしていますが、ハマらないためには、OID を直接指定したほうが良いかもしれません。

なお、上記のコード実行後に確認すると、コード署名に利用可能な証明書が表示され、署名を行うことができます。

PS C:\> Get-ChildItem Cert:\CurrentUser\My

    ディレクトリ: Microsoft.PowerShell.Security\Certificate::CurrentUser\My

Thumbprint                                Subject
----------                                -------
A9E494C41DFD461E94EB3C11790AD11B50F8E5DA  CN=test@operationslab.local
3AB427ABF2A2C141156D6B5925D88180A120B394  CN=admin@operationslab.local

PS C:\> Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert

    ディレクトリ: Microsoft.PowerShell.Security\Certificate::CurrentUser\My

Thumbprint                                Subject
----------                                -------
3AB427ABF2A2C141156D6B5925D88180A120B394  CN=admin@operationslab.local

PS C:\> $cert = Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert
PS C:\> Set-AuthenticodeSignature C:\test.ps1 $cert

    ディレクトリ: C:\

SignerCertificate                         Status        Path
-----------------                         ------        ----
3AB427ABF2A2C141156D6B5925D88180A120B394  UnknownError  test.ps1

因みに、Set-AuthenticodeSignature の結果、Status が UnknownError となるのは、自己証明書を使用しているためです。正規の認証局から発行された証明書を使用するか、自己証明書を「信頼されたルート証明機関」ストアへ(にも)配置する(つまりルート証明書として登録する)と、以下のように Status が Vaild になります。

PS C:\> Set-AuthenticodeSignature C:\test.ps1 $cert

    ディレクトリ: C:\

SignerCertificate                         Status  Path
-----------------                         ------  ----
3AB427ABF2A2C141156D6B5925D88180A120B394  Valid   test.ps1

WinRMとProxy

leave a comment »

この Post は PowerShell Advent Calendar 2014 の 12/08 分です。

企業などでは Proxy サーバが存在している環境も多いかと思います。PowerShell Remoting / WinRM は(構成によりますが)接続に HTTP/HTTPS を使用する為、Proxy 設定の影響をうけます。

Internet Explorer などのブラウザは、WPAD (Web Proxy Auto Discovery) を用いた自動構成と WinHTTP の静的 Proxy 設定が同時に有効になっていた場合に WPAD を優先してくれます。一方、PowerShell (WinRM) は(デフォルトでは) WPAD や構成スクリプト(pacファイル)を処理できないため、ブラウザは接続できるのに PowerShell Remoting では接続できない、という事が起こりえます。

特に、Proxy 設定されているノート PC を外部に持ち出した場合は要注意です。

Proxy 関連で問題がある場合、以下の様になります。(Proxy サーバに依存する部分がありますので、参考情報です。)

WinRM を Proxy できない Proxy サーバが設定されている場合

※Proxy サーバのサービスポートへは接続できるが、Proxy できない状態。

PS C:\> New-PSSession -Credential $cred $target
New-PSSession : [sv01.example.local] リモート サーバー sv01.example.local への接続に失敗し、次のエラー メッセージ
が返されました: WinRM クライアントは、リモート WS-Management サービスから HTTP 状態コード 504 を受け取りました。詳細に
ついては、about_Remote_Troubleshooting のヘルプ トピックを参照してください。
発生場所 行:1 文字:1
+ New-PSSession -Credential $cred $target
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
   gTransportException
    + FullyQualifiedErrorId : -2144108273,PSSessionOpenFailed

Proxy サーバから target ホストに接続できない場合

※例えば、Proxy サーバ上で target ホストの名前解決ができなかったり、ルーティングが存在しない状態。

PS C:\> New-PSSession -Credential $cred $target
New-PSSession : [sv01.example.local] リモート サーバー sv01.example.local への接続に失敗し、次のエラー メッセージ
が返されました: 指定したリモート ホストへの接続は拒否されました。 このリモート ホストで WS-Management サービスが実行さ
れていて、適切なポートと HTTP URL で要求をリッスンするようにリモート ホストが構成されていることを確認してください。詳細
については、about_Remote_Troubleshooting のヘルプ トピックを参照してください。
発生場所 行:1 文字:1
+ New-PSSession -Credential $cred $target
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
   gTransportException
    + FullyQualifiedErrorId : CannotConnectWinRMService,PSSessionOpenFailed

Proxy サーバに接続できない場合

※Proxy ホストには到達できるが、Proxy サービスを提供するポートへ接続できない状態。

PS C:\> New-PSSession -Credential $cred $target
New-PSSession : [sv01.example.local] リモート サーバー sv01.example.local への接続に失敗し、次のエラー メッセージ
が返されました: クライアントは、要求で指定された接続先に接続できません。 接続先のサービスが実行されていて、要求を受け付
けられる状態であることを確認してください。 接続先で実行されている WS-Management サービス (通常は IIS または WinRM) に関
するログとドキュメントを参照してください。 接続先が WinRM サービスの場合は、リモート ホスト上で次のコマンドを実行して、
WinRM サービスを分析および構成してください: "winrm quickconfig" 詳細については、about_Remote_Troubleshooting のヘルプ ト
ピックを参照してください。
発生場所 行:1 文字:1
+ New-PSSession -Credential $cred $target
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
   gTransportException
    + FullyQualifiedErrorId : CannotConnect,PSSessionOpenFailed

※Proxy ホストへ到達すらできない場合は、以下のようになります。

PS C:\> New-PSSession -Credential $cred $target
New-PSSession : [sv01.example.local] リモート サーバー sv01.example.local への接続に失敗し、次のエラー メッセージ
が返されました: WinRM クライアントは、サーバー名を解決できないため、要求を処理できません。詳細については、about_Remote_
Troubleshooting のヘルプ トピックを参照してください。
発生場所 行:1 文字:1
+ New-PSSession -Credential $cred $target
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
   gTransportException
    + FullyQualifiedErrorId : ComputerNotFound,PSSessionOpenFailed

解決方法

Proxy の問題であれば Proxy 設定を修正すればよいのですが、環境によっては管理者に Proxy 設定をロックされているかもしれないですので、PowerShell 上で(ある程度)指定する方法を。

New-PSSessionOption コマンドレットを使用すると、PSSession を生成する際にパラメータを調整できます。

New-PSSessionOption [-ApplicationArguments <PSPrimitiveDictionary>] [-CancelTimeout <Int32>] [-Culture <CultureInfo>] [-IdleTimeout <Int32>] [-IncludePortInSPN] [-MaximumReceivedDataSizePerCommand <Int32>] [-MaximumReceivedObjectSize <Int32>] [-MaximumRedirection <Int32>] [-NoCompression] [-NoEncryption] [-NoMachineProfile] [-OpenTimeout <Int32>] [-OperationTimeout <Int32>] [-OutputBufferingMode <OutputBufferingMode>] [-ProxyAccessType <ProxyAccessType>] [-ProxyAuthentication <AuthenticationMechanism>] [-ProxyCredential <PSCredential>] [-SkipCACheck] [-SkipCNCheck] [-SkipRevocationCheck] [-UICulture <CultureInfo>] [-UseUTF16] [<CommonParameters>]

ProxyAccessType パラメータを指定することで、New-PSSession / Enter-PSSession 時に、WinRM サービスへプロキシ設定を渡すことができます。

-ProxyAccessType <ProxyAccessType>

Determines which mechanism is used to resolve the host name. Valid values are IEConfig, WinHttpConfig, AutoDetect, NoProxyServer and None. The default value is None.

ProxyAccessType に指定可能な値は以下の通りです。

  • AutoDetectProxy 構成を自動検出します。
  • IEConfigInternet Explore の Proxy 設定を使用します。
  • NoneProxy 情報を(明示的には)指定しません。WSMan など、下位(ベースとなっている)サービスに Proxy の解決を委任します。WinHTTP の設定はベースサービス側でも参照されるため、結果として WinHTTP などの Proxy 設定が利用されれる場合があります。
  • NoProxyServerProxy サーバを使用しません。(使用しないことを明示的に設定します。)
  • WinHttpConfigWinHTTP の Proxy 設定を使用します。

注:具体的なサーバを指定することはできません。

詳細は、MSDN に記載があります。

Proxy サーバ設定を迂回したい場合は、ProxyAccessType に NoProxyServer を設定します。

PS C:\> $options = New-PSSessionOption -ProxyAccessType NoProxyServer
PS C:\> New-PSSession -Credential $cred -SessionOption $options $target

 Id Name            ComputerName    State         ConfigurationName     Availability
 -- ----            ------------    -----         -----------------     ------------
 16 Session16       sv01.example... Opened        Microsoft.PowerShell     Available

Written by kazu

2014/12/08 at 12:52