Select Page
12 Days of ECHO, Seventh Day: My Admin Gave to Me, Tips on Epicor ERP 10 Server Disk Space!

12 Days of ECHO, Seventh Day: My Admin Gave to Me, Tips on Epicor ERP 10 Server Disk Space!

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

Epicor ERP 10 Server Disk Space – Where’d It Go?

 

Do you ever wonder where your server’s disk space goes?  Many times, you might not even notice until a server crashes with an ‘out of disk’ error message, or some application stops working.  Only then might you start digging around and find that a volume is out of disk space.  Proactive monitoring is essential, and if you sample free disk space once a day for a month, Excel will tell you when you’ll run out of disk space.  However, if you proactively monitor and cultivate your disk usage, your server will reach a general stasis and disk usage will remain relatively constant.

 

A disclaimer – if you never purge old data and keep every document, sales order and schematic from the beginning of time, you’ll keep buying more disk space.  However, disk storage is cheap, management of it is expensive!

 

If your Epicor Terminal Server runs lower than about 6GB free, Epicor.exe will start throwing errors.  You don’t even have to be THAT critically low before that will start impacting functionality and performance.  Disks that run low on space suffer fragmentation, and even on an SSD drive, the work of allocating new disk space on a mostly full volume hurts!

 

So what are the common culprits in an Epicor ecosystem?

  • IIS Logs (see our prior holiday report on IIS Log Sprawl)
  • SQL Transaction Logs (report coming soon)
  • Enabling Epicor server tracing in the Admin Console can be helpful, but the C:\inetpub\wwwroot\app\server will grow with those logs quickly!
  • The share called \\appserver\EpicorData stores many files; bad BAQ’s, BPM’s, and reports can leave large files here.
  • Server administrators often to download patches and new versions, extract them and forget to remove the downloads and extractions when done with the upgrade.

 

Here’s an example over a month of a SQL server transaction log volume.  Guess what day was a bad day?  And to boot, it was at midnight, when everyone was home, not watching the servers.

How can you manage this?  Use a tool like TreeSizeFree (from JAM Software) will quickly reveal the disk hogs, and the built-in windows tool forfiles.exe will make short work of removing the old files.

 

You can also use a management tool like EstesGroup Managed Services does and gain visibility into the critical component long before it becomes a problem in your business.

 

 

If you liked reading the “Seventh 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.

12 Days of ECHO, Sixth Day: My Admin Gave to Me a Fix for Microsoft IIS Log Sprawl!

12 Days of ECHO, Sixth Day: My Admin Gave to Me a Fix for Microsoft IIS Log Sprawl!

by | Dec 16, 2019 | Epicor 10, ERP, Network Administration, Prophet 21

Microsoft IIS Log Sprawl: Getting Away from the Sprawl

 

On the Sixth Day of ECHO, my admin gave to me, some tips about Microsoft Internet Information Services (IIS) and log files!

 

Every Epicor E10 and Prophet 21 Middleware server uses Microsoft Internet Information Services (IIS) to get the job done.  And by default, IIS creates a log file on the C: drive for every day it’s running. Often we can see how long a server has been running by counting IIS log files. However, chances are great you don’t ever look at those log files! Therefore, we recommend disabling the IIS logs in IIS Manager to save the I/O and disk space. If you need the logs for auditing, we suggest putting them on another volume and marking them with NTFS compression for best performance.  After that, a weekly script to delete the oldest files will keep things neat and trim. FORFILES /P C:\inetpub\logs /s /*.LOG /D – 30 “cmd /c del @FILE” is my go-to command. 

 

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

ECHO is EstesCloud Managed Hosting. What does that mean and what does it have to do with Microsoft IIS Log Sprawl? What doesn’t have to do with cloud-based data strategy these days? EstesCloud brings you all the security and reliability of cutting edge technology, and you don’t have to maintain it or worry if it’s compliant or it’s going to crash. We take on the worries, so you can focus on your business. (This might even allow you a little free time to look at your Microsoft IIS Log Sprawl if you like.)

 

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, 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, First Day: Relating Epicor Extended Tables via SysRowID

12 Days of ECHO, First Day: Relating Epicor Extended Tables via SysRowID

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

On the first day of ECHO, my admin gave to me, some notes about my SysRowID! 

 

Relating Epicor Extended Tables via SysRowID 

 

As part of an ERP implementation, it’s not uncommon for companies to find the need to store information that does not easily fit into the ERP system’s existing database schema.  Fortunately, Epicor ERP offers a robust ability to extend an existing database table and add fields to store custom data, to better address the requirements of an implementing company, and The Estes Group’s Echo hosting platform completely supports these critical capabilities.  

 

On the technical side, adding UD fields to an existing table actually creates a new table in the Epicor database, a table that is structured to relate back to the original “parent table.”  While two tables exist at the database level, the data model at the application level presents the two tables as a single unified entity, which allows customers to interact with the standard and custom data through BPMs, BAQs and form customizations, as if they were working against a single table. 

 

While this capability is of great utility, there are times when an ERP administrator may have a need to compare child and parent tables, for administrative purposes.  As such, it is helpful to understand the architecture for relating standard Epicor tables to their UD children at the application and database level.  The following example intends to serve this purpose.  

 

Adding UD fields to the Epicor ERP application is done though the “User Defined Column Maintenance” form.  In the following example, I added a UD field to the standard Epicor ERP Part table: 

Once UD fields are added to one or more tables, the administrator needs to regenerate the data model from the Epicor Administration Console on the AppServer.  In the example, I regenerated the data model as follows:

Performing the above tasks adds a “Part_UD” table to the Epicor database:

It also synchronizes the application’s data model with the database:

In the following example, I went on to query the Part UD table.  Note the “ForeignSysRowID” field—as you can see, the key to a UD table is based on the SysRowID of its parent, since the records of a UD table exist in a 1-to-1 relationship with their parents:

As such, if you join the Part_UD table to its parent Part table where Erp.Part.SysRowID = Erp.Part_UD.ForeignSysRowID, you will receive results similar to the following:

Whether on premise or in a hosted solution such as ECHO by EstesGroup, Epicor’s database extension capabilities are of great use to implementation teams and end users.  For ERP admins, an understanding of the underlying structure can serve to assist in managing the database and the application, should the need arise.

 

If you liked reading the “First 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 data, UD or otherwise?  Please feel free to Contact Us and see if we can help get your bits and bytes in order.