General discussion


Notes from an Always On tech

By timbstoke ·
Tags: Off Topic
blog root

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

Batch Files: Comparing a file to a backup copy before overwriting it

by timbstoke In reply to Notes from an Always On t ...

This is a batch file I actually wrote for our Mailsweeper servers.
Although the customer services dept in our company operates 24/7, some
of the multilingual staff only work during the day. Therefore, we have
some mailsweeper scripts that basically send an 'out-of-office' to our
non-english speaking customers in response to any mails they send
overnight. That means we need to turn these scripts on every night, and
turn them off again every morning. This is somewhat tedious, so I put
this together to do the job for me. A slight caveat is that we fairly
regularly change this config, so it's quite essential that we don't
break anything else when we run this script. Here's what I did<br />
<br />
<p>I took two backup copies of the config file - one with the rules
enabled, and one with them disabled. This is for two reasons - firstly,
it makes changing the config a simple file copy operation; secondly,
and more importantly, it gives us a sanity check, and allows us to
abort if all is not as it should be. See below:</p>
<p>copy /Y "\\msw01p\C$\Program Files\MAILsweeper for SMTP\Config\Shared\scenarios.cfg" H:\Batch\backup.cfg<br />
FC H:\Batch\lhrbackup.cfg H:\Batch\lhrrulesoff.scenario | FIND "FC: no dif" > nul<br />
IF ERRORLEVEL 1 goto :files_are_different<br />
copy /Y H:\Batch\ruleson.scenario "\\msw01p\C$\Program Files\MAILsweeper for SMTP\Config\Shared\scenarios.cfg" <br />
h:\pstools\psexec \\lhrmsw01p net stop "Mailsweeper for SMTP Security Service"<br />
h:\pstools\psexec \\lhrmsw01p net start "Mailsweeper for SMTP Security Service" </p>

:files_are_different<br />
Echo Unable to continue. Configuration file on the server has changed.<br />
echo Turn On rules manually, and backup correct config to h:\Batch\ruleson.scenario<br />
goto :end</p>

:end<br />

<p>The first line is obvious: Take an offline copy of the existing scenario. Secondly, we compare that offline copy to our known good <em>rulesoff </em>configuration
file. If the files are different, we return an error without making any
changes. If they are the same, we then proceed to overwrite the
existing file with our <em>ruleson </em>configuration file. Since the only difference between <em>rulesoff </em>and <em>ruleson </em>is
the changes we want to make, we know we're safe to continue only if the
current configuration matches one of these configuration. If there are
any other differences, then someone has changed the config, and we need
to update our backup copy. Maybe one day I'll automate this too, but at
the moment it's overkill for what I need. </p>
<br />

<br />

Collapse -

Don't overlook the simple approach

by timbstoke In reply to Notes from an Always On t ...

Until recently, our department was fairly small. Due to natural growth
of the business, we've grown from a team of 7 or so, with 2-3 people
working at a time, to about 15, with up to 6 people working at a time.
We've also split from just being the IT Dept to a department with
seperate first/second line areas. This has brought with it's own
problems. Some of
these were expected and anticipated - permissions, organisational
structure, and various other obvious pitfalls. <br />
<br />
One that wasn't anticipated was information flow throughout the
department. We needed a way of tracking, for example, any purchase
orders due to arrive, any warranty returns due to take place, and
ongoing high priority problems. This solution had to be easily
accessible by everyone in the team, so that anyone can leap into action
with all the speed and agility of a slightly overweight ninja the
moment reception call to say that FedEx are waiting to collect a
package. <br />
<br />
We looked at various solutions. Sharepoint was one option. It had
promise and did everything we needed, with one problem: Initially, at
least, it would only be used to fulfil this one requirement. That means
that no one would use it until that requirement presented itself,
meaning when reception called, we had to fire up a browser, navigate to
the SPS homepage, and hope that whoever was responsible had remembered
to add the details. No good. <br />
<br />
Email was another option. We use email for everything, and Outlook is
constantly open. A d-list is already set up for everyone in the team,
and it works OK for most things. The opposite problem presents itself
here: Too Much Information. I currently have 436 emails flagged for
follow up. If there's a collection that won't be made for a day or two,
by the time the van arrives, I've received another 250 emails, and the
email that came around has been forgotten all about <br />
<br />
Our helpdesk system was the third option. Like Outlook, everyone has
visibility, and it's running all day. Also, most issues get resolved
quickly enough that a ticket a day or two old won't slip out of view. A
good solution, with two downfalls: First, should management ever want
to pull off stats on our helpdesk (increasingly likely in a growing
company), these stats will be skewed by non-issues such as collections
and deliveries. Secondly, and more importantly, the helpdesk assigns
tickets to a person. One Person. If that person is away from their desk
when the collection van arrives, no one is going to check through
everyone elses tickets to see what needs to be picked up. <br />
<br />
The system we ended up going with? A whiteboard. Not a fancy flash
whiteboard on a plasma screen. Not an interactive whiteboard that you
can draw on from a monitor and print out. Just a basic, standard
whiteboard, split into sections for Today, Tomorrow and Ongoing issues.
Our search for a technological approach failed on some point or other
with every single system we tried, but this meets the lot. It can be
seen at a glance - we don't even need to Alt-Tab. Management get an
immediate overview of what's going on, without affecting any stats they
need to pull. Everyone has access to it. It takes seconds to update. It
never, ever crashes. <br />
<br />
The moral - when evaluating requirements, don't assume that the
thousands of dollars of technology you have at your fingertips is
necessarily going to be the best solution. Take a step back, and look
at exactly what you need. It may just be that when someone wants a
'virtual widget', a real-life widget will do the job easier, faster and
cheaper. <br />

Related Discussions

Related Forums