This post is part of a series What’s new: Check here for the other parts.
In SCOM2007R2 you could multihome an agent to different management groups but it was quite the hassle as there was no option in the management console to control this feature. In SCOM 2012 this has changed by including the Operations Manager Agent Application to the control panel when the agent has been installed. Pretty cool feature if you ask my because now you have full control over the homing or multihoming of the agents.
Although this feature is not that high on a lot of peoples list of great new features this really facilitates the work of those who are working with a complex environment with connected management groups.
So where is this feature actually.
You can do this semi automatic by pushing the agent from all the different management groups (the maximum is 4). This is in fact a recommende maximum and not hardcoded. So in theory it is possible to multihome an agent to more than 4 management groups but it’s not supported as Alexis Yakovlev kindly pointed out. In fact the agent will be detected and not reinstalled but the additional management group will be added…
Now there’s the option to do it manually on the server as well using the new Agent Configuration app in control panel.
Before you had to run the setup wizard of the SCOM 2007 R2 agent and choose the “add a management group” option when installing.
Now you can just open your control panel:
Navigate to System and Security
Open up the Operations Manager Agent
You’ll see your primary Management group where the client initially was pushed from:
Click add and fill in the name / primary server and port of the additional management group:
It’s added! Click apply and wait for the services to restart and your done.
So at this point your agent is multihomed to your 2 management groups and is happily sending it’s alerts to both of the management groups.
This convenient little adaption has changed the way you multihome an agent and has significantly improved the user experience of doing so.
Stay tuned
Ok first of all I’m wishing you all a very nice year 2012 with everything you wish for as well on private as professional fields…
But enough chit chat. That’s not why I’m so excited.
THIS… yes THIS year will be a milestone in the System Center family. All the new versions of System Center products are just waiting around the corner packed with new features to make your live as a Sysctr admins even easier.
It has been a bit quiet on this blog due to various professional and personal reasons but my resolution for 2012 (at least one I can keep) is to start posting to this blog back regularly.
Stay tuned for the next events in the pipeline:
Next blog series in the pipeline:
So take a deep breath, close your eyes and then jump in and let the system center 2012 rollercoaster take off
I have the privilege of giving a session at the “Meet the System Center operations Manager 2012 Experts” event of Scug NL on 06/01/2012.
On the link below you can find the different topics + timetable.
http://www.scug.nl/2011/12/07/meet-the-system-center-operations-manager-2012-experts-6-januari-2012/
I’ll go over the different aspects of preparing yourself for the upgrade / move to the next best thing SCOM2012 by planning and not by being the IT_Rambo for a change…
There’s a good chance that IT-Rambo will surface in NL.
In my recent session I’ve showcased an error I encountered when upgrading my SCOM2007R2 environment to SCOM2012beta.
After the upgrade was finished successful I performed my standard after migration health check and opened my web console to check out the new features of the SCOM 2012 console.
Only to find out this very “nice” cryptic error message:
Apparently this is because the ASP.NET version was installed after the IIS role and the new web app “SCOM 2012 Web Console” was never registered to use this version of ASP.NET with the IIS role.
So what are we going to do now… well euhm… Fix it
Open an elevated command prompt (make it a habit, this will save you a lot of trouble in your live)
Open explorer and browse to “c:\windows\Microsoft.net\Framework64\v4.0.30319\”
Note: Make sure you use your installed framwork and version
Locate the file aspnet_regiis.exe and drag it into your elevated command prompt and add the switch –iru at the end as shown below.
This actually will reinstall the ASP.NET version into the IIS sites so they can all use the new version. Sites which already use the new version are left untouched.
Finished installing… So we’ll see what happened to our console!
Well it’s loading up fine at this point
Note: You’ll need to have Silverlight installed. If you don’t have it on your machine a nice kind message will appear whether you want to install it. I’ve installed it in advance as it is one of the prerequisites.
There we have our nice brand new shiny Scom 2012 web console which we can start exploring
During my session on how to prepare yourself I’ve showcased some tips and tricks which will make your live much easier when you upgrade your existing SCOM 2007 R2 installation to SCOM2012.
One of the tricks I’ve mentioned was to run the SCOM2012 web console in it’s own app pool. During the upgrade of your web console the application pool will be removed and you can only choose the default application pool to install the website which is in my opinion not a best practice.
So before installing the Web Console on your webserver perform the following tasks in IIS:
Open the IIS manager on your machine
Right click the application pools and choose “Add Web Site…”
Fill in the details:
Note: At this point you need to choose another port than the default 51908. You can change this again after the upgrade.
The site is up and running.
During the wizard for pre installation you’ll get at one point at the following dialog to choose your application pool. Here’s the reason explained why we can’t reuse the “old” site:
The Operations Manager WebConsole will be deleted during the upgrade so it will default to the default application pool.
Select the new created website and continue.
After the upgrade you’ll notice that the old site has been removed. At this point you can edit the binding of the application pool again to the default port to keep the same transparency towards your users.
More tips to follow so stay tuned!
On 20th of September I’ll be hosting a live meeting where we’ll go over the different steps to prepare yourself and your environment for the move from SCOM 2007 to SCOM 2012. The upgrade path has been said to be easier than the one from MOM2005 to SCOM2007 (god thank). But still there are some things to keep in mind and consider before moving towards the new version when it’s released.
So join me on the 20th of September to prepare yourself for the next version of the SCOM software family.
The abstract of the topics covered (more to come):
Link to join in: https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032492077&Culture=en-US
I’ll be prepared for SCOM 2012… will you?
In SCOM 2007 it’s possible to fill in custom fields with rules like you did in MOM 2005 as explained here: http://scug.be/blogs/dieter/archive/2011/05/13/scom-2007-custom-alert-fields.aspx
However this is not possible in monitors because there’s a fundamental change in how the alerts are created. In Rules the GenerateAlert module is used to create the alerts. In this GenerateAlert module it’s possible to pass extra data like the custom fields. In monitors the alert creation is slightly different. The alert is generate with parameters in the monitor itself so it’s not possible to pass extra data.
For a client I’m migrating MOM2005 to SCOM2007R2 and of course I would like to take advantage of the fact I can create monitors instead of rules. My client has a mainframe based problem management system (could also be any other system which doesn’t have a connector) which uses a mail scrubber to read out mails and scan for specific keywords to create tickets.
The specific keywords were passed in MOM through the custom fields. This is also possible in SCOM but only by using rules and not monitors. A solution could be to create a monitor and create a separate alert generating rule for that monitor. This solves our issue but is not manageable because if things change you have to change both the monitor and the rule to make sure they reflect the new situation.
Therefore I came up with another solution. Because there are only 15 possible combinations of keywords at my client I choose to use the Subscription / notification channel to insert the keywords in the dbase before I send it to the Problem management system. I could have just passed the parameters to the mail and send it but I prefer to update the dbase as well to also reflect the changes in the alert.
I’ve based my script on the script I used earlier on and is featured here: http://scug.be/blogs/dieter/archive/2011/05/11/scom-dump-alerts-to-text-file-and-mail.aspx
The main difference with the script above is that instead of reading the custom fields out of the dbase I pass them with the Notification Channel. Doing this makes the keywords centrally manageable when the keywords change.
As mentioned above I mostly reused the script of my previous blog post but for the record I’ll explain the script here once more:
First of all. You can download the script here: http://scug.be/members/DieterWijckmans/files/create_customfields_monitors.zip.aspx
The main difference with the previous script is the fact that we are not reading the data out of the dbase (in the $_.customfield fields) but inserting the data in the dbase through parameters by using the script.
Parameters: The “param” statement needs to be on the first line of the script. In my case I’m reading 3 parameters: The alertID (which is mandatory for the script), The Problemtype and the Objecttype.
The last 2 fields will be inserted in the $_.customfield dbase fields and are needed by the third party problem management solution to make the proper escalation.
RMS: Read the RMS server name of your environment. If you are using a clustered RMS it’s better to fill in the name of the cluster and comment the automatic retrieval of the name out to avoid problems.
Resolution State: The resolution state needs to be defined here and also defined in the SCOM environment (for more details on how to configure this in the SCOM environment check here: http://scug.be/blogs/dieter/archive/2011/05/11/scom-create-custom-alert-resolution-states.aspx
Loading the SCOM cmdlet
Culture Info: To make sure that the data format is correct you need to fill in the Localization. In my case it’s nl-BE.
Read in alert + fill in custom fields: The alertID which is passed as parameter is read in here and the data is retrieved out of the dbase. The other 3 custom fields which are required by the problem management system are filled in here and updated in the dbase. Technically there’s no obligation to fill in the fields in the dbase but to make sure that the custom fields are filled in when you open the alert in the console I update the alert anyway.
Note that I needed to make modifications to the date format to reflect the localization format here. All the data will be dumped to a file which is kept for future reference. The File path in yellow can be changed to reflect your location.
Mailing section:
Mailing the file to the problem management system or if in case an error occurred alerting the SCOM admin. Make sure you fill in the OK recipient, the NOK recipient and the SMTPserver to send out the mail.
Last but not least we are writing an event in the event log whether the operation was successful or not. This gives us the opportunity to monitor the problem creation script from within SCOM.
This solution works for me because I have a limited number of possible combinations.
A couple of things you need to configure before this script can be used in production:
The script must be run on the RMS (if it’s a clustered RMS make sure that the script is on both clusters in the same location).
Note: If you want to use more parameters or different names you have the change the following things:
There are 10 customfields available in the dbase so you can pass up to 10 parameters in the script and thus into the customfields.
If you have remarks or questions regarding the script please do not hesitate to drop me a line or contact me on twitter http://twitter.com/#!/dieterwijckmans
Scom is a great product but from time to time you need a custom build tool or script to do just the thing, or change just that bit that’s not possible in the SCOM console.
I’m personally a huge fan of the Powershell cmdlet supplied with SCOM. For most of the tasks (whether it’s automating or extending SCOM) it does the trick quickly and easily.
From time to time there’s a tool passing by on the world wide web that fills a gap to make our lives as a SCOM admin more easy.
Yesterday another of these fine tools emerged: http://systemcentercentral.com/forums/tabid/60/indexid/88501/default.aspx?tag=
Note: You need to register to download the tool.
This is the first version of the nice tool to count the instances per management group. This can be helpful to troubleshoot your environment. The PowerShell script which was posted in the community a while back took sometimes 3 hours to complete the task while this nice .net program is taking minutes…
You need .net framework 4 to run the tool.
Keep an eye on the topic because I’m sure it will progress in the next days like the authors mentioned in the topic itself.
Yesterday Microsoft released the Cumulative Update 5 (CU5) for Scom 2007 R2.
This new update contains some additional fixes for Operations Manager 2007 R2 + support is added for Red Hat 6.
You can download the CU5 package (948.0 MB) here: http://www.microsoft.com/download/en/details.aspx?id=26938
The KB2495674 article apparently is not online yet but can be found here: http://support.microsoft.com/kb/2495674
For instructions on how to install a CU package in general (blog is written for CU4 but best practices can be followed for installation of CU5 as well) you can check this :http://blogs.technet.com/b/kevinholman/archive/2011/02/01/opsmgr-2007-r2-cu4-rollup-hotfix-ships-and-my-experience-installing-it.aspx
A new milestone in the development of System Center Operations Manager 2012 (SCOM2012) today. The release of the beta to the public.
More info on the team blog here:
A small portion of the SCOM 2012 FAQ which is something most people are very curious about:
“We’ve made significant investments to help our customers build more comprehensive monitoring for their private cloud environments, while integrating their existing datacenter investments.
Here’s the direct download link:
http://www.microsoft.com/download/en/details.aspx?id=26804
Technet info link:
http://technet.microsoft.com/nl-be/library/hh205987(en-us).aspx
The final release is still planned for the first half of 2012. But you can evaluate it now already.
Caution:
As this is beta software it’s not supported to run this in a production environment.
We’ll be blogging more on the install process and first findings soon.