Best Practice – Folder Structure for Building Windows Images and Maintaining Drivers in Win7 Server2008 & Server 8

Home > Blogs > Windows 7 > Best Practice – Folder Structure for Building Windows Images and Maintaining Drivers in Win7 Server2008 & Server 8

Best Practice – Folder Structure for Building Windows Images and Maintaining Drivers in Win7 Server2008 & Server 8

Like This Blog 0 Steve Fullmer
Added by March 28, 2012

With the advent of customizable Microsoft .wim files, students often ask if there is a best file structure for gathering and maintaining drivers and images. The textbook answer is ‘develop a structure that supports your environment’, effectively another way to say ‘it depends’. After providing varied examples, I wondered if there might be a related best practice starting point. Nope. A web search reveals dozens of best practices for AD Group structure, file server shares, and website content. Microsoft offers image deployment structure best practices. There is a great article that clarifies the independence of driver source directories relative to deployment package placement in System Center Configuration Manager (SCCM). SCCM best practice suggests creating packages based on the collection definition, though this is an inefficient method to manage source content.

Images can be modified using the Windows Automated Installation Kit (WAIK) and the Microsoft Deployment Toolkit (MDT) as well as SCCM. SCCM assembles packages from OS images, updates, and drivers using task sequences so it makes sense to separate the source content similarly if you are using SCCM. Task sequences are a component of the image capture, build and deployment processes. Changes to infrastructure, including the capture folder structure, will cause sequence rework or repeated component import. Yet, ‘it depends’ ought to be independent from the tool or deployment approach selected. You want to pre-think and create a folder structure that will simplify component capture and management without significant content duplication or structure modification. Regardless of your preferred management or deployment tool, there are some considerations that remain constant.

Plan a comprehensive source structure. Start with the major component sets, and work toward the granular. Even if you do not use all the possible sets, or place them on the same server, planning a comprehensive layout will help to identify potential gaps, and to prepare for both OS and tool evolution. As with all good plans, once you have a top-down model, work up from the bottom looking for missing elements.

Note. We are not discussing the management of deployment images or related configuration controls. Windows Deployment Services (WDS) or SCCM serve this purpose. This article focuses on the source elements of an image build. While you may wish to manage multiple images for deployment purposes, only two best lend themselves to the image preparation. The first is the Out-of-the-Box (OOBE) image. The second is the reference baseline for your enterprise. Beyond these two baselines, customization involves selecting from the smorgasbord of drivers and tools collected from across the entire content licensed by your enterprise.

To plan your folder structure, start with large categories: server, client, mobile, drivers/peripherals, common, and legacy. Server, client and mobile platforms will support different OS and application suites. Peripherals, like printers, might be connected to any platform, as are drivers – this set is often hardware aligned so you might call it ‘hardware’ although this label implies ‘system platform’ which is a generally bad delineator or label. You might want to separate printer drivers from other drivers (which I discuss later). The ‘common’ bucket contains tools, agents, or installers that could be used on any platform. I recommend the ‘legacy’ folder as a catch-all for drivers and tools that once served strong purpose in your organization, though for any variety of reasons don’t fit your current deployment plans. You want to gather useful content as you discover it.

A SCCM driver best practice articles by Hayes Jupe suggests separating good drivers from bad drivers and provides a few examples. Given the absolute requirement for signed drivers in the Windows 7 64-bit architecture, unsigned drivers might fit into the ‘bad driver’ category until driver compatibility and signing issues are resolved. Why add a problematic driver (or other component) into a source folder that might be automatically integrated (using the recurse switch) into an image build? I like the idea and will be adding a’BadDriver’ folder to my repository.

Although software applications can be injected into a .wim image, and similar organization might be useful, application deployment methodologies are more varietal and therefore suggest less organized controls.

Within the server, client and mobile categories, create folders for each OS baseline. For example, within the server folder: Windows Server 2008, Windows Server 2008R2, and Windows Server “8”. Within the client and mobile categories create a folder for each operating system: Windows XP, Vista, 7, 8, etc. Place editions (e.g. Professional, Enterprise, Ultimate) under the OS. Consider whether you want to separate x86 and 64-bit architectures at or below the OS edition level. Place Service Packs below the edition level, within their own folder since components are less interchangeable. Although you may place multiple editions of an OS within a single .wim file very efficiently, the requirement for digitally signed drivers and driver compatibility suggests separation for source management purposes.

Driver source collection is more complex. You can simplify your efforts by separating print device drivers from all other driver sets. Printer drivers can be inserted cross-platform even when locally incompatible, for instance when providing print services and drivers to a mixed client environment. Aggregate deployment of printer drivers also applies across the x86 versus 64-bit architectures. For instance a 64-bit Windows 7 client functioning as a print server could provide x86 drivers to other clients within the environment. Although you want to further separate printer drivers by architecture and vendor, placing them all within one high level directory allows for recursive image insertion.

While other peripheral drivers may be deployed across platform or version, they should not be deployed across architectures (x86 vs. 64-bit) due to the driver signing constraints. Examples include webcams, bar code readers, and other external devices. Create a second, top tier hierarchy for this set. Your third category includes drivers that are device, vendor or system specific, including both platform and architecture limits. I prefer separating the third set by vendor/provider for easy location, although there is a strong consideration for separating by type (e.g. NIC, HDD, USB, CD/DVD) since many USB or expansion slot connected devices can be migrated between system units, or installed to circumvent failing mother-board embedded elements. Once you have determined how to aggregate the third set of drivers, incorporate the architecture consideration within your directory structure for this set as well – at least for systems or devices that are capable of supporting Windows 7 and beyond.

Here is a screenshot representing a possible hierarchy. hierarchy Folder Structure Windows Images Drivers in Win7 Server2008 & Server 8

 

There are clearly hundreds of possible combinations.  The organization structure will make a difference, whether you manually gather components during image modification or use an automated tool.  Do a little research, consider the tools you are using and might use before settling on a structure.  One of the more powerful Windows 7 build elements is the ability to recursively gather drivers into an image.  Starting at a selected folder, a single command dynamically walks all the subfolders to discover driver files.  Yet, you do not want to add incompatible drivers to an image.  A little understanding and planning will go a long way.

SCCM 2012 adds the concept of ‘application’ deployment to the use of ‘package’ deployment.  While packages are deployed to collections, typically filtered by hardware (WMI) settings or AD computer groups, applications will be associated with individual users and aid in distinguishing between desktop and mobile solution sets for the same person.  Expanding functionality and complexity suggests getting a handle on your source content sooner rather than later.

Whatever your environment, you will discover that carefully planned source management will help you to efficiently use the suite of tools available for .wim management and feature deployment.

Enjoy,

Steven Fullmer
Interface Technical Training Staff Instructor

Videos You May Like

Windows 10 Managing, Deploying and Configuring – December 2, 2015

0 434 1

In this recorded Windows 10 training webinar from December 2, 2015, Windows Server instructor Rick Trader presents the deployment and management of Windows 10 Enterprise and the new Provisioning capability in Windows 10. Learn how to manage Windows 10 deployments using System Center Configuration Manager, Mobile Device Management and Intune. Also included in his presentation … Continue reading Windows 10 Managing, Deploying and Configuring – December 2, 2015

Subnetting a TCP/IP Network using the Magic Box Method

0 1642 5

See our class schedule for complete Course Schedule Training. Classes are held in Phoenix, AZ and can be attended online from anywhere in the world with RemoteLive™. Instructor: Rick Trader  Video Transcription: One of the things that we might have to do in our corporate network is to take a class of IP addresses and then subnet that into … Continue reading Subnetting a TCP/IP Network using the Magic Box Method

Detailed Forensic Investigation of Malware Infections – April 21, 2015

4 608 5

How does an investigator hunt down and identify unknown malware? In this recording of our IT Security training webinar on April 21, 2015, Security expert Mike Danseglio (CISSP / CEH) performed several malware investigations on infected computers and identify symptoms, find root cause, and follow the leads to determine what’s happening. He demonstrated his preferred … Continue reading Detailed Forensic Investigation of Malware Infections – April 21, 2015

Write a Comment

Share your thoughts...

Please fill out the comment form below to post a reply.