Active Directory is the foundation of most business networks. In this video, you’ll learn about Active Directory services, adding a device to a Windows Domain, adding Group Policies, configuring folder redirection, and more.
If you work in a business or an enterprise, you’ve probably heard the term active directory or directory services. This is referring to Microsoft Active Directory, which is a centralized database of everything that connects to the network. And by everything, I mean all of your computers, your user accounts, any file shares, any printers that you have on your network, anything that anyone needs access to goes into this Active Directory database.
Since we’re storing user account information, usernames, passwords, and other important details, we can use this database as an authentication source. So if we need to log in from anywhere on the network, we can access this centralized database to see if we’re using the correct login credentials. As an administrator, you’ll be responsible for determining if people can access the file shares that they need, or if they can print to the corporate printer.
All of the configuration options to provide that access, set the permissions, and then assign that permission to a user is all contained within the Active Directory database. And if you’re working on the help desk, you’ll be using this database quite a bit to be able to reset passwords, confirm that people are able to access the resources they need, and provide any other support for the Active Directory infrastructure.
The core of this Active Directory infrastructure is the name of the Windows domain. This is a name that is related to this grouping of users, computers, printers and other resources on the network. If you were working at Microsoft, you’re probably on the Microsoft domain. If you’re working at my company, then you would be on the Professor Messer domain.
On the network somewhere is a server that is responsible for maintaining this Active Directory database. We refer to these as domain controllers, and this is where all of this information will be stored. Active Directory has a distributed database that it uses, so making changes on one directory controller will copy and replicate those changes to all of the other directory controllers. On these servers, acting as domain controllers, we are running a service known as Active Directory. So everything that we see on the system will show information about the server and about Active Directory that is running on that server.
If you’re working at the help desk, you probably have this console open most of the time. A lot of your questions will start and end with this Active Directory database. For example, if someone calls in with a problem with their computer, you may want to know if that computer has been added to this Active Directory domain. Or if they are logging in to the domain, you may need to reset their domain password using that Active Directory database front end.
This is the main screen of my Active Directory server. You can see it is the Server Manager. This is what comes up by default when you turn on this server, and there are a number of different servers and processes running on this system. The very first one that we see is the Active Directory Domain Services, ADDS. There are also a number of other services running on this computer. There’s a DNS service, there’s a local server service, there’s an IIS web server, and other services, as well.
Let’s get more information about this local server. I’ll click on the option for local server, and you can see that the name of this server is Cheyenne 1. Cheyenne 1 is part of a larger Active Directory domain, and that domain is called SGC.local. If you were to bring your own computer into your corporate network, it would not simply become part of your Active Directory domain. A system has to be explicitly added to the domain by someone with administrator rights.
That process is relatively simple, but it is required to have that system managed on that domain. You can add a device to the network using the system properties. You can also add a device to the domain from the Settings app under the System option. This is a relatively straightforward process, but it is required to have that system managed by the centralized domain controller. This can also be done at the command line through automated scripting. You can use PowerShell to also provide this functionality.
This Windows 11 computer that I have is in a Windows workgroup, and I would like to add it to my Windows domain. I’m in the Settings app, and if I scroll all the way down in the default system option, you’ll see a link for About. Inside the About, you’ll see information about the device name, the processor, how much memory, and those types of metrics. You also see a link to domain or workgroup.
And if we click that option, it brings up another window that gives us information about the computer name that we’re using, where it is located on the network. In this case, it is in a workgroup, and that workgroup is called Workgroup. That is the default workgroup in Windows. But we would like to add this device to the domain. So we’re going to choose the Change option, and it’s going to ask us how we would like to change this system.
We’re going to keep the same computer name. In this case, the computer is Dedalus. Instead of it being in a workgroup, I’m going to specify that it is in a domain, and we’re going to say that it is the SGC.local domain that we would like to join. And then we’ll click OK. By default, Windows needs administrator access to connect this device to the Active Directory domain, so we’re going to add our administrator login and the password associated with the administrator account, and we’ll click OK.
After a moment, a message appears that says welcome to the SGC.local domain, and we can click OK. Windows then tells us that we must restart our computer to apply these changes. So in order to connect to the domain for the first time, we will restart this workstation. When our system restarts, we have the option to log in as another user, and this would be someone who is signing in to the SGC domain. So let’s add a username and password and see if we can log in.
So now we have a computer that’s part of the domain, and we’ve logged in with a username that is part of the domain. And we can manage both of those from our centralized domain management console. Active directory databases can become very large, especially in organizations where you might have hundreds or even thousands of employees. Each one of those employees probably has multiple devices, and there might be many printers and other devices on the network, as well.
So it makes sense to organize your Active Directory database into logical areas. We refer to these as organizational units or OU. You can create a very specific hierarchy inside of this database that might be separated by the location where somebody may be located, or you might have a different OU for each different building. Or perhaps your OUs are specific to different departments of your company. You might have a marketing OU, a shipping and receiving OU, and an accounting OU.
These OUs become very important when you’re ready to start setting policies on the network because you generally assign those policies to an organizational unit. So if you need to associate one set of policies with the marketing department and another set of policies in the accounting department, you might want to have both of those in separate OUs.
If you’re working in a help desk environment, then you’re probably going to run these utilities on your local workstation. But in our example here, I’m going to run these utilities from the Active Directory server itself. Under the Active Directory Server Manager, there is a tools pull dropdown menu. And in that pull dropdown menu, I’m going to choose the option for Active Directory users and computers. This brings up a utility where I can now access the entire Active Directory tree, and I can look at all of the users and all of the computers on this network.
You can see that there are some OUs that are the default for this domain. For example, the built-in OU, the computers OU, and the domain controllers OU are all standard OUs that are included by default. On this network, the Windows or domain administrator has created some additional OUs. You can see that we have a Milky Way OU, one that is named Pegasus, and another one named Stations.
And if I expand the Milky Way and the Pegasus OU, you’ll see there are computers, printers, and users that you can find in each one of those specific OUs. Inside of the Milky Way, OU is an OU named SGC, and under the SGC OU is the computers, the printers, and the users. And if I click on the users, you can see a grouping of users that are associated with that specific organizational unit. If we right-mouse-click on any of these users, we’ll have the option to add them to a group, disable their access, reset their password, and perform other administrative functions.
And of course, if we need to rearrange where things might be in our Active Directory database, we can certainly do that by moving things from one OU to another. This might be the process you follow when someone moves from one department to another, or they move from one part of the business to another. By moving this object to a new container, you are now applying a different set of policies for that particular user or that computer.
We move these objects from that same Active Directory users and computers application. We right-mouse-click on an object and choose the option to move it. On our network, we’ve been informed that Rodney is going to move from the Milky Way SGC OU to the Pegasus Atlantis OU. To be able to move Rodney, we will right-mouse-click on Rodney’s name, and we’ll choose the option to move. This brings up a separate list of these OUs. We’re going to choose the Pegasus OU, the Atlantis OU, and we will move Rodney into that users folder.
Now, if we click down on the Pegasus and Atlantis OU and look at the users, you can see that Rodney has now been moved into that new organizational unit. Now that we’ve designed our Active Directory tree, we have a number of OUs that are separating our company into logical units. We can now focus on applying policies to each one of those OUs. We would do this from the group policy management editor. And from here, we can effectively manage all of the policies for the organization.
So if we’d like to add a login script, modify QoS settings, or effectively manage any part of the Windows operating system, we can do it by using these Active Directory group policies. When you make a policy change, it usually doesn’t take effect until the user logs in again. But you can force a policy change down to a user system by using the GP update utility. This is the group policy update utility, and you can force it to update a user’s workstation by using the slash force option.
Here is Rodney’s desktop. It is a standard Windows desktop, and you’ll notice in the upper right is the recycle bin icon. What we’d like to do is create a policy in our Active Directory domain that specifies that the recycle bin icon should not appear on the desktop. To do that, we’re going to add a new group policy and push that group policy down to Rodney’s computer. On our domain controller, I’m going to move from the Server Manager, choose the Tools option, and you’ll see there’s an option for group policy management.
The group policy manager allows you to set policies for any of the devices in your Active Directory tree. Inside of our group policy management utility, you can see all of our OUs. And currently, I’m in the Pegasus Atlantis OU. If I right-mouse-click, I have the option to create a group policy object in this domain and link it here. It asks for a name for this group policy object. We’re going to call this Recycle Bin, and we’re going to click OK.
This puts a recycle bin GPO associated with that specific OU. To modify this group policy object, we’ll right-mouse-click and choose the option to edit. This will bring up a separate window that is the group policy management editor. And I know that the policy that we would like to change is under the user configuration, under policies. We’ll choose the option for administrative templates, and then choose the option for desktop.
You can see there are a number of policies that you can configure under the desktop, things like hiding and disabling all items on the desktop, removing the My Documents icon on the desktop. And here’s the one for removing the Recycle Bin icon from the desktop. If I double click that option, I can see that it is configured as not configured by default, but I could enable that policy and then click OK.
You can see in this Group Policy object that is enabled. And now anyone who connects that is part of that OU will have that policy applied to their system. On Rodney’s computer, I’m going to open up the command prompt with a CMD, and I’m going to run the GP update option with the force, and we’re going to hit Enter. That will show us that it is updating that policy. We’re going to wait for it to communicate to the Active Directory server, so that it then makes the changes on this local system.
And once it’s done, it says that the computer policy update has completed successfully, and the user policy update has completed successfully. Notice that this change has not been made to the desktop yet because the recycle bin still exists. So in order to have this take effect, we’re going to log off of Rodney’s account and log back in.
Now, when Rodney starts up his computer, you can see that the desktop no longer has the recycle bin icon at the upper left, which means this group policy object has taken effect. One common group policy option that’s available is to run a login script when somebody first connects to the domain. This can automate a series of tasks that’s in a batch file or a script, and it can run that every time someone logs into the domain in that particular OU.
You can also have different login scripts depending on the OU that someone might be a part of. So you might have one login script for the marketing department, and it’s a different login script than is used in the accounting department. This feature is built into group policy. You can find it in the group policy management editor under user configuration, policies, Windows settings, and scripts. So now we can create login scripts that run when someone logs in, and we can customize those login scripts depending on what OU they might be a part of.
Back in our group policy management utility, let’s now create a login script that will run for everyone who has the Atlantis OU. So we’ll find the Atlantis OU on the right side. We’ll right-mouse-click and choose to create a group policy object. From here, let’s assign this as logon script, and I’ll click OK. And you can see that we have a GPO that has been created called Logon Script. We’ll right-mouse-click and choose Edit. And from here, we will find the option in the group policies that allows us to run a logon script.
In the editor, you will find this under the user configuration, under policies, Windows settings, and there’s an option here for scripts. We want to run a logon script, so we will find the logon option and double click on that. It now asks us to add a logon script into this particular object. And you can choose to add it by using the Add button. And to add a script name, I’m going to click the Browse option.
There is a script that has already been configured and is in this folder called logon map share. So that we know what this is going to do, I’m going to right mouse click and choose the option to edit this script. It asks us to open that particular file because we are opening it with a different user than the original one. And you can see that it is a one-line script. It has a net use command. It has net use G colon. So it’s mapping the G drive, and it’s mapping it to a share that is on the Cheyenne 1 server.
This is the Cheyenne 1, and the name of the share is Missions. Let’s now close out that editing session, and we’ll choose that option and choose open. It’s going to add that as our script name for this particular policy, and we’ll click OK. We now have a login script that is linked to this Group Policy, and that group policy is within the Atlantis OU.
Back on Rodney’s computer, I’m going to start the File Explorer, and I’m going to choose the option for this PC. So we can see all of the different drives that might be associated with this computer. You can see our local folders are at the top, our folders for desktop, and documents and downloads. And we have two drives that are currently available on the system.
There is the C colon for our local disk and a D colon that is for the DVD drive. What we’ll do now is log out and log back in, and let’s see what the results of our log in script are. From the login page, we’ll add our password. We’ll log in with Rodney’s login name. And let’s start up our File Explorer again once it finishes the login process. I’m now going to choose this PC, and you can see that a new drive now appears automatically after logon. It is our mission share that was created from that logon script.
Now that we’ve got a login script for our users, it would also be nice if we had a network-based home directory that they could use to store all of their documents. This allows them to store information on a network drive, rather than storing them on a local system drive that’s on their local machine. This allows people to store documents on a network drive instead of storing them on their local machine.
This allows us to have all of our user documents in one place, which certainly makes it easy for management and for backup. We’ll modify each user’s profile so that we can create a single drive that they’ll be able to access whenever they log on. This doesn’t require every user to store their documents in their network-based home folder. But with a little bit of training, you can get them out of the habit of storing things on their local drive, and instead storing all of their documents on their network drive.
On Rodney’s computer, by default, you can see that we have our G drive that we created during that login script, and there’s no other network drives associated with Rodney’s computer. Let’s modify the profile of our users so that each one of them has their own private home drive. To make this change, we’ll want to modify the profile of each of these users. And in this case, we’ll choose the Pegasus and Atlantis OU. And we’ll select all of the users that happen to be in that organizational unit.
If we right-mouse-click on that group, we can choose the option for properties. In this properties page, there is a profile tab, and under profile is an option for home folder. You can see the default for the home folder is to use a local path. But in this particular case, I would like to use a network path, so I’ll choose connect. And I’ll choose an H drive that we’ll use for all of our users. Now we need to specify the share where all of these home folders will reside.
And in this case, this will be on the Cheyenne server. So I’ll specify Cheyenne 1, and then I’ll specify the home directory. Since I’m making this change for multiple profiles, I’ll use the username as a variable. So we’ll use the percent sign, username, and another percent sign. Now if I click OK, I’m brought back to the main screen, and that home profile has now taken effect. To see if this change has taken effect, we will log out of Rodney’s account and log back in again.
So now let’s start our file manager. And under this PC, you can see that we have our G drive that was created as our login script. And we have a brand new H drive that is our home directory on that Cheyenne 1 server. Now that we’ve created a private drive where every user can store their personal documents, we may want to consider redirecting the entire Windows library to a network share.
Normally, when someone stores a file on the desktop, in a downloads folder, or in the documents folder, it is storing it on that local computer’s storage drive. We might want to instead redirect all of those folders to a central network share, so that we can easily back up all of our users’ data. And the users don’t even have to think about it when they’re clicking on these Windows library folders.
To do this, we need to create a group policy that is located in user configuration, policies, Windows settings, and folder redirection. Since we’re redirecting the Windows library to a network share, we have to think about what happens with those files when we leave the building with our laptop. Usually, the folder redirection is often paired with the Windows offline files feature. This means there will be a local version of those files for people to use. And when somebody returns with their laptop, all of those changes to the local files will be updated with the centralized Windows library files.
Inside of the group policy management editor, we will choose the option under user configuration, under policies. We will choose the option for Windows settings, and under the Windows settings, you’ll see an option for folder redirection. If we right-mouse-click on the documents folder, we can choose properties, and you can see that the setting is not currently configured. We’ll choose the basic configuration for this, and we’ll leave the default as to create a folder for each user under the root path.
We now need to specify a root path for every user’s document folder, and I’m going to specify a root path that is on the Cheyenne 1 server. So we’ll specify the server name with the two backslashes. We’ll put in the Cheyenne 1 name, and we’ll choose a folder, in this case, that is the home folder. That home folder will be the one that every user is able to take advantage of, and you can see that it gives you an example of this.
So it will be on the Cheyenne 1 server under home. It gives an example for Claire, and you can see that it is the documents folder. That is exactly what we’d like, so we will click OK. And you will see that it presents a message that says, “This group policy setting will not apply to Windows 2000, Windows 2000 Server, Windows XP, or Windows Server 2003.”
In this case, we’re not using any of those Windows versions, so we will say yes, we would like to continue. And our group policy has now been configured. Back on Rodney’s computer we’re going to open the File Explorer. I’m going to right-mouse-click on the documents folder and choose the option for properties. This properties option under the location tab shows us the default setting before the group policy is applied. You can see that it is set to C colon, backslash, users, backslash, R MacKay, backslash, documents.
So anything stored into the documents folder on this computer will automatically be stored on the local drive. For this to take effect, let’s go down to our search menu. I’m going to go to the command prompt, and let’s force a GP update. We’ll perform a GP update and choose force, and we’ll have this update the policy on this local computer. This gives a message that the group policy client-side extension folder redirection was unable to apply one or more settings, and we will need to log on to be able to have this particular setting take place.
Is it OK to log off? Yes, it is, and we will hit Enter. Now, from the login page, we will put in Rodney’s password, we will get back to our Windows desktop, and let’s start up our Windows Explorer and see what the differences are with this new change versus what we looked at before. Let’s right-mouse-click on the documents folder, show the properties, and under the location tab, you’ll notice that now our documents folder is going to the Cheyenne 1 server under the home folder, R McKay, and documents.
Now, anytime we store anything into our documents folder, it will be stored on the Cheyenne 1 server instead of being stored on our local computer. In Windows, you can assign rights and permissions for a file, for a folder, or other network resources to an individual user. So we could go into Rodney’s account and configure all of the file settings that are appropriate for Rodney.
But when you’re in a large environment with hundreds or even thousands of people, it may not be possible to go to each individual user to configure individual permissions. Instead, you might want to create a Windows group. This group can be configured with all of the permissions you might need, and then to activate those permissions for the user, you simply add the user to that group. If you need to remove permissions from a user, you simply remove that user from the group. And of course, you can add or remove large groups of people all at the same time.
There are a number of groups that are built into the Windows operating system that you don’t have to add. For example, you can see account operators, backup operators, guests, performance log users, and others. Using groups as a way to provide these rights and permissions saves a lot of time and avoids any errors that you might make if you were trying to individually create permissions on every user account.
Back in our Active Directory users and permissions, let’s see what groups Rodney is a part of. We’ll right-mouse-click and choose the option for properties. Under properties, there’s a tab called Member Of, and this will list out all of the groups associated with that user. If you’d like to add this user to another group, you can simply choose the add button at the bottom. This screen that pops up is very common when you’re trying to browse all of the different users and groups on a system.
Instead of presenting you with the entire list, Windows presents you with a search box that you can use to find what you’re looking for. Let’s say in this case that we would like to add Rodney to a group of users that have access to remote desktop. So if I type in the word remote and I hit enter, it will show me all of the matches for that particular term. In this case, there are two of them, one that is a remote desktop users, and one that is a remote management users.
In this case, I’d like to add Rodney to the remote desktop users, we’ll click OK, and now Rodney has been added to the remote desktop users group. All of the rights and permissions associated with the remote desktop users group now also apply to Rodney. This makes it very quick and very easy to be able to manage large groups of people that need access to very different resources.
If you’re in the accounting department, we can add you to the accounting apps group. If you’re in the marketing department, we’ll add you to the marketing apps group. And now that this group has been associated with the user, the user now has all of the rights and permissions associated with those group properties.