Tag: Intune

SCCM Co-Management Monitoring greyed out and not populating

SCCM Co-Management Monitoring greyed out and not populating

SCCM Co-Management Monitoring

When I was recently configuring co-management with SCCM, I noticed that even after days the monitoring pane for co-management was not populating the charts and status of the co-management devices.

This issues can occur when SCCM is upgraded to a co-management support version (1710 +) but the prerequisites were not configured correctly.

One of the prerequisites for SCCM is to have the latest version of the SQL native client installed. The latest version of the native client can be downloaded here.

Once you have downloaded the client, run it on your primary site server and it will upgrade your version of SQL native client. You can verify the upgrade is successful by checking the ODBC 64-bit connection:

Click Start > type in ODBC > click on ODBC Data Sources (64-bit). Then click the Drives tab.

ODBC data sources

Microsoft will not be releasing a SQL Server 2014 or later version of the SQL Server Native Client. The SQL Server 2012 Native Client can continue to be utilised by SQL Server 2014 and later versions.

Once you have completed the update of the SQL native client, restart the server and wait around 24 hours. You will see SCCM automatically populating the charts in the monitoring pane.

SCCM Co-Management Monitoring

That’s all for now, let me know how you get on.

MDM Auto enroll error 0x80192efd

MDM Auto enroll error 0x80192efd

GPO auto enroll

When trying to use group policy to MDM Auto enroll a co-managed device you may come across the error 0x80192efd in task scheduler Microsoft > Windows > EnterpriseMGMT

Or you may see the error in the event log viewer Applications and Services Logs > Microsoft > Windows > DeviceManagementEnterpriseDiagnosticsProvider

Event ID: 71 – Auto MDM Enroll: Device Credential (0x1), Failed *Unknown Win32 Error code: 0x80192efd)

This error is most likely related to your proxy settings. Depending on how you configured enrollment within Group Policy. For example you have the ability to configure auto MDM enroll for Device Credentials or User Credentials. Using Device Credentials will utilise the NT\SYSTEM account to enroll and therefore you may need to set the system proxy on your device.

You can set the system proxy using a command prompt by typing netsh winhttp set proxy 111.111.111.111:8080 [replace with your proxy settings].

To view your current system proxy settings type the following in a command prompt: netsh winhttp show proxy

Further troubleshooting can be found at docs.microsoft.com

Windows Autopilot Disable Windows Hello

Windows Autopilot Disable Windows Hello

Image result for windows hello

For those enterprises thinking of taking the leap to Modern Desktop with Windows 10, Autopilot is a great feature that build your device to a business ready state by the end user. Those who have played around with this feature would notice that Windows Hello has to be configured by setting a PIN every time you build a device.

The problem you may see is that when logging into a device with Windows Hello you will not be able to Single Sign-On to corporate resources that authenticate with local Active Directory and you will be prompted to enter your corporate credentials each and every time.

To get around this you will either need to implement Windows Hello for Business or disable Windows Hello. To Disable Windows Hello, go to Microsoft Intune > Device Enrollment > Windows Hello for Business

Then click on Windows Hello for Business properties and set to Disable. When setting this to Disable is will disable the Windows Hello configuration screen. If set to Not Configured then Windows Hello will apply.

Intune MDM Azure Portal Explained

Intune MDM Azure Portal Explained

MS Intune

Managing Windows 10 with Intune MDM

I am hoping this helps with the understanding of Intune (Azure Portal) and MDM.

 

There are 3 types of configurations for devices when connected to Intune (Azure Portal):

Intro:

Azure AD Registered devices: this allows a device to come into the realm of MDM. This is focused on BYOD. End users can bring their devices and Register them with Azure where they can be managed by adding a work/school account. Admins can push out policies. But nevertheless the end user can remove themselves from the MDM management, because this is their personal device.

Types of Azure AD Domain Joins:

Azure AD joined devices: this allows a device to join a Azure AD domain. Targeted for workplace devices that do not have an on-premise AD infrastructure or a cloud first/only approach. Benefits include:

  • Single-Sign-On (SSO) to your Azure managed SaaS apps and services. Your users don’t see additional authentication prompts when accessing work resources. The SSO functionality is even when they are not connected to the domain network available.
  • Enterprise compliant roaming of user settings across joined devices. Users don’t need to connect a Microsoft account (for example, Hotmail) to see settings across devices.
  • Access to Windows Store for Business using AD account. Your users can choose from an inventory of applications pre-selected by the organization.
  • Windows Hello support for secure and convenient access to work resources.
  • Restriction of access to apps from only devices that meet compliance policy.

 

Hybrid Azure AD Joined devices: this is for organisation who also have a on-premise footprint as well as cloud. Devices are joined to a local AD. These organisation would require the need for group policies or imaging devices or NTLM/Kerberos hence why they are not fully in Azure.

Rule of thumb:

A rule of a thumb, you should use:

  • Azure AD registered devices:
    • For personal devices
    • To manually register devices with Azure AD
  • Azure AD joined devices:
    • For devices that are owned by your organization
    • For devices that are not joined to an on-premises AD
    • To manually register devices with Azure AD
    • To change the local state of a device
  • Hybrid Azure AD joined devices for devices that are joined to an on-premises AD
    • For devices that are owned by your organization
    • For devices that are joined to an on-premises AD
    • To automatically register devices with Azure AD
    • To change the local state of a device

 

So what does this mean:

Well in a nutshell, you don’t need to use the old classic Intune portal!!! We can configure a on-premise domain joined machine to be managed by Azure Intune MDM (agentless MDM). The trouble you will find is that there is no clear documentation on how to configure this. My next post will discuss how to configure local AD domain joined device to be managed via Intune MDM using the Hybrid Azure AD Domain Join option.