Archive

Archive for February, 2013

Demo OpsMgr 2012 network monitoring with Network device simulator

February 25, 2013 Leave a comment

There has been discussion lately around running SCOM 2012 and other SC products in the cloud for DEMO and POC purposes. One problem with running SCOM in a cloud solution is not having access to network device/s. There is a solution to this. You can run a network device emulator. This is available as software and will simulate a full network device that SCOM can then discover and monitor. You will find several network device emulation software packages out there with from a quick internet search. Here is a good tool that is free. It is called Xian SNMP Device Simulator and can be downloaded here:

http://www.jalasoft.com/xian/snmpsimulator

SNMP Simulator Screenshot

The devices it can simulate are:

  • Cisco Switches
  • Cisco Router
  • Cisco Firewalls
  • Cisco VPN Concentrators
  • Cisco Wireless devices
  • 3Com Switches
  • HP Pro curve Switches
  • F5 Big Ip Nortel
  • APC UPS

You can simulate up to 15 devices with Xian SNMP Device Simulator . This same company has another tool that can be used as well that actually simulates network devices and traffic. This tool is called Xian NetFlow Simulator  and can be downloaded here:

http://www.jalasoft.com/xian/xiannetflowsimulator

The Xian NetFlow Simulator is not free but you can obtain a trial. The Xian NetFlow Simulator sends packets between a given source and a destination. You could use SCOM to monitor actual network traffic using this second tool.

The first tool has been around for some time but I thought I would post about it again with talk of running SCOM in the cloud for demos. Here is a reference to an old blog post on setting up Xian SNMP Device Simulator and monitoring it with SCOM.

Test/Demo OpsMgr 2012 network monitoring with Jalasoft’s network device simulator

Advertisements

Monitoring the Hybrid Microsoft Cloud

February 25, 2013 2 comments

he Microsoft Hybrid cloud, as it stands currently, is a mixture of a Hyper-V private cloud with an Azure public cloud, managed by System Center App Controller (formerly Concero).  One of the key pieces of the Microsoft solution is monitoring the health of the application (that the business really cares about) using System Center Operations Manager (OpsMgr).

Management packs make monitoring of Hyper-V, Windows, SQL, Exchange, CRM, hardware, storage, etc, easy.  You can put together end user perspective monitoring from the basic ping test to the advanced synthetic transaction, build service-centric distributed application models, and provide SLA monitoring of the LOB applications.  That’s got the private cloud covered.

There is also a management pack for Azure.  This allows you to monitor the availability, health, and performance of your public cloud services.  Let’s face it – even if Microsoft does/did provide a monitoring solution within Azure – can you really use a monitoring solution that is a part of the thing you are monitoring, i.e. the Microsoft public cloud?  I say no – and that’s the first reason why you should use OpsMgr and this management pack.  The second reason is that it allows you to integrate your monitoring of public and private clouds, giving you that mythical single pane of glass for monitoring.

  • The features of this management pack are:
  • Discovers Windows Azure applications.
  • Provides status of each role instance.
  • Collects and monitors performance information.
  • Collects and monitors Windows events.
  • Collects and monitors the .NET Framework trace messages from each role instance.
  • Grooms performance, event, and the .NET Framework trace data from Windows Azure storage account.
  • Changes the number of role instances via a task.

The prerequisites of it are:

  • The management group must be running Operations Manager 2007 R2 Cumulative Update 3.
  • The Windows Azure role must be published with full trust level. For more information about Windows Azure trust levels, see Windows Azure Partial Trust Policy Reference.
  • Windows Azure Diagnostics must be enabled. For more information about Windows Azure Diagnostics, see Implementing Windows Azure Diagnostics.
  • Windows Azure Diagnostics must be configured to forward diagnostic data to a Windows Azure storage account. For more information about configuring Windows Azure Diagnostics, see Transferring Diagnostic Data to Windows Azure Storage.
  • Microsoft .NET Framework version 2.0 or newer must be installed on the computer that you designate as the proxy agent when you configure the Monitoring Pack for Windows Azure Applications.

SCOM – Enable Agent Proxy Setting for all Installed Agents

February 16, 2013 1 comment

This is a quick post and mostly for my own reference but some people may find it interesting or useful.

When deploying SCOM agents in an environment, there is an ‘Agent Proxy’ setting that is disabled by default on all newly installed agents titled:

Allow this agent to act as a proxy and discover managed objects on other computers

If you install an agent onto for example, an Active Directory, SQL or Exchange server and leave this setting disabled, then SCOM will detect the agent as only being of the ‘Windows Server’ class and will not allow discovery of Active Directory, Exchange or SQL roles and attributes.

This setting is disabled by default as there is a potential risk associated by allowing an agent to discover external managed objects.

When installing a new SCOM solution, I tend to deploy agents to all of the servers that I know will need this setting switched on first (Exchange, AD, SQL, Hyper-V etc.). I then run a powershell command that turns this setting on for all of these agents in one quick swoop!!

Once all of the agents that I want to have this enabled on have it enabled, then I install the remaining Windows agents and leave the setting as its default of ‘disabled’.

Here’s how to do it:

Go to the ‘Security’ tab within the newly installed agent from the SCOM Administration console tab and check to see if the settings is disabled as below

setagentproxy0

Open up the ‘Operations Manager’ shell from a SCOM Management Server with administrative permissions as below:

setagentproxy1

setagentproxy2

When you have the Operations Manager Shell window opened as above, copy the script below into it and hit ‘Enter’

## Enable Agent Proxy for all agents where it is disabled
$NoProxy = get-agent | where {$_.ProxyingEnabled -match “false”}
$NoProxy|foreach {$_.ProxyingEnabled = $true}
$NoProxy|foreach {$_.ApplyChanges()}

Updated 5th May 2012: The script above will only work on SCOM 2007 R1/R2 and not SCOM 2012. See below for the SCOM 2012 equivalent:

## Enable Agent Proxy for all agents where it is disabled
$NoProxy = get-scomagent | where {$_.ProxyingEnabled -match “false”}
$NoProxy|foreach {$_.ProxyingEnabled = $true}
$NoProxy|foreach {$_.ApplyChanges()}

Updated (again!) 24th August 2012 – My good buddy Bob Cornelissen (fellow co-author of Mastering System Center 2012 Operations Manager and SCOM/OpsMgr ninja warrior) has just posted an even easier one-liner PowerShell command to enable agent proxy for all of your machines. Check out his post here and see his script below:

Get-SCOMAgent | where {$_.ProxyingEnabled.Value -eq $False} | Enable-SCOMAgentProxy

Once you have run the script above in the Operations Manager Shell window, go back to the ‘Agents’ window and open up your agents ‘Security’ tab again. You should now see that all agents present when you ran the powershell command have changed their ‘Agent Proxy’ setting to enabled!!

setagentproxy3

Easy!!

Keep in mind that this is just a simple powershell script that will enable the setting for all agents so if you want to specifically enable just a small amount and not the whole lot of them, then this isn’t the script for you!!