Select Page
12 Days of ECHO, Fifth Day: My Admin Gave to Me Too Much RAM for My Epicor VM!

12 Days of ECHO, Fifth Day: My Admin Gave to Me Too Much RAM for My Epicor VM!

by | Dec 13, 2019 | Epicor, Epicor 10, Managed IT Services, Network Administration

Too Much CPU & RAM for Epicor Application Server

 

Sometimes, more memory is not better.  Often, server admins will throw more resources (CPU and RAM) at a server to make it go faster.  Check our tidbit on SQL Licensing to see what that might hurt your licensing model, and in general, with SQL, the more RAM the merrier.  There is a decreasing return on investment however, and when it comes to your Epicor application server, we often see clients who over-commit resources and cause hypervisor performance issues.  Assuming you run in a virtualized world (as most of our clients do), over-committing CPU and RAM can cause the host machine to ‘thrash’ and actually run slower than if you had less resources.  For more details, search on NUMA boundaries and “memory ballooning”.  Check your Epicor application servers, if they have a lot of unused RAM and low CPU utilization, you might be a victim of over-committing resources. 

 

If you liked reading the “Fifth Day of ECHO” return to our main list to read all of the other “12 Days of ECHO” posts.

 

Do you have questions or need assistance with your Epicor system?  Please feel free to Contact Us and see if we can help get your bits and bytes in order.

[pardot-form id=”856″ title=”Blog Forms Submission”]

12 Days of ECHO, Fourth Day: My Admin Gave to Me Tips on SQL 64k Clusters!

12 Days of ECHO, Fourth Day: My Admin Gave to Me Tips on SQL 64k Clusters!

by | Dec 12, 2019 | Epicor, Epicor 10, Managed IT Services, Network Administration, Prophet 21

Tips on SQL 64K Clusters and Epicor SQL Services Database Bytes

 

Microsoft SQL likes to do all its input/output in 64k chunks, but Windows likes to format hard drives in 4K chunks called “clusters”. Studies have shown that formatting the volumes that store SQL databases and transaction logs benefit from 64k clusters – up to 35% better performance!  To check what your cluster size is, open an Elevated Command Prompt and type “CHKDSK D:” (where D: is where your databases are stored).  The line with “xxx bytes in each allocation unit” should say 65536, and not 4096.   

 

If you find your server admin formatted with the default 4096 allocation unit, then changing is easy – just kick everyone out of Epicor, shutdown the SQL services and backup the entire volume.  Then, reformat with 64k clusters and do a volume restore.  Restart SQL services (and your Epicor Task Agent) and let the users back in! 

 

Sound like too much for you to handle? 

Give us a call or send us a message, and our Database Admins’s would be happy to assist. 

 

If you like this tip and trick post, please read our other 12 Days of ECHO.

GET MORE TIPS FROM OUR CLOUD SERVICES TEAM NOW

About the Author

Daryl Sirota has served for 35+ years in IT, both as a sole proprietor and as a senior team at System Source, and now as VP of Managed Services at EstesGroup. He loves to travel and currently resides near EstesGroup headquarters in Loveland, Colorado.

Daryl Sirota – VP, Technical Services
12 Days of ECHO, Third Day: Some Notes on Epicor ERP Auto-Login and SysConfig!

12 Days of ECHO, Third Day: Some Notes on Epicor ERP Auto-Login and SysConfig!

by | Dec 9, 2019 | Epicor, Epicor 10, Network Administration

On the Third Day of ECHO, my sys admin gave to me, swift yet safe: Auto-Login in Epicor 10.1 and beyond.

 

Interacting with technology can become a perpetual struggle between ease-of-use and security-of-use.  The two seem at odds, such that increases in security reduce the ease-of-use, and vice versa.  I once worked for a company that increased security after a user opened an infected email attachment and blew up her computer.  Thereafter, all email attachments were cloud-scanned before anyone could open them.  Safe—but now it took an extra five minutes to view an attachment.  We used to joke to ourselves that our network admin was going over the files byte-by-byte with a pair of tweezers in one hand and a scalpel in the other.

 

That is to say, Epicor users generally like things quick and dirty, while admins like things safe and clean.  Early versions of Epicor adhered to the quick and dirty principle: In early versions of Epicor, automatically logging into Epicor, in the absence of a single sign-on setup, was relatively easy—it was as simple as plugging the user ID and password into the .sysconfig file:

<userSettings>

<!– provide values for UserID and Password to enable auto-login –>

<UserID value=”manager” />

<Password value=”manager” />

 

This capability was especially helpful for those interacting with the system via Epicor’s Manufacturing Execution System (MES) or Handheld (HH) clients.  But storing plain-text passwords in a configuration file has long been anathema to system administrators.  As such, starting in version Epicor 10.1, a number of changes were made to improve Epicor’s security architecture.  As part of this effort, the ability to store passwords as plain-text in .sysconfig files was removed.  It was replaced with a more elegant means of achieving the same ends through the application itself.  The setup requires steps from both the Epicor administrator and the end user.

 

Epicor Administrator:

 

To allow users to auto-login, perform the following steps, while logged in as a security manager:

  • Open the “Password Policy” form (located under System Setup > Security Maintenance).
  • Select the “Allow save password” checkbox and save.

Epicor End User:

 

For those who intend to utilize auto-login capability, users must save their credentials in the following manner:

  • Log into the workstation as you normally would, using your Epicor username and password.
  • From the Epicor Homepage, click the “Settings” tile:
  • Select the “Preferences” option:
  • This will open the Preferences window. Select the “Automatic sign on” checkbox and click the “OK” button to commit the changes:

The next time the user logs in, the auto-login functionality will be invoked. 

 

Note: The above user steps can only be done after the Epicor admin has performed the necessary prerequisite steps, else the user will receive the error below:

As part of our ECHO Epicor managed hosting solution, we’ve helped a number of customers migrate from Epicor’s older config file-based methodology to its current auto-login configuration.  The above configuration is a one-time “set it and forget it” activity, which allows the user to utilize the auto-login functionality without issue.  In this way, Epicor has devised a solution that improves security without impeding ease-of-use—it is swift, yet safe.

 

If you liked reading the “Third Day of ECHO” return to our main list to read all of the other “12 Days of ECHO” posts.

 

Do you have questions or need assistance with your Epicor system?  Please feel free to Contact Us and see if we can help get your bits and bytes in order.

[pardot-form id=”856″ title=”Blog Forms Submission”]

12 Days of ECHO, Second Day: SQL Licensing

12 Days of ECHO, Second Day: SQL Licensing

by | Dec 9, 2019 | Epicor, Network Administration, Prophet 21

On the First Day of ECHO, my System Admin gave to me, SQL Licensing!

 

You probably already know that Microsoft SQL Server is required for Epicor 10 and Prophet 21, but do you know if you are in Microsoft compliance? SQL licensing can be confusing, but in most cases, it can be broken down to either “by core” or “by user”.  There is an exception for SQL Enterprise licensing on a hypervisor, but that’s a specialized case. Most smaller organizations use SQL Standard Edition, as opposed to the more expensive and capable Enterprise Edition.  Likewise, most Epicor clients use the “By core” licensing model as opposed to the “by user” model. 

 

In short, if you are running SQL In the “per core” licensing model, each 2 cores that are available to the SQL server must have the appropriate licenses – with a minimum 4 cores.  If you have more than one SQL server, then you must have a minimum of 4 cores licensed PER server!  Keep in mind that the SQL Engine and the SQL Reporting Services are both licensed software, and if they are split to different servers, they EACH must have appropriate licenses. 

 

We’ve seen instances of clients who increase their SQL Server CPU core count to see if they get faster processing, but often end up violating their license agreement and creating expensive problems when Microsoft Auditors come knocking.  Likewise, splitting the SQL Engine and the SSRS functions will increase your license count. 

 

One small consolation prize – multiple instances of SQL on the same OS do not require additional licensing beyond the first instance.  Therefore, you might find some benefit to running another SQL instance on the same server to split queries.  (See our future blog 11th Day of ECHO: Separating OLTP and DS – detecting and avoiding deadlocks) 

 

The downside is that all SQL licenses are on an honor system – the application does NOT keep track of licenses, so it’s your job to make sure you’re in compliance! 

 

Till next time, keep the holiday cheer! 

 

If you liked reading the “Second Day of ECHO” return to our main list to read all of the other “12 Days of ECHO” posts.

 

Do you need assistance managing your SQL licenses or database administration?  Please feel free to Contact Us and see if we can help get your bits and bytes in order.

[pardot-form id=”856″ title=”Blog Forms Submission”]

Understanding Epicor ERP’s “Default Revenue Recognition Method” Error is Part of Company Configuration

Understanding Epicor ERP’s “Default Revenue Recognition Method” Error is Part of Company Configuration

by | Dec 4, 2019 | Epicor, Epicor 10, ERP Risks and Challenges

Revenue Recognition is Everything

When I was still part of the user community, I was involved in a planned implementation of Epicor at one my company’s divisions.  The division was in the construction industry, and the ERP systems of the time routinely encountered gaps in addressing the business requirements that come out of construction management environments.  This was back in the days of Vantage 803, and at the time, Epicor’s construction management capabilities were rather thin.  

 

To address this yawning void of a gap, a large customization was in the works to allow for increased revenue recognition (or “rev rec”) functionality as part of Epicor’s Project module.  This functionality would eventually find its way into Epicor’s base package, but at the time, all anyone at my company could talk about was “rev rec”…  “We can’t start prototyping until rev rec is ready.”   “There’s no point in testing until rev rec has been implemented.”  Everywhere I went, all anyone could talk about was “rev rec.”  Still rather green in general and quite new to the business models of the construction industry, such shorthand was immensely confusing: Just what exactly is revenue wrecking?  Isn’t revenue a good thing?  I was befuddled. 

  

I wasn’t the only one.  As is the case with many of such monumental customization projects, all of these discussions were in vain, as the division never came close to going live on Epicor—though the functionality that came out of this failed attempt was pretty cool!  Many years later, I’m still quite oblivious to the intricacies of the construction industry, but I have managed to get past one annoying revenue recognition error when setting up a new company in Epicor.  As part of initial company configuration, I’ve encountered the following “Default Revenue Recognition” error message a number of times: 

The message reads as follows: “Default Revenue Recognition Method cannot be None or Blank when not allowed to be changed per project.”  Well, that’s not especially helpful, especially given that the error normally surfaces when configurating another area of the applicant, such as the Modules > Production > Job area above.   

  

As it turns out, the cause of this error actually resides in the JCSyst.DfltRevRecMthd field, as found on the Modules > Services > Project Billing tab: 

Selecting a method is normally sufficient to get past this error, though additional setup may be required, depending on the method selected.  Even if you don’t intend on using revenue recognition, this step is necessary, depending on the modules licensed.  So don’t let revenue rec your company configuration—set your default revenue recognition method and move on to bigger and better things… like deciding whether or not to schedule into the past!  Now that conversation requires three cups of eggnog and a game of twister—so I’ll save it for another day. 

Have questions about Revenue Recognition Methods or Company Configuration? Let us know below or Contact Us today.

Getting Past the “CGCCode Mismatch” Error When Importing Dashboards in Epicor 10 ERP

Getting Past the “CGCCode Mismatch” Error When Importing Dashboards in Epicor 10 ERP

by | Nov 26, 2019 | Epicor, Epicor 10, ERP

In work and in life, I find myself torn between two ambivalent instincts: the instinct for understanding and the instinct for action.  It is often of great utility to understand as much of a given situation as possible—to be able to relate its causes and effects.  I think back to my Six Sigma days, to years of enlightening multi-factor designed experiments.  While this kind of understanding is summoning in itself, sometimes you simply don’t have the time to design an experiment to be in the know.  Sometimes you need to go straight to action itself as knowledge. 

  

The life of the ERP administrator is often torn between such directions of learning.  The Epicor 10 ERP admins out in the user community that I’ve met over the years are some of the most knowledgeable people when it comes to navigating Epicor 10 ERP’s ins and outs, and I’ve learned much from their deep understanding of the application, from the end-user’s experience, all the way down to the application’s lower–level functionality.  But admins also understand that if something needs to happen by morning, it needs to happen, and have therefore developed an appreciable measure of pragmatism as to be able to triage situations and “git er done” as needed. 

  

One such circumstance occurs when importing dashboards, especially when the dashboard is coming from one company to another or from one version to another.  In my own practice, I have a bundle of old favorite dashboards that I have developed over the years, going back to my own time in the user community.  And over the years, I’ve doled these out to customers, to assist with issues that they are experiencing.  In so doing, I have, on occasion, encountered the strange “CGCCode mismatch” error upon import.  Here’s how it happens: 

 

I follow the normal protocol of importing a dashboard definition: 

But I receive this quarrelsome application error message in response: “There is CGCCode mismatch.  Dashboard export created with CGCCode=US.  Import cancelled.”

One could talk at length as to why this error occurs without coming to a specific answer.  While I don’t have a good explanation of the source of the issue, I do know how to get rid of the error, as to allow the dashboard to be imported. 

  

Opening the dashboard definition in Notepad, I search for the “CGCCode” tag: 

I locate the nearly “PropertyValue” node and discover that the value is “US”, as was specified in the above message: 

I delete this value and save the definition: 

Thereafter upon subsequent import, the dashboard will load successfully.  While I think it’s optimal to know a situation’s underlying causes and effects, sometimes circumstance demands simplicity.  As such, if you’re in need of getting a dashboard loaded on a timeline, and need to get functionality in front of the user community in a hurry, this little hack might be just the trick for fixing your CGCCode mismatch error in Epicor 10 ERP.

 

Are you having issues with, or have questions about, your Epicor 10 ERP Dashboards or Technical areas? Contact Us today. 

[pardot-form id=”1302″ title=”Ask Us”]