Azure StackのPEP(privileged endpoint, 特権エンドポイント)へどこから接続すべきか

Azure Stackではログ収集や一部の操作を行うためにPEP(privileged endpoint, 特権エンドポイント)に接続するケースがあります。個人的に一番多いのはTest-AzureStackコマンドでテストすることでしょうか。 そのPEPにはRemote PowerShellで接続するのですが、そこに対してどこから接続すべきか、というガイドラインが当初と大きく変更されていますので少々注意が必要です。 - [Azure Stack での特権エンドポイントの使用 | Microsoft Docs](https://docs.microsoft.com/ja-jp/azure/azure-stack/azure-stack-privileged-endpoint) 上記の最新のドキュメントでは下記の説明が記載されています。 注意 セキュリティ上の理由から、PEP への接続は、ハードウェア ライフサイクル ホスト上で実行するセキュリティを強化された仮想マシンから、または Privileged Access Workstation のような専用のセキュリティで保護されたコンピューターからに限定して行う必要があります。 ハードウェア ライフサイクル ホストは、元の構成から変更しないようにするか (新しいソフトウェアのインストールするなど)、または PEP への接続に使わないようにする必要があります。 HLH(ハードウェアライフサイクルホスト)から直接接続するのではなく、その上で動く仮想マシンや専用のPCからの接続が推奨されています。 これ、実は当初はHLHから直接接続することが推奨されていたんです。このことは過去の編集履歴を参照するとわかります。 - [adding update · MicrosoftDocs/azure-docs@a0826e6](https://github.com/MicrosoftDocs/azure-docs/commit/a0826e6e56975c80572d9867ab19a7573d75fef5#diff-191bf0c6135f0e9c0ec5d08b7ec9c30f) ドキュメントがGithub上で管理されているので過去の履歴も追いやすくて良いですね。 これからAzure Stackを利用する場合にはどうということもないのですが、HLHから接続するようにしていたところ、ある時からPEPに接続ができなくなっていてこの事に気が付きました。 OEMのUpdateを適用する中でHLHへのセキュリティ設定が変更され、HLHからPEPへのRemote PowerShellでの接続も禁止されたようでした。 同様の変更は今後は発生しないとは思いますが、いつものことながら英語の最新版のドキュメントを参考にするのが色々と良さそうです。

August 26, 2018 · 1 min · 胡田昌彦

シャットダウンが進まない時には停止処理中のサービスに注目

メンテナンス中にトラブルがあってかなり無駄に時間を使ってしまったので反省も兼ねてメモしておきます。 Hyper-Vクラスタで予備ノードが無いテスト系のノードにhotfixを適用して再起動する作業をしていました。再起動を実行した所…Remote Desktopからはすぐにログオフさせられたもののいつまでたってもシャットダウンしない状況になってしまいました。結局起きていたことは以下の様なことでした。 - Hyper-Vのホストなので、稼働していた仮想マシンの状態を保存 - iSCSI接続に障害を併発しており(そもそもその対応のメンテナンスだったのですが)、ディスクへの書き込みパフォーマンスが出ていなくて時間がかかっていた - さらにディスクが見えなくなりHyper-V Virtual Machine Managementサービスが異常停止 - Hyper-V Virtual Machine Managementサービスはしばらくして自動的に開始 - その間にClusterサービスが停止中のままになる(デッドロック?) 結局Remote PowerShellでは接続できたので、Enter-PSSessionで該当ノードに入り、clusterサービスの実体であるclussvcを殺すことで再起動処理が先に進みました。 get-process clussvc | kill シャットダウンプロセスが進まない場合には、停止処理中で止まってしまっているサービスを見つけてそのプロセスを切るというのはすぐに思いつけないといけないですね。今日はこれに気がつくまでに1時間くらいかかってしまいました。反省です。また、そもそもHyper-Vクラスタでは予備ノードが無いとメンテナンスが非常に厳しいですね。

January 9, 2014 · 1 min · 胡田昌彦

Windows8でRemotePowerShellを有効にする方法

Windows Server 2012ではRemotePowerShellが規定で有効になっていますが、Windows8ではそうではありません。有効化する方法が紹介されています。 Understanding PowerShell Remote Management - Hey, Scripting Guy! Blog - Site Home - TechNet Blogs

January 12, 2013 · 1 min · 胡田昌彦

Office365へのPowerShell接続時にはWinHttpを使用しています。

かなり久しぶりに自宅に仕事を持ち帰ってしまいました。Office365のExchange Online周りのトラブル対応のスクリプトを書いたり動作確認したりするためにRemote PowerShellで接続しようとした所エラーが…。 New-PSSession : [ps.outlook.com] リモート サーバー ps.outlook.com への接続に失敗し、次のエラー メッセージが返されました WinRM は処理を完了できません。 指定したコンピューター名が有効であること、コンピューターにネットワーク経由でアクセスで きること、および WinRM サービスのファイアウォールの例外が有効になっていてこのコンピューターからアクセスできることを確認 してください。 既定では、パブリック プロファイルの WinRM ファイウォールの例外によって、同一のローカル サブネット内のリ モート コンピューターへのアクセスは制限されます。詳細については、about_Remote_Troubleshooting のヘルプ トピックを参照し てください。 発生場所 行:1 文字:16 $O365Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUr … CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin gTransportException FullyQualifiedErrorId : WinRMOperationTimeout,PSSessionOpenFailed ネットワーク的にはきちんとInternetに接続できてますし、IEでもきちんと外部サイトが見られる状態。Proxyは無し。Windowsファイアウォールも無効の状態でした。なぜなのかわからずTwitterでつぶやいていたら@genkiwさんにポイントを教えてもらえました。ありがとうございました! @ebi 接続先はポータルでしょうか、Exchange Onlineでしょうか? Proxyの設定(IEとwinhttp)とかサインインモジュールが古いとか、 Set-ExecutionPolicy RemoteSignedが実施されてないとか。 — 渡辺 元気さん (@genkiw) 11月 7, 2012 結局、WinHttpの設定がproxyを使用する設定のままになっており、proxyが無い環境なのでps.outlook.comに到達できない状態でした。 Vista以降ではコマンドプロンプトにて「netsh winhttp show proxy」にて現在の設定の表示、「netsh winhttp import proxy ie」にてIEからの設定の取り込みが可能です。これできちんと接続できるようになりました。接続方法はこちら。 ...

November 8, 2012 · 1 min · 胡田昌彦