‏ماجرای ناسازگار شدن دستگاه‌های Intune بعد از آپدیت جولای

تو این پست اومده که بعد از آپدیت جولای، دستگاه‌های ویندوزی که همه‌چیزشون درست بود توی Intune سه تا خطای قرمز می‌گرفتن: BitLocker، Secure Boot و Code Integrity، هر سه با کد 2016345708 یا همون SyncML 404. نویسنده می‌گه دستگاه واقعاً سه تا چک امنیتی جدا رو رد نکرده بود؛ ویندوز خیلی قبل‌تر سر گرفتن نتیجهٔ Device Health Attestation شکست خورده بود و گواهی سلامت روی 0xFFFF گیر کرده بود.

Device Health Attestation پل بین دستگاه و Intune حساب می‌شه: ویندوز شواهد measured boot و متکی به TPM رو جمع می‌کنه، سرویس مایکروسافت اون‌ها رو بررسی و یه نتیجهٔ امضاشده برمی‌گردونه، و Intune موقع ارزیابی پالیسی همون رو می‌خونه. وقتی این نتیجه نباشه، تنظیمات می‌تونن روی دستگاه کاملاً فعال باشن و Intune باز هم 404 نشون بده، چون جواب مشترکی وجود نداره که بخونه.

مقایسهٔ باینری‌ها به فیچر 62861611 با نام داخلی PCPKspEKPubEnumeration رسید. با روشن بودنش، ویندوز کلیدهای عمومی Endorsement Key رو از طریق Microsoft Platform Crypto Provider فهرست می‌کنه، متریال RSA و ECC اضافه آماده می‌کنه، تصمیم می‌گیره گواهی AIK به v2 ارتقا پیدا کنه و مسیر تازهٔ pre-attestation health check رو برمی‌داره. نویسنده این فیچر رو با ViVeTool خاموش کرد و DHA دوباره کار کرد.

همین توضیح می‌ده چرا گزارش‌ها شبیه هم نبودن. توی یه مورد TPM فیزیکی با گواهی واقعی و زنجیره‌ای تا Nuvoton TPM Root CA 2111 بود که باز هم تست زنجیره نامعتبر درمی‌اومد؛ توی مورد Parallels یه TPM مجازی بود که اصلاً نمی‌تونست به فراخوانی‌های تازهٔ ویندوز جواب بده و Get-Tpm خطای «Structure is wrong size» می‌داد. مایکروسافت هم با اطلاعیهٔ IT1431577 تأیید کرد که این یه رگرسیون توی کد ویندوزه، نه اشتباه پالیسی Intune.

مایکروسافت اول سمت سرویس Intune اثر مشکل رو کم کرد و بعد KB5101684 Preview رو به‌عنوان اصلاح سمت کلاینت پیشنهاد داد. جالب اینه که طراحی جدید حذف نشد: فیچر 62861611 هنوز سر جاشه و به‌جاش دو کنترل کوچیک‌تر اضافه شده. فیچر 61744298 به CertEnroll اجازه می‌ده بین APIهای فعلی crypttpmeksvc و نسخه‌های سازگارتر با پسوند _Old یکی رو انتخاب کنه، بدون اینکه از مسیر جدید بیرون بیاد.

فیچر 63184087 هم یه تور نجات باریکه: اگه ارتقای گواهی از v1 به v2 با خطای HTTP 404 (کد 0x80190194) شکست بخوره، ویندوز پیغام می‌ده که سرویس v2 در دسترس نیست و همون گواهی AIK v1 سالم رو نگه می‌داره به‌جای اینکه دورش بندازه. نویسنده تأکید می‌کنه این تور نجات عمومیه، ولی مرحله‌های قبلش هنوز به TPM وابسته‌ست — بسته به اینکه هر TPM چه کلیدهایی رو در معرض بذاره، نتیجه می‌تونه فرق کنه یا حتی با HTTP 429 شکست بخوره.

نکات کلیدی:

• هر سه خطای 2016345708 یک ریشه داشتن: نبودِ نتیجهٔ Device Health Attestation
• فیچر مخفی 62861611 با نام PCPKspEKPubEnumeration ویندوز رو وارد مسیر تازهٔ هویت TPM و AIK v2 کرد
• خاموش کردنش با ViVeTool، روی دستگاه تست‌شده مشکل رو حل کرد
• مایکروسافت با IT1431577 رگرسیون رو تأیید کرد و KB5101684 رو برای اصلاح کلاینت پیشنهاد داد
• طراحی جدید حذف نشد؛ فقط دو فیچر سازگاری 61744298 و 63184087 کنارش اومد