Base-Build Bullet-point List-o-rama

Microsoft

Sep 19, 2018

First published on TechNet on Mar 21, 2012

A lot 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
- WDS
- SCCM w/ OSD
- Manual
- VM templates - don't forget SYSPREP!
- Are most/common reqs met?
  - AD/SQL/EXG/IIS/TS/etc
- Logs/DB spindles
- SAN
  - Space capacity?
  - HBA slot(s) avail?
  - iSCSI NIC slots/ports avail?

Consider scripted build vs image-based build (WIM-based or block-based)
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
Logical/physical drive setup

Standardize on the various high-level elements of the build
- Drive config
- 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
  - 3 ^rd party agents
  - All settings
  - On-going mgmt. of both options

Consider aspects of the OS
- 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
  - Who/What/When/Where
- 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 3 ^rd party add-on
- User Account Control settings
  - During the build – preventing some 3 ^rd 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