Upgrade warning-10.2.600

Make sure you go to atleast .10 - had some other minor bugs that, make now sense (with MES).

@kfierce Were you able to resolve the 404 error when trying to print, We are currently in the middle of upgrading to 10.2.600.9 and are seeing the same behavior.

@Bridget_Casey1 - happy we connected over the weekend. Good luck on your work week.

2 Likes

Hello all,

We went live on 10.2.600.9 over the weekend. We have ran into a couple of issues.

The biggest issue is when printing ANY SSRS report whether it was standard or custom it would intermittently fail with an error of RunTask:
System.Net.WebException: The request failed with HTTP status 404: Not Found.

In our test database we did not see this error and I think it is because we went from 10.2.300 to 10.2.600.5 and then put the .9 patch in last week and no issues. Over go live weekend we upgraded our database from 10.2.300 straight to 10.2.600.9.

@kfierce solved a similar issue with 10.2.600.9 by shutting off kinetic before ever seeing the HTTP status 404: Not Found error.

To resolved our issue we backed up the test database that no users were in yet and moved it to prod and immediately shut kinetic off before seeing the HTTP status 404: Not Found.

A couple of small things to also be aware of.

  1. Our payment methods for AR were no longer connected to our bank accounts.
  2. Attachments have been moved out of company maintenance and now have their own table. This change does not allow users to attach documents without having a document type selected unless you set up an attachment type maintenance like below.

Thank you @kfierce for your help this weekend!
Hope this helps!

3 Likes

The problem is that your .net framework did not update to 4.8. if you look at your web config file. search for supportedruntime, you will see the SKU will reference 4.0. This is not correct. it should be 4.8. This seems to be an issue with the upgrades. Epicor support couldn’t tell me how to prevent the issue. To resolve, you will have to remove the old Application Server and create a new one with the exact same name. I have down this a few times and it only takes 10-15 minutes for my application server (no Epicor extensions, just SSRS).

Backup and CSG files, custom reports, etc.

  • Remove asp.net web pool
  • Remove web directory
  • Remove from Local Clients
1 Like

You should always do this for any non-patch level upgrades:

  1. 10.2.300 to 10.2.400
  2. 10.1.500 to 10.2.200

The only time I dont do it is for patch level 300.15 to 300.27.

3 Likes

How does one install the new version for testing on the same server?

Say I currently have 2 Apps (both 10.2.300) on my production server\\App01. They are PRD_102300 and TST_102300. SQL is in a different server, \\SQL01. DB’s are also names PRD_102300 and TST_102300. And we’re upgrading to 10.2.600.

My plan would have been to:

  • Install 10.2.600 on \\App01
  • Duplicate DB PRD_102300 as TST_102600 (Notice the number change)
  • Update DB TST_102600
  • Create App PRD_102600 on \\App01, pointing to TST_102600

After testing was complete, the real upgrade would be to copy PRD_102300 to PRD_102600, and then redo the steps that I did to get PRD_102600 running with DB TST_102600.

But it sounds like 10.2.600 doesn’t want to run if and earlier version is installed. So how to test the version while keeping the current version running?

1 Like

Just make a new instance

image

I have like 23 instances.

  1. Copy PRD_102300 SQL Database to TST_102600 SQL
  2. Register the Database TST_102600 in Admin Console (when you do this it should ask you which snap-in version you want)
  3. Upgrade TST_102600 via Admin Console (Database Node still)
  4. Add New AppServer TST_102600 and point it to DB TST_102600 (this will also ask you which snap-in version you want)
  5. Login and it’ll ask you to run Conversion Workbench, do it
  6. Setup Task Agent stuff… etc done.
3 Likes

So if you create a new App server for 10.2.600 (with a different App name), then previous posts about having to remove the prior version don’t apply?

It’s only when trying to upgrade an App that was originally created with a prior version?

1 Like

I may have taken the wrong approach for our .600 upgrade but I spun up new servers (VMs) for it. Here’s how I got our .600 test/dev environments going. This worked fairly well. There were a few little bumps in the road but I figured those out. When it’s time to the PROD .400 to .600 I would do the same thing.

  1. Installed .600 RL on new VMs
  2. Copied our PROD .400 dB to a new .600 DEV dB
  3. Added the new .600 DEV dB to the EAC
  4. Ran the dB upgrade to get the dB up to .600
  5. Add a new app server and deployed a .600 DEV app
  6. Ran the conversion workbench to go from .600 to 600.10
2 Likes

Damn. Wish I saw this 28 days ago, lol.
Nuked ours too.

2 Likes

At least it’s not just me

Thats what I understood from reading the last comments, if you modify the existing app server to point to the new installation the issues happen, so creating a new one should avoid those.

Well, I had a backup, but I had to create a new 10.2.200 server to reload it to. Time consuming, but less so than creating and remembering the BPMs from scratch!

1 Like

Check your Customized Grid Columns!

Heads-Up if you have Grid Layouts, your columns order may be jacked up, in many screens, messing with Paste Insert, Paste Update templates your users may be using.

Not sure what the reason or benefit for this change was:
in 10.2.600 they remove the LayoutXML old VisiblePosition and then they store it in ColumnFilters XML Node, and your customization xml goes from 2mb to like 4mb in size.

They don’t even migrate your old VisiblePositions to the new, but just remove it.

It literally shuffles you around:
image


@JeffLeBert do you know of the benefit for this, in prep for Kinetic?


Check your columns folks.


Thats a lot of addition of junk, bloating the XML (the Customization Download speed etc)…

400 vs 600

Do we really have to store the colors, appearance etc… some x coords…
image

Sorry, I haven’t worked in this area in years. Prep for Kinetic sounds like a good guess, but for me it is only a guess.

1 Like

I created a brand new base in 400 and 600 and then customized it to simply move 1 column and saved it.

10.2.400: File Size: 14kb, 243 lines
10.2.600: File Size: 912kb, 12,225 lines (yikes)

doesn’t Epicor pay for I/O in Azure, won’t this double Epicor Cloud costs? :smiley:

My Order Entry went from 2mb to 9mb, all because I have increased the Description field on 5 grids.


10.2.400: File Size: 14kb, 243 lines
10.2.600: File Size: 912kb, 12,225 lines (yikes)

Update:

Maybe this has been like this, for a while and I just happen to be still on the 10.2.400.x version where the following bug was still not fully patched:

So, I am now noticing the bloat because, when you have that bug, it didn’t bloat it.

I tried it on my local 10.2.300.17 copy and it bloated like 10.2.600, yet 10.2.400.12 didn’t bloat, which works in my favor because its just junk, o well.

Maybe that’s why my columns have been through a washing machine and shuffled all over the place in 600. But then again, it removes the old VisiblePosition or doesn’t honor it, unless you move your stuff and Save Layouts again. (still a bummer).

Task Agent 10.2.600

Has anyone had any gotchas with the Task Agent? We just had an odd one where it wouldn’t start and even with verbose on the agent enabled, it didn’t log the cause. Then we made a slight change to the TA Schedule (basically trigger an update, uncheck, check a box) and the Agent started fine.

Leaving this out here in case anyone else sees anything. For now unexplained mystery.

I had the same issue actually. I ended up just reinstalling the task agents as I couldn’t figure out a way to get them going.

1 Like