Tag Archives: domain

Active Directory: Built a mirror lab before?

By Robert Meyers

Do you have a lab?  Specifically, do you have an Active Directory lab? Do you need a lab?  Hint: the answer is yes.  The modus operandi for the industry has been simple: salvage your old equipment and build an ad hoc lab.  Times have changed and that now begs the question: is that really good enough?  Nope.  It wasn’t back in the day, and it certainly isn’t today.

So let’s get down to business and look at what you need for your lab.  One thing any IT professional will agree is that building a lab is an essential part of preparing for a variety of tasks such as an Active Directory transition, an Active Directory migration, Novell Migration, schema changes and the list goes on.  Anything that changes your current settings in Active Directory beyond a single account should always hit the lab first.  The lab is there so you can do a dry run, practice and validate any process.  It is a lab environment.  If it blows up, you get the experience gained from rebuilding it.

So a lab should closely mirror the production environment (in every way that is feasible). While it is not feasible to completely mirror production’s many application servers and enterprise computing platforms, it should be as close as possible and account for the business critical applications, at least include a small sampling of those servers.  It should also have workstations if you use workstations.

Without a close replica of the production environment organizations cannot successfully plan for potential show stopping events from infrastructure changes.  Think of the results from a schema extension preventing a domain upgrade (I have seen these).  Think of a time configuration error that is allowing domain controllers to lose synchronization (these are common).  Think of a large PowerShell script import of thousands of groups being imported to the wrong OU (stopped this before).

Any process that has an impact on your current Active Directory environment should be tested.

An implementation of a new lab cannot account for the “history” or breadth of the production environment. This includes some of the following examples: schema extensions over time, upgrades of operating systems, administrative changes in functionality, and current policies in effect, and anything you don’t see in a DCDIAG. Everyone agrees that implementing a lab environment using the concept of “mirroring”, or as close to a mirrored environment as possible is crucial to a successful implementation of an upgraded or migrated environment.

There are many strategies for implementing a lab environment but they all have their own caveats to plan for in order to avoid disaster. The best mirror methodology is to introduce a new domain controller in a production domain, replicate all data, remove the domain controller and place it in the lab environment, and then perform metadata cleanup on both the production and lab environments.  This gets you a copy of the real environment. In the production environment the metadata cleanup would remove existence the newly promoted DC to avoid replication failures. In the lab environment the metadata cleanup would involve removing all existence of the missing domain controller in the forest.  The cleanup consist of seizing FSMO roles, NTDSUTIL being used to clean up the metadata and then going through and manually pruning each side from the other.

There is a major risk for this best of breed lab.  The lab environment must be guaranteed to never touch the production environment. If this were to occur, two separate domain controllers would attempt to assume the FSMO roles and would cause all sorts of issues… think best possibility would be USN rollback and dire replication issues.   As such, while a lab environment is essential, there are many preventative tasks that must be performed to ensure the lab environment never is in contact with the production environment. This should be locked down by all available security measures. A very critical security concern is if the lab environment is a virtualized environment. Domain controllers are only as secure as the server in which they run on.

I always recommend using a dedicated Hyper-V V3, VMware vCenter Lab Manager or VMware ESXi environment. Please note that this security is essential, as if a VHD or VMDK files end up in production they can potentially cause a true full scale outages and additionally security risks.

Scared yet?  Should be. Well this best of breed, is the best of breed but it needs to be done methodically.

Going to give it a try? Good!

Now everyone, let’s work together to make the new IT modeus operendi: just say no to “blowing up” your Active Directory.

A Visual Step by Step: Windows Server 2012, Active Directory 2012, time to build your first forest!

By Robert Meyers

 

Sometimes you just want to see how something is done. Well today, we are going to look at how to build a basic forest. This is for the first domain controller in your lab. Yes, I said lab. You want a lab. Why do you want a lab? This lets us see if anything is going to break? Or as close as we can ever get.

Now everyone, let’s work together to make the new IT modeus operendi: just say no to “blowing up” your Active Directory.

So, in sixty seven simple steps… let’s build the lab so we can make that new modeus operendi. Just follow the recorded steps.

Recorded Steps

 

 

Step 1: (‎9/‎6/‎2012 7:02:23 AM) User right click on “Server Manager (button)”
 

 

Step 2: (‎9/‎6/‎2012 7:02:25 AM) User right click on “Server Manager (list item)” in “Jump List”
 
Step 3: (‎9/‎6/‎2012 7:02:26 AM) User left click on “Run as administrator (menu item)”
 
Step 4: (‎9/‎6/‎2012 7:02:30 AM) User left click on “Add roles and features (button)” in “Server Manager”
 
Step 5: (‎9/‎6/‎2012 7:02:33 AM) User left click on “_Next > (text)” in “Add Roles and Features Wizard”
 
Step 6: (‎9/‎6/‎2012 7:02:35 AM) User left click on “_Next > (text)” in “Add Roles and Features Wizard”
 
Step 7: (‎9/‎6/‎2012 7:02:37 AM) User left click on “Microsoft Windows Server 2012 Standard Evaluation (text)” in “Add Roles and Features Wizard”
 
Step 8: (‎9/‎6/‎2012 7:02:38 AM) User left click on “_Next > (text)” in “Add Roles and Features Wizard”
 
Step 9: (‎9/‎6/‎2012 7:02:41 AM) User left click on “Active Directory Domain Services (tree view item)” in “Add Roles and Features Wizard”
 
Step 10: (‎9/‎6/‎2012 7:02:44 AM) User left click on “Add Features (text)” in “Add Roles and Features Wizard”
 
Step 11: (‎9/‎6/‎2012 7:02:47 AM) User left click on “_Next > (text)” in “Add Roles and Features Wizard”
 
Step 12: (‎9/‎6/‎2012 7:02:53 AM) User left click in “Add Roles and Features Wizard”
 
Step 13: (‎9/‎6/‎2012 7:02:57 AM) User left click on “_Next > (text)” in “Add Roles and Features Wizard”
 
Step 14: (‎9/‎6/‎2012 7:02:59 AM) User left click on “_Next > (text)” in “Add Roles and Features Wizard”
 
Step 15: (‎9/‎6/‎2012 7:03:02 AM) User left click on “Install (button)” in “Add Roles and Features Wizard”
 
Step 16: (‎9/‎6/‎2012 7:04:04 AM) User left click on “Export configuration settings (text)” in “Add Roles and Features Wizard”
 
Step 17: (‎9/‎6/‎2012 7:04:07 AM) User left click on “Page down (button)” in “Save As”
 
Step 18: (‎9/‎6/‎2012 7:04:08 AM) User left click on “Local Disk (C:) (tree item)” in “Save As”. You should always save a copy of a configuration that you are using.
 
Step 19: (‎9/‎6/‎2012 7:04:11 AM) User left click on “Save (button)” in “Save As”
 
Step 20: (‎9/‎6/‎2012 7:04:20 AM) User left click on “Promote this server to a domain controller (text)” in “Add Roles and Features Wizard”
 
Step 21: (‎9/‎6/‎2012 7:04:24 AM) User left click on “Add a new _forest (text)” in “Active Directory Domain Services Configuration Wizard”
 
Step 22: (‎9/‎6/‎2012 7:04:25 AM) User left click on “_Root domain name: (edit)” in “Active Directory Domain Services Configuration Wizard”
 
Step 23: (‎9/‎6/‎2012 7:04:28 AM) User keyboard input on “Active Directory Domain Services Configuration Wizard (window)” in “Active Directory Domain Services Configuration Wizard” […]
 
Step 24: (‎9/‎6/‎2012 7:04:36 AM) User left click on “_Next > (text)” in “Active Directory Domain Services Configuration Wizard”
 
Step 25: (‎9/‎6/‎2012 7:05:10 AM) User left click on “Passwor_d: (edit)” in “Active Directory Domain Services Configuration Wizard”
 
Step 26: (‎9/‎6/‎2012 7:05:31 AM) User left click on “Passwor_d: (edit)” in “Active Directory Domain Services Configuration Wizard”
 
Step 27: (‎9/‎6/‎2012 7:05:34 AM) User keyboard input on “Active Directory Domain Services Configuration Wizard (window)” in “Active Directory Domain Services Configuration Wizard” [… Shift … Tab …]
 
Step 28: (‎9/‎6/‎2012 7:05:42 AM) User left click on “_Next > (text)” in “Active Directory Domain Services Configuration Wizard”
 
Step 29: (‎9/‎6/‎2012 7:05:52 AM) User left click on “Show more (text)” in “Active Directory Domain Services Configuration Wizard”
 
Step 30: (‎9/‎6/‎2012 7:06:04 AM) User left click on “OK (button)” in “DNS Options”. Since it looks like an informative link, please take a moment and read it.
 
Step 31: (‎9/‎6/‎2012 7:06:06 AM) User left click on “_Next > (text)” in “Active Directory Domain Services Configuration Wizard”
 
Step 32: (‎9/‎6/‎2012 7:06:09 AM) User left click on “The NetBIOS domain name: (edit)” in “Active Directory Domain Services Configuration Wizard”
 
Step 33: (‎9/‎6/‎2012 7:06:21 AM) User left click on “_Next > (text)” in “Active Directory Domain Services Configuration Wizard”
 
Step 34: (‎9/‎6/‎2012 7:06:33 AM) User left click on “_Database folder: (edit)” in “Active Directory Domain Services Configuration Wizard”
 
Step 35: (‎9/‎6/‎2012 7:06:34 AM) User left click on “_Database folder: (edit)” in “Active Directory Domain Services Configuration Wizard”
 
Step 36: (‎9/‎6/‎2012 7:06:35 AM) User keyboard input on “Active Directory Domain Services Configuration Wizard (window)” in “Active Directory Domain Services Configuration Wizard” […]
 
Step 37: (‎9/‎6/‎2012 7:06:40 AM) User left click on “_Log files folder: (edit)” in “Active Directory Domain Services Configuration Wizard”
 
Step 38: (‎9/‎6/‎2012 7:06:41 AM) User left click on “_Log files folder: (edit)” in “Active Directory Domain Services Configuration Wizard”
 
Step 39: (‎9/‎6/‎2012 7:06:43 AM) User keyboard input on “Active Directory Domain Services Configuration Wizard (window)” in “Active Directory Domain Services Configuration Wizard” […]
 
Step 40: (‎9/‎6/‎2012 7:06:52 AM) User mouse drag start on “_Database folder: (edit)” in “Active Directory Domain Services Configuration Wizard”
 
Step 41: (‎9/‎6/‎2012 7:06:53 AM) User mouse drag end on “_Database folder: (edit)” in “Active Directory Domain Services Configuration Wizard”
 
Step 42: (‎9/‎6/‎2012 7:06:53 AM) User left click on “_Database folder: (edit)” in “Active Directory Domain Services Configuration Wizard”
 
Step 43: (‎9/‎6/‎2012 7:06:54 AM) User mouse drag start on “_Database folder: (edit)” in “Active Directory Domain Services Configuration Wizard”
 
Step 44: (‎9/‎6/‎2012 7:06:56 AM) User mouse drag end on “_Database folder: (edit)” in “Active Directory Domain Services Configuration Wizard”
 
Step 45: (‎9/‎6/‎2012 7:06:56 AM) User keyboard input on “Active Directory Domain Services Configuration Wizard (window)” in “Active Directory Domain Services Configuration Wizard” […]
 
Step 46: (‎9/‎6/‎2012 7:07:00 AM) User mouse drag start on “_Log files folder: (edit)” in “Active Directory Domain Services Configuration Wizard”
 
Step 47: (‎9/‎6/‎2012 7:07:01 AM) User mouse drag end on “_Log files folder: (edit)” in “Active Directory Domain Services Configuration Wizard”
 
Step 48: (‎9/‎6/‎2012 7:07:01 AM) User left click on “_Log files folder: (edit)” in “Active Directory Domain Services Configuration Wizard”
 
Step 49: (‎9/‎6/‎2012 7:07:02 AM) User mouse drag start on “_Log files folder: (edit)” in “Active Directory Domain Services Configuration Wizard”
 
Step 50: (‎9/‎6/‎2012 7:07:05 AM) User mouse drag end on “_Log files folder: (edit)” in “Active Directory Domain Services Configuration Wizard”
 
Step 51: (‎9/‎6/‎2012 7:07:05 AM) User keyboard input on “Active Directory Domain Services Configuration Wizard (window)” in “Active Directory Domain Services Configuration Wizard” […]
5
 
Step 52: (‎9/‎6/‎2012 7:07:08 AM) User left click on “S_YSVOL folder: (edit)” in “Active Directory Domain Services Configuration Wizard”
 

 

Previous
Next
Step 53: (‎9/‎6/‎2012 7:07:09 AM) User left click on “S_YSVOL folder: (edit)” in “Active Directory Domain Services Configuration Wizard”
 
Step 54: (‎9/‎6/‎2012 7:07:11 AM) User keyboard input on “Active Directory Domain Services Configuration Wizard (window)” in “Active Directory Domain Services Configuration Wizard”. I have never liked having important folders hidden among everything else. As such, I like to break out the NTDS locations.
 
Step 55: (‎9/‎6/‎2012 7:07:20 AM) User left click on “Next > (button)” in “Active Directory Domain Services Configuration Wizard”
 
Step 56: (‎9/‎6/‎2012 7:07:24 AM) User left click on “_View script (text)” in “Active Directory Domain Services Configuration Wizard”
 
Step 57: (‎9/‎6/‎2012 7:07:35 AM) User left click on “File (menu item)” in “tmpF8A.tmp – Notepad”
 
Step 58: (‎9/‎6/‎2012 7:07:37 AM) User left click on “Save As… (menu item)”
 
Step 59: (‎9/‎6/‎2012 7:07:41 AM) User keyboard input on “File name: (edit)” in “Save As” […]
 

 

Previous
Next
Step 60: (‎9/‎6/‎2012 7:07:54 AM) User left click on “Save (button)” in “Save As”
 
Step 61: (‎9/‎6/‎2012 7:07:57 AM) User left click on “Close (button)” in “ADDS Deployment – Notepad”. Once again, check out the script.
 
Step 62: (‎9/‎6/‎2012 7:08:00 AM) User left click on “_Next > (text)” in “Active Directory Domain Services Configuration Wizard”
 
Step 63: (‎9/‎6/‎2012 7:08:58 AM) User mouse drag start on “_View results (group)” in “Active Directory Domain Services Configuration Wizard”
 
Step 64: (‎9/‎6/‎2012 7:09:02 AM) User mouse drag end on “_View results (group)” in “Active Directory Domain Services Configuration Wizard”
 
Step 65: (‎9/‎6/‎2012 7:09:05 AM) User left click on “_Install (text)” in “Active Directory Domain Services Configuration Wizard”
 
Step 66: (‎9/‎6/‎2012 7:11:17 AM) User left click on “Close (button)” in “You’re about to be signed off”
 
Step 67: (‎9/‎6/‎2012 7:11:19 AM) User left click on “Steps Recorder – Recording Now (button)”. And we are done.
 

Group Policy Object Decisions: Monolithic GPO

By Robert Meyers, MCITP

Group policy objects (GPO) are one of the headaches and addictions available for the modern active directory administrator.  For those new to administration, group policy objects are sets of rules that are saved into a special file that declare a set of guidelines to control the workings of users or computers in a Windows environment.

When you begin to configure them, all administrators run across two ways, or styles in which they are done.  There is the monolithic policy which tries to do everything for a domain, or category of resource.  Next there are the task-based policies, sometimes called functional policies.  Task-based policies are policies based on a single setting or thought.  Another way of looking at is a few policy objects, or many policy objects.  Of course in the real world, more often than not, a domain will have both forms of policy objects.

Some right about now will ask the obvious questions, “Why would I use a bunch of GPOs instead of one?”  Others might ask, “Why would I ever want a single GPO doing everything?”   These are both good questions, but the answer lies in the theory behind them.  This article will focus on monolithic group policy object theory.

The monolithic group policy object is personified by the default domain policy: a single policy that does dozens of actions out of the box.  This type of policy will normally have settings that include administrative templates, internet explorer, firewall settings, and maybe even software installation.   At its core, this complete and pervasive group policy object should always be simple.  Monolithic group policy objects are traditionally simple to read, and do not contain complex or single use instances.  This is often referred to as KISS, keep it super simple.  If these get too complex they become unmanageable.

Before designating when and where to deploy this, since we have defined what it is, let’s take at what a monolithic group policy object is not.  A monolithic group policy object is not easily isolated for testing or troubleshooting, nor is it easily delegated to small groups; it is too comprehensive in scope for that.  A monolithic group policy is also not fast in processing changes, as every component will need to run through in its entirety after any changes.  Lastly, monolithic policies are not easy to deal with when they go corrupt.  When a monolithic policy object goes corrupt: you lose everything that policy did.  Rebuilding is by definition much harder with a monolithic policy object than with a task-based policy object.

So now that we know what these are, when should we use them?  Sadly, this is not as cut and dried as it should be.  And of course, like many things in systems administration, there is always a personal style involved in the operation.  As such, you are about to get where the author would use them.

The most common place in which monolithic policies are normally found is when an installation is a default windows installation.  When this is done, all the basics for windows are in the default domain and default domain controller policies.  Normally these will be there because the administrator has not experienced utilizing the concept of group policies or has a staff that is not as well trained to deal with them.  This is normally a transitory situation.

Planed deployments of monolithic policies are normally found in smaller installations of windows.  The reason for this is that if you have only a hundred or two hundred users, the likely-hood of needing only a few basic configurations is relatively high.  When there really are only a few configurations and the environment is small enough to enable easier troubleshooting; then there really is little need for the flexibility and troubleshooting advantage that is part and parcel in the task-based group policy object model.

The basic concept here is that monolithic group policy objects should be used when complexity is not required.  The deployment should be simple and efficient.   The reason to keep the complexity down has a few reasons behind it.  The first is that if a problem occurs with the group policy object, you know have to delve much deeper into a monolithic policy, or worse, a collection of monolithic policies in order to troubleshoot the issue; delving deep into troubleshooting a complex monolithic group policy object will exhaust countless unneeded hours.  The next is the old hit by a bus concept.  Monolithic policies that are complex are by definition: hard to unravel.  As such, if you as a group policy object administrator were to be hit by a bus: can someone else quickly take over?  If the answer is no, then the deployment is over complicated for its purpose.

The common theme here is smaller and simpler deployments.  Does this mean this will not work in a larger environment?  Not at all.  In fact, if the environment is simple and straight forward, then you will have the same simplified benefits as you would deploying to a small installation.  As you increase complexity however, you will find that the complex nature of the monolithic group policy object precludes simple at glance knowledge of what is happening and exponentially complicates troubleshooting.

Tech tip #2:

If you structure your organization units (OU) so that you can restrict deployments of group policy objects to just organizational units, then you will have a visual representation with the group policy management tool.  If group policy objects are deployed to groups, you will need to trace every member when doing troubleshooting.

Tech tip #3:

When naming monolithic group policy objects, normally the end all target is used.  Examples that are common are: “domain”, “notebooks”, “desktops”, and “servers”.  Names should always tell you what you need to know at a glance.

Group Policy Object Decisions: Monolithic GPO

By Robert Meyers, MCITP

Group policy objects (GPO) are one of the headaches and addictions available for the modern active directory administrator.  For those new to administration, group policy objects are sets of rules that are saved into a special file that declare a set of guidelines to control the workings of users or computers in a Windows environment.

When you begin to configure them, all administrators run across two ways, or styles in which they are done.  There is the monolithic policy which tries to do everything for a domain, or category of resource.  Next there are the task-based policies, sometimes called functional policies.  Task-based policies are policies based on a single setting or thought.  Another way of looking at is a few policy objects, or many policy objects.  Of course in the real world, more often than not, a domain will have both forms of policy objects.

Some right about now will ask the obvious questions, “Why would I use a bunch of GPOs instead of one?”  Others might ask, “Why would I ever want a single GPO doing everything?”   These are both good questions, but the answer lies in the theory behind them.  This article will focus on monolithic group policy object theory.

The monolithic group policy object is personified by the default domain policy: a single policy that does dozens of actions out of the box.  This type of policy will normally have settings that include administrative templates, internet explorer, firewall settings, and maybe even software installation.   At its core, this complete and pervasive group policy object should always be simple.  Monolithic group policy objects are traditionally simple to read, and do not contain complex or single use instances.  This is often referred to as KISS, keep it super simple.  If these get too complex they become unmanageable.

Before designating when and where to deploy this, since we have defined what it is, let’s take at what a monolithic group policy object is not.  A monolithic group policy object is not easily isolated for testing or troubleshooting, nor is it easily delegated to small groups; it is too comprehensive in scope for that.  A monolithic group policy is also not fast in processing changes, as every component will need to run through in its entirety after any changes.  Lastly, monolithic policies are not easy to deal with when they go corrupt.  When a monolithic policy object goes corrupt: you lose everything that policy did.  Rebuilding is by definition much harder with a monolithic policy object than with a task-based policy object.

So now that we know what these are, when should we use them?  Sadly, this is not as cut and dried as it should be.  And of course, like many things in systems administration, there is always a personal style involved in the operation.  As such, you are about to get where the author would use them.

The most common place in which monolithic policies are normally found is when an installation is a default windows installation.  When this is done, all the basics for windows are in the default domain and default domain controller policies.  Normally these will be there because the administrator has not experienced utilizing the concept of group policies or has a staff that is not as well trained to deal with them.  This is normally a transitory situation.

Planed deployments of monolithic policies are normally found in smaller installations of windows.  The reason for this is that if you have only a hundred or two hundred users, the likely-hood of needing only a few basic configurations is relatively high.  When there really are only a few configurations and the environment is small enough to enable easier troubleshooting; then there really is little need for the flexibility and troubleshooting advantage that is part and parcel in the task-based group policy object model.

The basic concept here is that monolithic group policy objects should be used when complexity is not required.  The deployment should be simple and efficient.   The reason to keep the complexity down has a few reasons behind it.  The first is that if a problem occurs with the group policy object, you know have to delve much deeper into a monolithic policy, or worse, a collection of monolithic policies in order to troubleshoot the issue; delving deep into troubleshooting a complex monolithic group policy object will exhaust countless unneeded hours.  The next is the old hit by a bus concept.  Monolithic policies that are complex are by definition: hard to unravel.  As such, if you as a group policy object administrator were to be hit by a bus: can someone else quickly take over?  If the answer is no, then the deployment is over complicated for its purpose.

The common theme here is smaller and simpler deployments.  Does this mean this will not work in a larger environment?  Not at all.  In fact, if the environment is simple and straight forward, then you will have the same simplified benefits as you would deploying to a small installation.  As you increase complexity however, you will find that the complex nature of the monolithic group policy object precludes simple at glance knowledge of what is happening and exponentially complicates troubleshooting.

Tech tip #2:

If you structure your organization units (OU) so that you can restrict deployments of group policy objects to just organizational units, then you will have a visual representation with the group policy management tool.  If group policy objects are deployed to groups, you will need to trace every member when doing troubleshooting.

Tech tip #3:

When naming monolithic group policy objects, normally the end all target is used.  Examples that are common are: “domain”, “notebooks”, “desktops”, and “servers”.  Names should always tell you what you need to know at a glance.

This site is using Web Stats, created by emailextractor14.com