Hybrid Azure AD Tip – The device object by the given id (ID of machine) is not found.

Recently when working with a customer I was troubleshooting why their devices were showing up as Azure AD Registered in the Azure portal in Azure Active Directory when they should be Hybrid Azure AD joined. These were Windows 10 1809 devices.

When running “dsregcmd /status” on one of the machines, it would show as AzureAdJoined : NO. When it is Hybrid Azure AD joined, it should still say Yes.

If you run the command as admin, you will see there is Diagnostic Data section. On my devices, it said:

Client ErrorCode : 0x801c03f2
Server ErrorCode : DirectoryError
Server Message : The device object by the given id (guid) is not found.

This is because the device(s) has not been synced to Azure AD by Azure AD Connect. Make sure that the OU’s that the computer objects are in are set to sync to Azure AD. In my customer’s configuration, they had additional filtering where the users and computer objects needed to be in a Security Group to be synced to Azure AD.

Once the Azure AD Connect sync had completed successfully, and the device registration task had run again on the client, the machine now shows as Hybrid Azure AD joined in the Azure portal.


Intune – iOS – Profile installation Failed

When enrolling an iOS device in Intune, it may fail at the Installing Management Profile with the error “Intune – iOS – Profile installation Failed A connection to the server could not be established.”


If you happen to see this error, login to the Intune portal and go to Device Enrollment > Enrollment restrictions > and look through your existing restrictions to see if there are any settings blocking personal enrollments.


The example below shows that there is an enrollment restriction blocking personally owned iOS devices.


For the iOS to be enrolled, it needs to be a corporate owned iOS device. From https://docs.microsoft.com/en-us/intune/corporate-identifiers-add

At the time of enrollment, Intune automatically assigns corporate-owned status to devices that are:

  • Enrolled with a device enrollment manager account (all platforms)
  • Enrolled with the Apple Device Enrollment Program, Apple School Manager, or Apple Configurator (iOS only)
  • Identified as corporate-owned before enrollment with an international mobile equipment identifier (IMEI) numbers (all platforms with IMEI numbers) or serial number (iOS and Android)
  • Joined to Azure Active Directory as a Windows 10 Enterprise device
  • Set as corporate in the device’s properties list

Tip – Using Azure AD Monitoring to track Conditional Access failures

If you ever wanted to have an overview of the devices in your environment that have have been blocked from accessing cloud resources due to Conditional Access, then you can use the Monitoring Sign-Ins feature in Azure AD. Using this really simple feature, you can view the user name, the application that the user used, the operating system, and the actual conditional access policy that blocked the user from accessing the cloud resource.

This post will show how you can use Azure AD Monitoring to find devices that failed to meet the needs of the Conditional Access. In my example I have a simple Conditional Access policy for iOS devices that require the device to be compliant to access Exchange Online. I will test accessing Exchange Online using the Outlook mobile app on an iOS device that is not enrolled in Intune.

In Azure Active Directory in either https://devicemanagement.microsoft.com/ or https://portal.azure.com, go to Azure Active Directory and you will see a section called Monitoring. Under Monitoring, you will see Sign-ins.

If you click on Sign-ins, you can then use the drop downs and buttons to view specific information. For example, if you click on Columns you can choose to hide or show certain columns to get the information that you need.



In the example below I have clicked the drop-down under Conditional Access and selected Failure so I can see the devices that have been blocked due to not meeting the Conditional Access policies. In the screenshot below you can see there is an iOS device that used the Outlook Mobile app with a Conditional Access failure.



If you select this, you can then view more information about the device including Username, Application, Client App, and you can also view the Conditional Access policy name that it failed on by clicking on the Conditional Access tab.

In the example below you can see that I have a Conditional Access policy called “Exchange Online iOS Managed Only Devices” with the Grant control of “require compliant device” and that my device failed against this Conditional Access policy.


Conditional access – third party apps

This post will show how you can add a third party app to Azure AD that supports SAML, and then create a conditional access policy so that only compliant devices can access the third party cloud resource.

In my example I have signed up for a GoToMeeting trial. I will add GoToMeeting app to Azure AD and configure the single sign-on options to use SAML, and then on the GoToMeeting side I will configure Azure AD to be the Identity Provider. Once this is set up, I will create a Conditional Access policy that will require devices to be compliant in order for them to access GoToMeeting. When logging in with a work account to GoToMeeting, GoToMeeting will then redirect me to sign in through Azure AD, and then the conditional access policy will kick in.

Always test conditional access with test users, and plan thoroughly for any changes in a Production environment. The information below is for testing purposes.

Recommended reading:

Single Sign-On SAML protocol

Single sign-on to applications in Azure Active Directory

Tutorial: Azure Active Directory integration with GoToMeeting

What is conditional access in Azure Active Directory?

Tutorial: Configure GoToMeeting for automatic user provisioning

In Azure Active Directory, go to Enterprise applications then click on New application.


Search for the application. Note that it says it supports SAML based sign-on for the Single Sign-On Mode. Click on Add.


Once the application has been added, I will give access to my test users by clicking on Users and groups, and then Add user.


Now I will configure SAML for the single sign-on mode. Click on Single-Sign-On on the left hand side, then select SAML.


In the Identifier (Entity ID) I have put in https://authentication.logmeininc.com/saml/sp and Reply URL (Assertion Consumer Service URL) https://authentication.logmeininc.com/saml/acs and Relay State


Now I am going to download the Federation Metadata XML and upload it to the GoToMeeting site.


When logging in with my admin account in https://organization.logmeininc.com/ on the Identity provider section, I have selected to Upload SAML metadata file. This will contain all the Azure AD information and then configure Azure AD as the identity provider.


Now with a user I will login to https://www.gotomeeting.com/meeting/sign-in and select My Company ID so it can redirect me to my identity provider (Azure AD)


As expected, it has redirected me to Azure AD. I can confirm that the the SAML single sign-on mode has been configured successfully.


Next I will add the conditional access policy.


For the Cloud apps, you can see that GoToMeeting now appears because we added it earlier. I will select this as the Cloud app.


I will configure it to apply to all device platforms.


I have configured it to apply to Browser, and mobile apps etc.


In this test example, I have configured it to require only Intune enrolled compliant devices to access GoToMeeting.


Now lets login to https://www.gotomeeting.com/meeting/sign-in with the My Company ID


It will redirect us to Azure AD as we configured Azure AD as the identity provider earlier (and the domain used in my UPN was also added and confirmed in GoToMeeting)


Now because my device is not enrolled into Intune, I am blocked from accessing the GoToMeeting cloud resource as expected.


I have installed the GoToMeeting app on an Android phone, and it is the same expected user experience.


On an Intune enrolled compliant device I can login fine as expected (or you can launch the app from myapps.microsoft.com


SCCM Current Branch 1810 – Windows Store for Business

This post will show how you can integrate Windows Store for Business with SCCM Current Branch 1810, to sync applications and deploy WSfB applications to machines like Company Portal app.

Suggested Reading for prerequisites: Manage apps from the Microsoft Store for Business with Configuration Manager

In the SCCM console, go to Cloud Services > Azure Services > Configure Azure Services


Enter in the Name, and then select Microsoft Store for Business and click Next.


If you already have other Azure services configured in SCCM (Cloud Management Gateway for example), then it will automatically pull the server app, then you can click Next. If it doesn’t find a web app, then follow the instructions below.


If it doesn’t find a web app, click on Browse and we will create it.


Click on Create.


Give it a name and sign in to create the web app.


Click on Next.


Enter in a path and select your languages and click Next.


Now we need to login to the Microsoft Store for Business and give the web app we created before permission. Log in to https://businessstore.microsoft.com/en-gb/store and go to Manage > Settings > Distribute > Add management tool


Enter in the name of the web app that was either created earlier in the Azure Services wizard, or the one that you imported.


Click on Activate.


Back in the SCCM console, select the Microsoft Store for Business and click Sync from Microsoft Store for Business


The sync status should change to Successful.


You can view the WsfbSyncWorker.log for more information.

After a successful sync, you should see your MSfB apps in License Information or Store Apps.


To deploy one of these apps, right click on the app and select Create Application and then follow through the wizard.



The application will then appear in the Applications section. You can now deploy it as normal.


Further reading: Manage apps from the Microsoft Store for Business with Configuration Manager

SCCM Current Branch – Currently logged on user in Console not displaying

One of the new features that came out in SCCM Current Branch 1806 was the ability for the SCCM console to show the currently logged on user.

I had an issue where this field was blank. First thing I checked was that the SCCM client on the device was up to date (1806 or later)

On all clients, in the ccmmessaging.log I noticed:

No reply message from Server. Server may be temporarily down or a transient network error.
Post to http://<mp>/ccm_system_windowsauth/request failed with 0x8000000a.

Then when checking the IIS status codes on the Management Point IIS logs it said:

CCM_POST /ccm_system_windowsauth/request 401.2 (401.2 – Logon failed due to server configuration.)
CCM_POST /ccm_system_windowsauth/request 500.0 (500.0 – Module or ISAPI error occurred.)

This was due to Active Directory User Discovery being disabled in my site.


Once it was enabled and the users were discovered, the errors went away in the ccmmessaging.log and as well as the MP IIS logs. Now the Last logged on username appears in the ConfigMgr console.


SCCM Co-management – MDM enrollment failed with error code 0xcaa9001f ‘Integrated Windows authentication supported only in federation flow.’

Recently I was setting up Co-Management in SCCM Current Branch 1810. I was having issues with clients not being enrolled into Intune.

First I confirmed that the device was Hybrid Azure AD joined (this is a requirement, the device needs to be registered in Azure AD) then when looking at the CoManagementHandler.log file on the client I saw the error:

MDM enrollment failed with error code 0xcaa9001f ‘Integrated Windows authentication supported only in federation flow.’. Will retry in 240 minutes…

I found this error to be misleading. I am using Azure AD Connect with password sync, and not ADFS.


In my case, this error was caused by an enrollment restriction being set that blocked Windows 10 devices from being enrolled.

In Intune (portal.azure.com or devicemanagement.microsoft.com) in Device enrollment > Enrollment restrictions

In my Default restriction in Properties, then Select platforms, I had Windows (MDM) set to Block.


After allowing Windows (MDM) to Allow, the CoManagementHandler.log said Queuing enrollment timer to fire at 01/15/2019 21:42:19 local time

After trying again it was successfully enrolled into Intune and you can see the Managed By now says MDM/ConfigMgr Agent