これは、PowerShell DSC Advent Calendar 2014 - Adventar 5日目の記事です。
4日目は、DSC の2つのモード PUSH、PULL と利用シーンを説明しました。
今日はDSCのエンジンについてずらっとみてみましょう。シンプルですが大事な機能なので抑えておきましょう。
目次
- 目次
- Local Configuration Manager
- LCM のパラメータ状態を調べる
- LCMのパラメータを設定する
- MOFの競合を避ける方法
- v4 と v5 (Preview) のパラメータ比較
- PUSH/PULL 両方に影響するパラメータ
- PULL に影響するパラメータ
- まとめ
Local Configuration Manager
DSC のエンジンは、 Local Configuration Manager (以下LCM)と呼びます。
DSC の挙動や現在の構成、定期実行などはすべてこの LCM が制御しているので一般に DSC のエンジン と称されます。
今回は、LCMについて以下を見ていきます。
- LCM のパラメータ状態を調べる
- LCMのパラメータを設定する
- MOFの競合を避ける方法
- v4 と v5 (Preview) のパラメータ比較
LCM のパラメータ状態を調べる
まず現在のLCMにどんなパラメータが設定されているのか確認できないと話しになりません。管理者権限で起動した PowerShell で Get-DscLocalConfigurationManagerを実行することでLCMに設定されている状態を確認できます。
Get-DscLocalConfigurationManager
PowerShell v4
まずはPowerShell v4 の、何も設定していない LCM状態を見てみましょう。
$PSVersionTable
Name Value
---- -----
PSVersion 4.0
WSManStackVersion 3.0
SerializationVersion 1.1.0.1
CLRVersion 4.0.30319.34014
BuildVersion 6.3.9600.17090
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0}
PSRemotingProtocolVersion 2.2
Get-DscLocalConfigurationManagerの実行結果です。
AllowModuleOverwrite : False CertificateID : ConfigurationID : ConfigurationMode : ApplyAndMonitor ConfigurationModeFrequencyMins : 30 Credential : DownloadManagerCustomData : DownloadManagerName : RebootNodeIfNeeded : False RefreshFrequencyMins : 15 RefreshMode : PUSH PSComputerName :
これは、まだ何も構成していない Windows Server 2012 R2 での実行結果です。
RefreshMode にある通り、PUSH モードが既定であることがわかりますね。
PowerShell v5 November Preview
PowerShell v5 では、DSC が現在抱えるバグと使い勝手の悪さが改善されます。その肝になるポインtのがLCMにも表れています。
最新のWMF5 November Preview で何も設定していない LCM状態をみてみましょう。
$PSVersionTable
Name Value
---- -----
PSVersion 5.0.9814.0
WSManStackVersion 3.0
SerializationVersion 1.1.0.1
CLRVersion 4.0.30319.34014
BuildVersion 6.4.9814.0
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.2
Get-DscLocalConfigurationManagerの実行結果です。
AllowModuleOverWrite : False
CertificateID :
ConfigurationDownloadManagers : {}
ConfigurationID :
ConfigurationMode : ApplyAndMonitor
ConfigurationModeFrequencyMins : 30
Credential :
DebugMode : False
DownloadManagerCustomData :
DownloadManagerName :
LCMCompatibleVersions : {1.0, 2.0}
LCMState : Ready
LCMVersion : 2.0
MaxPendingConfigRetryCount :
StatusRetentionTimeInDays : 7
PartialConfigurations : {}
RebootNodeIfNeeded : False
RefreshFrequencyMins : 30
RefreshMode : PUSH
ReportManagers : {}
ResourceModuleManagers : {}
PSComputerName :
細かいパラメータの意味を紹介する前に、LCM のパラメータを設定する方法を紹介します。
LCMのパラメータを設定する
LCM の設定には、コンフィグレーション構文を用います。*1
コンフィグレーション構文自体の説明は後日行うので、RebootIfNeeded のパラメータだけ false から true にする構成を書いてみましょう。
コードは次のようになります。
Configuration LCM
{
Node localhost
{
LocalConfigurationManager
{
RebootNodeIfNeeded = $true
}
}
}
どうですか？Key/Value で宣言されており、なんとなくでもやろうとしていることがわかると思います。
これを、自分自身のLCM に適用する流れを見てみましょう。
MOFの生成
コンフィグレーションを実行(コンパイル)して MOF ファイルを生成する必要があります。
コードは次のようにLCM -OutputPath LCM を追加しました。
Configuration LCM
{
Node localhost
{
LocalConfigurationManager
{
RebootNodeIfNeeded = $true
}
}
}
LCM -OutputPath LCM
コンフィグレーションの実行 は、 Configuration の後ろに書いた名称を指定します。(今回は LCMというコンフィグレーション名)
実行時のパラメータ-OutputPath に指定した値がポイントです。(今回はLCMを指定)
-OutputPath に指定した任意のパスが MOFファイルの生成先となります。
今回の場合、-OutputPath に指定したLCMで現在のパスにフォルダが自動的に作成され、 Nodeに指定した名称の MOFファイル をフォルダ内に生成します。(localhost.meta.mofが生成されました)
Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 2014/12/05 23:41 826 localhost.meta.mof
meta.mof ファイルは特殊な MOFファイル なのですが、説明は後述します。
MOF の適用
MOFファイルが生成できたら、対象のノード(今回は自分自身)のCIMに設定を指示します。
この時使うのが、Set-DscLocalConfigurationManager Cmdlet です。状態取得がGetで、状態設定が Setです。
コードには、 Set-DscLocalConfigurationManager -Path LCM を追加しました。
Configuration LCM
{
Node localhost
{
LocalConfigurationManager
{
RebootNodeIfNeeded = $true
}
}
}
LCM -OutputPath LCM
Set-DscLocalConfigurationManager -Path LCM
これで、コンフィグレーションがlocalhost(つまり自分)に設定されました。
LCM設定結果の確認
Get-DscLocalConfigurationManager を使って結果が変わったことを確認しましょう。
AllowModuleOverwrite : False CertificateID : ConfigurationID : ConfigurationMode : ApplyAndMonitor ConfigurationModeFrequencyMins : 30 Credential : DownloadManagerCustomData : DownloadManagerName : RebootNodeIfNeeded : True RefreshFrequencyMins : 15 RefreshMode : PUSH PSComputerName :
コンフィグレーションで指定した通り変化しました。
| 変更前 | 変更後 |
|---|---|
RebootNodeIfNeeded : False |
RebootNodeIfNeeded : True |
これでLCMの構成は完了です。LocalConfiguration Manager の構成は、指定したパラメータのみ変更され他は維持されることを覚えておいて下さい。
リモートノードへの適用
自分自身でない ノードが対象の場合は当然認証を渡す必要があります。(ADに参加しているサーバー同士なら不要です)
認証の渡し方には、2つ選択肢があります。
- CIMセッションの利用
- Credential に認証を渡す
見ていきましょう。
CIMセッションの利用
CIM には、WSMan を使ったリモートマネージメントプロトコルがあることは用語で説明しました。
以下のコードで CIMセッションを使って リモートノード(10.0.0.10) にLCM設定が可能です。Set-DSCLocalConfigurationManagerの実行時にCredential に認証を渡してもいいのですが、valentia を使っていない環境ではCIMを使うことを推奨します。*2
Configuration LCM
{
Node 10.0.0.10
{
LocalConfigurationManager
{
RebootNodeIfNeeded = $true
}
}
}
LCM -OutputPath LCM
$cim = New-CimSession -Credential (Get-Credential) -ComputerName 10.0.0.10
Set-DscLocalConfigurationManager -Path LCM -CimSession $cim
Credential に認証を渡す
認証方式を接続時に変更するなど特殊な操作をしない場合は、CIMセッションを一々作らずとも直接 -Credential に認証情報を渡すことも可能です。
その場合は、以下のコードとなります。
Configuration LCM
{
Node 10.0.0.10
{
LocalConfigurationManager
{
RebootNodeIfNeeded = $true
}
}
}
LCM -OutputPath LCM
Set-DscLocalConfigurationManager -Path LCM -Credential (Get-Credential) -ComputerName 10.0.0.10
MOFの競合を避ける方法
リモートホストにLCMを適用する時には、Node に対象(リモートホストのIPやホスト名)を指定することで、コンフィグレーション実行時にノード名で MOF ファイルが生成されます。
Set-DscLocalConfigurationManager実行時に、-Path に MOFファイルを生成したフォルダを指定すると、「フォルダに存在する MOFファイルの中からノード名を含むMOFファイルが合致したものが適用」されます。
Set-DscLocalConfigurationManager実行時に、-ComputerNameやCIMSessionにMOFと合致するノードを指定することはとても大事です。
ComputerName を指定しなかった場合
つまりこうです。
Configuration LCM
{
Node 10.0.0.10
{
LocalConfigurationManager
{
RebootNodeIfNeeded = $true
}
}
}
LCM -OutputPath LCM
Set-DscLocalConfigurationManager -Path LCM -Credential (Get-Credential)
-Pathに存在する「全MOFファイル名のホスト」に対してLCMの適用が行われます。
localhostだけにしか常にLCM設定をしないのなら問題ありません。が、もし以前に他ノードのMOFファイルを生成してあった場合は、Set-DscLocalConfigurationManager実行時に意図しないノードにも MOFの適用を試みることになります。
意図しない動作とならないように、MOFの競合に注意してください。
ComputerName を指定した場合
つまりこうです。
Configuration LCM
{
Node 10.0.0.10
{
LocalConfigurationManager
{
RebootNodeIfNeeded = $true
}
}
}
LCM -OutputPath LCM
Set-DscLocalConfigurationManager -Path LCM -Credential (Get-Credential) -ComputerName 10.0.0.10
-Path に指定したフォルダから「Computer名に指定した名称のMOFファイルを探して」ノードに設定を試みます。
実行対象が限定されるので、大事大事。
無用な混乱を防ぐため
MOFがコンフィグレーションの実行で生成されるので、MOFの競合を意識しないと MOF地獄になります。
MOFの競合を避けるには、いくつかの手法があります。
Set-DSCLocalConfigurationManager実行後にMOFファイルを消すようにする- MOFファイルの生成先を(コンフィグレーションの
-OutputPath)をホストごとに指定して競合をさける Set-DscLocalConfigurationManagerを、DSCサーバーからノードに実行するのではなく、対象ノード自身で実行する
謎社の場合
LCMの構成時には、3を利用しています。
まっさらなインスタンスを生成時に、そのホスト自身に必要なLCMコンフィグレーションを自動的にダウンロード、実行することで MOFの競合が避けられます。
これにより、Nodeには常に localhostを指定するだけ、構成もシンプルに保つことができます。
他にも、valentiaを使うことで3を実現することができます。
v4 と v5 (Preview) のパラメータ比較
LCMの状態確認、パラメータ設定方法がわかったところで、どんなパラメータがあるのかを見てみましょう。
LCM にはいくつかのパラメータがありますが、PUSH と PULL では影響するものが違います。
今回の記事では、最新の v4 と v5 Preview について、LCM パラメータの有無(ある場合はデフォルト値)、PUSH/PULL それぞれへの影響を比較していきます。
パラメータが存在がない場合は、- としておきます。
| LCM Parameter Name | v4 | v5 Nov Preview | PUSH | PULL |
|---|---|---|---|---|
| AllowModuleOverWrite | False | False | x | o |
| CertificateID | null | null | o | o |
| ConfigurationDownloadManagers | - | {} | x | o |
| ConfigurationID | null | null | x | o |
| ConfigurationMode | ApplyAndMonitor | ApplyAndMonitor | x | o |
| ConfigurationModeFrequencyMins | 30 | 30 | x | o |
| Credential | null | null | x | o |
| DebugMode | - | False | o | o |
| DownloadManagerCustomData | null | null | x | o |
| DownloadManagerName | - | null | x | o |
| LCMCompatibleVersions | - | {1.0, 2.0} | o | o |
| LCMState | - | Ready | o | o |
| LCMVersion | - | 2.0 | o | o |
| MaxPendingConfigRetryCount | - | null | o | o |
| StatusRetentionTimeInDays | - | 7 | o | o |
| PartialConfigurations | - | {} | x | o |
| RebootNodeIfNeeded | False | False | o | o |
| RefreshFrequencyMins | 30 | 30 | x | o |
| RefreshMode | PUSH | PUSH | o | o |
| ReportManagers | - | {} | x | o |
| ResourceModuleManagers | - | {} | x | o |
| PSComputerName | 実行された対象PCが表示 | 実行された対象PCが表示 | - | - |
どうでしょうか？
- LCMのバージョンなど多くの新パラメータが v5 (Preview)で追加
- PUSH に影響するパラメータは少ない
- PULL には全パラメータが影響
それでは、PUSH/PULL両方に影響するパラメータ、PUSH向けのパラメータ、PULL向けのパラメータを見ていきましょう。
なお、PowerShell v4 におけるパラメータは以前 @IT へ寄稿した記事にある程度まとめています。今回も、改めてさらっと触れます。
PUSH/PULL 両方に影響するパラメータ
まずは、PUSH と PULL の両方に影響するものがどれか見ておきましょう。
CertificateID
CertificateID には。ノード/サーバーが利用する証明書の Thumbprintを指定します。
一般にパスワードなどは機密情報とされるのはご存知の通りです。広く使われる暗号化手法が証明書を利用した「信頼の担保」と「ハッシュ値による暗号化/復号化」です。
Windows も証明書を利用した暗号化/復号化が一般的に用いられており、DSC でも[PSCredential] などは証明書で暗号化するのがベストプラクティスです。
DSCで利用される証明書の指定をするのが、CertificateID です。
サンプルだと、こんなデータですね。*3
1847HFN47RGILJA3423ZEQR82346YS8UOIFW24K4
DebugMode (v5 で追加)
設定可能な値は、[bool] です。
DSC の動作モードをデバッグにするか、しないかの設定です。
- Trueを指定してデバッグにすることで、PUSH で ノードに対してコンフィグレーションを適用する際にデバッグが可能となります。
- パフォーマンス面などから、デバッグ時以外は FALSE にしておくべきです。
LCMState (v5 で追加)
ReadOnly のパラメータです。設定はできません。
LCM は常に一つの状態しか持ちません。状態は、新しい構成を受付可能な アイドル状態と、構成を適用/取得中のビジー状態を遷移しています。
アイドル -> ビジー -> アイドル -> ビジー....
PowerShell v4 における DSC では、LCM の状態が ビジーな最中にLCMに問い合わせをすると必ず例外が吐かれます。結果、ノードだけでなく自分自身の LCMの状態を把握することも困難というさいてーな状態が発生しえます。*4
v5 においては、LCM に LCMState を持つことで、ビジーかどうかが判定可能になります。これはかなりプライオリティの高い問題なので大変重要です。
LCMVersion (v5 で追加 / 最新のv4 でもみれたり)
ReadOnly のパラメータです。設定はできません。
3日ほど前に起動した Windows Server 2012 R2 で、これまでになかった LCMVersion が取得できていました。*5そのため、v5からではないと思います。
LCM のバージョンは、DSC のコンフィグレーションの記述、LCMの持つパラメータの判断材料となります。
StatusRetentionTimeInDays (v5 で追加)
まだ詳細が公開されていないパラメータです。
名前からすると LCMの状態がロテートする間隔(日) のようですが。
RebootNodeIfNeeded
コンフィグレーションを実施した時に、リソースによっては適用時に再起動を求めるフラグを指定していることがあります。
RebootNodeIfNeeded には[bool]で値を指定可能です。
- True を指定すると、コンフィグレーションの再起動が求められた場合に再起動をします。
- False を指定すると、自動的な再起動を抑止できます。
RefreshMode
設定可能な値は、PUSH か PULL です。
そのノードのLCM が、PULL として挙動するか、PUSH として挙動するかはここに依存します。
- PUSH を指定すると、PUSHモードになります。
- PULL を指定すると、PULLモードになります。
RefreshMode の変更は、Set-DscLocalConfigurationManagerを実行するだけではだめで、Windows Management Instrumentationサービスの再起動が必要です。
さくっと行うなら、以下のサービス再起動を利用しましょう。
Get-Service Winmgmt | Restart-Service -Force
PULL に影響するパラメータ
続いて PULL でのみ影響するパラメータを見ていきます。
Credential
設定可能な値は、[PSCredential] です。
Credential は、ノードが PULLサーバーに問い合わせに行く時に利用する 認証情報となります。
PULLのDSCサーバーが、対象のノードを制限する時に使う認証と思ってください。
個人的には、認証よりIPアドレス制限などもっと根本で制御するか、組み合わせるべきだと思います。Webサーバーのベストプラクティスと同様ですね。
AllowModuleOverWrite
設定可能な値は、[bool] です。
PUSH モードでは、コンフィグレーションで利用するリソースをコンフィグレーションの実施前に自分でそのノードに置いておく必要があります。そのためこのパラメータは関係しません。
一方でPULLモードでは、ノードはコンフィグレーションを実施する前に必要なリソース(PowerShellモジュールとしてかかれています)を一緒に取得します。
もっと新しいモジュールがサーバーに存在した場合、
- True を設定すると、ノードはサーバーから最新のモジュールを取得します。
- False を設定すると、ノードはサーバーから最新のモジュールを取得しません。
重要
このパラメーターは、最新のモジュールがあった場合はそれを取得する便利な機能です。
が、v4 では挙動が怪しく、モジュールの最新バージョンを取得時にエラーが出ることが多発します。このバグは、v5 で修正されています。
ConfigurationDownloadManagers (v5 で追加)
ResourceModuleManagers (v5 で追加)
ReportManagers (v5 で追加)
設定可能な値は、[CIMInstance[]] です。
v4 と v6 の大きな違いの一つに、これまで v4では ノードが参照できた PULLサーバーは1つでしたが、これを役割ごとに分割、複数対応しました。
以下に分割されています。
- ConfigurationDownloadManagers : ノードが取得する、コンフィグレーションのDSCサーバー
- ResourceModuleManagers : ノードが取得する、コンフィグレーションに利用するモジュールの先DSCサーバー
- ReportManagers : コンフィグレーションの設定結果のレポート先サーバーDSCサーバー
ですが、まだ詳細の設定方法が公開されていません。
ConfigurationID
設定可能な値は、[String]です。(GUID形式で指定します)
PULLモードのノードは、DSCサーバーにてどの「あるべき状態」の MOFファイルファイルを取得すればいいﾉか判断する必要があります。
この時、ノードが自分が取得しないといけないMOFファイルをDSCサーバーにリクエストする時に使われるのが、 ConfigurationIDです。
PULLのDSCサーバーには、MOFにはノードに対応する [ConfigurationID].mof とそのハッシュ値を記述した [ConfigurationID].mof.checksum を設置します。
PULLのノードには、ConfigurationID に参照するMOFの [ConfiguraionID] をLCMに設定します。
ConfigurationMode
設定可能な値は、ApplyAndAutoCorrect、ApplyAndMonitor、Apply の3つです。
4日目に詳細を書いていますのでどうぞ。
PULLでは、ノードが「あるべき状態を適用後、どのように動くのか」を3つの基準から1つ選べます
ふつーは、ApplyAndAutoCorrect で自動復旧を可能にしますね。
設定 概要 ApplyAndAutoCorrect 対象サーバーが自分で継続的にDSCサーバーへ構成のずれを確認しに行き、ずれが生じていた場合自分を構成する。 ApplyAndMonitor 対象サーバーが一度だけDSCサーバーから構成を取得して適用。以降は定期的に自分があるべき状態とずれてないか監視するが、ずれがあっても勝手に復旧しない。 Apply 対象サーバーが一度だけDSCサーバーを構成を取得して適用します。以降は差異がないか確認もしない。 PULLの動作モードは↓の図を参考にどうぞ。
ConfigurationModeFrequencyMins
設定可能な値は、[int] です。(最小値 30)
一度DSCであるべき構成を適用すると、ノードのあるべき状態はLCM にキャッシュされます。
ConfigurationModeFrequencyMins の間隔に従って、「LCMにキャッシュされたあるべき状態」と「現在のノードの状態」を比較します。
注意
設定可能な最小の値は 30分です。
また、ConfigurationModeFrequencyMinsの値は、後述するRefreshFrequencyMinsの倍数である必要があります。もし異なる数値を指定した場合は、自動的にRefreshFrequencyMinsに対して2倍の値になります。。
DownloadManagerCustomData
v4 では、PULLサーバーとなるDSCサーバーを指定しました。
v5では、コンフィグレーションの指定やリソースの指定が分離しましたので、設定がどうなるのか少し謎です。
以下は v4 での指定例です。
DownloadManagerCustomData =
@{
ServerUrl = "https://Dsc.PullServer.contoso.com:8080/PSDSCPullServer/PSDSCPullServer.svc"
AllowUnsecureConnection = "false"
}
ServerUrl
ノードが参照するPULLサーバーエンドポイントを指定します。
AllowUnsecureConnection
[bool] を指定できます。
- false は、既定/推奨です。 falseを指定するとHTTPS 接続になります。
- True を指定すると、HTTP接続になります。
Verify された証明書が必要なので、True にするには考慮点が多いのが面倒ですね。
DownloadManagerName
設定可能な値は、WebDownloadManager と DSCFileDownloadManager です。
PULLモードで、ノードとDSCサーバーが通信するプロトコルには2つ方法があります。
- HTTP/HTTPS :
WebDownloadManagerを指定 - SMB :
DSCFileDownloadManagerを指定
一般に、HTTP/HTTPS は、NAT/ファイアウォールを超えることが容易なため外部エンドポイントにするときに好まれます。SMBは、NAT/ファイアウォール越えが面倒なため、内部利用のみなら、まぁ。
SMBは使えない
- HTTP/HTTPS では、DSCサーバーでノードの構成状態など一覧が取得可能です。*6
- SMBでは、ノード一覧や状態を取得できません。これは、ノードの状態把握が困難になるため、SMBはかなり使えないです。
ノードの状態把握
HTTP/HTTPSなら ノードの状態をJSON で取得できます。
謎社ではラップ、拡張して以下のようにノードの状態を一覧取得可能にしています。
TargetName : 192.168.100.10 ConfigurationId : 1847HFN47RGILJA3423ZEQR82346YS8UOIFW24K4 ServerCheckSum : ASA4asef6DE23982A2F3C16TJS369FA9E38FE9mkhl69AAS4942234N293B5E5CB TargetCheckSum : ASA4asef6DE23982A2F3C16TJS369FA9E38FE9mkhl69AAS4942234N293B5E5CB NodeCompliant : True LastComplianceTime : 2014-12-02T13:02:13.4431237Z LastHeartbeatTime : 2014-12-02T13:02:13.4431237Z Dirty : True StatusCode : 0
PartialConfigurations (v5 で追加)
PowerShell v5 から Partial Configuration が可能になります。
v4 では、ノードのLCMには1台のPULL サーバーしか指定できず、また 1つのコンフィグレーションを分割して取得/適用することもできませんでした。
v5 の Partial Configuration は、複数のPULLサーバーから あるべき状態を記述したコンフィグレーションをを分割して受け取ることができるようになります。*7
v5 で Partial Configuration をLCMで設定するには、次のようにコンフィグレーションを書きます。
[DSCLocalConfigurationManager()]
configuration v5PULLNodeLCMSetting
{
Node localhost
{
Settings
{
RefreshMode = "Pull"
ConfigurationID = 'a5f86baf-f17f-4778-8944-9cc99ec9f992'
RebootNodeIfNeeded = $true
}
ConfigurationRepositoryWeb PullSvc1
{
serverURL = 'https://wmf5-1.sccloud.lab:8080/OSConfig/PSDSCPullServer.svc'
AllowUnSecureConnection = $true
}
ConfigurationRepositoryWeb PullSvc2
{
ServerURL = 'https://wmf5-2.sccloud.lab:8080/SQLConfig/PSDSCPullServer.svc'
AllowUnsecureConnection = $true
}
PartialConfiguration OSConfig
{
Description = 'Configuration for the Base OS'
ConfigurationSource = '[ConfigurationRepositoryWeb]PullSvc1'
}
PartialConfiguration SQLConfig
{
Description = 'Configuration for the Web Server'
ConfigurationSource = '[ConfigurationRepositoryWeb]PullSvc2'
DependsOn = '[PartialConfiguration]OSConfig'
}
}
}
RefreshFrequencyMins
設定可能な値は、[int] です。(最小値 15)
ノードの LCM にキャッシュされた「あるべき構成」と、DSCサーバーであるべき状態にずれがないかをか確認して適用します。
ConfigurationModeFrequencyMins の間隔に従って、「LCMにキャッシュされたあるべき状態」と「PULLサーバーにあるあるべき構成に変化がないか」を比較しします。
注意
最小の値は 15分です。
また、ConfigurationModeFrequencyMinsの値は、このRefreshFrequencyMinsの倍数である必要があります。
以上でLCMに設定できるパラメータはおしまいです。
まとめ
触りなので、LCMの本体などは後日ですね！
LCMは DSC のまさにエンジンなので、把握しないで DSC使うと困ることになります。コンフィグレーションの初歩としてもLCMの設定を試してみてください。