Friday, December 21, 2012

From Saturday the 22nd of December 2012 until the second of January 2013 this blog will be silent since I am enjoying holiday season with my family.

Like every year when I post a similar article, I want to thank YOU for visiting my blog and taking time to comment on many of my postings. This is very important to me since this blog isn’t about me but for everyone working with System Center on a daily basis. And like a restaurant which becomes just as good as it’s critics, this blog can only become a good one (and stay up to specs) with your feedback.

So keep your comments coming in, I will most certainly respond to it (sometimes I get swamped by all the comments and work so sometimes some comments slip through for which I apologize).

Before I’ll answer that (or better provide a link to to the official webpage of Microsoft about that topic) I want to tell that it looks like that SP1 for System Center 2012 will be general available from the 3rd of January 2013. So just a few more weeks to go before the bits can be downloaded. Nice!

The official webpage all about SP1 for System Center 2012 can be found here. As you can see there are many improvements. And because the webpage is a bit dated it might be expected there will more to tell about SP1 when it becomes GA.

Wednesday, December 12, 2012

Bumped into this issue: the SCOM R2 Reporting Tree was stale: MPs which were a long time ago removed still showed the Reports and newly added MPs, containing Reports, weren’t uploaded to the SSRS instance. Time for an investigation.

CauseIt turned out there had been a change of proxy server several months ago and was enforced to all users by a GPO. Even though the SCOM 2007 R2 service accounts had internet access, the Data Warehouse WRITE account needed additional adjustments as well.

Problem SolvedI logged on to the RMS by using the Data Warehouse WRITE account for SCOM 2007 R2. Opened IE and adjusted the proxy settings so it would bypass the proxy for local addresses:

The saying is based on this fact: A pearl come to be because in the oyster shell a small particle (sand) is irritating the mussel. Therefore it puts a layer of material around it so it doesn’t irritate anymore, thus a pearl is created. Thus meaning, out of irritation many good things come to be…

When looking at my blog, I can say the same about it for many postings. Quite a few times I bumped into a situation which really looked straightforward to me at the beginning but after 30 minutes, everything is totally different and a seemingly easy procedure – like ABC – turns sour. Until now I cracked most of them and posted them on my blog for the community and as my ‘personal’ KB library.

This posting is no different. A seemingly easy procedure goes bad. Took me some hours to find the cause but I cracked it. There’s much to tell so let’s start.

The DealAdding a second OM12 Management Server to an existing OM12 Management Group since only one OM12 MS is in place which isn’t valid for any OM12 environment.

Next > Next > Finish? No! Next > Next > Roll back!Of course I have everything in place and ready. A new VM, with enough storage, CPU and RAM. Added to AD and the proper permissions in place. All the information of the MG is at hand with also the OM12 service accounts. The prereqs on the OM12 MS to be are installed and functional.

So lets start! Next > Next > Next > ?!%$^@ > Rollback?!

But all the OM12 services started so KB2677070 isn’t at play here. Double checked it (presumptions are the mother of all…), but no way, that KB isn’t present on that server. And yes, the new server can connect to the OM12 SQL Server without any issue. And yes, the account which runs the install has all the required permissions. Is admin on the local server, has OM12 Admin permissions and SA permissions on the SQL Server instance. And no, the firewalls aren’t blocking anything here.

And that’s correct. Simply because the installation GUI of OM12 when installing an additional OM12 MS doesn’t prompt for those credentials:

As you can see, no credentials are entered for the Data Warehouse accounts (Read/Write). So the installer passes an empty value for those accounts which SQL Server refuses, causing the installation of the OM12 MS to fail.

But WHY?OK, now I have found the cause. But now the reason WHY. I have installed many new OM12 environments with many additional OM12 MS servers. And that went just fine. So what’s different here?

In this particular situation the SQL Server being used here runs many other SQL Server instances as well. One is dedicated to OM12. But this is a named instance with another port then the default one, 1433.

Somehow, somewhere when an additional OM12 MS server has to be installed and the OM12 databases reside on a named SQL Server instance NOT using port 1433, the OM12 installer has to pass the Data Warehouse credentials used by OM12. But the GUI installer doesn’t prompt for them so it’s passes a zero value instead!

Why doesn’t the GUI installer prompt for ALL OM12 Service Account credentials?Good question and beats me as well…

The FixInstall the additional OM12 MS servers using an elevated cmd-prompt while running a silent install. But before you start read this posting of mine as well because otherwise it won’t work.

Close all other installation screens opened by the Install GUI of OM12. Otherwise the new installation will fail as well;

Empty the folder %LocalAppData%\SCOM\Logs. Two reasons: we don’t want to be remembered by our failures and secondly we want clean log files;

Copy the contents of the installation media of OM12 to the local server for instance C:\Install\OM12;

Create the syntax for the Setup.exe file you’re going to need later on. Syntax is this:

Replace all values in blue with your values and copy everything into a single line;

Open an elevated cmd-prompt and go to the folder containing the installation media of OM12;

Run the syntax you made based on the information as described in Steps 4 and 5;

Because it’s a SILENT installation nothing will be shown like a GUI for instance;

In Task Manager however you’ll see some instances of msiexec.exe taking place;

Be patient, in my case it took less then 10 minutes for the additional OM12 MS server to install successfully;

Signs of success:

The OM12 Console shows in Administration > Management Servers the additional OM12 MS which becomes green and stays like that (not greyed out anymore for an endless period of time);

On the additional OM12 MS server itself the OpsMgr event log is being filled and continues to grow with good healthy messages;

On the additional OM12 MS server itself, the earlier mentioned msiexec.exe processes disappear and are ‘replaced’ by some MonitoringHost.exe processes, telling you the OM12 MS server has started monitoring itself.

Now with the additional OM12 MS server in place it’s time to install the OM12 Console as well, we left that initially;

Open Control Panel > Programs and Features > select System Center 2012 – Operations Manager > right click, select Uninstall/Change;

In the screen which appears now select the option Add a feature > Next;

Select Operations Console > Next;

Follow the rest of the wizard and the OM12 Console will be installed within a few minutes;

Close all screens and install now the same Update Rollup which is in place for the OM12 MG on the newest OM12 MS server.

Now all is well and OM12 has an additional OM12 MS server. Still puzzles me why the installation GUI of OM12 doesn’t prompt for ALL OM12 Service Accounts. Would have saved me a lot of time…

In the last posting of this series I’ll take a look at the other Dell MP Suite monitoring functionality and come to a verdict of this MP Suite. When you haven’t read the previous postings you’re advised to do so before reading this posting.

A nice touch of Dell is here that a MP especially for SCOM R2 is made (Dell.CMC.OM07.mp) and another for OM12 (Dell.CMC.OM12.mp). So depending on the OM version you run you import the MP which is relevant. For CMC monitoring four MPs must be imported.

Dependencies(limited to the CMC MPs only!)As you can see is the Dell.Model.CMC.mp the foundation here. The SCOM R2 MP or OM12 MP depends on all other three CMC MPs. Basically meaning all four MPs must be imported otherwise CMC monitoring won’t work.

MPBA & MPViewer resultsThe Dell.Model.CMC.mp isn’t shocking. MPBA shows only one warning which was to be expected since this MP is really tiny. It only creates the foundation for CMC monitoring. It defines some classes and relationships. No Rules or Monitors what so ever.

The Dell.OperationsLibrary.CMC.mp is a library file defining the operations used by the Dell CMC MP. A small MP as well only containing four discoveries. No Rules or Monitors to be found here. MPBA is happy with the MP and finds nothing to report about. Didn’t expect otherwise actually with such a basic small MP.

The Dell.View.CMC.mp defines the views used by the CMC MP. It doesn’t contain any OM12 Console widgets which is why this MP fits SCOM R2 as well. The MP adds 5 basic Views to the console. MPBA finds one nagging issue which results into the Alerts to be displayed in the wrong order (not the newest Alert on top).

The Dell.CMC.OM12.mp is the one which does all the CMC monitoring. It contains 4 Unit Monitors (2 SNMP based) and about 25 Rules, all SNMP trap based.

So per CMC device you have about 27 SNMP based Rules/Monitors running against it. Something to reckon with in your OM12 environment. Make sure your MG is properly dimensioned to take this additional load of network device monitoring.

Also here Dell differentiates between SCOM R2 and OM12 by delivering the Dell.DRAC.OM07.mp and the Dell.DRAC.OM12.mp. So depending on the OM version you run you import the MP which is relevant. For DRAC monitoring four MPs must be imported.

Dependencies(limited to the DRAC MPs only!)As you can see is the Dell.Model.DRAC.mp the foundation here. The SCOM R2 MP or OM12 MP depends on all other three DRAC MPs. Basically meaning all four MPs must be imported otherwise DRAC monitoring won’t work.

MPBA & MPViewer resultsThe Dell.Model.DRAC.mp is a surprise. MPBA shows about 18(!) warnings which is bad since it creates the foundation for DRAC monitoring. Most warnings are about missing Display Names. So this isn’t a good start. The MP itself defines some classes and relationships. No Rules or Monitors what so ever.

The Dell.OperationsLibrary.DRAC.mp is a library file defining the operations used by the Dell DRAC MP. A small MP as well only containing five discoveries. No Rules or Monitors to be found here.

The Dell.View.DRAC.mp defines the views used by the DRAC MP. It doesn’t contain any OM12 Console widgets which is why this MP fits SCOM R2 as well. The MP adds 8 basic Views to the console. MPBA finds two nagging issues which result into the Alerts to be displayed in the wrong order (not the newest Alert on top) and another issue about missing Display Names.

The Dell.DRAC.OM12.mp is the one which does all the DRAC monitoring. It contains 10 Unit Monitors, 9 Dependency Monitors and 191(!) Rules, all of them enabled and generating Alerts.

Good to know is that 74 of these Alerts have an Informational Alert Severity. Personally I don’t fancy informational Alerts since they don’t really add value to SCOM R2/OM12. Many times they’re noise.

But still 67 of the 191 Rules do have a Critical Alert Severity which is really a whole lot. Don’t know how many of these are really critical.

And YES, all of these Rules are SNMP based. So per DRAC device being monitored by OM12 there are 191 SNMP based Rules in place. Again an additional load on your OM12 environment. Something to reckon with in your OM12 environment. Make sure your MG is properly dimensioned to take this additional load of network device monitoring.

Chassis Modular Server CorrelationThis MP (Dell.ChassisModularServer.Correlation.mp) doesn’t monitor anything – thus not a single Rule or Monitor to be found in that MP – but correlates the Dell CMC and DRAC/MC slots with Dell Modular Servers.

Not much to add here besides this MP is advised to be imported when you decide to monitor CMC and/or DRAC.

VerdictThe Dell MP Suite on itself proofs Dell is truly dedicated to bring Dell hardware in to SCOM R2/OM12. The scale of the MP is rather huge since it covers many aspects of the Dell hardware. Compared to a few years back the Dell MP Suite shows progression in build quality.

However, the build quality is still one of the most crucial points of any MP and the Dell MP Suite isn’t an exception here. As shown in previous postings and this one as well, the Dell Suite MP and it’s set of MPs do have some issues, ranging from a nuisance (wrong sorting order of Alerts) to more serious issues many of them directly related to Core MP Functionality.

This new suit also introduces a new approach to importing the Dell MPs in SCOM R2/OM12. On itself, looking at the amount of MPs involved, an understandable idea. But the way it’s done (by adding the functionality in the Monitoring part of the Console) is a bad idea. This part of the Console is shown to the Operators as well and they don’t have any permissions to import/delete MPs. So Dell should bring this to the Administration part of the Console or skip it all together. For now my advice is to remove that MP (Dell Feature Management) from your environment, as described in the third posting of this series.

As seen with previous Dell MP Suites, the amount of Rules and Monitors using SNMP can be enormous. In SCOM R2 this can pose a real threat to the overall stability, scalability and availability of the whole MG simply because the SNMP module used by SCOM R2 is anything but robust and scalable.

But even when running OM12 there is still a lot going on SNMP wise. So be careful when monitoring CMC/DRAC modules since the additional load created can be (to) big for your environment. Testing is key here and also very important, tweaking and tuning.

Perhaps Dell should build the next version of the Dell MP Suite in a different kind of way: Most of all Rules/Monitors disabled and a few MPs only containing overrides to enable the most relevant ones. This way one can use a phased approach when deploying the Dell MP Suite.

Should I or not?When you have Dell hardware in place it’s wise to monitor it by using the Dell MP Suite. However, don’t import all Dell MPs found in this suite but use a phased approach instead. Go about it like this:

RTFM both documents (PDF and text file);

Start with Dell Server hardware monitoring only and nothing fancy like OOB;

Tuning, tuning and tuning is key here.

When that’s in place and functional AND OM12 is still OK, you can move on but only after you’ve tested these MPs thoroughly. The DRAC MP contains too many SNMP Rules for instance so tuning is really required here.

And for the rest take notice of the advice I have given in all the previous postings of this series.

Monday, December 3, 2012

It was to be expected, sooner or later one or more SC 2012 components to be delivered from the cloud. Cased Dimensions is the first one to make it really happen.

They offer System Center 2012 – Service Manager directly from the cloud!

Taken directly from the Service Manager Engineering Blog: ‘…The offering is pushed from a Private Cloud platform where clients get the full native functionality of Service Manager whilst being in the Cloud. Their Management Packs for Asset Management, SLA Management and Assigned to me also come as part of the Cloud…’

A few days ago Microsoft released the System Center 2012 Integration Guide – Orchestrator.

Purpose: ‘…to provide an overview of each System Center component in its role as a programmable platform to be leveraged for the Microsoft Private Cloud. It is intended to provide an abstraction layer that guides partners and customers on their decision process for methods to build automated solutions across System Center components…’

A few days ago Microsoft released the System Center 2012 Integration Guide - Operations Manager.

Purpose: ‘…to provide an overview of each System Center component in its role as a programmable platform to be leveraged for the Microsoft Private Cloud. It is intended to provide an abstraction layer that guides partners and customers on their decision process for methods to build automated solutions across System Center components and between System Center and other systems…’

Veeam

NiCE

Search This Blog

Didacticum

Pageviews last month

Visitors to this blog:

Why this blog?

On an almost daily basis I work with Azure, OMS & System Center related technologies. At the moment my main focus areas are Azure, OMS, SCOM & SCCM.

Because I bump into many challenges I decided to start this blog, which has two main purposes: to help YOU with mastering these products by covering the undocumented features and last, but not least, as my personal - but open to any one - knowledge base.

From January 2010 on I have been rewarded with the MVP award and until now this this status is prolonged every year.

MVP AWARD

Follow me on Twitter

Disclaimer

The information in this blog is provided 'AS IS' with no warranties and confers no rights. This blog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my own personal opinion. All code samples are provided 'AS IS' without warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.