So I was asked a question about OSConfig on Facebook today. The question was “Why don’t you want to create a reference image?” I have several answers . . .
OSConfig can be used to create a Reference Image
When I decide to create a Reference Image, there is nothing preventing me from using OSConfig.
Threshold 2 Has Not Been Released
I don’t want to make a Reference Image today, when there is a major update next week
We are still evaluating Settings and Configuration of Windows 10. Not having a Reference Image right now allows me to make changes on the fly. I can make a change within minutes if I need to make a change, rather than waiting for me to run a new Build / Capture for a new Reference Image
We still do not have 100% of the Settings and Configuration defined and approved yet. Why make a Reference Image if you don’t have the Reference Settings and Configuration defined yet? With OS Config and Rapid Changes, I can deploy several different Configurations for testing as necessary.
OEM Folders Don’t Work
In OSD Deployments, OEM Folders don’t work, you have to have a separate script to perform this function. OSConfig handles this
Auditing of OEM Folders
OEM Folders allows me to add files to our Corporate Image. The Logs that are persistent on the Client Computer allow me to know which files were default and which files were added by the OS Deployment.
In addition on the Client Computer, I have a persistent Archive of these added files.
Auditing of Settings and Configuration
In addition to the logging of all Registry changes
I also have persistent copies of all the files used for the Settings and Configuration, allowing me to restore in the future if something gets overwritten.
Backup of Registry
I have a snapshot of the System prior to when my changes were made.
Single Point of Configuration
I now have a single point in my OS Deployment that has every change I made in one step. So rather than maintain several steps in the Task Sequence, I only have to maintain one.
Issues with Sysprep Copy Profile
Since CopyProfile doesn’t work properly, I avoid that issue altogether.
Remove Settings and Customization from Reference Image
When I decide to make a Reference Image, I can choose not to use OSConfig, and make no changes to the Settings and Configuration. I can make my Reference Image build only for the purpose of integrating Patches and Runtimes. Once I have this Reference Image, I can use OSConfig in the OS Deployment Phase, separating the two entirely (since Settings and Configuration may change more often than Runtimes).
While you may be an expert in Deployments, and may not have a need for OSConfig, others that are new to Customizations may find OSConfig easier than writing separate scripts, adding multiple Task Sequence steps, or Suspending a Task Sequence and making all the changes in there.
Pack and Go
If you need to share your OS Configuration and Settings, how do you do this? OSConfig allows me to make a copy of a single directory that I can Zip and share with someone. This takes maybe 2 minutes total. Without this, it could take hours or be impossible to provide someone with all your steps, files, and configuration. This could be essential to Consultants that work with multiple Companies, and having everything in one spot, in one step, and one Zip Archive.
In addition it is very lightweight. On a check of a Windows 10 x86, OSConfig in the Windows directory consumes 138MB, with 134MB being the backup of the Registry, so in reality there is only 4MB of content (which are probably from OEM Folders).
Nothing is Set in Stone
I haven’t made any decisions yet on which way I will go with a Reference Image, but OSConfig allows me to be more dynamic about my deployments. Good luck with your deployments. I’ll share OSConfig soon enough.