Freigeben über

Part 1: Nano Server Domain Join (Deployment-at-a-scale an introduction)

  • Artikel

Over a series of blog posts we will describe a solution for how to deploy Nano Server at scale using Microsoft tools. The blog posts are:

Introduction

As we are in the final leg of Windows Server 2016 development, many of you are already planning to deploy Nano Server in your organization at a large scale. For those of you who are evaluating Windows Server 2016 and Nano Server and have provided feedback, a huge THANK YOU. We are listening closely to your comments and have been actively making changes based on your input. Today's topic is a great example.

Nano Server

When deploying at scale, we see that most deployments are in clusters with homogeneous hardware such as a rack or two of servers configured with identical hardware configurations. In this case, we want to focus on providing a highly optimized and standardized, minimal footprint image that can be deployed and managed at scale. That's where Nano Server comes in.

Nano Server is "Just-enough-OS" and provides the optimal choice to run in your datacenters and private cloud for Compute, Storage, DNS, Web and Containers workload to name a few. Nano Server is provided on the Windows Server 2016 media, but is not part of the Setup experience like you may be used to seeing with the other two options: "Server with Desktop Experience" or "Server Core". Instead, Nano Server uses image based deployment and requires you to create an image for your configuration in order to deploy it (see https://aka.ms/nanoserver for instructions).

In many scenarios, you might want to join Nano Server to your Active Directory domain for authentication or because your workload requires it such as Clustering. Nano Server is refactored from the ground-up to provide a minimal base OS footprint and thus Nano Server does not have the capability to do online domain join at the time of deployment which is typically used by most deployment/provisioning system like: Windows Deployment Services (WDS), Microsoft Deployment Toolkit (MDT) or System Center Configuration Manager (SCCM). For Nano Server, domain join is an offline process.

Since offline domain join may be new to some of you, there are some important considerations for this process. For Nano Server to join a domain offline, this involves creating a domain blob and applying the blob to an instance of Nano Server. The offline domain blob is a high privileged asset representing machine identity on the network and is important to safeguard. While these domain blobs are used one time only, you should secure these domain blobs (typically stored on a file share) and applying auditing and access control policies. When deploying generic images across datacenters, security and access control has an additional challenge because either:

  • the generic image lacks security context to use for domain join, or
  • you have to explicitly specify a domain credential that can be used for domain join and ensure it is not stored in plain text

Thus, when using offline domain join, you must use a security credential to read the offline domain blob from your network.

As with any online domain join operation, using offline domain join post deployment on Nano Server, a full reboot of the machine is required. This may require significant time on higher-end scale up servers if doing Bare Metal Deployment (BMD) – increasing overall time it will take for installation.

Your Feedback (Thanks!)

Based on your feedback we have received about the need to be able to easily domain join Nano Server deployments at scale, we have come up with a solution using Microsoft tools that are available today. This will enable you to deploy Nano Server in large numbers and still automate the deployment in a similar fashion to your Server with Desktop Experience and Server Core deployments today.

The Challenges & Design Goals:

The primary challenge that is addressed with this solution is "Deployment at scale of Nano Server" with customized images with the following design criteria's in mind:

  • Simplicity: Only use one tool
  • Speed: Minimize Reboots: Deploy end-to-end with a minimum of reboots, as a reboot can take long time (10+ minutes on large scale up physical servers)
  • Security: Stay secure without taking high risks
  • Automation: Minimum of / no manual steps in the process outside the deployment
  • Goal: Full deployment and Domain Join in under 3 mins from boot to login screen

The Solution

In order to address the above challenges & design goals, the following components enable most, if not all of the these:

  • Windows Deployment Services (WDS) only
  • WinPE image with .NET and PowerShell added
  • Embedded PowerShell script
  • Variables controlled via Unattend xml file in WDS
  • No storage or blob files stored on shares
  • No storage of usernames / passwords to allow for maximum security.

Scoop of the solution:

The main objective for the proposed solution is to provision a Nano Server image to a physical or virtual machine and domain join the server to a domain based on the following user input, which can be stored in an unattend.xml file or be provided by the administrator as part of the provisioning process.

- User Name

- Password

- Machine Name

* the domain name is taken from the user name

Requirements for the solution:

The following requirements are needed in order to deploy Nano Server and join it to a domain:

  1. AD domain
  2. DHCP Server with IP scope which the VM or Physical server can connect with
  3. WDS Server
  4. Modified WinPE Image
  5. Unattend XML file
  6. Nano WIM / VHD / VHDX Image
  7. Domain account(s) to create the AD computer object and authenticate with WDS server.

The process

  1. Server PXE boots and gets an IP address from the DHCP Server
  2. Downloads and boots the modified WinPE Image from the WDS server
  3. Selection of Image from WDS (Automated)
  4. Partitioning of Server (Automated)
  5. Deployment of WIM / VHD / VHDX & Unattend.xml
  6. PowerShell executes and joins Nano Server to the domain with domain credentials
  7. Server reboots and is fully provisioned, including joined to the domain.

 

 

This process takes about 2½ minutes using a virtual machine in our test environment. This might take longer depending on your network speed, disk performance, and if using a physical server, the post time for the server.

You can read more about WinPE Order of Operations in WinPE and WinPE Limitations.

The videos

We have recorded two videos which show the deployment of Nano Server using WDS

Video 1: This video deploys Nano Server to a VM without asking any questions, all information is stored in the unattend.xml file on the WDS server.

Video 2: This video shows deployment of Nano Server with parameters given for Image, Partitions, User & Password and Server Name.

Various scenarios between the two videos can be achieved, based on how much data is given in the unattend.xml file and automation done around it.

Next Step Blog Posts

In the next few blog posts, we will drill into this topic further. Here's what we're planning:

Regards

The Nano Server Team