Windows Azure SDK 1.3 を使用してFull IISなWeb RoleをWindows Azure上に展開した際、Web.configに指定していたMachineKeyが上書きされる（IISによって自動設定される）という問題がありました。
※ただし最初の仮想サイトのみ。追加した仮想サイトや仮想アプリケーションは影響受けない（だったと思う）
さて、こちらの問題ですがこの間リリースされた Windows Azure SDK 1.4 では修正されているので、困ってた方はSDK 1.4を採用することも検討頂くといいのではないでしょうか。
他の問題もいろいろ修正されてるようですし。。。
ただまぁSDK1.2 以降でがらっと変わってる部分もあるので一概にOKとは言えないかもしれませんが。
前回Squidを利用してキャッシュ・リバースプロキシサーバーを構築しましたが、Squid版では以下の問題がありました。
これらはURLのRewriteをリバースプロキシな処理の中で行えば解決しますが、外部公開サイトに対してはいろいろグレー＋Squidだと少し面倒でした。
さて代替方法として（緊急で対応する必要もだいぶ減ったので）IIS＋Application Request Routing 2.0を使用してキャッシュ、リバースプロキシ、URL Rewriteを行いたいと思います。
※今回実装にあたってはMicrosoftさんを始めJAZUな面々、多数の方にご協力頂きました。ありがとうございます。
デプロイパッケージを作成するにあたって実装している点は以下の通りです。
コードはやっつけ仕事もいいとこですね。
成果物はこちらからダウンロードください。
利用方法は上記パッケージをダウンロードしてDeployPackageフォルダにある .cscfg のインスタンス数や対象URL、公開URLを修正してデプロイするだけです。
今は1：1の書き換えしか対応できません。もし1つのサーバーで複数展開する場合は現状のコードでは対応できませんので、RDPの設定をして頂き、展開後手動でIIS+ARRの設定を行ってください。
非常時用ですのでこんな感じです。
CDNを利用する場合や、より細かな対応、本格的にAzure化する為にコンテンツホルダーとの調整が必要な場合等は こちらのサイト を参考にして頂き、Microsoftさんへコンタクトを取っていただくのもよいと思います。
3月11日、東北地方太平洋沖地震が発生しました。私のほうではうまく表現できません。ただ心より祈るばかりです。
とはいっても、できることはないだろうか？と漠然と思っていたところ、日本赤十字社のサイトが過負荷で見えない、という話題が流れていました。
ぱっと思いついたのはとりあえずキャッシュサーバーとリバースプロキシを組み合わせて負荷を軽減できないか？ということでした。
幸い、リソースはWindows Azureですぐに展開できますし、SquidとDelegateは少し触ったことがあったので @halmnm を巻き込んでSquidを構築することに決めました。
並行してMicrosoftさんがAzure Passの９０日無償開放、4インスタンス、転送量無制限という臨時仕様で解放してくれました。ありがとうございます。
タイトルはホッテントリメーカーで生成しました。内容とはあまり関係ないと思われます。
さてWindows Azure CDNが新しくなったので、試してみました。
目玉としては、
だと思うので（QueryStringでどうのこうのもありそうですが検証が大変そうなので今回は置いておきます）、それぞれ見てみようと思います。
ということでWindows Azure SDK 1.4がリリースされました。
変更点等現時点で気づいた点を列挙しておきます。
前回の続きです。前回はこちら → Azure AppFabric ACS v1+ADFS+WCF Data Services
今回は実際にフェデレーション認証を利用するサービスとクライアントを作成します。
サービス側はWCF Data Servicesを利用して、トークンが有効な場合のみデータ（Entity）を返すようにします。
クライアントはActive Federation認証を行いますので、ADFS2.0とACSv1を使用し得られたトークンと利用してWCF Data Servicesにアクセスしデータを取得します。
ではまずサービス側から。
今日はWindows Azure AppFabric Access Controle Service v1 （現行）（以下ACSv1）とActive Directory Federation Services 2.0 （以下ADFS）を組み合わせてWCF Data ServicesをActive Federation認証してみようと思います。
WCF Data Servicesを利用するクライアントは今回はブラウザではなく、Windowsアプリとします。なのでブラウザが自動リダイレクトして認証画面に飛ぶようなPassive Federation認証ではなくActive Federation認証です。（自前でトークンのやり取りします）
そもそも、現行のACSv1はPassive Federationに対応していませんし、マルチテナントを考えるとちょっとWindows Identity Foundation（以下WIF）についてるFederation Utilityは使えないのでほぼコードでいろいろ制御することにします。
はっきりいって、ACSv2が出るまでのつなぎですね。ちなみに今回のネタはWIF トレーニングキットに付属するハンズオンラボ（IntroAppFabricAccessControl）を見ながらやればある程度できると思います。
今回想定している環境はこんな感じです。
※見ての通り（？）、WCF Data ServicesとSQL ServerはWindows Azure＋SQL Azureでもまったく問題ありません。
では準備から。
今日は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等で明示的に書き換えてあげる必要があるようです。
