Use PowerShell
Real Admins Script
Systems Administration
Dear Devs, Give Us The Tools. K Thx
Jul 6th
I just finished listening to the latest Herding Code podcast (#52) where the hosts (K. Scott Allen, Kevin Dente, Scott Koon, and Jon Galloway) talked with Alan Stevens ( C# MVP and ASP Insider) and G. Andrew Duthie (author and Microsoft Developer Evangelist) about a debate that began on Twitter regarding “Real Software Development vs Microsoft Bubble Development”.
What does that have to do with PowerShell and administrative tools? The specifics of their conversation don’t have a lot of relevance to administrators and scripters, but one of the directions that their conversation took really resonated with me.
Alan throws the first punch – He likes Herding Code because it’s about real software development rather than development in the Microsoft bubble. It’s about the tool users rather than the tool builders and it’s about honest feedback.
As administrators, we need to make sure the developers of the applications that we use and administer provide us the tools we need to efficiently run our networks. Microsoft has gotten the message loud and clear. Windows 7, Server 2008 R2, and TechEd 2009 LA confirmed that. There weren’t many sessions where you didn’t hear something about PowerShell and there aren’t many products where PowerShell isn’t making inroads into the management structure.
Kudos to Jeffrey Snover and the awesome management technologies team for really selling this internally at Microsoft.
Another point made on the podcast was that Microsoft needed to do more to encourage better development practices… Can those same developers say that their products encourage better application management practices?
Now, we as the users of PowerShell need to step up and convince demand better administrative tooling from our vendors and internal development staffs. Companies like Quest, VMWare, Idera, Compellent, and others have gotten the message, but there are still many, many other products out there and many internal applications that suffer from inflexibility.
Web interfaces and GUI tools are nice and can be considered the icing on the cake. A true manageable application allows for consistent and repeatable actions in an easy to maintain structure, as well as providing flexibility to integrate other potential solutions. PowerShell provides a lot of that right in the box and allows administrators to bridge the gap and create their own solutions that might not have been supported yet (ever hear – “it’s in the next version”).
So, here is the call to action:
Rise up and demand proper administrative interfaces.
Talk to your managers about the benefits of streamlined application management using a consistent interface across multiple platforms and applications.
Take a developer to lunch and explain how you want to help make using his product a better experience from the application management side.
Let’s take our cue from the oft repeated concept in that Herding Code podcast – there is a need for candid feedback and it is all about the tools that we have to live in and work with every day.
If by chance one of the guys from the Herding Code podcast (or any other developer-centric podcast like .NET Rocks, Deep Fried Bytes, or StackOverflow) happens onto this post and wants to talk further, I’m available. There are also a good number of PowerShell MVPs and community bloggers who I’m sure would love to provide some “candid feedback” to “developers in the trenches doing real development”.
Response: Give Me A Coconut and Six Months
Jun 5th
I was tagged by SQL Server Expert Brent Ozar in his response to a great, thought provoking blog post called Give Me a Coconut and Six Months by Tim Ford (SQLAgentMan on Twitter).
The short summary of the post is if you had six months free of distraction, what would you turn your attention to. Tim’s choices included backups, security, and monitoring, which I think is a great “solid foundation” to work from.
Brent posits that if he became more effective at data mining, he would be able to provide a business with critical insight with which to improve sales, product focus, and develop key personnel.
If I had more time (and skills), I could tell executives things like:
- These are the top five customers who are about to leave us.
- These are the top five products that are about to go viral, and we need to stock more ASAP.
- These are the top five salespeople who need coaching to produce more revenue.
Walk into an executive’s office with this kind of information, and you’re a hero.
Here’s the shocker Brent… I agree.
I agree that delivering that kind of data to management is the Holy Grail of IT projects. Before coming into the IT realm, I ran a small business and I would have killed for information along those lines.
One thing I think is missing from Brent’s discussion is that there are three parts to this type of data mining:
- The first part is the technical aspect on how to retrieve the data from databases and other sources of information, which Brent probably has handily covered.
- The second part is not a technical question at all. The second part of the data mining is actually coming up with questions you have for your data. The quote above from Brent’s post highlights those, and point to an area of expertise outside the technical. Brent is demonstrating (and probably should have said explicitly) that a domain/business knowledge is very important in determining these requests. This is often difficult for the stereotypical IT person, but is essential if you are interested in moving your career past a technical implementer.
- So, it appears Brent’s real goal is the the third part of this process, which is translating these questions (taking the business knowledge) and retrieving and correlating the data (using his technical skills) that he will need to make these determinations.
Brent continues on to cover a common area of disagreement between us.
I kick the PowerShell horse a lot, and here it comes again. If you’re in IT, listen up: you’re either cutting costs, or making money. Guess which one has more upside. If you truly bust your hump, become an amazing scripting deity, and save 99% of your time, you just saved 99% of your salary. If you’re really good, you might save 10 people 99% of their time.
I work as the sole admin/accidental DBA/desktop support/multimedia support/”if it has a blinking LED light” support for an agency that collects lots and lots of data. As a scripting practitioner, if I save myself 25%, 40%, or even 60% of my time not having to solve the same problems over and over, I’m free to plume the mysteries of my database and convert the bits stored their into meaningful data and even information that is usable and actionable.
Not every environment has the luxury of being able to afford someone of Brent’s caliber to come in and learn their business and help them develop methods of turning their data into knowledge. In my situation and that of many small to medium businesses, scripting is the tool that enables the IT generalist to explore and branch out into these other areas.
Brent may feel ” you can go into data mining and make 100 salespeople twice as effective” and that IT people who keep things running are replaceable and he may be right, but I believe, especially in tighter economic times, specialists become a luxury that only a few can afford where efficient generalists that know the business become more in demand.
Don’t be mad Brent… it’s okay to be wrong every once in a while! 
So if I had six months of no interruptions and could focus on certain specific projects, I would:
- Finish automating (via PowerShell, SQL, or other means) common tasks
- Develop the questions my administrators (not technical admins, but departmental administrators) would like to ask our data sources
- Build tools to answer those questions via reports, graphs, network maps, or other data visualization techniques (like the cool stuff Doug Finke and Chad Miller have been doing)
I personally think that EVERY technical person should have a grasp on the basic business environment, be aware of what is happening in their company’s industry (or at least their department’s industry for larger organizations), and begin to develop more in depth domain knowledge as to the business processes.
Due to the odd path I took to becoming an IT person, I’ve actually accumulated quite a bit of domain knowledge about the law enforcement, the various jobs, information requirements, and the ins and outs of our workflows and data. This background gives me a great starting place when going to look at my data, since scripting has given me the time to do so.
Judging from the pattern in Tim’s and Brent’s posts, I’m supposed to tag a few people..
How about:
- Doug Finke (developer, data visualization explorer, and PowerShell MVP),
- Hal Rottenberg (administrator, VMWare vExpert, podcaster, and PowerShell MVP),
- and Wes Stahler (administrator, blogger, and PowerShell enthusiast)
Comparing Database Schemas
Feb 12th
I regularly am working with several versions of a database for an application that I manage (a live database, training database, test database, and previous version database). Occasionally, I need to know what the differences between the databases are, especially after our vendor updates my test environment or right after an update in my training or live environment.
Since I spend a good portion of my day in PowerShell, I wrapped some system table queries in a PowerShell script and use Compare-Object to find any differences in the tables and compare the column definitions as well. The queries targets only user tables.
Compare-DatabaseSchema.ps1 takes several parameters.
- SqlServerOne – SQL Server for the first database
- FirstDatabase – Name of the first database for the comparison
- SqlUsernameOne – SQL user name for the first database
- SqlPasswordOne – SQL password for the first database
- SqlServerTwo – SQL Server for the second database
- SecondDatabase – Name of the second database for comparison
- SqlUsernameTwo – SQL user name for the second database
- SqlPasswordTwo – SQL password for the second database
- FilePrefix – Prefix for the log file name
- Log – Switch parameter that saves one CSV file with the difference in the tables. If the Column switch parameter is chosen also, it will save one CSV file per table with differences in the columns
- Column – Switch parametr that enables a comparison of the columns in the tables that match. Columns are compared by name and datatype.
I still have to add some checks for the various constraints, but that will come later.
You can find the script on PoShCode.org.
Dealing with WMI Timeouts
Jan 26th
There was a question in the PowerShellCommunity.Org forums about WMI timeouts.
I did some digging and found there are several different types of timeouts that can affect your WMI queries. I’m still working through different scenarios and I’d appreciate any feedback.
The first type of timeout can occur if the machine that you are targeting does not respond to network traffic (it’s down, you have the wrong IP address, firewalled, etc..). Your WMI call will usually time out after around 20 seconds.
A partial solution to that type of timeout is to ping the machine first. If you can ping that machine, you’ve eliminated a number of potential problems. You still might have permission issues or firewall issues, but you are able to reach the machine.
The second time of timeout I’ve seen is when the connection is made, but the WMI call hangs and does not return.
A potential fix for this issue is to use the [WMISearcher] accelerator. In the options property of the resulting object, there is a ReturnImmediately property, which should be set by default to true.
$searcher = [WMISearcher]”
$searcher.Options.ReturnImmediately
The ReturnImmediately property being set to true requires that the invoked operation (the search) be done synchronously and return immediately. The enumeration of the results of the WMI call are handled after the return of this operation.
An alternative solution for this issue would be to check the Transaction timeout setting on the target machine. Run DCOMCnfg.exe and navigate to the Component Services->My Computer. Right click and choose properties. On the options tab, there is a timeout (in seconds) for DCOM transactions. The default value for this setting is 60 seconds. Fiddle with that at your own risk. Also, I haven’t had a chance to check for where that value is in the registry or see if there is a Group Policy setting for it. Setting this value should allow a failed WMI connection to timeout more quickly.
The third area in which I’ve found timeouts/hangs in WMI queries is during the enumeration of the query results. There is a property in options for the WMI class accelerator called Timeout, which sets the length of time between enumerations before timing out. The options property is hidden in the default view of PowerShell, so you will need to access it via the psbase property.
The timeout value is a System.TimeSpan object. You can specify the value with a TimeSpan object, a number of ticks, or a string that can be cast to a TimeSpan.
It can be set like this:
$wmi = [wmi]”
$wmi.psbase.options.timeout =’0:0:2′ #String that will be cast to a two second TimeSpan
You can also set a timeout value for the [WMISearcher] accelerator.
$searcher = [WMISearcher]”
$searcher.Options.timeout = ‘0:0:2′
WMI timeouts can be aggravating, hopefully one of these solutions will help mitigate your WMI woes.
