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?
- 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
- 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
- What do we want audited and what do we need to answer the questions
- 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 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?
- Strongly consider the default settings of current OS versions