これは典型パターンですResultには、TestScriptで設定したのと同じロジックを入れます典型が多いのはいいのですが、冗長この上ないですね。必要悪とはこのことなのか...。スクリプトリソースの問題点スクリプトリソースの利用には、たくさん問題があります。型の明示MOFの可読性低下ロジックをコンフィグレーションに直接定義これは、リソースコンセプトの破壊につながりかねないことです。するのか?再利用する場合は、リソースにするのです。コンフィグレーションをリソースにして再利用する方法や、リソースを自分で定義してもいいでしょう。*5ただ、その場限りで再利用もなく、シンプルな場合は許容できると思います。スクリプトリソースを使ってコンフィグレーションを書きたくなったら、再利用する場合はリソースにしましょう変数の参照は$using:スコープConfiguration構文内部でも、PowerShell構文は使えることを説明しました。変数が一番使いやすいでしょう。変数を参照する時は注意が必要です。スクリプトリソースの実態は、リモートで利用することが前提のスクリプトブロックです。この場合、ローカルとはコンフィグレーションを実行するDSCサーバー、リモートとはMOFを読み込むノードです。PowerShellのルールです。スコープは不要ですよ?例えば、先ほどのスクリプトリソースでローカル変数を、コンフィグレーションで参照する場合はこう書きます。ポジショナルパラメータの利用これはリモートスクリプトブロックの制限ですが、ポジショナルパラメータの利用はできません。先ほどの例なら、これはダメということです。パラメータを明示する必要があります。型は明示してください。暗黙の型変換はダメです。[String]を受け取るパラメータには、.ToString()や""で明示的にキャストが必要です。型をあいまいにするなんて避けますよねーふつー(棒)MOFの可読性低下コンフィグレーションを実行した時にMOFファイルがコンパイル生成されます。MOFを読む機会は余りありませんが、ある時はあるのです。読みにくくて仕方ありませんね。コンフィグレーションを1つだけ持てます。コンフィグレーション1つに全部の定義を書かないといけないのかというとそうではありません。ネスト(組み合わせ)が可能です。コンフィグレーション構文の中で、Nodeセクションは1回しか書けません。デフォルトで入ります。Nodeセクションを書きます。簡単ですね!ネスト対象の子コンフィグレーションにもパラメータが渡せます。