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.

Friday, January 8, 2016

Performing the first domain join: CARBON to Hydrogen

If you're been following our articles correctly, here's what our setup currently looks like.

R0 [] - We've named our network router R0. The DHCP server on this router has been disabled and an static IP has been assigned.

CARBON [] - Our physical server running Windows Server 2012 R2 Datacenter. This server is our Hyper-V host. In my example setup I've used a WD Sentinel DS6100 as my physical server. This computer is currently not domain joined and will also double as our file server.

Hydrogen [] - A Windows Server 2012 R2 Standard virtual server running on CARBON. This virtual server is our domain controller and hosts the domain. It also has DHCP and DNS installed.

Domain Joining CARBON to Hydrogen

The actual process of domain joining a computer to a domain is quite simple although it varies between different versions of Windows. In general, you open your system properties the same way like you would when you rename your computer. Instead of selecting a Workgroup, select Domain and enter your domain like the example below.

You'll then be prompted to enter in the credentials of a domain administrator, someone who has rights in the domain to join computers to the domain. Once done, you'll get a confirmation that the computer is joined to the domain and that it needs to restart.


In our setup, CARBON is our Hyper-V host and we are domain joining it to our domain which is hosted on a virtual machine called Hydrogen hosted on CARBON. Can you see the interdependency here?

Before performing the domain join, open the Hyper-V manager console on CARBON and go into the settings of the virtual machine Hydrogen. Make sure that the Automatic Start Action is set to Always start this virtual machine automatically and the Automatic Stop Action is set to Shut down the guest operating system. This will make sure the domain controller is available when CARBON starts and is shutdown gracefully when CARBON is shutdown or restarted.

For the WD Sentinel DS6100 only: Installing WD components

After performing a clean install of Windows Server 2012 R2 on a WD Sentinel DS6100, the LCD screen will not work and the system fan will spin at full speed. To fix this you need to install the Windows Server Essentials Experience role and the WD components. Do not do this until you have domain joined your server to your domain!

If you install the Windows Essentials Experience role before a domain join, it will automatically convert your server to a domain controller and create a new domain. This is not what we want. Perform the steps to install Windows Server Essentials Experience and the WD components when have domain joined CARBON to to fix your LCD and system fan issues.

Wednesday, January 6, 2016

Configuring DNS

DNS translates easy-to-remember names such as into their respective IP addresses which are easier for machines to understand. In this article we are going to look at configuring DNS for our domain on our domain controller Hydrogen. In our earlier guide, we installed and configured the Active Directory Domain Services role on Hydrogen. As part of that process, the DNS Server role was also installed.

Make sure you understand the network design for for this exercise.

There are only two things we need to do to configure DNS on our domain controller. They are;
  1. Create Forward and Reverse Lookup Zones
  2. Configure DNS Forwarders
Start by logging onto Hydrogen. Server Manager should start up automatically.

Step 1. In Server Manager, go to the Tools menu and select DNS to start the DNS management console. Right-click on the HYDROGEN node in the left pane and select Configure a DNS Server to start the Configure a DNS Server Wizard.

Step 2. Select the second option Create forward and reverse lookup zones (recommended for large networks).

Step 3. If a forward lookup zone does not exist, select Yes, create a forward lookup zone now (recommended) on the Forward Lookup Zone page. Otherwise select No, don't create a forward lookup zone now and skip to Step 8.

Step 4. On the Zone Type page, select Primary Zone. Make sure Store the zone in Active Directory (available only if DNS server is a writeable domain controller) is checked.

Step 5. Select the second option, To all DNS servers running on domain controllers in this domain: to replicate zone information to the domain.

Step 6. Enter as the name of the DNS zone.

Step 7. Only enable secure dynamic updates.

Step 8. Now create the reverse lookup zone.

Step 9. Select Primary Zone again for the zone type. Make sure Store the zone in Active Directory (available only if DNS server is a writeable domain controller) is checked.

Step 10. Replicate zone information To all DNS servers running on domain controllers in this domain:

Step 11. Select IPv4 Reverse Lookup Zone for the zone name.

Step 12. Identify the reverse lookup zone with the following network ID,

Step 13. Allow secure dynamic updates.

Step 14. Allow your DNS server to forward queries and complete the wizard. If your router supports it, add your router as your forward DNS server. Alternatively you can add DNS servers provided by your ISP or use the ones from Google, and You can add more than one.

Once configuring DNS is completed, we like to add a new host record for our router R0. Add a new record for with the IP address to the forward lookup zone.