21 Effective Active Directory Management Tips

This is the most comprehensive list of Active Directory Management Tips online.

In this article, I will share my tips on, AD design, naming conventions, automation, AD cleanup, monitoring, Active Directory user management, and much more.

Check it out:

1. Active Directory OU Structure Best Practices

If you don’t have a good Active Directory organization unit (OU) design you’re going to have problems.

First, I’ll quickly explain the three main reasons why good OU design is so important.

  • Reason #1 Group Policies – Having a good OU design will make implementing and managing group policies much easier. I’ve seen a drastic decrease in issues with proper OU design.
  • Reason #2 Delegate permissions – Being able to delegate rights at a granular level and auditing those rights is a must. A proper OU structure will allow you to easily delegate permissions at a granular level.
  • Reason #3 Administrative tasks – Modifying user accounts, using LDAP queries, reporting, and bulk changes are all common administrative tasks.  If Active Directory is a mess, these simple day-to-day tasks can become difficult for the whole team.

Now that I’ve explained why OU design is so important, let me show you my tips for good OU design.

OU Best Practice #1: Separate Users and Computers

Do not put users and computers into the same OU, this is a Microsoft best practice.

Instead, create a new OU for Users and an OU for computers.

Next, create sub-OUs for each department or grouping.

Do this for both computers and users.

Next, create OUs for specific functions or grouping of similar objects. Here are some examples that I use:

  • Conference room computers
  • VDI (Virtual desktops)
  • Test computers
  • Generic accounts
  • Service Accounts

I’ll create an OU for each one of these functions.

You can structure the sub-OUs in any way you like, it basically comes down to how you plan to manage the users and computers. In organizations I’ve worked at, it made the most sense to manage them by department and specific functions. The most important tip is to group user and computer objects into separate organizational units.

Active Directory Design Best Practices Example 

Here is a real-world example of how a good OU structure makes managing Active Directory easier.

A customer had a domain policy that locks the computers after 15 minutes of inactivity. This policy was applying to every computer in the domain.

This became a problem for conference room computers, users would be teaching or giving a presentation and the screen would keep locking.

To fix this I just created a sub-OU called conference room computers and moved the affected computers into this OU. I created a new Group Policy object that changed the lockout time to 60 minutes and applied it to this new OU.

Now, these computers still inherit the policies from their parent while applying the new timeout policy.

Problem solved!

OU Best Practice #2: Create an OU for Security Groups

At first, I put security groups into department folders.

It made sense at the time.

BUT….I was wrong.

What happened was, I would have groups that were not department specific.  Where do those go?

They would end up in various places and then no one could find them.

To fix this mess I created a group just for security groups.

Just like users and computers, I can create sub-OUs to group them by department or function.

This works great, I know exactly where all the groups are and can organize them any way I want with sub-OUs. For example, if I or someone on my team needed to give a user access to a shared folder, I would know these groups are in the Shared Folders OU.

OU Best Practice #3: Create an OU for Servers

You want to keep your servers in their own OU. You will have group policies that need to apply only to servers and not workstations and vice versa. I can also create sub-OUs to group specific servers for whatever need.

Now I can apply policies to all the servers or specific ones.

Active Directory structure and design are very important. If you implement the design tips above it will make managing Active Directory much easier. You will have the flexibility to apply group policies, delegate control, and administer AD objects.

2. Use a Standardize Naming Convention

No matter if your organization is big or small you need to standardize the naming of Active Directory objects.

Here are my tips for good naming conventions.


The most popular option is users first initial + last name.

I’ll use “Joe Smith” as an example.

The user name would be: jsmith

The next popular option is complete first name + last name (use a special character to separate the name).

The user name would be: joe.smith

Both methods work well and are user friendly. The one problem you may run into is duplicate user names.

To fix this just add in the middle initial.

For example, I have Joe Smith, then I get a new employee with the name of Jane Smith. The user name for Jane will be the same as Joe so I need to use Jane’s middle initial.

Jane’s middle initial is A, so the username would be jasmith. or jane.a.smith

I would avoid naming conventions that truncate names or include numbers. It’s just too confusing for everyone.


Here is my template for creating groups.

Department or group + resource + Permissions

Let me break this down

  • Department or group – You can use the full department name or an abbreviation. It some cases it may not be a specific department it may be users from various departments so just come up with a name for this group.
  • Resource –  This should define what the group is being used for, it could be one word or a few words (separate words with a hyphen)
  • Group Prefix: When you create a group you must select a group type, I use a prefix to define what group I’m using.
    • Domain local = L
    • Global = G
    • Universal = U
  • Permissions – The permissions will you apply to the resource
    • R = Read only
    • RW = Read, write

Here are some examples

Example 1 – Helpdesk staff needs rights to reset passwords.

Security group name would be: Helpdesk-PasswordReset-G

Example 2 – HR department needs training folder locked down

Security Group name: HR-Training-Folder-G-RW

Example 3 – Sales department want shared calendar locked down

Security group name: Sales-Shared-Calendar-G-RW

Once I got all my groups renamed following this naming convention it made it much easier to find and use them.

Computers, Servers, and other AD Objects

For most other objects I follow this naming convention:

Type + department or location code + asset#

  • Type
    • W = Workstation
    • L = Laptop
    • P = Printer
    • S = Server
    • V= VDI or virtual machine
  • Department: Use two letter appreciations for departments or use a location code
    • HR = Human Resources
    • MR = Marketing
    • SA = Sales

Here are some examples

Workstation in the IT department asset# 1234


Laptop in the HR department asset# 1235


Printer in the sale department asset # 1233


Create a clear naming convention that the whole team can follow, and I’m not just talking about users and computers. Create a naming convention for all objects

3. Monitor Active Directory with Premium Tools

Active Directory is the heart of the network, if it stops beating then everything else dies.

I know FREE tools are great (I use plenty of them) but when it comes to monitoring I rely on professional tools.


It saves me serious time and it provides other IT staff with easy to read metrics on servers and applications.

Here are a few favorites:

SolarWinds Server & Application Monitor – I like this tool as it allows me to monitor any application on any server. Monitors all the components and services that make Active Directory run. If Active Directory is having issues or is slow this program will quickly identify the issue.

SolarWinds Network Performance Monitor – Excellent tool for monitoring the network, bandwidth, CPU, Memory, and many more metrics on any device that supports SNMP.

Netfort Languardian – This is a deep packet inspection program that monitors the network and user activity. Although it may be considered a networking tool it has tons of use cases. I can find out who deleted a file, monitor DNS, find rogue DNS servers, monitor bandwidth to servers and active directory, and much more.

ManageEngine Audit Plus – Provides real time auditing to Active Directory. Track changes to AD objects, user activity, DNS, GPO, and more.

There are plenty of professional tools on the market, I recommend you search around and find what best fits your needs.

4. Use Core Servers (When possible)

Server Core has a smaller footprint, is more secure, and doesn’t require as many updates.

Bonus benefit fewer reboots!

I was skeptical at first when Microsoft said this is the preferred install option. But after running core servers for a few years they ROCK. They are stable, and they really do have fewer updates.

Unfortunately, they don’t work in every situation.

Not all 3rd party applications support core servers.

They work great for Windows servers such as domain controllers, DHCP, DNS.

So, install core servers when you can and reap the benefits.

Here is a nice table that summarized the benefits of server core


5. Know How to Check AD Health

Issues with domain controllers, DNS, and replication are going to cause all kinds of problems.

Here are some quick tips for checking the health of Active Directory.

Use dcdiag to check domain controllers

Dcdiag is a command line tool that analyzes the state of domain controllers in a forest or enterprise and reports any problems. It is built into most Windows server operating systems, it is also included if you have the ADDS or ADLDS role installed.

Use the following command to analyze the health of your domain controllers.

dcdiag /s:servername /a

This will run several tests on various components and services that run on a domain controller.

You will get a fail on any tested that does not pass.

Use dcdiag to test DNS

Use the command below to test dns

dcdiag /test:dns /s:servername

You can in the screenshot the test has detected some issues with my dns

Looking through the tests I’m missing some A and SRV DNS records

Use repadmin to test replication

Use the following repadmin command to test replication between your domain controllers.

repadmin /showrepl

6. Use Security Groups to Apply Permissions to Resources

DO NOT use individual accounts to apply permissions on resources (printers, shared folders, applications, calendars, etc).

Instead, use security groups.

This makes adding and removing users to resources much easier. It also helps with reporting and audits.

Once the groups are set up on the resources you don’t have to go to each resource every time to modify access.  You just update the group.

Using the group naming convention from tip# 3 this works like a charm.

Here is an example.

I have a folder called training in the sales department.

I will create a group called HR-Training-SG-RW (This following my naming convention tips#)

Then I’ll add this group to the permissions on this folder.

Now anytime I want to give permissions or revoke a user’s rights to this folder I just modify the members of this group.

I can use the method for all resources.

7. Cleanup Active Directory (at least once a month)

Over time, Active Directory will have stale users, computers, and group accounts.

To keep Active Directory secure and tidy you need to find these stale accounts and remove them.

It is recommended check AD at least once a month for inactive computers and inactive user accounts. There are plenty of scripts and GUI tools available that help with finding and removing old accounts.

The AD Pro Toolkit includes several AD Tools for cleaning up Active Directory.

I run this cleanup process once a month.

8. Add Descriptions to Active Directory Objects

It’s frustrating to see objects in Active Directory and have no idea what they are for.

Even if you are using a good naming convention I still like to add descriptions to objects. Obviously not all objects, but servers, groups, service accounts, and generic accounts I put descriptions on them.

Not only does this help me quickly identify the use of the object it helps the whole team understand.

You can see in the screenshots below I’ve added descriptions to some groups and service accounts.

Here are some non standard accounts, again using the description field I can easily see in Active Directory what these are for.

Again, I don’t do this for all objects, mainly groups, servers, and non standard accounts.

It’s another big time saver.

9. Use Delegation Control Wizard to Set Permissions for non admins (helpdesk)

Active Directory delegation is important to understand so that permissions can be granted without adding users to privileged groups like Domain admins.

Using delegated permissions, you can use the least privileged access method. (Give only rights that are needed)

This helps with security and compliance.

Here are a few examples of why you would need to delegate rights.

  • Helpdesk needs to reset passwords
  • Update user account info such as phone number or address
  • Give rights to add and remove computers from domains.
  • Create, delete and manage user accounts
  • Modify group membership

In this video, I will give our helpdesk group the rights to reset passwords.

YouTube video

10. Audit Changes to Active Directory

Active Directory auditing is the process of logging changes and events in Active Directory.

Auditing is important for security and compliance reasons.

You should at least be auditing active directory for the following events:

  • Failed logon attempts
  • Any changes to objects
  • Successful logons
  • Modifications to Privilege Accounts
  • Group Policy Changes
  • File/Folder deletes

Before you can audit Active Directory, you must first set up an audit policy.

Steps to audit Active Directory

Step 1: Enable auditing on the domain controller

Step 2: Enable events to audit

Step 3: Review and maintain the audit logs

The above steps are a high level overview.

For detailed steps check out these resources:



11. Track Down the Source of Account Lockouts

Random account lockouts are not only frustrating to the end users but for helpdesk and the admin who is troubleshooting it.

Knowing how to track down the source of account lockouts is something all systems admins need to know.

Mobile devices and user accounts set to run a service are the most common reasons for account lockouts.

12. Automate Common Active Directory Tasks

I would encourage you to automate anything that you can.

Active directory administration involves many routine tasks such as user account creations, modifications, account removals, computer management, security, and so on. Some of these day to day tasks are very time consuming.

Most routine tasks can be automated to make you more efficient at your job.

Here are some common tasks that you should automate:

  • User account creation
  • Account removal
  • Account modifications
  • Group Membership Management
  • AD cleanup
  • File copies, directory cleanups
  • Software deployment
  • Windows and 3rd party patches
  • Inventory
  • Decommission of assets

It may be difficult to automate the entire process of some tasks but automate what you can. Automating any part of a repetitive task will save time.

PowerShell is a tool for automating a lot of these tasks.

My team recently automated the whole user account creation process using PowerShell. This involved many steps such as creating the account, adding to groups, creating an office 365 mailbox and creating a personal shared folder.

Creating user accounts has never been easier.

13. Understand LDAP Distinguished Name Paths

Active Directory is an LDAP (Lightweight directory access protocol) directory service, this means all access to objects occurs through LDAP.

LDAP uses paths to locate objects, a full path of an object is defined by its distinguished name.

When integrating other systems with Active Directory it often requires some LDAP information.

Unfortunately, every program does this differently. Having a little knowledge of distinguished paths will help with integrating other systems with Active Directory.

In most cases you need the distinguished name for the following:

  • Domain name
  • User account (That has read access to AD)
  • OU where users are located

Here is how you find the distinguished name

Step 1: Open ADUC and browse to the account

Step 2: Right click on the account and select properties

Step 3: Select Attribute editor

Step 4: Find the attribute distinguished Name, then click the view button

The distinguished name for the user Pam Smith is:

CN=Pam Smith,OU=Accounting,OU=ADPRO Users,DC=ad,DC=activedirectorypro,DC=com

Repeat these steps for any other object that is needed.

14. Use Service Accounts (with least privileges)

There will be a time when you need to run a task, script or program with a user account (domain or local).

These are referred to as service accounts.

First of all, don’t use a domain admin account or any other user account for these.

Instead, create a new account to use for each specific service.  Your user accounts should have a policy to change their password every x days. If an account is being used and its password changes that service is going to stop working.

Here are some additional tips:

  • Use a descriptive name
  • Document the account and add a description in Active Directory
  • Create long complex passwords
  • Set account to never expire
  • Restrict what the account can log into
  • Audit and monitor service accounts usage
  • When possible create local service accounts instead of domain accounts
  • Give the service account the least privileges
  • Don’t use one account for multiple services.

15. Delegate Tasks When You Can

No, I’m not talking about delegating rights to helpdesk.

Over the years the responsibilities of System and network administrators have skyrocketed. Some system administrators are responsible for almost everything from the server down to a printer.

To save your sanity be willing to delegate some tasks to others outside of your team.


I was hesitant about this for years. I worked hard to get everything in order, procedures down, and keep systems running 24/7.

BUT as responsibilities grew it reached a point where productivity was down. New projects were slow to roll out.

To resolve this, I learned that it was OK to delegate tasks outside of my team.

Here are a few tasks that I delegated:

  • Account setups and removal
  • Managing Print Servers
  • Modifying Account attributes
  • Adding and removing domain computers
  • Software distribution
  • Modifying group members
  • Patching workstations

Talk to supervisors, talk to other staff members that are willing to take on these roles.

If it doesn’t work out simply revoke their rights and take the task back over (I’ve had to do this a few times).

16. Use Restrictive Groups to Control Local Groups

Restricted groups allow you to centrally manage who is a member of local groups on workstations and servers.

One common use of this is to add an Active Directory group into the local administrator’s group on all computers. This is an easy way to give your helpdesk or other IT staff admin rights on all the workstations.

It’s also a great way to prevent users or other staff from adding users to the local admin group.

Regular users should not have admin rights, I’ve seen this get way out of control. You can use restricted groups to put a stop to this.

Here is a video tutorial demonstrating adding a domain group into the local administration’s group on domain joined computers.

YouTube video

Here are some good resources and tutorials on using restrictive groups


17. Get Your Domain Time Right

Why should you care about the time?

If the time is not synchronized on all domain controllers, member servers, and machines you will encounter problems.

So how do you set the time correctly?

Here are a few Time sync tips

1 Set your PDC emulator to a time source

w32tm /config /manualpeerlist:timeserver /syncfromflags:manual /reliable:yes /update

All domain join machines will get its time from the PDC.

2 Disable time synchronization between the host system and guest operating systems.

VMs tend to synchronize time with the hosts (VMware or Hyper-v). It’s best practice to disable this so domain joined systems will continue to use the domain hierarchy for time synchronization.

I remember fighting time issues until we figured out the VMware hosts were changing time and getting out of sync or the PDC.

You may read about setting time with Group Policy. Unless you have jacked around with the time settings on computers you don’t need this.

Domain joined computers will by default sync with the PDC.

Additional resources


18. Document Active Directory & Group Policy

Active directory is critical to authenticating users, authorized access to many resources such as email, printers, files, remote access, and much more.

So, it would make sense to document Active Directory.

Here are a few things that I’d recommend you document

  • Forest name
  • Domain name
  • NetBIOS name
  • Forest Functional Level
  • All domains in the forest
  • Global Catalog servers
  • FSMO role holders
  • Diagram of topology
  • Sites and subnets
  • Naming convention for all objects
  • Group policy objects and description of what they do

The Microsoft Active Directory Topology Diagrammer is a handy little tool that helps with documentation.


19. Properly Implement Group Policies

I love group policy.

It’s an easy way to control and apply settings on all domain joined computers.

It can even be used to deploy software.

To be successful with group policy you need to follow a few rules.

Here are my group policy tips.

Tip#1 First of all, don’t modify the default domain policy

Tip#2 Do not modify the default domain controller policy

Tip#3 use good OU structure

Tip#4 Do not set Group Policy objects at the domain level

Tip#5 Apply Group Policy at an OU root level

See my complete list of Group Policy Best Practices 

20. Implement Change Control

Changes to Active Directory and group policy can disrupt services and affect business operations.

It’s important to put these changes through a change control process to avoid any downtime.

It’s also helpful to document your changes in case something goes wrong, and you need to roll back the changes.

When making critical changes I recommend the following.

  • Who is responsible for the change
  • Description of the change
  • Time of implementation
  • Duration of change
  • Expected impact
  • Has changed been tested
  • Backup procedures

I would advise making the change process as simple as possible. Nothing slows progress down more than a bunch of red tape and paperwork.

21. Use Active Directory as Your Centralized Authentication Source for Everything.

If you’re on-premise or cloud-based applications that support Active Directory Authentication, then use it.

It makes authorizations and access to resources so much easier when it’s controlled centrally by Active Directory.

It’s also a huge plus for the end users, they can authenticate with just one username and password.

Any questions? Leave a comment below.

50 thoughts on “21 Effective Active Directory Management Tips”

  1. Great work! I am very beginner level with Active Directory but this article helped me a lot.

    I have a concern in my mind. I want to set up an industrial production line and authenticate everything (few number of network equipment, less than 200 industrial controllers, average 50 users..) with Active Directory as you suggested. In this system, asset will be same always except users. There will not be any update, patch new software to be installed, no new shared folders, no office programs. Only helpdesk account will create and disable unprivileged users.

    Do you suggest me to set up AD for this system? What kind of administrative tasks could be required in this case after completing set up?

    • The advantage to AD is it will centralize authentication and authorization to network resources. I don’t know all of the details of your environment but AD might be overkill for what you described. I’ve worked with some large SCADA networks that did not have AD and just used local accounts. Not saying that is right or wrong it just really depends on your requirements.

  2. Thanks for this list, as a non-admin who needs to understand AD a bit better for one of my projects, it has made it clear that AD is not just a list. Loved your comment that “Active Directory is the heart of the network, if it stops beating then everything else dies.”
    My question is this: we’ve had a massive organisational restructure, and many people are now reassigned to different departments/teams/divisions, as well as managers. I’m trying to explain to our network manager that we simply cannot sit and wait around for every affected person to raise a helpdesk ticket, as this would clog up our helpdesk… Is there a way to bulk edit/amend the AD? How can I get them to understand that we need to shake the entire AD out once and for all – and that there are ways to go about it that reduces risk and improves quality?

  3. Hi Robert,

    first of all. Great article. Was a joy to read it. I have a question regarding your point 12. “Automate Common Active Directory Tasks”
    I am responsible for a big company with lots of account changes over the year (people coming and leaving) therefore I am very interested how you managed to automate these steps at once (creating the account, adding to groups, creating an office 365 mailbox and creating a personal shared folder) as we are facing exact same challenge. Maybe you have a hint for me to realize this. Thank you.

  4. Good one! Great posting.

    could you provide a solution to find 3rd party systems (or similiar) in the network which are using hard configured DNs? Related to the point 13. of your posting.

    I’ll be very graceful if someone has a good idea.

    Reason is that we would like to restructure our active directory OU structure. We would prevent of degrading a 3rd party system which is using hard configured DNs.

    • hmm… I don’t know of any tool for this. You might be able to use PowerShell if you know exactly where to look. You might be able to use Wireshark on the domain controller to see which systems are making the requests.

  5. Do you have any suggestions for documenting security groups? For example, we have 100+ security groups and from time-to-time I might get a manager to ask “why is so-and-so in that group?” Of course, that change might have happened two years ago and I have no way of remembering who requested that access and why. I’m contemplating a couple of options such as having a document for each security group and making sure I update it each time a change is made to a group. Do you know of any better options?

    • For documenting adding/removing users to groups I use a ticketing system. Include who requested access, why, and any approval. The last company I worked for we had an approvers list for certain requests (adding to groups was one of them). For example, Alice in accounting puts in a request to access the HR finance folder. This would require approval. We would document all of this in a ticket. Then when someone asked why does Alice have access to the HR finance folder we have documentation for it.

      If you have poorly named groups (generic names) then security will get out of control. I have found it best to be very descriptive with the name of the group. For example, group name = “N_Drive_IT_Training_Full”. Just by looking at the name, your staff can probably guess what it is used for. This will help avoid the group from being a catch-all and the wrong people added. Also, use the description field in AD to provide even more details on the group.

  6. Such a wonderful and huge article! Thanks a lot for you suggestions!
    Soon I will have to implement my first AD/DC environment from scratch…

  7. Excellent, Very good, I want to know what about Backup if Windows server crashed or if anything happened
    Pls. guide on this, how can I backup and others..

      • Hi Robert! Same question, but a little more dynamic. My work has multiple standalone environments (for the sake of simplicity, lets just say there are no domain trusts). We have a script that can deploy servers in vSphere and join servers to a selected domain through VMWare Guest OS Customization. Because the OU structure is different in the various domains, it is not feasible to specify the OU when the server is created and joined to the domain through the customization script. Otherwise we would have hundreds of customization scripts and it would just be insane to manage and use.

        On the domain controllers however, I’ve been searching for a way to dynamically move servers to their proper OU based on the servers name: ie, (server vmtestsql01, needs to go to the servers/sql/test OU), (server vmprdsql01, needs to go to the servers/sql/prod OU).

        I’m thinking there’s a way to parse AD objects that land in the servers OU when they are created, and move them according to the name prefix, perhaps a script that runs in task scheduler or other method. I’m just not sure what such a script would look like. Any suggestions?

  8. The first part of this article covering OU design does not sound like it’s written by someone who has ever read the rule book on OU creation. You’re ideas might work for a 50 user organisation but definitely not for a 1000+ user org. Please do not encourage people to create OUs willy nilly for the sake of “organising” things where naming standards and descriptions should suffice. OUs are created when 1) We need OU delegation, 2) A different set of GPOs need to be applied to other OUs or the root level and 3) For different types of objects (users and computers should be separated as you rightly say). OUs are not there to please your aesthetic desires or to help lazy people quickly identify things. That’s what a search is for. And that’s what descriptions and names are for. Because of hard and fast rules like this, AD environments are a mess with no structure at all and a very difficult to untangle configuration.

    • Are you talking about this rule book? Then yes this is how I design my OU structure.

      Designing OU Structures that Work

      My recommendation hits on all 3 of the design principles and works on small to large AD environments.

      1. Does this OU need to be created so a unique Group Policy Object (GPO) can be applied to it?
      2. Does a particular group of administrators need to have permissions to the objects in this OU?
      3. Will this new OU make it easier to administer the objects within it?

  9. Hi,

    I am not sure of understanding your structure.

    What is the problem with creating an OU with computers and users inside like the following ? :

    => OU=Users
    => OU=Computers

    Instead of what you do :

    OU=ADPRO Users
    OU=ADPRO Computers

    • Hi Eric, good question.

      As long as the computers and users are in separate OUs then I don’t see a problem with that structure.

  10. Hello
    I have to give permission to my helpdesk user to be able to change users expire date on other user in OU.
    How can I set permisson to this user? what kind of permission ? gonna make me happy if you have some tips for me….

  11. Hello Robert. We currently have an environment of about 65k total users and we are utilizing about 20 of these recommendations currently. I noticed in a comment above that a user was having trouble with ~375+ nested groups per user causing problems with header size and kerberos authentication. I believe we’ve been seeing a few issues related to this lately and we did not realize until now that this could be the cause. What tool(s) would you use to track total nested group membership for a user to prevent this from becoming a more widespread problem?

  12. Really that’s great. Yeah we read you from Cameroon ant this post is just GREAT. I just got enrolled in a Company and I am trying to put on a Directory from scratch. This will be very helpful for me

      • Thanks very much for this great article. I wish to know how to organize my OUs to prevent lnternet access to machines in a department that shouldn’t have access to Internet. Thanks

        • A web filter/proxy server is the best way to control internet access. You could use group policy and the windows firewall to block the browsers from running but its an all or nothing thing.

          Check out this post on blocking powershell with group policy. You can use this tutorial and block the browser exe but this would not work if they need the browser for anything. Web filter or proxy will be the best for controlling internet.

  13. Hi,

    very nice tutorial and I have a question, in point 5, which command did you used to know where were the missing entries at the DNS server?

  14. I would like to appreciate you for such a hard work and sharing it freely for beginners like me to catch up with your years of hard work, its indeed a detailed description thank you very much!!!

      • Excellent work! This is the best checklist I have seen and certainly It comes with many years of extensive experience. You solved my biggest worry about AD knowledge transfer to commence soon. Thanks a ton.

        • Thanks Praveen.

          I’ve been an administrator of Active Directory for over 15 years and I’m still learning new things.

  15. Nice tips – thanks!

    Question/comment on #6: We’ve been exploring (and are a good ways into implementing) Role-Based Access Control and using AD groups to facilitate. As the number of resources that AD groups need to be created for increases, it is resulting in transitive membership to a large number of AD groups for some staff. The resulting security tokens are so large now that it exceeds the http header size limit when trying to authenticate to some internal web apps/sites.

    Do you have any insight or feedback on this aspect of using AD groups to implement RBAC? I love the idea, but we’re hitting what appear to be practical limits. (And we have MANY more resources that we were planning to secure this way…)


  16. It’s a very very good tutorial. Thanks !

    I would like your advice.

    In our company we have this OU design but it is not good for us.
    We range computers by city and not office

    Domain > City 1 > Office 1 > Users
    Domain > City 1 > Office 2 > Users
    Domain > City 1 > Computers

    We have 60 city and we add city frequently. 1 -3 per years. Each city can have multiple office.

    Your advice is to have :

    Domain > Computers > City1
    Domain > Computers > City2

    Domain > Users > City1 > Office 1
    Domain > Users > City1 > Office 2

    Computers and users will not the default OU

    • Hi Natria,

      Yes that would work, I would definitely separate the users and computers into their own OUs.

      Depending on how you need to apply group policies you can also organize it like so.

      Domain > Computers > Department

      Then under department and another OU for each City.

      Domain > Computers > Department > City1
      Domain > Computers > Department > City 2

      Then you can apply policies based on department.

      Hope that helps.


Leave a Reply to Robert Allen Cancel reply