That (along with reading the text in the guide) looks like we could install 10.2.300 on a virgin server (which will become our new App Server). And then use the database server manger to: Upgrade, Keep, Remove, or Take No Action , on the existing DBs on the SQL server.
Does the Upgrade action strictly update the DB on the server, or make a copy and update the copy? In other words, are you supposed to make a copy of your 10.x DB, then either:
Upgrade the copy,
or
Upgrade the original and point the previous versions App to the copy. Assuming you want access to the previous version.
Are there issues to consider when changing the App Name and/or DB names?
What is the first “New Server” ?? For running Task Agent?
Edit: I’m probably confusing the term “server”. I tend to think of the box (or VM instance) running the O/S.
There’s another underlying issue. We’re having problems with the current App server crashing. Not the Eppicor App instance, but the box it runs on. So copying that server to a new one, as not going to happen. Plus they’d like to update the O/S from 2012/R2 to 2016.
Our environment we have 1 VM server that hosts the App Server and DB
So we created a
New Windows 2016 VM
New 2016 SQL Server DB
Installed 10.2.200
Which means App Server and Task Agent
Plus EDD, Enterprise Search, Report, Education, and the other fun stuff
I agree with Ken. It really is pretty painless. Just stand up new app / sql servers. Copy your db over to new sql server (advise upgrading to SQL 2019 / Server 2019 when they are out later this year), and install epicor app front end fresh.
I would advise waiting a little if you can for 10.2.400 which is supposed to drop in May and should be certified for 2019 SQL/Server
Ask your CAM for the Epicor ERP Analyser. It is free. You will get a great report on customizations, BPM, BAQ, and other things that might not be documented. I used it as a checklist as I tested 10.2. features.
We are working on this same sort of upgrade path from 10.1.600 to 10.2.300 (I think I’ve decided to wait for .400 now after Insights - I hope that’s the right choice).
We just created a brand new VM where I installed 10.2.300 completely from scratch. I have SQL, AppServer, and Task Agent all on the same server and that works for us.
I’m using SQL Developer Edition on this new VM. I bring over a copy of our Live Database and perform an Upgrade against the copy. When we decide to “Go Live” I’m planning to change from Developer Edition to our licensed version of SQL on this new VM.
Keeping it all separate with a new VM just seems to make things so much easier for us.
Make a copy of your 10.1.400.23 database, then in the App Console register as an existing db but for the ICE version use the 10.2.300 (or 10.2.400), not the 10.1.400 version. Then you pick Upgrade which use the scripts to take you to that release.
I would make the DB and AppSever names different (even if you are on a new O/S Server).
Besides reports, you will most likely have to tweak/change BPMs and UI forms as well because there was .NET version change going from 10.1 to 10.2.
Or use the Customizations dashboard that is somewhere here on the forum! I found it easier to list everything out using that rather than the analyzer tool
So after creating the New 2016 SQL Server (again, is this on a separate OS than the App Server?), do you copy the current DB from your old SQL server to the new one?
If it’s not too much trouble could you describe it with the “computer name” (as far as Active directory is concerened)? For example our current setup is:
computer USDATAPS00122 is running 2012/R2, and hosts the E10 App Server
computer USDATDBS00001 is running 2012/R2, and hosts the SQL Server 2014
We’d like to make a new server (say USDATAPS00234) running OS 2016, but continue to use the existing SQL server USDATDBS0001.
@ERPSysAdmin - how “big” is your system (# of users, and DB size)? I ask as we’re tiny (15 users and the Production DB is about 11 GB) and I was afraid of running the App server and SQL server on the same OS.
We have a 215GB database and we have 60 Regular and 60 MES Epicor licenses.
We have been running for a year and a half with SQL, AppServer and TaskAgent on the same server with no issues. We do have a second TaskAgent running on another server just for a backup in case the main one goes down (recommendation from @aidacra).
I’m not real clear on why you would want to run the Epicor AppServer on a different machine? But I would think it would be for a much bigger use case (Larger SQL DB size and #users) than what you have…since SQL is a memory hog, maybe just to give the Epicor AppServer some more room to work.
Where’s @aidacra when you need him? He explains these things so well…
Yes, it is just for if the Task Agent on the main server goes down. I think back in the earlier versions of 10 there were a lot of problems with the Task Agent stopping or getting hung up which would cause all other processes sent to it to fail/hang. So it was recommended to us to create at least one other Task Agent just in case. Here is a post that explains this in more detail:
Where are you located @ckrusen? Just wondering if you might be close enough to come to the MI/IN EUG to see @aidacra’s presentation which will cover some of these topics and best practices for SQL, AppServer, TaskAgent setups!
You guys have a really good EUG out there already, don’t you!? Have you gone to any meetings?
That would be great! Would love to meet you and shake your hand and say, “Thank you!” for all the help you’ve given to me on this site. (Along with so many others!) Promise we won’t pull you up on stage at the Grand Ole Opry and make you dance with FloRida-Georgia Line or anything. (A little Insights-Inside Joke. LOL! )
I’ve done a similar upgrade to a test server in Azure that you are describing and what Ken pretty much said is the process I went through.
It was relatively painless and I was able to get it done within a few hours. My test environment is regularly upgraded to new versions of Epicor, SQL, etc. and I usually use my 10.1.400.38 DB as a baseline for the upgrade testing.
I would definitely create a backup of your DB and do a test run at first.
I also have a task agent running on a separate server and it has helped quite a bit when reports on task agent stop processing. It has saved me a lot of time of having to keep an eye and restart the services.
We have about 60ish users and our main Epicor DB is roughly 70GB. When we moved into Azure we built all new servers and upgraded from Server/SQL2012 to Server/SQL2016 as well. It might seem daunting at first but the upgrade process is quite smooth considering.
@ckrusen - didn’t realize you and I were only a couple hours apart - I’m just west of DC.
I agree with all the info you’ve got, but I’ll add this - We’re running a combination of all of these questions/answers if you want to talk more about it. We’ve got production environment on two VMs, pinned to a host for performance, plus we’ve got two test/dev environments that are all-in-one boxes (appserver/db/etc on one), plus I’ve got a second production appserver just to serve up the mobile/web parts. And I’ve got some cool SQL scripts for doing prod-to-test copies to keep things up to date. We’re at 150GB DB with about 80 users world wide.
)