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.


Steven Fullmer
Interface Technical Training Staff Instructor

Videos You May Like

A Simple Introduction to Cisco CML2

0 3902 0

Mark Jacob, Cisco Instructor, presents an introduction to Cisco Modeling Labs 2.0 or CML2.0, an upgrade to Cisco’s VIRL Personal Edition. Mark demonstrates Terminal Emulator access to console, as well as console access from within the CML2.0 product. Hello, I’m Mark Jacob, a Cisco Instructor and Network Instructor at Interface Technical Training. I’ve been using … Continue reading A Simple Introduction to Cisco CML2

Creating Dynamic DNS in Network Environments

0 646 1

This content is from our CompTIA Network + Video Certification Training Course. Start training today! In this video, CompTIA Network + instructor Rick Trader teaches how to create Dynamic DNS zones in Network Environments. Video Transcription: Now that we’ve installed DNS, we’ve created our DNS zones, the next step is now, how do we produce those … Continue reading Creating Dynamic DNS in Network Environments

Cable Testers and How to Use them in Network Environments

0 735 1

This content is from our CompTIA Network + Video Certification Training Course. Start training today! In this video, CompTIA Network + instructor Rick Trader demonstrates how to use cable testers in network environments. Let’s look at some tools that we can use to test our different cables in our environment. Cable Testers Properly Wired Connectivity … Continue reading Cable Testers and How to Use them in Network Environments

Write a Comment

Share your thoughts...

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