ぜんぜん話は違うのですが、日本の SQL Server サポートチームの Blog が気合入っています（笑）。今後ともご贔屓にしてくださいませ。評判が悪かったら元に戻すと言っていたので、4月には元に戻っている可能性があります。

さて、かなり前のことになりますが、以下の資料を SlideShare に投稿しました。このスライドでは、VBScript を使用して、WMI のイベントをリアルタイムに収集するスクリプトについて解説しています。

このスライドで解説している手法を使用すると、システム内に発生したさまざまなイベントを待ち合わせて、その次のアクションを自動的に実行することができます。

例えば、次のような処理が簡単に自作できます。

• 監査ログを監視して、ユーザーが作成されことを検出したらホームディレクトリを自動的に作成する
• 特定のサービスを監視して、停止したらメールする
• 特定の誰かがログオンしたらメッセージを表示する
• 特定のプログラムが起動したら強制的にKILLする

などなど。

※上記スライドには MOF を使用してスクリプトをサービス化する手法についても書かれています

【PowerShell 1.0 の場合】

これと同じことが PowerShell でできないだろうか....と思いつつすっかり忘れていましたが、実は初期の PowerShell の頃から同じことは実現可能でした。

（参考）Windows PowerShell 2.0 - WMI Event Monitoring

上記の参考リンクでは、以下の様なスクリプトを紹介しています（ちょっとだけ変えています）。このスクリプトでは、WMI の __InstanceCreationEvent というイベント監視用クラスを使用し、Win32_Process を監視しています。クラス名に「Creation」という言葉が入っている通り、「何らかのプロセスが起動したらコンソールにプロセス名を表示する」という動作をします。

$a = 0 
$timespan = New-Object System.TimeSpan(0, 0, 1) 
$scope = New-Object System.Management.ManagementScope("\\.\root\cimV2") 
$query = New-Object System.Management.WQLEventQuery ` 
    ("__InstanceCreationEvent",$timespan, "TargetInstance ISA 'Win32_Process'" ) 
$watcher = New-Object System.Management.ManagementEventWatcher($scope,$query)
do 
    { 
        $b = $watcher.WaitForNextEvent() 
        $b.TargetInstance.Name 
    } 
while ($a -ne 1)

このスクリプトの記載をご覧いただければわかる通り、VBScript とほとんど同じです。Do ～ While でイベントを待ち合わせるのも同じですね。

もし、「プロセスの停止」を待ち合わせるのであれば、クラス部分を __InstanceDeletionEvent に置き換えます。

非常に便利なのですが、この書き方だとスクリプトを常駐しておかなければならないという面倒くささがあります。

【PowerShell 2.0 の場合】

PowerShell  2.0 では、専用のコマンドレットが提供されました。

Register-WMIEvent コマンドレットです。

このコマンドレットにより、上記のスライドに書かれた「スクリプトのサービス化」なんてことをせずとも、WMIイベントを待ち合わせるジョブがシステムに登録されます。

※ 以前、田辺さんが紹介されていたのを思い出しました（Windows PowerShell V2 の新機能）。

そこで、上記のスクリプトを Register-WMIEvent で置き換えると、以下ようなかんじになります。

少し長いですが、これで1行です。

Register-WMIEvent -query "Select * From __InstanceCreationEvent within 3 
Where TargetInstance ISA 'Win32_Process'" 
 -sourceIdentifier "NewProcess" 
 -Action { $Event.SourceEventArgs.NewEvent.TargetInstance.Name |
 Out-File -FilePath "c:\tmp\log.txt" -Append}

上記コマンドレットを実行すると、新しいプロセスが起動するびに、- Action {} 部分が実行されます。

ここでは起動したプロセスの Name を log.txt というテキストファイルに Out-File しています。

$Event は、このコマンドレットに組み込みの変数で、WMI のイベントが格納されています。このコマンドレット内でした使用することができません。

$Event.SourceEventArgs.NewEvent.TargetInstance は、イベント（ここではプロセスの起動）が発生したときに返される Win32_Process のインスタンスです。

ためしに、以下のように修正して実行し、log.txt の結果を見てみましょう。

Register-WMIEvent -query "Select * From __InstanceCreationEvent within 3
 Where TargetInstance ISA 'Win32_Process'" 
 -sourceIdentifier "testProcess" 
 -Action { $Event.SourceEventArgs.NewEvent.TargetInstance | Get-Member |
 Out-File -FilePath "c:\tmp\log.txt" -Append}

以下のような結果が格納されているはずです。Win32_Process だってことがわかりますね。

   TypeName: System.Management.ManagementBaseObject#root\CIMV2\Win32_Process

Name                       MemberType Definition                               
----                       ---------- ----------                               
AttachDebugger             Method     System.Management.ManagementBaseObject...
GetOwner                   Method     System.Management.ManagementBaseObject...
GetOwnerSid                Method     System.Management.ManagementBaseObject...
SetPriority                Method     System.Management.ManagementBaseObject...
Terminate                  Method     System.Management.ManagementBaseObject...
Caption                    Property   System.String Caption {get;set;}         
CommandLine                Property   System.String CommandLine {get;set;}     
CreationClassName          Property   System.String CreationClassName {get;s...
CreationDate               Property   System.String CreationDate {get;set;}    
CSCreationClassName        Property   System.String CSCreationClassName {get...
CSName                     Property   System.String CSName {get;set;}          
Description                Property   System.String Description {get;set;}     
ExecutablePath             Property   System.String ExecutablePath {get;set;}  
ExecutionState             Property   System.UInt16 ExecutionState {get;set;}  
Handle                     Property   System.String Handle {get;set;}          
HandleCount                Property   System.UInt32 HandleCount {get;set;}     
InstallDate                Property   System.String InstallDate {get;set;}     
KernelModeTime             Property   System.UInt64 KernelModeTime {get;set;}  
MaximumWorkingSetSize      Property   System.UInt32 MaximumWorkingSetSize {g...
MinimumWorkingSetSize      Property   System.UInt32 MinimumWorkingSetSize {g...
Name                       Property   System.String Name {get;set;}            
OSCreationClassName        Property   System.String OSCreationClassName {get...
OSName                     Property   System.String OSName {get;set;}          
OtherOperationCount        Property   System.UInt64 OtherOperationCount {get...
OtherTransferCount         Property   System.UInt64 OtherTransferCount {get;...
PageFaults                 Property   System.UInt32 PageFaults {get;set;}      
PageFileUsage              Property   System.UInt32 PageFileUsage {get;set;}   
ParentProcessId            Property   System.UInt32 ParentProcessId {get;set;} 
PeakPageFileUsage          Property   System.UInt32 PeakPageFileUsage {get;s...
PeakVirtualSize            Property   System.UInt64 PeakVirtualSize {get;set;} 
PeakWorkingSetSize         Property   System.UInt32 PeakWorkingSetSize {get;...
Priority                   Property   System.UInt32 Priority {get;set;}        
PrivatePageCount           Property   System.UInt64 PrivatePageCount {get;set;}
ProcessId                  Property   System.UInt32 ProcessId {get;set;}       
QuotaNonPagedPoolUsage     Property   System.UInt32 QuotaNonPagedPoolUsage {...
QuotaPagedPoolUsage        Property   System.UInt32 QuotaPagedPoolUsage {get...
QuotaPeakNonPagedPoolUsage Property   System.UInt32 QuotaPeakNonPagedPoolUsa...
QuotaPeakPagedPoolUsage    Property   System.UInt32 QuotaPeakPagedPoolUsage ...
ReadOperationCount         Property   System.UInt64 ReadOperationCount {get;...
ReadTransferCount          Property   System.UInt64 ReadTransferCount {get;s...
SessionId                  Property   System.UInt32 SessionId {get;set;}       
Status                     Property   System.String Status {get;set;}          
TerminationDate            Property   System.String TerminationDate {get;set;} 
ThreadCount                Property   System.UInt32 ThreadCount {get;set;}     
UserModeTime               Property   System.UInt64 UserModeTime {get;set;}    
VirtualSize                Property   System.UInt64 VirtualSize {get;set;}     
WindowsVersion             Property   System.String WindowsVersion {get;set;}  
WorkingSetSize             Property   System.UInt64 WorkingSetSize {get;set;}  
WriteOperationCount        Property   System.UInt64 WriteOperationCount {get...
WriteTransferCount         Property   System.UInt64 WriteTransferCount {get;...
__CLASS                    Property   System.String __CLASS {get;set;}         
__DERIVATION               Property   System.String[] __DERIVATION {get;set;}  
__DYNASTY                  Property   System.String __DYNASTY {get;set;}       
__GENUS                    Property   System.Int32 __GENUS {get;set;}          
__NAMESPACE                Property   System.String __NAMESPACE {get;set;}     
__PATH                     Property   System.String __PATH {get;set;}          
__PROPERTY_COUNT           Property   System.Int32 __PROPERTY_COUNT {get;set;} 
__RELPATH                  Property   System.String __RELPATH {get;set;}       
__SERVER                   Property   System.String __SERVER {get;set;}        
__SUPERCLASS               Property   System.String __SUPERCLASS {get;set;}    

登録しておけば、あとは何もせずともずっと監視が続けられます。もちろん、OS を再起動しても消えません。

監視を終了するには、以下のように Unregister-Event コマンドレットを使用します。

Unregister-Event NewProcess

今回は単純な例をご紹介しましたが、もっともっと複雑な処理を実装することもできます。

それについては今後。

p.s.

テストを繰り返していると以下のエラーに見舞われることがあります。そのときは Windows Management Instrumentation サービスを再起動してください。そういう意味では...本番環境ではテストをしないほうがよいです。

Register-WmiEvent : クォータ違反です
発生場所 行:1 文字:18
+ Register-WMIEvent <<<<  -query "Select * From __InstanceCreationEvent within
3 Where TargetInstance ISA 'Win32_Process'" -sourceIdentifier "NewProcess" -Act
ion { $Event.SourceEventArgs.NewEvent.TargetInstance.Name | Out-File -FilePath
"c:\tmp\log.txt" -Append}
    + CategoryInfo          : NotSpecified: (:) [Register-WmiEvent]、Management
    Exception
    + FullyQualifiedErrorId : System.Management.ManagementException,Microsoft.
   PowerShell.Commands.RegisterWmiEventCommand

これ、私の現在のランキングです。72ポイント獲得で、日本で12位！世界で51395位！orz シルバーステータスまでもう少しだ！

なんのこっちゃわからない方も多いですよね。

マイクロソフトでは、オンラインの学習サイト「Microsoft Virtual Academy」を運営しています。

以下をクリックして、まずはユーザー登録からはじめてください（ぜんぜん面倒じゃありません）。

Click！

要は、ブラウザを使ってオンライン学習して、ポイントかせいでランキングを上げちゃおうってやつです。勤勉な方ほどランクが上がるという、なんともやりがいのあるシステムです。

Virtualization のコンテンツ（以下）が日本語化されてますので、是非とも挑戦してください。

これらをクリアするだけで 71 + 43 + 65 = 179 ！ 軽く私のランクを超えます。

近日中に、Windows Server 8 や System Center 2012 の日本語版コンテンツも公開予定です。

国ごとのランキングが出ると、もっとおもしろいんですけどねぇ。

以前以下の投稿をしました。

世界に挑戦してみます？ Microsoft Virtual Academy

Microsoft Virtual Academy に日本語で受講できるコンテンツが増えました。

• Windows 7 を展開する (299ポイント)

• VMware プロフェッショナル向け Microsoft Virtualization: セッション 1 - プラットフォーム(71ポイント)

• VMware プロフェッショナル向け Microsoft Virtualization: セッション 2 - 管理(65ポイント)

• VMware プロフェッショナル向け Microsoft Virtualization: セッション 3 - VDI(43ポイント)

• System Center 2012 の全体像を理解する(42ポイント)

• Hyper-V と VMware の混在環境のシンプルな管理(43ポイント)

上記のコースを全て受講しテストに合格すると、563点！

2012年3月19日 10:30現在、日本のトップ10は以下の通りです。

1. Akira Hatsune さん（904ポイント）RANK:Gold
2. Takahito Yamatoya さん（非公開）RANK:Gold
3. Kenichi Hayashi さん（517 ポイント）RANK:Gold
4. Yukio Saitoh さん（376 ポイント）RANK：Silver
5. Tomoyuki Obi さん（293 ポイント）RANK：Silver
6. Munetatsu Go さん（非公開）RANK：Silver
7. Keiji Kamebuchi さん（256 ポイント）RANK：Silver
8. Junichi Anno さん（251 ポイント）RANK:Silver ← ワールドワイドで 18804 位 です
9. Tomohiro Ohtakeさん（239ポイント）RANK:Silver
10. Kazufumi Takahashi さん（238 ポイント）RANK:Silver

つまり、全ての日本語コースを合格するだけで 2位か3位に浮上できる！ということです。

わたしは週末に集中的に行って、なんとか8位までたどり着きました。

上を見ると、まだまだ壁が厚いですね。

Windows Management Framework 3.0 ベータ版がリリースされています。

Download: WMF3 Beta - Microsoft Download Center - Download Details（英語版です）

既に、Windows Server 2008 R2 や Windows 7 には WMF 2.0 相当の機能がインストールされていますが、WMF 3.0 Beta をインストールすることで、新しい Windows Server "8" と同等の管理フレームワークを実装することができます。

なお、インストールするには事前に以下をインストールしておく必要があるの注意しましょう。

• 以前のCTPがインストールされている場合にはアンインストール
• 英語版の言語パック
  Download: Windows Server 2008 R2 Multilingual User Interface Language Packs
• .NET Framework 4.0
  ダウンロード詳細 Microsoft .NET Framework 4 (Web インストーラー)
• Windows PowerShell ISE
  WMF 3.0 では PowerShell ISE が更新されますが、事前に「機能の追加」で ISE をインストールしておく必要があります。

さらに、一旦英語環境に変更しておく必要がありますので、これも注意しましょう。

なので、本番の運用環境にインストールするのは厳しいと思います。コマンドレットや PowerShell スクリプトの仕様なんかも変更されているので、テスト環境を使用していただくことを強くお勧めします。

では、簡単にどんなものがインストールされるかをご紹介します。

Windows PowerShell 3.0

待ちに待った Windows PowerShell 3.0 です。PowerShell 3.0 によって何ができるようになるかというと....

※ 詳しくは What's New in Windows PowerShell 3.0 を参照してください。

• ワークフロー
  PowerShell 3.0 ではバックグラウンドジョブ機能が大きく強化されています。これについては牟田口さんの記事や Ahf さんの記事に詳しく書かれているのでここでは割愛しますが、例えば、System Center Virtual Machine Manager のセルフサービスポータルのように、利用者が仮想マシンの作成を要求し、承認後に仮想マシン作成処理が動きだし、しばらくして仮想マシンの作成が完了したら申請者にメールで知らせる...などといったプロセスを実装することができます（GUI が必要じゃないかどうかは別として）。
• セッションへの再接続
  英語では Robust sessions（堅牢なセッション）と表現されていますが、ちょっとわかりずらいので「再接続」としました。前出のワークフローのように、複数単位で構成されるジョブには必須の機能ですね。例えば、リモートコンピューターでジョブを実行し、一旦ローカルPCを再起動後、再度そのセッションに接続してジョブの実行経過を監視する..なんてことができます。Windows PowerShell Web Access を併用すれば、社内で開始したジョブを、自宅に帰ってブラウザから状況を監視する...なんてこともできるわけです。これは IT Pro にとってはうれしい機能です。
• ジョブスケジューリング
  以下に示すコマンドレットを使用して、PowerShell からタスクにジョブを登録することができます。もちろんジョブトリガーを定義することもでき、これもワークフローにとって必要な機能ですね。
  

  PS C:\> Get-Command -Module PSScheduledJob Capability      Name                                               ModuleName ----------      ----                                               ---------- Cmdlet          Add-JobTrigger                                     PSScheduledJob Cmdlet          Disable-JobTrigger                                 PSScheduledJob Cmdlet          Disable-ScheduledJob                               PSScheduledJob Cmdlet          Enable-JobTrigger                                  PSScheduledJob Cmdlet          Enable-ScheduledJob                                PSScheduledJob Cmdlet          Get-JobTrigger                                     PSScheduledJob Cmdlet          Get-ScheduledJob                                   PSScheduledJob Cmdlet          Get-ScheduledJobOption                             PSScheduledJob Cmdlet          New-JobTrigger                                     PSScheduledJob Cmdlet          New-ScheduledJobOption                             PSScheduledJob Cmdlet          Register-ScheduledJob                              PSScheduledJob Cmdlet          Remove-JobTrigger                                  PSScheduledJob Cmdlet          Set-JobTrigger                                     PSScheduledJob Cmdlet          Set-ScheduledJob                                   PSScheduledJob Cmdlet          Set-ScheduledJobOption                             PSScheduledJob Cmdlet          Unregister-ScheduledJob                            PSScheduledJob

• Delegated Administration（管理の委任）
  PowerShell 2.0 でもセッションのエンドポイントに対する委任機能がありましたが、3.0でそれが強化されたようです。ただ、具体的に何が強化されたのか...うーんごめんなさい。追いきれていません。ワークフローでの委任だとは思うのですが...。
• 構文の簡易化
  「構文の簡易化」といきなり言われましても...な感じではあるのですが、 Keith Hill's Blog からの引用によれば以下のように $_ が必要なくなるなど、大きく改善しているようです。もちろん以前の書き方も下位互換性のためにサポートされています。
  旧：Get-Process | Where {$_.PM -gt 100MB}
  新：Get-Process | Where PM -gt 100MB
  確かにこれはうれしいです。でも、$_ に慣れちゃったからなぁ。。。とか言って....。
• Cmdlet Discovery 
  いま PowerShell を使っていて何がストレスになるかって、Import-Module をしないと Get-Command でコマンドレットが参照できないってことです。 今回の改善によって、Get-Command -Module ActiveDirectory とかを実行したときに、自動的に Import-Module が実行されます。これは、地味～ではありますがうれしいです。
• Show-Command コマンドレット
  Show-Command コマンドレットを使用すると、モジュールごとにどんなコマンドレットが用意されているのかを GUI で確認できる他、GUI上でパラメタ等を指定して直接実行することができる優れものです。この機能は PowerShell ISE でも提供されています。
  VBScript 時代に ScriptOmatic や WMIOmatic というツールがあったのですが、あれの高機能 PowerShell 版といったところでしょうか。
   

この他、いろいろとアップデートされていますので、詳しくは What's New in Windows PowerShell 3.0 を参照してください。

WMI

Script Geek には欠かせない WMI（Windows Management Instrumentation）ですが、これもアップデートされました。

• 新しい開発モデル
  従来の COM 依存からの脱却
• CIM（Common Interface Model）との親和性強化
  CIM とは DMTF によって標準化されたマルチプラットフォーム環境における標準管理モデルです。WMI とは CIM 標準の MS 実装版ですが、こいつが CIM 標準との親和性を高めることにより、今まで以上に Windows 以外のプラットフォームを Windows 上からに柔軟に管理できるようになります。現在は OpenPegasus というオープンソースが普及？しており、例えば Linux 上に OpenPegasus がインストールされていれば WMI から Linux に接続して管理すると言ったことが可能ではありますが、 出来ることに制約があったりスピードが遅かったりと問題が無いわけではありません。じゃ、どうするのかといえば...詳しくは書けないのですが、これをなんとかしようという動きが無いこともありません。
• ネイティブコードによるPowerShellコマンドレットの開発

WinRM

前出の CIM はあくまでもオブジェクトモデルであり、これだけで管理が行えるわけではありません。PowerShell や各種コマンドの要求を受け入れるサービスが必須です。CIM に対応したインターフェース標準として WBEM（Web-Based Enterprise Management）というものがあり、その実装として普及しているのが WS-Man（Web Service Management）です。でもって、WS-Man の MS 実装版が WinRM（Windows Remote Management）ということになります（疲れますね）。

WinRM は以前のバージョンとくらべて、接続性が大きく改善されています。この改善が、PowerShell 3.0 の「再接続可能なセッション」を実現しています。

Windows PowerShell Web Service（WPWS）

※この機能、Windows Server 2008 R2 に提供されています？？恥ずかしながら見つけられませんでした...。

その名称から容易に想像できますが、PowerShell の要求を受け付ける Web Service が提供されます。インターフェースが ODATA なので、どんなクライアントからでも接続が可能だというメリットがあります。

このサービスの面白いところは、WPWS をゲートウェイとして別のコンピューターの WinRM に接続できる点です。つまり、DMZ にこのサービスを立てておけば、社内のサーバーに接続して自宅から管理が行えます。PowerShell  3.0 でコマンドレットが 2300 にまで増えたので、管理のし甲斐があるってもんです。

標準では、ブラウザからアクセス可能なGUIが提供されています。もちろん、スマートフォンからのアクセスも可能です。

Server Manager CIM Provider

Windows Server "8" のサーバーマネージャーから、Windows Server 2008 R2 SP1 および Windows Server 2008 SP2 のサーバーマネージャーに接続するための CIM プロバイダーです。WMF 3.0 をインストールし、さらに、Enable-PSRemoting コマンドレットでリモートからの接続を許可すると、Windows Server "8" から Windows Server 2008/2008 R2 のサーバーマネージャーを操作できるようになります。

PS C:\Users\Administrator> Enable-PSRemoting WinRM Quick Configuration Running command "Set-WSManQuickConfig" to enable this machine for remote management through WinRM service. This includes:     1. Starting or restarting (if already started) the WinRM service     2. Setting the WinRM service type to auto start     3. Creating a listener to accept requests on any IP address     4. Enabling firewall exception for WS-Management traffic (for http only). Do you want to continue? [Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): Yes WinRM has been updated to receive requests. WinRM service type changed successfully. WinRM service started. WinRM has been updated for remote management. Created a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine. WinRM firewall exception enabled. Confirm Are you sure you want to perform this action? Performing operation "Set-PSSessionConfiguration" on Target "Name: microsoft.powershell SDDL: O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD). This will allow selected users to remotely run Windows PowerShell commands on this computer". [Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): Yes Confirm Are you sure you want to perform this action? Performing operation "Set-PSSessionConfiguration" on Target "Name: microsoft.powershell.workflow SDDL: O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD). This will allow selected users to remotely run Windows PowerShell commands on this computer". [Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y Confirm Are you sure you want to perform this action? Performing operation "Set-PSSessionConfiguration" on Target "Name: microsoft.powershell32 SDDL: O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD). This will allow selected users to remotely run Windows PowerShell commands on this computer". [Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y Confirm Are you sure you want to perform this action? Performing operation "Set-PSSessionConfiguration" on Target "Name: microsoft.ServerManager SDDL: O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD). This will allow selected users to remotely run Windows PowerShell commands on this computer". [Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y PS C:\Users\Administrator>

昨日以下の記事を投稿しました。

【Management】Windows Management Framework 3.0 Beta

多くの方は PowerShell 3.0 の機能にワクワクされていると思います。私もそうです。

どんなコマンドレットが使えるかはインストールされている役割や機能に依存するのですが、手元のサーバーにインストールされているモジュールを確認するのであれば以下のように入力してみてください。

中でも注目したいのが Hyper-V の管理機能です。

これまで、PowerShell から Hyper-V を使用するには以下の方法が用意されていました。

• WMI の Virtualization プロバイダーを使用する
  ※正直、かなり難しかったです
• System Center Virtual Machine Managger のコマンドレットを使用する
• コミュニティ版コマンドレットを使用する
  PowerShell Management Library for Hyper-V

今回の WMF 3.0 には、なんと 162 個もの Hyper-V 用コマンドレットが用意されています。

以下はその一覧です。

すばらしいです。なんか、ものすごい武器を手に入れたような感覚です。

これらとワークフロー機能を組み合わせれば、簡易的なセルフサービス機能なんかも作りこめますね。これについてはおいおいまとめていきたいと思います。

現行の Windows PowerShell 2.0 では、「リモーティング」と呼ばれる機能がサポートされています。リモーティングとは、「リモートコンピュータに対する操作」のことです。

運用管理を自動化するにはリモーティングは欠かせない機能ですので、PowerShell ユーザーの方はぜひ押さえておきましょう。

【PowerShell 2.0 でサポートされているリモーティング】

PowerShell のリモーティングの使い方は、大きく 4 種類に分かれます。

• コマンドレットの –ComputerName パラメタを使用する

（例）Get-Service -ComputerName Server01

ただし、全てのコマンドに –ComputerName が実装されているわけではないので、以下に示すような方法を使用する必要があります。

• Enter-PSSession / Exit-PSSession

telnet や ssh のようにリモートコンピュータとセッションを構築し、その中でコマンドレットを実行することができます。セッションの有効期間は、Enter-PSSession 実行から Exit-PSSession 実行までです。

PS> Enter-PSSession -ComputerName Server1 [Server1]: PS > $A = 1 [Server1]: PS > $B = 2 [Server1]: PS > $C = $A + $B [Server1]: PS > 3 PS> Exit-PSSession

• Invoke-Command

以下のように Invoke－Command を使用すると、-ComputerName で指定したコンピュータに対してコマンドレットを投げ、その結果だけを受け取ります。セッションはその都度消滅するので、例えば上の例のように、$C = $A + $B の計算結果が 3 にはなりません。なぜならば、セッションが消滅してしまうので、セッション中の変数も消滅してしまうからです。

PS C:\> Invoke-Command -ComputerName junichia-vdi -ScriptBlock {$A = 1}

PS C:\> Invoke-Command -ComputerName junichia-vdi -ScriptBlock {$B = 2}

PS C:\> Invoke-Command -ComputerName junichia-vdi -ScriptBlock {$C = $A + $B}

• 永続化されたセッションを使用する

セッションを永続化するには、New-PSSession コマンドレットを使用します。以下の例では、Server1 との間に TestSession という名前のセッションを作成しています。作成したセッションに入り込むには、Enter-PSSession に –Name <セッション名> を指定します。Invoke-Command でも セッション名を指定してコマンドを送信することができます。

PS C:\> New-PSSession -ComputerName Server1 -Name TestSession PS C:\> Enter-PSSession -Name TestSession [Server1]: PS C:\> $A = 1 [Server1]: PS C:\> $B = 2 [Server1]: PS C:\> $C = $A + $B [Server1]: PS C:\> $C 3 [Server1]: PS C:\> Exit-PSSession PS C:\>

作成したセッションは、削除しなければそのまま残ります。現在保持しているセッションの一覧を取得するには、Get-PSSession を使用します。

PS C:\> Get-PSSession Id Name            ComputerName    State    ConfigurationName     Availability -- ----            ------------    -----    -----------------     ------------   1 TestSession    Server1         Opened   Microsoft.PowerShell     Available

保持しているセッションはローカルコンピューターが再起動されない限り永続化されるので、再度 Enter-PSSession を使用して接続することができます。

ただし、作成したセッションを別のクライアントから使用することはできません。これは、PowerShell 2.0 ではセッション情報がローカルコンピューターに保持されるためです。

また、ローカルコンピューターを再起動してしまうと、作成したセッションは消滅してしまいます。

さらに、リモートコンピュータが再起動されるとセッションは破壊され、接続することができなくなります。

PS C:\> Get-PSSession -ComputerName Server1 Id Name         ComputerName State   ConfigurationName    Availability -- -----------  ------------ -----   -----------------    ------------ 2  TestSession Server1      Broken Microsoft.PowerShell None PS C:\> Enter-PSSession -Name TestSession Enter-PSSession : セッションが開かれている必要があります。 発生場所 行:1 文字:16 + Enter-PSSession <<<< -Name tmpsession + CategoryInfo : InvalidArgument: (:) [Enter-PSSession]、ArgumentException + FullyQualifiedErrorId : PushedRunspaceMustBeOpen,Microsoft.PowerShell.Commands.EnterPSSessionCommand

ちなみに、セッションの利用が完了したら、Remove-PSSession でセッションを削除することができます。

PS C:\>Remove-PSSession -Name TestSession

次の投稿で、PowerShell 3.0 で改善されたセッション永続化について解説します。

つづき 【Management】PowerShell V3.0 で向上したリモーティング機能 その2

【PowerShell 3.0 で改善されたセッションの永続化機能】

※ここからはローカルとリモートの両方が PowerShell 3.0 を使用してることを前提としています。

前回は、PowerShell 2.0 でのリモーティング機能についてご紹介しました。

【Management】PowerShell V3.0 で向上したリモーティング機能 その1

今回は、PowerShell 3.0 によって何が改善されるのかについて解説します。この改善は、ワークフローにとって非常に重要であり、この機能なしにワークフローはありえないと言えるでしょう。

PowerShell 2.0 と PowerShell 3.0 とではセッション情報の持ち方が変わりました。

2.0 では New-PSSession を実行したクライアント側にセッション情報が保持されます。そのため、別のクライアントから当該 PSSession を使用することができません。

一方 PowerShell 3.0 では、セッションの永続性を確保するためにリモートコンピューター側に PSSession を保持します。そのため、PSSession が生きていれば、別のコンピューターから接続して処理を継続したり、ジョブの状態を確認することができるようになりました。

それに伴い、新しいコマンドレットが追加されています。

• Connect-PSSession

事前に New-PSSession でセッションを作成しておくことで、いつでも本コマンドレットで再接続することができます。ただし、別のコンピューターから接続されているセッションに接続することはできません。（-Force オプションが見当たりませんでした）

• Disconnect-PSSession

当該コマンドレットを使用すると、接続中のセッションから切断し、セッションの Status を Disconnect にします。Disconnect のセッションには、別のコンピューターから接続することができます。

• Receive-PSSession

Disconnect した PSSession からコマンドやジョブの実行結果だけを受け取るためのコマンドレットです。が...私の使い方が悪いのか、現時点ではうまく使えません...。

では、これらのコマンドレットを使って、ものすごく単純な例で試してみましょう。

以下のように、3台のマシンがあるとします。いずれも PowerShell 3.0 がインストールされているマシンです。

【社内PCから】

社内の PC で、リモートコンピューターに対して新しいセッションを作成します。

testSession というセッションが作成されました。

次に、このセッションに接続します。接続するには Connect-PSSession を使用します。このとき、自分で作ったセッションなので －Name でセッション名だけ指定すれば接続できます。

さらに、このセッションに Enter-PSSesssion で入り込みましょう。

そして、セッションの継続性を確認するために、$a という変数を作り、セッションから抜け出します。

この状態ではまだセッションに Connect された状態なので、他のコンピューターから接続しようとしてもエラーが発生します。

なので、セッションを Disconnect します。とても重要です。

以上で完了です。

【自宅のPCから】

今度は別のコンピューターに移動します。ここでは「自宅のPC」と仮定しています。

はじめに、サーバー Server1 のセッション状態を確認してみます。State が Disconnect になっていることがわかります。

ここに Connect-PSSession ���ましょう。Disconnected が Opened になったことがわかります。

次に Enter-PSSession して、$A の中身を確認してみます。

いかがでしょう？非常に単純な例で恐縮なのですが、セッションに再接続できることがご理解いただけたかと思います。

セッションを使い終わったら、かならず Remove-PSSession でセッションを削除しておきましょう。

Windows Developer Day 2012 のセッション資料締切も目前なのに、すっかり PowerShell づいています。

前回、前々回とリモーティングの話を書いてきました。

• 【Management】PowerShell V3.0 で向上したリモーティング機能 その1
• 【Management】PowerShell V3.0 で向上したリモーティング機能 その2

リモートにあるサーバーを、手元のクライアントから操作する...などというのが主な使い方になりますが、今後は PowerShell ワークフローをキックしたり、結果を取得したりといった方法にも活用することになります。

で、リモーティングに関してもう数点ご紹介しておきたい機能があります。

そのうちの1つが、Import-PSSession というコマンドレットです。

ご存知ない方も多いのではないかと。このコマンドレットは、PowerShell 2.0 でサポートされました。

PowerShell では Invoke-Command というコマンドレットにより、リモートコンピューターにコマンドを投げることができます。

ただ、コンソールで対話しているときに Invoke-Command を頻繁に入力するのって疲れるんです。面倒なのです。キーッってなるのです。

Enter-PSSession で PSSession に入り込んでもいいのですが、プロンプトが長くなるので、これも キーッ となるのです。

じゃ、手元のマシンに Module をインストールすることができるのか...といえば、出来るものもあるし、できないものもあります。

RSAT（Remote Server Administration Tool）をインストールすると、Active Directory 関連の PowerShell モジュールはインストールすることができます。

ちょっと中途半端ですよね。

そこで、Import-PSSession コマンドレットです。

Import-PSSession を使用すると、PSSession を張ったリモートコンピューターから、指定したコマンドレットやモジュールをローカルに取り込むことができます。

以下のように使います。

はじめにリモートコンピューターとの間に PSSession を作成します。

次に、Import-Session を使用して、リモートコンピューターから使用したいコマンドレットまたはモジュールを取り込みます。以下の例では、Hyper-V モジュールを指定し、 Hyper-V 系コマンドレットを全てとりこんでいます。

これで Hyper-V モジュールに含まれるすべてのコマンドレットが取り込まれました。

tmp_c4aumigk.g4m がローカルコンピューターでのモジュール名になるので、こいつを使ってコマンドレットの一覧を見てみると以下の通りです。

これで、心置きなく Hyper-V 関連のコマンドレットを使用することができます。

ただし、注意が2点。

• コマンドレットはリモートコンピューターとの PSSession 上で実行されます
• コマンドレットが使えるのは、PSSession が生きている間です。PSSession が切断されるとコマンドレットも消滅しますので注意してください。

なお、万が一ローカルに同じ名前のコマンドレットが存在する場合には、アラートが表示されて当該コマンドレットは取り込まれません。��存のコマンドレットを一時的に上書きしてでも取り込みたい...といった場合には -DisableNameChecking を指定して Import しましょう。

広島方面の皆さまへ

3月23日および24に、広島でセミナーを実施します。

3月23日 14:00~16:00 マイクロソフト中四国支店 セミナールーム

Windows XP ではできないことがあります～Windows 7 を使用した柔軟なワークスタイルの全体像

多くの業務が Windows XP で動作している現在、Windows XP で十分という声が多く聞かれます。しかし、それは本当でしょうか？何かを見落としていませんか？ 2011年3月の東日本大震災発生から数週間、 関東では交通網の混乱を起因として多くの業務遂行に支障が発生しました。 社内システムや、インターネットをはじめとするインフラが生きていたにもかかわらずです。
これが意味することは何でしょう。「出勤しないと仕事ができない」という現実です。 本セッションでは、Windows 7 Enterprise をベースとした新しいインフラがもたらす柔軟な業務スタイルに加え、タブレットPCやスマートフォンなどの個人のデバイスから業務を遂行するためのインフラ設計について解説いたします。

以下の投稿を、もっと技術寄りにまとめた内容となる予定です。
マイクロソフトの IT コンシューマライゼーション 全体像 1

年度末の金曜日！ということで、皆さん死ぬほどお忙しいと思います。

ご参加できるようでしたら、是非お申し込みください。

3月24日 10:00～18:00 マイクロソフト中四国支店 セミナールーム

.NET 勉強会 / ヒーロー島 - 第27回勉強会「ハンズオンで PowerShell に触れてみよう」

終日 PowerShell 漬けです。安納による2時間の概要解説の後、牟田口さんによる3時間のハンズオンも実施されます。

休憩含めて 8時間程度で、PowerShell をマスター！できるお得な1日です。

是非ご参加くださいませ。

以上、ご案内でした。

ご存知のように、Windows Phone 7.5 では IRM 保護されたメールやOfficeドキュメントを読むことができます。今のところ、IRM 保護されたメールやドキュメントを参照できるのは、Windows Phone だけです。

※ 残念ながら、現時点では Windows Phone から IRM 保護の設定はできません

IRM とは Information Rights Management の略です。Active Directory Rights Management Service（AD RMS）を導入することによって、IRMで保護されたデータ使用することができます。

では、IRM とは具体的にどのようなメリットをもたらしてくれるのでしょう？ご存知の方も多いと思いますが、ちょっとだけ復習しておきましょう。

情報漏えいを抑止するにはデータの暗号化が基本です。しかし、人間が読むためには暗号化されたデータを解除しなければなりません。危険はここに存在します。いくら暗号化していても、かならず暗号化を解除する瞬間が必ずくるのです。データの受信者に悪意があったり、リテラシが低かったりして、暗号化が解除されたデータを印刷されたり、外部に転送されたら、その瞬間暗号化して送信した意味が無くなります。

そこで、暗号化以外の強制力が必要になります。

つまり、「受信者に許可された権限」を保持したまま電子メールやOfficeドキュメントを流通させることで、データの漏えいリスクを低減することができます。

Windows Phone では、電子メールとOfficeドキュメントとでは、IRM の扱われ方が少しだけ異なっています。

知っているから何か得する...ということでもないのですが、IT Pro にとっては興味があるところだと思いますので両者の違いについて少し解説しておきます。

■ 電子メールの場合

Windows Phone の Outlook Mobile から電子メールの同期要求を受け取ると、Exchange はユーザーをチェックし、同期対象となる電子メールおよび添付ファイルに対して、一旦 IRM 保護（暗号化と権限付与）を適用します。

受信者が電子メールの参照権限を持っていれば、Exchange Server 上で暗号化を解除し、ユーザーの権限を付与したまま Windows Phone の Outlook Mobile に送られます。

ユーザーは与えられている権限の範囲で電子メールを取り扱うことができます。

Windows Phone の場合、以下の権限を使用することができます。

• 返信 (REPLY)権限: 送信者に返信できる。返信の下書きを保存することもできる。
• 全員へ返信 (REPLYALL): 全員へ返信することができる
• 転送 (FORWARD): 受信したメールを転送することができる
• 受信者 (RECIPIENTS): 受信者はこのメッセージに返信または転送するときに、新しい受信者を追加できる
• 抽出 (EXTRACT): 受信者はメッセージの内容をコピーできる

なお、電子メールにOfficeドキュメントが添付されている場合、OfficeドキュメントにもIRM保護が適用されます。ただし、それを参照するためのプロセスはメール場合とは異なります。

■ Office ドキュメントの場合

Office ドキュメントの場合、暗号化を解除するのは Office 自身になります。添付ファイルの場合も同様です。

Office ドキュメントを Office で開こうとしたときに、毎回 AD RMS に対して権限のチェックが行われます。つまり、IRM保護されたOfficeドキュメントを Windows Phone で参照する場合、常に AD RMS と通信可能なインフラが必要となります。

2011年2月時点では AD RMS はオンプレミスにしか置けない（サポートされていない）ので、Windows Phone がインターネットから社内環境にアクセスできるようにしておかなければなりません（Forefront Unified Access Gateway が必要です）。

前回までの記事は以下の通りです。

マイクロソフトの IT コンシューマライゼーション 全体像 1

３．フレキシブル ワークスタイルを支えるテクノロジー

3.1 どこからでも接続 ～ 社内デバイスを社外から

多くの企業が社員に対し PC を支給しています。支給された PC には、業務に必要なアプリケーションがインストールされていますから、これを外部に持ち出せれば業務の継続性が維持できることは誰でも知っています。しかし、多くの企業ではそれらを社外に持ち出すことを許可していません。理由は単純です。紛失や情報漏えいが心配だからです。こうした心配事は本当に絶対につぶすことはできないのでしょうか？

いいえ、できます。しかるべきインフラを整備しさえすれば、難しいことではありません。

以下の図は社内PCを社外に持ち出して利用するためのインフラの概念図です。

ここでは、3つの重要なテクノロジーが使用されています。

• Bitlocker および Bitlocker to go
• Direct Access
• Lync

Bitlocker とは、デバイスを暗号化するためのテクノロジーです。Windows 7 では Enterprise Edition と Ultimate Edition に実装されています。このテクノロジーを使用することで、PC に実装されたハードディスク全体を暗号化することができます。通常、PC の利用者は起動時にPIN コードを入力することで、ハードディスクにアクセスできるようになります。PIN コードが一致しなければ OS の起動さえも行われません。万が一 PC が盗難にあい、ハードディスクを抜き出されたり他の OS からアクセスしようとしても、、暗号化したハードディスクを読み取ることはできません。

• Windows 7 用の BitLocker ドライブ暗号化展開ガイド

Bitlocker は USB メモリにも適用することができます。これを Bitlocker to go と呼びます。Bitloker to go を使用することで、USB メモリの盗難や紛失に伴うデータ漏えいのリスクを大幅に低減することができます。

Bilocker は盗難や紛失を防止するものではありませんが、万が一の際の最悪の事態を防止する役割を持っています。

さて、ここで、多くの IT 部門の方が疑問を持つでしょう。

「情報の漏えいも当然心配だが、盗難や紛失という事実によって顧客の信頼を失うことが問題なのだ」

おっしゃる通りです。だから持ち出しを制限するわけですね。残念ながら Windows には盗難や紛失を防止する機能は備わっていません。

では、もし顧客に対して、「デバイスが確実に暗号化されていたことを証明できる」としたらどうでしょう？たとえ紛失してしまったという事実が明るみに出たとしても、「信頼できる仕組みで暗号化されていたことが証明」できれば、企業の信頼低下を最小限に食い止めることができるのではないでしょうか？

それを実現するのが、MBAM（Microsoft BitLocker Administration and Monitoring）です。システム管理者は、MBAM を使用することで、PC に Bitlocker が適用されているかどうかを監視することができます。適用されていないデバイスに対しては、その持ち主に対して持ち出し禁止の通告をする必要があるでしょう。

MBAM は MDOP（Microsoft Desktop Optimization Pack）に含まれる製品です。MDOP はソフトウェアアシュアランス契約によって提供されます。Bitlocker 機能が実装された Windows 7 Enterprise を使用するには ソフトウェアアシュアランス契約が必要となるので、Windows 7 Enterprise の利用者であれば、自動的に MBAM が利用できるということになります。

• Bitlocker | 暗号化 | 企業のデータを安全に保護するための Windows 7 向けの MBAM
• MDOP - Windows の管理、仮想化、グループ ポリシー、エラー | TechNet
• Windows 7 - マイクロソフト ソフトウェア アシュアランス特典 - マイクロソフト ボリューム ライセンス

Direct Access とは、社外から社内リソースへのアクセスを容易にする VPN テクノロジーの一種です。従来の VPN と大きく異なるのは、「手動による接続操作」が必要がない点、「必要な時だけ社内にアクセス」する点、そして検疫機能（Network Access Protection）と完全に連動できる点です。

以下の図は社外から Windows 7 Enterprise の Direct Access 機能を使用して社内へのアクセス権を得るまでの大まかな流れです。

※以下のプロセスについて、認識違いがあるようですので、現在調査中です。すみません。

• Direct Access Server およびクライアントは Active Directory ドメインのメンバーである必要があります。
• Windows 7 Enterprise がインストールされたクライアントがネットワークに接続されると、Direct Access Server に接続を試みます。
• このとき、クライアントの正常性状態（Health State）がチェックされ、正常性状態がネットワークポリシーに合致しない場合、検疫ネットワークにリダイレクトされ、正常性を回復するための更新処理が実施されます。
• 正常性が確保されると、クライアントに対して正常性証明書が発行されます。
• クライアントはDirect Access Server に正常性証明書を提示し、Direct Access Server がそれをチェックします。
• クライアントコンピューターと Direct Access Server は、それぞれのコンピューター証明書によって相互認証を行います。
• 相互認証が完了すると、クライアントとドメインコントローラーの間に IPsec セションが確立し、ドメインコントローラーからセキュリティポリシーがクライアントコンピューターに適用されます。これにより、インターネット上であっても、常に社内のセキュリティポリシーが適用され続けます。
• ユーザーがクライアントにログオンすると、社内リソースにアクセスするための IPsec セッションが確立されます。

※詳細な解説はこちらをご覧ください
Windows 7 および Windows Server 2008 R2 の DirectAccess の技術概要

これ以降、クライアントコンピューターの正常性は杖にチェックされ続け、マルウェア感染や Windows Update の必要性を含めて何らかの問題が発生すると即座に IPsec セッションは無効になり、問題が解決するまで社内リソースに接続することはできません。ただし、インターネットへのアクセスは別です。Direct Access の場合、社内へのパスとインターネットへのパスは完全に分離されており（Direct Access 用の仮想ネットワークカードが使用される）、社内へのアクセスが遮断されてもインターネットへのアクセスは可能です。

ここで注目していただきたいのは、Active Directory の存在です。

こうした仕組みは、単なる VPN の進化によって実現されるものではありません。社内の Directory Service（ここでは Active Directory ファミリ）が適切に機能しており、コーポレート セキュリティの中心に存在して、はじめて実現できます。

いくら素晴らしい VPN や検疫の仕組みが存在していても、ユーザーID が適切に管理されていなければ意味がありません。なぜならば、全てのアクセス制御はユーザー ID が起点となるからです。ユーザーIDが適切に管理されていなければ、それに紐づくコンピューターやリソースを特定することもできず、セキュリティ上の問題が発生した際にアラートを送信する先さえわかりません。

とかく「デバイス」の安全性のみに目が向きがちですが、本当に管理すべきは ID であり、ID を中心としてすべてのリソースが紐づいている状態を維持しなければなりません。ID 管理は全ての基本であり、その上にアクセス制御が存在しているということを忘れてはなりません。もし、今のインフラでセキュリティがうまく機能していないとしたら、それは ID 管理に問題があるかもしれません。

Lync（リンク）

支店や顧客先、喫茶店など、オフィス外で業務を遂行する際に問題となるのがチームメンバーとのコミュニケーションです。

以前は携帯電話さえつながれば問題ない...という考え方が中心でした。確かに以前からテレビ会議システムは存在していましたし、実際に導入された企業も多いでしょう。しかし、それは「テレビ会議室」という特別な施設が必要とされ、例えば喫茶店で手軽にミーティングに参加するといった目的とはかけ離れていました。

一方、コンシューマー市場には Skype や Live Messenger など、動画や音声、文字を使用した手軽なコミュニケーション手段が浸透してきました。多くのユーザーがこうした携帯電話以外のコミュニケーション手段に慣れ親しみ、独自に使い始めていました。オンラインゲームの世界でも、友達がオンラインかどうかをチェックし、ヘッドセットで通話しながらゲームを共同で進めるといったことが当たり前のように行われています。

問題は、企業がそうしたテクノロジーを取り入れるには、それらがあまりにも社内セキュリティの統制外であったということです。

Lync は、そうした不便を解消し、現代の働き方に合ったコミュニケーションを実現するためにリリースされました。

Lync でできることは、おそらく皆さんのご想像通りです。

• Active Directory との統合
• オンライン会議
• 動画を使用した音声通話（内線のみでなく外線への通話も可能）
• 画面共有

これだけを見ると、「なにも今までも変わらないじゃん」と思われるかもしれませんが、実際は大幅な改善がなされています。

以下は Lync クライアントのコンソール画面です。利用者は、このコンソール画面を起点として、チームメンバーのプレゼンスをチェックしたり、メンバーと会話やチャットすることができます。また、複数のメンバーを選択して通話を開始すれば、そのままオンラインミーティングになります。

プレゼンスはあらゆる Office 製品で確認することができます。以下は OUTLOOK のメール送信画面および、WORD の IM 送信画面ですが、ユーザー名が表示される場所では、かならずユーザーのプレゼンスを確認することができます。

なお、チャット機能は多くの企業で使用を禁止しているかもしれません。しかし業務の効率を考えてみてください。まずはプレゼンスで相手の状態を確認し（会議中かどうかなど）、次にチャットで会話可能かどうかを確認し、そのうえで CALL したほうが絶対に「横入りのストレス」が軽減されます。

会議は何もオンラインだけではありません。以下の図ように、一部のチームメンバーが外出していたり在宅勤務の場合もあるでしょう。こうした場合でも、社内の誰か一人（例えば会議主催者）が Lync に接続しさえすれば、外出中のメンバーを含めた会議が可能です。PC にWEBカメラが搭載されていれば、全員の顔を見ながら会議をすることもできます。もちろん、主催者が会議室のスクリーンにデスクトップを表示しつつ、Lync で画面を共有すれば、出張先にいながら同じ画面を参照することができます。

東日本大震災の発生後 1 週間、交通網のマヒにより全てのマイクロソフト社員は在宅勤務を強いられました。そのような状況下でも、Lync によって確実に会議は開催され、決定すべき事項は遅延なく決定されました。

なお、Lync を使用するには Lync Server を構築する必要がありますが、Office 365 を契約すれば Lync Online を使用することもできます。

Lync の詳細は以下をご覧ください。

• Lync 2010（製品情報）
• Lync Server（技術情報）
• Lync Online - クラウドの統合コミュニケーション - Office 365

つづき

前回までの投稿は以下の通りです。

• マイクロソフトの IT コンシューマライゼーション 全体像 1
• マイクロソフトの IT コンシューマライゼーション 全体像 2

3.2 どこからでも接続 ～ 個人のデバイスから社内に接続する①

個人デバイスとしては、通常のノートPC、そしてタブレット、スマートフォンが挙げられますが、ここではノートPCとタブレットを軸にお話ししたいと思います。

BYOD（Bring Your Own Device）という言葉がはやっているように、個人のデバイスを業務で使用したいという要望が大きいことはご認識の通りです。PC の買い替えのスピードは企業よりも個人のほうが早く、個人のほうが社内支給デバイスよりも高性能のデバイスを使用しています。このことは業務遂行のストレスとなり、生産性の低下を招きかねません。

個人デバイスを業務で使用する場合、もっとも心配なのはセキュリティです。個人デバイスは社内支給のデバイスと異なりセキュリティポリシーが適用しづらい難点があります。そのため、多くの企業では個人デバイスの業務利用を禁止せざるをえない状況だと思われます。また、個人デバイスに保存された情報の流出も心配です。

では、個人デバイスを使用して、安全に業務を遂行させるためのインフラは存在するのでしょうか？

はい、存在します。

以下は個人のデバイスを社外から使用することを想定したイメージですが、これは、社内からであっても基本的な考え方は変わりません。

個人のデバイスを使用させる場合に問題となるのは以下の事項です。

• どうやって社内リソースにアクセスさせるか
• どうやって個人デバイスのセキュリティに依存しない環境を提供するか
• どうやって社内で使用しているアプリケーションと同じアプリケーションを使わせるか

そして、すこし欲張りな要望として以下が挙げられるでしょう。

• どうやって社内の個人環境を復元するか

これまで、多くのIT部門が上記に頭を悩ませ、さまざまなルールを作ってきたはずです。中には破綻してしまったルールも少なくないと思います。

これらのニーズを一気に満たすことができるソリューションが VDI（Virtual Desktop Infrastructure）です。

VDI ソリューションは各社からリリースされており、いずれを選択するかは現在導入されているインフラストラクチャーとの相性によるでしょう。マイクロソフトが提供する VDI のメリットを最大限に生かすのであれば、Active Directory によるユーザーIDおよびコンピューターの集中管理が必須です。

VDI ソリューションを使用すると、以下に示すような運用が実現できます。つまり、社内に用意したクライアントOSに、リモートから入り込んで使用することができます。

すでにご想像通り、リモートから社内に入り込む際に使用するのは、リモートデスクトッププロトコル（RDP）です。リモートデスクトップによる接続を有効にしたクライアント OS を社内に用意しておき、社外の PC から RDP クライアントを使用して入り込みます。Windows Server とは異なり、Windows XP や Windows 7 のようなクライアント OS の場合、同時に接続できる リモートデスクトップセッションは 1 つなので、一度に外部から利用するユーザーの数だけクライアントOSを用意しておく必要があります。

リモートデスクトップを使用するメリットは、「セッションの分離」が実現できることです。ユーザーが使用しているクライアントからリモートデスクトップを使用して社内の PC に接続したとしても、両者には明確なセッション境界が存在し、お互いに影響を及ぼしあうことができません。極端な話、利用者の PC が数百のウィルスに感染していたとしても、境界線を越えてリモートデスクトップセッションに入り込むことはできません（もちろん、そのためにはリダイレクト機能を無効にしたり、ネットワーク的な接続経路を遮断しておく必要があります）。

リモートデスクトップセッション内で使用している社内データは、背後から除かれる心配はあるにせよ、そのデータがセッションを超えて社外に流出したり、PC に感染しているウィルスに影響を及ぼされる心配もありません。

さらに、データ自体は社内にあるので、万が一 PC を紛失してしまってもデータも同時に紛失してしまう...ということもありません。

さて、ここで多くの方が、以下の一文に何か気持ち悪いものを感じているでしょう。

「一度に外部から利用するユーザーの数だけクライアントOSを用意しておく必要があります。」

安心してください。クライアントOSを用意するとは書きましたが、「PCを用意する」とは書いていません。

以下はマイクロソフトの VDI ソリューションの模式図です。

上の図にあるように、ポイントは5つです。

• クライ���ント OS の仮想化
• アプリケーションの仮想化
• ユーザーステータスの仮想化
• コネクションブローカー
• 運用管理

■ クライアントOSの仮想化

不特定多数のユーザーが利用するクライアントを物理的に用意する必要はありません。クライアント OS は、Windows Server Hyper-V 上に集約してしまえばよいのです。ユーザーの PC から見て、クライアントOSが仮想化されているかどうかは問題になりません。OS のインストールも通常通り Windows 7 メディアを使用できるので、Hyper-V さえセットアップできれば特に難しいことはありません。

ただし、クライアント OS を仮想化し VDI 環境を提供しようとすると、新たな課題も見えてきます。それらを以下に挙げてみます。

仮想化されたクライアントの UX
• 色の再現は（減色されたりしないか）？
• 解像度は？
• 音声や動画の再生は可能か？
• USB デバイスなどを使用できるか？
• 印刷は可能か？
個人環境の保存や復元は？
クライアントの集約率
• クライアントごとのメモリ確保
• 仮想クライアントを保存するサーバーのディスクスペース
仮想クライアント OS の管理
• 利用者が増減にどう対応できるのか？
• 無駄な電力を使わないか？
• 資産管理やサポートはどうするか？

これらの問題を解消するため、以下のようなテクノロジーや製品が提供されています。

• RDP 7.1
  最新のリモートデスクトッププロトコル。
  仮想デスクトップ上での Aero を使用した高品質な表示やデバイスのリダイレクト機能などにより、よりローカル PC に近い環境を再現できるようになった。
• RemoteFX
  サーバーに実装されたGPUを使用して3Dグラフィックスのデコードが可能
  RDP7.1 標準で対応していない USB デバイスを仮想デスクトップにリダイレクト
• Dynamic Memory
  Hyper-V 上の仮想OSに割り当てるメモリ量を動的に変更できる。初期設定で1024GBと設定されていても、未使用であれば徐々に使用量が減り、たのアクティブな仮想OSに再割り当てされる。
• Pooled Virtual Desktop
  例えば100人が仮想 OS を利用するとして、100 の仮想クライアントを準備しても、これらが常に使用されるとは限りません。利用率が30%であれば、30台だけ用意しておき、空いているところに自動的に接続するようにできればハードディスクやメモリ、CPUの使用効率を抑えることができます。Pooled Virtual Desktop はそのような機能を提供します。 また、仮想クライアントを停止しておいても、アクセス要求に応じて起動する...と言った設定も可能なので、"微々たるものではありますが"未使用時の電力量を節約することもできます。
• System Cetner シリーズおよび Windows Intune
  30 の仮想クライアントを準備するには、Widnows 7 Enterprise のインストールを 30 回繰り返す必要があります。あたりまえです。でも、そんなこと受け入れられますか？受け入れられません。そこで登場するのが System Center Virtual Machine Manager です。事前にクライアントOSのテンプレートを作成しておき、必要に応じて仮想マシンを増やしたり、減らしたりすることができます。なんなら、ユーザーからの要求に応じて即時作成したり...と言ったことも可能です。その他の System Center 製品を使用すると、ホストやゲストのパフォーマンスを監視して、別の Hyper-V サーバーにダイナミックにマイグレーションしたり、といったことも可能です。VDI は「幽体化した PC 教室」であると言えます。文教担当のSEさんならばご存知の通り、PC 教室のメンテナンスって結構大変です。それが仮想化されて「ブツ」が見えないとなると、いままでの管理の常識が通用しない場面が多くなります。それをカバーするための運用管理製品も、とても重要なのです。

長くなってしまったのでこのへんで。

次回は、3.2 どこからでも接続 ～ 個人のデバイスから社内に接続する② をお送りします