Arena Check-In stations

March 25, 2008 |   |  4 Comments  |  Church IT, Hardware

Some of you (JP!) have asked me about our Check-In setup, and I promised to blog about it. So here goes.

We’re currently on Shelby V5. Until recently, we were using 1998-vintage gateway PCs running ThinStation (a Linux-based Live CD that gives us an RDP client – 2X is a good option too) that connected back to a dedicated terminal server that had the Shelby V5 application and each room printer defined. We’ve recently started installing new hardware in preparation for the cutover to Arena.

Update, May 2011: Arena check-in rocks.


Thin Clients
We chose the HP t5720, running XP embedded. This machine has 512MB of RAM, an AMD Geode 1500 processor (1GHz), VIA Rhine II Ethernet, and SiS graphics chipset. ATA Flash options are either 512MB or 1GB. We ordered the 512MB option to save about $50, but it turns out that the .NET framework requires more space than was available on the flash drives. Luckily, a 1GB module for these is about $50. We chose XPe because the check-in application has a client-side component that runs on Windows, and won’t work well in a Terminal Server environment. In January, HP released a flash image that includes IE7. Another option for us was the Wyse terminal which we could get through Dell (for some reason they won’t sell us HP gear?!??!), which were priced similarly (the 512MB units are just under $500, the 1GB units just over), but we’ve had good experience with our T5500 CE thin clients that have been in our check-in info booth since we opened our west building in 2004. The T5720 also has a PCI slot option which requires a chassis expansion kit (about $30) if you want to use PCI wireless. We’re also using the 512MB units in our training lab and will be deploying them afterward to a number of volunteer stations around our campus, to replace several aging GX260 machines. Remote management of the thin clients (both the older CE thins as well as the new XPe thins) is with Altiris Deployment Solution. It’s been a bit of a challenge getting HP to support this, as many of their India-based folks are unfamiliar with the process of getting Altiris on the line. Altiris is based in Salt Lake City and is now part of Symantec. Let’s hope their support stays right where it is, because Altiris support is quite good, once you finally get through to them via HP.

Update, May 2011 : We’re replacing the t5720 units with HP’s latest, the t5740e, running Windows Embedded Standard 7, because Arena’s latest code requires .NET 3.5 SP1 to function in the check-in module.  WES7 is a lot easier to deal with than XPe. The new units sport a 1.66GHz Intel Atom N280, 2GB RAM, 4GB flash, Broadcom Gigabit Ethernet and Atheros Wireless. Dell’s FX160 thin client is very similar, but is nearly double the price.


Touch Screens
We went with the Dell E157FPT, a 15-inch SAW touch unit that has both USB and RS-232 interfaces, as well as integrated speakers. Based on the drivers, I have strong reason to believe these are OEMed by Elo. They sure are built well. The main reason for selecting the Dell unit was cost – the nearly identical Elo units were about 50% more (mainly because Dell can’t discount those as heavily as its own branded gear). Dell also has a 17″ version of this monitor for about 25% more. While we’re on the topic of touchscreens, this one is really shiny!

Update, May 2011: Other than a single unit that was DOA, we have had ZERO problems with these units, and they see a LOT of fingers every week. SAW was definitely the right tech for this application, as there are no overlays to wear out and they’re easy to clean. However, Dell seems to have gotten out of the touchscreen business. Even drivers for our screens were hard to come by from Dell when we deployed the WES7 terminals. Fortunately, the ELO driver package works just fine (and is identical except for a different logo.  By all appearances, the E157FPT is a rebranded ELO Intellitouch 1522, which can now be had for around $500, with 17″ and 19″ models only a few dollars more.

Receipt Printers
We’re using our existing fleet of Zebra LP2844 and LP2824 printers that we’ve been using for Shelby V5 Check-In for some time. These are currently located in each classroom and connected over Ethernet via a Trendnet parallel print server (Zebra also has a model of these that has built-in ethernet which I’ve seen at the Wal-Mart pharmacy). We’re still debating whether to keep them in the classrooms or move them to the kiosks. There are a number of arguments in favor of each option, and it will ultimately boil down to what the people in our Children’s Ministry prefer. Some of the staff are going to visit some other Arena-based churches and see how they do it before making a final decision.
The Zebras are solid printers, although we’ve had some issues with drivers. For V5, we ended up using a third-party driver from Seagull Scientific because V5 doesn’t play nice with the OEM Drivers. Strangely enough, Arena check-in (which uses SQL Server Reporting Services to generate a label) doesn’t play nice with the Seagull drivers, but does play nice with the OEM drivers. Go figure. I’m not a huge fan of the TrendNet units, but our options in that space are VERY limited. If we end up moving the printers to the kiosks, they’ll be directly attached via USB.

Update, May 2011: Zebra no longer makes the LP2844, so we’re replacing dead ones with the Zebra GK420d, which has on-board Ethernet. They’re a lot faster too, printing at 6 inches/second, and can be had for around $400.

Bar Code Scanners
Another re-used item from our existing setup. These are Symbol LS1902T scanners (Symbol was acquired by Motorola a while back). The stand has a little magnet under the logo that activates the scanning (or it can be turned on by programming the scanner). Another quirk we discovered between Shelby V5 Check-In and Arena is that the Arena application expects a carriage return following the scanned code, whereas V5 expects a tab (although a CR seems to work too), and all our scanners had been reprogrammed accordingly. We’re using these as keyboard wedges, so the system simply sees them as a PS/2 keyboard. One advantage to using these in keyboard mode (instead of a standalone USB scanner, also supported by Arena) is that I can remove the station keyboards. If I need to get into the maintenance screen, all I have to do is make a Code 39 barcode containing $M, program the scanners to do the full ASCII set, and it will read this barcode as a Ctrl-M. I now have a sticker of 72-point Code 39 on the back of my door access card. From there, it’s all about the touch screen. I can also do codes for Alt-F4 and ESC, which would be useful for V5 Check-In.


Barcode Printer
This unit is a DataCard SP35 that we currently use to print barcode tags for our families. We haven’t determined if it’ll be worth our while to keep issuing tags post-cutover, since the whole point of going to touch screens was to let people check in using their phone number without requiring a physical ID. The existing tags will still work in Arena, so those who have tags can continue to use them if they wish (hence the barcode scanners) In the V5 world, this was a lifesaver – the previous method involved printing a sticker with a barcode and attaching it to a name tag. The life expectancy of these tags was abysmally short (a few weeks) and caused heavy load on our info booth volunteers. This unit lets us print a V5 ID Card onto a set of keychain tags. The life expectancy of these is considerably longer (months/years – they’re wash proof!), they scan better, and they cost us pennies per tag instead of dollars. Even with the printer costing around $1400, this setup paid for itself very quickly. A box of 1000 cards runs a little over $100, and a monochrome ribbon good for 1500 cards runs about $20. Our old nametags used to run us about $2.50 each. In the Arena world, we could use this to print ID cards for our volunteers. We use a similar (older) ID card printer to print our facility access badges. One major downside to this unit is that it REALLY does not like to be connected to its host machine via network print servers. It manages to crash both the host machine and the print server. There is an Ethernet option available, but it’s really spendy.

Update, May 2011: We stopped using barcodes about 6 months after converting to Arena. We’re searching by phone number now.

In a future post, I’ll blog about the layout of the check-in areas and the information booth. Sadly, we don’t have the ubercool furniture JP has.

Off I go, into the wild blue yonder…

July 22, 2007 |   |  Comment  |  Church IT

I’m currently sitting in the departure area at Kansas City International’s Terminal C awaiting my flight to Denver. This all came up rather suddenly last Friday afternoon when I got an E-mail from Bill English at MindSharp, offering me a seat at one of their SharePoint training events. The only one they had scheduled for Kansas City this year was the course for SharePoint Designer 2007, which Bill admitted probably wasn’t quite what I needed. After a quick jaunt through their course schedules, I found that they were offering the SharePoint Administration course this week in Denver. Since I have family in Denver, that made it easy to do on a church budget. After some fortunate timing involving Clif showing up online (he’s in Texas for the next few weeks) and getting his approval for my travel expenses, a plan was put together. The original plan was to load up the minivan and whisk away my lovely wife and two adorable daughters for a week, but we weren’t able to secure the time off for her, so I sadly have to go to Plan B, which means I go by myself. On the other hand, driving is an expensive way to go at the standard IRS mileage rate, so I booked myself a flight and a rental car on Friday night and saved the church a few hundred bucks in the process.

Added bonus: I can take a SharePoint test as an MCSE elective, which improves the Bird:Stone ratio considerably. I’ll also probably spend most of the flight seeing where my existing knowledge stands with regards to the certification requirements. I’ve been getting an awful lot of on-the-job learning for that stuff.

I’m discovering that the WiFi in Terminal C is much better than that in Terminal A (as I discovered last February on a Southwest flight). Terminal A’s WiFi is nearly unusable. I have a fallback plan, however… I got me a new Mogul with Phone-As-Modem capability (more on that in a later post).

I’ll post more on SharePoint as well.

The importance of a good disaster recovery plan…

February 17, 2007 |   |  Comment  |  Church IT

Yesterday, a building in the Waldo neighbourhood of Kansas City burned to the ground. The building housed, among other things, a cafe, a bar, and a bridal shop.

By mid-afternoon, the owner of the bridal shop was on the phone to her customers that were getting married this weekend, as well as to designers in order to get replacement dresses overnighted so as not to impact the weddings taking place. She also said that they were buying new computers this weekend and would start up again soon in a yet-to-be-determined location.

In addition to the incredible level of customer service, it would appear that the owner of this shop had a DR plan in place and executed it. When the worst-case scenario actually happened, she knew exactly what needed to be done to continue operations. If she had good backups, she should have her computers up and running by monday. All she needs is some retail space and to replenish her inventory, and she’s back in business.

There are a few key points here:

  • Make sure you have recent and good backups, and that they’re stored somewhere safe. Having them sit next to your computer isn’t going to do you a lick of good if the building crashes down around it in a sea of flames.
  • Make sure your DR plan is kept current, that key staff know about it, and that a written copy of it is kept off-site. Periodic disaster recovery drills don’t hurt either.
  • If you deal primarily with customers, they need to be taken into consideration with DR planning. Taking care of them even when disaster strikes will pay off huge dividends in the long term.

What not to do:

  • Keep your backups onsite (or have one copy onsite and one offsite. The most current one should be the offsite copy). Note that fire safes are meant to keep paper documents safe. In a raging fire, the inside of a fire safe will hit 350 degrees. While it won’t cause the paper to burst into flame, your backup tapes/CD/DVD/whatever have long since melted into a puddle of plastic slag.
  • Hope that your backups work. Test them every now and then.