Category Archives: SCCM 2012

System Center Configuration Manager 2012 SP1

Please don’t setup Intune Hybrid. Just don’t.

Note: This information is relevant as of June 2017 and may change moving forward. The cloud moves quickly and blog posts have a tendency to linger for quite some time 😊

In my role as an Enterprise Architect, I see lots of different environment configurations, and often, have to work within the confines of what I’ve been given. Customers don’t always want to re-architect their environments from scratch, even if the way they have it is far from best practice. Sometimes ‘good enough’, is exactly that.

As of late, I’ve been doing lots of work with Microsoft Intune, a rather comprehensive platform of services that focuses around configuration management of devices, along with complementary services around security and compliance. The most widely used aspect of Intune for my customers is for Mobile Device Management (MDM) which, as of the latest round of updates, has a feature set comparable to MobileIron or AirWatch making it a compelling alternative to centralize licensing, billing, and management of devices in an organization.

So far, all of these customers have also had System Center Configuration Manager (SCCM or Configuration Manager) for managing their existing computers on-premise. The natural thought then, is to integrate Configuration Manager with Intune in what is called a ‘hybrid’ configuration, so that mobile devices and on-premise devices can all be managed from the same console. I’m here to tell you why this is a bad idea, even though for several years, Microsoft advocated for it.

Before we begin, you don’t have to take my word for any of this! Microsoft has updated their own documentation here, advising customers to look towards Intune Standalone for future implementations:

First, there are different development cycles for Intune (cloud-based) and SCCM (on-premise system). Intune can function in a standalone configuration where all configuration is done via the Intune portal in Azure, or in a hybrid configuration where it is linked with SCCM and all configuration is done via the SCCM console. This leads to situations where features and functionality are available in Intune standalone but are not available to be configured via Intune Hybrid, because the SCCM console does not make those features and functionality available.

Here’s a quick example. Let’s look at the documentation on iOS device settings for Intune Standalone, and Intune Hybrid.

Intune Standalone:

Intune Hybrid:

Even taking a single section, the ‘Password’ configuration for example, there’s additional settings you can configure in Intune Standalone that are not possible to configure in Intune Hybrid. Whether these settings matter to you today is important, but knowing that the Intune Standalone features will continue to evolve faster than SCCM, at least in regards to mobile device management, may give you an indicator of which configuration you’d rather be on if you’re hoping for new features that don’t currently exist in Intune as a platform.

Second, one of the biggest issues that I run into when implementing Intune for customers in a hybrid scenario is, well, patience. SCCM, for anyone that has worked with is, is a wonderfully capable product. Truthfully, I don’t know where many of our customers would be without it! That said, SCCM is anything but responsive to a lot of actions in the system. Actions are scheduled, then run on a reoccurring basis, and in some system actions, execution times are randomized in order to not overwhelm servers or systems. How does this apply to MDM in an Intune Hybrid scenario? Well, policies and configuration made in the SCCM console need to be replicated to Intune, and then pushed out to clients. The configuration for these can be complex enough, but coupled with delay and a lot less visibility into Intune actions than SCCM admins are used to (SCCM has extensive logging, but the connection between Intune and SCCM provides minimal information), it can be difficult to know if the issue is you, your policy, SCCM, or Intune when things don’t work how you expect.

Consider, for a moment, Intune Conditional Access. It’s an awesome feature of Intune that blocks email from reaching a device that is deemed non-compliant in an environment. I have users in government, healthcare, and finance using this feature with great success, but getting it configured initially can be complex.

To get conditional access to work, you need to interact with 6 systems (if we’re assuming AD, Exchange, and Configuration Management via Intune/SCCM are all in Hybrid scenarios). A good bit of the complication is waiting for everything to sync not just up into the cloud-based systems, but then back down into SCCM where features can be adjusted and reported on. Keeping Intune in a Standalone configuration cuts down on a replication/sync cycle, and as an admin, well, it just feels faster. It also gives you a web-based interface for configuring your MDM solution, which is likely what teams are used to if they are coming from MobileIron or AirWatch.

Finally, since Intune is part of Azure, which is where Microsoft is bringing many of their new features, Intune Standalone is an environment in which admins should become comfortable. Microsoft has said in no uncertain terms that it’s moving towards Intune as its primary device management system in the long-term (See here: . How Microsoft will handle complex situations like Operating System Deployment (OSD) is anyone’s guess, but as more innovation is being driven from the cloud, I believe the experience in learning how to use Microsoft’s new toolsets outweighs the ‘single pane of glass’ that was once the deciding feature in determining if Intune should be stood up in Standalone or Hybrid configurations. I’ll admit, this is probably a weak point of contention today, but I can only imagine it gains relevance in the coming months as Microsoft continues to innovate.

If you take nothing else away from my experiences, know that every Intune Standalone deployment I’ve done has gone quickly and successfully. Every Intune Hybrid deployment I’ve done has been a challenge for both me, and customer, alike.

Oh? I’ve convinced you? Excellent! But wait, you’re still on Intune Hybrid and want to switch? Until recently, you’d have been out of luck. Thankfully, Microsoft now allows the MDM authority to be changed as of Configuration Manager build 1610 and Intune version 1705. I’ve done this a few times, and while it requires planning and preparation, the process is on the whole, smooth. The docs on making the change can be found here:

Ultimately, the choice is yours as to whether or not you implement Intune Standalone, Intune Hybrid, or move from whatever configuration you already have. Just know that after a few complex Intune Hybrid configurations, and a few simple Intune Standalone ones, I know which side I’m on 😉

Writing back to a file share that isn’t the distribution point – SCCM 2012

Another day another good fight to fight! Today was an epic battle between myself, my coworkers, and our new SCCM 2012 environment.

We do things a bit oddly here, we never used deployment shares in our old system, and so we’re in a ‘transition phase’ between doing things our way, and doing things the right way. In the interest of getting things done quickly, we’ve got a number of scripts that deploy software in creative, but messy, ways.

For example, the following!

1. Script starts
2. Script copies files locally so a network interruption doesn’t mess with things
3. Script caches files back to the file server since they are shared by each instance of the installer that runs
4. Script cleans up and exits

This works really well on our SCCM 2007 server, but has been problematic with our SCCM 2012 R2 instance. The other tech’s that have packages in our environment aren’t too keen on changing anything more than they have to, so the responsibility is on me to figure out how to make it work.

My first thought was the Network Access account in SCCM 2012. It’s moved around a bit, but a friendly google search can help you locate it! I used the following as a nice easy pointer to the right spot in the admin console:

I added the same account as our ‘Client Push’ account, as that’s already an admin on all of our boxes, and has access to the share that we wanted to write back to. I pushed a program. I waited. I shed a few tears. No luck.

I have a simple program that just runs ‘whoami’ and prints it to the C: drive, to see who is writing what. As it was in 2007, SCCM 2012 runs scripts spawned from SCCM as ‘NT Authority\System’. Since that is a local account, with Admin rights of course, it can’t write back or even read from network shares. Ideally then, our hope is that SCCM 2012 would use the Network Access account that we had specified earlier!

Nope. SCCM only uses that account with machines that aren’t in the same domain or in a local workgroup. It does us no good.

Then, after a few hours of staring into the endless pixels of my monitors, I tried what seemed silly. I added ‘Domain Computers’ to our share and gave them ‘Read/Write’ access. Why? Why all of them? Well, it’s not so crazy…

domain computers

Since ‘NT Authority\System’ can’t read or write back to the network, SCCM, by default, uses the machine object in an attempt to connect. I *thought* that it would move to the Network Access account, specified in SCCM if the machine object didn’t work, but that’s not the case for domain-joined machines. This means that you need *every* machine object added to the share that you want to write back to, which seems daunting, but is actually quite easy thanks to the existence of a ‘Domain Computers’ account by default in AD.

Now, I hear the cries of everyone, everywhere. “Security, security! It’s horribly insecure!” It’s actually not as bad as I thought. I’ve found it very difficult (Read: impossible for my feeble mind, crackers might be able to do it) to drop down to system-level authentication via any means that are easily user-accessible. This keeps any ole’ user from authenticating to the share and being able to write, while allowing the SCCM client to drop in as the domain-authenticated machine object and write to its heart’s content!

Forcing SCCM to use the Network Authentication account would be nicer, but I can’t find out how to use those credentials from within a batch file. And yes, I know this all could be way easier with PowerShell by storing an AD account’s credentials and using them to run things, but I’m just trying to make our few hundred batch files run happily in the shortest time possible 🙂

Java 7u51 – System Wide Exception Site List

I recieved a visit from a co-worker the other morning informing me that Java updates had broken his software. He wasn’t too upset, which was nice, but we needed to figure out what went wrong.

As it turns out, Java 7u51 introduced some new security features (yay!) but unless programs using Java applets had applied security certificates to their applications, Java would flag them as potentially malicious and not run them (not yay!).

The workaround isn’t hard; if you go into the ‘Java’ control panel area, head over to the ‘Security’ tab, and add the websites that you need exempted to the ‘Exception Site List’ then your applications should be running once again. The bad news is that doing things this way is only a per-user setting. We needed a way to do this on a system-wide basis, and then be able to deploy it to our organization via SCCM.

As it turns out, there *is* a way to do it, it’s just a bit complex. Oracle has official documentation in a few places but it’s a bit fragmented and there’s not an easy path from these documents to an actual working solution:

Exception Site List Documentation
Java Deployment Documentation

But, to save you all the time and trouble, I’m going to post exactly what you need to do to make it all work!

First, you’re going to need to create a file called ‘deployment.config’ – add the following lines:

Cool. Sweet. Progress. This is just telling Java that it *must* read the system wide config file I’m specifying, and then giving it the path to said config file. Yes, the double slashes and slash in front of the ‘C’ are necessary. Don’t ask me why, but it works as shown above.

Now you’re going to need to make a file called ‘’ – add the following to it:

Same idea as above, you’re telling Java the path to the security exemption site list. I’m putting all this in the same folder because we want it to be system readable and not writable. That makes it so users can’t change the sitelist.

Last, but not least, you’ll need to create the ‘exception.sites’ file. Once you do so, just add whatever site(s) you need, one per line. For example:

Now, dump all that in the “%systemroot%\Sun\Java\Deployment\” folder (You may have to create this folder, it doesn’t exist by default) and head back to that Java control panel area. Head over to the ‘Security’ tab and you’ll see that your site or sites that you listed show up! It’s like magic! In case you were wondering, Java reads that config file every time it loads. This includes in the browser or via the Control Panel, so there’s no need to reboot or do anything crazy, as long as you’re not trying to adjust an already spawned Java session.

All you’ve got to do now is write up a little batch file to make that folder and dump those files in the right place on each machine (SCCM!), and you’re all set! Remember, if you allow users to write to your exemption.sites file via Windows permissions, then they can edit the list, otherwise it’s read only (We went the read only route to give us complete control). Equilibrium has now been restored to your Java-tainted environment 🙂


If you’re wondering about the Mac side of things, it looks like someone else beat me to it! Head on over there and check it out!

Other References:

Installing Orchestrator integration packs without Deployment Manager

Another day in the life of a systems engineer with limited access! While I own the SCCM and SCSM servers that I’ve been blogging about, the Orchestrator server is owned by a different division of our Technology Services group. Now, it’s not usually a problem, and honestly he does a great job with it, but today I ran into an issue.

The Orchestrator admin was taking a day off, he has no backup, and I needed to add the Runbook Designer to a new workstation (my VDI session that I mentioned in an earlier post). Cool, no problem, just install the Designer with the script I set up before. Easy. Right.

I opened the console today to actually use it, and, oh no! All my runbooks had funny looking question marks where there should have been pretty green cubes!


I looked around and noticed that I didn’t have the SCSM integration pack installed. No problem, I’ve just got to find them and install the ones I need! Oh look, they’re right here!

Except – the install process involves making sure it’s deployed via the Orchestrator Runbook Server… that only the admin has access to.

Now is when I had to get creative. I had the integration packs extracted so I had a bunch of .oip files, but attempting to use the console to ‘import’ them didn’t work. I tried dragging them onto the console (just in case) – nope. Tried using the ‘import’ function (which is usually used for runbooks) – nope. Left with no other choice, I busted out my trusty 7Zip utility and tried to extract the .oic file and see what was inside.

Lo and behold! Extracting a .oic file gives you a few configuration-type files (a .ini, .cap, and .eula) as well as a .msi! Woah.


Sure enough, running that .msi as an admin, on my local machine with the Runbook Designer installed on it, installed the integration packs I needed!


Awesome! I can now do what I needed to do.

Now – a few things to keep in mind:

-This is not approved by Microsoft in any way. Do this at your own risk! (That said, I don’t think it’s too risky.)

-This won’t do anything unless the same integration packs have been deployed to your Runbook Server as well! Since I’m just adding a second Runbook Designer on a new machine, pointing to the same server, we’re fine.

-You will feel way cooler that you were able to do this and not pester your Orchestrator admin!



MDT 2012 Error – FAILURE: 8000

So we’ve got a few deployment servers here at the office, all of which I admin. Our production one is a bit old, so I set up a new MDT 2012 server to test things out on. It just so happens I do all the cool stuff on the test server, so sometimes our test becomes our production; welcome to IT in Higher Education!

Anyway, my co-workers were imaging from my test server one day when I got the complaint that imaging was no longer working. I was confused. I hadn’t touched anything lately, but I went to take a look.

The deployment would all of a sudden just stop. No errors (visibly), no screens, I was just left with the background of an MDT Windows PE session. Sigh.

I opened up ztigather.log with CMTrace (If you haven’t added this to your Mini PE disk, you’re missing out!) and found the following error: FAILURE: 8000: Running wscript.exe "X:\Deploy\Scripts\ZTIGather.wsf" /nolocalonly1

I wasn’t quite sure what in the world this meant, so I googled. Not much luck. I found a few notes about trying to run the ztigather.wsf script manually by copying the unattend.xml from the deployment share to the locally created ramdrive, so I attempted to do so.

Looking through the logs I could see that it mounted my deployment share properly at ‘Z:\’ so I didn’t suspect anything wrong at first, but when I tried to path out to actually get my unattend.xml file… I couldn’t!

As it turns out, my permissions on my Deployment Share permissions had changed, and the task sequence could no longer access the files on that share. That’s why nothing was showing up! It kept waiting to get files from the deployment share, and it never got anything back.

I remoted into my MDT server, went to my deployment share, made sure that permissions were set back to where they needed to be (Honestly, since it was easier and this is just my test server, I set it to allow ‘Everyone’ read permissions for a short time.) and all was well! We could once again deploy like MDT intended.

Running the Configuration Manager Control Panel applet from the command line

…or ‘How I learned to stop worrying when Configuration Manager didn’t show up in the Control Panel!’

So I’ve been playing with Windows Thin PC lately at the office. It’s kinda awesome.

It’s a 32bit only OS, but that’s just fine! It’s meant to be an ultra thin base for ‘kiosk’ type deployments. It’s really not meant to have much installed on top of it either, so it’s missing plenty of libraries and supporting pieces of the OS in an effort to remain small. The installed footprint is something close to 1GB and ram usage is beautifully small. That said, sometimes things don’t work quite right due to the missing libs.

I’ve been using Thin PC because my office refuses to use Citrix for some reason (Past history – I swear, working in Higher Education people have such vivid memories it’s like 10 years ago was yesterday…) and there’s no one who is willing or able to try an App-V kinda thing. I’d love to try it in my free time, but I lost that about a year ago. Oh well.

In lieu of that, since our SCCM setup works so darn well, and I’m also the master of Group Policies, I end up making Thin PC based kiosks with single applications installed on them. Any additional updates or patching are handled via WSUS (since I don’t install anything 3rd party on these) but I also install SCCM just in case we need to further manage them down the line, and so we get good reporting on them.

The issue I was having is that after running the SCCM client install, I wasn’t seeing the ‘Configuration Manager’ icon show up in the Control Panel. I saw ‘CCMExec.exe’ running in Task Manager, so I was pretty confident all was well, but I really, really wanted to see that applet.

Thankfully, you can launch it from the ‘Run’ prompt!

Woah! Check that out! It launches the normal Configuration Manager Properties page! It’s worth noting that this appears to work on multiple versions of SCCM and Windows ( SCCM 2007 and 2012, Windows XP and higher) so it may be of use for various configurations beyond this one.