In the afternoon I attended the Manageability and Monitoring talk by Charlie Chung and Greg Thiel and took some rough notes.

• EX2013 – Protocols are always served from the protocol instance that is local to the active database copy
• Best way to monitor is at the user level
  • Availability – can I access the service?
  • Latency – how is my experience?
  • Errors – am I able to accomplish what I want?
• Scaling applications magnifies errors
• Main goal is to reduce the alerts
• ‘Stuff breaks and the experience does not’
• Managed Availability Overview
  • Probes will determine if something is broke
  • Check will validate thresholds and make certain they’re within certain parameters
  • Notify will take bugs and other odd failures
  • Monitor will take data from probes/checks/notifies and apply business logic to either recover if it’s possible (i.e. restart services, etc.) or escalate to a human
• This runs on every single box and then reports up to SCOM (if you are so inclined to utilize SCOM)

Basically, the built in manageability tools that are automated are similar to SCOM – same building blocks and concepts apply, so if you’ve utilized SCOM, then you’re going to be used to how these tools operate.

And like the SCOM tools, you can also modify the defaults if needed.  However, this should rarely be needed in your production environment.  In a TEST environment, however, you really need to change the defaults, or you’ll start getting some odd issues creep up (since test labs are generally thin on resource availability).