Splitting our Epicor, SC and SQL Server Recommendations

Hello All :slight_smile:

I maintain an Epicor server that has E10, Service Connect, SQL and Reporting all installed on one physical server - win 2012.

The company that providers our IT support are looking to virtualize this server but also split it into two servers: One for SQL and One for Epicor/SC/Reporting.

I’m happy to go ahead with this and do the install etc… but I would like to keep the current Epicor Server DNS Name the same on the New Epicor Server so my questions are:

  1. I need these to run side by side whilst I complete the migration over to the new servers, so would renaming the new epicor server AFTER the install cause issues? The main reason I want to keep the server names the same is that my boss doesn’t want to have to update his reports (anything to make his life easier), is this possible?

  2. People who have done this before, do you have any tips and recommendations that I should do/follow for doing this? Would you keep the same App Servers or recreate new ones and deloy them to your users?

My Plan of action is this:

  1. Take backups of everything.
  2. Spin up a Server and install SQL and configure.
  3. Spin up another server, install and configure Epicor, SC and Reporting
  4. Confirm working.
  5. Rename Epicor Server to old server name and turn off old server
  6. Test Epicor usage from users machines - not sure if Epicor would as the new server would have a new app server but I’m hoping to keep same App Server name (E.g. ERP10-Live).

What’s everybody’s thoughts?

  1. For users check and update config file only.
1 Like

I don’t specifically know what will happen if you change the server name after installations, but I can’t imagine that going smoothly… Can Production go down for a weekend while you do the migrations? If so you can disable NIC on old server so that you can spin up the new one with the same name while it’s offline.

Still, I would recommend new names… Fresh installs on Server 2019 or 2022, go to SQL 2019, fresh everything. Restore Epicor db from backup to your new SQL Server instance. Restore the SC db or create a fresh db during installs and port over your workflows manually.

Also I think the recommendation is to keep SQL and reporting on the same server as long as you allocate enough resources to it.

Make sure the SQL VM has separate disk drives for database, t-logs, and tempdb. And probably another for backups.

2 Likes

Is 2022 certified by Epicor yet? Hot patching (when available) would be a very nice feature.

1 Like

Good catch, looks like 2022 is not certified yet as per the New Install guide for the latest Kinetic release.

1 Like

Your point still stands. It’s a really good idea to do a technology refresh and start with clean running servers.

2 Likes

@duncan - I’ve done this before, sort of, so I’ll chime in with my 2 cents :slight_smile:

My advice would be to install everything on three NEW servers - Appserver, SQL, and SC - and use DNS to your favor.

To make sure that your new server cluster works you’ll need to configure everything with a copy of your Production database copied over to that new SQL box. There are a handful of posts/responses here showing scripts that can be run (like moving from PROD to TEST) and I have one if you need it. You can use this script to record all the special locations referenced in the database that contain a server reference (there are many) depending on your modules/products in use.

However - changing to a split server scenario only sort of works for you… Presently the sysconfig and the reports point to the same server name (in DNS). If the boss’ custom reports go direct to the database - you’ll have two servers so you’ll need to decide how much work you want to do. Either the reports will need to change to the new SQL name, or redistribute a new sysconfig file to the clients using the new appserver name. Depending on you decision about reports or sysconfig, what’s next varies. Either you need to create a DNS alias of the old appserver name pointing to the new appserver or do that for the SQL Server.

Lastly, you could take this opportunity to fix the sysconfig AND reports to use a DNS alias for all the servers and de-couple those from the actual servers - while the servers refer to each directly.

2 Likes

Honestly, I would much rather have new server names and keep it all fresh as opposed to battling with it. I may just go down this route and have new server names.
I would like the new servers and old servers to run at the same time so I can jump between them and double check setting etc…, so I can’t really see any other way than giving the new servers new names.

Yeah, I meant to put SQL and Reporting on the same server, I got ahead of myself there ha! Good catch.

I plan on putting Databases, t-logs, backups all on separate drives away from the OS drive. Same with Epicor install and data files, they will be separate from the OS drive.

Licensing is the issue for 3 servers, we can only have two unfortunately, otherwise I would have that exact setup you recommend :slight_smile:
Could I get a look at that script? I usually just move the Database manually but a script would be great.

Some very good points about DNS there and the reports. I will get a decision on the reports and then take it from there. Thanks for your input, that’s great.

There are some other posts on the site that cover the topic of moving a copy of Prod to Test (or some variation), but here’s the script I posted before - TestEnvironment on same server as Production - #7 by MikeGross

There might need to be some tweaks for recent modules - Collaborate, QuickShip, etc…

1 Like