Companies around the world use Active Directory (AD) every day hosted on various Windows operating systems.

Windows Server 2019 is the latest in a long line of supported Windows platforms. Even if you don't have to manage
AD on Windows Server 2019 today, chances are you will at some point. In this course, Managing and Maintaining
Windows Server 2019 Active Directory Domain Services, you will learn how to maintain a healthy AD environment
in Windows Server 2019. You will learn how to not only manage AD objects like user accounts, computer accounts,
groups, organizational units and more, you will also learn how to maintain a healthy AD infrastructure. First, you will
explore how to create, modify, and remove user and computer accounts. Next, you will learn how AD accounts are
organized into groups and organizational units, and how to keep AD secure through password, service, and
authentication policies. Finally, you will discover how to ensure AD databases and critical SYSVOL data is never
lost. When you are finished with this course, you will have the skills and knowledge to manage Active Directory
objects and keep a Windows Server 2019 Active Directory environment in top-notch shape.

Course Overview
(Music playing) Hi everyone, my name is Adam Bertram. Welcome to my course, Managing and Maintaining
Windows Server 2019 Active Directory Domain Services. I'm a Microsoft MVP, blogger, freelance writer, and
consultant around various Microsoft technologies. Did you know that Active Directory has been around since
1999? That's a long time! It's still around and used more than ever by organizations worldwide now available to be
hosted on Windows Server 2019. This course is going to cover keeping up with Active Directory task, both from my
GUI perspective and PowerShell. Yep, you get to learn some automation, too. Some of the major topics that we will
cover include managing user and computer accounts, managing those user computer accounts as logical units with
groups and organizational units, ensuring your Active Directory environment remains secure with various passwords,
service, and authentication policies, and maintaining an Active Directory environment through replication
checks, regular backups, restores, and Active Directory database maintenance. By the end of this course, you will
have learned how to manage and maintain a healthy Active Directory environment your users will love you for. I hope
you'll join me on this journey to Active Directory bliss with this Managing and Maintaining Windows Server 2019
Active Directory Domain Services course at Pluralsight.

Course Introduction

Introduction

So you're studying for a Microsoft certification exam, or you need to get up to speed with managing Active
Directory. Either way, you're in the right place. Let's not chitchat and get right into this course on Managing
and Maintaining Active Directory hosted on Windows Server 2019. Meet Adam. He's the lucky guy that just had his
boss quit who previously managed the Active Directory environment. He's now been given the responsibility to
manage that AD environment. Reluctantly, Adam now has to learn to manage AD environment himself. Throughout
this course, you'll get a glimpse into what Adam's day-to-day life is like and how he's managing to maintain his new-
found responsibility. For this course's lab, we'll be working with Windows Server 2019 VMs. We have two domain
controllers called DC1 and DC2. These are both hosting a single forest and domain. We'll also be working with a few
Windows 10 machines here and there. We will add and remove these as necessary to the domain and will manage
them in various ways. I highly encourage you to check out Greg Shield's course on Installing Windows Server
2019. You'll need these skills to bring up your Windows Server 2019 domain controllers needed to follow along with
this course.
Creating and Managing Active Directory Users and Computers

Introduction

So let's get down to business and start to jump into the demos. In this module, we're going to cover many facets of
managing AD users and computer accounts. You're going to learn how to create change and remove user accounts via
the GUI and automate all those processes with PowerShell. By the end of this module, you'll have the skills required
to manage even the largest batches of users and AD computers. To follow along with the demos in this module, be
sure you already have a Windows Server 2019 DC set up and a Windows 10 machine available. If you'd like to run
through the domain join process with me, that Windows 10 computer should not be domain joined. When managing
AD via the GUI or PowerShell, you've really got two options. You can either remote desktop into a Windows
Server 2019 domain controller with a GUI, or you can install the remote server administration tool's package. This
package can be installed on Windows 10. It allows you to manage your domain just as if you were on the
domain controller and really is my recommended way of managing AD. On a domain join Windows 10 build 1809
computer or later, that's important, you need to make sure you have the latest version of Windows 10, click on Start
and then go to Settings and then click on Apps. Now, click on optional features, and then click on add a feature. Scroll
down a little bit until you get into the RSAT features where you'll see quite a few here. For AD, you'll need to install
the RSAT Active Directory Domain Services and Lightweight Directory Services Tools feature. Go ahead and click
on that one, and then on Install. Now click the back button, and you'll then see the installation progress of the feature
going. That's all there is to it. Once that's done, you should now have the AD management tools installed. You're now
ready to begin managing AD remotely.

Create a User Account from Scratch with Active Directory Users and Computers

One of the most common tools you use when managing AD is via the Active Directory Users and Computers Tool, or
ADUC for short. ADUC is a tool that allows you to manage user accounts and a whole lot more. We'll be covering a
lot in this course. To open up ADUC, I'll go here to the Start menu, go ahead and click ADUC, and then you'll see two
window panes. On the left is the domain tree. This is the domain at the top, along with the containers and
organizational units. The organizational units are also known as OUs. We'll cover those a lot in this course as well. To
create a new user account at the root of the domain, right-click on the domain, hover over New, and then choose
User. In the later modules, you'll see how you can create and move computers between OUs and containers. You'll
then be presented with a typical wizard. The wizard will walk you through adding all applicable attributes to the user
account. I'll go ahead and create Donna Jones' account by simply filling in all of the applicable fields. Notice that the
user logon name here has the domain name. If I were in a multi-domain forest, I'd have multiple options here, but
since I only have one domain set up, I'll just go ahead and leave this as is. Then I'll click Next. Here is where I can
assign the password and other options. I'll go ahead and assign a password that adheres to my domain's password
policy. So at this time, I could change options like if the password shouldn't expire, disable the account when it's
created, and so on. Typically when creating a standard employee account like this, you want to force the user to set
their own password. So I'll go ahead and leave the User must change password at next logon enabled. I'll also go
ahead and leave all the other options unchecked because I do want the password to expire according to my password
policy. I want the user to be able to change the password at any time and I want to enable the user account when it's
created so the employee can begin using the account immediately. You can go ahead and review the options selected
here on the last screen. If you're okay with that, go ahead and click on Finish. You can see the user account is now
shown in the right pane labeled as first name, last name. Notice that I already had an account created in this view
called Janice Helmick. This is another employee account. If you need to modify multiple accounts at the same
time, you can hold down the CTRL key to select multiple accounts, right-click, and then go to Properties. You'll then
get a box that coincides with all of the attributes you'd like to set on all of the user accounts that you have
selected. You'll see that you've got lots of options here. You can select the description for all of the accounts
by checking the box and inputting a description. The same could be done for the office attribute or really any of
them. You can then navigate to other tabs to explore other options such as account, address, profile, and so on. In each
tab, you'll find numerous attributes you can assign and edit in bulk. I'd just like to look at the user account I just
created. Here you can see similar tabs, but a lot more. Not all tabs are supported to modify in bulk mode. Notice that
there are lots of options here that we didn't really get the chance to add when the user was created. To assign attributes
like the office, the employees, for example, you must set these attributes after the fact like we're doing here. To
change the office, I'll just simply add the office name in the office field. I could click through some of these other tabs
to discover other attributes if I wish. But for now, I just need to change the office attribute. After I'm done, I'll click
OK, and now I've created a new user account with ADUC.

Create a User Account from Template

Using an existing AD user as a template, we can make copies of a template user to save time when creating new
users. You can see here that I'm in ADUC, and I have a computer account created called HR Employee
Template. This is a disabled user account that's only used to create new users for the HR Department. When I look at
this user, notice that I have placeholders for many of the fields. All these fields will be overwritten when a copy is
made. The only ones that are not placeholders here are the department and manager fields. Unfortunately, when you
make a copy, not all of the attributes are copied over, but these are the most common ones that are. HR just hired a
new employee, George Shields, and opened a ticket to create a new AD user account, so I'm prepared here. I'll right-
click on the HR template account and choose Copy. I'll then fill out the user information like first name, last name,
and user logon name. Next, I'll click Next, and I'll provide a password. Since the template account was disabled and
set to password never expires, I need to uncheck those since this will be a live account. I'll also ensure George must
reset the password when first logs in. Now you can see the account has been created. Looking at this account, notice
that the department and manager attributes are the same as the template. I didn't set these manually. Creating a copy of
the user account brought these two attributes over, so I don't have to worry about defining them myself. This is one of
the big benefits of using templates.

Create a User Account with Active Directory Administrative Center

Microsoft has a newer GUI tool called the Active Directory administrative center that you can use to manage many
aspects of AD as well. On your Windows 10 domain join computer, with the RSAT tool feature installed, go ahead
and go to Start and you should see the ADAC. Click on it, and you should see a pane on the left similar to ADUC that
shows the domain name. Right-click on that, hover over New, and then click on User. This will bring up a much
bigger and more thorough new user interface than what ADAC does. You'll immediately notice you've got a lot more
options here to set. You can set all the user attributes that you get from the get-go without really modifying any of
them after the user is created. Let's create an employee account called Toni Warner. Toni is an employee in Adam the
Automator LLC and is located in Atlanta. I'll go ahead and add some central attributes in here. Now that I have some
basic attributes added, I can begin looking at some of the other options. For example, notice that in this interface, I can
not only define manager, but I can also assume Toni is a manager himself and give him direct reports. This will not
assign attributes to his account, but actually do the employee user account that Toni manages. I can browse user
accounts by clicking on Add. Here I can either type in the user account separated by a comma if I wish. Notice that if I
click on Add here, that same box comes up. This is a common account picker-box. I'll click on this Advanced button
here, and then on the Find Now button. This lists all the user accounts that are available for you. You could narrow it
down by username here in many different ways also if you wish. Scrolling down a bit more, you can also see how to
define fine-grain password policies and authentication policies in silos, which we'll cover later. When you've added all
the attributes, click on OK. You can then see the user account by clicking on the domain and then noticing the user
account in the right pane.

Create a User Account with PowerShell

When you created a user via the ADAC or ADUC tool, notice that it added attributes by default. You didn't explicitly
specify some of these attributes; it just went ahead and did it for you. During the introduction, you installed the
Remote Server Administration Tools feature, or the RSAT. A PowerShell module that you need to create user
accounts and manage AD came with that feature. It's called the PowerShell Active Directory module. The Active
Directory module contains hundreds of commands that allow you to manage AD. In this first PowerShell demo, we'll
be using a command inside of the module called New-ADUser. So let's over to the PowerShell ISE script editor now
and I'll show you some of this PowerShell code. You can get information about the Active Directory module using
the Get-Module command and the Get-Command command. There are quite a few commands available you can see
here. You'll use a lot of these eventually. One we're going to use today is New-ADUser. We'll use this to create an
account with attributes that you see here. Just to show you how much the GUI tools help out, for now I'll just run
New-ADUser with a minimum number of parameters. I'll now open up this user account in ADUC. Now notice that
the user account is disabled. When I open it up, notice no attributes are on the General tab, nothing is under Address,
and no user logon name under the Account tab exists. Organization is also empty. To populate all of these
attributes, you need to provide various parameters to the new AD User cmdlet as I've done here. Many of these
cmdlets should be self-explanatory. But the parameter names don't always match up 1:1 with the fields you see in
ADUC. The only semi-complicated one is the AccountPassword parameter. For security reasons, PowerShell doesn't
allow you to pass a plain text password to the AccountPassword parameter. Instead, you must convert it to a secure
string. You can do that by using the ConvertTo-SecureString command I've done here. Also notice that I've used back
ticks as well after each parameter. This allows me to specify one parameter per line, so the line doesn't wrap all the
way around to the right of the screen. Once I've gotten all the parameters defined, I'll then highlight the command and
all the parameters since I'm in the PowerShell ISE code editor and then go ahead and run them now. Once I do that,
I'll go back over to ADUC, I'll refresh Users container. This is the default container PowerShell places accounts
in. You'll now notice no arrow indicating the account is disabled. It's enabled since I use the enabled parameter. Now
going into Properties, you'll see that all of the typical properties the GUIs set for us are now defined in their user
account. Those are there because we define those specifically via those parameters on the New-ADUser command.

Modify Active Directory User Accounts

You've created a user account, but there's ultimately going to be a time when you need to change them once they're
created. There are a few ways to do that. First is through the Active Directory Users and Computers Tool, or
ADUC. You can see here that I have ADUC open. To modify user account, I'll simply double-click on it to get to the
properties and change a few fields. All of these fields are writable that you see here. Jane Helmick just joined the
group at Atlanta. I can set office attribute to reflect that. Maybe I forgot to add email. I can easily change that here as
well and hit Apply to commit the changes to AD. I can also click on any other tab in this Properties dialog and change
that such as the city under the Address tab. I can also make changes to user accounts in AD Administrative Center, or
ADAC. I'll go ahead and over here and I'll navigate to the Jane Helmick user account. I'll then double-click on it to see
the properties. I could right-click and go to properties as well. Here you're seeing the same attribute, just in a different
way. Everything in the ADAC is on one screen, unlike the ADUC, which has multiple tabs. Maybe I need to remove
department and thus the manager. I can easily edit each of these fields, click OK, and the change is made. Finally, one
last way to change the user account is with PowerShell. I first need to see if I can find the user account. To do that, I'll
use the Get-ADUser command. If I don't receive an error, as I've done here, looks like it worked. I want to change the
department, but notice that there's really no department shown here. By default, the Get-ADUser command doesn't
return all of the attributes. To do that, we need to specify the properties parameter with an asterisk at the end to see
them all. When I do that, you can see that there are a lot more properties shown now. If I scroll up a bit, I'll eventually
find the department attribute to set to IT. Maybe Janice Helmick decided to make a department change to HR. I don't
know, it happens. We need to change that. To do so, I can use a concept in PowerShell called piping. I'll pipe the
object return from Get-ADUser to the Set-ADUser command. This tells PowerShell that I want to input the user
account to set ADUser that Get-ADUser returns. And I'll also tell PowerShell with the department parameter that
I want Janice Helmick to be in the HR department. I can use the Set-ADUser cmdlet directly, too. This time, since
Set-ADUser isn't receiving information from the Get-ADUser, I'll need to use the identity parameter and provide the
username here. This is followed by one or more parameters indicating the AD attribute to change. Maybe I want to
limit this user's ability to change his password. I'd like to change the department at the same time. That's not really a
problem. I simply use the department and the cannot change password parameter. Now I'll open up ADUC and find
the user. Now notice that ADUC shows the attributes we just changed with PowerShell.

Remove Active Directory User Accounts

In ADUC, it's easy to remove a user account. Just right-click. We'll remove George Shields here and select Delete,
and then just click on Yes. It's really that easy. In ADAC, there are two ways to delete a user. Just like ADUC, you
can right-click and delete, but you can also go over to the Tasks tab and click on Delete there. Like in ADUC, you'll
be asked for confirmation. Now let's take a look at PowerShell. We can use get-aduser to make the user exists, but we
can also use it to pass the information to the remove-aduser cmdlet to remove the user account. By default, you'll be
asked for confirmation. But you can use the confirm parameter and set that to false to turn that off if you'd like. And
then we'll just double-check to make sure that it worked using get-aduser again. And now you can see that we get an
error. We get that error because that's good because the user isn't an AD anymore. You can also use the remove-
aduser command by itself. Just use the Identity parameter here with the account name as a value. Once I do that, of
course, confirm that you really want to delete it, and it's gone. That's really all there is to removing AD user accounts.

Add Computers to Domain with an Online Join

Whenever a new computer is added onto a domain, it will automatically come up in Active Directory Users and
Computers as a computer account. You can see here I'm in Active Directory Users and Computers, and in the
Computers container. You can see there are no computer accounts at all created. Let's change that. So I'm now on my
Windows 10 computer that I want to add to the domain. To do that, I will go down to the Start menu. Go to the
Settings app. Once that's open, I will go to System, then I will scroll down and go to About. Now this is where you
would normally see an option to join the computer to a domain. However, the option only shows up if you are logged
in as the local administrator account. I'm logged in as a local administrative account, not the actual local
administrator, so I can still add it to the domain; I just cannot do it here. So, to add it to the domain as a general local
administrative account, I will go ahead and close this out and go to my Start menu again and type in Sys and then go
to the System Properties. Once I do this, I will go over here to Change settings underneath Computer Name, Domain,
and Workgroup settings. Once I do that, I can click on Change here. This is where you can rename the computer and
also add it to the domain. So to add it to the domain, I will select Domain, type in my company domain that I
have, and then you should get prompted for a username and password. This is where I will provide my domain
administrator username and password. However, any user account can add up to 10 computers to the domain. All
right, once I do that, I'll get the message Welcome to the domain. Click OK. Click OK again to accept the prompt,
Close, and Restart. The computer will always need a restart once it's joined to the domain. So now that computer has
been restarted, now let's check and see if it actually is. Let's verify that it actually is a member of the domain. To do
that, I will go over here to the Start menu again, go to the Systems Properties section, and then now you can see the
full computer domain is not just MYDESKTOP; instead, it's MYDESKTOP.company .pri, and then you'll see the
domain is company.pri. You can also confirm that by going over here to change settings again. You can see the full
computer domain and the domain in there as well. So that's how you add a Windows 10 computer to the domain via
the traditional online method. All right, just to verify that the computer account was created, I'll come back over here
to Active Directory Users and Computers, and now you can see that the MYDESKTOP computer account is in the
computers container. So it did successfully get added to the domain. Next up, let's now dictate where that computer is
added in a domain. So back by default, you'll notice that it did add it to the computer's container. However, whenever
you add a Windows 10 computer or any computer, for that matter, to a domain, you can actually make it show up in a
particular organizational unit or OU of your choice. So notice here that I have an OU called IT. A new IT department
employee has been hired, and I would like to add his machine to the domain. I would like to automatically add it into
the IT OU. To do that, I will create a new computer account. I can right-click IT, go to New, and then click on
Computer. Here's where you specify the computer name. Now, the computer name has to exactly match what the host
name of the computer which you will be connecting to the domain. In this case, my computer name is just
USERDESKTOP, and once I add that, I'm going to click on OK, and you can see the computer account has been
created inside of the IT OU. All right, so once it's created, now I need to go to the USERDESKTOP computer and
then add that to the domain and we'll see what happens here. All right, I'm now on the USERDESKTOP
computer, and just like before, I will go to the System Properties and add this computer domain. We'll go ahead and
speed through this process fairly quickly because you've already seen this process. Now it's restarting. It should be on
the domain when it comes back up. Now let's verify if Active Directory sees that computer account. Now we can go
over here and you can see that if we wouldn't have pre-created a computer account, it would show up in the
Computers container. However, you can see here when I refresh this, USERDESKTOP does not show up in
Computers container. However, when I go over here to the IT OU, it's still here. It's not abundantly clear if it actually
got created on the domain, but since it did not get created in the Computers container, it will have been associated
with this computer account in the IT OU. All right, now for one final way, let's learn how to online domain join a
computer with PowerShell. I have another computer, and I will go ahead and go over to the console of that. I will go
ahead and open up a Windows PowerShell session. And once I do that, I will just hit hostname to show you this
computer account is USERDESKTOP2, so we have not added a computer account for that yet. All right, to add the
computer to the domain, I will use the Add-Computer cmdlet. I will provide it the domain name of
company.pri, which is the fully qualified domain name of the Active Directory domain I'm working with. And I'll
provide a credential, which this is the same username and password which you used before which has access to add a
computer to the domain. To do that, I will use my abertram domain administrative account like I did before. Then I
will choose Restart because I could manually restart this after the fact. I just want to go ahead and just restart this all
in one shot. And then I'll also use the Force parameter here to ensure we don't get prompted for any additional
confirmation. All right, let's hit Enter. Now you can see that it prompts me for my password. I will go ahead and put
that in. And then you will see the computer will restart just like before. Now I'll head back over to Active Directory
Users and Computers, refresh my computer container, and now you can see that the USERDESKTOP2 computer
account has been created. So that concludes this demo where we added an online computer to the domain in three
steps. We joined the computer to the domain with the common method of using the system properties in Windows
10 without pre-creating computer account. We then pre-created a computer account and joined the computer to see
that you could assign that computer account to an OU while the computer has been created. And finally, we used
PowerShell to make it happen.

Remove Computer Accounts from a Domain

Now let's look at several different ways to remove a machine from Active Directory. There really isn't a right or
wrong way here; it's just different ways to accomplish the same task. Let's first start out with ADUC. All you need to
do is right-click on a machine and choose Delete, click Yes, and you're done. If you go over to ADAC, it's just about
the same. Right-click, and you can delete or you can go over to Tasks and select Delete that way. And, of course, just
go ahead and click Yes to confirm. If you want to remove the computer account from Active Directory via the
machine itself, which disjoins the machine, you can use PowerShell or the GUI. Let's look at PowerShell first. Here
I'm on a Windows 10 Pro machine at the PowerShell console. The cmdlet to use is Remove-Computer. To use this, we
just need to run this and provide a valid credential, a valid username and password that has permission to remove this
computer from the domain. Once done, I will need to restart the machine because that is required to join or leave the
domain. I'll go ahead and do that with the Restart-Computer cmdlet. And finally, let's remove it via the GUI. This is
the same machine as before. I've already added it back to the domain. So, we go to the same place as we did to add the
machine, but this time we'll select workgroup and enter a name. Then just like we did a moment ago with PowerShell,
I'll go ahead and reboot. One important thing to be aware of is that when you remove a machine from the domain, you
aren't actually deleting it from Active Directory. So you should now know how to remove a machine whether you like
to do it via ADAC or PowerShell.

Configure User Rights

The Default Domain Policy doesn't have any user rights assignments configured as first, but we can certainly change
that. So I've got the Group Policy Management console open here, so let's navigate to user rights. To do that, I'll right-
click on Default and click Edit. Now I'll go into Policies, Windows Settings, Security Settings, Local Policies, and
then finally you'll find the User Rights Assignment section. As you can see, everything is set to Not Defined right
now, which means this GPO, in this case, the Default Domain Policy, won't change how anything is set up on your
machines. But if you want to change something, here it will affect every user in your Active Directory domain. This is
the place to do that. For example, you could give the user the right to change the time zone or system time on
machines, or maybe you'd like to deny the right to connect to a machine using a remote desktop. You could even
change who's allowed to shut down a machine. You can change all kinds of user rights in this section here. So, keep in
mind, though, that all of these settings are also available in standard DPOs. Generally speaking, it's best to leave the
default domain policy alone and make any changes to policies in GPOs that you would create. That will allow you to
name the GPOs and organize them based on what makes sense to you, and hopefully anyone else that may be working
in your domain.

Implement Offline Domain Join

Offline domain joining is a two-step process. First, you run the command on a machine that's on the domain as
an admin with rights to add machines to the domain. Then, you run it on the offline workstation to actually add to the
domain. Let's see how this works using a Windows 10 Pro machine that's on my domain here. You can see that I'm at
a PowerShell console and the command we're running is djoin. We'll tell it we want to provision, which creates a text
file needed by the PC that we're going to join. We're going to provide the domain name that we want to join, the name
of the machine that we want to have join the domain, which we will run on here in a minute, and the location and
name of the text file we'll be taking to that offline machine. Once that's done, we should be able to see the machine in
ADUC. Let's go take a look now. Here you can see the ADUC console, and if I go to Computers, you'll see the
abertram PC is listed. Next, we need to take that text file to the offline workstation. Now let's go to a PowerShell
console and run the command. Doesn't necessarily have to use PowerShell; it could be the cmd Command Prompt, but
I'm just using PowerShell in this instance. This time we'll use the request to domain join option. I'll then point it to the
file we created earlier, tell it where Windows is installed, and then localos to let it know we want to add the OS right
now, not an offline image. And that's it. The machine is now a member of the domain. Keep in mind, though, that you
won't be able to log onto the domain until the machine can contact a domain controller so that it can be authenticated
at least once. That's all there is to offline joining. The same command, djoin, used in two different places.
Automate User Account Lockout Maintenance

User accounts get locked for a few different reasons. As an admin, it's up to you to unlock them for your users. Let's
take a look at how to do this in ADUC and with PowerShell. In ADUC, there are two different places you can unlock
account from. If your user has forgotten their password, you can right-click on their name and then go to Reset
Password. Then notice here near the bottom saying their account is locked out. And by default, the unlock box will be
checked here. If you don't want to change he password though, you can right-click and go to Properties, and then the
Account tab. Here you can also see that the account is locked out, and you can check on the unlock box, and then on
OK to unlock the account. And just to confirm, we can look at the password reset option here, and now you'll see that
the account is unlocked. Now let's look at how you can automate this process with PowerShell. We'll open the
PowerShell console and check for any locked accounts. We'll do that with the Search-ADAccount cmdlet. I'll then
want to unlock all of them. As you can see, unlocking accounts is much faster here, especially when you have more
than one to unlock. Let's take a quick check in ADUC just to confirm one of the accounts is unlocked. And there you
can see that it is. Now that you know how to unlock accounts in a couple of different ways, you should have no
problem dealing with the inevitable account lockout that all admins have to deal with.

Automate Password Resets

Passwords can be reset in several different ways. We're going to look at ADAC for one user, and then we'll use
PowerShell for both one user and we'll go ahead and automate that for a lot of users. Let's start with ADAC. To reset a
password here, you would right-click on the username and then select Reset Password. Enter the new password
twice, and then decide if you want to force the user to change the password when they log on. If the account is locked,
you can select to unlock it here, too. Now let's switch over to a PowerShell console. Here we can use the Set-
ADAccountPassword command. We need to specify the account name, the new password, and reset it to let it know
that we want to reset the password. This is not going to be a new password where we need to reset it. We're using the
Read-Host command here to receive the password input. This will tell PowerShell to ask us for the new
password. We're reading it as a secure string too because that is what the parameter on Set-ADAccountPassword
requires. So we'll go ahead and run this, and I'll enter the password. Notice that we don't get any errors, so it did work
as expected. We reset the password. And, finally, let's look at resetting lots of passwords at once. We can set 1, 10, or
100. We can automate this process. For this, I'll go ahead and go over to the script console here, and first up on line 4,
we'll generate a password. This password is set to 24 characters long and 4 special characters. But, of course, you can
set that however you'd like. And then just to show you it worked, we'll show you the password. Now on line 9, I'll
show you the code to convert it to a secure string. Line 11 is where we really get started, though. This is where we
take everything we showed you above and put it into a for each loop. We've only listed two users here, but you can
make this as many as you want, or even pull in accounts from an array or a file. On line 14, we're displaying a
message with the Write-Host command. We're doing that just so you can see things are working correctly. And then
on line 15 is where the passwords are actually changed. Let's run this and see what happens. And there you go, the
two listed accounts have had their passwords changed. This is how you can change many different passwords at one
time. As an administrator, you'd almost certainly be resetting passwords more than you'd ever want to. Now that you
know a few different ways to do it, hopefully it won't quite be as annoying the next time.

Manage Inactive and Disabled Accounts

I can use PowerShell to query AD in many different ways. One way is to find out which accounts may not be used
anymore. In this demo, Contoso has as problem with accounts going stale. I'd like to discover and clean those up. It's
important to limit my search to accounts that have set a password at least once; otherwise, I might accidentally remove
new accounts that were just going to be set up. On line 6 here, I'm setting a password age limit. You need to modify
this to match whatever your company policy is. I'm setting it very low in this demo because my demo environment
hasn't been up and running for very long. Here on line 7, I'm finding the date which is 60 days ago. Then on line 8
through 12, I'm querying AD to find all the accounts that haven't had their passwords set in 60 days. This will give me
all of the user accounts that I'm going to label as stale. Now on line 16, I'm going to disable those unused accounts
because I like to give myself a little wiggle room just in case. I shouldn't really delete them yet. We need a manual
review process. Now because I don't necessarily want to remove these just yet, I'm piping the results obtained to Set-
ADUser. This is where I'm disabling all of the accounts. Now let's assume some manual review time has passed and
all of these accounts have been deemed deletable. If I know all of the disabled accounts are indeed deletable, I can use
the Search-AdAccount command to find all of the disabled user accounts. When I do that, I could then pipe those user
accounts to Remove-ADUser to finally remove them completely. Notice that I have two options here. The first option
I'm going to ask if I really, really want to delete each user. This really is the safest option, so I'll just go ahead and do
that and I'll just show you what that looks like. On line 22, I'll use Remove-ADUser, which will prompt me for each
and every one. If there are only one or two accounts, getting prompted isn't a bad idea, just as a double-check to make
sure they really should be deleted. And here's a good example. This is my account, which I don't want to delete. And
this error here shows what would happen when you try to delete a built-in account. You can't do it. On line 25 here,
I'll just set it to delete them without asking for confirmation. While a little riskier, this is what you want to do if you
have a large list. Nobody wants to accept a prompt over and over and over again. I'm not going to run this one,
though, because it will try to actually delete my account, and I don't necessarily want to do that. Now let's take a look
at the same workflow, but for computer accounts. Just like before, I'll define a number of days and find the
daysAgo. Then I'll use Get-ADComputer and filter out all the computer accounts that haven't been used in 60 days. I'll
then disable any machines that are too old. Then I'll use Get-ADComputer again to find the disabled computers and
I'll use Move-ADObject to move them to an OU that I've already created called Disabled Computers. This gets them
out of the way without actually deleting them yet. Here you are free to perform whatever workflow you need. You
don't actually have to move them to a different OU, you could disable them, delete them, whatever you'd like. And
finally here where this will be run later, maybe a couple weeks, you would go ahead and delete those unused
machines, and just like before, if you add a Confirm false to the end, it won't prompt you for each deletion. Now you
should know how to create a list of accounts on computers based on age. You can keep your AD nice and clean, easily
removing all of those outdated and unused accounts.

Sync Users from a CSV

Now let's take a look at how we can sync Active Directory users from a CSV to Active Directory. To do that, we'll
write a PowerShell script to do the work for us. Let's start by taking a look at the CSV file itself. It's important to
know what information is in there so you can write your script correctly. It wouldn't really do much good to acquire a
phone number, for instance, if there isn't one in the CSV file. As you can see here, there's not too much information in
here, but the file does have a line with a header so you don't need to guess what each of those fields. There are some
common employee attributes in here. Now, let's open up the PowerShell ISE and take a look at the script we're going
to be running. We've got a few prerequisites listed at the top here. If your OUs are different, just go ahead and change
them in lines 27 and 42. On line 16, this is where we import the file using the Import-Csv command. This is what
brings it into memory and to PowerShell. And then on line 18, we start looking at the data. First, we check to see if
the user already exists in Active Directory using the Get-ADUser command, and if not, we set the required parameters
on it. Based on the CSV file, csvUser variable here is what is represented by each row in that CSV file. Once we
define all the required parameters, we can then run the New-AdUser command to add the new user to
Active Directory and then we'll use the Add-AdGroupMember command to add them to the group information based
on their new AD account. So, for example, in this instance, we're assuming that the department is an Active Directory
group, and finally, we check to see if the computer name already exists. If not, we'll use New-ADComputer to go
ahead and add it that way. Now let's switch over to ADUC and to make sure that our users and computers are there. If
we look in the Computer Users OU, we can see our users were successfully added. Notice the down arrow there next
to them, though. That's because we created these accounts without passwords, and by default, accounts without
passwords are disabled. If we check the company's computer OU, our machines are there. Everything worked as
designed. And finally, if we go back to the PowerShell ISE again and run it again, you can see that our script just tells
us that these accounts already exist, so you can run this script over and over and over again. It's not going to try to
create duplicate accounts. You will, of course, need to make some minor changes to this script to match up to your
Active Directory structure, if you ran this in your own environment. But hopefully you can see now how easy it is to
add a list of users and computers to AD using PowerShell. PowerShell really makes it a lot easier to sync employees
defined in a CSV file or really any data source for that example directly to your Active Directory environment.

Creating and Managing Active Directory Groups and Organizational Units (OUs)

Introduction

You've now seen what it takes to manage user and computer accounts in Active Directory. Let's now get into
organizing and managing the accounts in bulk by adding them to groups and organizational units. In this module, we'll
first get into containers and OUs. Containers and OUs are ways you can manage AD objects as one unit. Groups are a
similar concept where you can manage objects as one; however, groups offer more AD features you need to know
about. In this module, we're going to cover managing members inside of those groups, scopes which comes into play
when managing multiple domains in a forest, and converting groups between scopes. We'll then dive into assigning
permissions for others to help you manage both groups and OUs with AD's delegation wizard. And finally, we'll finish
up with some PowerShell and show you how to automate some typical AD group tasks.

Manage Default Active Directory Containers

When you install AD, it will come with various containers. Now, not to be confused with organizational units or
OUs, containers are a way to segment out various objects in the AD. By default, no user accounts will go into the
users container and computers will go into the computers container. There's not to managing these default containers,
to be honest with you. You can't modify or remove them, but we can force new accounts to go into an OU instead. So,
I'll use ADAC here and right-click, choose New OU, and I'll just call it Company Computers. We're going to use this
as a new default OU when computers are added to the domain. Now that I have that, let's go over to PowerShell to
change the default. The command is actually an old command-line utility here. It's really not a PowerShell
command, so technically you could run this in a Command Prompt, just I choose to use PowerShell for just about
everything these days. I'll go ahead and do users first. To do that, I'll run the redirusr command. To use that, I just
need to provide the distinguished name of that OU. The command for computers is almost identical. It's called
redircmp.__ To do that, I'll just provide the same information as before, except the OU this time will be company
computers. I'm just choosing to put the user accounts and company users and the computer accounts and company
computers. Now that those defaults have changed, all new user accounts and computer accounts that are added will by
default go to these new OUs.

Manage OUs

Organizational units, or OUs, are how you can keep AD organized. Each OU can contain users, computers, groups, or
even other OUs. Let's go into ADUC and look at how this works. Now this works the same way in ADAC, so I'll just
stick with ADUC for this demo since it's more common. To create a new OU, I'll just right-click and then click on
New, and then OU, and then I'll enter a name. Now, notice a checkbox here. This checkbox is on by default. This
makes it harder to delete an OU. If this is checked, even those with permission to delete this OU will get prompted
and we'll have to manually disable it. It's really a nice safeguard. To show you how this works, I'll now try to delete
this OU. Here you can see the message saying I don't have the ability to delete it. But what if I really do want to delete
it? To do that, I would first have to enable advanced features. I'll click on View at the top menu bar, and then on
Advanced Features. Then I can right-click the OU and go to Properties. Now you can see the Object tab. I now can
uncheck the protect box and click OK. There's really no way you'd do that by accident. Now I can right-click and
delete the OU if I want to. I also mentioned earlier that OUs can contain other OUs. Let's demonstrate that. I'll go
ahead and create a couple here so you can see what I mean. By nesting one OU inside of another, we can keep things
organized, and I can make it easy to find AD objects when we need them. If at some point we decide to attach a GPO
to the parent OU, that GPU would then also apply to all the objects in those child OUs. Now you should know how to
create, delete, and organize your OUs.

Manage Groups

In ADUC, it's pretty common to keep users and computers in the same OU. But if you prefer to keep them separate,
you certainly can. I'll be keeping them in the same OU this time because I find it easier to manage them this way. To
create a new group, I'll right-click on the OU I want that in, click New, and then I'll click Group. Here I'll enter the
name and pick the type. Security would be for user rights if you're assigning user rights, and distribution would be for
email lists. And then you'll be able to decide on the group scope. This group's mission will just be for the local
domain, globally for any domain, or universal for any domain or forest. And now if I open that new group, I can add
in some more details. On the General tab, I could enter a description here and some notes about the group, which can
be useful if this will be seen by other users that may not know why I created this group, for example. If this was a
distribution group, the email address would show here, too. On the Members tab, here I can see a member list. This is
a new group, so, of course, it's empty. On the Member Of tab, I can make this group a member of another group
allowing us to nest groups inside of each other. This can be very useful when setting up permissions. This allows you
to easily assign higher-level groups all of the permissions that lower-level groups should have. You don't have to
assign each permission individually this way when you've already done that for the other group. And the last tab here,
Managed By, let me add a user or group as a manager of this group. We'll talk about that in another section. Once
you've created a group, you can now easily move it to another OU by simply dragging it over, or if you'd prefer, right-
clicking and choosing Move. And now you notice there is a Delete option here as well, making it very easy to delete
the group. We can now do all these things in ADAC. Go to ADAC, right-click on New, Group, and then aside from
just a slightly different look, it's all the same information here, which really makes sense because ADAC is just
another way of looking at AD. You should now be able to create groups, add and remove users from groups, and
move groups to whatever OU you would like them to be in.

Manage Group Members

A group of permissions can get confusing. When you only have two or three groups, it's not too difficult to figure out
what's going on, but the more groups and users you add, the more confusing it can get. For instance, if I go into my
PowerShell console here, I can run Get-ADGroupMember to find members of my IT group. I'll pipe this output to
format table at aliased as the ft here to just return the names. This shows the members, and in this case, it's the IT
group. If I knew that the IT folks didn't belong here, I could remove them. Another way of checking permissions is
from the user side of things. Maybe I've noticed that one particular user seemed to be getting into things that he
shouldn't, or maybe a manager was having some trouble with an employee where they shouldn't need to. They've
asked me to limit their access. I can check a user's group membership with the Add-ADPrincipalGroupMembership
cmdlet. I'll need to spy the username here, and also I'll pipe this to format table again to make it a little bit easier to
read. Now I can see every group that this user is a member of. If this user shouldn't be in one of these groups, I can
remove him. Now this doesn't show me if he's also a member of any other group. We need another way to find this
information. To do that, we can use the Get-ADUser cmdlet using the Filter parameter to limit user accounts only to
accounts that are in the group, let's say, called IT. You can see that I have to specify the entire distinguished names for
the groups when using this method. Now this gives me a list of every user in AD that is in that secure group. If I see
someone that doesn't belong, I can start troubleshooting and trying to figure out why they are in there. Groups are a
handy feature in AD that can make your life much easier. You should now know how to manage the members in those
groups with PowerShell.

Manage Group Membership Using Group Policy

You've learned how to manage group memberships through ADUC and ADAC and PowerShell, for that matter. Let's
now cover one more way through Group Policy. Managing group members through Group Policy ensures group
members always stay that way. A GPO targeted to an OU enforces changes happening again every time your GPOs
refresh. So, it's a good way to make sure that members don't get moved around incorrectly. To do this, I'll open up the
Group Policy Management Center, or GPMC, and go to our Default Domain Policy. I'm going to use this one because
I'll be using restricted groups, and those can only be configured on a GPO attached at the domain level. You could, of
course, create a GPO and attach it here, but for this demo, I'll just go and use the default policy. The setting I'm after is
under Policies, Windows Settings, Security Settings, and Restricted Groups. Now, keep in mind that this is an
enforced option, so if I add a group here with a name that already exists in AD, that old one will be overwritten and
this one will take its place. So before putting anything in here, it's a good idea to double-check your current
group names to ensure you don't overwrite one. Once you do create a group, because the members listed here are
enforced, it can be a little difficult to add new members. What you might want to do instead of putting users in here to
put it in a standard, not a restricted group. Then you can add and remove members of that group right in ADUC
without ever having to come back here and edit a GPO and wait for this to be applied. You may not use restricted
groups very often, but now you should know where they are and how easy they are to set up.

Configure Group Nesting

Now let's learn how you can nest groups. Group nesting is a concept that allows you to put other groups inside
of other groups between various domain local groups or domain local groups in global security groups; it just
depends. There's a lot of different scenarios here, but in the end, what's possible is that it allows you to apply
permissions, group-based-level permissions, at a higher level. So let me show you what that means. So, the first step I
have two groups that I'm going to be working with here. The IT group, which is a domain local group, as you can see
there, and then also I have a Tech Project X group. So let me go over here and Tech Project X, you can see there is
another group. This is a group that has IT employees in it that are working on a specific project. So, if they're both
domain local groups, you can nest one group inside of the other. So in this case, I want to put all of the employees that
are in the Tech Project X group and make those part of the IT group. I don't want to grab the users out individually
one at a time and put those in IT. If they're already in the Tech Project X group, I can just add that whole group to the
IT group. So, to do that, it's pretty simple. I'll go ahead and cancel this out to show you the get back to the group view
here, and then I'll go into the IT group, and then there you see the Members tab. All I have to do is click on the
Members tab, and then once I do that, I'll click on Add, find the Tech Project X group that I'm going to put in
there, hit Find Now to find it, double-click, and OK, and now you can see that Tech Project X is embedded in
IT. After that, just hit Apply, and we're all done. That's all there is to it.
Convert Groups

There are three types of scopes for groups you can see here; Domain Local, Global, and Universal. Each of these
scopes has a specific purpose. You can look along the X axis here. I've outlined three columns; members from the
same domain, members from another domain in the same forest, and members from a trusted external domain. These
are the general groups that make each group scope different. In a nutshell, you assign members to domain local groups
if you have a single domain in a forest, or if you have multiple external forests set up. If you have multiple domains in
a single forest, you would then use global groups. Use universal groups sparingly. Universal groups do not have near
the functionality as the other groups and are really rarely used in the real world. Now that you know why you might
need to convert groups back and forth, let's take a look at how it's done. In ADUC here, you can right-click and go to
Properties and you'll see the Group type on the General tab. To convert that group, click on the proper button there
and click OK. It will take a little while for that change to replicate across your domain, but you really don't need to do
anything else at this point. It's been converted; that's all there is to it. You can, of course, do this in PowerShell as
well. Just to show you the whole process, I'll create a group and put it in the wrong scope. I'll use the New-ADGroup
cmdlet and I'll call this one Dist-Group, which I meant to be a universal distribution group, but then I'll accidentally
put it in the global scope, and by default, it's a security group. Just to confirm I messed up, I'll go over to ADUC now
and refresh and check it, and then, yep, it is wrong at this point. Now, back to PowerShell to fix my mistake. This time
I'll use the Get-ADGroup cmdlet to get the information on it, and I'll then pipe that over to Set-ADGroup and use
the GroupScope parameter to change it to universal. But it's still a security group, and I want it to be a distribution
group. To change that, I'll use almost the same command here, but this time using the GroupCategory parameter
and specifying a value of distribution. Once I do that, I'll then go back over to ADUC and I'll refresh. And now you
see that we have a universal distribution group set up. Now, chances are, you won't need to do this very often. It's
good to know that you can change group types and scopes when necessary, and it's really not all that hard to do both
with the ADUC and with PowerShell.

Delegate Group and OU Management

If you work alone, this won't be of much use to you, but if you have others in your department or some power users
that you trust, you can have them help you with group management. Inside of ADUC, you can delegate control to
others. To get to that control, you'll need to go up to View and then turn on Advanced Features. Now pick an OU that
you'll want to delegate some kind of group control to. I'll go ahead and pick the Company Users OU. I'll right-click on
it and then I'll click on Delegate Control. This will start up the wizard. Now we need to decide who to allow. Here I
can pick an individual user, or I can pick a group. Then I get to decide what exactly he'll be able to do with this
OU. Whether it's creating groups in the OU, managing GPO links, for example, there's a lot of different things that we
can do here. There's also an option for a custom task, which brings up a long list of choices. You probably won't use
these unless an application requires a specific setting in here. For now, I'll just stick with the Create, delete, and
manage groups option. This will ensure Jim can manage groups only in this OU. After making sure I've selected the
right people, I'll then click on Finish and I will be returned to the ADUC. The final part of this is remembering what
you just did. Sitting at ADUC here, there's no easy way to tell if a delegation exists. There's not one that just shows up
immediately in this window. To find the one I just did, I'll have to remember which OU it was. I'll then go to
Properties and then go to the Security tab, and then on the Security tab, I can click on Advanced before I see anything
useful. Here I can see the create/delete access that I have just delegated.

Automate Group Management with PowerShell

PowerShell is great for making mass changes to AD. Things like adding or removing users from groups is one of
those. I don't have a lot of users in my demo environment here, but I can still show you how this all works. First, I'll
create a new group using the New-ADGroup PowerShell cmdlet. I'm going to make a group for some users that I
really don't trust with access to the network. I just know they'll click on something they shouldn't. I'll call it, I don't
know, unsafe, so there's no doubt why this group exists. I also need to specify the scope and the path, and I'll put this
group in the Company Users OU. We could then take a peek in ADAC here just to confirm this new group
exists. After a refresh, there it is. If I open it, you'll see that there's nothing in there yet, which makes sense because I
haven't added any group members. If I go back to PowerShell, I can then add some users to this new group using the
Add-ADGroupMember cmdlet. To do so, I'll need to specify the group name and the user accounts I like to add to the
group. And then if I want to check to make sure that they are there, I can use the Get-ADGroupMember cmdlet. This
is where I can specify the group I want to check, and sure enough, there's the users that we just added. I could also
have checked in ADUC by opening the group and going to the Members tab. And there you have it, they're right
there. Previously, I had mentioned the Managed By tab, and as long as I'm in here, I'll go ahead and just show you
how this works. If you have other people in your IT group or maybe even a power user that's not in IT, you may want
to let them add and remove members from some of your groups to, I don't know, take a little bit of work off your
shoulders. To set that up, just add them here by clicking on Change and then finding their name. Then you would
check the box to allow them to update the member list. And now that the user can help me out by adding
and removing members by themselves, they don't have to call IT. You should now have the ability to add new security
groups, put users in those groups, and even allow someone else to help you manage those groups.

Configuring Service Authentication and Account Policies

Introduction

You've gotten your AD accounts in check, and you've created a bunch of groups and OUs, but now you need to focus
more on security. I got you covered here. In this module, we'll cover many different ways you can manage
AD infrastructure and account security. As I mentioned, we'll be focusing a lot on the security aspect of AD in this
module. To properly cover many of those features, we'll first get into managing Service Principal Names, or SPNs,
and group-managed service accounts, or GMSAs. These associate services with AD account identities. On the local
client, we'll also cover virtual account, which help you more granularly manage identifies controlling Windows
Services. And an AD course would not be complete without mentioning Kerberos. We'll get into setting some
Kerberos policies and introduce you to Kerberos constrained delegation. Of course, we'll also cover some policies
around passwords like the Default Domain Password Policy, as well as fine-grain password policies or password
security objects. I'll then show you how to manage all those annoying account lockout problems via policy and finally
hit on how to set up authentication policies and silos to better control what accounts can be authenticated from certain
devices.

Manage Service Principal Names

Service Principal Names, or SPNs as I call them, are unique IDs for a particular service instance. SPNs allow AD to
associate a particular instance of a service with an account. SPNs associate a host name with a service. Since there can
be different host names, a service instance can have multiple SPNs as well. You'll notice a SPN by its format of the
host name the service has installed on, followed by the serivce name itself. You'll see this in action in the upcoming
demo. Now that you've heard a theory, let's dive in how you can configure a SPN. The setspn command with the list
parameter will show any SPNs associated with the account listed. I'll use an account I set up earlier called the serve
account. Nothing shows up here because I haven't assigned any SPNs yet. To do that, I'll use the setspn command
again, but this time I will use the -s switch. I should mention here that in older versions of server, you'd have to use
the -a switch, but the -s switch has been here since Server 2008 and it verifies that there are no duplicate SPNs for
you, so it makes sense to use it. After this switch, I have to list the service class and I'll use HTTP for this demo. I'll
then put a / and what that is associated with. In this case, it's going to be a website. And finally, I need to supply the
service account I want it to be associated with. When I hit Enter, it will check for duplicate SPNs, and when it finds
none, it will register this new SPN. The setspn command will also work with the host, not just the full name. So I can
go back and remove everything other than www and it will create another SPN for me. And just to show you that our
SPNs have been added, I'll now run setspn -l with the Contoso\servaccount again, and now you can see that the two
SPNs are listed. Of course, HTTP isn't the only class we can use to create SPNs. We can pretty much put any service
type you want here because it's just a label the client uses when making your quest to find out where the services
exist. For example, I could use the test service I set up in a previous section, s-test. I'll use the same service account
here, but it could be any service account that you have created. And like we did with HTTP, I can also set it to just use
the first part, setting up a second SPN. Now users can use either the FQDN or just the service to access it. I should
also mention that the -d switch is used here to remove a SPN. So if I wanted to remove that last one I created, I would
just change the switch to -d, and it would be removed. And now I'll just run -l again just to show that it's really
gone. Now chances are you won't be using SPNs very often, but every now and again, some applications may require
it, and you should now know how to get them set up.

Understand and Manage Group Managed Service Accounts

Your Group-Managed Service Accounts, or gMSAs, are an evolution of traditional service accounts that have been
around forever. GMSAs allow you to set up a single account and assign it to a particular service like a load balanced
web server, a cluster, or whatever have you. It ensures that the passwords are reset on a continuing basis amongst each
service account in group situations. GMSAs also use the Microsoft Key Distribution Service that you'll get a glimpse
of in an upcoming demo. This runs on every DC and ensures that the password of the single service account that's
used by different service instances is kept in sync. Now let's take a look at how we can create a Group-Managed
Service Account and get it associated with a service. I'll do this in PowerShell, so I'll go ahead and open up a
PowerShell console here. The next time you do this on your domain, you'll need to generate a Kerberos Key
Distribution Service, or KDS root key. This is done with the add-KdsRootKey cmdlet, and to make that effective
immediately, I will use the EffectiveImmediately parameter. The name is a little misleading, though. While it causes it
to start right away, it doesn't actually take effect for about 10 hours. That allows it the time for replication to cross
over through the domain. For this demo, I don't have any need for replication across multiple DCs or sites, though. I
want this to start working now, so I'll go ahead and use the EffectiveTime parameter. This is not something you'd
want to do in production, but if you're working in a small lab environment, it can save you some time. I'll go ahead
and set this to be effective as of 15 hours ago, just as random number. That will ensure that it's available to use right
away. Now that I've done that, onto the next step, which is creating the service accounts. I'll use the New-
ADServiceAccount cmdlet and specify the name with the name parameter. I'll be very original here and call it
gMSAtest. I also need to give it a unique DNS host name. I'll then need to tell it which principals are allowed to
access the password. I can do that with the PrincipalAllowedToRetrievePassword parameter. You can specify any
group here. Maybe you have a group just for servers, for instance. I don't know, it really doesn't matter, you can
specify a group. But for now, I'll just go with Domain Computers for this demo just to make it simple. Now I've got a
service account and a key, but I still need to associate these with a machine and with the service I want on that
machine. To tie it to a machine, I'll use the Add-ADComputerServiceAccount cmdlet and use the identity
parameter, specify the name of the machine I want to have this available on. That is the machine which I'm on right
now, actually. Then I'll use the ServiceAccount parameter and specify the ServiceAccount name itself, which in this
case is gMSATest. Of course, this doesn't do much unless the service account is installed on the machine itself. To
install it, I'll then use the Install-ADServiceAccount cmdlet. This runs locally on my machine, so I don't need to give it
a machine name. I do, however, need to give it the service account name, which using the identify parameter of
gMSATest. And really that's all it takes to install it. But I can make sure it's there by running the Test-
ADServiceAccount cmdlet followed by that name again in the identity parameter, gMSATest. You can see that I've
gotten a true response here, which means the service account is installed on the machine. And now it's time to
associate this service account with a service on my machine. For this demo, I'll create a new service both so you can
see how that's done and so I don't have to make changes to anything already running on my machine. To do this, I'll
use the New-Service cmdlet. I'll give it a name and a path to the executable. Of course, I don't have a real
executable, so really, this path doesn't mean anything at this point, but I'll just have to give it something. We're just
creating a random Windows Service to associate this to. And now if I switch over to our services.msc, I can confirm
whether or not it's really in there. And there it is. Under the s, you should see it right there. If I double-click on that, I
can go into the Log On tab and change the account from the default to the service account that we just created. I'll
need to change the location to the domain and then I can select the domain name. You also need to remove the
password that's in there. If you don't, you'll just get an error. Nothing really breaks, but no big deal if you forget,
though. Now I'll remove that password and click OK again. And if I get a nice message letting me know I've
been given a Log On As A Service right, it's working now. If this was a real service, not really the fake one that I
created for this demo, I could now right-click on it and click on Start, and it would start up under that service account
that I just assigned to it. Now this isn't exactly an intuitive setup, and it does involve several steps. But you should
now understand how Group-Managed Service Accounts are created and associated with computers and services. Once
you've done it a few times, it really won't seem so bad.

Configure Kerberos Policy Settings

Let's now dive into Kerberos Policy Settings. Now chances are you'll never touch these, but you should at least have
an idea of what they do. Enforce logon restrictions, which is the default, sets the Kerberos Key Distribution Center to
validate every request against user rights on the account. In theory, this can slow things down, which is why you can
disable it, but in reality, you probably aren't even going to notice. The default adds a little bit of extra security
and really that's always a good thing. The next three lets you adjust the lifetime for tickets. These are only for new
connections to a server, though. Once a connection has been authenticated, these settings don't apply. The default
seems very reasonable to me, and I really never had a reason to change them. Lastly, we had the clock sync tolerance
setting. Now this one is important in day-to-day operations. It's important because you can affect whether your
machines are allowed to connect to your domain or not. In theory, the time on your machines is synchronized to your
PDC emulator or a PDCE role domain controller. That's the default setting for Windows Domains. However, we all
know that sometimes the clock on a PC will drift or someone may change the time that they have on their machine for
some reason. It's important that the clocks be in sync because the time is used for lifetime tickets that are created, the
ones controlled by the settings above, and if they don't match, you can have all sorts of strange connection issues. This
setting lets you adjust how much of a difference there can be between your PDCE clock and the clock on the machine
trying to connect. If it's higher than the setting, the connection will be refused. Five minutes is a pretty good
number, as really most clocks should be keeping decent time these days and adjusting themselves by synchronizing
with a good time source. Now, while you probably won't ever change the settings in here, knowing they exist can help
with troubleshooting.

Configure Kerberos Constrained Delegation

Like SPNs, you probably aren't going to be using this very often. Generally, you only need to configure Kerberos
constrained delegation when an application requires it. To configure this feature, I'll open up ADUC and you can see
some of the computers on my domain. So to make this work, I'll open up one of those machines and go to the
Delegation tab. Here I can decide how much I want to trust a machine or user. For the sake of security, you want to be
very careful here. Only trust what you absolutely have to. Generally that will mean specified services only, so you can
limit the trust here as much as possible. Next, click on Add to pick the computer or user account. This is what account
you're going to trust along with the service you're going to allow. First, we pick the machine. In this case, I'll just pick
my machine, and then we'll be shown a list of services. You can select more than one here holding down CTRL, or
even use the Select All button, but again, you really want to be careful to only allow the absolute minimum. For this
demo, I'll just randomly pick facts just to show you how this works. That adds it to the list here. And I could then add
others if needed. While I'm at it, I can also remove anything no longer needed using the Remove button. Again, you
may never need this feature, but if some application you need requires Kerberos constrain delegation, you now know
how to get it configured.

Configure Virtual Accounts

Virtual accounts are another way to manage services on the network. However, unlike AD Service Accounts, or
Group-Managed Service Accounts, these accounts are local. They actually replace all of these shared instances of
using local accounts, like NETWORK SERVICE, for example. Luckily for you, they don't support or require
password management. The service accounts they're creating instances for don't have a password either, which is
nice. This should make more sense once we jump into the demo. So let's take a look at how these virtual accounts
actually work. I'll open up my Services list here and I'm going to open up a dummy service that I created just for this
called Virtual. It's important to get the actual service name here, which is often different than a description
that's shown in the main services list. So I don't make a typo, I'll just copy that out to be used in a moment. I now need
to assign a virtual account to this service. To do that, I preface the account name with NT service followed by that
name I copied a few seconds ago Because virtual accounts don't use passwords, I can go ahead and blank this out now
and then click OK, and really that's all there is to it to associate a virtual account with a service. You should now have
a specific local service instance, allowing you to audit and track its activity rather than sharing that service across
many different Windows Services. Note that if the service will be needing network access, you may have some more
work to do to get properly configured due to the nature of the NT Service account, but for local access, that's all you
should need to do.

Configure Domain Password Policy Settings

To review domain password policies, I'll now open up the Group Policy Management console from my Windows 10
desktop. Now to review and edit a domain password policy, you need to navigate to the Default Domain Policy. I'll
open this up, and let me make this a little bigger here. And then now I'll go to Computer Configuration, Policies,
Windows Settings, and then finally, Security Settings. This is where the account policies are located. This is where
you will find the Password Policy Settings. You can see the choices here, and unlike GPO options, they are fairly
straightforward in how they work. There's Enforce password history, which sets how many times a user has to change
their password before they're allowed to reuse an old one again. If you're in a very secure environment, you may want
to set this to a higher number than the default 24. Next is password age. The minimum prevents users from changing
their password over and over again. This is usually in an attempt to bypass these password history settings. By default,
it's set to 1 day, which means they can only change this 1 time per day. That's usually enough to discourage people,
but you can set it higher if needed. Maximum age is another attribute that sets how long a password can be used
before the system requires a user to change it. The default here is 42 days, but that's based on old guidelines for the
most part. The latest NIST guidelines state that you should not require your users to change your passwords at
all. Really, only changing them either when the user wants to or when there's some kind of breach that has been
detected. Unfortunately, some industries still require changing this every so often, but you may not have a choice
there. But if you can set this to 0, which means it will never force a password to expire, you probably should. Your
users will probably thank you. And then we have the password length. This is another one that users hate because
admins know passwords should be long, but users really hate remembering them. I found that suggesting phrases like
the start of a poem or song lyrics really helps. The users already know these things, so it's not nearly as hard for them
to remember. Next is complexity. Now, this is a mixed bag. The setting itself is fairly clear. Require that passwords
have numbers, characters, upper and lowercase in them, and not include the username, or don't. But you can't change
some of that, like requiring a number, for instance. The password has to always have three out of the four items
listed. And with the length, users do not like this at all. If you're willing to set a long password length, say, 20 or 30
characters, you probably don't need complexity. But if your length is only 10 or so, which is certainly more than
common, forcing complexity is probably a good idea. And finally, there is the reversible encryption setting. Now, if
you enable this, all of the passwords on your domain will be stored in a way that will allow someone to decrypt
them. Unless there is some really special need here, like maybe this is a test domain and you're practicing your
decryption skills, you'll probably never want to enable this. Let's now look at the account

Configure Account Lockout Settings

lockout policy settings. The setting that you're probably most familiar with is the lockout threshold. Now this
determines how many times someone can enter an incorrect password before their account is locked. By default, this
is set to 0, meaning that the account will never lock due to bad attempts. If you're in a small company and your
domain is only accessible locally, that might be okay. But in most cases, you'll want to adjust this so that if someone
trying to get into the account with a wrong password, that account will go ahead and lock out. Your user will then
need to contact you and ask you to unlock it, which you can do in ADUC. To do that, go to their name and then the
Account tab, and then check on the Unlock box. Click OK, and you're done. That's all there is to it. If you're more
comfortable in PowerShell or maybe you just happen to have your PowerShell console open, you can unlock the
account there, too. I'll now open an admin PowerShell console and I'll use the cmdlet Unlock-AdAccount followed by
the parameter Identity, which is the username. If it works, it doesn't return any results. But if you make a mistake,
you'll see a nice red error message for you. So back in the GPO, another option here is the lockout duration. If you set
this, a locked account will automatically unlock itself after a certain number of minutes you set. So, for instance, I had
this set to 30 minutes. Now if one of my users gets locked out, they can just wait 30 minutes and try again. They don't
have to contact me for help this time. This can cut down on help desk calls and also allow users to get back in if
nobody in IT is available for some reason. And finally, there's the reset lockout counter. This one is a little more
complicated than the others, though. This setting determines how much time is allowed between failed logon attempts
before the counter is incremented. The counter is the one used by the lockout threshold to determine if your account
should get locked or not. If you set this to 1 minute, for example, and someone enters a bad password, the count goes
to 1. Now they enter another bad password right away in, I don't know, let's say anything less than a minute, the count
goes to 2. If they keep doing this, the count will keep incrementing until it reaches a threshold, which then at that
point the account will lock. However, if they enter a bad password and wait for 90 seconds maybe and then try
again, the counter will not increment because they went past the time here. They can keep trying, entering as many
bad passwords as they want without ever getting locked, as long as they wait long enough between attempts. The
whole point of the lockout system is to fight brute force attacks. Obviously you don't want someone trying to get into
your system by entering password after password, and they finally find one that works, but brute force attacks take a
really long time. You can be sure that nobody trying is going to wait 90 seconds between attempts. They would need
to try hundreds, if not thousands of times per minute, even per second if they have any hope of finding a valid
password.

Delegate Password Settings Management

The delegate password settings are located in the same place as delegate OU management. I'll go ahead and open up
the ADUC to get there. Right-click on the domain and choose Delegate Control. Now I can select or group to be given
the control that I'm after. For this demo, I'll go ahead and just choose the entire IT group. Anyone in here will be able
to reset user passwords. Now I'll choose what I'm delegating control of. There are a lot of choices here and it's
important to pick the right one. As you may recall from when we covered OU delegation, it can be difficult to view
and change these settings after they've been made. Keeping good documentation can really save you a ton of time and
headache here. In this case, I want to delegate password resets, so I'll just check the second box, and once I click
Next, it's confirmed. Now you should know how to delegate password management. This gives you the power to
allow others to reset user passwords, taking some work off of your shoulder.

Configure Fine Grained Password Policies (PSOs)

Next are fine-grained password policies, or password setting objects, or if you refer to them as just PSOs. This is a
concept that allows an administrator to apply different password policies to the same domain. Password setting
objects, or PSOs, allow more granular control over the options that define a password policy for different users. PSOs
are defined by group, although you can define a PSO by the user level, it's not really recommended just for
management purposes. This means that if you like to define a separate policy for administrators versus lower-
privileged accounts, for example, you'll need to create different AD groups. In this upcoming demo, we're going to
cover how to get PSOs set up in AD. While PSOs have the same kind of settings that we saw before in our default
domain policy, we can't configure them via GPO. So in my domain controller here, I'll go into ADAC to get this set
up. Inside my company, I'll click on System and then on Password Settings Container. By default, this will be empty,
so I'll just click on New to add something. You'll probably recognize most of the settings in here because they are the
same settings we covered earlier. We have our minimum length, history, complexity, and lockout options. There's
even that reversible encryption option that you'll likely never use, at least I hope not. You can see that there are
several items marked as required, but most of them are already filled in with default values. You'll need to change at
least one of these defaults, or there really wouldn't be any point in having a PSO at all. The only attribute you'll be
required to fill in is the name and the precedence. Now you can put any number in here for the precedence number
because this number is only used in relation to the precedence defined in other PSOs. If you have a single PSO, this
setting really doesn't matter. If you make this one 100, for instance, and you create another PSO and it set that 1, I
don't know, 200, this 1 will have precedence. Of course, to keep things simple, you'll probably want to keep the
numbers lower than that. But what's really important though is that you don't assign the same number to two different
PSOs. These PSOs can be assigned to users and groups and because users can be in more than one group, the
precedence number defines which PSO will apply. And then, finally, any PSO, whether it's a group or a user will
override the default domain GPO. With that being said, just remember the order is domain policy, group PSO, and
then user PSO with each one overriding the previous one. If a user is in more than one group with a PSO, the
precedence number determines which PSO applies. So this is why it's very important to only use unique precedence
values. All right, so back to the action. I'll call this PSO I'm creating IT-PSO and give it a precedence of 1. I'll then
click on Add to assign this policy to a group. In this case, I'm going to apply it to my IT security group. That's all it
takes. The new policy is in place for that group. As with most tasks, you can do this in PowerShell, too. Now this is
one of the few cases where PowerShell may actually be harder than it's worth. Most admins will only create a few
PSOs. The advantages you get from PowerShell's bulk processing automation capabilities aren't really likely to matter
much here. And the PowerShell commands for this are honestly a bit complex, but they do exist, so you should at
least be exposed to them. To demonstrate this, I'll open up a PowerShell console as an administrator now. The cmdlet
I'll use to create a new PSO is called New-ADFineGrainedPasswordPolicy. This cmdlet can be a bit confusing, so I'll
list some help content for this cmdlet here so you can see the available parameters. Now, as you might expect after
seeing it in the GUI, there are lots of different settings. You have to supply a name, the precedence, the lockout
information, password length, age, et cetera, lots of different things. After you provide that information, you have to
run another cmdlet called Add-ADFineGrainedPasswordPolicySubject. This cmdlet finally assigns the PSO to a user
or a group. This cmdlet doesn't have too many parameters, though, thankfully. We've got the name of the PSO and the
user or group it's going to apply to. These are the only parameters that are technically required. PSOs are a useful tool
when it comes to configuring your Domain Password Policy. You no longer have to create a separate AD domain just
to separate out these password policies. You should now be ready to set up as many PSOs as you need and properly
configure them in your environment.
Maintaining Windows Server 2019 Active Directory

Introduction

For our final module of the course, we're taking a step back and focusing more on infrastructure. We're going to cover
how to maintain your AD infrastructure once you've got a smoothly running environment. We're going to cover
roughly three topics in this module. The first is replication. We'll cover how you can ensure domain controllers are
replicating properly and how to troubleshoot some common issues. We'll cover how to manage replicating the AD
database, the sysvol share, and password replication policies to read-only domain controllers. Next, we'll jump into
backing up and restoring AD both for the AD database itself and the required sysvol share hosted on all DCs. We'll
then finish up on maintaining the database through offline defragmentation techniques and how to clean up
unnecessary metadata in the database.

Monitor and Manage Replication

Replication is the process of copying your Active Directory data in the database and the sysvol contents back and
forth between your domain controllers. It's really one of the most important background processes that your DCs
run. When replication fails, lots of critical processes can break. Now, while replication is usually a set-it-and-forget-it
thing, a time will always come, it'll inevitably happen, you'll need to troubleshoot it. You'll probably want to start
taking a look at the Active Directory Sites and Services console. Here I'm looking at the site settings. You can see all
of the DCs in the domain here listed under servers. If I click on this arrow, it will show NTDS Settings. Off on the
right, you can see that this is automatically created by the knowledge consistency checker, or KCC to replicate the
data. The details here show you which server and site the data is coming from. You can open it up for some more
details, but it's really doubtful you'll ever have to change anything in here. What you may want to do, though, is if you
suspect a replication problem, is right-click and choose Replicate Now. This will initiate replication between the
servers right now instead of waiting for the next scheduled replication task. As you can see here, it completed without
errors. But if something goes wrong, you would see an error here, and it might provide some clues to help you pin
down the issue. Now if something is wrong, you want to dig deeper using the repadmin command-line utility. I'll go
ahead and open up a PowerShell console here, and using the question mark switch, you can see that there are a lot of
switches available for rep admin. There are really too many to dive into all of them here, but I'll go over the ones
you're most likely to use. The first is the showrepl switch, which will show you the status of replication between the
domain controllers you've authenticated with and all of the other domain controllers that are supposed to replicate
with it. Those you see here will be all the ones we saw earlier in the Active Directory sites and services applet when
we looked at the NTDS settings. I'll scroll up here, and then this first part shows that my machine is authenticating
against DC1. Then below it shows all the DCs. In my case, there's only one other DC, but if there are more, they
would be listed here. The list shows you the DCs and the last time replication happened, and really if it worked or
not. As you can see, all of mine were successful, but if they weren't, I'd now have a better idea of where the problem
was coming from. Now it's also worth mentioning here if you want to check a DC that you did not authenticate
against originally, you can change the command a little bit by adding the name of the other DC to the end. You'll see
all of that same information here, but now it's about the domain controller I picked. When you have a lot of DCs, this
is a quick and simple way of checking each of them for replication problems. Another useful switch is
showcon. Without additional parameters like the showrepl command, this will be directed at the DC that you
authenticated against. This command shows you all of the connections that the knowledge consistency checker makes
between that DC and the other domain controllers. As you can see here, there are quite a few, but all you're really
looking for here are errors to see if something isn't working as it should. And just like with the showrepl switch, I can
direct showcon to display information from other DCs by just putting the DC name at the end. You can see that you'll
get the same kind of information, but for that DC instead. You may also want to check to make sure your
AD attributes are replicating properly, which you can get more granular with the showobjmeta switch. Now you need
to specify which DC you want to check, and also which object you would like to check the metadata replication
on. I'll just check on my user account here located in the users container. As you can see, there are quite a few
attributes just for this one object. This list shows you where the data originates from, along with the original date and
time. This information can be helpful if you suspect that an object has started at a certain DC on a certain date. If it
shows something different here, that DC may not be functioning as expected. I've mentioned the knowledge
consistency checker, or the KCC, a few times in this demo. The repadmin command will also let you check on the
KCC itself. To do that, you would use the KCC switch. This switch performs a consistency check on that same DC
again, but if you want to run it on another one, just supply the DC name at the end, just like you have been. Next,
another useful switch is the replication summary, or replsum command. This shows a high-level overview of
replication across your DCs. If you have several, especially if some aren't nearby, this could take some time to
run. Listed here you'll find source and destination DCs and how many replication failures there have been along with
any error messages. If you do see a failure here, it's almost certainly worth investigating further. One quick thing you
could try would be to force a replication to run right now. You would do that with the replicate switch. You would
then specify the destination DC first and then the source DC and then the Active Directory context you would like to
replicate. If this doesn't succeed, you'll want to start looking at what might be blocking the replication. It may be a
firewall, a DNS issue, for example, it could be a lot of different things. If you don't want to test a single
connection, you can just do a syncall command. This will force a replication to happen from a specified DC to all of
its replication partners within its site. If I add the /e switch here, it will sync to any partners that it has access to across
the entire forest. As you can see, that's a bit messy showing the GUID for each DC. If I go back and run it again with
the /d switch, it will show you the distinguished name instead, which is a lot easier for us humans to read. And the last
line here, no errors, is exactly what I want to see. If anything else, you'll want to scroll back through all of this and
look for the details to pin down where that error is coming from if you did have an error. Now before I go, one final
method I would like to show you is using PowerShell to check for replication errors. Throughout this demo, I've been
using the repadmin command-line utility for all this, but you can also use a PowerShell command called Get-
ADReplicationFailure. To quickly demonstrate this, I can provide it a DC name and it will show any failures that DC
may have had while trying to replicate. Replication issues can make your domain behave in some way unexpected
ways with issues that won't always become obvious quickly. So keeping on replication is definitely something you
want to add to your list of maintenance tasks.

Configure Password Replication Policies (PRP) for an RODC

Read-only domain controllers, or RODCs, have a very specific requirement when it comes to password policies in
AD. RODCs are normally considered not as secure as full domain controllers, being as they are usually deployed in
remote locations. It's important to limit what passwords especially get replicated to them. In ADUC, you can right-
click on an RODC and under Properties you'll find a tab just for the Password Replication Policy. This will show you
which groups, users, or computers are allowed to have their passwords stored on this DC. You can see the defaults
here that are admin-type accounts, administrators, account operators, backup operators, et cetera. All of them have
some kind of elevated level of credentials and are all explicitly denied. This is to ensure that there is no possible way
any account in those groups will ever have the passwords stored on this DC. You'll only want to choose allow for
those accounts that are local to the RODC. Any other account we'll pass on as the authentication request to another
DC. It may take a little bit longer to get that authentication, but as long as the network is working correctly, it will
authenticate and work just fine. If the defaults don't fit your needs, you can edit them right here. If I decided, for
example, that I didn't want the Allowed RODC group to be allowed. Maybe because I'm going to create my own
group instead. I could just select it and then click on Remove. I'll then say Yes because I'm sure I want to remove
it, and there you can see it's no longer in the list. Now if I want to add a group in here, now, disclaimer, I could add an
individual user to this, but it's honestly always much easier to work with groups, so please don't add individual
users. To add the group, I would click on Add and then select this new group will be allowed or denied. I'll go ahead
and go with allow and then I'll add in this group that I just deleted because I do really want that group in there, after
all. You can also use the command-line utility to modify password replication policies to RODCs using the repadmin
utility. To modify password replication policies, you would use the prp switch. Now, there's a lot in here, but I'll just
go ahead and hit on the ones you're most likely to use. For instance, the add command. This will let you add a user or
group just like we did a moment ago in the GUI. I can tell it which RODC to add to, whether this will be an allow or
deny, and the group or the user I'm going to add. In this case, I'll just add the unsafe group, which I created in a
previous clip. And there you can see the confirmation that the group was added to the allow list. And if we want to
remove a group, it's almost the same thing here, just with delete instead of add. Another thing you may want to do
here is double-check which accounts you've allowed or denied. You can do that with the view option. I'll tell it the
RODC to check and then I'll look at the allow list. And here you can see the default groups are listed. Just to show you
it works, though, I'll add that unsafe group back in using the add command from a few seconds ago. And now if I run
view on allow again, you can see that the group is listed here. You can also check which groups are explicitly denied
by using deny. And finally, with the view command, you can also check to see if there's any passwords currently
cached on the RODC. For that you would use the reveal switch. As you can see here, there aren't any users listed
because of my demo environment, the RODC hasn't seen any use. Whenever a password is authenticated by the
RODC, it will be cached. But if any user had been authenticated to the RODC, this would let you see all those user
passwords that have been cached. Now there are lots of other PRP switches here that you may want to review, but for
the most part, add, delete, and view are the ones you'll be using a huge majority of the time.

Back up Active Directory and SYSVOL

With as many backup programs that exist these days, it's seems pretty likely that you'll be using something other
than Windows Backup to handle your server backups. But it does exist, and there are certainly maybe some people out
there that still want to use this, including getting some questions answered on the certification exams. To back up AD
and the sysvol share, the first task is installing Windows Backup. If you're using a full installed server with a
GUI, you may want to go into to the Server Manager and then go into Add Rolls and Features, click Next until you
reach the Features section. Here select the Windows Server Backup box, click Next, and then Install. When it finishes,
you'll click on Close, and you're done. If you don't have the GUI available or you would just rather use
PowerShell, we can make that happen, too. Perhaps you've got Server Core installed on your DC, or you're just
working remotely from your workstation anyway. For those circumstances, the way to install Windows Backup is
with PowerShell. From my Windows 10 PowerShell admin console, I'll first need to remote into my server. I can open
up a PowerShell remoting session with Enter-PSSession and enter the name of the server. You can see my prompt
changes here to show that I'm on the server. Now I'll need to use the Install-WindowsFeature cmdlet to install
Windows Backup. Now that the feature has been installed, I'll create a backup policy. I'll use this backup policy to
then run the backup when I'm done. There are several parameters here that need to be set, so I'll set up a variable to
hold them. I'll call it backpol, and I'll use the New-WBPolicy cmdlet to assign values to this variable. When I output
the value of backpol, you can see what it contains. You can see that most of the property values in here are blank by
default, and a backup won't run if you run against this policy without setting at least some of them. You'll need to
define at the very least a target and a source. Since we're backing up AD and sysvol, in this module, I'll need to define
a bit more than that. Notice the SystemState is set to False there. I need to get that set to True. To do that, I'll use the
Add-WBSystemState cmdlet with a policy name to change that value from False to True. This is just telling Windows
Backup to backup the system state. And to double-check, I'll clear the screen and check backpol again. Now that the
SystemState is in the policy, I then need to set a source volume to be backed up. In most cases, this will be the same as
it's been for a very long time, which is Drive C. TO check, I'll run Get-WBVolume -AllVolumes. This shows me all
of the volumes that are currently available. And you can see here it listed as MountPath. As expected, I've got a C
volume on this machine. I've also got a D and a System Reserved partition, but for this demo, I'm just going to work
with C. Now I need to get that into my policy. There are a few ways to do that, but I think the clearest is by assigning
this to a variable. I'll go ahead and use the vol variable here and the Get-WBVolume cmdlet with a VolumePath
parameter set to C. And then using the Add-WBVolume cmdlet, I'll add that volume in to pass in all of the
needed volume information that I need. If I now check the value of my backpol variable, you can see that
VolumesToBackup is now set. Next, I need to set the target. The target is a location to store my backups. This can be
a local volume or maybe a network location. For this example, I'll use a network location because it seems likely that
you'd be backing up somewhere else other than a locally attached drive. Again, I'll use a variable here to keep things
more readable and easy to follow. I'll use the New-WBBackupTarget cmdlet to assign the path and put it into
networkbackuplocation. Make sure that this path exists and you have permission to write to it. If needed, you can pass
an alternate credential here using the credential parameter, but in my case, I'll just use the currently logged on user
account to authenticate. And like before, I now need to get this added into my policy. I do that with the Add-
WBBackupTarget cmdlet. I give it the policy name and the target I just set up. And you can see now that I've got a
warning here. Because I'm backing up to another location, this server has no way of protecting it with things like
NTFS permissions. For a final review, let's check the value of backpol. Now you can see everything that I need is
here. We have the source, the destination, and the SystemState is set to True. Now that I have everything set up
correctly, I can go ahead and start a backup. That's done with the Start-WBBackup cmdlet. I'll give it a policy name
and it will start to backup as I've configured it.

Perform Active Directory Restore

Unfortunately, disaster strikes sometimes. Your AD environment goes belly-up and you have to perform an Active
Directory restore. Now I hope you never have to use the skills you learned in this clip, but if you do, you'll at least be
prepared. An AD restore consists of rebooting a DC in Directory Services Restore Mode, or DSRM. Now this is a
mode that takes the AD database temporarily offline to perform maintenance. You should also know that there are two
kinds of restoration, authoritative and non-authoritative. In a nutshell, an authoritative restore allows you to restore
AD objects on a DC and replicate those changes across the domain. A non-authoritative restore, on the other hand,
does the opposite. It will force other DCs to replicate AD objects to a problematic DC. In the upcoming demo, we'll
cover these in detail. So I'm here now in a PowerShell console with an open PowerShell remoting session to my
domain controller. Now, in a production disaster recovery situation, you'd normally have to be at the domain
controller console with no network connection to do most of this. That's because we wouldn't want to replicate
any changes to the other DCs at this time. But due to my demo environment, I can't replicate this. However, the steps
will be nearly identical. If this were in production, you'd first restart the domain controller in Directory Services
Restore Mode, or DSRM. You may be familiar with this when you install a new DC. Every time we install a new
DC, it will ask you for an administrative DSRM password. DSRM mode is required for an Active Directory restore
whether you'll be doing an authoritative restore or a non-authoritative one. And before you do this, be sure you have
your DSRM password handy because without that, the process isn't going to work very well. You'll need to use the
BC edit tool to force Windows to start in DSRM or DesiredSize Repair Mode the next time it's rebooted. You can do
that by running bcdedit with the set switch, followed by the safeboot dsrepair switches. Once that's finished, you'd
then reboot when you're ready. When the server comes back up, it will be in DSRM mode. You would then be ready
to recover the system state. Now, one thing to notice, we're using Windows Backup to restore AD in this clip. That
means recovering the Windows System State on a domain controller. To recover the system state, you'll need to know
the backup set that you want to restore from. To get the backup information, run Get-WBBackupSet. This will show
me all of the backups that have been run and show me what type they are. Now, as you can see here, I've only got
one. But assuming you're making regular backups, you'll have several. Make sure you are selecting the one that has
the SystemState listed under RecoverableItems. I'll use a variable here to make things easier to follow called
sysback. I'll then use it to capture the output of the Get-WBBackup command, but only where the version ID is the
one I want. Instead of typing the version information, I'll just go ahead and copy it here and paste it at the end. Here's
what the current value of sysback looks like. I'll need to use this PowerShell object to pass to the Start-
WBSystemStateRecovery cmdlet. For a non-authoritative restart, which will pull AD information from another
DC, I'll tell it the backup set and also use the Force and Reboot parameters because we want to prevent
getting prompted and to automatically reboot. Once it reoboots, it will come back up, connect to another DC in the
domain, and begin synchronizing all the changes that have happened since that latest backward. Now let's overwrite
some AD objects with an authoritative restore. To do that, I'll add the AuthoritativeSysvolRecovery parameter. This
prepares you for the next step where you will tell it which objects you want to authoritatively restore. These objects
will not be updated and overwritten when you reboot to connect to other DCs, but instead will become the current
version, which other DCs would sync with. This is authoritatively restoring the object, meaning this DC we're
working on has the version we would like to restore across the entire domain. The command needed to perform this
restore is ntdsutil. Unfortunately, some of the restore process can't be done here because we would need a DC and
DSRM mode; however, I can't connect to the server console at a Command Prompt and force the NTDS service to
stop. This will put the DC in a state that's close enough to DSRM to let me run the ntdsutil command. Once I stop the
NTDS service, I'll say yes to stop all those other services as well. And now I should be able to run ntdsutil. There are a
lot of available options here, but the one I want is activate instance ntds. This will force the ntdsutil command to be in
the ntds context. I'll then go ahead and run an authoritative restore to get to the next menu. Here is where you will
really see how difficult this kind of restore can be. So now I'm ready to restore my AD object or OU subtree, but the
only way to do that is to know exactly where it was and what it was called. You have to supply the full distinguished
name for whatever you are trying to restore here. For example, if I wanted to restore my user account called Adam, I
would need to provide the fully distinguished name as follows. And if I wanted to restore the entire company users
OU, I would need to specify the OU DN like this. I don't actually want to override the object this time, so I won't hit
Enter here, but that's how the command is used. I'll now quit my way out and show you the last required
step. Assuming you've used bcdedit to reboot into DSRM, you'll need to use that again, this time to set the boot mode
back; otherwise, every time you reboot, you'll end up back at the DSRM console. I'll run bcdedit and use deletevalue
to remove this safeboot option. And now that you know how to perform an AD restore, I'm sure you'll agree that this
is not something you will ever want to do in a production. You'll always want to have more than one DC up and
running so they can replicate across each other and you'll also want to enable the AD recycle bin. Lucky for you, this
is a topic we'll be covering shortly in this course.

Perform Object and Container Level Recovery with the Active Directory Recycle Bin

Now that you've had a look at how backing up and restoring Active Directory had to be done in the past, let's now
take a look at what Microsoft is now offering in newer versions of Windows Server. The Active Directory recycle bin
is a much better way to deal with recovering objects that may have been inadvertently deleted and need to be
recovered for whatever reason. To demonstrate the AD recycle bin, first let's make sure that the recycle bin feature is
enabled. To do so, open up ADAC. I will do here on my domain controller, and click on my company. Over on the
Tasks menu, you'll see an option to enable the recycle bin. This will only be here if you haven't already enabled it
because once you do enable it, there is no way to turn it back off. This message you see here is just letting us know
that a refresh is required before the change will be visible. There's also a reminder here that if you have multiple
DCs, it can take awhile for this change to replicate. Until it does replicate to all of your DCs, this feature may not
work properly. In my demo environment, replication is really fast, so I'll be able to just start working on it right
away. But in production, you would definitely want to wait awhile to ensure all of your DCs sync up to get this
change. One other thing to know here is that you can enable this via PowerShell if you prefer. Because it's just a
single click in ADAC, I think most people will probably just use that method, but, I don't know, maybe you're a
PowerShell junkie or you don't have access to ADAC for some reason; you can enable it with PowerShell. The
command to do so is called Enable-ADOptionalFeature. You'd then provide the feature name, followed by the
scope, which I've set here to forest, and then the target, which is the domain you would like to enable it on. I'll run this
and get that same warning as you saw in the GUI. And if I say yes, you can see I get an error message because it's
already enabled. Now that the recycle bin is enabled, let's go back to ADAC to see how this works. You can see a new
container listed here called Deleted Objects. As of now, this is empty because the recycle bin was just enabled. Let's
change that. I'll go over to my company users OU and delete an account. I don't know, let's say that, I don't know, I'm
feeling malicious and maybe I'm fat-finger-prone and accidentally delete Donna Jones' account. Oops! Now if I go to
the Deleted Objects container, I can see the Donna Jones object. You can see that it shows the name, the date it was
deleted, and the OU it was in when it was deleted. I can easily correct my mistake by right-clicking and then clicking
on Restore. Now I hope no one noticed that. If I go back to the Company Users OU, you can see it's back where it
belongs. Now maybe I didn't learn my lesson the first time and I accidentally delete the same user account again. And
then I'll go back into Deleted Objects and click on Restore. Now maybe I need this account restored to a different
location. In this case, I don't want it back in the original OU it came from. I can restore this back to the users
container, for example, if I would like to. And just to confirm it worked, I'll open up the users container, and there it
is. The ADAC approach is very simple, but you should definitely know how to do this from PowerShell, too. I'll open
up a PowerShell admin console and run Get-ADObject. I'll then filter my query to return just the Donna Jones
account. I'll now pop back over to my ADAC and delete him again, then I'll go back over to PowerShell and you can
see this command doesn't work. That's because this command doesn't check deleted objects unless we provide the
IncludeDeletedObjects parameter. So I'll run this again; there he is, and now you can see it says deleted true. And to
get him back, I would simply run that again and pipe that output to the Restore-ADObject cmdlet. And just to confirm
it worked, I'll run Get-ADObject again without the include parameter, and voila, he has returned from the dead. If you
can forego restoring the entire database, it's best not to. You can see that recovering an ADObject is much easier to do
with the Recycle Bin and it's also less dangerous.

Perform Offline Defragmentation of an Active Directory Database

One of the maintenance tasks that you might see on a Microsoft certification exam, but will probably never need to do
is defragmentation of the Active Directory database. Now, defragmenting the AD database removes white space from
the database. It compresses and reduces its size. Although, it's usually not necessary because Active Directory usually
does a good job of taking care of that on its own. If you do need to do an offline defrag of the AD database, the
command to use is called ntdsutil. You may recall this command from one of the previous clips that we did. Now that
I'm in the DC console session, like before, I'll need to stop the NTSD service to take the database offline. I'll run net
stop ntds to make that happen, and now I can run ntdsutil. The first thing I need to do is assign the AD database I'd
like to work with using the activate instance ntds. Now I'll go into the Files menu. From here, you can see the
commands available in this menu. To defragment, I'll use the compact to command. I'll store this in a folder I've
already created called backup. You can call it whatever you want, though. Depending on the database size, this could
take a long time, but my Active Directory demo environment is so small it will only take a few seconds. You can see
the results here both saying it worked and reminding you that now you need to manually copy the
newly defragmented database over the old one, or nothing's going to happen. So if I quit out of ntdsutil and go over to
the backup folder on the C drive, you can see the database file that was just created. Now at this point, you could
override the existing database file with this one, which is what you probably would want to do in a real environment
and restart the NTDS service to force AD to begin using the defragment database. But for now, I don't necessarily
need to overwrite the existing one that I have due to my demo environment, but that's what you should do in a real
production environment.

Cleanup Metadata

One maintenance task you may find yourself doing a bit more frequently than the others I talked about is cleaning up
AD metadata. One of the most common reasons to do this is to remove orphaned objects like domain controllers from
Active Directory. If I go into ADUC and go to the domain controller's OU, domain controllers are always talking to
each other, synchronizing the data back and forth, so having objects in here that aren't actually available isn't a good
thing whatsoever. You definitely want to keep this container limited to just DCs that are really on your domain and
are available and online. You could just right-click and Delete, but in older versions of Windows Server, that only got
rid of the object itself from this location. Not everything related to this DC was removed. To get rid of it correctly and
completely, you needed to use the ntdsutil command-line utility again. It was a nightmare. However, since Server
2008, which is a long time ago, Microsoft has included the metadata cleanup right in ADUC. When you select delete
on a DC after confirming that you really want to delete it, you'll get this dialog box. Because I'm cleaning up after this
DC is gone, I'll select the permanently offline option, then delete. Now I'm warned that it's a global catalog
server. That's okay. All of my domain controllers are, so I'll go ahead and say Yes here. And that's all there is to it. It
is so much easier than it used to be. There's no need to mess around with the NTDS command-line utility and trying to
remember all those menu options that we did way back in the day.