問題タブ [domaincontroller]

関連するすべての DNS セットアップと文書化されたベスト プラクティスに従って、Azure VM にドメイン コントローラーを作成することにより、Azure サブスクリプションに単純なドメインをセットアップしました。これは、クラウド専用 vnet 上のクラウド専用ドメインです。オンプレミス接続はありません。少数の VM をプロビジョニングしてドメインに参加させました。現在、新しい VM をプロビジョニングすると、ドメインへの参加に問題が発生し (多くの場合、まったく参加できません)、これらのマシンからの DNS ルックアップ (特にインターネット アドレス) がタイムアウトすることがよくあります。どうすればこれを修正できますか?

詳細

「 Azure 仮想ネットワークに新しい Active Directory フォレストをインストールする」および「Azure 仮想マシンに Windows Server Active Directory を展開するためのガイドライン」のプラクティスと手順に従って、Azure VM にドメイン コントローラーをセットアップしました。 AD データベースを別のデータ ディスクに配置しませんでした。さらに、168.63.129.16 を 2 番目の DNS アドレスとして追加しました (最初のアドレスは DC の内部 vnet アドレスで、Set-AzureStaticVNetIP を使用して静的にしました)。インターネットに到達します。

PowerShell コマンドレットを使用して新しいマシンをプロビジョニングし、VM の作成時に -WindowsDomain スイッチと Add-AzureProvisioningConfig の関連パラメーターを使用して自動的にドメインに参加させます。DC を 1 つのクラウド サービスでプロビジョニングし、他のすべてのマシンを別のクラウド サービスでプロビジョニングしました。すべてが同じ vnet サブネット上にあり、これらすべてが 1 つのアフィニティ グループにあります。約 15 台のマシンをプロビジョニングして参加させましたが、そのうちの約 10 台はまだ実行中です (他は削除されています)。

通常、新しい VM のプロビジョニングには約 11 ～ 12 分かかります。今では 30 ～ 35 時間以上かかることがわかりました。完了すると、マシンはドメインに参加できませんでした。全体的な DNS ルックアップは遅く、タイムアウトになることが多く (特にインターネット アドレスの場合)、ドメインに参加できなかったこれらの新しいマシンでは、完全に失敗することがよくあります。これらのマシンから DC への ping は失敗しますが、以前にドメインに正常に参加したマシンでは成功します。

domain/vnet/cloud service/subscription 上のマシンの数がこの問題の原因であるかどうかはわかりませんが、ドメインをしばらく使用して多数のマシンをスピンアップするまで、この問題は見られませんでした。マシン。

私は Active Directory に取り組んでいますが、これは初めてです。ここでは、C++ と ADSI を使用して Active Directory 内のすべてのユーザーを一覧表示する必要があります。投稿が重複している可能性がありますが、多くの投稿を見て、ADSI を使用するというアイデアを得ました。 .だから、さらに先に進むためのアイデアを出してください。

現在、コマンド repadmin /syncall /e [自分の dn] および repadmin /syncall /eP [自分の dn] を使用して、ドメイン コントローラー間のレプリケーションを強制しています。ドメイン コントローラーを同期するために powershell を使用したいと考えていますが、オンラインで表示されるすべての情報は、powershell 内から単に repadmin を呼び出す必要があることを示しています。repadmin /syncall に相当する純粋な PowerShell はありますか?

ドメインに接続できなくなった 1 台のラップトップで問題が発生しています。それはある時点まで機能し、その後突然停止しました。

DC を調べたところ、コンピューターはまだそこに登録されていますが、空のシェルです。以前のものと一致するように属性を手動で編集しましたが、それも修正されませんでした。ADからコンピューターを削除して再度追加しようとしましたが、役に立ちませんでした。

ラップトップをオフィスに送って見てもらい、完璧に機能しました。サインインはまったく問題ありません。返送すると、元の問題が再び表示されました。

これは、接続しているワイヤレス接続によるものですか? それともただの偶然？

ありがとう。

AD で一部のユーザー属性をクエリしたいのですが、特定の DC で C# を使用しています。数十の DC があり、それらの間にレプリケーションの問題があると思われます。未使用のアカウントのクリーンアップを行い、最終ログオン時間属性を使用して、すべての DC でこれを 1 つずつ照会したいと考えています (これは総当たり攻撃に少し似ていることはわかっていますが、ただし、あまり頻繁に行うつもりはありません) ので、最新の値が最新かどうかを確認できます。すべての DC を照会するコードがありました。

また、AD からユーザーにクエリを実行できるコードを作成するためのヘルプも見つけました。

そしてここで私は立ち往生しました。ここで、すべての DC からユーザーの最終ログオン タイムスタンプを取得したいと考えています。過去に、ユーザーが毎日使用していることが判明したため、DC からの情報が同期されていないことが判明したため、長い間使用されていないように思われるアカウントを誤って削除しました (1 つの DC のみを確認してください)。最も合理的な行動は、この誤った同期現象の原因を確認することであることは承知していますが、私の現在の状態では、時間がかかり、おそらく何の発見もなく終了するでしょう...建設的な応答/コメントを事前にありがとう!

Windows Server 2012（ドメイン）を備えた新しいサーバーがあり、いくつかの新しいユーザーとワークステーション（ADを使用）を追加して、すべてのユーザーがすべてのワークステーションにログインできるようにします。それは簡単ですが、オフィス、pdf リーダー、ビデオ プレーヤーなどのソフトウェアをいくつか追加して、すべてのユーザーがすべてのワークステーションで (同じように) それらを使用できるようにしたいと考えています。どうすればそれができますか？

すべてのワークステーションにすべてのソフトウェアをインストールする必要がありますか、それとも他の解決策がありますか。すべてのワークステーションのソフトウェアを同時に更新したい (更新が必要なソフトウェアがある場合) ので、各ワークステーションを個別に更新する必要がなく、すべてのワークステーションが更新されます。

最善の解決策は何ですか。ご不明な点がございましたら、お気軽にお尋ねください。

環境内のすべての DC でユーザーの最終ログオン時間を監査できる小さなアプリケーションを作成しています。少しの助けを借りて、すべての DC を反復処理し、ユーザーの最終ログオン時刻を照会するコードを作成することができました。前に読んだように、この値は DC 間で同期されておらず、これは MS の設計によるものです。すべての DC でユーザーをチェックするために使用するコードは次のとおりです。

ブラケットの多くが不要であることはわかっていますが、この方法の方が読みやすいです。

これがプログラムの核心です。ただし、見つかったユーザーの最終ログオン時刻は各 DC インスタンスで同じであることがわかりました。この問題を確認するために、同じことを行う小さな PS スクリプトを作成したので、結果を比較できます。PSスクリプトは次のとおりです。

繰り返しますが、これは実際の作業を行うスクリプトのコアにすぎません。

しかし、結果はまったく異なります。PS スクリプトの結果は、ほぼすべての DC でかなり異なります (すべてが他の DC と異なるわけではありませんが、ほとんどの DC と異なります)。ただし、.Net プログラムはすべての DC インスタンスから同じ時間を返し、さらに PS スクリプトに表示されない時間を返します。

今、私はかなり混乱しています。私は PS スクリプトが正しいと信じていますが、.Net バージョンで何が欠けていたのか本当にわかりません。

プログラムでデバッグを行いましたが、見つかったユーザーには、プログラムが表示する時間だけが含まれており、PS バージョンとは異なるファイル時間の値さえ含まれています。日時変換の問題についても考えましたが、結果の構造は異なる値で同じでなければなりませんが、そうではありません。

あらゆる種類のヘルプが必要な場合は、事前に Thx.