VMM ライブラリと通信できていますか？

SCVMM 2019から仮想マシンを展開しようとしたら、こんな感じのメッセージが出ました。。。
vmm cannot locate a virtual hard disk that is marked as equivalent to the virtual hard disk with id GUIDの文字列
※すみません、画面取り損ねました。

色々調べたら、
SCVMM Template issue
に該当しそうな感じ。
VMM ライブラリは稼働していましたので、変な感じですよね。。。

まず、VMM ライブラリを疑似的に落として（NICを無効化等々、今回は仮想マシンなので保存状態にしてみました）、確認してみました。
が、再現しませんでした。。。

Windows Updateのどさくさに紛れたパターンも試してみました。


ふと、VMM データベースに仮想ハードディスク存在するが、VMM ライブラリに無い状態を作ればよいのかと。。。（ファイル名変更ですかね）
これも再現しない。。。

また再現するようなことがあれば、追記していきます。

Raspberry PI の Samba をファイル共有監視にして S2D 組んでみますよ

Windows Server 2019 の2ノード S2D では、ルーターに接続された USB メモリをファイル共有監視にできるというのがあります。
※詳細は、
　Windows Server 2019での記憶域スペースダイレクトの改善ポイント５つを公表。
　をご参照ください。

これについて、
「Raspberry PI の Samba でSMB2 が有効になっていればできるらしい」
と小耳にはさんだので試してみます。
まあ、「PoCとしてこういうこともできるよ」ということで読み進めていただければ幸いですー。

さて久しぶり過ぎて、Sambaが構成できなくなっておりましたが、
SAMBA: SET UP A RASPBERRY PI AS A FILE SERVER FOR YOUR LOCAL NETWORK
のパスをアレンジして構成しました。
net use での確認コマンドは、下記を参考にさせていただきました。
Windows：net use コマンドでネットワーク上の共有名に接続する

やっぱり常に触ってないとだめですねぇ。
ということで、4.5.16-Debian の導入完了。

testparm で確認できたコンフィグを載せておきます。
※ min protocol の部分は、
windows10にてsambaのファイルサーバーにアクセスできなくなった件について
を参考にさせていただきました。

pi@raspberrypi:~ $ sudo testparm
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[homes]"
Processing section "[printers]"
Processing section "[print$]"
Processing section "[quorum2019n2]"
Loaded services file OK.
Server role: ROLE_STANDALONE

Press enter to see a dump of your service definitions

# Global parameters
[global]
log file = /var/log/samba/log.%m
max log size = 1000
panic action = /usr/share/samba/panic-action %d
usershare allow guests = Yes
server min protocol = SMB2
map to guest = Bad User
obey pam restrictions = Yes
pam password change = Yes
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
passwd program = /usr/bin/passwd %u
server role = standalone server
unix password sync = Yes
dns proxy = No
idmap config * : backend = tdb


[homes]
comment = Home Directories
browseable = No
create mask = 0700
directory mask = 0700
valid users = %S


[printers]
comment = All Printers
path = /var/spool/samba
browseable = No
printable = Yes
create mask = 0700


[print$]
comment = Printer Drivers
path = /var/lib/samba/printers


[quorum2019n2]
comment = Pi shared folder
path = /var/samba/quorum2019n2
create mask = 0777
directory mask = 0777
guest ok = Yes
read only = No

上記構成のうち、quorum2019n2 共有を S2D の FileWitness に指定します。

2ノードの S2D を組んでいきます。
まずフェールオーバークラスターが有効化出来たら、ファイル共有監視を追加します。
Raspberry PI は、ワークグループですから、Set-ClusterQuorum で認証情報を指定しないといけません。
調べたところ、ムッシュのブログ記事を発見！
Windows Server 2019 の WSFC の機能拡張
Set-ClusterQuorum に -Credential $(Get-Credential) を加えれば大丈夫です。
実行結果は下記の通り。

Raspberry PI からファイル共有監視のディレクトリを確認した結果は、下記の通り。


OSディスク以外のクリーンアップが完了したら、


いよいよ S2D を有効化します。
※最新の累積更新プログラムが適用済みか念のため確認しておきましょう。

無事に有効化完了！


Get-VirtualDisk では、CSV となる仮想ディスクは作っていないので、"ClusterPerformanceHistory"だけしかありません。

Get-PhysicalDisk は、片方の OS ディスクが見えていますが、それ以外はデータディスクですー。


Windows Admin Center から CSV を作ってみましょう。



もう一度、Get-VirtualDisk を実行してみます。


以上です！

5月の第二水曜日、Windows Server 2016、Windows Server 2019 のパッチ適用

第二水曜日を過ぎたので、Windows Server 2016、Windows Server 2019 を新規インストールした際のパッチ適用を具合を見てます。
※要は、オフラインでパッチ適用したい場合、どの更新プログラムを用意すればよいのかを把握するのが本稿の目的です。
いずれも、同一の Hyper-V ホストで動作する仮想マシンで確認しました。

Windows Server 2016の場合

2019/05として新しいサービススタック更新プログラム(SSU)がリリースされていますね。


Windows Server 2019の場合
※画面キャプチャーで、日時が入れ忘れました...


これまでも何回か確認しているのですが、月次定例の更新プログラム適用状況は、Windows Server 2019 のほうがわかりやすいですね。
加えて、Windows Server 2019のほうが所要時間短いと思われます。（更新プログラムの数やサイズは、まったく同じではないですけれども）

System Center Operations Manager 2016 Update Rollup 7 を適用しました

標記の件、遅まきながら適用しました。

System Center 2016 更新プログラム UR7 がリリースされました！！
サポートフォーラムのサイトに情報が投稿されるようになっています。


KB 情報はこちらよりアクセスできます。


注）Update Rollup 2が適用済みであることを確認してください。なお本環境は、Update Rollup 6を適用済みなので、このチェックは割愛します。

Windows Update で検出されていないので、Microsoft Update カタログからダウンロードします。
ダウンロードする対象（インストールの順番でもあります）は、下記の通り。

• Management server
• Web console server role computers
• Operations console role computers
• Reporting

cab 形式でダウンロードできます。その中に msi ファイルが入っていますので、解凍します。
解凍すると下記のような感じになります


msiexec /update KB4492182-AMD64-Server.msp
を実行して、Management server をアップデートします。（管理者権限で実行しましょう）


msiexec /update KB4492182-AMD64-ENU-WebConsole.msp
を実行して、Web console をアップデートします。


msiexec /update KB4492182-AMD64-ENU-Console.msp
を実行して、Operations console をアップデートします。


msiexec /update KB4492182-AMD64-ENU-Reporting.msp
を実行して、Reporting をアップデートします。

以上で更新プログラム自体の適用は終了。

SCOM への更新プログラム適用はこれで終わりません。
続いて、下記の2行を冒頭に追加したSQL スクリプト"インストールしたドライブ\Program Files\System Center 2016\Operations Manager\Server\SQL Script for Update Rollups"を実行します。
use OperationsManager
go


インストールドライブ\Program Files\System Center 2016\Operations Manager\Server\Management Packs for Update Rollups
より管理パックをインポートします。
※下記の管理パックは含まれていません。よって、事前に IIS 管理パックは追加してください。本環境では導入済みで、IIS 管理パックの導入は割愛します。
Microsoft.Windows.InternetInformationServices.CommonLibrary.mp



が、上記画面の通り、これまでの UR6 まででインポート済みであり、改めてインポートしなくて良いです。（というかインポートのボタンが押せないですね）

あとは、各々のエージェントを更新すれば完了となります。

SCOM の build 番号を調べる場合は、下記を参照してくださいー。
System Center Operations Manager 2016 build numbers

System Center Virtual Machine Manager 2016 Update Rollup 7 を適用しました

標記の件、遅まきながら適用しました。

System Center 2016 更新プログラム UR7 がリリースされました！！
サポートフォーラムのサイトに情報が投稿されるようになっています。


KB 情報はこちらよりアクセスできます。


KB 情報より、Microsoft Update カタログにアクセスできます。
下記はその画面をキャプチャーしたものです。



cab 形式でダウンロードできます。その中に msi ファイルが入っていますので、解凍します。
解凍すると下記のような感じになります。


msiexec /update kb4496920_vmmserver_amd64.msp
を実行して、VMM Serverをアップデートします。（管理者権限で実行しましょう）

サービスを止めてアップデートする方法を選択しました。



msiexec /update kb4496921_AdminConsole_amd64.msp
を実行して、VMM コンソールをアップデートします。



System Center Virtual Machine Manager 2016 build numbers の build 番号と一致していることを確認しました。


Update Rollup 7 の適用に伴い、VMM Agent のバージョンも上がります。
Hyper-V ホストにインストールしている VMM Agent のアップデートもお忘れなく！

MySQL リソースプロバイダーを試したいので、Azure Stack の証明書を Validate します

MySQL リソースプロバイダーを試したいので、Azure Stack の証明書を作りますの続き。

Validate Azure Stack PKI certificates
に基づいて進めてみました。

Fail がいくつか。

Root CA 配るポリシーを設定している AD ドメインメンバーで試してみます。

同じ Fail が出ました。
Azure Stack PKI 証明書に関する一般的な問題を修復する
の「キー使用法」に該当してます。
作り直しですね。。。

New-AzsCertificateSigningRequestで作った証明書要求用テキストファイルです。

[Version]
Signature="$Windows NT$"

[NewRequest]
Subject = "CN=portal.yksk.azs.sshzk2016.local,OU=AzureStack,O=Sashizaki,L=yksk,ST=Kanagawa,C=JP"

Exportable = TRUE ; Private key is not exportable
KeyLength = 2048 ; Common key sizes: 512, 1024, 2048, 4096, 8192, 16384
KeySpec = 1 ; AT_KEYEXCHANGE
KeyUsage = 0xA0 ; Digital Signature, Key Encipherment
MachineKeySet = True ; The key belongs to the local computer account
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
SMIME = FALSE
RequestType = PKCS10
HashAlgorithm = SHA256

; At least certreq.exe shipping with Windows Vista/Server 2008 is required to interpret the [Strings] and [Extensions] sections below

[Strings]
szOID_SUBJECT_ALT_NAME2 = "2.5.29.17"
szOID_ENHANCED_KEY_USAGE = "2.5.29.37"
szOID_PKIX_KP_SERVER_AUTH = "1.3.6.1.5.5.7.3.1"
szOID_PKIX_KP_CLIENT_AUTH = "1.3.6.1.5.5.7.3.2"

[Extensions]
%szOID_SUBJECT_ALT_NAME2% = "{text}dns=portal.yksk.azs.sshzk2016.local&dns=adminportal.yksk.azs.sshzk2016.local&dns=management.yksk.azs.sshzk2016.local&dns=adminmanagement.yksk.azs.sshzk2016.local&dns=*.blob.yksk.azs.sshzk2016.local&dns=*.queue.yksk.azs.sshzk2016.local&dns=*.table.yksk.azs.sshzk2016.local&dns=*.vault.yksk.azs.sshzk2016.local&dns=*.adminvault.yksk.azs.sshzk2016.local&dns=*.adminhosting.yksk.azs.sshzk2016.local&dns=*.hosting.yksk.azs.sshzk2016.local&dns=*.dbadapter.yksk.azs.sshzk2016.local&dns=*.appservice.yksk.azs.sshzk2016.local&dns=*.scm.appservice.yksk.azs.sshzk2016.local&dns=api.appservice.yksk.azs.sshzk2016.local&dns=ftp.appservice.yksk.azs.sshzk2016.local&dns=sso.appservice.yksk.azs.sshzk2016.local&dns=*.sso.appservice.yksk.azs.sshzk2016.local"
%szOID_ENHANCED_KEY_USAGE% = "{text}%szOID_PKIX_KP_SERVER_AUTH%,%szOID_PKIX_KP_CLIENT_AUTH%"

[RequestAttributes]
CertificateTemplate = Machine

AD CS の証明機関でエラーにならないよう、RequestAttributes の CetificateTemplate を定義しました。サーバー認証、クライアント認証が必要である旨、Invoke-AzsCertificateValidation の Fail 結果を踏まえました。
エンタープライズ CA ならば、Get-CATemplate でテンプレートの英語名を確認できます。


これで、Certreq し直します。
が、これが出てます。

※仮のAレコードを作るというフェイクは実施済み

比較のために、スタンドアロン CA を立ててやってみます。これなら証明書テンプレート周りのトラブルを回避できると安易に考えた。
※エンタープライズ CA の子 CA という位置づけ。
証明書作成要求用テキストファイルは、[RequestAttributes]は空のまま。

[Version]
Signature="$Windows NT$"

[NewRequest]
Subject = "CN=portal.yksk.azs.sshzk2016.local,OU=AzureStack,O=Sashizaki,L=yksk,ST=Kanagawa,C=JP"

Exportable = TRUE ; Private key is not exportable
KeyLength = 2048 ; Common key sizes: 512, 1024, 2048, 4096, 8192, 16384
KeySpec = 1 ; AT_KEYEXCHANGE
KeyUsage = 0xA0 ; Digital Signature, Key Encipherment
MachineKeySet = True ; The key belongs to the local computer account
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
SMIME = FALSE
RequestType = PKCS10
HashAlgorithm = SHA256

; At least certreq.exe shipping with Windows Vista/Server 2008 is required to interpret the [Strings] and [Extensions] sections below

[Strings]
szOID_SUBJECT_ALT_NAME2 = "2.5.29.17"
szOID_ENHANCED_KEY_USAGE = "2.5.29.37"
szOID_PKIX_KP_SERVER_AUTH = "1.3.6.1.5.5.7.3.1"
szOID_PKIX_KP_CLIENT_AUTH = "1.3.6.1.5.5.7.3.2"

[Extensions]
%szOID_SUBJECT_ALT_NAME2% = "{text}dns=portal.yksk.azs.sshzk2016.local&dns=adminportal.yksk.azs.sshzk2016.local&dns=management.yksk.azs.sshzk2016.local&dns=adminmanagement.yksk.azs.sshzk2016.local&dns=*.blob.yksk.azs.sshzk2016.local&dns=*.queue.yksk.azs.sshzk2016.local&dns=*.table.yksk.azs.sshzk2016.local&dns=*.vault.yksk.azs.sshzk2016.local&dns=*.adminvault.yksk.azs.sshzk2016.local&dns=*.adminhosting.yksk.azs.sshzk2016.local&dns=*.hosting.yksk.azs.sshzk2016.local&dns=*.dbadapter.yksk.azs.sshzk2016.local&dns=*.appservice.yksk.azs.sshzk2016.local&dns=*.scm.appservice.yksk.azs.sshzk2016.local&dns=api.appservice.yksk.azs.sshzk2016.local&dns=ftp.appservice.yksk.azs.sshzk2016.local&dns=sso.appservice.yksk.azs.sshzk2016.local&dns=*.sso.appservice.yksk.azs.sshzk2016.local"
%szOID_ENHANCED_KEY_USAGE% = "{text}%szOID_PKIX_KP_SERVER_AUTH%,%szOID_PKIX_KP_CLIENT_AUTH%"

[RequestAttributes]

スタンドアロン CA から発行した証明書をインポートしてみました。

ハイライトしたほうが今回作成した証明書です。目的にサーバー認証とクライアント認証が入ってます。
これをpfxにしてから Validate です。
Key Usage は、OK になったけど、Cert Chain はまだ Fail 。。。

エンタープライズ CA、スタンドアロン CA 両方の証明書は、インポートしているのですが。

うーむ、証明機関の居るドメインメンバーで確認したほうが良いのだろうか。。。
で、やってみましたが、状況変わらず。PaaS の証明書も validate やってます。



なんだかまだ負けた感あるものの、エンタープライズ CA よりは、スタンドアロン CA のほうが敷居は低いことが分かっただけでも良いのかな。。。

System Center 2019 のシステム要件

すでに VMM は使い始めているのですが、おさらいもかねてリンク集にまとめます。
※SCCM は、2019というくくりではないのですが、Supported configurations for System Center Configuration Manager にシステム要件があります。

• Preparing your environment for System Center Data Protection Manager
• System requirements for System Center Operations Manager
• System requirements for System Center Orchestrator
• System requirements for System Center Service Manager
• System requirements for System Center Virtual Machine Manager

VMM の次は、 SCOM 入れてみないとなぁ。。。

Windows Admin Center 1904 の証明書が変わっちゃうようにみえるんですけど？！

How can we improve the management tools and experience in Windows Server? にてフィードバックしているのですが、謎の現像です。

Windows Server 2019 に SCVMM 2019 を載せた環境へ Windows Admin Center 1904 をインストールしました。
別稿でまとめた SAN を定義した証明書を Windows Server 2016 AD CS で作成し、上記の Windows Admin Center 1904 へ関連付けました(binding)。
このタイミングでは、関連付けた証明書を使っています。



一時間ほどたったのですが、突然 SAN が定義されていない旨のエラーが出ました。

よく見ると自己署名証明書になってます。

別の日に、念のため拇印を確認したところ、SCVMM の自己署名証明書でした。


改めて証明書に関連付け直します！



またしばらくするとダメになる。。。

こういう画面になることもあります。。。


※この現象、既に何回か出ております。その都度、証明書を作成し直したのですが、この現象が繰り返し出ています。

現在、ほかの環境でも確認中。再現するようであれば、コメント等で追記します。