Windows Server 2012 Automation with PowerShell Cookbook: If you work on a daily basis with Windows Server 2012, this book will make life easier by teaching you the skills to automate server tasks with PowerShell scripts, all delivered in recipe form for rapid implementation.

Setting up a new Active Directory environment can be either exciting or boring. If you have rarely built out new domain and networking environments, the process is probably new and very exciting. However, if you are constantly building out new environments for test labs or other business needs, the process can be fairly long and drawn out. Instead, you are mostly interested in automating the process to require minimal user input and maintain consistency between builds.

This chapter covers the installation and configuration of Active Directory, DNS, DHCP, and Certificate Services. This chapter should cover everything necessary to prepare an environment as a fully functioning Active Directory domain for use in labs or new domain environments.

TCP/IP is the primary technology used for communicating between computers today. When first building out an environment, one of the first items to accomplish is to define and apply an IP addressing scheme. Once the addressing scheme is defined, we can create static addresses for our first servers. Later, we will configure DHCP in case static addressing is not desired for all of the systems in your environment.

Getting ready

From the following diagram we can see that we have already defined our addressing scheme using both IPv4 and IPv6. At the start of our network, we have a router acting as a default gateway, and we will configure two servers in preparation for becoming domain controllers. The default gateway router is already statically assigned with IPv4 and IPv6 addresses:

All three of these components are connected to a common Ethernet segment to communicate with each other.

Note

Before defining any networking configuration, we should confirm that our addresses...

Once the TCP/IP networking is set up and working, the next step to tackle is installing the domain controllers. In a Windows Active Directory domain, the domain controllers can be viewed as the core of the network. Domain controllers provide user authentication, group policy information, time synchronization, and access to Active Directory objects. Additionally, domain controllers often provide several network services such as DNS, DHCP, certificate services, and more.

This recipe will set up and install the first domain controller, creating a new domain in a new forest. Once completed, the second domain controller will be remotely installed and promoted. Additionally, we will install DNS on both domain controllers to provide name resolution services.

Windows domains rely heavily on DNS for name resolution and for finding appropriate resources. DNS is composed primarily of zones, each of which contains records. These zones and records provide name to address and address to name resolution for clients.

Here we will install and configure the DNS service and configure zones for servicing clients.

As an alternative to statically assigned TCP/IP addresses, Windows supports the Dynamic Host Configuration Protocol (DHCP). This service allows for provisioning of IP addresses, default gateways, DNS information, and even more advanced information such as boot servers.

This recipe will set up the basic DHCP features on a domain controller and configure an initial DHCP scope.

Prior to Server 2012, there were limited methods of ensuring DHCP was redundant and always available to service requests. One of the most common methods was to split DHCP scopes between multiple servers, with each server providing a subset of the scope. If one system was unavailable, the other system was still able to provide a subset of addresses. However, this caused problems because if a DHCP server was unavailable, there may not be enough addresses available to service all of your clients. Other redundancy options involved clustering or other expensive technologies that were difficult to manage.

In Server 2012 DHCP server failover is a built-in feature. This feature allows servers to share a common DHCP database to provide leases and provide redundancy. To use DHCP failover, the DHCP feature just needs to be installed and configured across servers. This recipe will walk through the configuration of DHCP failover.

While DHCP is an easy way to manage network addresses, especially, in dynamic environments, it does have its drawbacks. If something happens on your physical network or to your DHCP server, clients may not be able to receive or renew their addresses. And due to the dynamic nature of DHCP, addresses may change, causing issues with firewalls and DNS records.

This is normally fine for desktop environments, but in server environments, we want to minimize any possibility for an outage. As such, at some point you may want to convert your dynamically addressed hosts to use static addresses.

# Identify all adapters that recieved an address via DHCP
$adapters = Get-WmiObject -Class Win32_NetworkAdapterConfiguration...

Windows Active Directory domains are a great way to authenticate users and computers. Using a central store of accounts and passwords, requests can be easily authenticated, and accounts can be quickly added, updated, or removed as needed. While this is a great method for authentication within the domain, it does not work as well outside of the domain. Situations, where the domain controller may not be accessible, where the authority of the domain controller is in question, or when accessing resources outside of a domain, call for alternative authentication methods.

Certificates allow for creation of an authentication infrastructure by using a series of trusts. Instead of joining a domain, and thereby trusting the domain controllers, you trust a Certificate Authority (CA). The CA is responsible for handing out certificates that authenticate the user or computer. By trusting the CA, you implicitly trust the certificates it produces.

Windows server has the ability...

When working in a test or lab environment, it is useful to have a number of test accounts to use. These accounts can have different access permissions and simulate different types of users doing specific tasks. These AD users are normally made up of simple accounts with a common password.

Additionally, when setting up a new production environment, it may be necessary to populate users into AD. These usernames and e-mail addresses are predefined and the passwords must be unique.

In this recipe we will use a PowerShell script to create both types of users.

Getting ready

To use this recipe properly, you need an AD environment with credentials capable of creating user accounts. Additionally, if you want to create specific users, you will need a CSV file with headers of LastName,FirstName as shown in the following screenshot that contains the users to create:

Once your AD environment has existed for some time, finding and changing settings in your environment can become difficult. For example, let's say when the domain was first created, all the users had the same logon script named logon.bat. Over time, specific needs arose that caused the creation of logon2.bat, and new_logon.bat, and testlogon.bat, with different users assigned to each script.

As an administrator, you want to consolidate all these logon scripts into one, but you need to know what this will impact. You need to know which logon scripts are being used, who is using which ones, and why the different scripts exist. Thanks to the capabilities of AD and PowerShell queries, these items can easily be found.

In this recipe we will perform multiple queries against Active Directory. We will be returning different information.

As domains grow and change, one of the largest polluters of AD is expired machine accounts. Whenever a computer is joined to the domain, a machine account is created. However, when a machine is retired, the machine account is often left. There are no built-in tools to remove these machine accounts from the domain, and unlike user accounts, they are rarely audited. This becomes a problem as the environment grows, and auditing of the computer accounts becomes difficult.

This recipe will show how to search AD for expired, or nearly expired, machine accounts.

One of the questions I receive every time there is a security audit or review is How many super users are there? To find this out, I have to manually open up Active Directory and look at the membership of Domain Admins and Enterprise Admins groups. Once I have identified the users, the security team then wants a documented list of who has superuser rights, when they got them, and why.

If your environment is anything like mine, looking at the Domain Admin group membership will be very surprising. Even though we work hard to limit who has access, more and more users creep into these groups throughout the year. By the time they are identified, finding out when, why, and how they were added can be exceedingly difficult. What is needed is a method of keeping up on the changes as they happen.

In this recipe we will create a superuser report that reports on membership of these critical groups. This report will show which accounts are in each group, and even...