Ever wonder how we internally develop our people? How our top people continue to develop? As one might expect we do REQUIRE the technical staff of Product Support Services (PSS) to maintain their MCSE/MCSD certification. However, this is largely accomplished on the individual's own time. The program new hires are put through depends largely on the major product they will be supporting. In Exchange, approximately 3 weeks of compressed training covering topics on the Operating System, Active Directory, and Exchange are covered. In addition further training is provided by the “specialty team” the individual will be a member of such as Administration, Client, etc. In the majority of cases, this training stems directly from the content and whitepapers that has been published and freely consumable by customers.
Readiness and Sustained Education is the program internally of providing training related to new products and features such as Service Pack releases, feature additions, depth knowledge in a product, etc. Various teams work together to determine where knowledge is lacking based upon analysis of the cases that are coming in. For example, Storage Area Network concepts. Not directly related to Exchange, but engineers are required to have some conceptual understand of the devices. Further training is also provided in the Exchange group in a triage format where engineers take turns covering topics they have strength in such as performance monitor analysis, cluster recovery, mail flow troubleshooting, etc.
So what about Escalation Engineers? It isn’t what you would typically think… years of technical training? Not even close. It all about architecture and fundamentals. In a recent internal meeting, a question was posed to a panel of EE on how do they stay abreast of technology? The answer was simple, we don’t. We rely upon the fundamental understanding of how things work. What I am referring to is how the Operating System Platform works, specifically the interaction of a process running on the operating system.
Regardless if you are running the basic command line application or a sophisticated server based application as Exchange, the rules are the same. If you want to synchronize threads within the process you use one of half-dozen synchronization mechanism (e.g. critical section, mutex, timed event, etc.). If you want to transmit something over TCP/IP from a usermode application you have to use Winsock or some wrapper for it. If you are in kernel mode, then you have to submit requests via IRP (I/O request packets) to the tcpip driver. The process of allocating memory and interfacing with the network all require adherence to the rules set forth by the operating system.
So for example say we introduce a new log file replication service. Here would be my immediate questions to attempt to answer:
Is a push or a pull scenario?
Who initiates the replication?
How frequent is the replication?
What is the rule used to govern when something should be replicated?
What communication mechanism does it use? RPC? Straight Sockets?
How does it know about it target replication partner?
These questions are applicable to any replication scenario; these are the rules of replication so-to- speak… So where is the new information here you might ask? We’ll this may not be new, but when it comes down to applying these concepts, people get caught up in the details and forget to understand the big picture.
Lastly, the major key attribute in EEs is their attitude. There is an inherent drive to learn, to develop continuously, and most importantly accept responsibility for resolving a customer issue.
So what do I recommend as essential reading? It would be a course on the platform, programming, and debugging. Regardless of the application, it will adhere to using the facilities provide by the operating system. Understanding how the platform works provides the essentials to be able to look at and reverse engineer any application on the fly.