From 9f8cf116e288dd201c0763afd7692da7aeb3d60b Mon Sep 17 00:00:00 2001 From: SaurabhSarkarMS <68551771+SaurabhSarkarMS@users.noreply.github.com> Date: Tue, 25 Jan 2022 18:43:27 +0530 Subject: [PATCH] Update troubleshoot-windows-enrollment-errors.md I have added a section "Important" at line number 347. Technical Justification/Validation for the added statement- Kindly refer to the ICM https://portal.microsofticm.com/imp/v3/incidents/details/222369419/home Business Justification for adding the statement- While troubleshooting cases in support we have seen customers (specially service based industries like HCL/TCS/Wipro) implementing this unsupported scenario several times. The traditionally take over management of devices which are joined to the customer's domain and try to enroll it to their tenant(wherein there is no link b/w the customer's domain and their tenant) Surprisingly this configuration works a lot of times! (Currently HCL has a customer wherein this works for 10k machines and does not work for 1k machine in the same environment) Since we donot have a pubic facing doc calling this scenario as "Not Supported", organizations tend to implement this at first, and by the time it breaks for them, its too late to roll back given the anomaly(of devices working VS devices not working) and Microsoft is not able to help them much here as the configuration is not supported. I understand that this is not a known issue or a bug, but "by design", and we possibly cannot document everything that we dont support, however in my opinion this is a scenario that definitely needs to be explicitly called out in our docs. Just to add a little more reference- We had a case from Wipro for the very same issue with Microsoft Support in 2018 which ran for over 10 months after which PG mentioned that this is not supported. Last year we had HCL do it for one of their customers and this year again they have comeup with another customer which is in that state. Now we have an internal kb article which states this, ensuring that there are no such delays in communicating this to the customer anymore. However (as expected) in almost all the cases we have customers coming back to us asking for a public documentation for the same. Relevant Recent CSS Cases- 26550041 and 28928647 (There are many many more which i can probably dig up if needed) Having a public documentation would not only help us in better communicating this to the customer, but also ensuring that this "unsupported scenario" which works 90% of the times, is something that customers are aware of, and dont fall into the trap. --- support/mem/intune/troubleshoot-windows-enrollment-errors.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/support/mem/intune/troubleshoot-windows-enrollment-errors.md b/support/mem/intune/troubleshoot-windows-enrollment-errors.md index e00bec93a2..ed9b695a18 100644 --- a/support/mem/intune/troubleshoot-windows-enrollment-errors.md +++ b/support/mem/intune/troubleshoot-windows-enrollment-errors.md @@ -343,3 +343,7 @@ Try one of the following methods: - Target your Intune compliance policies to devices. Make sure that compliance can be determined before the user logs on. - Use offline licensing for store apps. This way, the Windows client doesn't have to check with the Microsoft Store before determining device compliance. + + > [!IMPORTANT] + > The following scenario is unsupported. + > We have 2 domains- A and B and there is no link between Domain A and Domain B. We have Machines which are local domain joined to Domain A. We donot support scenarios wherein attempts are made to DRS/WPJ these machines + MDM enrol in Domain B that is linked to Azure AD via AAD connect