Windows 11の「Microsoftアカウント必須」廃止へ? メーカー側も反対の声

Windows 11のMicrosoftアカウント強制、ついに見直しか Microsoftは今週、Windows 11に関する複数のユーザー要望への対応を発表したが、初期セットアップ時に必須とされるMicrosoftアカウント(旧称:Live アカウント)の要件については変更が見送られた。 メーカーからも批判の声 注目すべきは、この「強制アカウント登録」に対してPCメーカー(OEM)側からも反発が出ている点だ。Windows 11を搭載したPCを製造・販売するメーカー自身が、この仕様に否定的な見解を示しているという事態は異例とも言える。 これまで同要件を回避するには、セットアップ中にネットワークを切断するといった非公式な手順を踏む必要があり、法人展開やオフライン環境でのセットアップに支障をきたすとして、IT管理者やエンタープライズユーザーから長く不満の声が挙がっていた。 日本市場への影響 日本の法人市場でも、セキュリティポリシーやプロキシ環境の制約からMicrosoftアカウントとの連携が難しいケースは多い。教育機関や中小企業では「ローカルアカウントで使いたい」というニーズが根強く、この要件の緩和・廃止は実務面での恩恵が大きい。 今後の動向 現時点でMicrosoftは公式にアカウント要件の撤廃を表明してはいないが、メーカー側からの圧力とユーザーの継続的な批判を受け、近い将来の方針変更が期待される。Windows Insiderプログラムや今後のアップデートで、ローカルアカウントによるセットアップが正式に再サポートされる可能性がある。 Microsoftアカウント連携はOneDriveや各種サービスとの統合において利便性も高いが、「選択できること」と「強制されること」は別問題だ。ユーザーの自由度を高める方向への舵切りに期待したい。 ※出典: Mandatory Microsoft Account may soon be gone as even Windows 11 makers hate it 元記事: Mandatory Microsoft Account may soon be gone as even Windows 11 makers hate it

March 22, 2026 · 1 min · 胡田昌彦

なぜ今まで知らなかったのか…Win10標準機能「クイックアシスト」が素晴らしすぎる

Windows3.1の時代からのヘビーユーザーでありながら、私はWindows 10標準機能の「クイックアシスト」を知らずにずっと無駄な苦労をしていました…。 なんと、Windows10にも標準でTeamViewerやAnyDeskのような画面共有しながら同時にWindowsが操作できる機能がついてました。いや、もちろん以前からリモートアシスタントなどの機能があることは知ってましたが、Windowsの機能なんて使い物にならないでしょと見向きもしてなかったんです。ごめんなさい。 でも、Windows 10 アニバーサリーアップデートで追加された「クイックアシスタント」は操作する側のみマイクロソフトアカウントを持っていればよく、画面に表示された番号を伝えて入力してもらうだけの簡単接続でFirewallも越えて簡単にリモート接続ができてしまって、びっくりです。 接続手順 操作する側 まず「操作する側」で番号を取得します。 アプリを起動して… 「ほかのユーザーを支援する」をクリックします。 マイクロソフトアカウント、あるいは組織アカウントでサインインします。 セキュリティコードが表示されるので、それを相手に伝えます。 操作される側 こちらもまずはクイックアシストを起動します。 伝えてもらった番号を「アシスタントからのコード」に入力します。 「画面の共有」をクリックします。 あと、もう少し手順はあるのですが、画面の通りに進めるだけなのでもう説明の必要もないくらいに簡単です!「番号を生成して、それを伝えて入力してもらう」だけできればあとは心配なさそうです。 実際の操作のデモ 下記の動画で実際に接続して操作していますので、実際の動きをご覧になりたい方は見てもらえればと思います。 https://youtu.be/Tm0q9g_JKDw というわけで、以上ご紹介でした。 本当に簡単に接続できるので、これからガンガン活用しようと思います。リモートワークが多い現在ですから本当に大活躍する機能だと思います! (2021/9/16 追記)Team Viewerはもっと便利 書き忘れていましたが、この機能があればもう全部大丈夫…、というわけではなく、やはり「相手の許可を得て接続する」ということしかできないのは場合によっては不便ですね。有無を言わさずどんな状況であっても完全にリモートからコントロールしたい場合もあるわけです。私も実家の親のPCのサポートなどの場合には何かあったら「わかった見ておくから、電源つけてほおっておいて」とだけ言っておいて、あとは自分で接続して事象を確認して問題解決をしておくわけです。 そんな時にいつも大変便利に使わせてもらっているのはTeam Viewerです。 https://www.teamviewer.com/ja/ さすが専用の歴史もシェアもあるソフトだけあってクイック アシストには無い、痒い所に手が届く機能が超大量に搭載されております。個人が非営利目的で利用する場合は無料ですし、商用版なら企業で使うための機能も大量に搭載されています。 https://www.teamviewer.com/ja/content/request-business-trial-t2/ より引用 https://www.teamviewer.com/ja/content/request-business-trial-t2/ より引用 というわけで、Windows 10標準搭載の「クイック アシスト」でリモートコントロールの便利さを体験して、さらにステップアップしたい方はTeam Viewerをお勧めします。そして、企業利用なら商用版ですね! ※当初「TeamViewer」を「Teams Viewer」「Team Viewer」と誤って記載してしまっておりました。大変失礼いたしました。Microsoft Teamsに思考が汚染されてしまっていたものと思います。TeamViewerには長年お世話になっております。お詫びとして紹介させていただきました。

September 15, 2021 · 1 min · 胡田昌彦

VMSS(Virtual Machine Scale Set)のWindows仮想マシンからのログ取り込み

Azure LogAnalyticsワークスペースに様々なログを取り込んでみます。他にも色々とやってますので下記エントリも確認お願いします! Azure LogAnalyticsワークスペースに様々なログを取り込む(まとめエントリ) | Microsoft Cloud Administrators 今回はWindows仮想マシンを使ったVMSSからログを取り込んでみます。以前やったLinux仮想マシンを使ったVMSSとやりたいことは同じです。 VMSS(Virtual Machine Scale Set)のLinux仮想マシンからのログ取り込み VMSSは適当に作成しました。 WindowsにはWindows用のCustom Script Extensionというものが存在してますが、これを利用してエージェントをインストールするのはUACが邪魔をしてうまくいきません。ですので専用の拡張機能を利用する形でよいでしょう。 拡張機能はAzure CLIからインストールします。Azure CLIはどこから使っても構いませんが、今回はAzure管理ポータルからCloud Shellを利用します。 実行するのは下記のコマンドです。 a z v m s s e x t e n s i o n s e t - n a m e M i c r o s o f t M o n i t o r i n g A g e n t - p u b l i s h e r M i c r o s o f t . E n t e r p r i s e C l o u d . M o n i t o r i n g - r e s o u r c e - g r o u p v m s s - n a m e - s e t t i n g s " { ' w o r k s p a c e I d ' : ' ' } " - p r o t e c t e d - s e t t i n g s " { ' w o r k s p a c e K e y ' : ' ' } " ...

July 6, 2021 · 2 min · 胡田昌彦

Azure LogAnalyticsワークスペースに様々なログを取り込む(まとめエントリ)

LogAnalyticsワークスペースには様々な種類のログを取り込むことが可能です。工夫すれば事実上すべてのログの取り込みが可能です。 シリーズとしてログをあれこれ取り込みまくってみたいと思います。記事を作成したら下記に項目を増やしてリンクしていきます。 ログの取り込み Azure LogAnalyticsワークスペース作成(Azure Monitorログ) - Azure上の仮想マシンからのログ取り込み- Azure外のWidows仮想マシンからのログ取り込み(エージェントインストール編)- Azure外のLinux仮想マシンからのログ取り込み(エージェントインストール編)- Azure Arcと連動したAzure外の仮想マシンからのログ取り込み- エージェントの構成(エージェントから取得するログの設定)- Azure LogAnalyticsワークスペースへのApacheログの取り込み - VMSS(Virtual Machine Scale Set)のLinux仮想マシンからのログ取り込み- VMSS(Virtual Machine Scale Set)のWindows仮想マシンからのログ取り込み - NSGフローログからのログ取り込み(Network Watcher) | Microsoft Cloud Administrators- App Serviceからのログ取り込み- Azure SQL DBからのログ取り込み- Azure Database for MySQLからのログ取り込み- Azure Database for PostreSQLからのログ取り込み- BIG-IP Cloud Editionからのログ取り込み ログの解析 Azure LogAnalyticsのカスタムログで収集した「RawData」を扱いやすくする(クエリ実行時のデータ解析)

July 5, 2021 · 1 min · 胡田昌彦

Azure外のWidows仮想マシンからのログ取り込み(エージェントインストール編)

下記のエントリがまとめエントリになっていますのでそちらも参照下さい。 Azure LogAnalyticsワークスペースに様々なログを取り込む(まとめエントリ) | Microsoft Cloud Administrators Azure内のWindows仮想マシンからのログ取り込みはAzure管理ポータル上で仮想マシンを指定するだけの簡単操作でした。Azure外の仮想マシンに対してはもう少しだけ手間がかかります。とはいえ、それでもとても簡単です。 今回はエージェントを直接VMにインストールする方法です。他にも先にAzure ArcでAzureに接続する方法もありますが、まずは基本としてこちらの方法を抑えておいてもらっても良いと思います。(ですが、色々とAzureを活用するならAzure Arcに接続して管理することをお勧めします。) Log Analyticsワークスペースにてエージェント管理をクリックします。 このページからエージェントもダウンロードできますし、接続するためのワークスペースIDやキーも入手可能です。 今回はオンプレミスのHyper-V上にWindows Server 2019の仮想マシンを用意しました。NAT配下に存在している仮想マシンです。 エージェントのインストーラーを入手し、実行します。 ウィザードをすすめていきます。 「Azureログ分析(OMS)にエージェントを接続する」にチェックを入れます。 ※Azure LogAnalyticsなのか、OMSなのか、Azure Monitorなのか・・・、色々と混乱してしまってますね。 ワークスペースIDとワークスペースキーをAzure管理ポータルから入手して入力します。 これで、構成は完了です!簡単ですね!

July 5, 2021 · 1 min · 胡田昌彦

ネットワーク接続が不安定な場合の対処方法

「ネットワーク接続が不安定になる」というトラブルは…残念ながら結構な頻度で発生する事象だと思います。私自身何度も様々なパターンで体験しています。 そして今日もまた…。 「ネットワーク接続が不安定」という問題は様々な要素が複合的にくみあわさって「完全につながらないわけじゃないけど、なんだか不安定」というような事が多いです。下記にかかれているものは私の経験上「よくあるもの」ではあるのですが必ずしも該当するわけでも設定変更することが必ずしも良いものでも全くありません。ですが、とりあえずパフォーマンスを犠牲にしてでも「安定」する方向の設定であることは間違いありません。一度下記を参考に「安定」方向に設定を変更してみて問題を切り分けてみるのは良いかと思います。 ドライバを最新版にする まずはNICのドライバを最新版にすることをお勧めします。この記事を見ている方はコンシューマー向けのPCを使われている方が多いと思いますので、各メーカーのドライバ更新用の専用ユーティリティーなどを利用してもらえればと思います。 ワイヤレスアダプタの省電力設定を無効化する ワイヤレスアダプタに関しては省電力の設定が存在するものがあります。とりあえず「最大パフォーマンス」で可動させるようにしましょう。 ※PC(NIC)によっては存在しない設定項目です。 NICの各種オフロード機能を無効化する NICの各種のオフロード機能は本来ハードウェアにネットワーク関連の処理を行ってもらうことによりネットワークパフォーマンスを向上させるための仕組みなのですが、場合よってうまく動作せずむしろ接続不良の原因となることがあります。一度各種オフロード機能を無効にして切り分けてみるのは多くの場合有効です。 オフロード系の機能を無効化します。どの項目が無効化していいものかわからないということもあると思いますが、項目名と現在の設定値を控えておいた上で無効化できるものは何から何まで全部無効化してまわってまず挙動の変化を確認するようなやり方を個人的にお勧めします。 MTUの引き下げ MTUはMaximum Transfer Unitの略でようはNICが送信するパケットの最大サイズに関係するものです。途中の経路で小さなパケットしか通せない部分があるにもかかわらず大きなパケットを送信することで経路の途中でパケットが破棄されてしまうような挙動が比較的多くあります。この場合通信できないわけではないのですが異様に遅い…というような挙動になります。最適なサイズを検出するような手法もありますが、まずは一度小さく設定してみて挙動を確認することをお勧めします。 これはコマンドプロンプトで設定するのが簡単です。 コマンドプロンプトを管理者として実行します。 まずはインターフェースの一覧を表示して名前や現在のMTUを確認します。 netsh interface ipv4 show subinterface 今回は「Wi-Fi」というInterfaceのMTUを1430に変更してみます。 netsh interface ipv4 set subinterface “Wi-Fi” mtu=1430 store=persistent 再度インターフェースの一覧を表示するとMTUが変更できたことが確認できます。 確認 設定を変更したら一度再起動した上で確認先のホストに継続的にping(icmp echo)を送信し応答を確認するのがお手軽です。 下記の例ではwww.google.comを宛先に設定させてもらっています。安定的に通信できている様子が見えますね。 これでもだめなら私としてはもうパケットをキャプチャしてしまってパケットレベルで処理を追うことをしてしまいます。流石にそれは必要となる前提知識の量が違いすぎるのでまた別エントリにしたいと思います。要望あれば…書くかも…しれません。

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

AnsibleでWindows VMの構成

今日は先日作ったTerraformファイルで作成したAzure上のVMに対して、先日作成したAnsibleが動作するコンテナ上でAnsibleのPlaybookを書いて、VMを構成してました。 - ドメインコントローラーに昇格(新規フォレスト作成) - 必要に応じて再起動 - StandAloneRootCAに構成 - 必要に応じて再起動 - サブジェクトの別名を利用可能に構成 - Azure Stackに必要な証明書のためのCSRを作成 というところまで自動化しました。 変な所で色々とハマりましたが、結局目的のところまではできたので良かったです。VMをAzure上にイチから作成するところから含めて全部やり直しても構築時間で15分もかからない感じに収まってます。 他にもDocker for WindowsをつかってLinuxコンテナを利用したり、実PCのファイルシステムをマウントしたり、Dockerfileを使ってのビルドをローカルPCとGitHub連携したDockerHub上でおこなったりというところもずいぶん慣れました。 ansibleでPSCredentialを渡す所でxxxx_username, xxxxx_passwordという形で表記しておけばよいだけとマニュアル上で読んだのですが、実はxxxxの部分に使う文字列によって挙動が異なるように見える部分があってかなり時間を無駄に消費しました。一部スペルミスもあったりなどもあり。よくわからないエラーが出たときには一度クリーンなところまで戻ってから文字をコピペせずに慎重に打ち直そう…と思ったのでした。 ansibleからPoweShellDSCを利用する部分も理解しましたし、昨日、今日で結構Terrafrom + ansible(+ PowerShell DSC)の組み合わせには慣れた気がします。 というわけで今日の成果はこちら。 - [https://github.com/ebibibi/hccjp/tree/master/VMConfigure](https://github.com/ebibibi/hccjp/tree/master/VMConfigure) 明日と明後日は贅沢に丸々2日間Puppetのトレーニングです!楽しみです。

July 18, 2018 · 1 min · 胡田昌彦

ansibleが使えるコンテナイメージ

TerraformでWindowsVMを展開した後はansibleで構成を自動化しようと考え中です。 Windowsからの管理は現実的に無理みたいなので、仕方なくDocker for Windows上のLinuxコンテナで管理しようとかんがえています。 ansibleの公式イメージをpullすれば瞬殺だろうと思ったのですが以下のあたりはもう公式ではイメージメンテナンスされてません、ということだったのでそのままの利用を躊躇してしまいました。 - [ansible/ubuntu14.04-ansible - Docker Hub](https://hub.docker.com/r/ansible/ubuntu14.04-ansible/) - [ansible/centos7-ansible - Docker Hub](https://hub.docker.com/r/ansible/centos7-ansible/) で、勉強も兼ねて自分でDockerfileを書きました。(あまり根本的解決になっていない気もしますが) - [ubuntu_ansible/Dockerfile at master · ebibibi/ubuntu_ansible](https://github.com/ebibibi/ubuntu_ansible/blob/master/Dockerfile) Dockerfile作成中には「pip install –upgrade pip」というコマンドも入れていたのですがこちらはpipの9と10のバージョン違いによるトラブルが発生してしまいうまく行かず。結局pipのアップグレードはやらないことにしました(逃げ)。 このあたりは下記ブログに解説されていました。 - [pip install --upgrade pip (10.0.0) 後の奇妙な挙動について - 雑記](http://icchy.hatenablog.jp/entry/2018/04/17/064443) 助かりました。ありがとうございます。 というわけで、Dockerイメージも準備できました。 - [ebibibi/ubuntu_ansible - Docker Hub](https://hub.docker.com/r/ebibibi/ubuntu_ansible/) 次は、このコンテナを利用して、Azure上に展開したWindowsVMを自動構成する予定です。明日時間取れる予定…! 業務時間にこうやって自分がやりたい領域のことを勉強しながら作業できるのは本当にありがたいです。(注意:遊んでいるわけではありません。仕事です。)

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

(主にインフラ系エンジニアから見た)コーディングやスクリプティングに関しての流れ

主にインフラエンジニアからみて、過去から現在までの流れ…のようなものを私が見えている範囲で記載してみました。昨今はクラウド化の流れと相まって非常に高度な自動化やインフラのコード化まで実現可能となっており例えば「スクリプトも書いたことありません」という人に対してどの領域から飛び込んでもらうのが効率的か…をちょっと悩んでいます。 もうコーディングレスでLogic Appとかそういうところに飛び込んでもらった方がはやいのかもしれないし、仮想基盤のことやWindows, Linuxの中の事はすっ飛ばしてTerraformとかコンテナとかそこに注力するところから入って必要が出たところで仮想マシン内部の処理に入ったほうがいいのかもしれません。でも、現実的にはシェルスクリプトとかPowerShellスクリプトの基礎とかは抑えておかないとだめかもしれないし・・・。結構悩ましい所です。 - 昔はバッチファイルやシェルスクリプトで繰り返し実施する作業の効率化がありました。 - その後Windows的にはWSHの時代があり、vbscriptでスクリプトを書いたひとも多かったと思います。 - その後Microsoft的にはコマンド毎にオプションが違ったりコマンドがなかったりすることを解決し、全て統一するものとしてPowerShellを生み出しました。(私の大好きな[Jeffery Snover](https://twitter.com/jsnover)さんの仕事です。) - これでMicrosoft系はPowerShellで全てオブジェクト指向の管理となりました。(バックグラウンドにあるのは.net framework) - 一方UNIX系は当初からなんでもかんでもテキストであるという思想でした。 - MicrosoftはPowerShellを標準として様々な製品を開発しました。GUIではできないことでもPowerShellでなら操作できる。GUIで操作しても裏ではPowerShellコマンドが自動生成されてそれが実行されている…というものも多くありました。(結果、仕方がなくPowerShellを使うようになった方も多いと思います。) - Microsoftはクラウドサービスにもその流れを取り入れました。PowerShellにてクラウドサービスの管理も行うことになりました。 - Chef, Puppetなどに代表されるような冪等性を備えた仕組みが登場してきました。(Infrastructure as code, Configuration as code) 何度実行しても「記載した望むべき状態になる」ことを特徴とします。 - これ以前は「これを実行したらこうなる、やって見る前に状態を確認して、やってみて、やった結果を確認する」というような作業の流れを記述するようなイメージでした。 - MicrosoftもPowerShell DSCにて冪等性を持つフレームワークを提供しました。 - Microsoftのオープンソース指向が進む中でよりマルチプラットフォーム化を意識した取り組みがなされるようになっていきます。 - PowerShellの継続開発が打ち切られ、PowerShellCoreに舵がきられます。PowerShellCoreはWindowsだけではなく、Linux, Mac等でも動作するマルチプラットフォームなPowerShellです。(バックグラウンドにあるのは.net core) - AzureにもCloudShellの機能がつき、ポータル上でもコードで制御できるようになります。これまでのAzure PowerShellよりも先にAzure CLI(UNIX系の文化)の方が先に搭載されました。Azure管理はPowerShellよりもCLIの方が優先されるようになってきています。 - クラウドサービスも普及する中で、大規模な環境ではもう個別に1台づつターミナルで作業するなり、RDPではいってGUIで操作するなりすることが現実的に不可能な規模になりました。このような環境ではコードで全てを制御可能な環境にすることは必須条件となりました。 - WindowsもWindows Server Coreが出てGUIがなくなり、さらにNano Serverにてどんどん軽量化していきます。 - Windows Server 2016, 2019となると継続的に進化するモデルはGUIが利用できなくなりました。 - 更に軽量化を推し進める中で仮想マシンではなく、コンテナに大きくトレンドが傾きます。 - コンテナの標準であるDockerはDockerfileというコンテナをコードで定義できる機構を備えています。 - クラウドサービスも冪等性をもったテンプレートにて展開可能な構造となります。AzureであればARMテンプレート、AWSであればCloud formationなど。 - ARMテンプレート、Cloud formationによるInfrastructre as Codeと仮想マシンの内部を構成するChef, Puppet, AnsibleのようなConfiguration as Codeによって仮想マシンベースの環境構築の完全自動化が可能となりました。 - ARMテンプレート、Cloud formationによるInfrastructre as CodeとDockerによるコンテナコントロールで完全自動化が可能となりました。 - 複数のコンテナプラットフォーム自体のコントロールという観点ではKubernetesが標準化してきています。 - AWSLambda, Azure Fuctionsのようなインフラ自体を意識せずアプリケーションロジックのみを記載すればそれでおしまいとなるようなサービスも出てきました。ここではInfrastructure as CodeやConfiguration as Codeすら必要ない世界があります。(これですべてまかなえるわけでもないですが) - DevOpsという流れもありますが、NoOpsに向かう流れの方が強そうに感じています。(私の感想) ※NoOpsはインフラ管理者がいらないという意味ではなく、極力インフラの面倒を見なくていいアーキテクチャを採用する、くらいの意味で捉えています。 ...

May 16, 2018 · 1 min · 胡田昌彦

2017/02/17 今週のトピックス

今週後半は暖かい日が続きましたね。春一番が吹いた地域もあったようです。 さて、今週のトピックスです。 - 3分でわかる Azure Managed Diskのしくみ 8 users 3分でわかる Azure Managed Diskのしくみ 1. FD A FD B 2. FD A FD B 3. https://docs.microsoft.com/ja-jp/azure/storage/storage-managed-disks-overv… [www.slideshare.net ](http://b.hatena.ne.jp/ebibibi/?url=http%3A%2F%2Fwww.slideshare.net%2F) - テクノロジー - あとで読む - [![ebibibi](https://ebiwordpress.azureedge.net/windowsadmin/profile_l.gif)](http://b.hatena.ne.jp/ebibibi/)ebibibi w, azure, b ![Twitterでのツイートを閲覧](http://cdn-ak.b.st-hatena.com/images/icon-twitter.png)34 clicks 2017/02/15 - なぜWindowsの標準ドライバーはすべて「2006年6月21日」のまま更新されないのか? - GIGAZINE 71 users Windows純正のドライバーのタイムスタンプはすべて「2006年6月21日」に統一されています。Windowsマニアでもなかなか知らなさそうなトリビアの理由をMicrosoftのエンジニアが明かしています。 Why are all Windows drivers … [gigazine.net ](http://b.hatena.ne.jp/ebibibi/?url=http%3A%2F%2Fgigazine.net%2F) - テクノロジー - あとで読む ...

February 17, 2017 · 2 min · 胡田昌彦

ドメイン参加時にSIDの重複を指摘してくれるようになってました

検証環境を構築していて、うっかりsysprepを実行し忘れていました。その状態でドメインコントローラーとメンバーサーバーを複製して構築し(ドメインコントローラーとメンバサーバーのSIDが同一)、メンバサーバーをドメインに参加させようとした所、以下のようにSIDの重複を指摘してくれました。 いつからこのような挙動になったのか知りませんが、ちょっと親切になりましたね! photo credit: wallace39 " mud and glory “ via photopin cc

April 19, 2014 · 1 min · 胡田昌彦

パフォーマンスカウンタをコマンドで設定する方法(コマンドじゃないとまともに登録できません)

何か問題があった時に頻繁にお世話になるパフォーマンスモニター。パフォーマンスモニターに必要なカウンタを登録し、状況を把握します。でも、パフォーマンスカウンタをGUIから登録しようとしてもまともに登録できないんですよね。10個程度までなら普通に動きますが、20個30個となるとまともにGUIが動かず、やっと登録できた!と思っても実際に取得してみると抜け落ちていたりします。 私の知る限り2003R2まではこのような問題はなかったのですが、2008以降でこのような問題が発生します。もしかして日本語環境だけなんですかね…。さすがにもう直ってるだろうと思っていたのですが、先日Exchange関連のトラブルがあって、プレミアサポートにExchange関連のパフォーマンスカウンタを根こそぎ取得を依頼され、頑張っても実施してみたらまともに登録取得できませんでした。 というわけで、GUIではやろうと思ってもできない大量のパフォーマンスカウンタをコマンドで簡単に取****得する方法を紹介します。 - 「管理者として実行」したコマンドプロンプトで「typeperf –q > counters.txt」を実行する。 - counters.txtを編集して取得したいカウンタのみ残す。 - 「logman create counter hogehoge –cf counters.txt」を実行する(hogehogeはデータコレクタセット名) この手順で簡単に大量のパフォーマンスカウンタを登録したデータコレクタセットの作成が行えます。手動で長時間かけて登録しようとしてがっかりした方。是非この方法を使って下さい。

April 6, 2014 · 1 min · 胡田昌彦

タスクマネージャーが更新されない

最近タスクマネージャーが更新されない現象が発生していて困っていました。起動した瞬間の状況のまま画面が変更されないんです。 調べてみたところ、表示メニューの中に「更新の頻度」という設定があり、そこで「一時停止」が選択されていました。 この設定を変更することできちんと更新されるようになりました。 こんな設定があるとは知りませんでした・・・。

January 7, 2014 · 1 min · 胡田昌彦

電源プランの変更

Windows Server 2008以降では電源プランの規定値が「バランス」になっています。 このままで良いケースも多々あるとは思いますが、やはりパフォーマンスを要求されるサーバーでは「高パフォーマンス」に設定しておくのが良いと思います。それだけでも随分パフォーマンスに差が出るケースがあるそうです。 全台で設定して回るのも大変なので、せっかくなのでPowerShellで設定する方法も調べてみました。 [gist id=7480767] このようにしてPowerShellで設定可能です。

November 15, 2013 · 1 min · 胡田昌彦

バッチファイルでWindows OSバージョンを判定する方法

バッチファイルでOSを判定する必要があったので、記録しておきます。 色々とやり方がありますが、今回はverコマンドの結果だけを見るようにしました。これだとサーバーOSなのかクライアントOSなのか見分けられませんが、そこまでみわけようと思うとsysteminfo.exeあたりの結果を見る必要があり、実行に時間がかなりかかってしまいます。カーネルが同じならできることはかなりの部分同じでありこの程度の分岐で事足りることも多いのではと思います。今回は必要なかったのでやりませんでしたが必要なら同じ要領でコマンドの結果からOS種類やServicePackの違いなどがわかる部分をfindコマンドで引っ掛ければさらに細かく分けられます。 [gist id=4722663]

February 6, 2013 · 1 min · 胡田昌彦

Windows Server Backup からのリストア後に使用されるドライバ

AskCoreブログにてWindows Server Backupとその後利用されるドライバについての記事が公開されています。重要な記事なので確認しておくべきだと思います。 Windows Server Backup からのリストア後に使用されるドライバについて - Ask CORE - Site Home - TechNet Blogs Windows Server Backup からのリストア後に使用されるドライバについて … 要点は以下です。 - WindowsPE、WindowsREでバックアップするためだけに、NICドライバやストレージ用のドライバを組み込んだ場合に、そのドライバがリストア完了後のシステムで使われてしまう場合がある。 - 場合によってはそれが原因でシステムが起動しない。 - Windows Server 2008 R2 以降であればHKLM\SYSTEM\CurrentControlSet\Services\wbengine\DoNotInjectDrivers (DWORD)に1を設定しておけばリストア用に組み込んだドライバはシステムには格納されず使われない。 - Windows Server 2008 R2以前のOSではリストア後のシステムでも利用できるドライバしかリストア時に組み込んではいけない。

December 23, 2012 · 1 min · 胡田昌彦

ファイルサーバーのデザインについてのあれこれ

ファイルサーバーのデザインについて質問を受けて、色々要素があって一応説明したけれどもあまり伝わらなかった気がするのでブログに書いておいてみます。 注意というか前提 何に関してもそうなのですが「どうするのがベストなのか?」という問いにはたいていの場合答えはありません。「いや、ベストってのはなかなかないよね。お客さんの使い方にあわせてベターな選択肢がいくつかあるという話であって、例外が無いなんていうことはあり得ないし…ごにょごにょ……」というのが本音であり、紳士的な回答だと思います。 #だいたい、何かにおいて「こたえはこれです!こうしておけば間違いない!」なんてのは騙そうとしているか、その人自身盲目になっちゃってるかですよね。 #怪しい宗教とか怪しいビジネスとか疑似科学なら断言するでしょうけどね! とはいえ、技術要素を抑えた上で「こうすればこうなる。一方こうすればこうなる。こういう前提ならこの選択肢がいいんじゃない?」ということは言えるし、お客さんの前では「お客様の環境や使い方を考慮すると、私としてはこのようなデザインと進め方をお勧めします。」ということはやっぱりプロとして言わなくちゃいけないですよね。それをするためには技術的なことを抑えた上でお客さんの希望や使い方を良く聞いて、自分の頭で考えてアイデアを出さなくちゃいけないです。 特にファイルサーバーのデザインや運用に関してははっきりいって「うまくいってる!」「こうすれば成功確実!」というようなものは聞いたことがありません。ファイルサーバーの権限管理は破綻し、ゴミファイルが散乱し、慢性的に容量不足で、組織変更の度にアクセス権設定とフォルダ構成変更とで多大な工数が必要となり…となってしまっている環境も多数あると思います。 そういう分野であるという認識の元、以下を読んでもらえればと思います。 抑えておくべき技術的な事 まず抑えておくべきは以下の事項です。 - [アクセス権の理解(NTFSアクセス権と共有アクセス権) - WindowsServer管理者への道](https://windowsadmin.ebisuda.net/2009/04/15/%e3%82%a2%e3%82%af%e3%82%bb%e3%82%b9%e6%a8%a9%e3%81%ae%e7%90%86%e8%a7%a3ntfs%e3%82%a2%e3%82%af%e3%82%bb%e3%82%b9%e6%a8%a9%e3%81%a8%e5%85%b1%e6%9c%89%e3%82%a2%e3%82%af%e3%82%bb%e3%82%b9%e6%a8%a9/) - [コピー&ペーストとカット&ペーストではNTFSアクセス権が異なる - WindowsServer管理者への道](https://windowsadmin.ebisuda.net/2008/10/30/%e3%82%b3%e3%83%94%e3%83%bc%e3%83%9a%e3%83%bc%e3%82%b9%e3%83%88%e3%81%a8%e3%82%ab%e3%83%83%e3%83%88%e3%83%9a%e3%83%bc%e3%82%b9%e3%83%88%e3%81%a7%e3%81%afntfs%e3%82%a2%e3%82%af%e3%82%bb/) アクセス権の設定個所は「NTFSアクセス権」「共有のアクセス権」の2つがあるので(Windows Server 2012ではさらにもう1つ増えましたがここでは触れない事にします。すぐに使われそうも無いので。)どちらかあるいは両方のパターンについてきちんと検討が必要です。 NTFSアクセス権を使ってアクセス権をコントロールすることに決めた場合にはそのファイルをコピー、移動した時のアクセス権の動きに付いても考慮が必要です。 その他にも知っておいた方がよい事柄を紹介します。 NTFSのアクセス権を維持したままファイルをコピーする方法はある - NTFSのアクセス権はxcopy, robocopy等のコマンドでオプションを適切につければ、コピーであってもアクセス権を維持することができる。 これについてはヘルプを見てもらえば一発で分かるかと思います。xcopyなら/oオプション、robocopyなら/SECオプションあたりで実現できます。 フォルダがネストしていて、別階層が共有されている場合ユーザーが混乱するかもしれない - 共有フォルダの作成方法によっては「同一のファイルに複数のUNCパスが存在する」という状況が起きる。しかもその際に共有のアクセス権の設定方法によっては「ある人は複数のUNCパスで同一のファイルを開けるのに、別の人はこちらのパスでは開けるけれども、別のパスでは開けない」ということが起きる。 これについてはちょっと補足説明があった方がいいでしょうか。例えば以下のパスがあるとします。 - D:¥Share →Shareとして共有(¥¥Server¥Share, 管理者のみフルコントロール) - D:¥Share¥Share2 →Share2として共有(¥¥Server¥Share2, Everyoneフルコントロール) さてここでD:¥Share¥Share2¥folder¥file1.txtというファイルがあったとします。このファイルは1の共有からたどると 「¥¥Server¥Share¥Share2¥folder¥file1.txt」というUNCパスになります。一方2の共有からだと 「¥¥Server¥Share2¥folder¥file1.txt」というUNCパスになります。 管理者であればどちらのUNCパスからでも同じファイルにアクセスする事ができます。一方管理者以外の人は1の共有からのパスにはアクセスできません(共有のアクセス権を持たないので)。しかし、2の共有からのパスにはアクセスする事ができます。 エンドユーザーがこの事を理解して「あの人はこの共有にはアクセス権を持たないからこっちの共有からのUNCパスを伝えてあげないとな」と、気を利かせてくれたりする……ということはかなり難しいと思いますし、それを期待してはいけないと思います。 また、この場合でも、NTFSのアクセス権のみで制御し、共有のアクセス権はだれでも何でもできるような権限設定の場合にはアクセス自体には何も問題が発生しない事になります。ユーザーさんはちょっと混乱するかもしれませんけどね……。 組織毎にフォルダ作成、権限設定をすると組織変更時に泣きたくなる 決行スタンダードなファイルサーバーの設計として、「組織毎に管理する」というのはあると思います。組織毎にセキュリティグループがあり、ファイルサーバーにも組織毎のフォルダがあり、その組織に所属する人はその中にアクセスできる(つまり、組織のフォルダに組織のセキュリティグループでのアクセス権が設定してある。共有アクセス権か、NTFSアクセス権かはここでは問わない)。 一見なんの問題もなさそうな、スタンダードな設計に思えますが以下の場合には悲惨な事になります。 - 組織が頻繁に変わる 組織変更の度にファイルサーバーの中のファイルやフォルダを移動して回らないといけなくなります。1つの組織が2つに分割したら?どのフォルダ、ファイルがどちらの組織に所属すべきなのかを全部担当者に聞いて回らないといけない事になります…。 - 別の部署と共有したいファイルが出てくる 別の部署と共有したいばあい共有用に別の場所をつくってそこに移動してもらうか、その特定のファイル、フォルダだけアクセス権を変更してしまうか…というようなイレギュラーな対応をする必要が出てくると思います。別の場所に移動するとその場所のアクセス権の設定はどうしても緩くなり、そうするとそこの使い勝手がいい物だからみんなそこにファイルを作るようになり…と当初の構成が無意味になってしまう事が良くあります。 かといって特定のファイル、フォルダだけアクセス権を変更すると、都度管理者が特別対応をしなくてはいけないので管理者の負荷が上がる上に、出来上がった特別ファイル、フォルダは次の部署移動の際にどう扱っていいのか分からない事に……。 ユーザーにフルコントロールを与えてしまうとデザインを維持できない ユーザーが自分で好き勝手できるようにフルコントロールを与えてしまうケースがあります。そうするとそのユーザーはそのフォルダ以下すべて完全に好き勝手できちゃいます。アクセス権も変更できてしまうので、ある程度の枠組みを決めてあったとしても事実上破綻します。もちろんそのフォルダ以下は完全に権限移譲するのと引き換えに管理責任もきちんと引き取ってもらえるのならいいのかもしれません。…が、部署毎のフォルダ構造があるなかに勝手に別部署用のフォルダを作られたりなどもできちゃうのでやはりフルコントロールは危ないと思います。 アクセス権はグループでつけておき、ユーザーはグループへの追加、削除で権限管理するのが大抵うまくいく これはかなり常識的な感じですが、アクセス権のエントリに個人名を出してしまうのは良くない方法だと思います。 - 個人で付与すると、アクセス権を追加、削除したいときにすべての場所に個別に設定を行う必要が出てくる。 - 個人にしておくと、その個人アカウントを削除したときにアクセス権のゴミが残ってしまう。(生SIDが見えちゃうやつですね。) - 「XXさんの後任なので同じ権限で」と言われても、くまなく見て回って個別にアクセス権をつけるしか無くなってしまう。 このようになってしまうので、まず、グループを作成し、グループで権限をつけ、そのグループメンバの追加削除でアクセス権のコントロールをするとうまくいきます。 ...

August 30, 2012 · 1 min · 胡田昌彦

典型的なWindows系トラブルシューティングの際の確認ポイントやよくある問題

このエントリでは典型的なWindowsクライアント、Windowsサーバーのトラブルシューティング時の確認ポイントやよくある問題についてまとめてみようと思います。 ログ確認 - イベントログ アプリケーション - システム - (監査)※監査ログを追う機会は比較的少ない - アプリケーションのログ デバッグモード、診断ログ的なものがあれば有効にする - 循環したり、切り捨てられるものが多いのですぐに回収する ダンプ - ダンプファイル確認 再現 - 再現性の有無を確認する - 再現手順を探す 設定差異 - 問題が発生する状況を確認する(問題発生時と未発生時) 端末 - ユーザー - OSバージョン - SPバージョン - 修正パッチ - ブラウザ(違うブラウザでの切り分け) - 導入ソフトウェア、アドオン 特にウイルス対策ソフトウェア(無効、除外による切り分け) - ログオンDC - ログオンサイト - ドメイン - ネットワーク設定 SNP - GW - DNS - NetBIOS over TCP/IP - WINS - IPv6 - コンポーネント - Windows FireWall パフォーマンス確認 - CPU - メモリ - ディスク - リーク メモリーリーク - ハンドルリーク 環境確認 - ネットワークトラフィック ブラックホールルーター問題 - SNP - ジャンボフレーム - DC複製状況 repadmin - GPO適用状況 gpresult - VSS動作状況 vssadmin list writers 問題発生時の動作確認 - ProcessMonitor - TCPコネクション状態 TCPポート枯渇 - パケットキャプチャ ...

April 23, 2012 · 1 min · 胡田昌彦

マルチホーム構成時の注意

今回はマルチホーム構成時の注意点についてです。マルチホームというのは要するにNICが2つ以上あって、複数のネットワークに足を出している状態のことです。結構な頻度でマルチホーム構成を選択し、やってはいけない構成でトラブルに遭遇するケースを見ています。しっかり抑えておきましょう。 デフォルトゲートウェイは1つだけ まず、一番初めに理解してほしいのは「デフォルトゲートウェイを2つ以上設定してはいけない」ということです。よく理解していない人は多くのケースで2つNICがあったら2つゲートウェイを設定してしまうようです。 でも、ちょっとよく考えてみてください。デフォルトゲートウェイというのは、自分が所属していないネットワークに向かって通信するときにパケットを投げる相手ですよね?それが2つ設定されていたら、どっちに投げたらいいんでしょう?困ってしまいますよね? どっちに投げてもきちんと相手まで届く構成であれば問題がおきないこともあるでしょうけれども、やはりこれはよくない構成です。場合によっては通信できないことになるでしょう。 - デフォルトゲートウェイは1つだけ設定する(1つのNICだけで入力し、ほかのNICでは空白にしておく) - 必要な経路に関してはスタティックルートを記述する このようにしておかなくてはいけません。 スタティックルートを記述 スタティックルートの記述・・・といってピンとこない方も多いかもしれませんね。基本的にNICが1つであれば必要ない設定ですから。でも2つ以上になったら、「このネットワークアドレスに向けての通信は、こっちの足からあのルーターに投げる」ということをしっかりと記述してあげる必要があります。 Windowsではこの設定は「route」コマンドで実施できます。経路の追加はroute addコマンドです。コマンドの説明は例のごとく@ITにお願いしちゃいます。 - [route - ルーティングテーブルの表示/設定を行う](http://www.atmarkit.co.jp/fnetwork/netcom/route/route.html) 注意点としては、再起動しても消えないように設定するには-pオプションをつける必要があることです。route printコマンドで経路情報を表示した際に、きちんと追加した経路が「Persistent Routes」として表示されることを確認しておきましょう。そうでないと、うまくいったと思っていたら1月くらいたって再起動したらまたおかしくなったなんていうことになってしまいます。 DNSを2つ以上設定しない またデフォルトゲートウェイの次に気をつけてたいのはDNSの設定です。特にInternet側とIntranet側なんていうようにNICが分かれていた場合、Internet側のNICにはインターネットの名前解決ができるDNSを、Intranet側のNICには社内のDNSを設定したくなる人も多いかと思います。 でも、よく考えてみてほしいのですが、両方に問い合わせるわけにはいきませんよね。もしも両方のDNSに同じドメインが存在したりしていたうえに異なるレコードが登録されているような場合には(これはありえないことではありません)、通信しようとするたびに名前解決の結果が異なるようなことにもなってしまいます。これはやはりだめです。 DNSに関してはどれが正解ということはないです。そのホストの必要に応じて、正しいDNSを参照させる必要があります。「両方のDNSを参照したい」と思ってしまうのなら、それはDNSの設計、構成が間違っている可能性があります。場合によってはhostsファイルを併用してもいいでしょう。 DNSへの登録に気をつける マルチホームの場合にはDNSへの登録にも気をつけてください。特に何も考えないと、ホストについている2つ以上のIPアドレスをすべて登録して、ラウンドロビンになってしまいます。特にDCでこれをやってしまうとかなりクリティカルな障害にもつながってしまいますので、特に気をつけてください。 DCに関してはマルチホーム時のマスタブラウザの問題もあるのでそもそもマルチホームにしないほうが良いです。でも、それでもどうしてもDCをマルチホームにしたいのであれば、Aレコードの自動登録をやめさせる必要があります。DCはNetlogonサービスが定期的に自身のDCとして動作するためのレコードをDNSに定期的に登録に行くようになっているからです。このあたりの手順は以下のKBを参考にしてください。 - [Active Directory communication fails on multihomed domain controllers](http://support.microsoft.com/?scid=kb%3Ben-us%3B272294&x=7&y=17) その他まだまだありますが・・・ 今回紹介したこと意外にもマルチホーム構成の時の注意点は色々あります。特にDMZとLANに足をだしていて、DMZ側のIPでサービスを提供しているようなときに、入力と出力で使うNICが異なるようになってしまったりとか・・・。2つ経路があるときに意図的に片方のネットワークを使わせようと思ってもうまくいかなかったりとか・・・。バックアップ専用のネットワークを作ろうとしたりするときとか・・・。 このあたりはちょっと複雑になりすぎるので、また機会を改めて解説させてもらおうと思います。とりあえず今回紹介した注意事項が基本中の基本ですので、まずはここから気をつけていってみていただければと思います。 参考URL - [マルチホーム コンピュータのデフォルト ゲートウェイ設定](http://support.microsoft.com/kb/157025/ja) - [[NT]同一ネットワークに複数のアダプタを接続した場合の障害](http://support.microsoft.com/kb/175767/) - [マルチホーム化されたブラウザに関する問題](http://support.microsoft.com/kb/191611/ja)

October 30, 2009 · 1 min · 胡田昌彦

ActiveDirectoryとは -認証、アカウント管理の視点-

ActiveDirectoryというと、色々な要素があり、なかなかとらえずらいですが、まずはひとつの見方として、認証、アカウント管理の視点からその進化の過程を見ていこうと思います。(※あくまでもひとつの見方です。) スタンドアロンPC まず、スタンドアロンPCではローカルでユーザー管理、アクセス制御を行います。ローカルにユーザーを作成することが出来、NT系のOSではローカルにユーザーを複数つくり、それぞれプロファイルを切り替えて使うことで1台のパソコンを共有する仕組みが備わっています。その上で他の人に見られたくないファイルには自分だけがファイルにアクセスできるようにアクセス権を設定することが出来ます。1台のWindowsマシン上で、マシンの共有とリソース権限の確保が実現されています。 複数のPCがあると困ること 複数のWindowsPCが存在すると、ユーザーアカウントデータベースはそれぞれのPCに個別に保持されます。アカウントとパスワードの組み合わせを複数覚える必要があるので少々不便になります。同じIDとパスワードにしてしまうことも考えられますが、ユーザーの登録作業は必須です。また複数PC間でリソースの共有ができないので、不便です。 ワークグループでのリソース共有 リソースの共有(例えば共有フォルダや共有プリンタなど)を実現するために、WindowsPC同士をネットワークでつなぎます。具体的にはNetBEUI、TCP/IPなどのネットワークプロトコルを構成し、相互に通信可能な状態にします。そのうえで、複数のマシンがネットワークに参加します。これをWindowsネットワークでは「ワークグループ」と呼びます。ワークグループに参加してしまえば、マイネットワークからネットワーク上のコンピューターの一覧が表示でき、共有したいリソースを「共有」し、他のPCに見せることが出来ます。しかし、ここでアクセス制御をする上で少々こまったことが起きます。 ワークグループでのリソース共有で困ること リモートのPCで共有されているリソースにアクセスしようとすると、IDとパスワードを聞かれてしまいます。これは他のPCにアクセスするためにはそのPCで有効なIDパスワードを入力し、そのPCのユーザーとしてアクセスする必要があるからです。複数のパソコンにアカウントデータベースが存在し、連携されていないのですからこれは当たり前です。 複数のパソコンで複数のIDが管理されており、パスワードも一致していないとしたら・・・かなり混乱します。これを避けるために、同じIDを全てのWindowsPCに登録し、パスワードもそろえてしまうという運用方法があります。これなら他のPCのリソースにいちいちID/Passwordを入力しなくてもアクセスすることが出来ます。 しかし、ある程度大きな規模でこれを実現しようとすると、1人新しく人が加わっただけで全てのPCにユーザーを登録して回らなくてはいけません。さらにセキュリティ対策のために、定期的にパスワードを変更する必要がある・・・などとなったら面倒でやっていられません。 アカウントデータベースの一元管理(NTドメイン) そこでアカウントのデータベースを個別のWindowsPCに持つのではなくて、一括してどこかにまとめて管理してしまおうという発想が出てきます。これがWindowsドメイン(NTドメイン)です。 NTドメインによって、認証やネットワーク資源の一元管理を行うことが出来るようになりました。 ユーザーはドメインに登録し、コンピューターはドメインに参加することで、ドメインに管理をゆだねます。PCにログオンするときや別のPCにあるリソースを使用する際には、アカウントデータベースとしてNTドメイン上のアカウントデータベースを利用するわけです。これで、どのPCにでも誰でもログオンでき、別のPCにあるリソースにアクセスする際に、一々ID,パスワードを入力する必要がなくなりました。 (余談)ローカル管理から一元管理への流れ ホスト名の解決にしても、NETBIOS名の解決にしても、データベースにしても、たいていのものはローカルでの管理から始まって、ネットワーク上で共有する方向に向かっているように思われます。 NTドメインの問題点 こうしてNTドメインにアカウント情報が共有され、クライアントPCもドメインのリソースとして登録すれば、どのPCにでもログオンできるし、リソースの管理も一元化できます。しかし、以下の問題点が・・・。 扱えるオブジェクト数の限界 NTドメインでは単一のドメイン内で扱えるオブジェクト数がそれほど多くなく約4万が限界でした。そのため大規模な環境の場合、アカウントを登録するドメインとは別にリソースを登録するドメインを分ける・・・ということを余儀なくされることがありました。 管理者の権限 ドメイン内においてドメイン管理者は全てのオブジェクトに大しての権限を持つことになります。本来であればひとつの拠点や部署など小さな単位で管理権限を与えたい場合でも、一般ユーザーでない場合にはドメイン管理者にせざるを得ず、不必要に強い権限を与えなくてはいけませんでした。これを避けるためには、これまたドメインを分割する必要がありました。 信頼関係の管理 上記のような理由からにドメインを分割した場合には相互に連携するために、信頼関係を結ばなくてはいけません。この信頼関係はドメインが増えるたびに全て追加で個別に登録の必要があったため、維持、管理に問題がありました。 シングルマスタ NTドメインではアカウントの管理は一元化されたものの、大規模に展開するためには、そのデータベースを複数用意し、参照できる必要があります。そうしないとトラブル発生時に全ての情報が失われてしまい、機能がストップしてしまうことになります。NTドメインではこれはPDCがマスター、BDCがバックアップといった具合に実現されています。 しかし、データベースの更新処理自体はPDCにしか行えず、PDCのデータのコピーをBDCが保持するという形態になっていたため、運用上少々不便でした。例えば、PDCが無い拠点とのネットワーク経路に障害が発生したような場合には、PDCにアクセスできず、ユーザー情報の更新すらできなくなってしまいます。 ActiveDirectoryでの改善 ActiveDirectoyでは上記の問題点が解消されています。 扱えるオブジェクト数の限界 ActiveDirectoryでは単一のドメインで扱えるオブジェクトの数が100万オブジェクト以上となり、事実上オブジェクト数のみを問題としてドメインを分割する必要はなくなりました。 信頼関係の管理 ActiveDirectoryでは「ActiveDirectoryフォレスト」というものを形成し、自動的に推移的な信頼関係を構築するので、信頼関係の維持管理にかかるコストが減少しました。 同一フォレストに子ドメインを作成すれば、自動的に信頼関係を結んでくれるようになったのです。 管理者の権限 ActiveDirectoryでは単一のドメインの中にOUという管理組織を作成することができ、その中にオブジェクトを格納できます。その上でそのOUに対して管理の委任を行うことができ、「このアカウントにはこのOUの管理を任せる」ということが出来るようになりました。 これによってわざわざドメインを分割することなく、1つのドメインの中で管理の制御が行えるようになりました。 シングルマスタからマルチマスタへ ActiveDirectoryではドメインコントローラーが対等な立場として存在し、そのドメインコントローラーでも情報の更新が行えるマルチマスタモデルになりました。 ただし、全ての機能が対等に存在しているわけではなくて、5つの機能(フォレスト単位で2つ、ドメイン単位で3つ)に関しては単一のドメインコントローラーが保持しています、これはFSMO(フィズモ)の役割などと呼ばれます。FSMOに関しては別のところで述べます。 ActiveDirectoryのいけてないところ 色々改善されたActiveDirectoryですが、悪いところも多々あります。 データベース容量 扱えるオブジェクト数の限界は増えたものの、その分データベースにしわ寄せが来ている印象があります。データベースエンジンはMicrosoftおなじみのExtensible Storage Engine(ESE)です。それぞれのオブジェクトが消費するデータベースが結構大きく、削除済みのオブジェクトも規定で60日間、2003R2以降では180日間保持されます。なので、オブジェクトの絶対数はそれほどでもないけれども、毎日大量に削除~作成を行うようなシステムでは容量は要チェックです。 テストフェーズだからといって、大量にオブジェクトを生成、削除を繰り返していると、DBが肥大化してしまうことになりますので、気をつけましょう。 信頼関係の管理 フォレスト内での信頼関係はいいのですが、その他のNTドメインや別フォレストと信頼関係を結ぼうとすると、結局以前のNTドメインの際の問題に直面します。ある意味仕方ないのかもしれませんが・・・。 ※ただし、フォレスト間の信頼関係に関してはWindowsServer2003で改善されています。 - [Active Directory フォレスト間信頼機能](http://www.microsoft.com/japan/windowsserver2003/evaluation/demos/flash_animations/01forest.htm) OUへの効率的なリソース配置 OUを分けることで管理を委任できる・・・というところが売りなのですが、OUに対していかに効率的にリソースを移動、配置するかという点はあまりサポートされていません。たとえば、コンピューターオブジェクトは普通にドメイン参加するとComputersコンテナに作成されるので、そこから手動でOUに移動する必要があります。ドメイン参加の際にコンピューターオブジェクトが作成される規定の場所を変更することは可能ですが、それも別の1箇所に変更するのみであって、条件によって振り分けるようなことは出来ません たとえば、あるOU以下しか管理権限がない場合に、単純にドメイン参加すると、Computerオブジェクトが管理下にないOUに作成されてしまい、手も足も出なくなってしまいます。このような場合、先にコンピューターオブジェクトを管理下のOUにつくっておけば問題は回避できますが・・・。 OUへのオブジェクトの配置は今のところ独自にアプリケーションを開発するなどして管理してあげる必要があります。 シングルマスタ、マルチマスタ 複数のDCに書き込めることのメリットも確かに沢山あるのですが、複数に書き込めるようになった分だけその整合性を取るところでおかしなことが起きます。書き込んだつもりの情報があとから更新された情報によって上書きされたり、削除したはずのオブジェクトを再作成しようとすると、まだ削除の情報が全てのDCに伝わっていないためにエラーではじかれてしまったり。最悪なのはDC間の同期がおかしくなった場合です。この場合完全に全ての最新の情報を救うのは絶望的になります。DC間の同期の正常性の確保は非常に重要です!

March 10, 2009 · 1 min · 胡田昌彦

AI・テクノロジーの情報を発信しています

YouTube

AI・テクノロジーの最新トレンドを動画で配信中

note

技術コラム・深掘り記事を公開中