Wednesday, December 31, 2014

Happy New Year!

I wish everybody a Happy New Year. 2015 will be an exciting year with MANY new blog postings about System Center products.

So stay tuned. For now, I wish you all the best for 2015.

Friday, December 19, 2014

Merry Christmas

My blog will be silent for the week during Christmas. The days before New Year I’ll do my best to publish some postings. But for now I want to wish all the readers/visitors of this blog a Merry Christmas.

And thank YOU for visiting this blog and all your comments. It’s what makes my blog standing out of the crowd. Awesome!

Wednesday, December 10, 2014

Error When Trying To Remove Web Application Transaction Monitor

Prelude…
Sometimes I find myself in situations which give me the ‘Duh!’ feeling, like doing something wrong and not being able to fix it at that moment. However, when trying to solve it a day later, it’s fixed in the matter of minutes while the day before the solution eluded me totally. And not only that, but when I solve it, I don’t feel that smart either since I know I stepped into a well known pitfall which I should have avoided…

For me these are signals it’s time for a break and gladly within a few weeks I’ll have a break of one whole week! Nice!

Issue
Got this error when I tried to delete a certain Web Application Transaction Monitor: The item you are trying to delete cannot be deleted because another object references it. The object must be deleted before this item can be deleted:
image

But at that moment I couldn’t crack it. Yes, there was a Distributed Application using this very same Monitor. So normally you remove that DA first (or modify that DA so it doesn’t use that particular Monitor anymore).

But also the DA kept throwing similar errors! And the cause of that eluded me. Instead of wasting valuable time, I exported the MP containing this Monitor and set it aside for another day. Simply because I already felt that I was missing something very obvious here…

Cause
As it turned out, that particular Monitor was used in a DA. But that DA had some other modifications as well, like newly added Dependency Monitors, in order to enable the rollup of the Performance, Security and Configuration parent monitors as well.

After having removed those Dependency Monitors, one by one, I could easily remove the DA containing that Monitor. And afterwards I could easily remove the Web Application Transaction Monitor.

Recap
Whenever the removal of any Web Application Monitor throws errors like item you are trying to delete cannot be deleted because another object references it. The object must be deleted before this item can be deleted, that Monitor is being used (referenced) in one ore more DAs.

When removing that DA throws the same error as well, changes are that you have some modifications on that DA as well.

So start with the removal at the bottom and work your way up. By removing all the references one by one, soon you’ll end at the Web Application Monitor involved and than you can remove that Monitor without any hassle.

Tuesday, December 9, 2014

SCOM 2012x Console On Steroids? Try MDoP…


Update December 9th 2014: Based on some good and valid feedback from PFE Microsoft Germany I’ve decided to update this posting with their advice and experiences from the field:

The bigger your SCOM environment gets, the better it is to test different MDoP (MAXDOP) settings. Simply because the MDOP Calculator mentioned in this posting, might not always give you the best MDoP values for SCOM. Also in virtualized environments many other factors play an important role as well. For instance, PFE Germany bumped into an environment with 5000+ SCOM Agents. The recommended MDoP setting was 8 but as it turned out, a reduction to 4 for MDoP worked better.

So: TEST YOURSELF BEFORE YOU WRECK YOURSELF.

A BIG word of thanks to Microsoft Germany PFE for their valid feedback and their willingness to share their own experiences from the field.


Issue
A dead slow SCOM 2012x Console. No matter what we did, there was only some minor improvement. And yes I know. The SCOM 2012x Console isn’t speedy at all. It’s by design apparently Sad smile. One of the biggest drawbacks of SCOM 2012x and also of SCOM 2007x.

But in this particular case it was dead slow. Even for SCOM 2012x it was totally unacceptable. So even when tuning SQL and the related SCOM Operations database, temp databases and disks to the max as the environment allowed for, the SCOM 2012x Console became a bit faster. But still no good and still frustrating.

So it was time for some deeper investigation and searching on the internet. And suddenly I bumped into this blog posting written by S.Carrilho, all about "mDOPING" your SCOM Console performance with some simple SQL tips.

And as it turned out, the change of speed is AWESOME! Let me first try to explain what MDoP is and does.

Time to meet Max Degree of Parallelism (MDoP)
MDoP = When SQL Server runs on a server with more than one processor or CPU, it will try to find the best level of parallelism by itself. Parallelism is the number of processors used to run a single statement, for each query which has a parallel execution plan.

So far so good.

Out of the box will SQL Server detect by itself what level of MDoP to use. HOWEVER, on servers using hyper threading this won't work out too well. Simply because SQL Server thinks there are more processors/CPUs present than there actually are. This happens on physical and virtual servers alike as long as hyper threading is enabled.

In cases like these it's better to set that value by yourself, for instance by using this MAXDOP Calculator. Otherwise SQL Server will use all the available processors it thinks it has resulting in serious performance issues…

Example
In this example I’ll use the MAXDOP Calculator on my test environment.

  1. Out of the box MDoP is set to zero so SQL Server can decide for itself what the best setting is. Right click on your SQL Server instance in SQL Server Management Studio > Advanced: > Max Degree of Parallelism:
    image

  2. However, the VM running SQL Server uses hyper threading, so the MDoP setting SQL Server chooses for itself isn’t that good at all:
    image

  3. Time to use the MAXDOP Calculator:
    First I run this SQL query: SELECT COUNT(DISTINCT memory_node_id) AS NUMA_Nodes FROM sys.dm_os_memory_clerks WHERE memory_node_id!=64. And this is what the query returned:
    image

    Then I run this PS cmdlet: Get-WmiObject -namespace "root\CIMV2" -class Win32_Processor -Property NumberOfCores | select NumberOfCores. And this is the output it returns:
    image

    Let’s copy & paste that information into the MAXDOP Calculator and see what it returns:
    image

  4. So in this particular case MDoP needs to be set to three.
    This can be done by using the query as described in KB899000 OR you can use the interface itself as shown in Step 1. Simply change the value for Max Degree of Parallelism and click on OK.

    NO REBOOT REQUIRED NOR A RESTART OF SQL SERVER SERVICES!!!

    It’s applied right away after you clicked OK:
    image

  5. In the case of this customer the speed difference is HUGE! (Mind you, their MDoP setting is different than the one in this posting but I don’t share customer information) No, the SCOM Console hasn’t become a speed monster, but right after this setting was applied, people came to us asking what we had done since ALL OF THE SUDDEN THE SCOM CONSOLE BECAME WORKABLE!!!

  6. So we went ahead and changed MDoP on all SQL Servers used by SCOM. And still the differences are HUGE!

Recap
Never I heard of MDoP before not how hyper threading can throw SQL Server of it’s track when setting MDoP for itself. When using dedicated SQL Server instances for SCOM it certainly pays of to check the MDoP setting which is currently used and compare it by what the MAXDOP Calculator tells you is best.

When working with dedicated SQL admins, keep them in the loop and – even better – in the lead. And for this customers I’ve noticed some awesome improvements. From dead slow to a workable situation. Still no Ferrari but the current SCOM Console will never get to that level.

Perhaps this setting can be applied for other System Center components as well. Until now I haven’t seen that modifying the MDoP setting had a bad influence. But always check it with the SQL experts Smile.

Resources
These are the resources I’ve found all about MDoP, in general and related to SCOM and other SC components:

Wednesday, December 3, 2014

Free ebook: Extending SCOM 2012x Reporting

A few days ago Microsoft Press released a new book, all about extending SCOM 2012x Reporting. And yes this book is FREE Smile.
image

Don’t know whether this book makes a real deep dive, but it’s a start at least and it’s FREE Smile. Want to know more? Go here.

Cross Post: Free Microsoft Exam Vouchers For Azure & Office 365 Exams

Bumped into this posting on UP2V:
image

So when you’re interested, go here.

OM12: Monitoring UX & RequireTTY

How I met requiretty…
A few days ago I was asked a question about monitoring UX based systems with SCOM 2012x. Even though I’ve already helped to monitor 500+ UX systems with SCOM 2012x, this question was totally new to me and I even didn’t know at first what it meant Smile.

The question was: ‘We use requiretty on all of our UX systems. However, the OM12x UX Agent doesn’t work with that setting turned on. Does the OM12x UX Agent only function without this setting turned on?

What to do with it…
So it was time to visit the internet in general and one website in particular: Unix & Linux StackExchange, all about UNIX and Linux related stuff. And soon I found two interesting webpages:

  1. Is it okay to disable requiretty?
  2. How to disable requiretty for a single command in sudoers?

But still no clue about what requiretty is
So soon enough I had found what I was looking for. But still requiretty itself eluded me. Gladly I could ask all I wanted to know about requiretty since another customer has this awesome RHEL engineer working for them. He’s a kind of person who would have invented RHEL himself if it wasn’t there already. He eats, drinks and breaths RHEL Smile.

So I asked him whether he knows anything about requiretty. And first he didn’t know what I was talking about until I wrote it down. Even though one writes requiretty it’s pronounced as Require TTY Smile. And as soon as I wrote it down, he recognized it right away and started talking and talking and talking…

What RequireTTY is and does
This is my translation of what I’ve been told. So when I am wrong or not complete mind you I am anything but an UX kind of guy…

As it is pronounced, it’s a security setting in UX, like RHEL based systems. Here you can make the usage of TTY (the RHEL ‘user interface’) a hard requirement. Anything running on that system requires TTY or else it won’t be allowed to run.

However, the SCOM 2012x UX Agent is nothing more but a web service. So it runs in the background and doesn’t use the TTY at all. And when it’s set to use it, or else it’s blocked, it simply won’t run.

How to deal with it when RequireTTY is enabled on the UX system?
Pretty easy actually. For RHEL based systems you can turn RequireTTY off for a certain command or user. So in this case disable it for the SCOM2012x UX Agent and you’ll be just fine. The UX system will keep on running RequireTTY and the SCOM 2012x UX Agent will keep on running.

Tuesday, December 2, 2014

Cross Post: MP Sync Between MGs With PS

I guess many of us have faced the challenge how to synchronize MPs between different Management Groups, like testing and production. Yes, the manual approach is doable when it’s a one time process. But how about it when it needs to be done on regular intervals?

Is Orchestrator the way to go? Is the time required to build such a workflow to be justified? Because it will be much more than just a simple export > import job. One needs to reconsider many different aspects.

Gladly, my highly respected friend and fellow MVP Cameron Fuller has written an excellent posting about this topic WITH the solution for it, based on PS.

For everyone running more than ONE MG, I highly recommend this posting. It contains tons of solid information and a good solution as well. Awesome!

Credits:
All credits go to Cameron Fuller for sharing these awesome PS scripts. Thanks man! Sharing = Caring!