SCCM – Controlling Application Supersedence

You might be wondering how to control this box in your SCCM 2012 R2 SP1 (or ConfigMgr SP2, pretty much the same thing) deployments.


I’ve finally been able (with the help of my friend and future ConfigMgr MVP nominee, Eric Anderson) to track down precisely what is going on in the confusing world of applications and supersedence in SCCM.

The Scenario

· Machines all had the old version of Java, Java 8 Update 65, which is deployed via either a Task Sequence , or with a firm-wide mandatory advertisement
· We made a new deployment of Java, Update 71, and set this to supersede the old version
· The new version of Java was deployed as Available yesterday, not required, to a small subset of machine (5 or so)
· Today, these machines have all automatically updated to the newest version of Java even though it was an Available deployment!!

Looking into the logs, we see this:

AppIntent –
Continue reading

SCCM – Updating all drivers after a migration

Every time you migrate from one SCCM instance to another, or if you have to move your drivers around (for instance: you originally had your drivers placed on the c:\ and want to mover them to another drive), you’ll need to update the location not only of DriverPackages, but also of all drivers as well.

This has been something that I MIGHT have forgotten more than once.  More than twice even.

So I wrote up this script.

This script assumes that you’ve already moved your drivers from their original location to their final resting place.  It also supports adjusting the path based on driver folder as well.  I’m a firm believer that SCCM Drivers should be stored in as small a folder structure as is possible, here’s how I normally layout my content for SCCM:

Type Of Content Location Shared Path
All SCCM Content D:\ContentSource \\SCCM\Content\
Drive Source Files D:\ContentSource\Drivers \\SCCM\Content\Drivers
Driver Packages D:\ContentSource\DriverPackages \\SCCM\Content\DriverPackages

So when I saw that this instance of SCCM had the content in the C:\ drive, and also had very long path names, I had to truncate things. Continue reading

Conditional Access with SCCM and InTune

The Question

How does InTune Conditional Access Policy affect devices in the field?  (e.g. Bob’s phone already has a manually configured mail profile.  What happens to Bob’s e-mail when I enforce Conditional Access (i.e. saying a user must have InTune to receive e-mail?))

The Background

Consider this: A company with ~1000 mobile devices. They roll out InTune with SCCM and get it installed on 90% of devices in the field, and use it to push e-mail profiles to devices using Conditional Access.

However, 10% of the devices don’t have InTune, but still have manually configured e-mail profiles, using either the built-in mail client (Exchange Active Sync or EAS) or the Outlook application.

The company wants to lock down mobile e-mail to only those with a healthy device, one with security policies being enforced. If you’ve got SCCM w/ InTune installed, you just go to the Microsoft Intune portal at ( to enable Conditional Access. Continue reading

InTune – Don’t forget this important e-mail setting!

On a recent InTune deployment, we had a requirement to force encryption and security on mobile devices and also provision mail profiles as well.

During the pilot, we heard informal reports that a user thought they couldn’t send a photo using their company e-mail after migration, but we found this hard to reproduce.

However, during the production roll-out, we discovered that users were unable to add attachments using their InTune configured mail account.

Note that this was an ConfigMgr w/ InTune deployment, and the affected devices were mostly iOS and Android devices.

How do I fix this?

You control this setting from ConfigMgr, so launch the console. Continue reading

Solved: iOS Devices can connect via InTune, but not Android

We had a big issue at a client recently, which was quite a bear to solve.  They used ADFS with On-premise SSO (meaning that they didn’t use DirSync to push passwords into Azure AD/Office 365), so when clients come to authenticate over the web via the Company Portal App, they were referred to our on-prem ADFS for authentication.

This worked fine for our iOS and Windows Devices, no issues at all!  But then when we tried to use Android devices, they would be presented with the following error message:

The Symptom

"Cool, I'll call the IT admin, OH SHIT that's me!"
Could not sign in. You will need to sign in again. If you see this message again, please contact your IT Admin.

Don’t you love those messages that tell you to contact yourself? Continue reading