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.
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.
When I copy LIVE to TEST (both on same App Server), all I do is:
Restore a backup of LIVE, to the TEST db
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.
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
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.
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.
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
