Alot more goes into a "well managed" base OS build design beyond booting from the OS media and then "Next > Next > Finish."  The content of this post is the outcome of many fruitful whiteboard sessions around Windows base-OS builds.  Some of this applies to physical servers only, some to virtual only but most is applicable to both.  Many customer's build processes were designed/built circa Windows Server 2003 and XP or earlier.  Alot has changed since then. 

Have a look and see if some of these points don't get you fired up about expanding and/or improving your own base OS build system/processes. 

Rule #1: Document everything.

Consider creating a SharePoint site for build information/documentation

  • How-To Docs
  • Standards
  • Version info
  • Boot disk images (if needed)
  • Contact info
  • Training/PPT
  • Shortcuts to boot images or other paths

 Specifics

  • Standardize on hdwr mfg/models/components (to minimize the variety)
    • Consider a series of ‘hardware templates’ for VMs (low util, standard util, high util)
    • Consider a series of specs for physcial servers - standard util and high util 
    • RAM
    • CPU
    • Local storage
    • USB
    • Optical
    • Standardize on a label/ID process for phys servers
      • Front/rear panel label stickers w/ server name (minimum)
  • Create an “Advisory Board” for the build to get input from various elements across the business and IT
    • Ensures a ‘common’ build is developed (where/if possible)
    • Ensures consistency across the business (where/if possible)
    • Get the network team there for buy-off on the network suitability for the build traffic, DHCP/non-DHCP segments, unicast, multicast, etc
    • Talk to the desktop team – they likely have a build mechanism(s) in place and you may be able to integrate with or build off of what they have
  • Standardize on hdwr/firmwr/sw/ROM/driver versions and update frequency, testing,
  • Use Policy to set/reinforce settings along the 90/10 rule whenever possible
    • Define Local Group Policy settings aligned with corporate policy
    • Define AD GPOs to reinforce settings aligned with corporate policy
    • Use Exception OUs/GPOs for the exceptions
    • Have a solution for getting Local GPO standard settings applied to non-Domain joined systems
      • DMZ
      • LocalGPO tool in MSFT Security Compliance Manager Toolkit
  • Use a flexible process to create the builds so they can easily be maintained and modified going forward
    • Consider scripted build vs image-based build (WIM-based or block-based)
      • WDS
      • SCCM w/ OSD
      • Manual
      • VM templates - don't forget SYSPREP!
    • Service Pack, patch, driver updates and other changes should be easily added to the ‘base build’
    • Design/document a policy to update the build at certain time intervals/milestones
      • 1x, 2x per year
      • Every Service Pack
      • ?
    • Consider off-line builds as well as network connected processes
    • Consider DMZ builds/rebuilds
    • Consider remote/branch office builds/rebuilds
    • Consider partnering w/ hdwr vendor to deploy the build prior to ship/delivery for large-scale roll-outs/refreshes
      • Consider security ramifications of doing so
    • Base the process around defaults/common tools – don’t overly customize a system
      • Leads to a single point of failure and a possible bottle neck as the current enviro is reverse-engineered by someone
    • Consider if DHCP is a requirement of the build process or if static NIC entries can be made
    • Develop a numbering/tracking system for build versioning
      • Service Pack levels
      • OS platform (x86/x64)
      • OS version (Standard/Enterprise/Datacenter – 2003/2008/R2)
      • Core or full GUI
    • Consider the workloads/roles  
      • Are most/common reqs met?
        • AD/SQL/EXG/IIS/TS/etc
    • Logical/physical drive setup

      • Logs/DB spindles
      • SAN

        • Space capacity?
        • HBA slot(s) avail?
        • iSCSI NIC slots/ports avail?
  • Standardize on the various high-level elements of the build
    • Drive config
      • Hdwr-based RAID controller model(s) and settings
      • Logical drive layout
      • Drive letters and sizes
        • How big is C:\ for W2k8 R2 vs W2k3?
        • Is the data drive D:\? 
        • What about CD ROM?
          • Consider making it Z:\?
        • Where in the cage will the drives be place? 
          • How will the logical array chop up those physical slots?
          • Hot spare?
        • Are there multiple channels on the Controller and how will that be set up?
        • What slot will the controller go in?
    • Network config

      • Will there be NIC teaming required?
        • Network/switch port capacity for teaming?
        • Drivers/versions/firmware on NIX
        • Supportability statement reminder
        • Fault toler?  Load balance?  Auto?
        • Speed/duplex settings?
      • What slot will the NIX go in?
      • Consider additional slot use/capacity planning
        • Controller(s)
        • HBA(s)
        • Additional NIX (i.e. VM host server)
      • Naming of the NIX – be consistent and helpful (slot/port/speed//etc)
        • Consider naming them so that based on the name, they can be ‘found’ in the OS on the server – ‘which is which’?
      • Decide to use hdwr vendor drivers or in-box MSFT drivers
      • IPv6 – enabled/disabled/supportability
      • NetBIOS over TCP/IP – enabled/disabled?
      • DNS suffix list?
      • NIC setting standards
        • WINS?  Multiple entries – unless it is a WINS server (in which case, it points to itself only)
        • DNS?  Multiple entries
    • Go through ALL BIOS settings and understand them

      • Consider the various settings/values
      • Define and document the standard
        • See if the hdwr vendor has a way to automate/replicate setting all servers to the spec (HP SmartStart Scripting Tools)
    • Go through ALL Controller settings and understand them

      • Consider the various settings/values
      • Define and document the standard
        • See if the hdwr vendor has a way to automate/replicate setting all servers to the spec (HP SmartStart Scripting Tools)
  • Consider server naming standards and flexibility (vs strict adherence) to be entered during the build process
  • Consider domain-joins and computer account (pre)creation in AD
    • This also includes OU location within AD to ensure proper OUs are applied and security policy is applied as expected/required/desired
    • Consider rebuilds, too, and/or existing computer accounts needing to be ‘touched’ prior to (re)deploying a build
  • Consider time zone settings being configured as part of the build process, if desired
  • Consider a ‘post build’ script or manual checklist that will verify/validate items
    • SCCM/DCM/other inventory tools?
  • Consider logging during the build to ease troubleshooting what can become a VERY complex collection of tasks
  • Consider how complex (and light-touch) you want to design vs how simple (and more-touch)
  • Consider asset tracking systems/updates as part of a build process if needed
  • Control access to the build images to help control sprawl and casual/undocumented changes
  • Consider change mgmt. as required
    • No builds during office hours due to network impact
    • Isolated/insulated/dedicated segment for builds
    • Is a change request needed to build a server?
    • Ensure there is tracking within the build system to answer the common questions - possibly a custom reg key(s)?
      • Who built this system?
      • When was it built?
      • What version of build/components?
  • Consider ‘thick’ or ‘thin’ (build type - not to be confused with fixed-size vs dynamically expanding VHDs)
    • Thin = starting with just what’s on the OS install media
    • Thick = complete, fully-loaded end point system
      • 3rd party agents
      • All settings
      • On-going mgmt. of both options
  • Consider aspects of the OS
    • Strongly consider the default settings of current OS versions
      • W2k8/R2 are secure out of the box
      • Supportability
        • Will some custom setting revert when a Service Pack is applied?
        • Will some patch install make assumptions that aren’t valid on a highly-customized build?
        • Third party tools/agents/etc
          • Many are developed using the base OS default settings
      • Auditing design - base OS builds and the build system itself
        • What do we want audited and what do we need to answer the questions
          • Who/What/When/Where
        • This is likely bigger than a base build component, but it is part of a base build
      • Local Policy Settings
        • Security Policy
        • Other settings
      • Power Management
        • Often an interaction between this and the hdwr vendor/BIOS settings, drivers, firmware
      • Pagefile details
        • How big?
        • Separate spindle?
      • Desktop layout and “Folder” or view options, BG Info?
      • System failure behavior
        • Full dump
        • Mini-dump
        • Kernel dump
        • Dump file location
          • Lots of RAM might mean huge pagefile
            • Consider disk space requirements
        • Auto-reboot
        • Over-write existing file? 
      • Windows Firewall Profiles, Network Location Profiles
      • Backup – either in-box or 3rd party add-on
      • User Account Control settings
        • During the build – preventing some 3rd party drivers/utils to install?
        • After the build – define the design of UAC, set via Local GPO; reinforce/manage via AD GPO
      • Remote Desktop – enabled?
      • Services state
        • Auto/Manual/Disable
        • Supportability
      • WinRM?
      • Powershell code signing reqs?
      • Activation/KMS
      • IPv6?
        • Enabled/disabled
        • Supportability reminder
      • 3rd party or add-on Agents
        • Backup
        • Monitoring
        • Management
      • Application ‘platform’ elements
        • App install location/path/folder(s)
        • Permissions req’d for app run/install?
          • NTFS
          • Registry perms
        • Data drive size/letter
        • Local policy settings and any app impacts?
          • Advanced User Rights
          • Security Settings
      • Permissions model
        • Do we stray from defaults on the System drive?
        • Data drive?
      • Customer Improvement Experience Program settings
      • Error reporting settings (‘Do you want to send this to the Internet?’)
      • Recovery Tools or hidden partitions
        • WINRE
      • Mgmt of local Admin account and password
        • Enabled?  Disabled?
        • On-going pwd mgmt. of some type of local Admin-level account
  • Consider aspects of 3rd party agents, tools, add-ons
    • Where to install?
      • C:\Program Files?
      • A/V exclusion mgmt.
        • What files/folders are we real-time scanning?
      • Security Policy settings req’d by any local service accounts?
        • Log on as a batch job
        • Act as part of the OS
        • Etc
      • Additional pre-reqs for these tools
        • .Net versions
        • WebDav
        • Java
  • Management of the builds
    • Updating driver packs, etc
    • Updating Service Packs
    • Updating 3rd party agents
    • Firmware/ROM updates
    • DR – can you restore the box with your normal methods after one or more of these updates have been applied?
  • Provide training to staff on how to build/rebuild
    • Avoid one-offs or manual builds getting into Production
    • Ensure process/procedures/standards followed
  • Consider DR of the build system(s)
    • Can you restore a base-built server?
    • What if a key DB gets corrupt?
    • What if a config change error is made?  How do we get back to the previous setting(s)
    • The simpler, likely, the better – from many standpoints incl DR
    • Change tracking

Well, I've pretty thoroughly tested out the "bullet point" feature of the blog editor.  

Ping us back in the comments and let us know what works/doesn't work in your experiences.  

Cheers!

Hilde