The BPA exists for a reason…


Ah, another SBS post. I didn’t expect one to come so soon.

I’m a big fan of Microsoft. I think they make good products, and in fact, I believe that Windows 7 is probably their most “must have” upgrade since Windows 95. Their Windows Server 2008 R2 is an equally good server OS. You can put together a pretty nicely running small office infrastructure in a relatively short period of time, with a modicum of skill, using these two products.

Because not everyone is a techie, Microsoft has created a tool called the Best Practices Analyzer. This could be best summed up as “we’re going to check your work, and let you know if you messed up”. Let me say that you don’t have to slavishly follow the BPA’s instructions like a robot. Sometimes you might have reason to have a “fairly unique” configuration in a production environment. However, it is good to have an understanding of what the BPA is telling you, so that you may decide to leave a configuration as a best practice outlier or not, once it has been brought to your attention.

The BPA has been around for a while, and I used to use it often to “check my work” (or the work of others) in Exchange implementations. The BPA has also been around for a while for ISA, Active Directory, and others, but when I set up one of those I’m usually pretty confidant I haven’t missed anything.

So, when I was recently troubleshooting an SBS 2008 environment that was having some unusual behavior, one of the first things I did was run the BPA to see if there was anything that got my attention. As it turns out, this needn’t have been one of the first things I had to do.

This environment had an upgrade from an SBS 2003 environment to an SBS 2008 environment. Guess what – the 2003 server was still running as a domain controller.

It was also running DHCP – in a class B with a different address range than the class C being issued by the 2008 box – and it was actively issuing addresses.

It hosted scripts the users had been told to manually run – that mapped them to printers that no longer existed.

It was running a non-AD integrated version of the AD zone – which was not replicating with the zone on the 2008 server.

As you can imagine, the users were not having a positive experience with their network.

So, I clean up the easy stuff, and get back to the BPA report on the 2008 box. There were 37 issues identified by the BPA. This was in addition to the fact that WSUS wasn’t running, the clients didn’t all have anti virus, and there were 97 workstations joined to the domain that no longer existed. 37 issues? That could have been identified by spending 5 minutes running a free tool? Well, I suppose if you bill by the hour, you don’t want these things to go fast…

Anyway, it took over a business day to completely clean up everything on the server(s) and touch the clients that needed to be touched. I’ll find out tomorrow if the users perceive improvement.

My point is this. Some of these tools are fairly complex. Some of them aren’t. The BPA is one more resource you can use to help you make the difference between a well running technology infrastructure and a poorly running one. Use it. Let it help. If you aren’t going to follow a particular suggestion, document it, and why, so the next guy doesn’t break something fixing what he thinks is an error.

That keeps guys like me from coming after you and spending 10 minutes writing about how he couldn’t believe the mess you made…

 

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s