If it can’t be repro’d within Support, that is more or less the end of the application support triage as they work with the base application.
When we bring a database in-house, my DB Load team executes a tailoring database script to allow it to work within our environment. As of 10.1, the script does the following–one of them could be your X-factor.
WE REMOVE:
- any pending shop warnings
- system monitor records (systask, sysrptlst, etc)
- user account lockouts
- any existing pointers to taskagent configurations within the customer’s environment
WE DISABLE:
- UI tracing on user records
- solution workbench tracking
- all BPMs <-- this should be tested in a customer’s environment before uploading the database to support
- tax connect (if applicible)
- system agent schedules
- taskagent rules
- the SSRS override on the company record
- require SSO on user records
WE UPDATE(OR CREATE):
- a security manager user record that it can be used with the system agent taskagent configuration, login via the client <–NOTE: the user on the system agent/taskagent doesn’t need to be a security manager and best practices would be NOT to have it be one
- the system agent to work with our epicordata folder shares and remove the appserverURL as it isn’t needed in our environment
- the company records to set the work station method to Machine name + Domain User <-- everyone should do this in their environment, the report type preference to SSRS if Crystal was set, and to use a local file share for file attachments (if applicable)
- the menu to expose the data fix workbench and conversion workbench if they were disabled/removed/not where they should be by default
WE COMPLETE AS NEEDED:
- apply an internal support license <-- not common
EDIT:
We only load databases at the latest point update for the release that the database is currently on. So, as of today, any 10.1.400.x database processed by support would be loaded at 10.1.400.38, for 10.1.600.x that would be 10.1.600.18 (etc).