Update 23 October 2016 – Its confirmed
So, its confirmed that this in fact is a bug and its being worked on by the product group over in Redmond. But I wanted to give you a brief update with our latest findings as well.
First of all – according to the Intune Premier Support (I haven’t been able to confirm this by myself) the problem starts to show at a different point than we first believed. Instead of starting to show after the first 5 devices – it seems to start when you have enrolled three (3) devices from the same image.
Second, again from the info we have received from the support, the Intune back-end actually see the unique devices and have one device ID per device. So it looks like its when the devices gets visible in the portal that the Unique ID is created and the issues starts.
Me and my colleagues have also done some test with an original media – deployed via MDT. When we use the original files, everything seems to works as we would like it to do. And this is our current work-around.
But the questions remains:
- What has changed? We know for a fact that we have colleagues in Denmark that has this kind of environment up and running – with an MDT-captured image.
- How (and when) is the Unique Device ID created?
- And why is there a difference between a sysprepped image and the original media?
I will of course update you on this as soon as I get more info, either from our testing, the Intune Support or the PG.
So, once again I’m having a support case with Microsoft Premier Support – this time its not iOS but Windows 10.
So, what’s up. We are enrolling a large amount of Windows 10 Education x64 that mostly will be shared PCs. Therefore we are using several enrollment accounts that later on will be manage by each school.
Initially we had issues getting apps and policies out to the devices, but it was a bit later that we discovered why. What happens is that when we enroll different models, using different images (or of course the same image) with the same enrollment account – they end up with the same device ID. Seems to be directly connected to the enrollment account, because when we use an additional account we get the same experience but with a different ID. For example Device 1 and 2 is enrolled by DEM-A and they share one single unique device ID. Device 3 and 4 is enrolled by DEM-B and they share one single device ID – but a different one from device 1 and 2.
For me as an admin the experience is that I only see one device at a time in the console (Intune Cloud Only – so the web console) and that it changes name after each device synchronization. This of course affects everything when it comes to management.
As you can see, they share the same ID and both looks like a HP 8100 – but the M6007 is actually another model. The name and info will change when the devices sync or do a HW-inventory cycle.
During the day the first day of troubleshooting we discovered that it is something with our captured images that creates this behavior. An Vanilla MSDN-image worked as it was supposed to.
The unique ID also seem to vary regarding to how the device has been enrolled – so it changes if you do it during OOBE or from the OS aka Private/Corporate device. But this far I haven’t received any information in regards to what Intune uses to create the ID from – at least not when it comes to hardware configuration. And this is still the case today, at the time of writing – I will of course update you guys when I receive that info.
After a though Sunday with lots of troubleshooting we thought that it was related to Zenworks and the way that tool manage images. Why we use Zenworks during the migration is an entire different story, but it has its reasons. We are also using MDT – and we know moved towards starting the MDT Task Sequence from Zenworks – and it worked as it should. We prepared for a roll out a day later and did some more tests. One of which ran last night. This morning we discovered that the behavior also affects our MDT image – as well as an additional image (Enterprise) created using MDT that we use in ConfigMgr today. So back to square one.
After another long day with the support we are close to filing it as a bug. What we have discovered – and it has been reproduced by MS Premier Support – is that:
Regardless of what image we use (as far as we can tell) this behavior emerges when one account (in our case the enrollment account) enrolls more than the maximum devices allowed by Intune. That was the reason why we didn’t discover it prior to this larger roll out. In our case its 5 devices per user. This is happening regardless of how we enroll the device, but as I’ve stated previously, automatic enrollment and manual enrollment seems to create different device IDs. This behavior is of course most obvious when we use a DEM-account because it will in general enroll more devices than a normal user account.
But – and this I want to emphasize – we see every single machine as a unique device in Azure AD under the enrollment account. So its definitely related to Intune and the way it creates the unique device ID.
And this is what we end up with in the Intune Portal
Where M6007 will change name each time a sync happens on any of the devices. Only three devices are visible here due to other devices enrolled to the same account (but not in the Azure AD picture) is taking up two spaces. It could also be related to, but not verified, old records from wiped and retired devices.
We still believe that our issue with the failures of application deployments and policy enforcement is related to this issue and hope that we will solve both in the same manner.
Tomorrow we will move forward by doing some more tests with different accounts and also a Windows 10 1511 image. I would also like to investigate if we now get the same behavior with the original media. Ill also request some more information in regards to how the ID is created.
Strange enough I have colleagues in Denmark that have managed to do a roll out using the same strategy as us – and haven’t seen this issue. I’m investigating this with them as well as with MS Support.
If you have experienced the same behavior – or have a working solution please let me know and track down this bug – if it is one.
Ill finish with some useful resources for troubleshooting – there may of course be several other ways, links and tools but these are the once I’ve used so far – I strongly recommend the link for the Ignite-session.
https://byodtestservice.azurewebsites.net/ – Nice tool to view Azure AD Joined devices and claims.
https://www.youtube.com/watch?v=zz1yE1o3WtI – Great resource on how to use different tools to troubleshoot Intune and other MDM-services.
https://gallery.technet.microsoft.com/scriptcenter/Device-Management-Log-XML-aa3bf9d4 – The tool used in the above video to convert XML to HTML.