Intune – Passcode Reset and Microsoft PIN Reset Service

Hello all,

Today we are going to be talking about a relatively new feature in Azure AD that can be leveraged with managing devices in Intune, passcode reset and the Microsoft PIN Reset Service.  First things first, what is passcode reset and the Microsoft PIN Reset Service?  Per our documentation here:

The reset passcode capability for Windows devices integrates with the Microsoft Pin Reset Service to let you generate a new passcode for devices that run Windows 10 Mobile. The devices must be running the Windows 10 Creators Update, or later.

Let's expand on that a bit further.  The PIN or passcode is a Windows Hello for Business PIN.  A Windows Hello for Business PIN is required by default for any Azure AD joined devices or workplace joined devices.  By default, Windows Hello for Business policy is set to 6 numerical characters that must be set after the device is Azure AD joined or workplace joined.  In some organizations, this default policy is not restrictive enough and an organization can change their Windows Hello for Business policy to require a more complex PIN, such as 6 characters, alphanumeric, require uppercase letter, and a special character.  The downside to more complex PINs is that it is essentially, quoting users here, "just another password I have to remember".  Followed by, "what if I forget my passcode/PIN?".  The forgotten passcode is a valid concern.  Prior to the ability to reset the passcode, the only solution was to wipe the device and start over.  Not the most elegant of solutions.  I was onsite last week with a customer and passcode reset was a big item for them as they required complex PINs and were wiping devices when a user forgot their passcode/PIN.  So, I got some pretty good first hand experience from assisting my customer set this up.  So let's dive in on what was learned in my experience.

First, if you have checked out documentation linked above, it's a pretty short article and seems rather straight forward.  However, as you follow the docs, you quickly realize some questions start to emerge and the waters get muddy real quick.  Azure AD cloud services, like Intune, are updated weekly and things change quite a bit.  So right off the bat, following the docs, you'll see the screenshots don't match what the service is actually called when searching for it in Azure Enterprise Applications.  As of this blog post, the names of the services you need to enable are:

  • Microsoft Pin Reset Service Production
  • Microsoft Pin Reset Client Production

Yes, there are two applications you need to add and they are similarly named.  Ensure you enable both of them.  Also, beware of the filter.  If you are searching for the applications and do not find them, ensure your filter is set properly to find them.  See the screenshot below:

The docs also do not tell you that when you click Accept to enable the service, it sends you to a "Page not found" webpage.  Cue freak out right?  It would be nice if a webpage was presented that said "Enterprise application successfully added to tenant", but alas, this is not the case.  After you follow the steps to enable the services, go back into Enterprises Applications, change your filter settings to show Enterprise Applications with status Enabled and make sure you see the two services showing up for your tenant.  It is critical that these applications are added to your tenant if you want passcode reset to work properly.

The next confusing part is the section that details the OMA-URI policy settings that you have to deploy.  I've asked that this section be updated as it is uber confusing to any admin trying to configure this.  First, if you were just copy and paste what is listed, it won't work because the OMA-URI setting is missing a critical component.  It must contain your Azure AD directory ID.  Looking at the docs, it shows the following OMA-URI setting:


Notice the "//" between PassforWork and EnablePinRecovery.  Here is where you need to put your Azure AD directory ID.  So it should actually look something like this:  NOTE: The directory ID listed below is completely fabricated and is provided to show you an example of what you would actually use for your OMA-URI setting.


To find your Azure AD directory ID, open your Azure AD blade in the Azure portal.  Then click Properties form the menu to the left and you'll see your Directory ID.  This is value you'll need to include as in the example above for your custom policy.

There is also a user setting listed and the docs seem to imply that both settings need to be configured in your OMA-URI  policy, or custom policy, to successfully configure your devices.  However, this is not the case.  You should only use the device setting in your policy.  There is also mention that the setting needs to be set to True.  The docs fail to call out that True is a Boolean value that you will need to set in the policy.  In this section, there is a link to another article on how to create the custom policy where you would define this setting.  Follow the instructions at that link along with the information above to create your custom policy.  Then of course, the policy needs to be assigned, or deployed, whichever terminology you prefer, to a group.  The last confusing part to our docs, there is no mention of which type of group to assign it to.  For this particular policy, you can assign or deploy it to a user group or a device group, the policy will apply successfully in either case.  The only real impact of assigning it to a users group versus a devices group is that a user group may contain users who have other device types enrolled such as iOS.  In which case, the policy will not be applicable, but it will show as a success and inflate your status numbers.  Once you create the policy, it will look something like this in the Intune portal:

Ok, so that was a lot.  Still with me?  Because we are just getting started really!

Now, let's talk about what we saw for my customer after we got everything setup properly as mentioned above.  We're were ready to rock and start testing the capability.  So we Azure AD joined some Windows 10 Mobile devices, which subsequently enrolled the devices in Intune, and we ensured the OMA-URI policy got applied to the devices successfully.  Then we began attempting to reset the passcode on the devices:

Remember our Windows Hello for Business policy we talked about earlier?  For my customer, they had set a rather complex PIN requirement - 7 characters, alphanumeric, upper and lower case required, with a special character.  Our experience was when we would reset the passcode for the device, we would simply see "New Passcode Pending" in the portal for the device and nothing would happen on the device:

When I set this up in my test tenant prior to going to assist my customer, my experience was it took a couple minutes for the device to lock and took about 5 minutes for the temporary passcode to show up in the Azure portal.  For my customer, we simply saw the above screenshot and nothing ever happened on the devices.  Oddly enough, for workplace joined devices, passcode reset worked like a charm.  Things that make you go hmmmmm.  I wiped my device from my test tenant and Azure AD joined it to my customer's tenant.  Sure enough, we could not reset the passcode on my phone now enrolled in my customer's tenant.  At this point, I wasn't really sure what going on, I just knew it was something configured on the tenant or something on the backend not working properly for the tenant.  Talking with some colleagues about the issue, I was pointed in the direction of using Field Medic to get some logging off the device.  By the way, if your organization is using Windows 10 Mobile, I highly recommend deploying Field Medic as a required app for all Windows 10 Mobile devices.  You just never know when you may need to collect some data from the device to assist with identifying an issue.

Field Medic is a configurable app with all sorts of logs you can collect.  As we were dealing with PIN reset, this is an event that would be captured in Security logs.  So rather than collect a bunch of logs I didn't need, I configured Field Medic to only capture the Security logs.  So, I fired up Field Medic, started logging, and then reset the passcode on the device again.  I waited about 5 minutes and then stopped the logging on the device.  Windows 10 Mobile phones are pretty cool in that you can connect them directly to another Windows device with a USB and it will see the phone as basically another drive.  So I connected my phone to my Surface Book, browsed to and opened up the Security log I captured.  A lot of the Field Medic logs are jibberish due to being encrypted, but there are some remnants that are useful.  I wasn't really sure what I was looking for, so I decided to search for "PIN".  Sure enough, I found what I was looking for.  In the security log for the device, I saw the following:

Microsoft.Windows.Security.NGC.KspSvc  & &   InvalidPinTooFewCharacters retVal []

The first entry is the passcode reset action calling the function on the device to reset the PIN.  So we know the device was successfully receiving the passcode reset action initiated in the Intune portal.  The second entry is the response and the most important piece of information.  The return for the action was InvalidPinTooFewCharacters and it returned a value of null.  Now, we don't publicly have workflows for how the PIN reset service works, but it started to make sense at this point.  The PIN reset service generates a PIN and stores it locally on the device.  The PIN is then sent back to Azure/Intune and it is displayed in the console to be given to the user by an admin.  In this case, a PIN could not be generated due to not being enough characters.  After I saw this, I will admit I felt a little silly as I simply missed when I tested in my test tenant that the default PIN complexity (based on my observation and not documented anywhere to my knowledge), is 6 characters, alphanumeric, upper and lower case required, with a special character.  Sound familiar? If not, go re-read the first part of this blog about Windows Hello for Business policy.  At this point, a light-bulb went off and I knew what the issue was.  Recall earlier I mentioned my customer had a Windows Hello for Business policy that required 7 characters, alphanumeric, upper and lower case required, with a special character?  Eureka right?  The PIN reset service was not able to generate a PIN because it violated the customer's Windows Hello for Business policy - InvalidPinTooFewCharacters.  As soon as the Windows Hello for Business policy was changed to 6 characters, it worked beautifully.

Earlier I mentioned workplace joined devices and passcode reset working just fine even with the 7 character Windows Hello for Business policy.  I wanted to understand this a bit more.  If we look in the Intune console for the passcode reset command for both an Azure AD joined device and a workplace joined device, we see the action is labeled differently.

For an Azure AD joined device (notice the Corporate ownership tag), the action is labeled New Passcode:

For a workplace joined device (notice the Personal ownership tag), the action is labeled Reset Passcode:

What does this tell us?  It tells us that the passcode reset actions are different when initiated on Azure AD joined devices and workplace joined devices.  As in, they call different functions on the device when the action is initiated for the device.  And you can see this if you pull the Field Medic logs for both device types.  As far as the internals, I'm not privy to divulge that information here, but the actions that run on the devices are not the same and that explained why it worked for workplace joined devices and not Azure AD joined devices, even in lieu of the 7 character Windows Hello for Business policy my customer had configured.


All right, well that it's!  Thanks for sticking in there with me and I hope you all gained some useful information from this.  Happy Passcode Resetting!

Comments (3)
  1. GeekPower0 says:

    Can this be used with ConfigMgr/Intune Hybrid?

    1. Per this link, yes, it does work with Hybrid current branch.

  2. JJ says:

    does this apply to hybrid domain joined pcs? We have over 10k Windows 10 devices joined to AD and registered in AAD, evaluating WHFB. thanks in advance

Comments are closed.

Skip to main content