Just a quick note. Since begin February 2014 i changed job. I wanted to do more deep dives into creating System Center add-ons like SCOM Management Packs. So I joined the OpsLogix Dev team. I will be working on the Opslogix released Management packs , for example VMWARE , Oracle and Blackberry.
Right now I have finished an IBM WebSphere MQ MP and I’m now designing the ORACLE RAC monitoring MP. Many other new products will follow in our roadmap. If you need any custom MP or have a need for authoring assistance please let me know.
Let’s do some “Happy Scomming”!
Maybe you noticed that I didn’t post no more for a couple of month.
Yes I bought a new home. So I had to renovate it all. It took(and still takes) a lot of time. But I will try to post regular again.
1) do not buy a new home ! it will save you time…
2) stop blogging. …. not a option
3) start again if you have time … hmmm
I prefer #3.
Happy scomming soon
First mention this is a non official solution.
You have installed SCOM 2012 Sp1 UR2 and have implemented the scom webconsole and reporting service to be running under HTTPS mode. You have created using the native scom console a favorite report and now when you try to open this favorite report in the scom webconsole you get a error 500.
To see the real error we have to do some web.config changes. So open the web.config file on this location: C:\Program Files\System Center 2012\Operations Manager\WebConsole\MonitoringView
Now we enable the SCOM error logging
And to get it displayed on the user page we do
Now when you run the favorite report again we get in the webconsole the real error
Okay looks like the reportviewer web component binary dll can’t be found. Hmm but wait wasn’t this a prereq at installation time. So I checked if the 2010 ReportViewer components where installed and yes it was and the dlls where also spotted in the assembly cache. It looks like the webconsole has problems finding the correct version of the Microsoft.ReportViewer.WebForms.dll in the assembly cache.
The Quick non Official Solution
Copy the missing dlls to the correct directory will force the web runtime to first look in this directory for the dlls and then go to the assembly cache. So that’s what i did.
Copy the Microsoft.ReportViewer.WebForms.dll file from the assembly cache to path : C:\Program Files\System Center 2012\Operations Manager\WebConsole\MonitoringView\bin
Come on give me some script to do that ! Okay open PowerShell as admin and run
Copy-Item c:\Windows\assembly\GAC_MSIL\Microsoft.ReportViewer.WebForms\10.0.0.0*\*.dll “C:\Program Files\System Center 2012\Operations Manager\WebConsole\MonitoringView\bin”
And now you try to run the favorite report again in the webconsole …
… and Yes its working!
For me this looks like a bug and I will address this to Microsoft.
A really short post. A member of a NOC operations team reported a problem with his SCOM console.
Using the operations native console and opening a windows computer state view resulted in gray computer targets.
Normally when for example the computer targets are gray you know it’s a gent connectivity problem or the MS health service is stalled / crashed. But this time non of this was true. Looking at the agents and MS states its was all green and okay.
First the root cause was assumed to be the computer of the NOC operator. Yes I have rebooted it twice and I have installed all the patches was the first response . But however I am running Windows 8. Okay .. could this be the case ?… After a while of figuring out what could be the problem we detected that on other NOC computers the problem was also reproduced. And yes now we had found the problem .. And what do you think ? If you have a target state view (for example the windows computer view) and you personalize this view and remove the State column you will facing the problem above. So we added the State Column again and the problem was fixed.
Of course you can ask you’re self why remove the state column it’s a very important one. Lets say the most important one in a state view…. I have ask it my self’s but I think it was a human error by mistake and not noticed earlier… But the question remains this still looks like a bug in the SCOM console.. What do you think ?