2010/11/18, 17:56
I am right now deploying a lot of Gateway servers so to make the Gateway approval a little easier I wrote a little script.
There is probably some way of doing this even better, but here goes:
$MS = Read-Host “FQDN of the Management Server”
$GW = Read-Host “FQDN of the Gateway”
$Site = Read-Host “Name of the site”
& “Microsoft.EnterpriseManagement.GatewayApprovalTool.exe” /ManagementServerName=$MS /GateWayName=$GW /Site=$Site /Action=Create”
Note:
When using the GateWayApprovalTool you need to have Write Permissions on the SQL Instance that holds the OpsMgr database.
2010/11/09, 16:35
Word is that we will se Opalis 6.3 on 25th of November. Support for installing on Windows server 2008 and integration packs for more System Center products is the news there.
When it comes to the vNext versions of both Opalis and OpsMgr they will probably be releases under the names System Center Opalis 2012 and System Center Operations Manager 2012.
A little more here: http://ianblythmanagement.wordpress.com/2010/11/08/v-next-2012/
2010/10/05, 16:56
I see this question a lot in the technet forums:
“I don’t want to monitor the IIS on this server and have disabled the discovery, but the server wont disappear. How do I get rid of it?”
To resolve this you just need to open a Operations Manager Shell and enter: Remove-DisabledMonitoringObject
Description of cmdlet:
Removes all monitoring objects for which discovery is disabled. For example, if you created an override to disable discovery for a particular database on a database server, calling this cmdlet would cause the removal of this database from Operations Manager.
2010/09/28, 22:20
It is now official, OpsMgr now supports SQL Server 2008 R2 read more here: http://support.microsoft.com/kb/2425714
But remember where you read it first. ;) http://www.opsmode.com/2010/05/install-opsmgr-on-sql-2008-r2/
2010/09/14, 12:26
I have a customer with a lot of SQL Agent Jobs that are being monitored on Job duration and after upgrading the SQL MP to 6.1.314.36 they didn’t get alerted when the SQL Agent Jobs was running for to long.
It turned out that the threshold format has been changed, in previous versions it was HHMMSS (H=hours, M=minutes, S=Seconds). And still is for the SQL 2000 MP!
So if you would set 2 hours you would write 020000.
In the new version of the MP the threshold format has been changed to minutes instead.
That makes you write 120 instead.
I haven’t found anything about this in the MP Guide, but if you do please let me know.
2010/06/30, 11:01
A new version of the Operations Manager Management Pack was released yesterday.
Download: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=61365290-3c38-4004-b717-e90bb0f6c148
And a nice change is that they have made the rules that monitor failure of scripts, commands and WMI queries less noisy and easier to understand. The rules has also been renamed, new names is listed in the following table:
| Old name |
New name |
| Alert on Failure to Create Process for Batch Response |
Workflow Initialization: Failed to start a process or script |
| Alert on Failed Batch Responses |
Workflow Runtime: Failed to run a process or script |
| WMI Probe Module Runtime Failure |
Workflow Runtime: Failed to run a WMI query |
| WMI Probe Module Initialization Failure |
Workflow Initialization: Failed to start a workflow that queries WMI |
| WMI Event Module Runtime Failure |
Workflow Runtime: Failed to run a WMI query for WMI events |
| WMI Event Module Initialization Failure |
Workflow Initialization: Failed to start a workflow that queries WMI for WMI events |
| WMI Raw Performance Counter Module Runtime Failure |
Workflow Runtime: Failed to run a WMI query for performance data |
| WMI Raw Performance Counter Module Initialization Failure |
Workflow Initialization: Failed to start a workflow that queries WMI for performance data |
| (new rule) |
Workflow Initialization: Failed to start a workflow that runs a process or script |
So if you have alot of script failuers and WMI errors import this MP!
The catalog accessible from the console has not been updated with the new version when this is published.
2010/05/28, 23:07
I couple of weeks ago I had the pleasure to beta test Dan Kregors tool OMWatcher. And I must say, this is a great tool that I will use at many customer sites…
This is the answer when some one is asking: “But who is watching the watcher?” Meaning, who is monitoring OpsMgr. Well the answer i OMWatcher!
Overview
The 1E OMWatcher tool for System Center Operations Manager 2007 fills an important, and often overlooked gap in every OpsMgr environment.
Arising from the question…
“Who’s watching the watcher?”
… 1E OMWatcher is designed to monitor the 3 critical service on the Root Management Server (SDK, Config and HealthService). 1E OMWatcher will proactively mitigate unnecessary and potentially expensive downtime by ensuring the RMS is active (via a ping), and taking remedial action should one of the core RMS services stop. In addition, 1E OMWatcher will notify administrators (via email) were an issue arises.
1E OMWatcher should be installed on a server other than the RMS (preferably on a secondary Management Server), and configured to run under an account that has local administrative rights on the RMS.
Key Features
- Actively pings the RMS at regular polling intervals, alerting (via email) should the RMS not respond (indicating the potential for the server to be offline).
- Checking the status for the 3 OpsMgr services, ensuring they are running. In the event that a service is stopped, OMWatcher will attempt to restart the service, and will alert (via email) that the service had stopped.
- Checking the startmode for the OpsMgr service, they are not set to disabled. In the event that a service is set to disabled, OMWatcher will set the service to Automatic, restart the service, and will alert (via email) that the service was set to Disabled and stopped.
More here: http://opsm.gr/2010/05/28/1e-system-center-watcher-tool-v1-now-available/
Download here (registration required): http://www.1e.com/Downloads/FreeTools/Index.aspx
2010/05/25, 13:51
When using a management pack designed to discover a 32bit application and that application is installed on a 64bit server OS the application will probably not get discovered.
This is because the 32bits app will write its registry keys in the HKLM\SOFTWARE\Wow6432Node\ (because its a 32bit app on a 64bit system) and the discovery will look for keys and values in HKLM\SOFTWARE\
To resolve this you can either create the registry keys under HKLM\SOFTWARE or install a 32bit agent on the system.
If you install the 32bit agent it will bee replaced every time you do a upgrade from the console, and worse you wont bee able to monitor your 64bit system properly.
When author MP’s for OpsMgr 2007 R2 there is a new feature that can be used in the discovery.
<RegistryView>32bit</RegistryView>
Should go somthing like this:
<RegistryAttributeDefinition>
<AttributeName>TheApplication</AttributeName>
<Path>SOFTWARE\TheApplication</Path>
<PathType>0</PathType>
<AttributeType>0</AttributeType>
<RegistryView>32bit</RegistryView>
</RegistryAttributeDefinition>
And this will make it look in the Wow6432Node
