« April 2008 | Main | June 2008 »

May 2008

May 31, 2008

Wireless Safety: the VPN Question

In response to my earlier post about wireless security, Stuart made the comment about using VPN to enhance security.

I’ve heard this many times, and it makes sense.  I’ve also heard that it actually creates an even greater risk!  The thought is, if you have a VPN connection, then you have a "trusted" pipe into your network.  But, if your local Internet connection isn't safe, then have you just created a pipe from danger into the guts of your network.  The question (to which I do NOT know the answer): if your notebook is on an unsafe network, how does a VPN connection make it safe?

I've heard the analogy: VPN is like a clean pipe with one end in the middle of a cesspool!  Please tell me how that's wrong.

May 30, 2008

First Thoughts on RTO, RPO

Continuing to think about Disaster Recovery / Business Continuity. How much of an outage and data loss is "tolerable?"

Reminder of the two terms:

RPO: Recovery Point Objective
How much of your data can you afford to lose in a crash?  (as in 10 minutes worth, 2 days worth, etc.)

RTO: Recovery Time Objective
Basically, how long can you afford to be without your data?

First thoughts (without too much consideration of costs or technologies)

Server/Service

RPO

RTO

Email

1 day

2 days

Accounts Payable

2 days

4 days

Payroll

1 pay period

1 week*

Church Database

1 week

1 week

File Server

1 week

1 week

All Else

1 week

2 weeks

* Assumption: in AP is up, you could write checks to people to hold them until the next real payroll, and then balance things out.

I can't say I like any of these numbers. I'm just trying to imagine the costs of making them smaller.

May 29, 2008

Biggest Loser 2: The Target

The weight isn't the problem, it's the distribution.  This is the enemy to be defeated!

Belly

Intranet Mailer

Kirk Longhofer sent me an email regarding my post (actually Jim LaBarr's tip) on Outbound Email guidelines asking for more info on our Intranet Mailer solution.  The short answer: this was something Stephen Wareham wrote for us many years ago.  He made some comments way back in response to the "Tool vs. Job" post that describe some of the story behind it.  For those using Shelby V5, the basic Shelby Web Interface is still available here.

May 28, 2008

Switchvox Presentation/Demo

SwitchvoxFor those of you in or near the Atlanta area, we're going to have a chance to look at the Switchvox variation of Asterisk.  In case you don't already know, Digium is the commercial company behind Asterisk, and Switchvox is now part of Digium, bringing it all back together.  (very abbreviated summary, obviously)

Tom Guffin of Higher Ground Technologies has been deploying Switchvox for a while and has nothing but great stories about it.  He's arranged to have a Digium representative spend an afternoon to help show off Switchvox and answer questions. 

Don't make any big travel plans yet, but pencil in lunch and early afternoon on July 2.  I expect to confirm that in the next few days.  It's confirmed: July 2, starting at noon, location will be Perimeter Church.

CRM Starts Paying Off

We're not live on CRM yet, but some of the benefits are starting to be visible.  Our staff lives in Outlook all day long.  Now, with ProVision CRM, membership info is right there, without having to open another application.  Happy Days!

Outlookcrm

May 27, 2008

RTO & RPO

Several of us met with Veristor today to talk about, what else, ILM.  Although we'd planned to see a demo of Moonwalk, that didn't really work out, and we ended up having a lot of discussions on many different ILM-related topics.  Everett Dolgner, the Sr. Storage Architect we were meeting with, kept bringing us back to the need to set our criteria before choosing any technologies.  In particular, he said we should always start by determining our RTO and RPO.

RTO: Recovery Time Objective
Basically, how long can you afford to be without your data?

RPO: Recovery Point Objective
How much of your data can you afford to lose in a crash?  (as in 10 minutes worth, 2 days worth, etc.)

Here's an article from SearchStorage that gives an overview of the two terms.

Veristor tends to work with larger organizations that us - organizations that live and die based on the immediate and correct access to their data.  Churches are different.  Or are they?

In the event of a disaster, how long could you go before you had your data back?  And consider, a "disaster" doesn't necessarily mean a bomb being dropped on your facility.  What about an overhead pipe bursting above our server?

May 25, 2008

NT on the Clipper

May 25, 1993; 15 years ago. 

WinworldRemember when Comdex and Windows World was an event that took place most springs in Atlanta?  That's where many of Microsoft's big announcements took place.  Windows 3.1 and Windows NT each got their first big public showing at this Atlanta event.

Now, a quick bit of history.  The original plan for Windows NT was for it to be somewhat hardware independent.  It was expected to run on many different processors, with Intel being just one of a bunch.  You may remember than NT was ported to MIPS and to ALPHA.  Not as well known is that NT was ported to other processors, including the Intergraph Clipper.  A year earlier, Intergraph and Microsoft had started down a path of partnership and I had the privilege of being right smack in the middle of it.

In 1993, way up on the 67th floor (I think) of the Peachtree Plaza hotel, Intergraph (specifically Bob Mueller and Tommy Steele) powered up Windows NT, running on the Clipper, and demoed it to Paul Maritz of Microsoft.  The whole event was maybe 15 minutes, or even less.  It was a huge success, at least as far as credibility was concerned.  Too bad that the Clipper's future was shortened.  It would have been nice to see some other processors still running NT.

Nt31Clipper 

May 24, 2008

It isn't Vacation Until...

I'm not sure what made me think of this "family rule," except maybe having a Cracker Barrel breakfast yesterday and thinking ahead toward vacation next month.  For the past several years, we've had an unwritten rule about vacations, and it's simply this.

Crackerbarrel It's not a vacation until we've had a breakfast at Cracker Barrel.

May 23, 2008

Guidelines for Outbound Email

I debated posting this tip because it is so extremely Perimeter specific. But, maybe others deal with these types of issues too. Our goal is to have good email communication. We happen to use some technologies to help reinforce the goal. It is one of our most controversial issues, and a frequent subject of helpdesk requests. Note that there are several internal links below. If you really want those documents, let me know…

 - Tony

From: LaBarr, Jim
Sent: Tuesday, May 06, 2008 10:12 AM
To: _Announcements - Intranet
Cc: LaBarr, Jim
Subject: Outbound Email Messages need to follow specific guidelines

Although the reasons that email messages would be blocked were communicated several weeks ago, there was only partial enforcement. Now that the messages are being blocked if they exceed the maximum number of recipients, I have been asked to list again the reasons for the guidelines, and the specific guidelines.  

Question: Since item 3 says there cannot be more than 9 names in the TO: field, does that mean that you cannot communicate with your volunteer leadership team of 12 people?

Answer: No, put the names in the BCC field. Item 2 says the TOTAL names (BCC and TO and CC) must be 25 or less.  

Jim


From: LaBarr, Jim
Sent: Monday, March 31, 2008 10:29 PM
To: _Announcements - Intranet
Cc: LaBarr, Jim
Subject: Reasons that certain Outbound Email Messages are Blocked

What Are the Goals for Outbound Messages from Perimeter?

  1. To communicate politely, in other words, to use good email etiquette.
  2. To avoid the appearance of Spam in messages we send.
  3. To protect the privacy of the recipients of our email message.
  4. To encourage the use of the Intranet to send messages that go to a lot of addresses. This helps us to keep our Shelby database up to date.

What Items Could Cause an Outbound Message to Be Blocked?

1 - There is no Subject line. Or you are trying to Forward or Reply to a message that had no Subject line.

2 - There are more than 25 TOTAL names in the TO line, the CC line, and the BCC lines. Notice that this is different than the next reason.

3 - There are more than 9 names in the TO line or the CC line. Notice that this is different than the previous reason. Put those names into the BCC field.

4 - A Distribution List is counts as the number of names it contains. If you put 30 names into 1 personal Distribution List in the Bcc field, they still are counted as 30 names, and the message is blocked.

5 - If a message is over 3.5M in size, it will be blocked with a message such as, "The message being sent exceeds the message size established for this user." For several ideas on how to deal with this situation, read this document P:\KnowledgeBase\FAQ\MessageSizeLimitOutbound.doc

6 – There are several miscellaneous reasons such as crude language, or a Subject of "Hi" or "Hey" or "Hello."

7 - The words [Spam/Warning] or [QUAR] were in the Subject line of a message you received, and you are trying to Forward or Reply to that message. Even though you didn't put those tags into the Subject line, they will cause your outgoing message to be blocked.

Even though there are other reasons, nearly all of our blocks are for one of the reasons above.

If you Reply to or Forward an email that exhibits any of the issues listed above, the message will be blocked, even if you didn't create the problems.

Shown below is the message you will get if your message is blocked before leaving Perimeter. The body of the non-delivery message is confusing and misleading when it says, "You do not have permission to send to this recipient." In reality, the problem could be any one of the various issues listed above. The Subject of the NDR (Non-Delivery Report) is always "Undeliverable: **Message blocked by Perimeter's outbound mail filter**"

To learn more about size limits, P:\KnowledgeBase\FAQ\MessageSizeLimitOutbound.doc

To learn more about all the other reasons a message could be blocked,

P:\KnowledgeBase\FAQ\OutboundBarracuda.doc