Friday, April 15, 2016

Enhancing WDS with the Microsoft Deployment Toolkit (MDT)

The Microsoft Deployment Toolkit (MDT) is a free tool that can be downloaded from Microsoft to assist you with Operating System Deployment (OSD) and is often used in conjunction with Windows Deployment Services (WDS) and System Center Configuration Manager (SCCM). It can also be used on its own. It this article we'll be looking at using MDT with WDS.

Download and install the Microsoft Deployment Toolkit (MDT)

Get started by downloading the Microsoft Deployment Toolkit (MDT) from here. We're using the MDT 2013 Update 2 version in this article. You'll also need to download the Windows Assessment and Deployment Kit (ADK). We're using Windows ADK for Windows 10, Version 1511 which you can download here.

After downloading both of these tools, install MDT and when you go to install Windows ADK, we recommended selecting the following option in the picture below.

Creating the Deployment Share

The deployment share is a network share on your Windows network that hosts all of your deployment resources. You interact with your deployment share through the MDT Deployment Workbench and you can have multiple deployment shares on your Windows network.

Start by creating an empty network share on your Windows network for example, \\\DeploymentShare$. Make sure you have write permission to this share and that anyone you wish to be able to deploy from it has permission to read it.

Start the MDT Deployment Workbench and in the left pane, right-click on the Deployment Shares node and select New Deployment Share. The first screen you will be presented with will ask you to specify the path to your deployment share. Replace the default path of C:\DeploymentShare with the path to your network share. When you complete the wizard, MDT will begin populating the network share with some default deployment resources.

Configuring the Deployment Share

Before you can start deploying Windows from your deployment share, you need to configure your deployment share by adding deployment resources and creating task sequences. Deployment resources includes things like operating system installers, drivers, applications and Windows updates. Task sequences allow you to specify what happens on a step-by-step basis during an operating system deployment.

Deployment resources and task sequences are configured and managed through the MDT Deployment Workbench. There is a lot you can configure that we're not going to cover here in this article but the best way to learn is to have a play and explore. One thing we do recommend you configure is the rules for your deployment share which can be accessed by right-clicking on your deployment share in the Deployment Workbench and then selecting Properties and then the Rules tab.

We've added the property DeployRoot=\\\DeploymentShare$. MDT has a bunch of other properties you can add that you'll have to find and discover.

Generating a boot image for your Deployment Share and adding it to WDS

After you have configured your deployment share, the next step is to actually perform a deployment. In the Deployment Workbench, right-click on your deployment share and select Update Deployment Share. Complete the wizard to generate new boot images for your deployment share.

One the wizard completes, your boot images will be located in a subdirectory called Boot in your deployment share. For example \\\DeploymentShare$\Boot. Select the appropriate boot image from this folder and upload it to your WDS server. If configured correctly, any computer that performs a network boot from your WDS server will now download the MDT boot image. This boot image will then connect to your deployment share allowing you to select which task sequence to run for your deployment.

Saturday, February 20, 2016

Remote connect to Windows PE with VNC

A few years ago, I came across this neat trick while trying to upgrade my WD Sentinel DX4000 from Windows Storage Server 2008 R2 Essentials to Windows Server 2012 R2 Standard. The challenge in this was that the DX4000 is a headless system. To interact with the DX4000, someone came up with the good idea of injecting a TightVNC server into the Windows PE boot media of the installation. You could then interact with the installation from a remote computer. In this guide, we are going to show you how you do that.

To see the original article about installing Windows Server 2012 onto a WD Sentinel DX4000, click here.

Download and install TightVNC

The first step is to download TightVNC from and install it onto a reference computer. We're using the 64-bit version of TightVNC 2.7.10 for this guide. Perform a Complete install of TightVNC accepting any defaults. When prompted to set a password for our TightVNC server, we have chosen not to use a password for the purpose of this guide.

After installing TightVNC, the next step is to configure your TightVNC server with all the settings you want and then open up the registry to HKLM\SOFTWARE\TightVNC\Server.

Export that key to a file called TightVNCServerSettings.reg and save the file to the installation directory of TightVNC, C:\Program Files\TightVNC. Your .reg file should look similar to the following.
Windows Registry Editor Version 5.00


Download and install the Windows Assessment and Deployment Kit (ADK)

Windows PE is a part of the Windows Assessment and Deployment Kit (ADK). For this exercise, we're using Windows ADK for Windows 10. You can download Windows ADK for Windows 10 from here.

Run adksetup.exe. When you get to the part where you select the features you want to install, select Deployment Tools and Windows Preinstallation Environment (Windows PE). We only need these components for this exercise.

Create the Windows PE image and inject TightVNC

Run the Deployment and Imaging Tools Environment command prompt as an administrator. The shortcut should be in your Start menu after you install ADK.

Using the following article as a guide to create and mount a Windows PE image. We're using the 64-bit for our example.

Step 1. Create your Windows PE image with the working directory C:\WinPE_amd64.
copype amd64 C:\WinPE_amd64

Step 2. Mount your Windows PE image so that it can be edited.
Dism /Mount-Image /ImageFile:C:\WinPE_amd64\media\sources\boot.wim /Index:1 /MountDir:C:\WinPE_amd64\mount

Step 3. Copy the installation directory of TightVNC, C:\Program Files\TightVNC with the .reg file we created earlier in it to C:\WinPE_amd64\mount\Program Files\.

Step 4. Configure TightVNC to start up automatically in your Windows PE image by editing C:\WinPE_amd64\mount\Windows\System32\startnet.cmd in notepad. Add the following lines to startnet.cmd. This is a quick and dirty method.
%WINDIR%\System32\wpeutil.exe InitializeNetwork
%WINDIR%\System32\wpeutil.exe DisableFirewall
%WINDIR%\regedit.exe -s "%SYSTEMDRIVE%\Program Files\TightVNC\TightVNCServerSettings.reg"
"%SYSTEMDRIVE%\Program Files\TightVNC\tvnserver.exe" -install -silent
"%SYSTEMDRIVE%\Program Files\TightVNC\tvnserver.exe" -start -silent

Step 5. Unmount and save your Windows PE image.
Dism /Unmount-Image /MountDir:C:\WinPE_amd64\mount /Commit

Step 6. Once your Windows PE image is saved and unmounted, create your Windows PE media using the command MakeWinPEMedia. Below is an example for a USB drive on D:\.
MakeWinPEMedia /ufd C:\WinPE_amd64 D:

Boot Windows PE and remote in

Test your TightVNC enabled Windows PE boot media by booting a computer with your Windows PE boot media. On another computer on the same network, connect to your Windows PE machine with TightVNC viewer. You'll need the IP address of the Windows PE computer. How you work this out, we'll leave up to you.

Wednesday, February 10, 2016

Introduction to Operating System Deployment (OSD)

Operating System Deployment (OSD) is the practice of creating, maintaining, configuring and deploying operating system images usually to a large groups of computers in an organisation. In the past, the objective was to create a Standard Operating Environment (SOE) where the software is standardised in an organisation as much as possible. Increasingly more common nowadays is the practice of customising operating system deployments on-the-fly to cater to an individual's or group's need in an organisation.

In this article we are going to look at some of the tools available to the Windows administrator for OSD and to cover off some of the basic terminology used in this practice.

Windows Deployment Services (WDS)

Windows Deployment Services (WDS) is a server role that is included in the server editions of Windows. When deployed, it allows you to deploy Windows over a network to Preboot Execution Environment (PXE) enabled clients.

WDS is a full deployment solution however it does not have the ability to create or edit operating system images. Administrators have to do this manually using other tools such as the Deployment Image Servicing and Management (DISM) tool or the Microsoft Deployment Toolkit (MDT) before importing the image into WDS for deployment.

Deployments are initiated by configuring the PXE client to perform a network boot. During the network boot, a boot image running Windows PE is downloaded from WDS to the client and is used to perform the Windows install. Resources for a WDS deployment are stored on the WDS server.

Microsoft Deployment Toolkit (MDT)

The Microsoft Deployment Toolkit (MDT) is a set of free tools that can be downloaded from Microsoft to assist you in OSD and is often used in conjunction with Windows Deployment Services (WDS) or System Center Configuration Manager (SCCM). One of MDT's best features is the use of task sequences to create and deploy operating system images. Task sequences allow you to specify what happens on a step-by-step basis during an operating system deployment.

MDT also introduces the Windows administrator to the practice of building and capturing a reference image for OSD. The purpose of the captured reference image is to create a standard or baseline for all other deployments. To cater for a particular individual or group need, all the Windows administrator would need to do is deploy the captured reference image using a customised task sequence for that particular individual or group. This minimises the need to maintain different operating system images for different purposes. All there would be is different task sequences. Task sequences are a lot easier to create and maintain.

Although MDT can deploy operating systems, it is not often implemented as a deployment solution by itself as MDT deployments have to be initiated by using boot media. MDT does not have a mechanism to deliver boot images over a network. This is why MDT is often used in conjunction with WDS or SCCM.

When MDT is used on its own or in conjunction with WDS, resources for a MDT deployment is stored in a network share called the Deployment Share. We recommend setting up this share on the WDS server. When used with SCCM, resources for deployment are stored on targeted SCCM distribution points.

System Center Configuration Manager (SCCM)

System Center Configuration Manager (SCCM), also just simply known as Configuration Manager is just one of many products from the Microsoft System Center suite. Configuration Manager is a systems management solution designed to manage large groups of computers. OSD is just one of Configuration Manager's many capabilities.

OSD with Configuration Manager is similar to MDT in that they both employ the use of task sequences for deployment. Unlike MDT, Configuration Manager by itself is a full deployment solution. Operating system deployments with Configuration Manager can be initiated by boot media, PXE boot and if the environment is configured correctly, the Configuration Manager server itself. This ability to deploy an operating system without the need for a Windows administrator to physically initiate it on the target computer is the basis for Zero Touch.

The other part to Zero Touch is fully automating the workflow so that there is absolutely no user interaction at all during the operating system deployment. When using Configuration Manager alone to accomplish this, anything beyond a simple workflow will require heavy scripting. This is why MDT is often integrated into Configuration Manager. Integrating MDT makes available all the Microsoft made scripts in MDT for Zero Touch Installation (ZTI) in Configuration Manager.

Integrating MDT with Configuration Manager also makes available another installation type, User Driven Installation (UDI). UDI is a user friendly wizard-based approach to operating system deployment and is designed to be used by the end-user. One of the advantages of UDI is the ability to customise the operating system deployment, allowing for example the user to select what applications get installed or whether or not, their data is migrated. ZTI is more suitable to standardise environments.

Resources for operating system deployments in Configuration Manager are stored on targeted distribution points.

Windows Assessment and Deployment Kit (Windows ADK)

The Windows Assessment and Deployment Kit (Windows ADK) is another free toolkit from Microsoft to assist you in deploying Windows. Windows ADK is actually a prerequisite to installing MDT and SCCM. There are two types of tools included in Windows ADK, assessment tools and deployment tools.

The features most commonly installed for OSD in the Windows ADK are, Deployment Tools, Windows Preinstallation Environment (Windows PE) and User State Migration Tool (USMT).

Tuesday, February 2, 2016

WD Sentinel DS6100: Supporting Time Machine

One of the features of the WD Sentinel DS6100 running Windows Server 2012 R2 Essentials is that is supports Time Machine out of the box. Time Machine is a very user friendly backup solution for users running Max OS X on your network. They will need a user account on your domain to access this feature.

The default location for Time Machine backups on your server is D:\ServerFolders\TimeMachine. If you attempt to move the folder, you may have noticed that it doesn't appear in your Windows Server Essentials Dashboard.

Moving the Time Machine Folder

Moving the Time Machine folder required a bit of trial and error on my part. It is not something supported by Western Digital. Regardless I'm going to show you how I did it on my sever.

Step 1. Go to the new location on your server and create a folder called TimeMachine or copy it from your old location.

Step 2. Open services.msc and stop the services Western Digital AFP Support Service (WDAfpSupportService) and Western Digital Bonjour Service (WDBonjourService). You may also need to open the Task Manager and kill any associated processes.

Step 3. Open regedit.exe and using the Find and Find Next features, find all instances in your registry that references the old location (D:\ServerFolders\TimeMachine) and change it to your new location. In our example we have changed to E: drive.

Step 4. Open services.msc again and restart the services Western Digital AFP Support Service (WDAfpSupportService) and Western Digital Bonjour Service (WDBonjourService). It may also be a good idea to restart your server.

Step 5. The folder should have been moved now. Check by attempting to use Time Machine on a Mac on your network. To help troubleshoot errors, you can look at the Event Viewer for events generated by ExtremeZ-IP.

ExtremeZ-IP is the third-party tool Western Digital used to provide Apple Mac support on the DS6100.

Sunday, January 31, 2016

Connecting to Windows Server 2012 R2 Essentials

If you've been following my blog, you'll know that the server I've chosen to host my Windows domain is a WD Sentinel DS6100. This is a server that originally came with Windows Server 2012 R2 Essentials. I've since performed a clean install with Windows Server 2012 R2 Datacenter however to keep the LCD and fan working correctly, I've had to install the Windows Server Essentials Experience role, not something you would typically do to a server in a large enterprise environment.

Anyway since it's installed, I thought I should have a play with it and note down my experiences. I'm going to start by looking at the client experience. For more information about Windows Server Essentials, have a look at this TechNet article.

Connecting to the Server

You can connect both Windows and Mac OS X clients to a Windows Server 2012 R2 Essentials server. Connecting a Windows client to Windows Server Essentials will domain join the client to the Windows domain however on Mac OS X, it does not.

To connect your client to the Windows Server Essentials server, you need to download and install the connector client which can be found on your server. Simply open up a web browser and enter in http://<SERVER>/connect. Replace <SERVER> with the IP address or host name of your server. You must be on the same subnet as your server to connect.

Follow the wizard to connect your client to Windows Server Essentials. You'll need a user account on the server in order to successfully connect. The user account you use will become the local administrator on the client you are connecting.

If you are installing the connector software on a Windows client that is not domain joined, there will be one restart to join the client to the domain. It is also possible to install the connector software on clients that are already joined to the domain.

The Launchpad

Once the connector software is installed on your client, you'll have access to the Windows Server Essentials Launchpad. The Launchpad is just a simple app that provides access to all the services provided by Windows Server Essentials. Some of these services such as Remote Web Access will need to be configure correctly before it can be used.

Managing Windows Server Essentials

Installing the connector software also gives you access to the Windows Server Essentials Dashboard if you are an administrator on the Windows Server Essentials server.

The Dashboard is where you perform all of your Windows Server Essentials administrative tasks such as adding users, removing devices, creating shared folders and managing backups. This is not accessible on the Mac OS X Launchpad though. You'll need to log on locally to the server for these situations.

Wednesday, January 27, 2016

Redirecting the Users and Computers Containers in AD

By default, when you create a new user or join a new computer to your domain, the Active Directory (AD) object for that new user or new computer is put in the default Users or Computers container under the root of your AD domain.

To see what is the default location for these objects in AD, you can run the following PowerShell command.

Get-ADDomain | Select-Object ComputersContainer, UsersContainer | Format-List

The Users and Computers containers in AD are not Organizational Units (OUs) and hence you cannot apply Group Policy Objects (GPOs) to them. To get around this many administrators design their own Active Directory structure with OUs for users and computers. We've created an example of an AD structure below. When you do this, you may want to change the default location of where your new user or computer objects are created.

I know we've used PowerShell to check the default location of where these objects are created however we will not be using PowerShell to redirect these object to their new location. At the time of writing, the PowerShell way looks way more complicated as there are no PowerShell equivalent cmdlets. We'll be using the commands redirusr and redircmp.

Redirecting Users to another OU

To redirect new user objects in Active Directory to another organisational unit, use the command.
redirusr <CONTAINER-DN>
For example in our AD structure, we would enter the following;
redirusr "OU=User Accounts,OU=Users,,DC=Unit34,DC=co"

Redirecting Computers to another OU

To redirect new computer objects in Active Directory to another organisational unit, use the command.
redircmp <CONTAINER-DN>
For example in our AD structure, we would enter the following;
redircmp "OU=Computers,,DC=Unit34,DC=co"

Sunday, January 24, 2016

Configuring Auto-Logon for a Computer in a Windows Domain

Now you wouldn't do this in a corporate environment but in your Windows domain at home, you may have a parent or partner that doesn't like entering their username and password on their Windows computer that you've domain joined to your network. For situations like these you may want to configure auto-logon.

To configure auto-logon for a computer on your domain, you'll need to modify the registry on that computer.

Important Note: Be careful when editing the Windows registry. Some serious damage can be done to your operating system if you modify something important. Also for this to work, you'll need to store the password of the user account you are going to use for the auto-logon in the registry. This isn't secure.

Start regedit.exe on the computer you are configuring auto-logon and navigate to the following location.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

In the above location, modify or create the following registry keys. Once done auto-logon is configured. Restart your computer to test.

DefaultDomainNameREG_SZ<Insert domain name here. E.g. UNIT34>
DefaultUserNameREG_SZ<Insert domain username here. E.g. hannah.chan>
DefaultPasswordREG_SZ<Insert domain user's password here.>

This works for Windows 7, Windows 8, Windows 8.1 and Windows 10.

Deploying Windows Deployment Services (WDS)

One of the most useful and easiest services you can deploy in your Windows domain is Windows Deployment Services (WDS). WDS allows you to install Windows over your network to Preboot Execution Environment (PXE) enabled clients. This can save you time when installing Windows on your client computers or virtual machines as you don't have to create and use install media.

How does Windows Deployment Services (WDS) work?

It's quite simple. The WDS server sit on your network and listens for PXE boot requests. When it receives a request, it sends down a boot image to the PXE enabled client. The boot image, running Windows PE is then used to download and install the actual operating system image. The boot image and operating system image is stored in the Windows Imaging format (.WIM) on the WDS server.

Choosing where to deploy WDS

This one is pretty straight forward for our domain. Since we only have one subnet, WDS will be deployed on that subnet. What we do need to consider is whether we want to deploy WDS on an existing server such as or on a new virtual machine. Our recommendation is on a new virtual machine (called Deploying it to is fine as well. Whatever you choose, just make sure there is enough hard disk space provision for the Windows images you wish to deploy.

In a domain with multiple subnets, you'll need to work out which is the best subnet to deploy WDS to as well as how to configure the routers with IP Helper trickery. We're not going to cover this here in this article.

Deploying WDS

Start by creating a new Windows Server 2012 R2 virtual machine called with enough disk space (40-60 GB) to hold your install images. Alternatively you can use install WDS on your Hyper-V host

To install WDS on your server;
  1. In Server Manager, star the Add Roles and Features Wizard.
  2. Continue through the wizard until you get to the Server Roles page. Select the role Windows Deployment Services.
  3. Leave the feature selection as is on the Features page and continue through the wizard to install WDS accepting any default values. The defaults will install the WDS roles Deployment Sever and Transport Server.
  4. Once WDS is installed, close the wizard.

After installing WDS, we need to configure the WDS server. Start the Windows Deployment Services management console under the Tools menu in Server Manager.

In the Windows Deployment Services management console, right-click on your WDS server and select Configure Server to start the Windows Deployment Services Configuration Wizard.

Integrate the WDS server with Active Directory.

Enter the path for the remote installation folder. For our lab environment, accepting the default value is fine otherwise please use a NTFS volume prepared earlier that is separate from your system partition.

If you've kept the default path for the remote install folder you'll see the following warning. Just click Yes to continue.

Configure the WDS server to Respond to all client computers (known and unknown) and then complete the wizard.

Importing Windows Images

Before we can start deploying Windows over our network, we need an Windows image to deploy. There are actually two parts to this. First we need to prepare and import our boot image. Second we need to prepare and import our actual operating system image. We're not going to cover Windows image management here so in our example, we're just going to use the default images (boot.wim and install.wim) you can normally find on Windows install media.

Start the Windows Deployment Services management console under the Tools menu in Server Manager. In the Windows Deployment Services management console, select your WDS server and right-click on the Boot Images folder, select Add Boot Image.

Select your boot.wim file on your Windows install media. It should be located under the sources folder under the root of your Windows install media.

Accept all the defaults and complete the wizard. Your boot image should now be imported.

Now back in the Windows Deployment Services management console, select your WDS server and right-click on Install Images and select Add Install Image. The first thing you need to do is create an image group. We've decided to create one called Windows.

Select your install.wim file on your Windows install media. It should also be located under the same sources folder in the root of your Windows install media. If you don't see an install.wim file but an install.esd file instead, you'll need to export it into a .WIM file. Here's a quick reference on how to do that quickly here.

Accept all the defaults and complete the wizard. Your install image should now be imported.

Performing a network boot

How you perform a network boot will depend on the device you are booting. You may need to configure the firmware of the device you are booting. For most computer, hitting the F12 key during boot will cause the computer to perform a network boot. If WDS is configured correctly, performing a network will download the boot image you imported early to the computer and then from there, you can install your Windows operating system.

Thursday, January 21, 2016

WD Sentinel DS6100: Using Unsupported Drives

The WD Sentinel DS6100 has 4 drive bays for 3.5" hard drives. If you put one in and the drive bay light lights up red, you may have put in an incompatible drive. The drive is still usable however and most likely there is nothing wrong with it. Western Digital just wants you do know that they won't support it. They would rather you would use one they have specified.

Anyway, to use the incompatible drive in your WD Sentinel DS6100, all you have to do is go to the Monitor tab of the Windows Server Essentials Dashboard. Look for the drive bay with the incompatible drive and on the left of it, press the Enable button.

You'll get a prompt telling you the drive is incompatible and that data loss may occur. We're not entirely sure how true that statement is. Just simply press Yes to the prompt to start using it. The red light should then go away.

Update: It turns out that you need the latest WD components for this option.

Wednesday, January 20, 2016

Prevent Objects from being Accidentally Deleted in Active Directory

Once you have gone through all the effort of designing and implementing your Active Directory structure you may wish to lock down some of your Active Directory objects to prevent them from being accidentally deleted or moved. Organisation Units (OUs) are locked down by default however you may also want to do this to your domain controllers and important servers.

To do this, start Active Directory Users and Computers and make sure you have Advanced Features selected in your management console.

Then find the object you want to protect, right-click on it and select Properties. If you've selected Advanced Features in your Active Directory Users and Computers console, you should now see an Object tab. Select Protect object from accidental deletion and then you're done.

In our domain, we did this for our domain controllers and our Hyper-V server

Windows Images: Converting between .ESD and .WIM

There has been a few times now that I have found myself needing to convert a Windows image in Microsoft's Electronic Software Delivery format (.ESD) to a Windows Imaging file format (.WIM). I don't like the use of third-party tools and have trouble remembering what the exact commands are to do this in Windows. So I've written a quick reference below. You'll need to run the commands with administrative rights in a command prompt.

Get Windows Image Info

To find out what is in your Windows image use the following commands.
dism.exe /Get-WimInfo /WimFile:install.esd

Convert from .ESD to .WIM

To convert an Windows image from .ESD to .WIM format, use the following commands.
dism.exe /Export-Image /SourceImageFile:install.esd /SourceIndex:1 /DestinationImageFile:install.wim /Compress:Max /CheckIntegrity

Convert from .WIM to .ESD

Use a command similar to the above to convert a Windows image from .WIM to .ESD. Please note that the compress type parameter is set to Recovery.
dism.exe /Export-Image /SourceImageFile:install.wim /SourceIndex:1 /DestinationImageFile:install.esd /Compress:Recovery /CheckIntegrity

Tuesday, January 19, 2016

Remote Server Administration

In an modern environment, the majority of server administration tasks are performed remotely. In this article we are going to introduce to you some of the tools you can use to remotely administer your Windows domain.

The Admin Computer

Before you can perform any remote administration, you'll need a computer to perform the remote administration from. Administrators normally maintain a computer with the latest administrative tools on it which is often also their everyday computer. To administer your Windows domain, you will need a Windows computer, ideally domain joined to your Windows domain.

We recommend using the latest version of Windows as your admin computer with the latest version of whatever admin tools you are going to use installed. This is a common practice as the latest tools can often also administer systems that are older than the tools are. For the purpose of this blog, we are going to assume you will be doing most of your administration from a Windows 10 or later computer.

Remote Desktop

The easiest remote administration tool most administrators learn first is Remote Desktop Connection. This is mainly because this tool is included in Windows.

Remote Desktop is also a pretty simple concept. When you connect to the remote computer, you will see the desktop of the remote computer on your screen. You can then basically interact with the remote computer as if you were physically there.

There are some disadvantages however. As a graphical tool, Remote Desktop can consume quite a bit of resources, especially bandwidth. You'll notice performance decreases on slow servers and connections. Remote Desktop is also a tool that uses one-to-one connections, making management of a larger number of servers time consuming.

In Windows and Windows Server, receiving Remote Desktop connections is not allowed by default. You must enable this on each computer you want to connect to in the Remote tab of System Properties. Many administrators enable and enforce this setting for computers in a domain using Group Policy.

In older versions of Windows, Remote Desktop Connection was also known as the Microsoft Terminal Services Client (mstsc).

Windows Remote Management (WinRM)

Without going into too much detail, Windows Remote Management (WinRM) is not a tool but a implementation that underpins remote management tools in recent versions of Windows. WinRM is turned on by default in the server editions of Windows (Windows Server 2012 onwards) however is off by default in the client editions.

There are two tools that rely on WinRM that we are going to look at.

Server Manager

Server Manager is a dashboard-like management console in the server editions of Windows. Server Manager allows IT professionals to manage multiple Windows-based servers, both locally and remotely from their desktops. On Windows Server installations with a full GUI, Server Manager comes installed by default and starts automatically when you log in.

Server Manager can be installed on client editions of Windows and is a part of the Remote Server Administration Tools (RSAT) that you can download from Microsoft. You'll need to find the matching version of RSAT for your version of Windows. Installing RSAT will also install other Microsoft Management Consoles (MMC) snap-ins which you can use to manager your server. Server Manager is good for managing small to medium sized environments.

PowerShell Remoting

PowerShell is a powerful command-line interface (CLI) and scripting language for the administration and automation of Windows and Windows Server. It is preinstalled on all modern Windows-based operating systems.

Compared to other tools, PowerShell has a steep learning curve however it is the most powerful, especially in large environments. Administrators are strongly advised to acquire skills in using PowerShell. If you are new to PowerShell, we recommend getting started by doing the free Getting Started with PowerShell 3.0 Jump Start course from the Microsoft Virtual Academy.