Category: Windows Server 2012 R2 MCSA

Setting up and Configuring WDS and Windows Images

Windows Deployment Services (WDS) is a Windows Server role which allows administrators to configure and deploy Windows images over the network. In order for WDS to work the client computers must have a PXE bootable network card installed. Also DHCP must be enabled on the network so that clients can acquire a valid IP address. The DHCP server may need to have options 66 and 67 configured.

  • Option 60 needs to be set to “PXEClient” if WDS is installed on the same server as DHCP or when using PXE with UEFI clients
  • Option 66 points to the FQDN (Fully Qualified Domain Name) or IP of the PXE server (in the case WDS) e.g. “”
  • Option 67 contains the boot file name on the boot server e.g. “boot\x64\” for BIOS and “boot\x64\wdsmgfw.efi” for UEFI

DNS is also required to resolve the FQDN of the boot server specified in option 66.

For Active Directory integrated WDS servers, the WDS server will need to be a domain controller or member of the desired domain.

WDS uses TFTP (Trivial File Transfer Protocol) to transfer files to PXE Clients, the download phase can get quite intensive and can fail if sufficient resources are not available. Ensure the “Remote Installation” folder is on a separate drive to the OS.

WDS is not cluster-aware, however fault tolerance can be achieved using multiple servers on the same network.

1.1.1WDS networking considerations

Both DHCP and WDS listen on UDP port 67. When the PXE client boots it uses the DHCP DORA (Discover, Offer, Request and Acknowledgement) process to acquire an IP address. As this process uses broadcasts, DHCP only works on the same subnet on which it is configured unless a DHCP agent is installed on a router on the subnet of the client.

Understanding this can help to determine how WDS should be configured in a particular environment.

WDS has a few scenarios where problems can occur if not configured correctly: network with WDS and DHCP on one server

In this scenario both services will be trying to bind to UDP port 67 on the same server. In order to get around this problem WDS needs to be configured to listen on a different port and set DHCP option 60 to “PXEClient”.

By default if WDS is configured after DHCP, the setup will do this for you without the need for any manual intervention.

To manually configure WDS to work on a server which also runs DHCP:

  1. Open Server Manager, go to Tools and choose Windows Deployment Services.
  2. In the left navigation pane, expand Servers, right click on the WDS server and click Properties.
  3. Select the DHCP tab and check the Do not listen on DHCP ports checkbox.
  4. If the servers runs Microsoft DHCP then also check Configure DHCP options to indicate that this is also a PXE server, otherwise you will need to leave it unchecked and manually set option 60 to “PXEClient” on the third-party DHCP software.
  5. Click OK to apply the settings. is located on a different server to DHCP

In this instance DHCP option 60 isn’t needed unless you are using UEFI, however for WDS to work options 66 and 67 need to be configured.

1.1.2Install Windows Deployment Services role

The WDS role relies on the Transport Server feature. The Transport Server feature can be installed on its own and used to build custom PXE deployments. For more information about how this can be utilised see this Technet example.

WDS can run on the same server as DHCP or on a separate server, however the configuration is slightly different. This guide assumes that DHCP and DNS have already been configured using Windows server on your network. the role

As of Windows Server 2012 R2, WDS is not yet supported on Core installations. Also to perform the installation you must be a member of the Local Administrators group.

Using Server Manager
  1. Open Server Manager on the server you want to install the role on, go to Manage and click Add Roles and Features
  2. Click Next three times, check Windows Deployment Services, click Add Features and then click Next four times.
  3. Click Install to start the installation and click Close to exit the wizard.
Using Windows PowerShell
  1. Open Windows PowerShell
  2. Issue the following command:

Install-WindowsFeature WDS -IncludeManagementTools WDS

To initialise an AD integrated WDS server you need to be a member of the Domain Admins and Local Administrators group. For a standalone install just the Local Administrators group.

Configuring using the GUI
  1. In Server Manager click on Tools and then Windows Deployment Services to open the WDS management console.
  2. In the left pane, expand Servers and right click on the WDS server and select Configure Server.
  3. Click Next, choose if this will be Active Directory integrated or standalone configuration and click Next.
  4. Click Browse to choose the location to store the images and boot files and click Next. Note that this should be located on a separate drive to the operating system for performance and must be formatted with NTFS.
  5. If this server is already or will be a DHCP server, both check boxes should be checked so that the two roles don’t interfere (see section and click Next.
  6. Choose which clients to respond to and click Next. Normally during the configuration stage of WDS Do not respond to any client computers is checked so not to interfere with the production network. The responding option is then later changed in properties.
  7. Wait for the wizard to complete and click Finish.
Configuring using WDSUtil.exe

This WDSUtil appears to only initialise if the WDS server is domain joined.

  1. Run Command Prompt as an Administrator
  2. Run the following command:

WdsUtil /initialize-server /reminst:”C:\RemoteInstall

You should change the /reminst path to the location where the remote installation files and images will be stored on the server.

This command will initialise the WDS server with defaults and that means that until told to do so, it will not respond to any PXE Clients.

1.1.3Configure and manage boot

So that WDS is able to deploy and installation image (i.e the operating system image) to the client computer, it needs to load to Windows PE (Preinstallation Environment). To do this once the PXE client has downloaded the initial boot software for BIOS or UEFI, the software will connect to the WDS server and using TFTP, download a boot image. The boot image contains a version of Windows PE which is loaded into RAM.

WDS doesn’t contain a copy of Windows PE by default, instead you can load a number of different versions into WDS and choose which one to boot. It is recommended that they should be sourced from Windows installation media and is included with Windows Vista/2008 and onwards. Windows PE is located in the “sources” folder of the media in a file called boot.wim.

Older versions of Windows PE may not allow for all of the features to be used in news versions of WDS. For example x86 UEFI booting requires Windows PE4.0 or above shipped with Windows Server 2012. boot images using the GUI

  1. Insert a Windows Vista or onwards installation media – Server 2012 R2 is recommended
  2. Open Server Manager, go to Tools and click Windows Deployment Services.
  3. In the left pane expand Servers, expand your WDS server, right click on Boot Images and choose Add Boot Image…
  4. Browse to the media, open the sources folder and open boot.wim.
  5. Click Next, and on the next screen it is often advisable to provide a more meaningful Image Name and Image Description.
  6. Click Next twice and wait for the boot image to be added.
  7. Click Finish

An image can be removed by right clicking on it and choosing Delete. It is also possible to disable the image if you don’t want to remove it all together. images using PowerShell

New to Windows Server 2012 is PowerShell support for some of WDS.

  1. Open Windows PowerShell
  2. Issue the following command:

Import-WDSBootImage -Path D:\sources\boot.wim -NewImageName “Boot Image Name”

The path should be replaced with the path of the installation media (typically drive D) and optionally a new image name can be set.

To verify the boot image has been imported run in PowerShell:

Get-WDSBootImage images using WDSUtil

  1. Open Command Prompt
  2. Issue the following command replacing the ImageFile parameter with the path to your image:

WDSUtil /add-image /imagetype:boot /imagefile:D:\sources\boot.wim

1.1.4Install and discover images

Install images contain the operating system, complete with any desired patches, applications and custom configuration settings. WDS deploys these images to the client computers.

Install images can be found in the “sources” folder of the Windows installation media for Windows Vista/Server 2008 onwards in a file called “install.wim”. Typically “install.wim” will contain a number of different images with in which can be selected at setup. WDS allows us to import all or just some from this file.

Images can be added from other sources, for instance customised images and captured images. It is also possible to to deploy VHD files as installation images. When deploying VHDs, WDS will copy the VHD to the client computer as a VHD. This is so that VHD deployment can take place, however you will need a client OS with a licence to boot from a VHD such as Windows 8 Enterprise edition.

WDS puts images into separate groups, when adding images you need to specify or create a group to add the image in. an installation image using the GUI

  1. Open the WDS MMC.
  2. Expand Servers, expand the WDS server, right click on Install Images and choose Add Image Group…
  3. Enter a group name and click OK
  4. Right click on the new group and choose Add Install Image…
  5. Click browse and find the installation image to add, click Open and then Next
  6. Select which images to add to the group and click Next (optionally uncheck Use the default name and description for each of the selected images if you want to change them)
  7. If you chose to rename, follow the steps to change them, click Next and wait for the image to be added. an installation image using PowerShell

  1. Open Windows PowerShell
  2. Run the following command replacing the appropriate parameters to match your scenario:

Import-WDSInstallationImage -Path “D:\sources\install.wim” -ImageGroup “Desktop Images” -ImageName “Windows 10 Enterprise 2016 LTSB Evaluation”

The “ImageName” parameter is optional and is used to choose which images to import when the WIM file has multiple images within it. You can use the following command to list the images held within a WIM file:

Get-WindowsImage -ImagePath “D:\sources\install.wim” an installation image using WDSUtil

  1. Open Command Prompt
  2. Run the following command replacing the appropriate parameters to match your scenario:

WDSUtil /Add-Image /ImageFile:D:\sources\install.wim /ImageType:Install /ImageGroup:”Desktop Images” /SingleImage:”Windows 10 Enterprise 2016 LTSB Evaluation”

The “SingleImage” switch is optional and performs the same function as the “ImageName” parameter as the PowerShell commandlet equivalent.

Not all NICs (Network Interface Cards) support PXE and therefore cannot PXE boot to contact a WDS server. In some instances these computers may need to acquire an image from a WDS server. To allow these computers to discover a WDS server a boot up, an alternative boot device such as an optical or USB device can have a special boot image call a discover image on them. This is a modified Windows PE image, which when booted will find the WDS server and allow the setup to deploy images located a deployment server.

Discover images are created by copying and adapting a boot image in WDS, consequently before attempting to create a discover image, first make sure there is a boot image loaded into WDS. a discover image using the GUI

  1. Open the WDS MMC and navigate to the boot images folder.
  2. Right click on a boot image and select Create Discover Image…
  3. Enter a Name, Description, choose a location to save the discover image to and optionally specify the WDS server to contact.
  4. Click Next and wait for the image to be created a discover image using WDSUtil

  1. Open Command Prompt
  2. Run the following command replacing the appropriate parameters to match your scenario:

WDSUtil /New-DiscoverImage /Image:”Windows 7 x64 Boot” /Architecture:x64 /DestinationImage /FilePath:C:\discover.wim

The “Image” switch indicates the image of the boot image to use to create the discover image from. a discover image to bootable media

For this exercise ensure you are logged in as a local administrator.

  1. Download and Install the Windows Assessment and Deployment Kit for Windows 8
  2. Run Deployment and Imaging Tools Environment from Start
  3. Run the following commands:
  4. CopyPE amd64 C:\WinPE
  5. Copy /y C:\Discover.wim C:\WinPE\media\sources\boot.wim
  6. Oscdimg -n -b”C:\WinPE\Fwfiles\” C:\WinPE\Media C:\Discover.iso

1.1.5Update images with patches and hotfixes

Images can be serviced offline using a program called DISM (Deployment Imaging Servicing and Management). DISM is a command line tool accessible with Command Prompt and PowerShell. DISM can apply Windows updates from CAB and MSU files, which can be downloaded from the Windows Update Catalogue.

DISM can be pointed at a folder of patches to apply or a specific patch. The following example points to a specific update, to update using a folder set the package path to the folder instead.

To service an image it must be mounted to folder, changes can then be made then when it is unmounted the changes can be committed. patches using DISM Command Prompt

Before continuing use the following command to determine which images are in the WIM file so that you know which one to select and service:

DISM /Get-WimInfo:C:\Install.wim

  1. Open Command Prompt and run the following commands:
  2. MKDIR C:\mount
  3. DISM /Mount-WIM /WIMFile:C:\install.wim /Index:2 /MountDIR:C:\mount
  4. DISM /Image:C:\Mount /Add-Package /PackagePath:C:\Updates\windows8.1-kb4052978-x64.msu
  5. DISM /Unmount-WIM /MountDIR:C:\mount /Commit patches using DISM PowerShell Commandlets

Before continuing use the following commandlet to determine which images are in the WIM file so that you know which one to select and service:

Get-WindowsImage -ImagePath C:\install.wim

  1. Open Windows PowerShell and run the following commands:
  2. Mount-WindowsImage -ImagePath C:\install.wim -Index 2 -Path C:\mount
  3. Add-WindowsPackage -Path C:\mount -PackagePath C:\Updates\windows8.1-kb4052978-x64.msu
  4. Dismount-WindowsImage -Path C:\mount -Save

1.1.6Adding and deploying drivers

Drivers can be applied to images, both boot and install as well as to WDS for images to query and install as required. drivers to images

Divers can be added and removed from images using DISM, using a similar process to managing patches. You should note that system drivers cannot be removed. DISM will only accept drivers in their basic form (inf style drivers), that is the inf file and some associated files. DISM can install either one driver at a time or it can load a folder of drivers using the “Recurse” switch.

To modify the drivers in an image file it must first be mounted, the driver changes then made and the changes saved on dismount of the image. The mounting and dismounting commands are the same as those used for modifying any offline image, see the patching example for details.

To get a list of the current drivers the following commands can be used:

Using Windows PowerShell

Get-WindowsDriver -Path C:\ImageMountPath

Using DISM with Command Prompt

DISM /Image:C:\ImageMountPath /Get-Driver

Drivers can be added by referencing the INF file or the folder containing the INF files. The “recurse” switch can be added to search the folders within the specified directory. The “ForceUnsigned” switch can be used to force unsigned drivers to be added.

Adding a driver using Windows PowerShell

Install a specific driver:

Add-WindowsDriver -Path C:\ImageMountPath -Driver C:\drivers\mydriver\driver.inf

Install add driver in specified folder:

Add-WindowsDriver -Path C:\ImageMountPath -Driver C:\drivers\mydriver

Install all drivers in a set of folders:

Add-WindowsDriver -Path C:\ImageMountPath -Driver C:\drivers\ -Recurse

Adding a driver using DISM with Command Prompt

Install a specific driver:

DISM /Image:C:\ImageMountPath /Add-Driver:C:\drivers\mydriver\driver.inf

Install add driver in specified folder:

DISM /Image:C:\ImageMountPath /Add-Driver:C:\drivers\mydriver

Install all drivers in a set of folders:

DISM /Image:C:\ImageMountPath /Add-Driver:C:\drivers\ /Recurse

Although the drivers initially provided from Microsoft on an image cannot be removed, it is possible to remove any additional drivers when they are no longer required. To do this it is best to list the drivers and find the oem*.inf reference for the driver e.g. oem1.inf. This reference is required to specify the driver to remove.

Removing a driver using Windows PowerShell

Remove-WindowsDriver -Path C:\ImageMountPath -Driver oem1.inf

Removing a driver using DISM with Command Prompt

Removing a single driver:

DISM /Image:C:\ImageMountPath /Remove-Driver /Driver:oem1.inf

Removing multiple drivers:

DISM /Image:C:\ImageMountPath /Remove-Driver /Driver:oem1.inf /Driver:oem2.inf drivers to WDS, configure driver groups and packages

WDS can store reservoirs of drivers in driver groups, these groups can have filters applied to them to target specific computer groups. If no filters are set, any computer can check the group for drivers. By default WDS creates a “DriverGroup1” driver group.

Driver groups can be disabled if required so that they aren’t applied to any hardware without having to delete them and enabled again later.

Adding a driver group:

Currently there isn’t a PowerShell command to create driver groups, therefore they must be created using the MMC or WDSUTUL.

Creating a driver group using the WDS MMC

  1. Open the WDS MMC, navigate and expand the WDS server
  2. Right-click on Drivers and select Add Driver Group…
  3. Type in the group name and click Next
  4. You can then set some hardware filters for the group by clicking Add…
    1. Choose a filter type, operator type, enter a value, click Add and then OK
  5. Click Next and then Add if you want to specify some image filters
    1. Choose a filter type, operator type, enter a value, click Add and then OK
  6. Click Next and choose if you want any hardware which matches the criteria to install all of the drivers in the group or just those that match its hardware
  7. Click Next and Finish

Creating a driver group using WDSUTIL

WDSUTIL /Add-DriverGroup /DriverGroup:NewGroupName /Enabled:Yes

You can also apply filters and applicability settings in this command with the “Filter” and “Applicability” switches.

Delete a driver group using WDSUTIL

WDSUTIL /Remove-DriverGroup /DriverGroup:DriverGroupName

Add a driver to WDS using the MMC

  1. Open the WDS MMC
  2. Expand the WDS server which drivers will be added, right-click on Drivers and select Add Driver Package…
  3. Browse to and select the driver to add and click Next
  4. Wait for the drivers to populate and check the ones to add and click Next twice
  5. Wait for the driver to be imported and click Next
  6. Choose to add the driver to an existing group, create a new group or don’t assign at this time and click Next and Finish

Adding a driver to WDS using Windows PowerShell

Import-WindowsDriverPackage -Path “Driver Path” -Architecture X64 -DisplayName “Driver Display Name” -GroupName “DriverGroup1”

The minimum requirement:

Import-WindowsDriverPackage -Path “Driver Path”

Adding a driver to WDS using WDSUTIL

WDSUTIL /Add-DriverPackage /InfFile:”Path to driver file” /Name:”Driver Display Name” /DriverGroup:”Group Name”

The minimum requirement:

WDSUTIL /Add-DriverPackage /InfFile:”Path to driver file”

Once a driver has been added to WDS it can be referenced using its unique name or id.

Adding an existing driver to a group using the WDS MMC

From All Packages:

  1. Go to the “All Packages” folder and right click on the driver you want to assign/remove from a group.
  2. Select Add or Remove from Groups and use the arrow buttons to choose which groups the driver should apply to.

From the driver group:

  1. Right click on the driver group to add the driver to and select Add Driver Packages to this Group.
  2. Add any driver filters to narrow the search and click Search for Packages.
  3. Select the packages to assign and click Add.

Adding an existing driver to a group using Windows PowerShell

Referencing driver name:

Add-WdsDriverPackage -Name “DriverName” -DriverGroupName “Driver Group Name”

Referencing driver id:

Add-WdsDriverPackage -id driver-id -DriverGroup “Driver Group Name”

Adding an existing driver to a group using WDSUTIL

Referencing driver name:

WDSUTL /Add-DriverGroupPackage /DriverGroup:“Driver Group Name” /DriverPackage:”Driver Name”

Referencing driver id:

WDSUTL /Add-DriverGroupPackage /DriverGroup:“Driver Group Name” /PackageID:driver-id

Removing a driver using the WDS MMC

  1. Open the drive group and select the driver to remove from the group.
  2. Right-click on the driver and choose Remove from this group to just remove from the group or Delete to remove it entirely.

Drivers can be removed on the command line either by referencing their name or ID. The following examples for the name only, however the syntax for ID is similar to that of adding to a group.

Removing a driver using Windows PowerShell

Remove driver from a group:

Remove-WdsDriverPackage -Name “Driver Name” -GroupName “Driver Group Name”

Remove driver entirely:

Remove-WdsDriverPackage -Name “Driver Name” -RemoveFiles

Removing a driver using WDSUTIL

Remove driver from a group:

WDSUTIL /Remove-DriverGroupPackage /DriverPackage:”Driver Name”

Remove driver entirely:

WDSUTIL /Remove-DriverPackage /DriverGroup:”Driver Group Name” /DriverPackage:”Driver Name” drivers to boot images using WDS

WDS makes adding drivers to boot images easier by allowing administrators to do a “point and click” injecting of drivers. Note that it is not possible to remove drivers using WDS. To remove the driver after, the image would have to be exported, then the driver removed using DISM and added back into WDS.

To do this the driver must first be added to WDS. To add a driver to a boot image using the WDS MMC follow these steps:

  1. Navigate to the boot images folder and right-click on the boot image to add the driver.
  2. Select Add Driver Packages to Image… and click Next.
  3. Modify the filters if required and click Search for Packages.
  4. Choose the driver to add and click Next.
  5. Wait for it to be applied to the image and click Finish.

1.1.7Install features for offline images

Like updates and drivers, features are turned on and off using DISM, either via Windows PowerShell or the DISM in the command prompt. The following sections will explain the commands for each method. As discussed in the previous sections images must be mounted first, before DISM can manipulate them. Windows Features using PowerShell

List features:

Get-WindowsOptionalFeature -Path C:\MountDirectory

Enabling a feature:

Enable-WindowsOptionalFeature -Path C:\MountDirectory -FeatureName NameOfFeature

Disable a feature:

Disable-WindowsOptionalFeature -Path C:\MountDirectory -FeatureName NameOfFeature Windows Features using DISM Command Prompt

List features as a table – table is optional:

DISM /Image:C:\MountDirectory /Get-Features /Format:Table

Enable feature:

DISM /Image:C:\MountDirectory /Enable-WindowsFeature /FeatureName:NameOfFeature

Disable feature:

DISM /Image:C:\MountDirectory /Disable-WindowsFeature /FeatureName:NameOfFeature

1.1.8Further reading

Further Information

Eli the Computer Guy, (2013). Introduction to Windows Server 2012. [online] YouTube. Available at: [Accessed 10 Jun. 2015].

Jscon, (2012). Understanding Features on Demand and role persistence in Windows Server 2012 – The Windows Servicing Guy – Site Home – TechNet Blogs. [online] Available at: [Accessed 10 Jun. 2015].

Microsoft, (2013). Cloud optimize your business with Windows Server 2012 R2. [online] Available at: [Accessed 10 Jun. 2015].

Microsoft, (2014). Migrate from Previous Versions to Windows Server 2012 R2 Essentials or Windows Server Essentials Experience. [online] Available at: [Accessed 10 Jun. 2015].

Microsoft, (2015). Upgrade Options for Windows Server 2012 R2. [online] Available at: [Accessed 10 Jun. 2015].

Zacker, C. (2014). Exam ref 70-410. Redmond, Wash.: Microsoft Press.

1.1.3 Migrating Windows Server Roles

Migration is the recommended method of moving from an older version of Windows Server to Windows Server 2012 R2. This is because most of the troubles and restrictions encountered when performing an in-place upgrade are no longer and issue. It works by taking copies of critical data from the source (old) server to the destination (new) server with a fresh copy of Windows Server 2012 R2 installed.

Following the migration guide provided by Microsoft, administrators can migrate between:

  • Versions – any version of Windows Server 2003 SP2 or higher
  • Platforms – 32 bit to 64 bit platforms
  • Editions – any edition of Windows Server (provided it supports the required features)
  • Physical and virtual instances – from physical to virtual or the other way
  • Installation options – between Server Core and GUI or the other way

Migration is performed on roles and role services, rather than migrating everything in one go. Windows Server Migration Tools are sometimes required to perform migrations for certain roles and can be installed using the Add Roles and Features Wizard or PowerShell using the following command: “Install-WindowsFeature Migration”.

1.1.2 Upgrading Servers

An upgrade installation is the most likely to have problems due to its complexity and therefore it is recommended that where possible, administrators perform clean installations or migrate applications and roles. If an in-place upgrade has to take place make sure the the server is prepared properly and there is a roll-back plan. Upgrade Paths

Upgrades which are not supported

  • from a 32 bit architecture
  • from Itanium architecture
  • from another language
  • from a workstation computer
  • between build types
  • if it is a domain controller
  • from pre-release versions of Windows Server
  • if the installation type will change (e.g. from Server Core to Server GUI)

If the server is running a 64 bit version of Windows Server 2008 R2 or Server 2012, it can be upgraded to the appropriate edition of Windows Server 2012 R2. Table 5 shows the supported in-place upgrade paths for Windows Server 2012 R2.

Current System Windows Server 2012 R2 Edition
Windows Server 2008 R2 Datacenter SP1 Windows Server 2012 R2 Datacenter
Windows Server 2008 R2 Enterprise SP1 Windows Server 2012 R2 Datacenter or Standard
Windows Server 2008 R2 Standard SP1 Windows Server 2012 R2 Datacenter or Standard
Windows Web Server 2008 R2 SP1 Windows Server 2012 R2 Standard
Windows Server 2012 Datacenter Windows Server 2012 R2 Datacenter
Windows Server 2012 Standard Windows Server 2012 R2 Datacenter or Standard

Table 5: Windows Server 2012 R2 Upgrade Paths Upgrade Preparation

Before performing an in-place upgrade follow this check list:

Check Explanation
Hardware compatibility Ensure the server hardware meets the requirements minimum for Windows Server 2012 R2. Also ensure device drivers are supported on the new operating system.
Disk space There needs to be enough disk space to hold the old operating system, the new one and any setup files.
Check software is signed Device drivers and other kernel-mode software must be signed or the upgrade could be aborted or hardware failures. Uninstall any unsigned software before upgrading.
Gather any required storage drivers To provide the setup with access to necessary mass storage for installation, have a copy of the drivers ready on removable media or placed in “/amd64” directory in the setup location.
Check application compatibility Create an inventory of all the software on the system and check the manufacturer to see if it is compatible. If this is not possible, test it on another server running the new version of Windows Server before upgrading. If the software is critical it is advised that the software is tested in the new environment before an upgrade, regardless of what the manufacturer claims.
Check system for faults Make sure the current install of Windows Server along with any third-party applications are running as they should.
Perform a full backup If anything goes wrong there needs to be something to fall back on. At the very least critical data must be backed up. When imaging the system ensure to take a copy of all boot and system partitions too.
Disable any anti-virus applications Anti-virus software can slow down the upgrade processes and possibly cause problems as well. It is best disabled during the upgrade process.
Disconnect UPS devices Disconnect UPS data cables before running the upgrade as setup will attempt to detect connected devices and sometimes UPS devices cause issues.
Purchase a suitable Windows Server 2012 R2 licence key Check the valid upgrade paths to ensure the in-place upgrade is possible.
Roll-back plan Be prepared to roll-back the upgrade if required. Have a cut-off time which allows enough time for the upgrade to be roll-back, before the maintenance window closes. Ensure the roll-back procedures work before proceeding with the upgrade.

Table 6: Windows Server 2012 R2 In-Place Upgrade Check List

During the upgrade process, the server may restart a few times. Whilst the upgrade is still in progress, the boot menu will provide the option to abort the upgrade and revert the changes. Once the upgrade is completed, this option will no longer be available.

1.1.1 Planning a Server Installation Windows Server 2012 R2 Editions and Installation Options

Since Windows Server 2008 R2, there has not been a 32 bit version of Windows Server. This is because most server processors are now manufactured to the 64 bit standard. This helps when deciding which version of Windows Server 2012 R2 to purchase because there are now only four editions to choose from (see Table 1).

Edition Features
  • Purpose – big powerful servers in data centres with lots of virtualisation
  • Max users – dependant on licence
  • Max SMB connections – 16,777,216
  • Available – through volume licensing and OEMs (Original Equipment Manufacturers)
  • Features fault-tolerance features such as hot-add processor support
  • Purpose – for physical servers with small amounts of virtualisation
  • Max users – dependant on licence
  • Max SMB connections – 16,777,216
  • Available – through volume licensing, retail and OEMs
  • Limited number of virtual machine instances, but has all of the features as the datacenter edition
  • Purpose – intended for small businesses with no more than 50 devices and 25 users
  • Max processors – 2
  • Max users – 25
  • Max SMB connections – 16,777,216
  • Available – through retail and OEMs
  • One physical or virtual server licence
  • Does not include:
  • Server Core
  • Hyper-V
  • Active Directory Federation Services
  • Purpose – intended small businesses with basic server requirements and no more than 15 users
  • Max processors – 1
  • Max users – 15
  • Max SMB connections – 30
  • Available – OEMs
  • No virtualisation support
  • Provides basic services for file and print sharing

Table 1: Windows Server 2012 R2 Editions and Features

For more information about the different server editions see:

Factors affecting the choice of Windows Server edition are:

  • Roles required for the server
  • Virtualisation requirements
  • Licensing plan

It is the job of the administrator to choose an edition which meets the requirements of their organisation with the best return on investment.

When installing the Windows Server 2012 R2 Standard or Datacenter editions there is the option to choose server Core, Minimal Interface and Full. The Core installation provices CLI acess to the server, minimal provides a cut down version of the GUI and the Full version provides the will GUI and CLI options.

Server Core

The CLI option uses the least system resources and has the smallest attack face as many common attack vectors, such as Internet Explorer, are not available (see Table 2).

Advantage Description
Reduced hardware utilisation Removes the some of the memory and processor intensive features of the operating system.
Reduced disk space Requires less disk space for the operating system installation and the swap.
Reduced patch frequency The GUIs for Windows Server are among the most patched aspects of the operating system. Removing them reduces the patch frequency of the server and in turn reduced restarts and downtime.
Reduced attack surface Due to the reduced amount of software running on the server, there are less weaknesses for attackers to try and exploit.

Table 2: Advantages of Server Core

Server Core is the default option when in stalling Windows Server 2012 R2. It does also allow for the install type to be changed after installing, unlike Windows Server 2008. This means the server can be configured using the full GUI, then maintained using the CLI should the administrator wish.

Due to the way Windows Server 2012 R2 can be configured, the CLI is not likely to be heavily used. This is because the Server Manager can be used to remotely manage Windows Servers across the network. This means only a few servers need to be configured with the GUI to manage all of the other servers in the network.

Minimal Server Interface

The minimal server interface provides some of the advantages of the Server Core, but also adds some useful GUI tools too. Most of the hardware intensive UI (User Interface) are removed:

  • Some Windows Shell Features
    • Desktop
    • File Explorer
    • Windows 8 Apps
  • Internet Explorer
  • Some Control Panel Features
    • Programs and Features
    • Network and Sharing
    • Devices and Printers
    • Display
    • Firewall
    • Windows Update
    • Fonts
    • Storage Spaces

It does provide

  • Server Manager
  • MMC
  • Device Manager
  • PowerShell

To install the minimum server interface, first install the Full server installation. Then navigate to “Remove Rolls and Features Wizard” in “Server Manager”. Look for “User Interfaces and Infastructure” feature, then display the sub features and uncheck “Desktop Experience”. This can also be achieved in Windows PowerShell with this command: “Remove-WindowsFeature -Name Server-GUI-Shell -Restart”. This will remove the selected feature and restart the computer in minimal server interface mode. Server Roles

Server roles are collections of services which together make server functions. Roles can be configured in Windows Server 2012 R2 using the Server Manager or PowerShell. The edition selected will determine the role available.

When planning the server, the administrator not only needs to consider which roles the server will need to perform now, but which ones may be required in the future.

Server Core does not support all of the roles available in Windows Server 2012 R2. These are the unsupported roles:

  • Active Directory Federation Services
  • Application Server – this is because it is depreciated
  • Fax Server
  • Network Policy and Access Services
  • Remote Desktop Gateway
  • Remote Desktop Session Host
  • Remote Desktop Web Access
  • Volume Activation Services
  • Windows Deployment Services Virtualisation in Windows Server 2012 R2

Windows Server 2012 R2 Datacenter and Standard editions both support Hyper-V. Each licence allows for one POSE (Physical Operating System Environment) installation. The two editions differ when it comes to the number of VOSE (Virtual Operating System Environment) installations.

Datacenter edition allows for unlimited VOSE, whereas Standard edition allows for just two VOSE installations. Windows Server Essentials allows for either one POSE or VOSE installation. The Foundation edition is limited to one POSE installation only.

More POSE and VOSE installations can be acquired by purchasing additional licences. System Requirements for Windows Server 2012 R2

Table 3 details the minimum hardware requirements to install Windows Server 2012 R2.

Requirement Specification
Processor 64 bit 1.4Ghz or faster
HDD 32GB Available (more is required if installing over a network or the system has more then 16GB of RAM)
Display Super VGA 1024×768 or higher
Peripherals Keyboard and Mouse/Pointing Device
Network Internet Access

Table 3: Minimum Windows Server 2012 R2 Hardware Requirements

There are also some maximum hardware restrictions which may need to be considered (see Table 4).

Requirement Specification
Processors 640
Failover cluster nodes 64

Table 4: Windows Server 2012 R2 Maximum Hardware Configurations Features on Demand

In order to allow administrators to add and remove features to the Windows operating system as they please without having to provide the installation medium, all the required components are stored in a folder called “WinSxS”. These files are copied there when the system is installed and is about 5GB in size. Once a system is configured it is unlikely these files will be used and the disk space could be put to better use.

Features on Demand is a new feature to Windows Server 2012 and Windows 8. It allows administrators to remove these files from the local hard disk of the server. In the event the server requires these files, it can get the from a remote source instead, such as Windows Update, NAS (Network Attacked Storage) or from the installation media. Group policy can also be used to specify the new location for Windows Feature payloads. Features on Demand provides three states for features in a system:

  • Enabled
  • Disabled
  • Disabled with payload removed

To remove the payload of a feature, the following command can be used in Windows PowerShell: “Unistall-WindowsFeature [feature] -Remove”. To reinstall the feature from a specific source (other than Windows Update) the following command can be using in Windows PowerShell: “Install-WindowsFeature [feature] -Source [source]”.

The ability to move the storage disabled components to a central local is very useful when disk space is limited and or expensive. Increased virtualisation and SSDs (Solid State Drives) have increased the need for Features on Demand.

1.1 Installing Servers

When deciding on a new server installation careful thought and planning needs to be taken. Some things which needs to be considered based on the functional requirements of the server are:

  • Hardware
  • Virtualisation technologies (if any)
  • Operating system edition
  • GUI (Graphical User Interface) or Server Core CLI (Command Line Interface)
  • If the new server will be introducing new technologies or software, should it be first tested on a test network before it is put into production?
  • Location in the network
  • Number of users now and in the future

Introduction to 70-410

70-410 is the first exam in the Server 2012 R2 MCSA (Microsoft Certified Systems Associate). This blog contains some material to help you prepare for the exam.

I am studying for this exam now, so most of the content is based on my notes.

The main book that I am using for this exam is Installing and Configuring Windows Server 2012 R2 Exam Ref 70-410 along with other documentation on Microsoft Technet.

They say one of the best ways to learn something really well, is to learn it, then see if you can teach it. So here it goes; hope it helps.