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 ContentSoftware md ContentUpdates md ContentDrivers md ContentApp-V md ContentOSD md ContentOSDBootImages md ContentOSDOSImages md ContentOSDOSInstall md ContentOSDMDTToolkit md ContentOSDMDTSettings md ContentOSDDrivers md ContentOSDMDTSettingsDeploy md InstallationUpdates md BootImageFiles md Captures md Hotfixes md Scripts md StateCapture md Tools md ToolsPSTools md Stuff md MDTLogs md Import md ImportDrivers
md ImportMOFs md ImportBaselines 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).
