Azureのコスト最適化とセルフサービス

最近仕事の一つとしてAzure利用の無駄を調べて利用料金を最適化する事をしています。 Azure自体種類が沢山ありますし利用料金の取得はそれぞれ色々な手法がありますが、料金の無駄を省く…という観点だとEA契約を対象にすることが多く、まずはAzure EAポータルからAPIキーを使って利用料金を取得する手法であれこれするのが良さそうです。 個人的に一番やりやすいと思っているのはPowerBIと連携してレポートを作成する手法です。データ連携は簡単にできますし、あとはPowerBIの豊かな表現力を使って自由にさまざまな切り口で利用状況を可視化する事ができます。 EA Azure自体で適切に部署、アカウント、サブスクリプションの構造を作成するのがまず必須事項で、その上でその切り口で情報を可視化するのが良いです。 さらにリソースグループやタグを使った構造を採用しているならその切り口でもみられるようにするビューも必要ですね。 もちろんこの辺りはcloudyn(Azure Cost Management)を利用するのでも良いです。 で、ここまではいいのですが、「本当にこのVMのサイズは適切なのか?」というようなところまで踏み込もうとするとAzureのサブスクリプション自体に権限を持たないといけません。権限を持てば CPU, Netwotk, Storageがどの程度実際に使われているか(使われてなければサイズを下げるべきかも)- アタッチされていないVHDファイルなども見えてきます。 この辺りの情報を元にAzure Cost Management では最適化候補をレポーティングしてくれます。(もちろん全てそのまますぐに指示に従ってやればいいとはならないのですが) が、このAzureサブスクリプションに対して権限を付与する操作周りがとても大変です。 そもそもAzureはセルフサービスでバンバンサブスクリプションを作って各種サービスを使ってシステムを作っていくことができます。その自由さやスピードが1番の良いところだと私は思っています。 が、多くの人がそれぞれバラバラに作成したサブスクリプションに対して管理者が漏れなく権限を持つ、それによってサブスクリプション内部まで情報を取得して無駄を発見する…ということができないのです。 組織の管理者であっても、誰であっても、サブスクリプションの所有者によって明示的に権限を付与されなければ何もできない構造になっています。 利用者が全員技術的にしっかりと理解した人なのであれば完全に任せておくだけで良いのでしょうけれども、現実的にはなかなか難しく。コストを支払う部署なり、人なりがきちんとその責任でもって使っているのだからこれでいいのだ!というように割り切ればそれでおしまいですが、やはりこのあたりはコントロールしたくなる人の気持がわかります。 で、よく考えるとCSPではこのようなことが発生しない構造になってるんですよね。サービスプロバイダーは全ての顧客の全ての環境に権限を持つことができます。 さて、Azure EAにおいても管理者が全てのサブスクリプションに対して監視のための権限はもちつつ、セルフサービスのスピード感も損ないたくない…という時にそれが可能なのかというと…別途System Center Service Managerですとか、もう一枚仕組みを噛ませば簡単に実現できますね。 ユーザーは申請を出して、全自動でサブスクリプションが発行されるけれども、同時に組織の管理者にも権限がわりあたっている…そんな状況が理想なのかもしれません。 と、思いながら今日も権限くださーい。あるいは、サービスに権限つけてくださーい。とお願いして回るのでした。

January 26, 2018 · 1 min · 胡田昌彦

すでにインターネットにつながっている環境で「制限」することの意味

私の意見はちょっと過激かもしれませんが…一応何処かではしっかりと書いておく必要を感じるのでまずブログに書いてみます。 私は個人的に「すでにインターネットにつながっているなら下手に『制御』しようとしても無駄どころか悪影響」だと思っています。 例えばどんどん出てくる様々な便利なサービス、特にクラウドサービスがある時にそれを使わせるかどうか企業のIT担当者としてはもちろん考えると思いますし、場合によっては制限をかけるということをすると思います。 組織外部の人間と無制限に情報をやり取りしてはなにかセキュリティ事故がおきてしまうかもしれないから制限しよう…、特定の信頼できる組織とだけつながるようにしよう…。発想としては自然だとは思います。 でも、すでに「Webサイトにつながる」とか「全世界とメール送受信できる」環境がそこにあるのであれば(これ、結構普通にありますよね)、やろうと思えばどんな会話だって世界中の人とできちゃうし、ファイルだって共有できちゃうし…、もうなんでもありの状況ですよね?あとはそれがどれだけ便利なのか、不便なのかという話です。 でも、メールは許可しておきながら、あのクラウドサービスはダメだとかそういう話をしている組織ってすごく多い印象です。HTTP, HTTPSで外部に通信できる時点で技術的にはもう何でもありですよね?外部のサービスを使うにしても、VPNでどこかと繋がっちゃうにしても…。もちろんProxyで監査してるとかメールサーバーで監査しているとかそういう話はあるとは思いますが、結局いたちごっこですし「面倒だけど抜けられる」ものです。 インターネットからも完全に隔離されている環境であれば意味はもちろんあると思うのですが、でも、もう個人が全員スマートフォンを持ってる時代なので、会社のオフィシャルな場でやりづらければ個人で勝手に別のネットワークを使っていろいろとできちゃいます。 「守るべきポイントはそこじゃないよな」と思うところが多くあります。 むしろ組織として少しでもガバナンスを効かせうる組織公式のサービスをどんどん便利にして使ってもらって、外部とも連携可能にして、何かあった時にコントロールが効く状況を作るほうが正しいと思うんです。 昔と違ってクラウドサービス間の連携はものすごくやりやすくなってますし、全てをオープンにしてそこで生み出される情報を活用する方向に舵を切ることで生産性も上がると思うんですけどね。 そしてその上で、狙われたらまずやられてしまう世の中にもうすでになってしまっているので、セキュリティ的にまずい状況になることをを前提に物事を組み立てたほうが現実的だと思います。 皆さんはそう思わないでしょうか?

January 17, 2018 · 1 min · 胡田昌彦

Windows10が(再び)勝手にスリープする / Surface Dock経由の電力供給が足りない

Windows10が使っている最中にスリープしてしまう現象が以前発生しておりまして。一度下記の記事の内容で対処していました。 Windows10が数分で勝手にスリープする原因と解決方法 内容は「System unattended sleep timeout(システム無人スリープタイムアウト)」という隠し項目を電源オプションに対してレジストリを編集して追加し、その値を設定する、というものです。 私の場合は120分に設定してあります。 が、この設定にしているにもかかわらず何度もすぐにスリープしてしまう事象が発生し…おかしいなぁと思って再度確認してみました。 イベントログにてシステムイベントを確認すると、ソースがPower-TroubleShooterの以下のイベントが…。 ログの名前: System ソース: Microsoft-Windows-Power-Troubleshooter 日付: 2018/01/15 10:35:55 イベント ID: 1 タスクのカテゴリ: なし レベル: 情報 キーワード: ユーザー: LOCAL SERVICE コンピューター: xxxxxxxxxx 説明: システムは低電力状態から再開しました。 スリープ時間: ‎2018‎-‎01‎-‎15T01:35:27.642739500Z スリープ解除時間: ‎2018‎-‎01‎-‎15T01:35:53.793083800Z スリープ状態の解除元: 不明 イベント XML: 1 2 4 0 0 0x8000000000000000 42390 System xxxxxxxxxx 2018-01-15T01:35:27.642739500Z 2018-01-15T01:35:53.793083800Z 2440 1292 968 0 5677 2998 456985 33571073 5 5 0 0 0 0 0 ...

January 15, 2018 · 2 min · 胡田昌彦

Office 365グループの一覧とメンバーを取得するPowerShellスクリプト(多要素認証対応)

Office 365グループの一覧とメンバーを取得してExcelに貼り付けるちょっとしたお仕事がありました。 WebUIを使って目で見て転記する方法だと気が遠くなるくらいの時間がかかりそうだったので、ちょっとPowerShellでスクリプトを書きました。 スクリプトを動かすためにはExchange Onlineへの接続が必要で、多要素認証が有効化されているアカウントの場合には"Exchange Online Remote PowerShell module"モジュールの事前インストールが必要でした。 多要素認証を使用して Exchange Online PowerShell に接続するなお、このモジュールのインストールをfirefoxからダウンロード、インストールしようとして全然できなくて困ってしまいましたが、Internet Explorerから実施したところ成功しました。皆さんは時間を無駄に使いませんように…。 スクリプトに、出力先のファイル名(***.csv)を指定して実行すると、情報を取得したうえでCSVファイルを生成します。 日本語環境でCSVファイルを開いてそれなりの見た目で表示されることを意図しているので、文字コードはあえてSJISにしました。なので、CSVファイルダブルクリックのみでそれなりにExcel上で表示されます。 1番(無駄に)苦労したのは文字コードと改行コード周りでした。 一度Add-Content –encoding Stringした状態のファイルに後から追記した時の文字コード、改行コード周りの挙動が意味不明過ぎてくじけたので、全行変数上で出力結果を保持した上で、一発でAdd-Contentしています…。 ソースはGithubにあげています。 https://github.com/ebibibi/AzureManagement/blob/master/AAD/ListGroupsAndMembers.ps1多分むやみに需要あると思いますので、お使いいただければと思います。

December 19, 2017 · 1 min · 胡田昌彦

「この ms-excel を開くには新しいアプリが必要です」への対処

おそらく先日Microsoft Projectを追加インストールしたのが原因だと思うのですが、TeamsよりExcelが開けなくなってしまいました。 プロトコルへの関連付けをしないといけないです。 Excelもきちんと関連付けされていないことは認識しているようです。起動時に教えてくれます。 でも、ここで「はい」を押すと、自分で設定してねと言われます。 でも、[設定] > [システム]の中にはその項目はありません。(環境によります) 私の環境だと、[設定] > [アプリ]が設定の場所ですね。 「プロトコルごとに規定のアプリを選ぶ」を選択します。 すると、そもそも「MS-EXCEL」がありませんでした。 コントロールパネル側から見ても、プログラムにExcelが表示されません。 仕方がないので、Office 365 ProPlusを修復することにしました。 修復完了。 これで、きちんと「MS-EXCEL」プロトコルが登録され、Excelが起動するようになりました。 この結果からすると、おかしくなったら、あまり悩まずにとりあえず修復をかけてしまってそれでもうまく行かなかったら、そこからトラブルシューティングを開始するという手順が良さそうです。 プロトコルの関連付けをデスクトップ Office に切り替える - Office サポート

December 8, 2017 · 1 min · 胡田昌彦

VMWare on Azure周り

MicrosoftからVMWareのベアメタルソリューションをAzureにて提供する、という話があって驚きました。 Transforming your VMware environment with Microsoft Azure | ブログ | Microsoft Azure 私の理解ではMicrosoftの戦略の中心は「クラウド化」にあるのであり、VMWare(Hyper-Vも同じ位置づけ)によるものは「仮想化」であってそもそも注力する領域ではない…と思っていましたのでこの発表には「え?そこやっちゃうの?」という驚きがありました。 もちろん、現場からのニーズはそこに強くあるとは思うのですけどね。 以下は私なりのMicrosoftさんのクラウド化戦略に関しての解釈です。 と、思ったらVMWareさんから「お勧めしないし、サポートもしないよ」というコメントが出てました。 Article Detail - VMware Blog VMWareと組んでVMWare on Azureを実現するという話なのかと誤解していましたが、そうではないようですね。ある意味納得です。

November 28, 2017 · 1 min · 胡田昌彦

Azure Stackに関して3つのイベントでお伝えしたこと

今日、Equnixさん、HPEさん、MicrosoftさんとJBSの4社でのAzure Stackのセミナーを実施させてもらいました。これで10月16日のセミナー、11月8、9日のTechSummit、本日11月21日のセミナーと立て続けに3回、Azure Stackをテーマに登壇させてもらいました。あと、実はこの間にある企業様へのプライベートセッションで2時間喋らせてもらってるので、実質は4回ですね。 これだけ短期間に繰り返し喋らせてもらっていますが、自分の喋ってみての感じですとか、そのイベントに来てくださるお客様をイメージして喋る内容や実施するデモ内容は毎回変化させています。同じ内容だと自分が飽きちゃうというのもありますし(笑 今日の登壇内容のサマリーは以下のような感じになりました。 「クラウド化」による変化高い生産性- 継続的な進化- 管理の委任- クラウド≠場所- クラウド=方法論- Azure = Azure Stack =クラウド- 未来のシステムはハイブリッドクラウドであり、SaaS, PaaSを積極活用する方向- Azure / Azure Stackの組み合わせは「同じ方法」が使えるところがユニークである- Azureはそもそも複数種類あり、Azure Stackもその1種類である- Azureをすでに使っているユーザーも使っていないユーザーも、Azure Stackを有効活用できる- Azure Stackの導入は非常にシンプルなので、むしろその配置場所や電源容量の確保、既存環境、クラウドとの接続性のほうが導入においては重要- 導入後はAzure Stackがデータセンターを抽象化するため、開発手法を劇的に変化させることが可能- 世界中の開発者との共同開発も可能- Azure / Azure Stackのエコシステムへの参加によるメリットは非常に大きいちょっとこれだけだと何のことかわからないかもしれませんが、おいおいブログでも詳しく書いていきたいなと思います。 ですが、改めてこのように自分がまとめて書いたものを見返しながら、思い出すのはWindows Server 2012登場のころにシドニーで聞いたJeffery Snover氏の話です。そのころはWindows Server 2012がでるぞ…!というタイミングで今の状況とは全く違う状況でしたしAzure Stack…どころかAzure Packもまだお目見えしていない頃だったのですが、そのときに目指す方向として聞いた話がまさに今Azure Stackという形に具現化されたのだなと改めて思います。 きちんと明確なビジョンを描きそこに対して実装を何年も続けていくというのは本当にすごいなと思います。きちんと未来が見えている人の言っている話はきちんときいておくに限りますね。

November 21, 2017 · 1 min · 胡田昌彦

11月21日火曜日にAzure Stackのセミナーを行います!

最近はAzure Stackにどっぷりの胡田です。週明けの11月21日火曜日の午後はEqunixさん、Microsoftさん、HPEさんと一緒にAzure Stackのセミナーを行います! セミナー概要日時:2017年11月21日(火) 15時 - 19時30分(14時30分 開場)会場:日本ビジネスシステムズ様 セミナールーム東京都港区虎ノ門 1-23-1 虎ノ門 ヒルズ森タワー16階対象:社内情報システムのご担当者様、システムインテグレーター様、クラウドインテグレーター様 お申込み方法:http://info.equinix.co.jp/AzureStack_Reg_LP.html 14:30 –開場15:00 – 15:05ご挨拶エクイニクス・ジャパン株式会社 徳久和幸15:05 – 15:50Azure Stackが導く真のハイブリッドクラウドへの道 日本マイクロソフト株式会社パートナー事業本部 パートナー技術統括本部 パートナーテクノロジーストラテジスト 高添 修様 15:50 – 16:25解説 「HPE ProLiant for Azure Stack」 その実力とは 日本ヒューレット・パッカード株式会社 シニアソリューションアーキテクト 辻村 洋太郎様16:25 – 16:35休憩16:35 – 17:10ハイブリットクラウド構築の先を行くデータセンターとは!? エクイニクス・ジャパン株式会社 グローバルソリューションアーキテクト 鈴木 康之17:10 – 17:55Azure Stack有効活用案とデモンストレーション 日本ビジネスシステムズ株式会社 パートナーアライアンス本部 クラウドアライアンス開発部 部長 胡田 昌彦様 (Microsoft MVP for Cloud and Datacenter Management)17:55 – 18:00御礼日本ビジネスシステムズ株式会社執行役員 パートナーアライアンス本部長 三浦 剛志様18:00 – 19:30懇親会私も登壇させてもらいます。現在HPEさんの「HPE ProLiant for Microsoft Azure Stack」をEquinixさんのデータセンターに導入中なので、その中で出てきた導入時のポイントも含めて、お伝えさせてもらいます。 ...

November 17, 2017 · 1 min · 胡田昌彦

Azure Stack上ではAADを認証基盤につかいましょう!

日経SYSTEMSの2017年9月号のAzure Stackに関連する記事に私のコメントも掲載されています。 日本ビジネスシステムズの胡田氏は「Azure StackでID管理に用いるAzure Active Directoryは、ユーザー企業のオンプレミス環境で一般的なActive Directoryとは別物。混乱を招く恐れがある」と指摘する。私も、Web上や雑誌上でも記事を書いたり、インタビューを受けてコメントが掲載されたりなどかなり露出がふえており、大変ありがたいことです。私は人生の生存戦略において、外部露出を増やす戦略でやっていますので実名でこのように雑誌記事にコメントがのるのは大変ありがたいことでして、是非インタビューでもなんでもお声がけいただければと思います。 と、大変ありがたい話ではあるのですが、流石に短い紙面でこのコメントだけ掲載だと相当の誤解を産んでしまうのも致し方がないところだと思います。このコメントに関しては追加で補足をさせてもらおうと思います。 まず、Azure StackでID管理にAzure Active Directoryを用いるというのは半分正しく、半分正しくありません。Azure Stack自体へのアクセス、特に管理ポータルへのアクセス時に使うIDはAzure Active DirectoryとADFSのどちらかが選択可能です。推奨はAzure Active Directoryであり、つまりはクラウド上のIDですからインターネット接続が行えることが前提条件となります。Azure Active DirectoryのIDということはつまりはO365で利用しているIDとも共通とすることができるわけであり、Microsoftの戦略からするとクラウドIDの中心としてのAzure Active Directoryを軸に全てのクラウドサービスをコントロールしようとしていますので、Azure Stackもその1つということで何も違和感がありません。 ただ、一方で「インターネットには接続させない、クラウドサービスは利用できない」という環境ではAzure Active Directoryを使うことはできませんから、そのためのオプションとしてADFSおよびADFSと連携するActive DirectoryをIDとすることもAzure Stackでは可能となっています。この場合、「ユーザー企業のオンプレミス環境で一般的なActive Directory」のIDをそのまま利用可能となりますから、何も混乱なく利用可能となります。 さらにいうと、企業においてAzure Active Directoryを利用する場合にはそのIDはオンプレミスのActive DirectoryとAD Syncにて同期されているケースが非常員多いため、Azure Active DirectoryをIDとしている場合でも、それは事実上Active DirectoryのIDと統一であり、混乱を招くようなものではないケースが多いでしょう。 記事上では表現されていませんが、私が危惧している心配はAzure Stackのマネジメントポータル利用時のIDではなく、Azure Stack上に構築されるシステムへのアクセスに利用されるIDに関してなのです。 もちろんAzure Stack上にIaaSを利用してWindows Serverを展開し、そのWindows Serverを既存のネットワーク上のActive Directoryにドメイン参加させ、いつもと同じようにAD統合認証でシステムを作成する…、これはもちろんやろうと思えばできるのですが、これをやろうと思うと、オンプレミス同士にもかかわらずVPN接続が必要になってきます。これ、非常に違和感が出てしまうんじゃないかと思っています。 もちろんAzure StackはAzureそのものなのですから、VPNで接続するというのはAzureと同等であり、一貫性があります。 でも、同じ社内ネットワークに存在している「隣のサーバー」なのにVPNをはらないとネットワーク的につながらないというのはちょっと違和感を感じるひとが多いいんじゃないかと思うんです。 さらにAzure StackになるとInfrastructure as Codeも非常にやりやすくなります。コードにシステムを表現しておいて、それを展開して環境を作り出す…必要なくなったら消す…そんなことをバンバンするようになってくると…。既存環境へのVPN接続やドメイン参加をして…ということが非常に足かせになってしまいます。そもそも同じ環境を2つ作ろうとおもうと、コンピューターアカウントが重複して問題が発生してしまったりもしますしね。 つまり、Azure Stack上でAzure Stackらしい使い方をしようと思うと、今までのようにActive Directoryを使った認証にするのではなく、自然とAzure Active Directoryを使った認証システムを採用することになると思っています。 Azure Active Directoryに寄せることで色々とメリットも出てきます。Azure Active Directory Premiumの各種機能を使って認証を強化したり、セキュリティを強化したりできるが大きいでしょうか。 このあたりをきちんと理解してシステムを組んでいくようになるのがすぐ近い未来だと私は思っています。「社内であっても認証にActive DirectoryではなくAzure Active Directoryを使う」このあたりをきちんと理解し、システムを構築するようになるまでには、まだまだ結構色々とあちこちで苦労があるだろうなと思ってます。 雑誌のコメントにはこのようなバックグラウンドがあり、それが凝縮されてあのような表現になっているわけです。 Azure Stackを利用するなら、IaaSでVPNをつかって既存のシステムとネットワーク的にに連携してAD統合認証…ではなく、PaaSをつかって認証はAzure Active Directoryを使ったシステムをまず第一に考えて行きたいですね! ...

October 21, 2017 · 1 min · 胡田昌彦

Azure Stackの拡張性について(デマに惑わされない)

Azure Stack関連記事、第三弾です。 関連記事は以下です。 Azure Stackは誰がどう使うと幸せになれるのか?- Azure Stackは「できること」ではなく「できないこと」に思想がある 今回は、Azure Stackに関して、現時点で出ている否定的なネット上の記事にあまりにも誤解を招く表現があったので勝手に反論してみたいと思います。 その記事に直接リンクを貼る・・・のはやめておきますが(大人の事情)、その記事には以下のようなことが書かれています。 Microsoft Azureの豊富な機能を使いこなしているユーザー企業にはAzure Stackは向かない(Azure StackではAzureの全ての機能を備えていないから)- 全ての業務システムをAzure Stackで稼働させるのも難しい(拡張性はラック1本に収まる範囲であり限界があるから)- Azure Stackはハイパーコンバージドと呼ばれるジャンルの製品と競合する。Azure StackにはMicrosoftによる運用サービスが付加されている点が異なる。私に言わせると全部間違いです。 1に関して。Azure StackはAzureの拡張であり、Azureを使いこなす企業にこそ1番向くものです。それはマイクロソフトが1番主張していることでもありますし、合わせてハイブリッドでつかうことにより最大の効果が発揮されるものです。このことに関しては「Azure Stackは誰がどう使うと幸せになれるのか?」でも述べました。より具体的な技術的な話はまた他のエントリで解説したいと思います。 3に関して。確かにAzure Stackのアーキテクチャにはハイパーコンバージドという要素もありますが、それはほんの一部分であり、そこは本質では全くありません。Nutanixと競合しているのはWindows Server 2016自体ですよね。ハイパーコンバージドを実現するStorage Spaces Direct、ハイパーバイザーのHyper-V、管理手法を提供するMMC、ちょっと先だとHonoluluですとか。System Centerまで含めてもいいかもしれません。が、このあたりは見解の違いもあろうとは思います。でも、Azure StackとNutanixを比較するのはレイヤーが違いすぎてて…。 で、1番気になってしまったのは2の拡張性に関して。確かに現段階でのAzure Stackの拡張性に制限はあるのですが、その情報を間違って理解しているとしか思えないです。 現時点で拡張性に関して発表されているのは以下です。 Azure Stackは、ユーザー専用の1つのAzureリージョンと捉えることもできます。GA時点では、1つのAzure Stackリージョンに1つのスケールユニット(1つのスケールユニットは最小4ノード、最大12ノードで構成)が配置可能になっています。2017年中にスケールユニットが最大16ノード構成に拡張され、1リージョンに複数のスケールユニットを配置可能になります。また2018年中には、リージョンをまたがる地理的冗長性やスケールに対応する予定です。 「Azure Stack」のスケーリング *引用元:ASCII.jp:ついにGAした「Azure Stack」、“オンプレ版Azure”は何に使える?*確かに現時点(GA時点)では1つのAzure Stackの環境の中に1リージョン、1スケールユニットしか作成できずそれも最大12ノードです。ここをさして「拡張性はラック1本に収まる範囲」と言ってるのだと思いますが、2017年中に1リージョン中に複数スケールユニットを配置可能になればまだ上限は不明ですが、1企業のインフラ全てを扱える程度には拡張可能となるでしょう。 #でも、現状でもAzure Stackのシステムを複数買って動かせば全システム動かせると思いますが…。 …でも、私がもっと伝えたいのはMicrosoftがすでに何を成し遂げているかということです。MicrosoftはAzureや様々な世界規模のサービスを構築し、運用し続けているのです。 そんなMicrosoftにしてみればAzure Stackを「完全にAzureと同じ設計」にしていいのであればそれは簡単な話だったろうと思います。それこそハイパースケールで実装できます。が、それではエンタープライズには合わない…ということで「スケールダウン」させることに非常に苦労しているはずなんです。規模の拡大ではなく規模の縮小に苦労しているのってクラウドの世界ではMicrosoftくらいなのではないかと…。 そんなAzure Stackの下回りで台数の制約に1番からんでいそうなのはあきらかにWindows Server 2016のフェールオーバークラスタとStorage Spaces Directですよね。そこに関しての今後の拡張のロードマップはigniteの以下のセッションで語られていました。 MyIgnite - What’s new in Windows Server clustering and storage: Hyper-converged SHAZAM!このセッション中ではClusterを束ねて管理するCluster Setの概念、機能が解説されています。 この機能を使ってAzure Stackも今後の拡張を担保していくものと理解しました。 Azureですでに実現されていることをスケールを小さくしてWindows Server、そしてAzure Stackで実現していくことをMicrosoftは今後ずっと継続的にしていくことを顧客にコミットしているわけです。「スケールダウン」させた実装を一貫性をもって行い続けることは非常に難易度が高いとは思いますがMicrosoftにしかできないことだと思いますし、素晴らしいビジョンだと思います。 ...

October 6, 2017 · 1 min · 胡田昌彦

Azure Stackは「できること」ではなく「できないこと」に思想がある

Azure Stack関連記事第二弾です。 関連記事 Azure Stackは誰がどう使うと幸せになれるのか? | Windowsインフラ管理者への道 今回は、1つの捉え方としてAzure Stackの「できること」ではなくて「できないこと」に注目してもらいたいと思います。 Azure Stackは自由にハードウェアを選択できない OEMパートナーの統合システムとして限定されたモデルから選択する Azure Stackは自由に構築できない 「インストール作業」はエンドユーザーは行わない Azure Stackの基盤を構成する仮想マシン群にはアクセスできない コンソールアクセスをしても拒否される 「いつもの」ソフト群も導入できない 監視ツール アンチウイルスソフト バックアップソフト アップデート適用ロジックはコントロールできない ボタン1つで自動的に適用される 適用順序等もコントロール不可能 ソフトウェアに加えてハードウェアのファームウェア等も自動更新される スケールセット拡張方式もコントロールできない 同じHW、同じモデルを追加することができるのみ(※GA後に機能追加) どうでしょうか。運用の現場にいる人からすると「今のルールとは違う」ということになると思います。 ハードウェアもその時々で最適なものを選択しているし、インストール作業は自分たちでしているし、ハードウェアもその上のOS,仮想マシン含めて全部コントロールしているし、必ず入れる監視ツール、アンチウイルスソフト、バックアップエージェントがあり、アップデートのときにも必ず適用順序や適用後の確認もしている…、拡張するときには都度その構成を検討、設計して、慎重に作業していて…。 これこそが「ITインフラ管理者の仕事である」という意見の人も多いと思います。 ですが、Azure Stackは明確にこれにNOを突きつけています。「そんなことは本質じゃないからもっと本質的なことに時間を取れるように楽にしておいてあげたよ」という声が私には聞こえます。 実は、このあたりクラウドサービスを使っている組織には当たり前のことです。クラウドサービスの下回りがどうなっているかは完全にクラウドベンダーにおまかせですし、視線は「その上」で動いているサービスに向いています。 このクラウドでの当たり前をAzure Stackはオンプレミスでも当たり前にします。構成に悩まない。構築は自分でしない。提供されるサービスを利用し、基盤には立ち入らない。全自動で更新でき、更新を怖がる必要はない。リソースがたりなくなればすでに準備されている方法でスケールアウトすれば良い。 そんなことをされてしまったら自分の仕事がなくなってしまう!という危機感を覚える人ももしかするといるかもしれません。 でも、大丈夫です。それはすでにクラウドに進出した人が過去に通ってきた道ですし、そういう世界にあっても仕事は沢山あります。しかもそれは、より、本質的な仕事です。 インフラ基盤周りに関してはAzure Stackを入れておけばそれでおしまい。AzureとAzure Stackを使って「その上」の話に集中する。それがすぐに可能になります。 いや、むしろAzure Stackを導入するとそうなってしまうのです。なぜなら「いじれない」からです。 この1点だけでもAzure Stackが組織のITインフラ環境に「革命」を起こす製品であると理解いただけると思います。 もっと詳しく話がききたい!という方は、以下のセミナーでもこのあたりを話させてもらう予定なので、是非申し込みいただければと思います。 プライベートクラウド?ハイブリッドクラウド?Azure Stack 活用セミナー | JBS 日本ビジネスシステムズ株式会社 概要およびアジェンダは下記の通りです。 日時 2017年10月16日(月) 14:00-17:00( 受付開始時刻 13:30 ) 開催場所 虎ノ門ヒルズフォーラム ホールB 東京都港区虎ノ門1-23-3 虎ノ門ヒルズ森タワー4F 地図はこちら 定員 100名 参加費 無料 / 事前申し込み ※同業者様のご参加をお断りさせて頂く場合があります。あらかじめご了承ください。 ...

October 3, 2017 · 1 min · 胡田昌彦

Azure Stackは誰がどう使うと幸せになれるのか?

皆さんこんにちは。最近色々あってめっきりブログ投稿できておりませんが、仕事で年単位で温めてきた「Azure Stack」がいよいよ日本にもやってくるタイミングになりましたので、しばらくはAzure Stackに関しての記事を集中的に書いていきたいなと思います。 まずはじめに、Azure Stackは誰がどう使うと幸せになれるのか、誰のためのソリューションなのかという点について私の考えを書いてみたいと思います。 ずばり私は「まだクラウド化できていない組織」だと思っています。…が、これはAzure Stackのメインターゲットではありません。 「マイクロソフトの狙い」と「市場のニーズ」にずれがあると思うのです。そこを自分がうまく埋められるのではないかとも考えています。 私の個人的な考えですが、一つの切り口としてユーザーの種類は以下5種類くらいに大きく分類することができると思います。 [パブリッククラウドオンリーOKユーザー] パブリッククラウド比率100% クラウドをすでに活用している…というかオンプレミスのサーバーシステムなんてそもそも使っていないユーザー。あるいはオンプレミスに既存システムはあるけれども今後は全てクラウド上にシステムを構築していき、オンプレミスのシステムは長い目では0に向かっていく意思決定がなされているユーザー。 [ほぼパブリッククラウドでOKだけど一部はオンプレに置きたいユーザー] パブリッククラウド比率80~90% クラウドはすでに活用していて、基本的にはクラウドにシステムを構築するし、そのノウハウや手法ももっている。それでもパフォーマンスを高くするためにユーザーのアクセス窓口はパブリッククラウドではなくオンプレミスのユーザー近くに置くべきシステムが場合によってある。法律や厳格な社内ルールで縛られていて、特定のデータはパブリッククラウドには置くことは絶対にできないが、パブリッククラウドの良い点を極力フル活用したいユーザー。 [システムの置き場所は自由に選択できるようにしたいユーザー] パブリッククラウド比率20~80% ベンダーロックインを極力避け、どこにでもシステムを配置できるようにしたいユーザー。マルチクラウドでの可搬性ももちろん視野に入る。 [パブリッククラウドに行きたいけどまだいけていないユーザー] パブリッククラウド比率 0~20% 本当はパブリッククラウドを利用したいけれども、具体的にどうしていいかわからず踏み出せていないユーザー。あるいは、パブリッククラウド採用に対して前例のなさや、ルールの変更等の変更負荷が高すぎて合意形成が取れないユーザー。 [パブリッククラウドには絶対行かないユーザー] パブリッククラウド比率0% オンプレミスにこだわりがあり、パブリッククラウドを利用する気はまったく無いユーザー。 私の考えでは、Azure Stackを使って幸せになれるのは、2,3,4,5のユーザーです。ですが、特に4,5のユーザーに注目してほしいと私は考えています。 マイクロソフトが明確に狙っているAzure Stackの対象ユーザーというのは2および3である、というのが私の理解です。「Azure StackはAzureの拡張である」ということで、すでにAzureも使っているし、そのメリットも享受しているユーザーが何らかの理由(遅延、パフォーマンス、法律、ポリシー等など)でオンプレミスにシステムを構築しなくてはいけないときに、Azureの素敵な世界でいつも素敵にシステム構築しているのに、オンプレミスで全然別のやり方(そしてそれはきっとAzureよりも効率的ではない)をしなくてはいけないのは大変だよね、非効率だよね…ということですね。 「どこでも同じようにできる(開発、運用、保守、その他諸々)」ということを求めるならAzure + Azure Stackの世界感ですよね、というわけです。 これはこれですごく合理的な話だし話の筋は通っていると思います。 でも、現実を見たときに多いのは4や5のユーザーなんじゃないかと私は思っています。エンタープライズの企業規模の大きな企業に関しては特に。思い切ってクラウド化に向けて舵をきれる…ようならいいのかもしれませんが、様々なルールや「やり方」がしっかりと決まっている中でそこに変化を起こして行くのは並大抵のことではなく、検討している間にパブリッククラウドはどんどん変化してしまうし…それでも、なにかしらパブリッククラウドの良さを活かしていかないといけないという問題意識はある…。こういう状況の組織とても多いと思っています。 私は、そんな「まだクラウド化できていない組織」が一気に素敵な環境にジャンプできるそのための起爆剤にAzure Stackがなれるんじゃないかと思ってます。 なぜそう思うのか、その一番の理由は「場所」です。Azure Stackは兎にも角にもオンプレミス上で動作し、インターネットから完全に遮断した状態で「パブリッククラウドと同じもの」が動いちゃうものなのです。これなら様々な理由でパブリッククラウドに『行けなかった/行けていない/行く気がない』組織が、オンプレミスにありながらパブリッククラウドのパワーを手に入れられてしまうのです。しかも、Microsoftおよびハードウェアメーカーの完全なサポート付きで。しかも、パブリッククラウドと一緒なのでガンガン進化し続けます。 これならXXXさんを説得できるかも?と思う人も多いのではないでしょうか?私はオンプレミスで何年もずっと(効率的ではない)やり方をずっと続けてきた組織がAzure Stackを起爆剤として一気に「素敵な世界」を使い始められると思っており、それを実現していきたいなと思っています。 Azure Stack発表から登場まで2年(!)もあった中で、人にはまだ喋っちゃいけない知識ばかり頭のなかにいっぱいある…という状況になってしまいました。それがいよいよお客さんとの会話ができる状況になってきましたので、是非、色々な人にお伝えしていきたいです。大きく言えば日本のエンタープライズのIT環境に革新を起こしたくおもっており、その中心になりたいと思っています。Azure Stackにはそれができる可能性が大いにあると思っています。 …が、Microsoftの想定するメインのユーザー層とはことなることもあり、注意しなければいけない点も多数あります。このあたりの話はこのあとのブログエントリにてお伝えしていきたいと思います。しばらくAzure Stack関連の記事を連続で書く想定です。 注意点が早く知りたい!という方は、以下のセミナーでもこのあたりを話させてもらう予定なので、是非申し込みいただければと思います。 プライベートクラウド?ハイブリッドクラウド?Azure Stack 活用セミナー | JBS 日本ビジネスシステムズ株式会社 概要およびアジェンダは下記の通りです。 日時 2017年10月16日(月) 14:00-17:00( 受付開始時刻 13:30 ) 開催場所 虎ノ門ヒルズフォーラム ホールB 東京都港区虎ノ門1-23-3 虎ノ門ヒルズ森タワー4F 地図はこちら 定員 100名 参加費 無料 / 事前申し込み ※同業者様のご参加をお断りさせて頂く場合があります。あらかじめご了承ください。 ...

September 26, 2017 · 1 min · 胡田昌彦

ローカルセキュリティポリシーの編集ミスでサインインできなくなってしまった

恥ずかしい話ですが、今日ローカルセキュリティポリシーの設定編集をミスしてサインインできなくなってしまいました。 やってしまったのは以下の「対話型ログオン:Windows Hello for Business またはスマートカードが必要」のポリシーの有効化です。 会議中にWindows10の規定のポリシーがWindows Hello, PINを利用しないようになっている、という話を聞き、ローカルセキュリティポリシーのWindows Hello関連のポリシーにどんなものがあるかを確認している中で不用意に設定を変更してしまい、そのまま会話が長くなって画面がロックされ・・・入れなくなってしまいました。 どのユーザーで入ろうとしても、下記のように「サインインするにはスマート カードを使う必要があります。」ということで入れません。 もちろん入れないので、構成もできず…。 なんとかリモートから管理者に迷惑をかけずにもどしたいなということで頑張りまして結局以下の手順で復旧させました。 別のPCから「コンピューターの管理」で接続- リモートレジストリーサービスを開始- Regeditにてリモートレジストリに接続- コンピューター\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\scforceoptionを0に設定 最終的にレジストリで反映されているので、そのレジストリを直接編集した形です。 Windows Firewall等で完全にリモート接続できない環境だと上記でも復旧できないので、ドメイン側からGPOで設定を上書きする等の対応までやらないといけないかなと思います。 昔はよく、ローカルの管理者をきちんと準備していないのにドメインから抜けてしまって困るということをしたものですが久しぶりにそれを思い出しました。 いやはや、自分専用のPCとはいえもっと慎重に作業しないとだめですね…。

September 25, 2017 · 1 min · 胡田昌彦

個別の事項で細かく検討するのではなく大きく軸のある方針を持つ事の大切さ

最近、技術的な事をさほどやっていない事もあって、話が一気に細かい話になるような場面で「うーん」と唸ってしまうことが多くなりました。 個別の話自体ではもちろん色々と考え方もあれば検討すべきこともありますし、議論も必要なのですが、大きな大方針なく個別最適化してもいびつになるだけだし、そもそも、その議論が成り立つのは今と今後数カ月、長くても数年の話であって、進化の速いIT業界においてその考え方だと時代に取り残されますよね…というような…。 また、大きな流れ自体は何年も前からわかっているということも沢山あるのだなと実感するようにもなりました。むしろ、ビジョンに実装が追いつくまでの時間が長くて「え!まだ実装されてないの?」と驚くことも多いです。 そんな中にあって「個別の事項で細かく検討するのではなく大きく軸のある方針を持つ事の大切さ」を日々強く思うようになってきました。 また、どこに「注力すべきなのか」ということに関しても随分と意識をするようになりました。結局差別化要因ではないところにどれだけ力を割いてもあまり意味はなく…。 骨太の方針レベルで合意できるお客様と長期的なビジョンの実現に向けて一緒に二人三脚で、長期的に取り組んでいければ理想なのだけどなと考えています。 言うは易しですが…

August 29, 2017 · 1 min · 胡田昌彦

【質問/解説リクエスト募集】YouTubeへの解説動画投稿をはじめてみようと思います

胡田です。最近、ブログの投稿も滞ってますし、本の執筆もあまり進んでおりません。Microsoft MVPは先日再受賞したばかりですが、次回はこのままでは更新は無理だなと思ってます。 そんなこともあって、気分転換に、お昼休みの時間にでもYouTubeでライブ動画を配信して遊んでみたいなと思います。 特に準備せず、5〜15分程度で1つのトピックに関してホワイトボードにでも書きながら解説するくらいなら準備時間もかからず回せる可能性もあるかなと考えてます。 というわけで、何か質問や解説をしてほしいものがあれば、以下のあたりのどれかでリクエストいただけますと嬉しいです。- ブログのコメント欄- メール:ebibibi@gmail.com- Twitter:@ebi- Facebook:masahiko.ebisuda 何かしら約束ができるものでもないですが、モチベーションアップに協力いただけますとありがたいです。 #子供達がYouTube大好きで、自分たちでも配信してみたいそうなので、そのサポートのための勉強も兼ねる予定です。

July 27, 2017 · 1 min · 胡田昌彦

Microsoft MVP for Cloud and Datacenter Managementを再受賞しました

表題の通り、Microsoft MVP for Cloud and Datacenter Managementを再受賞しました。 ですが、最後の受賞になる可能性もかなり高いです。更新申請自体もしないかもしれません。色々と状況が変化することを自分自身にも期待しながら…。

July 2, 2017 · 1 min · 胡田昌彦

Miracastについてすこしだけ調べてみました

最近身の回りにSurface HUBが複数台ある環境なのですが、Surface HUBへの投影方法として提供されているMiracast(ミラキャスト)がうまく動作しない(PC側からSurface HUBを見つけられない)という事象がありました。 Miracastに関してはまだ何も調べたことがなかったので、トラブルシューティングのとっかかりもつかめなかったため、すこし調べてトラブルシューティングができる程度にはなりたいと思います。 というわけで、この記事は勉強したことの記録です。ですので、深い話があるわけではありません。 AppleのAirPlayに代わるオープンな企画対応していれば機種が異なっていてもつながる- 接続はP2P型のWi-Fi接続であるWi-Fi Directを使う。Wi-Fiに接続している状態でイーサネット接続デバイスとTCPで繋がって画面をストリームして…というわけではない。- 対応機器同士が1対1でつながる- Wi-Fi Directを使うためにMiracast接続時には通常の無線LAN接続は無効化される…という記載が見られるが、そうもない、という情報も見つかる。自分で確かめたい。- 違う周波数帯を使って1つはアクセスポイントに、1つはWi-fi Directに接続…ということができるらしい。- Source, Sink共にアクセスポイントへのアクセスあり、無しの接続パターンあり。- WindowsではWindows8.1以降でMiracast対応- HDMIとの共通部分も多いが別物- プロトコル周り通信路はWifi Direct- セキュリティはWPA2- 伝送プロトコルはRTP- 伝送制御プロトコルはRTSP- 映像はH.254- 音声はLPCM/AAC/AC3- 多重化はMPEG2-TS- 著作権保護技術にHDCP2.0/2.1 参考にしたもの Miracast – Wikipedia- 第596回:Miracastとは - ケータイ Watch Watch- Miracast よくある誤解と解説 - RC3の無職しょ日記 …。と、ここまで調べてから改めて、Wifi Allianceの 以下のドキュメントを見てみると…、ここまでの話とはまた全然違う話が書かれていました。 Wi-Fi Display Technical Specification v2.0 例えば接続形態に関してだけでも以下3つが記載されています。 Wi-Fi P2P- TDLS- Infrastructure and Wi-Fi Protected Setup 規格と実装も違うでしょうし、企画自体もバージョンアップしますし。ネットの記事も古くなりますし。このあたりはやっぱり難しいなぁと改めて思うのでした…。 Surface HUB関連の情報としてはとりあえず以下のあたり…。 Surface Hub による Wi-Fi Direct のセキュリティ問題への対応 | Microsoft Docs- Troubleshooting Miracast connection to the Surface Hub – Microsoft Surface Hub

June 29, 2017 · 1 min · 胡田昌彦

ADFSのClaimルールでUser-Agentを参照するのはやめましょう

皆さんこんにちは。胡田です。 ADFSでクレームルールを書いて様々なコントロールを行う…ということは技術的に可能なのですが、ものによっては意味がない、正しくない実装になってしまいますので注意してください。 例えば1例として、User-Agentを用いてアクセスをコントロールするような実装があります。ぐぐると解説記事もいっぱい出てきます。例えば以下。 - Restrict iOS apps which can access to Office 365 services (ADFS required) – beanexpert ADFSのクレームルールでuser agent(x-ms-client-user-agent)を参照してそれが特定の値であれば許可/拒否する…ということが開設されています。 これははっきり言ってひどい実装です。 HTTP(S)プロトコルにおいて、User-Agentヘッダはクライアントアプリが任意の値を埋め込むことが非常に簡単に行えるものです…、というかそもそもが自己申告制のものでして…こんなものを信じてなにかをコントロールするというのは「あなたは犯罪者ですか?」という質問の答えで許可/拒否するようなものです。 例えば「user agent change」というキーワードあたりでちょっとググるだけでも山ほどツールや手法が出てきます。 - user agent change - Google 検索 例えばProxyで書き換えるようなことも簡単にできますね。 - user agent change proxy - Google 検索 このあたりはHTTPプロトコルがそもそもどんなものなのか、ということを知っていれば当たり前に分かる話ではありますが…。 何をどのポイントでコントロールするか、というのはなかなかに難しいトピックではありますが、ADFSで色々とコントロールしようとするのは、Microsoftの今後の方向性からいっても相当の悪手だと思います。 MicrosoftソリューションであればAzure AD Premium( + Intune)を活用するのが吉だと思います。

June 27, 2017 · 1 min · 胡田昌彦

Azure Log Analyticsの検索に応じてMicrosoft Teamsにメッセージを送る

件名の記事をQiitaに書きました。 Azure Log Analyticsの検索に応じてMicrosoft Teamsにメッセージを送る - QiitaQiitaに記事を書くのははじめてだったのですが、Markdownはやっぱり良いですね。また、クリップボード内の画像をCopy & Pasteでアップロード&埋め込みができるのはすごく良いですね。この操作感を得たくてずっとWindows Live Writerを愛用してましたが、Qiitaの編集画面ならWebから生入力で全然問題ないなという印象でした。 Wordpressの編集画面もQiita相当にできないのか調べてみようかなと…。

June 14, 2017 · 1 min · 胡田昌彦

Windows 10にてWindows Updateできなくなる

Windows Updateができなくなってしまいました。 「更新とセキュリティ」をクリックするとそこでハングアップしてしまいます。 また、起動直後に以下のエラーがシステムに記録されています。 > ログの名前: System ソース: Service Control Manager 日付: 2017/05/02 12:03:02 イベント ID: 7031 タスクのカテゴリ: なし レベル: エラー キーワード: クラシック ユーザー: N/A コンピューター: xxxxxx 説明: Windows Update サービスは予期せぬ原因により終了しました。このサービスの終了は 1 回目です。次の修正操作が 60000 ミリ秒以内に実行されます: サービスの再開。 > ログの名前: System ソース: Service Control Manager 日付: 2017/05/02 12:03:42 イベント ID: 7034 タスクのカテゴリ: なし レベル: エラー キーワード: クラシック ユーザー: N/A コンピューター: xxxxxx 説明: Update Orchestrator Service for Windows Update サービスは予期せぬ原因により終了しました。このサービスの強制終了は 1 回目です。 対処として、How to fix Windows Update in Windows 10 if it becomes stuck | Alphr にしたがって作業をしました。 結局私の場合には、Windows Updateサービスと、Background Intelligent Transfer Serviceサービスを停止した上で、C:\Windows\SoftwareDistributionフォルダの中身を削除することで正常に動作するようになりました。 C:\Windows\SoftwareDistributionフォルダの中身や"C:\Windows\SoftwareDistribution\ReportingEvents.log"をのぞくとUpdateの動きが推測できて楽しいですね。 (2017/05/04追記) せっかくなので、その他の確認ポイントや修正方法に関しても記載しておきます。 - proxy設定の確認 - winhttp設定の確認 - netsh winhttp show proxy - Windows Update トラブルシューティング ツール - HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\UseWUServer - WSUSを利用する場合にはこれの値が1となっている。直接にするなら0に設定する。 ...

May 2, 2017 · 1 min · 胡田昌彦