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?
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.
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.
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)
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.
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:
Windows and SQL are pretty well covered by the Google (Epicor has quite a bit too).
For Epicor all that you need can be found here Sign In, look for the Epicor10_NewInstallGuide_102400.pdf.
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.
Could you provide me with more information on how to find this referenced procedure. I tried searching in Epicweb under KB0020119 but was not able to find any entries.
Just to add a vote, I recommend a fresh install as well. Also, as @sfarrellPVA stated it does not have to be the same specs as production. Our DEV/Test servers are smaller in horse power.
Thank you. In your earlier post, you decided to cloned all your production VM servers. I am thinking of doing the same. I have a VM for the DB Server+Report Services, Epicor Application Server, and Epicor Reports Agent Servers. Did you encounter any issues with Cloning the Database Server. By Cloning the DB server first and assigning a new IP address and Server name. Could you elaborate an outline of the sequence of steps you followed for all servers?
If you are using Veeam for your VM Backups you can create a Virtual Lab which gives you an exact copy of your prod servers including IP addresses on their own virtual lan. We use this for testing major upgrades.
This was a couple of months ago, so the below is how I remember it.
I closed the app and db server. edited settings to disconnect their nics.
Changed their ip addresses and names, changed from domain to workgroup.
Brought both up with new names and ip addresses, connected the nics and joined them to the domain.
In SSMS changed the SQL server to use the new name. It is simple, but I google the process every time I do itâŚ
Use SSRS Configuration to change to the new server name.
On the app server opened the EAC.
Use Properties to change Endpoint to new server name.
Use Application Server Config to change the database settings to the new server then deployed and dealt with anything I had missed.