Shoretel Panic Buttons

The safety guy called me and asked about panic buttons for the personnel at the front desk last week.  After listening for several minutes describing how they “used to do it” using lights, buzzers, SCADA, and pagers they finally asked me for input.  “I can configure a button on their phones to alert a group of people.”  I’ve done this in the past with Mitel systems; it can’t be that hard to do the same thing with Shoretel.

I figured that if I setup a shared call appearance on a key to all those users designated to respond to panic calls, all I would need to do is setup a speed dial for the panic button.

Bridged Call Appearance

First, I configured a BCA.  Logging into Shoreware Director, click on Call Control –> Bridged Call Appearances.  I named the BCA “Emergency” and assigned it an extension:


Configure Panic Responder Phones

After setting up the BCA, I started mapping each responders’ button on their respective phones.  Clicking on Users –> Individual Users and selecting the user –> Personal Options –> Program IP Phone Buttons, I configured the following screen for each user:


I put an ‘SOS’ label so that it would show on their phone’s display.

Configure Panic Button Phones

For the people needing panic buttons, I simply programmed a speed dial on an IP Phone Button:


Notify The Users

From: Ian Fleming
Sent: Wednesday, February 06, 2013 8:56 AM
To: People who need to know
Cc: IT Department
Subject: Panic Button

Panic buttons have been configured at the Lakeside office.

You have been designated as a responder.

When the ‘SOS’ button illuminates and rings your phone, the display will read:

For 184



If you see this on your phone, Gracie pressed her panic button.

Extraction of 401(k) Share Prices

2013 is upon us; HR says it’s time to look at my cooperative retirement account.  I get quarterly statements informing me of my investment performance along with the share price of each investment.  This is a good, generalized summary for a retirement account such as a 401(k).













































Looking at this report, I can see that I am on-track and everything is performing to my annual expectations.  Lucky for me, I didn’t hold any of the poorly performing funds. But what if I did?  Should I move my investments contributions around or re-allocate?  I need more information than just what is on my most recent quarterly report.  It is conceivable that a “poor” fund is showing signs of turning around if I could get more detail.  What’s the share price… today, yesterday, or a year ago?

On to…

Clicking on My Retirement, 410(k) Investment Details, Investment Information, I can view today’s and historical share prices by entering a date and pressing the Find button.  This is a good start.  After fooling around with the interface, I couldn’t find a way to download all the daily prices. I would like to see a trend chart for each fund.


Instead of beginning the tedious effort in copying and pasting dates and share prices into Excel, I turned tothe iMacros data extractor to do all the heavy lifting for me.  The process is as follows:

FOR X=1 to 360

Input todays date – X
Press find
Extract the current share prices listed on the screen
Append extracted to a CSV file


This gave me a file of everything I’m looking for saved as c:\SHARES.csv

'While logged into, start this macro on this URL GOTO=
TAG POS=1 TYPE=INPUT:TEXT FORM=NAME:GetPrices ATTR=ID:FPriceDate CONTENT=EVAL("var today = new Date(); var tomorrow = new Date(); tomorrow.setDate(today.getDate() - {{!LOOP}}); var day = tomorrow.getDate().toString(); if (day.length < 2) {day = \"0\" + day;} var month = (tomorrow.getMonth() + 1).toString(); if (month.length < 2) {month = \"0\" + month;} var year = tomorrow.getFullYear().toString(); var dateString = month + \"/\" + day + \"/\" + year; dateString;")

(Note: Copy the above code and paste into notepad or iMacros to view the code in its entirety)

Run this by pressing Play (Loop) with 365 set as the Max parameter.  You can set the Max to a higher value if you need more historical share price data.


Next, I imported the CSV into Excel and turned to the fancy pivot chart for some date-driven analysis:


For those that just want the share prices, here they are.  It’s not like they are top secret and we all shouldn’t have to run the script to peg out’s web server:

Read the rest of this entry »

SEL 2505 Remote IO Module – no flash photography!

A strange investigation of a remote IO module exposed to a flash from digital cameras…

SEL-2505 camera flash testing

There’s not an app for that yet!?

If a man believes and expects great things of himself, it makes no difference what gadget he puts in his pocket or which gadget you show him. He will be surrounded by magnificence. He is in the condition of a healthy and hungry man, who says to himself, “How sweet this crust is!”

Conversely, if a man believes and expects that an app should take care of him, it makes no difference where you put him or what you show him. He will be surrounded by pity, ignorance, self-doubt, and dependency. He is in the condition of a weak and pathetic man, who says to himself, “Who made this for me? This app tastes bitter!”

VoIP Call Recording with Remote Port Mirroring

  The following are only my opinions and should not be taken as gospel from the Book of Alexander Graham Bell. Without getting into the business, philosophical, risk management, or business management reasons for recording calls, I’ll simply address the issues that I focus on when accomplishing this technical task.

It can be said that all call recording systems accomplish the same thing: they record calls.  Like all phone systems, they accomplish a similar end-result using very similar methods.  They all have a way of ‘tapping’ into the phone line (virtual or physical), indexing the call record, storage and/or archiving the call, and offer some sort of a playback/reporting interface.  In my opinion, the only significant difference between one call recording solution over another is the touch-and-feel of the interface or the method(s) in which a line can be tapped.

There are two common interface locations that an installer will place a recorder: Trunk or Station.

With a Trunk recorder, all in/outbound lines that come in from the phone company are recorded.  This is accomplished by tapping in (bridging) where the PRI, T-1, or POTS lines come into the PBX.

The pros to this interface:

– All customer/external calls will be recorded
– Very little configuration
– Call indexing is simplified
– Easy to understand
– Easy to troubleshoot

The cons to tapping at this interface:

– Internal calls (extension to extension in the same PBX) will not be recorded
– Recordings are not easily bypassed should a call not need be recorded
– Usually trunk recorders are expensive (depending on the physical interface used for the tap)

With a Station recording solution, calls are recorded per station (extension).  You simply specify which stations you want to record.

The pros to tapping into the station:

– Only the stations that are required to be recorded are
– Internal and external calls are recorded
– Station recording solutions are common on many modern voicemail systems (you already have an option to record to voicemail on your Mitel 3300, it needs to purchased and configured per station in the COS form)

The cons:

– Confusing and sometimes complex configuration when compared to any trunk tap
– High potential for duplicate recordings and information overload (one recorded ext calls another recorded ext = 2 recordings)
– Difficult to troubleshoot

I am going to focus on station based recording solutions.  Trunk based recorders are really easy to setup; although they have a few drawbacks, they are well known and easy to understand for both the installer and the users of the system.  Station recording systems have a potential for confusion due to a lack of perspective. For instance, after researching for a recording on a station that isn’t being recorded, the user will scream, “So, you’re telling me that we spent all that money on that system and it didn’t even record my important call?!”  Another task I’m going to focus on is recording VoIP (virtual taps) as opposed to traditional phones (physical taps).

In configuring a station based recording system, your network must be capable of mirroring ports.  A port “mirror” is a feature that most managed Ethernet switches are capable of.  I have a bunch of HP Procurve switches on my network.  Each station that I want to record must be identified at the physical port on my switch and traffic must be mirrored (virtually tapped) to the recording Ethernet port.  This is accomplished with the following commands on an HP procurve switch:

# This is the port to be recorded

interface C17
name “Mediatrix”

# this line assigns port C17 to mirror one, monitor all traffic (in- and out-bound)

monitor all both mirror 1 no-tag-added

# This is the port doing the recording

vlan 101
name “Sniffers”
untagged B1
no ip address

# this sets up the mirror instance on the switch

mirror 1 port B1

I put the monitor port in its own VLAN called Sniffers to only allow traffic-to-be-monitored on the VLAN segment.  While this it isn’t completely necessary, it does prevent the recorder interface from being overloaded with a bunch of traffic not applicable to call recording.

So now I can plug my vendor’s recorder in on port B1 of my switch and it will start recording SIP based VoIP traffic auto-magically.  My vendor will now take my money and go spend it on that F150 he’s been eyeing – yeah… that’s right. That nice one with the vanity mirror.

There are some caveats that you should be aware of:  If you want to record VoIP and DTMF signaling, be sure to read up on RFC 2833.  You might have to call your vendor to make necessary changes to your equipment so you can actually hear the DTMF digits dialed in your recording.  Many SIP implementations decode and send DTMF digits out-of-band using RTP so all you’ll hear is a bunch of button clicking noises instead of the expected DTMF.  It also messes up IVRs – which is what I record exclusively.

Be sure you turn off encryption on your PBX.  It sounds pretty funny when the recordings are encrypted…

So, now we have a system recording calls and we need to retrieve the recordings. Indexing is where many people have issues with their recording systems.  Some systems don’t index anything but a date/timestamp of when the recording took place.  Others record the extension, IP address, MAC address, SIP offer/invitation header, dialed number, whether the call was in or outbound, and all sort of nifty information.  In my opinion, you should address each of these index criteria based on your requirements.  It is not common that a vendor will set all of these up for you; all they will care about is whether the call is being recorded and walk away leaving you to figure out how to find the calls you are looking for in your new digital file cabinet.

As mentioned in my previous post, I simply use the date/timestamp to research and retrieve my recordings.  Why do I do this?  Because a timestamp is an inherent index that comes with -every- call recording system, it is cheap and only requires synchronization of a couple of system clocks; synching clocks is something that should be done anyway.  Also, before even considering a call recording system, the business should already be recording the call records.  Call records are usually called SMDR or CDR and should be indexed in an easily accessible database with a nice research interface.  The users should already be familiar with this record system and have one installed before they even try recording calls anyway; it’s a “walk before you run” thing, again, in my opinion.

I get a lot more useful information looking at CDR in a comparable timeframe than I ever do listening to recordings anyway; plus, CDR gives me traffic reports and other useful info that I can never get when listening to call recordings.

The major drawback of using date-timestamp retrieval/indexing method is that it requires extra mouse clicks.  I have to research calls on the SMDR, get the times and date of those interesting calls, and then cross-reference those calls with the date-timestamps of the recordings.  While it isn’t as integrated as a system with all the extra fields attached to the recording, it has worked very well for me in the past and present.  Another drawback is if a recorded-caller answers a call, transfers the call to another station that isn’t being recorded, and then the call is transferred back to another recorded-caller, the SMDR or CDR might not account for the timestamp of the transfer. This scenario will require additional research in retrieving the call recording (a lot of hunt and peck and cross-referencing).  I’m sure that there are other hypothetical’s that I haven’t thought of yet but I’m not positive that a fancy call-indexer could also address every one of the those either.

Playback is usually WMP on a web interface.  This is pretty standard.  There are bells and whistles available to mark a call, color it a different shade of grey, or download it – like the vanity mirror in my vendor’s new F150 pickup truck, these are all selling points that I might be enticed to focus on… or not.  Again, one might not like the taste of one system over another. Either way, they all pretty much do the same thing.

The following commercial call recording systems I have installed in the past:  ASC, TeleRex, and Onvisource.  I’ve used the following freebies: Wireshark, Ethereal, (yes – the Ethernet sniffers can record calls too!) and Oreka.

I use Oreka now because it is easy to setup, it has a nifty web interface and, more importantly, it is free.  While it doesn’t do a lot of fancy stuff, it gets the job done and the price is right.  The amount of time I spent on configuring it was well worth it compared to the $60k price tag of the ASC.

I’m sure there are a lot of opinions and input on these types of systems out there – take this as just another opinion from a guy named “ian”.

Quality can only be engineered into a product. So either way you choose to go, make sure you understand and design around valid business requirements before you start kicking the tires on a call recording system (or any system you choose to install at your cooperative for that matter)!

Hope this helps…


Remote Port Mirroring and intelligent mirroring for Oreka (or other tasks)

In the past I configured a lot of physical port mirroring.  It was most useful when configuring call recording for VoIP systems but it can be used for other tasks – like sniffing out a network problem.  It’s easy to configure for call recording because usually there is one call control system or media gateway such as a Mitel or Shoretel system that you have to monitor.  Configuring for this task was simple: make a list of ports that you want to monitor, configure a mirror port, and put the sniffer on that port.

Conventional port mirroring is possible on just about all modern switches now days.  The limitation of traditional port mirroring is that it’s limited to traffic local to the switch that it’s configured on.  In order to replicate a traffic flow from a non-local switch port, the mirror port must be on the trunk that connects to another switch. This means that the packet capture has to do all the filtering.  On a trunk port that is running gigabit speeds, this makes the equipment work a lot harder than it really needs to.  So, to keep the traffic down on the several switches in your campus LAN, you’ll need a network analyzer and port mirror on each one of your switches.

Before I only recorded IVR traffic.  The IVR system health falls solely into the Information Technology department and should be something that we maintain quality control of.  I view each automation port as an individual employee which must be managed accordingly.  Just because they show up to work on time, answer/service more calls than any single employee in the company, and work correctly 99.9% of the time, when there are problems, I am the one accountable.

I had a problem last weekend. The media gateway decided to take a break for about 30 hours.  Now, I configured for this contingency: interflow forward to the dispatcher on duty if an IVR port rings for more than 4 times.  This weekend, the dispatcher was unaware of a technical issue and just answered the calls.  Unfortunately, there was no alarm for this glitch.  Reviewing the logs, it appeared that the SIP gateway decided not to answer calls for 30 hours.  We are now assuming that the gateway reset itself because calls started coming back in with no problems.

I want to record the dispatcher.  It would also be nice to record other phones on the fly without having to mirror physical ports all throughout our campus.  So, I decided to rebuild my Oreka setup to run under Windows XP x32 running on a virtual machine and monitor only certain traffic from specific VoIP MAC addresses.

Configuring remote mirroring on HP Procurve

I use Procurve switches in my campus LAN.  I found that they allow me to redirect specific data flows to a different physical destination switch.  This will allow my Oreka VoIP recording VM to physically reside in the datacenter even though the monitored traffic is on a physically different port.

At a high-level, my goals are simple:  mirror all traffic to and from interesting MAC addresses from a remote switch (PhoneRM to the switch port that my Oreka VM is connected to (CPUrmHP  Interesting MAC addresses are things that I identify such as the dispatcher’s ShoreTel phone and the Mediatrix media gateway that services the NISC analog IVR.  The port doing the monitoring must be a physical port.  So, I’ll need a free port to act as the mirror on my switch.  I saw that port C9 in the computer room was open.  This will be my “destination” mirror port.

Configure Destination switch

Personally, I prefer configuring all of my switches from the command line interface.  It gives me a more global view of what is happening on my switch rather than navigating through menus and tabs on a web interface. In order for me to configure the remote mirror port, I ran the following command in global config mode:

CPUrmHP(config)# mirror endpoint ip 20302 port C9

What this command does is setup a mirror port endpoint.  On this switch I set up a service to expect traffic from the remote switch on UDP port 20302 which will be mirrored on port C9.  I must set this switch up first before the remote switch is configured otherwise the remote switch would have nowhere to send the mirrored traffic to.  The command syntax is:

CPUrmHP(config)# mirror endpoint ip <src-ip-add> <srv-udp-port> <dst-ip-add> port <port#>

The command syntax was a little confusing to me because the destination IP address is the same switch that you are typing the command in –the destination switch.

Configure mirror on remote switch(es)

I logged into my PhoneRM switch and entered the following command in global config mode:

PhoneRM(config)# mirror 1 name “VoIP traffic” remote ip 20302

What this command does is setup a mirror process that forwards interesting traffic to the destination port (C9) in the computer room.  If you have multiple switches that you need to mirror traffic to, all that is required is that the switches have IP connectivity to each other.  Use this command on other switches to mirror traffic to your central monitoring location.  The command syntax is:

PhoneRM(config)# mirror <1-4> [name <name>] remote ip <src-ip-add> <src-udp-port> <dst-ip-add>

Configure interesting traffic on remote switches

Now that the mirror process is setup to forward traffic to the destination switch port C9, we can define interesting traffic to monitor.  There are two ways that this can be done: by MAC address or by physical port.  If you have a device that occupies a port on your remote switch and you want to see all of the traffic on that port, you should mirror the port.  If you are interested in traffic coming to and from a MAC address, you should mirror based on the MAC address.  For the purposes of VoIP call recording, I chose to mirror traffic to and from a MAC address.  It seemed to be the easiest because I don’t have to find out which port each phone is plugged into.  Also, I can just input the same monitor command in my switches should the phone move from switch to switch (if the VoIP phone is a wireless device, for example).

I configured interesting traffic coming from my VoIP devices MAC addresses using the following command in global config mode:

PhoneRM(config)# monitor mac 00014900eeffee both mirror 1

monitor mac MAC-ADDR < | src |dst|both > mirror <1-4 | NAME-STR>

To monitor a port, you’ll use the interface command and specify what traffic you want to monitor, traffic direction and the mirror process number.  The command syntax is:

PhoneRM(config)# interface <port/trunk/mesh> monitor all [in | out | both] mirror <1-4>

Setup the VM

Now that my mirror process is configured to send VoIP traffic to physical port C9 in the computer room, I need to setup my Oreka virtual machine.  I’m running ESXi 5 in this environment.

I installed a VM with 2 network cards.  One of the NICs is going to be connected to the already-configured corporate LAN for network access and the other is going to be connected to the mirror port for VoIP mirror traffic.  First, I have to configure a free physical NIC port from the VM host to connect to port C9 on my CPUrmHP switch.

On the host I configured a new virtual switch by clicking on the Add Networking wizard in the vSphere Configuration tab.  I named mine vSwitch2:

Note that the security setting on this switch allows promiscuous mode, MAC address changes, and forged transmits.

Note the VLANid is set to all (4095)

Then I connected the second network card to the “Sniffers” network on vSwitch2 and plugged vmnic2 into port C9 of my HP Procurve switch.

Install OS and Configure

Next, I installed Windows XP Professional, downloaded all the updates using our WSUS,  and installed VMWare Tools.  I then removed all MS Networking and assigned a static bogus IP address to the vNIC connected to the Sniffer network; this prevents silly Microsoft traffic from being transmitted on this adapter.

Test with Wireshark

I downloaded Wireshark, started a capture on the Sniffer port, and made a test call to generate traffic.  Everything looked good:

Installing Oreka on Windows XP

Since Wireshark already installed the pcap driver, installing Oreka was a snap.  First, I downloaded the latest orkaudio-1.2 installer from and installed Oreka as a Windows service.

I didn’t want Oreka to monitor the LAN interface.  I wanted it to monitor only the Sniffer network on port C9.  Also, I wasn’t planning on using the web front end.  The Oreka installation is actually 3 separate software packages: OrkAudio, OrkTrack, and OrkWeb.  OrkAudio captures the VoIP network traffic and makes files out of it.  Optionally, OrkAudio updates OrkTrack: a database application that keeps track of the audio files.  OrkWeb interfaces with the database and presents a semi-OK front end application to listen to your recordings using a web interface.

For my purpose, I don’t want or need a web front-end.  This makes my configuration very simple: sniff off VoIP traffic mirrored from the switches and turn them into audio files with a date-time stamp, caller, direction, and callee.  My configuration is limited to OrkAudio only.

All configuration files are located in c:\Program Files\OrkAudio.  The first one I need to configure is config.xml

I opened it up with Notepad and made the following changes:

  • <StorageAudioFormat>gsm</StorageAudioFormat>
  • <DeleteNativeFile>yes</DeleteNativeFile>
  • <TrackerHostname></TrackerHostname>
    (I don’t need a Tracker – blank this tag out)
  • <TrackerTcpPort></TrackerTcpPort>
  • <!– <CapturePortFilters>LiveMonitoring</CapturePortFilters> –>
    I don’t need Live Monitoring so, I commented this line out.
  • <TapeProcessors>BatchProcessing, TapeFileNaming, Reporting</TapeProcessors>
    I do want custom file names, so I added the TapeFileNaming option.
  • <TapePathNaming></TapePathNaming>
    I’m fine with the default path where it makes a directory tree down to the hour
  • <TapeFileNaming>[year],[month],[day],_,[hour],[min],[sec],_,[localparty],_,[shortdirection],_,[remoteparty]</TapeFileNaming>
    My WAV files will be written just the way I want them: 20120703_133032_%2B1928[censored]_O_388.wav meaning this recording was taken on July 3, 2012 at 13:30:32, when +1928[censored] called extension 388.
    More file naming options are referenced in the Oreka User’s Manual.
  • <!– <TapeDurationMinimumSec>5</TapeDurationMinimumSec> –>
    I commented out this line which disregards calls with a duration less than 5 seconds.  Why? Because there are strange instances where the SIP call record is put on a blank recording that contains the SIP INVITE message; the actual recording is recorded on another file with the callee or caller labeled as Unavailable.  I have a ticket in with Shoretel about these calls.  Until then, I keep all calls no matter their duration.

Now, the VoIpPlugin, Devices tag needs to be customized for your configuration.  You’ll need to open the file, orkaudio.log with Notepad and look at the INFO packet: logs after the “Initializing VOIP plugin” event.  You’ll see a listing of available pcap devices.  Copy the NIC that is configured on your Sniffer vSwitch and paste it into the config.xml file under the <Devices> tag.

Start –> Run services.msc and Restart the OrkAudio service.  Check the OrkAudio.log file for any initialization errors.

Make a test call

By default, the recordings are stored in a directory tree c:\oreka\audio\[year]\[month]\[day]\[hour]\[filename].wav  When the call is being recorded, I noticed that there are files being written with the MCF extension.  This stands for multimedia container format and contains the raw audio data as sniffed off the wire as the call is being made.  After the mcf file is completed, Oreka converts it (if possible) to a wav/gsm file (see config.xml) so that you can use Media Player to listen to the recording.  If there are MCF files that are not converted to wav, one of three things has happened: you have option DeleteNativeFile set to NO in config.xml, the service stopped prior to the conversion taking place, or the phone system you are recording is using a codec that Oreka doesn’t know how to decode.

One biggie for me is that Oreka cannot decode the G.729a or G.729 codecs nor can it decode some of the clear-channel, high quality, Shoretel codecs.  To disable these codecs on your Shoretel system, remove them from Codecs List screen in your ShoreWare Director interface.  The only ones I left enabled are the BV16 and PCMU8000.

Ragnar Del Sol

Ragnar Map

Ragnar Del Sol Map

This would be my first recreational relay. After looking at all of the bumper stickers on vehicles around Phoenix, one stood out amongst the rest. It was called The Ragnar. I’m not sure, but I believe that it was named after the Norse god Ragnarok. I ‘m going to have to research and find out where it came from.

The non-mythological Ragnar Del Sol is a 200.5 mile relay race through Arizona’s valley of the sun. This does not mean that it’s a 200 mile race per person. Each team has twelve members split into two vans. There are 36 legs in the race of varying distances. Each leg is classified as easy, moderate, and hard; however, we found the rating system to be objective only to the total distance of each leg and does not take into account the varying grades of elevation. For instance, the 3.9 mile leg #30 is rated as easy with no van support yet it has a total elevation gain of 606 feet – through Fountain Hills. The vans take on the six consecutive legs (1-6, 7-12, and so on).

It starts in Wickenburg and ends in Tempe, Arizona. There are some nice areas that we would run through like Scottsdale and Fountain Hills; however, the nice areas come with lots of steep hills, inclines over bridges, declines, stop lights, and some rather confusing running lanes. The desert portion of the course is vast.

My brother Aiden called me six weeks prior to the race:

“Hey, Ian. We just lost two runners and we were hoping that you would want to try running the Ragnar with my team. Collin (my youngest brother) will also be running. It would be cool to have the Fleming brothers all in the same race. My coworker already reserved the two required rental vans for the race.”

“Sounds good. I haven’t done this kind of thing since getting out of the military. Well, maybe paintball is similar. In March, I’m driving 1,200 miles to play paintball with some friends of mine in Texas. That would be too long. Sure. I’ll do this if you pay for it. Besides, I’ve never ran a 200 mile relay race before.”


I figured that I needed to train a bit and lose about 5 pounds. Oatmeal, bananas, chicken, and pork loin did it for me in the past. Since my orthopedic surgeon removed a 3mm by 1cm bone fragment from my left shoulder last year it has messed up my karma in more ways than one. First and foremost, my archery skills have suffered. I had to back down from 69lb draw to 62lb. Also, I can’t hold the draw as long as I used to. I had stopped going to the gym. The only exercise was using surgical tubing to keep up my shoulders while sitting on my office Lay-Z-Boy chair; however, I don’t do this as much as I should. Cardiovascular was near nil.

I re-opened my gym membership.

The winter in the White Mountains of Arizona made it impossible for me to run outside. Really, the only thing that I used the gym for was the treadmill. I didn’t want t build up upper body muscle. My mission was lose weight – and lost it I did. I lost 6 lbs in 6 weeks.

Glucosamine, Chondroitin & MSM, Echinacea, and occasionally, Tums, were my daily supplements. I started taking the G/C/MSM thinking that all this running was going to be hell on my joints. Beginning the training, I went to and downloaded their “couch potato to 10k” training program that I loosely followed. In hind sight, I should have followed it exactly. The training program I bastardized from it was more for speed than endurance. I really didn’t want to spend hours on a gym treadmill 4 days a week. Not knowing in advance that this was going to be my big mistake, I thought I was doing really good reaching a 7.5 minute pace for my 3 mile training sessions on the gym’s treadmill. In my mind, the 7,200 feet of White Mountain elevation that I was training in would only add to my superhuman ability…

Race Day Minus Two

I had a work meeting with Oracle in Phoenix the Thursday prior to the race. Lucky for me, my company would reimburse me for my mileage to attend this meeting. Following the meeting, we would have a couple hours to drive around, shop and experience the warm valley weather – a nice break from the cold.

My girlfriend has an uncle that lives in Wickenburg. His house is 9 minutes from the Ragnar starting line. She wanted to tag along and stop at all the major exchanges to be sure we were alright. We both live about 230 miles away from the Ragnar which posed the first problem: the team vans start the drive to Wickenburg from Scottsdale. If we were driving, how would we all meet up and if my girlfriend were to ride along, how would we get back to Wickenburg to pickup my car? I discussed this with my brothers. I would meet up with them in Wickenburg and get on the van. My girlfriend would drive my car and not ride along. She had some weekend conferences that she could go to and she also wanted to go back to the Scottsdale Arabian horse show.

All was clear. I packed my gym bag for the race and started the drive to Phoenix. Then my sister, mother, and brother called me frantically. There was a death in the family. My uncle out in West Virginia.

“When is the funeral?” I asked. “More information to follow” was all I could get from my Mom.

It was Wednesday. The funeral would probably be on Sunday or Monday. Are the Fleming brothers still running? Aiden called me, “Yes! The funeral isn’t until Monday.”

“So, we are flying out on Sunday, I take it.” Here’s where I turn the car around to pickup my suit.

“Aiden, do you have a suit protector that we can double up on?”

“I don’t have one”, was Aiden’s reply.

When plans change or emergencies rise, I try my best to roll with it. When there are a lot of loose ends, I look for a general direction. As long as I have this general direction, I can provide some form of forward momentum. I don’t need every detail planned out before I start moving.

I arrive back to my house, pickup my suit, then my girlfriend, and we continue the drive to Phoenix.

Race Day Minus One

I wake later than normal, around 8:30, get dressed, and take off to the Oracle meeting. The meeting was about the Oracle Database Appliance (ODA) hosted by Cloud Creek Systems. It was an interesting appliance that I may look into further instead of migrating Oracle boxes (Aclara, Elster, NISC, etc.)

After the meeting, we went shopping. I picked up some energy food and some running socks at the Sports Chalet, played with some guitars at the Scottsdale Guitar Center, and got a haircut before we started the drive to Wickenburg to meet up with my girlfriend’s uncle.

Race Day – 5AM

The day began at 5AM… well, more like 3AM. I “slept” on a sleeper. Feeling the beginning symptoms of a head cold (my girlfriend had one a week prior) and being in a strange place, I didn’t get much sleep. My girlfriend’s uncle was nice and his house was massive. Being a single guy, he didn’t have much furniture around; hence, the sleeper.

I met up with my team in van 2. All really nice people who picked up everything that a newcomer would forget like the special sunscreen that goes on your forehead as not to get burning sweat in your eyes, baby wipes, lots of reflective tape, first aid kits, food, food, food, and lots of water. There was a mom in our group and we were all lucky enough to be treated like her kids.

We drove to the start line and saw the first van off. Instead of just going to exchange 6 (where the vans exchange), we decided to cheer on the other runners as well as those in our team. It was funny cheering for the other teams. Most of them gave a smile followed by a strange look as if to say, “Do I know you guys?” We were just having fun. It’s a hard race. This was the first couple legs. It wasn’t going to determine anything this early on. Even the most competitive teams may fall out due to injury or other reasons for all we knew.

After three hours of cheering, we moved on to my van’s exchange point. My first run was about 5 miles in the heat of an unseasonably hot day in February. I paced a 10 minute mile on the first leg and it just about took me out. I am not used to +90F weather!

Race Day (plus one)

We caught some sleep in the van and took a detour to a teammate’s house for showers.  My second leg was 2AM the next morning. I’ve learned that there’s nothing like a night run in the middle of the night with nothing but a headlamp, tail light, and the hum of power lines to keep me company. I held a 9:15 pace.

My final leg was all downhill from Fountain Hills into Scottsdale down Shea Blvd. It was, again, in the heat of the day. The thing that got me on this leg were the traffic lights. It took a good 3 minutes of stalling to get though all of the traffic. That was a little demoralizing but I appreciated the break.

At the end of the race, both vans met up at the finish line and ran with the last runner. They gave us our finishing medals, some free beer and pizza coupons, and took our picture. There were some family members from our team that made us some banners to run around with. It was a good time.

Baton Hand-off

To Run or To Play?

The impetus behind the Ragnar is the run; however, most of the time is downtime. During this time, people play tricks and pranks on the other vans. There’s a lot more to this run than just running. The most fun was cheering on other teams and picking fun at them. The costumes that many teams wore really added another angle.


Just about every Ragnar van was decorated with the team names. They did this with wet chalk, window markers, or something that could be easily wiped off. Our team name was “Ask Your Doctor If Getting Off Your Ass Is Good For You”. We had taped a picture of a donkey on our van. We took two peach colored plates taped them together to make an ass and drew a running stick figure. [picture?] Of course, there are the pranksters that were tagging the vans quite heavily.

The best tag attempt (in my opinion), was from a person from the Disco Team. These guys were great. They had a disco ball on the top of their van, an outdoor blaster that played disco music, and they were disco dancing at every exchange. It was quite a sight. Needless to say, they looked like they took a time machine from the seventies. They successfully erased the second “Your” from our team name and updated it with the word, “IN” with a bright pink colored marker. They were about to violate the stick figure when I yelled, “HEY! Get off my van!” and startled the heck out of guy. I thought he was going to run off but instead he walked up laughing and gave me a high-five. “I gotta give you props for that one!” I said, laughing.

Most tags were harmless magnetic stickers, bumper stickers, or window chalk. Others seemed more malicious. I believe the vans that had tallied their “KILLS” got maliciously tagged more than others. A “kill” is apparently when a team member passes another person. I would assume that they are net kills and not gross kills. There are some vans that had a whole window of tallied kills. Of course, there’s no way to validate this until the finish line but even then it seems kind of a silly thing to keep track of. It’s a form of motivation for those who get off on being ultra competitive, I guess.

Race day (plus two) – Celebrate

Immediately after the finish-line celebration, we met up at The Twin Peaks Microbrew. One of our teammates came all the way from Australia. Two others from San Francisco and Las Vegas. They were really fun people and I am glad that they were on our team. We set them off with a couple drinks.

Race day (plus three) – Flight

I called my sister who purchased the tickets for the funeral. Eight hours later, we are at the airport. I mistake United for US Airways and am dropped off at the wrong terminal; I was off to a bad start. My brothers and I could hardly walk and we needed to run.

We made the flight, the 3 hr layover in Cleveland, and finally get to the rental car. Now for the 3 hr drive. In spite of the incessant DING and check engine light flashing, we made it to the viewing on time. My dad was very pleased to see that we made it. I was as well. I haven’t had a trip with my brothers and sister in a couple of years. I wish it had been under better circumstances.

The funeral was the following day. Goodbye Uncle Pat…

Race Day (plus five)

On the way home, one of the engines on the Continental plane in Cincinnati wouldn’t start after taxiing to the runway. We disembarked the deadlined aircraft, got a new ticket with American Airlines and flew home to PHX via DFW. There was a 130 knot head wind which put us in about 40 minutes late. I got home at 4 AM this morning. Work starts at 7AM so, I’m still wearing my funeral suit – at work.

What a weekend!

To Page or to Blog

To Blog

When I started this blog, I first intended to use it for recording my daily activities.  I didn’t want to make a new website and add a whole bunch of administrative overhead to my life.  This is why I settled on WordPress.  I really like the format and the ease of posting here.  When writing here, I don’t have to worry about if an iPad, Kindle Fire, or mobile device wants to read my postings.  This makes WordPress a real no-brainer for just ad-hoc writing.

To Page

What my blog has become is a collection of references with no real tie to the date of posting.  Over this weekend, I read more about the other posting alternatives in WordPress, I found that I can use “pages” instead of “posts”.  A “post” is to support the blog-style format where the date is something that is supposed to be tracked.  Pages do not require date references in the URL. I’m going to put together some pages of past e-mails and topics that may be useful.  This will be a little different than what I’ve done in the past.  I think I like the idea of pages for the purposes of many of my postings.  It also makes it easier to integrate others.  This brings up my next point:

Cooperation Among Cooperatives

If you have something that you wish to share, please e-mail me and I’ll post it, give you a log-in, or we can come to some other arrangement.  If you are anything like I was in the past, you probably don’t want others knowing what you are up to.  After writing about some of this stuff and getting so much feedback and input from others, I don’t know if I can go back to working in a vacuum again.  The reason that the IT industry has surpassed most other industries is that IT workers traditionally share information.  This spirit of information sharing goes hand-in-hand with two of the Seven Principles of Cooperatives:

  • Education Training and Information
  • Cooperation Among Cooperatives

So, do you have anything you wish to share?  Criticisms of my posts I’d be interested in.  To be blunt, I’m shocked that no one has publicly disagreed with my use of VMWare’s free licensing models in a production environment.  Especially by those who have spent the money… Who knows? Maybe the criticism is happening behind my back.  Well, there’s an open opportunity to criticize on the same page that promotes!


On the week of the 5th, I attended Mikrotik training in Salt Lake City.  I am now a fully certified:

  • MTCNA – MikroTik Certified Network Associate
  • MTCRE – MikroTik Certified Routing Engineer
  • MTCWE – MikroTik Certified Wireless Engineer
  • MTCTCE – MikroTik Certified Traffic Control Engineer

What it really amounts to is more alphabet soup to remember when someone asks me about it.  I’m planning on writing up a review of the training sessions from Dennis Burgess at LinkTechs. Hopefully, I’ll have the time to post some pages of what I learned about RouterOS this week.


Get every new post delivered to your Inbox.