Test Epicor server - Epicor 10

I am trying to build Epicor Test server. We have 2 servers Epicor Apps and Epicor Database in VM. I already did clone these two VMs then changed the hostname, remove from domain and configure new IP address. Now individually I can login to these two servers and these two servers can ping each other.

I am not that much familiar with Epicor and SQL. Now I need to connect the SQL database from Apps server to get the test environment ready. I tried to login in the SQL database from SQL Server Management Studio using SQL Server Authentication but I can not login. It gives error message “Cannot connect to the IP”…A network-related or insatnce-specific error occured while establishing a connection to SQL Server…"

Can someone please advise or share the process how I can fix this SQL database issue and connect it from Apps server?

Thanks
Sazzad

I tried to go down this route last year and quickly decided that cloning is not the right approach. You will have far fewer headaches and get your test environment up and running much faster if you start with clean server vm’s and then run through the documented installation procedure for a new installation. Then with a much smaller effort, you can restore your production database over the top of the new test environment database.

1 Like

I actually tried to setup a fresh server server in VM but I got it difficult then read some discussion in the forum to get some help. From the forum discussion I saw feedback from others easiest way to build a test environment is cloning the VMs. That’s why I was trying to build the test servers by cloning the VMs as I though this would be easier. Now I am confuse.

I abandoned the clone approach because Epicor could not provide documentation of all the places I would need to change configurations in my cloned Epicor instance to point to the new machine names instead of my production machine names. I needed to create a sandbox environment that could be accessed by any production workstation on my network.

I felt that the risk of cross contamination from my sandbox to production was too great if I started from a clone.

If you can completely segregate your test environment from your production environment – i.e. keep machine names the same, then cloning might be a viable solution.

1 Like

Hi Danvoss I am exactly facing the same problem no documentation available how I can connect the new apps server to new SQL server. In our case the only purpose to build test server is to test the new update or new changes before roll out in production server. We actually don’t need to connect any workstation to the test server. That’s why I though cloning might be the easiest way to do it but now I am not fining any guideline.

The appserver to Database connection is handled on the database tab of the appserver configuration.

We run our Prod and Test databases on the same SQL server (we do not have a huge load on the SQL server) but it’s easier to start with new VM’s for the appservers. Make sure your VM’s have unique hostnames and that your Test/Prod/Dev instances all have unique database and appserver names. this will make it easier in the end. Depending on what modules you are working with, you can backup/restore the production database over the test database (even if it’s the blank stub created during new appserver installation) and run a sql script similar to the attached. This script covers MOST BUT NOT ALL of the configurations points needed to separate the prod from test. You Epicordata directory and other paths will need to be edited for your environment.

Our process is to backup restore Prod over Test each month and run portions of this script. Stop the appservers, restore the prod db over test, run the sql script, regen the data model, restart the appservers, ‘fix’ the task agent for test. That’s the whole process in a nutshell. And I do this on an entirely separate machine each time I want to test a patch/upgrade too.

WARNING - the attached script is not perfect, NOR can be run in its entirety at any time. EDIT it before use. UNDERSTAND what it does before use.Post Upgrade Settings.sql (8.5 KB)

2 Likes

I have cloned my VMs and changed the setup on the Test versions and they work. No matter how you do this you have to do parts of the setup and deploy for the new configuration to point to the rights app and sql servers. There is KB0020119 on Epicweb that goes over steps that could need to be performed, but again configurations will vary, so you have to be able to adapt this to your environment.

1 Like

My personal opinion is build it from scratch. Dev/Test environments are made to be just that. I have done both and have seen some pretty catastrophic issues with cloning, even with them on separate networks it’s just a dirty way to do it imo.

For Testing I build one reasonable beefy VM, nothing crazy but enough to unpack compressed files quickly and load tables into memory on deploy. My ideal VM sits on an SSD, 32gb RAM (not super necessary and mileage varies based on DB size), i7 or decent Xeon with at least 4 cores allocated to it. Windows Server 2016 (you can get a 180 day trial if you don’t have licensing), SQL 2016 also (you can get the full thing for free in Dev environments). Create your base VM,install Windows + Roles and features (IIS, file services, etc.) and SQL, followed by reporting services, then take a back up. From there mimic your lives environment from a drives and directories standpoint and then install the latest RL (found on epicweb). Open the admin tool, connect your Database server, Add new DB, Create new App server, add a company, add your license (can be the one from Prod), verify you can login, then update to the latest UD. Install and create a task agent make sure that starts (might need to give your user impersonation rights). Next thing you can do is take a backup of your prod DB and restore it to that DB you created before, depending on how closely you modeled your app servers to your prod environment I would recommend creating a new app server to connect to your restored prod DB. Verify Login, update as necessary and your off to the races, don’t forget to clean up and kill prod Agent tasks such that people aren’t getting erroneous emails and files aren’t being accidentally overwritten. The more you do from the beginning the better you will understand it in the end, and the better off you are from a troubleshooting standpoint.

Side note the performance and diagnostic tool is your friend, it has a config checker that will help tweak you identify areas that need to be fixed or adjusted after you complete the install.

Edit: As far as documentation is concerned:

1 Like

Hi Sean thanks for sharing the steps. Did you configure both Apps and Database in the same server?

Thanks Mike for your response.

Sure do, strictly for my test environment though. Keep in mind your test environment doesn’t need to be an exact copy of your live unless you dictate it needs to be.

Thanks Sean