Welcome, Singapore Early Experts Study Group Participants (and anyone else who stumbles across this post). We’ll be tackling the first objective in the MCSA exam – Installation of Servers. The Objective definition is the same regardless to whether you are doing the 70-410 or the 70-417 exams, it is as follows:
“This objective may include but is not limited to: Plan for a server installation; plan for server roles; plan for a server upgrade; install Server Core; optimize resource utilization by using Features on Demand; migrate roles from previous versions of Windows Server” [http://www.microsoft.com/learning/en/us/exam.aspx?ID=70-410]
If you have been using the plethora of resources available online such as those found at http://earlyexperts.net and more specifically the Early Experts Installer Quest found at http://aka.ms/EarlyExpertsInstaller you will have gone through the installation of the Operating System, as well as configuring NIC Teaming and Local Storage. Once you log into this resource you get a whole list of TechNet resources; a video on server Deployment which covers Heavy and Light touch installation, a video on Configuring NIC Teaming and a number of articles as follows:
- Install Servers
- Plan for a Server Installation
- Plan for Server Roles (Familiarize yourself with the available Server Roles – We’ll go into more detail on each role in future study guides)
- Plan for a Server Upgrade
- Server Core Overview
- Install Server Core
- Configure Features on Demand
- Migrate Roles from Previous Versions of Windows Server (Familiarize yourself with an overview of the Server Migration Tools – We’ll go into more detail on migrating specific server roles in future study guides)
- Install, Use and Remove Windows Server Migration Tools
- Demo: Installing Server Migration Tools (Based on Windows Server 2008 R2, but still relevant)
- Configure Servers
- Configure Server Core
- Delegate Administration
- Add and Remove Server Roles and Features
- Convert Server Core to/from Full “Server with GUI”
- Configure Services
- NIC Teaming Overview
- Configuring NIC Teaming
- NIC Teaming PowerShell Cmdlets
- Configure Local Storage
- Overview of Storage Spaces ( Covers Storage Spaces in Windows 8 and Windows Server 2012 )
- Thin Provisioning and Trim Provisioning Overview
- Configure Storage Pools and Disk Pools
- Deploy and Manage Storage Spaces with PowerShell
- Implementing Disk Management ( Based on Windows Server 2008, but still relevant )
If you haven’t already, I encourage you to first go ahead and go through this material as this forms the basis for the next posts I have, again this is found at Early Experts – Installer Quest. Don’t be put off by the quantity, it’s broken down into manageable chunks that you can fit into various parts of your day and after all, it’s how you become an expert 🙂
Once you’re ready to progress and covered the material given to you in the Early Experts – Installer Quest it’s time to read on ….
Windows Server 2012 OS Installation
Now that you’re here, I can assume that you’ve gone through the above material and are ready to review. So, we can recap on what’s important and what has changed from previous versions in Windows Server 2012.
The full list of System Requirements is found here: http://technet.microsoft.com/en-us/library/jj134246
Minimum requirements are summarised as follows:
- Minimum Processor: 1.4 GHz 64-bit processor
- Minimum Memory (RAM): 512 MB
- Minimum Hard Disk: 32 GB (This is only for successful installation, consider anything installed over the network, patches, updates, Hibernation and Dump files and so on)
The System Requirements have not increased beyond that of Windows Server 2008 and should not require new investment in hardware to move to Windows Server 2012.
Clean Installation Process
For those who have installed Windows Server 2008 before, you will notice very little has changed. All that is different is the text of some dialog boxes and the speed of installation. If you’d like to see how this has changed over the versions you can check out this video: Windows 2012 vs. Tea. The main difference you will see is that Server Core is the default installation. Let’s understand why this is:
- Deploying a Server Core is:
- Faster than a Server with a GUI – less files and data stored on the server, less patches
- More secure than a full server – less interface and functions means less attack surface, which means less available exploits, which means less patches, which means more uptime .. you get the idea
- More reliable than a Server with a GUI – less components means less things that can go wrong and cause you downtime
- Is more efficient than a Server with a GUI – less components means less workload to run the core OS, this means you can either:
- Have more resources available for the application running on the server
- Use less resources in this server so you can run it on lesser hardware, or, have resources left over for more VM’s on the host server than you previously would have
Key Point to Note: The choice you make at installation is no longer the one you are committed to for the life of the server. You can switch between Server Core, Minimal Shell and Full GUI using PowerShell and a reboot, without having to reinstall the OS. Discussed later …
In addition, Server Core is easier to manage than ever before, as Windows PowerShell (without the ISE as this requires WPF which is not installed) and the .NET Framework (Windows Management Framework) are installed by default, and (very important) Windows Remote Management is enabled by Default. This is an important change from 2008 where it had to be enabled manually (or by GPO or script). So what does this result in? A server that once installed appears, ready to be managed in your Server Manager tool on your workstation or administrative endpoint.
The Microsoft direction with this and future versions of Windows Server is that we should not need to log onto the Server to do anything. Everything is available to remote tools. With PowerShell, you can use a Remote Session if you need to, which launches a PowerShell Process on the Server but runs as if it is local to your machine. So you have multiple alternatives available to you allowing you to avoid logging onto the server.
We will cover management tools in later posts but one other important thing to highlight if you’re thinking “but I still need to log onto the server because we have firewalls in the environment, restricting remote tools” – everything PowerShell and WS-Man runs over one port, so you’re covered there also! Let’s save the in’s and out’s of this for another post though.
Administrators haven’t made the move to PowerShell yet
They just aren’t comfortable enough to use it fully
Perhaps you should check out the Singapore PowerShell User Group
Consider Minimal Server Interface or Server with a GUI (Full Server Interface)
We’re more comfortable doing some administration locally on newly built servers before using remote tools
Our Servers don’t auto-configure as best they should during the build process
Consider Minimal Server Interface
We have some applications which aren’t compatible with Server Core yet
The vendor doesn’t support these apps on Server core
Use Server Core on Minimal Server Interface on servers that you can use it on, speak to your Application Vendors about when they will certify their apps for Server Core and start planning
So what is Minimal Server Interface?
- Command prompt
- Server Manager
- Microsoft Management Console
- Some Control Panel Applets – remember to experiment to find out which ones
But you don’t get (and you don’t really need these anyway as they are on your Administrative endpoint or workstation):
- Control Panel
- Windows Explorer
- Notification Area
- Internet Explorer
- Built in Help
- Windows 8 Shell
- Windows Store
- Windows Media Player
A full reference table is published on TechNet (http://technet.microsoft.com/en-US/library/hh831786)
The best practice for Server Installation is to install Server Core, add Minimal Server Interface or the Full Server Interface when if and when you need it and remove it when you no longer need it. This includes those scenario’s where you think “I’ll leave it there just in case”.
Switching Between GUI/Interface Modes
The Server Interface components are now broken down into 3 features. Server Core is the base module which is always present. On top of that is Graphical Management Tools and Infrastructure. This provides the Minimal Server Interface. On top of that one is Server Graphical Shell (Full Server Interface/Server with a GUI) which gives you Windows Explorer and the rest of the GUI experience. An additional feature is Desktop Experience, this will give you all the Windows 8 stuff on top of the Full Interface such as Media Player, App store and so forth. In a typical Server environment, it’s not typically required but it’s there should you want it.
So, you can visualise the GUI components as follows:
Layer 4: Desktop Experience
Layer 3: Server Graphical Interface (Full Server Interface)
Layer 2: Graphical Management Tools and Infrastructure (Minimal Server Interface)
Layer 1: Server Core
So, how do we switch between each installation type? With PowerShell …
- To start from Server Core and go to Minimal Server Interface
Install-WindowsFeature Server-Gui-Mgmt-Infra -Restart
- To start from Server Core and go to Full Server Interface
Install-WindowsFeature Server-Gui-Mgmt-Infra;Server-Gui-Shell -Restart
- To start from Full Server Interface and go to Server Core
Uninstall-WindowsFeature Server-Gui-Mgmt-Infra -Restart
- To start from Full Server Interface and go to Minimal Server Interface
Uninstall-WindowsFeature Server-Gui-Shell -Restart
- To start from Minimal Server Interface and go to Server Core
Install-WindowsFeature Server-Gui-Shell -Restart
- To start from Minimal Server Interface and go to Server Core
Uninstall-WindowsFeature Server-Gui-Mgmt-Infra -Restart
The appropriate Features can also be installed and removed using Server Manager. The Features are ‘Graphical Management Tools and Infrastructure’ and ‘Server Graphical Shell’
IMPORTANT: In example 2 where we went from Full Server Interface to Server Core you only need to remove the Minimal Server Interface component (Server-Gui-Mgmt-Infra), this results in the dependent component (Server-Gui-Shell) being removed automatically. So although you need to remove two features, you only need to specify one.
IMPORTANT: A restart is required for each change in GUI in order to load the relevant component. You can install without a restart, but the change will only take effect when you restart. Also, to run this against a remote computer, you can use the -ComputerName switch
The Server Roles available within Windows Server 2012 are defined in a full list on TechNet here http://technet.microsoft.com/en-us/library/hh831669.
If you want to use the following Roles then you must add the GUI and cannot use Server Core:
- Active Directory Federation Services
- Application Server
- Failover Clustering
- Fax Server
- Network Policy and Access Services
- Remote Access Services
- Remote Desktop Services
Upgrading from Previous Versions
Generally, it is recommended to install a fresh OS if you are moving from a previous version. You would back everything up, reinstall the OS then set up all the data and apps once again on the new OS. However, there are times where this just is not practical or possible. In the situations you need to upgrade you should remember the following:
- You cannot upgrade a 32bit OS to a 64 bit OS.
- Windows Server 2012 is only available in 64bit and cannot be run on 32bit hardware
- Your SKU is important:
- You can upgrade Standard and Enterprise to both Standard and Datacenter
- You can only upgrade Datacenter to Datacenter
- Windows Web Server can only upgrade to Standard
There is a great post on this from the Core Team Blog that you should read which offers some good information.
Migrating your existing server roles to Windows Server 2012 is made possible with the included Migrations Tools. Full details on those tools can be found here: http://technet.microsoft.com/en-us/library/jj134202 and guidance on how to migrate each role type can be found here: http://technet.microsoft.com/en-us/library/jj134039. Remember, migration guides on TechNet will guide you through migrating a specific role or feature, but where a server runs multiple roles you will need to compile your own migration plan specific to your environment. That said, the TechNet information will still be extremely useful to you.
You can migrate roles from servers running an OS as early as Windows Server 2003. The minimum requirements would be the .NET framework 2.0, PowerShell 1.0 or later and you’re good to go. First, deploy the Migration Tools to the Destination Windows Server 2012 machine using PowerShell or Server Manager. Second, deploy Migration tools to the Source server. If the Source server is running Windows Server 2012 also, deploy using the same method as you did with deploying the tools to the destination. For earlier versions such as Windows Server 2008/2003 you can use smigdeploy.exe which is located in a Deployment Folder that you must create on the Destination Server. You can reference the help of smigdeploy.exe (smigdeploy.exe /?) for exact syntax but it is recommended to become familiar with this before the exam.
IMPORTANT: It is supported to migrate from physical to virtual machines. It is not supported to migrate between servers with different UI languages. It is supported to migrate from legacy OS versions on either x86 or x64 platforms to the x64 Windows Server 2012 platform.
Once you have the tools deployed on the Source and Destination Servers, you’re good to start using them. The migration tools are run from Windows PowerShell, you must be running as an Administrator and add the snap-in to the console using Add-PSSnapin (see command reference below). They can also be accessed from the start menu which launches the PowerShell Console with the Snap-In already loaded.
- Install Migration Tools using PowerShell (Windows Server 2012)
Install-WindowsFeature Migration –ComputerName <computer_name>
- Create a Deployment Folder on the Destination Server (run from the folder cd %Windir%\System32\ServerMigrationTools\)
SmigDeploy.exe /package /architecture <amd64|x86> /os <SOURCE OS Version i.e. WS08R2|WS08) /path <deployment folder path>
- Add the Migration Snap-in to the PowerShell Console
- Open PowerShell on Server Core with the Migration Tools loaded
powershell.exe -PSConsoleFile %SystemRoot%\system32\ServerMigrationTools\ServerMigration.psc1
Features on Demand
Features on Demand supports the Role Based architecture of Windows Server. By adding only the Roles and Features required by the server, it allows you to keep your attack surface smaller and use less disk space (by applying less patches and having less code installed). It also ensures that servers are used for the purposes they are intended and makes delegation and access easier to control. One issue that previous versions of Windows had was that even though all Roles and Features were not installed on each server, the source to install these roles and features was locally present on the disk. This significantly increased the disk consumption of machines (virtual machines were a particular concern), if you had 1000 Virtual Machines, those VM’s had all the source code for all Roles and Features locally on their Virtual Hard Disk, so that’s 1000 copies of something that you will likely never use! Think about how this impacts the server environment, we have mentioned before that it consumes more disk space unnecessarily but also think about backup scenarios, Live Migration scenarios. These will also take longer due to the backup and migration of unnecessary data on the disks. So, how does Windows Server 2012 solve this issue?
Features on Demand supports the removal of source files from a the local disk. This data can be re-added at any time, but better yet you can specify a shared source location when adding Roles and Features, so you can have a single source that all machines can use.
Source files for all Roles and Features are stored in the c:\Windows\WinSXS folder
The Get-WindowsFeature cmdlet will show what Roles and Features are installed and for each of these, will show which have the source files available and which have been removed.
You can remove the source files for any role or feature using the -Remove switch on the Uninstall-WindowsFeature i.e. Uninstall-WindowsFeature DHCP -Remove
If you remove the source files for any role or feature you can specify a location to pull them from by using the -Source switch on Install-WindowsFeature i.e. Install-WindowsFeature DHCP -Source \\myshare\WinSXS. This is also available when using the GUI to install a Role or Feature as a link on the Confirm Installation stage of the wizard. The source can be a local WIM file, a WIM file on a Network Share or a Folder on a network share.
If no source location is specified on an install and the source files are not on the local disk, Windows will try other locations previously used when adding roles and features, a path specified in the Group Policy setting and lastly, Windows Update. This can be a lengthy process however.
What’s Next …
That concludes todays recap post on Server 2012 installation. Please go through all the resources in your own time and ensure you are comfortable with each subject area before sitting the relevant exam. For configuring NIC Teaming and Local Storage, you can follow Richard Qi’s and Tianxiang Chua‘s posts (Links to be added when available)
If you’re interested in taking additional information please check out: