In part II of my walk through on configuration management, I’m going to work on setting up Subversion (SVN). SVN is a version control system and, just like any version control system, is used to keep track of changes. The most common use is in a development environment with teams of developers so that everybody can work on the code, without having to worry about other people’s work. It’s obviously not limited there, it can be used as a form of backup, keeping a track of what you’ve changed, and when. This is how we’ll be using it for our configuration management.

I’ve been asked to write a post on configuration management, and version control by a friend, Steven Klassen. Instead of a single post, I’m going to break this into several posts as some parts might be unimportant to some, and they can easily skip a whole post. I’ll be posting this over a few days, so stay tuned. If you’re not subscribed to my RSS feed, now would be a great time.

The Nubby Admin has a great post on uptimes, and the old fascination of having a large uptime¹. Okay, you can get your minds out the gutter now, not that kind of up time. We’re talking servers here.

The post covers a hidden fear, and the goods and bads of large server uptimes. A good read, and one you should look at if you’re watching your server rolling over into the third year of being running. I get a mention (well more of a quote), and seem to fall in with the general crowd, large server uptimes are generally bad.

Go read, enjoy, learn something new from the great minds Wesley is surrounding himself with (myself excluded).

Since IIS6, or there abouts, IIS will not host a file that it does not understand, or doesn’t have a MIME handler for. This is a security feature, but can cause some unknown issues…

Bob Plankers of The Lone Sysadmin fame, has an excellent article titled Midnight is Always Tomorrow, which talks about communicating maintenance windows effectively with peers, as well as customers. He describes the confusion between the term of Midnight, and how some people consider it one day, whilst others see it as a different day.

Midnight is 00:00, meaning the start of a new day. Always.

If you’re in doubt, use 00:01. Assume everybody is clueless about time, because they are. For example, a lot of people think in terms of when they go to sleep, not what actual time it is, so if they’re still up at 0200 on Sunday they consider it to be Saturday.

He timed it well, I was thinking of posting about this very subject myself after a similar incident last week. After our QA team had cleared a break-fix release, it was scheduled for that fateful time, on Midnight on Friday. This was discussed at length by several people on Monday. After several meetings, I hear somebody walking past, telling the business units on Wednesday…

Yes, it’ll be released tonight, and ready for tomorrow.

“Tonight” would have been Wednesday night, tomorrow would have been Thursday. Somehow the magical shift of midnight pushed the release forward a day. Fortunately we interjected, and had them corrected.

This isn’t the only incident that is like this, we see it frequently when something gets requested for that time. I cannot begin to count the number of times I’ve had somebody ask me “is the release tonight at 2am?”. This goes into the idea that people consider “tonight” to be anytime before they went to sleep.

Going with Bob’s suggestion, use dates, and 24 hour clocks, if necessary (and always recommended) shift the time by a few minutes to make it obvious which date midnight falls on. Notify customers, tell them the outage/maintenance/changes are at 00:05 on 06/15/2010 (if you work with international customers, use words instead of numbers).

Bob finishes on a perfect example…

“The system shutdowns will commence at 2200 on 4/17/2010, the power will be disconnected at 0000 on 4/18/2010, and power-ups will occur again at 0800 on 4/18/2010. All times are in CDT (-0500).”

Be clear. Be concise. Be exact. Remove as much ambiguity as you can. The customers will be happy for it.

Whilst sitting here on a product release call, I was reading over my twitter feed, specifically looking at #powershell, and I saw a post by @tonjoh. Feeling I had a few minutes on my hands whilst QA bashed away at the servers, I decided to take a look…

Whilst working away this morning, I received a very pitiful look. It’s that look that we all know. The “I did something terribly wrong” kind of look. This look came with the hands of a digital camera, a small compact point and shoot. A story followed the look, as the camera was handed over to me…

Part of our application at work sends email notifications to various uses when certain criteria are met. This is great, except testing is difficult as you really don’t want to send out mails to valid customers, so we disable relaying outbound, and the local mail server just chomps on it a bit, then decides to not deliver it and drops it to the local file system. This is great, except in a the matter of days, we have 100k message files. This becomes entirely unmanageable with Windows, so PowerShell is here to help…

From time to time, I have to share screen shots, it’s a common task for some, especially when showing errors and the likes. This is usually fine because it can be emailed, or saved as an image file for attaching to a bug ticket. I’ve started sharing some screen shots online, which now requires a few more steps, and becomes quite time consuming, screen shot, save image, upload to some site. This is where jing came in…

A feature I’ve long awaited in Microsoft SQL (TSQL) has been a function similar to MySQL’s REPLACE function. For those that haven’t used it, the REPLACE function allows you to do an insert of a new record, or replace an existing record¹ if one matches the primary key. In SQL 2008, Microsoft introduced a function called MERGE. This is like REPLACE, but a whole bunch of extra goodies…