Azure

マイクロソフトを装った不審メールの配信について | News Center Japan 1 user 2017年1月11日深夜より、マイクロソフトを装った『ご注意！！OFFICEのプロダクトキーが不正コピーされています。』という件名の不審メールが、不特定多数のお客様に断続的に配信されています。 このメールはマイクロソフトから配信したものではなく、記載されている内容は… news.microsoft.com - テクノロジー - あとで読む - [](http://b.hatena.ne.jp/ebibibi/)ebibibi w, microsoft, spam, b 26 clicks 2017/01/13 - VMs で使っていた VHD が消せない場合の対処方法 at SE の雑記2 users Windows Azure の Virtual Machines (VMs) で仮想マシンのインスタンスは存在していないのですが、インスタンスで使用していたディスク (VHD) が削除できないという状態になってしまいました。 # VMs が使用できるようになった時に… blog.engineer-memo.com - テクノロジー - あとで読む - [](http://b.hatena.ne.jp/ebibibi/)ebibibi w, azure, vhd, b 27 clicks 2017/01/13 ...

仕事で最近Azure EAポータルに触ることが多いので自分用のメモを書き残しておきます。 そもそもAzure EAポータルにはアクセスしたこともなければその必要すらない人がほとんどだとは思います。だからこそ情報が少なく初めのとっかかりが難しく感じましたので、記録を…。 - Azure EAポータルはAzureをEA契約で購入した際に、その課金管理やサブスクリプションの作成等を行うところです。 - https://ea.azure.com - 一企業に閉じたものではなく、Azure EAライセンスを販売するLSP(License Splution Partner)から複数企業の末端のアカウントまで統一的に管理できる仕組みが備わっています。 - 権限は明確に階層化されています。(パートナー、企業、部門(部署)アカウント) - 通常の企業ユーザーは「企業(エンタープライズ)」以下の領域を管理します。 - 私はLSPにて働いているので「パートナー」レベルからの管理に関わります。普通に考えるとさらに上位にMicrosoftの管理レベルがあるのかもしれません。 - LSPレベルで「マークアップ」を行わないと企業レベルでは課金情報が確認できません。(マークアップ≒顧客に対しての利益or割引の利率を設定する操作) - 企業内では、エンタープライズ管理者かまそこから下位の管理者を設定していける。 - 部門(部署)を使う、使わないは任意 - アカウントを部署に割り当てる場合にはその対応は必ず1対1となる。後からの変更は自由に可能。 - アカウントに対してのアカウント管理者は自由に設定、変更可能。 - サブスクリプションのアカウント間での転送が可能。ただし、同一の組織アカウントに所属するアカウント間での移動でない場合には共同管理者設定は失われ、サブスクリプションに紐ずく規定のディレクトリも変更される。 - それぞれのアカウントは自分に権限のある場所しか見られない。 - 使用量のダウンロードはポータルからも実施可能だが、APIキーを生成してAPIを通じても可能。 - APIキーには半年間の期限がある。プライマリキーとセカンダリキーがあり、さらに任意のタイミングで再生成も可能。 - Power BIにはAzure Enterpriseという接続があり、EAポータルにて生成したAPIキーとエンロールメント番号だけわかればレポートの生成が可能。 - 料金は「マークアップ前」、「マークアップ後」があり、APIキー作成時にもその考慮が必要。(アカウントによってどちらかが決まる) - PowerBI利用時にはメールを使ったアクティブ化の処理が必要であり、そのため組織アカウントで、メールを受け取れる状況である必要がある。 (以下2016/06/20追記) - 実際の請求額はAzure EAポータルの「使用状況の概要」にて確認できる。 - 使用状況のダウンロードから「Azureサービス、個別請求の料金」と「Azure Marketplace」の詳細をダウンロードできる。 - しかし、Azure Marketplaceに関しては現時点では全量出力されていない模様。今後の改善が望まれる。 - 請求は四半期に一度、マネタリーコミットメントからの超過料金と個別請求の料金が1つの請求書で、Azure Marketplaceがまた別の請求書来る。 - 利用料金のポータルへの反映はオフィシャルには5営業日の時差がある。実際には2,3営業日で確定する模様。 - 「使用状況のダウンロード」にて「月単位レポートのダウンロード」としたときに、(現在6/19/2016)の用にでていることで何日までデータが確定しているかを確認可能(な模様) (以下2016/06/21追記) - 消費税に関して。請求書には明細ごとは税抜き価格、加えて税抜き合計、消費税合計、税込み価格合計が記載されている。

皆さんこんにちは。今回はAzure VMのv2, ARMにてカスタムのVMイメージを作成～展開する方法です。 v1の時には楽ちんだったのですが、現状(2016/05/06)だとポータルからの操作で完結しないのでちょっと手間に感じる方もいるかもしれないですね。今後も継続的に方法は変化すると思いますが、現時点の私のやり方を記録しておきます。 仮想マシン作成～構成 まずは、普通に仮想マシンを作成し、カスタマイズを行います。この部分の手順は省略します。 仮想マシンの準備 仮想マシンをカスタマイズしたら、テンプレート化するための準備を行います。具体的にはsysprepを実行します。PowerShellにて以下のコマンドを実行でOKです。 & “$Env:SystemRoot\system32\sysprep\sysprep.exe” /generalize /oobe /shutdown 結果、仮想マシンは仮想マシン内からのコマンドでシャットダウンされることになります。 仮想マシンイメージのキャプチャ 次に仮想マシンイメージのキャプチャですが、Resource Explorerからの実施が簡単だと思います。 - https://resources.azure.com/ Resource Explorer上で対象のVMにまで移動して… まず、deallocateを実行します。ポータル上で仮想マシンの状態の変化を確認しながら操作を行うのがおすすめです。 きちんと処理が完了したら次はgeneralizeを実行します。 これも完了したことを確認してから、次にcaptureを実行します。 この時には、パラメーターをきちんと入力してからの実行が必要です。 これを・・・、必要に応じて編集してからcaptureボタンを押します。(以下はあくまでも例です。) これによって、同一ストレージアカウント内のblogに、イメージがキャプチャされます。 「system」内に作成されます。 イメージからのデプロイ イメージからのデプロイに関しては、ポータルからは行えない…と思います。現時点では。(やり方知ってる人いたら教えて下さい。) 先に、NICとパブリックIPがある状況で、PowerShellを使って簡単にデプロイできるPowerShellスクリプトを作成したので共有しておきます。 スクリプトはGithubで公開しています。 - https://github.com/ebibibi/AzureManageCodes/blob/master/VMImage/CreateNewVMfromTemplate.ps1

皆さんこんばんは。胡田です。 Windowsをemacs風キーバインドにするxkeymacsを使い続けて…もう何年たったのかすら忘れました。Windows10ではちょっと動作が不安定な感じもありますが引き続き使いまくってます。 Caps Lockを右Ctrolキーにレジストリ変更で変更し、CapsキーをC-に割り当てて使っているのですが、Windows10のUpdateのたびにレジストリ設定がクリアされてしまって毎回レジストリ再設定&再起動をするのがとても面倒なのでDSCを使って自動的にレジストリ設定がなされるようにしました。PCを乗り換えることも多々あるので、PowerShellスクリプトを一発実行すれば、Azure上にAzure Automation DSCが構成されて、PowerShellスクリプトを実行したPCが自動的に登録されるようにしています。非常に快適です。 ソースコードはGitHubにあげてあります。 ebibibi/Windows10Config

Azureは従量課金ですので、課金データをきちんと管理する必要があります。ほおっておくとあっという間に課金額が増えてしまいますので…。 そんなわけで課金レポートを常時見られるようにしておくのが望ましいのです。課金レポートの実装方法には様々な方法がありますが…、私のお勧めはPowerBIのレポートを利用する方法です。EA契約限定ですが…。 Power BIのサンプルレポートの中に、AzureのEA契約用のレポートが用意されているので、これを使えば非常に簡単にAzureの課金レポートを作成できます。しかも無償でOKです。 このようなレポートが非常に簡単に作成出来ます。 しかも、Power BIですので、レポートの編集も簡単です。任意の形態でAzureの課金情報を確認可能となります。 個人的にはせっかくの標準機能ですので使わないのはもったいないと思っております。 ですが、様々な事情でPower BIを利用できないケースもあるかもしれません。(Azure EAがつかえるということは無償でAADも作れるわけで、AADアカウントがあればPowerBIも使えますから、本当は使えないケースは皆無に近いはずなのですが…。) そんな時にはEAポータルから使用量のデータを取得し、Excelで…というのもやり方によっては有りかと思います。そんな時には以下のPowerShellスクリプトが非常に便利です。 スクリプト Automatically Download Microsoft Azure Billing Reports (Enterprise Agreement) CSVファイルのダウンロード作業を簡単に自動化してくれます。

Azureサブスクリプションには「既定のディレクトリ」という概念があり、紐付いているAzure Active Directoryのユーザーを管理に使用することが出来ます。企業で利用する場合にはAzureの管理にマイクロソフトアカウントではなく、組織アカウントを使用することがセキュリティの観点から良いと思います。アカウント生成、削除、多要素認証の適用等適切に管理可能だからです。 以下では新規のAzureサブスクリプションに対してすでに存在しておりO365で使用しているAzure Active Directoryを既定のディレクトリとして紐付ける方法を紹介します。 まず、Azure管理ポータルにアクセスします。2016/04/07時点ではまだAzure Active Directory周りの管理操作はクラシックポータル上で行う必要があります。 https://manage.windowsazure.com/ 左ペインから「Active Directory」を選択した所です。サブスクリプション作成時に自動的に生成された「Default Directory」(※「規定のディレクトリ」の場合が多いと思います。)のみが見える状態になっています。 「設定」にて確認をするとサブスクリプションに対して、規定のディレクトリが紐付いていることが確認出来ます。 この規定のディレクトリを変更していきますが、変更するためには変更先のAzure Active Directoryの管理者として現在操作しているアカウントが権限をもっていなければいけません。別途O365の管理コンソールから操作することも可能ですし、場合によってはだれか別の人に管理者に追加してもらう必要がある場合もあるでしょう。 ここではひとつのやり方として、O365の全体管理者のアカウント(Azureの管理者とは別のアカウント)を自分自身が持っている前提で、Azure管理ポータル上の操作で権限追加まで行う方法を紹介します。 この場合まずAzure管理ポータル上のActive Directoryの一覧に、紐付ける先のAzure Active Directoryが表示される状態にします(これは必須ではありませんが一つのわかりやすいやり方です)。 このため、まず、O365で使用しているAzure Active Directoryへの接続を行います。 「Active Directory」にて「新規」をクリックします。 「ディレクトリ」をクリックします。 「カスタム作成」をクリックします。 「既存のディレクトリの使用」を選択します。 「 既存のディレクトリを使用するには、その前にユーザーがサインアウトし、ディレクトリの全体管理者としてもう一度サインインする必要があります。」と表示されます。 ここで混乱してしまう人が多いのですが、つまりこれはまず事前にアクセス権を付与するための操作です。 これからAzure管理ポータルにAzure Active Direcotryを追加してそれを管理しようとしていますが、そのためには、そのAzure Active Directory自体の全体管理者の権限が必要です。全体管理者の権限を付与するためには、その権限をすでに持っているアカウントで操作する必要があります。ですから、一度サインアウトして、別のアカウントで(この場合はO365の全体管理者で)サインインしなさいと言われているわけです。 チェックをつけて、次に進みます。 サインアウトされます。 サインイン画面になります。 ここではO365の全体管理者の権限を持つアカウントでサインインします。 サインインします。 権限付与する旨のメッセージが出ます。続行します。 権限が付与されました。サインアウトします。 Azureの管理者アカウントでサインインします。 O365で利用しているAzure Active Directoryが新しく追加されました。 これでAzureサブスクリプションの規定のディレクトリを変更する準備が整いました。 これからAzureサブスクリプションの規定のディレクトリを「Default Directory」から「ebisuda」に変更します。 「設定」に移動し、規定のディレクトリを変更する対象のサブスクリプションを選択した上で「ディレクトリの編集」をクリックします。 ...

欲しかったものが一発で手に入ったのでうれしくてポスト。 Get-AzureRoleSizeで、仮想マシンのサイズ一覧が手にはいります。 PS C:> Get-AzureRoleSize InstanceSize : A10RoleSizeLabel : A10 (8 cores, 57344 MB)Cores : 8MemoryInMb : 57344SupportedByWebWorkerRoles : TrueSupportedByVirtualMachines : TrueMaxDataDiskCount : 16WebWorkerResourceDiskSizeInMb : 1861268VirtualMachineResourceDiskSizeInMb : 391828OperationDescription : Get-AzureRoleSizeOperationId : 5919eb4d-96de-60d2-9149-caea24fef5caOperationStatus : Succeeded InstanceSize : A11RoleSizeLabel : A11 (16 cores, 114688 MB)Cores : 16MemoryInMb : 114688SupportedByWebWorkerRoles : TrueSupportedByVirtualMachines : TrueMaxDataDiskCount : 16WebWorkerResourceDiskSizeInMb : 1861268VirtualMachineResourceDiskSizeInMb : 391828OperationDescription : Get-AzureRoleSizeOperationId : 5919eb4d-96de-60d2-9149-caea24fef5caOperationStatus : Succeeded InstanceSize : A5RoleSizeLabel : A5 (2 cores, 14336 MB)Cores : 2MemoryInMb : 14336SupportedByWebWorkerRoles : TrueSupportedByVirtualMachines : TrueMaxDataDiskCount : 4WebWorkerResourceDiskSizeInMb : 501760VirtualMachineResourceDiskSizeInMb : 138240OperationDescription : Get-AzureRoleSizeOperationId : 5919eb4d-96de-60d2-9149-caea24fef5caOperationStatus : Succeeded ...

一つ前の投稿でAzureサブスクリプションとAzure Active Directory(以下AAD)まわりで苦労した話を書いたばかりですが、やはりこのあたりで苦労している人は多いらしく、質問がきましたのでせっかくなのでブログで回答してみたいと思います。スクリーンショットもペタペタしながらですね。 Q1. 組織アカウントでサブスクリプションの共同管理者としてポータルを操作する方法 →サービス管理者の権限でどうやったら設定できるのか教えてください 質問はサービス管理者はマイクロソフトアカウントで現状使っているのだけれども、それを組織アカウントに権限を付与し、そのアカウントでAzureポータルを操作したい…ということだと理解しました。 この場合にはユーザーを作成してそこに権限を出してあげればよいです。操作手順…を見る前に1つだけ注意です。Azureサブスクリプションの共同管理者として追加できるのはAzureサブスクリプションの規定のディレクトリのユーザーのみです。ですので、まず最初におこなうことは「どのディレクトリの組織アカウントを共同管理者にすべきなのか」です。特にO365を利用しており、「組織アカウント」が暗黙的にこのO365が参照しているAADディレクトリである場合には、それを規定のディレクトリにまずする必要があります。 質問から早速脱線してしまいますが、先に、現在Azureコンソール上に表示されていないAADディレクトリに接続する方法を紹介しておきます。 まず、サービス管理者でAzureポータルにアクセスします。まだ現在ではクラシックポータルでの操作となります。 まず、Active Directoryを選択します。私の環境ではすでに複数作成および接続済みですが通常ははじめは「規定のディレクトリ」のみが表示されていると思います。 新規からカスタム作成をします。 既存のディレクトリに接続したくても、ここで選択するのは「カスタム作成」です。エントリの作成くらいの意味なんでしょうね。きっと。 ここで、「既存のディレクトリの使用」を選択します。これによって、すでに存在しているディレクトリに接続するわけですね。 このあとの操作ははじめは戸惑うところだとおもいますが、いちどサインアウトして、「ディレクトリの全体管理者として」サインインします。 ここ、ポイントです。 今、AzureポータルにはAzureサブスクリプションの管理者としてアクセスしています。そして次は、Azure Active Directoryディレクトリの全体管理者としてサインインするのです。 つまり、 「Azureサブスクリプションの管理者」と「Azure Active Directoryの管理者」は全くの別物 であり Azure Active Directory内に「Azureサブスクリプションの管理者」に対しての権限を追加し、参照可能とする 操作をこれからしようという画面なわけです。 あとは、単純にウィザード通り進めればよいので省略します…すいません。入るアカウントを間違えないように！ …というわけで、目的のAADディレクトリが接続できたら、次はそのAADディレクトリをAzureサブスクリプションの規定のAADディレクトリとして設定します。 「設定」の項目で「ディレクトリの編集」をクリックします。 ここで、変更可能なディレクトリ一覧(管理ポータル上で接続しているもの)がでてきますので、目的のものを選択してあとは進めていけばOKです。 さて、これでAzureサブスクリプションには目的のAADディレクトリが紐付いているはずですので、そこにユーザーを作成し、それを共同管理者にしていきます。 (ここからが質問への回答) 目的のAADディレクトリを選択します。 ユーザーの追加をクリックします。 組織内の新しいユーザーを作成します。(これが組織アカウントです。) ここに「ロール」がありますが、ここも注意！これはAADディレクトリに対してのロールであり、Azureサブスクリプションのことは何も言っていません。両者は別物です！ あとは一時パスワードの生成等進めていくだけです。 これでソースが「Microsoft Azure Active Directory」のユーザーができました。これが組織アカウントです。 このアカウントをこのAzureサブスクリプションの共同管理者に追加していきましょう！ 「設定」にて「管理者」を選択し、「追加」を行います。 これでnewadmin@windowsadmin.onmicrosoft.comが共同管理者となりました。 サインアウトし、このアカウントで入り直してみます。 はい。これで組織アカウントで共同管理者としてAzureポータルにアクセスできました。 右上のアイコンがきちんと組織アカウントのものになっています。 ...

前回のエントリに引き続き、AzureサブスクリプションとAAD周りの質問への回答です。 Q. 共同管理者権限のMSアカウントをAADの既定ディレクトリと紐付ける方法 → サブスクリプションに紐付いた既定のディレクトリを共同管理者にも操作させたいんですが、どうやったらいいのか教えてください これは、前回の内容が理解できればもう答えが出ている内容ですね。(エントリわけなくてよかったですな・・・） AzureサブスクリプションとAADディレクトリの権限はべつなので、該当のMSアカウントをAADの管理者にしつつ、コンソール上でAADに接続してしまえばよいです。 これはまさに前回のエントリで既存のディレクトリへの接続を行った操作を行えばよいです。 AADはAzureサブスクリプションとは完全に独立して別途存在しているものなので、両者をべつものとして考え、見る、操作させるためには権限が必要と考え…としていくと理解は容易かなと思います。このあたりADのころの信頼関係を結ぶあたりと似てますね。複雑で混乱しやすいあたりも…。

Azureにはサブスクリプションという管理単位が存在します。サブスクリプション単位で管理者を設定したり、課金管理をしたりする事ができます。新しいポータルになってAzure Resource Managerが全面的に採用となりリソースグループ単位でのアクセス制御や課金管理が行えるようになりましたが、それまではサブスクリプション単位での管理が主体でしたので「自分が自由に使って良いサブスクリプション」が用意されていて、その中でのみ利用できる…という状況の人も多いと思います。 私もこの状況でして、その状況でVisual Studio Team Servicesを無償枠の5人を超えたチームで使い出そうとして色々と無駄にはまってしまったのでその記録を残しておきます。 やりたかったのですが断念したのは以下の事です - VSTSにO365で利用しているAADを紐付ける 現在自分のチームに割りあてられているAzureサブスクリプションにVSTSの無償枠を超えた分を課金する もちろんこれは適切に設計されていれば当たり前にできる事ですし、頑張れば今回の私の状況でも実現できたはずです。ですが、色々とやりづらくなってしまったのはAzureサブスクリプションに紐付いている「規定のディレクトリ」が異なっていた事が原因でした。 「規定のディレクトリ」という概念は結構難しいので、少し説明しておきます。 - ディレクトリの実態はAzure Active Directoryのディレクトリです。(ディレクトリのディレクトリ……) Azureサブスクリプションは作成されるときに同時にそれに紐ずくAADディレクトリが生成されます(以前、生成されなかった時期もあったそうです) 1つのAzureサブスクリプションに紐ずくAADディレクトリは1つのみです AzureサブスクリプションとAADディレクトリの関係は1対1の固定的なものではなく後から変更する事ができます AADディレクトリはそれ単体で(事実上)いくつでも無償で作成する事ができ O365の契約をするとO365で利用するその組織専用のAADディレクトリが生成され、O365で利用されます 複数のAzureサブスクリプションの規定のディレクトリを単一のAADディレクトリに設定する事ができます Azureサブスクリプションを削除しても、それに紐付いていたAADディレクトリは削除されません Azureポータルから、AADディレクトリを作成するときには「新規に作成する」のか「既存のものを接続」するのかを選択できます このようにAzureサブスクリプションとAADディレクトリはそれぞれ独立して存在しつつ、くっつけたり、切り離したりする事ができます。 そもそもなぜAzureサブスクリプションにAADディレクトリを紐付ける必要があるのか？というのは正直なところ私にもよくわかりません。ごめんなさい。より正確に言うと「紐付ける必要がある現状の設計は悪い設計なんじゃないの？」と思います。今回はまったのもこのあたりが関係しています。 AzureサブスクリプションとAADディレクトリを紐付けないとできない事を知っている範囲で書いてみます。 - Azureサブスクリプションの管理者は規定のディレクトリのアカウントか、Microsoftアカウントでなければいけない(規定でない別のAADディレクトリのアカウントは管理者に指定できない) Azure Powershellで利用するアカウントはAADのユーザーでないといけない(Microsoft アカウントではだめ) Azure Automationで保存して使用するクレデンシャル(アカウント)はAzureサブスクリプションの規定のディレクトリのアカウントでないといけない(Microsoftアカウントではだめ) おそらく他にも色々とあると思いますが、私が知っているのはこれだけです。 さて、やっとVSTSの話になります。VSTSに限らない話なのですが、Azureポータル上で操作をしている時に何か既存の他のサービスとひも付けたりするときに「現在のアカウント」でアクセスできるものが自動的に表示され、それ以外が選択できないGUIがほとんどです。別のアカウントを入力できるケースのほうがレアですね。ですので、具体例としてVSTSの場合には以下の条件を満たさないと意図する結果にできません。 - 自分が使えるサブスクリプションの規定のディレクトリが、VSTS上で参照したいディレクトリと一致している - そのディレクトリ上に組織アカウントがあり、その組織アカウントがサブスクリプションの管理者である あるAzureサブスクリプションの共同管理者として規定ではないAADディレクトリのユーザーが指定さえできればこのあたり何も問題ないんですけどね。これができないので混乱、苦労します。 そして、Microsoftアカウントはとりあえずどこにでもなんにでも権限つけられちゃうのでそちらのほうが楽に使えちゃうんですよね。でも、他要素認証とか色々企業でコントロールするには組織アカウントを事実上つかわないと色々とやりづらくなってしまうわけで…。このあたりもう少しアーキテクチャ的に改善されて欲しいところです。

Microsoft Azure Fundamentals - Microsoft Virtual Academy 上記のMVAのコンテンツがAzureの管理周りの理解によい感じです。以下のあたりしっかりはっきり理解している人って少ないのではないでしょうか。 複数のサブスクリプションの使い分け - サブスクリプションとAADディレクトリの関係 - サービスの管理者と、ディレクトリの管理者の関係(両者は別物である) 前編英語ではありますが…、いろいろと悩む前にまとまったコンテンツで概念を理解してしまうのが手っ取り早いですね。 願わくばこのあたりがまとまった日本語コンテンツも欲しいところですが…。自分でやるべきか…。

- [Download System Center Management Pack for Microsoft Azure (Technical Preview) from Official Microsoft Download Center](http://www.microsoft.com/en-us/download/details.aspx?id=50013) 待望の新しいAzure管理パックが出てきています。この管理パックの特徴はなんといっても… - AzureのREST APIをキックする方式 - Azure Resource Managerによって標準的な手法で公開されるパフォーマンスデータを取得する - 新しいARM対応サービスに**自動対応**する 「自動対応」がとても嬉しいですね。全部ARMにきちんと寄せていってもらえると思ってますので、Azureの監視は何でもかんでもこれだけでOKになる…はず！

Azure Resource ManagerをいまからやっておけばAzure Stack対応もバッチリ！…ということでAzure Resource Mangerのお勉強を始めています。さらにはInfrastructure as Codeの実現に向けてDesire State Configurationのお勉強も。外側はARMで、VMの中はDCSで…という感じですね。 まず手始めに何から手をつけると良いかな…と探した所、以下のブログが非常にいい感じだったのでここから手をつけてみました。 - [18 Steps for End-to-End IaaS Provisioning in the Cloud with Azure Resource Manager (ARM), PowerShell and Desired State Configuration (DSC) - KeithMayer.com - Site Home - TechNet Blogs](http://blogs.technet.com/b/keithmayer/archive/2015/07/07/18-steps-for-end-to-end-iaas-provisioning-in-the-cloud-with-azure-resource-manager-arm-powershell-and-desired-state-configuration-dsc.aspx) コードで紹介されているので、基本的にそれをコピペすれば動くのですが、せっかくなので全部写経しつつコメント出力を追加したり、いちいち色んな物を選択したり、手動でクレデンシャルを入力したりするのが面倒なのでそこも自動化したり…と、改造しながら楽しんでみました。まだ、DSCでIISを構成するところまで行ってないのですが以下の動作を行わせる所までは全部理解して書いて正常動作を確認するところまでできました。 - クレデンシャル生成 - Azureアカウント追加 - ARMプロバイダ登録 - サブスクリプション選択 - リソースグループ作成 - ストレージアカウント作成 - 仮想ネットワーク作成 - VIPリソース作成 - ロードバランサ作成 - ネットワークセキュリティグループ作成 - NIC作成 - 可用性セット作成 - VM作成 https://gist.github.com/ebibibi/9a0a6830b54f0d3a7400 ...

最近はAzure上で検証を行うことも多くなってきました。凄く便利なのですが、その代わりに課金のことを随分と気にしなくてはいけなくなります。これが結構ストレスなんですよね…。 そこで、とりあえず、特定サブスクリプション内の仮想マシンを毎日定時に強制シャットダウンしてしまうスクリプトをAzure Automationで定期実行することにしました。これでシャットダウンし忘れでもある程度安心ですね。 取り立てて難しいところは何もないですが、検索するとさくっとその目的に使えるものが以下にあったのでそれを流用させてもらうことになりました。 - [Q and A - TechNet Stop Azure Virtual Machine using Azure Automation Runbook](https://gallery.technet.microsoft.com/Stop-Azure-Virtual-Machine-0b1fea97/view/Discussions#content) https://gist.github.com/ebibibi/b6b0c1ce51f42e9548a6 あとは、Azure Automation上への登録とスケジュール設定ですね。 とりあえずこれで、毎日深夜3時に全てのVMが停止されるようになりました。本当は例外処理を入れられるようにしたりなど必要ですが…。まずはこれで良いことにします。 2015/07/17追記 ごめんなさい。もともと公開していたコードだとジョブは成功するものの、正常にVMが停止しないことがわかりました。コードは修正してあります。具体的にはシンプルに以下のように全VMを取得～停止させてしまうロジックにしました。これで正常に停止されることを確認しました。 Get-AzureVM | Stop-AzureVM -Force

Microsoft Virtual Academy(MVA)では無償で良質のコンテンツが多数提供されています。 今回はその中でも特にお勧めのコンテンツを紹介します。 ID管理 まずID関連で超お勧めなのは安納さんの「クラウド時代のActive Directory次の一手シリーズ」です。 - [クラウド時代の Active Directory 次の一手シリーズ ~ 第 1 回 Active Directory の位置づけ](http://bit.ly/1QjvAQu) - [クラウド時代の Active Directory 次の一手シリーズ ~ 第 2 回 Active Directory ドメイン サービスの新しい役割](http://bit.ly/1GPP3rl) - [クラウド時代の Active Direcrory 次の一手シリーズ ~ 第 3 回 Active Directory フェデレーション サービスの役割 解説編](http://bit.ly/1AHn4ZT) - [クラウド時代の Active Direcrory 次の一手シリーズ ~ 第 4 回 Active Directory フェデレーション サービスの役割 構築編](http://bit.ly/1M2dstR) - [クラウド時代の Active Directory 次の一手シリーズ ~ 第 5 回 認証のためのプロキシ Web Application Proxy](http://bit.ly/1FnQusO) - [クラウド時代の Active Directory 次の一手シリーズ ~ 第 6 回 Microsoft Azure Active Directory とは](http://bit.ly/1LVTTmv) 社内でActive Directoryで管理させていたWindows PCをつかってWindows統合認証をしていれば幸せになれる時代はとっくに終ってしまって、これからのクラウド時代で様々なSaaSを効果的に利用しながらID管理もシンプルに保ちつつ、セキュリティも担保していかなくてはいけないのが現在の状況です。ID管理はやっぱり肝です。これらのコンテンツで大きな流れを理解することが出来ます。「フェデレーションってよく聞くけどなんだか難しそう…」という人におすすめです。 ...

Build, IgniteとMicrosoftの大きなイベントが立て続けにあり、新発表がわんさかありましたね。いや、面白いですね。 色々とHotな話があるのですが、個人的に一番衝撃的だったのは「Microsoft Azure Stack」です。オンプレミスでも、ホスティングサービスプロバイダーでも、Azureでも一貫性をもった「Cloud OS」を提供していく…というのはWindows Server 2012のころからのMicrosoftのビジョンですが、いよいよ本格的に具現化していくのだなという印象です。 まず、気になるのは「Windows Azure Packはどうなるの?」という事ですが、冒頭の図によく表されていますね。これはIgniteのセッションの1つであるWindows Azure Pack Roadmap | Microsoft Ignite 2015 | Channel 9のスライドからの引用です。 Microsoft Azure StackはWindows Azure Packとは別物であり、Microsoft Azure Stackが出た後もWindows Azure PackはURによって機能追加が継続される。 ということが読み取れると思います。ただ、あちこちのセッションの動画を見て回ったり、Q&Aでのやりとりを聞いたり…と繰り返しているとちょっと違う印象にもなるところですが。現時点での私の理解は以下です。私の英語力の問題により、誤解や誤りが入っている可能性はあります。また、リリースは随分先になるはずなので、これから変更になる可能性も大いにあると思います。 Microsoft Azure Stackは基本的に今のWindows Server, System Center, Windows Azure Packとは別製品。基盤のOSから一番上のUIまで含んだ単独の製品となる。 - Windows Server 2016の上にMicrosoft Azure Stackをインストールする…というようなことは出来ない。 - Azure Resource Managerという管理層を新たに設け、それによってAzureとAzure Stackとに互換性を持たせる。 - 基本的に「接続先を変更する」という操作だけで切り替えられ、その先がAzureなのかAzure Stackなのかは気にしなくて良くなる。 - リソースはjsonファイルで記述可能であり、デプロイにどどまらず変更も可能。 - Azure上には多数のサービスがあるので、そのうちどのサービスがAzure Stackに乗るのかはビジネス上判断となりこれから決定される。(エラスティックであることが有利なサービスはAzure Stackにはこなかったりするのでしょうね、きっと) - Azure Stackを今すぐ触りたかったら、Azureを触れば良い。Azure StackのPoCはAzureでできる。 個人的には、MicrosoftがAzureで本当に使っているハード(相対的に相当安いはず)まで含めて全部ラックにおさめる形で提供しだしたりすると大変なことになるよなぁと思います。さすがにそこまでは無いかもしれませんが、CPSの例もありますし、似たようなことはDELLさんあたりと組んで行われそうな気もします。 個人的には、Azureも学んでおかないとまずいよなぁと思いながら時間が取れなくて中々…という感じでしたが、もうAzureだのオンプレミスだのを区別する必要もないような世界がもうすぐそこですね。

金曜日の帰りの電車で座席に座れたので、Surfaceを取り出してこのブログを書いています。最近ブログ記事を全然書けていないので書きたいことがたくさんたまっております…。 さて、今回の話題はAzure Active Directory(AAD)です。オンプレミスのActive Directoryは知っていてもAzure上のActive Directoryの事を概念的に理解出来ている人はまだまだ少ないのが現状ではと思います。私が理解しているところをいくつか書いておこうと思います。一部正確ではない表現をあえて書いている部分がありますし、私の理解がそもそも間違っている部分があるかもしれません。ですが、まずはこういう理解から入ると良いだろうと思っています。 - オンプレミスのActive Directory Domain Service(ADDS)と似た名前がついてますし、機能的に同じ部分も一部ありますが、当初の理解のためには「名前は似てるけど現状は完全な別物」という捉え方をするのがよいだろうと思います。(将来的には同じような形に収束するのかもしれません。むしろクラウド上のみで完結する形になるのかもしれません。どういう方向に行くか、ワクワクしながらウオッチする感じです。) - AADはクラウド上にあって、インターネットに公開されていて、インターネット上での外のサービスとの連携を主眼に機能が用意されています。 - AADにはユーザーやグループ等が登録できます。 - O365のユーザー情報はAADに格納されています。例えばExchange OnlineはディレクトリとしてO365のテナント用に用意されたAADを利用しています。 - AADはAzure上のサービスとして存在しているので、いくつでもテナントを作成することができます。 - Microsoftアカウントはマイクロソフトが用意してくれていて全世界に公開されている1つのAADテナントです。 - AADのテナントは開かれているので、AADの1つのテナントに別のAADのテナントのユーザーを登録して権限を付与する…というようなことも可能です。 - AADとオンプレミスのADDSは「ディレクトリ同期ツール」にて同期することが可能です。 同期は基本的にADDSからAADの方向のみです。 - パスワードに関してはAADからADDS方向の同期も実装されてきました。今後も増えていくのかもしれません。 - AADの管理は複数の場所から行えるのですが、一番充実した管理が行えるのはAzureの管理ポータル画面からです。 - O365のAADも1つのAADなので、Azureの管理ポータル画面からO365で利用しているAADを「追加」して管理することができます。 - AADに機能を追加したAzure AD Premiumというサービスがあります。これはAzureの管理ポータルから管理します。O365の管理ポータルからは管理できません。 超簡単なまとめとしてはオンプレミスのID管理はAD DS。クラウドのID管理はAAD。間のID同期はディレクトリ同期ツール。というあたりで良いのかなと思います。 ADFSは?という声が聞こえてきそうですが、一旦ADFSを絡めずに理解するのが良いのではと思います。 ADDSの理解。AADの理解。ADFSの理解。これらを単体で理解した上で、この3つをつなげた時に行える世界の広がりを理解すると感動的だと思います。 もっとちゃんと時間をとって書きたいですね…。

先日、The Microsoft Conference 2014で登壇させていただきました。 その際に使用したプレゼンテーション資料はSlideShareで共有しておきました。Azure Site Recovery自体が素晴らしいものなのでその紹介を中心に、周辺のことをいろいろとしゃべらせていただきました。去年の2013でも登壇させてもらいましたが、その時は3人で10分ずつという配分でしたが、今回は一人で45分。150名程度参加いただいたでしょうか。無事に終わってよかったです。 外でしゃべることは1年前のMicrosoft Conferenceが初めてでした。それから1年、何度も機会をいただき、慣れてきたところもありますが、いまいち「響いている」感じがしていなかったのが正直な所です。The Microsoft Conference 2014の1日目はただの参加者として参加していましたが、その中でも技術的な部分はさておき「面白い」感が足りないと感じました(みなさんすいません)。 そこで、今回はセッションとミニセッション、両方であえてピエロ的に「面白い」要素を盛り込んでみました。単にネタを仕込むというだけではなく、言葉の抑揚だったり、テンポだったりそのあたりもちょっと意識しながら。初めての試みなのでうまくいったかどうだかわかりませんが、私から見る限り「寝ている人」がいなかったのはよかったです。それでも、終わった後にその場で、またその後ブースで「面白かったですよ。」と数名の方からお声掛けいただきました。今後もこの方向性は継続してトライしていきたいと思います。 また、今回のイベントでは、お声がけいただいて、本も読んだし、ブログも読んでくださっているという方がいて、とても嬉しかったです。ブログで記事を書くのはともかく、カンファレンスで喋ったりなどというのはかなり準備含めて消耗するものなのですが継続していきたいなと思います。

Azure Site RecoveryとAzure Backupが日本リージョン(東日本、西日本)で利用可能になっています。どちらも大量のデータを複製、同期するサービスですので、日本リージョンで利用可能になるのは大変嬉しいですね。 - [Azure Site Recovery Available In Japan East and West](http://azure.microsoft.com/en-us/updates/azure-site-recovery-available-in-japan-east-and-west/) - [Azure Backup Available In Japan East and West](http://azure.microsoft.com/en-us/updates/azure-backup-available-in-japan-east-and-west/)

以前ブログ記事でも紹介しましたが、現在Azure Site Recoveryの検証を進めています。 - [Azure Site RecoveryでAzureをDR先に構成可能に | System Center Blog](https://systemcenter.ebisuda.net/2014/06/06/azure-site-recovery%e3%81%a7azure%e3%82%92dr%e5%85%88%e3%81%ab%e6%a7%8b%e6%88%90%e5%8f%af%e8%83%bd%e3%81%ab/) 実際に検証を進める中で、仮想マシンの保護を有効にするまでにいくつかハマったポイントがありましたので共有します。 参考情報 Azure Site Recoveryって何?という方のためにリンクもいくつか貼っておきます。 まずはこちら。概要が良くわかります。 - [Implementing Enterprise-Scale Disaster Recovery with Hyper-V Recovery Manager, Network Virtualization, and Microsoft System Center 2012 R2 | TechEd North America 2014 | Channel 9](http://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DCIM-B322#fbid=) 以下のブログもASRの概要の理解に役立ちました。 - [Microsoft Azure Site Recovery Preview | Thomas Maurer](http://www.thomasmaurer.ch/2014/06/microsoft-azure-site-recovery-preview/) 具体的な計画や構築ステップに関しては以下のサイトがまとまっています。 - Recovery Manager | Microsoft Azure Technical Documentation Library [http://msdn.microsoft.com/en-us/library/azure/dn440569.aspx](http://msdn.microsoft.com/en-us/library/azure/dn440569.aspx) 保護対象とする仮想マシンには結構制限があります。ここには注意が必要です。 - Prerequisites and support [http://msdn.microsoft.com/en-us/library/azure/dn469078.aspx](http://msdn.microsoft.com/en-us/library/azure/dn469078.aspx) OSはWindows Server 2008以降, CentOS, openSUSE, SUSE, Ubuntu - 64bitOSのみ - OSのディスクサイズは20MB～127GBで1ディスクのみ - データディスクは20MB～1023GB - ネットワークアダプタは1つ、IPアドレスも1つのみ。複数NICがある場合には1つだけ選択することになる。 - 静的IPアドレスはサポートされない。フェールオーバー後にDHCP構成となる。 - iSCSIディスクはサポート対象外。 - 共有VHDディスクはサポート対象外。 - FCディスクはサポート対象外。 - クラスターティスクはサポートされる。 - ディスクフォーマットはVHD, VHDXの両方がサポートされる。 - 第1世代の仮想マシンのみサポートされる。 ハマったポイント1 : 証明書の有効期限 ハマったポイントの1番目は証明書の有効期限です。証明書をアップロードすると、以下のように有効ではないと怒られてしまいました。 ...