Q&A

字幕テキストがかなりノイズの多い自動認識結果ですが、読み取れる内容から忠実に記事化します。 【Q&A】Office 365の「テナント」の意味 この記事の内容 「テナント」という言葉は、文脈によって意味が変わる曖昧な用語です クラウドサービスにおける「テナント」は、Azure Active Directory（Entra ID）と結びつけて考えると理解しやすいです 1つの企業が複数のテナントを持つケースも存在します 「テナント」という言葉自体を使わないことが、混乱を防ぐためのおすすめアプローチです 「テナント」はなぜわかりにくいのか Office 365を使い始めたとき、「テナント」という言葉の意味がいまいちよくわからない、という方は少なくありません。 その理由の一つは、「テナント」という言葉が文脈によって扱いが変わってしまうからです。明確な定義があるわけではなく、使われる場面によってニュアンスが異なります。 クラウドサービスにおけるテナントの考え方 クラウドサービスにおける「テナント」は、**Azure Active Directory（Entra ID）**と結びつけて考えると理解しやすいです。 Azure Active Directoryのディレクトリ（テナント）が実体としてあり、Office 365はそのテナントと紐づく形で利用されます。 企業が複数のテナントを持つケース 「テナントは1企業に1つ」とは限りません。1つの企業が2つのテナントを持つ、という構成もあり得ます。 このような状況があるため、単に「テナント」とだけ言ってしまうと、どのテナントを指しているのかが不明確になってしまうことがあります。 おすすめは「テナント」という言葉を使わないこと 曖昧な言葉を使うことで混乱が生じやすいため、「テナント」という言葉自体を使わない、というアプローチがおすすめです。 「テナント」と言う代わりに、「Azure Active Directory」や「Entra IDのディレクトリ」など、より具体的な言葉で表現することで、誤解や混乱を防ぐことができます。 まとめ 「テナント」は文脈によって意味が変わる曖昧な用語です。クラウドサービスにおいては、Azure Active Directory（Entra ID）と同義として扱われることが多いですが、企業が複数のテナントを持つケースもあるなど、単純に「テナント＝1社に1つ」とは言い切れません。 混乱を避けるための最善策は、「テナント」という言葉をなるべく使わず、より具体的な用語（Azure Active Directory、Entra IDのディレクトリなど）で話すことです。曖昧な言葉を排除するだけで、コミュニケーションの齟齬を大幅に減らすことができます。

字幕テキストが自動認識による文字化けが激しく、具体的な手順・コマンドを忠実に抽出することが困難な状態です。「勝手な情報を追加しない」ルールに従い、読み取れた範囲のみで記事化します。 【Q&A】現在時刻を取得したファイルをCドライブ直下に保存する方法 この記事の内容 「現在時刻を取得して、その情報をファイル名や内容に含めたい」というQ&Aへの回答です 保存先をCドライブ直下（C:\）にする際のポイントを解説します Cドライブ直下への書き込みにはアクセス権限の問題が伴うことを説明します 実際に動作するデモを通じて確認する内容です 質問の内容 今回のQ&Aでは、「現在時刻を取得して、Cドライブの直下にファイルを保存するにはどうすればよいか」という質問が寄せられました。 Cドライブ直下への保存とアクセス権限 Cドライブ直下（C:\）にファイルを保存しようとする際、注意が必要なのがアクセス権限の問題です。 Windowsでは、C:\ 直下への書き込みは管理者権限が必要なケースがほとんどです。一般ユーザー権限でスクリプトや処理を実行した場合、アクセス拒否のエラーが発生することがあります。動画内でもこのアクセス権限の話が取り上げられており、実行環境の権限設定を確認することが重要なポイントとして示されています。 デモの概要 動画では、現在時刻（日時）を取得し、それをファイルに反映してCドライブ直下に保存するデモが行われています。日付・時刻のフォーマットについても言及があり、実際に保存されたファイルの中身を確認する流れで進められています。 まとめ 現在時刻を取得してファイルに含める操作は、スクリプトを用いることで実現できます Cドライブ直下（C:\）への書き込みには、管理者権限が必要になる場合があります 権限エラーが発生した場合は、スクリプトの実行権限や保存先のアクセス設定を確認しましょう 開発・テスト目的であれば、C:\ 直下よりもユーザーフォルダ配下などアクセスしやすい場所を保存先として検討するのも有効です 注記: 本記事は字幕テキストの自動認識精度が低く、具体的なコマンドや詳細手順を正確に読み取ることができなかったため、動画から確認できた範囲のみで構成しています。正確な手順については動画本編をご確認ください。

【Q&A】ADドメイン間のユーザー移行にCSVDEは使えません この記事の内容 ADドメイン間のユーザー移行にCSVDEコマンドを使おうとした際に発生するよくある誤解を解説します CSVDEが「使えない」理由と、何のためなら使えるかを整理します ドメイン移行で本当に重要なのはSIDヒストリーの引き継ぎであることを説明します ドメイン移行に適切なツール（ADMT）を紹介します 質問の内容 「ActiveDirectoryのユーザー移行について教えてください。Windows Server 2016環境にドメインのユーザーやグループを移行したいのですが、CSVDEコマンドを使ってインポートしようとするとエラーが発生します」 このような質問はよく寄せられます。まず結論からお伝えすると、ドメイン間のユーザー移行にCSVDEを使うのはそもそも適切ではありません。 CSVDEとは何か CSVDEは、ActiveDirectoryのオブジェクト（ユーザー、グループなど）をCSV形式でエクスポート・インポートするためのコマンドラインツールです。 csvde -f export.csv -r "(objectClass=user)" 同じドメイン内で同名のユーザーを大量作成したい場合や、テスト環境で本番環境と同じ構成のユーザーを素早く用意したい場合には有効です。たとえば「テスト環境に本番と同じユーザーを作りたい」といったシナリオであれば、CSVDEは十分に活用できます。 ドメイン移行にCSVDEが使えない理由 ドメイン間のユーザー移行においてCSVDEが使えない最大の理由は、SIDヒストリー（SID History）を引き継げないからです。 Windowsのアクセス権限は、ユーザー名ではなくSID（セキュリティ識別子）に紐付いています。ドメインが変わると新しいSIDが割り当てられるため、たとえ同じユーザー名でアカウントを作り直しても、移行前にアクセスできていたリソース（ファイルサーバー、共有フォルダなど）へのアクセス権限は引き継がれません。 CSVDEはあくまでADオブジェクトの属性をCSVで出し入れするツールであり、SIDヒストリーをきちんと移送する仕組みは備わっていません。 つまり、「ユーザーを移行した」はずなのに「リソースにアクセスできない」という問題が発生します。これが、ドメイン移行にCSVDEが適さない本質的な理由です。 ドメイン移行に適切なツール：ADMT ドメイン間のユーザー移行には、**ADMT（Active Directory Migration Tool）**を使用してください。 ADMTはMicrosoftが提供するドメイン移行専用ツールで、以下を適切に処理します。 ユーザー、グループ、コンピューターオブジェクトの移行 SIDヒストリーの引き継ぎ（移行後も旧ドメインのリソースにアクセス可能） パスワード移行（Password Export Server（PES）と組み合わせて使用） SIDヒストリーが引き継がれることで、移行後のユーザーは移行前と同様にファイルサーバーや各種リソースにアクセスし続けることができます。これがドメイン移行における最も重要なポイントです。 まとめ 用途 CSVDEの適否 同ドメイン内での一括ユーザー作成 ✅ 使用可 テスト環境への同名ユーザー作成 ✅ 使用可 ドメイン間のユーザー移行 ❌ 使用不可 ドメイン間のユーザー移行は、単純に「同じ名前のアカウントを作り直す」作業ではありません。SIDヒストリーを含めたアクセス権限の完全な引き継ぎが不可欠です。 そのためには、CSVDEではなく**ADMT（Active Directory Migration Tool）**を正しく学んで使用することが重要です。移行プロジェクトを始める前に、ADMTの仕組みとSIDヒストリーの概念をしっかり理解しておくことをお勧めします。

任意のメールアドレスでMicrosoftアカウント（個人用）を作成する方法 この記事の内容 既存のメールアドレス（Outlook以外）をMicrosoftアカウントのIDとして利用できる アカウント作成画面で「新しいメールアドレスを取得」ではなく、既存アドレスを入力する手順を解説 作成時に確認メールが送られ、そのメールアドレスをIDとしたMicrosoftアカウントが完成する Azure Active Directoryに登録済みのドメインでは個人用アカウントを作成できない点に注意が必要 任意のメールアドレスをMicrosoftアカウントとして使う 「すでに持っているメールアドレスをMicrosoftアカウント（個人用）として登録したい」という場面があります。Outlookアドレスを新規取得しなくても、既存のメールアドレスをIDとしてMicrosoftアカウントを作成できます。 作成手順 Microsoftアカウントの作成ページにアクセスします。「サインイン」の画面が表示されたら、「作成」または「アカウントをお持ちでない場合は作成できます」のリンクを選択してください。 アカウント作成の画面では、「新しいメールアドレスを取得」というリンクが表示されていますが、ここではそちらを選択しません。代わりに、入力欄に自分が所有している既存のメールアドレスをそのまま入力します。 例 : y o u r n a m e @ e x a m p l e . c o m メールアドレスを入力して次へ進むと、入力したアドレス宛に確認メールが送られます。メールに記載されたコードを入力して手続きを進めることで、そのメールアドレスをIDとしたMicrosoftアカウント（個人用）が作成されます。 注意点：作成できないメールアドレスがある 任意のメールアドレスで作成できる一方で、一部のドメインでは個人用Microsoftアカウントの作成ができないケースがあります。 具体的には、そのメールアドレスのドメインがすでにAzure Active Directory（Azure AD）に登録されている場合です。 以前はこのような制限はありませんでしたが、現在は作成できないようになっています。これは、組織が管理するドメインで個人用アカウントが作られると、管理責任の所在が曖昧になったり、退職後のアカウントの扱いが問題になったりするなど、さまざまなトラブルの原因となるためです。 該当するドメインのメールアドレスでアカウント作成を試みると、作成できない旨のメッセージが表示されます。 まとめ OutlookやHotmailアドレスを新規取得しなくても、既存のメールアドレスをMicrosoftアカウントのIDとして登録できます。 作成画面では「新しいメールアドレスを取得」を選ばず、入力欄に既存のアドレスを直接入力するのがポイントです。 ただし、Azure Active Directoryにドメインが登録済みの場合は個人用アカウントの作成が制限されます。会社のメールアドレスなどで作成しようとした際にエラーが出る場合は、この制限に該当している可能性があります。

字幕テキストから記事を生成します。 【Q&A】組織用にMSクラウド環境をゼロから作成する方法 この記事の内容 Microsoft クラウド環境を組織向けに構築する際の正しい手順と順番を解説します Azure Active Directory（Entra ID）を最初に作成することが最重要ポイントです Microsoft 365 / Office 365 ライセンスは必ず既存の Azure AD テナントに紐付ける必要があります 完全新規パターンとオンプレミス AD が既存のパターン、2つのシナリオを紹介します 誤ったテナントにライセンスを紐付けてしまう典型的なミスとその回避策を説明します はじめに：なぜ順番が重要なのか 「組織向けに Microsoft クラウド環境をゼロから作りたい」というご質問をよくいただきます。この作業で最も多いトラブルが「順番を間違えること」です。Office 365 を先に購入してしまったり、異なる Azure AD テナントにライセンスが紐付いてしまったりするケースが非常に多く見られます。 正しい順番を理解してから作業を進めることが、後々の混乱を防ぐ最大のポイントです。 全体の流れ（正しい順番） 組織向け Microsoft クラウド環境を構築する際の正しい順番は以下のとおりです。 Microsoft アカウントを用意する Azure ポータルで Azure Active Directory（テナント）を作成する Microsoft 365 / Office 365 ライセンスを購入し、作成したテナントに紐付ける ユーザーを作成し、ライセンスを割り当てる Windows 10 / 11 デバイスを組織アカウントに参加させる この順番を守ることが非常に重要です。 パターン1：完全新規でゼロから作成する場合 Microsoft アカウントの準備 まず Microsoft アカウントが必要です。Azure ポータルにアクセスするための入り口となります。Microsoft アカウントをお持ちでない場合は事前に作成しておいてください。 新しいメールアドレスを使って作成することをおすすめします。 Azure ポータルで Azure AD テナントを作成する Microsoft アカウントで Azure ポータル（https://portal.azure.com）にサインインします。 ...

IDディレクトリ・テナントは絶対に1つがいい！その理由と背景 この記事の内容 Azure AD（Microsoft Entra ID）のテナントを複数作ってしまう問題とその背景を解説します オンプレミスのActive Directory時代から繰り返されてきた「複数ディレクトリ」の失敗パターンを振り返ります テナント分散がなぜ後々の大きな苦労につながるのかを具体例とともに説明します Microsoftが推奨するシングルテナント・シングルドメインのベストプラクティスについて解説します 短期的な個別最適が長期的な全体最適を妨げる構造的な問題を考察します テナントが複数に分散してしまうよくある相談 最近、「グローバルにテナントが複数あります。これを1つに統合できますか？」という相談が増えています。さまざまな方がそれぞれに作ってしまったテナントを、あとから修正したくないという状況です。 統合が可能かどうかという話になると、「めちゃくちゃ大変ですよ」という答えになります。そもそもなぜ複数のAzure ADを作ってしまったのか、という話になると、「複数テナントにしたらあとで苦労する」というのは最初から分かりきっている話なのです。 オンプレミスActive Directory時代から続く同じパターン この問題はクラウドに限った話ではありません。オンプレミスのActive Directory（AD）の時代から、まったく同じことが繰り返されてきました。 NTドメインからActive Directoryへと移行し、フォレストと呼ばれる木構造でドメインを管理するようになりました。複数のフォレスト間で信頼関係を設定することもできましたが、結局どんなテクノロジーでも、「何かを作り、その有効な範囲がある」という構造は変わりません。 グローバルな企業グループでも複数テナントを作ってしまうと、後からの統合作業は非常に困難です。実際に、日本・アメリカ・ヨーロッパにそれぞれADが存在していたものを1つに統合する大プロジェクトが行われた事例もあります。その作業内容は以下のようなものです。 親フォレストとなる集約用フォレストを作成する ADMT（Active Directory Migration Tool）でユーザーアカウントを移行する アクセス権を継承・付与し直す コンピューターを新しいドメインに参加させる プロファイルを移動する ローカルのSIDをマッピングして書き換える 世界中の拠点を回りながらこれだけの作業をすることになります。最初からMicrosoftが推奨する「シングルドメイン」のベストプラクティスに従っていれば、必要なかった作業です。何年もかけて、膨大な人数を投入して実施するはめになりました。 クラウド時代にも繰り返される同じ失敗 オンプレミスの苦労を経てクラウドの時代になり、「同じ失敗を繰り返すのはやめましょう」と言い続けているにもかかわらず、Azure ADでも同じことが起きています。 よくあるパターンの1つが、「Office 365を使うためのAzure ADを新しく作った」というものです。既存のオンプレミスADとは別にテナントを作り、後から同期しようとするケースです。これが後々の混乱の元になります。 また、Azure ADにはリージョン（地域）の属性があります。日本のテナント、アメリカのテナントというように、リージョンによって使えるサービスや契約できる機能が異なる場合があります。「このユーザーではこのサービスが使えないけれど、別のリージョンのテナントなら使える」という理由で別テナントを作り出す人たちが出てくると、どんどんカオスな状態になっていきます。 テナントを1つに保つことが正解である理由 グループ企業でも、テナントは1つに統一してみんなが仲良く使うのが正しい姿です。Azure ADのガバナンスをきちんと管理し、誰がどのアプリケーションを作れるかをコントロールする仕組みを整えることが重要です。 特にMicrosoftのクラウドサービスを中心に利用していく場合は、Azure AD（Microsoft Entra ID）に寄せることを強くおすすめします。考え方は明確です。 テナントは1つ すべてのSaaSサービスをそのAzure ADと連携させる 1つのIDで複数のサービスを使う これが間違いのない構成です。 短期的な個別最適が長期的な全体最適を妨げる 狭い視点だけを見て個別最適に走ってしまうと、全体を眺めたときに最適な状態が実現できません。「なぜ最初からそう考えなかったのか」という話になります。 ベンダーの思想や方向性を理解した上で、どこを中心に据えるかを最初に決めることが大切です。多少の不便があっても受け入れ、長い目でサービスの流れに沿った使い方をしておけば、長期的には幸せになれます。 逆に、短期的・局所的な問題を解決するために本来の方向性に沿わない実装を追加してしまうと、どんどん複雑化します。その結果、本来の方法でその問題が解決された時期が来ても、独自の実装があるために新しい解決策を取り入れられない状況になります。「新しい機能を使いたいけれど、この構成のままでは使えない」という問題がずっと続くことになります。 まとめ オンプレミスのActive Directory時代から現在のAzure AD（Microsoft Entra ID）に至るまで、「ディレクトリを複数に分散させてしまう」失敗は繰り返されています。後から統合しようとすれば、膨大な工数とコストがかかることは最初から目に見えています。 Microsoftは一貫して「シングルドメイン・シングルテナント」をベストプラクティスとして推奨しています。Microsoftのクラウドサービスを中心に使っていくのであれば、テナントは1つに統一し、すべてのサービスをそのIDと連携させる構成が最善です。 短期的な不便や個別の事情から複数テナントを作る誘惑は常にありますが、長い目で見て本筋の流れに沿った構成を最初から選ぶことが、本質的な苦労をしないための近道です。

拠点にドメインコントローラーを残すべきか？ ゼロトラスト時代のActive Directory設計を考える この記事の内容 拠点のActive Directory Domain Controllerをデータセンターへ集約する際の推奨アプローチを解説します 回線品質が十分な場合にDCを集約してもよい理由と、その際のリスクについて整理します ドメインコントローラーの「移動」ではなく「追加と降格」が推奨される理由を説明します ファイルサーバー・プリントサーバーの扱いなど、集約を妨げる現実的な課題を取り上げます ゼロトラストネットワーク・クラウドへの移行を見据えた、より本質的な設計方針を紹介します ドメインコントローラーを「移動」してはいけない ADの移行プロジェクトで拠点のドメインコントローラー（DC）をデータセンターへ集約する場合、既存のDCをそのまま「引っ越し」する方法は推奨されません。 DCにはサイトリンクやDNSの設定など、環境に紐づいた多くの情報が含まれています。そのため、既存のDCを物理的・論理的に移動するよりも、次のような手順が推奨されます。 データセンター側に新しいDCを追加する レプリケーションが正常に機能していることを確認する 拠点側の古いDCを降格（デモーション）して削除する この「追加してから降格する」アプローチのほうが安全で、トラブルが発生しにくい構成です。 回線が強ければ、拠点にDCは不要か 「拠点の回線が十分に強い」という前提であれば、DCをデータセンターに集約してしまっても問題ないケースは多くあります。実際に、拠点にはDCを一切置かずデータセンターに全て集約して、問題なく運用されているお客様の事例も多数存在します。 DCの負荷自体は非常に低く、Windowsが登場した初期のころとは異なり、現代のサーバースペックであれば1台で数万・数十万ユーザーのリクエストも十分にさばけます。 拠点DCが不在のときに起きること ただし、DCをデータセンターへ集約した状態で回線が切れた場合には、次のような問題が発生します。 PCがドメインに対してログイン認証しようとしても、DCに到達できないためロックインができない ドメインログイン時に時間がかかる、または失敗する この問題への対処として、キャッシュ認証情報によるログインが利用できる場合があります。一度ログイン済みのアカウントであれば、キャッシュを使って認証を通過できます。 どの程度のリスクを許容するかは、BCPの設計方針や組織の要件によって異なります。ファイルサーバーなど他のリソースも同様に切断されるなら、拠点にDCだけ置いても意味がないという考え方もあります。 DCを拠点に残す判断基準 拠点にDCを残すかどうかは、最終的には次の観点から判断することになります。 回線品質: 専用線や安定した回線が確保されていれば集約で問題ない BCP要件: 回線断時にどのレベルのサービス継続を求めるか 運用能力: オフィスにサーバールームがあり、温度・電源管理、セキュリティ管理が適切に行えるエンジニアが常駐しているか サーバー台数とスペース: サーバーが増えると発熱も増え、サーバールームに収まらなくなることがある サーバーの適切な管理体制がある環境では、近くにDCを置く利点もあります。一方で、管理が難しい場合はデータセンターに預けるほうがメリットが大きいことも多いです。 集約を妨げる現実的な課題：ファイルサーバーとプリントサーバー DCの集約を検討する際に、よく障壁となるのがファイルサーバーとプリントサーバーの存在です。 「回線が切れても、このファイルサーバーだけは拠点で使い続けたい」というニーズがあることで、拠点にサーバーを残さざるを得ないケースがあります。 Azure FilesのAD認証（プレビュー） この課題に対して、Azure FilesのAD認証機能がプレビューとして利用可能になっています。従来はAzure FilesにAD認証を統合するのが難しい状況でしたが、ドメイン参加したアカウントでAzure Filesへ認証アクセスできるようになってきています。 これにより、拠点のファイルサーバーをAzure Filesに移行し、AD認証もクラウド側で完結させる構成が現実的になりつつあります。 プリントサーバーについては、クラウドプリントサーバーの選択肢もありますが、まだ課題が残る部分もあり、プリンター自体をAD連携なしで運用する方法も検討に値します。 ゼロトラストの世界観へ：そもそもVPNを使わない設計 DCを拠点に置くかどうかという議論自体が、実は時代遅れになりつつあるという視点もあります。 テレワークやリモートワークが普及した現代では、「拠点間の回線がつながっていること」を前提とした設計から脱却し、次のような設計方針が求められています。 システムはインターネット越しにアクセスできる構成にする Microsoft 365などのSaaSはもちろん、社内システムもインターネット経由でアクセス可能にする PCからでもスマートフォンからでも、インターネットさえ繋がれば全てのサービスが使える この世界観では、拠点間のVPN（サイト間VPN）に依存する構成ではなく、EntraID（旧Azure AD）やアプリケーションプロキシなどを活用した、よりモダンなゼロトラスト構成を目指します。 [ 拠 [ P 従 点 ゼ C 来 ロ の ─ ト / 構 ( ラ 成 専 ス ス ] 用 ト マ 線 構 ー / 成 ト V ] フ P ォ N ン ) ─ ─ ( デ イ ー ン タ タ セ ー ン ネ タ ッ ー ト ) ─ ─ A E D n t D r C a / I D フ ァ / イ ル A サ z ー u バ r ー e F i l e s / S a a S データセンターに自社システムが残る過渡期でも、インターネット経由でアクセスできる構成に整えていくことが、将来を見据えた方向性です。 ...

【Q&A】ソフトのインストールのたびに認証を求められる — UACの仕組みと設定方法 この記事の内容 ソフトをインストールするたびに許可やパスワードを求められる原因を解説します Windows Vista以降に導入されたセキュリティ機能「UAC（ユーザーアカウント制御）」の仕組みを説明します UACの通知レベルを変更する手順を紹介します 管理者権限を持たないユーザーでインストールしようとした場合の挙動についても触れます 組織アカウントでのソフトウェアインストール権限についても補足します 質問の内容 今回取り上げるのは、次のような質問です。 「組織のアカウントで作成した環境で、ソフトのインストールのたびにメールアドレスとパスワードの入力を求められます。これは設定上の問題でしょうか？」 この質問には、実は2つの要素が含まれています。ひとつは「インストール時に許可を求められる」という話、もうひとつは「組織アカウントで構成した」という話です。これらは別々の問題として考える必要があります。 UACとは何か 「インストールのたびに許可を求められる」という現象の正体は、UAC（ユーザーアカウント制御、User Account Control） という機能です。 UACはWindows Vistaのころから導入されたセキュリティ機能で、ウイルスやマルウェアからコンピューターを守ることを目的としています。 管理者権限を持つユーザーがサインインしていても、何らかの悪意あるプログラムに騙されて不正な操作を実行しようとした場合に、UACがそれを検知してブロックしたり、確認ダイアログを表示したりします。つまり、「本当にこの操作を意図してやっていますか？」と人間に確認させることで、意図しない変更を防ぐ仕組みです。 UACの設定を変更する方法 UACの通知レベルは変更できます。設定画面は以下の手順で開けます。 スタートメニューで「ユーザーアカウント制御」または「UAC」と検索する 「ユーザーアカウント制御設定の変更」を開く 設定できる通知レベルは主に以下の4段階です。 レベル 内容 常に通知する アプリの変更・自分での変更、両方で通知 アプリによる変更のみ通知する（既定） アプリがコンピューターに変更を加えようとする場合のみ通知。デスクトップは暗転する アプリによる変更のみ通知する（デスクトップを暗転させない） 上記と同じだが、デスクトップの暗転なし 通知しない UACを事実上無効化する インストール時の確認が煩わしい場合は、「アプリによる変更のみ通知する」という既定の設定になっているかを確認し、必要に応じて通知レベルを調整してください。 なお、「通知しない」に設定するとUACによる保護がなくなりますので、セキュリティリスクを理解した上で設定してください。 管理者権限がない場合の挙動 もし、管理者権限を持たない一般ユーザーとしてサインインしている状態でインストールを試みると、UACのダイアログには「管理者のメールアドレスとパスワードを入力してください」という認証フォームが表示されます。 今回の質問で「メアドとパスワードを入力を求められる」とあることから、サインインしているアカウントが管理者権限を持っていない可能性も考えられます。管理者権限を持つユーザーの場合は、通常は「はい／いいえ」の確認ダイアログが表示されるだけで、パスワード入力は不要です。 組織アカウントとUACの関係 「組織のアカウントで作成した」という部分については、UACとは別の話になります。 組織アカウントで環境を構成したこと自体が、インストール時の認証を求める直接の原因にはなりません。インストール時の認証はUACの設定と、ユーザーに与えられている権限によって決まります。 組織アカウントでのソフトインストール権限 関連する別の質問として「組織アカウントで作成した環境でも、各社員が自由にソフトをインストールできるようにできますか？」というものもありました。 これはUACの設定だけでなく、ユーザーアカウントに管理者権限を付与するかどうかで決まります。ユーザーに管理者権限を与えれば、インストールが自由に行えるようになります。ただし、セキュリティポリシーとのバランスを考慮した上で判断してください。 まとめ ソフトのインストール時に許可やパスワードを求められる原因は、UAC（ユーザーアカウント制御） という機能です UACはWindows Vista以降に導入されたセキュリティ機能で、マルウェアなどからコンピューターを守る役割を担っています UACの通知レベルは「ユーザーアカウント制御設定の変更」から調整できます パスワード入力まで求められる場合は、サインイン中のアカウントが管理者権限を持っていない可能性があります 組織アカウントの構成とUACは別の問題で、インストール権限はユーザーに与えられた権限によって制御されます

【Q&A】ドメイン参加時のコンピューターアカウントの重複 この記事の内容 Active Directory 環境でコンピューターを入れ替えた際に「コンピューターアカウントが重複している」というエラーが発生する原因を解説します ドメイン参加の権限を持つユーザーについて整理します 一般ドメインユーザーがドメイン参加できる台数制限（デフォルト10台）について説明します 組織がドメイン参加を管理するための一般的なパターンを紹介します コンピューターアカウントを事前作成して権限を付与するアプローチについて解説します 質問の内容 今回いただいた質問は次のような内容です。 Active Directory 環境に参加していた Windows 7 マシンを Windows 10 に新規で入れ替えた際、同じコンピューター名でドメインに再参加させようとしたところ、「コンピューターアカウントが重複しているため、削除してください」というエラーが発生した。なぜこのようなことが起きるのか？ この問題は Active Directory のドメイン参加の仕組みや権限まわりが絡んでくるため、少し複雑な話になります。 ドメイン参加の基本的な流れ Active Directory 環境では、Windows PC をドメインに参加させると、Active Directory 上に コンピューターアカウント が作成されます。DNS の参照やネットワーク疎通が確保された状態で、ユーザーが資格情報を使ってドメイン参加操作を行うと、このアカウントが作られる仕組みになっています。 ドメイン参加できるのは誰か ドメイン参加には 権限を持つユーザー が必要です。重要なのは、「ドメイン管理者（Domain Admin）でなくても、一般のドメインユーザーでもドメイン参加ができる」という点です。 Active Directory のデフォルトの動作として、一般ドメインユーザーは 最大10台まで ドメイン参加させることができます。11台目以降はエラーとなります。 この仕様はあまり知られていないことも多く、「一般ユーザーでもドメイン参加できるんですか？」と驚かれることもあります。 一般ユーザーによるドメイン参加のリスク 一般ユーザーでもドメイン参加できるということは、極端な話、自宅のパソコンを会社のネットワークにつないで、自分のドメインアカウントでドメイン参加してしまうことが可能 になります。 これは BYOD（Bring Your Own Device）を許可している組織であれば問題ありませんが、多くの組織ではセキュリティ上の理由からこれを禁止したいと考えています。 組織でよく使われる管理パターン パターン1：一般ユーザーのドメイン参加を禁止する 設定によって一般ユーザーのドメイン参加を禁止し、ドメイン管理者（または専用の作業用アカウント）だけがドメイン参加できる 状態にするパターンです。 PC のセットアップ・キッティング作業は管理者権限を持つ担当者が行い、エンドユーザーに代わってドメイン参加を実施します。一般ユーザーがドメイン参加しようとするとエラーになります。 パターン2：コンピューターアカウントを事前作成して権限を設定する Active Directory 上にあらかじめコンピューターアカウントを作成しておき、「このアカウントには〇〇さんがドメイン参加できる」という形で 特定のユーザーに参加権限を付与 するパターンです。 たとえばキッティング作業を外部委託する場合、作業者にドメイン管理者権限を渡すのは権限が強すぎます。そこで、作業専用アカウントを発行し、そのアカウントであれば特定のコンピューターアカウントに対してドメイン参加できるよう設定しておく、という運用が可能です。 今回のエラーの原因 冒頭の質問に戻ります。今回のエラー「コンピューターアカウントが重複しているため削除してください」が発生した原因は次のように考えられます。 ...