If your CIO doubles as your CFO, you might be a small or midsize business (SMB).

Steve Snodgrass fills both roles at Granite Rock, a 600-person construction supplier.
The CIO/CFO, like a lot of his SMB peers, works with a tight budget, a downsized IT staff, and increasing requests from the business. “We’re what I would call a classic midmarket company,” Snodgrass said in an interview.

For some SMBs, that mix means cutting corners on things that have a blurrier link
to the bottom line, like disaster recovery (DR) planning. Yet Snodgrass keeps DR top of mind because, well, he has to–Granite Rock operates on the San Andreas Fault, where an earthquake isn’t just possible–it’s probable. “One of the challenges for us as a company is to have a disaster recovery plan that works and is affordable,” Snodgrass said.

Snodgrass and Granite Rock began facing that challenge back in 2000–largely by accident–when the company decided to outsource its enterprise resource planning (ERP) system to WTS, which is now part of Velocity. The reason? The Bay Area firm was dealing with a dot-com talent drain. A full backup and recovery plan came about over time as its outsourcing decision evolved. Today, Granite Rock’s ERP system is hosted in Seattle and fully recoverable from another secure site in Denver should anything go wrong. If disaster strikes in San Francisco–or Seattle, for that matter–Granite Rock
can continue to pay employees, bill customers, and keep critical operations running.

Whether or not you’re in a high-risk area, Snodgrass’s approach offers some DR wisdom for fellow SMB IT pros to consider in their own organization.

1. Become a pragmatist. Granite Rock doesn’t have the budget or IT staff to ensure that every application and system is fully recoverable, so Snodgrass doesn’t bother trying to achieve 100% readiness. Recovering the ERP platform is priority one, so that’s where he and his team has put its focus over time. Granite Rock does some less comprehensive
DR planning for other important applications–its Microsoft Exchange server, for example–and it makes educated decisions about which areas to ignore. An earthquake would knock out the weighing systems Granite Rock uses when customers place orders for tons of rocks–but Snodgrass isn’t losing sleep over that. The wide-area networks those systems rely on would also be down, so recovery is moot.

“Redundancy wouldn’t get you anything,” Snodgrass said. “We take a pragmatic approach: What are systems you can’t afford to live without, and what are systems you could live without?”

2. Lose the cloud fear. Snodgrass is quick to acknowledge that his company’s DR readiness began somewhat serendipitously. But the decision to move a business-critical application offsite was key; fellow execs that have shunned cloud platforms for security
or other reasons. Snodgrass doesn’t think those fears are unfounded, but notes that moving to hosted platforms can help IT pros create a DR plan without separate costs. “We embrace it,” Snodgrass said. That doesn’t mean he does so with a blind eye–it’s just that the benefits outweigh the risks. “Are there security and trust issues? Absolutely.”

3. Stop fretting over ROI. When it comes to proving a return on his IT investments, Snodgrass is in a unique position: because he’s also the CFO, he is, at least in part, proving ROI to himself. Yet when it comes to DR, Snodgrass thinks SMBs should become less obsessed with ROI in the traditional sense. “One of the major flaws of the
IT industry is that there aren’t a lot of solutions that have a tangible return,” Snodgrass said. That’s a problem if you’re making a financial case for DR in your organization–a case Snodgrass said will likely be met with skepticism by the CFO and other stakeholders. Instead, he advocates a different approach: Describe your DR plan as an insurance policy.

“There’s no rate of return on insurance,” Snodgrass said. “If you don’t have a [disaster] that’s insured, it’s just an ongoing cost to the business.” And yet when something does go wrong, the uninsured business might soon be out of business.

4. Put the plan through its paces. The most common DR pitfall in Snodgrass’s view–aside from ignoring it entirely–is to invest in a plan and then not test it. “It’s one thing to have a disaster recovery plan; it’s another to know that it actually works,” Snodgrass. That means testing it in simulated disaster conditions. Granite Rock, for example, practices recovering and restoring its offsite tape backups so that the team isn’t trying the somewhat laborious process for the first time in an actual disaster scenario.

Equally important: Testing should be an ongoing process, not a one-time task. The
reason is simple: “It’s a moving target,” Snodgrass said. “IT is always adding services, and the business is always demanding services. That’s a real challenge for a midmarket company.”

Now what is virtualization? Virtualization lets fully utilize your server hardware assets by allowing you to run multiple virtual machines (operating systems) on a single physical machine (physical host), with each virtual machine sharing the resources of that one physical computer. VMware customers typically save 50-70% on overall IT cost. Call us today or email us at sales@easyit.com if you would like more information on what virtualization might provide for your IT environment.

-145 MPH wind ratings
-22 inch exterior concrete walls
-A duel, independently layered roof system
- 24×7 Network Operations Center
-911 rated facility – operations cannot be powered down
-Compliant with HIPAA, PCI and Tier IV data center standards

DataCenter.BZ leverages high density power and cooling capacities to allow for smaller footprint solutions and lower customer operating cost. To read more about this exciting Central Ohio development follow this link DataCenter.BZ Completes 34,000 Square Foot Expansion

“TO THE CLOUD!” Everyone has seen the commercial or heard the phrase, but do you really know what this often misused phrase refers to? Most of us use the cloud in our daily lives but have little knowledge of what it truly means.  Cloud computing refers to using  software and applications over the Internet rather than from a hard drive on a local PC or server.

Still confused?  Let me provide a common example that we see amongst our clients.
A popular mail server is Microsoft’s Exchange server.  Traditionally, if you wanted to have email, shared calendaring and more sophisticated mail functions, you would have to buy
a robust server and license and load MS Exchange on the server.  It would probably be that loud machine stuffed in a closet in your back office somewhere.  It is a significant up-front investment and means you will also have on-going support costs.  The new “cloud” alternative is to migrate the Exchange email (along with calendar items and perhaps documents) to a hosted service such as Google Apps for Business or Microsoft’s Office 365.  In this scenario, the business does not have to make a capital investment in servers and hardware; they just pay per user, per year.  Meanwhile, the user may have no idea that their mail is being provided from “the cloud”, in that they still use it as they did when they had an internal server.  They also may have more options for getting to their email and calendars from more places, such as home or even Starbucks; any place where they can get an Internet connection.

A number of small businesses have taken the leap from on premise computing to the cloud. One third of small/mid-sized businesses (SMB) have adopted some form of cloud
computing.  They have taken their email, calendars, and/or documents to the cloud. Company employees now have access to their important information wherever there is an Internet connection.  Of these early adopters, 98% have said their cloud experience has been positive or very positive and has produced the desired results.

What does the future hold for the cloud and SMB’s?  Another third of SMB’s predict moving to the cloud in the next year.

- EasyIT

P.S. Be on the lookout for “To the Cloud – Part 2, private versus public cloud”

All numbers were based on the survey done by CompTIA.

When considering a mobile application, trying to figure out what needs to comply with the Health Insurance Portability and Accountability Act (HIPAA) can be an intimidating task. Asking yourself a few questions can make this much easier on you and your mobile  developer.

First, ask yourself who will be using the application? Is this app for your physicians, hospital or health plan? If so then the HIPAA rules must apply, as these are “covered entities.” HIPAA rules also apply to any business associates of the covered entities as well.  A business associate is an entity that handles “protected health information” on behalf of a covered entity. For example, a pharmacy benefits manager operating a health plan’s  prescription benefit: the health plan is the covered entity and the pharmacy manager is the business associate.

The second question you need to ask yourself is what information is the mobile application going to have access to?  HIPAA rules only apply to protected health information. This includes information that can identify a specific individual and that relates to that  individual’s physical or mental health,  health care services to the individual and payments that were made for the health care.

An example of an application that would need to comply with HIPAA rules would be an app that allows a doctor to follow up with a patient, or one used by health plan employees to quickly gather an individual’s enrollment information.  This application would need to comply.

An application that helps a patient remember their medicine schedule would not have to comply with HIPAA rules as there is no covered entity involved.

So get to developing, and remember that technology can be your competitive advantage when it comes to growing your practice!

- EasyIT your partner for expert technology services for your practice

For more information on this topic please go to When HIPAA Applies

Moving a production data center can be a huge task and can take between 2 -3   months to plan. Often small business will attempt to move their own data center which can result in chaos, downtime, significant cost, and ultimately loss of business. Be sure to pick a vendor that has experience in this area and has perfected the process for data center moves to insure minimum interruptions to your business.

Planning Phase:

Per the EasyIT approach, we start by planning with our partner/client to determine downtime tolerance and to gather information regarding the new facilities.  Priorities are set and the communication, wiring and electrical vendors are engaged.

It is important that your IT department or IT vendor work closely with your various vendors to plan and coordinate.  Don’t underestimate this task, it can take considerable time and is very important.  A poor vendor or mediocre vendor management can sink the best laid plans.  We also suggest that you take advantage of this opportunity to evaluate new vendors, such as new Internet service providers (ISP’s).

Detailed site planning should then be performed.  It should account for network and phone connectivity, power, cooling, physical security, rack placement and wire management.   Be sure to allow for future growth! You may want to invest in additional space in your new data centers along with improved cooling and power management.

Colocation is a strong option for many businesses when they need to move their data center. Adding a co-location facility as part of the data center move provides a location for your backup or production servers to reside.  This dramatically reduces the risk of future power or ISP interruptions for that equipment.  EasyIT strongly recommends that you select a carrier neutral datacenter, as this reduces your reliance on a single telecom vendor in the future.  We leverage datacenter.bz, a Tier 4 data center in Columbus, to provide per “Rack unit” (RU) colocation with redundant power, cooling and communications.

Preparation Phase:

The second step in the EasyIT approach involves documentation and planning.  We suggest taking a complete inventory of every single component being relocated. This inventory will include the following:

- Equipment models
- Serial numbers
- Configurations
- Replacement value
- Vendor contacts

Also during this step, create diagrams to show how each system is currently installed and how it will be installed in the new data center and rack.  Wiring and ports in the computer rack should be painstakingly labeled and documented.

Before beginning the actual move, build contingency plans for most foreseeable move-related system failures.  An important possibility to consider is equipment failing during the move.  Servers, routers, switches and other equipment with moving internal parts pose the greatest risk of failure.  Their risk of failure increases significantly the longer they have been running in production.  In general, at risk equipment is anything that has been in production for more than 2 years.  To mitigate equipment failure risks, extra backups, including image based backups, should be made prior to the move and contingency plans are put in place for different failure scenarios.

Move Phase:

On move day, have your vendor take responsibility for moving all data center racks and equipment. At the pre-determined time, perform a system shutdown and immediately do whatever communication cut-overs are necessary as that can be one of the lengthier parts of the move. The equipment should then be immediately torn down, loaded and delivered to the new data center. Depending on the distance of the relocation, a reasonable expectation to have the new data center “up” and fully tested should be about 12 hours for a small business.

With proper move and contingency planning, you should experience minimized downtime and greatly reduced overall risk.  Issues often come up but can be handled quickly by a prepared move team.

EasyIT offers great peace of mind by providing an expert team of technicians to move your data center.  Please contact our staff to learn more.

While we are quick to point to the danger of erroneous diagnosis and treatment resulting from incorrect medical records, this study confirms that there is also a significant financial impact to protecting protected health information (PHI). In addition, security breach violation penalties are significant. The Health Information Technology for Economic and Clinical Health Act (HITECH) drastically strengthened aspects of the HIPAA security rule, including the penalties imposed under HHS and the Office of Civil Rights. Attorney General from across the United States have been given clear authority to prosecute healthcare providers for criminal penalties for security breaches on patient data. Fines can be imposed from $100 to $50,000 per violation, and up to $1.5 million per calendar year. The rules also require you to report certain data breaches to the general media – a bad dose of publicity no physician needs.

There’s no doubt that converting to electronic health records (EHR) saves space, makes it easier to track accidental or even intentional changes in records, saves you money (eventually), and allows you to coordinate patient care. More importantly, EHR provides the speed required to transmit life-saving patient information. Yet, one of the inadvertent consequences of EHR is the increased potential for security breaches and vulnerabilities.

How pervasive is the problem of PHI record security breaches? Nearly 1.5 million Americans were victims of medical identity theft in 2010, according to the Poneman study. The leading cause is negligence, accounting for 41 percent, up slightly from 40 percent in 2009. The report sampled nearly 1,700 consumers to determine how pervasive medical identity theft is in the United States.

The Ponemon report points to these seven threats to electronic health information:

1. Virus and malware infections
2. Malicious employee attacks
3. Data breaches
4. Social engineering
5. Organized cyber-crimes
6. Regulatory challenges
7. Identity and authentication failures.

The message to physicians is clear: Once patient data goes electronic, you have no choice but to be diligent in strengthening the security, integrity and privacy of this vital data. Your practice must be diligent in securing both the privacy and the integrity of your patient’s data. How safe is your practice from the legal ramifications of security breaches? To find out, answer these questions:

• Is there an audit trail to track every change made to a record, when and by whom?
• Do you have timely access to your patient’s data?
• What is your system to backup this data?
• Do you have a disaster recovery plan which is regularly tested?
• How easily could a hacker break into your system? Where can you find the resources to
discover the gaps and close them?

Consider also that the current climate in healthcare reform means that changes to the rules and regulations are inevitable. We can only expect that security and compliance rules will continue to evolve. Compliance with these rules— issued under authority of the HITECH Act by the US Department of Health and Human Services (HHS) with respect to healthcare providers, and by the Federal Trade Commission (FTC) – requires practices to assess and update their data privacy and security policies and procedures, as well as train all affected staff accordingly.

Encrypting patient data is not required under the federal regulations, but if the data is encrypted, and the data does fall into the wrong hands, the information is unreadable and thereby, safe and sound, and avoids federal prosecution. There is of course a cost to the hardware, software and labor associated with encrypting all of the data on your networks and files. Also, if done incorrectly, it can adversely affect the speed at which you can retrieve data. The approach to encryption is one that must be weighed with a professional IT consultant to ensure the methods of securing data do not impact productivity.

Beyond encryption, there are other data security factors to consider:

• Can patients easily look across a desk to see computer monitors?
• Are employees’ computers password protected? What if someone walks away from a
workstation?
• How often do passwords expire?
• Are printers and faxes located in secure areas?
• What is your procedure for lost laptops or flash drives?
• What about a virus from email or unauthorized software downloads that could breach the
integrity of your network?

As if the above responsibilities are not enough, HITECH also requires a medical practice to ensure the confidentiality of the patient information not only within its domain, but also to make sure that third parties who have access to the same information (outside vendors, laboratories, consultants, etc.) maintain confidentiality.

There are many things to consider in managing patient information. Security and disaster recovery are complicated and evolving sciences. A professional compliance audit can give you an assessment involving people, policies, processes and technology and a detailed gap analysis against HIPAA Security Rule and HITECH, with a detailed remediation plan to becoming secure and compliant in the face of the evolving health care regulatory climate.

Be sure to contact EasyIT, or your technology services provider to schedule an audit and ensure that you are doing what is necessary in order to protect your practice and your patients.

Late Friday morning, the virtual host that houses, amongst other things, the Easy IT Exchange e-mail server for whatever reason essentially lost its mind.  What we could deduce at that time was the RAID (disk drive array) failed and it could not read any of its drives.  Without any drive access, the server was completely dead and e-mail was down.

Technologists have built in many ways for systems not to fail.  RAID is one of them. The concept is you have Redundant Arrays of Independent Disk drives and if one of the drives goes down you just read from another because the data is replicated across more than one disk in the array. It is not normal for all of a RAID array of disks to go down.

Another way to not fail is to have a fully functional backup and disaster recovery appliance (BUDR – http://www.easyit.com/computer-network-products/backup-disaster-recovery-appliance/).  With a BUDR, you can have a bare metal backup (complete server image) of the whole server living resident on the BUDR appliance.  The image of the server is updated every 15 minutes and replicates off-site once a day.  If trouble happens you can turn up any one of those images on the BUDR appliance itself and run as if the production server were still alive.  Next to real time replication, this is probably the best backup solution available in the industry.

So you might ask how can an office full of network engineers with a fairly new server, a RAID array, and a BUDR have a system crash and be down for over 8 hours?  It should have taken less than half an hour to start the image on the BUDR appliance.  No one would know that they were not actually working on the actual production server.  Had our engineers immediately failed the system over to the BUDR, we could have taken our time fixing the production server and ultimately copied the virtual image off of the BUDR and back onto the production box when convenient, such as during off hours.  How a room full of engineers went from ½ hour downtime to 8 hours, while not especially flattering, is a worthwhile lesson to share on how IT works as a mix of technology, people and processes.

Maybe part of the reason is because engineers are a confident lot.  Maybe it’s because engineers jump in to solving problems and only have eyes for the problem.  Maybe it is optimism or ego or any number of things.  We can skip the actual technical details of the problem solving part of the story, but hallmarks of the problem solving included statements like “why don’t we just…” where you can fill in the rest with any number of things, such as resetting drives, rebuilding the RAID, upgrading various firmware, etc.  All of these smaller tasks, while well-suited to solving the problem, nevertheless accumulated until several hours had been invested in getting the box operational again.  You can then add to that testing the box to make sure it was stable and finally copying the virtual image from the BUDR back on the production box.  We were back in production, which is great, but it was more than eight hours later, which was not as great.  Further it was 7 ½ hours longer than we should have been if we had just backed up to the BUDR immediately and solved the real problem off-line.

What did we learn and possibly can you learn from this unfortunate episode?  First, never assume that a new server with multiple fail safes (like RAID) won’t crash and put your business at risk.  Any server or technology can crash.

Second, realize there is a maturity to problem solving that you may have in your own business and you should demand of your IT partners. It involves more than asking how to fix the problem or what caused it (which engineers often care about) and going straight to the business side of it and asking “how soon can you get it fixed?” You can ask for an estimate for how long it will take to get back up and running and not accept nebulous answers like “we’re working on it.”  You can build an SLA (service level agreement) so that you can demand that if we go down we know we will be back up in so many hours so that there is an understanding of what the priority is (be back up and running).  To be fair, the more strenuous the SLA the more it will often cost, but there is often a good balance that can be had.  But asking those questions would force the engineers to think about the problem with a time to production restore element at the top of their minds instead of solving the problem.  Doing the math they might realize that that after getting the production server back on its feet we would want to spend some time testing it and the restore would thus be hours away.  This may have led them to decide to fail over to the BUDR immediately after initially diagnosing the problem.

Lastly, had we not had an image based backup of the server on the BUDR, we would have been down for potentially another 10 hours doing a traditional restore from backup.

As you look at your own system resiliency and IT partners, keep in mind that systems can crash and the way you and your partners are prepared for it can have an impact on your business. Part of the solution is going to be technology, part people, and part process and understanding.

http://www.microsoft.com/business/bposoffer/

The incentive seems to represent a 50% savings.  For instance, when ordering five Business Productivity Online Suite (BPOS) licenses, you get a $300 reward, a 50% savings on the regular $10/user/month license.  Similarly, Hosted Exchange, regularly $5/user/month provides a 50% rebate.   This offer is only good until April 1.

For more information on the growing security threats on smartphones, check out this article from Bloomberg Businessweek.

 http://www.businessweek.com/technology/content/oct2010/tc20101013_611298.htm