Implementing Active Directory – 11/16/2009

Today we covered the final two chapters in the book: 11 and 12.

Chapter 11 was all about the day to day maintenance of the AD database.  Since AD is a database, and a living one at that, we must make sure we keep it in shape so that it runs as efficiently as possible.  To do this, we run one of two AD defragmentation: online or offline.

Online Defragmentation happens on a regular basis — once every 12 hours — and involves cycling through the AD database looking for tombstones that are set to be cleaned.  (Tombstones are what’s left behind when something is deleted from AD — it’s left with a tombstone that lives on for another 60 days (does this make them zombies??)).  At the 60 day mark, those tombstones are deleted by AD’s Online Defragmentation.  The upside is that the server doesn’t have to be taken down in order for this to occur, but the downside is that the size of the database doesn’t actually change.  So, if you need  a more powerful, database-reducing activity, the Offline Defragmentation is the way you’ll need to go.

Offline Defragmentation is a slightly more complicated process, and should only be done when reducing the size of the AD Database is the primary goal.  It involves taking the DC offline, booting into Directory Services Restore Mode and running the NTDSUtil command (Files | Compact To C:\Backup).

We also looked at backing up AD, which can be done via the default Windows Server backup program, NTBACKUP (or your competent 3rd party choice).  If using NTBACKUP, you’ll just do a backup of the System State, and that will grab the AD database and settings along with it.

To restore the AD database, you have a couple of options.  You can choose to either do a non-authoritative restore, or an authoritative restore.  The differences lie in how you’d like your data to propagate throughout the network.

The easiest and most common type of restore you would be performing would be the non-authoritative.  What happens in a non-authoritative restore is that directory information is replaced, but is flagged indicating “Hey, I’m probably out of date”.  When AD replication occurs, if any information comes down the pike that is deemed newer, or more relevang, that newer, more relevant information replaces the older information established by the non-authoritative restore.  Typically you would perform this type of AD restore on a new server that you want to designate as a DC, and just have the new information replicate to the server.

When you accidently delete a user and that change has worked it’s way through AD, you would need to perform an authoritative restore.  Authoritative restores replace a particular object, and then indicate it as “authoritative”, so that when AD replication occurs, it is flagged as the most recent and relevant, and that change is then replicated throughout Active Directory.

Moving on to Chapter 12, we discussed the various scenarios you might encounter when installing Windows Server 2003 in an organization, including making the decision to either upgrade or migrate (meaning new equipment, moving just the data over).  We looked at several tools that might be needed in such scenarios.

Homework:

• Take Home Test #6 – download it here.
• Continue work on MS E-Learning modules!

Implementing Active Directory – 11/9/2009

We had a big day today, covering 3 chapters, and finishing up our discussion on Group Policy.  Next week, we’ll finish up the remaining two chapters in the book and work the remaining time on our “Show Me the Money” network implementation!!

Anyway, chapter 8 covered the user and computer environments when configured by Group Policy.  The first area of focus was the area of security policies.  As you know from previous discussion (earlier today!?) that we can configure security policies on our machines to allow or disallow (or block, even) certain kinds of behavior, or limit that behavior to certain individuals.  The nice thing is is that, using Group Policy, we can configure those settings once in a GPO and then assign it to a large number of computers by attaching that GPO to an object associated with the computers we wish to control (inside the Sales OU, for example).

We also looked at a concept called Folder Redirection.  With Folder Redirection, we are able to control where user files end up during backup or in day-to-day use.  A common use of Folder Redirection is to configure a GPO that makes the client computers store files on a network location instead of on the local computer when a user saves in the “Documents” folder.  To the end user, nothing is too different from their home machine, but the files are actually saved to the server without the user having to know to save their documents to the \\srv-01\files\ directory.  It’s just easier that way.  Especially if we ever have to move those files!   Oh, and also, the .zap files only work on software assigned to user groups — not computers.  Very important!

Disk Quotas, we’ve looked at before, are ways of limiting your users from gobbling up a bunch of server space.  Especially in this day of digital media, it’s not uncommon for users to rip a  bunch of CDs to their computers thinking they’re storing them on their local HDD, when in fact they are being stored on the server (aha! Folder Redirection!).  Disk Quotas ensures that your server doesn’t get filled up with a bunch of 320 kbps Menudo .mp3 files.

Chapter 9 talked about the installation of software titles via Group Policy.  This is perhaps one of the most useful things you can do with GP — imagine having to install something like MS Office onto 200 computers (especially if you only had 1 disc) — it would be a nightmare!

By copying the disc to a network share and then configuring a GPO to put that software onto the computers that fell within its scope, you could install that software automatically, with no walking around and mindlessly configuring.

There is a downside, however.  In order for GP to install software programs, the program installation file must be a Windows Installer file (.msi extension).  .EXEs won’t work, unfortunately, unless you want to configure a .zap file.  .Zap files work like old .ini files and simply are directions for GP to use .EXEs in their deployments.  The downside is that the installations often will need user intervention and in many cases will need someone with local administrator rights present.

Finally, Chapter 10 covered GP management, and here’s where things can get fun.  Or hairy.  Or both, if that’s your thing.

Group Policy is an object just like anything else, and can therefore have an ACL attached to it.  This ensures that certain users within an OU keep from having GPOs attached to them.  For example, if I wnated a particular user in an OU to *not* have their taskbar locked, I could place a deny read on that particular GPO for that particular user.

In addition, I can use something called WMI filters.  WMI stands for Windows Management Instrumentation, and is used in Windows 2003 to filter down for particular requirements on our machines.  For example, if I want to apply a certain GPO to only Windows XP machines, I could apply a WMI filter that selects out Windows XP machines.  How, you ask?  Well, WMI uses a mechanism that is very similar to the SQL database language, and a query is written in very much the same way.  So to only apply a particular GPO to Windows XP machines, I would apply a WMI filter that looks like this:

SELECT * from Win32_operatingsystem WHERE caption = "Microsoft Windows XP Professional"

The downside here, of course, is that I can only apply 1 WMI filter to a GPO.  (I can use the same WMI filter attached to several GPOs though).

Homework:

• Take Home Test #05 – download it here!
• Continue working on MS E-Learning Modules!

Implementing Active Directory – 11/2/2009

Ok, you’ve heard me blather on and on since the A+ class about how my favorite topic to talk about is Group Policy.  Well, good news (me), we’ve reached the point in your educational career where we get to dive into Group Policy head-first!

Group Policies make it easier to configure large amounts of computers identically, correctly and quickly.  Imagine if you had to travel around to hundreds of client computers and set up a corporate wallpaper on everyone’s desktop!  This would take literally hours to accomplish, and several users would simply change the wallpaper back to their kids after you left anyway.  With Group Policy, you can literally make about 10 clicks, do some minimal typing, and then when each user logs back on to their computers, they have the corporate wallpaper in place and, if you set it up this way, are forced into keeping it that way!

A set of settings is called a Group Policy Object (GPOs), and the various objects that can have GPOs attached to them can have many GPOs attached at a time.  The various objects that can have GPOs attached to them are the local machines, the AD site, the domain and the Organizational Unit (OU).  Interestingly, Security Groups can not have GPOs attached to them, despite having the name Group Policy.  Weird, eh?

We took a look at where GPOs are actually stored, and took a look inside them.  Each GPO is about 4MB in a Server 2003 system, and so having a BUNCH of them can really start to affect replication, so try to use them sparingly.  Server 2008 solves this problem with XML making the GPO system a lot more lightweight.  But I digress.

We took a look at the Group Policy Editor inside Server 2003, and then installed the Group Policy Management Console.  This is an invaluable tool not included with the Server 2003 media, but you are expected to know how to use it, so make sure you download it from Microsoft’s site and practice with it.

So, what happens if you have a GPO attached to one place that requires one thing, and a separate GPO attached to a different place that requires something totally different?  The GPOs will be in conflict — which one wins?

The answer lies in a) which object the GPO is attached to and possibly b) how high on the priority list the GPO is.

Active Directory attaches GPOs in the following order: local machine, sites, domains and finally OU.  If a GPO is already assigned and another one comes along that is different, the newest one takes precedence.  Let’s explore this with an example user that is in the BG site of the greedycorp domain.  Furthermore, this particular user lives in an OU called “Sales”.  If I have a policy of “Lock the Taskbar” set to enabled at the local machine level, and a different policy of “Don’t Lock the Taskbar” attached to the BG site, the user’s task bar is not going to be locked?  Why?  Because the BG site’s GPO was attached later, and therefore overwrote the policy attached ot the local machine.  If another policy attached to the greedycorp.com domain indicated “Lock the Taskbar”, then that particular user’s taskbar would be locked, since the policy attached to the domain was applied after the local computer and the site.  Make sense?

There’s a really easy way to remember the order in which GPOs are applied: LSD… Ohhhh.  (I’m sure this blog is going to get all kinds of unintended attention now).

Homework:

• Take Home Test #04 – Chapter 07 – download it here.
• Continue work on MS E-Learning modules.

Implementing Active Directory – 10/26/2009

Just the midterm!

Homework:

• No homework this week!

Implementing Active Directory – 10/19/2009

In today’s class we stepped up the pace a bit and covered three (woah!  three!) chapters today, in anticipation of my being out the week of October 26.

Chapter 4 was first on the docket, with the concept of the Global Catalog and FSMO Roles.  The global catalog is used to facilitate logins for Windows 2000 Native mode and higher (Mixed Mode doesn’t use it), and not having a Global Catalog server available in these modes will not permit logins.  We talked about a way to alleviate so much dependency on the GC server by introducing the concept of Universal Group caching.  We next switched gears and worked with Flexible Single Master Operations (FSMO) roles.  When we first install AD, the first DC is saddled with the responsibility of the five server roles in the organization.  In situations with large networks, this can be too much to handle for a single server, so in those cases we will want to reassign those roles to other servers.  We do this with the tool NTDSUTIL, which is including with the Server 2003 Support Tools.

Next, we switched gears to cover Chapter Five, which was all about the creation of and managing of Users and Groups inside server.  Admittingly, this topic is much lighter than the topics we just  covered.  Some highlights that we covered that aren’t covered elsewhere include which groups you need to be a member of perform certain administrative tasks like site creation and schema viewing and editing.  We then used the DSADD command line command to create users and OUs in our domain.

And springing from that topic, we talked about AD security including proper naming concepts, password selection, using the built-in RunAs command (which was hugely ignored, and corrected by MIcrosoft), and administrative duty delegation.

Homework:

• Take Home Test #3 – download it here.
• Continue work on MS E-Learning modules.

Implementing Active Directory – 10/5/2009

Today’s topic was all about Active Directory Sites — the crash course for Active Directory to learn about geography, since it apparently missed that day back in 3rd grade (ba-dum-bum!).  Obviously, AD doesn’t care about where geographically another domain controller might be located, it’s going to try and replicate with it.  If that server is over an expensive WAN link, that constant hourly (or 4 times hourly) communication could be very expensive.  So, with Sites, we can set up boundaries for AD to observe.  Within these boundaries, AD will only update once a day (or whatever we configure it), saving us on bandwidth.  I mean, really, does a new user at our New York office really need to be represented on the Los Angeles DC immediately?  Really?

So when replication occurs, AD looks at two things on given DCs when it’s figuring out what data gets sent across the wire: the Update Sequence Number (USN) and a timestamp of the last changes.  With those two pieces of information, AD makes the decision of what information is good new information, and what needs to be deleted, and does its mojo to sync up the two DCs and make them identical.

Between two sites, when replication occurs, not all DCs sync up with all other DCs at every other site — that would just be ridiculously wasteful in terms of leased bandwidth.  Instead, what occurs is replication between each site’s bridgehead server — the designated “king server” of the site.  That server then replicates to the other DCs at the site locally, without the use of leased bandwidth.  Since the bridgehead server is going to be the one interfacing with replications from other geographic locations, it usually is a beefed up server.

To connect the different sites, we use our leased lines and any routes we have set up through our routers.  Again, the concept of sites is a logical one, and so we also have to tell AD how the different sites are connected.  Some networks can become quite complex, and sites can have various ways of connecting to one other.  Some ways will be slower and/or more expensive than other ways, and so in the name of saving money (because Uncle Sam is not bailing your company out), we need a way to tell AD to use the cheapest ways possible.  The way we do this is through site links, which literally are represented in AD as lines connecting the different sites.  There’s nothing saying we can’t have more than one site link connecting different sites, and the connections will present multiple paths from one site to another.  So which way will AD send packets from one site to another during replication?  The answer lies in the AD Site Link costs.  We configure arbitrary numbers that loosely represent whether or not we want AD to take a given path.  During replication, AD will take these numbers, add up the various combinations to get to a given site and will travel along the one with the lowest number.  Because of the nature of this behavior, we call these arbitrary numbers costs.  So, just like many of us, AD will try to take the “cheapest” path possible.

There are two protocols used when replicating AD: RPC over IP and good old SMTP.  We generally will use RPC over IP, however, SMTP will be used every now and then when we require asynchronous replication.  The bad thing about using SMTP is that it requires having certificate authorities in place to take care of the inherit security problems present in SMTP (at least in doing something like sending DC information across the wire).

Finally, we looked at some support tools that are useful for managing/monitoring sites and replication.  These tools are included in the Windows Server 2003 Support Tools: DCDiag, RepAdmin, Replmon.

Homework:

• Take Home Test #2 – download it here.
• Continue work on Microsoft E-Learning modules.

Implementing Active Directory – 9/28/2009

Since this class is all about Active Directory, I can’t think of a better way to start than by talking about what exactly AD is.

So, what is it?  Active Directory is the directory service system that modern Windows networks use.  Most networks you’ll find are at least moderately complex, and AD serves as a way to navigate and organize them.  AD provides us a way to manage resources such as users, computers, applications and network devices (think printers) in a relatively easy way (at least compared to the way we used to have to do it!).

We quickly reviewed some concepts you’ll need to wrap your mind around as we go forward in this class.  Namely, the schema, domains, forests, sites, organizational units, functional levels and trusts.

Speaking of functional levels and trusts, since those are new concepts to us, why not cover them now?

Functional levels serve as the limits of what features your implementation of AD can cover.  The higher the functional level, the higher the amount of functionality you’ll have.  Why not have the most functionality you can?  Well, the reason comes from compatibility.  So, I can’t have Universal Groups if I still have some ancient NT4 domain controllers hanging around, and if I want to set up trusts between two forests, I’ll need all of my domain controllers running Server 2003.  You get the point.

Trusts have to do with the authentication arm of AD.  If you’re a user that needs to log into and access resources located on various domains, imagine the royal pain in the butt it would be to maintain separate logins for each of those domains.  Trusts allow domains to trust the previous authentications of other domains.  Obviously, by default, no trusts are configured when you first install Windows, but you can configure trusts to be shortcut trusts, external trusts, realm trusts or cross-forest trusts.  We discuss these more in depth later.

We went ahead and tackled chapter two, which dealt with actually installing this beast we call AD.  Before even starting, make sure you have the following: a version of Server 2000 or greater (and not Web Edition), at least 200 MB of free space on an NTFS partition, a network infrastructure running TCP/IP, DNS, or the ability to host it, and local access to the server you’d like to install it on.  Setting up AD is as simple as issuing a command and answering some questions in a wizard, but you can also configure an answer file if you see yourself setting up multiple identical servers.  The command for setting up AD is dcpromo, and if I wanted to point to an answer file to move that annoying wizard out of the way, I might issue a command that looks like this: dcpromo /answer:a:\dc.txt.  Then scoot back and walk away.

Most domains have more than one domain controller.  The controllers are, by definition, identical, so why have more than one?  Fault tolerance, my friend.  When setting up the second or third or whatever domain controller, we can make things easier on ourselves by setting these servers up as Replica servers.  What this means is that the dcpromo utility finds an existing controller for the domain and simply clones it.

Homework:

• Take Home Test #1 – download it here.
• Work on Microsoft E-Learning modules