Share via

Learning Essentails in Exchange PSS

  • Article

Learning Essentials

 

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.

 

  • Inside Windows 2000, Third Ed. (ISBN 0735610215)
  • Programming Server-Side Applications for Microsoft Windows 2000 (ISBN 0735607532)
  • Programming Windows, Fifth Edition (ISBN 157231995X)
  • Windows NT Device Driver Development (ISBN 1578700582)
  • The C++ Programming Language (Special 3rd Edition) (ISBN 0201700735)
  • Algorithms in C++ (ISBN 0201510596)
  • Debugging Applications (ISBN 0735608865)
  • The help file with Windows Debuggers download (https://www.microsoft.com/whdc/devtools/debugging/default.mspx)
  • Transaction Processing : Concepts and Techniques (Morgan Kaufmann Series in Data Management Systems) (ISBN 1558601902)

Comments

  • Anonymous
    November 13, 2004
    WOW!

    I don't think I've ever read the way I feel about certifications put into words quite so well. In fact, on some points, I was not even sure about the way I felt, yet you have clarified things for me.

    I work in IT as a systems administrator, but I have a deep understanding of Operating Systems and Networks. I've never had a certification, and as someone who generally seems to know a bit more than those who get jobs based on their certifications, I've never held much regard for those certifications. Thanks for the post and for clarifying things.

  • Anonymous
    November 14, 2004
    Thanks Jay...
    I did forget to mention something, EEs do have to maintain certifications. That is an essential requirement of our role, but the knowledge that we rely upon is the fundamentals I spoke about.

  • Anonymous
    June 09, 2009
    PingBack from http://quickdietsite.info/story.php?id=10434

  • Anonymous
    June 13, 2009
    PingBack from http://thestoragebench.info/story.php?id=9369