If you’re still hesitant to dive into powershell, you’re not alone. To someone who is a light scripter or has limited or no development background it can seem like a daunting task. A lot of the examples you’ll find are easy and simple, but Write-Host –Fore Green “Hello World! I’m using PowerShell” won’t help you with automating all of those tasks out there.
There are a few places to go, and a few books to read, to help you get up to speed with it.
One of the most promising looking resources would have to be Doug Finke’s “Try PowerShell”.
Try PowerShell is an interactive PowerShell tutorial created with PowerShell using WPF (( Wikipedia: Windows Presentation Foundation )) and PowerBoots.
With it you can easily try out PowerShell commands just by clicking on them, no typing needed. You can search for particular commands, run them, and even edit them to see what happens if you change something. This is an awesome tool I don’t think enough people know about.
The new Infrastructure Planning and Design Guide for OpsMgr 2007 R2 has been released.
If you’ve never checked it out, I strongly encourage you to – especially if you have a new install coming up. The IPD guide walks you through all aspects of the planning and design of an OpsMgr network. After you’ve gone through it you’ll know how to:
These guides are pretty invaluable, especially if you’re not an expert in the technology.
So what are you waiting for? Download it now – and when you’re done, check out the rest of the design guides, too!
Note: The version number is still 1.0 and the published date remains June 2008 – I sent a note off to ask them to increment that.
Operations Manager has always been a fairly powerful tool. Even in it’s MOM2000 and MOM2005 variations it has a lot to offer. Sadly, in all the organizations I’ve been to, it’s never been utilized to it’s fullest.
I want to help change that.
Do you have a ‘batch’ server at your organization? You should. A batch server is a general all purpose scripting machine. It’s one you use to automate a lot of tasks that you don’t want to have a dedicated machine for, but are more important then you’d want to trust to run on your regular workstation. It doesn’t need to be anything particularly powerful – my batch server is a small Dell pizza box with now outdated hardware: Pentium 4 3.4Ghz CPU, maxed out at 2GB of ram, with an 80GB hard drive. Up until recently it ran Windows 2000 – it now runs Server 2008 standard.
A lot of the stuff I’ll be writing about will have a batch server in mind. I run these scripts there, and use OpsMgr to interact with the data. You’d be amazed at how much more you can accomplish and automate things with a simple ‘throw away’ desktop.
To start out, let’s get OpsMgr to record some stock prices. This will be a powershell script, that I’ll be running on our batch server. Read on to see how I do it.
Go out and download the evaluation version. Learn about what’s new and improved! Try it out in the virtual lab. Or watch a quick video by Sacha Dawes, Senior Program Manager for Operations Manager, on a tour of all the new features in R2.
It’s not on MSDN downloads quite yet, but it should be there soon.
Be sure to add them to your list of places to check for all things Operations manager related http://social.technet.microsoft.com/Forums/en-US/category/systemcenteroperationsmanager
As usual, Anders is the first post over there!
I’ve added a suggestion on Connect, #436472, that I think would really assist with the creation of custom reports. In HP’s System Insight Manager, when you generate a report for something, like number of CPUs per server, at the very bottom of the report is a link that says “Show SQL query used to generate this report”.
A feature like that added to OpsMgr reporting would go a long long way to allowing us to generate custom reports.
Why?
Well, the SQL schema for OpsMgr is not, and never will be, given out. It’s like that because once they’ve shared a schema, then they are more or less stuck with it and it makes adding, removing, or making more efficient sql much more difficult. So they just don’t share it. They didn’t in MOM2005 either, but it was significantly easier to figure things out there, since we had the one MOM database, and all of the warehousing data was pulled from that one via DTS packages, so the whole thing functioned easier. With OpsMgr 2007, data is written to the OpsMgr database and the reporting database concurrently, and they are more less independent of each other. Because of that a lot of the tables and such are a lot more confusing and a lot more happens behind the scene. So adding something simple like “Show me the SQL used to generate this query” would open up a whole new world to us.
Let’s face it. For the vast majority of us, we’re either System Administrators that handle day to day duties as well as the OpsMgr infrastructure, or we’re full time OpsMgr Admins. We’re IT renaissance men, Jacks (and Jills) of all trades. We know a little bit about all of the applications, operating systems, hardware, etc of our company, but we’re not an expert in one thing. Since OpsMgr uses SQL Reporting Services to issue up reports, that means we need either:
What I normally run across is:
But, if we had a way of looking at the SQL queries a particular report uses to pull up it’s information, we’d be able to bang something together. Jonathon Hambrook showed us how to create the report model and get started. Kevin Holman shows us a different way, and also shows us a real world query to use.
While those are great starting points, I want more information. I want to create a report through the reporting tab – let’s say we want to look at the CPU usage over a 4 week period for all of the exchange servers. I then want to see exactly what SQL voodoo was run, and then re-create the report myself in the SQL BI suite, that way I can prepare something for a presentation, and make sure this report adheres to my companies style and branding guides. Just that one simple change would be the bridge that lets us go from “No idea” to “Hey, I have a great idea!”.
Hopefully I’ve got you fired up enough to rate my suggestion – if we get it high enough there’s a good chance it’ll be included! So open up suggestion #436472, and rate it! If you’ve never been to MS Connect before, login to the site and subscribe to the OpsMgr connection, #446. Then you’ll be able to click on the suggestion above to go directly to it. In the mean time, I’m trying to figure out how to pull up this info via ‘other means’.
Until next time!
Yes, it’s true. You can have fun with Operations Manager. Right now I’m currently on the bench, and then probably unemployment soon since jobs are scarce, but it won’t be slowing me down ((If you need someone in the Twin Cities area, please shoot me an email – it’s my first name@my last name.net.)) In fact, I’ll be able to work on a lot of the wacky creative uses for OpsMgr – things like:
So I’m rebuilding my current SP1 environment and turning it into an R2 RC one. Then I’ll start adding wacky monitors. And I’ll create a full management pack to do it, and you’ll learn step-by-step. It’ll be a fun time! So stay tuned, and you stay classy, San DIego!
Have you noticed that the command shell performance is lacking? Tab-completion can take over 15 minutes to complete, depending on how many servers you’re monitoring. I’m not 100% sure of the exact reasons behind it, but it seems that the auto-complete will first traverse the local path you’re in when it attempts to complete a command. And when you’re trying to do this from the monitoring:: provider, that means it will possibly look through tens of thousands of objects.
I thought that behavior was a little odd, because most other providers will attempt to auto-complete known cmdlets first THEN go through the local directory. So I went to MS Connect and logged a bug report, bug ID #436239.
And this morning I received a response from Cory Delamarter, the Senior Program Manager for Operations Manager. He wrote:
Jeremy – Thank you very much for reporting this. We’ve confirmed this behavior and we will defintely look into how we can improve this in future releases.
The feedback is much appreciated!
So hopefully we’ll get that fixed soon and it’ll be just as fast as all the other providers out there! There really isn’t a work-around for this, as most (If not all) of the OpsMgr commands need to be run from the monitoring:: provider, or else they will fail. So we’ll have to live with it for just awhile longer.
