Finally got a request to set up a subscription for an event report. The person wanted this report for a particular event from X servers in the last 24 hours. I create the report, set up subscription and saved it. When I saved it I got an error about SQL Server Agent not started. I found the SRS DB server, started the agent. I figured I was good to go. Next morning, no reports. Look in the console and saw the subscriptions failed:
We don’t use Exchange to relay, we use Unix MTA servers. We have a dedicated round robin DNS entry that will redirect servers to various MTA’s that allow anon relaying based on computer name and IP. You have to register your servers with this process. I verified I could telnet to the round robin and send a test message. So I was baffled as to why it wasn’t working. I checked the event log on the SRS server and saw a few of these, but they were not consistent with every failure:
So I checked the Config utility:
Looked good right? Yes it did. I bounced the SRS service, still no go. I examined the SRS log files to see what I could find and found this:
“ReportingServicesService!emailextension!10!12/17/2009-16:24:22:: Error sending email. System.Runtime.InteropServices.COMException (0x80040213): The transport failed to connect to the server.”
I saw several of these due to my testing. I
googled, I mean Binged! for this error and found a few results. Most everyone was telling the person with the problem to look at the ReportServerConfig file and ensure the data was valid in there. I looked at mine and saw it reflected what was in the config gui, but didn’t have the SMTP port listed. I stopped SRS, added my change, started SRS:
Once I did that, I checked the status of the subscription in SCOM:
Great success! Within a minute I got all of the reports I had been trying to send initially. Very Nice!
So if you have a similar problem, then you might want to mod the config file to put port 25 in there and see if that solves your issues.
…And it feels like a major pain point. I don’t know how this got approved, but maybe with enough feedback we can get MSFT to revert this, and or make it better.
Searching for a MP in the old MP catalog was pretty simple and straight forward:
1) Go to the Catalog
2) Pick your criteria
3) View your results and sort by various criteria!
83 management packs by Microsoft for SCOM 07 all listed on one page and sort able by various columns (name, release date, etc)!! Alright let’s do this!
Oh, but those days are soon to come to an end whenever they turn that link off I gave you at the top. If you go to the SCOM product page and click on ‘Find Management Packs and Connectors’ link (as seen below).
Then you will be directed to the new site.
Search for Exchange 2003 and I get two results:
If you look at the works with drop down boxes, you will notice SCOM R2 is pre selected. So you will need to change that to your version of SCOM/MOM. I changed mine to SCOM 2007 and price “Free” and that gave me one result for Exchange 2003.
As I changed what I searched for, the “works with products” selections never changed, but my results for OCS were a bit off:
This is not user friendly, very clunky, and time consuming for people who want to quickly find and download management packs. Where’s the apple guy when you need him to do a new commercial? I doubt that five year old kid who is a “PC” could figure this out. Oh she can take pictures, transfer them to her laptop and print them out, but ask her to find a management pack on pinpoint and she will probably have to go to the “naughty” corner for the language that comes out of her mouth.
I recently have had to do a lot of tuning for the Exchange 2003 MP. Our labs are SP1 with the post SP1 HF. If you have deployed this post SP1 HF rollup, then you know that some of the SCOM libraries get updated as well. While tuning the Exchange 2003 MP I was sure to only target the correct application classes. Happy with my tuning efforts I exported the MP and tried to put it into the SP1 production environment. This failed because the override MP had a dependency on the Windows Library MP that was now a .100 from .0. I hacked the manifest and changed that from a .100 to a .0 and was then able to import the MP into production.
I wouldn’t recommend this for everyone of course. You have to ensure that your overrides are targeting the right classes and not applied to other classes that might be from one of the updated management packs.
The other thing I learned, which I suppose is a known issue, is that consecutive threshold monitors will not display the actual value of the performance counter when they raise an alert or in health explorer. There was some bug/issue in the model for that monitor. This was fixed in R2. If you have the Exchange 2003 MP you might be aware of the Self-tuning threshold monitors that are pretty noisy. I disabled all of those and created consecutive threshold monitors to replace them, but now operators will have to launch the performance view to see the current value of the monitor. I really cannot wait to get on R2.
Did you, like me, import the HP server management pack and have a large clustered Exchange environment running on HP servers? Did you notice how frequent the discoveries run and monitors change state? How about the duplicate alerting for cluster’s going offline? Sometimes it’s nice to have all your bases covered, but other times it turns into a management mess. Realizing that there are other groups responsible for the HP hardware, I decided to exclude all of our Exchange servers as well as other applications (OCS/BlackBerry/SharePoint) from HP monitoring. I created a over ride mp for the HP management packs (I did just one, instead of one for each of their management packs) and created a group targeting the windows computer class that contained all of my servers by OU and name filtering and saved it in the HP override mp. Once I verified the membership was correct, I disabled the discovery for this group, then ran the “remove-disabledmonitoringobject” command from the command shell. All the while I had my console scoped to the HP Server discovered objects (over 1000 were listed and my group membership was about 550). When I ran it I would see something similar to this after it completed:
I got a little concerned, and talked to the elite DSE Jonathan Almquist. We did some queries, but ever time I would run this I would get this output. I did notice the number of objects listed in the targeted class window was decreasing. I had to keep executing this until all the disabled objects were finally removed. Once they were finally removed I no longer got the red text. Jonathan had told me that there were some support engineers who said that they had seen this issue with customers who had large SCOM deployments. So if you have a large SCOM implementation and are trying to do what I was, don’t be surprised if you see this, just continue to remove.
Have you ever seen what appears to be duplicate reports in the actions tab of your SCOM console? Something similar to this:
If you have seen something similar, then you might want to check if you have the MOSS 2007 and Windows SharePoint Services MP’s imported. Turns out that these “duplicates” are not duplicates at all, but targeting Windows Computer classes.