After seeing Adam Gross’ very interesting content on CM TechPreview’s new AdminService
feature, I immediately started to wonder how I could go about using it in place of remote WMI Operations.
So I connected to my stale Tech Preview Environment (it was TP 1806, lol!) and found it had expired 😢.
After googling for 14 seconds, I found no one had made a completely slap-dash guide to deploying the current version of CM Tech preview complete with all of the links you’ll need, so I decided to do that here.
note: I am assuming you’ve installed ConfigMgr **a lot of times** before this, so I won’t go too in-depth into what you need to do for each step. Where relevant I provide a link to a post with the exact step you need to do, in case you’re not sure.
Have an AD domain
You must have a domain to setup ConfigMgr. Womp womp. If you need a domain controller, make a new Server 2019 VM and follow this blog post for a one-click domain controller install.
Make a Service Account
You don’t want to be stuck doing this when you get to the SQL Install step so do it now. Make a new account and set it to never expire and give it limited perms.
Do not place it in Domain Admins or Enterprise Admins
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.
· 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:
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
|All SCCM Content
|Drive Source Files
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
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?))
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 (manage.microsoft.com) to enable Conditional Access. Continue reading