Intune recently released the setting in the Administrative Templates to redirect known folders to OneDrive for Business.
This post will show how you can quickly configure it, and the user experience.
Login to the Intune portal https://devicemanagement.microsoft.com and create a new Device Configuration profile. Select Windows 10 and later for the platform, and Administrative Templates for the profile type.
Tip: there are many settings here. Use the search feature to make it easier.
Set the “Silently move Windows known folders to OneDrive” by selecting Enaled and enter in your Tenant ID. See below how you get the tenant ID.
To get your Tenant ID, go to Azure Active Directory, then Properties. Copy the Directory ID.
Configure the other settings such as “Silently sign in users to the OneDrive sync client with their Windows credentials”
Once you’re finished, don’t forget to assign the profile to your devices.
Here is an example of my Autopilot device applying the profile, and then the files appear on the desktop after OneDrive for Business has been configured.
Following up on a similar post I did here about requiring Azure AD User Discovery and Active Directory user discovery so Windows 10 machines can communicate over the CMG using Hybrid Azure Active Directory – https://nhogarth.net/2018/10/26/sccm-1806-cmg-hybrid-azure-ad-failed-to-get-ccm-access-token/
You may run into an issue where a specific Windows 10 client cannot communicate with the CMG. In ccmmessaging.log you will see “Post to http://<CMG>.COM/CCM_Proxy_MutualAuth/<ID>/ccm_system/request failed with 0x87d00231.”
You can run through the CMG Connection Analyzer to confirm that everything is working fine.
Then you realise it is something on the Windows 10 device end.
If you run “dsregcmd /status” and see that AzureAdJoined is set to No, then you know that the device is not Hybrid Azure AD joined, thus it cannot communicate with the SCCM CMG.
This particular machine was put in an OU that was not synced to Azure AD using Azure AD Connect. After moving it in the correct OU and doing another Azure AD Connect Sync (Start-ADSyncSyncCycle -PolicyType Delta) the device can then communicate over the CMG fine.
Microsoft recently added “Require app protection policy (Preview)” to conditional access. App Protection Policies in Intune are a great way to secure the apps on either a managed device or an unmanaged device.
Suggested Reading – https://docs.microsoft.com/en-us/intune/app-protection-policy
This blogpost will show creating an example Conditional Access policy leveraging the “Require an app protection policy (Preview)” control, targeting Exchange Online, and the user experience for a device that does not have any App Protection Policies assigned.
In devicemanagement.microsoft.com go to Conditional Access, and create the new policy.
Give the policy a name, and in my policy I am testing out this policy, so I have only targeted one user.
I will be testing this policy only for Exchange Online.
I will only be using iOS and Android for this policy.
I have configured the conditions for all apps.
I have selected the control to require app protection policy.
The policy has now been created and enabled.
Below is the user experience when trying to add an email account targeted by the CA policy to the native mail app on an iOS device. You can see that it is blocked (similar to what happens if you require an approved client app in the CA policy)
Now If I try and setup the account in Outlook, I get the error saying that no application protection policies have been assigned.
In the Whats new Page for Intune (https://docs.microsoft.com/en-us/intune/whats-new), you can see that Microsoft recently added some BitLocker encryption reports in Preview.
For more information: https://docs.microsoft.com/en-us/intune/encryption-monitor
To access the Bitlocker reports, go to the Intune portal (portal.azure.com or devicemanagement.microsoft.com) and go to Device Configuration > Encyrption report (preview)
An example of the Bitlocker report is below:
You can also use the Filter button to filter the encryption readiness by Ready/Not ready and Encryption status by Encrypted/Not encrypted
The example below shows the devices that are not encrypted:
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.
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
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.