Base-Build Bullet-point List-o-rama

___________________________________________________________________________________________________________________________

IMPORTANT ANNOUNCEMENT FOR OUR READERS!

AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!

We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!

Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.

If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.

NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!

As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!

__________________________________________________________________________________________________________________________

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