System Center Management Pack for Remote Access combines monitoring for DirectAccess and RRAS into a single management pack. This management pack retains the monitoring capabilities of RRAS 2012 management pack. This management monitors Remote Access role in Windows Server 2012 R2 only. This management pack monitors the following conditions:
• Issues with internal and external network adapter connection and settings such as forwarding
• Teredo server state and configuration
• Isatap availability and configuration such as name publishing and route publishing
• 6to4 adapter and forwarding state
• Heuristics around network security such as DOS attack, spoof attack and replay attack and state of IPSec
• State of network infrastructure like DNS servers, Management servers configured for DirectAccess
• IP-Https state and configuration
• State of various underlying services such as BFE, IPHelper etc needed for Remote Access
• Heuristics related to OTP
Most of the health monitoring scenarios that can be monitored using the native DirectAccess UI have been included in the management pack.
Existing capabilities for RRAS management pack have been included in the unified management pack as well. We’ll summarize the monitoring capabilities for RRAS included in the unified management pack:
• Remote access (VPN) connection failures due to erroneous configuration.
• Demand-dial (site-to-site) connection failures due to erroneous configuration.
• Erroneous configuration of VPN tunnels:
• Point-to-Point Tunneling Protocol (PPTP)
• Layer Two Tunneling Protocol (L2TP/IPSec)
• Secure Socket Tunneling Protocol (SSTP)
• Internet Key Exchange version 2 (IKEv2)
• Connection licenses, registry corruption, authentication, and accounting issues for remote access
• VPN network access protection (NAP) enforcement and Network Access Quarantine Control access issues
• Erroneous configuration and setup issues involved with various routing protocols that are exposed through RRAS, such as the following:
• Routing Information Protocol (RIP) v1 and v2
• DHCP Relay Agent
• Internet Group Management Protocol (IGMP)
• DHCPv6 Relay Agent
• Monitors and alarms to notify the administrator about erroneous conditions. These conditions include the following:
• Hardware device error
• Protocol initialization failure
• Remote Access Connection Manager (RASMAN) service unexpected termination
• Routing and Remote Access service unexpected termination
• Routing and Remote Access service monitor
• Authentication or accounting failures
• Configuration failures
• IPsec-related failures
• Packet filter-related failure
• IPCP negotiation failure
• Memory allocation monitor
• Memory allocation failure
• No more licenses monitor
• Port open failures
• Support for monitoring performance counters and instrumentation, including the following:
• Total number of remote access connections
• Total number of timeout and serial overrun errors for this connection
• Total number of alignment errors for this connection (alignment errors occur when a byte received is different from the byte expected)
• Total number of buffer overrun errors for this connection (buffer overrun errors occur when the software cannot handle the rate at which data is received)
• Total number of bytes received for this connection
• Number of bytes received per second
• Total number of bytes transmitted for this connection
• Number of bytes transmitted per second
• Total number of cyclic redundancy check (CRC) errors for this connection (CRC errors occur when the frame received contains erroneous data)
• Total number of data frames received for this connection
• Number of frames received per second.
For instructions about importing a management pack, see How to Import a Management Pack in Operations Manager 2012 R2
Tuning Monitoring by Using Targeting and Overrides
When you import a management pack, System Center 2012 – Operations Manager discovers the objects defined by the management pack and begins applying the management pack’s rules and monitors to the discovered objects. You should always import a new management pack in a pre-production environment first so that you can evaluate the management pack and adjust or tune the management pack as necessary to meet your business needs.
To tune a management pack effectively, you should involve the service owner or subject matter experts, the operations team members who monitor the alerts and events and take action when something requires attention, and the engineering team responsible for the Operations Manager infrastructure. Depending on the service that is monitored by the management pack, you might also include the networking or security teams. Those responsible for the Operations Manager infrastructure might not have the knowledge and experience with the service to effectively tune the management pack without expert input.
For servers or applications, tune from the highest severity alerts and dependencies to the lowest. Look at alerts first, then open the Health Explorer to gather more detailed information for the problem. Validate results of the alerts generated, verify scope of monitoring against intended targets (servers or services), and ensure the health model is accurate.
Each rule should be evaluated according to the following criteria:
- Actionability: An alert is actionable if it tells you what went wrong and how to fix it. When alerts are generated that do not require any action, consider disabling alerting for the rule.
- Validity: An alert is valid if the issue that generated the alert can be confirmed and the issue actually occurred at the moment the alert was generated.
- Suppression: There should be only one alert stating the issue occurred.
What to Tune
- Discovery frequency
- Monitor thresholds
- Import a single management pack at a time.
- Review any new alerts reported for servers monitored with the new management pack. You can use the Alerts and Most Common Alerts reports to help you discover your most common alerts. When you first install a management pack, it tends to discover a multitude of previously unknown issues. Monitor the alerts to determine potential areas of concern
- Override the monitor or rule as applicable for a particular object type, a group, or a specific object.
- Disable the monitor or rule if the issue is not severe enough to warrant an alert and you do not need to be made aware of the specific situation being monitored.
- Change the threshold of the monitor that is generating the alert if you want the underlying condition to be monitored, but the alert is being generated before the condition is actually a problem for your particular environment.
- When you set overrides for a management pack, save them to a management pack that is named ManagementPack_Override, where ManagementPack is the name of the sealed management pack to which the overrides apply. For example, overrides to the management pack Microsoft.InformationWorker.Office.XP.mp would be saved to Microsoft.InformationWorker.Office.XP_Overrides.xml.
Tuning Monitoring by Using Targeting and Overrides topics
• Using Classes and Groups for Overrides in Operations Manager
• How to Override a Rule or Monitor
• How to Enable or Disable a Rule or Monitor
• Using the Enforced Attribute in Overrides
• How to Enable Recovery and Diagnostic Tasks
Other resources for this component
You can find also awesome information about Microsoft System Center 2012 R2 Operations Manager on Technet wiki here :