AD CS で SAN 属性を追加すると設定値はどう変わっているのか

必要に迫られて調べました。

AD CS で SAN 属性を追加する方法は、
セキュリティで保護された LDAP 証明書にサブジェクトの別名を追加する方法
になりますね。これ以外にもいくつかの記事があります。

で、設定するコマンドは、明らかになっているのですが、どうやって確認するのが正しいか？

AD CS で SAN 属性を追加していたので、一旦外してみました。

よく見ると
EDITF_ATTRIBUTESUBJECTALTNAME2
自体が無くなっていますね。
で、設定のオプションが -setreg なら、get もあるでしょと調べてみたところ、-getreg オプションがありました。

EDITF_ATTRIBUTESUBJECTALTNAME2
自体は、無いですね。

AD CS で SAN 属性を外したままにはできないので、再設定します。

EDITF_ATTRIBUTESUBJECTALTNAME2
自体が増えています。

certutil -getreg policy\EditFlags
コマンドで念のため確認してみます。

EDITF_ATTRIBUTESUBJECTALTNAME2
があることを確認できます。

certutil -getreg policy\EditFlags
コマンドは、レジストリ設定のうち、policy\EditFlags を表示してくれるので、
EDITF_ATTRIBUTESUBJECTALTNAME2
以外にも使い道がありそうです。

Windows Admin Center からのリモートデスクトップ接続がうまくいかない場合

Windows Admin Center からのリモートデスクトップ接続がうまくいかない場合の解決策を書いておきます。

山市良さんの
WAC 1809 のリモート デスクトップ機能が使えない問題の解決
解決方法にはまらないケースがあり、調べていました。

• グループポリシーのほうは設定済みだった。
• レジストリを追加してみたが、効果無し。

で、Azure VM は、Windows Admin Center からのリモートデスクトップ接続がうまくいく。
山市良さんにならって、Windows Admin Center からのリモートデスクトップ接続において、バックグラウンドで実行されているPowerShell を眺めてみました。
山市良さんの記事にあった、Get-RdpNlaGroupPolicySettings 関数が目に留まりました。

そこで確認したところ、Azure VM は、NLA が有効になっています。
ができないほうは、NLA が無効になっていた。。。
ということで、できないほうで NLA を有効化しました。

※念のため、レジストリ設定を消してみた。レジストリ設定が無くても、リモートデスクトップ接続ができました。

グループポリシー設定も、
ENABLE NETWORK LEVEL ACCESS FOR WINDOWS RDP
を参考に設定しました。これで、AD ドメインに参加しているコンピューター群で問題は発生しなくなります。


コマンドプロンプトを全画面表示にしちゃってますが、Windows Admin Center 2007でのリモートデスクトップ接続は、下記のとおりです。

Windows Admin Center 2007 HA 構成をデプロイしてみる

Windows Admin Center 1910.2 HA 構成をデプロイしてみる
では、HA 構成がうまくデプロイできない旨、記載しました。

HA 構成のスクリプトファイルは、依然として1907です。Windows Admin Center 2007 HA 構成が、Windows Server 2019 Fail Over Cluster に展開、利用できるか確認します。

結論としては、やはりダメです。。。HA 構成のスクリプトで警告は出ていないけれど。

インストール直後は、クラスターの役割自体は、作成されます。が、リソースは起動しません。

これは、AD にアカウント（今回の場合は、wacha）が無いことに起因しています。


HA 構成のスクリプトは、アップグレードされないのだろうか。。。

Windows Admin Center の PowerShell から更新プログラムの適用状況をみてみる

Windows Admin Center から更新プログラムが適用できます。
ただ、下記のように、適用開始後、状況を確認したくなることがあります。


※もちろん適用が完了していれば、下図のように、概要画面で再起動が必要だと確認できますね。


少し調べたところ、下記のブログ記事が参考になりました。

• PowerShellを使って適用済みの更新プログラムの一覧(Windows UpdateのKB番号)を取得する方法
  この記事では、get-hotfix が使えると理解しました。
  
• Windows10でWindowsUpdateをPowerShellから実行する方法
  と
• 更新プログラムのダウンロード／インストール進捗状況が知りたい――Windows 10（バージョン1709以降）の更新用スクリプト解説
  では、Start-WUScan があると理解しました。ちなみに実行結果は、下記のようになります。
  
  が、すでに Windows Update スクリプトは、色々な方が作られております。今回は、適用状況の確認ができればよいので、Start-WUScan は使わない選択としました。
  あと、Get-WUIsPendingReboot は、自分でも調べがついていたのですが、Windows Update 適用後の再起動有無について確認でき、とても便利です。
  

以上、Windows Admin Center の PowerShell から、get-hotfix と Get-WUIsPendingReboot で簡単に確認した結果が、下記となります。

get-hotfix で今回の適用状況を確認しています。実際の完了状況は、いろいろなスクリプトを拝見すると別の方法を使っていますね。
適用後の再起動有無については、Get-WUIsPendingReboot で簡単に確認しています。結果が、True になっていますので、Restart-computer で再起動させます。

以上、Windows Admin Center 上でちょっと簡単に確認する際の方法をまとめました。

最後に、複数のコンピューターで、Windows Update を適用するには、下記のスクリプトやそれ以外にもいろいろな方が作成されているスクリプトを参考になさるがスムーズということも、申し添えます。

• Windows10でWindowsUpdateをPowerShellから実行する方法
  
• 更新プログラムのダウンロード／インストール進捗状況が知りたい――Windows 10（バージョン1709以降）の更新用スクリプト解説
  
• フルオートでWindows Updateする

Windows 10 の Open SSH クライアントを間違えて消してしまった。

Windows 10 の Open SSH クライアントを間違えて消してしまい。
※Open SSH クライアントは、Windows 10 バージョン1803から使用できます。

なぜか、設定から追加できないため、PowerShell で追加する方法を試します。
PowerShell を使用した OpenSSH のインストール
が、エラー。。。


Quick tip: avoid error 0x800f0954
を見つけたので、-LimitAccess オプションをつけて再実行。

しかしここで、Open SSH クライアントがないことに気づかないまま、
Add-WindowsCapability : Add-WindowsCapability failed. Error code = 0x800f0950 #2074
を試してしまう。
Windows Update の設定を一時的に変更して、みました、が、当然うまくいくわけなし。

インターネットからファイルをダウンロードできていない挙動に見えたので、オフラインでインストール方法を探す。

Install OpenSSH client in Windows without internet access
に
Offline installation of OpenSSH Server on Windows Server 2019
を見つけました。

早速、my.visualstudio.com より、
en_windows_10_features_on_demand_part_1_version_1803_updated_march_2018_x64_dvd_12063771.iso
をダウンロードしました。

ISO ファイルを開いて
OpenSSH-Client-Package~31bf3856ad364e35~amd64~~.cab
を c:\fod にコピーしました。


ファイルが準備できましたので、下記のコマンドを実行します。

Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0 -limitaccess -source c:\FOD

ようやくインストールできました。

設定でもインストール済みであることを確認しました。


無事に、ssh コマンドも実行できました！

Windows Admin Center 1910.2 HA 構成をデプロイしてみる

Windows Admin Center 1910 HA 構成をデプロイしてみる
では、HA 構成がうまくデプロイできない旨、記載しました。

HA 構成のスクリプトファイルは、依然として1907です。Windows Admin Center 1910.2 HA 構成が、Windows Server 2019 Fail Over Cluster に展開、利用できるか確認します。

結論としては、やはりダメです。。。

インストール直後は、クラスターの役割自体は、作成されます。が、リソースは起動しません。
これは、AD にアカウントが無いことに起因しています。

おそらく、アカウント無効化しても、1910の確認結果と同様に、インストールが失敗するのではないかと推測しています。
結果、アカウント無効化してもインストールは、失敗してます。。。

Windows Admin Center から Azure Cloud Shell をセットアップ

Windows Admin Center の拡張として、 Azure Cloud Shell があります。
せっかくなので、セットアップしておきます。

拡張として、 Azure Cloud Shell が追加されていると、メニューから Azure Cloud Shell を起動できます。


サインインの画面になります。コードをコピーしておきます。
※一時的なコードなので、そのまま貼っております。


先ほどコピーしたコードを貼り付けます。


サインインするアカウントを選択します。


サインイン完了、ブラウザーのタブを閉じます。


先ほどの画面に戻りました。
Azure Cloud Shell をセットアップするので、[Go to Azure Cloud Shell]をクリックします。


どのディレクトリを使うのか、選択します。


どちらのシェルをつかうのか、選択します。


Azure Cloud Shell は、ストレージアカウントが必要です。ストレージアカウントを作成するサブスクリプションを選択し、[ストレージの作成]をクリックします。


セットアップ完了。


Windows Admin Center からも Azure Cloud Shell を起動できました。


Windows Admin Center から Azure Cloud Shell を起動する際に、改めてサインインの画面は表示されることは、留意しておきましょう。

Dell EMC OpenManage Integration 1.1.0 for Windows Admin Center

Windows Admin Center 1910.2をちょっと触っていたところ、拡張が更新できますというメッセージが出ました。
見てみたら、Dell EMC OpenManage Integration 1.1.0がリリースされていました。


リリースノートやインストールガイドは、
OpenManage Integration with Microsoft Windows Admin Center
にあります。
New in this releaseや、Key featuresを見ると、あることがわかりますね。

Windows Admin Center の接続リストを Export / Import する

Windows Admin Center 1910.2を入れ直すので、せっかくだから「PowerShell を使用して Windows Admin Center の設定を管理する」を試してみます。
サンプルスクリプトは、「PowerShell を使用して Windows Admin Center の設定を管理する」を見てくださいね。

Windows Admin Center がインストールされているサーバー上に、ライブラリがあるので、そこが使えるように実行します。

CSV ファイルの内容を表示してみました。最後の"global"が共有接続のフラグですね。

いったん、Windows Admin Center をアンインストール。
再インストールしました。Windows Admin Center 自身のみが接続リストにある状態です。


「PowerShell を使用して Windows Admin Center の設定を管理する」に、-prune オプションが言及されています。インポートされたファイルに明示的に含まれていない接続を削除してくれるそうです。

-prune オプション無しで実行してみました。

で、画面をリロード。

接続リストが、復元できました。ちょっと表示が消えた個所がありますけど。。。

Windows Admin Center 1910.2は、プレビュー版だったはずだが、GA 版である

ちょっとなにいっているかわからない的なタイトルになってます。

最初にリリースされた時は、確かにプレビュー版でした。証拠のファイル名は下記の通り。

build番号は下記の通り。

2020/07/04 15:24 追記）プレビュー版リリースの記事がありました。
　Announcing Windows Admin Center Preview 1910.2

このところ色々調べる機会がありました。
リリース履歴をみたら、1910.2は、GA 版の扱いになっていました。。。
1910.2のリンクをたどると確かに GA 版になっています。。。
プレビュー版をダウンロードしてから、2週間ほどでステイタスが変わったのか。。。
というか3か月ほどたって気が付くとはなぁ。

GA 版をダウンロードしてみたところ、ファイル名が異なります。


じゃあ、build番号はどうなるのか？
念のため、いったんアンインストールして、GA 版のファイルでインストールしてみます。

変わってないですね。
ということで、プレビュー版のファイルを入れた方も、安心してそのままお使いいただけると思いますー。

Storage Spaces Direct の CSV を BitLocker 暗号化

Storage Spaces Direct (S2D)の CSV を BitLocker 暗号化について、確認する必要があったので、ここに記録しておきます。

BitLocker and Cluster Shared Volumes in Hyper-V Scenarios
Protecting cluster shared volumes and storage area networks with BitLocker
を参考します。

だた、上記のドキュメントは、一部違いがあります。
BitLocker and Cluster Shared Volumes in Hyper-V Scenarios
では、
Get-ClusterSharedVolume “Name of CSV” | Suspend-ClusterResource
としています。
Protecting cluster shared volumes and storage area networks with BitLocker
では、
Get-ClusterResource "Cluster Disk 1" | Suspend-ClusterResource
となっています。

Windows Server 2019としては、どちらになるかというと、BitLocker and Cluster Shared Volumes in Hyper-V Scenariosのほうです。
確認してみましょう。

CSV こと、クラスター仮想ディスクは、ClusterResource ではなく、ClusterSharedVolume に分類されています。
ということで、BitLocker 暗号化の前に、
Get-ClusterSharedVolume “Name of CSV” | Suspend-ClusterResource
を実行します。
BitLocker 暗号化の後に、
Get-ClusterSharedVolume “Name of CSV” | Resume-ClusterResource
を実行します。

では、
BitLocker 暗号化を有効化するために、S2D の各ノードで、BitLocker をインストールします。
こういうスクリプトで実行させます。有効化が完了したら各ノードを再起動しましょう。

Invoke-Command ($ServerList) {
Install-WindowsFeature -Name $Using:Featurelist -IncludeAllSubFeature
#Restart-Computer -Force
}

※CSVの同期をきちんと取りたいので、再起動はコメントアウトしてますw
S2D 有効化前であれば、問答無用で再起動します。


BitLocker がインストールされると、Get-BitLockerVolume を使って各ボリュームの暗号化状況を確認できるようになります。


では、Volume03 を BitLocker 暗号化してみます。
まずは、CSV をサスペンドします。



失敗します。（理由は後述）


いったん、resume するのですが、このコマンドレットではダメで、

Resume-ClusterResource CSVの仮想ディスク名
を実行したほうが良いみたい。

さらに、サスペンドしないとどうなるかということですが、こちらも失敗します。


先ほどの失敗について、種明かしをします。
Volume03 のオーナーシップがありません。


Volume03 のオーナーシップを PowerShell の実行ノードに移動します。


サスペンドからやり直してみます。


サスペンドしても、Volume03 のパスは存在していますね。
CSV のオーナーシップを PowerShell の実行ノードが保有しているかは、必ず確認です。
※要するに、このあたりちゃんと確認しないで、一度検証していたということですw

下記コマンドレットは、クラスターのコンピューターアカウントを指定することで、どのノードからも暗号化された CSV にアクセスできるという寸法のようですね。
Enable-BitLocker "C:\ClusterStorage\Volume03" -ADAccountOrGroupProtector -ADAccountOrGroup s2dws2019$
有効化しました。正確には、暗号化が開始されました。進行状況は、
Get-BitLockerVolume|ft -AutoSize
で確認できます。


今回の環境は、RAID5な SSD 上に構築した Nested S2D クラスターで、3 way Mirror な330GB のCSVを暗号化しました。
で、所要時間としては、30分弱でした。暗号化に要する時間は、ストレージのスピード、容量によって変わると考えます。


忘れずに、
Resume-ClusterResource "クラスター仮想ディス ク (Volume03)"
します。


暗号化できたので、仮想マシンのストレージ移行（ライブストレージ移行）を行ってみます。
SCVMM 上のジョブ画面でも、エラーなくライブストレージ移行が完了しました。


非暗号化な CSV に戻してみます（ライブストレージ移行）。

問題なく完了。

確認は、以上で終わり。

CSV が Cluster Resource ではなく、Cluster Shared Volume に分類し直されているなど、最近の Windows Server ではマイナーな仕様変更があります。
このあたりを読み替えながら、
BitLocker and Cluster Shared Volumes in Hyper-V Scenarios
Protecting cluster shared volumes and storage area networks with BitLocker
の手順に沿えば、CSV の BitLocker 暗号化は可能です。