Best Practices for Test Envionment E10

Good Morning,
In the process of setting up a test environment to move from 10.1 to 10.2. In the past (previous company), I’ve had an offline server where I had an exact copy of my production environment and SQL server all in one place for testing upgrades before rolling them out. That was fine when I was simply testing everything myself from quote to cash, but now there may be “too many moving parts” for something that simple. I am in a multi-company, virtual environment and will need a few people to test customization, along with DocStar and IQS before rolling out the upgrade. I have one virtual environment set up now where I will set up App, Reporting and SQL. Some recommended making a mirror of my current production environment and simple going through the upgrade process from there before repeating the process with my live environment. Sounds good to me, but I would like to know how most of the admins handle it. Thanks in advance…

Eric
DBA/ERP Admin

Snapshotting your Prod server over to a virtual server and performing your upgrade and testing on that virtual server first is the ideal way of doing it. It will be the quickest method and will let you run the upgrade against your most recent data which will help you if you run into any errors because you will then be able to apply your fixes to your Prod server when you Go Live. It will also help your development team to address any issues using your most recent data.

2 Likes

If the test server is not offline though, do you have problems with IP addresses and all of that being duplicated? asking for friend. (I know very little about servers)

You either have to change the server name or run it on a separate network to prevent network conflicts with the actual Prod server.

You could snapshot and restore your production servers to a separate vlan or within a virtual switch on whatever hypervisor you may be using. this way you can set it up so they are accessible by others and they are separate. Also, they are replicas of your current environment.

1 Like

We use Cisco UCS Blades with vSphere (VMware)

We have a replica environment for:

  • Development
  • Test
  • Train
  • Production (this one being beefed up more)

We also use the Naming Conventions popularized by SAP and others… DEV, TST, TRN, PRD… In SAP there is usually a QAS (Quality Assurance)

Each Environment has the same amounts of VM Machines:

  • Development
    DEV-APP1
    DEV-RPT1
    DEV-SQL1 (Just Epicor DB)
    DEV-SQL2 (SSRS, BarTender, EKM…)
    DEV-SHARED
    DEV-SC
  • Production (this one being beefed up more)
    PRD-APP1
    PRD-RPT1
    PRD-SQL1 (Just Epicor DB)
    PRD-SQL2 (SSRS, BarTender, EKM…)
    PRD-SHARED
    PRD-SC (Service Connect)

Etcetera same for TST and TRN - There are probably a few more I missed. Each one isolated and each one having the same amounts of instances so we can always replicate our entire process. Yeah I could put it all onto 1 Server its DEV, but then again, I wouldnt be able to be 100% certain on testing…

We have a CopyDB Script where we can do

CopDB.vbs PRD DEV

It would Backup PRD, Backup DEV, Restore PRD over DEV, then it will find/replace all \\PRD- strings with \\DEV- and make other changes like change Avalara to Sandbox, Modify our Insite Manifest Paths, Change Some User Permissions (like Developers get switched to Enabled, because not allowed to have access to PRD), Start/Stop Services it needs, Agent, IIS Poll etc…

We also have seperate clients per Environment, so when you install Epicor on 1 PC and you need DEV, TRN, TST - you will get 3 Clients, each one having a Epicor.sysconfig file; this allows us to be flexible during upgrades (not sharing the same client files) and again, isolation/replication/consistency.
2019-02-15_1209


Now at Home I run a Lab with a 32GB Lenovo Thinkserver on 7200rpm drives and I have E9, E10, E10.1, E10.2 all installed onto 1 SQL, 1 OS - 1 CPU… Just a Lab, so I can tinker and learn.

2 Likes

Also just for the record, you can always use Disk2vhd - Sysinternals | Microsoft Learn this tool to convert your OS as its running to a Hyper-V .vhd. It will not affect your OS, simply it will create a .vhd file just like a .zip file =) Ready to be attached to a Hyper-V

1 Like

Our setup is very similar to yours although we have offloaded almost everything to Azure now and are leveraging remote desktops.

Looking at getting a blade setup for something local or just a tower I can keep at home. How do you like the ThinkServer? We used to be a dell shop but have slowly been transitioning people to Lenovo products.

1 Like

I like the ThinkServer I mean I bought the cheapest one I could get for 600$… But if I had the space and electricity… I would probably like to have something like the DELL T-710 or DELL-T310 Series at home. (They are heavy) with a few 15K SAS Drives and Host Hyper-V on it.

You can find them now at 1200$


But the ThinkServer from Amazon, does the job for a Lab. I run 10-15 instances of Epicor on it, (all AppServers running) the only downside it has a low RAM Limit. Perhaps I can find one with dual CPU Slots and 128GB Ram would be ill!

Do you still use PCs or do you use Win Terminals?

If I duplicate our 3 servers, App, Report, SQL and have it on the same network with different server names, as suggested above, is there a tool within Epicor to look for and rename links, etc from our production db to the new server names?

Hi

We have Apps and SQL VM in hyper-V. I did cloning this two VMs, changed the hostname and IP address. This two servers can communicate with each other and also the member of domain. Now I am struggling to connect the Apps server to the database to make this test environment workable. Can you please share what are the changes I need to make in these two servers to get the Epicor workable in test environment.