ConfigMgr Folder Structure

I’ve seen a lot of environments and the one typical commonality is that there simply was no planning or forethought put into where to store everything like source files, packages, downloads, etc. Chaos reigns and it ain’t pretty.

For all of my lab builds and production rollouts, I use a simple script to build up a nice, consistent folder structure that is easy to follow and enforce, eliminates ambiguity, and is simple. Note that in really large environments, the exact details I outline here may not apply, the principals do though – namely keeping it simple (stupid) and consistent.

One of the first things I notice in most of these environments is that they have multiple shared folders on the same system for the different items. Why? Why use three or five or whatever number of shared folders when one will suffice? I always create a single, top level folder called ConfigMgr (not SCCM) and share it out. Then, under this folder I create multiple sub-folders for all of the content required. This way, everything that is needed is easily found and backed up. This share could even be hosted by DFS and physically located on a non-ConfigMgr system (or multiple if you are using DFS).

Another common source of issues is simple organization and naming, particularly of package/application source files. This is key so that you actually know what’s in each folder, what package or application it corresponds to, and if it’s being used at all. I always use three-levels of sub-folders: vendor, application, version. For the version sub-folder, if its applicable, I always use the version number, architecture (x86 or x64), edition (like Pro Plus or Enterprise), and an indicator for App-V if that’s in use in the environment. You could use more sub-folders for these, but that’s usually overkill and unnecessary.

Permissions can get a little tricky — but just like King Burger, don’t get crazy with it. Best practice for shared folder permissions is to use Everyone Full or Read and let NTFS control access on a granular level. In this case, I use Everyone Full because ConfigMgr needs to write files to some of these directories and you as an administrator surely will want to also.

Here’s a snippet of the batch file I use to set up my typical hierarchy:

@echo off
pushd %~dp0

echo Creating top-level Directory
md ConfigMgr
cd ConfigMgr
net share ConfigMgr=%cd% /GRANT:Everyone,FULL 

echo Creating Sub-directories
md Content
md Content\Software
md Content\Updates
md Content\Drivers
md Content\App-V
md Content\OSD
md Content\OSD\BootImages
md Content\OSD\OSImages
md Content\OSD\OSInstall
md Content\OSD\MDTToolkit
md Content\OSD\MDTSettings
md Content\OSD\Drivers
md Content\OSD\MDTSettings\Deploy
md InstallationUpdates
md BootImageFiles
md Captures
md Hotfixes
md Scripts
md StateCapture
md Tools
md ToolsPSTools
md Stuff
md MDTLogs
md Import
md Import\Drivers
md Import\MOFs
md Import\Baselines

echo Setting permissions
icacls Captures /grant %USERDOMAIN%_cmnaa:(OI)(CI)F
icacls MDTLogs /grant %USERDOMAIN%_cmnaa:(OI)(CI)F 
icacls StateCapture /grant LocalService:(OI)(CI)F

popd

And, here’s a PDF that shows my “typical” folder structure with a brief explanation of each and permissions I often assign (this doesn’t match completely with the batch file above as these are both just starting points).

[ddownload id=”5617″]