DB Refresh Rules of Thumb

I’m looking for comments regarding account/db copies and task agent names

Our particular installation happens to be a two application server setup,
one application server where the LIVE, Test, Pilot and Train dbs are
and one application server where an extended group of Test dbs are (A/B/C/D/E…) are

And the copying process seems to get “balled up” on occasion

I’m trying to determine best practice when copying databases - such as
WHEN and HOW the actual name of Task Agent needs to change

  • given sometimes the copy is on the same server and sometimes its on a different server.

So when “copying” a DB from LIVE to PILOT - which are on the same server
Does the task agent need to change - or should the task agent name change

and when “copying” a DB from LIVE to TEST-C - which are on the different servers
Does the task agent need to change - or should the task agent name change

I understand the answer is in the details - so i’m looking for Typical/Best Operating procedures here.

thanks

As a consultant can you not reach out to the Epicor hosting team? I would think that they have best practices and automation scripting as well.

In our case, we have a Task Agent for each instance which simply allows for a bit more flexibility. That means we delete and recreate the task agent each time we refresh a database from production. We also run a lengthy script to change permissions, meta data locations, URL’s for EWA/EMA/Search/etc. Each script is specific to the instance we are refreshing.

Now I’m scared…

When I copy LIVE to TEST (both on same App Server), all I do is:

  1. Restore a backup of LIVE, to the TEST db
  2. Go into the launch the E10 of the TEST db, and update a few things:
    a. Change Company name to !!! TEST COMPANY !!!
    b. Turn off Tax Connect (we don’t have a sandbox)
    c. In the Task Agent, delete scheduled tasks that auto print and auto email
    d. Change the theme so the TEST environment is visually different from the LIVE one.

Both our Live and Test environments share the same SSRS repository. So changing a SSRS report layout would show in both environments.

I assumed since most logs and files created by the server usually include the company in the path, that there was no need to worry about a log or user file (created in the Test Environment), conflicting with one created by the Live environment.

I also rename all my printers to a fake printer or a test printer, so we don’t auto-print to production. ACH Paths. Attachment Paths, so we dont delete attachments from PRD.

We also clear the Ice.BpAction and Ice.BpActionQueue tables and the Mail Queue so we don’t get stale session errors for Async BPMs.

2 Likes

ok - i assume then when you delete and recreate the task agents to give them instance names
such as TaskAgentLIVE or TaskAgentPILOT … that you also delete and re-create the schedules?

and particularly, if your using MCD, you recreating them with different log files

when you change the theme - do you use a script or do you edit it manually

I just like EVERYTHING to be separate. I also do what Haso does, and set all of my agent schedules to disabled, clear the IntQueIn and Out tables (multicompany queues). And some other stuff like change the company names…

I think it depends a lot on what functionality you use. Like you mention Tax Connect - good point as we will be using it in the near future so I’ll add that to my script as well.

1 Like

I created the Theme in the LIVE company - but it’s not set as the default. So in the Test company, all I have to do is make that one the default.

I’ve seen others do it with a Script / SQL

1 Like

I guess my main concern, is about not creating a new Task Agent.
The fields in System Agent Maintenance are identaical between my LIVE and TEST companies - except for the Client Program Directory. Which contains the environment in the path (ex:. c:\inetpub\wwwroot\MC-UAT\Server), and is read-only.

What risk am I taking?

agreed.

i assume you’re clearing the InQue/OutQue tables on the TARGET database :wink:

it is my understanding (correct or not) - there IS no difference in the TASKAGENTNAME
the key is as you stated - that the CLIENT PROGRAM DIRECTORY must match/point
to the URL in the TASK AGENT PROPERTIES - which indicates the appropriate application pool

but also there are SOME items which SHOULD be separated.
For ONE - PAUSE/disable the TASK SCHEDULE - and copy/refresh the TASK SCHEDULE on the TARGET
specifically for MCD logging … otherwise they DO overwrite

i am looking to see what others do to cover all bases and generate a best practice

case in point … I DO like Mikes note about clearing the Que tables
and has’s about clearing the BPaction

Do you have individual SSRS’s setup for each App (LIVE, Test, Pilot, Train, Test-A, Test-B, etc…)?

Or do you let multiple Apps share the same SSRS reports?

In mine we call our servers, paths

DEV-CM-APP1, DEV-CM-APP2, DEV-CM-SQL1, DEV-CM-RPT1 …

So we do a full Find/Replace

DEV-CM to TST-CM or PRD-CM or TRN-CM to make sure we change all our paths, BarTender paths, SSRS Paths etc… all in our DB Copy Script =)

1 Like

SSRS is separate for each
requires copying and reassignment of datastore