Tag Archives: GPO

Certification Spotlight Series: MCITP Windows 7, Enterprise Desktop Administrator… how does it rate? Valuable?

MCITP

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?

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