現代の技術の開発のペースは、私たちがそれらにほとんど追いつかないほどです。 しかし、今日は少し先に進み、PowerShell v3の革新について学び、目だけでなく手でも調べます。
スタンド
Hyper-Vの下でWindows Server 2012 RCに基づいて2台のマシンを組み立て、
litware.inc
という1つのドメインからフォレストを作成しました。 ドメイン内の2つのマシンは、それぞれ
w2012dc1.litware.inc
および
w2012cl1.litware.inc
と呼ばれます。
w2012dc1
ドメインサービスとDNSが回転し、
w2012cl1
では、実際にはOS自体を除いて、何も回転していません。 また、ドメインには、ユーザー
user1
あり、
domain users
グループのメンバーです。 もちろん、2台目のマシンにWindows 8 RCをインストールすることもできました(いわば、美しさのためです)が、2台の独立した仮想ハードドライブを使用する代わりに、1台の親仮想ハードドライブを使用して2台の子をフックすることで、ディスクスペースを節約することにしました。
また、使用するすべての用語が既にローカライズされて
おり、Microsoft言語ポータルで利用できるわけではないことに注意する必要があり
ます 。したがって、これらの用語を理解したとおりに翻訳を提供し、括弧内に元の名前を英語で示します。
新機能
最初に、それらをリストします、これ:
- ワークフロー (eng。Workflows)は、順次または並行して実行され、複雑な管理タスクを実行する特定のプロセスです。 実際、PowerShell v3にはWindows Workflow Foundationのサポートが含まれるようになり、PowerShellワークフロー自体は反復可能、並列化可能、中断、および回復可能です。
- 信頼性の高いセッション ( ロバストセッション )は、ネットワークのトラブルや同様の中断の後に自動的に復元されるPowerShellセッションです。 このテクノロジーを使用すると、あるマシン上のセッションから切断し、別のマシン上の同じセッションに接続することもできます。
- スケジュールされたジョブは、特定の間隔で、またはイベントに応じて実行できるPowerShellジョブです。
- セッションの特別な構成 (Eng。 カスタムセッション構成 )-PowerShellセッションごとに、特定のパラメーターセットを事前定義し、特別な構成ファイルに保存して、準備ができたときにセッションに入ることができます。
- 単純化された言語構文 -伝えられるところでは、単純化された構文により、PowerShellスクリプトはプログラムのようではなく、自然な人間の言語のように見えます。
- コマンドレット検出 ( コマンドレット検出 )-コマンドレットが配置されているモジュールの自動読み込み。もちろん、このモジュールがマシンにインストールされている場合。
- Show-Commandは、おそらく最初から使用する新しいコマンドレットの1つにすぎません。
表示コマンド
パラメータを指定せずに起動すると、ウィンドウが表示され、そこから壮大かつシックに吹き飛ばされます。
以前にTechNetで特定のコマンドレットを検索する必要がある場合、または.NETオブジェクトを使用する必要がある場合、すべてのモジュール、すべてのコマンドレットがそれらを探す必要はありません。
DNSサーバーとDNSクライアントサービスを管理するためのコマンドレットと、ネットワークモジュールなどのモジュールを選択すると、ルーティングテーブルを構成するためのコマンドレットや、ネットワークインターフェイスのTCP / IPパラメーターなどを見つけることができます。
また、「share」、「user」、「acl」、「policy」、「adapter」などの単語を検索してみました。試してみてください。面白いです。
コマンドレットの発見
前のものに関連付けられていますが、直接依存していません。 Windows Server 2008 R2のPowerShell v2では、特定の操作を実行するために、1つまたは別のモジュールを接続する必要があります。PowerShellv3は、コマンドレットの実行とバックグラウンドでこのモジュールが問題なくロードするモジュールを自動的に決定します。
比較してください。 PowerShell v2でドメイングループポリシーをダウンロードしようとすると、ドメイングループポリシーのリストを取得することにしました。
Get-GPO -All | ft Id # Id ,
GroupPolicyモジュールがロードされていないため、エラーが発生します。
Import-Module GroupPolicy
繰り返しますが、すべてがうまくいきます:
PowerShell v3では、最初からすべて問題ありません。
簡略化された言語構文
ここでは、開発者は言語をSQLに近づけることを決めました。少なくとも、ある程度の類似性があります。 実際には、
Foreach-Object
および
Where-Object
コマンドレットに新しい構文が導入されています。
Foreach
の実用的な価値は次のとおりです。
Get-Service | Foreach Name
の代わりに
Get-Service | Foreach {$_.Name}
私の意見では、疑わしい。
別のこと
Get-Service | Where Status -eq Running
の代わりに
Get-Service | Where {$_.Status -eq "Running"}
すでに何もありません、中括弧なしでドル引用符で囲まれています。
範囲を示す
-In
および
-NotIn
の新しい演算子もいくつか登場しました。 彼らと、私は、理解できる以上のものだと思います:
カスタムセッション構成
最初の部分でお話ししたい最も注目すべき革新は、管理権限の委任に関連するセッションの構成です。 構成ファイル自体は、拡張子が.psscのファイルです。このファイルには、作成者、言語、変数、関数定義などのプロパティと値のハッシュテーブルのみが含まれています。 セッション構成自体には、他のプロパティがあります。
Get-PSSessionConfiguration | Get-Member
次のような画像が表示されます。
カスタムオプションの数をご覧ください。 PowerShell v2でこのコマンドを実行したときに表示される画像と比較して、違いを感じることもできます。
しかし、それを使用するには? そして今、私はこれらの数行を書くのに十分な長さを選んでいることを認めなければなりません。 したがって、次を順番に実行します。
$defSSDL = (Get-Item WSMan:\localhost\Service\RootSDDL).Value
構成を
DnsServer
モジュールと
Show-DnsServer
で開始するコマンドレットのみに制限していることに注意してください。これにより、シェル自体は
administrator@litware.inc
特権で実行されますが、リモートマシン
w2012cl1
リモートユーザー
user1
は何もできなくなります。おそらくこれを除いて:
便利なものですよね? PowerShell内のモジュールとコマンドレットを制限することで、一部の従業員をDNSに、無条件で管理者チーム内のネットワークの責任者にしたり、VDI内のHyper-Vマシンのスナップショットを作成する権限をユーザーに付与したり、タスクが実行されるユーザーの資格情報を知ってください! そして、完成した構成ファイルは、1つの場所から同様の機能を持つ他のすべてのサーバーに単純に転送されます。
次の部分では、さらに先に進むか、リストの上位に進み、信頼できるセッション、スケジュールされたタスク、そしてもちろん作業プロセスを分析します。 まあ、そしておそらく新しいPowerShell ISEに少し触れて、見るべきものもあります。