I admit it, I’ve been procrastinating. I’ve been carrying around podcasting equipment for months, intending to use it from hotel rooms around the world to create podcasts for those that prefer audio information over written text. Since traveling is no longer a near-term option, I decided it was time to turn my home office into a (marginal) recording studio — no time like the present to try something different.
So here is episode #1:
Over time, these will be published to your favorite podcast app or destination. At the moment, you can find it on Spotify:
Apple iTunes and iHeartRadio should be added soon. (It seems that they get in no hurry when reviewing new podcast submissions.) Feeds based on Google seem to be completely at their mercy, waiting for the site to be indexed. (Hey Google, try to index http://oofhours.libsyn.com/.) Any other location comes later. (Of course you can always use the RSS feed directly, https://oofhours.libsyn.com/rss.)
Topic suggestions and questions are always welcome. To keep them from being lost in the e-mail pile, send them to Michael@oofhours.com.
Categories: Windows Autopilot
Great post Michael, i got eveything to work in my lab. However at a customer i cannot get it to work. In after the AP signin process the client just sits at “please wait while we set up your device..” and in the deviceManagement-enterprise-diagnostic-provide it will just loop with the error Attempting to get the DC name. (The specified domain either does not exist of could not be contacted). I can resolve the AD with DNS and ping all DC’s and know it should work.
You are saying that some customers are running with the skip ADCheck function. Is this something we also could be part of? We are in a startup project moving to AAD and Intune but in the end we will run with Hubrid join as a fallback scenario. In the end we will be moving approx 50.000 client over to the new platform.
If the device is on the corporate network and you are seeing that, then the device probably hasn’t received an ODJ blob at all (so it’s trying to ping “null”). If it isn’t on the corporate network, you could use white glove (deploying a VPN client during the technician phase so the user can make a VPN connection when they receive the device) now, or wait for the public preview of our VPN support (which will still require that VPN client, just like in white glove) which should be available in the next couple of months.
Hi Michael, thank you for this Podcast Episode.
We have been playing with AutoPilot AAD join for sometime but for some reason we are struggling withe the “handover” from Azure AD join to ENroll via Intune using Deployment Profiles. I know this is vague but we have checked permissions, Groups ( 2 devices targeted) , ESP settings. For some reason the device OOBE gets as far as sucessfully joining to Azure AD and then stops – even though the device is in a group that has a Windows Autopilot deployment profile assigned. After running OOBE I can see that the device is joined to AAD but not managed by MDM (Intune), Just needing some pointers where to look. Thank you!
If MDM auto-enrollment is configured in Azure AD for the user credentials specified, then the join cannot complete if the enrollment doesn’t. So make sure you check the MDM auto-enrollment settings in Azure AD (enabled and configured for “All” or an appropriate group of users).
Excellent podcast.. Thanks for it.!
Michael, Thank-you for taking the time to blog on this topic. I have been reviewing the Hybrid Join away from the corporate network and after listening into the audio and reading over documentation, I just want to clarify that it is expected that the AutoPilot Hybrid Join profile WILL NOT work if you are away from the corporate network with no VPN?? I know its mentioned a couple of times in the audio but it still seems unclear that part of it works (for example in my LAB, I have the full setup and can see the ODJ Connector receiving the request and creating the AD object on prem) but then from the device perspective I just see entries of being unable to get the DC Name and an eventual time out. It seems like it can half operate and its a shame InTune and the connector cannot be used as the conduit to establish connectivity to the DC. The value in AutoPilot seems to come more from being able to build a device away from the Corporate Network so I am trying to ascertain the value-add to my customer if this cannot operate without the reliance of Network/VPN connectivity as opposed to it using Azure to broker that connection. Appreciate any comments and guidance if any of the above is incorrect.
LikeLiked by 1 person
We are working a feature that removes the “ping a DC to confirm connectivity” check that currently exists in the process. But we can’t change the way Active Directory works: The user will still need to put in their username and password to authenticate against a domain controller. So it would be up to you to deploy a VPN configuration that either automatically connects, or one that the user can invoke manually before logging in. Most existing VPN clients support this. This capability is presently in private preview, with public preview expected in May.
Thank you for this podcast! I’ve been reviewing Hybrid AD Join Autopilot for my company.
Our company has remote offices, which are all connected with the main office through MPLS. Their (remote) subnets do not contain a domain controller and we prefer not to deploy any extra DC’s.
Systems can be domain-joined because of the MPLS connection.
All systems have an internet connection.
Does this mean we will be able to use Hybrid AD join Autopilot once “Ping a DC to confirm connectivity” is no longer a necessity ?
You can do Hybrid AD Join today – the MPLS connection provides access to the DC, the internet provides access to Autopilot and Intune. The “skip connectivity check” setting we’re adding would eliminate the ping, but that would only help in two situations: (1) the device is on the internet only, or (2) you block pings to your DCs.