Points to be noted in setting up test environment.
Users,
Test environment can be created with the production data. Take a backup of existing data, by invoking backupData.bat script under <sdp_home>/bin directory. Backed up data will be stored under <sdp_home>/backup directory. Install the same version of SDP in any test machine and backed up data need to be copied to that machine. Backed up data can be restored using restoreData.bat script under <sdp_home>/bin directory.
We like to specify points to be noted when setting up a test environment (with production data).
If you want to run a test machine on the same network as your production server, better look into the following to prevent conflicts and confusion :
Bjm, thanks for collecting this.
Users, please update us if any other good practises are followed.
regards,
Uma.
Test environment can be created with the production data. Take a backup of existing data, by invoking backupData.bat script under <sdp_home>/bin directory. Backed up data will be stored under <sdp_home>/backup directory. Install the same version of SDP in any test machine and backed up data need to be copied to that machine. Backed up data can be restored using restoreData.bat script under <sdp_home>/bin directory.
We like to specify points to be noted when setting up a test environment (with production data).
If you want to run a test machine on the same network as your production server, better look into the following to prevent conflicts and confusion :
-
1. Stop mail fetching immediately after applying production data to your test server. You don't want it stealing emails that should be going into your production system. Or you could also leave fetching turned on but point it to a different email account.
2. Disable email notifications to everybody but the people who will be doing the testing. Emails from two SDP servers will easily confuse non-technical users.
3. Optionally, disable any preventative maintenance tasks. If you have already taken care of the notifications in step 2, this may not be necessary.
4. Change the alias URL to the correct server name so that any notifications that do get sent out will not have broken URLs (under General -> Self Service Portal Settings).
5. Disable scheduled workstation scanning
6. Optionally, open the [ServiceDeskHome]\server\default\conf\rebrandInfo.xml file in a text editor and change the product name tag to something like "SD+ Demo." That tag is displayed in the title bars of web browser windows, and will make it easy to differentiate between test and production systems if you are working on both in the same web browser.
7. Preferably disable scheduled importing of Requesters from AD
8. Disable Survey options, if configured so that end users do not receive survey notifications for requests in test environment.
9. Disable scheduled Email Reports.
Bjm, thanks for collecting this.
Users, please update us if any other good practises are followed.
regards,
Uma.