here is interesting info:
My customer has DHCP server is running on a cluster node, all of the other cluster groups are monitored but not the DHCP group this result that the virtual server not included in the windows 2003 DHCP group and DHCP on it is not monitored, I found the issue: the issue that the discovery is processing the start reg value with object of 2, on the cluster the attribute is set to 3:
As I searched and most of my fellow consultants did, it looks that the DHCP MP is not cluster aware, and this will be fixed in the next version, so be careful as this is not mention anywhere in the documentation either in DHCP MP or cluster MP.
Here we go with the detailed steps of moving the MOM DB to a new SQL server, In my case I assumed that the server will be hosted on SQL active/active cluster, the steps are similar for SQL on stad alone server.
there is 2 tricks in the above setup, First Correct the SQL connection in the SQL reporting or it will not wwork, the second is to make sure that the disk that will host the MOM DB and Logs is a part of SQL server dependencies or the MOM DB will not be created.
1- Uninstall all other MOM Server components (and any MOM Agent of the same management group) that reside on the destination computer.
2- On the designated active SQL cluster Node create the MOM database using the momcreatedb.exe utility (this utlity could be found on the following path: “MOM CD”:\ SupportTools\x86).
3- Stop the MOM service on all MOM Management Servers. If MOM to MOM Product Connector (MMPC) is installed, stop the momcomm service.
4- Back up the current OnePoint database to a file.
5- On the destination computer, Restore the SQL database using the backup created in step 4.
6- Grant "db_owner" privileges to the DAS account. The DAS account was specified when you installed the original MOM database component. To grant these privileges, do the following:
a. In the SQL Server Enterprise Manager navigation pane, expand the SQL instance associated with this database.
b. Expand Security, and click Logins.
c. Right-click the DAS account displayed, and open the properties page.
d. From the Properties page, select the Database Access tab.
e. Select the OnePoint checkbox.
f. In the Database Roles for OnePoint pane, select the "db_owner" check box. Click OK.
7- On the first MOM Management Server start Regedt32.exe, and change the following registry values from the current SQL Server Instance to the new SQL Server Instance SQLservername\instanceame:
· HKEY_LOCAL_MACHINE\Software\Mission Critical Software\DASServer\DataSource Value
· HKEY_LOCAL_MACHINE\Software\Mission Critical Software\Onepoint\Configurations\\Operations\Database Value
8- Restart the MOM service.
1- On the Designated SQL active node install IIS, and enable ASP.Net
2- Install SQL Reporting.
3- Install MOM Reporting As using Normal installation steps.
4- After the installation complete open MOM reporting console.
5- Select the SCDW link
6- Edit the Connection string by Removing the . and replace it with SQLservername\instanceame.
7- Restart IIS service.
8- Edit the MOM DTS package job using the following steps:
· Click Start, then select Settings, Control Panel, Administrative Tools, Scheduled Tasks.
· Right-click the SystemCenterDTSPackage task and select Properties.
· In the "Run" text-box change the /srcserver: parameter to the destination computer as in the example below:
MOM.Datawarehousing.DTSPackageGenerator.exe /silent /srcserver: SQLservername\instanceame /srcdb:OnePoint /dwserver: SQLservername\instanceame /dwdb:SystemCenterReporting /product:"Microsoft Operations Manager"
· Click OK and reconfirm the password.
Some people reported and error in SCOM reporting:
MSI (c) (DC! E8) [13:47:30:933]: PROPERTY CHANGE: Adding FailedMsgProperty property. Its value is’ CheckHttpAddressResponse: Failed Status Code of the remote server sent an error: (503) Server not available. ".
For people who are getting this error, please remove the proxy settings from the IE and try again.
I have posted a nice amount of posts about SCCM in multiple forests, it looks like I have gave away all of the required info, not sure if I missed something but sure I recall anything I will post it.
For SCOM deployment across forests, it is very easy. More than SCCM, you have 2 options either allow the agent to talk directly to the RMS/MS servers or deploy a opsmgr gateway in the remote forest, based on studying here is the factors the controls your decisions:
- If you have a small amount of agents with acceptable bandwidth and network connectivity I would go to allow them to connect directly t the SCOM server.
- If you have a large amount of servers or WAN connectivity, I would go for deploying a GW in the other forest, check and Google about top 10 benefits of using GW servers, as data will be compressed better, less administrative overhead…etc
In both cases you will need a CA around, you cannot use self signed certificates, an enterprise or standard certificate will do the job, once certificates in place and configured communication will flow smoothly and here is 2 tips:
- You will need to import and configure a certificate on the RMS/MS server in the original forest. And import the certificate using the certificate import utility, it is not clear in the document and people didn’t pay attention to this point.
- You don’t need a trust in place between forests.
- In the other forest where the GW installed you don’t need certificates for agents as long as servers are joined to the forest, agents will communicate with the GW using mutual authentication, GW to RMS communication will be secured using certificates.
- Note the AD MP will not work across forests.
This is the major points I wanted to highlight, I will start posting about transitioning from SMS to SCCM soon, so keep reading J.
It has been released yesterday, this is a very important update to implement in your infrastructure, it has a lot of fixes and improved cluster performance monitoring.
The download is here http://www.microsoft.com/downloads/details.aspx?FamilyId=AC7F42F5-33E9-453D-A923-171C8E1E8E55&displaylang=en&displaylang=en you will have to uninstall the previous cluster MP before installing this one, check the MP guide file first.
Went yesterday through a nice SCOM installation, install SCOM then reporting then SP1 for SCOM and reporting, however I had an issue as reports were not showing, tried everything, and went to google and found that most of those cases solved using reporting reinstallation, uninstalled reporting, reset SRS, now I am trying to load the reporting to install, but it gets interrupted, checked the error log and found that reporting cannot be installed as it tries to load MP Warehouse library version that is old and the version will not load. And setup fails.
It gives the following error:
ImportMomManagementPack: Loading management pack C:\Program Files\System
Center Operations Manager
2007\Reporting\Microsoft.SystemCenter.DataWarehouse.Internal.mp. 5:26:43 AM
ImportMomManagementPack: We are using the Client API to load the MP.
ImportMomManagementPack: Error: Unable to load management pack C:\Program
Files\System Center Operations Manager
: Cannot import ManagementPack
6.0.6246.0>>. A newer version of this ManagementPack <6.0.6246.0> is already
imported in the database.
To fix this issue follow the following steps:
- Uninstall SCOM reporting
- Reset SRS if you
- Export the default MP and remove the WH library reference and overrides.
- Import it back
- Delete the WH library and ORD library MP.
- Install the reporting.
- Import the original MP
This is a complex solution, I had a reply from the product team, to run the Reporting2007.msi directly and this should solve the problem, didn’t try this one so you have the both solutions now
This fixes and changes introduced in this release were thanks in large part to the feedback that all of you have provided to us.
The OpsMgr 2007 MP for SQL 2000 and 2005 has been updated and was released to the MP Catalog on 3/31/2008 (version 6.0.6278.8). This version includes the fixes from all previous versions of the MP and is supported on both OpsMgr 2007 RTM and OpsMgr 2007 SP1. The table below is an excerpt from the MP guide detailing the changes and fixes that were made in this release. I’d like to specifically call out the final bullet in the "Changes to SQL Server 2005 Management Pack" as the behavior of the "Database Status" monitor has been updated to have three states now so it can more appropriate handle DB restore and recovery states.
The March 2008 update to the SQL Server Management Pack includes the following changes:
· The “Transaction Log Space Free (%)” monitor was made public for both SQL 2000 and SQL 2005 to allow for further customization.
· Some corrections were made and additional detail provided in the “Key Monitoring Scenarios” sections of this guide.
· Removed the hard-coded exception for jobs with a specific name from the “A SQL job failed to complete successfully” rules for both SQL 2000 and SQL 2005.
· Fixed an issue with the scripts used to calculate DB free space which was preventing some databases from having their free space correctly monitored on SQL installations that did not have DBs with contiguous IDs.
· Corrected typographical errors.
Changes to SQL Server 2000 Management Pack
· Fixed an issue where incorrect free space values were being calculated for some SQL 2000 databases.
Changes to SQL Server 2005 Management Pack
· A fix was made to address issues with collection of performance data from specific instances of Analysis Services.
· Significant changes were made to the “Database Status” monitor in the SQL 2005 MP. The monitor now has three states reflecting good, bad, and neither. The possible database states have been realigned into these categories which will reduce “false-positive” alert volumes specifically when log-shipping and database backups are occurring.
If you have noticed, some of you after applying SP1 will not be able to collect some performance data and get alerts as before, A some DB performance counters has been changed is SP1, this caused performance data not to be collected so here is what is going exactly. As far is reported the only performance counter object that was changed in SP1 was the Database object, which was renamed to the MSExchange Database object (affects mb, hub transport, edge transport roles). A list of where these counters appear is below. the alerts customers could be missing would be the ones generated by the monitors. Obviously the views and data collection rules do not work either.
In terms of workarounds for this, you could disable the 2 rules and monitors and create a separate MP where the rules collect the “right” performance counters and the monitors take configuration from the rules. You’d need to do the proper targeting, but the MP classes are declared as public, so you could refer to them from another MP.
Note that for the updated MP, we will look for the updated (SP1) counters only, i.e. the customers could expect seeing similar types of behavior from their monitored Exchange 2007 RTM servers.
Information_Store__Version_buckets_allocated___Red_2000_._5_Rule.AdvancedAlertCriteriaMonitor (takes data from the rule with the same name)
Information_Store__Version_buckets_allocated___Yellow_1800_._5_Rule.AdvancedAlertCriteriaMonitor (takes data from the rule with the same name)
I am in the airport now, I just wanted to give you a quick ip, the new Exchange management pack for SCOM is not looking for the old customurls key, it is looking for the CustomOwaUrls, so beware of that a it might trick you.
Wish me a safe trip.
I am afraid this is cannot be done, if you try to do that you will get an error state that you tried to connect to server with version not supported, so you will have to use the RTM console to manage the RTM version and the SP1 versions to manage the SP1 version