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: http://www.jamesbannanit.com/2011/04/configure-the-network-access-account-in-sccm-2012/
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…
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 🙂