The Active Directory database maintained by Windows Domain Services is a core component of any large Windows installation. In this video, you’ll learn about Active Directory, Domain Services, Organizational Units (OUs), login scripts, Group Policy, home folders, folder redirection, and security groups.
In this course, we’ve spoken often about Active Directory, and that’s because Active Directory is the foundation of most corporate networks. On Active Directory, you have a database of everything that’s been configured on your network, including users, computers, printers, and all other devices. Active Directory is also your central database for your authentication. So when someone logs into the domain with their username and password, those credentials are checked against the credentials that are already saved in Active Directory.
Active Directory also centralizes access control so we can assign access for certain user or group of users inside of Active Directory. So if you’re getting your first job in IT on a helpdesk or service desk, you’ll be accessing the Active Directory database quite a bit to reset passwords for users or to add and remove accounts from the domain. You often hear those terms used almost interchangeably, Active Directory and a Windows domain.
A Windows domain is a name that we can associate with a group of users, computers, printers, and anything else that might be on that network. All of this information is stored in a central database on this domain. And we access that database using the Active Directory service. This now becomes a central point for troubleshooting or finding out more information about what’s on the network.
So when somebody asks if this computer has been added to or removed from the domain, you can find out in the domain configuration. Or if you need to reset a user’s domain password, you would do all of that from the same front end. I’ve created a Windows Server running an Active Directory domain. You can see that I’ve got a local server. There’s Active Directory Domain Services, there’s DNS, and there’s file and storage services all running on the same server.
If we look at the local server information, you can see that it has been configured for a domain SGC.local. And you can also see that this is a Microsoft Windows Server 2022 standard evaluation that I’ve downloaded from Microsoft just to create this domain environment. I’ve also downloaded an evaluation version of Windows 10 so we can add a user to this domain and begin setting policies for that user.
If you can think about managing all of the users and computers for a very large organization, you can have tens, hundreds, or even thousands of devices and users that you need to manage. Fortunately, the domain database could be managed using a concept called organizational units, or OUs. This means that you could have all of your users in one single group or one single organizational unit or you could create separate OUs use for each department within the company.
You get to decide how you would like to build out all of the separate OUs use for your Active Directory domain. So you can have one OU for each country, an OU for each state, maybe separate buildings, or departments. And you get to decide exactly what mix of these makes sense for your organization. Once you’ve created the OU, you can then apply policies to that OU. So if you have certain policies that should be applied to certain buildings, it might make sense to have different OUs for different buildings.
Or if you need to apply policies based on the location of a particular site, you can create separate OUs use for each individual remote location. Let’s look at how the OUs use have already been configured so far on my SGC domain. Under the Tools pulldown menu, I’ll choose Group policy management on the left side. This shows us the SGC.local domain.
You can see within that domain that I’ve created a number of OUs, specifically the Milky Way, Pegasus, and Stations OU. Within the Milky Way OU is another OU for the SGC. Within the Pegasus OU is another OU for Atlantis. And within the Stations OU is another OU for Midway. So you can start to see how you can build a hierarchy of these different OUs and then apply different policies to different parts of the hierarchy.
To see the list of users and computers that have been added to this domain that could then be added to a particular OU, let’s click the Tools menu. And we’ll choose the option to view the Active Directory Users and Computers. This will bring up a list of all of those OUs. And you can see, there’s the Milky Way, Pegasus, and Stations. And if we look under the Pegasus OU, which has the Atlantis OU inside of it, let’s click the Users. And we can see all of the users that are configured under that particular organizational unit.
Now that we have a hierarchy of organizational units, we can start applying policies to those OUs. Let’s start by adding a script that is going to run each time a user logs in for a particular OU. These login scripts will automate a series of tasks. So if you’d like someone to always have a particular drive mapped when they log in or automatically share a particular printer, you can do that through the login scripts.
To do this, we would first write a script. And that script would provide the drive mapping or the printer sharing that we would like to use when someone logs in. We would then apply this script to a particular organizational unit in your group policy management. When you edit that group policy, you would configure, under User Configuration– Policies– and Windows Settings, an option for Scripts. Because you’ve created this hierarchy of OUs, you can assign different scripts to different organizational units. This allows you to customize what a user will see when they log in based on what organizational unit they happen to be a member of.
Before we make any changes, let’s look at a current configuration for a user that’s logged in to the Atlantis OU. You can see in the File Explorer for this user, under This PC, that we only have two drives that have been assigned. One is the C drive, which is the local drive on this computer, and a DVD drive, which has been assigned the D colon. We would like to automate the process of mapping a drive each time this user logs in. So let’s create a group policy with that script.
Let’s create a login script that will be used for everybody within a particular OU. Let’s go to the Tools menu, and we’ll choose the option for Group Policy Management. Normally you wouldn’t run these utilities on the Active Directory server itself. You would run these utilities on your own workstation, and it would communicate across the network to the Active Directory server. But to simplify this process in this demonstration, I’m running these utilities on the AD server, and we have a separate computer that will be the user.
Inside of Group Policy Management, I’m going to choose the Pegasus OU. And within the Pegasus OU, there is an Atlantis OU. And that’s where I would like to create a login script for everybody who’s stored under the Atlantis OU. We’ll right-mouse click and choose the option to create a group policy object in this domain and to link it here. I’m going to call this our logon script. And I’ll click OK.
There’s the logon script. We will right-mouse click and edit that script. And it will bring up the options on the left side to configure this policy for computer configuration or user configuration. For logon scripts, we’ll find that under the User Configuration– Policies– Windows Settings– and Scripts.
Now that we’ve selected the area of the group policy editor that contains the logon scripts, I’ll right-mouse click on Logon and choose Properties. You can see the logon properties shows no login scripts that are currently configured in this group policy. So I’m going to add one, which gives me the option to add a script name. Instead of adding it or typing it in, I’m going to choose the Browse option. And under the bar at the top, I’m going to choose the sgc backslash netlogon directory.
Under that Netlogon directory, I’ve already created a batch file. If we look at it very quickly– we’ll choose Edit– you can see it’s a very simple script. It’s a single line with a net use command with a G colon. And then SGC-AD is the server. And the share name is files. So if someone logs on who’s part of this OU, this group policy will run this batch file and automatically map that drive for the user.
Let’s close that view, and we’ll choose that file and choose Open. It will then add that file into the script name. And it adds it, and we’ll click OK and then click OK. We’ve now added that script to this particular group policy. And we can now see if that group policy can be applied when a user logs in.
I’ve now switched over to the user that is under this particular Atlantis OU. And if you recall, all they had were two drives that were originally configured, a C drive and a D drive. Now let’s log off of this user, log back on, and see if our logon script runs.
Now that we’ve rebooted, let’s log in as this user. I’ll add their password, and we’ll load up the Windows desktop and see what we can find under File Explorer. Here’s our File Explorer front end. I’m going to choose the option for This PC. And you can see that we now have a G drive that has been mapped to SGC-AD, and it has the file share.
You can change a vast number of Windows configurations from the Group Policy Editor. And you would manage everything within that single utility. You can add login scripts, modify the way that Windows operates or the way that it looks when a user logs in. You can view all of the group policies from the Group Policy Management front end. And when you drill down into a group policy, you can make changes with the Group Policy Management Editor.
This allows you to go to one single utility and be able to manage any device and any user across the entire domain. This allows us to manage any size network, whether you have 10 users or 10,000 users. In the login example, I logged out so that we could see the results of the login process. But if you’re using a group policy that doesn’t require someone to log out of their system, you could potentially have that group policy applied by using the gpupdate utility on a user’s computer. If you use gpupdate by itself, it will simply add anything that has been changed with the policies. But if you’d like to update all of the group policies for that user, you can use gpupdate/force.
Another useful way to manage content for your users is to create a single drive on the network that they can use to store all of their files. This would keep all of the user’s files on the central network share. This also allows you, as the network administrator, to back up that share so that you have all of that data protected. If a user happens to delete a file accidentally, you can go back to the backups and restore that file for the user. That’s not something that’s very practical if the user is going to store their files on their local computer, especially if it’s on a laptop that they tend to take home with them at the end of the day.
To be able to centralize this, we would make changes to a user’s profile that modifies the home location from their local computer to this centralized network share. This might also require that you tell the user to store information into this home folder rather than storing information onto their local machine. But there are some ways within Group Policy to force that process, so the user doesn’t even have to think about it.
From your local machine, you would launch the utility to configure the Active Directory Users and Computers. Since I’m already on the Active Directory server, I’ll simply use the Tools pulldown, and I’ll choose the option for Active Directory Users and Computers. This will bring up the utility for the users and computers. And you can see that I do have the Pegasus and Atlantis OUs already marked. And the users underneath that OU are listed on the screen.
I would like to change that home directory for all of the users. So I’m going to choose the first user, hold down the Shift key, choose the last user so that all of the users in that particular OU are selected. Now let’s right-mouse click. And for all of these, let’s choose Properties. When this comes up, it tells us that multiple users are selected and you would make changes to the General tab, Account tab, Address, Profile, or Organization.
We want to change the profile for these users. So if I choose the Profile tab, you can see there’s an option for Profile Path, Login Script, and Home Folder. I’m going to choose Home Folder because I’d like to change the location of the current home folder. And under that home folder, I’m going to choose Connect and then choose the H drive and then specify where I would like that home folder stored. Ideally this would be a share that’s already configured on the network.
So I’m going to choose, on the SGC-AD server, a home directory that I’ve already called Home. And then to specify that this home server will be for that specific user, we’re going to use a variable. And that variable is percent sign, username, and then ends with percent sign. Now any time a user logs in, that %username% will be translated to their login name.
To create those home folders for those users, we’ll click OK. And behind the scenes, we’ve updated this share with all of the user names that are in this particular OU. Now, let’s have a look at what this looks like over on the user side. If you recall earlier for this user, we had a C drive, a D drive, and we recently added a G drive in the logon script. Let’s try logging off and logging back in, and let’s see what the results might be.
Now, let’s log back in for this user and see if there’s any difference in our File Explorer. I’ll click on the File Explorer down here. And we’ll choose the option for This PC. And you can see that now there’s a new H drive that’s pointing to a home directory.
Now that we’ve created this home directory in a centralized server, we can hope that our users would use that directory to store their files. There’s nothing that we’ve created that would force a user to store files into that folder, which means they still could store files locally on their computer. But there are ways to redirect folders in Windows. So instead of clicking Desktop, Download, Music, Documents, and other folders on a local machine, it really redirects those folders to a server.
To redirect users to this network share, we would create a group policy and configure the group policy under User Configuration– Policies– Windows Settings– and Folder Redirection. You might already be thinking that there might be some downsides to putting all of a user’s folders onto a server that’s on the network, especially if they have a laptop that they take with them when they’re away from the network. Fortunately, Windows includes options to be able to use files in an offline mode so that you can still access those files and make changes. And when you come back to the network, those changes are updated on the network share.
This configuration is done as a group policy, so I’ll choose the Tools option and choose Group Policy Management. This group policy will be created under our Atlantis OU. And I’m going to right-mouse click and create a GPO in this domain. And let’s call this Documents Redirection. And we’ll click OK.
Now we have a Documents Redirection group policy that we can then edit. And under this edit, we’re going to go under User Configuration– Policies– Windows Settings– and Folder Redirection. You can see that it lists out all of the folders that you can redirect in Windows. Let’s start with the Documents folder.
If I right-mouse click the Documents folder and choose Properties, I can choose the option to specify the location of the Documents folder. We’re going to choose the option to perform a basic redirection, which redirects everyone’s folder to the same location. When I choose that option, I can see that I can create a folder for each user under the root path. And our root path, we’re going to choose SGC and Home.
Since we already created this Home folder for all of our users, we can take advantage of that and use this also as our home folder for all of our redirected folders. You can see that by adding SGC Home, that every user will be redirected to that SGC Home with their username and the subdirectory documents. We’ll click OK to apply that group policy. And it says this group policy will not be redirected if users are using Windows 2000, 2000 Server, Windows XP, or Server 2003. We’re not using those operating systems, so we’ll click Yes to continue. Now, we can perform a gpupdate on that user’s workstation and see if that global policy applies to their documents folder.
Before we make any changes, let’s look at where this Documents folder is currently configured. I’m going to right-mouse click on Documents, and we’ll choose the option for Properties. Inside of the Properties, you can choose the option for Location. And you can see currently that this Documents folder is stored on the user’s hard drive under C colon backslash users rodney dot mckay backslash documents. Now let’s perform a gpupdate and see if that changes in File Explorer.
Let’s go down to the search that’s on the toolbar. I’ll choose the option for Command Prompt, and then we’ll perform a gpupdate. And then I’ll also choose Force to make sure that all of the group policies are updated on this person’s computer. Now it goes through the process of updating the policy. As we can see, the group policy update has completed successfully. It does say there were warnings created because there is a client side extension for folder redirection, which can’t be applied because you have to log off and log back in. We are going to say Yes to log off.
To check our folder redirection, we’ll log in as the user. We’ll choose our File Explorer at the bottom. And then we’ll look at the Documents folder to see where it has been redirected to. We’ll click the Properties option, choose the Location tab, and you can see that the location for the Documents folder is in the SGC-AD server under backslash home backslash rodney dot mckay backslash documents. And if we double click on the Documents folder, the group policy has already copied over all of our documents. And now it appears that we’re using the documents on our local computer, even though we’re being redirected to a network server.
In Windows, we could go through each individual user in the domain and specify what rights and permissions that particular user might need to be able to perform their job function. But of course, if your domain has hundreds or even thousands of users, it’s not practical to go to every single user to customize their rights and permissions. Instead, we would create a security group, specify rights and permissions for that group, and then add users to that group to provide them with the rights that they need.
This is much faster than configuring individual users. We could set up predefined groups with all of the permissions we might need and simply add the user to that group. So if they’re in shipping and receiving, we will add them to the Shipping and Receiving group. And anyone in that group has the rights and permissions to be able to create labels for all of the shipments. But if you’re a manager in shipping and receiving, you might need additional rights and permissions to be able to run reports and see how much money you’re spending on shipping. So we might want to create a separate security group called Shipping and Receiving Managers and add all of the managers to that group so they get the rights and permissions they need.
If you look inside the Active Directory Users and Computers utility, you’ll see a number of groups that are already available. There’s a User group, a Guest group, a Remote Management Users, Event Log Readers, and many more. You can, of course, add on to this list of groups and create as many groups as you need to manage your domain. This will save you a lot of time, as you configure these rights and permissions in one place and then apply those permissions to hundreds or even thousands of users.