My good friend and MVP Kevin Greene put out a blog post here with details on how you can win a copy of Mastering System Center 2012 Operations Manager by downloading and evaluating System Center. Look here for his blog post.
In the case you have done a clean install of SCOM 2012 SP1 you might want to take a look at the file names of the OperationsManagerDW database and log files. They might look like this:
So empty names for the files and ending up with ".mdf" and ".ldf" for the file names.
However, my good friend Marnix Wolf also found that when using custom database and log file paths, the file names can take on the name of the directory they are in!
In the Release Notes of SCOM 2012 SP1 this known issue is mentioned (well, at least the part where the file names can be empty):
There are multiple ways to overcome the issue, and it would be best to solve this right after installation of the first management server before you install the other management servers.
One of the ways to fix this is to "Detach - Rename - Attach" the database. I will describe this process below with screenshots and all for those who like the step by step guides.
First of all some work before we get started:
- BACKUP your database before you play around with it!!
- Stop the System Center * services on the management servers before you do the next steps
- Perhaps you want to make sure where your database files live, because you want to be able to find these files. Open SQL management studio. Right-click on the database OperationsManagerDW and select Properties. On the left click the "Files" tab and find the Path and File Name of the database. Remember these.
This procedure uses the Detach - Rename - Attach method.
- Open SQL Management studio and connect to the database instance where the SCOM databases live.
Find the OperationsManagerDW database and right-click it. Go to Tasks - Detach...
- If there are still any connections just use the "Drop Connections" option
- After a succesful detach the database will be gone from the SQL management studio.
- Next go to the Windows Explorer and on your file system find the database files and rename them to what you want them to be called. In general the default would be OperationsManagerDW.mdf and OperationsManagerDW.ldf .
- In SQL management studio, right-click on Databases and select Attach...
- Click the Add button to select the database file.
- Select the mdf file belonging to the OperationsManagerDW database in the file path where it lives
- The resulting screen shows some information on how it wants to attach the database and information about the files. There are a few problems in this screen (red circles). The first is the Owner might not be the one you want and the second is that it can not find the two files it expects.
- To change the owner just click on that field and a dropdown list will appear where you can select from known logins and take the one you want.
- Next we have to go to the Not Found files. This is because the database file knows which files it relies on (at least one database file and one log file) and it only knows about the old file names in the old file paths. So we need to change both and point them to the correct files. The first one points to the database file (mdf), so click the small button next to it.
- Go to the correct path where the database file is located and select the database file OperationsManagerDW.mdf in my case.
- Next do the same with the second file and point it to OperationsManagerDW.ldf for the log file.
- Now attach the database
- when opening the properties of the OperationsManagerDW database and going to the Files tab you will now see the correct paths and file names for both files belonging to this database.
- Do not forget to start the System Center * services again on the management servers!
The management servers and databases should be fine now.
Like I mentioned before my friend Marnix Wolf used another method and that is the backup - Restore method, whereby you can define the path location and file names of the files. You can find that post here: http://thoughtsonopsmgr.blogspot.nl/2013/01/om12-sp1-known-issue-data-warehouse.html.
Thanks to our SQL DBA David Scheltens for the procedure!
Well, I hope this helps and enjoy your monitoring!
Because Microsoft released CU7 for SCOM 2007 R2 in January 2013 as explained in a previous post about this subject, it was time to also update the checking scripts I had made before for CU5 and CU6 and make them work for CU7.
As I explained in the previous post on how to check for CU5 installation on SCOM 2007 R2, the way to check for successfull implementation of Cumulative updates has come up as questions in the community a number of times and I found a need as well to have this scripted. So I created a number of scripts for SCOM 2007 R2 CU5 which I discuss in the other blog post here. The method for CU7 is exactly the same as mentioned in that article with two differences.
- The names of the scripts are with a 7 in it
- scripts are located on another TechNet Gallery page (see below for the link)
Refer to the post on CU5 check scripts for SCOM 2007 R2 on the procedure and screenshot.
This is the link to the TechNet Gallery page where the CU7 check for SCOM 2007 R2 is located.
Good luck and enjoy!
Microsoft released SCOM 2007 R2 CU7 last night.
The relating KB article can be found here: Cumulative Update 7 for System Center Operations Manager 2007 R2 http://support.microsoft.com/kb/2783850/en-us
The update contains the following fixes (and this is a screenshot from that KB article):
Also interesting to note is that there are a few security vulnerabilities for SCOM 2007 R2 fixed within this CU7 as you can find explained over here: http://technet.microsoft.com/en-us/security/bulletin/ms13-003
Please pay close attention to the installation order and steps as described in the KB article. It is basically the same story as CU4+5+6 for the ones informed on the process of those.
Funny things this System Center 2012. As you probably know by now Service Pack 1 for System Center 2012 is available for some, but not yet in GA (General availability) status. Expecting that to be soon, and please watch for announcements on the System Center blogs... I really will not tell you anything more than this.
However last night some people found with the WSUS/SCCM updates of this months patch-Tuesday a number of additional updates called something like Update Rollup 1 for Microsoft System Center 2012 SP1 - [product] (KB1111111).
Say what? UR1 for SP1 already?
Yes, it has to do with the quarterly cadence of updates coming from the System Center team. Even though the SP1 is not yet available to everybody, of course the product team is moving forward.
If you do not see all these updates yet in WSUS and are applicable to you check in your WSUS server settings.
In WSUS go to Options -> Products and Classifications. In the popup scroll down to the System Center products. Here you will see both the System Center 2012 and System Center 2012 SP1 type of product categories.
As you see in my case I still needed to select them and synchronize again to get to see all the updates related to SP1 as well.
And now we see a list of updates released 8 January 2013 relating to System Center 2012 and up.
The following KB article contains the Description of Update Rollup 1 for System Center 2012 Service Pack 1.
In the Article there are fixes describer for App Controller + DPM + SCOM + SPF + VMM.
Interesting is that it talks about UR1 for VMM 2012 SP1 and in WSUS it shows both that one and UR4 for VMM 2012. Not all links to all the KB articles seem to be active or available yet. Well perhaps its just waiting for a few hours/days more until all the info is up on TechNet.
The article also contains important information on how to install the updates and where to find stuff. Do not think that for all products you simply need to approve stuff in WSUS and be ready with it! As SCOM is still my main thing I will post a note below for SCOM admins. Check in the article for extended notes for SCOM and other products!!!
Note for SCOM admins: After installing the update on management servers, gateways, web console and agents and so on, you need to import the new management packs! These are according to the KB article the following: (By the way, please read further below first before you start clicking on things)...
You can find them in the following location:
%SystemDrive%\Program Files\System Center 2012 SP1\Operations Manager\Server\Management Packs for Update Rollups
However, I found the following two mpb management packs to be present in the mentioned folder (and in my case the folder name did not have SP1 in the path name):
And these also sound more like the mentioned issues actually.
Update 23 January 2013: The KB article seems to have been adjusted. It now mentions to only install the Microsoft.SystemCenter.AlertAttachment.mpb management pack! The IntelliTrace management pack contains a number of dependencies that seem to be as yet impossible to resolve and I read somewhere that it would actually contain nothing new over the version included in the SP1 bits. So only import the one mpb file!
For UNIX/Linux monitoring there are also updates. You can find them by going to this location: http://www.microsoft.com/en-us/download/details.aspx?id=29696 and download the MSI and guides.
Install the MSI to extract the contents. You will find updated Microsoft.Unix.Library management pack in the Microsoft.Unix.Library\2012 SP1 folder and the Microsoft.Process.Library management pack bundle and platform library management packs that are relevant to the Linux or UNIX platforms you are monitoring which you can import.
Good luck updating your System Centers!
Was surprised this morning with an email stating I had earned a certification for the System Center 2012 suite. Well, I did the exams in April 2012, so I went and had a look what happened in my transcript. And at first I did not see it, but with a little scrolling I found these:
MCTS System Center 2012, Monitor and Operate
MCTS System Center 2012, Deployment and Configuration
With an achievement date of the first of January 2013.
Until now there were no separate MCTS certifications for these exams, but they were of course taken together as two exams together with an MCSA 2008 or MCSA 2012 to attain MCSE Private Cloud. Seems they changed their minds and created the MCTS anyway now for the two existing exams 70-246 and 70-247.
Well, I guess thanks Microsoft for these two certs as a 2013 new year present
I just got the confirmation that I got renewed as MVP for SCCDM (System Center Cloud and Datacenter Management) for my second year!
I want to thank the whole System Center community for making this possible!
Lets have much more fun in 2013! There will be lots to do around System Center in this year as well.
In my lab I was looking at upgrading three SCOM 2012 instances to the SP1 RTM version. Upgrading the ones which already had a pre-release version of the RTM of SP1 turned out to be no work at all, so I was left with the one which was SCOM 2012 UR3 and upgrading that one. Lets see what happened.
First of all the System Requirements from the Supported Configurations page on Technet here http://technet.microsoft.com/en-us/library/jj656654.aspx
Lets see, this computer is running Windows 2008 R2 SP1 and SQL 2008 R2 SP1 and of course has SCOM 2012 with UR3 installed. We should be fine.
I did give the machine a reboot and checked everything came back up again before I went ahead with the installation. Downloaded the SCOM 2012 SP1 ISO file and attached it to the machine.
There it is. It says Service Pack 1, so on to the Install link!
One thing I forgot to say is that this is an all-in-1 installation. So all roles are combined on one machine. It doesn't have that many agents connected to it, so thats fine. As we can see it found the installed components and it wants to upgrade them all. Of course the added tip of first creating a backup of your databases! The next screen asks you to agree to the license terms.
Select installation location. In my case the default installation location is fine, so moving on!
A prerequisite checker starts running which verifies the hardware and software configuration.
The System Center Configuration service and System Center Data Access service account. You have a choice for Local System or a domain account. If the database is running locally as is the case on my machine you can leave it at Local System. If the databases are remote it required to use a domain account. Because I might move some components out from this machine I will use a domain account anyway and proceed.
The next screen tells me it is ready to upgrade and it shows me again the installation location and config/das account setting I selected.
There it is, the upgrade button. Click!
In my case it took a while for it to upgrade all the bits and pieces and there is a progress indication for each. During the Operational Database Configuration phase it also imports a whole lot of management packs, so that takes some time. After upgrade finishes, just close the setup screen.
Start the SCOM console and go to Help -> About.
Looking good! Service Pack 1 and of course still activated.
Next up are our good friends the SCOM agents.
Go to the Administration Pane of the SCOM console and open the Pending Management node.
All the agents which were installed through the SCOM console which are manageable by the console are set to Pending Management with the note Agent Requires Update. Right-click them and select Approve. In bigger installations I would it about 30 to 40 at a time. Use the default action account or one you provide yourself and select Upgrade.
In my case all success and one fail. That was a machine which was turned off actually.
Next jump over to the Monitoring Pane, and on the left hand side go to Operations Manager -> Agent Details -> Agents by Version.
As you can see in this picture the process has started already. The first two have been upgraded and have reported back their new version already. The path list is empty again for the updated agents, because they dont have a patch installed now. Its a full SP1.
Next phase would be looking at management packs. On the installation ISO there is a Management Packs directory where you can select the ones you want/need. The upgrade should have upgraded the management pack you had installed already and for which it had an updated version. It could be that you want more things, like APM, and cross plat monitoring management packs for instance.
Well, all looks nice and well now.
This upgrade was relatively easy to do because the OS and prerequisites were in place already and it was just one upgrade step for the Service Pack. Also an all-in-1 machine is easier to upgrade of course, but generally its all the same story. Upgrade all the components following the same procedures as any SCOM update for SCOM 2012.
Update: One important thing to note is that you have to update the management servers one by one. SO do not even start the wizard on the second management server if your first has not completely finished updating to SP1! See http://blogs.technet.com/b/momteam/archive/2013/01/16/patience-is-a-virtue-with-the-system-center-2012-operations-manager-sp1-installation.aspx in case you were not patient and ran into error messages when opening alerts and such.
I'm done for today. Tomorrow is another day to play with System Center!
This weekend was a good time to upgrade my DPM server from DPM 2012 with UR3 to DPM 2012 Service Pack 1. I tried to capture the whole process in words and pictures; for anybody who is interested and as a reference when looking back later.
First of all check if the server was running alright. All protection groups in a green status. Nice one!
Next I checked the agents in the Management pane and found that two of them had an update waiting, so I approved the agent update and waited for it to finish. After this step the server and agents were running 4.0.1920.0 of DPM. This is the DPM 2012 UR3 version.
Meanwhile downloaded the SP1 version and because it was an ISO file and a physical server I just extracted the files to local disk before running the upgrade.
So lets see if the software configuration supports the upgrade.
The software requirements are listed here: http://technet.microsoft.com/en-us/library/jj651645.aspx
- Windows 2008 R2 SP1 is running here. Good enough. Check.
- SQL 2008 R2 SP1 is running on this machine. Good enough. Check.
- MS .Net Framework 3.5 SP1. Check.
- MS Visual C++ 2008 reditributable. Check.
- Powershell 2.0. Check.
- Windows Installer 4.5 or up. Having V5 here, check.
- Windows Single Instance Store (SIS). Check.
- Microsoft Application Error Reporting. Check.
Don't forget that the DPM installer will be able to install or update a few of the prerequisites as well if they are missing or not at the right level. The installation/upgrade process will let you know if it encounters any blocking issues you need to install first. Seems good to go people. Lets rock.
And to be sure this is SP1 we are installing it says so at the bottom of the screen. Just for fun, I first run the prerequisite checker. This takes me to the website with the prerequisites. Well, I was there just before, so lets move on!
Select the Install Data Protection Manager option. Accept the license terms. And wait for the program to unpack itself.
Alright, so now we can see what steps the program will go through. Moving on.
As there already is a SQL instance on the machine I keep the default and click the CHeck and Install button.
Looking good so far. Of course it gives the good advice to backup the database before upgrading. Clicking the Next button.
Enter your product key for your DPM (System Center). In my case the Copy/Paste action of the complete key in one time worked in this field. Saves me typing.
It gives us a chance to change the folders where DPM is installed. Space requirements are all good it seems.
DPM creates a few local user accounts and requests us to provide a strong password for these accounts. So we enter something which it translates to dotdotdotdot again.
In my case it is nice to use Microsoft Update, so I select that one and move on.
Customer Experience Improvement Program (CEIP). Just select Yes and move forward. This option makes it possible for Microsoft to anonymously receive some base data on the use of DPM, in order to use this in improving the program for future minor and major versions.
There it is, the magic Upgrade button. Lets click it!
Aha, it installs SQL 2008 R2 Service Pack 2 (remember I had SP1 installed?). And after that it will move on to the DPM upgrade. It is time to go to the kitchen and get something to drink as this will take a while. It is not the fastest hardware and things like service packs tend to take a while.
Alright! The server components have been upgraded.
On to the next step, the agents. The warning tab in the screen above states the following:
To prevent protection jobs from failing, you must now update all previously installed DPM Replication Agents. To update Replication Agents, go to the Management task area in DPM Administrator Console.
Closing the screen first popped up the Windows Update screen. After that one was finished its on to the DPM 2012 SP1 icon and open the DPM console.
In the DPM console on the left-hand side go to the Management pane. This will show your agents. In my case it looks like this:
As expected it says there is an agent update available. Until you update these agents there will be errors protecting them as well.
Clicking the Update Available link will give a popup:
So first click Yes to upgrade and we will check the protection state later.
After a while most agents have the 4.1.3313.0 version (= 2012 SP1). There is only one who would like a reboot. Will do that later.
Next I move back to the Protection Pane and find all protection groups have a critical red state. The protection status says: Replica is inconsistent. This was expected, so lets resolve that.
Right click a protection group and select Perform Consistency Check.
All this takes a while. I just select multiple and perform this consistency check and wait for all of them to finish. Plus during the consistency check they al go from red to yellow state, which looks much less dangerous.
In any case, yet another point to eat and drink something, as this takes a while. Slowly there are more and more green Data Source Health states.
I know there are a few slow data sources in here, so seeing this I know things will turn out alright in about an hour. Time to wrap up this blog post.
Update from the next morning: Everything green!
The process of upgrading DPM 2012 UR3 to DPM 2012 SP1 was an easy one as expected, mostly because the hardware and software specs were already sufficient and of course its the smallest version difference for the upgrade (outside of beta versions of course). Good one!
Update March 2013: Around every quarter Microsoft brings an update rollup (UR) for System Center products. In January they released UR1 for SP1, also for DPM. It is recommended that after the update to SP1 you have a look at what Update Rollup is the latest and install it as well.
It was about 10 months ago since I published a simple script for SCOM 2007 R2 to close old alerts coming from rules. The reasoning is that: 1) alerts from rules do not close themselves, 2) they do have a last modified date of x days ago, so might not be current anymore. In some cases we just encounter environments where a lot of alerts have been created for whatever reason and/or have not been cleaned for some time. A script can make your life easier to quickly filter these out and close them before turning your attention to the more current alerts.
Of course we want to be able to do the same for SCOM 2012. Some months ago I looked into it for half an hour and could not understand why I could not simply adjust the command to the 2012 version of the cmdlets and have it working.
Today I looked into it again for some reason and found the problem was in the Resolve-SCOMAlert command.
When looking at the functioning of the command over here http://technet.microsoft.com/en-us/library/hh920262.aspx we see the following quite clear statement:
Resolves an alert. This does the same action as Set-SCOMAlert -ResolutionState 255.
And of course the good thing about the Resolve-SCOMAlert command is that we can enter a comment in the alert history saying we closed it automatically because it was too old.
However I found again that this command does not close the alert. It simply does not change the resolution state to 255 (which is "Closed").
So I have worked around it by first having this command insert the comment and next feeding the alert back into the Set-SCOMAlert command in order to close it.
On the TechNet Gallery you can now find a script to close old alerts from rules in SCOM 2012.
In the script you will find a variable with the amount of hours we define as old (Alert Last Modified), which you can change from the default 96 hours to whatever your environment desires.
Also the script assumes you run it on a management server, so it connects to localhost by default. However there are commented lines defined already where you can enter the name of a management server and connect to it remotely from something other than a SCOM management server.
The script can be downloaded from here:
SCOM 2012 script to close old alerts coming from Rules
Enjoy your cleaning up!