sysadminfocus
Advertisements

10747D – Administering System Center 2012 Configuration Manager R2 SP1 – Module 2: Discovering and Organizing Resources

Advertisements

Real World Active Directory (1) – Brief History

Video recording below:
In this series, we’ll be going through Active Directory in depth!! But we won’t be going through this in the usual way. Believe me you’ve not seen a series on Active Directory like this. At least I haven’t. That’s one of the reasons why I set out to create it. We will take an unusual way of looking at it through an architectural  perspective but we’ll try to go in depth through the process. Believe me when I say we won’t be doing any death by slides here. We’ve all seen all these boring slides training and we’ll try to avoid that. The only discussions that we’ll be going through are discussions that are necessary.

So this is the purpose of this series. First we’ll be going through the process of designing an Active Directory Domain or forest. We’ll go through the different decisions that are necessary to be made to best translate your organization’s business requirements into a reliable and resilient Active Directory Infrastructure. But we’ll not only talk about them, we’ll be demonstrating them using Virtual Box and GNS3. Now this is very cool because we will not only go through different architectures, we will design and demonstrate different scenarios including multi-national scenarios. We will be using actual machines, switches, routers, VPN connections and firewalls.

Now the first thing that we’ll start with is a brief discussion about the history of Active Directory. Now if I get any facts wrong, please feel free to contact me and let me know. I’m not an Active Directory history expert. I wasn’t there when ITU and ISO got together to create the X.500 standards but I’ll do my best to communicate my understanding of it. So here we go!

Is this Important?

Now we all know that as a System Administrator, you need to have a very good grounding and a solid understanding in the fundamentals and basic concepts of Active Directory.. we all get that… But someone may ask the question – why are we starting with a brief history of Active Directory? Is this really something worth discussing? Why cant we just go straight to the architecture and design methodologies? and that is a really valid question. My answer to that will be this – PHILOSOPHY. Many IT professionals miss this. The importance of philosophy in IT. Simply put, this means understanding the reason behind a technology. Why it came into existence.
It’s always a good idea to have at least a general understanding of the reason behind a concept or a technology. As IT people, we’re all interested in configurations and implementations but think about this, how would you be able to properly use a technology to solve a problem if you don’t understand the reason behind it to begin with. How would you be able to properly diagnose the right solution to a problem if you’re not familiar with the problems that a solution was created to solve?

What is Active Directory?

So to start with, WHAT is ACTIVE DIRECTORY. Now we’ll get into the details later on but this is just from the philosophical side. Simply put, Active Directory is a DIRECTORY. Perhaps an easy way to break this down is to look at other directories around us. The most popular one that we know of is a telephone directory. Now a telephone directory is a directory; But what purpose does it serve? If you get to a new area and you’re looking to see if one of your old classmates, you’ll go to the telephone directory to see if they’re listed and from there you will get a number to contact them on. Or let’s say you’re new to an area and you’re looking for a place where you can get some good Mexican food. What will you do? Again, you will look in the yellow pages and see where the different Mexican restaurants are located in town. In other words, a directory, LISTS the names, numbers and addresses of all the people in a local area. So if you’re trying to find where someone lives in a local area or where a business is located in an area, there’s an authoritative place that you can go to, to find their names and numbers.
– It also LISTS important numbers for emergency services like hospitals, doctors, organisations that can provide help in a crisis. BUT IT ONLY DOES THIS FOR A LOCAL AREA – not for the whole world.

Where did it come from?

So where did Active Directory come from or what is it based on?
Once upon a time.. in 1988, the International Telecommunication Union (ITU) and International Organization of Standardization (ISO) teamed up to develop a series of standards around directory services called the X.500. Just so you know Active Directory supports the X.500 information model. Now this is important… take a look at this from Wikipedia – http://en.wikipedia.org/wiki/X.500. “The PRIMARY concept of X.500 is that there is a single Directory Information Tree (DIT) which is a hierarchical organization of entries which are distributed across one or more servers called Directory System Agents (DSA)”. Does this sound familiar to you if you’ve worked with Active Directory?. An entry consists of a set of attributes, each attribute with one or more values. Now there are some important part of this article that I’ll like to point out.
1. The X.500 standard defined some protocols.. The first one is DAP (Directory Access Protocol) which was used for connecting systems to X.500 directories. Now DAP had some issues, the biggest of which is this – It uses the OSI networking stack. Why is this a problem? The internet that we all love and use today isn’t based on the OSI stack, it is based on the TCP/IP stack. The second issue is this, DAP was too complex to support on clients. So what happened was that a group headed by the University of Michigan started work on a lightweight “X.500” ACCESS PROTOCOL that would make the X.500 standard easier to utilize.
This gave birth to the LDAP (Lightweight Directory Access Protocol). The first version of LDAP was released in 1993 and after some further evolutions, the last major update LDAPv3 was released in 1997. The last update was robust enough and extensible enough to be suitable for most vendors to implement. For a Microsoft paper on its LDAPv3 implementation and conformance, please refer to this website  http://www.microsoft.com/en-us/download/confirmation.aspx?id=30734

So how does all this relate to Microsoft’s Active Directory? This is how.

In the 1980s, Microsoft released their first Network Operating System (NOS) called MS-NET. Now a NOS is a term used to describe a networked environment in which various types of resources such as users, groups and computer accounts are stored in a central repository that is controlled by administrators and accessible to end users. Then they released a NOS called the LAN Manager which they  in 1988. In 1990, they released  Windows NT 3.0. This combined many features of the LAN Manager protocols and the OS/2 operating system that they were developing with IBM. Under Windows NT, the “domain” concept was also introduced, providing a way to group resources based on administrative and security boundaries. Over the next coming years, Microsoft continued to improve the Windows NT platform. They enhanced its stability with the release of Windows NT 3.51 and added the Windows 95 GUI in Windows NT 4.0. Now because Windows NT was based on the LAN Manager architecture, it has a couple of limitations:
  • Scalability: In Windows NT 4.0, the domain is stored in the Windows registry. Although these domains are theoretically limited to 40,000 objects (users, groups and workstations), mot practical deployments cannot exceed 10,000 objects before becoming extremely cumbersome and essentially unsupportable. Simple management tasks such as changing a user’s password may require sorting through thousands of objects. Further complicating the matters, the registry is always cached in the server’s memory so large domains require a lot of RAM
  • Replication and Fault Tolerance: Windows NT 4.0 domain replication is built on a master-slave replication model: Domain changes such as adding a user, creating a group and changing a password occur at the Primary Domain Controller (PDC) which sends out updates to all Backup Domain Controllers (BDCs). Unfortunately, if the PDC is down or unreachable due to a LAN or WAN problem, the domain is unmanageable. The PDC is not only a single point of failure in terms of management, but it is also the sole source of domain information creating inefficient replication in large companies that may include hundreds of BDCs
  • Delegation of Authority: Administrative rights within the Windows NT 4.0 domain system are all-or-nothing. It is impossible to delegate administrative rights to a subset of objects such as giving a department manager rights to manage users within their department
Microsoft was aware of these limitations and the need to re-architect its Network Operating System Model into something that would be much more scalable and flexible. So when LDAPv3 was released in 1997, Microsoft implemented it in their development of a new directory service called Active Directory. SO basically when Microsoft re-architected their NOS, they developed a directory which uses the X.500 information model (without requiring systems to host the entire X.500 overhead) and they designed it to use the LDAPv3 access protocol. Take note of this:   The Active Directory is not an X.500 directory, it only uses the X.500 information model and uses LDAPv3 as its access protocol. You can find that here:

RECOMMENDED READING

HIGHLY RECOMMENDED: Active Directory: Designing, Deploying and Running Active Directory (5th Edition)

A Better Way To Learn Powershell (1)

Many System Admins or aspiring System Admins have had it mentioned to them at some point about the importance of learning powershell. New Windows admins have heard it said over and over again, “if you want to safeguard your career for the future, learn powershell”. Microsoft has made this clear and even boistered it by making it ta core focus of newer MCSE and MCSA exams. We get i Microsoft! We need to learn how to do stuff with powershell!

However, in trying to “learn” powershell, I’ve seen many admins try to memorize the commands by constant repitition. This can do you a bit of good but let me introduce you to a much better way.

There is indeed a better way to learn powershell!! (not the only way) but a better way. You can learn powershell without having to memorize commands, you can learn powershell without having to recite and cram commands. First of all, let me start by saying that if your goal of leaning powershell is to be able to type a few commands to impress your colleagues, you’re doing it wrong!! (yes you heard me). Powershell was not created so that we can learn to type single commands in the console to achieve minor tasks (even though we have to start with that). Powershell was created with one main goal in mind – AUTOMATION.

In other words, it’s not wrong to learn single commands but you must learn them with the understanding that they are building blocks for something bigger. You can complete single tasks with the GUI but if you have multiple repeated tasks to complete, then you want to automate it and let the machine do the work for you!

So in the first part of the series, I’ll highlight some simple basic building blocks for getting around in powershell and letting powershell teach you how to use it.

1. Get-Module: This lists all the installed modules on the PC that you’re working on. The way powershell works is that as you load more modules, you get access to more commands. Powershell 3.0 has about 2430 CMDLETS but you don’t have all of them available on your machine. The only ones that you have available are the CMDLETS that pertains to the modules that have been loaded on your PC.

You can use the “Get-Module List-Available” to list installed module

2. Get-Command: After you have viewed the powershell modules installed on your PC, you’ll probably need to view the commands associated with each module. To do this, the command that you need is “Get-Command -Module <ModuleName>

This will list ALL the commands associated with that module. Needless to say, this list can be a really long list depending on which module you’re viewing but for every module, there’s a limited set of objects (or nouns) that you can perform actions on. to list the nouns/objects for a particular module, use the command “Get-Command -Module <ModuleName> | Select Noun

3. Get-Help: After seeing the CMDLETS that are available for the module that you want to work with, the next step will probably be working with the CMDLETS themselves. For this, you may need help. To get help with any CMDLET, you need the following:

Get-Help <CMDLET>
Get-Help <CMDLET> -examples
Get-Help <CMDLET> -detailed
Get-Help <CMDLET> -online

There you go! Feel free to grab a PC in a test lab, play around with this and let powershell teach you about itself!! The only thing you need is to dedicate time with this and keep pacrticing and very soon, you’ll know your way around Powershell and be confident with it.

We recently had a series of hangouts on Powershell in the study group that I am part of. Please watch the videos below to see this concept in practice.

10747D – Administering System Center 2012 Configuration Manager R2 SP1 – Module 1: Overview of System Center 2012 R2 Configuration Manager

Connect

Archives