Windows インフラ

今夜はちょっと時間があるので、久しぶりに気になっているもので遊びたいなと…。 ものとしてまず選んだのはMicrosoft Flow。 いつも情報収集中にストック、シェアしたい記事は、「はてなブックマーク」でブックマークをして、それをはてなブックマークのTwitter連携機能でTwitterに、Facebook連携機能でFacebookに投稿しています。 でも、ここからさらにWindows管理系ネタは「Windows****インフラ管理者への道」というFacebookページにも投稿させています。これは私のtwitterの投稿の中に#wというハッシュタグが付いていたら、「Windowsインフラ管理者への道」Facebookページに対して投稿するように、IFTTTにてレシピを書くことで実現しています。以下のようなレシピですね。 これはこれで便利に利用しているのですが、私はFacebookページをほかにもいくつか作成しておりまして…、本当は「#wだったらWindows Server管理者への道」「#sだったらSystem Center Blog」「#eだったらExchange Server Blog」…というように複数のFacebookページに投稿を振り分けたいんです。ですが、残念ながらIFTTTでは単一のFacebookページにしかリンクさせることができず…。 というわけで、これがMicrosoft Flowで実現できるとうれしいのですが、さて、どうでしょうか。 最悪複数Facebookページに投稿を振り分けられなくても、IFTTTではこちら、Microsoft Flowではこちら…ともう1つのFacebookページには投稿できるようになると考えております。さて、うまくいきますか。 Microsoft Flowにアクセス まず、Microsoft Flowにアクセスします。 Automate processes + tasks | Microsoft Flow レシピを作成します。 まず、Twitterのポストをトリガーに指定します。 #sに反応するようにしたいと思います。 次に、Facebook Pageに投稿するように構成します…。 ここではFacebookページのidが必要になります。 調べ方はいろいろあると思いますが、私は面倒なので、さくっと見つけたWeb****サービスを利用して調べました。 これだけ！ですね。 うーん。ものすごく簡単です。きちんと動くでしょうか？試しにやってみます。 確認してみると…失敗してしまっています。 ユーザーがパスワードを変更したとおっしゃってますね…。本当かな…。 Update passwordをクリックしたらconnectedとなりました。 でも、これでもまだしっぱいします。 一度接続を削除して、再度接続を作成しようとすると…？ 残念ながら、Unexpected end of JSON inputとなってしまい、うまく接続を作成することができなくなってしました。 Facebookページへの投稿にはIDの指定ができるため、複数Facebookページへの投稿の振り分けができそうに見えるので…、今後に期待ですね。今日はフィードバックページから「Facebookに接続できないよ」と投稿するだけにしてあきらめておこうと思います…。

Azure Stack版のClouc Platform Systemに関して発表されています。Igniteでの発表だと思ってましたが、WPCに合わせて発表出ましたね。Igniteではおそらくハードウェアベンダーから具体的なラインナップや価格の発表があるのかな? https://azure.microsoft.com/en-us/blog/microsoft-azure-stack-delivering-cloud-infrastructure-as-integrated-systems/ まずは、DELL, HPE, Lenovoがベンダーとして名前が出ています。 Microsoft is committed to ensuring hardware choice and flexibility for customers and partners. To that end we are working closely with the largest systems vendors – Dell, HPE, Lenovo to start with – to co-engineer integrated systems for production environments. CPSのAzure Stack版リリース目標は2017年半ば。 We are targeting the general availability release of Azure Stack, via integrated systems with our partners, starting mid-CY2017 上記発表を「メジャーベンダーの固定化されたハードウェアでしかAzure Stackが動かない」と受け取った人からコメント欄で苦情の嵐…。(気持ちはよく分かりますね…) ...

前回の記と事を書いて、「続きはその2で」…と言いながら４年以上の月日が流れてしまいました。4年…あまりにも長い月日なので、結局当時のことはもう通用せず意味が失われ……てはまったくいないのが現在です。 今でもきちんとActive Directoryを理解することは難しいですし、そのなかでDNSの扱いの理解が難しいことも変わりません。そもそもちょっとたったら知識が陳腐化してしまうようなことはどうでもいいことですしね。 というわけで、4年以上の歳月をあけて「その２」です。 でも、随分間が空いてしまったので自分でも何をその２で書こうとしていたのかよく覚えておりませんが…、とりあえず前回予告したとおりいくつか典型的なパターンを挙げてみましょう。 社内のActive Directoryにはインターネットには絶対に存在しないドメイン名をわりあて、社外（インターネット）の名前解決はそもそも行わせないパターン まずはこのパターンから見ていきましょう。これは「Active Directoryが使うDNS」と「インターネットの世界のDNS」が完全に分離されているパターンです。 この場合には具体例としては「test.local」というようなドメイン名がActive Directoryの使うドメイン名として割り当てられることになります。 xxx.localというドメインはインターネット上には絶対に存在し得ないドメイン名です。なぜならトップレベルドメインにlocalというのは存在しないからです。今後追加される可能性がゼロでは無いものの、その場合にも「local」が選択される可能性はほぼ0と言ってよいでしょう。 そして、社外の名前解決はクライアントに対して行わせないパターンですので、社内のネットワークは全てインターネットの世界とはつながらず、切り離して考えることが出来ます。 つまり、社内のDNSの世界は完全にActive Directory用として切り離されています。そのなかでドメインコントローラーを探したり、同じドメイン内の他のホストを探したりという動きにはActive DirectoryのDNSが使われることになります。 技術的にはインターネット上のDNSと同じ技術が使われているが、社内の閉じた世界、Active Directoryの閉じた世界でのみ使用されているため混乱する要素がありません。 しいて言うならば、この場合にどうやってインターネットにアクセスできるのか?ということが疑問としてでるかなと思います。 これにかんしては、このような構成をあえてとっている場合には「インターネットには管理対象のクライアントは完全にアクセスさせない」という構成にする、というのがまず一つあります。 インターネットに繋がることが当たり前の今日においてこれは違和感があるかもしれませんが、セキュリティ対策を完全に行おうと思えばインターネットへのアクセスがどのような形であれ行えてしまえばもうなんでもありの世界ですから、インターネットへのアクセス自体を完全にブロックさせるというのは一つの考え方としてはありなわけです。 このケースにおいては、Active Directoryでは技術的にDNSを使っているけれども、ただ単に技術的に同じものが使われているだけであって、完全に切り離されている。ということで理解してもらえればと思います。 社内のActive Directoryにはインターネットには絶対に存在しないドメイン名をわりあて、社外（インターネット）の名前解決はそもそも行わせない…けれども、Web閲覧は許可する インターネットへのアクセスはセキュリティ面を考慮してさせたくない…けれども、やはり完全に隔離するのも不便すぎるので、Web閲覧のみは許可する、というパターンがあります。 この場合には、ブラウザの設定として、Proxyサーバーを設定し、Web閲覧のみProxyを経由することでインターネットにアクセス可能とします。もう少し正確に書くと、「Proxyサーバーに閲覧したいWebサイトのアドレスを伝えて、コンテンツを代わりに取ってきてもらい、結果のみProxyサーバーから受け取る」という事になります。 この場合、DNSを用いたインターネット上の名前解決を行っているのはProxyサーバーのみであり、クライアント自身はDNSを用いてインターネット上の名前解決をする必要はありません。 ですから、クライアントが参照しているのはローカルのActive Directoryのドメインコントローラーが持つDNSであり、Proxyサーバーが参照しているのはインターネットホスト名が解決できる(Active DirectoryのDNSではない)DNSということになります。 内部の(Active Directoryの)名前解決ができるDNSと外部の（インターネットの)名前解決ができるDNSを完全に分離してしまい、そこは連携させず、クライアント自体は内部のDNSを参照させて、インターネットの世界からは分離させ、ブラウザでWebサイトを見る時だけProxyにお願いすることで（直接クライアント自身ではインターネットにアクセスしないことで）このような構成を可能としています。 うーん。まだまだパターンはありますね。続きは「その3」で…。（いつになることやら。）

仕事で最近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追記) - 消費税に関して。請求書には明細ごとは税抜き価格、加えて税抜き合計、消費税合計、税込み価格合計が記載されている。

※長期間下書きのままになってしまっていたようなので、そのまま公開してしまう… SCOM経由でOperational Insightsにデータを送信する形態の場合に、そのデータ送信が途絶えてしまう…というトラブルがありました。 結局その後トラブルシュートすることで - Operations ManagerのDBの空き容量が少ない場合にSCOMとしては概ね正常に動いていながらも、Operational Insightsにはデータを送信しない事象が出る - SCOMからOperational Insightsへのデータ送信の確認はパフォーマンスモニタで行える ということがわかりましたので、メモとして残しておきます。 1に関してはきちんとSCOM自身の監視にて警告がでており、DBの拡張を実施することで正常に動作するようになりました。 2に関しては、Health Service Management GroupsのHTTPからはじまるカウンタにてデータ送信の状況が確認できます。以下のページに方法が書かれています。 - [Operational Insights のプロキシとファイアウォール設定の構成](https://azure.microsoft.com/ja-jp/documentation/articles/operational-insights-proxy-firewall/#operations-manager)

皆さんこんにちは。今回は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」に変更します。 「設定」に移動し、規定のディレクトリを変更する対象のサブスクリプションを選択した上で「ディレクトリの編集」をクリックします。 ...

みなさんこんにちは。胡田です。 今回は証明書に関しての注意喚起です。 SSL/TLS 証明書の SHA-1 廃止が予定されています。 これはつまり「以前作成した証明書のままにしておくと、ある日システムが動かずトラブルになる」ものがあるということです。 自分たちが関わっているシステムは大丈夫なのか？ 証明書を使用している全システムに関して確認が必要です。 すでにチェック済み…ですよね？ 「え?なんのこと?」というひと、まずいですよ。以下のあたりを参照して対応お願いします。 ・[IT 管理者向け] 残っていませんか? SSL/TLS 証明書の SHA-1 廃止はもうすぐ - 日本のセキュリティチーム - Site Home - TechNet Blogs Windows上では2017 年 1 月 1 日が挙動変更予定の日です。 皆さん周りの人にも注意喚起お願いします。

かなり今さらネタなのですが、MVP特典のO365サブスクリプションのService SettingsをFirst releaseにしておらず、検証したい項目が出てこなくてちょっと悩んでしまいました。 上記の図のようにO365のAdminセンターでFirst releaseを全体、あるいはユーザー単位で設定可能なので先行検証ユーザーはFirst releaseに割り当てる等の対応を予めしておくのが良いですね。

欲しかったものが一発で手に入ったのでうれしくてポスト。 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アカウントはとりあえずどこにでもなんにでも権限つけられちゃうのでそちらのほうが楽に使えちゃうんですよね。でも、他要素認証とか色々企業でコントロールするには組織アカウントを事実上つかわないと色々とやりづらくなってしまうわけで…。このあたりもう少しアーキテクチャ的に改善されて欲しいところです。

突然ですが、以下のメッセージはSCCMのログに出ていたメッセージからの抜粋なのですが以下をみて意味が皆さん分かりますでしょうか? WNetAddConnection2 failed (LOGON32_LOGON_NEW_CREDENTIALS) using account DOMAINNAME\accountname (00000775) ログオン、クレデンシャル、アカウント…など出てますので、ログイン周りで何かしら失敗したのだろう…と推測つきますでしょうか。 そして、最後の「00000775」がポイントです。 このような文字列を見た時にはまず何も考えずにerr.exeに入力してみる発想が重要です。 以下err.exeの実行結果です。 C:\Users\MEbisuda.JBS\Dropbox\Apps\Err>Err.exe 00000775 # for decimal 775 / hex 0x307 : SE_AUDITID_CERTSRV_PUBLISHCRL msaudite.h Certificate Services received a request to publish the # certificate revocation list (CRL).%n # %n # Next Update:%t%1%n # Publish Base:%t%2%n # Publish Delta:%t%3 ERROR_BLOCKED raserror.h for hex 0x775 / decimal 1909 : SQL_1909_severity_16 sql_err Cannot use duplicate column names in index. Column name # ‘%.*ls’ listed more than once. ERROR_ACCOUNT_LOCKED_OUT winerror.h ...

気がついていませんでしたが、PowerShell ISEに「アドオン」メニューがあり、そこから各種アドオンのダウンロードページに飛べるようになっていました。 Script Browser、Script Analyzerは知ってましたが、Module Browserアドオンの存在は知りませんでした。 アドオンをインストールすると、まずは、NuGet-anycpu.exeのインストールを要求されます。 でも、普通にAcceptをクリックすると、初期化に失敗します。 どうやらこのバージョンは動かないようです(!) ISE Module Browser - A new way to manage your PowerShell modules - Windows PowerShell Blog - Site Home - MSDN Blogs 上記ページに解説があり、動作可能なバージョンとして以下が紹介されています。 PowerShell Gallery | ISEModuleBrowserAddon 1.0.1 PowerShellベースでインストールできます。 Install-Module -Name ISEModuleBrowserAddon

Microsoft Assessment and Planning Toolkit - TechNet Articles - United States (English) - TechNet Wiki MAPインベントリ情報やパフォーマンス情報を収集できる便利なツールですが、ツールから出力できるレポートの種類には限りがあります。収集したデータを自由に出力したい場合、データベースがSQLとなっていますので MAPからデータをエクスポート - SQL Serverでインポート - ビューを参照してデータを取得 という流れで自由に情報を取得できます。 パフォーマンスデータ関連は以下のテーブルに入っているようです。 ここから情報を取得すれば、MAPツールではできませんが「パフォーマンスデータの時系列のグラフ」を作成することもできそうです。 個人的にはパフォーマンスデータの取得、可視化にはSCOMが抜群によいと思っているのですが、一時的な調査にはMAPも使えそうですね。

今回はPowerShell ISEのアドオンであるCIM Explorerを紹介します。 l TechNet PowerShell ISE Addon - CIM Explorer これはWMIにアクセスするスクリプトを記述する際の便利なツールです。 以前あったWMI CodecreatorのPowerShell版…という感じです。 例えば、BIOSのシリアルナンバーを取得したい時には… ローカルホストに接続し… ネームスペースを選択し… Win32_BIOSクラスを選択し… SerialNumberを選択し… 右クリックから「Get value of properties in PowerShell」をクリックします。 すると、PowerShellコードが生成され、実行するとシリアル番号が取得できました。 このように簡単にマウスで選択していくだけで、簡単なPowerShellスクリプトを生成することができます。いろいろと活用できると思いますので、是非チェックしてみてください。

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