powershell vs GPOインストール、構成、メンテナンス用
私の質問は、PowerShellスクリプトを使用して、2008R2ドメインでWindows 7 Pro/Entワークステーションをインストール、構成、更新、および保守することと、GPO/ADMX/msiを使用することについてです。
状況は次のとおりです。
累積的な企業の大騒ぎのコメディーのために、私たちは突然、完全なWindows Server2008R2とWindows7 Pro/Enterpriseを非常に短い通知と配信スケジュールで設計、構成、および展開する必要があることに気付きました。もちろん、私は決してWindowsの専門家ではありません。人員が不足しているため、流行語のビンゴには「自動」と「ワンボタン」、「ただ機能する必要がある」が含まれています。 （FWIW、私はDECから始め、次にsolarisとCisco、そして最近ではBSDが少し入ったさまざまなフレーバーのLinuxに進みました。私は電子メールとフォームへの入力にWindowsを使用しています）。
そこで、私たちはこれを行うために請負業者を連れてくることにしました。そして彼らは締め切りに間に合いました。システムは稼働していて、ほとんど使用可能であり、これは良好です。私たちはこれを行うことができなかっただろう。しかし、現在PIMAであることが証明されているのは「ほとんど」の部分であり、継続的な運用のためにこれらの人と新しい契約を結ぶことができるまで、とにかくマイクロソフトのことを学ぶ必要があります。
これが私の質問です。請負業者は、展開、構成、および更新にほぼ独占的にPowerShellを使用していました。先週の私の集中的な読書は、Microsoftのものの展開、構成、および更新のための一般的に受け入れられている慣行が、おそらくPolicyPakのようないくつかのサードパーティのものとともにGPOとADMXテンプレートの要素を使用していると思います。
GPOメソッドよりもPowerShellスクリプトが優先されるという確かな理由はまだありませんか？
私は彼が休暇から戻ったときに請負業者のリーダーとこれについて話し合うつもりです、そして彼は私とまっすぐになります（また彼らが私たちを設定したとは思いません）。しかし、これは宗教的な問題かもしれないこともわかりますので、それでも背景を教えてください。
考え？またはウェブリンク？
ありがとう！
ここには「正しい」答えはありません。私の個人的な好みは、設定/ポリシーにグループポリシーを使用することですが、アプリケーションの展開には、複雑な信頼の問題がない単一のドメインがあると仮定して、PowerShell（またはレガシーWSHスクリプトやバッチファイル）を使用します。ただし、トレードオフがあります。 PowerShellですべてを行うことは確かに合法です。
アプリケーションの展開（GPOとスクリプト）：
GPOベースのソフトウェア展開では、MSIパッケージに制限されます。これは、MSI経由で配布されない製品（setup.exeなど）にとっては煩わしい場合があります。その場合は、パッケージ化する必要があります。 AdobeReaderのMSI + MSPディストリビューションをお楽しみください（AIPを作成する必要があります）。インストールをカスタマイズする必要がある場合は、MSI変換をいじる必要があります。スクリプトの1行である可能性があるものは、複雑なマルチになる可能性があります。 -ステッププロセス。
展開するすべてのものがMSIとしてすぐに利用可能であり、特別なカスタマイズなしでインストールできる場合、GPO展開は非常にスムーズです。WMIターゲティングを使用して、不足しているものを自動的にアンインストールできます。ポリシー。ただし、そのボックスの範囲を超えると、状況はさらに複雑になります。また、問題が発生した場合、イベントビューアから何が起こったのかを把握するのが難しい場合があります。
スクリプトを使用すると、MSI、EXEなど、ほとんどすべてのものをインストールまたはアンインストールできます。インストールする前にクリーンアップ作業を行う必要がある場合（たとえば、クリーンにアンインストールされなかった以前のバージョンから古いレジストリキーを削除するなど）、それを行うことができます。問題が発生した場合は、必要な数のデバッグ/再試行/回避策コードを追加でき、ロギングを有効にしてmsixecを実行できます。
通常、スクリプトには、ソフトウェアが既にインストールされているかどうか（およびそのバージョン）を確認し、必要に応じてインストーラーを呼び出すための条件付きロジックが必要です。プログラミングのバックグラウンドがない場合、これは恐ろしいことです。ポイントアンドクリックソリューションではなくなりました。自分で書いたので、何かを台無しにする機会も増えます。
アプリケーションの展開のためにGPOからPowerShellに切り替えたため、作業が非常に簡単になりました。新しいバージョンがリリースされたら、AppDeployment共有に新しいインストーラーファイルをドロップするだけです。スクリプトの$ expected_version変数を更新します。1/ 10の時間かかります。
GPO MSI関連のものとその他すべてのスクリプトに使用するハイブリッドアプローチを実行することもできます。インストールされているものを確認するために1つの場所が必要なので、私はこれが好きではありません。 。
グループポリシーでは、アプリケーションの展開は再起動するまで行われないことに注意してください。スタートアップスクリプトを使用している場合、これも当てはまります。ただし、 PowerShell Remoting またはスケジュールされたタスクを使用すると、再起動せずにそれを実行できる場合があります（ただし、面倒になる可能性があります）。
設定と構成（GPOとスクリプト）：
グループポリシーの基本設定は、レジストリ値の作成、ネットワークドライブのマップ、ショートカットの作成などを行うのに非常に簡単に使用できます。ユーザーに再起動を強制せずに設定を適用できるため、グループポリシーにバックグラウンド更新があるという事実は巧妙です。アイテムレベルのターゲティングにより、多くの柔軟性が得られます（これは、GPOレベルでのWMIおよびセキュリティフィルタリングに追加されます）。
ただし、グループポリシーの基本設定は完全にはほど遠いです。私のピーブズのいくつか：
Internet Explorerを管理するには方法が多すぎます。廃止された方法もあれば、最新のIEで機能しない方法もあります。私はいつもレジストリ設定を直接管理するだけになってしまいます。
愚かなイベントビューアのランダムエラー。例：スケジュールされたタスクを削除するアイテムを作成しました。すばらしい、それは私のすべてのワークステーションからなくなった。これで、イベントビューアに、「タスクが存在しないため、タスクを削除できませんでした」というエラーが表示され始めます。えっ！
一度適用し、再適用しないでください あなたのキャリアの中で少なくとも一度はあなたを台無しにします 。
更新と置換 。おそらく間違ったものを選ぶので注意してください。
アイテムレベルのターゲティングでできることには制限があります。 for（）ループまたは文字列操作（文字のトリミング、大文字と小文字の調整）が必要な場合は、スクリプトに戻ります。
GPPファイル操作は、ファイルが変更されていない場合でも常に発生します。ワークステーションは、必要がない場合でも、同じファイルをサーバーから何度もコピーし続けます。これにより、サーバーとネットワークが予期せず打撃を受ける可能性があります。アイテムレベルのターゲティングはこれを軽減するのに役立ちますが、[適用されていない場合は削除]がオンになっているかどうかを確認してください。
イベントビューアのGPPエラーの多くには、実際に問題を修正するための有用な情報が含まれていません。 トレースをオンにする する必要があります。
設定にPowerShellを使用できますが、いくつかの欠点もあります。
PowerShellを使用したレジストリ設定の管理は面倒になります（少なくともネイティブレジストリプロバイダーでは）。私の意見では、Microsoftは、レジストリ値を実際のアイテムではなく「プロパティ」にしたときに失敗しました。それは物事を必要以上に複雑にします。値を作成する前に、レジストリキーをテストして作成するには、一連の条件付きロジックが必要です。この領域では、グループポリシーははるかに単純です。
PowerShellではネイティブに実行できない「基本的な」sysadminタスクがたくさんあります（ショートカットの作成、スケジュールされたタスクの管理など）。 Wsh、.Net Frameworkを呼び出すか、サードパーティのモジュールを使用する必要があります。
スクリプトは起動時/ログオン時にのみ実行されます。バックグラウンドの更新はありません（スケジュールされたタスクを設定しない限り）。
従来のウィンドウコマンドユーティリティ（net.exe、schtasks.exe）を呼び出す必要がある場合、コマンドを呼び出すのは難しい場合があり、画面出力をPowerShellの出力とうまく再生させるにはさらに「難しい」場合があります。コマンドが失敗し、それがわからない場合があります。
スクリプト（PowerShellまたはその他）とGPOに関するその他の一般的なコメント：
スクリプトはほとんどプログラミングプロジェクトです。コードwillは成長し、時間の経過とともにより複雑になります。コメント、バージョン履歴、サブルーチンなどを含む「実際の」プログラミングプロジェクトのように扱わない場合は、will維持不可能な混乱に発展し、後継者はそれを理解していなかったために廃棄してしまいます。
システム管理者は（一般的に）プログラマーではありません。彼らは適切なプログラミング分野を知りません（ポイント＃1を参照）。適切に構造化されたコードでさえ、プログラミングのバックグラウンドを持たない管理者にとっては威圧的で読みにくい場合があります。現在および将来のスタッフのスキルセットに注意してください。
スクリプトには、バージョン管理にチェックインして差分をとることができるという利点があります。 GPOの場合、これを行うのは少し難しいです。
スクリプトはUSBキーにコピーして持ち運ぶのが簡単です。それはおそらくあなたの請負業者の場合でした。彼はおそらく、あなたのプロジェクトのためにリサイクルすることができた以前のプロジェクトからのいくつかの既存のスクリプトを持っていました。私の環境では、エアギャップのある2つのネットワークがありますが（質問しないでください）、構成は似ているため、可能な限りPowerShellスクリプトを使用して、2つのネットワーク間でコードをリサイクルできるようにします。
GPOには、 RSoP などのツールを使用して、特定のワークステーション/ユーザーに適用されたすべての設定のレポートを取得できるという利点があります。これは、監査とトラブルシューティングにとって重要な場合があります。
GPOはより「発見可能」です。なじみのない環境に入ると、どのポリシーと設定が適用されているかをすぐに理解できます。スクリプトを使用して、コードの学習を開始する必要があり、十分にコメントされていることを願っています。
PowerShell Remoting 多数のシステムで実行したい、「永続的な」ポリシーにしたくない（たとえば、誰もがこれを削除する）1回限りのコマンドには非常に便利です。一時ファイル）。
使用するアプローチに関係なく、物事が十分に文書化されていることを確認してください。 microレベル（「アプリケーションyの問題を解決するためにすべてのアカウンティングワークステーションに設定xを実装」）で文書化する必要があります。 macro-level（ "すべてのワークステーション設定はGPO xと呼ばれる"）に保存されます）。
フォローアップ編集：PowerShell 4は、 必要な状態の構成 という新機能を追加します。これは、グループポリシー設定の機能の一部を実現するために使用できるようです。それはゲームチェンジャーかもしれません。まだ使用していませんが、とてもかっこいいです。
フォローアップ編集2：私が気付いたのは、 グループポリシーポリシー）を適切に区別していなかったことです。 vs設定 。設定は、PowerShellスクリプトとほとんど同じです。ポリシーはもう少し「厳密」であり、スクリプトで実装するのは難しいです。そのためには、スクリプトでHKLM\Software\Policiesを作成する必要がありますが、GPOとの衝突に注意する必要があります。その場合は、両方ではなく、どちらか一方を実行してください。
明らかに、マイクロソフトは、グループポリシーがクライアント構成の大部分を処理するための最良の方法であると信じています（そしてほとんどの人が同意しています）。インターフェースは単純明快で、ほとんどの設定では、キーボードに触れる必要さえありません。レポート機能も組み込まれています。
誰かが自分で攻撃してPowerShellログインスクリプトを使用するのを私が見ることができる唯一の理由は、GPが処理しないある種のカスタムレポートまたは独自の機能です。
また、Windowsがインストールされている場合、PowerShellスクリプトはデフォルトで無効になっています。ただし、心配しないでください。これを変更するためのグループポリシーオプションがあります。
全体的な構成、グループポリシーについては、それが設計されたものです。
ソフトウェアのインストールでは、PowerShellを100％選択します。 GPOを介したソフトウェアパッケージの公開/割り当ては不適切な方法であり、ログオン/ログオフスクリプトを実行するのはあまり好きではないと言われています。どちらかを起動できるPowerShellスクリプトを用意してくださいユーザーがイントラネットの場所から、またはPSRemotingを使用して自分でインストールを起動します。PSRemotingを使用すると、コマンド（Invoke-Commandまたはicm）を呼び出して、ドメイン内の1台、多数、またはすべてのコンピューターにコマンドを送信できます。
メンテナンスにはPowerShellスクリプトを使用しますが、メンテナンスとはどういう意味かわかりません。
展開にPowerShellを使用するのは、以前に実行したことがあり、スクリプトのテンプレートがある方が簡単だからです。設定する必要のあるすべてのユーザー/コンピューター/役割/機能についてGUIを操作する代わりに、これを使用できます。
コンサルティングフェンスの両側での以前の経験から、PowerShellスクリプトはコンサルタントが一般化するのが簡単だと思います。そこにあるさまざまなOUターゲティングを考慮して、GPOをエクスポート/インポートするよりも、PSスクリプトをあるクライアントサイトから別のクライアントサイトに移動して詳細を変更する方が簡単です。
Win7ワークステーションの保守について話している場合は、Microsoft System Center、Kaceなどの専用のシステム管理ユーティリティも検討する必要があります。以下は、状況にある程度類似しているように思われます。
ドメイン内のWindowsワークステーションでタスクを（堅牢に）リモートで実行するにはどうすればよいですか？
あなたはできた PowerShell/GPOでやりたいことをすべて行う（私は本当に新しいPS4の望ましい状態の構成の調査に興味がある）が、多くの場合、専用システムで時間を節約できます/お金。