Ok so in the last 48 hours I think I’ve fallen madly in love with PowerShell. My time is limited so I’ll make this short. Last night I wrote a script to copy files from one file share to another and log the process. Luckily PowerShell community guru Laerte Junior (Blog | Twitter) and Ron Dameron (Blog | Twitter) were online and willing to help me out (as always). I aksed him some general questions but was determined to write script on my own and just have him review it and point me in right direction. So after much Boogling I got some code example and spat this PowerShell turd out:
Basically it moves the files from one server to another and writes basic information of each file moved to a log file. The log file it writes to is dynamically named based on the date the script is ran. If the script bombs then it writes the errors to another log file the administrator can refer to for troubleshooting.
Next up this morning I saw an article on SQLServerCentral.com ‘s newsletter on how to Make a 100+ Server Inventory in 30 minutes. 30 minutes? Hell, with PowerShell I think I could knock that out even quicker! And so I have, try 5. First create a text file with a list of all your server names. I’m sure you could get that using PowerShell too but Boogle it. Next try this code out:
First off, welcome back class! So this week we’re talking about writing. As a DBA or a developer you are going to be asked at some point to perform a necessary evil called documentation. Why is this evil? Well, it’s not really evil but it is not one of the more glamorous parts of the job, yet it is one of the most essential. Good documentation is everything! Without documentation you can spend all the time in the world developing the greatest system on earth, utilizing some of the most complex and beautiful code ever written but when something eventually (and it will) break, you’re going to be expected to be the one to fix it.
“But I’m working on this really important production issue, I can’t stop everything just to troubleshoot a system I put into production 3 years ago and can’t remember half the things I put into it!” Ah, but if you had only documented it someone else could be supporting the system and you could be blissfully working on the here and now. When we talk about documentation, however, that word means different things to different people. Let’s go over some of the different aspects of documentation within a system and why they are important.
The other morning I was migrating an application from a desktop machine to server. Some real fun with this project includes zero documentation from the developer (he was a contractor who did a rush job and left). Thankfully I have experience migrating applications from dev to acceptance to prod so I knew to look for missing assemblies and whatnot.
My big headache this morning, and the source of this posting, was the missing Crystal Reports assemblies since this was developed in Visual Studio 2008. My first indication of a problem was that locally (on the server) I tried pulling up the page and got greeted with the following:
Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.
Parser Error Message: Could not load file or assembly ‘CrystalDecisions.CrystalReports.Engine, Version=10.5.3700.0, Culture=neutral, PublicKeyToken=692fbea5521e1304’ or one of its dependencies. The system cannot find the file specified.
After some quick Google searching I came across this post at Egghead Cafe with my solution. They provided me links to download the runtime I needed to install. For the sake of helping others I have decided to host the files as well just in case those links die from that link. After installing the runtime on the server I restarted IIS by issuing the iisreset /restart command from the command prompt. After the restart I was able to successfully pull up my page without a problem.
As a system administrator it’s your job to know the ins and outs of the systems you manage. But are you the only cog keeping that particular wheel turning? If you were to leave your current position, or God forbid, something were to happen to you would your company be able to move forward without you without ill effect? This is where proper documentation becomes a crucial part of your job.
Now some would argue that if you document your responsibilities/job/systems/etc you become dispensable. While yes that could be true I dare to say that you really shouldn’t have to worry about that. In my opinion if you’re doing your job, and doing a good job at it, those who matter will notice and this becomes a non-issue. Properly documenting your system if anything then becomes an aid to you to help you do your job better. Yesterday Jonathan Kehayias (Blog | Twitter) wrote a great article on the importance of good documentation. If you get a chance I highly suggest you give that a read since it brings up some great points that include turnover, management, and compliance auditing.
Currently I’m trying to get a handle on the documentation of my systems at work. At the moment my current thought is to create a Word document template that simply has fill-in-the-blank type fields and for every new system that comes online I simply fill out a new form. These forms will be kept in our Sharepoint site and that way those who need access to them (i.e. on-call personnel, Help Desk staff, other system admins, etc.) know where to find them. Of course one could argue the problem with this method is that people who don’t necessarily NEED to see everything in that documentation have access to it. To that I say this, why not? I may take a little flack for saying this but here goes nothing. I believe the world of IT has drastically changed in the last few years (duh). Granted I’m still young but from what I’ve witnessed we are coming from shops where mainframes were king and jobs and knowledge were extremely siloed. Now before you start blasting me on silos, I know they still exist but go with me on this.
In today’s IT world there are simply so many things flying at us at all times. With the rate of new technologies coming out and with organizations trying to do more with less in this economy I think its more important than ever to make knowledge transparent across the enterprise. If someone wants to know what I do as a DBA why not let them know? That person could be interested in jumping in the administration world themselves and just need the basic knowledge and understanding to do so. Another example would be explaining to a project manager the technical pieces of the project they’re managing. How many times have you seen a project dumped in your lap and the necessary components are things that you either A) Don’t support B) Have no in-house knowledge of the necessary technologies.
From my experience knowledge dissemination becomes all the more vital as systems become more tightly integrated. Look at the Microsoft suite of products. Sharepoint is a collaborative portal designed to let people across teams and enterprises share and disseminate (damn I love this word) knowledge with ease. Well in order to stand this product up you’ll need someone who understands databases and their management/administration, someone who understands architectures and how best to implement them, maybe a trainer to let end users understand how this new technology works, desktop personnel to understand the technology and how to troubleshoot it, etc, etc.
As I’m writing I’m realizing I’m really digressing from my original point which is about documentation methodologies. I’ve laid out my general plan for documentation of systems but my original intention of this post (besides my slight soapbox rant up there) was to see how the rest of you guys/gals handle your documentation. Strict methodology and templates? Random documents thrown out on a shared drive or somewhere on your drive? None? Let me hear from you in the comments.