どうでもいい話なのですが、久しぶりにOSのセットアップではまりました。

先日 UST 配信用に、以下のノートブックPC を会社に買ってもらいました。

IdeaPad Y570
Lenovo - ノートパソコン - IdeaPad - Yシリーズ – Y570

このマシンには、もともと Windows 7 Home がインストールされていたのですが、社内ドメインに参加したかったので Windows 7 Enterprise にアップグレードしようとしたのです。

時間が無かったので修復ディスクを作成せず（IT Pro にはあるまじき行為！）、ドライバーが入っているフォルダだけバックアップを取り、Windows 7 Enterprise のメディアを挿入...インストールを開始しました。

当然クリーンインストールしたいので、目に見えるパーティションは内側からえぐりこむように削除！削除！削除！

そしたらですね...やってしまいました。いくらインストール先のディスクを選択しても、「システム パーティションを作成できません」というエラーで先に進めません。

今回の Y570 というマシンには、64GB SSD（Disk 0）に加えて 700GB HDD（DISK 1）が内蔵されています。当初は SSD が認識できないのかと思い、ドライバの読み込みなどいろいろと試していたのですが一向に埒があきません...orz。

時間もないし、情報もない....。

仕方が無いので最終手段を取ることにしました。

そうです。ディスクの構成情報をきれいさっぱり消してしまおうという、ある意味暴挙です。捨てるものが無いからこそできる荒業です。

今後同じ境遇に合われた方のために、今回の手順を残しておきます（たいした手順じゃないですが）。

↓

↓

↓

↓

↓

これで修復モードのコマンドプロンプトが起動できました。

あとは、以下のようにディスクを選択してから Clean コマンドを実行して、ディスクに書かれた構成情報をクリアしてしまいます。

これでディスクはきれいになり、無事クリーンインストールを行うことができるようになりました。

あくまでも、トラブル回避の一例とです。

Cleanコマンドの詳細は、@IT さんの以下のページにとてもよくまとまっています。

diskpartのcleanコマンドでディスクの内容を消去する － ＠IT

久しぶりに Windows Update をスクリプトから実行しようかなぁと思って PowerShell のコマンドレットを探していたら、標準では提供されていないんですねぇ。全く気づいておりませんでした。

となると、VBScript のように Microsoft.Update.Session を呼び出すしかないものかと思っていると、なんと便利なモジュールが提供されていました。

Windows Update PowerShell Module
http://gallery.technet.microsoft.com/scriptcenter/2d191bcd-3308-4edd-9de2-88dff796b0bc

さっそく使ってみましょう。

まずはダウンロードして ZIP ファイルを開いてみてください。PSWindowsUpdate フォルダが格納されているはずです。この中にこのモジュールを構成するスクリプト群が格納されています。

これらのファイルは「インターネットゾーンからダウンロードしたファイル」なので、必ず「ブロックの解除」を実行しておきましょう。でないと実行できません。

• 【PowerShell】一括で「ブロックを解除」する ～ Windows PowerShell 編 その1
  http://blogs.technet.com/b/junichia/archive/2012/01/13/3475162.aspx
• 【PowerShell】「ブロックを解除」するためのメソッドを追加してみる
  http://blogs.technet.com/b/junichia/archive/2012/01/15/3475439.aspx
• 【Management】一括で「ブロックを解除」する streams コマンド編
  http://blogs.technet.com/b/junichia/archive/2012/01/12/3475091.aspx

ブロック解除が完了したら、PSWindowsUpdate フォルダを、PowerShell のモジュール用フォルダに保存します。

モジュール用フォルダの場所を確認するには、以下のように PowerShell コンソールから環境変数 PSModulePath を確認します。

（参考）Windows PowerShell: Windows PowerShell のカスタム ツールをパッケージ化して配布する

ここでは3つのパスが指定されています。

以下のパスはユーザーの個人的なモジュールパスで、今回はモジュールを追加するのでこの配下に PSWindowsUpdate フォルダを移動してください。なお、既定ではこのパスは存在しないので、自分で作ってください。

• C:\Users\junichia\Documents\WindowsPowerShell\Modules

以下のパスはシステムモジュール用のパスです。

• C:\windows\system32\WindowsPowerShell\v1.0\Modules\

以下は Windows Azure 用コマンドレットをインストールしたときに作成されたパスでしょう。既定では存在しませんので、無くても不安にならないでください。

• C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\

PSWindowsUpdate フォルダを移動したら、コンソールから Import しましょう。

ブロック解除が行われていれば、特にエラーは出力されないはずです。

次に、コマンドレットの一覧を見てみましょう。以下の用の出力されたら問題ありません。

それぞれのコマンドレットの用途は、なんとなーくわかりますよね。

具体的な使い方は次の投稿で。

超軽い話題を。

Windows PowerShell を使用してメールを送信するには Send-MailMessage コマンドレットを使用します。例えば、以下のように使います。

-Credential はSMTPサーバーに接続するための資格情報です。事前に Get-Credential で設定してもよいですし、上の例のように指定すればパスワード入力のためのポップアップが表示されます。

このように、Send-MailMessage は簡単でとても便利なのですが、SMTP のポート番号を変更できないという難点があります。

例えば、Gmail 、Office 365 、Hotmail ともに、メッセージのサブミッション時には Port 587 を使用しています。そのため、Send-MailMessage を使用してメールを送信することができません。

では、どうしたらよいかというと、.NET Framework の Net.Mail.SmtpClient を直接使用します。

例えば、gmail の場合には SMTPサーバーは smtp.gmail.com なので 以下のように書きます。

Office 365 ならば以下の通りです。

知っていれば簡単ですね。

Scripting Guy の以下の投稿も参考にしてください。
Send Email from Exchange Online by Using PowerShell - Hey, Scripting Guy! Blog - Site Home - TechNet Blogs

Active Directory on IaaS の構築手順書を公開しました。

手順書は以下のキャンペーンに応募していただくと GET できます。なんか面倒でごめんなさい。。。いろいろ大人の事情がありまして。。。。

応募いただくと 240GB Intel SSD なんかも当たるかもしれないので、どうぞよろしくお願いいたします。

http://technet.microsoft.com/ja-jp/windowsserver/dn715816

この構築手順書では、以下の環境を作成します。

クラウドサービスとか、可用性セットとか、負荷分散セットとか、Azure なコツがちょっとだけ必要なので、一から勉強するよりかはこの手順書でサクッと評価してもらったほうが手っ取り早いです。

オンプレミスには何も必要ありません。すべて、Microsfot Azure 無償評価版の範囲内で構築できます。

当キャンペーンは終了してしまいましたが、こちらからダウンロードできます！

http://technet.microsoft.com/ja-jp/windowsserver/jj649374.aspx

すっかり定番となった管理ツール「グループポリシー」ですが、日本語版の全設定項目リファレンスが無いってのがタマに瑕でした。

英語版はリリースされてるんですけどね。。。
（参考）http://www.microsoft.com/en-us/download/details.aspx?id=25250

そこで、いま Windows Server 2012 R2 評価版ダウンロードに登録してくださったみなさま全員に、日本語版 グループポリシー設定リファレンスガイドをプレゼント中です。

※評価版ダウンロードは以下からどうぞ。
　http://technet.microsoft.com/ja-jp/windowsserver/jj649374.aspx

ご覧ください。しっかりと日本語化されています！ヘルプも完璧です。

実はこれ、"翻訳したんじゃないんです"。とある PowerShell プロフェッショナルな方にお願いして、スクリプトを作ってもらったんです。
詳しくは後日。。。

さらに、評価版ダウンロード登録後にキャンペーンに応募してくださると、以下の書籍も抽選でプレゼント。

期間は1か月と短いのですが、この機会をお見逃しなく～

Terminal Service Team Blog に以下の記事が投稿されました。

Using Multiple Monitors in Remote Desktop Session
http://blogs.msdn.com/rds/archive/2009/07/01/using-multiple-monitors-in-remote-desktop-session.aspx

タイトルのとおり、RDP 7.0 からサポートされたマルチモニタ機能に関する記事です。この記事では5つのモニタを接続して、RDP Client上でPowerPointを起動してモニタの切り替えをテストしています。

どれどれ..ってことで、私も確認してみました。

まず、自分のノートPC（Windows 7 RC）に外部モニタを接続し、以下のようにモニターの設定をします。今回は上下に並べました。

＃ところでモニター並べ方って、かなり柔軟にできるんですね。上下左右をずらしたり…知りませんでした。

次に、mstsc.exe を起動し、[画面]タブから[リモートセッションですべてのモニターを識別する]をチェックした状態でリモートのコンピューター（Windows Server 2008 R2）に接続します。すると、以下の真ん中の写真のように、モニター１とモニター２がRDPクライアント上で識別されていることがわかります。

ためしに画面のプロパティを見てみると、Windows 7で設定したものと同じ設定が表示されています（変更することはできません）。

また、「評価ビルド」であることを示す表示が2箇所に表示されていることからも、2つの画面として認識されていることがわかります。

ちなみに、[リモートセッションですべてのモニターを識別する]のチェックをはずした状態ですと、以下のようになります。

画面として1つしか認識されていないことがわかります。

これで、VDIも安心ですね！？

ヒトはパンのみに生きるに非ず…とか言うようですが、わたしは PowerShell のみに生きてもよいとさえ思っています。もうたまりません。いま、可愛いヤツ ランキングをつけたら、間違いなく Windows PowerShell が1位です。2番目が 赤ちょうちん の頃の秋吉久美子。３番目に偕楽園の梅娘と写真を撮ってくれと泣いてせがんだ5歳の頃の自分です。

アクセス権の一覧を作りたいけど、うまい方法が無くて困っている方はいらっしゃいませんか？これまで、CACLSコマンドとかを使ってきて、うーんどうも…じゃVBSで作るか！と思い立ったものの、以外に難しくて断念したり…（VBSを使う方法は知っておく価値アリなので、時間のあるときに解説しようかとも思っています）。

いい方法があるんです。Windows PowerShell の Get-ACL コマンドレットです。

このコマンドレット１つで、ファイルシステムも、レジストリも、はてはActive Directory のオブジェクトに関してもアクセス権を参照することができるのです！現場のSEさんにとって、これほど便利なコマンドがいままであったでしょうか？いや無いです。

■ファイルシステム編

まずはPowerShell のコンソールを開いてください。

以下は、C:\ に設定されているアクセス権を取得しています。

PS C:\> Get-ACL c:\ | Out-GridView

出力結果は以下の通りです。パイプ（|）を通して、Out-GridView に結果を渡しています。

うーん。見やすい…。ちなみに、おなじみCACLSコマンドを使用した結果は以下の通りです。

PS C:\> cacls C:\ | Out-GridView

うむむ、いまいちですよね。やっぱり、Get-ACL の結果のほうが美しいです。

では、Get-ACLの結果を CSVファイルに保存するにはどうするかといえば、以下のようにします。ちょっと長いですが、1行で書けてしまいます。

PS C:\> Get-Acl C:\ |Select-object @{Label="Path";Expression={Convert-Path $_.Path}}, Owner, AccessToString |Export-Csv C:\tmp\accesslist.csv

CSVファイルに保存するには、Export-CSV コマンドレットを使うのが簡単です。ここでは、C:\tmp\accesslist.txt というファイルに保存しています。

さて、難しいのは、「Get-ACL」と「Export-CSV」の間にあるSelect-Object ですよね。ためしに、Get-ACL の結果をそのまま Export-CSVを使って保存してみてください。Path、Owner、AccessToString以外のプロパティも保存されてしまうことがわかります。今欲しいのは、ひとまず3つの属性だけなので、Select-Object を使用して、Get-ACLの出力結果から必要な3つの属性だけを抜き出しています。

もう1点、以下のコマンドで、Path の値を見てください。

PS C:\> Get-Acl C:\ |Select-Object path Path ---- Microsoft.PowerShell.Core\FileSystem::C:\

Path の値として「Microsoft.PowerShell.Core\FileSystem::C:\」という文字列が格納されていることに気づくと思います。これはPowerShell内での絶対パスの表現方法です。例えば、レジストリの場合には、Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\ 、Active Directory ならば、ActiveDirectory:://RootDSE/CN=Schema,CN=Configuration,DC=contoso,DC=com といった具合です。

Microsoft.PowerShell.Core\FileSystem:: が入っているからと言って意味不明なものでもありませんが、管理上、ちょっと気持ち悪いですね。

そこで、このPowerShell上の絶対パスを、ファイルシステムやレジストリ、Active Directory 内の相対的なパスに変換したいと考えるわけですが、この時に使用するのが Convert-Path コマンドレットです。ためしに、以下のように入力してみてください。結果として、ファイルシステムプロバイダー内の相対パスである C:\ が結果として得られます。

PS C:\> Convert-Path( (Get-ACL C:\).Path ) C:\

で、残った問題は @{Label="Path";Expression={Convert-Path $_.Path}} が何を意味しているかですよね？

なぜ単純に、Select-Object {Convert-Path $_.Path}, Owner, AccessToString と書かないのか？ためしに書いてみると、以下のような結果になります。

PS C:\> Get-Acl C:\ |Select-Object {Convert-Path $_.Path}, Owner, AccessToString Convert-Path $_.Path          Owner                         AccessToString --------------------          -----                         -------------- C:\                           NT SERVICE\TrustedInstaller   NT AUTHORITY\Authenticated...

何がダメなのかわかりますか？そうです。ラベル名として Path が欲しいのに、Convert-Path $_.Pathとなってしまうのです。せっかくCSVに保存するのですから、きれいにしておきたいですね。そこで、@{  }の登場です。@{   } は、Key-Value 型の配列を表現しています。

わかりずらいので、図にしてみました。以下をご覧ください。Get-ACL の戻り値は、以下の図に書かれた表のように、LabelとExpressionの対で格納されています。

つまり、@{Label="Path";Expression={Convert-Path $_.Path}}  は、Label の値が「Path」の列のExpressionの値を「Convert-Path $_.Path 」という値に置き換える..ということを意味しています。

これで疑問解決ですね。

安心して、以下を実行してください。

PS C:\> Get-Acl C:\ |Select-object @{Label="Path";Expression={Convert-Path $_.Path}}, Owner, AccessToString |Export-Csv C:\tmp\accesslist.csv

保存された accesslist.csv ファイルをEXCEL等で開くと、以下のように見えるはずです。

Path	Owner	AccessToString
C:\	NT SERVICE\TrustedInstaller	NT AUTHORITY\Authenticated Users Allow AppendData NT AUTHORITY\Authenticated Users Allow -536805376 NT AUTHORITY\SYSTEM Allow FullControl NT AUTHORITY\SYSTEM Allow 268435456 BUILTIN\Administrators Allow 268435456 BUILTIN\Administrators Allow FullControl BUILTIN\Users Allow ReadAndExecute, Synchronize

この表の中で、アクセス権が数値で書かれているものがあります。これらは、特殊なアクセス権を表現しています。

• -536805376：サブフォルダーとファイルに対する特殊なアクセス権
  
• 268435456 ：サブフォルダとファイルに対するフルコントロール

これら数値は、特殊なアクセス権の組み合わせによって変わります。

複数のファイルやフォルダのアクセス権を取得する際にはワイルドカードを使用することもできます。

PS C:\> Get-Acl *.txt

また、指定したフォルダ配下を全てなめてアクセス権を取得するには、Get-ChildItem を使用して、以下のように書きます。複数行にまたがっていますが、改行なしの1行です。

PS C:\tmp> Get-ChildItem -Recurse |Get-Acl | Select-object @{Label="Path";Expression={Convert-Path $_.Path}}, Owner, AccessToString |Export-Csv C:\tmp\accesslist.csv

長くなってしまったので、レジストリとActive Directoryについては次回で。

すぐに試してみた方は、PowerShellのコンソールで、「CD HKLM:」または「CD AD:」と入力してから Get-ACLしてみてください。感動すると思います。

前回は「チャンバー」の概念についてお話ししました。

【WP for IT Pros】Windows Phone のセキュリティモデルについて～「チャンバー」という考え方(1)

今回は、その補足的な内容となるのですが、「機能ベースの権限モデル」と「サンドボックス」について書きます。

■ 機能（Capabilities）ベースの権限モデル

「機能」とは別の言い方をすれば「リソース」です。Windows Phone にはさまざまな機能が実装されており、「位置情報」「カメラ」「マイク」「ネットワーク」「センサー」などが「機能」に該当します。これらの機能は、Windows Phone の使い方と密接に関連していることは言うまでもありませんが、機能こそが「ユーザープライバシー」「セキュリティ」「コスト」「ビジネスに関する考慮事項念」などに影響を与えることになります。

既に述べたように、LPC（Least Privileged Chamber）には規定で必要最小限のアクセス権限が与えられています。しかし、だからといって LPC 内のアプリケーションがそれ以上の機能を使用できないわけではありません。例えば LPC 内のアプリケーションが「カメラ」機能を使用する必要がある場合には、アプリケーションのインストール中に「カメラ」へのアクセスがユーザーに打診されます。ユーザーがそれを承認すれば、アプリケーションはカメラ機能を使用することができるようになります。ただし、こうした権限の昇格はアプリケーションの実行中に与えられることは無く、かならずアプリケーションを使い始める前に承認される必要があります。

このようにして、LPC はダイナミックに「機能」によってによって権限が拡張されます。これを「機能ベースの権限モデル」と呼びます。

機能ベースの権限モデルには、以下のような利点が挙げられます。

- アタック面の最小化

それぞれのアプリケーションは、その動作に必要最小限の「機能」のみを使用する。攻撃の対象はそれらの機能に付随することになるが、逆に言えばその範囲に留まるということでもある。

- ユーザーの承諾と制御

それぞれのアプリケーションが利用者に対して、どのような機能を使用するのかを提示する義務を負う。規定では、以下に示す場所とタイミングで使用する機能を提示しなければならない。

• Windows Phone Marketplace 内のアプリケーション詳細説明ページ
• アプリケーションの購入画面
• アプリケーションを最初に使用するとき

アプリケーションの開発者は、Windows Phone の開発ツールを使用して、機能リストを作成する必要があります。機能リストはアプリケーションパッケージの WMAppManifest.xml ファイルに格納されます。

■ サンドボックス

Windows phone の全てのアプリケーションが、それぞれの分離したチャンバーの中で事前に定義された機能とともに動作することは既に述べたとおりです。

このとき、必要最小限の権限が全てのアプリケーションに与えられますが、その中には「分離ストレージ」へのアクセス権も含まれています。アプリケーション間には、クラウド等の外部デバイスを除き、いかなる通信チャネルも存在していません。アプリケーションは互いに完全に分離されており、当然のことながら互いのメモリやデータにアクセスすることもきません。これにはキーボードのキャッシュも含まれています。

加えて、Windows Phone はバックグラウンドで動作することも許されていません。これにより、意図的に隠されたアプリケーションや、いわゆるスパイウェアから利用者のデータを守っています。利用者が別のアプリケーションに切り替えたときには、これまで使用していたアプリケーションは休止状態となり、それまでの動作状態が保存されます。こうしたアプローチにより、アプリケーションがリソースを食いつぶしたり、裏で勝手にインターネットにアクセスするといったことを抑止しているのです。

本来参照する権限を持たないユーザーに対して社内情報を流出してしまうなど、スマートフォンにありがちな一般的なリスクを軽減するには、堅牢なセキュリティで守られたデバイス上にアプリケーションを展開する必要があります。

Windows Phone はデバイス自身がこのようなセキュリティで守られている他、Exchange Active Sync（EAS）によりセキュリティポリシーの集中管理が行えるようになります。EAS については別の記事で解説します。

以下につづく

【WP for IT Pros】Windows Phone のセキュリティモデルについて～データの保護

Windows Server 2008 で刷新された「ポリシーベースのQoS」を使ったことがある方、手を挙げてください。

あぁ、すくないですね。実は、私も一度も使ったことがありませんでした。

で、本当にこんな標準機能ごときで帯域制御なんてできるの？ってことで試しに使ってみました。

設定方法は簡単です。グループポリシー管理コンソールの「コンピュータの構成」または「ユーザーの構成」の配下にある [Windowsの設定] - [ポリシーベースのQos] にエントリを登録するだけです。

設定の手順は以下の通りです。非常に簡単です。

はじめにポリシーの名前を入れて、DSCP値とスロットル率を指定します。以下の画面ではスロットル率（帯域）に300kbps と指定してあります。つまり、このポリシーが適用されるコンピューターまたはユーザーは300Kbpsの帯域しか使えないということです。

つぎに、このポリシーの対象となるアプリケーションを指定します。ファイル転送等をおこなう業務アプリケーションのファイル名（.exe）を指定すれば、そのアプリの通信だけをQoSの対象とすることができます。今回は Internet Explorer のファイル名である iexplore.exe を指定しています。

次のページではQoSのターゲットとする「送信元」と「送信先」を指定します。必要に応じてIPアドレス等を指定してください。

最後に、QoSの対象とするポート番号です。これも、送信元と送信先を分けて指定することができます。今回は80番を指定しました。

ちなみに、Windows間のファイルコピーに使用するSMB（2008-Vista では SMB2)は、主に Port 445（送信先）が使用されますが、他にもいろいろな場面で使われるので、このポートで帯域を制限するのはお勧めできません....。

以上で設定は完了です。gpupdate /force でグループポリシーを適用したらさっそく通信してみましょう。

ここでは、インターネット上の SkyDrive に Internet Explorer から10MB程度のファイルをアップロードしてみました。

スロットル率 100Kbps と 500kbps それぞれの場合にパフォーマンスモニタでグラフを作成したものが以下です。明らかに違いが出ていることがわかりますね。無線LANの環境が遅いので、500kbpsの制限まで使い切っていませんが...。

次に、イントラネット環境におけるファイルのバックアップを想定した動きを試してみましょう。

バックグラウンドでファイル転送のプログラム（バックアップエージェント）が自動的に動くものと想定します。そして、業務時間中のバックアップサーバーとの通信を300Kbpsに制限したとします。業務時間が過ぎたら（例えば17時に）自動的にスロットル率を解放したらどうなるか？という実験結果です。

以下のように、ポリシーが適用された（スロットル率が解放された）瞬間にネットワーク使用率が跳ね上がっていることがわかります。

＜－－Recived でなくて Received ですね...お恥ずかしい

以下のグラフは、バックアップサーバー以外との通信がどうなるかを示したものです。グラフをご覧いただくとわかる通り、QoS対象以外との通信には制限が掛けられていないことがわかります。

どうでしょう？おもしろそうですよね。

ただ、以下の現象が見られました。うーんなんでだろう...ちょいと調査中です。

• Windows Server 2008 にはうまくユーザーポリシーが適用できなかった（CSEがVistaとレベルが違う？？）
• Xcopy を制限アプリとして登録してもうまくいかなかった（cmd.exeも同様）

まだまだ埋もれた機能がたくさんありますので、ご紹介します。

「埋もれた機能を使ってみた！」という方、是非ともお知らせください！こちらでご紹介いたします！

VHDBOOT で使用していた VHDX ファイル（Windows 8 Enterprise）をメンテナンスしようと、Hyper-V 上の仮想マシンのシステムディスクとして設定し起動しようとしたところ、以下のようなエラーが発生して起動できなくなってしまいました。

回復

お使いの PC は修復する必要があります。
要求されたデバイスが接続されていないか、デバイスにアクセスできません。

エラーコード: 0xc000000e

仰せの通りに回復ツールで回復しようと思い「PCのリフレッシュ」を実行しようとしたところ、今度は以下のエラーが出ました。

Windows がインストールされているドライブがロックされています。ドライブのロックを解除してやり直してください。

VHDX ファイルをマウントして確認してみても、特におかしなところはみあたらず。

調べてみると、0xc000000e エラーは BCD ストアの破損に類するトラブルらしく、ここを修復しないことにはどうにもなりません。

(参考)ブート構成データ（BCD）ストアを理解すれば VHDブート は簡単
http://blogs.technet.com/b/junichia/archive/2009/10/26/3289120.aspx

ひとまず仮想マシンに Windows 8 の ISOイメージをマウントして、ISOから起動します。

「今すぐインストール」を脊髄反射でクリックせずに、おちついて「コンピューターを修復する」をクリック。

「トラブルシューティング」を選択。

「詳細オプション」を選択。

「コマンドプロンプト」を選択。

コマンドプロンプトが表示されたら、すかさず bcdedit コマンドでBCDストアの状態を確認してみます。

すると。。。なんと、device エントリと osdevice エントリが unknown ! これじゃ、起動するはずがありません。

ということで、bcdedit コマンドでエントリを正しく修正します。対象となるエントリの  Identifier が {1b09e76-2efa-11e2-aca3-e1d02980083a}  であることは、以下に表示されているとおりです。

起動したい Windows 8 は D ドライブとして見えています。

よって、以下のコマンドで正しい情報を登録します。

bcdedit /set {1b09e76-2efa-11e2-aca3-e1d02980083a} device partition=D:

bcdedit /set {1b09e76-2efa-11e2-aca3-e1d02980083a} osdevice partition=D:

Exit して再起動すると、今作成したエントリから無事起動することができました。

冷や汗かきました。

以下に Windows PowerShell 3.0 のオンライントレーニングコースが公開されています。

もちろん日本語です。

PowerShell 3.0 を使用した高度なツールとスクリプト
http://www.microsoftvirtualacademy.com/training-courses/advanced-tools-and-scripting-with-powershell-3-jump-start-japanese#?fbid=pJeqjxv8UId

是非テストに挑戦していただきたいのですが、テストの解説がどこにも掲載されていないので、今日から9回に分けて解説したいと思います。

PowerShell V3 をサポートしているオペレーティング システムは次のうちどれですか?

Windows PowerShell v3 を利用するには Windows Management Framework 3.0 が必須です。

Windows 8 および Windows Server 2012 以降には標準で組み込まれていますが（Windows 8.1 および Windows Server 2012 R2 には v4 が組み込まれています）、それ以前の OS には以下からダウンロードしてインストールする必要があります。

http://www.microsoft.com/en-us/download/details.aspx?id=34595

Windows Management Framework 3.0 をサポートしている OS は Windows 7 Service Pack 1, Windows Server 2008 R2 SP1, Windows Server 2008 Service Pack 2 となります。

なので、設問中の Windows 7 は、微妙ですがサポート外ということになります。

スクリプトを使用して自動化する作業の種類はどれですか (2 つ選択してください)

これは結構悩ましい設問です。

「1回だけ発生して繰り返されない作業」については、一般的に自動化のメリットは得られずらいので選択肢としては妥当ではありません。

「アドホックな作業」とは、暫定的に行うような作業を意味しており、これも自動化できない作業と考えてよいでしょう。

よって、「管理者にとって一般的な作業」「繰り返し発生する作業」が選択肢としては適切です。

IT 環境における PowerShell の目的は何ですか

これも設問が漠然としていて難しですよね。

従来よりスクリプトの大きな目的は作業の自動化です。スクリプトがあるからといって、GUIの存在が必要なくなるわけではないし、手動の管理作業が必要なくなるわけではありません。

よって、最適な選択肢は「作業を管理および自動化するツールを提供する」になりますね。

PowerShell 3.0 の実行に必要な .NET Framework のバージョンはどれですか。

間違いやすい問題です。これは、Windows Management Framework 3.0 の動作条件を確認する必要があります。

以下にも記載されているように、.NET Framework 4.0 が必須となっています。

Windows XP でサポートされている PowerShell のバージョンはどれですか

サポート期限が 2014年4月に迫った Windows XP ですが、実は XP でも Windows PowerShell はサポートされていることをご存知の方は意外に少ないです。

実は、Windows Management Framework 2.0（Windows Management Core Package）は Windows XP SP3 用にも提供されており、これをインストーすることで Windows XP SP3 でも Windows PowerShell 2.0 を利用できます。

http://www.microsoft.com/ja-jp/download/details.aspx?id=16818

PowerShell の実行に使用するユーザー コンテキストはどれですか

これ、質問文が悪いですね。

言いたいのは「Windows PowerShell を実行する際に使用すべきユーザーコンテキストはどれですか？」という意味です。

ここでのユーザーコンテキストとは、「ユーザーの実行空間」とでもいえばよいでしょうか。なかなか訳しずらい言葉ですが。

要は、「どのユーザーの権限で Windows PowerShell を実行すべきか？」という問いです。

マイクロソフトにおける Windows PowerShell の位置づけはシステム管理ツールなので、「管理者コンテキスト」がただし答えになります。

Windows PowerShell のコンソールを開くときに「管理者として実行」を選択するようにしてね！というメッセージが込められています。でないと、管理作業がエラーになってしまうので。

PowerShell を管理者コンテキストで開くとプロンプトに表示されるディレクトリの場所はどれですか

「管理者コンテキスト」というところがミソですね。

実際にコンソールを開いてみれば一目瞭然です。

以下は「管理者として実行」を選択した開いた時のプロンプトです。

「管理者として実行」を選択しないと、現在のユーザーコンテキストで開かれるので、プロンプトは以下のようになります。

実行ポリシーを設定するには、どのコマンドレットを使用しますか

これは、これから Windows PowerShell を使用してシステム管理を始めようとする方が覚えておくべき事項の1つです。逆に言えば、これを知らないとシステム管理が先に進みません。

当然、こたえは「Set-ExecutionPolicy」ですね。

PowerShell のコンソールを開いたら、真っ先に以下のコマンドを入力してください。

Set-ExecutionPolicy  -ExecutionPolicy  RemoteSigned 

RemoteSigned は、「リモートからダウンロードしてきたスクリプトには署名が必須」という設定です。つまり、インターネット上に転がっているスクリプトをむやみやたらに実行できなくするわけですね。

ちなみに Windows Server 2012 までの規定値は Restricted（制限されている）です。つまり既定では自分で作ったスクリプトも実行できないので、これではあまりにも厳しすぎる。。。。ということで、RemoteSigned を使用するようにしましょう。R2 からは RemoteSigned が規定値になりました。

（参考） Set-ExecutionPolicy コマンドレットの使用 http://technet.microsoft.com/ja-jp/library/ee176961.aspx

PowerShell リモート処理の機能はどれですか

これは簡単だと思うのですが、どうでしょう。

「リモートデスクトップ」と書かれている選択肢は明らかに間違いです。リモートデスクトップはリモートデスクトップですからね。全く別の機能です。

答えは当然「リモート システムに対して対話的にまたはスクリプトで PowerShell を使用する機能」です。

Windows PowerShell を使用すると、スクリプトを使用してリモートのコンピューターを管理できます。これを「リモーティング」を言います。

リモーティング機能は、大きく分けて3種類の使い方があります。

1. 各コマンドレットの -ComputerName パラメタを使用する
2. Invoke-Command  -ComputerName を使用する
3. Enter-PSSession ｰComputerName を使用して、SSHのようにリモートコンピューターにサインインする

多くのコマンドレットでは -ComputerName をサポートしていますが、中にはサポートしていないものもあります。場合によっては、リモートコンピューターのDOSコマンドを実行したいことがあるかもしれません。

そのときは Invoke-Command を使ってください。Invoke-Command を使用すれば任意のコマンドやスクリプトを相手のコンピューター上で実行することができます。

対話的に相手のコンピューターに入り込みたい場合には、Enter-PSSession -ComputerName を使用します。

Windows Server 2012 の既定の実行ポリシーは何ですか

これ、問題または答えが間違えています。

本当は、「Windows Server 2012 R2 の既定の実行ポリシーは何ですか？」でないといけません。もしくは、答えが 「Restricted」 でないとつじつまが合いません。

前述したように、Windows Server 2012 R2 の規定値は RemoteSigned です。

もしこのままの問いだとすると、「Resricted」が答えになるので、満点が取れなくなってしまいます。満点が欲しい方は「RemoteSinged」で答えてください～。

http://technet.microsoft.com/en-us/library/hh847748.aspx

本日の講義はここまで。

次回は、Part2 PowerShell のスクリプト言語 編 です。

※ この投稿は Windows Azure Advent Calender に参加しています。

System Center は言うまでもなくマイクロソフトの運用管理製品です。最新版は System Center 2012 R2 です。

System Center を使用すると、オンプレミスのインフラストラクチャーに加えて、Windows Azure に展開したインフラストラクチャーやアプリケーションも管理、監視できます。

以下のコースウェアでは、System Center を使用して Windows Azure を含むハイブリッドクラウド環境を管理することを学習することができます。

System Center と Windows Azure を使用したハイブリッド クラウドへの移行ジャンプ スタート
http://www.microsoftvirtualacademy.com/training-courses/38d1d8c0-240e-432b-994c-ab34e71088b6#?fbid=pJeqjxv8UId

各モジュールにはテストも用意されていますが、解説が無いので、このBLOGで各問の開設をしたいと思います。

今回は「01 | 監視、管理、および運用」について。System Center の基本的な機能について学習しましょう。

Q) System Center Operations Manager を使用して、クラウドに展開した WEB アプリケーションの可用性とパフォーマンスを監視する必要があります。次のうちどの Operations Manager の機能を使用しますか。

1. Windows の管理パック
2. ネットワーク デバイスの監視
3. Hyper-V の管理パック
4. .NET と JEE のアプリケーション パフォーマンス監視

System Center 2012 には新たに APM（Appliation Performance Monitoring）が実装されました。これは以前 AVICode と呼ばれていたもので、マイクロソフトが買収し System Center に組み込んだものです。

APM を使用すると、.NET Framework または JEE（Java Enterprise Edition）で開発されたアプリケーションを監視することができます。

System Center Operations Manager 2012: 簡単に監視機能を拡張する
http://technet.microsoft.com/ja-jp/magazine/hh825624.aspx

Monitoring .NET Applications
http://technet.microsoft.com/en-us/library/hh212856.aspx

Monitoring Java Applications
http://technet.microsoft.com/ja-jp/library/hh212856.aspx

もちろん、アプリケーションが Windows Azure に展開されていても監視可能です。

Q) System Center Operations Manager を使用して、クラウド ファブリックを監視する必要があります。次のうちどの Operations Manager の機能を使用しますか。

1. ネットワーク デバイスの監視
2. レポート ビューとダッシュボード ビュー
3. 通知配信登録
4. Windows、Hyper-V、および Virtual Machine Manager の管理パック

これは特に迷うことはないと思います。ファブリックを監視するわけですから、物理レイヤ、仮想レイヤを統合的に監視できなければなりません。

よって、4. が正解です。

Oprations Manager には「管理パック」と呼ばれる監視用のアドインが用意されています。

管理パックは製品や機能ごとに用意されており、この問の場合にはOS用の管理パック、物理レイヤを監視するHyper-V管理パック、仮想レイヤを監視するVMM管理パックを使用します。

Fabric Monitoring
http://technet.microsoft.com/en-us/library/dn249700.aspx

もちろん、Windows Azure を監視するための管理パックも用意されています。

System Center Management Pack for Windows Azure
http://www.microsoft.com/en-us/download/details.aspx?id=38414

Q) System Center コンポーネントを使用して、クラウドを監視する必要があります。既定の監視対象は次のうちどれですか (2 つ選択してください)。

1. SQL Server のファイル ストレージ
2. クラウド ファブリック
3. サービス正常性
4. Microsoft Exchange インフォメーション ストア

この問題はあまり難しく考えないでください。

既定で監視できるのは、クラウド ファブリックとその中に展開されている各サービスの正常性です。

SQL Server や Microsoft Exchange を監視するには、別途管理パックを追加する必要があります。

Q)チャージバック レポートを実装する予定です。必要な System Center コンポーネントは次のうちどれですか (2 つ選択してください)。

1. Service Manager
2. Configuration Manager
3. Orchestrator
4. Operations Manager CI コネクタ

ここでいうチャージバックとは、クレジットカードの払い戻しプロセスのことではありません。顧客ごとのクラウドリソースの使用状況を計測することを意味しています。

つまり、チャージバックレポートとは、クラウド使用量に関するレポートのことでです。

チャージバック レポートについて
http://technet.microsoft.com/ja-jp/library/jj614457.aspx

チャージバックレポートを作成するための System Center コンポーネントは Service Manager なのですが、各リソースの使用量を計測するために Operations Manager と連携する必要があります。この時に使用するのが、Operations Manager CI コネクタです。CI は Configuration Item のことです。

Q)チャージバック レポートのインストールモジュールに含まれているコンポーネントは次のうちどれですか (3 つ選択してください)。

1. 管理パック ファイル
2. XML 構成ファイル
3. Web.config
4. Windows PowerShell のインストール スクリプト
5. Excel サンプル レポート

Service Manager のチャージバック レポートは、管理パック ファイル、管理パック ファイルをインポートするための Windows PowerShell スクリプト、Microsoft Excel サンプル レポートなど、さまざまなファイルで構成されています。 これは、覚えるしかないですね。。。

チャージバック レポートをインストールする方法
http://technet.microsoft.com/ja-jp/library/jj614406.aspx

Q) 価格シートを実装する予定です。価格の対象となるプライベート クラウド オブジェクトを見つける手段は次のうちどれですか。

1. Service Manager の手動登録
2. Configuration Manager による探索
3. Operations Manager CI コネクタによる探索
4. Orchestrator の同期

チャージバックレポートを作成するには、各リソースの価格が設定されている必要があります。

その価格のリストを「価格シート」といいます。別名 レートカードとも言います。

もちろん、顧客のSLAによって価格も変わりますから、SLAごとに異なる価格シートを用意することもできます。

答えはもちろん、Operations Manager CI コネクタです。これを使用して、クラウド内のオブジェクトを探索します。

チャージバック レポートについて
http://technet.microsoft.com/ja-jp/library/jj614457.aspx

価格シートを作成または変更する方法
http://technet.microsoft.com/ja-jp/library/jj614404.aspx

Q) クラウド オブジェクトと価格シートを関連付ける必要があります。関連付けの前に必要な作業は次のうちどれですか。

1. 価格シートを保存してエクスポートする
2. 価格シートを作成して公開する
3. オブジェクトの探索を実行する
4. Orchestrator をインストールする

これは、実際にオペレーションをしたことないと難しいですが、ちょっと考えるとわかるかもです。

価格シートとは、「こういうオブジェクトはこのくらいの価格」というポリシーです。

実際のクラウドオブジェクトを値付けするには、事前に価格シートが作成されていなければいけないことは、容易に想像がつくと思います。

富士山頂にある自動販売機（クラウドオブジェクト）に、「コーラ 100円」という価格シートと、「コーラ 200円」という価格シートのどちらを適用するか決定するには、事前に「価格シート」が存在しなければならいですよね。

詳細な手順は以下を参照してください。

価格シートを作成または変更する方法
http://technet.microsoft.com/ja-jp/library/jj614404.aspx

Q) 展開したクラウドの正常性と容量に関するレポートを確認する必要があります。どの System Center コンポーネントを使用しますか。

1. Operations Manager
2. Windows Intune
3. System Center Advisor
4. Service Manager

これは悩むと思うのですが、レポートを確認するのに最適なのは Service Manager です。Operations Manager はダッシュボードで個々のコンポーネントの監視を行ったりレポートを参照することは可能なのですが、「クラウドの正常性」という大きなくくりで全体の正常性をレポートするのであれば、CMDB を持つ Service Manager が最適です。

Q) クラウドの可用性とパフォーマンスに関する値を監視する必要があります。どの System Center コンポーネントを使用しますか。

1. Operations Manager
2. Windows Intune
3. System Center Advisor
4. Service Manager

パフォーマンスに関する具体的な値を監視するのであれば、Operations Manager です。

次回は、「02 | パブリック クラウドへの System Center の接続」について解説します。

Windows Server 2012 R2 のあの画面どうだったかな？あの機能ってどこまでできたっけ？

そんなことを思いながらも、「インストールめんどくせー」ってことありますよね。

評価版をダウンロードするのも時間かかるし。

そんな方のために、バーチャルラボが公開されています。

ちょっとわかりずらいところにあるので、以下でナビゲートします。

まずは以下のページに移動。

1. 評価版のダウンロード:Windows Server 2012 R2
   http://technet.microsoft.com/ja-jp/evalcenter/dn205286.aspx
   
2. 以下のプルダウンから「Windows Server 2012 R2 データセンター バーチャルラボ」を選択して、「今すぐダウンロードする」をクリック
   
   
3. プロファイルセンターに移動するので、地域を「日本」に変更して「次へ」
   
   
4. 以下のページに移動したら、お好きなラボをクリックしてください。
   

実を言えば、私も、ちょっとした画面ショットを撮りたいときには愛用していたりします。。。楽なので。。。

追記 2009年10月27日 Boot.ini と BCDのパラメタ対応表（ページ最後尾をご参照ください）

XPモードが使いたくて、Windows7 環境を Hyper-V から VHD ブートに移行しようとしたら、なんか手順がわかりずらいんですけど（半切れ）。

そんな方、結構いらっしゃるんじゃないでしょうか？あれ？私だけ？（恥）

原因は何かといえば、「ブート構成データストア（BCDストア）」についてきちんと理解していなかったことが原因でした。古くからの利用者（私ですが）は Boot.ini に慣れてますからねぇ。

ということで、同朋が存在することを期待し、VHD Boot への移行手順を説明する前に BCDストアについて簡単に解説しておきます。

参考文献：Boot Configuration Data in Windows Vista
http://www.microsoft.com/whdc/system/platform/firmware/bcd.mspx

参考サイト：ブート構成データ エディタに関してよく寄せられる質問
http://technet.microsoft.com/ja-jp/library/cc721886(WS.10).aspx

BCDストアは、簡単に言えば従来のBoot.ini に代わるブート構成情報のことです。Boot.iniはテキストファイルとして提供されていましたが、BCDはレジストリハイブ（HKLM 直下の BCDxxxxxxxxキーにロードされる）に格納されています。

ただし、Regedit等を使用してエントリを直接操作することはできません。BCDxxxxxxxxキー配下のアクセス権をご覧いただくとわかりますがSYSTEMアカウントにのみ編集権が与えられています。よって、ユーザーが編集するには、BCDEditコマンドやWMIを使用したスクリプトで操作する必要があります。

BCDストアの構造は以下の通りです。

上の図と、以下の Boot.ini ファイルを見比べてみてください。表現方法は変わりましたが、BCDストアのやりたいことはなんとなく見えますよね。

重要なのは、「Windows Boot Manager」と「Windows Boot Loader」です。

ブートの順番を変えたり、待ち時間を変えたりするには、Windows Boot Manager オブジェクトを編集します。これはBoot.iniの[boot loader]に相当するものです。

新しいOSのブート情報を追加したり、いらなくなったOSのブート情報を削除するには、Windows Boot Loaderオブジェクトを操作します。通常は1つのOSにつき1つの Boot Loaderオブジェクトに対応していますが、boot.ini でやっていたように、起動環境（使用するCPUコアの数やメモリ使用量、デバッグモード等）を変えて複数の Boot Loaderオブジェクトを持つことも可能です。

では、BCDストアを編集するにはどうしたらよいか？といえば、通常はBCDEdit.exe というコマンドラインツールを使用します。

ためしに、Vista/2008以上のOSで、コマンドプロンプトから BCDEDIT と入力してみてください。以下のような情報が表示されるはずです。

BCD Storeに格納されるBCDオブジェクトのタイプは3種類あります。

• Application
• Inheritable
• Device

通常の運用で管理者が編集しなければならない「Windows Boot Manager」や「Windows Boot loader」「Ntldr」などは、いずれもApplicationタイプに属します。

上の画面ショットには、Windows Boot Managerのオブジェクト1つと、Windows Boot Loader オブジェクトが1つ表示されていることがわかります。この場合、何もしなければブートメニューは表示されず、唯一のWindows Boot Loaderオブジェクトである「Windows Server 2008 R2」が、C:\Windows\System32\Winload.exe を使用して起動します。

Windows Boot LoaderオブジェクトやWindows Boot Managerオブジェクトに用意されているパラメタを詳しく調べるには以下のサイトが参考になりますが…英語だし、しかも開発情報なんですよね…

Boot Manager に用意されているパラメタ（エレメント）
http://msdn.microsoft.com/en-us/library/aa362641(VS.85).aspx

OS Loaderに用意されているパラメタ(エレメント）
http://msdn.microsoft.com/en-us/library/aa362670(VS.85).aspx

そこで、ちょちょいと調べるのであれば MSConfig ツールをお勧めします。

GUIを少しずつ変えながら、BCDEDITを実行しながらパラメタが変わった様子を確認できます。

追記 2009.10.27

以下のページに、Boot.ini と BCD のパラメタ対応表が掲載されています

BCD Boot Options Reference
http://msdn.microsoft.com/en-us/library/aa906217.aspx

3月の投稿が少ないのですが、実は書きたいことがたくさんありすぎて...でも書くための「詰め」作業時間が取れず...。

ひとまず数ある書きたいことの中から、KMSについて拾い集めた情報をまとめておきたいと思います。

■ 基本情報

KMSとはボリュームアクティベーションの仕組みですが、まだ KMS をご存じない方は、ひとまず以下をご覧ください。

【Windows Server 2008】Volume Activation 2.0 ～ あなたの Vista アクティベーションされてますか？

ボリューム アクティベーション ガイド（ボリュームアクティベーションの基礎知識系）
- BDD 2007 のボリューム アクティベーション ガイドの概要 
- ボリューム アクティベーション計画の作成
- OEM アクティベーション
- MAK アクティベーションの実装
- KMS アクティベーションの実装
- ボリューム アクティベーションの使用に関する問題をトラブルシュートする
- Windows Anytime Upgrade

ボリュームアクティベーションドキュメント（ボリュームアクティベーションの展開系）
ボリューム アクティベーション 2.0 概要ガイド
ボリューム アクティベーション 2.0 計画ガイド
ボリューム アクティベーション 2.0 展開ガイド
ボリューム アクティベーション 2.0 運用ガイド
ボリューム アクティベーション 2.0 関連リソース
ボリューム アクティベーション 2.0 FAQ
ボリューム アクティベーション 2.0 Windows Server® 2008 と Windows Vista® SP1 での変更点

■KMSサーバーが死んだので、新しいKMSサーバーをたてたい

１台目のKMSサーバー同様の方法でキーをインストールします。

死んだKMSサーバーのDNSエントリ（_VLMCS ）は削除します。

■古いKMSサーバーのエントリをクライアントから削除したい

クライアント側で以下のコマンドを入力

slmgr.vbs ckms

■新しいKMSサーバーのエントリを、クライアントに明に指定したい

クライアント側で以下のコマンドを入力

slmgr.vbs /skms <KMSサーバーのIPアドレス>:1688

※1688はKMSのポート番号

■どのKMSサーバーで認証されているのかを知りたい

クライアントで以下のコマンドを入力

slmgr /dlv

■DNSに、クライアントがKMSサーバーとしてエントリ（_VLMCS レコード）されている

クライアントにKMSキーをインストールしてしまったため、KMSサーバーとして認識されてしまった可能性があります。

KMSクライアントに「KMS セットアップ キー」をセットし、KMSクライアントに戻してあげる必要があります。

さらに、DNSサーバーから、不要な _VLMCS レコードを削除します。

この現象に起因し、アクティベーション時に 0xC004C008 エラーが発生することがあります。詳しくは Windows Server Setup / Core Team を参考にしてください（すみません、英語です）。このエラーは「ライセンスが枯渇した」という意味ですが、要は、ライセンスキーをKMSサーバー以外にインストールしてしまったためにこの現象が発生してしまっている事例が多く、これを正常な状態に戻すための手順が書かれています。

■MAKクライアントからKMSクライアントに変更するには？

上記と同様に、KMS セットアップ キー をセットしてKMSクライアントに戻します。

■仮想環境におけるゲストOSはカウントアップされるか？

Hyper-V上にゲストOSとしてインストールされたVistaおよび2008はKMSサーバーでカウントアップされません。

VMWare 上のゲストも同様です。

ただし、この仕様はVista SP2 / 2008 SP2 でカウントアップされるよう変更される予定です。

※2003をKMSにしている場合もQFEが提供される予定となっていますが、現時点では時期が明確にされていません

■ KMSに関するレポートを出したい

残念ながら、現時点ではKMS自身、レポート情報を出力する機能持っていません。

現時点の最適なソリューションは、Operation Manager 2007 + KMS管理パックです。

■KMSサーバーのロードバランスは可能か？

KMSクライアントは、最初にライセンス認証したKMSサーバーを使い続けます。これは、「KMSサーバーの負荷が高くなって来たから1台追加」しても、結果的にロードバランスされないことを意味します。

※もちろん、KMSサーバーからの応答が無くなれば新しいKMSサーバーをDNSを経由して探します

これを回避するには、クライアント側でKMSサーバーを切り替える必要があります....（上記参照）。

ひとまず以上です。

また新しいネタが入りましたら書き込みます。

こんばんは。

唐突ですが、私、老眼です。なので、老眼鏡を作りました。最近、日本語翻訳されたドキュメントを査読する仕事がありまして、老眼鏡が手放せませんでした...老眼鏡って...便利...。もともと両目共に2.0なので、全くメガネには縁がありませんでしたが、まさか38歳にして老眼鏡のお世話になるとは....。老眼鏡って便利です。しみじみ。

いや、そんな話ではなく、oof です。

MS社員以外の方で、oof っていう言葉、ご存知ですか？例えば、以下のように使います。

oof  9am - 11am

Exchange をお使いの方はお分かりになるかもしれません。
私は、最初に見たとき、「off」かと勘違いしました。9時～11時まで休みを取るのかと。

で、気になっ�� Live Search を駆使して調べたところ、どうやら MS発祥の用語らしいのです。
本来のつづりは、

Out of Office

とのことで、外出中という意味で使うらしく、ときには休暇の意味でも使うことがあるようです。ちょっと便利ですよね（と私は思いました）。

で、なぜにこれがMS用語なのかといえば、 Exchangeグループblog の古い記事に以下の記述がありました。

いわく、oof は、もともと Out Of Facility を意味し、Xenix のメールシステムで、ユーザーの状態を「外出中」にセットするために使用するコマンドだったとのこと。これが次第に「外出中」を現す隠語的な使われ方をするようになったみたいです。

同じようにコンピュータのオペレーションから来ている言葉で、「 little r 」ってのもあるとか。これは、Outlookを使用して返信するためのショートカットキーが 「コントロール＋小文字 r 」であることから、「返信してね」という意味で使うらしいです...。

そういえば、IT業界って同じような言葉って多いですよね。

忙しい人が応答できる状態にあるかどうか確認することを「pingをうつ」と言ったり（え？言いません？）。

関係ないですが、mmk は もててもててこまっちゃう..でしたよね。

この投稿は PowerShell Advent Calendar 2013 に参加しています。

※投稿遅れてごめんなさい!!!!

http://technet.microsoft.com/ja-jp/windowsserver/jj649374.aspx

Windows PowerShell を使用すれば、Windows Server 上にインストールするサービスの構成も自動化することができます。

ただ、その中でちょっと面倒なのが DHCP サーバーです。

サーバーマネージャーで DHCPサーバーをインストールし、DHCPマネージャーで構成するには、以下の手順が必要です。

1. DHCP サーバーをインストールする
2. サーバーマネージャー上にフラグた立つので、「DHCP 構成を完了する」を実行
   
   
   • DHCP サーバー管理の委任用にセキュリティグループ（DHCP Administrators、DHCP Users）を作成する
   • DHCP サーバーをActive Directory で承認する
3. DHCP サービスのバインディングを設定する
4. スコープを構成する

これらをWindows PowerShell に置き換えると以下のようになります。

1. Add-WindowsFeature dhcp -IncludeManagementTools -IncludeAllSubFeature
2. 「DHCP 構成を完了する」というコマンドレットが用意されていないので、以下のコマンドを実行します。
   • Netsh dhcp add SecurityGroups
     
     残念ながら、Netsh dhcp add SecurityGroup に相当するコマンドレットが存在せず、ここだけはDOSコマンドを使うことになります（少し悔しい）。または、New-ADGroup コマンドレットを使用して、ここにセキュリティグループを作ってあげるという手もありますが….
     
   • Add-DHCPServerInDC -DnsName <DNSドメイン名>
     
     DNS ドメイン名には contoso.com のような文字列を指定します。
3. Set-DHCPServerV4Binding -InterfaceAlias “NIC の名前” -BindingState $True
   
   -InterfaceName に指定するのは DHCP サーバーをバインドするネットワークカードの名前です。名前を調べるには、Get-NetAdapter コマンドレットで表示される Name プロパティを確認してください。
   
   
   
   このコマンドレットでは IPv4 アドレスをリースするための設定をしていますが、Set-DhcpServerv6Binding コマンドレットを使用すれば IPv6 用の設定も行えます。
   
4. スコープを構成するには 2つのコマンドレットを実行しなければなりません
   
   はじめに、スコープのレンジを設定します。このとき、-State でスコープをアクティブにすることができますが、このままでは設定が足りないため中途半端にリースされる可能性があります。よって、作成時には -State を InActive としましょう。
   
   Add-DHCPServerV4Scope -StartRange 192.168.0.10 -EndRange 192.168.0.20 -SubnetMask 255.255.255.0 -Name “スコープ1” -State InActive
   
   スコープを作成すると、ScopeID という一意のIDが割り振られます。ScopeID を確認するには、以下のコマンドレットを使用します。
   
   Get-DHCPServerV4Scope
   
   
   
   ScopeID がわかったら、今度はスコープに DNS サーバー の設定を追加します。
   
   Set-DhcpServerV4OptionValue -ScopeID 192.168.0.0 -DnsServer 192.168.0.1
   
   このとき、DNS サーバーの有効性がチェックされます。もし DNS サーバーがまだ存在していない場合等には、 -Force  オプションを使用して設定を強制することもできます。
   
   
   最後に、以下のようにスコープの State を Active に変更し、アドレスのリースを行えるようにします。
   
   Set-DhcpServerv4Scope -ScopeID 192.168.0.0 -State Active
   

以上で設定は完了なのですが、Windows PowerShell から構成を行った場合、ちょっとした問題が出ることがあります。それが、以下です。

そうなのです。こいつが消えてくれないことがあるのです。害はありませんが、ちょっと鬱陶しいですね。。。

そこで、対応が完了しているフラグがどうしても消えない場合には、以下のようなコマンドを最後に実行しましょう。

Set-ItemProperty –Path registry::HKLM\SOFTWARE\Microsoft\ServerManager\Roles\12 –Name ConfigurationState –Value 2

「HKLM\SOFTWARE\Microsoft\ServerManager\Roles」配下には、サーバーにインストールされている役割が列挙されており、その直下の数字が各役割の管理番号になっているようです。つまり、「12」というのはDHCP サーバーを示しています。ConfigurationState = 2 が「構成完了」を意味しています。

前回の投稿では、EXCELで用意したユーザーリストを読み込んで QRコードのイメージを作成するスクリプトを Windows PowerShell で作成しました。

【PowerShell & WORD】QRコードを差し込み印刷してみる 1/2

今回は、作成した QRコードのイメージファイルを使用して、WORD 2010 を使用して差し込み印刷をしましょう。

この、イメージ（画像）の差し込み印刷...正直言って苦労しました...いや、わかってしまえば何てことないのでしょうけどね...Office の MVP の方々からすれば "笑止!!" なのでしょうが...。今回は、私のように差し込み印刷に苦労した方向けの解説ですので、できる限り平易に解説します。

前回の投稿で作成した UserList.xlsx ファイルを差し込みリストとして使用し、WORD 2010 に読み込みます。

ちなみに、今回作成してあるEXCELファイルは以下のようなデータが入っています。先頭行はタイトル行になっていることに注意してください。

さっそく始めましょう。

■ WORD で画像の差し込み印刷をする

① EXCEL ファイルを差し込みリストとして指定する

※ わたし、生まれて初めて「差し込み文書」タブをクリックしました...（恥）。

WORD を起動し、[差し込み文書] タブ から[宛先の選択]をクリックし、[既存のリストを使用] を選択します。ファイル選択のダイアログが開いたら、事前に作成してある UserList.xlsx を選択してください。

ワークシートの選択画面では、[先頭行をタイトルとして使用する] にチェックが入っていることを確認してください。

これで読み込みは完了です。

② 文字列を差し込む

差し込み用のデータを読み込むと、以下のようにリボン内の [差し込みフィールド] コマンドが有効になります。クリックして開いてみると、EXCEL のタイトル行が表示されます。

ここで、上のメニューから FirstName をクリックしてみてください。以下のように本文に «FirstName» と表示されるはずです。これ、手で書いちゃダメですので注意してください。かならずメニューから選択してください。

さて、ここからがビックリです。この状態で、[ALT] + [F9] という、なんとも見慣れない組み合わせのショートカットキーを押します。画面が「フィールドコード」と呼ばれる表示に切り替わり、画面には { MERGEFIELD FirstName } と表示されています。はじめて「フィールドコード」などという言葉を聞いた方、今後は知ったかぶりをしましょう。私もそうします。

もう一度 [ALT] + [F9] を押すと、元の表示に戻ります。

同じように、«LastName» も挿入し、その後ろに「様」を入れましょう。ついでに、フォントも大きくしてみます。

↓↑ [ALT]+[F9]

つづけて、本文も入力しちゃいましょう。ここは普通に入力すればOKです。

URL も単なる文字列ですので、同じように入力できます。繰り返しますが、«blogsite» と «UserName» は手で入力しないでください。かならず、[差し込みフィールドの挿入] から行います。

ひとまずここまで。

③ データの確認をする

ここまで確認したら差込データの動作確認をしてみましょう。

[差し込み文書] の [結果のプレビュー] をクリックしてください。

以下のように、差し込みフィールドの部分に実データが入ってくるはずです。[結果のプレビュー] の横にある数字は、差し込みリストの行番号です。この数字を変えると、データも次々に変わります。

ただしくプレビューできましたか？OKならば、今度は画像を挿入します。

④ 画像を差し込む

画像を差し込むには INCLUDEPICTURE というフィールド名を使用します。INCLUDEPICTURE の引数として画像ファイルのパスを指定することで、画像を差し込むことができます。

もう何をするか想像できますよね。そうです。画像のパスに { MERGEFIELD UserName } を使用すれば、画像の差し込み印刷ができそうです。

さっそくやってみます。

[ALT]+[F9] を押して、画面をフィールドコード表示（っていう表現は正しい？？）にしてください（以下のように）。そして、画像を差し込みたい場所にカーソルを移動しておいてください。

この状態で、[CTRL]+[F9] を押します。CTRL ですよ！!間違えないでください。

すると、以下のように「フィールドの枠」だけが挿入されます。

この枠内に、次にように入力してください。なんか中途半端に見えますが、OKです。

INCLUDEPICTURE “C:\\tmp\\img\\

～\\img\\ の後には、JPEGファイルのファイル名が入るのですが、ここには差し込みフィールド { MERGEFIELD UserName } を挿入しますします。もちろん手で入力してはダメです。かならず ～\\img\\ の後ろにカーソルが点滅している状態で、[差し込みフィールドの挿入] - [UserName] を選択してください。

INCLUDEPICTURE “C:\\tmp\\img\\{ MERGEFIELD UserName }

さらに、「.jpg”」を追記してファイルのパスを完成させます。

INCLUDEPICTURE “C:\\tmp\\img\\{ MERGEFIELD UserName }.jpg”

仕上げに、以下のように追記します。\d の後ろには半角空白を入れてください。

INCLUDEPICTURE “C:\\tmp\\img\\{ MERGEFIELD UserName }.jpg” \* MERGEFORMAT \d

結果、以下のようになります。

ここで、入力したフィールドコードを反映させるために、[F9] キーを押してリフレッシュしてください。[F5] じゃないですよ！[F9] ですよ！

リフレッシュしたら、[ALT]+[F9] を押して元の表示に戻します。

今入力した部分が QRコードになりましたか？

もしならない場合は、[結果のプレビュー] をクリックして、[F9] キーでリフレッシュし��ください。

ここで、行番号を変更してみましょう。

画像が変わらないですよね？

はい、もうおなじみですよね。[F9] を押してください。画像が書き変わるはずです。

これで差し込みの設定完了です。

⑤ 印刷する

印刷する場合にも注意が必要です。

印刷を開始するには、画面右端の [完了と差し込み] – [文書の印刷] を選択します。

印刷のダイアログが開いたら、忘れずにしなければならないことがあります。プリンタの[オプション]にある [印刷前にリンクされているデータを更新する] をチェックしてください。これを行わないと、画像が更新されず毎回同じQRコードが印刷されてしまいます。

いかがでしょう？

いやー難しいですねぇ、WORD ...。

現場でお客様を担当されている SE さんて、結構こういう質問されるんですよねぇ。でも意外とお客様のほうがよく知っていたり...なんてことがよくあります。

私では1000年たっても Office の MVP にはなれそうにありませんが、これで差し込み印刷は3割くらい把握できたんじゃないかなと思います。

※今回ちょっと長いです。すんません。

DPMの環境設定を自動化しようシリーズの 2 回目です。

1. バックアップ領域となるディスクを認識させる
2. 保護対象となるサーバー（保護サーバー）にエージェントをインストールする  ← 今回
3. 保護グループを作成する

前回はセットアップ直後のDPMに、ボリュームを追加してストレージプールを作成しました。

【Management】DPM 2007 の初期設定を自動化 その1 ディスクを追加する

今回は、保護対象となるサーバーに対し、スクリプトを併用してエージェントをインストールしてみます。

ただ、エージェントのインストール自体は、できることならGUIから行ったほうがよいです。なぜならば、そのほうがはるかに簡単だからです。DPMサーバーと保護サーバーの間に Firewall があるためにRPCを使用したリモートからのプッシュインストールが行えないといった理由が無い限りは、管理コンソールから行ってください。

とはいえ、あえて手動で行ってみると、リモート管理に関する汎用的で細かなスキルを身につけることができますので、スキルアップを目的に挑戦してみるのならばよいかもです。

では、やってみましょう。

エージェントを手動でインストールするには2つのステップが必要です。

① DPM保護エージェントを保護サーバーにインストール
② DPMサーバーに、エージェントがインストールされた保護サーバーを認識させる（PowerShell）

それでははじめましょう。

① DPM保護エージェントを保護サーバーにインストール

保護エージェントのインストールの流れは以下の通りです。

• 保護サーバーの Windows Firewall サービスを停止する（無効にするのではなく、サービスを停止する） 
• 保護サーバーにエージェントをインストール
• 保護エージェントの修正パッチがあれば、それを適用する
• Windows Firewall サービスを起動
• 保護エージェントに対して通信を許可するように Windows Firewall を設定する

上のリストにはとても重大な問題が含まれています。

それは、手順の一番上にある、保護サーバー上の Firewall サービスの停止という作業です。「無効」ではありません。「停止」です。「停止」しておかないと、以下のように、エージェントのインストール時に 80070643 エラーが発生して DPMAgentInstaller が失敗します。これは、どうやら各国語にローカライズさらたバージョンでのみ発生する問題のようです。

Installing agent and configure for dpmserver =[ServerName]
DPMAgentInstaller failed with errorcode =8070643, error says:
Check log files in [WINDIR]\Temp\MSDPM*.LOG
Press Enter key to close the window

が、慣れた方ならば何か違和感を感じますよね？そうです。Firewallサービスを無効にするならまだしも、停止してしまったらリモートからの通信を受け付けられないじゃんか！ということです。リモートコンピュータのサービスの停止は SC コマンドで簡単に行えます。が、Firewall サービスを停止してしまうと、二度とコマンドを受け付けることができなくなります。当然、Firewall サービスを起動することせえもできなくなりますから、これはもう、厄介どころの騒ぎではありません。現時点では、管理コンソールを使わず手動でインストールする場合には、リモートからのインストール制御は事実上不可能であると言ってもよいでしょう。

誠に残念ですが、ここでは保護サーバー上でバッチファイルを実行するという前提でお話を進めていきます。

WinRM についてご存じない方は、以下の記事をご参照ください

• 【Windows Server 2008】WinRM Quickconfig って裏で何をやっている？
• WinRM が XP や 2003 でも使えるようになりました （ WS-Management 1.1 日本語版リリース ）

せっかくなので、WinRM/WinRS 関連のTIPSをご紹介しておきます。

上記のようなバッチファイルをWinRSでリモートコンピュータに発行しようとすると、既定では以下のように「アクセスが拒否されました」エラーが発生します。

これは、発行先のコンピュータを経由してさらに別のコンピュータ（この場合には \\DJ-DPM01 ）にアクセスしようとしているからです。おそらくお聞きになったことがあると思いますが、あるコンピュータを経由して別のコンピュータに接続する場合には、デリゲート（委任）機能を有効にしなければなりません。

委任を有効にするには、「Active Directory ユーザーとコンピュータ」で保護サーバーのプロパティを開き、[委任]タブで、「任意のサービスへの委任でこのコンピュータを信頼する」をチェックします。

ーー 余談 ーー 実は、舞台裏を明かしますと、問題はこれだけではありませんでした。 以下のバッチファイルを見てください。ご覧頂くとお分かりの通り、 Firewallサービスの停止 → エージェントのインストール → Firewallサービスの起動 までを一気にやってしまおうとしています。こうしたバッチファイルを WinRS で保護サーバーに発行してしまえば、一度に処理を指示できることになるので、Windows Firewall サービスが停止してしまってもうまくいくかなと考えたのですが....どうしてもインストールの途中で処理が止まってしまい、うまくいきませんでした。原因追究にまるまる1日使ってしまいましたが、結局ダメでした。 net stop MpsSvc \\DJ-DPM01\i386\DPMAgentInstaller.exe /q DJ-DPM01.Example64.jp net start MpsSvc

 エージェントをインストールするには、保護サーバー上で、DPMサーバの \Program Files\Microsot DPM\DPMAgents\RA\<i386 or amd64> 配下にある DPMAgentInstaller.exe を、DPMサーバー名を引数として実行します。つまり、以下のようなかんじです。

DPMAgentInstaller.exe /q DJ-DPM01.Example64.jp

保護サーバーのプラットフォームに合わせて、i386 か amd64 は選択してください。

この操作をリモートの保護サーバー上で実行させるわけですから、DPMサーバー上の i386 または adm64 フォルダを共有化しておくとよいでしょう。

i386 フォルダを、i386 という名前で共有化したとすれば、保護サーバーからは以下のようにして実行することができます。

\\<DPMServerName>\i386\DPMAgentInstaller.exe /q DJ-DPM01.Example64.jp

エージェントのインストールが完了したら、Firewallサービスを起動しておきましょう。

次に 保護サーバー側の Windows Firewall の設定を行います。本来は SetDpmServer.exe というコマンドで行うのですが、やはりローカライズ版では不具合があるらしく手動でFirewallの例外の設定を行う必要があります。もちろん、DPM管理コンソールからインストールすれば自動的に例外を作成してくれます。

DPM管理コンソールを使用してリモートインストールを行うと、DPMRA.exe というプログラムに対して、以下のような例外ルールが作成されます。

 

上記と同じルールをコマンドから実施するには、おなじみ netsh を仕様します。

netsh advfirewall firewall add rule name="dpmra" dir=In action=Allow protocol=Any Program="%PROGRAMFILES%Microsoft Data Protection Manager\DPM\bin\DPMRA.exe"

この後、再起動すれば保護サーバー側の作業は完了です。

以上の作業をバッチファイルで表現すると、以下の通りです。

net stop MpsSvc \\<DPMServerName>\i386\DPMAgentInstaller.exe /q DJ-DPM01.Example64.jp net start MpsSvc netsh advfirewall firewall add rule name="dpmra" dir=In action=Allow protocol=Any Program="%PROGRAMFILES%Microsoft Data Protection Manager\DPM\bin\DPMRA.exe"

② DPMサーバーに、エージェントがインストールされた保護サーバーを認識させる（PowerShell）

仕上げの作業として、DPMサーバーに保護サーバーを認識させます。これは専用の PS1 ファイルが提供されています。

DPM管理シェルを起動して、以下のパスに移動してください。

C:\Program Files\Microsoft DPM\DPM\bin

ここで、Attach-ProductionServer.ps1 を以下の書式で実行します。引数を指定しなければ、プロンプトが表示されます。 

Attach-ProductionServer.ps1 <DPM server name> <production server name> <user name> <password> <domain>.

実行結果例を以下に示します。

 

これで完了です。

以下のように、DPM管理コンソールにエージェントがリストされていれば成功です。

エージェントの更新欄に「利用可能な更新」が表示されている場合にはエージェントをアップグレードできますので、クリックして最新にしておきましょう。

いやー長かったですね。とても面倒です。

やはり、手動ではなく、管理コンソールを使用することをお勧めします。

次回は、保護グループの作成を行いましょう。

前回の続きです。

• 【Management】日本語版のグループポリシー設定リストを"作ってみる" 1/3

なんとか機械的に Group Policy Settings Reference for Windows and Windows Server を日本語に変換できないだろうか...と考えて思いついた方法の2つ目です。

■ Translation Glossary を辞書として使用する（TechNet/MSDN 契約者限定なのです。。。）

Translation Glossary ってご存知ですか？ランゲージポータルにさりげなく書かれているのですが、要は「マイクロソフト製品で使用されている用語やメッセージの英語ー日本語対応表」が OS ごとに、CSVファイルで提供されているのです。

ってことは、PowerShell でちょちょいとスクリプトを組めば、Translation Glossary を辞書代わりにして、英語版のグループポリシー設定リストを日本語に置き換えることができそうです。

ただ、TechNet または MSDN のサブスクライバーでないと入手できませんし、再配布も禁止されていますのでここに添付することができません...。TechNet サブスクリプションの場合、以下から Translation Glossary をダウンロードできます。

[ツールとリソース]-[Translation Glossary]

中身はどんなかというと、テクノロジーや製品ごとにファイルが用意されています。その数392個。容量も全部で555MBと、かなりのボリュームになっています。

jpn-jpn-csv-.NETFramework2.0SP1.csv jpn-jpn-csv-.NETFramework3.5SP1.csv jpn-jpn-csv-.NETFramework4.csv （略） jpn-jpn-csv-ExpressionWeb4.csv jpn-jpn-csv-FirewallClientforISAServer.csv jpn-jpn-csv-FlightSimulator_X.csv （略） jpn-jpn-csv-MicrosoftOfficeDocumentImaging2007SP2.csv jpn-jpn-csv-OfficeLiveWorkspaceSV4.csv jpn-jpn-csv-OfficeOnlineClient2007.csv （略） jpn-jpn-csv-SQLServer2008R2.csv jpn-jpn-csv-SQLServerCompact3.5SP2.csv jpn-jpn-csv-SQLServerJDBCDriver3.0.csv （略） jpn-jpn-csv-Windows 7 (1).csv jpn-jpn-csv-Windows 7 (2).csv jpn-jpn-csv-Windows7UpgradeAdvisor2.csv （略）

ここで、jpn-jpn-csv-Windows 7 (1).csv というファイルに注目してください。その名の通り、このファイルには Windows 7 で使用されている日本語と英語の対応表が掲載されています。行数はざっと259万行! 膨大な量です。どうやら、Windows Server 2008 R2用のものは現時点では見当たらないですね。。。

ほんのちょっとだけファイルの中身をのぞいてみると、以下のような内容です。

A列 ＝ 英語表記
C列 ＝ 日本語表記

ってことをおさえておいてください。

ーーーーーーーーーーーーーーーー

一方、英語版の Group Policy Settings Reference for Windows and Windows Server はどんな構造かというと、EXCELファイルで提供されており、ポリシーの性質によって、2つのタブに分かれています。それぞれのタブの列一覧と内容は以下の通りです。

【Administrative Template（管理テンプレート）タブ】

※EXCEL を操作するのは（私が）面倒なので、タブをCSVファイルとして保存しておいてください。ここでは、次のファイル名で保存したものとします。WndowsServer2008R2andWindows7GroupPolicySettings_AdministrativeTemplate.csv

• A列：File Name（templateファイル名）
• B列：Policy Setting Name（設定名）← 日本語化
• C列：Scope（ターゲット）
• D列：Policy Path（設定ノードのパス）
• E列：Registry Information（レジストリのパス）
• F列：Supported On（サポートされているOS)
• G列：Help Text（設定内容の説明） ← 日本語化
• H列：Reboot Required（有効にするために再起動が必要かどうか）
• I列：Logoff Required（有効にするためにログオンしなおしが必要かどうか）
• J列：Active Directory Schema or Domain Requirements（ADのみで有効かどうか）

【Security タブ】

※EXCELファイルを操作するのは（私が）面倒なので、タブをCSVファイルとして保存しておいてください。ここでは次のファイル名で保存したものとします。WindowsServer2008R2andWindows7GroupPolicySettings_security.csv

• A列：Policy Path（設定ノードのパス）
• B列：Policy Name（設定名）←日本語化
• C列：Supported On（サポートされているOS）
• D列：Registry Settings（レジストリのパス）
• E列：Help Text（設定内容の説明）←日本語化
• F列：Reboot Required（有効にするために再起動が必要かどうか）
• G列：Comments（コメント）←日本語化

ーーーーーーーーーーーーーーーー

さて、これで方針は決まりました。

スクリプトを作成する前に、以下のファイルが存在していることを確認してください。

• jpn-jpn-csv-Windows 7 (1).csv
• WindowsServer2008R2andWindows7GroupPolicySettings_AdministrativeTemplate.csv
• WindowsServer2008R2andWindows7GroupPolicySettings_security.csv

ーーーーーーーーーーーーーーーー

上記の3つのファイルを使用して、PowerShell で作成したスクリプトが以下の通りです。コメント欄に簡単に解説を加えておきます。ご覧のとおり、非常にシンプルです。

$japaneseFile = '.\jpn-jpn-csv-Windows 7 (1).csv' $englishFile_Security = '.\WindowsServer2008R2andWindows7GroupPolicySettings_security.csv' $englishFile_adm = '.\WindowsServer2008R2andWindows7GroupPolicySettings_AdministrativeTemplate.csv' #日本語ファイルをCSVファイルとして読み込む。各列は a～k とする。 $jpnfile = Import-Csv $japaneseFile  -Header "a","b","c","d","e","f","g","h","i","j","k" #ハッシュテーブルを作成し、a列をキーとして、c列を格納 $jpnfile_hash = @{} $jpnfile |foreach-object {    if ($jpnfile_hash.ContainsKey($_.a) -eq $false ){        $jpnfile_hash.add($_.a,$_.c)        }    } # セキュリティポリシー一覧ファイルをCSVとして読み込む。各列は a～g とする。 $enfile = Import-Csv $englishfile_Security -Header "a","b","c","d","e","f","g" # 読み込んだファイルから1行ずつ取り出し、日本語化したい列をハッシュテーブルのキーをベースに置換する ForEach($item in $enfile) {   if ($jpnfile_hash.ContainsKey($item.b.replace("`n","\r\n")) ) {     $item.b = $jpnfile_hash.Get_Item($item.b.replace("`n","\r\n"))    }   if ($jpnfile_hash.ContainsKey($item.e.replace("`n","\r\n")) ) {     $item.e = $jpnfile_hash.Get_Item($item.e.replace("`n","\r\n"))    }      if ($jpnfile_hash.ContainsKey($item.g.replace("`n","\r\n")) ) {     $item.g = $jpnfile_hash.Get_Item($item.g.replace("`n","\r\n"))    } } # 置換後のデータをCSVファイルに保存 $enfile | Export-Csv gplistjp_security.csv -encoding Default # 管理ポリシーファイルも同様の処理 $enfileadm = Import-Csv $englishfile_adm -Header "a","b","c","d","e","f","g","h","i","j" ForEach($item in $enfileadm) {   if ($jpnfile_hash.ContainsKey($item.b.replace("`n","\r\n")) ) {     $item.b = $jpnfile_hash.Get_Item($item.b.replace("`n","\r\n"))    }   if ($jpnfile_hash.ContainsKey($item.g.replace("`n","\r\n")) ) {     $item.g = $jpnfile_hash.Get_Item($item.g.replace("`n","\r\n"))    } } $enfileadm | Export-Csv gplistjp_adm.csv -encoding Default

ちなみに、「replace("`n","\r\n")) 」が意味不明かと思います。実は、英語ファイルのほうには改行コードが含まれているところがある一方で、日本語では \r\n という文字に置換されているのです。なので、英語から読み込んだ値は、一旦 replace("`n","\r\n")) で日本語と同じ値にリプレイスしています。

上記スクリプトを実行した結果は以下の通りです。ご覧いただくとお分かりの通り、完璧じゃないんですよねぇ。原因は、微妙な文章の違い（複数形と単数形、ピリオドの有り無しなど）なので、目視すれば「あ、これ同じだ」とはわかるのですがプログラムでの判断は厳しいかんじです。テキストマイニングとかできる方だと、「これは同じ」とかできるのでしょうけど...。

さて、では、この変換しそこなった部分をどうするのか？やはり手作業なのか？

いえ、そこでやっと機械翻訳の登場となるのです。前回の投稿で、意外と品質の良い変換をしてくれたアイツを使って完成させることにしましょう。

前回：【Management】日本語版のグループポリシー設定リストを"作ってみる" 1/3 ～ランゲージポータル編

次回：【Management】日本語版のグループポリシー設定リストを"作ってみる" 3/3 ～ 機械翻訳併用  編

Active Directory を Windows Azure 上の IaaS として展開するためのガイドラインが公開されていました。

元記事 Guidelines for Deploying Windows Server Active Directory on Windows Azure Virtual Machines（英語）

このガイドラインでは、Windows Azure 仮想マシン（Azure VM）上にADを展開する際の留意点について解説されています。

せっかくですので、内容を補足しつつ、ざくっと日本語で。

----

Windows 2000  とともに登場した Active Directory は、この10年で大きく進化しました。挙げればきりがありませんが、2012年はActive Directoryにとってさらに大���な飛躍の年になります。クラウドへの進出です。まさに飛躍ですね。

上の図でも触れられている通り、これまで Active Directory と Windows Azure の連携には「ハイブリッドクラウドシナリオ」が用意されてきました。Windows Azure上に展開したアプリケーションを利用するための独自に認証基盤を用意するのではなく、オンプレミスの Active Directory Domain Service（AD DS）で認証を行い、Active Directory Federation Service（AD FS）から発行されたセキュリティトークンを使用して、Azure 上のアプリケーションへのアクセスを認可するという方式です。これにより、クラウド上にパスワードを保存することなく、企業内から SSO でクラウドアプリが使用できます。

• AD FS 2.0 と Windows Azuer AppFabric ACS V2 を使用した SSO の構築 第2.2版
• Active Directory の10年の軌跡～ファイルサーバーからクラウドまで
• TechNet ハイブリッド クラウド コンテンツ一覧

これに加えて、Windows Azure 上に Active Directory を展開するというオプションが用意されました。

“Windows Azure 仮想マシン” と “Windows Azure 仮想ネットワーク”は Windows Azure の IaaS の一部として提供される機能であり、この機能を使用することでWindows Azure を企業インフラの一部として活用することができ、ここに Active Directory を展開することができるようになります。

なお、Windows Azure Active Directory は従来の Windows Server AD とは、かなり趣が異なります。実体は AD DS ではなく AD LDS で、マルチテナントに対応した REST ベースのサービスです。Office 365 や Windows Intune が既に Windows Azure Active Directory を使用しており、Windows Azure に展開した独自のアプリケーションからも Windows Azure Active Directory を使用できるようになります。また、オンプレミスのWindows Server AD からユーザー情報を同期する仕組みもサポートする予定です。ちなみに、Windows Azure AppFabric ACS は、Windows Azure Active Directory ACS として統合されました。 よって、Windows Azure Active Directory とは、ID ストアでもあり、認証サービスであり、かつ他のアイデンティティプロバイダーと連携可能なアクセスコントロールサービスでもあるということです（ちょっと複雑ですが）。

Windows Azure Active Directory については以下をご覧ください。

Windows Azure Active Directory

では、Windows Azure VM に Active Directory を展開する際の留意点について詳しくみていきましょう。

はじめに

基本的には、オンプレミスの Hyper-V 上に Active Directory をインストールした場合と大きく変わることはありません。例えば、ネットワーク的に離れたブランチオフィスにドメインコントローラー（DC）を展開した場合、意識しなければならないのは「サイト」です。サイトとはすなわち…サブネットです。システム管理者はサイトを定義し、サブネットをサイトに関連付け、サイト間リンクを作成し、通信コストに応じて複製間隔を設定する必要があります。こうした留意点は、Active Directory の管理者であれば当然のリテラシですが、AD on Azure の場合にも同様の見当が必要です。

ただし、Windows Azure に特有の新しい概念が必要なので、はじめに”軽く”触れておきます。

1. Windows Azure 仮想ネットワーク

Windows Azure 仮想マシンがオンプレミスのネットワークと通信を行うには、Windows Azure 仮想ネットワークを使用する必要があります。Windows Azure 仮想ネットワークとは、クラウドとオンプレミスのサイト間通信を可能にする VPN です。なお、Windows Azure 仮想ネットワークは ピア・トゥ・ピア通信を可能にする Windows Azure Connect とは異なるので注意してください。

（参考）Networking （英語です。すんません）

なお、すべてのアプリケーションサーバーがクラウド上にあり、かつオンプレミスと複製などの通信が発生しない場合、Windows Azure 仮想ネットワークを使用した通信経路を用意する必要が無いように思える場合がありますが、それはダメです。詳しくは以降で。

2. Windows Azure 仮想マシンでは静的IPアドレスがサポートされない

Windows Azure 仮想マシンでは静的なIPアドレスがサポートされません。よって、仮想マシンを展開する際にはDHCPを有効にしておかなければなりません。しかし Active Directory の経験者であれば、ここで疑問が出ます。「DC ってDHCPだとヤバイんじゃ？」そこで、Windows Azure 仮想ネットワークを使用して仮想マシンを作成すると、動的にIPアドレスが割り当てられ、これが永続化されます。一度割り当てられたIPアドレスは、仮想マシンが廃棄されるまで使用されるため、結果としてスタティックにIPアドレスを割り当てたのと同じ状態を維持することができます。

なお、これに関連してDNSに関する留意点もありますが、これについては後述します。

3. Windows Azure 仮想マシンは2種類の異なるディスクタイプを使用することができる

ディスクタイプの選択はドメインコントローラーにとってとても重要です。Windows Azure では、OSディスクとDataディスクという2種類のディスクを使用することができます。Dataディスクは、Writeキャッシュが無効に設定されており、データが確実にディスクに書き込まれるようになっています。ドメインコントローラーにおける書き込みミスはシステム全体に影響を耐える可能性があるため、このことは重要です。

よって、DC のデータベースおよびSysvol は Dataディスクに保存するようにしなければなりません。

用語と定義

※ 以下は抜粋です。完全な用語集は Windows Azure Glossary を参照してください

• Windows Azure 仮想マシン
  : Windows Azure の IaaS 上に展開された仮想マシン
• Windows Azure 仮想ネットワーク
  : Windows Azure とオンプレミスをセキュアに接続するためのVPNサービス。
• Virtual IP アドレス (VIP)
  : インターネットからWindows Azure 仮想マシンに接続する際の、インターネット側から見えているIPアドレス。VIP はネットワークロードバランス機能も提供し、VIP と複数のWindows Azure 仮想マシンを関連づけることができる。
• Dynamic IP アドレス (DIP)
  : Windows Azure 仮想マシンにマウントされた仮想ネットワークアダプタに動的に割り当てられるIPアドレス。このIPアドレスは永続的であり、Windows Azure 仮想マシンにマウントされている仮想ネットワークアダプタのMACアドレスに対応付けられている。DIPはネットワークロードバランス機能は提供しない。
• サービス・ヒーリング
  : Windows Azure が、Windows Azure に展開したサービスに障害が発生したこと検出したときに、そのステータスを正常に戻すためのプロセス。これは Windows Azure の可用性と弾力性を担保するための仕組みではあるが、例えば、万が一DCが展開された仮想マシンがハングアップしたことを検出するt、仮想マシンが自動的に再起動されることがある。これにより、以下のような影響が発生する。:
• 仮想ネットワークアダプタが変更される
• 仮想ネットワークアダプタのMACアドレスが変更される
• 仮想マシンのプロセッサIDが変わる

オンプレミスのActive Directory では上記のようなことは発生しませんが、Windows Azure 仮想マシン上に Active Directory を展開した場合には、前述のように仮想ネットワークを使用して永続的なIP構成を手に入れておく必要があります。仮想ネットワークを使用すると、サービスヒーリングによってIPアドレスが変わることはありません。

つづく

ちょっと必要に迫られて調べただけなので、中途半端な情報ですみません。役に立つ方がいらっしゃるかもしれないので投稿しておきます。

WEB サイトの移行や廃棄等で、既存のページのバックアップを取っておきたい場合があります。それも、大量にあるので出来る限り自動化したいという。

方法はい��つかあるのですが、代表的な方法として2つ考えられます。

※ここでは再現性の高い MHT 形式で保存するものとします。

1. CDO.Message を使用する

いにしえの方法で、こなれた感じではありますが、正直なところ出力結果に難ありです。

例えば、Tech Fielders サイトで公開されている、Windows Intune 利用時に知っておくべき Proxy Server 環境設定 | Tech Fielders コラム（三井情報株式会社 後藤 諭史 さん）を保存してみます。

$url = "http://www.microsoft.com/japan/powerpro/TF/column/sg_01_1.mspx" $filename = "c:\tmp\tf\sg_01_1.mht" $cdo = New-Object -ComObject "CDO.Message" $n = $cdo.CreateMHTMLBody( $url, 0, "", "") $objStm = $cdo.GetStream() $objStm.SaveToFile( $filename,  2)

実行結果は以下の通りです。読めなくはないですが、レイアウト的に微妙な感じですよねぇ。

ちなみに、CreateMHTMLBody メソッドの第二パラメタ「０」は、指定したURLの全てのコンテンツをダウンロードすることを示しています。

（参考）CdoMHTMLFlags Enum

また、SaveToFile に指定している ２ は $filename が存在している場合に上書きすることを示しています。１ を指定すると、同じファイルが存在する場合にエラーとなります。

2. IE の ExecWB を使用する

この方法は、IE で「ページを名前を付けて保存する」をスクリプトから実行するものです。IE から GUI を操作して保存した場合とまったく同じ結果を得ることができるため、結果の品質は申し分ありません。

ただ、問題がちょっとだけあります。それは、「名前を付けて保存」を自動化することができないということです。

以下のスクリプトの最終行に書かれている、ExecWB(4,0,$null,[ref]$null) は IE の「名前を付けて保存」ダイアログを呼び出すためのメソッドです。「4」が「名前を付けて保存」を意味しています。第二パラメタには「0」を指定していますが、「2」を指定するとプロンプトを表示しないで実行ができるはずなのです...が、どうもうまくいかない...ということで、だったらダイアログ操作を自動的にやってしまうことにしました。

$url = "http://www.microsoft.com/japan/powerpro/TF/column/sg_01_1.mspx" $code = '$WShell = New-Object -comobject WScript.Shell; ' $code = $code + '$WShell.AppActivate(''Web ページの保存'', $true); ' $code = $code + '$WShell.SendKeys(''%T'') ; ' $code = $code + '$WShell.SendKeys(''{DOWN}'') ; ' $code = $code + '$WShell.SendKeys(''{DOWN}'') ; ' $code = $code + '$WShell.SendKeys(''{ENTER}'') ; ' $code = $code + '$WShell.SendKeys(''%N'') ; ' $code = $code + '$WShell.SendKeys(''{HOME}'') ; ' $code = $code + '$WShell.SendKeys(''C:\TMP\TF\'') ; ' $code = $code + '$WShell.SendKeys(''%S'')' $ie = New-Object -ComObject InternetExplorer.Application $ie.Navigate( $url ) while ($ie.ReadyState -ne 4) { Start-Sleep -Milliseconds 100} Start-Process powershell.exe -argument ('-version 2.0 -noprofile -windowstyle hidden -command "{0}"' -f $code) $ie.ExecWB(4,0,$null,[ref]$null)

コードをご覧いただいてもわかるように、ちょっと特殊なことというか...古臭いことをしています。

Windows Script 時代からスクリプトを使っていた方ならばご存じの、SendKeys メソッドです。

（参考）Converting the Windows Script Host SendKeys Method

事前に、$code に WScript.Shell を使用した SendKyes メソッドを埋め込んでおきます。そして、ExecWB を実行する直前で、Start-Process コマンドレットを使ってスクリプトを実行しています。

こうすることで、ExecWB によって表示されたダイアログを SendKeys メソッドで操作することができます。

今回は Windows Script を使用しましたが、.NET Framework らしく [System.Windows.Forms.SendKeys] を使うこともできます。ただ、これだとコードが見づらくなってしまうので、個人的にはあまり好きじゃありません。

ちなみに、「名前を付けて保存」の便利なところは、ファイル名として自動的にWEBページのタイトルを使用してくれるところです。そのため、ファイル名の指定にも SendKey を使用するといった面倒なことをする必要がありません。

この他 WORD に読み込んで保存するなど方法はいくつかありますが、出力結果を比較すると、やはり ExecWB がベターかなといった感じです。

SQL Server とダイエットコークが大の苦手な安納です。

SQL Serverに対する苦手意識を克服するためにどうしようかなぁと考えた末、「知らない振りをする」という裏ワザではなく、自習書を使うという極めてスタンダードな方法に落ち着きました。

自習書シリーズってご存知ですか？

SQL Server チームが作成した（お金を出して発注して作ってもらった）、それは素敵な学習書のことです。

もちろん無償でダウンロードできます。

SQL Server 2008 自習書シリーズ（一覧）
http://technet.microsoft.com/ja-jp/sqlserver/dd610200.aspx

私のように、とにかく SQL Server が苦手！という方は、まずは以下の3冊を実施してみましょう。

• SQL Server 2008 ささっと試せる SQL Server 超入門編
  ※インストールから管理ツールの基本的な使い方をマスターできます
  http://go.microsoft.com/?linkid=9294187
• SQL 基礎の基礎
  ※SQL構文の基礎をマスターできます
  http://go.microsoft.com/?linkid=9294195
• データのコピーと現場で役立つ便利な操作集
  ※フィールドSEとして現場で求められる基本的な管理機能についてマスターできます
  http://go.microsoft.com/?linkid=9294192

基礎を知ったところで、さらに理解を深めるために以下も読破しましょう。

普段SQL Server を管理しているという方は、ここからはじめてもよいでしょう。案外知らないことが多いはず。「あぁ、あの操作ってそういう意味なのか！」と感動すること請け合いです。

• ログイン認証とオブジェクト権限
  http://go.microsoft.com/?linkid=9294225
• セキュリティ
  http://go.microsoft.com/?linkid=9294246
• 監視ツールの基本操作
  http://go.microsoft.com/?linkid=9294228
• バックアップと復元
  http://go.microsoft.com/?linkid=9294237

そして、「運用担当のフィールドSEだけど、ちょっと業務アプリのメンテナンスもしなくちゃならないんだよねぇ」という方には以下が用意されています。

• インデックスの基礎とメンテナンス
  http://go.microsoft.com/?linkid=9294240
• ロックと読み取り一貫性
  http://go.microsoft.com/?linkid=9294243
• データベース ミラーリング入門
  http://go.microsoft.com/?linkid=9294231
• データ パーティション入門
  http://go.microsoft.com/?linkid=9294234

さらに、一歩先の使い方をお客様に提案したい、ほかのSEに自慢したい、新しい業務の仕組み考えているなんて方は、以下がおすすめです。特に、Integration ServicesとReporting Servicesは、知らないと損です（と、恥ずかしながら思いました）。

• SQL Server 2008 Reporting Services 入門
  http://go.microsoft.com/?linkid=9294198
• SQL Server 2008 Reporting Services 応用
  http://go.microsoft.com/?linkid=9294201
• SQL Server 2008 Analysis Services 入門 with Excel 2007
  http://go.microsoft.com/?linkid=9294204
• SQL Server 2008 Integration Services 入門
  http://go.microsoft.com/?linkid=9294207
• SQL Server 2008 Integration Services 応用
  http://go.microsoft.com/?linkid=9294210

すばらしいです。SQL Quality の 松本さん、ありがとう！

多くの方が Windows PowerShell をお使いのことと思います。

PowerShell にはさまざまな「奥義」が存在しますが、「バックグラウンドジョブ」も奥義の一つです。これは究極奥義である「ワークフロージョブ」へとつながる大切な概念です。

まずは以下をご覧ください。

Get-Service  -ComputerName  Server01

何をやっているかは一目瞭然ですよね。

リモートコンピューター Server01 上のサービス一覧を取得しています。

通常 Get-Service は直ぐに結果を得られるので問題ないのですが、結果取得までに10分とか20分を要する場合にはコンソールを占有されてしまうことを回避するため、「バックグラウンドジョブ」と呼ばれる方法を使用します。

つまり、コマンドを投げっぱなしにしておいて（非同期実行）、あとから結果を取りに行く...という方法です。

バックグラウンドジョブを作成するには2つの方法があります。

• -AsJob パラメタを使用する
• Start-Job コマンドレットを使用する

いずれを使用しても得られる結果は同じですが、コマンドレットによっては -AsJob をサポートしていない場合もあり、その場合には Start-Job の引数にコマンドレットを指定します。

例えば、Get-Service の場合には -AsJob パラメタをサポートしていないため、バックグラウンドジョブ化するには以下のように書きます。

Start-Job -ScriptBlock { Get-Service -ComputerName  Server01 }

さて、ここまでは一般ピープルでも知っていることです。

エキスパートな方はここからが重要なのです。

さっそくですが、以下の2つの違いわかりますか？いずれも上の記述を書き換えたもので、同じ結果が得られます。

$S = New-PSSession  -ComputerName  Server01
Invoke-Command  -Session $S  -ScriptBlock { Get-Service }  -AsJob

$S = New-PSSession  -ComputerName Server01
Invoke-Command  -Session $S  -ScriptBlock {Start-Job  -ScriptBlock { Get-Service } } 

1 行目の 「$S = New-PSSession  -ComputerName  Server01 」はおわかりですよね。リモートコンピューター Server01 と PS セッションを張ってます。図にすると以下のような感じです。

問題は2行目です。同じことをやってそうなのですが、微妙に書き方が異なっています。-AsJob と Start-Job に何か秘密が隠れているようではあります。

Invoke-Command を使用すると、リモートコンピューター上でコマンドレットを実行することができます。今回の例では、事前に作成した Server01 とのセッションを使い、Server01 上で Get-Service を実行しています。

-AsJob を指定することで Invoke-Command 自体がバックグラウンドジョブ化され、リモートでのコマンド実行を待ち合せることなく、バックグラウンドで非同期に実行することができます。

結果は Invoke-Command を実行したローカルホストに保存されます（ここ重要！）。

図にすると以下のような感じです。

一方、-AsJob ではなく、ScriptBlock 内で Start-Job を実行した場合はどうなるでしょう。

Start-Job は Server01 上で実行されるため、バックグラウンドジョブ化されるのは Server01 上の Get-Service コマンドです。

では、結果はどこに保存されるかといえば、ジョブが実行された Server01 上です。

図にすると以下のようになります。

当然、結果を取りに行くときは、以下のように Server01 に対して Receive-Job する必要があります。

Invoke-Command -Session $S -ScriptBlock { Receive-Job <jobid> }

両者の違いを正しく理解しておくことはとても重要です。

例えば、「長く時間を要するバックグラウンドジョブを実行して、あとで結果を受け取ろう」と考えたとしましょう。

もし Invoke-Command -AsJob を使用してローカルコンピューター上に結果を保存するようにした場合、ローカルコンピューターはジョブが終わるまでネットワークから切り離すこともシャットダウンすることもできません。ネットワークから切り離されたり、シャットダウンした瞬間にジョブは消滅します。

しかし、後者（ Invoke-Command {Start-Job }）で実行すれば、ジョブはリモートで実行され、結果もリモートに保存されます。

ジョブを投げたあとはDisconnect-PSSession でセッションをいったん切断し、あとから Connect-PSSession でもとのセッションに再接続することができます。

（参考）

【Management】PowerShell V3.0 で向上したリモーティング機能 その1
http://blogs.technet.com/b/junichia/archive/2012/03/24/3488392.aspx

【Management】PowerShell V3.0 で向上したリモーティング機能 その2
http://blogs.technet.com/b/junichia/archive/2012/03/26/3488520.aspx

「ジョブの実行場所が、結果の保存場所である」

.....ということをくれぐれも忘れないでください。

たったいまこんなことがありました。

Windows Server 2012 R2 上にインストールされている Active Directory Federation Service が「開始中」のまま起動できないのです。30分ほど待ってみましたが、まったく状況は変わりません。もちろん、AD FS に依存している Device Registration Service も起動していません。

AD FS の構成情報が格納されている Windows Internal Database は正しく起動しているようなので、Directory Service の問題かと考えイベントログを調べました。

すると、以下の警告ログが大量に見つかりました。

Event ID 2947

グループ管理サービス アカウントのパスワードを取得できませんでした。

「グループ管理サービス アカウント（gMSA：Group Managed Service Account）」とは、Windows Server 2012 でリニューアルされたサービスアカウント機能です。手元の環境では AD FS のサービスアカウントとして gMSA を設定してあるのですが、どうやらそのパスワードを取得できないことにより、AD FS が起動できない模様です。

ここですこしだけ gMSA について解説しておきます。ご存知ない方は読んでおいてください。

Winodws Server 2008 以前、サービスに使用する「サービスアカウント」は、ユーザーアカウントと同様に作成する必要がありました。ユーザーアカウントと同様の扱いなので、安全上の配慮からパスワードの変更を行った時には、サービスのアカウント設定画面でパスワードも再設定する必要がありました。

もちろん、Builtin のローカル システム アカウント等を使用することで、パスワードリセットの手間を省くことも可能ではあります。

しかし、サービスが多様化するに従い、サービスアカウントに必要な権限も多様化しました。それ以上に、強い特権を持っている Builtin ローカル システム等を使用することは、システム全体の安全性を脅かすことにもなります。

そこで、Windows Server 2008 R2（Windows 7も含む）では「管理サービスアカウント（MSA：Managed Service Account）」というアカウントがサポートされました。

MSA を使用すると、サービスに独自のアカウントを作成して、必要な権限を与えることが可能です。また、パスワードが自動管理されるため、一度作成して以降は手動でパスワードを変更する必要がありません。

ただ、これですべてが解決されたわけではありませんでした。

MSA には以下の制限があったのです。

• 複数のコンピューターで共有できない
  MSAは、作成したら「特定のコンピューターにアカウントをインストールする」という作業が必要で、一度インストールされたアカウントは他のコンピューターにインストールすることができないのです。この制限は結構残念で、例えばクラスター化されたノード上のサービス間で共有したり、複数の IIS サービスで共有するといったことができませんでした。もちろん、AD FS をファーム構成にした場合にも同様です。
• MSAはアプリケーションレベルでサポートされる
  ちょっと意味が分かりずらいと思いますが、OS が MSA をサポートしているからといって、その上で動作するアプリケーションも MSA をサポートするわけではないということです。事実、Exchange の一部の機能や SQL Server では MSA をサポートしていませんでした。
• タスクスケジューラーで使用できない
  これも結構残念です。

Windows Server 2012 でサポートされた「グループ管理サービスアカウント（gMSA）」では、以下の通り"ある程度"制限が解除されています。

• 複数のコンピューターで共有できる
  フェールオーバークラスターのサービスアカウントとして使用することはできませんが、クラスター化されたノード上のサービス間で共有することは可能です。
• タスクスケジューラーで使用できる

アプリケーションでのサポートについては、実は従来通りの制限があります。どのアプリケーションが gMSA をサポートしているかは、その都度調べる必要があります。ちなみに、AD FSでは問題ありません。

話を戻しましょう。

冒頭に示したエラーを解消する方法を探したのですが、「これ！」というものが見つかりませんでした。

そこで、試しに gMSA のパスワードをリセットしてみることにしました。

まずは、PowerShell コンソールから以下のコマンドレットを使用して gMSA の情報を出力します。

PS C:\Windows\system32> Get-ADServiceAccount -Filter * DistinguishedName : CN=FsGmsa,CN=Managed Service Accounts,DC=itcampjp,DC=com Enabled           : True Name              : FsGmsa ObjectClass       : msDS-GroupManagedServiceAccount ObjectGUID        : 86e6d9df-1621-48ab-b915-fe11aa58fa75 SamAccountName    : FsGmsa$ SID               : S-1-5-21-1369388327-1626757837-1784127236-1126 UserPrincipalName :

gMSA の sAMAccountName を見てください。アカウント名の後ろに 「$」がついていることに注意してください。

次に、以下のコマンドレットで、gMSA のパスワードをリセットします。

PS C:\Windows\system32> Reset-ADServiceAccountPassword fsgmsa$

私の手元の環境では、リセットが完了するまでに 30 秒程度要しました。なので、なかなか終わらなくても安心してください。

リセット完了後、イベントログに以下のメッセージが表示されたらしめたものです。

イベントID 2946

発信者がグループ管理サービス アカウントのパスワードを正常に取得しました。

AD FS も正常に起動することができました。

なぜ gMSA のパスワードが取得できない状態になってしまったのかは、現時点では判明しておりません。

この環境が仮想環境で、2週間程 起動していなかったことが影響している可能性があります。

gMSA のパスワードは、既定では 30日で自動更新されるのですが、それが影響しているようでもありません。この点は継続して調べてみたいと思います。