Wait 5-10min, done anytime, anyday, on-demandā¦ Some simple basic cloning scripts, sql backup / restore scripts, and POST Copy Modify all these tables, permissions and paths.
No Admin Console. No ODBC. No SSMS, even for your SSRS database.
As for Data Regen, this is an area of improvement.
IMHO, this should be like Azure, this should be on a Portal or Dashboard. Go to your Portal, request a Data Regen. Boom. But currently, you fill out a ticket. I also usually schedule it with the ticket beforehand.
So if we were to go a new server route, who you recommend virtualization under a Hyper-V host? We currently are all physical servers with no present virtualization. When I was talking to our Epicor reseller the tech mentioned doing a VM but having the OS on RAID 1, and Data on RAID 10. For every virtualization platform Iāve setup itās always been on one big array of RAID 5/10. I canāt imagine splitting up VHDX files on separate arrayās would be beneficial at all.
Everything on one big array though, correct? He had said doing a separate RAID 1/5 for OS and RAID 10 for DB, which, I canāt see being beneficial on virtualization.
Thats typically how I build them out too. When the vendor suggested separate arrays for virtualization it made second guess myself. Maybe they confused physical with virtual.
Having installed, configured and administrated both on prem hardware, and cloud based (Azure NOT Epicor hosted) i am a big proponent of on prem if the scale ability makes sense for you. I seen better performance on prem, they donāt suffer service outrage from telecoms etcā¦ and i agree with @hkeric.wci comments regarding ROI and reliability as well as performance. When we consolidate our facilities next year i will be making a push to go to on prem rather than remain in Azure. I believe we have a 100 mbps pipeline and with VOIP we struggle some days for various reasons.
When we switched over, we paid Epicor to rubber-stamp the server spec and set the environment up for us. We had got a lot of conflicting advice, some of which even I knew didnāt make sense, and Iām no IT admin, so it was worth spending the extra for us. Even then, it took a few weeks of tinkering to get the performance as it should be, though I have to say our Epicor man did crack it in the end and itās been great since.
But the experience has made me wary of advice on the subject of Epicor environments, wherever they are. Itās a great idea being able to sign off responsibility onto a third party, but you are then in their hands, which is incredibly frustrating if something isnāt going as it should.
It sounds as though youāre inclining towards moving on from the server you have, though? That wasnāt a foregone conclusion at the start of this thread.
New server would be worse case scenerio if the upgrade for some reason performs miserably on what we currently have; though reading most of these posts I donāt think that would be the case. Azure platform is 99.9% a no-go. I really think vendor is pushing it because of the monthly revenue they gain from it.
If you are getting new servers I wouldnāt worry about storage. MSSQL 2019 will support Persistent Memory which is the holy grail of DBās since all data will just live in āRAMā and persist between reboots. HP is a big partner and you should start seeing servers rolling out soon.
Weāre pseudo-on premises. Our parent company has a data-center in Georgia (the US one, not the Russian one). but our facilities are in PA, TX, OK, and CO.
The APP and DB servers are virtualized. Most users run via TS. Only a few users run the client on their local machine.
Weāre really small (only 15 seats), so doubt weād see much performance difference based on the data-centerās physical hardware.
All things being equal you should not need a new server hardware. That being said, I have seen issues using 10.0 and 10.2 (app) on the same server, same admin console, which prompted me to build new servers (VMs) for 10.2. I would recommend this track. At the very least a new Appserver will keep your environments separate. Azure has nothing to do with it unless you lack the resources to deploy in-house, and it would increase your reliance on external communications. IE redundant WAN connections and increased bandwidth requirements.