question

Hello @JonMercer-8382,

Thanks for reaching out.

Are you facing discover issue with multiple devices or specific device? which version of Windows facing registration issue? also can you confirm, do you have Single forest AD or multi-forest environment because if devices are across from multiple Active Directory forests then you must create the SCP object in each forest root as explained over here.

Generally, we would get discover error when device couldn't retrieve SCP information or it could retrieve SCP information from local AD, but device failed to establish connection with Azure AD service endpoint for device registration.

First, verify if SCP keywords can be retrieved from domain joined device using PowerShell as explained in this article , outcome should look similar to below example and the field names are case-sensitive. Make sure that they are exactly azureADName: and azureADId:

 azureADName:contoso.com
 azureADId:62f988bf-####-####-####-############

The value for azureADName: can be any of the custom or default domain names configured in Azure AD, such "contoso.onmicrosoft.com" or "contoso.com" domain name since you are using Pass Hash Synchronization not AD FS federation. azureADId: is tenant ID of your Azure Active Directory Tenant.

Second, verify these service endpoints accessible in System Context (In computer account) not user context . You can test this by doing the following:

• open a command prompt as System using: psexec -i -s cmd.exe
  

• Then launch internet explorer: "c:\Program Files\Internet Explorer\iexplore.exe"
  

• Then try to navigate to the discovery url: https://enterpriseregistration.windows.net/verifiedDomain/enrollmentserver/contract?api-version=1.2

Note: Where verifiedDomain is the customers domain name. E.g. Contoso.com or Contoso.onmicrosoft.com. If it is working you will see response similar to:

Alternatively, you could use following script Registration Connectivity script and Device Registration Troubleshooter Tool which is very straight forward and help us in validating all prerequisite for device registration as these script validate internet connectivity under the system context also, it checks for SSL/TLS handshake and report as failure if any.

Hope this helps.

---

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

Are you facing discover issue with multiple devices or specific device: Multiple Devices

Which version of Windows facing registration issue: Windows 10 1909 and newer

Can you confirm, do you have Single forest AD or multi-forest environment: Single forest AD

When I run this in PS, nothing comes up, just goes to the command prompt. Changed the DC to our information, which was verified correct with the get-adrootdse command.

$scp = New-Object System.DirectoryServices.DirectoryEntry;

$scp.Path = "LDAP://CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=fabrikam,DC=com";

$scp.Keywords;

Farther down with this, there isn't a AdPrep folder on my system.

Import-Module -Name "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1";

$aadAdminCred = Get-Credential;

Initialize-ADSyncDomainJoinedComputerSync –AdConnectorAccount [connector account name] -AzureADCredentials $aadAdminCred;

One thing I have wondered is an issue, is that our domain is not .com, but .local, and if that could cause an issue.

For the PSExec command, I had to go to https://docs.microsoft.com/en-us/sysinternals/downloads/psexec and then download, extract, and then go to its location in command prompt, then the command you posted ran.

It looks like it worked.

https://enterpriseregistration.windows.net/EnrollmentServer/DeviceEnrollmentWebService.svcurn:ms-drs:enterpriseregistration.windows.net1.0https://login.microsoftonline.com/16434642-8eaf-485f-a032-99937cbe0a74/oauth2/authorizehttps://login.microsoftonline.com/16434642-8eaf-485f-a032-99937cbe0a74/oauth2/tokenhttps://login.microsoftonline.com/ulsonline.net/wsfedhttps://enterpriseregistration.windows.net/EnrollmentServer/device/urn:ms-drs:enterpriseregistration.windows.net1.0https://login.microsoftonline.com/https://device.login.microsoftonline.com/https://enterpriseregistration.windows.net/https://enterpriseregistration.windows.net/EnrollmentServer/key/urn:ms-drs:enterpriseregistration.windows.net1.0

Running the PS script under https://docs.microsoft.com/samples/azure-samples/testdeviceregconnectivity/testdeviceregconnectivity/ was successful.

Running the DSRegTool and got the following:

Test 1 was successful

Test 2 was successful

Test 3 (Hybrid AD Join) failed in two areas:
Testing if connected to AzureAD - device is NOT connected to Azure AD
Testing Tenant ID - Tenant ID is not configured correctly, and gave the same registry location as in test 4.

Test 4 (verify SCP) Failed: Says the Tenant ID is not configured correctly and to make sure it is configured correctly in the registry.

Test 5 (verify health of device) failed with the same device is NOT connected to Azure AD, though it offers to go through the procedure of adding it by running dsregcmd /join, then run test 3.

Test 6 (verify PRT) passed for the PRT registry value

Ran the dsregcmd /join, and then tried test 3 again, and it still fails saying it isn't joined, and not happy with a registry entry.

Something changed at some point though, because when I run dsregcmd /status. The diagnostic data has changed to:
Error Phase - Pre-Check
Client ErrorCode - 0x1
It has a line of site to the domain, because I can login, and access network shared locations.

So I fixed this issue. We had done a selective number of people for AAD Connect, but had not added the computers. Once that was done, those computers switched to Hybrid AAD Join. Though after that, Hello stopped working. Seems there is an issue with the PRT.

Were you login to the device using PIN before it become HAADJ?. Do you have this device Intune managed?

Thanks, Saw your post over the mail. But its not yet reflected here.

Yes, you were using convenience PIN, which won't work once your device become HAADJ (once you synced to AAD). you need to clear TPM or clear NGC container via certutil -deleteHellocontainer
You will be able to get WHFB provisioned. MFA used if you login with password during provisioning. if you already use Phone sign-in to authenticate on the device it carry MFA signal and help you to satisfy the MFA requirement to provision WHFB.

WHFB login here after with PIN/Bio - treated as MFA's Sign-in (strong authentication credentials aka NGC credentials). so no more MFA prompts from that machine for that user.

Not sure why my post didn't come through, had moved it to the general discussion.

We couldn't login with the pin, since that feature after Hybrid Azure AD joining them came up with a new message saying basically unable to sign-in because it didn't recognize the network. It also wasn't InTune joined, just standard AD joined. After trying different things, and talking with our consultant, it was found by their suggestion, that suspending, and then clearing out the TPM after AAD Connect had done its thing, was needed to be able to setup the Hello features. After that, was able to setup the pin without any issue.

Basically had to make sure the computers OU was selected in AAD connect, and then it would convert to a Hybrid AAD join status so that the Hello system knew of the computer. Then for whatever reason (certificates is my guess) had to suspend, and clear out the TPM to get rid of the unable to sign-in message with Hello Pin in our case, and after the reboot, was able to add it.

The only thing I am wondering about, is it didn't ask for a second factor when setting up the pin. We setup people with phone authentication, but all it asked for during the setup of the pin was the login password.

Now to deal with InTune.

@JonMercer-8382 - Yes, you don't need admin right to clear NGC container via "certutil -deleteHelloconatiner" user can run this in normal prompt. it clears immediately any previously stored credentials. you can want to automate via logon script as well .
Caution: this would be a one time operation. if you repeat that command after provisioning WHFB PIN/Bio. This will clear up WHFB cred as well. Then user will end up in loop of provisioning and deletion upon logout and login back.

For the sake of testing, I tried the certutil -deletehellocontainer on a system that already had the Hello PIN setup, rebooted, and now I can't re-add the pin, because the sign-in is only available when connected to the organization's network came back. I had to suspend Bitlocker, and clear the TPM, reboot, and then could put the pin back in.

Could there be something I did that is causing a certificate to push in to the TPM, that Hello doesn't like?