Windows インフラ

先日新規にWindows10をインストールし直しまして、環境セットアップの一貫で「Install-Module Azure」を実行しました。 すると、以下のようにエラーが…。 PS C:\Windows\system32> install-module azure 警告: Could not get response from query ‘https://www.powershellgallery.com/api/v2/package/Azure/1.0.1'. 警告: MSG:SourceLocationNotValid «https://www.powershellgallery.com/api/v2/» PackageManagement\Install-Package : Package ‘Azure’ failed to install. 発生場所 C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1375 文字:21 + … $null = PackageManagement\Install-Package @PSBoundParameters + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : ResourceUnavailable: (C:\Users\MEbisu…ure\Azure.nupkg:String) [Install tion + FullyQualifiedErrorId : PackageFailedInstallOrDownload,Microsoft.PowerShell.PackageManagement.Cm kage 原因がわからず困っていたのですが、本日再度同じコマンドを実行するとインストールに成功しました。原因不明なのですが、何かしらwww.powershellgallery.comでおきていたのかな？とも思いますが…。

Localized Error Message Lookup - Microsoft | Language Portal 皆さん上記のサイト知ってましたか？Microsoft製品群のエラーメッセージを各種言語に変換できるサイトです。 皆さんご存知の通り、日本語の環境で出た日本語のエラーメッセージを元に問題を解決しようとして検索にヒットすればラッキーですが、中々情報が無く、英語圏で調べると沢山ある…という状況が多々あります。なので、日本語のエラーメッセージをまず該当する英語のエラーメッセージに「翻訳」するために、それをまず探す…ということよくやりますよね？ 私なんかはそれがめんどくさすぎるので、日本語の環境とは別にわざわざ英語の環境を作ったりもしているのですが…、実は上記のサイトを使えば簡単に検索できるとのこと！10年以上仕事してるのに誰も教えてくれなかったですよ…。ニアミスは何度もしてて、上記のLanguage Portal自体は使ったことが何度もあったのに！時間を非常に無駄にした気がします…。 これからは上記サイトをガンガン使っていこうとおもいます！

皆さんよくExcel上でのデータ操作はするだろうと思います。各種の情報を結合したり、編集結果をプログラムに流しこんだりなども。 私はExcel上でガリガリと手で操作をするのは極力避けています。その代わりにプログラムあるいはマクロを書きます。なぜそうしているのかというと結局Excel上で人が手で操作をすると時間もかかるし間違えるし、一度で済めばよいですが何度も繰り返し同じ作業をするはめになることが多いからです。プログラムを書いておけば何度でも同じプロセスを繰り返せますし、ミスや処理の追加があってもその箇所だけ修正、追加できます。 と、思っていたのですが、最近Power Queryの事を知りました。Power Queryを使えば複数のソースから情報を持ってきて目的に合うように加工してシートに収めることをGUIで簡単に行え、しかもそれを何度でも実行できます。例えば私が今回おこなった処理は以下の様なものです。 - 他のExcelファイルからシートを読み込む - 先頭の不要な行を削除する - 一意のIDとなる列を先頭列に移動する - 一意のIDとなる列の形式を数値にする - 一意のIDとなる列の重複を排除する 上記の操作を3つのExcelファイルに対して行い3つのシートに情報を格納しました。 このプロセスは非常に簡単に行なえ、ボタン一発で何度でも再実行可能になります。Power Queryいいですね。 今回はさらにそれぞれの情報を一意のIDを元に結合して集計しました。そこに対しては、Power Pivotを使ってGUI上でテ－ブル同士のリレーションシップを定義し、あとはピボットテーブルで簡単に集計できました。 また、抜粋した情報をまとめた別の表を作成したく、それにはVLOOKUP関数を使ったのですが(リレーションを元にフラットなピポッドテーブルを使って作れそうだったけど意図した形にならず断念)、最新のEXCELではセルの範囲指定(絶対参照とか相対参照とか)ではなくテーブル自体を範囲として指定したり、テーブル内の列を指定したりすることが出来るようになっており大変作業がはかどりました。最近といっても2007のころからの機能らしいですが。 というわけで、ここまで簡単に繰り返しに耐えられる形でのデータ操作ができるなら、もっと積極的にExcelを使うのもありだなといまさらながら思いました。

必要があってちょっとだけ簡単なPowerShellスクリプトを書きました。 AD上で表示名が同じスクリプトを見つけるスクリプト…と言いながら、以下の実装としては「displayNamePrintable」が同じオブジェクトを見つけるスクリプトです。 表示名で探すようにするのは単純にif文の中の属性を変更するのみです。 https://gist.github.com/ebibibi/16dbd44cd27ea7e0c0be

Active Directoryの表示名を変更しているのにLyncの表示名が変わらないという現象があり、色々と調べてみました。結果わかったのは以下の事です。(勘違いがあるかもしれません) - 基本的にはActive Directoryの表示名を使っている - しかし、ADの表示名を直接使っているわけではない - Lync Server上でアドレス帳を生成し、それをクライアントにダウンロードして利用する - Exchange, Outlookとも連携している - メールボックス内の連絡先の情報もつかう - Lyncでリストに登録するとOutlookの「Skype for Business連絡先」にも登録されてそれも使われる。 - Outlookのオフラインアドレス帳も使う - なので、Outlookがオンラインモードか、キャッシュモードかでも挙動が違う という感じのようです。優先順位としては以下の順番のように見えます。 - Outlookの連絡先に直接登録してある連絡先(登録した際の情報が保持され、手動更新) - Outlook内の「Skype for Business連絡先」にある連絡先(読み取り専用) ← Outlookがキャッシュモードならオフラインアドレス帳を優先的に見に行く模様 - Lyncのアドレス帳 - ADの表示名 かなり挙動が難しい感じです。

Channel 9でLog Analytics and Visualization Using Microsoft Azure Operational Insightsを見ました。ログを大量にためて分析するにはクラウドは最適ですし、SCOｍとの親和性も高いですし、無償で500MBまで7日間での切り捨ての状態でずっと試せるってのは非常にはじめやすくてよいのではと思います。 イベントログに何か出力しておけば、そのあとの回収と検索および可視化はOMSがやってくれるわけなので、アイデア次第で色々なことができそうです。

DSCのお勉強をしているなかでShow-Objectの存在を知りました。使えるようにしてみます。 まず、Windows Management Framework 5.0 Previewをインストールします。現時点ではApril 2015が最新の模様です。 Download Windows Management Framework 5.0 Preview April 2015 from Official Microsoft Download Center 手元の環境は64bit版のWindows8.1だったので「WindowsBlue-KB3055381-x64」を選択します。 しかし、なぜか適用できませんでした…。 調べてみるとen-usでないと動かないという情報が…。 Unable to Install PowerShell V5 preview on Windows 8.1 X64 地域の設定と言語の設定で「en-us」に設定して再度Updateを実行してみました。 適用可能になりました！ Find-Moduleが使えるようになりました！ I n s t a l l - M o d u l e P o w e r S h e l l C o o k b o o k で P o w e r S h e l l C o o k b o o k を イ ン ス ト ー ル す る と s h o w - o b j e c t を 使 用 す る こ と が で き る よ う に な り ま し た 。 様 々 な 出 力 を パ イ プ で S h o w - O b j e c t コ マ ン ド レ ッ ト に 渡 す と 、 オ ブ ジ ェ ク ト を 細 か く 調 査 す る こ と が で き ま す ！

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

“Identity is the new control plane” これがMicrosoftのモバイル戦略の最新のキーワードです。 Azure AD, Microsoft Intune and Windows 10 – Using the cloud to modernize enterprise mobility! - Active Directory Blog - Site Home - TechNet Blogs http://blogs.technet.com/b/ad/archive/2015/06/12/azure-ad-microsoft-intune-and-windows-10-using-the-cloud-to-modernize-enterprise-mobility.aspx 上記のブログが非常に「濃い」内容だったので、自分の考えの整理も兼ねて内容のサマリーを…。 Windows 10デバイス(スマートフォン、タブレット、PC等)がAzure ADに参加すると自動的に会社のポリシーに従ってMDMに登録される。会社のデバイスでも、個人のデバイスでも。 - 以下の要素に基づいたポリシーベースのアクセスコントロールでリソースを保護する O365等のアプリケーション - デバイスのヘルスやコンプライアンス状態 - ユーザーのプロファイル、属性、グループ - 認証強度 - アクセス元の場所 - クラウドのアプリケーションとオンプレミスのアプリケーションとの両方に、同一のポリシーでのアクセスコントロールを可能にする - これら全てをクラウドで実現する。新しいサーバーもネットワークデバイスも不必要。VPNも不必要。ほんの数時間で実現できる。 マイクロソフトは個人デバイスの持ち込みであっても、会社のデバイスであってもきちんと自動的にコントロール可能となるシナリオを重視していることがよくわかります。ECSライセンスだと個人のデバイスにOSの実行権限もOfficeの実行権限もつきますしね。 「会社のデバイスのみを会社のデータにアクセスさせる(≒以下に個人所有のデバイスのアクセスをブロックできるか)」というポリシーの企業も特に日本では多いと感じていますが、BYODによって個人にも会社にもメリットを出そうという考え方は合理的だと個人的に思います。 この大きな方向性の中で、会社のデータをいかに個人に不便を与えることなく安全に守るか。これをOSとクラウドで実現しようというわけですね。さすがはOSまで作っているマイクロソフト…といったところでしょうか。(もちろんWindows10以外のOSへの対応も進むものと思われますが!) AzureAD(premium)にて柔軟なポリシー設定ができないのがいままで色々とネックとなりADFS含めて他のソリューションが色々と必要な状況がありましたが、ついにMicrosoftのクラウドサービスだけで完結できるようになりますね。 軸足がどんどんオンプレミスからクラウド側にうつすことが「可能」になってきています。そしてWindows10においてはモバイルデバイスとPCとの境目は全くなくなる事になります。まさにモバイルファースト、クラウドファーストという感じですね。 Windows10ではOSのセットアップ時にAzure ADに参加が非常に簡単にできます。 個人利用のWindows10も簡単にAzure ADに参加できます。 管理者がIntuneにデバイスの管理ポリシーを設定し、Azure ADに条件に基づいたアクセスコントロールポリシーを設定します。 Intuneはデバイスがきちんとコンプライアンス設定が満たされているかを評価し、その結果をAzure ADにレポートします。 この時、きちんと「デバイス」とそれを使用している「ユーザー」が紐づくのが大きなポイントですね。 ...

ここ最近、色々な場面で「クラウド時代のID管理」について考える場面が多くあります。 それこそ、Azureの管理ポータルに権限をつけるときに…という話もあれば、Onenoteでドキュメントを共有するときにも、プログラムからクラウドサービスを叩くときにも…。IDですからいつでも、どこでも、何にでも、という感じです。 私はWindows系のシステムを触ることが大半なので、オンプレミスではAciveDirectoryがあり、関連しステムはすべて同一のフォレストに所属している…という中で、IDやグループ周りの登録、管理、メンテナンスなどはすべてADで一括管理され、それをすべてのシステムで利用することができるのがほぼ当たり前の状況でした。 下手にシステムごとや組織ごとに別フォレストを作ってしまって、後から統合しようとして四苦八苦しているところもあり、統合されて管理されていることの重要性を強く感じます。(政治的に難しくて…というのもよくある話ではありますが) この、当たり前だった前提がクラウドサービスを色々と利用していく中で相当崩れてきている組織が多いことを実感しています。クラウドサービスでオンプレミスのID, グループを直接利用できるわけないですからね。 せっかくオンプレミスでIDを一元管理していたのに、クラウドサービスを利用するためにあちこちで個別に管理をしだしてしまうのははっきり言って悪手だと思ってます。きちんとクラウドサービス群から使えるクラウド時代のID管理ポイントを作成し、そこを中心に据えるべきだと思います。そして、オンプレミスでこれまでID管理をしてきたものとそれとは同一であるか、そうでなければシームレスに同期されるべきです。 この文脈で登場するのはMicrosoftの場合にはAzure Active Directoryです。オンプレミスのADと同期するツールまで無償提供されているし、O365などのMicrosoftの様々なクラウドサービスを利用しようとすると勝手に利用する形になっており、Microsoft のうまさを感じます。もちろんAADじゃなきゃいけないわけではないですが、Microsoft 系のシステムで固めているのであれば有力な選択肢になると思います。 でも、残念なことにO365を利用するにあたってわざわざ別のフォレストを新規に作成して、そことAzure Active Directoryを同期させるような構成をとってしまっている組織が結構あるらしいという話が聞こえてきてます。 様々な利用からそうしてしまいたくなる気持ちはよくわかるのですが、後になってより大きな問題となってしまう可能性は非常に高いと思うんですよね。もちろん状況次第なのですが。ここのところはしっかりと先を見据えた構成が必要だと思います。

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管理はやっぱり肝です。これらのコンテンツで大きな流れを理解することが出来ます。「フェデレーションってよく聞くけどなんだか難しそう…」という人におすすめです。 ...

Microsoft Message Analyzer 1.3がリリースされています。 Download Microsoft Message Analyzer from Official Microsoft Download Center パケットキャプチャする際の選択肢の一つとして…。

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 Pro 3のファームウェア & ドライバのアップデートが出ていたので適用してみました。 ダウンロードは以下のURLから可能です。 - [Download Surface software, firmware, and drivers from Official Microsoft Download Center](https://www.microsoft.com/en-us/download/details.aspx?id=38826) 何やらファイルが沢山ありますが、私の場合にはSurface3_150504.msiを適用しました。 特に何もなく、「次へ」と進めていくだけで適用可能ですね。 適用後には再起動を求められます。 再起動は素早く、普通に終わります。本当にドライバ適用とかされているのかな・・・と不安になる速度で…。 とりあえずNICのドライバを見てみたところ…。 更新されている気配がありません。 よくわからないので「“C:\Program Files (x86)\SurfacePlatformInstaller\dpinst.exe”」をキックしてみます。 ドライバを適用可能なデバイスが見当たらないと…。何か私は勘違いをしているのでしょうか? きちんと情報を確認します・・・。 - [Surface Pro Firmware and Driver Pack の構成ファイルとその内容 (15/04版: 4/13 更新) - Microsoft Surface BlogS - Site Home - MSDN Blogs](http://blogs.msdn.com/b/microsoft_surface_blogs/archive/2015/04/08/10606011.aspx) 適用方法は間違っていないようですね。単にドライバが更新されていないものを確認してしまったのか? 例えばこのあたりはきちんと更新されていそうです。 これも更新されてますね。大丈夫そうです。 というわけで、「きちんと作業後の確認方法自体を確保してから作業しないと、確認もままならないよ！」というお話でした…。

Windows7以降で使える「Snipping Tool」はWindowsが標準で持っているスクリーンショット取得アプリです。 - 画面の特定の領域を指定して切り抜けます。 - さらに、切り取った領域に対してペンや蛍光ペンで書き込みも出来ます。 ちなみにサーバーの場合には機能として追加されておらず、「Desktop Experience」を追加することで使用可能となります。PowerShellでの追加が簡単です。 Add-WindowsFeature Desktop-Experience Print Screenを押して全画面を取得して、ペイントを立ちあげて、書き込んで、切り取って…と毎回やっていた人は悔い改めてください。 ※せめてAlt + Print Screenで！ 超有名だと思っていたのですが、先日超できるエンジニアの人と会話していたら存在を知らなかったらしく…改めて書いてみました。自分にとって当然の事でも、他の人にとって当然じゃないことって多いんですよね…。

あちこちで話題になってますが、2015年3月のWindows Updateを実行したあとからエクスプローラーが頻繁にハングアップし、再起動し、その間プログラムの切替等が行えない…という現象が起きています。私の環境はWindows 8.1でGoogle日本語入力を使っています。ブルースクリーンになる人もいるようですが、私はそこまでの現象は発生していません。 とりあえず「KB3033889+Microsoft IME以外のIME」が原因なのではないか、という推測があるようで、私もKB3033889のアンインストールを試してみました。 参考：2015年3月のWindows Updateの不具合情報 そもそも、Windows Update適用の時点でいつまでたってもうまく適用出来ず、待機状態のまま強制的に電源を落とした経緯があるのですが、アンインストール後の再起動の際にもいつまでたっても再起動が行われず…という状態になってしまいました。今回も強制的に電源を切りました。Microsoft IMEに切り替えてからの変更作業ならここはスムーズに行ったのかもしれません。 再起動後は頻繁なエクスプローラーのハングアップは収まったようです。 マイクロソフト セキュリティ情報 MS15-020 - 緊急 ただ、上記の脆弱性が復活している状態なので、あまり気持ちが良いものではないですね。早くパッチの修正がなされると良いのですが。 (2015/03/18追記) 以下のKBにて問題を修正するプログラムが公開されました。 - [Update 3033889 causes Windows Explorer to stop responding on some systems that use the Japanese IME](https://support.microsoft.com/en-us/kb/3048778) 上記ページからダウンロードリンクが記載されたメールを送信してもらうようにリクエスト出来ます。 KB3033889をインストール→上記hotfixを追加でインストールという流れになります。逆の順番でも仕組み上正常に動作するはずだと思いますが、hotfixは問題が発生しているシステムにのみ適用するのがセオリーなのでこの順番が正しいと思います。

先日、自宅のネットワークで「インターネットに接続できない」というトラブルがありました。事象としては以下の様な感じです。 - ブラウザ等でインターネットに接続できない - nslookupでの名前解決は出来ている - ADSLルーターを再起動すると一時的に接続可能になるが、しばらくするとまた接続できなくなる - ただし、完全にインターネットへの接続が出来ないわけではなく、稀に成功することもある 嫁さんからの連絡でこの事象に気がついたのですが、良く調べてみると結局ルーターのNATテーブルがGoogle Driveによって食いつぶされているのが原因でした。 512件しか登録出来ないところを512件全て使い切ってしまっています。この状態ではきちんとNATが維持出来ずTCPコネクションが確立し続けられない事になります。 UDP1発の往復ですぐに終わるnslookupはうまく動作していたこととも整合性があります。(NATテーブルの維持時間が短くてもすぐに動作完了するので成功する) netstat –anbで利用しているポートを確認した所、googledrivesync.exeが原因でした。 とりあえずgoogle driveのプロセスを終了した所正常に通信できるようになりました。 google driveの同期先のサーバーに障害でも発生していたのでしょうか？ちょっとそこまではよくわかりませんが、とりあえず数日おいてから同期を再度開始してみたら問題は特に再現しませんでしたので、一過性のものとして判断しています。

金曜日の帰りの電車で座席に座れたので、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つをつなげた時に行える世界の広がりを理解すると感動的だと思います。 もっとちゃんと時間をとって書きたいですね…。

Windows 10 Previewのビルド番号が上がってから、OneDriveがクラッシュするようになってしまって非常に困ってました。でも、まぁ、なんとか誤魔化してましたがどうにも不便すぎるので、検索してみたところ、解決方法を発見！ - [OneDrive crashing on Windows 10 Threshold Fix | Windows 8, Windows Phone, Windows Azure, Visual Studio and other Microsoft Technologies Blog | Tan Chun Siong](http://www.tanchunsiong.com/onedrive-crashing-on-windows-10-threshold-fix/) 手順は、OneDriveの同期フォルダと設定ファイルを削除した上でのクライアントの再インストールです。 - c:\users\yourusername\onedrive を削除 - C:\Users\yourusername\AppData\Local\Microsoft\SkyDrive\settings\ にある設定ファイル2つを削除 - C:\Users\yourusername\AppData\Local\Microsoft\SkyDrive\17.3.4517.1031\OneDriveSetup.exeを起動してインストールを実行 設定ファイルはこんなところにあったのですね。 これで、OneDriveでの快適なファイル同期生活に戻れます。よかった！