Everest Server & Environment Setup and Optimization
Over the past 20 years, the team at MARTEC360 has been on the forefront of complex server deployments with Everest ERP Software. This stems from our early history / background after originally upgrading from Accware for DOS to Everest 1.0 alpha as part of a large Consumer Electronics (computer systems, parts, peripherals) distributor. We have been through the good software version releases as well as those which were rather problematic in the early days.
Along the way we have identified server and application optimizations which have gone undocumented for years and helped 10’s of hundreds of merchants to gain efficiency through consultancy/support, new eco-system deployments, as well as virtualization and private cloud implementations.
Below is a sampling of frequent questions which we routinely get from clients running Everest, ranging from version 2.x up through the latest version of v8.2.x. Should you have a question and not see it listed below, feel free to reach out and contact us. If you are in need of some consulting on your existing environment and need an Everest eco-system audit conducted or professional support services to help optimize your existing environment please take a look at our business support services page related to our process.
Everest ERP & Server Eco-System FAQ’s
Everest ERP versions 4, 5, 6, 7 and 8.x are all supported in our environment by our team of engineers in the MARTEC360.
See our business support services page for our process. A typical eco-system audit starts with between 5 to 10 hours of LOE (level of effort) depending size, nature and complexity.
Yes – to a degree. We will not provide hardware support or installation unless within our Private Cloud for Everest.
Assuming your IT hardware folks or managed service provider can give us access via RDP to your Active Directory Server (ADS), Database Server and Application Server(s) once they hardware and OS has been stood up, then we can/will configure everything from there under business support services.
Depending on version of Everest this changes.
For version 5.x & 6.x, Everest 2008R2 Server Standard Edition or Enterprise/Data Center Edition. SQL 2008R2 Standard or Enterprise.
For Everest 7.x and above, Windows 2016 Standard, Enterprise and Data Center. SQL 2016 Standard or Enterprise.
If one is looking for more than 32GB of memory support (larger database sizes, larger numbers of users, or targeting faster performance) then the Enterprise and/or Data Center editions should be considered.
We can use TeamViewer for very limited access. There are problems with access / management to some configuration settings within Windows which creates challenges for our professional services teams.
If Microsoft Remote Desktop cannot be made available to our secure network environment / IP address, then we typically request access via Google Remote Desktop Instead with a shared Google/Gmail account such as [email protected].
Through extensive optimization and testing spread across a variety of accounts over the past 20 years, MARTEC360 has settled on Microsoft Remote Desktop Services (RDP) as the primary remote configuration for all versions of Everest. Additionally, with the remote application deployments (part of RDP), so long as a user does not need the Outlook interface for mailing documents from Everest, then the “Client” can sit via RemoteApp on ones remote workstation and communicate efficiently with a cloud/wan deployment.
While a number of organizations have attempted to roll out Citrix remote deployments, the speed and performance in the client application layer is deprecated too greatly to consider it a viable solution.
We have run into this question or concern a lot. The answer is it depends on what is happening in the environment and the business.
- For each 20-25 concurrent users, we find that it is best to silo them onto a separate application server. This is typically by department so that should one department have an application error, it impacts them only – not the entire organization.
- If there are 3rd party integrations in play such as FoxFire WMS, TrueCommerce EDI, KnowledgeSync CRM (CRM Studio), other integrations or SDK/API applications performing extensive automation capabilities then we strongly suggest they be on their own application server. This is so that should these components/solutions have a problem they are isolated from the application servers and client users … similarly, if the application server(s) being used by clients have any type of problem it doesn’t adversely impact the SDK/API integrations.
First, while it is technically EOL from Microsoft, they are still publishing patches and security updates for Windows 2008R2. Second, if you are in private cloud environment with the network security and firewalls locked down then Windows 2008R2 is perfectly healthy to continue to run on for quite some time ahead.
Believe it or not, here in 2020, we have limited support agreements with multiple accounts which are on Everest 2.x & Everest 3.x which means they are running Windows 2000 and SQL 2000 with few if any problems.
It is all about Total Cost of Ownership (TCO) and maximizing ROI. One should not need to consider a re-platform simply due to operating system support. Anyone which advises “make a switch now because Windows isn’t supported” is selling fear.
The answer to this is again – it depends on a variety of factors:
- How many users do you have?
- How many customizations do you have in Everest form designer for your customer, item, and document profile screens?
- Do your users have “save on exit” enabled in your heavily customized document profile screens? … there are reasons why one should not have this enabled…
- How many application servers do you have deployed?
- and How many 3rd party applications or SDK/API are being utilized in the environment.
What we have found as a general rule of thumb:
- in AWS environments, the Z1D systems should be used for database servers because of their inherent hardware based acceleration for the SQL temp DB
- in most Everest environments, the speed limits are not at the SQL/database performance side of things. Usually, the speed impacts are at the desktop/client layer of the application. For this reason, MARTEC360 tends to recommend our Private Cloud for Everest environment as a total piece of mind solution which can be tailored to your speed/performance needs. This is because MOST organizations we work with which host “in-house” have one big server which is virtualized with either HyperV or something else. The big server is most frequently something in the realm of a 2.x GHz CPU with between 2-8 cores. By simply going up to a 3.1 Ghz – the performance on the client can increase. By going up to some of the faster sustained CPU rates, the performance at the Client level can jump considerably. For one merchant/distributor – stop watch speed tests were performed and by simply going from a 4 core 2.4 Ghz with 32GB of memory to a 2 core 3.3 Ghz sustained processor with the same 32GB of memory – the performance of “browsers” more than doubled and the speed of customer, item and document profiles increased by 3.5x.
A note related to server memory:
Windows Standard Editions and SQL Standard Editions only support 32GB of memory. If you have more than 32GB in that server, congratulations – you are wasting $ by having the extra memory. In Windows Server Standard editions, it will not recognize it at all. If Windows is Enterprise / Data Center Edition and SQL is Standard Edition – congrats, Windows will get to have more memory which it doesn’t really need while SQL will be capped at 32GB.
Let’s start by defining what these 2 options are.
Virtualized environments are where organizations invest resources/dollars into one big server. Maybe an eight (8) core server with say 2.4GHz processors, with 96GB of memory and 1 TB of disk space or more on an SSD RAID 5 / RAID 10 array. Sounds like a decent hardware environment to run everything on EXCEPT that server is likely to cost something in the neighborhood of $15,000-$20,000 by the time its all done AND:
- database servers need disk speed & fast memory access, better yet, hardware layer memory access to SQL temp DB’s.
- web servers need fast disk speed & fast CPU’s/processors (and in some cases many of them) or the server load balanced for scalability.
- Everest application servers need mostly memory and some CPU however there is little to no disk operations to create latency.
- Everest end-user clients which actually physically “use the software” … they need ~500GB per user profile (if using RDP) for Windows resources + Everest usage needs if a heavy user. Moreover, the end-user clients really need CPU speed, the faster the better. In a study conducted by MARTEC360 for a client moving from their local environment to our Private Cloud for Everest, we were able to speed up the client by over 227% by simply increasing the clock speed on the RDP client-server.
- and you still need local IT which fully understands the 3 tier architecture support needs of the system and how to optimize each server for their respective performance needs.
In a Private Cloud environment such as the fully managed solution MARTEC360 has put together for clients – the entire eco-system is rolled out in a virtual private cloud. In our case, we have partnered with Amazon Web Services (or AWS) as our backbone. The benefits of going this route from a performance and optimization perspective are considerable:
- each server can be spun up (created) to serve its specific role.
- you do not need to pay for “extra” utilization for an Active Directory server or a file server when those can be inexpensive T2-Large devices (approximately $80 a month before storage) or even less on the hardware side.
- a database server could have something like a Z1D or M5D class which is highly tuned for SQL
- an application server can get its needs met without needing the disk speed, CPU or memory requirements necessary to meet the SQL demands
- an end-user client RDP server can go light on disk speed, fast on processor with the necessary memory limits based on what’s needed for your # of users
- if some of your end-user RDP clients need super fast access and the others can live with 2-4s longer lag, no problem, bring on a super-fast client-server for those which need it and have a T2-Large for those users which do not require blazing speed.
- you can easily scale from SQL Standard Edition (which has a 32GB memory limit) to SQL Enterprise without having to “rebuy” the software all over again if/when your needs grow.
- you have a team that doesn’t work after 6 pm and before 6 am on client/application servers? Cool … in an optimized private cloud environment we can auto disable those servers during the off hours. What does that mean? It means you just cut your bill in 1/2 for that server each month because for the hardware you’re only billed for when it is “on”. It is a consumption model.
While virtualizing is better than nothing. The cost certainty, total-cost-of-ownership (TCO) and ROI of moving your ERP eco-system into a professionally managed private cloud with the redundancy and scalability options which it brings is the #1 reason why a private cloud environment should be more strongly considered vs investing in your own on-premise virtualized server.