SCOMでサービス監視に失敗し、いろいろ試したらrpc 1747 the authentication service is unknown windows serverが出まして

SCOMでサービス監視に失敗したら、結果、rpc 1747 the authentication service is unknown windows serverが出ました。
※SCOMでサービス監視の設定に失敗したら、直ちにrpc 1747 the authentication service is unknown windows serverが表示されるわけではありません。ご注意ください。

Windows Serviceのモニターを作っていくわけですが、



でこの後、リモートホスト（サーバー）のWindows Service一覧が取得できない、事案が発生。

SCOMエージェント経由だと、Windows Service一覧が取得できます。

で、「サービス」の管理コンソールを起動して、リモートホスト接続すると
1747 the authentication service is unknown windows server
がでました。
RPC周りのトラブルと判断。。。
※ちなみに、RPCで接続できない場合は、1722がエラーコードとして表示されます。

1747 the authentication service is unknown windows server
でひたすら検索したところ、
Windows Event Log サービスを起動しようとしたら 「エラー 1747: その認証サービスは認識されません」 - netsh winsock reset で解消
[RESOLVED] Event Viewer Service Won't Start
Error 1747 : The Authentication Service is Unknown
[SOLVED] Error 1747 " The Authentication Service is Unknown" How To Fix It - YouTube
Windowsシステムエラーコード一覧
といった感じで、いずれも
netsh winsock reset
が解決方法でした。

あと、SCOMエージェントのプッシュインストールに失敗していたということでしたので、下記も探し当ててみました。
"Error Code 800706D3" occurs when you perform an Agent push installation to Windows Server 2012-based servers
※その後、事象が発生しているサーバーで確認しました。残念ながら、こちらに該当しませんでした。

半信半疑でしたので、やむを得ず確認と相成ったのですが、なんと
netsh winsock reset
で、"1747 the authentication service is unknown windows server"が解決し、Windows Service一覧が取得できました！

以上、参考になれば幸いです。

System Center Operations ManagerのAgentのプッシュインストールが失敗したら

System Center Operations ManagerのAgentのプッシュインストールが失敗したら、見ていただきたい記事がありましたので、改めてご紹介します。

記事自体は、2015年5月に書かれたものですが、埋もれてしまってはもったいないのです。

KB: "Error Code 800706D3" occurs when you perform an Agent push installation to Windows Server 2012 computersがその紹介記事で、"Error Code 800706D3" occurs when you perform an Agent push installation to Windows Server 2012-based serversにて解決方法が書かれています。

"Error Code 800706D3" occurs when you perform an Agent push installation to Windows Server 2012-based serversで、解決方法は、DNSクライアントサービスを起動することになっています。
ですが、名前解決に起因しているので、何らかの原因でDNSキャッシュに問題があった時にも参考になるのではないかなーと考えています。

System Center Operations ManagerのAgentのプッシュインストールが失敗したら、まず"Error Code 800706D3" occurs when you perform an Agent push installation to Windows Server 2012-based serversを見てみてください！

Azure Stackデプロイ時にGet-AADtokenでエラーが出た

Azure Stack用に用意したAADアカウントの文字列に注意しましょうというお話。

Azure Stackデプロイ時にGet-AADtokenでエラーが出たわけです。

これは、指定したAADアカウントが無いよ、というメッセージそのもの。

上記の前段で、クレデンシャルを設定している箇所があります。
Deploy Azure Stack POC
にある下記のスクリプトです。（ブログ転載のためちょっとだけ直してます）

$adminpass = ConvertTo-SecureString "local admin password" -AsPlainText -Force
$aadpass = ConvertTo-SecureString "aad account admin global password" -AsPlainText -Force
$aadcred = New-Object System.Management.Automation.PSCredential ("aad account admin global", $aadpass)

メモ帳に準備した上記のスクリプトを使っていたのです。
いろいろ試行錯誤するうちに、

AADアカウントの@マーク部分が文字化けしていることに気が付きました。。。
これが直接の原因でした。

でもなんで文字化けしたのか、その後、そのメモ帳でテキストファイルを見たところ、@ではなく＠が入っていました。
つまりシングルバイトではなくマルチバイトの文字が入っていたわけです。
Azure Stackのデプロイ用VHDは英語版ですから、PowerShellも当然シングルバイトしか受け付けず、結果文字化けしたと。。。

AADアカウントのクレデンシャルをメモ帳に準備するときは、気を付けましょう。。。

Azure Stack向けにAzureサブスクリプションを別のAADに切り替えた

Azure Stack向けにAzureサブスクリプションを別のAADに切り替えたら、リソースが見えなくなって一瞬焦ったお話し。

Microsoftアカウントで、Azureサブスクリプションにサインアップしました。
Microsoftアカウントが居る既定のディレクトリを使っていました。

Azure Stack TP3 Refreshをデプロイするにあたり、
Register Azure Stack with your Azure Subscription
を読むと、Azure Stack用に準備したAADにAzureサブスクリプションを切り替える（紐付け直す）べきだと思い切り替えました。
※実際、Azure Stack用に準備したAADにAzureサブスクリプションを切り替え（紐付け直す）ていないと、うまくいかないことが別のデプロイで判明してます。。。

Azure Stack向けにAzureサブスクリプションを別のAADに切り替えました。
で、portal.azure.comにアクセスすると今まで作っていたリソースが見えなくなってました。
下図は、VMの例です。


ということで、Azure Stack用に準備したAADにAzureサブスクリプションを切り替えます。


そうすると、元通りリソースが見えるようになります。


今まで、サブスクリプションに複数AADを紐付けてはいたものの、こういう挙動が起きるとは、勉強になりました。

System Center 2016でSQL Serverの冗長構成は何が使えるのか

System Center 2016でSQL Serverの冗長構成は何が使えるか、おいおい必要になりそうなのでメモしておきます。
ドキュメントの日本語化が終わっているものとそうでないものがあるため、参考にした技術情報が英語、日本語入り混じっていますこと、ご承知おきください。

1. System Center 2016 Data Protection Manager
   System Center 2016 Data Protection Manager に対応する環境の準備に関するページによると、フェールオーバークラスターのみのサポートであり、SQL Server AlwaysOnはサポートされていません。
   
2. System Center 2016 Operations Manager
   SQL Server の設計に関する考慮事項によると、フェールオーバークラスターより、SQL Server AlwaysOnのほうが可用性を高くできるようですね。
   
3. System Center 2016 Orchestrator
   System Center 2016 Orchestratorとしての情報が見当たらないですね。SQL Server in System Center 2012 SP1にVMM、Operations Manager、Service ManagerとともにAlwaysOnをサポートする旨記載があるので、大丈夫そうですが。
   
4. System Center 2016 Service Manager
   SQL Server requirements for System Center 2016 - Service Managerでは、SQL Server AlwaysOnがサポートされる旨、記載があります。SQL Server AlwaysOnの対象となるDBは、Use SQL Server AlwaysOn availability groups with Service Manager to support failoverに記載ある通り、下記の3つとなります。
   
   • Service Manager CMDB
   • Service Manager Data Warehouse (all 3 databases)
   • OM and CM DataMart
5. System Center 2016 Virtual Machine Manager
   高可用性 VMM 展開の計画に、SQL Server AlwaysOnの利用を推奨する旨、記載があります。
   
6. Service Management Automation
   System requirements for Service Management Automationには、情報が見当たらないですね。
   公式情報ではないですが、Windows Azure Pack – SMA installationにサポートしている旨、記載ありますが。。。
   
7. System Center 2016 Service Provider Foundation
   Plan SPF deploymentには、情報が見当たらないですね。
   公式情報ではないですが、System Center 2012 SP1 Service Provider Foundation High Availabilityには、下記の文面がありサポートしていそうです。
   

   System Center Service Provider Foundation is an extensible OData web service backed by an SQL database. The database will be added to the SQL AlwaysOn Availability Group.

SQL Server AlwaysOnの取り扱いがはっきりしないSC 2016コンポーネントについては、実機で検証してみようかと思います。