2011年3月4日はクラウドチームのエバンジェリストによる TechFielders セミナーです。年度末でお忙しいとは思いますが、現時点の最新情報をお送りしますので、お時間のある方は是非ともご参加ください。新しい品川オフィスでの開催となります。

Events : [Tech Fielders セミナー 東京] クラウド プラットフォーム 最新情報 - 間もなくリリースされる新機能を徹底解説 -

私はその中で Windows Azure Connect について解説するのですが、検証作業をしていて不思議に思ったことがあります。それは...

Windows Azure Connect を使用したドメイン参加って”いつ”やってるんだろう？

ってことです。

Windows Azure Connect についてご存知ない方は、まずは以下をご覧ください。 Windows Azure Connect（Virtual Network）を使ってみる (1) Windows Azure Connect（Virtual Network）を使ってみる (2) Windows Azure Connect（Virtual Network）を使ってみる (3)

Windows Azure Connect を使用してドメインに参加するには、Windows Azure Connect の設定と同時に、ドメイン参加に関連するパラメタの設定も行います。（��考）Overview of Windows Azure Connect When Roles Are Joined to a Domain

でもよくよく考えてみれば、ドメインに参加するには Azure Connect が有効でなければならないわけで、どのタイミングでドメインに参加しているのかよくわからないですよね。もしかして、我々の知らない秘密の方法が隠されているのか？などと期待してよくよく観察してみると、どうやらロールインスタンスにインストールされた Azure Connect のエンドポイントソフトウェアが、ドメイン参加の設定を自動検出して裏で参加処理をしている模様です。

以下のような流れです。

1. Visual Studioで作成したパッケージをWindows Azure に展開する
2. Azure上にインスタンスが作成される
3. Windows Azure Connect  の設定が有効になっていると、自動的に Azure Connect のエンドポイントソフトウェアがインストールされる
   ※この時点では Windows Azure Connec の環境設定が有効でないので、Azure Connect のアイコンは「無効」として表示されています。もちろん、オンプレミスとの通信も行えません。
4. Windows Azure ポータルの「Virtual Network」で Azure Connect の設定（グループ作成）を行う
5. 設定が有効になると、グルーピングされたオンプレミスのコンピュータ(エンドポイントコンピューター）とロールインスタンスに Azure Connect が使用する専用の仮想ネットワークカードが作成され、IPV6アドレスが振られる
   
6. グルーピングされたオンプレミスのエンドポイントコンピューターとロールインスタンスの Firewall 設定に、Azure Connect 用の設定が埋め込まれる。これにより、めでたくオンプレミスとロールインスタンスの通信が有効になる。
   InBound設定
   
   OutBound設定
   
7. ドメイン参加の設定が検出されると、ロールインスタンスにインストールされた Azure Connect のエンドポイントソフトウェアが、裏でオンプレミスと通信を行い、ドメイン参加が行われる。
8. ドメインに参加後、自動的に全てのロールインスタンスが再起動される
9. ドメイン参加完了

わかってみればなんてことありませんでした。ごく普通の処理をしていたのですね...。

ここでつい気になってしまうのは Firewall の設定だと思いますが、これについてはまたあとで触れたいと思います。

3月4日のセミナーにお越しくださったみなさま、ありがとうございました。限られた時間で、あまり突っ込んだお話ができませんでしたが、Windows Azure Connect について何ができるのかはご理解いただけたかと思います。

懇親会ではネットワークの条件について多くの方からご質問をいただきましたので、この場を借りて補足しておきたいと思います。

※Windows Azure Connect は現時点でプレビュー版が提供されていますので、リリース時に使用が変更される可能性があることをご了承ください

ちなみに、以下のようなビデオ（英語ですんません...）も公開されていますので、興味のある方はご覧ください。

Windows Azure Platform Security Essentials: Module 5 - Secure Networking using Windows Azure Connect

Azure Connect 自身の機能については、以下も参考にしてください。
【Azure for ITPro】Windows Azure Connect を使用した ADドメインへの参加について

Windows Azure Connect を使用すると、IPv6 を使用して通信を行うことは多くの皆さんがご存知の通りです。ただ、そうなると疑問が出てきます。既に @kamebuchi さんのブログでも触れらている通り、「じゃぁ、IPv6に対応したネットワーク環境が必須になるの？」ということです。

ちなみに、Windows Azure Connect の技術解説サイトには以下のように書かれています。

Overview of Firewall Settings Related to Windows Azure Connect In Windows Azure Connect, the firewall settings on local endpoints (local computers or VMs) are under your control. Windows Azure Connect uses HTTPS, which uses port 443. Therefore, the port that you must open on local endpoints is TCP 443 outbound. Windows Azure Connect では、ローカルコンピューターおよびAzureインスタンスのファイアウォールの設定はシステム管理者の制御下にあります。Windows Azure Connect は HTTPS（Port 443）を使用しているため、ローカルコンピューターは外部に向けて TCP 443 を使用して通信ができなければなりません。

サクッと言ってしまうと、Windows Azure Connect は IPv6 over IPv4 によって、IPv6 を IPv4でカプセル化して通信します。その際に使用されるプロトコルは SSTP （トランスポートプロトコルは HTTPS）です。

※SSTPについては田辺さんのBLOGをご参照ください
SSTP VPN を試す - Shigeya Tanabe's blog - Site Home - TechNet Blogs

これは、Windows Vista SP1以降および Windows Server 2008 以降に実装されているトンネリングプロトコルで、 HTTPS を使用しているため、既存のファイアウォールやNATとの相性が良いというメリットがあります。そのため、おそらく多くのネットワーク環境では特別な設定が必要ありません。

Windows Azure Connect は、この SSTP を使用して Relay サービスとのトンネルを構成します。

このVPNトンネルの構成までは、既存の IPv4アドレスが設定されているネットワークカードが使用されます。

VPN トンネルが構成されると、Windows Azure Connect エンドポイントソフトウェア によって作成された仮想ネットワークアダプターが使用されます。

仮想ネットワークアダプターにはWindows Azure Connect 仮想ネットワーク用の IPv6 アドレスが振られており、VPN トンネルの中を IPSec で暗号化してロールインスタンスとの通信を行います。このとき、Relay サービスは IPv6 のルーターとして動作し、ルーター要請メッセージ（router solicitation message） を受け取ってルーティングを構成し、目的のロールインスタンスへのルーティングを行ってくれます。

さて、ここで2点疑問が出てきます。

• ローカルコンピューターからのロールインスタンスの名前解決はどうするのか？
• ロールインスタンスからのローカルコンピューターの名前解決はどうするのか？

ということです。

実は、Windows Azure Connect には、Relay サービスのほかに「Windows Azure Connect Name Service」と呼ばれる名前解決サービスが用意されています。この名前解決サービスに接続するためのリゾルバは、Windows Azure Connect エンドポイントソフトウェア のインストール時に、ローカルコンピューターにインストールされます（同様に、ロールインスタンスにもインストールされます）。

Windows Azure Connect エンドポイントソフトウェアは、ローカルコ��ピューターおよびロールインスタンスのホスト名とIPv6 アドレスを、Windows Azure Connect Name Service に登録します。これにより、エンドポイント同士の名前解決が可能になります。もちろん、オンプレミスのローカルコンピューターは、Windows Azure ロールインスタンスの名前解決クエリのみを Azure Connect Name Service に転送し、その他の名前解決は既存のDNSに転送します。ローカルネットワークのアドレスが Azure Connect Name Service に登録されることはありません。

※コミュニティサイトにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。

え？なんの暗喩かってですか？ いえ、そのまんまです。理由は OData Service がうまく使えなくて現実逃避中だからです。

本当は AppFabric ACS V1 のありがたみについて解説しようとしたのですが、ちょっと方針を変えてお湯のありがたみについて解説したいと思います。

同じことですからね。

私は 砂漠＋古代遺跡 系が好きなので、時間が取れると砂漠と古代遺跡がある場所に行くことにしています。

砂漠というと「暑い！」というイメージを持ちがちですが、経験のある方はお分かりの通り、朝晩は結構冷えるんですね。特に、この時期の砂漠なんて寒いったらないです。乾燥してますから余計に寒いです。その近くにある街も同様です。

そうなると、宿に戻ってからの楽しみといえば、食事よりも先に熱いシャワーです。砂で体中がじゃりじゃりですから、余計にシャワーが恋しくなります。

だからセレブな私はどんな国で宿泊するときも、宿選択の第一条件は「ホットウォーター」が出る「個室」です。セレブですから当然です。

ただしコレが曲者なんですねぇ。「24H Hot water」と大々的に紹介されていても、お湯タンクが全部屋共通だったり、水に少し毛が生えた程度だったりする場合が多いわけです。タンクが共通だと悲惨ですよぉ。少しシャワーの時間が遅くなると、どんなに待っても水しか出ませんから。真夏だって水風呂は厳しいのに、この時期の水風呂は絶対に回避しなければなりません。

なので先日宿泊した宿は、いつもならば一泊1000～2000円程度で抑えるところを、4000円（朝食付き）と張り込みました。セレブなので。

その結果、とても素晴らしいマシンが設置されたホテルに宿泊することができました。

その素晴らしいマシンが以下です。

これは「湯沸かし器」という装置です。その名も「SPEED HEAT」。否応にもフューチャーを感じさせるネーミングです。

これが実に素晴らしい！

全体像はこんな感じです。マニュアル不要の考えつくされた UX です。シャワーヘッドは気品さえ感じさせます。

ただし、気を付けなければならないのは、SPEED HEAT の気持ちになる必要があるという点です。ITPRO ならばお手の物ですよね。

今後、皆さんが同じ装置に出会った時のために、簡単に使用手順をご紹介しておきます。

1. 裸になる
2. 水を出す。
   （要注意）最初にSPEED HEAT のスイッチを入れないでください。空焚きになって故障します。
3. SPEED HEAT のスイッチを入れる
   以下はオフの状態です。
   
4. シャワーを浴びる。
   （要注意）この時、お湯を SPEED HEAT にかけないでください。ショートしてホテル中が停電になります。
5. SPEED HEAT のスイッチをオフにする
   （要注意）初めに水を止めないでください。空焚きになって故障します。
6. 水を止める
7. 体をふく
8. 服を着る
9. 故郷を想って少し泣く

この手順さえ守れば、快適なお湯生活が送れるという優れものです。「24H Hot Water」に嘘偽りはありませんでした。

4000円を支払った甲斐がありました。

ちなみに、このシャワー、トイレにあります。

え？ユニットバスのことかって？

いえいえ、違います。トイレの壁にシャワーがついています。

合理的ですね。

3月11日に品川オフィスで開催する TechFielders セミナーでは、2011年上半期にリリースが予定されている AppFabirc Access Control Service V2 を使用したシングルサインオンシステムの構築方法について、その手順とアーキテクチャを3時間みっちり解説します。

Events : [Tech Fielders セミナー 東京] Windows Azure AppFabric ACS で構築するシングルサインオンシステム [CoreIO]

対象はインフラを担当されているシステムエンジニア（IT Pro）の皆さんですが、開発者の方が参加されても十分面白いと思います。この機会に是非ともご参加ください。

資料はまだ作成中なのですが、当日の予告をいたします。

1. マイクロソフトのハイブリッドクラウドシナリオ（5分 程度）
   マイクロソフトがこれから提供しようとしているハイブリッドクラウドシナリオについて簡単に解説します。
2. クレームベースのアクセス管理 概説（15 分 程度）
   クレームベースのアクセス管理について、初めての方のために、まずはここから始めます。ここを知らないと、この先がさっぱりわからなくなります。ですので、既に「知ってる」という方は遅刻してください（笑）。
3. Windos Azure AppFabric Access Control Service 概説（20 分程度）
   Windows Azure AppFabric Access Control Service(ACS) の全体像について解説します。
   • 現在提供されている V1 のアーキテクチャとその用途について
   • 2011年上期にリリース予定の V2 のアーキテクチャとその用途について
4. Windows Azure AppFabric ACS V2 を使用したシングルサインオンシステムの構築
   現在提供されている ACS V2 のテスト環境を使用し、AppFabric ACS V2 を使用したシングルサインオンシステムを一から構築します。随時、手順の意味やアーキテクチャについて技術解説を入れていきます。
   • アプリケーションの作成とWindows Azure への展開（30分程度）
     ...といってもIT Pro 向けなのでできる限りコーディングしないで体験できる手順で作成します。ここでは一部Visual Studioを使用しますが、怖くありません。展開が完了するまでには時間がかかるので、ここで休憩をはさむ予定です。
   • AppFabric ACS の環境設定とアプリケーションの登録（15分程度）
     作成したアプリケーションをAppAFabric ACS V2 に登録します
   • Identity Provider の設定①－ AD FS 2.0 編（45分程度）
     まずはもっとも実装頻度の高いと思われるオンプレミスの Active Directory との連携から始めます。AppFabirc ACS V2 と AD FS 2.0 を連携させて SSO を構築します。ここでは、AppFabric ACS V2 のクレームルールについても詳しく解説したいと思います。コレが終わったらいったん休憩かな...。
   • Identity Provider の設定②－ Google 編（15 分程度）
     AD FS 2.0 との連携を踏まえ、今度は AppFabric ACS V2 と Google のアカウントを連携させて SSO を構築します。ついでに Yahoo!（yahoo.comです）との連携についても触れるかも���れません。
   • Identity Provider の設定③－  Facebook 編（30 分程度）
     Facebook を Identity Provider とするときの Facebook側の設定、および AppFabric ACS V2 側の設定手順について解説します。
5. まとめ（5分程度）

※ あれ？180分になっている....こりゃ休憩なしか？？ま、なんとかなるかな...。

Windows Azure の実環境を使用しますので、インターネット環境に接続可能なモバイルPCをお持ちの方は、その場でアプリケーションにアクセスしていただくことが可能です（ごめんなさい、残念ながら Wifi はありませんです...）。

Windows Azure の基本的なお話は、今回はいたしませんのでご了承くださいませ。

当日お会いできるのを楽しみにしております。

※ここでご紹介する方法はマイクロソフトにより正式にサポートされてものではありませんのでご了承ください

Windows Azure のサブスクリプションは、Windows Azure ポータル以外に、Windows PowerShell からも操作できます。管理作業や展開作業を自動化したい!といった場合には、やはりスクリプトの出番です。スクリプトといえば  IT Pro の十八番ですよね！

ただしマイクロソフトのサイトで提供されているコマンドレットは、まだ Windows 7/2008R2 SP1 および Windows Azure SDK 1.4 に対応していません。そのため、既に Windows 7 SP1 Windows Azure SDK 1.4 をインストールしてしまった環境では インストール時に以下のメッセージが出て失敗しまします。

Operationg System Not Supported.PLease review your machine configuration and try again. Click Close to exit the Configuration Wizard.

この問題を回避して、ひとまず Cmdlet を使用可能にするには、インストール用のパッケージを少し修正する必要があります。

ということで、コマンドレットを使用するまでの準備手順を以下に記しておきます。

（01）SDK をインストールする

SDK がまだインストールされていない場合には、Windows Azure 用 PowerShell コマンドレットをインストールする前に、最新の Windows Azure SDK（2011年3月時点では V1.4）をインストールしておきましょう。

Download details: Windows Azure SDK and Windows Azure Tools for Microsoft Visual Studio (March 2011)

※日本語版はまだリリースされていませんので英語版をインストールしてください。

（02）Windows Azure Service Management コマンドレット をダウンロードする

Windows Azure Service Management コマンドレットは以下からダウンロードすることができますので、ダウンロードしておいてください。

Windows Azure Service Management CmdLets - Release: Service Management Cmdlets - Feb 2011 Update

（03）(02)でダウンロードしたファイルを実行して解凍

ダウンロードした WASMCmdlets.Setup.exe を実行して、ファイルを解凍します。

解凍が完了すると、以下のフォルダが作成されます。

C:\WASMCmdlets

（04）バージョンを修正してインストールコマンド（startHere.cmd ）を実行する

C:\WASMCmdlets の直下には startHere.cmd というバッチファイルが格納されていますので、これを実行するとコマンドレットがインストールされます。

ただし、冒頭で述べたように、OSやSDKのバージョン不一致でエラーになることがあります。

その場合には、2つの対処を行います。

■OS バージョン不一致への対処

C:\WASMCmdlets\setup\dependency.dep ファイルをメモ帳で開いて以下のように赤字の部分を追記してみてください。

※保存後、拡張子が dep であることを確認してください

<?xml version="1.0" encoding="utf-8" ?> <DependencyCheckerConfiguration>   <title>WASM Cmdlets</title>   <image>resources\AzureServicesPlatformTools.png</image>   <previews>     <preview name="Check dependencies for Azure Management Tools"        description="Check dependencies for Azure Management Tools" />     <preview name="Install Windows Azure Management Tools PowerShell SnapIn"          description="Install Windows Azure Management Tools PowerShell SnapIn" />   </previews>   <tasks>     <task description="Install WASM PowerShell SnapIn"           scriptName=".\scripts\tasks\installPSSnapIn.cmd" displayConsole="true"/>   </tasks>   <dependencies>     <os type="Vista;Server" buildNumber="6001;6002;6000;6100;6200;7100;7600;7601">       <dependency       value=".\scripts\dependencies\check\CheckNET35SP1.ps1"       enabled="true"       optional="false" （略）

”7601”とはもちろん、OS のビルド番号です。SP1が適用されると、7600 から 7601 にビルド番号がアップします。

■ Azure SDK バージョン不一致の対処

SDK のバージョン不一致が発生すると、以下のエラーが発生します。

Download and install the Windows Azure SDK 1.3

この場合には、現在インストールされている SDK のバージョンを、インストールするスクリプト内（C:\WASMCmdlets\setup\scripts\dependencies\check\CheckAzureSDK.ps1 ）に記載します。

バージョンを調べるには、コントロールパネルを開いて、Windows Azure SDK のバージョンを確認します。

この場合に、Windows Azure SDK のバージョンは、1.4.20227.1419 です。よって、CheckAzureSDK.ps1 を以下のように修正します。

function SearchUninstall($SearchFor, $SearchVersion, $UninstallKey) { $uninstallObjects = ls -path $UninstallKey; $found = $FALSE; foreach($uninstallEntry in  $uninstallObjects) {    $entryProperty = Get-ItemProperty -path registry::$uninstallEntry    if($entryProperty.DisplayName -like $searchFor)     {        if($entryProperty.DisplayVersion -eq $searchVersion)        {          $found = $TRUE;          break;        }     } } $found; } ## $res1 = SearchUninstall -SearchFor 'Windows Azure SDK*' -SearchVersion '1.3.11122.0038' -UninstallKey 'HKLM:SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\'; ## $res2 = SearchUninstall -SearchFor 'Windows Azure SDK*' -SearchVersion '1.3.11122.0038' -UninstallKey 'HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\'; $res1 = SearchUninstall -SearchFor 'Windows Azure SDK*' -SearchVersion '1.4.20227.1419' -UninstallKey 'HKLM:SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\'; $res2 = SearchUninstall -SearchFor 'Windows Azure SDK*' -SearchVersion '1.4.20227.1419' -UninstallKey 'HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\'; ($res1 -or $res2)

この状態でファイルを保存して再度実行してみましょう。

表示されているSDKのバージョンは違いますが、内部では SDK 1.4 環境下で処理されています。

[Next] をクリックすると最後に、C:\WASMCmdlets\setup\Scripts\tasks にある installPSSnapIn.cmd が実行されてインストールは完了です。

Windows PowerShell のコンソールを開いて、Windows Azure Service Management コマンドレットが読み込まれていることを確認してみましょう。

まずは、プロファイルにWindows Azure Service Management コマンドレットを読み込みます。

次に、コマンドレットの一覧を表示してみます。

コマンドレットの一覧が出てくればひとまずOKです。

Windows Azure Service Management コマンドレットを使用するには、事前準備が必要です。準備については以下を参照してください。

【Azure for IT Pro】Windows Azure Service Management コマンドレット がインストールできない場合の回避方法

試しに Windows Azure Service Management（WASM）コマンドレットを使ってみましょう。ちょっとしたコツが必要です。

ここでは、PowerShell を使用した管理の全体像について解説します。

■Windows Azure の管理について

Windows Azure Subscription の管理イメージは以下の通りです。ご覧のとおり、管理には大きく分けて3通りの方法が用意されています。

• Windows Azure Management Portal
• Visual Studio
• Windows PowerShell

Windows Azure Portal は既定のポータルサイトのため利用者側では意識しませんが、Visual Studio や Windows PowerShell 等を使用して独自の管理用プログラムを作成する場合には、管理者であることを証明するために、クライアント証明書を用意しておく必要があります。クライアント証明書は自己署名証明書を利用することもできます。

クライアント証明書は、Windows Azure サブスクリプションにアップロードするとともに、自作のプログラムを実行するクライアントにもインストールしておかなければなりません。

■管理用証明書の準備

Windows Azure Service Management（WASM）を使用するための自己署名証明書（.cer）を用意しましょう。

.cer ファイルをを作成するには、Makecert コマンドを使用します。

コマンドを使用する前に、以下をインストールしておいてください。

• Windows SDK for Windows 7 | MSDN

コマンドは既に手元にある...という場合には、以下だけダウンロードしてインストールすれば使用することができます。

• Platform SDK Redistributable : CAPICOM

準備が出来たら、以下のコマンドを入力して .cer ファイルを作成してください。

C:\tmp> makecert -r -pe -a sha1 -n CN=AzureMgmt -ss My -sky exchange -e 12/31/2099 "AzureMgmt.cer"

• -r : 自己署名証明書を作成します
• -pe : プライベートキーをエクスポート可能にする
• -a sha1 : 署名のアルゴリズムを sha1 とする
• -n CN=AzureMgmt : 証明書の主体名。クライアント証明書なので主体名は何でもよい
• -ss My : 作成した証明書の格納先。My は個人の証明書ストアを示している。
• -sky exchange : キーのタイプを示しています。Exchangeオプションは、この証明書が署名と暗号化に使用できることを示しています。
• -e 04/30/2099 : 証明書の有効期限です。開始日を指定するには –b を使用します。
• “AzureMgmt.cer” : 出力する証明書のファイル名です

上記コマンドを実行すると、AzureMgmt.cer ファイルが作成され、かつ証明書の個人ストアにも格納されます。

■管理用証明書をアップロード

証明書のアップロードは、Azure Portal から行います。

これでAzureサブスクリプションを管理するための証明書の準備が完了です。

■PowerShell を使用してみる

では早速使ってみましょう。今回は、簡単なところで、Azure 上に展開済みのサービス一覧を取得してみます。使用するコマンドレットは、Get-HostedServices です。

PowerShell のコンソールを開き、以下のコマンドを入力して WASMコマンドレットを読み込んでおいてください。

PS C:\> Add-PSSnapin AzureManagementToolsSnapIn

① 証明書を取得する

WASM REST API にアクセスするには証明書の提示が必要です。証明書は既に個人ストアに格納されているので、そこから先ほど作成した AzureMgmt.cer を取得しましょう。これはとても簡単です。

実は、PowerShell を使用すると、ファイルシステムと同様の方法で証明書をブラウズすることができます。以下のように先ほど作成した証明書が表示されます。

PS C:\> cd cert: PS cert:\> cd .\CurrentUser PS cert:\CurrentUser> cd .\My PS cert:\CurrentUser\My> dir     ディレクトリ: Microsoft.PowerShell.Security\Certificate::CurrentUser\My Thumbprint                                Subject ----------                                ------- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  CN=AzureMgmt ・ ・ ・ PS cert:\CurrentUser\My>

では、この証明書をオブジェクトとして取得しましょう。使用するのは、おなじみの Get-Item です。

PS cert:\> $ManagementCert = Get-Item cert:\CurrentUser\MY\xxxxxxxxxxxxxxxxxxxxB4AAC33D06A3C89CC6C2 PS cert:\> $ManagementCert     ディレクトリ: Microsoft.PowerShell.Security\Certificate::CurrentUser\MY Thumbprint                                Subject ----------                                ------- xxxxxxxxxxxxxxxxxxxxB4AAC33D06A3C89CC6C2  CN=AzureMgmt PS cert:\>

では、この証明書を使用して Get-HostedServices コマンドを使用してみます。Get-HostedServices を使用して、すべてのホスト済サービスを取得するには以下のように入力します。

PS C:\> Get-HostedServices -SubscriptionId xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -Certificate $ManagementCert

-ScbscriptionId に指定しているのは、契約しているAzureサブスクリプションの SubscriptionId です。これはAzureポータルで参照することができます。

-Certificate には、事前に取得した管理用証明書のオブジェクトを使用します。

以下のような結果が得られれば成功です。

Url            : https://management.core.windows.net/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/services/hostedservices/conne                  cttestjuniachia AffinityGroup  : Location       : Description    : Label          : SubscriptionId : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx Certificate    : [Subject]                    CN=AzureMgmt                  [Issuer]                    CN=AzureMgmt                  [Serial Number]                    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx                  [Not Before]                    22/04/30 0:00:00                  [Not After]                    51/12/31 0:00:00                  [Thumbprint]                    sssssssssssssssssssssssssssssssssssssssssss ・ ・ ・

今回はここまでです。

次回以降、もっと複雑な処理を自動化していきましょう。

つづき 【Azure for IT Pro】診断モニタにアクセスするための PowerShell スクリプト その1

3月11日の地震の際、私の自宅がある栃木県小山市は目立って大きな被害は少なかったのですが、それでも街のそちこちで壁が崩れていたり、神社の灯篭が倒れていたり...私の自宅はといえば、耐震対策がなっていなかったせいか、すべての本棚が倒れ、食器棚の食器が床に散乱し、冷蔵庫は散歩を始め、XBOX 360 と Kinnect は宙を舞いました。今でも寄生獣の5巻が見当たりません。

お客様を担当されているフィールドSEの皆さまも、様々なかたちで被害を受けていらっしゃる方が多いと思います。比較的被害が少ないと言われている都内であっても、電車の運行状況によっては、思ったようにお客様のメンテナンスが行えない状況に悩んでいらっしゃる方も多いはずです。そんな状況でも、VPN の設備が整ったお客様であれば、なんとかサーバーのメンテナンスを行うことができるでしょう。でもすべてのお客様が VPN Supported ではないですよね。

そこで、”一時的な” 回避策として使っていただけるのが、Windows Azure Connect という仮想ネットワーク機能です。

まだプレビュー版ではありますが、何も手が出せない状況と比べれば天と地ほどの差があります。「Windows Azure Connect」は、Windows Azure 上に用意された リレーサーバーを中継点として、ネットワーク的に分断されたサーバー/クライアント間を仮想のネットワークパスで接続するものです。特別な機器は一切必要なく、仮想ネットワークで接続したいサーバーやクライアントにエージェントプログラム（Windows Azure Connect エンドポイントソフトウェア と言います）をインストールするだけなので、とても簡単にセットアップが可能です。

仕組みについてはこちら
【Azure for ITPro】Windows Azure Connect を使用するためのネットワーク条件について

本来の目的はオンプレミスとパブリッククラウドを仮想ネットワークでつないで Hybrid なクラウドを構築するのが目的ですが、このテクノロジーをうまく使うとフィールドSEによる遠隔メンテナンスにも流用できます。

構成パターンはいくつかありますが、ここでは代表的な2パターンをご紹介します。

左の図をご覧ください。自宅や自社のPCから、Windows Azure 上のロールインスタンス（サーバーのことです）を踏み台にして、各お客様先のマシンと通信することができます。もちろん、リモートデスクトップで入ることも可能です。ただし、サポートされているのは、Windows Server 2008/Windows Vista SP1 以降なので、もし お客さま先に Windows Server 2003 等が存在する場合には、一旦お客様先の Windows Server 2008 等に入り込んでから、再度接続することになります。

「お客様A」＜－＞「お客様B」間で通信ができてしまうのでは！？という心配ですが、これは問題ありません。直接お客様サーバー間で通信することはできませんし（そのような設定をしなければです）、各お客様は Windows Azure 上のロールインスタンスにさえも入ることはできません（もちろんロールインスタンスの管理者のパスワードを知らなければの話）。

もし心配であれば、以下のようにロールインスタンスをお客様ごとに用意しておけばOKです。

この機能を使用するには、まず以下の準備をしておく必要があります。

1. Windows Azure のサブスクライブ

現在、本震災対策用の90日間無償アカウントを使用することができます。クレジットカード登録も不要ですので、「捨てID」としてガンガン使ってください。サブスクライブ完了までに最長2営業日ほど要しますので、Windows Live ID を取得の上、速攻でお申し込みください。
もし、既にWindows Azure アカウントを申し込んだ Live ID が存在するようであれば、同じIDで申し込みすることも可能です。その場合には、ベータプログラムの利用権限はそのまま引き継ぐことができます（環境は引き継げませんが）。
なお、1つの Windows Live IDで申し込める無償パスは1回だけです。複数お申し込みする場合には、Windows Live ID をその都度作成してください。 

2.Windows Azure Connect ベータ利用申込み

Windows Azure アカウントが発行されると、http://windows.azure.com/ にログオンして各機能を操作することができるようになります。ここで、Windows Azure Connect を有効にするには、左側の「HOME」をクリック後、その上にある「Beta Program」をクリックします。すると、画面右側にベータ申込み用画面が表示されるので、「Windows Azure Connect」を選択して「Apply for Access」をクリックしてください。 興味があれば VM Role もチェックして申し込んでください。

まずはここまでやっておきましょう。Windows Azure Connect が有効になるまでには本社側の承認処理が必要になるため、少し時間を要すると思われます。Windows Azure Connect が有効になると、表示が以下のように変わります。

Windows Azure Connect が Active になったら、以降の作業を行ってください。

※約1週間で有効になります。有効になると「Welcome to the Windows Azure Connect CTP!‏」というメールが届きます。

3. Windows Azure 上に踏み台となるアプリケーションを展開するための準備

はじめに踏み台となるダミーのアプリケーションを作成するのですが、アプリケーションを作成するには Visual Studio が必要です。でも IT PRO の方は Visual Studio なんて持ってないですよね。なので、今回は無償の Visual Studio 2010 Express を使用します。

① SQL Server 2008 R2 Express をインストールする

ちょっと面倒なのですが、事前に SQL Server 2008 R2 Express をインストールしておいてください。SQL Server 2008 R2 Express は以下からダウンロードすることができます。もちろん無償です。

http://www.microsoft.com/downloads/details.aspx?familyid=8B3695D9-415E-41F0-A079-25AB0412424B&displaylang=ja

実は、これから紹介する Webプラットフォームインストーラー（Web PI）を使用して、Visual Web Developer 2010 Express と同時に SQL Server 2008 R2 Express をインストールすることができるのですが、インストールに失敗することがあります。原因は様々なのですが、事前に個別インストールしておいたほうが確実です。

② 無償の Visual Studio Web Developer 2010 Express をインストールする

SQL Server 2008 R2 Express のインストールが完了したら、以下の Web プラットフォーム インストーラー（Web PI）サイトに移動し、Web PI をダウンロードして実行しましょう。

Download the Microsoft Web Platform

Web PI を実行すると、以下の画面が表示されます。画面上にある[製品]をクリックしてから、一覧に表示されている「Visual Web Developer 2010 Express」を[追加]します。

まだインストールははじめないでください。次の項でもう1つコンポーネントを追加します。

Windows Azure に関連した開発を行うには、Windows Azure 用の SDK および Visual Studio 用の Addin がインストールされていなければなりません。

WebPI の画面を少し下にスクロールして、「Windows Azure Tools for Microsoft Visual Studio 2010 V1.3」を選択してください。

[追加]ボタンをクリックして選択が完了したら、[インストール]をクリックします。

インストールが始まると、以下のように関連コンポーネントも同時にインストールされる旨のメッセージが表示されるので[同意する]をクリックして先に進めてください。

インストールが完了したら、コントロールパネルの[プログラムと機能]に以下が表示されていることを確認してください。

• Windows Azure SDK v1.3.11122.0038
• Widnows Azure Tools for Visual Studio 2010 1.3 v1.3.31122.1601

以上で準備は完了です。

4. 踏み台となるアプリケーションを作成する

「アプリケーションの作成」と聞いて、引いている IT Pro も多いと思いますが、全然大した作業ではありません。Active Directory のインストールのほうが10000 倍難しいです。たんなる手順ですので、覚えてしまいましょう。

おそらく、多くの IT Pro の皆さんが、「なーんでアプリが必要なの？」と不思議に思っていると思います。気持ち悪いと思うので、それについてちょっと触れておきます。 Windows Azure Platform というのは、クラウドの種類の中では「PaaS（Platform as a Service）」に属します。PaaS の P は、もちろん「プラットフォーム」のことですが、この場合のプラットフォームとは OS を意味しています。つまり、Windows Azure は OS をサービスとして提供するクラウドの形態なのです。なので、Windows Azure は、お客様がアプリケーションを作成して Windows Azure 上に展開することを前提に設計されています。 言い換えれば、オンプレミスでは「OSをインストールする」という作業が必要ですが、Widnows Azure では必要ありません。なぜならば、OS は Windows Azure が用意することになっているからです。なので、お客様はアプリケーションの展開からいきなりはじめることができるのです。 では、OS がいつ準備されるかといえば、お客様がアプリケーションを展開しようとしたときです。つまり、アプリケーションの展開がトリガーとなってプラットフォームが準備（OSが展開）されます。そういうふうに、マイクロソフトが作ったのですね。なので、何かをするときには、まずアプリケーションの展開作業が必要になるわけです。 今回の作業では、実はアプリケーションは必要ありません。単に Windows Azure 上の OS を踏み台にするだけですから。けれども、上記のような設計になっているので、ダミーとなるアプリケーションを作成して展開してあげる必要があるのです。

ということで、ダミーアプリを作りましょう。

① Visual Studio を起動する

スタートメニューから、Microsoft Visual Web Developer 2010 Express を右クリックして、「管理者として実行」を選択してください。

Visual Studio が起動したら、スタートページで [ファイル]-[新しいプロジェクト] を選択します。

② Azure アプリ用のテンプレートを選択する

「新しいプロジェクト」ウィンドウの右側には [Visual Basic] と [Visual C#] という2つのノードが表示されますが、好きなほうを開いてください。今回は Visual C# を選択していますが、どうせコードは書きませんから関係ありません。

そんなことよりも、その配下にある「Cloud」が重要です。「Cloud」を選択し、中央のペインに「Windows Azure Project」が表示されていることを確認したら「OK」をクリックします。プロジェクトのファイル名も、何でも構いません。どうせダミーのアプリですから。

最後に、プロジェクトに含めるロールインスタンスを選択するのですが、ここも何も考えず「ASP.NET Web Role」を選択し、「>」ボタンをクリックしてください。すると、以下のように表示されているはずです。

問題が無ければ [OK] をクリックしてください。なんとなく以下のように表示されていれば、OKです。

③ Windows Azure Connect のセキュリティトークンを取得する

今回はコードは一切書く必要がありません。そのかわり、Windows Azure Connect を有効にするためのセキュリティトークンを、構成ファイルに埋め込む必要があります。ここで埋め込んだセキュリティトークンがアプリケーションとともにアップロードされ、Windows Azure の OS 本体に適用されます。なんだか今までと文化が違うので変な感じですが、そんなもんなんだな～と思ってください。

そのセキュリティトークンは Windows Azure ポータル で確認することができます。

まずは、Windows Azure ポータル windows.azure.com を開いて、画面左下にある「Virtual Network」をクリックしてください。

次に、画面右上の「Get Security Token」をクリックします。

すると、以下のようなポップアップが開きます。ここに書かれている英数字の羅列が噂の「セキュリティートークン」です。「Copy Token to Clipboard」をクリックして、クリップボードに一時的にコピーしてください。

④ セキュリティトークンをアプリケーションに埋め込む

これもぜーんぜんたいした話ではありません。

Visual Studio の右側に表示されている「ソリューションエクスプローラー」から、「ロール」の下にある「WebRole1」というノードを見つけてください。こいつを右クリックして「プロパティ」を選択します。

すると、WebRole1のプロパティ画面が開くので、「仮想ネットワーク」をクリックしてください。以下のような画面が開きます。そこで、「Windows Azure Connect のアクティブ化」をチェックし、その下のテキストボックスに先ほどコピーしたセキュリティトークンを貼り付けます。

これで、Windows Azure Connect の有効化に関する設定は完了です。

⑤ リモートデスクトップを有効にする

もうちょっとだけ設定が必要ですので頑張ってください。

今回の目的は、Windows Azure 上の OS をお客さま先への踏み台にするわけですから、リモートデスクトップで一度 Windows Azure に入り込めなくてはなりません。Windows Azure では規定でリモートデスクトップが無効になっているので、これを有効化するための設定を埋め込む必要があります。これも、Visual Studio で行います。面倒ですけど頑張りましょう。

Visual Studio の右側にある「ソリューションエクスプローラー」から作成中のプロジェクト（ここでは WindowsAzureProject9）を右クリックして [発行] を選択します。「発行」は他にもあるので、別の「発行」を選択しないように気を付けてください。

「Windows Azure プロジェクトの配置」画面が表示されるので、「サービスパッケージだけを作成」を選択し、さらに一番下にある「リモートデスクトップ接続の構成」をクリックしてください。

＜参考＞「サービスパッケージだけを作成」について 「Windows Azure プロジェクトの配置」画面にある「Windows Azure プロジェクトを Windows Azure に配置します」は、アプリケーションを Visual Studio から 直接 Windows Azure 上に展開する際に使用します。 しかし、一般的に IT Pro のみなさんにとっては、それはちょっと勘弁してほしいですよね。つまり、開発者が自分の知らないところでアプリケーションを展開してしまうのはやめてほしいと考えるのではないかと思います。 そこで、「サービスパッケージだけを作成」を使用してパッケージファイルだけ作成し、展開は IT Pro が Winodws Azure ポータルから実施する...これがおそらく当面のスタンダードな手順かと思います。

[リモートデスクトップの構成] をクリックすると、以下のように「リモートデスクトップ構成」画面が表示されます。ここで「すべてのロールの接続を有効にする」をチェックしてください。

次に、リモートデスクトップに使用するための証明書を作成します。オンプレミスの Windows Server に接続する場合には、自動的に証明書が作成されて使用されるので意識することはあまり無いのですが、Windows Azure の場合には証明書の管理方法が特殊（言い換えれば普通のWindows Server と比較してセキュア）なこともあり、自分で準備してあげる必要があります。

「証明書」といっても別に構える必要はありません。この画面でちゃちゃっと簡単に作成できます。

プルダウンを開き、 <作成...> を選択してください。既に一覧に証明書が表示されているかもしれませんが、これらは無視して結構です。

[証明書の作成] 画面が開くので、証明書の識別名を入力してください。何でも結構です。気にせず入力しちゃってください。今回は「certificate for RDS」と入力しました。

[OK] をクリックすると元の画面に戻り、いま作成した証明書が選択されています。

ここまでの作業で、「certificate for RDS」という名前の証明書が作成されて、ローカルの個人ストアに格納されました。

でも自分が証明書を持っているだけでは意味が無く、リモートデスクトップサービスを提供するサーバー側（つまり Windows Azure 側）に格納しておかなければなりません。そこで、この証明書をファイルに保存しておきます。保存した証明書は後で使います。

上の画面の [表示...] をクリックしてください。

すると、いま作成した証明書が表示さるので、「詳細」タブをクリックし、さらに「ファイルのコピー」をクリックします。

証明書のエクスポートウィザードが表示されるので、以下のような流れで PFXファイルを作成してください。途中証明書に埋め込むパスワードの入力が必要ですので、忘れずに覚えておいてください。また、エクスポートした PFX ファイルはあとで Windows Azure ポータル で使用しますから、保存場所を忘れないでください。

→→→→→

最後にリモートデスクトップでログオンするための ユーザーID とパスワード、そしてアカウントの有効期限を指定します。ここで指定したユーザーIDは、Windows Azure 上の OSで、以下のグループに所属し、リモートデスクトップへのログオン権限が与えられます。

• Administrators
• Windows Azure Remote Access Users

なお、有効期限にはくれぐれも注意してください。既定では 1か月 しか与えられません。

全て指定したら OK をクリックしてください。さらに、Windows Azure プロジェクトの配置 画面でも [OK] をクリックしましょう。

すると、以下のように、作成されたパッケージファイルが表示されます。cspkg と cscfg という2つのファイルがあることを覚えておいてください。あと、作成されたパスも覚えておいてください。あとで使います。

以上でダミーパッケージに作成は完了です。

5. Windows Azure にサービスを作成する

Windows Azure 未体験の方は混乱すると思うのですが、ここで言う「サービスの作成」とはオンプレミスで言うところの「OSの準備」です。

まずは、Windows Azure のポータルに移動してください。

画面左下のメニューから「Hosted Services, Storage Accounts & CDN」をクリックし、さらに左中央の「Hosted Services」をクリックしてください。すると、画面の左上に「New Hosted Service」ボタンが表示されるのでクリックします。

今度は[Create a new Hosted Service] ウィンドウが表示されるので、必要な情報を入力します。この画面では、前回までに作成した証明書とパッケージを指定します。

① このサービスの識別名を入力します。なんでもOKです。日本語でもかまいません。

② このサービスのURLの一部となるホスト名を指定します。世界で唯一でなければなりません。重複している場合には警告が出ますので、修正してください。指定したホスト名に .cloudapp.net というサフィックスが付加されてアプリケーションのURLとなります。左の例では、fumidai.cloudapp.net がこのサービスのURLです。

③ サービスをホストするデータセンターの場所を指定します。通常は East Asia（香港）をお勧めするのですが、今回はあえて「North Central US」を選択してください。Windows Azure Connect ではリレーサービスと呼ばれる中継サーバーを使用するのですが、現在はプレビュー版であるため North/South Central US に設置されているようなのです。よって、できるだけリレーサービスに近い場所にサービス展開したほうが、レスポンスが良くなります。

④ サービスを作成すると同時に、アプリケーションも展開するかどうかを指定します。今回は既にアプリケーションを作成済なので、一緒に展開してしまいましょう。よって「Deploy to Production environment」を選択します。さらに、その下にある「Start after successful deployment」もチェックしておきます。

⑤ 展開後のインスタンスの名前を指定します。これもなんでもかまいませんが、わかりやすい名前にしておきましょう。

⑥ 展開するパッケージを指定します。ここには、先ほど作成したアプリケーションを指定します。「Browse Locally」をクリックして、作成したパッケージファイル（.cspkg）を選択してください。

⑦ 展開するパッケージの構成ファイルを指定します。「Browse Locally」をクリックして、先ほど作成した構成ファイル（.cscfg）を選択してください。

⑧ 先ほど保存した証明書を指定します。「Add Certificate」をクリックすると、以下のような画面が表示されるので、PFX ファイルを指定します。このとき、保存時に指定したパスワードを指定します。

すべて完了したら、[OK] をクリックすると、パッケージファイルとサービス証明書が Windows Azure 上にアップロードされるとともに、リモートデスクトップによる接続、そして Windows Azure Connect が有効になります。

アップロード直前に以下のワーニングが表示されることがあります。これは、「インタンスが1つじゃ信頼性が低くなっちゃうよ？」という警告です。今回は無視してかまいません。

アップロードが完了すると、プロダクションのための処理が行われます。全て完了するまでに15分程度を要するので、一休みしておいてください。

処理が完了すると、上の画面のように Ready となります。

以上でアプリケーションの展開は完了です。残るは、Windows Azure Connect の設定だけです。もう少し頑張りましょう！

6. Windows Azure Connect を設定する

Windows Azure Connect を使用するには、以下の2つの作業をおこないます。

• 通信を行いたいコンピューターに Windows Azure Connect エンドポイントソフトウェア をインストールする
• エンドポイントソフトウェアをインストールしたコンピューターとAzure上のインスタンス（ロール）をグルーピングする

今回は、以下のような環境を作成します。自宅から複数のお客さま先に乗り込むイメージです。

① エンドポイントソフトウェアのインストール

エンドポイントソフトウェアとは、要はエージェントのようなものです。このソフトウェアがインストールされると、Windows Azure Connect のリレーサービスと通信するための仮想ネットワークカードが作成され、リレーまでの VPN を張ってくれます。また、Windows Azure Connect 専用の DNS に仮想ネットワークカードのアドレスを登録してくれます。

ということで、インストールを開始しましょう。なお、Winodws Azure 上のインスタンスにはパッケージのアップロードと同時にインストールされますので、手動で行う必要はありません。

Windows Azure Portal を開いて、画面の下にある「Virtual Network」をクリックしてください。

画面の左上にある「Install Local Endpoint」をクリックします。

すると、以下のようにソフトウェアのURLが表示されます。URLの引数としてセキュリティトークンが与えられていることがわかります。「Copy link to Clipboard」をクリックして、このURLをコピーします。

ブラウザーにコピーしたURLを張り付けて実行すると、ソフトウェアがダウンロードされて以下のようにインストーラーの実行をするか否かを問われます（画面は IE9 です）ので、「実行」をクリックしてインストールを開始します。「保存」してから実行しても問題ありません。

実行すると、以下のように言語の選択画面が表示されますが、現在はプレビュー版のため「English」しかサポートされていません。このまま次に進んでください。

インストールは30秒程度で完了します。

インストールが完了すると、タスクトレイに Windows Azure Connect エンドポイントソフトウェアのアイコンが表示されます。まだ構成が完了していないため、黄色い「!」マークが表示されていることがわかります。

ここまでの作業をすべてのコンピュー��ーで行います。今回の構築例であれば、「自宅のPC]「お客様Aのサーバー」「お客様Bのサーバー」の3か所です。URLさえ知っていればインストールはできますので、メールにURLを張り付けてお客様に実行していただく...といったことも十分可能でしょう。なお、インストールした後は再起動してください。

② グループを構成する

Windows Azure ポータルで、「Virtual Network」をクリックしてください。

画面の左上に表示されている「Activated Endpoint」をクリックすると、エンドポイントソフトウェアがインストールされているコンピューターおよびロールインスタンスの一覧が表示されます。いまエンドポイントソフトウェアをインストールしたコンピューター、および先ほどWindows Azure 上に展開したロールインスタンスが表示しているか確認してください。もし表示されていない場合には、コンピューターを再起動してみてください。

表示されていることを確認したら、画面左上の「Create Group」をクリックします。

すると、以下のようなグループ作成用の画面が表示されます。

i. グループ名です。なんでもかまいません。

ii. グループの詳細です。適当にどうぞ。

iii. エンドポイントソフトウェアをインストールしたコンピュータの一覧から、このグループに所属させたいコンピューターを選択します。今回の例では「自宅」「企業A」「企業B」の3つのコンピューターをここに所属させます。ほかにも構成の方法はあるのですが、今回は最もシンプルな構成を選択しました。

iv. iii. で所属されたコンピューター間の通信を可能とするかどうかの設定です。チェックすると可能になりますが、今回はその必要は無いので、チェックしません。もし、「自宅」と「企業A」だけであれば、このチェックによって通信を可能にするという選択もありです。

v. グループに所属させるロールインスタンスを選択します。先の作業でアプリケーションをアップロードしたロールインスタンスを選択してください。

以上の設定を完了したら、それぞれのコンピューターにインストールされたエンドポイントソフトウェアを「リフレッシュ」して、構成データを最新の状態にします。リフレッシュするにはタスクトレイに表示されている、エンドポイントソフトウェアを右クリックして「Reflesh Policy」を選択します。

Reflash Policy を選択すると、以下のような画面が表示されます。Last Policy Update at .... を見て、構成ポリシーが最新の状態になったかどうかを確認してください。

ポリシーが適用されると、アイコンは以下のように表示されます。

以上ですべての設定が完了です。お疲れ様でした。

7. 使ってみる

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

① Windows Azure 上のロールインスタンスにリモートデスクトップでログオンする

Windows Azure ポータルを開き、画面の左下から「Hosted Services, Storage, Accounts & CDN」をクリックします。

画面左上から「Hosted Services」を選択し、先ほど作成したロールインスタンスを選択します。

ロールインスタンスを選択すると、画面の上部にある「Connect」ボタンが有効になるので、これをクリックします。

すると、rdpファイルを開くかどうかを問うダイアログが表示されるので、「ファイルを開く」をクリックします（以下の画面は IE9）。

これ以降は、もうおなじみの操作です。ダミーアプリケーションの作成時に設定した リモートデスクトップサービスの「ユーザーID」と「パスワード」を使用してログオンしてください。

以下はリモートデスクトップで「fumidai.cloudapp.net」に接続しようとしているところです。

うまく接続できれば、Azure 上に展開したインスタンスのデスクトップ画面が表示されます。

② ネットワーク構成を確認する

ロールインスタンスに接続できたら、DNS の構成が完了していることを確認します。

コマンドプロンプトを開いて、オンプレミス側（自宅、企業A、企業B）のそれぞれのコンピューターに ping をうってください。ping をうつ際のコンピューター名は、オンプレミスで使用しているママの名前で大丈夫です。以下のように、IPv6のアドレスに解決されて応答が帰ってくれば問題はありません。さほど早くはありませんが、おおむね 300 ms 程度で応答がかえってくるはずです。現時点では、データセンターをアジアにした場合、応答時間は 600～800ms 程度に増えてしまいます。

③ リモートデスクトップでオンプレミスに入り込む

名前解決が問題なければ、ロールインスタンス上で「mstsc」を起動し、オンプレミスに接続してみてください。

あ、もちろん、オンプレミスではリモートデスクトップの接続を許可しておく必要があるので、この点は事前に行っておいてください。

以上です。

いかがでしょう？はじめはちょっと面倒ですが、慣れてしまえばどうってことないですよね？？

高価な VPN や KVM を導入しなくても、Windows Azure Connect を使用すると簡易的なメンテナンス経路を構築することができます。

是非とも活用してください。

このBLOGの趣旨からすると完全に「閑話」なのですが、せっかくなのでBLOGに残しておきたいと思います。

以下のような要件があったとしましょう。

• お客様にWORDで作成した案内状を印刷して送付したい。
• 案内状には、宛先ごとに異なる URL（会員番号等が含めたような） を張り付けたい。
• さらに、URL の QRコード も一緒に貼り付けたい

なんとなくありがちな要件ですよね。この要件をお金をかけずに実現しようとしてパッと思いつくのは、

• QRコードを生成するフリーのライブラリを使って、バッチファイルでQRコードイメージ（jpgファイルとか）を生成
• 作成したQRコードのイメージを WORD で差し込み印刷（または差し込みメール）

ってかんじじゃないかと思います。きっと Office の MVP の方あたりだと、もっとエレガントな方法が思いつくと思いますし、こうした案件に対応する専用の製品もあるはずなのですが、今回は小手先でなんとかしてみようかなと思います。ってことで、せっかくの休日なので遊んでみました。

■QRコードのイメージファイルを生成する

① まずはQRコードのｲﾒｰｼﾞファイルを作成してみる

QRコードのイメージファイルとは、ご想像通り、こんなものです。こいつを会員数分、事前に生成しておくわけですね。

とはいえ、QRコードの仕様なんて私は把握していませんし、たとえ仕様を読んだところで私のような人間には手に負えません。そこで、フリーのライブラリを探すことになるのですが、とても素晴らしいライブラリがありました。ご存知の方にとっては超有名なライブラリだと思うのですが..。その名も DotNetBarcode です。

【フリーソフト】高機能でカラフルなQRコード(二次元バーコード)がデザインできる ColorfulQRCodeMaker/高性能バーコード・ライブラリー DotNetBarcode公式ホームページ

他に、Open Source QRCode Livrary などの選択肢はありますし、商用のライブラリももちろん販売されていますが、今回は DotNetBarcode にお世話になろうと思います。いかんせん、私のような非DEVにもとてもやさしい仕様で、サンプルプログラムや仕様書もきっちり用意されていました。作者様、本当にありがとうございます。

さて、早速上記サイトの「ダウンロード」から、DotNetBarcode V2.4.0 をダウンロードしてください。

ZIPファイルを解凍すると、中に以下のファイルが含まれています。

• CsharpSample [DIR]
• VBSample [DIR]
• 【始めにお読みください】.txt ← ライセンスに関する情報等、必ず読んでから使用してください！
• 【DotNetBarcodeV2.4.0での機能強化点】.txt
• DotNetBarcode.dll ← ライブラリ本体
• DotNetBarcodeクラスライブラリ(DotNetBarcode.dll)の仕様書.doc
• DotNetBarcodeクラスライブラリ(DotNetBarcode.dll)の仕様書.pdf
• DotNetBarcodeクラスライブラリを使ったQRコードアプリの作り方.doc
• DotNetBarcodeクラスライブラリを使ったQRコードアプリの作り方.pdf
• サンプルアプリケーション画面.doc
• サンプルアプリケーション画面.pdf

【始めにお読みください】.txt を必ず一読しライセンス等に関する情報を理解してください。また、あくまでもフリーソフトとして公開されていますので、その点をご理解した上でご使用ください。

理解できたら、DotNetBarcode.dll ファイルを適当な場所にコピーしましょう。

当然のことながら DLL は C# や VB.NET などからアクセスできるのですが、今回は IT Pro らしく PowerShell から使用してみましょう。

以下のようなスクリプトファイルを作成し、拡張子 ps1 で保存しましょう。今回は qrcodegen.ps1 という名前で保存しました。

[System.Reflection.Assembly]::LoadFile("c:\tmp\qrcodegen\DotNetBarcode.dll") $bc = New-Object DotNetBarcode $bc.Type = "QRCode" $bc.PrintCheckDigitChar = $true $bc.Save("http://blogs.technet.com/junichia/" , "c:\tmp\junichia.jpg", 150, 150)

1行目と2行目は、PowerShell からシステムに登録されていない DLL を使用する場合の常套句です。覚えておくと便利です。LoadFile の引数には、コピーした DotNetBarcode.dll ファイルのパスを指定しています。

DotNetBarcode では、さまざまな種類のバーコードを生成することができるのですが、今回は QRコードを作成したいので、3行目でバーコードタイプを QRCODE としています。また、4行目では、QRCODE のチェックディジットもバーコード上に表示することを指定しています。既定では False です。

そして 5行目の Save() メソッド！これがとても便利です。引数は以下の通りです。

Save(<バーコードに表示する文字列>, <保存するファイル名>, <QRコードの横幅>, <QRコードの高さ>)

今回は、文字列として上記のようにURLを指定し、それを junichia.jpg というJEPGファイルで保存するように指定しました。今回は正方形のQRコードなので、「横幅」と「高さ」については値の小さいほうが一辺の長さとして採用されるようです。詳細は「DotNetBarcodeクラスライブラリ(DotNetBarcode.dll)の仕様書.pdf」をご覧ください。

このスクリプトで作成されたQRコードが以下の通りです。携帯電話などQRコードリーダーをお持ちの方は試してみてください。私のBLOGのURLが読み込めるはずです。

ここまでできたら、あとは簡単ですよね。

EXCEL か何かでユーザーリストを作成し、その情報を繰り返し読みこんで QRコードをバッチ的に作成すればよいわけです。

② ユーザーリストからQRコードを一括作成する

今回は、ユーザーリストが以下のように EXCEL で用意されているものとします。ここではファイル名を userlist.xlsx とします。

※この EXCEL ファイルは、WORD の差し込み印刷でも使用します。

上記の EXCELファイルを読み込み、BLOG サイトの URL を QRコード で生成する PoewrShell スクリプトを作成しましょう。

...ということで作成したのが以下です。冒頭の3行には以下を指定していますので適宜変更してください。

• $UserList ： ユーザーリストが保存されているファイルのフルパス
• $JpgPath ： 作成したQRコードのイメージファイル（JPEGファイル）を保存するパス
• $DLLPath ： DotNetBarcode.dll が保存してあるパス

$UserList ="c:\tmp\userlist.xlsx" $JpgPath = "c:\tmp\img" $DLLPath = "c:\tmp\qrcodegen\DotNetBarcode.dll" $objExcel = New-Object -ComObject Excel.Application $objWB = $objExcel.workbooks.open($UserList) $objWS = $objWB.Worksheets.Item(1) $intRow = 2 [System.Reflection.Assembly]::LoadFile( $DLLPath ) $bc = New-Object DotNetBarcode $bc.Type = "QRCode" $bc.PrintCheckDigitChar = $true $dirExist = Test-Path $JpgPath If ($dirExist -eq $false) {New-Item -type directory -path $JpgPath} Do {     $UserName = $objWS.Cells.Item($intRow, 1).Value()     $FirstName = $objWS.Cells.Item($intRow,2).Value()     $LastName = $objWS.Cells.Item($intRow,3).Value()     $BlogSite = $objWS.Cells.Item($intRow, 4).Value()         "http://blogs." + $BlogSite + ".com/" + $UserName     $jpgpath + "\" + $UserName + ".jpg"         $bc.Save("http://blogs." + $BlogSite + ".com/" + $UserName + "/" ,$jpgpath + "\" + $UserName + ".jpg" , 150, 150)     $UserName = ""     $FirstName = ""     $LastName = ""     $BlogSite = ""         $intRow++ } While ($objWS.Cells.Item($intRow,1).Value() -ne $null)   $objExcel.Quit()

このスクリプトを実行すると、以下のようにユーザーごとにQRコードが作成されます。

お手元の携帯等で読み取って確認してみてください。

それはそうと、やはり、junichia.jpg にそこはかとない気品が感じられます。そして、kazunorn.jpg からは、あまり更新していない様子がうかがえます。

次回は個々で作成したJPGファイルを使用して、WORDで差し込み印刷してみます。

次へ（【PowerShell & WORD】QRコードを差し込み印刷してみる 2/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割くらい把握できたんじゃないかなと思います。

リモートデスクトップサービス（旧 ターミナルサービス）が Windows Server（Windows NT）に実装されてから、もう15年位でしょうかねぇ。その機能はOSのバージョンアップのたびに強化され、気が付けばサウンドカードやグラフィックカードなど、ローカルデバイスを利用できるようにまでなりました。個人的にはローカルドライブをリダイレクトできる機能がお気に入りです。遠隔地にあるサーバーと簡単にデータ交換ができるようになりました。

RDP ファイルとは「Remote Desktop Protocol ファイル」のことで、リモートデスクトップサービスに接続するための定義が書かれたテキストファイルです。mstsc（リモートデスクトップクライアント）を起動すると「保存」「名前を付けて保存」というボタンが目につきますが、このボタンで保存したファイルがRDPファイルです。中身はテキストですので、メモ帳で編集することも可能です。

ご存知の通り、Windows Azure に展開したインスタンスにもリモートデスクトップで入り込むことができます。

• 【Azure for ITPro】Widnows Azure にリモートデスクトップで入り込むための手順 (1)
• 【Azure for ITPro】Widnows Azure にリモートデスクトップで入り込むための手順 (2)
• 【Azure for ITPro】Widnows Azure にリモートデスクトップで入り込むための手順 (3)
• 【Azure for ITPro】Widnows Azure にリモートデスクトップで入り込むための手順 (4) 最終回

ここで、気になることがあります。それは、

Windows Auzre 上の インスタンスって、RDPファイル内でどうやって識別されているの？

ってことです。

以下をご覧ください。Windows Azure ポータルから「VMRole1_IN_0」というインスタンスにリモートデスクトップで入り込もうとしているところですが、ログオン画面に表示されているのはサービスの URL だけで、この画面からは変更することができません。これだけ見るとどうやって、「VMRole1_IN_0」と「「VMRole1_IN_1」が識別されているのかが不思議です。

そこで、RDPファイルを一度保存して、メモ帳で中身を見てみましょう。

RDPファイルの中身は、基本的に1行1設定であり、コロン（:）で区切られた3つのカラムから構成されています。

<設定名>:<値の型>:<値>

1行目は full address という設定名に、値の型が文字列（s）で、vmroletestjunichia01.cloudapp.net という値が設定されています。vmroletestjunichia01.cloudapp.net は私が展開したサービスのURLですが、これだけではインスタンスは一意に決められません。なぜならばサービスは複数のインスタンスで構成されている場合がほとんどだからです。上の画面でも、2つのインスタンスが展開されていることがわかります。

じゃ、そのインスタンスを特定している設定はどれか...一目瞭然、3行目です。

LoadBalanceInfo:s:=Cookie: mstshashVMRole1#VMRole1_IN_0#Microsoft.WindowsAzure.Plugins.RemoteAccess.Rdp

マイクロソフトの VDI に詳しい方だと、似たような設定を見たことがあるかもしれません。VDI の場合、あらかじめ決められた特定のサーバーに接続するのではなく、複数のサーバーを保持しているサーバープールから、空いているサーバー1つ選択して接続する必要があります。そのような場合には、full address  設定に加えて、以下のような設定が使われます。これは、VMFarm という仮装デスクトップのプールから空いているデスクトップを探し出してリダイレクトするための設定です。もちろんこの仕組みの裏には、セッション管理を行ってくれるセッションブローカー等のサーバーが待機しており、そららの緻密な連携によって実現されています。

LoadBalanceInfo:s:tsv://vmresource.1.VMFarm

この値は、リモートデスクトッププロトコル（RDP）を使用してセッションを確立する前に、コネクションリクエストの一部として送信されます。

では、Windows Azure 場合には、この設定ファイルはどのような意味を持っているのでしょう。なんとなく、ロールインスタンスの名前が指定されていることはわかりますよね。

LoadBalanceInfo:s:Cookie は、クッキータイプの文字列を使用して特定RDPクライアントに対するコネクションリクエスト（X.224 Connection Request）を送付します。

このクッキーの中で使用される値の名前が「mstshash」です。mstshash には、

VMRole1#VMRole1_IN_0#Microsoft.WindowsAzure.Plugins.RemoteAccess.Rdp

という値が格納されます。ちなみに、上の画面ショットをご覧いただければお分かりの通り、「VMRole1」はロールの名前で、「VMRole1_IN_0」はインスタンス名です。2つ目のインスタンスに接続したい場合には、以下のように指定すればよいだけです。

VMRole1#VMRole1_IN_1#Microsoft.WindowsAzure.Plugins.RemoteAccess.Rdp

この文字列が full address で設定したホスト（この例では vmroletestjunichia01.cloudapp.net）に送信され、接続のやり取りが開始されます。

vmroletestjunichia01.cloudapp.net がクッキーを受け入れると、mstsc は vmroletestjunichia01.cloudapp.net との TLS コネクションを張ろうとします。これに対して vmroletestjunichia01.cloudapp.net は VMRole1_IN_0 の X.509 証明書を送付するなどのやり取りが行われて、TLSコネクションが確立します。

これらのやり取りをキャプチャしたのが以下の画面です。

Windows Azure の中が、どのようなリモートデスクトップ構成になっているのかはハッキリとは見えないのですが、ひとまず vmroletestjunichia01.cloudapp.net がコネクションブローカーのように見えますね。

SQL Server をクラウドに移行する方法はいくつか用意されています。

「SQL Server Management Studio を使用して、移行したいデータベースを SQL Azure の仕様に合わせてスクリプト化する」というのも有効な方法ですが、もっと簡単に使用できるツールがあります。それが 「SQL Azure 移行ウィザード（SQL Azure Migration Wizard）」です。

このツールは CodePlex というオープンソースプロジェクトで提供されており、もともと英語版のみでした。非常に使いやすいツールなので、心から日本語化を願っていたのですが、2011年1月に SQL Azure MVP の 大和屋（やまとや）さんにより日本語化が実現されました。現時点の最新バージョンは 3.6 です。

日本語対応したSQL Azure Migration Wizard v3.5.2 リリース
http://sqlazure.jp/b/sqlazure/426/

さて、そうなるとドキュメントはどうなの？という話になるのですが、何とつい先日、日本語版のドキュメントもリリースされました。もちろんドキュメントも V3.6 に対応しています。これも大和屋さんのご尽力によるものです。

さぁ、これで駒はそろいました！あとは実践あるのみです！

sqlazuremw - Release: SQL Azure Migration Wizard v3.6