Azure-docs: يحدث التسجيل التلقائي للجهاز بالرغم من تحكم GPO. معطل لا يعمل

TechTrooper شكرا على السؤال! سنحقق في هذه المشكلة وسنعاود الاتصال بك قريبًا.

TechTrooper ، هل يمكنك من فضلك تأكيد قيمة مفتاح التسجيل "ComputerHKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWorkplaceJoin" على الأجهزة التي قمت بتطبيق نهج المجموعة عليها؟

TechTrooper ، هل يمكنك من فضلك تأكيد قيمة مفتاح التسجيل "ComputerHKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWorkplaceJoin" على الأجهزة التي قمت بتطبيق نهج المجموعة عليها؟

قيمة autoWorkplaceJoin هي 0 مع GPO: " تسجيل أجهزة الكمبيوتر المنضمة إلى المجال كأجهزة ." اضبط على معطل
إليك حالة الجهاز قبل إعداد SCP لـ Azure AD Hybrid Join.

إليك حالة الجهاز بعد إعداد SCP لـ Azure AD Hybrid Join. لا يزال GPO لتعطيل التسجيل مطبقًا ومفتاح التسجيل موجود ، لكنه غير فعال. قد يكون هذا كارثيًا للمنظمات التي تتوقع إجراء تسجيل محدود.

TechTrooper لقد

حاليًا الحل البديل المقترح لهذا
1) احذف SCP
2) قم بإنشاء GPO لدفع مفاتيح التسجيل أدناه للأجهزة المستهدفة فقط.

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionCDJAAD]
"TenantId" = "" نوع القيمة مثل "REG_SZ"
"TenantName" = "" نوع القيمة مثل "REG_SZ"

سيساعد هذا التسجيل الجهاز على تحديد المستأجر الذي يستهدفه لتسجيل الجهاز.

أتفهم أن هذا ليس الحل المثالي ، ويعمل فريق المنتج على هذا وسيتم تحديث المستند بالتغييرات أيضًا.

أتمنى أن يساعدك هذا.

TechTrooper لم نسمع منك منذ فترة وسنواصل الآن إغلاق هذا الموضوع. إذا كانت لديك أسئلة أخرى ، فيرجى الإشارة إلي في التعليقات وسأواصل المحادثة بكل سرور.

@ ManojReddy-MSFT ،
نحن نخطط لنشر انضمام AAD المختلط وسنستخدم الإعداد الموحد ، هل هناك ما يدعو للقلق بناءً على هذه المشكلة؟
لقد اختبرت باستخدام "النطاق المُدار + sso" وقد نجح ذلك في مزرعة الاختبار.

مرحبا،
فتحوا اليوم قضية بدعم MS Pro وهم يؤكدون أن هناك مشكلة مستمرة مع هذا "التحكم" وبدون أي ETA متاح ...

@ ManojReddy-MSFT ،
مجرد سؤال ، إذا كنا سنقوم بنشر إجراء المجال الموحد ولكننا حددنا فقط "المستوى الأدنى" عبر تكوين AAD Connect ، إذن هذه المشكلة التي يواجهها الأشخاص ، لا ينبغي أن تنطبق على هذا الإعداد بشكل صحيح؟

لقد وقعنا في خطأ هذه المشكلة ، فلماذا تم إغلاق هذه التعليقات دون تحديث الوثائق لتنبيه الأشخاص بأن عنصر تحكم GPO لا يعمل؟!

lightupdifire بشكل عام ، يتم تشغيل مهمة تسجيل الجهاز على كل جهاز يعمل بنظام Windows 10 تلقائيًا ، كما أن تحديد كائن نهج المجموعة (GPO) الموضح في المستند سيؤدي إلى منع تشغيل مهمته.

في سيناريو متحد ، عند تكوين AAD HJ من خلال اتصال AD ، يتم إنشاء قواعد ADFS وتحديثها بواسطة AAD Connect ، لذلك إذا تم إنشاء القواعد بشكل صحيح ، فسيتم ضم الجهاز إلى Azure AD. لست متأكدًا مما تقصده بـ "تحديد المستوى الأدنى فقط عبر AAD Connect" ، هل يمكنك نشر لقطة شاشة للإعداد؟

@ benzini00 أنا آسف للإزعاج الناجم عن هذا. تم إبلاغي بأن فريق المنتج يقوم بإجراء التغييرات المناسبة ، ومن ثم قمت بإغلاق المشكلة. لقد تابعت مع الفريق اليوم وسأقدم تحديثًا بناءً على ذلك.

@ ManojReddy-MSFT
بالتأكيد ، نستخدم ADFS ونريد نشر "المستوى الأدنى" فقط ، الخيار الثاني في AD Connect:

السؤال هو ، إذا كنت تستخدم هذا الخيار الثاني فقط ، هل هناك مشكلة مماثلة مثل هذه الحالة قد نواجهها؟

lightupdifire سيتم إنشاء قواعد مطالبة ADFS المطلوبة عند تحديد أي من الخيارات. لذلك ، سيتم أيضًا تسجيل أجهزتك التي تعمل بنظام Windows 10 إذا كان لديك أي منها في بيئتك.

يجب عليك اتباع الخطوات المذكورة في هذا المستند ومسح SCP واستخدام GPO لملء مفاتيح التسجيل المطلوبة.

@ benzini00 تم تحديث المقالة بالمعلومات المتعلقة بـ SCP. اسمحوا لي أن أعرف إذا كنت تريد منا تضمين أي تفاصيل أخرى.

@ ManojReddy-MSFT ،
يجعل تحديث هذه المقالة الأمر أكثر تعقيدًا لفهم ما يجب القيام به ، ولا نريد تمكين التسجيل التلقائي على الإطلاق ، يجب السماح بخوادم 2x فقط من 300+. ماذا علينا ان نفعل؟

ما الذي يجب فعله لتعطيل التسجيل التلقائي لأجهزة Windows الحالية للمجال المُدار؟
ما الذي يجب فعله لتعطيل التسجيل التلقائي للأجهزة ذات المستوى الأدنى للمجال المُدار؟

ما الذي يجب فعله لتعطيل التسجيل التلقائي لأجهزة Windows الحالية للمجال المتحد؟
ما الذي يجب فعله لتعطيل التسجيل التلقائي للأجهزة ذات المستوى الأدنى للمجال المتحد؟

يعتبر
<<
إذا كنت تستخدم AD FS ، فأنت بحاجة أولاً إلى تكوين SCP من جانب العميل باستخدام الإرشادات المذكورة أعلاه مع ربط GPO بخوادم AD FS. هذا التكوين مطلوب لـ AD FS لتأسيس مصدر لهويات الأجهزة مثل Azure AD. >>
لذلك فقط لـ ADFS وليس لـ OU التي تحتوي على أجهزة كمبيوتر مرتبطة بالمجال؟

يعتبر:
<<
ب. قم بإلغاء تحديد "إزالة الأجهزة غير المستخدمة تلقائيًا" ضمن الخدمات> تسجيل الجهاز> الخصائص
اين ولماذا؟

>

يعتبر:
<<
ملحوظة
تأكد من بقاء التكوين الافتراضي بدون تغيير لـ "تسجيل أجهزة الكمبيوتر المرتبطة بالمجال كأجهزة" تعيين كائن نهج المجموعة إلى
تم تعيين "غير مكوّن" و "تسجيل الأجهزة الجديدة المرتبطة بمجال Windows 10 تلقائيًا مع Azure Active Directory" على "نعم" عند استخدام مدير التكوين.

>
وإذا لم تستخدم مدير التهيئة؟

فقط كن في حيرة من أمر ما يجب علي فعله الآن لإيقاف التسجيل التلقائي لأي سيناريو نشر أختاره .. وإذا اخترت المجال المُدار أو المجال المتحد ، فما الذي يجب فعله بالضبط ، هل من الممكن وصفه خطوة بخطوة وليس مثل "انظر أعلاه "و" انظر أدناه "؟

كانت المقالة القديمة أكثر وضوحًا من حيث إعداد المستند ، والقراءة التي يمكن أن تفهم بشكل أفضل مثل إيقاف جميع الأجهزة التي أحتاجها للتسجيل التلقائي: 1-2-3

الآن هو مجرد إعطاء خيار ما لتمكين القيام بالتسجيل التلقائي ، ولكن ليس في الحقيقة شرح ما يجب القيام به لإيقافه ...

lightupdifire هذا هو كل ما عليك القيام به:
1) تأكد من مسح إدخال SCP من AD
2) قم بتكوين SCP على العميل (في هذه الحالة خوادم 2x الخاصة بك) باستخدام خيار التسجيل من جانب العميل المذكور أعلاه
3) إذا كنت تستخدم AD FS ، فقم بتكوين SCP على AD FS نفسه باستخدام خيار التسجيل من جانب العميل المذكور أعلاه

@ SanDeo-MSFT

لذلك إذا كان لدينا:

• مجال داخل الشركة ؛
• مجال Azure AD ؛
• بين AD Connect و ADFS و WAP وما إلى ذلك.
• ~ 10x أجهزة Windows 10 المحلية المنضمة إلى المجال
• ~ 50x Windows 2016+ الأجهزة المنضمة إلى مجال داخل الشركة (تشغيل DC و ADFS و WAP وما إلى ذلك)
• ~ 240 Windows 2012 R2 والأجهزة الأقل المنضمة إلى مجال داخل الشركة

خطتنا هي استخدام حل "المستوى الأدنى" فقط الآن.

سيكون عملنا:

1. تأكد من مسح إدخال SCP من AD
2. قم بتكوين SCP على AD FS نفسه باستخدام خيار التسجيل من جانب العميل المذكور أعلاه
3. قم بتشغيل AD Connect وتمكين "المستوى الأدنى"
4. انشر Microsoft Workplace Join لأجهزة الكمبيوتر التي لا تعمل بنظام Windows 10

كل هذه الخطوات ستكون صحيحة؟
ماذا سيحدث مع "10x Windows 10" و "50x Windows 2016"؟ لن يفعلوا "التسجيل التلقائي"؟
ما الإجراء الدقيق الذي يتم إيقاف التسجيل التلقائي ، "مسح SCP"؟

lightupdifire قد تحتاج أيضًا إلى إنشاء SCP على العميل باستخدام خيار التسجيل من جانب العميل.

لن يتم تسجيل Windows 10 و Windows 2016 تلقائيًا. نعم ، ستبحث المهمة التي يتم تشغيلها على هذه الأجهزة عن SCP وعندما يتم مسحها ، لن ينجح التسجيل التلقائي.

lightupdifire لم نسمع منك منذ فترة. سنشرع الآن في إغلاق هذا الموضوع. إذا كانت لديك أسئلة أخرى ، فيرجى الإشارة إلي في التعليقات وسأواصل المحادثة بكل سرور.

@ ManojReddy-MSFT
هل يمكنك معرفة الحالة فيما يتعلق بخيار حظر التسجيل التلقائي للجهاز؟
لقد اختبرنا مع SCP GPO ونريد التوسيع عن طريق تكوين AD-Connect و ADFS. ومع ذلك ، لا نريد أن تنتهي جميع أجهزة وخوادم W10 الخاصة بنا كأجهزة Hybrid AD Join. أرى الخيارات التالية:

[الخيار 1]
قد نتحكم في ذلك عن طريق تعطيل مزامنة W10 محددة و Server OU من AD-Connect. (س: هل تمت إزالة هذه الأجهزة من Azure AD بعد ذلك؟)

[الخيار 2]
الهدف النهائي هو إقامة الإدارة المشتركة. لذلك قمنا بتوسيع SCP GPO ليشمل أجهزة إضافية وتكوين الإدارة المشتركة أيضًا ، بحيث ينتهي بهم الأمر إلى وضعهم تحت سيطرة MDM أيضًا.

@ ManojReddy-MSFT
لقد عدت من عطلة قصيرة :)

قبل أسبوعين ، فتحت تذكرة ProSupport عبر Azure وأكدوا لي أن فريق المنتج هذا يؤكد المشكلة التالية:

1. إذا حددنا أثناء معالج تكوين AD-Connect ، فإننا نريد إعداد الأجهزة "ذات المستوى الأدنى" فقط
2. ستتأثر أجهزة "الإصدار الحالي" وستبدأ AADHJ

لذلك سيكون من المهم بالنسبة لنا حظر أي أجهزة "الإصدار الحالي" ، لأن أجهزة "المستوى الأدنى" تتطلب تثبيت وكيل على الأقل.

هل يمكنك تقديم النصيحة ، ما هي أفضل خطة استرجاع في السيناريو:

1. نتبع جميع الخطوات من هذه المقالة
2. نقوم بتشغيل ADConnect وتمكين المستوى الأدنى
3. لبعض الأسباب السحرية ، تبدأ "الأجهزة الحالية" تلقائيًا AADHJ

كيف يمكن جعل تلك الأجهزة التي تستخدم AADHJ تلقائيًا مجرد مجال محلي انضم فقط كما كانت من قبل وتوقف العملية التلقائية؟

nielsvdGH إزالة SCP ودفع SCP GPO فقط للأجهزة التي تحتاج إلى التسجيل في Azure هو الحل الموصى به.

ستعمل إزالة الأجهزة من نطاق المزامنة مع مجال مُدار. لن يعمل عندما تقوم بتوحيد المجال. في السيناريوهات الموحدة ، تحدث مصادقة الجهاز على مستوى ADFS ولا تحتاج إلى مزامنة.

lightupdifire نعم ،

يعد إزالة SCP أهم شيء ، حيث ستبحث عنه مهمة التسجيل التلقائي للجهاز وعندما لا يجد SCP لن يتمكن الجهاز من الانضمام. بمجرد الضغط على SCP GPO ، سيوفر مفتاح التسجيل التفاصيل المطلوبة وستستمر العملية.

في سيناريو ، حيث لديك أجهزة Windows 10 مسجلة في Azure وتريد إزالتها ، تحتاج إلى القيام بما يلي:
1) احذف الجهاز من Azure AD.
2) افتح موجه CMD كمسؤول وقم بتشغيل الأمر التالي "dsregcmd / ترك". سيؤدي هذا إلى إلغاء الانضمام يدويًا إلى الجهاز.
3) تأكد من عدم تطبيق SCP GPO على الجهاز وإلا ستؤدي إعادة التشغيل إلى تشغيل مهمة تسجيل الجهاز مرة أخرى.

أتمنى أن يوضح هذا الأشياء.

@ ManojReddy-MSFT
لذلك في الواقع إذا لم يكن لدينا هذه الإدخالات في الخطوة "امسح إدخال نقطة اتصال الخدمة (SCP) من Active Directory (AD) إذا كان موجودًا"
قيم azureADId و azureADName ،
إذن كل شيء يجب أن يكون على ما يرام؟ ولكن هل من الممكن أن يتم ملء هذه القيمة بعد تشغيل معالج تكوين ADConnect؟

تحقق للتو من مجال الإنتاج ولا يمكن العثور على "azureADId و azureADName"

تضمين التغريدة
نعم ، إذا كانت هذه القيمة غير موجودة ، فلن يعرف الجهاز أي مستأجر يتم التسجيل له.

يحتوي تكوين AD connect على خطوة يتم فيها تكوين SCP. لذلك بعد تشغيل AD connect سيتم إنشاء SCP. يمكنك التحقق من ذلك عن طريق تشغيل الأمر التالي وإزالته إذا كان موجودًا.
"$ scp = New-Object System.DirectoryServices.DirectoryEntry؛

$ scp.Path = " LDAP: // CN = 62a0ff2e-97b9-4513-943f-0d221bd30080 ، CN = تكوين تسجيل الجهاز ، CN = الخدمات ، CN = التكوين ، DC = fabrikam ، DC = com" ؛

$ scp.Keywords؛ "

المرجع: https://docs.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-manual#configure -a-service-connection-point

@ ManojReddy-MSFT ،

لذلك يبدو أنه من غير الممكن تهيئة البيئة لحظر التسجيل التلقائي دون تشغيل معالج ADConnect ، فهل هذا صحيح؟

لذلك ربما يجب إعادة ترتيب الخطوات من أجل "التحقق المتحكم فيه من انضمام Azure AD المختلط على أجهزة Windows الحالية" ، شيء مثل:

1. قم بتشغيل معالج تكوين ADConnect ، سيؤدي ذلك إلى إضافة إدخال SCP
2. مباشرة بعد نشر معالج تكوين ADConnect لـ AADHJ ، امسح إدخال نقطة اتصال الخدمة (SCP) من Active Directory (AD) إذا كان موجودًا
3. تكوين إعداد التسجيل من جانب العميل لـ SCP على أجهزة الكمبيوتر المرتبطة بالمجال باستخدام كائن نهج المجموعة (GPO)
4. إذا كنت تستخدم AD FS ، فيجب عليك أيضًا تكوين إعداد التسجيل من جانب العميل لـ SCP على خادم AD FS باستخدام كائن نهج المجموعة

لست بحاجة إلى 1 و 2 للتحقق من الصحة المتحكم فيه.

2 فقط إذا كنت قد قمت بتكوين SCP مسبقًا باستخدام AAD Connect أو باستخدام PSH. وإلا فإنك تحتاج فقط إلى 3 و 4.

مرسل من الايفون الخاص بي

في 20 حزيران (يونيو) 2019 ، الساعة 6:15 صباحًا ، كتب موقع lightupdifire < [email protected] [email protected] >:

@ ManojReddy-MSFT https://nam06.safelinks.protection.outlook.com/؟url=https٪3A٪2F٪2Fgithub.com٪2FManojReddy-MSFT&data=02٪7C01٪7Csandeo٪40microsoft.com٪58C9d4f5ccfab4247861 ٪ 7C0٪ 7C636966333109794042 & sdata = FoCWsN5ArD٪ 2BN80٪ 2BkD٪ 2BrDR7p6mik9D4DIdwj٪ 2FtnM2eAY٪ 3D & محجوز = 0 ،

لذلك يبدو أنه من غير الممكن تهيئة البيئة لحظر التسجيل التلقائي دون تشغيل معالج ADConnect ، فهل هذا صحيح؟

لذلك ربما يجب إعادة ترتيب الخطوات من أجل "التحقق المتحكم فيه من انضمام Azure AD المختلط على أجهزة Windows الحالية" ، شيء مثل:

1. قم بتشغيل معالج تكوين ADConnect ، سيؤدي ذلك إلى إضافة إدخال SCP
2. مباشرة بعد نشر معالج تكوين ADConnect لـ AADHJ ، امسح إدخال نقطة اتصال الخدمة (SCP) من Active Directory (AD) إذا كان موجودًا
3. تكوين إعداد التسجيل من جانب العميل لـ SCP على أجهزة الكمبيوتر المرتبطة بالمجال باستخدام كائن نهج المجموعة (GPO)
4. إذا كنت تستخدم AD FS ، فيجب عليك أيضًا تكوين إعداد التسجيل من جانب العميل لـ SCP على خادم AD FS باستخدام كائن نهج المجموعة

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، واعرضها على GitHub https://nam06.safelinks.protection.outlook.com/؟url=https٪3A٪2F٪2Fgithub.com٪2FMicrosoftDocs٪2Fazure-docs٪2Fissues٪2F31078٪3Femail_source٪3Dnotifications ٪ 26email_token٪ 3DAJEFRT5ULL7WRH647FBYYLTP3N7F3A5CNFSM4HMLROMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYFMBBI٪ 23issuecomment-504021125 والبيانات = 02٪ 7C01٪ 7Csandeo٪ 40microsoft.com٪ 7C9d4f5ccfab42470555fa08d6f5815242٪ 7C72f988bf86f141af91ab2d7cd011db47٪ 7C1٪ 7C0٪ 7C636966333109804044 وsdata = etRmJsfzFdJII5Z5JziQs30mH٪ 2BC٪ 2Fi9٪ 2FYQVL2t7jMnDI٪ 3D & محفوظة = 0 ، أو كتم موضوع HTTPS: // nam06 .safelinks.protection.outlook.com /؟ URL = الشبكي٪ 3A٪ 2F٪ 2Fgithub.com٪ 2Fnotifications٪ 2Funsubscribe-المصادقة٪ 2FAJEFRT2DKTPYWGXRMX74IEDP3N7F3ANCNFSM4HMLROMA والبيانات = 02٪ 7C01٪ 7Csandeo٪ 40microsoft.com٪ 7C9d4f5ccfab42470555fa08d6f5815242٪ 7C72f988bf86f141af91ab2d7cd011db47٪ 7C1٪ 7C0٪ 7C636966333109804044 وsdata = sbTR1TyGVH3mKaFagCTIr05q6No1yDZwCUK3DAaeBdA٪ 3D ومحجوز = 0 .

@ SanDeo-MSFT

هذا هو السؤال الرئيسي الذي طرحته ، كيف أوقف التسجيل التلقائي بالضبط.
إذا بدأت في متابعة مثل "كيفية نشر مختلط" ، فأنا بحاجة إلى تشغيل: ADConnect للمجال المتحد
إذا قمت بتشغيل معالج ADConnect للمجال المتحد ، فيمكن أن يحدث التسجيل التلقائي.
لا يمكنني إجراء "التحقق من الصحة المتحكم فيه" أولاً ، لأنني إذا لم أقم بتشغيل معالج ADConnect للمجال المتحد ، فلن تتم إضافة سجل SCP.

لذلك أعتقد أن الأفضل هو القيام بما يلي:

1. قم بتشغيل ADConnect للمجال المتحد
2. مراقبة SCP وبمجرد إضافتها قم بمسحها
   اتبع خطوات الراحة 3 و 4 أعلاه.
   والخطوة الأخيرة 5 ، بالنسبة لأجهزتنا القليلة "المستوى السفلي" ، أضف SCP والمواقع الموثوقة في السجل ونشر العميل.

@ SanDeo-MSFT @ ManojReddy-MSFT

نظرًا لأننا لسنا بحاجة إلى أي جهاز آخر أو أي عملية تسجيل تلقائي يجب إجراؤها على الإطلاق ، هناك عدد قليل فقط من الأجهزة المطلوبة "ذات المستوى الأدنى" ،

هل تؤكد أن أفضل الخطوات لإيقاف التسجيل التلقائي ستكون من خلال القيام بهذا الإعداد بالترتيب التالي:

1. تشغيل معالج AD-Connect لتمكين الانضمام المختلط Azure AD للمجال المتحد ؛
2. مراقبة SCP وبمجرد إضافتها ، قم بمسحها ؛
3. بالنسبة لـ ADFS ، قم بتكوين إعداد التسجيل من جانب العميل لـ SCP على خوادم ADFS باستخدام GPO / يدويًا
4. بالنسبة لعدد قليل من الأجهزة المطلوبة "ذات المستوى الأدنى" ، أضف SCP في التسجيل ، وأضف مواقع موثوقة وانشر العميل.

و راجع للشغل. هل اختبر أي شخص بإجراء:

1. تم تمكين Hybrid Azure AD Join بالفعل للمجال المتحد / المُدار في AD-Connect
2. لذلك مسح SCP من المجال
3. قم بتشغيل ترقية / تحديث إصدار عميل AD-Connect أو تحقق مما إذا كان هناك تحديث تلقائي تم القيام به
4. تحقق مما إذا تمت إضافة SCP تلقائيًا مرة أخرى من خلال عملية تحديث إصدار AD-Connect

؟

@ SanDeo-MSFT @ ManojReddy-MSFT

آمل أن تكون بخير ، إذا كان ذلك ممكنًا ، سيكون من الرائع التعليق على آخر 2x أسئلة.

lightupdifire نعتذر عن التأخير. تبدو خطة العمل التي لديك جيدة.

لن يؤثر تحديث AD Connect على تكوين SCP ما لم تقم بإعادة تشغيل معالج التكوين.

@ ManojReddy-MSFT ،

شكرًا ، نخطط للنشر هذا / الأسبوع المقبل ونريد التأكد من أنه يمكننا حقًا إيقاف الانضمام إلى Hybrid Azure AD ، بعد اكتمال معالج التكوين ،
ثم قم بعمل HybridAADJ فقط لجهاز المستوى السفلي 1x ،
ولكن حتى ADConnect يعمل على خادم متصل بمجال محلي يعمل بنظام Windows 2016 :)
أعتقد أنه يمكنك "إعادة إغلاق" هذه الحالة ،
سأشارك بالتأكيد تجربتنا هنا.

تضمين التغريدة إنني أتطلع إلى تلقي رد منك.

@ SanDeo-MSFT @ ManojReddy-MSFT

نقوم بتشغيل النشر ، ونتيجة لذلك:

1. لا يمكن تسجيل الأجهزة ذات المستوى الأدنى ، الأخطاء:
   أ) "لم تتمكن خدمة التسجيل من مصادقة حسابك بنجاح. الرجاء التأكد من تسجيل الدخول باستخدام حساب مجال Active Directory الخاص بك والمحاولة مرة أخرى."
   ب) "خطأ في الانضمام إلى Azure AD الهجين: رسالة الخطأ: فشل الانتقال إلى"

1. يتم تسجيل الأجهزة الحالية تلقائيًا ، حتى SCP تم مسحها من AD الداخلي ،
   على الأقل نرى هذا مع أجهزة Windows 10 ، لا توجد هذه المشكلة في Windows Servers 2016.

باختصار ، أعتقد أن العملية "الخاضعة للرقابة" لا تعمل بشكل جيد ،
أيضًا سجل SCP الذي تم إنشاؤه في كل من الموقع والمجال وفي غابة المجال.

@ SanDeo-MSFT @ ManojReddy-MSFT

بعد استكشاف الأخطاء وإصلاحها وجدت ما يلي:

1. عندما نقوم بتشغيل الإعداد ، يبدو أن 5-10 ثوانٍ لمسح "الكلمات الرئيسية" كانت كافية ، لبدء بعض أجهزة الكمبيوتر في التسجيل ، ولهذا السبب رأينا بعض Win10 يبدأ التسجيل
2. عند إنشاء سجل SCP في AD FS والأجهزة الحالية ، يمكنك استخدام اسم المستأجر ، على سبيل المثال: contoso.onmicrosoft.com
3. عند إنشاء SCP على جهاز ذي مستوى أدنى ، تحتاج إلى استخدام المجال المتحد ، على سبيل المثال: contoso.com

باختصار ، تم التحكم بشكل جيد ، لكنني أنصح ربما بإضافة مستند ، لتشغيل البرنامج النصي لمسح السجلات وإنشاء حلقة البرنامج النصي بشكل مستمر أثناء تشغيل المعالج.
إذا تم استخدام المجال والغابة ، فسيتم إضافة سجل SCP في كليهما ، لذلك يجب أن يتم مسح SCP.
عند نشر وكيل من المستوى الأدنى ، فإنه يضيف المواقع المطلوبة إلى منطقة الإنترانت ، لذلك لا داعي للإضافة.

شكرا للمساعدة! لديك كل شيء عظيم في المستقبل؛)

تضمين التغريدة
الشيء الأساسي الذي يجب تذكره عند إجراء تحقق متحكم فيه لربط Azure AD المختلط هو تخطي تكوين SCP باستخدام Azure AD Connect. لذلك إذا كنت تستخدم AD FS ، فأنت بحاجة إلى تكوين مطالبات AD FS المطلوبة. نوصيك باستخدام Azure AD Connect لتكوين مطالبات AD FS. لذلك عند استخدامه ، تأكد من تخطي تكوين SCP. وبهذه الطريقة لا يتم كتابتها باللغة AD ولا داعي للقلق بشأن مسحها. بعد ذلك ، كل ما عليك فعله هو تكوين SCP من جانب العميل وستبدأ هذه الأجهزة في التسجيل مع Azure AD عند انضمام Azure AD المختلط. إذا كنت لا تستخدم AD FS وبدلاً من ذلك تستخدم مصادقة Azure AD باستخدام مزامنة تجزئة كلمة المرور (PHS) أو المصادقة التمريرية (PTA) ، فعندئذٍ لتسجيل الأجهزة ذات المستوى الأدنى على أنها انضمام Azure AD مختلط ، يجب عليك التأكد من سلس تسجيل واحد تم تمكين -On أيضًا.
أتمنى أن يساعدك هذا.
شكرا

أنا أيضًا في حيرة من أمري بسبب هذا المقال وقد استنرت كثيرًا بسلسلة التعليقات هذه أكثر من المقالة نفسها.

اقتراح: يرجى تحديث المقالة بأي معلومات ذات صلة يتم مشاركتها في هذا الموضوع. يجب أن يكون الأشخاص قادرين على قراءة المقالة والحصول على ما يحتاجون إليه من حيث خطوات التكوين.

سؤال @ SanDeo-MSFT ، @ ManojReddy-MSFT: أعمل على نشر Hybrid Join الخاضع للرقابة في بيئتنا المدارة (تمرير التجزئة) لأجهزة الكمبيوتر التي تعمل بنظام Win10. ما زلت غير واضح تمامًا بشأن الخطوات ، لذا يرجى التحقق من صحة ما أدرجته أدناه أو تصحيحه:

1. قم بإزالة تسجيل Azure AD من أي أجهزة مسجلة نخطط للانضمام إليها المختلط.
2. قم بمزامنة الوحدات التنظيمية للجهاز في AD Connect (لدينا حاليًا مستخدمون / مجموعات متزامنة فقط).
3. لا تقم بتمكين الانضمام المختلط في AD Connect.
4. تحقق من عدم وجود SCP في AD الداخلي (لم يتم ذلك ، لقد تحققت بالفعل).
5. تكوين SCP من جانب العميل.

بعد إكمال الخطوات المذكورة أعلاه ، يجب أن يبدأ أي عميل تم تكوين SCP به في الانضمام المختلط ، أليس كذلك؟

شكرا

JoelHazelton الاعتذار عن الرد المتأخر. تبدو خطة عملك جيدة. سيتم فقط ربط الأجهزة المزودة بـ SCP المكونة من جانب العميل بـ Azure AD.

سأعمل مع المؤلف لتحسين المستند.

تضمين التغريدة

مشاركة تجربتي عندما نقوم بتشغيل Hybrid AAD Join for ADFS solution:

1. تحقق من عدم وجود SCP في AD الداخلي (لم يتم ذلك ، لقد تحققت بالفعل). -> غير موجود ، حتى تقوم بتشغيل معالج AD Connect لتكوين Hybrid Azure AD Join.

2. SCP - كما هو مفهوم ، يمكن تخطي هذه الخطوة أثناء معالج AD Connect ، ولكن بصراحة ،
   لم نر هذا الخيار ... لذا ما فعلناه هو: أ) قمنا بتشغيل معالج AD Connect B) في نفس الوقت الذي نراقب فيه المجال ومجال المجال لسجل SCP في AD عبر تحرير ADSI وبواسطة PowerShell C) بمجرد عرض SCP حتى في AD قمنا بمسحها ، تمت إضافتها في كل من المجال والغابة المجال ، كلاهما تم مسحهما.

3. بعد اكتمال معالج AD Connect ، بعد أسابيع قليلة ، يرسل لنا مركز أمان Azure AD رسالة مفادها أن نقل النوافذ للوكيل للشبكة الخارجية أصبح مفتوحًا ، لذلك يتعين علينا إغلاقه.

4. أضفنا SCP على خوادم ADFS وعلى الأجهزة التي يجب أن تكون Hybrid AAD مرتبطة يدويًا عن طريق التسجيل ، حيث لا يوجد لدينا العديد من الأجهزة لهذا الإعداد ، حيث يجب أن يكون اسم المجال SCP TenantName المتحد.

إذا كان الأمر بالغ الأهمية بالنسبة لك ، فيجب أن تتم مراقبة SCP وتنظيفها بسرعة ، فقد رأينا بعض الأجهزة تبدأ في التسجيل بسرعة كبيرة ، وحصلنا على حوالي 5 أجهزة في حوالي 10 ثوانٍ بينما قمنا بمسح SCP.

أرغب في سماع تعليق من Microsoft عندما يتم إصلاح ذلك. هل يتطلب تحديث جميع أجهزة Windows 10 إلى إصدار جديد على سبيل المثال؟ على الرغم من أن لدينا عملًا ، إلا أنها ليست جميلة.

مرحبا،

إنه الآن عام 2020 وجميع المعلومات المفيدة موجودة ضمن موضوع التعليقات "المغلق" ، والذي أجده مزعجًا للغاية.

إذا كان تسجيل الجهاز GPO لا يعمل وأنت تقترح أن مسح تسجيل الجهاز SCP من Active Directory واستخدام طريقة ClientSideSCP هي الطريقة الوحيدة لتحقيق الطرح المتحكم به ، هل يمكنك إزالة المقالة أدناه ، حيث كانت أول نتيجة على Google عندما كتبت "التحكم في النشر من إعلان Hybrid AD" -

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-hybrid-azure-ad-join-post-config-tasks

إذا كان بإمكانك أيضًا تحديث هذه المقالة بأي معلومات ذات صلة ، فسيكون ذلك رائعًا.

الكثير من المعلومات المتضاربة التي من الواضح أنها مربكة للجميع!

أيضًا ، هل هناك أي وقت محدد للوصول عند تسجيل الجهاز سيعمل GPO مرة أخرى؟ كما أقول ، هناك معلومات متضاربة على الإنترنت بخصوص هذا الموضوع وسيكون من الجيد أن نفهم ما إذا كان هذا لا يزال يمثل مشكلة أم لا.

أتفق تمامًا مع @ jakeives95. لقد تعلمت من هذا الموضوع أكثر بكثير مما تعلمت من الوثائق. يجب أن يكون كل من هذه المقالة و "تكوين ارتباط Azure AD المختلط للمجالات المتحدة" أكثر وضوحًا حول الخيارات التي يجب استخدامها ومتى. لا أعرف حتى عن المقال الثالث @ jakeives95 الذي ربطه للتو. سأتجاهل أن الشخص الذي يفكر في أنه لم يتم تحريره منذ عام 2018.

لقد بدأنا للتو عملية طرح مضبوطة معتقدة أن الخطوات الواردة في هذا الدليل ستكون كافية. ومع ذلك ، ما يفشل هذا الدليل في تضمينه هو حقيقة أن AD FS تحتاج أيضًا إلى تكوين قواعد مطالبة - وليس فقط إلى SCP كما هو مشار إليه ضمن "تكوين إعدادات AD FS". يرجى تحديث هذه المقالة لإعلام الأشخاص بأن قواعد مطالبة AD FS ستحتاج إلى التكوين عبر AAD Connect أو يدويًا للانضمام المدعوم بالكامل. أعلم أن بعض الأجهزة سيتم تسجيلها بدون قواعد المطالبة بسبب الخيار الاحتياطي ، ولكن حقيقة أن هذه المعلومات قد تم استبعادها أدت إلى يوم كامل من استكشاف الأخطاء وإصلاحها وتأخير الطرح. تتمكن بعض الأجهزة من استخدام الإجراء الاحتياطي بينما لا يتمكن البعض الآخر من ذلك ، لذلك لا تنطبق هذه المقالات على بيئات AD FS ما لم يتم تكوين قواعد المطالبة مسبقًا. هناك أيضًا متطلبات مسبقة أخرى حول الوكيل وما إلى ذلك والتي تتجاهلها هذه المقالة.

أنصح حتى بترحيل هذه المقالة إلى "تكوين انضمام Azure AD المختلط للمجالات المتحدة" و "تكوين انضمام Azure AD المختلط للمجالات المدارة" - ثم إزالته. وإلا فإنه يحتاج إلى التحديث ليشمل جميع التفاصيل التي تمت مناقشتها في هذا الموضوع. على سبيل المثال ، أضف قسمًا ضمن البرامج التعليمية الأخرى لـ "اتبع هذه الخطوات لتمكين التسجيل لكل جهاز عبر GPO" وتوضيح أن الخيار سيكون الانضمام التلقائي إلى كل شيء خارج عن سيطرتك. ثم قم بتضمين الخطوة المهمة للغاية من @ SanDeo-MSFT في 1 أغسطس 2019 ، حول تخطي تكوين SCP في معالج AAD Connect.