5 Ways to Break Your Windows Network

So you want to make your Windows network more secure by “hardening” it against attack. Or maybe you want to tweak Windows to make your servers perform better. Or maybe you want to develop a custom application that takes advantage of some cool Windows “hack” you’ve read about. Should you proceed?

What many administrators don’t know is that some steps they take to harden their systems, eke out performance gains or take advantage of undocumented registry hacks might have a downside — they can place your systems and even your network into an unsupported state. What does this mean? It means that when things start going wrong and you call Microsoft Customer Support Services (CSS) for assistance and the support engineer asks you what the problem is and you tell him what you’ve done, the engineer replies, “Sorry, you’re out of luck — what you’ve done has placed your server into an unsupported state. You need to flatten and rebuild.” Yikes!

Let’s look at five easy ways you can break your Windows network and place it into an unsupported state. And by “unsupported state” I don’t mean only that CSS may have difficulty supporting you when you have trouble — I also mean you as an administrator might find it difficult to support what you’ve built with your own hands: your network.

1. Hardening Your Network So Much That It Becomes Brittle and Cracks Start to Appear

Everyone is concerned about security nowadays, especially network administrators. But it’s easy to become too concerned about network security, and an obsession with hardening your systems can quickly lead to an unsupportable condition. Here’s a simple example: You’re scratching your head wondering why Outlook Express is installed by default on Windows servers. “Who needs a mail client on a server?” So you nuke OE in the name of “reducing your attack surface” and sit back, happy that you’ve just improved the security of your servers. Then things start going wrong and you discover that Microsoft Operations Manager is no longer sending you e-mail alerts from your servers. Could there be a connection?

Here’s another example of how overzealous hardening can cause undesirable things. You notice one day that print queues are no longer being scavenged by Active Directory. What’s going on? After a long talk with support engineers, you discover you shouldn’t have disabled the Print Spooler service on your domain controllers.

“But my domain controllers aren’t running the Print Server role. Therefore I thought the Spooler service wasn’t needed on them, so I disabled it.”

Once again, your zeal for security has gotten you into trouble. This time the support engineer helped you determine the problem — next time you might not be so lucky. For example, the quickest way to thoroughly mess up your Windows servers by “hardening” them is to modify the default Access Control Lists on your system directories — you wouldn’t believe how often people try this. Don’t do it.

2. Developing Applications That Break When the Next Version of Windows Comes Out

You’re proud that you developed a custom application for your business that uses an undocumented registry setting to streamline the workflow between Active Directory and some line of business application. Then Service Pack X for Windows came out, and when you applied it, users complained the application no longer worked. What’s going on? Some digging reveals that the problem is caused by a change in the way the registry setting stores data. Your initial reaction is to blame Microsoft: “How dare they change the registry setting without telling me!” But calm reflection tells you that you shot yourself in the foot.

Undocumented registry settings are undocumented for a reason — they’re hidden implementation details that are subject to change without notice. And that goes not just for the registry but also for Win32 and .NET application programming interfaces (APIs), too. Just because you’ve figured out how to make an API do something it’s not documented to do doesn’t mean you should use your discovery in an application your business depends on. If you want to write apps that last, use only documented APIs and registry settings, because these are the only ones that Microsoft officially supports.

3. Making Your Deployment So Complex It Becomes Almost Unmanageable

Group Policy is a Windows administrator’s friend, but not if you make things too complicated. Sure, Group Policy features such as Block Inheritance, Enforced, Loopback, Security Filtering, WMI Filters and so on give you a lot of flexibility in how you ensure or prevent specific policies from applying to particular users or groups in different situations, but did you know all this flexibility can make your deployment so flexible that it breaks?

“Hmm, why isn’t this policy applying to that user?” you ask yourself as you scratch your head and stare at the effect of dozens of Group Policy Objects displayed in a report generated by the Group Policy Results Wizard.

Domains are another example of complexity that can become unmanageable. Does each business unit really need its own domain? Are multilevel domain trees really needed in a company your size? You’d be surprised how many large (even very large) companies get by with deploying a single domain in their Active Directory forest. The moral here: Build a network you’ll be able to support.

4. Using Products and Tools That Are Grossly inappropriate for the Size and Scope of Your Business

Complexity is also closely related to the tools you choose to get the job done. For instance, deploying Microsoft Systems Center Configuration Manager would probably be overkill if your network consists of only 75 machines. On the other hand, using the Microsoft Solution Accelerator for Business Desktop Deployment (BDD) for deploying Vista to 5,000 desktops across an enterprise would also probably be inappropriate — BDD is more suited for midsize networks than large enterprises. You’ll quickly get yourself tied up in knots if you don’t choose the right tool for the job, and your support costs can also escalate quickly if you’re not on the ball.

And just in case you weren’t sure, so-called “unsupported” tools such as the Windows Server 2003 Resource Kit Tools really are unsupported. Use them at your own risk, and don’t expect CSS to provide you with an easy way out should you foul up your network using them.

5. Tweaking Performance to Eke Out More Gains Until All Hell Breaks Loose

I’ve seen this kind of thing again and again, especially lately with Windows Vista.

For example, you’re not happy with how the Indexing service works in Windows Vista so you start messing around with its configuration to improve things, and soon it’s not working at all. Or you’re unhappy with slow file transfers for large files and you start modifying TCP/IP registry settings to tune network performance, and in no time your machine can’t see the darn network at all. Let the techies at Microsoft have a go at fixing bugs instead of trying to work around them using tweaks and hacks.