formats

Have you ever just been starring at your computer saying, “Come on already!”  Or, “if you don’t hurry up, I am getting out a soldering iron and converting you into a toaster!”  No?  Are you lying to me? Am I just impatient?  Well, if I am, I am not alone.  However, experience has been kind enough (read: I am still alive) to teach me that sometimes, it just takes time.

In general, patience is hard learned in computer work.  I remember coming up with the Starbucks rule.  When creating VPN changes, make your changes and then go to Starbucks; when you get back it will be working.  When it comes to Active Directory, it is actually worse.  Patience isn’t needed just to get the things working: patience is required so that Active Directory isn’t damaged by troubleshooting.

You see, when doing Active Directory work, you sometimes need to slow down.  Why?  It all takes time.  KCC, time synchronization and replication over however many links data has to go across. This is just how Active Directory works since it is a multi-master system.  And before anyone gets any ideas… yes, we all want it to be a multi-master system and accept this as normal.

As a general rule, when doing a major Active Directory project, work at the pace of the slowest task.  Let the changes matriculate. They need to.  In fact, over time it appears that once everything is done and complete… give it a good twenty four hours and then double check it.

Twenty four hours?  Am I insane? Nope.

Take the time and validate that the changes matriculated.  Why?  You see one of the biggest pains in Active Directory is when you don’t realize your environment has some KCC, replication or time errors… and the changes you think went through… didn’t. This does happen.  So don’t rush it.

When you rush it, you make mistakes.  Like not backing up every domain controller when doing a domain transitions or not documenting the changes you are making in a migration. Take the time that the job actually requires.

Oh, and since you’re now taking the time to do it right, how about we all try and  remember to finish the job.  Active Directory projects are left incomplete with epic proportions. Take the time, and finish it. Really finish it.  Yes, even fill out sites and services.  It is all important and makes it easier for those who come after you.

When working with Active Directory just take it methodically.  Then make sure the replication is done.  Rush and you may make a mistake and end up rebuilding your forest.

 

 
formats

On Friday the seventh of September Microsoft sent out an email that is bound to drive many of the Windows 7 certified IT folk to drink.  And Microsoft should have known better. Hopefully you have read my valuation of the MCITP Windows 7, Enterprise Desktop Administrator… it will help explain what the confusion really is about. But wait, there is more!  Well here is an excerpt from the email they sent out.

“Soon you will receive an email to congratulate you on your Microsoft Certified Solutions Associate (MCSA): Windows 7 certification you have earned.  You may be wondering what the MCSA: Windows 7 certification is and how did you earn it.”

“In April 2012, Microsoft announced new certifications that have been re-invented for the cloud, covering on-premises skills as well as in the cloud.  As part of our efforts to grandfather our existing customers into the new program, we are awarding those individuals a new certification under the new certification program to jump start them towards an expert level certification in the program.   For individuals that have already earned the Microsoft Certified IT Professional (MCITP) Enterprise Desktop Administrator or MCITP: Enterprise Desktop Support Technician, they are being granted the MCSA: Windows 7 certification.”

So, there are two Windows 7 MCITPs that are completely different certifications… wouldn’t you expect Microsoft to know better?  Guess, not, they are adding a third… that is meaningless. So how do you tell which Windows 7 certified staff knows client management and which are highly trained help desk technicians?  Wait, you can’t?  Nope… not with that MCSA. So what do they mean?  Great question!  Microsoft, what do they mean?

You know there is one other weirdness here.  MCSA was used for a decade plus to define the Microsoft Certified Systems Administrator… a server certification (actually you can still get one). So, we have a “free certification” of the new models.

Confused yet?  I am.  Please Microsoft, end the confusion!

 
formats

So, when you are looking at hiring or being hired in IT (or maybe more aptly named in the old days, managing information systems staff) you will always hear about certifications.  You went and decided to get one… and supposedly this blog is going to help you find some value in them, right?  Right.  Here goes the second article in the series.  It is starting with one of the least coveted, most often required and completely misunderstood certifications.

So what does the MCITP Windows 7, Enterprise Desktop Administrator certification mean?  It means you can support Windows 7, right?  Wrong.  Would you believe that the actual MCITP test doesn’t even include supporting Windows 7 systems or users in the description of skill measured?  Not even one percent.

Here is the breakdown of what skills are measured with the final test for this.  Planning and Managing a Client Life Cycle Strategy (16%); if this sounds more like planning the management of a bunch of workstations, then you are right.  Designing a Standard Image (17%); hey wait a minute, this is a major task that you do when deploying operating systems isn’t it?  Yes it is.  Designing Client Configurations (17%); this sounds like more deployment skills… maybe even large scale deployment skills.  Designing a Windows 7 Client Deployment (15%); ok, this is straight up deployment… and it actually touches on MDT and SCCM (System Center Configuration Manager).  Designing Application Packages for Deployment (17%); packaging, are you kidding, this is a major task that is often outsourced because people do not know how to do it… but wait there is more.  This section also includes deployment strategies and skills including virtualized, Remote Desktop Services, Group Policy, or software distribution (read SCCM).  Identifying and Resolving Deployment and Client Configuration Issues (19%); this should read: Windows 7 troubleshooting from the domain, forest, network, and Group Policy Object or deployment level.

So if you couldn’t find the support Windows 7 angle, you are looking at the wrong part here.  See the support skills are a building block to get to the MCITP.  They are tested in the MCTS: Windows 7, Configuring certification, which someone with this cert has to have already earned.  So getting to the MCITP includes support elements, but it really is more of a managing workstations certification than a support certification.  This certification validates your ability to deploy operating systems, desktop applications and to manage the Windows 7 client life cycle.

There actually is a Windows 7 support certification at the MCITP level.  MCITP: Windows 7, Enterprise Desktop Support Technician is the certification for support.

So Microsoft says the audience is: “Candidates for this exam should have a minimum of three years of experience installing, configuring, and administering clients in a Windows networked environment and also have experience deploying operating systems and applications. Candidates should be familiar with the client administration capabilities of Windows Server and with management tools such as the System Center suite of products.”  So they are expecting three years of high end, highly skilled work that just happens to be directed to workstations.

Now let’s compare this to the candidate audience for the MCITP: Windows 7, Enterprise Desktop Support Technician that everyone seems to be mixing up with this certification. “Candidates for this exam support end users who run Microsoft Windows 7 in a corporate environment. They should have experience using applications that are included with the operating system, such as productivity applications used in a corporate environment and Microsoft Office applications.”  Did you notice the lack of a time in the role listed?  Yep, it isn’t there.  This is a significantly lower valued certification.

For my reviews I will be rating certification on a 1-10 scale.  Ten will be the highest, with one the lowest. So on a ten scale, with MCM, CCIE and JNCIE at the top as a ten, and Microsoft Technology Associate (MTA), A+, CCENT at the low end as a 1.  Well, I hope you weren’t waiting for me to rate those six certs… they just were rated as my baseline.

How would I rate these?  First off let’s rate the certification everyone mistakenly thinks this cert is.  I would rate MCITP: Windows 7, Enterprise Desktop Support Technician at about a 3 on my scale.  The certification does not have a long time in the role required to master the skills and is mainly aimed at technicians able to resolve operating system issues by telephone, email, connecting to an end user’s system remotely, or by visiting an end user’s desktop.

MCITP Windows 7, Enterprise Desktop Administrator is a weird one.  The perceived value is low, possibly a 3, as everyone mistakes it for the other Windows 7 MCITP.  However, the real value of the skills this represents is significantly higher.  I would rate this certification a 5.  Additionally, if this certification is combined with a MC TS: Windows 7 and Office 2010, Deploying; that is a major boost.  That combination would rate as a six… and nearly any consulting firm that does Windows 7 (or 8) deployments is, or should be, looking for just that combination.

What do you think?  And what certification would you like me to take a look at and grade next week?

 
formats

So, when you are looking at hiring or being hired in IT (or maybe more aptly named in the old days, managing information systems staff) you will always hear about certifications.  Great, let’s get some!  So, you have a cert now.  What does it matter?  What do they really mean?  As the first in a series of articles on certification on this site, I am going to take a look at a variety of certifications and help you understand what they mean and help pin a little bit of valuation on them.  Not in cash, but in skill level.

Today we live in an age where everything we do is cataloged, blogged about, qualified and quantified. But in the end, all people can say is where you worked and what people say you have done.  Think of certifications as putting up headers or tabs in those catalogs of you.  Headers saying: yes, I can do that.  In the end, one caveat: remember when discussing certs, certs do not equal experience; certs validate experience.

So how does your certification stand up to other certifications?  To look at that we look at a variety of things.  One is how much time is expected of the certified person to work in the technology before taking their certification.   An additional view is how specialized is it? Sometimes what makes a certification different is that it is on an obscure technology.  In these cases even a low ranked certification, such as an MCTS could be valuable, for its rarity.  An example of this is the “Microsoft Certified Technology Specialist (MCTS): Forefront Identity Manager 2010, Configuration”.  Ninety nine out a hundred people have never even heard of the technology, but if you need someone to manage or implement it: it can take years of effort just to find someone.

Here is another piece to remember, when prepping for this certification can you really just study a book and pass the test?  One example is the A+.  Everything I have heard is a yes.  Granted, that is heard, I have never taken it.  On the other hand, “Microsoft Certified Technology Specialist (MCTS): Forefront Identity Manager 2010, Configuration”?  Good luck.  I don’t think 99 out of 100 people could pull it off.

And lastly, there is another component that that should always be looked at.  That is a simple question of: does this certification enhance or get enhanced by another certification?  This has to be taken into account when doing a valuation of certifications.

For my reviews I will be rating certification on a 1-10 scale.  Ten will be the highest, with one the lowest. So on a ten scale, with MCM, CCIE and JNCIE at the top as a ten, and Microsoft Technology Associate (MTA), A+, CCENT at the low end as a 1.  Well, I hope you weren’t waiting for me to rate those six certs… they just were rated as my baseline.

In this series I will review many certifications.  These certifications will all be IT related in some way or another, and I will try and qualify these so you can think about what your headers will be.  One thing though, always keep that one caveat in mind: remember when discussing certs, certs do not equal experience; certs validate experience.

What do you think?  And what certification would you like me to take a look at and grade next week?

 
formats

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.
 
 
formats

By Robert Meyers

The release of WS12 is going to have a major impact on all of us who implement and manage Windows environments. There are major changes and we are all going to learn them or go the way of the dinosaur.  As someone who grew up in CP/M, trust me: it can be done.  So what are the big standouts on changes that I am going to have to worry about?

First off we have the interface, and for the first time since Windows NT 4, we have a major interface overhaul.  And I mean a major overhaul.  To me it seems like an amalgamation of Windows 2000, 3.0 (yes, 3.0) and Windows Phone 7.  Does it work?  Yes.  Do I consider the look somewhat hideous?  Yes.  Could I get used to it? You bet.

PowerShell V3 for the win. When you add domain functionality you get a link that lets you output the settings.  These are actually an output of a PowerShell script.  PowerShell is now everywhere… as it should be.  The days of DOS, PowerShell V1, PowerShell V2, Quest PowerShell and VBS being mixed everywhere is done.  When servers are 2012, PowerShell V3 rules the roost and renders the others inconsequential.  Now, if you are a VBS guy, well, as a CLI guy, I feel for you… but get over it.

While I am going to skip talking about all the incredible new features of 2012, let me just set one expectation: Active Directory Domain Serveries 2012 is a massive upgrade.  Not a minor update like 2008 R2, where you received great functionality with hideous management so people just ignored it.  No, you gain everything.  Features, functionality and most of all usability; Server 2012 has it all in the new version of Active Directory.  Think of all the pain we have all gone through trying to convert from Quest PowerShell to PowerShell V2 AD Cmdlts?  Well everything you do now is shown with its PowerShell syntax.

I really want to go over the new functionality like the new virtualization safe domain controller cloning or the death of the USN rollback… but let’s not get ahead of ourselves.  Download the OS and install it.  It took me 30 minutes to download, install and configure Active Directory.  How long do you want to wait to lab yours?

 
formats

By Robert Meyers, MCITP

As we have all waited with baited breath, Microsoft System Center 2012 has been released.  Now that it has been out for a few months and I have been done both lab and production installs, and our team has done more of the same, it is time to discuss some of these new products.  So where better to start than the new and improved installer?

Microsoft writes, “System Center 2012 – Unified Installer is a tool that provides a single-user-interface experience for the installation of [all] seven System Center 2012 components, including all prerequisites and Microsoft SQL Server 2008. Unified Installer provides a means of distributed installation from a central point using the existing component Setup.”  Does that sound awesome?  You bet.

Now how many people here have heard the old saying that Microsoft only gets things right on the third incarnation?  Let’s just say this is not the third incarnation.  After speaking with multiple System Center implementers there seems to be a problem.  We all are averaging only about 50% success rate in installing the suite with this tool.

So, if you are in a lab environment, give it a try.  If you are implementing it without a schedule, give it a try.  When this works it is like a dream.  When it doesn’t… it is nearly impossible to troubleshoot.  So, if it doesn’t, you may have your work cut out for you.

So my take on the System Center 2012 Unified Installer? This product is an unmitigated disaster and an unfulfilled dream.  Microsoft, please fix it.

 

Tech tip:

When importing software into SCCM, check IT Ninja and see if they already researched all the switches for you.  You may be able to save days of work in minutes.  Just remember, share here when you discover new techniques.

 
formats

By Robert Meyers, MCITP

We all love Microsoft’s active directory.   It just works.  You install it and walk away.  Right?  Nothing else to do.  Right?

If a car company built a car, but only protected the outer shell from rust. painting, bluing or annealing nothing but the outer shell, the body.  Not the under carriage.  No parts of the engine…  nothing but the outer shell.  That car would run.  It would run as well as any car with a bit better finishing.  Heck, initially it might even run a bit better since it is lighter.  But how long would it be till the rust literally ate the car apart from the inside out?  Ask anyone who has ever been in a cold climate, they know: it wouldn’t last very long at all.  Heck, it isn’t uncommon in areas that salt their roads for cars to last half a decade with complete sealing.

So why don’t people finish setting up Microsoft’s active directory?  Why not just setup sites and services, setup organizational units… and maybe ever group policies?  No, I don’t know the answer.  In this case I just know this is an industry wide problem.   This is what leads to a great many problems that most administrators either don’t understand or often, just have no idea it even can occur.

In general, systems administrators’ love active directory.  It is logical and it just works.  You install it and walk away.  Or at least that is the realization I have had after viewing nearly a hundred installations of active directory over the last decade.  People install active directory and say, “we’re done!”  This is a fallacy.

When you simply install active directory, and walk away, you haven’t really setup anything.  This is normally referred to as installation, not setup.  And this can also be referred to as a disaster in waiting.

As a specialist in active directory, I always check on errors and events.  Or as Microsoft states, troubleshooting active directory starts with: “an event reported in an event log;” an alert generated by a monitoring system, such as Microsoft Operations Manager (MOM);” or “a symptom reported by a user or noticed by IT personnel.”  Working from one of the first two are a lot easier than the last.  Granted, if you didn’t setup active directory… many alerts are worthless or just don’t generate.

When active directory is fully configured, you get to view a massive amount of information.  Often information to the point of information overload.  And yes, you read right: information not data.  When it isn’t configured, you basically give up on troubleshooting.  Why?  Because in general you don’t get the alerts that you should have had to work from.

When you setup active directory, when you completely setup active directory, things really begin to work.  Your alerts actually begin to mean something (and in many case, simply begin being available).  You can actually see when you are having issues.  And most importantly: when something does go wrong, you can fix it.

So, when you see that active directory is simply installed, ask yourself: why didn’t someone they finish it?  If it’s your work: why wouldn’t you finish it?  I always hear the same from every engineer or administrator I have asked have said the same thing: it works.

Of all the answers, “it works” is completely without merit.  Professionals I have great respect for have been included in this group.  “It works” is not the answer.  It is a disaster.

The old saying is that if you take on a job, work it till completion.  So I recommend finishing active directory.  Then it really works.

Tech Tip #1:

The command to run a general domain diagnostic of all domain controllers in your domain and export to a log are listed here.

DCDIAG /V /E >> “C:\DCDIAGLOG.TXT

 
formats
Published on June 6, 2012, by in Active Directory.

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.

 
formats
Published on June 8, 2010, by in Active Directory.

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.