Exchange administration skills

I’m working on a project that will involve (big surprise) teaching Exchange 2010. That got me to wondering: what skills do commercial administrators and consultants actually need?

To put it in context, some explanation might be in order. I’m working on designing an Exchange 2010 curriculum that will be used with Acuitus’ Digital Tutor. The overall goal of the Tutor is to take someone with no computer skills and turn them into a competent, skilled junior sysadmin– someone who can troubleshoot and fix complex problems with Windows Server, Cisco IOS, and Exchange. We’ve already proven that we can do this with Navy students. Now we’re going to try it with a few different populations.

For Exchange 2003, which is what the Navy’s still using (yeah, yeah, your tax dollars at work), the curriculum design was simple; the Navy asked us to teach the same things they teach in their legacy courses. However, for the new course I have a free hand to include whatever I think a junior Exchange 2010 admin needs to know. 

When Tony and I put together the curriculum for the Exchange Maestro classes we focused on what we thought experienced admins needed to know about the new version. In general, all my writing and teaching has focused on explaining new features in version N to admins who were familiar with version N-1 (or N-2). That leaves me with a gap to fill, so I thought I’d ask the Exchange tribe for some feedback.

For a junior administrator– not a hotshot who’s comfortable editing EDB files with WinHex; not someone who remembers what the Exchange 5.5 IMS was for– what do you think the most important skills and concepts are? If you were hiring such a person, what would you expect them to know on day 1? What knowledge or skill would delight you if your new hire turned out to have it? What areas of Exchange 2010, in theory or practice, were most challenging for you to learn?

You can e-mail me your answer directly if you like, but I’d prefer that you leave it in the comments to hopefully stimulate some discussion.

Technorati Tags:

About these ads

14 Comments

Filed under UC&C

14 responses to “Exchange administration skills

  1. Mike

    A skill that would delight me in a new hire would be if he/she could take one look at an Exchange queue and determine if it was overridden with NDR’s from SPAM, and then know how to take the proper steps to clean it up. I have met a lot of “experienced” admins that overlook the simple stuff…

  2. One must-have going forward: comfort with X.509v3 certificates! Junior admins may not need to know how to generate them, but they definitely need to understand them, know how to pull them up and read them, be comfortable with the Certificates MMC snap-in, and validate a certificate chain/trust (and know how to troubleshoot certs in IE vs. Outlook to actually find certificate issues).

  3. Michael Dragone

    I don’t expect the junior admins to know how to actually do that much out of the gate, but only because they likely haven’t had a lot of hands-on experience yet. So, the more theory they know and their eagerness to learn the hands-on is what would impress me.

    Some really good-to-know items off the top of my head (besides certificates as Devin mentioned – those are a must in modern “non-Navy” Exchange):
    1. How to read email headers and use Message Tracking Logs to determine the path an email took. “How come this email took 10 seconds to get to me?” is a common question.
    2. How to quickly determine the overall health of an Exchange server. Are the queues backed up or is mail flowing through? All the services running? Databases healthy?
    3. What Retention Policies are and what they do. “What does it mean when Outlook says this message will expire in 14 days?” is another common question.
    4. An basic understanding of how Exchange integrates with telephony for Unified Messaging.
    5. PowerShell. I still meet people who are flat-out afraid of the command line. It seems that while our end user devices are getting more GUI-friendly (hello iOS), our infrastructure devices are getting more CLI-friendly (or CLI-only). Command lines lead to scripting and automation and increase the value of a junior admin to their organization. Apparently their not the only ones – anyone go to Don Jones’s “PowerShell Crash Course” at this year’s TechEd? It was mobbed!
    6. How end devices integrate with Exchange. What does Autodiscover do, why do we use a CAS object instead of a server name, etc.

  4. Andrew S Higginbotham

    I agree with Devin on the importance of certificates. Knowing why a client cares about the issuer, expiration date, and the name it’s using to connect matching what’s on the cert is vital for exch07/10/O365 connectivity issue troubleshooting.

    Also, I would spend time on the autodiscover process as well as outlook connectivity for the different web services. I work in exch services and support and I can’t tell you how many issues I’ve seen come in related to outlook prompts or connectivity issues related to a bad cert or incorrect internal/external url or uri value.

    Letting them know a-z how an outlook/active sync client connects can be very helpful for a jr admin working helpdesk issues. When I’ve taught exch 2010 level 100 classes this is always an area I put a lot of focus on.

  5. Andrew S Higginbotham

    I agree with Devin on the importance of understanding certs. Knowing why a client cares about the issuer, expiration date, and name its connecting to being on the cert is very important for troubleshooting and configuration.

    The other area I think anyone configuring or troubleshooting exchange should know is autodiscover and the autoconfiguration process. Not only for exch 07/10 but also for O365. Walking through the process a-z and letting them know why the internal/external url’s/uri’s matter. Anyone working a helpdesk needs to be able to identify and troubleshoot to resolution why outlook could get an auth prompt, fail to download oab, or use ews for free/busy or ooo.

    When I have taught level 100 Exchange 2010 classes, these are the areas I try to focus on right off the bat.

    Also, I work in Services and Support and I can’t tell you how many Exchange break-fix issues come in that are related to certs, autod, and iis.

    • Andrew S Higginbotham

      Sorry for the double post. Had a browser issue that made it seem like the 1st one didn’t go through so I re-typed it as best I could remember.

  6. Protocols and what they do.
    Firewalls, and how they stop or allow the different protocols.
    Services, and which ones do what and what needs to be started.
    Powershell, and how to query simple statuses in Exchange.
    AD, and what the important user objects are.
    Roles, and which does what.
    Transport and everything about it, as that is the most important role.

    • I was hoping Greg would drop by so the two of you could argue over whether CAS or transport is more important.. but we all know that UM is the most important role of all.

  7. Paul,

    Over the years in previous roles, I’ve enjoyed having new junior admins start and then training them up for the job. That was for pretty general role including Windows, Unix, Exchange, VMware and SAN, so not quite the same. These days I’ll do a half-day introduction to Exchange 2010 for (usually) generalists with Exchange 2003 experience. So hopefully my two cents are useful.

    First and foremost – they need to be enthusiast. If they’re not excited about the role then it’s a lot harder to teach them and they won’t have the self-motivation to take those junior skills further and will always bounce back problems.

    Core knowledge is the start of a good foundation. A basic understanding of AD, Windows Server, Services, DNS, Networking, Backups and Clients.

    Before Exchange, an overview of SMTP. What it is, how server-server communication works, headers, client communication, routing, queues – the kind of stuff that can apply to any MTA.

    Then basic troubleshooting. How to analyse a problem and isolate an issue. The danger of just trying something to fix it. What information to trust and what information not to trust, i.e. the danger of relying on Google/Bing. When to get help. What to do if you break something (i.e. it happens to everyone! Don’t hide it or get out of your depth and make it worse).

    On Exchange, understanding of each role, what it performs. How does Exchange use AD, Org config, sever config and recipient config. How do clients communicate with and discover Exchange. The importance of certificates and where these are relevant.

    PowerShell? Maybe, but for a junior admin writing scripts is something that probably isn’t essential. Basic use of PowerShell and the Exchange Management Shell is useful, but probably from the aspect of being task-based.

    Steve

  8. Exchange fundamentals are key. Knowing how SMTP transport works (and doesn’t work), client access (Outlook, OWA, OA, EAS) basics, Exchange object management, and use of management tools, including PowerShell basics (piping and cmdlets). While the administrative models have changed over the years, it’s very useful to have a good AD background.

    I agree 100% with Devin about certificate usage and general PKI, although this has gotten much easier over the years. I also agree with Steve that a basic working knowledge on the above is good enough and the rest can be trained. Each environment is different, and hiring an admin who has good working knowledge of UM doesn’t really help if my org doesn’t use it. On the other hand, that kind of knowledge may be helpful to open the eyes of the business to currently unused technologies.

    It also depends on the organization’s current environment and future plans. Exchange 5.5 forced us to be storage experts, Exchange 2003 made us clustering and SAN experts, Exchange 2007 made us PKI experts, and Exchange 2010 made us load balancing experts.

  9. They need to know how backup/restore works. One of the top issues of MS Support is full transaction log disks :-) So a bit of an understandig what ESE does is essential. I’m not talking about ESEUTIL, etc. only basic understandig.

  10. I took a look at some of the common things that pop up on our first and second line internal DG’s:

    Troubleshooting SMTP issues via usage of protocol logging, connection logging etc. Backup and importance of log truncation. Managing delegate access via PowerShell for calendar, inbox etc. How calendar processing works, how to configure and control access, delegation etc. Troubleshooting Free/busy. GAL / OAB updates and differences with outlook in online/cached mode. Troubleshooting CAS using IIS logs etc. Best practices when patching High availability installs. Best practices for Anti-Virus exclusions for all Roles. Difference between Remove/Disable Mailbox and implications of both. Managing Transport Rules. PKI especially renewing Certs. Performance management and throttling policies and why they are needed for things like BES etc. Configuring Receive connectors for relay, printers and 3rd party applications and how best match applies. Basics around AD and DNS, their importance and the role the play within Exchange.

  11. Beyond the obvious basics, I want junior admins to know how to use their heads and not to rely on instructions. I have had many interviews for PFE positions where I got responses like “because that’s how I was told to do things” or “I’ll restart Exchange IS”. Yikes!

    Even if you are junior, if you real aspire to be something someday, make sure you have solid understanding of the basics, components, how they work together, how to NOT do things.

  12. Gregorio Parra

    I think that one must to add is understanding of performance concepts, like disk high latency or queuing behaviors, that are so painful for Exchange, also processor and AD latency issues, this is useful not only for Exchange, those concepts are for many other admin operations, you know, “vital signs” :)

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 )

Google+ photo

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

Connecting to %s