「何度試しても、リモートデスクトップでEC2のインスタンスにログインできないのだけど・・・」と相談を受けました。

私： パスワードに記号が含まれてない？
私： キーボードの設定が英語版になっていて、日本語のキーボードだと記号の位置が違う場合があるよ。
私： まずは、ユーザー名の入力欄にパスワードを打ち込んで確認してみたら？

相談者： あぁ、本当だ！ ログインできました！

こういうことが、たまにあります。
質問者は随分時間を無駄にしたそうです。

「英語版のWindowsの場合、このようなことがありうる」という知識や経験がないと、なかなか思いつけないのでしょうね。

ただ、ITのプロフェッショナルなら、「ユーザー名の入力欄に打ち込んで確認してみる」ということは、すぐに思いつけなければなりません。

正直に書くと、今回の質問者はうちのスタッフです。

引き続き粘り強く指導して参ります。

とあるプロジェクトで、AWS EC2 を利用し Windows 2003 ＋ SQL Server 2005 Standard Edtion を用意することになりました。

古いバージョンのOSイメージはAMIイメージから探すわけですが、公開されている情報を見るだけでは、実際の中身がよくわからない場合があります。

今回は該当しそうなAMIイメージが2つあり、それぞれインスタンスを立ち上げ、中身を確認してみることにしました。

まず一つ目はこれ。

AMI ID: ami-f218aef3
AMI Name: Windows_Server-2003-R2_SP2-Language_Packs-64Bit-SQL_2005_Standard-2012.02.24
Description: Microsoft Windows Server 2003 R2 SP2 Datacenter 64-bit with SQL 2005 Standard Multi-Language AMI provided by Amazon
Source: amazon/Windows_Server-2003-R2_SP2-Language_Packs-64Bit-SQL_2005_Standard-2012.02.24
Owner: amazon (801119661308)    Visibility: Public    Product Code:
State: available    Kernel ID: -    RAM Disk ID: -
Image Type: machine    Architecture: x86_64    Platform: Windows
Root Device Type: ebs    Root Device: /dev/sda1    Image Size: 30 GiB
Block Devices: /dev/sda1=snap-148f2879:30:true
Virtualization: hvm

これだけの情報で大体はわかります。
2012/2/24に公開されたばかりのAMIイメージですね。

OSのデフォルトの言語(ユーザインタフェースの言語)は英語です。

インスタンスを起動し、まずはSQLサーバーのバージョンを確認してみました。

SELECT  SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')
の結果は次の通りでした。

productversion  productlevel  edition
9.00.5057.00    SP4    Standard Edition (64-bit)

SP4が適用されていますね。

SQL ServerのStandard Editionは64-bit版しか提供されていないようですが、やはりそうでした。
(Express Edtionの32-bit版がインストールされているイメージは存在しますが)

こちらのイメージの場合、インスタンスを作成する際、Microが選択できました。
SQL Server のStandard Edtionを利用する場合はLarge以上でなければいけないはずですが、これは知りませんでした。

次に試したイメージはこちら。

AMI ID: ami-5808a359
AMI Name: JA-SqlSvrStd2003r2-x86_64-Win-v1.03
Description: -
Source: ec2-public-windows-images-ap-northeast-1/JA-SqlSvrStd2003r2-x86_64-Win-v1.03.manifest.xml
Owner: amazon (206029621532)    Visibility: Public    Product Code:
State: available    Kernel ID: -    RAM Disk ID: -
Image Type: machine    Architecture: x86_64    Platform: Windows
Root Device Type: instance store    Root Device: -    Image Size: 0 bytes
Block Devices: N/A - Instance Store
Virtualization: hvm

この情報だけでは、SQL Serverのバージョンがわかりません。困ったものです。

先程と同じSQL文を実行した結果は次の通りです。

productversion productlevel edition
9.00.1406.00    RTM    Standard Edition (64-bit)

必要なSPを自分でインストールする必要がありますね。

ちなみに、こちらのOSのデフォルトの言語は日本語でした。

そして、インスタンスを作成する際には、Large以上しか選択ができませんでした。

両者の比較表もついでに作っておきましょう。

これらの情報が誰かの時間を節約できますように。

残念ながら日曜日の早朝から発生しているメール配信トラブルが収束しないので、自力で何とかすることにしました。

すでに、皆様からいただいたメールは正しく配信されるようになっております。
ご迷惑とご心配をおかけしまして、誠に申し訳ございませんでした。

MSのサポートによれば、初めての事例のため、国内では対応しきれず専任チーム（米国）にエスカレートされたようです。
ただ「解決までには1週間以上かかるかもしれない」とのことでした。

電話応対などは丁寧かつ真摯で好印象ですが、重大な問題の解決に時間がかかると言うのは非常に残念です。

さて、他に参考になる人がいるかどうかはわかりませんが、簡単に今回起こったことや自力での対処方法（まだ途中ですが）を書いておきます。

■ 発生している事象

• BPOSからOffice 365への移行が行われたが、それ以降ほぼすべてのメール受信ができなくなった
• 送信者および自分に、以下のような「エラーメッセージ」が、その都度送られる（一部加工してあります）
• 数十通に1通程度の割合で、問題なく配信される場合もある
• 問題が発生したのは、ドメイン内のユーザーのうち1名のみ

■ エラーメッセージ（一部）

次の受信者またはグループへの配信に失敗しました:

'Taro Yamada' (taro@mydomain.com)
受信者のメールボックスに問題があります。メッセージを再送信してください。問題が引き続き発生する場合は、ヘルプデスクに問い合わせてください。

管理者向けの診断情報:

生成サーバー: mydomain.onmicrosoft.com

taro@mydomain.com
#554 5.2.0 STOREDRV.Deliver.Exception:StoragePermanentException.MapiExceptionWrongProvisionedFid; Failed to process message due to a permanent exception with message Cannot complete delivery-time processing. 16.55847:53150000, 17.43559:00000000B6020000000000000F00000000000000, 255.23226:2B0A0000, 255.27962:0A000000, 255.27962:0E000000, 255.27962:0A000000, 255.27962:9E000000, 255.17082:8E0A0000, 0.18273:00000000, 4.21921:8E0A0000, 255.27962:FA000000, 255.1494:2C000000, 255.1238:0F010480, 4.4353:0F010480, 1.27420:0B00060C, 1.36537:0B00060C, 6.5587:0F0104800B00060C0F010480, 4.33375:0F010480, 6.21970:0F01048003002D670201C265, 6.21970:0F01048003002D670F010480, 6.21970:0F01048003002D670300E965, 0.33261:0F010480, 4.1179:8E0A0000, 4.6167:8E0A0000, 0.61527:0201F065, 4.5041:8E0A0000, 4.4465:8E0A0000, 4.6833:8E0A0000, 0.50217:0300F165, 4.5093:8E0A0000, 4.5318:8E0A0000, 4.10104:8E0A0000, 1.64937:F7D80800, 1.43123:3AE33506, 4.60457:0F010480, 4.4353:0F010480, 0.57449:0300F365, 4.6025:05000780, 4.5257:05000780, 4.4606:8E0A0000, 255.1750:00000000, 0.26849:2D000000, 255.21817:8E0A0000 ##

■ 自力で行なっている回避策

• 問題の生じているメールボックスの名前を変更 例: taro@mydomain.com –> old.taro@mydomain.com
• 新たに元の名前でメールボックスを作成 taro@mydomain.com
  → この時点で新しいメールボックスに社外からのメールが届き始める
• 配布グループ内のメンバーを調整 (old.taro@mydomain.com を削除し taro@mydomain.com)
• OWAでから社内の関係者に新しいメールボックスからメールを送信
• 新規のメールはそのメールに返信するよう依頼（GALが更新されていないため、古い方に配信されるのを避けるため）
• Outlookの設定。「Office 365 desktop setup」ではエラーが発生し、うまく出来なかったため、以下のサイトを参考にしながら手動設定。
  http://blog.valueengine.jp/?p=203

このあとは、古い方のメールボックスから、カレンダーのデータや必要な過去のメールをExport / Import したり、振り分けの設定をしなければなりません。

やれやれ・・・

この週末に弊社のメールシステム他がBPOSからOffice 365へ移行されました。

ところが、私のメールボックスのみうまく移行が完了していません。

今朝(1/29)の6:04以降に送信されたメールには、「配信に失敗した」というエラーメールが自動的に返送されてしまっています。

お客様ならびにお取引先の皆様にはご心配をおかけしまして誠に申し訳ございません。

なお、従来より万一の場合に備え、受信したメールがgmailに自動転送される設定にしてあります。

そちらは、現在も想定通りに稼働しているようですので、お送りいただいたメールは確認することができています。

休日にもかかわらず、Microsoftサポートのご担当者が熱心に対応してくださっていますので、問題の解消までにはそれほど時間がかからないのではと思っております。

取り急ぎ、お詫びと状況の報告をさせて頂きます。

-----

そういえば、サポートの電話番号を見つけるのに少し時間がかかりました。

http://onlinehelp.microsoft.com/ja-jp/office365-enterprises/ff637572.aspx

http://snow-white.cocolog-nifty.com/first/2011/12/microsoft-offic.html

この二つのサイトの情報がとても役に立ちました。

そして、電話番号がわかってから、その番号で検索したら以下のページがヒットしました。

http://technet.microsoft.com/ja-jp/library/cc742651.aspx

日曜日でも日本語でちゃんとご対応いただけました。

近畿大学の教授がクラウドについての実態調査をされています。

先日アンケートに回答をしたところ、調査会社から連絡があり、本日インタビューを受けました。

全体的には保守的な回答が多く、当社のクラウドに対する積極的な姿勢が、比較的珍しいとのことです。

以下のようなことを理由に、クラウドを利用したシステムやサービスの開発に躊躇している企業が非常に多いとの事でした。

• クラウドは一過性のブームと思う
• 自分たちの技術力では参入は難しい
• 先行して参入した会社が市場を押さえているので、難しい
• 売上げが下がってしまうのでメリットを感じない
• セキュリティが不安

「『クラウド、クラウドってあんまり騒がないでくれ！私たちも困っているのだから』とアンケートの回答用紙に書いてくる方もいるのです。」との話には、思わずニヤリとしてしまいました。

どうやら、環境の変化から目をそらし、現状維持で行きたいと考えている企業が少なくないようです。

天の邪鬼な性格の私には、他の経営者が保守的であればあるほど、今の状況がチャンスに思えてきます。

Prospex では Microsoft のクラウド “Windows Azure” を利用したシステム開発のご相談をいつでも受けられるよう、すべてのエンジニアが日夜研鑽に励んでおります。

Windows Azure Tips from Prospex

マイクロソフトの徳増様から Microsoft Data Center の説明ビデオがあることを教えてもらった。

http://www.microsoft.com/showcase/en/us/details/36db4da6-8777-431e-aefb-316ccbb63e4e

http://www.microsoft.com/showcase/en/us/details/84f44749-1343-4467-8012-9c70ef77981c

これまでに得ていた情報から想像していた通りだが、より詳細に理解できて面白い。

別に聞いたところによれば、「故障率がある一定の閾値に達したら、コンテナごと捨てる」ことなどが予め決められているらしい。
また、徹底的なオペレーションの自動化が実現されており、一人のオペレータが担当できるサーバー数が通常のデータセンターと比較して、二桁ほど多いとのこと。

単純作業の繰り返しや、正確さやスピードの要求されるものを、システムや機械に任せて自動化する流れは、今後益々拡大してゆくだろう。

そして、そのような流れに乗るか、自分たちが流れを作るかをした者たちだけが生き残るだろう。

一方で「コンピュータが人間に反旗を翻す」という未来を描いた映画が作られたりしているが、今のテクノロジーのレベルから考えれば、まだまだ杞憂に過ぎない。

システムや機械にできることはドンドン自動化し、人間はより高度な仕事に集中できる時間を確保すべきだと思う。

例えば、「企画」の仕事などがそうだろう。
そして、人との出会いや繋がりのなかから新しい未来への希望を見出してゆくことなどは、人間にしか出来ない。

データセンターのビデオの話が大きくなりすぎたかな。

http://itpro.nikkeibp.co.jp/article/NEWS/20110121/356336/

AWS Elastic Beanstalkは、ユーザーがアップロードしたJavaプログラムを稼働させるのに必要な仮想マシンやロードバランサー、Webアプリケーションサーバー「Tomcat」、Webサーバー「Apache」などを、ユーザーに代わって同社が設定し、仮想マシン貸しサービスの「Amazon EC2」上に展開するというサービスである。

同社はAWS Elastic BeanstalkをPaaSであると明言してはいないが、米グーグルの「Google App Engine」や米マイクロソフトの「Windows Azure」、米セールスフォース・ドットコムと米ヴイエムウェアが提携して開始する予定の「VMforce」などに競合するサービスと言える。

クラウド戦国時代の行方は予断を許さないが、Prospex はとことん Azure で勝負しよう。