Microsoft Cloud

この記事はシリーズの3つ目の記事です。他の記事も参考にしてください！ Windows10をAzure ADに参加させる！【M365フルクラウド環境検証 その1】 | Microsoft Cloud Administrators - Azure ADにドメインを追加してユーザーIDをわかりやすくする！【M365フルクラウド環境検証 その2】 | Microsoft Cloud Administrators さて、今回はIntuneでデバイス管理の入り口を…と思っていたのですが、よく考えたらまず評価ライセンスを申し込まないといけませんでした。というわけで、今回は全部入りライセンスのM365 E5のトライアルを申し込んでみたいと思います。 Microsoft 365 E5トライアル申し込み まずMicrosoft 365 E5トライアル申し込みをするための管理者ユーザーを作成します。もともとのAzure ADを作成したユーザーが管理者になっているのですが、別のAADディレクトリから招待されたユーザーであり少々心配なため…。 そして、新規のAAD管理者であるadmin@tm-plan.netにてMicrosoft 365管理センターにアクセスします。 Microsofot 365 E5の試用を開始します。 ロボットではないことを証明します。 25ユーザーでの1ヶ月試用ができます。 ユーザーへのライセンスの割当て 1ヶ月間のトライアル申し込みはできましたので、テストユーザーにライセンスを割り当てます。 これでテストユーザーにMicrosoft 365 E5のライセンスを割り当てることができました。では次回こそIntuneを構成してデバイス管理の構成をしたいと思います。 シリーズの次の記事はこちら！ Intuneへの登録を行う【M365フルクラウド環境検証 その4】 | Microsoft Cloud Administrators

前回の記事( Windows10をAzure ADに参加させる！【M365フルクラウド環境検証 その1】 | Microsoft Cloud Administrators )ではAADにWin10をAAD Joinさせて、AAD上のIDで直接Win10にサインインができるようにしました。 Win10で直接、職場または学校アカウントでサインイン これはこれで素敵なのですが、AADの規定のドメイン名は「xxxxxxxxx.onmicrosoft.com」という形式であり、ちょっと長いですし、やはり企業用途であれば独自ドメインを使いたいですよね。そうすればユーザーもわかりやすく短いユーザーIDを使ってWin10にログインすることも可能になります。 ということで今回はAADにドメインを追加してユーザーIDを変更してみます。このときに既存のユーザーおよびユーザープロファイル上のファイル等に影響が出るのか、出ないのかも確認します。 現状確認 まず、現状を確認しておきましょう。 初期状態でローカルにユーザーが1つあり、その状態からAADに参加し、AAD上のユーザーで一度サインインした状態のWin10があります。 もちろんローカルユーザーはビルトインのユーザー群と当初に作成した1ユーザーのみであり、AADのユーザーは表示されていません。 ログインしているユーザーはAzure AD上のユーザーです。 環境変数を確認してみます。 C : \ U s e r s \ m e b i s u d a > s e t A L L U S E R S P R O F I L E = C : \ P r o g r a m D a t a A P P D A T A = C : \ U s e r s \ m e b i s u d a \ A p p D a t a \ R o a m i n g a s l . l o g = D e s t i n a t i o n = f i l e C o m m o n P r o g r a m F i l e s = C : \ P r o g r a m F i l e s \ C o m m o n F i l e s C o m m o n P r o g r a m F i l e s ( x 8 6 ) = C : \ P r o g r a m F i l e s ( x 8 6 ) \ C o m m o n F i l e s C o m m o n P r o g r a m W 6 4 3 2 = C : \ P r o g r a m F i l e s \ C o m m o n F i l e s C O M P U T E R N A M E = D E S K T O P - 7 J O 0 T J G C o m S p e c = C : \ W I N D O W S \ s y s t e m 3 2 \ c m d . e x e D r i v e r D a t a = C : \ W i n d o w s \ S y s t e m 3 2 \ D r i v e r s \ D r i v e r D a t a F P S _ B R O W S E R _ A P P _ P R O F I L E _ S T R I N G = I n t e r n e t E x p l o r e r F P S _ B R O W S E R _ U S E R _ P R O F I L E _ S T R I N G = D e f a u l t H O M E D R I V E = C : H O M E P A T H = \ U s e r s \ m e b i s u d a L O C A L A P P D A T A = C : \ U s e r s \ m e b i s u d a \ A p p D a t a \ L o c a l L O G O N S E R V E R = \ D E S K T O P - 7 J O 0 T J G N U M B E R _ O F _ P R O C E S S O R S = 4 O n e D r i v e = C : \ U s e r s \ m e b i s u d a \ O n e D r i v e O S = W i n d o w s _ N T P a t h = C : \ P r o g r a m F i l e s ( x 8 6 ) \ C o m m o n F i l e s \ O r a c l e \ J a v a \ j a v a p a t h ; C : \ W I N D O W S \ s y s t e m 3 2 ; C : \ W I N D O W S ; C : \ W I N D O W S \ S y s t e m 3 2 \ W b e m ; C : \ W I N D O W S \ S y s t e m 3 2 \ W i n d o w s P o w e r S h e l l \ v 1 . 0 \ ; C : \ W I N D O W S \ S y s t e m 3 2 \ O p e n S S H \ ; C : \ P r o g r a m F i l e s \ I n t e l \ W i F i \ b i n \ ; C : \ P r o g r a m F i l e s \ C o m m o n F i l e s \ I n t e l \ W i r e l e s s C o m m o n \ ; C : \ P r o g r a m F i l e s \ T o r t o i s e G i t \ b i n ; C : \ P r o g r a m F i l e s \ G i t \ c m d ; C : \ U s e r s \ m e b i s u d a \ A p p D a t a \ L o c a l \ M i c r o s o f t \ W i n d o w s A p p s P A T H E X T = . C O M ; . E X E ; . B A T ; . C M D ; . V B S ; . V B E ; . J S ; . J S E ; . W S F ; . W S H ; . M S C P R O C E S S O R _ A R C H I T E C T U R E = A M D 6 4 P R O C E S S O R _ I D E N T I F I E R = I n t e l 6 4 F a m i l y 6 M o d e l 6 9 S t e p p i n g 1 , G e n u i n e I n t e l P R O C E S S O R _ L E V E L = 6 P R O C E S S O R _ R E V I S I O N = 4 5 0 1 P r o g r a m D a t a = C : \ P r o g r a m D a t a P r o g r a m F i l e s = C : \ P r o g r a m F i l e s P r o g r a m F i l e s ( x 8 6 ) = C : \ P r o g r a m F i l e s ( x 8 6 ) P r o g r a m W 6 4 3 2 = C : \ P r o g r a m F i l e s P R O M P T = $ P $ G P S M o d u l e P a t h = % P r o g r a m F i l e s % \ W i n d o w s P o w e r S h e l l \ M o d u l e s ; C : \ W I N D O W S \ s y s t e m 3 2 \ W i n d o w s P o w e r S h e l l \ v 1 . 0 \ M o d u l e s P U B L I C = C : \ U s e r s \ P u b l i c S E S S I O N N A M E = C o n s o l e S y s t e m D r i v e = C : S y s t e m R o o t = C : \ W I N D O W S T E M P = C : \ U s e r s \ m e b i s u d a \ A p p D a t a \ L o c a l \ T e m p T M P = C : \ U s e r s \ m e b i s u d a \ A p p D a t a \ L o c a l \ T e m p U S E R D O M A I N = A z u r e A D U S E R D O M A I N _ R O A M I N G P R O F I L E = A z u r e A D U S E R N A M E = m e b i s u d a U S E R P R O F I L E = C : \ U s e r s \ m e b i s u d a w i n d i r = C : \ W I N D O W S きちんとユーザーのドメインはAzureADと表示されていますね。さらに、プロファイルはC:\Users\mebisuda にセットされています。 ...

「もうできるんじゃないか？」「いや、まだ早いんじゃないか？」といつも論争になる(？)完全フルクラウド環境。もうオンプレミスのActive Directoryもファイルサーバーもプリンタサーバーも全部捨てて、フルクラウド環境で問題ないんじゃないか？そのように考えている方も多いと思います。 とはいえ、特にエンタープライズ環境では「いや、まだ無理だろう」という声も大きいですし、実際のところオンプレミスにある膨大な資産をどのように移行していくのか…ということで現実的に考えられない組織も多いと思います。 ですが！ 規模が小さいところで既存資産も対してなく、これから環境を整えたいという状況であればMicrosoft 365をつかってフルクラウドで環境を整えるのは非常に現実的で有力な候補だと思います。というか私がIT環境を全部コントロールできるなら絶対にそうします。 ということで、フルクラウドの検証環境を作って色々と挙動を見ていってみたいとおもいます。シリーズもの的な位置づけになる予定です。 初回はまずAzure ADを新規に用意し、Windows 10をAzure ADに参加させるとから言ってみたいと思います。 dsregcmd /status いきなりコマンドからで恐縮ですが、このコマンドで状況を確認しながら勧めていきたいと思います。 Win10の初期状態にローカルユーザーでログインすると下記のように、Device StateおよびUser StateはすべてNOとなります。 C:\Users\mebisuda>dsregcmd/status +———————————————————————-+ | Device State | +———————————————————————-+ AzureAdJoined : NO EnterpriseJoined : NO DomainJoined : NO +———————————————————————-+ | User State | +———————————————————————-+ NgcSet : NO WorkplaceJoined : NO WamDefaultSet : NO AzureAdPrt : NO AzureAdPrtAuthority : NO EnterprisePrt : NO EnterprisePrtAuthority : NO +———————————————————————-+ | Ngc Prerequisite Check | +———————————————————————-+ IsUserAzureAD : NO PolicyEnabled : NO PostLogonEnabled : YES DeviceEligible : YES SessionIsNotRemote : NO CertEnrollment : none AadRecoveryNeeded : NO PreReqResult : WillNotProvision ...

前回の記事「 Azure Portalにアクセスする際の動きをFiddlerで確認 – その１ クラウドIDを使った一番シンプルなパターン | Microsoft Cloud Administrators 」の続きです。 今度はクラウドIDが別AzureADテナントに招待されその別Azure ADテナントに紐付いているAzureサブスクリプションにアクセスする際の動きを確認してみます。 注意：このエントリの内容は「正確さ」に関しては保証しません。自分で実際に試してみて、挙動をみて、考えて、自分の既存の知識や経験、他のドキュメント等と照らし合わせた上で自分の現段階の考えを書いています。ご注意ください。 クラウドIDがテナントをまたいで招待されているパターン 今回は前回と同じwindowsadmin.onmicrosoft.comというAADに紐づくAzureサブスクリプションに対して別AzureADテナントwindowsadmin2.onmicrosoft.com上に存在するaccesstest2@windowsadmin2.onmicrosoft.comからアクセスをしたときの挙動を見てみます。 サブスクリプションは前回利用したものと同じです。紐付いているディレクトリはwindowsadmin.onmicrosoft.comです。 新規に別のAzure ADを作成しました。ディレクトリ名はwindowsadmin2.onmicrosoft.comです。 ユーザーとしてaccesstest2@windowsadmin2.onmicrosoft.comを作成しています。 accesstest2@windowsadmin2.onmicrosoft.comはwindowsadmin.onmicrosoft.comに招待してあります。 サブスクリプションへの権限も付与してあります。 実際の挙動 https://portal.azure.com/にアクセスします。 サインインを求められます。 アカウント名を入力します。 パスワードの入力を求められます。 サインインの状態を維持するかどうかを質問されます。 windowsadmin2.onmicrosoft.comディレクトリを利用してAzure管理ポータルにアクセスしました。サブスクリプションが該当ディレクトリには存在していないと表示されています。 ディレクトリをWindowsadmin.onmicrosoft.comに切り替えます。 Azure管理ポータルへのアクセスが完了しました。 Fiddlerに記録されたデータを含めた挙動 Fiddlerで動きを見ると、はじめの方の挙動は完全に同一になっています。その後、Azure管理ポータルにアクセスしたあとでAADテナントを明示した認証、認可が走っていることがわかります。 何度もAzure管理ポータル上でディレクトリの切り替えを行うと、そのたびにlogin.microsoftonline.comへのAADテナントを明示したアクセス(認証～トークン取得)が行われていることが確認できます。

皆さんこんにちは。胡田です。毎日暑いですね。みなさんお体にお気をつけください。 さて、今回はAzure Portalにアクセスする際の動きをFiddlerで確認してみようと思います。 Azure Portalにアクセスするためには皆さん御存知の通りAzure ADで認証される必要があります。マイクロソフトアカウント利用する場合には「Azure ADで認証」と書いてしまうのは少々正確ではないかもしれませんが、ここでは組織アカウントのみ考えることにします。 このとき、ユーザーとしてはAzure PortalのURL(https://portal.azure.com/)を入力してAzure Portalにアクセスするわけですが、Azure ADで認証する必要があるためリダイレクトされる動きになります。さらに、アクセスしようとしているAzure Subscriptionの紐付いているAzure ADが、ユーザーが存在しているAzure ADとは異なる構成もとれます。このようなときにどのようにブラウザが遷移しているのかをきちんと確認しようというのがこのエントリの趣旨です。 Fiddlerを使うことでHTTP/HTTPSの通信を生で記録、確認することができますので、テストした時点での正確な動きを確認することが可能です。 構成パターンはかなり多数ありますので相当複雑にもなりうるのですが、まずはシンプルなところから何パターンか見ていきたいと思います。 注意：このエントリの内容は「正確さ」に関しては保証しません。自分で実際に試してみて、挙動をみて、考えて、自分の既存の知識や経験、他のドキュメント等と照らし合わせた上で自分の現段階の考えを書いています。ご注意ください。 クラウドIDを使った一番シンプルなパターン まずは下記のような一番シンプルなパターンを見ていきましょう。 AADとしてwindowsadmin.onmicrosoft.comが存在します。 windowsadmin.onmicrosoft.com上にaccesstest@windowsadmin.onmicrosoft.comというアカウントを作成します。このアカウントはクラウド上に存在するアカウントであり、フェデレーション等は構成されていません。 windowsadmin.onmicrosoft.comをディレクトリとして構成された「MVP特典(Visual Studio Ultimate with MSDN)」というAzureサブスクリプションが存在します。 #なんだかひどいサブスクリプション名ですが、管理しているサブスクリプションが大量にあるのできちんと区別しやすい愚直な名前にしております…。 「MVP特典(Visual Studio Ultimate with MSDN)」 上でaccesstest@windowsadmin.onmicrosoftのアカウントに閲覧権限(Reader)を割り当てアクセス可能にしてあります。 実際の挙動 PC上でChromeをシークレットモードで開き、URLにhttps://portal.azure.com/を入力します。 URLがhttps://login.microsoftonline.com/となり認証を求められます。 ユーザー名を入力します。 次にパスワードの入力を求められます。パスワードを入力して「サインイン」をクリックします。 サインインの状態を維持するかどうかを聞かれます。この質問には今後も含めてこの検証内ではすべて「いいえ」で回答します。(テスト目的のため) Azure管理ポータルにアクセスできました。 Fiddlerに記録されたデータを含めた挙動 PC上でChromeをシークレットモードで開き、URLにhttps://portal.azure.com/を入力します。 このときhttps://portal.azure.com/の画面は表示されずすぐに画面が遷移しますがその様子が見て取れます。 1行目ではProxy接続でHTTPSを扱うためにHTTP1.1のCONNECTメソッドが利用されています。 参考URL： Re: Newbie Questions - Google グループ - CONNECT - HTTP | MDN - HTTPSとCONNECTメソッド - ITの窓辺から 2,3行目ではportal.azure.comおよびその配下のJavascriptを取得しています。実際にはJavascriptによってまず認証を行うためのページに遷移させられています。 ...

先日HCCJPにてハンズオンイベントを開催しました。ハンズオン資料作成、ハンズオン講師等務めさせてもらいました。 ざくっと概要を理解するものとしてはそんなに悪く無いできだと思いますのでよろしければ参考にしてみてください。 ※Azureの理解という観点でみると「Azure, Azure Stackで同じ概念、操作でできるもの」に引っ張られすぎている感は否定できませんけれども。 https://gitpitch.com/hccjp/hybridcloudhandson1

#この投稿は下記３つのブログにクロスポストしています。 https://diary.ebisuda.net/- https://windowsadmin.ebisuda.net/- https://cloud.ebisuda.net/ 今日はお休みの日ですが、Interact 2019にて登壇させてもらってきました。 休日のコミュニティイベントへの参加も解禁しましたが、今回はさらに長男と次女をつれていきました。そして私と一緒に登壇させました。 長男はきちんと自己紹介できましたが、次女は恥ずかしがって私の後ろに隠れてしまいました。そして結局、事前にはなにも教えておかずにその場で「こうやって」って操作をさせて、MinecraftのサーバーをAzure上に展開してもらいました。 どうやら結局なんだかよくわかっていなかったようですが、それでも楽しかったようなので良かったです。 セッションは参加してくれた人に何度も笑ってもらいました。それがよかったです。笑いもなにもない真面目なITのセッションって本当にくらーい感じになってしまうのでそういうのは好きじゃないんです。なんでも楽しいのがいいですよね！ 資料はSlideshareにアップロードしておきましたので、よろしければご覧くださいませ。 ** あなたも「違いが分かる人」になりましょう！ ～ Azure, AzureStack, AzureStack HCI ～ ** from Masahiko Ebisuda

AWS Outpostsの発表はずいぶん前(re:invent 2018)になされ、私もブログでも言及していました https://cloud.ebisuda.net/aws-outposts%E3%81%A8microsoft-azure-stack%E3%81%AB%E9%96%A2%E3%81%97%E3%81%A6%E6%9C%AC%E8%B3%AA%E7%9A%84%E3%81%AB%E5%A4%A7%E4%BA%8B%E3%81%A0%E3%81%A8%E6%80%9D%E3%81%86%E3%81%93%E3%81%A8/ まだOutpostsは市場には登場していませんが、Youtube上で解説動画が見られることを教えてもらいました。 https://youtu.be/Cnn3BYsE6ug?fbclid=IwAR0FbjkR0wjh3lIUMPbMm9zqeJwV1mO4RzkRIPAZH3nEZEhht1yJ-whPjm4 このような形でしっかりと解説を聞くのは初めてだったので、聞きながらTwitterで感想をつぶやいてみました。 AWS OutpostsとAzure Stack - Togetter Outpostsが予定どおり出荷されて(2019年後半を予定)、オンプレミスでも「クラウド」を利用する機運が高まってくれると良いなとあらためて思います。

Azure Stack上の仮想ネットワークと任意の場所のネットワークとをVPN接続で接続することができます。やり方はいろいろとありますが、簡単にできるものの一つとしてWindows ServerでのVPN接続があります。Azure StackとのVPN接続は(私の調べる限り)Windows Server 2012 R2では接続できず、Windows Server 2016以上が必要なようです。下記に方法を紹介します。 まずは、接続対象となる仮想ネットワークを作成します。 仮想ネットワークに対して「仮想ネットワークゲートウェイ」を作成します。このゲートウェイとVPNを接続することになります。 次に「ローカルゲートウェイネットワーク」を作成します。これは今回ですとWindows Server 2016に対応します。 次に「接続」を作成します。 接続の種類は「サイト対サイト(IPsec)」になります。 次はWindows Server 2016側の構成を行います。こちらはきちんとドキュメント、スクリプトが確認できませんでした。私は主に下記のコマンドレットを実行して構成しました。ここでAzure Stackの仕様にあわせるように細かくオプションを設定することがWindows Server 2012 R2ではできませんでした。 Install-WindowsFeature RemoteAccess -IncludeManagementTools Add-WindowsFeature -name Routing -IncludeManagementTools Install-RemoteAccess -VpnType VpnS2S Add-VpnS2SInterface -Name $SP_AzureGatewayIpAddress -Protocol IKEv2 -Destination $SP_AzureGatewayIpAddress -AuthenticationMethod PSKOnly -SharedSecret $SP_PresharedKey -Persistent -IPv4Subnet @($SP_Subnet) -AuthenticationTransformConstants GCMAES256 -CipherTransformConstants GCMAES256 -EncryptionMethod AES256 -PfsGroup PFS2048 -SALifeTimeSeconds 14400 -SADataSizeForRenegotiationKilobytes 819200 -MMSALifeTimeSeconds 28800 -CustomPolicy ...

セミナー用にvSphereからAzure StackへのCommvaultを用いた仮想マシンの移行デモ環境を作成しました。その中で行った「CommvaultへのMicrosoft Azure Stack Clientの作成」の方法を記録しておきます。 この作業を行うことによりCommvaultからAzure Stackを扱えるようになり、リストア対象にできるようになります。 事前準備 - Azure ADへのアプリケーションの登録 まず最初に行う必要があるのはAzure ADへのアプリケーションの登録です。Azure ADに慣れていない人だとこの部分で早速違和感を覚えてしまうかもしれませんね。 Azure StackはAzure ADを認証基盤として利用しています(AD+ADFSを使うパターンもありますがAAD利用がスタンダードです)。Azure AD上にアプリケーションを作成すると、そのアプリケーションがAzure Stack上のサブスクリプションに権限を持てます。そして、そのアプリケーションを利用してCommvaultが動作する仕組みになっています。 昔ながらのActive Directoryのアプリケーションであれば「サービスアカウント」を作成して様々なことを動作させていました。その「サービスアカウント」に相当するものがAzure ADにおける「アプリケーション」である、という理解をしておくのが良いかもしれません。 もっと詳しく理解したい方は下記を参照ください。 Azure Active Directory のアプリケーション オブジェクトとサービス プリンシパル オブジェクト | Microsoft Docs 今回のデモ環境作成時には様々な事情があって新規にAADアプリケーションの作成ができず、既存のものを利用しました。なので、スクリーンショット等ありません。すいません。この部分は非常に深い話なのでまた別途ブログエントリを書きたいなと考えています。 AADアプリケーションに関しての下記の情報が必要なので入手します。 アプリケーション(クライアント)ID- ディレクトリ (テナント) ID- オブジェクト ID- クライアントシークレット Commvaultへの「Microsoft Azure Stack Client」の作成 CommvaultにMicrosoft Azure Stack Clientを作成していきます。 これでAzure Stack Clientを作成することができます。この操作がうまくいくためには下記の条件が必要なので注意してください。 リソースマネージャURLは通常の管理ポータルのアドレスではなく https://management から始まるアドレスである。- Commvaultの「プロキシ」からAzure StackのリソースマネージャURLへのアクセスが証明書の信頼含めてきちんとなされている必要がある。- 「リソースグループが取得できること」によって接続成功を判定するので予め空でよいのでリソースグループを作成しておく必要がある。 ここまでできてしまえばあとは簡単にAzure Stackをリストア対象に選択することができるようになります。リストアの様子は下記の動画で紹介していますのでご覧になっていただければと思います。

4月27日に品川の日本MicrosoftさんのセミナールームにてAzure Stackに関する値段をやります。 Microsoft Azure Stack で、攻めの老朽化対策 - Windows Server 2008 や VMware の移行に向けた将来性のある選択肢 - | JBS 日本ビジネスシステムズ株式会社 今回はAzure Stackの魅力や良さは理解しつつも「ちょっと値段が高すぎて…、だって3千万も4千万もするんでしょう？とても予算的に手が出なくて…」と、値段が原因で手が出なかった方に「本当の値段」がわかるような内容にしたいなと思っています。 値段と言っても様々な観点があります。 ハードウェア料金- ラックや電源等含めた設置場所- 既存の環境と接続するための設計- ハードウェアを設置するための設置作業- 設置後にAzure Stackを構成するための作業- 構築した環境を実際に利用可能にするための構成- 構築した環境を運用監視- Update / Upgrade- バックアップ- 構築され運用されている環境をユーザーが利用するための仕組みを作る、回す- 可動したリソースに対して支払うライセンス費用- 基盤のオペレーターに対して支払う報酬- (既存環境から移行する作業) これまで単純に1だけの値段を見て「高い」という反応をされてしまうお客様も結構多かった印象です。1の値段が例えば5千万だろうと1億だろうと1～10トータルで長期的に考えたときの値段のほうが本質的に重要ですからAzure StackのTCOは本質的に圧倒的に安いというのが私の考えではあります。(※ただしそのためには「誰が何をするのか」という部分でのパラダイム・シフトが合わせて必要です。) ですが、今回のセミナーでは1の値段だけをみて「高い」と反応してしまっていた方にも「お？これなら先に進められるかも!」という感覚を持ってもらえるような値段が出せそう、ということで話が始まっています。 本当にセミナーに来てもらって、具体的な話が出来る方にしか伝えられない情報になりそうなので、是非お越しいただければと思います！ 申込みは下記からお願いします！ Microsoft Azure Stack で、攻めの老朽化対策 - Windows Server 2008 や VMware の移行に向けた将来性のある選択肢 - | JBS 日本ビジネスシステムズ株式会社

Azure Stackは何か管理者が対処することがあればAlertが発生しそれを教えてくれます。 私の印象としてはこのアラートは本当に最小限のみであり、Azure Stack自体の稼働に影響がないものは極力アラートとして表示しないように意図してアラートを設定しているのだな、という印象です。 一方で、必要があれば Test-AzureStack コマンドレットにてAzure Stackをテストすることができます。Update前の Test-AzureStack の実行は必須ですね。こちらのほうがかなり細かくAzure Stackをテストしてくれています。 そして、Test-AzureStackは結果をシンプルにPASS, WARN, FAILで表示してくれるのみなのですがもっと細かくその内容を確認したい、というマニアックな方もいらっしゃると思います。(私のように) この場合には、 Get-AzureStackLog -FilterByRole SeedRing を実行して得られる Azure Stack Validation Summary というHTMLファイルのレポートを参照することができます。 レポートファイル内はかなり詳細に状況を表示してくれます。 もちろんここで何がわかろうとも、わからなかろうとも、問題発生時にはMicrosoftさんのサポートへの問い合わせをすることになりますし、レポートをみてなにかがあっても直接手出しはできないし、する必要もないのですが、それでも、こういうの見ると楽しいですよね。

皆さんこんにちは。胡田です。 今回は珍しくPowerBIのお話です。私はPowerBIはデータ可視化ツールとしては以前からずっと便利に使っているのですが、PowerBI内でデータを加工したりすることはこれまで避けていました。なぜかというと「良くわからなくて、新しい方法を学ぶ時間が取れなかったから」です。 これは単純に言い訳なのですが、私はプログラムが書けるし書くことが好きなので、なにかデータ加工的な事をする必要がある場合にはデータベースの外側でプログラムで書いてしまいます。そして、データベースをプログラムで更新しちゃう。そして出来上がったデータベースに対してPowerBIを接続してしまえば必要な可視化が簡単にできてしまいます。なので、PowerBIの中でテーブルを定義して、データを操作して…ということはしなくてもどうにでもなったのです。 ですが、他の人と一緒にトレーニングも兼ねてちょっとした複数のcsvファイルを元にしたレポートを作成する機会があり、PowerBIで全部やりたいという希望がその一緒に作業する人にあったので、一緒に付き合うことにしました。 いや、勝手がわからなくて結構苦労しました（笑 というわけで、私のような「昔ExcelでVLookup関数を駆使して頑張ったことあったけどもうやりたくないなぁ…」と言っているような知識レベルの人に向けてPowerBIで戸惑ったところと理解したところを少し書いておきたいと思います。 理想的には「(昔の)Excelしか使ったことがない人に向けたPowerBIの導入記事」的な感じになるといいのですが、はて、さて。 私はこのあたり本気で初心者かつまともに勉強もせずいじって直感で理解しているだけなのでPowerBIをガリガリやっている人からするとレベルが低かったり効率が悪かったり、他にもっと適切なやり方があったりするのではと思いますが、そこは生暖かい目で見守りつつ、コメントで優しくアドバイスいただければと思います。 とりあえず好き勝手にデータを編集できない Excelでは新規にファイルを作るとシートがあり、セルがあり、適当な場所にいきなり値を書き込んだり出来るわけですが、PowerBIではそうはいきません。保持できるデータはすべてきちんと定義されたテーブルの形になります。データベースですね。 とりあえずまずは感覚を掴むためにテスト的にテーブルを作ってみて、データを書き込んで…と試してみたかったので、「データの入力」を行いました。 出てくるのは「テーブルの作成」画面です。このあたりはExcelよりもAccessに近いんですかね?すいません、Accessもほとんど使ったことなくてですね…。 で、この画面でテーブルを作成するのは特に違和感ありませんでした。 列を追加したり、複数レコードにしてみたり、はい。「読み込み」をクリックするとテーブルが作成されます。 ここまではまぁ違和感ないのですが、じゃぁ、このテーブルを編集したい！と思うと早速やり方がよくわからなくなりました。直接この画面では編集できないのですね。 これ、裏側ではすべて「クエリ」が作成され、それによってデータが読み込まれたということになっているようですね。 「クエリの編集」をクリックすると、このテーブルを生成したクエリを確認、編集することができます。 全部クエリで表現されるというのは面白いですね。Excelとは全く異なるアプローチです。 「ソース」をクリックすると再度テーブル作成のGUIが表示されました。なるほど。 １つのセルに「関数を書く」というアプローチではない このテーブルの作成画面は感覚的にはExcelに近い感じで操作出来るのですが、別に関数が書けるわけではないです。 こんな感じにExcelでの関数っぽい書き方をしてもたんに文字列になっています。 このあたりきちんとテーブルとして列の定義が厳密という感じでしょうか。Excelよりも列の型が厳密なSharePointの感覚に近いという印象です。 で、なにか関数を使って計算等したければ、新しい「列」を定義してその中で列の定義として関数を書いたり、テーブル全体に対して「メジャー」を定義するというアプローチになるようです。（間違ってたら突っ込みください。） 「新しい列」をクリックするとこのように列の定義を書くことができます。 これはセル１つに対して定義しているのではなくて、列全体の定義です。Excelとは違います。 ためしに”あ”と入力してみます。 今は２レコードしか無いですが、すべてのレコードの「列」には「あ」と入力されます。列の定義が「あ」なので当然ですね。あくまでも定義したが「列」であって、Excelのように１セルに入力したのでは無いことがわかります。 この列の定義の中では「同じレコードの他の列」を参照することができます。 ※「テーブル１」だと補完してくれなくて面倒だったのでテーブル名を「Table1」に変更しました。 補完してくれますね！ 「列」の定義をTable1の列１にしたところ、きちんと同じレコードの列１の値が入力されました。Excelだと他のセルの値を相対参照、絶対参照で自由に参照する事ができますが、PowerBI内のテーブルの定義ではそういうアプローチでは無いことがわかります。 で、この列の定義の中では「DAX式」が書けるのだそうです。なぜなら、そうやって怒られたから…。 DAX式を列の定義として入力してあげればいろいろと他の列の値なんかを使いながらデータ加工ができそうです。 リファレンスはこちらにあります！ - [Data Analysis Expressions (DAX) Reference - DAX | Microsoft Docs](https://docs.microsoft.com/ja-jp/dax/data-analysis-expressions-dax-reference) たとえば「列」に対して「列１」のテキストの左から３文字を入力してみます。 こんな感じに簡単に行なえます。 列の定義に書けるのがDAX式(DAX functions)ということを理解しておけばまずOKですね。 DAX式とPowerQueryは違うものなので注意！ ちなみに、DAX式とクエリの中で記載できるクエリの文法は全く別物なので注意が必要です。というか私は当初混乱しました。 こちらPower Query。「クエリ」の中で使うものです。 Power Query M function reference - PowerQuery M | Microsoft Docs ...

みなさんこんにちは。胡田です。Wordpressがメジャーバージョンアップしてエディタがかなり変更になり、戸惑っております。(慣れない…) さて、今回はAzure Stackの更新処理の素晴らしさについて…と、このネタはすでにこのブログでも書いた気がします。ですが、先日のHCCJPの第3回勉強会に合わせて動画を作成し、youtubeにアップロードしましたので改めて。 動画を見てもらうとわかってもらえると思うのですが、オペレーションは本当に簡単です。 テストする- (テストOKであれば)Updateのボタンを押す 本当にこれだけで、クラスタのホストノードがOSレベルで最新に刷新され、複数台動いているAzure Stackを構成するVM群も刷新されます。上で動いているユーザー作成のリソースもすべてライブマイグレーションで移動させながらの処理となります。 本当に私が昔からずっと夢見ていた 決め打ちの機器構成にしておけば構成組むのに悩まなくて済む- 構築作業も定型化、効率化、高品質化できる- 横展開できる- 構築も自動化できる- 更新も自動化できる というのが実現されているのがAzure Stackなんです。そしてさらに構築したシステム自体がセルフサービスポータルを備え、セルフサービスで勝手に利用してもらうことができるという現実。素晴らしすぎて涙が出ます。いままで自分が何十年も苦労していたインフラ周りの苦労は何だったのかと。 「こうすれば全部自動化出来るじゃん」ということは今までもずっとあちこちで言ってました。他の同業者さんの中にも同じような事を言っていた方はやっぱりおおくいると思うのです。でも、それを製品レベルできちんと仕上げちゃうというのはさすがMicrosoftだよなぁと思うのです。 本当にブラフ抜きで、Azure Stack相当の環境をAzure Stackを使わずに設計～構築しろっていわれたら数千万円レベルの費用では作れないと思います。更新にだってもちろん同じくらいの費用がかかります。そう思うとAzure Stackって本当に安いんですよね。 Azure Stackの絶対的な金額はもちろん高いのですが、でも、それって何と比べて高いんでしょう？Azure Stackが実現している範囲や運用まで含めたトータルのコストを考えた時に本当に高いんでしょうか？私は「圧倒的に安い」ことを確信しています。 「本当かなぁ？」と思う人は、是非、インフラを管理している管理者、あるいはベンダーに「全ホストOSの最新版への更新と基盤の全ミドルウェアの更新を、上で動いている仮想マシンを落とさずに作業する場合の期間と費用の見積もりをちょうだい」と言ってみると良いです。数ヶ月の期間をかけて数百万円～数千万円の費用がかかる見積もりが出てきますよ。間違いなく。本当に。 あるいは「まず調査、テストをしっかりしないといけません。そもそも停止時間なしで出来るかどうかも怪しいです。そのうえでの見積もりになります。でも、リスクなど考えると新規にシステムをside by sideで作成して、リソースを移動する手法をお勧めします」的な答えが返ってくるはずです。つまり「できない」「別でつくちゃったほうが確実で安い」という回答だって当たり前にありえます。 そんな現実がある中で、世界中のすべてのクラスタをボタン一発で更新できちゃう仕組みを備えているAzure Stackは本当に凄いです。この1点だけでもAzure Stackを導入する価値があると私は思うところです。だって、きちんとUpdateし続けないとセキュリティ的にやばいですよ。世の中の流れからも取り残されてしまいます。「作ったはいいけど更新できないシステム」沢山ありませんか？基盤が古くて新しいバージョンのゲストOSが動かせない基盤、ありませんか？更新できないのを言い訳するために「安定させるために基盤はいじりません」的なことを言ってませんか？ このあたり「うちは大丈夫！」って自信をもって言えるのはパブリッククラウドでPaaSを使っているところ以外にはほぼ無いだろうと思います。あるいはオンプレミスでAzure Stackを使っているところ、ですね。 この凄さ、伝わるといいなぁと思いながら動画を作りました。(あんまり伝わっていないと思いますが…。)

少し表現は異なるのですが「PaaSは勝手にアップグレードされてしまうのなら、どうやって事前にテストすればいいんでしょうか？」という趣旨の質問をたびたびされます。誰か特定の方に言われたから、というのではなく本当に多い話です。 - なにか変更を加える場合には必ず事前にテストをする - そのために本番環境とは別に本番環境を模した環境を用意している - まずテスト環境に変更を適用する、問題が見つからず全てテストが成功することが変更の絶対条件 というような運用を行なっている組織は実際のところ多いです。組織が大きくなったりシステムの重要度が上がってくるとさらに独立した環境がもう1つ、2つ増えるケースもあります。 このような組織では変更のためにかかる工数が大きく時間も必要なため、例えばWindows Serverを利用してシステムを構築しているけれども、セキュリティパッチも毎月は適用せずに数ヶ月に一度適用する…というような話もよく聞きます。 こうして、「変化」が稀にしかおきない、おこさない環境に慣れているとクラウドでは常識である「変化」に対して「知らないうちに勝手に環境に変化があるなんてどうやってテストしたらいいの？」という発想になると思います。この気持自体はよくわかります。 わたしも全てのシステムがクラウド上で変化し続けるようになるべきとはでは思っていないので、そういう「静的」なシステムおよびシステム運用があるのは良いと思うのですが、話をしているとそもそもAPIの概念を理解していないのでは?と思われる方もいらっしゃるのでその点に関してこのエントリでは書いておきたいと思います。 (ここからやっと本題です。) どのような種類の変化でもなにか破壊的なことが起こるのではないかと思って「全部テスト」という発想になる方もいらっしゃるようですが、基本的にクラウド等で発生する変化にはあるお約束があります。それは「APIは変化させない」ということです。違う言い方をすると「APIさえ変化させなければ内部では何がどう変更されても構わない」ということです。 APIという言葉はプログラマーの方でないと馴染みがあまり無いかもしれません。Application Programing Interfaceの略なのですが、まぁ、ここでは「インターフェース」としましょう。「インターフェース」が外部との連携窓口になっています。 例えばわかりやすい例として車を例にあげましょうか。車は免許があればどの車でも運転できます(大型車とかそういうのはいったんおいておきます。)。最近だと自動運転などに代表されるように、おそらく車の内部のデジタル化が進み、そうとう内部的な変化はおきていると思います。それでも、ハンドルがあり、アクセルがあり、ブレーキがあり、免許さえもっていれば車の運転はどの車でも同じようにできます。この時、人にとっての車のインターフェースはハンドルであり、アクセスであり、ブレーキです。車の世代が代わったらハンドルの形も使い方も代わってしまう…というのでは毎回免許撮り直しになってしまいますが、そういうことにはならない約束になっています。 ちょっと話を変えて、クラウド上にPaaSサービスとしてSQL Databaseがあります。例えば、Databaseに接続して、SQLクエリを実行してテーブルの中身を取得する事を考えてみます。この時、クライアントとSQL Databaseとの接続にはADO.NET、ODBC、 JDBC等のAPIが使われています。これらはクライアントとデータベース間の接続のために標準化されているものであり、いかにPaaS側が「勝手に変化」しようとも、この接続方法自体は担保しつづけます。SQLのクエリに関してもPaaS側が「勝手に変化」したとしても昨日まで通っていたSQLクエリが実行できなくなるような変化はおきません。「こんな便利な追加されました！」という変化はあっても「ADO.NETでの接続はできなくなりました！」という変化はおきないんです。というか起こさないんです。 これは、車の内部が変化したとしても、ハンドル、アクセル、ブレーキの使い方が全く変化してしまって免許を新システムで取り直さないといけないような変化は車メーカーが起こさないことと一緒です。 どんな些細な変化であってもかならずテストを事前にしなければいけないと考えるのは、どんな車のマイナーチェンジであっても、必ず事前に試乗して今までどおりに運転できることを必ず試さなければいけないと主張することに似ています。もちろんそれが現実的に運用として回せるのであれば一番安全だとは言えるでしょうけれども、場合によってはそこまでのテストをする苦労をかけるくらいであれば、万が一の時にそなえて車をもう1台用意しておくことでバックアップ手段とするようなやり方も考えられるでしょう。 PaaSの変化にもルールがあります。それでも、長い目で見ればAPIの変化も伴う変化が発生するタイミングもあるでしょう。PaaSの裏側でメジャーバージョンアップが行われるようなときです。このような影響が考えられる変化が発生するときにはクラウドのPaaSであっても事前に予告がなされますし、事前にテストをするための方策等がアナウンスされます。 どのレベルの変化の時に、どのレベルでのテストを行うのか、万が一の時のためにどのようなバックアップ手段を用意しておくのか。クラウドを使いこなそうと思ったらクラウド時代の流儀に合わせる必要があることは確かです。 例えば、仮想マシンでWebサーバーとDBサーバーがあり、アプリケーションも自分たちで書いているとします。この時に例えば、DBサーバーだけPaaSに置き換えた時に、今後PaaSのDBサーバーの自動的な変化(進化)によってエンドユーザーに影響がでる可能性というのは、わたしの考えでほぼ皆無です(※私ならWebサーバーまでPaaSに置き換えたって大丈夫でしょう、というかぜひそうしましょうよという感じではあるのですが)。でも、このレベルでも「ありえない！」という反応になってしまう方も多く、このようなエントリを書いております。なかなか難しいものです。

皆さんこんにちは、胡田です。何やら不穏なタイトルですが私が退職するという話ではありません。関係者の皆さんご安心ください（笑 今回のネタはかなりニッチな話なのですが、私の友人で下記の状況になって困ってしまった人がいました。それを受けてブログエントリを書きました。地味に重要な箇所だと思ってます。 - マイクロソフトアカウントに紐付いていたAzureサブスクリプションを退職前に全て削除したつもりが後日クレジットカードに請求が来てしまった - マイクロソフトアカウントで確認しようとしてももうサインインできなくなってしまった - パスワードリセットなども、もう以前の会社のメールが使えないのでできない この件では結局以前のメールアドレスを復活させる対応が必要となりました。このような事にならないために今回の話は理解しておいてもらえればと思います。 さて今回のお話は前提知識として下記を要求しています。記事を読んでよくわからない部分があった方は参照いただければと思います。 - [個人アカウントと組織アカウント | Microsoft Cloud Administrators](http://cloud.ebisuda.net/%e5%80%8b%e4%ba%ba%e3%82%a2%e3%82%ab%e3%82%a6%e3%83%b3%e3%83%88%e3%81%a8%e7%b5%84%e7%b9%94%e3%82%a2%e3%82%ab%e3%82%a6%e3%83%b3%e3%83%88/) 組織のメールには組織を抜けたあとにはアクセスできない さて、会社含めて組織に所属している中で、その組織に紐付いたメールアドレスで各種Webサービスのアカウントを作成することは数多くあることだと思います。マイクロソフト系のクラウド管理者だとかなりの高確率でマイクロソフトアカウントを**『組織のメールアドレスで』**持っていますよね。(※実はこれは現在ではもうできなくなっているのですが、昔からやっている人は持っている人が多いのです。) そして、「組織のメールアドレスがIDである」マイクロソフトアカウントはそもそも作成時に「自分がすでに持っているメールアドレスで作成する」という選択肢を使ってアカウントを作っているので、例えばパスワードを忘れてしまってリセットしたい場合や、新しい場所からサインインした時に追加で確認を求められたりする際には(追加でアカウントに電話番号を追加し、それを利用することもできますが)「組織のメールアドレス」に届くメッセージを使うことになります。 逆に組織の管理者であれば組織内のメールアドレスを自由に作成、削除、変更等できます。これは当たり前ですね。ですから「個人に紐付いているアカウントがたまたま組織のメールアドレスだった」という状況でも、組織の管理者は用意にそのアカウントを乗っ取ってしまうことができます。これってちょっと問題ですよね。なので、組織のメールアドレスで新規にマイクロソフトアカウントを作成することが(過去はできましたが)今は禁止されています。 マイクロソフトアカウントへのメールアドレスの追加方法 「マイクロソフトアカウントでIDとして使っているメールアドレスにアクセスできない」状況ではもう復活の手段がなくなってしまうことは理解いただけたでしょうか？ これを防ぐためには「組織のメールアドレス」にアクセスできているうちに、マイクロソフトアカウントのメールアドレス(これはつまりID自体なのですが)を変更する必要があります。このための機能がきちんと準備されています。 (2019/02/13時点の操作方法　※画面自体はすぐに変更になる可能性が高いです。) https://account.microsoft.com/profile/　にアクセス。 これを編集するためには下記のように追加で本人確認が必要です。ここを突破できるうちにメールアドレスを変更しておくのが肝なんです。 そして、下記のようにメールや電話番号を追加したり、プライマリエイリアスを変更したりなどの操作が行えます。 退職前にはここから個人でいつでもアクセスできるメールアドレスをまず追加し、その追加したメールアドレスをプライマリに変更するのが良いでしょう。さらに、個人でいつでもアクセスできる電話番号も追加しておくことも強くお勧めします。 注意 さて、ここまで書いておいて非常に申し訳ないのですが、実はこの対処を行って「プライマリエイリアス」の変更まで行うと、各種のサービスでおかしなことになる例がありました。私の場合には個人のマイクロソフトアカウントに紐付いているAzure EAポータル上のアカウントおよびそのAzureサブスクリプション周りでおかしな挙動になりました。 あきらかにMicrosoftさん側のバグだと私は思っているのですが…(サポートの方には伝達済み)。そのうち直ることを祈りつつ…。 このあたりの地雷を踏まないようにするためには、「プライマリエイリアスの変更」はそれが絶対に必要な場面において、最悪色々な悪影響が出てしまったとしても大丈夫な状況でのみ行ってください。念の為。 ※私は責任取れませんのであしからず…。 ただ、私自身の個人アカウントは実験も含めて10回くらいプライマリエイリアスの変更を実施して、現在問題なく動いているという事実はありますので、そこまで恐れなくてもいいかも？ 組織の管理者としてはやはり組織アカウントのみを使うべき このような問題も理解すると、より一層、組織としては「組織アカウント」を使うべきであり、「個人アカウント」はあくまでも個人利用のために使うことが望ましいことがわかります。 使えるからと言って、個人アカウントであるマイクロソフトアカウントを組織で契約しているAzure環境の管理者アカウントにしてしまったりするとのちのち面倒なことになります。このブログでも何度も繰り返していることですが、くれぐれもご注意ください。 でも、まだまだマイクロソフトアカウントでの使用例が後を絶たないんですよね…、このブログを見てくれている管理者の方は是非組織アカウントを使っていってもらえればと思います。 関連エントリ 下記のエントリも関連していますので、合わせてごらんいただければと思います。 - [個人アカウントと組織アカウント | Microsoft Cloud Administrators](http://cloud.ebisuda.net/%e5%80%8b%e4%ba%ba%e3%82%a2%e3%82%ab%e3%82%a6%e3%83%b3%e3%83%88%e3%81%a8%e7%b5%84%e7%b9%94%e3%82%a2%e3%82%ab%e3%82%a6%e3%83%b3%e3%83%88/) - [クラウド時代のマイクロソフト系インフラ管理者はまずAzure Active Directoryを理解し活用しましょう | Microsoft Cloud Administrators](http://cloud.ebisuda.net/%e3%82%af%e3%83%a9%e3%82%a6%e3%83%89%e6%99%82%e4%bb%a3%e3%81%ae%e3%83%9e%e3%82%a4%e3%82%af%e3%83%ad%e3%82%bd%e3%83%95%e3%83%88%e7%b3%bb%e3%82%a4%e3%83%b3%e3%83%95%e3%83%a9%e7%ae%a1%e7%90%86%e8%80%85/) - [アカウントの種類は何を使うべきか？ – チャットでいただいた質問への回答 | Microsoft Cloud Administrators](http://cloud.ebisuda.net/%e3%82%a2%e3%82%ab%e3%82%a6%e3%83%b3%e3%83%88%e3%81%ae%e7%a8%ae%e9%a1%9e%e3%81%af%e4%bd%95%e3%82%92%e4%bd%bf%e3%81%86%e3%81%b9%e3%81%8d%e3%81%8b%ef%bc%9f-%e3%83%81%e3%83%a3%e3%83%83%e3%83%88/) - [「マイクロソフトアカウントと組織アカウントを変換したい」という質問への回答 | Microsoft Cloud Administrators](http://cloud.ebisuda.net/%e3%80%8c%e3%83%9e%e3%82%a4%e3%82%af%e3%83%ad%e3%82%bd%e3%83%95%e3%83%88%e3%82%a2%e3%82%ab%e3%82%a6%e3%83%b3%e3%83%88%e3%81%a8%e7%b5%84%e7%b9%94%e3%82%a2%e3%82%ab%e3%82%a6%e3%83%b3%e3%83%88%e3%82%92/)

決してパスワードを生でコードに記載することはおすすめするものではないのですが、Exchange OnlineへのPowerShell接続ができなくて苦労している方をサポートする機会があったのでその際に作成したスクリプトを共有します。…といっても超簡単なものですが。 ドキュメントに書いてあるものそのままなので特に内容に関しては言及することもないのですが、今回の場合 - ドキュメントどおりに実行している - IDもパスワードも何度も確認した - 複数の端末でも実行した - ネットワークも複数切り替えた という切り分けを行っており、それでもうまく接続できない、という状況でした。 そこで、私がIDとパスワードを教えてもらってドキュメントどおりに試してみるとあっさりと接続できてしまう状況でした。 この場合 - なにかしらのドキュメントにも書かれていない超基本的な部分での前提条件の見落としがある - ドキュメントどおりに実行しているつもりができていない ID,Passwordのうち間違え - ドキュメントのスクリプトのコピーミス(ボタンもありますが…) - などなど - その他のなにか というくらいの可能性があるわけですが、1なのか、2なのか判別をつけることが重要だと考えました。なので、ドキュメントにかかれていることを全て単一のスクリプトに落とし、全く同じものを実行するだけで同じ結果が得られる状態にして1なのか2なのかの切り分けをするということに主眼をおきました。ですので、IDもパスワードも生で書き込んでそのままスクリプトを渡し、実行してもらいました。(※これでもまだPowerShellを管理者で実行しなくてはいけないとか色々ありますが、コンセプトとして。) 結果、今回の場合はスクリプトの実行では接続に成功しました。ですのでどこかはわからないですが、「2. ドキュメントどおりに実行しているつもりができていない」だったのだろうという事になりました。 これ、PowerShellスクリプトに完全に落とし込む手法じゃなかったらどれだけ丁寧に手順書が書かれていても手順書通りに実行されないリスクがあるんですよね。その点で完全にコードに落とし込んで確認できることは素敵だなと思うのです。 今回の例に限ったことではなく、可能であれば「コード」でのやり取りをインフラの管理者もするようにすると、コミュニケーションコストが低くなるケースはかなりあると思っています。もちろんInfrastructure as Codeという話もあるのですが、日常のオペレーションに関しても、です。 特にクラウドの時代になってほぼ全てのものがコードで表現できるようになりました。コードでなるべく表現することをベースにしていくことの価値や実現性は昔とは比べ物にならないです。個人的には、自分が行う作業は全てコード化するくらいの気持ちでいます。わたしの場合すぐに忘れてしまうので備忘録代わりでもあります。

皆さんこんにちは。胡田です。もう2019年ですしもうすぐ平成も終わりますね。私は最近あまりこのブログに記事をかけていませんが元気にやってます。将棋ウォーズがいつまでたっても2級のまま昇級でず苦しんでいます。将棋難しい…。 さて、マイクロソフトのクラウドサービスを利用しているといたるところで「テナント」という言葉を目にします。この「テナント」という言葉は結構曖昧に理解されていることが多く会話の中で様々な誤解を生んでしまう原因にもなっています。 このエントリでは「組織(＝顧客、会社)」と「テナント」の関係について整理しておきたいと思います。 Office 365の「テナント」 例えばOffice 365の契約を考えます。組織としての本番利用を考えるときには「組織」につき1つのOffice 365の環境を作成することが多いです。この時「組織」と「テナント」は1対1の関係となります。 「テナント」というのはサービスの1つの論理的なまとまりです。IDがあり、サービスがあり、データがあります。明示的な許可がなければ「テナント」の中にあるデータは「テナント」内で共有され、外部の「テナント」とは共有されません。 検証用の完全に独立したOffice 365の環境を本番環境とは別で保持したいという組織もあるでしょう。この時1つの組織に対して複数の「テナント」が存在することになります。 このブログでも繰り返し言及していますが、マイクロソフトのクラウドサービスの根幹はAzure Active Directoryにあります。事実上「テナント」というときには「Azure Active Directory」とそれに紐づく各種サービスという意味になります。ですので、「テナント」を指し示すのにはAzure ADのテナント名(xxxxx.onmicrosoft.com)やGUIDを使用します。 例えば私が管理しているhccjp.orgという「テナント」を見てみましょう。下記はAzure管理ポータルからアクセスしたAzure Active Directoryの管理画面です。 このAADはもともと「ebisuda.onmicrosoft.com」というテナント名で取得しました。その後hccjp.orgというドメイン名を追加し、プライマリに変更しています。 このテナントにはOffice 365も連携されています。エンタープライズアプリケーションの一覧を見てもらうとそれがわかります。 HCCJPは個人管理ではありますが、「テナント」としてAADとOffice 365がある状況がおわかりになりますでしょうか。 Azureの「テナント」 Azureに関してはOffice365と異なり、Azureサブスクリプションに対して「ディレクトリの変更」という操作すら行えてしまいますのでAADを軸として1つの「テナント」として考えることはできません。 契約の単位で管理されて入るのですが、サブスクリプションを契約間でコンバートすることもできてしまいます。 Azureに関しては実際のところ「テナント」という表現はほぼ使われないだろうと思います。Azureに関して会話をしている中で「テナント」という言葉が出てきたらそれがAzure Active Directory(＋Office 365, Dynamics 365等)を指しての言葉なのか、Azureのサブスクリプションを指しての言葉なのか等、しっかりとその意図するところを確認する必要があるでしょう。 「テナント」という言葉は注意して使いましょう というわけで、今回はなんだか締まらない内容になってしまいました。それだけ曖昧な言葉であるということです。話し手、書き手の意図をきちんと確認し、思い込みで誤解を生まないようにしていただければと思います。

皆さんこんばんは。胡田です。読めない人も多いとは思いますが「えびすだ」です。 最近「何を勉強しておくと良いでしょうか」という話を学生さんとか駆け出しの管理者さんによくもらうのでブログで回答させてもらいます。 ちょっと昔話から…。 私は小学生の時には親戚のお兄ちゃんからもらったMSX2でBASICやマシン語でゲームを作って遊んでいました。高校入学とともにPC(DOS/V)を購入してもらってWindows 3.1をいじったりC言語を勉強したりVisual Basicをいじったりもしました。大学では情報科学を学びつつ、オブジェクト指向プログラミングやUNIX、サーバー等に触れました。自分でWebサイト構築なども1998年から行っていました。2002年にはSIerに入社し、Windows Server関連のインフラ関連の仕事を多く行いました。Windowsクライアントを大量に展開し、Active Directoryを構築し、Exchange Serverを構築し…。 ここまでには「クラウド」という単語は出てきません。そもそも「クラウド」という単語もない時代も長かったですし。ですが、今では一番ちからを入れて追っているのはクラウドの話ですし、その進化の速度も圧倒的なものになりました。なにかイベントがあったときに何十個もサービスのUpdateが発表され、新サービスが出てきて…、もう追いかけきれない状況です。１つの製品の新バージョンがでたらゆっくり３～５年位はそれが最新版であり続けた昔とはもう全くスピード感が異なります。 この圧倒的なスピード感で物事が移り変わっていくクラウド時代に管理者は何を学ぶべきなのか、何を抑えておくべきなのか、どのような知識が長く使えるのか。そこを抑えておかないと変化の速さに圧倒されて呆然としてしまうと思うのです。 これは極論かもしれませんが私は個人的に「サービスの変化」を追いかけるのはあまり意味がないと思っています。このサービスは今何ができる、今何ができない、それはもちろん重要なことではあるのですが、ちょっと時間が経つと変わっちゃいます。もちろん現場への導入を勧めている中でなにかしら制限事項があるのであればそれをきちんと把握しておいてそこを回避する設計ができること、運用ができることはものすごく重要です。それでも、すぐに変化するんですよね。 私も昔自分がそうだったから気持ちはよく分かるのですがものすごい重箱の隅をつついて「XXXができないからこのサービスはだめだ」という話をするエンジニアがいます。いや、実際今現在はそうなんでしょうけれども。でも、それって半年後、１年後はどうなんでしょうか？それが本当に良くないポイントであるならば世界中から要望が上がって、改善されるんじゃないんでしょうか？改善されないならそれは要望がすくなかったということでそのポイントを回避するうまい使い方があるんじゃないでしょうか？ クラウド時代にはサービスはどんどん改善され続けます。新機能も出てきます。重要なのは「今」のことではなくてそのサービスが、サービス提供者が目指している理想の姿、ビジョンを理解することだと私は思います。サービスの目指すべきビジョンって何年も前に外部にも公開されてるんです。私何年も前からよく引き合いにだしているものの一つは下記のキャッチフレーズです。 Identity is the new control plane これは2015年6月12日にAzure Active Directoryのチームブログで表明されていたものです。なるほどなぁとおもって私がその数日後に書いたブログ記事が以下です。ちょっと読んでいただけると「今でも通用する話である」ということが納得してもらえると思います。 - ["Identity is the new control plane" Windows 10とAzure ADとIntuneで作れる素敵な世界 | Windowsインフラ管理者への道](http://ebi.dyndns.biz/windowsadmin/2015/06/19/identity-is-the-new-control-plane-windows-10%E3%81%A8azure-ad%E3%81%A8intune%E3%81%A7%E4%BD%9C%E3%82%8C%E3%82%8B%E7%B4%A0%E6%95%B5%E3%81%AA%E4%B8%96%E7%95%8C/) もう何年も前からビジョンがきちんとあり、そこにむかってサービスは進化し続けてきているわけです。2018年もそろそろ終わる今日このごろですが、ここで言われていることもまだ100%実現、普及したわけではないですよね。でも、ずいぶんとビジョンに実装は追いついてきています、そしてサービスもきちんと普及してきています。今の状況があることはもう何年も前に予告されていたんです。 ですから、私としては細かくサービスの新機能や変化等を追いかけなくても「あ、その機能まだ実装されてないんだ。」「あ、やっと実装されたんだ」というくらいの感想を持ちながらたまに進捗具合を確認するくらいの感じでこの領域を見ていました。 変化の激しいクラウド時代には日々変わっていく細かいサービスの変化を追いかけるのではなくビジョンを理解したうえで「使えるところから使っていく」「サービスの改善に合わせて使い方を変えていく」というスタンスを取ることが非常に重要だと思います。 「今どうなっているかきちんと比較しろ、比較表をつくれ！」「○✕をつけて「今」一番良いものを選択しろ！」「一度使いだしたらもう何も変えるな！」なんていうノリでは話になりません。 そして、そんな変化の早いクラウド時代においてもずーっと変わらないものもあります。それは「プロトコル」です。今でもWebページを見るのにはHTTPを使いますし、メールのやり取りにはSMTPが使われています。TCP/IPで通信しています。これってもう10年も20年も(バージョンの変化は有るにせよ)変化していませんし、これから先もまだまだ使われます。プロトコルだからこそ複数のベンダーをまたいで相互作用できますし、別製品同士でもやり取りが行えます。これは「サービス」とは決定的に違うところですね。 クラウド時代の管理者としても基本的なプロトコルを抑えておいて全く損はありません。なにせその知識の寿命の長さが違います。 基礎力はプロトコルレベルで抑えておき、サービス利用にあたってはそのビジョンを理解した上で「今」ではなく長い目をみて選択していく。そういうやり方が今求められているのだと思います。 あ、あと、プログラミング力はもちろん必要です。言うに及ばず。

AWS Outpostsが発表され、Microsoft Azure Stackとの比較論が出ていたりもします。どちらがいいか…を直接比較…とか比較するのはちょっと違う…とかいろいろ話も意見もありますが、そんなことよりもずっと本質的に大事だと私が思っていることがあります。それは「そのインフラが設計、構築、維持運用されるためにどれだけのコストが払われているのか」ということが大事なんじゃないかということです。 私はインフラエンジニアとして単一システムのための個別の環境を構築したり、統合仮想基盤を構築したりした経験があるのでよくわかっているつもりなのですが、「個別にものすごい労力を割いてシステム、プラットフォームを構築、維持管理している」状況があちこちにあります。そして個別最適化されているので知識の属人化が進み下記のような状況が当たり前のようにあります。 - XXさんじゃないとどうなっているかわからない - システムに変更加えようと思うとどこで何が起きるかわからない - 変更加えるためには徹底的なテストが必要 - でもそもそも全く同じテスト環境は構築できない - 『触らぬ神に祟りなし』なので何も更新しない - 脆弱性があっても修正しない - パッチ当てるにしても人間が一つづつ手作業で目視確認しながら作業する - プラットフォームが古いので新しいOS等に更新もできない - でも、よく考えると単に仮想基盤があって仮想マシンが動いているだけ… - 個別に最適化してしまっているので他社で培われたノウハウも展開できない 結果、あるシステム、プラットフォームにかかっている「コスト」はものすごいことになっているケースが多いです。それはハードウェアの話もありますが、むしろ人的コスト、消費されている時間の方が圧倒的に「やばい」と思っています。 一方、パブリッククラウドに目を向けると…、かなりの部分が隠蔽されているので不明な部分も大きいですが下記のような状況があります。 - 一般的なオンプレミスのシステムの規模は比較にならないような圧倒的なスケールで標準化されている(はず) - 通常のオペレーションも大規模に自動化されてなされている(はず) - セキュリティ対策も一般的なオンプレミスの環境とは比較にならないレベルで徹底、統一化されている(はず) - 世界トップのエンジニアたちのノウハウが投入され続けている - 最新のサービスを提供するように更新され続ける 例えば同じスペックの仮想マシンを1台動かすことを考えます。そのときにその基盤となる環境にかかっている人的コスト、消費されている時間はオンプレミスの方がパブリッククラウドの何倍、何百倍、何千倍、下手したら何万倍のオーダーでかかっているだろうと思います。1人のエンジニアが何台動かせる基盤の面倒を見ているか、何人が使えるシステムの面倒をみているかという尺度でも良いと思いますが、正しいデータが出せずに申し訳ないですがもう圧倒的であることは火を見るよりも明らかです。 かけたコストの分だけオンプレミスのシステムにて特別な差別要素のあることをしているなら意味もあるのでしょうけれども、結局やっているのは「サーバーを塩漬けで動かしてます」という話だとそれって単純に貴重なリソースの無駄遣い…ですよね。 その観点からすると、「差別化する必要があるものに関してはオンプレミスで自分たちで手をかけてやる」「差別化する要素がない部分はもっともコストが低いコモディティ化したもので良い」ということになります。 で、やっとAWS OutpostsやMicrosoft Azure Stackの話になるのですがこれらは究極的に「標準化」されているものなんです。個別に設計するのではなく世界規模で標準化されています。そしてパブリッククラウドのノウハウで標準化されているんです。更新だって勝手にやってくれたり、ボタン一発だったりします。テンプレートやコードだって世界で共通のものが動いちゃいます。これってインフラ構築で個別に苦労したことのあるエンジニアがみんな思う「共通化できたらみんな幸せになるのに」というシステムの1つの形だと思います。それを個別の組織レベルではなく、世界規模で行っているわけです。 そして、どのくらい時間がかかるかはわかりませんが「そういえば昔は個別に基盤構築していたよね」という時代が来ると私は確信しています。それはコンピューター製造に共通企画がなかった所から共通規格ができたように。標準的な通信プロトコルがなくて独自プロトコルが乱立していたところから共通規格ができたように。もちろんニッチな所、本質的に標準化できないところではそれはいつまでも残るのですが「全部まかせといていいよね」という話になります。これは「クラウド時代に「買って済ますべきもの」と「自分たちですべきもの」 | Microsoft Cloud Administrators」で書いたことと基本的に同じ考え方です。 結局何が言いたいのかというと、「自分たちでいちいち個別にプラットフォームを構築、維持管理する必要が本当にあるのですか？よく考えたほうが良いですよ」ということです。そうだね、って気がついた人はパブリッククラウドを利用するのでしょうし、どうしてもオンプレミスという場所にシステムを置く必要があるのであればOutpostsやAzure Stackを利用するようになっていくと思います。むしろそうならなければ行けないと思っています。 とはいえ、Outpostsが登場するのはまだ先ですし、Azure Stackも(組織サイズが大きくないと)値段が高すぎるし…ということでまだまだだと言うことには現時点では同意します。でも、きちんと先をみて、「世界標準のプラットフォームへの対応」を組織としても、エンジニアのスキルセットとしてもしておくべきだと強く思うところです。 この文脈においてOutpostsもすごく人気がでて普及してほしいですし、私が個人的に多くの時間を投資しているAzure Stackの普及も進んでほしいと思っています。「個別の無駄な苦労」はしなくて済むならそれでいいと思うのです。 #ちょっと極論を強い口調で書きすぎたかもしれません。気分を害された方ごめんなさい。