Select Page
Data Center Location is Critical to Your Company’s Success and Survival

Data Center Location is Critical to Your Company’s Success and Survival

Looking California When You’re Feeling Minnesota: Where is the Best Data Center Location?

 

For manufacturing companies, the advent of “cloud computing” has raised a lot of questions.  Luckily, you don’t have to wander lonely as a cloud to find answers to your questions surrounding cloud solutions for your business.  Not as complicated as a cumulonimbus or as feathery as a cirrus, a cloud in the field of technology is as simple, or as complicated, as someone else’s computer.  But of the many questions a manufacturer may have, one frequently surfaces in relation to the location of the data: “So where is my data located, anyway?”

 

This isn’t a small squall of a question: if you are looking for an on-premise installation or a server stack in the cloud, your primary and secondary data centers’ location is a decision of atmospheric proportions—one with direct business impact.  

 

Whether choosing hosted or cloud solutions, your data center location is critical.  You must be wary of where exactly your data center servers are located, for all clouds are not created equal.  Downtime is the great fear when it comes to all things computing, and is often the result of natural disasters—and do you remember how long it took to get the power grid functioning in Puerto Rico after hurricane Maria?  Clearly, minimizing the risks of mother nature is a central concern.  Let’s take a down-to-earth look at some of the natural dangers facing your company’s data.

 

Earthquakes

 

When I worked in Arkansas a number of years ago, in an area that was on the edge of the New Madrid seismic zone, I noticed the strange cross-bracing in one of the factories, and I asked a local about it.  He explained the seismic risks in the area, and recounted the family lore about the quake of 1812.  Then he looked me square in the eye and said, “Whatever you do, don’t blame Arkansas—it wasn’t our fault.” 

 

It can be a surprise to discover that one the largest earthquakes in North America’s recorded history was not along the California coast but was actually along the New Madrid seismic zone in Missouri—of all places!  This was the quake that briefly caused the Mississippi River to run upstream back in 1812, the year almost exclusively famous for the conflict between America and England.  But while the Americans were locked in battle with the British on the East Coast, they were unwittingly losing the war with nature in the Midwest.   

 

This might serve as a warning if you locate your data center in a seismic zone—if your server gets death-rattled into oblivion, it’ll be your own fault.

 

 

Tornadoes

 

Nothing can lay your blades out like a deck of 52 quite like a tornado.  Tornadoes pry open buildings like nature’s proverbial can opener, allowing copious rain and debris to decorate your server room like a third grade art project, and you don’t want to see your data garnished with nature’s glitter.  Tornadoes pose a risk not only to your data center itself, but they also tend to knock out your primary—and even your secondary power supplies.  Backup generators are often located adjacent to a building, making them a potential target for mother nature’s twisted wrath.  So while a twister might leave a building unscathed, it might take out your external generator, rendering backup power systems useless.  Of course, that’s a moot point if the contents of your data center are laid out across the lawn like your laundry, for all to see.  Luckily, a proper data center location can help you avoid an unfortunate game of 52-pickup.

 

 

Floods

 

I reached out to one of my customers after a series of tornadoes ripped through Oklahoma, and he gave the all-clear: “The twisters missed us, but the water levels are so high, some folks can’t get into work.”  That is to say, a natural disaster can be more sneaky than a weather channel headline.  While things like tornadoes get a lot of attention, water levels can do a lot more damage over time.  As such, one might think twice about locating a data center on a floodplain.  While all my gamer buddies are hyped over water-cooled CPUs, I don’t quite think this is what they’re referring to. 

 

 

Hurricanes

 

Hurricanes amount to the worst of wind and water, with the ability to pummel your data center into paste from above, or dissolve it into a silicon solution from below.  And while the zone immediately affected by hurricanes is rather small, the extended zone where hurricane-related storms transform into inland berserkers is much larger.  Locating your stacks in a place that is far-removed from the hurricane fallout zone will serve you well in reducing wind and water risks. 

 

 

Heat

 

Another sneaky disaster when it comes to all things electronic is heat.  Not too long ago, I was in Charlotte, NC with a coworker.  One morning after breakfast, we were about to head to the customer site when my coworker ran back into the hotel to retrieve his coffee mug, leaving me in the parking lot.  I stood out in the morning heat for maybe a minute or two.  Now, being a Canadian, I generally overheat reading the newspaper, and the morning temp in Charlotte was obliterating.  By the time we got to carpooling, I was already a puddle.  And this was still in the early morning!  Servers are like Canadian consultants—they work better in temperate climates.  When choosing a shack to hang your racks, look to locate it in a place where your cooling systems won’t be fighting a losing battle with the heat index.  Servers generate enough heat on their own—they don’t need any help! 

 

The Cloud

 

While the notion of “The Cloud” brings with it visions of the ethereal, it is in reality quite terrestrial in nature.  Hosting a customer’s ERP system is a huge responsibility, and not one to be taken lightly.  The cloud itself can be just as risky as a hurricane.  As such, the EstesGroup is all about maximizing service while minimizing risk.  In support of our Epicor Hosting initiative, we keep our data center located in Michigan, which has a favorable climate for keeping servers cool as a cucumber, while avoiding the many environmental pitfalls noted above.  Moreover, by having our data center location in the Midwest, we provide centrality that allows us to rapidly service a broad region.  With optimal location and cloud infrastructure, the team at EstesGroup can serve your business needs by providing ideal solutions for your data, regardless of the weather. 

 

If you find yourself looking to the sky for answers to your worldly business questions, please give our team a call.

Epicor ERP and Your Anti-Virus: A Love-Hate Relationship

Epicor ERP and Your Anti-Virus: A Love-Hate Relationship

I’ve seen enough of Epicor ERP installations to know that a finely tuned system needs… fine-tuning. Perhaps that’s obvious, but nonetheless, I’ve seen many deployments where Epicor ERP is installed, but not set up optimally. One area that has my bits all scrunched up is anti-virus, sometime called anti-malware, or malware protection. I’ll just call it anti-virus for purposes of this discussion.

Each vendor does it a little differently, but there are three primary aspects to worry about.

  1. Real-time scanning
  2. Scheduled scans
  3. Injection into an application

 

Depending on the tool and the configuration, you might have one or all three at play, on both your SQL and Epicor ERP servers. Done right, they’ll do their job, keep you protected, and stay out of your way. Done wrong, and your performance, reliability, and up-time will suffer.

Now, in my humble opinion, a dedicated, patched, protected, and behind the firewall SQL server needs no anti-virus – it’s not a file server, nor a SharePoint server, nor do any end-users directly interact with it. Your installation might be different, check your exposure! Anti-Viruson a SQL server, improperly configured, will just slow it down and give you headaches. If you can avoid it, do so. Of course, your company policy might require AV installations on ALL servers. Please follow Microsoft’s guidance for choosing anti-virus software to run on SQL Servers, including their exclusions. Some AV software will recognize SQL and exclude automatically, but don’t assume that to be the case.

Epicor ERP is another animal. By definition, an Epicor ERP application server is also a file server and is often exposed to the internet in some capacity. Therefore, in addition to your firewalling, patching and backups, make sure to protect your Epicor ERP Application servers with anti-virus – with the proper exclusions.

Some anti-virus platforms let you do the exclusions on the end-point, others require a central management console. Many enterprises have a team to handle it. Either way, set up the exclusions and then test them by dropping a copy of the test malware Eicar (from eicar.org) into one of the folders. The file won’t execute (since it’s an OLD win16 file), but if AV is scanning that folder, it’ll pluck it out and you’ll know AV is active in that folder.

Replace the X: with the volumes you’ve deployed Epicor ERP on. Not all installations will have all these folders, depending on the extensions and add-ons deployed.

X:\Epicor* X:\Program Files (x86)\Common Files\Epicor Software Corporation* X:\Program Files (x86)\Common Files\Epicor Software* X:\Program Files (x86)\Common Files\Epicor* X:\Program Files (x86)\Epicor Software* X:\Program Files (x86)\Insite Software* X:\Program Files (x86)\Seagull* X:\ProgramData\Epicor Software Corporation*

X:\ProgramData\Epicor* X:\ProgramData\EpicorSearch* X:\InsiteShip* X:\APM* X:\Applications\EKM* X:\BarTender Formats* X:\BarTenderData* X:\BarTenderTaskList* X:\Program Files (x86)\Insite Software* X:\inetpub\wwwroot\(Servers) – replace with appropriate folders X:\inetpub\wwwroot\(Servers)-(extensions) – replace with appropriate folders

Don’t forget the Epicor clients – whether they be full Windows clients or Terminal Servers:

C:\ProgramData\Epicor* C:\Program Files\Epicor Software* C:\Program Files(x86)\Epicor Software*

 

Looking for assistance with your Servers? Contact Us and don’t worry, we’ve got IT covered.

 

Ransomware, a Good Way to Stop Your Business. Or Maybe Not?

Ransomware, a Good Way to Stop Your Business. Or Maybe Not?

I just need to get this off my chest – so bear with me. 

First off, I’ve been doing sysadmin work for scores of years now, and the idea of backups, business continuity, and “bad guys” isn’t new.  However, this week it was brought to a new and interesting head for one small business. 

Rewind the clock two years and we were in the conversation with this business about where they host their “golden nuggets” of their business, what servers did what, where were the users, how did the backups fare, state of malware, web filtering protection, etc.  You know, all the “normal” stuff any qualified IT provider would ask a prospective customer. “We’re fine” was the answer – they had an in-house IT guru watching all that stuff.  However, they did make a (wise) decision to host their ERP solution with us.  

Last week, our monitoring went suspiciously quiet, it looked like the company went on vacation, or they had fallen asleep at the keyboard. I reached out to the company, and was informed that they had been the victim of the latest ransomware attack, and all their documents were encrypted and unusable. Thankfully, since they were hosting their ERP system with us, that was safe from the attack. All their ERP data was secure but everything else they controlled was locked. Backups proved unreliable or inaccessible, so the ransom was paid. The company got lucky and the recovery key worked and they got their documents back.  What they didn’t get back was Active Directory.  Ouch!  Nobody could login, even though their documents were back on a server, nobody could access them. 

A week later, a new domain, and new profiles on everyone’s desktop, new shares, new permissions, and they were back up and running. After everything, the company is back to doing business, but it could have been a much worse situation. A critical note: the ERP system was never at risk and no ERP data was lost since that was safely stored elsewhere. 

Moral of the story: 

  • Test your backups. Not just documents, but the whole server.  How long does it take to get it back? It should not be more than a few hours.
  • Just because you can restore files doesn’t mean you can go out, buy a new server and restore your existing workload onto a new server. 
  • If you can’t live without it, and you don’t have the in-house expertise to manage it – outsource it! Let the pros handle the critical IT while you do what you do best: making essential product and making your business grow. 

 

Contact Us to learn whether Hosting is right for your company.  

Learn more about EstesGroup’s EstesCloud Hosted ERP here… 

Defining and Setting Up ID Codes in Epicor ERP

Defining and Setting Up ID Codes in Epicor ERP

Setup is Critical – Take Time to Plan First

ERP Deployment

Please Note, this is Part 1 or a 2 Part Blog.

Whether you’re a user, a seasoned Consultant, or a new Consultant, you know that setting up ID codes in Epicor ERP is critical to the basic setup and configuration to all applications in the system.  You may also know, that once an ID Code is created, it becomes a Primary Key field in the database, for mapping purposes.  The code is also a way to filter and group large amounts of data, for reporting.  The frustration comes when there is a transaction against this, and you find out very quickly that it cannot be changed.

This is the primary reason why setting up these codes should involve some thought and planning.  In Epicor ERP, you are limited to eight characters. 

Part Numbering Schemes

Consultants and clients alike, typically use one of the following types of ID Code schemes:

  • Non-intelligent – Also referred to as “non-significant.” The ID code is generic and does not provide any information about the group.  Non-significant ID Codes are typically created in a series, (typically in numerical order), regardless of the group or reference. Using this ID Code system, a code could be assigned an ID Code – T100. 
  • Intelligent – Also referred to as “significant.” The ID code contains descriptive and informative details that provide significant information about the group.  With this type of scheme, an ID Code is generated for a Part Class, might be “RES” where “RES” stands for resistors.

 

Which scheme should you use?

In any manufacturing organization, establishing an ID Code should be an efficient and accurate process. Consider your current and future operations when selecting which type to use. Here are some pros and cons of each:

 

Advantages of Non-Intelligent ID Codes:

Using this type of scheme will save your organization time upfront. You can ramp new employees quickly, avoid relying too heavily on any one person and maintain the system without much overhead. Here’s how:

  • Time savings:  It takes little to no time to pull a sequential ID Code for a group.  Moreover, most of the setup is complete before cutover, and any additional setups are added on an as needed basis.  Assigning an ID Code can happen fast.  You do not have to put much thought into what the code should be as it is completely generic.
  • Little training needed:  If the organization hires new employees, they will not need to learn how to define an ID Code and can focus their attention on other tasks.  Assigning a new ID Code can happen with little training.
  • No single point of failure:  To rely on a single person who knows and understands the coding schema, which was established in the past, means you sometimes must wait to assign a new ID Code.  With non-significant ID Codes, you can easily have multiple people create them.  NOTE:  Since this is part of “Setup” in all application of Epicor ERP, Security group settings and rules should apply.
  • No “back-tracking” or having to redo setup and configuration:  Since the ID Code is non-intelligent, and since you cannot change an ID Code once it has been established, you can always reuse the code for a different group by simply changing the description.  This also avoids the dreaded “DO NOT USE” definition description when ID codes are created and cannot be deleted.
  • Simple maintenance:  It is easy to maintain this type of scheme, as it’s essentially a sequential list. You will not have to decide where and how a new ID Code fits into the scheme.

 

Disadvantages of Non-Intelligent ID Codes

Using a non-significant ID Code scheme isn’t completely error-proof; mistakes can happen, especially if data entry is involved, and managing similar parts can be difficult. Here’s why:

  • Potential for errors:  Because it doesn’t have meaning, a non-significant ID Code does not provide any cues to help a user evaluate a group.  If a ID Code is manually created, even an experienced person may fail to spot a data entry error.  ID Code E100 could inadvertently be entered as E001, with no frame of reference for a user to determine if the ID Code makes sense in the context of other data, the error will likely go unnoticed.
  • Difficulty managing ID Codes:  Without common prefixes, this type of ID Code scheme may require more work to maintain.  You’ll need to track additional metadata (descriptions) to define your codes and then use that information for grouping or searching (and for reporting) since the ID Codes do not provide identifying information.

 

So the big question is… Is Your ID Code Schema Costing You Money? 

Continue reading about Intelligent ID Codes’ pros and cons in our next blog: Is Your Epicor ERP ID Code Schema Costing You Money? 

Integrity is Key with Epicor ERP Customizations

Integrity is Key with Epicor ERP Customizations

An ERP system is like a person or a house: without integrity, you can’t put your trust in it.

 

One of the great things about Epicor ERP is its openness to customization. That feature can also be a source of trouble. It’s all in how you use the power.

 

Strictly speaking, you can’t directly modify Epicor’s software without a special Software Development Kit. Changing the base software opens the proverbial can of worms and has lots of ramifications we won’t discuss here, so what we’ll be talking about is the traditional “customization layer” the 99% uses.

 

Terms to Remember:

 

Business Object (BO). Data manipulation is governed by Business Objects. You hand the BO a dataset and let it figure out how to care for the data’s integrity, rather than writing directly to all the tables in the dataset.

 

There is a “Part” business object, for instance, that governs the Part table and its dependent tables. It won’t let you change the base unit of measure for a part if there is any activity like transactions, open orders, or open job materials for a particular part so you don’t, for example, make an material’s on-hand quantity of 10 Each suddenly 10 Gallons, or orphan transaction history by deleting the part.

 

Embedded Customization. Also known as a “screen customization” or just “customization” (client side) that sits on top of a form such as Part Maintenance. You can add a new field on the screen and attach it to a data source or use C# code to add and modify events happening inside the form to suit your business practices.

 

Personalization. Similar to the customization, the personalization is a user-made modification that sits on top of the form/screen customization (that sits on the base software). They’re mostly used to modify field placement, grid layout, etc. to let the user see and arrange things in a way useful to them.

 

BPM. Business Process Management Method and Data Directives (server side) modify data actions triggered by events on the form. They are typically accessed in record updates, new record creation, and so on. The Part BO has many methods like add, update, and delete, so you can say, “when this thing happens to the data also do this other thing,” or “when we create a new record add this thing to it.”

 

In generic terms, a typical Epicor ERP session works something like this:

 

  1. An Epicor form loads with standard (out of the box) data views, operations, etc.
  2. Epicor then looks for a screen customization and applies it on top of the standard form.
  3. Epicor looks for a personalization for the current user to layer over the form and over the customization, if any.
  4. The form displays and allows the user to do things.
  5. BPM – Method and Data Directives (server side) hang around and wait for the appropriate signal to take action, say, when you click the save button.

 

This is what I’m calling the customization layer–the places Epicor gives us to add in/change functionality.

 

So, where’s the danger? Here’s an example.

 

When we store data changes through Epicor’s Business Objects, we trust the BO to keep us out of bad trouble. But the data is stored in a SQL Server database, and it’s possible to go outside of Epicor and write directly to that part table or delete records via SQL commands without checking any dependencies. It can be much faster, in the same way ignoring the speed limit in your car can get you home sooner. Maybe you won’t corrupt your data. Maybe you’ll make that turn on four wheels.

 

There are occasions and circumstances when it’s okay to skirt the rules.

 

Rarely, something gets stuck and the BO won’t let you correct it, so a SQL fix is in order. Since directly using SQL commands on your database can invalidate your Epicor service agreement, I’d recommend doing it with one of Epicor’s folks on the phone.

 

Some simple tables and some fields don’t have dependencies that the BO cares about. It’s possible to take a more direct approach within Epicor—when you know what those are.

 

This topic comes up periodically when we developers talk amongst ourselves. In our company, the standard is to operate from within the Business Object unless there’s a compelling reason for something different.

 

Integrity is worth the extra effort.

 

Questions about Epicor ERP Customizations? Are you planning a customization project and have questions for the author? Let us know.