Roberts Blog

The House of SCCM and Intune on System Center Street

Tag: Standalone

Intune–The curious behaviour of Require and Not configured

While using super cool Intune Standalone recently, I had some head-scratching for a while over settings still being applied to enrolled devices when they shouldn’t be. It didn’t take long to figure out, and is easily worked around.

Let’s look at the default properties of an iOS device compliance policy:

The System Security setting is not being applied, and note that the greyed out properties are all defaults.

If you assign this to a group you’ll get the desired behaviour.

Here’s the same, but with System Security enabled and the properties configured:

Again assign this to a group and you’ll get the desired behaviour.

Now if you toggle System Security to Not configured, and leave the properties non-defaulted, the properties will still be applied:

It is easy to work around the issue by toggling back to Require then defaulting all the properties and finally setting it back to Not configured before you save it:

I believe this applies to the entire UI when it comes to enabling\disabling settings.

The Intune peeps in Redmond are aware and on it, a fix is coming asap.

It was already found and reported by another EM MPV Oliver Kieselbach but I didn’t notice, much kudos Oliver!

In the meantime follow the advice above and you can easily work around this temporary glitch.

Intune–BYO and relaxing device security

One of my Intune SA customers wants to allow BYO devices without a device PIN, but enabled managed apps used to access corporate data to be secured with a pin, while enforcing a device PIN on corporate (CORP) devices.

A pretty simple ask, but they were caught up in an underlying issue with Intune SA showing a setting as Not configured, while still enforcing any custom values entered in the setting before it was set to that state. Changing the setting to Require, defaulting everything then setting to Not configured while slotting in a save or two worked around the problem.

They have a bunch of users who use their own personally-owned iOS and Android devices to access corporate email, they do not want to enforce a password on these devices, instead, they want to use managed application policies to tighten down and secure corporate data on them; They also have a bunch of devices that are owned by the company and are not BYO, and thus need further configuration or tightening down.

Pairing off the BYO from CORP devices or users can be carried out using Azure Active Directories Groups, along with associated queries to tease them apart, much as we would in SCCM with Collections and AD security groups. We’d then use these groups to assign (deploy) policies and configurations.

The basics for getting an iOS or Android device configured so that the device does not require a PIN, or any security other than what the user has defined (biometric, pin, gesture etc), while prompting for a PIN when managed applications are accessed is pretty straightforward.

Hive off the BYO devices into a group, using manual or dynamic (queries) group types, then create the following specifically for the BYO devices and assign them to the BYO group:

Within the device profile that is used to restrict the device, Password is set to Not configured:

Note that the defaults are configured, no customisation of the settings were made before Not configured was selected.

And within the device compliance policy, both Email and System Security are tweaked. Here’s the managed email profile being enabled:

And here, system security is set so that having no device password does not make the device non-compliant:

Finally the application protection policy is configured so that a password is required, here we can see policies for both Android and iOS for application protection:


And here we have the iOS application protection policy’s access requirements configured:

The end result is that a newly enrolled device experience results in no device password enforcement for a specific group of users or devices, however, when they attempt to access their corporate email, they are prompted to setup a 4 digit PIN, or however you setup that aspect of security in your environment.

Such a light touch of a subject with many avenues to explore.

Intune has matured into a really strong platform for device and data management. There’s so much extensibility now that if you’ve already begun your journey from Active Directory to Azure Active Directory and the modern management landscape (EM:S), you cannot help feel inundated with options and flexibility that just a year or two ago we didn’t have.

An interesting observation I’ve made recently is that businesses are beginning to switch onto de-wiring parts of their existing corporate network, so as to reduce cost and align with their modern management roadmap using SDWAN or vWAN technology, reconfiguring their small to medium branch offices with far more cost effective internet connections for devices to VPN over, while installing at their larger sites network appliances pre-configured to VPN to their Azure network, the need to go side-ways is diminishing, with smaller more agile companies leading the charge on shunting or setting up most if not all of their assets in the cloud.

Azure, AAD, AD, Intune, and SCCM alone yield a rich landscape from which to design a modern infrastructure.

Intune Standalone – Part 2 – Enrol from OOBE

In this series:

Intune Standalone–Part 1 – Subscribe to Intune for evaluation

Intune Standalone – Part 2 – Enrol from OOBE

Intune Standalone – Part 3 – Software Updates

Intune Standalone – Part 4 – Managed BYOD for iOS and Android

In Part 1 of this series, I enrolled a device that in an post-OOBE state, had it in workgroup mode and finished the setup.

Here’s a brief run through on what it looks like to manually enrol a device that is sitting at the first prompt of Windows OOBE [2].

I’m enrolling a Windows 10 Build 1709 Operating System, with unmodified media.

We will at some point in the series modify the media, so that we can fine tune the configuration of Windows 10, before it is on-boarded into Intune.

Let’s punch in our Intune administrator credentials:


Tap in your password:


Some authentication is carried out, and the on-boarding to Intune Standalone begins:


We’ve now setting up the device:


This phase of setup could be automated, click around and select Accept


Ok the device is being readied up for the user to login:



In Part 1 I setup 2fa and enrolled a device, there were more dialogs to fill in then than now as a result, we’re now having policy enforced from Azure\Intune so as to setup a PIN for this device:


Tap in the verification code sent to you by whatever means you selected for 2fa notification delivery:


Now we get to set the pin, make sure it is memorable:


Cool, and now we’re …


We now see this new device showing up in the Intune Portal:




Very simple process.

As I said in the preamble, you can tweak the installation media a bit to configure how Windows 10 will deploy, a custom unattended file for example, then ship equipment to users who can enrol the device themselves using their Intune credentials, or, if you have AD Connect to plumb your on-premise AD to AAD, along with a bit more wiring, they can login with whatever account they use, and get the device enrolled into Intune.

Right, that’s another client to use for testing during this evaluation of Intune.

Powered by WordPress & Theme by Anders Norén