今日はWindows Azure Connectなんぞをネタにしようと思います。
さてWindows Azure Connectとは？というところなんですが、よく考えるとあまり取り上げてなかった気がしますね。
ぶっちゃけていうと、クライアントコンピューターとWindows AzureのホストサービスをVPN（IPSec）で結んであたかも直接通信ができるようにトンネリング接続してくれる機能のことを指します。
IPSec接続にはクライアントからOutbound TCP/443ポート（HTTPS）だけ開いていればいいので、ネットワーク要件としてはファイアウォールの設定変更も大半のケースでは不要ですし、使い勝手は良さそうです。が。
@IT にWindows Azure SDK 1.3の新機能（後編）が掲載されました。
特集：Windows Azure SDK 1.3の新機能（後編） – すべてが自由自在なクラウド環境「仮想マシン・ロール」
3部作の最後ですね。過去の記事はこちら↓
おいらは詳しく知らないのですが、グランドトップになったようです。
今回も編集の方含め多数の方に感謝！！
@ITの記事ものはこれで終わりです。いろいろ勉強になりました。ほんと。
Windows Azure SDK 1.3 の機能であるFull IISを利用してWeb Roleを展開すると、Web.configに明示的に指定してたMachineKeyが Windows Azure上に配置後上書きされる問題があります。（※Hosted Web Coreを利用する場合は問題ないようです）
この問題に対する回避策はSteve Marxが回答していますが、MSDNのIssueにあるようにRoleEnvironmentのOnStart等で明示的に書き換えてあげる必要があるようです。
@ITに記事が掲載されました。
特集：Windows Azure SDK 1.3の新機能（中編）
Windows Azure実行環境へのリモート・デスクトップ接続
毎度ながら編集の方に感謝。皆様にも感謝。
なんか需要があるとかないとか…
ASP.NET MVC3がやっとRTMになりました。（RTWじゃなくてRTMなんですね）
さて例によって Windows Azure 上でASP.NET MVC3を使おうとすると、アセンブリ参照をごそごそ追加してローカルコピーをTrueにしないといけないわけです。
※詳しくは 割と普通 さんの 記事「ASP.NET MVC3 RTMをWindows Azureで動かす！！～懇切丁寧な解説付き～」を参照ください
Windows Azure ホステッドサービスでSSL（HTTPS）したい場合のTipsです。
※Windows Azure SDK 1.3前提です。
今日はちょっとした実験の元ネタです。
Windows Azureのホステッドサービスは通常「xxx.cloudapp.net」なホスト名で提供されますが、ドメイン名は独自のでサービス提供したい！とか要望あるかと思います。
VM Roleで利用するOSイメージ作成時にSysprepを使用して配布準備を行うのですが、この時にSysprepが動作しない現象があるようです。（以前の投稿でも少しふれました）
その時は再現しなかったのですが、再現したので現象メモ。
Hyper-Vの環境によってはWindows Azure統合コンポーネントをインストールしてもDHCPからIPアドレス取得できたり、Sysprep時に問題ないケースもあるのですが、なんかDHCPからちゃんとIP取れなかったりでネットワーク接続で警告が出たりしてるとSysprepが起動しきれない？
もし同じ現象が出た方はネットワークまわり見てみるといいのかも…
いまいち状況が把握しきれていないので違うかもしれません。あしからず。
ブチザッキ 