Monday, August 22, 2005

Why should you care?

Before I go too much further in discussing the ways and means of automating and improving the use of Active Directory, perhaps I should talk a little bit more about the “why” of doing so.

Implementing and managing Active Directory can be an expensive undertaking. While Microsoft originally touted Active Directory as a great way of lowering your enterprise TCO, I’d bet that many organizations are actually spending more on administration now than they did before they implemented AD. Does that mean Microsoft was wrong? No. It means that we’re not fully utilizing the features and capabilities of AD, thus adding cost to our administrative budget. Yes, you heard me correctly. I firmly believe that, if implemented incorrectly or incompletely, Active Directory will add to your Total Cost of Ownership (TCO).

Let’s take a closer look. First, I bet many of you are still running NT servers in your Windows 2000/2003 computing environment and are likely still in mixed mode. Thus you’re not able to take advantage of the full functionality of AD. Cha-ching $. And you’ve probably not yet gone through the time consuming effort of implementing a comprehensive model for use of Group Policy, which means you’re still manually performing functions that could be automated. Cha-ching $$. And have you integrated AD with your HR application to automate role-based user provisioning/de-provisioning? Cha-ching $$$$ (user provisioning, frequently called Change-Add-Move or Move-Add-Change, often represents up to 40% of your TCO in a large environment). Did you adapt your system administration staffing model to fit the new workflows enabled by Active Directory, or are you using the same staffing model you used when performing NT administration? Cha-ching again $$$.

I could go on, but I’m sure you’ve understood my point already. These examples illustrate exactly how an organization ends up spending more by implementing Active Directory. Unless we adapt to make good use of technology tools like AD, we’re simply “putting lipstick on a pig”. (I hope that phrase is recognized outside of Texas. I once described someone as “all hat, no cattle” to a friend from Michigan, and he’s still laughing at me.)

Monday, August 15, 2005

OT: Dodgeball

Has anyone out there tried Dodgeball? I am a rabid user of LinkedIn for professional networking, but haven't yet made the leap to social networking. And Dodgeball takes things a step farther, no? I'm intrigued. But I wonder about the downside. Would love to hear anyone's experiences, whether good or bad.

Saturday, August 13, 2005

Active Directory Group Policy

I’ve already opined that we technologists have had the wrong focus on AD for the past several years. Based on my extensive background in providing outsourcing services, my methodology for designing and implementing Active Directory has always been based on how AD will be managed. Anyone who has managed an enterprise with hundreds of servers probably has a similar focus. But when you’ve managed multiple customers with hundreds of servers each, constantly honing administrative efficiencies becomes a calling. So after the initial challenge of learning Active Directory design basics, I quickly moved on to focus on using AD as a tool to streamline administrative work. And that is where I believe we should all be focusing now.

The most obvious means of gaining administrative efficiency is by managing users and objects through the use of Group Policy Objects. Yet I find that within most organizations, defining and managing Group Policy is considered a tremendous chore. Many administrators strive to minimize the number of GPOs in the environment, instead relying heavily on manual or scripted methods of managing users. When Group Policy can provide such tremendous administrative efficiencies, why aren’t more of us using it extensively?

I believe administrators shy away from Group Policy because they view it in an incomplete context. Group Policy should be seen as only one expression in a larger mathematical statement that ultimately equates to Policy Based Administration. Group Policy is the technology component of the equation, and will never equate to Policy Based Administration (PBA) by itself. We also require a clearly articulated model and corresponding policy definitions to make the equation add up. To prevent Group Policy Objects from becoming an additional administrative burden, we must first define the model we’ll use to achieve PBA and then define the policies that enable us to achieve the model. Group Policy is simply the technology, or tool, that enables us to deliver the model.