Field NotesLearn to Ask for Help

Edward Dake

TOO MANY DESKTOP administrators think they never need help. We should all be islands unto ourselves and know everything there is to know. Computers do what we want them to do and only what we tell them to do, and software simply behaves as designed. Why would we ever need to seek help or collaborate with our peers?

Who cares how many administrators toil in your organization? Everyone has his assigned job and we all know what that is, so we never step on one another with settings or infrastructure changes. Is there a server you can't reach in the enterprise? Clearly, it's not down for routine maintenance; it's off-line permanently. Just delete it! Don't check with anyone to find out the real story, don't e-mail or reference any change-management documentation recommended by Information Technology Infrastructure Library (ITIL) or Microsoft® Operations Framework (MOF). Need to try some new product or procedure? Who needs virtual machines when we have real ones to work on?

Do all of these examples sound horrifying to you? As far-fetched as these situations may appear, I've encountered them all in my career as a support engineer, and many could have been avoided with some planning and cross-team communication.

The truth is that to be really effective, administrators need to rely on a whole team of personnel, both inside and outside the IT group. There's no way I can know everything there is to know about administering today's heterogeneous enterprise environments. We all need to build great relationships so we have experts to call on when necessary. My instant messenger list is full of people I respect and trust from other groups.

I've found that building a network (not the wired or wireless type) of peers to collaborate with is extremely helpful when it comes to solving problems I haven't seen before or dealing with complicated issues that involve multiple technologies. Say you're troubleshooting Active Directory® replication, for instance. Is the problem a replication issue or a DNS issue? The term "forestprep" now applies to Exchange Server and Active Directory. Which forestprep is being attempted? Do I need to collaborate with my peers in Exchange or Active Directory?

I use my contacts in Microsoft Office Communicator and Windows Live™ Messenger (newly released) sorted by groups, and I can't tell you how many times I have solved complex issues with assistance from fellow engineers. Get to know your peers and ask them for help if you run into something that falls outside of your specific support boundaries. Most people are very willing to help and it could mean resolving your current issue in a more timely manner or even stopping an issue before it becomes a big problem.

Other tools in my collaboration toolbox include Microsoft Technical Communities, Support Webcasts, and Product Solution Centers. All of these are available as menu options on the Microsoft Help and Support page under Self Support Options. I have found the Newsgroups (in the Technical Communities section) very handy for supplying information and advice from people who have experienced the same issues or who have environments that match my own.

Adding yourself to newsletter distribution lists for specific technologies is also helpful. Such bulletins contain tips and tricks, best practices, news about upcoming releases, and other information that has helped me resolve issues and kept me aware of features that are on the way.

Testing in a virtual environment is a safe way to try out schema updates, group policies, environment changes, and many other products and processes. You can use Microsoft Virtual Server 2005 R2 (free download after registration) to build a lab to test many updates before rolling them out into production. In this way, you can find and resolve potential problems in a non-production environment and avoid unexpected issues during your enterprise-wide rollout. I've found the following resources in the Windows Server System™ Reference Architecture (WSSRA) very useful when planning and designing a virtual test environment. In particular, see the documentation entitled "WSSRA Virtual Environments for Development and Test". The chapter on Planning, Testing, and Piloting Deployment Projects is especially useful.

I also highly recommend TechNet Virtual Labs for demos and test drives of products. The labs are updated regularly and they're a great place to get a first look at a product or technology without the time and effort of building an environment yourself.

I have also found the Help and Support feature in current releases of many products to be very useful. It has improved over time and is now an invaluable tool to use to research help for current technologies and updated content. Don't forget about online documentation and even e-books for quick searches and assistance. Being a great administrator doesn't mean you need to know everything. Perhaps most important is knowing where to go for help. You'll be an even better administrator by collaborating with peers and with those in other groups to help resolve issues that cross boundaries or are new to you. The beauty of our industry is that we are a community and we should work to build relationships with each other. I often rely on the help of others to drive issues to completion. The end result is a satisfactory resolution and my administrative skills are enhanced by working in collaboration with others.

Edward Dake has worked for Microsoft Corporation since 1997 as both a Technical Account Manager and a Support Engineer. His current role is Technical Lead for the Directory Services team in the Customer Service and Support organization.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.