I85PREP
⌘ K
MSCE study materials
MSCE study resources

Server Deployment Automation with Constrained Bandwidth

MSCE · Put your knowledge to work in context.

All case studies

Server Deployment Automation with Constrained Bandwidth

Tailspin has 12 new physical servers to deploy in a data center, plus 200 branch-office workstations that need a standard image. The data center has a 1 Gbps LAN; branches are connected by 10 Mbps links. The team currently installs servers manually from ISO media, which takes about 6 hours per server. Management wants deployment standardized and repeatable. There is an existing Windows Deployment Services (WDS) server in the data center, and a Microsoft Deployment Toolkit (MDT) deployment share. Branch workstations are currently imaged by a technician with a USB drive.

1. Recommend a deployment architecture for the 12 servers and the 200 branch workstations, justifying where images and content should live.

Read the worked answer

Servers (data center, 1 Gbps):

  • Use MDT with a task sequence for standardized server builds, driven by a MDT database or customsettings.ini to assign roles/names per server.
  • Use WDS in PXE boot mode to deliver the boot image and connect to MDT; or use LiteTouch from a bootable ISO if PXE is not desired. At 1 Gbps, multicasting is optional but can help if deploying in waves.

Branch workstations (10 Mbps):

  • Do not stream full images over 10 Mbps; a 10 GB image would take hours per machine and saturate the link.
  • Instead, deploy a local distribution point / local MDT deployment share at each branch, or use pre-staged media (offline media) shipped to the branch. Alternatively, use a branch-cache solution if available.
  • If the branch has a server, host the WIM and MDT content locally and run LiteTouch from PXE locally.
  • Standardize the image and driver set centrally, then distribute content to branches during off-hours.

This balances repeatability with the bandwidth constraint.

2. What must be configured so that each of the 12 servers receives the correct name, role, and domain join during an unattended MDT deployment?

Read the worked answer
  • MDT database (or customsettings.ini with rules) keyed on the server's MAC address, asset tag, or serial number to assign OSDComputerName, domain join OU, and role-specific task sequence.
  • Domain join account: a service account with rights to join computers to the target OU; store credentials securely (MDT uses the deployment share credentials).
  • Task sequence variables: use role-based variables (e.g., ServerRole=Web) to drive application installs and configuration.
  • Bootstrap.ini: point to the MDT server and set the deployment share credentials.
  • Validation: after deployment, verify computer name, OU placement, and installed roles with a post-deployment script or dcdiag/Get-ADComputer checks.

Document the database entries so builds are reproducible.

3. How would you validate that the standardized deployment actually produces consistent, secure servers before rolling out to all 12?

Read the worked answer
  • Pilot one server end-to-end using the task sequence; capture the build log (BDD.log) and review for errors.
  • Baseline comparison: after build, export a configuration baseline (installed roles/features, services, local admins, firewall profile, patch level) and compare against an approved baseline using Get-WindowsFeature, Get-Service, Get-LocalGroupMember, and Get-HotFix.
  • Security checks: confirm the built-in Administrator is renamed/disabled per policy, that the server is in the correct OU and receives the right GPOs (gpresult /h), and that no default credentials remain.
  • Repeatability test: build a second server from the same task sequence and diff the baselines; differences indicate non-deterministic steps (e.g., time zone, locale, or manual prompts).
  • Sign-off only after the pilot and repeatability test pass; then deploy the remaining servers in waves.