I am doing the same thing at the moment, Mark. Not sure how "proper" you need it to be. but I have set up an additional Windows 2012 Server with it's own instance of SQL Server running.
you should probably shut down the mail services on the Pre-prod server for the time being to prevent this duplicated server processing and sending mails to end users. You can then run a script against the databse later to switch all users to not receive notifications (and then alter the odd one or two you want test with).
1. I installed the same version as is running on on our production server. (in our case 7.5)
2. restored the OOTB database that comes with the LDSD installation files.
3. check that you can get into the Console on the OOTB database and that everything works satisfactorily.
I then take a BAK backup of the production server's database, and restore it over the top of the OOTB databse on the Pre-production server.
If SQL instance names are different between your two servers you might need to go and upgrade the Service Desk Framework application on the Server's Configuration Center, and/or modify the console.exe.config file on your server so that the console points to the correct framework and connects with the corerct database credentials.
You should now have a useful pre-production environment that you can break to your heart's content.
Beware notifications though - you should probably chase up the SQL scipt to set all users to not receive notifications before you switch the mail service back on.
I believe LDMS 7.6 has a feature called "test to live" which will allow you to make your changes on the test server and once you have them working as you want, you can export them to your live server. I have not played with it in detail but will be looking at it before upgrading next year.
We have not gone as far as setting up a second SD server, but have created additional instances of Service Desk in ConfigCentre and have a separate DB for DEV running on second SQL server.
I would actually recommend setting up three (yes, 3) instances of ServiceDesk in ConfigCentre with separate DB's for each... if you can manage it:
- Prep/Staging of changes for transfer to (1). (by either DT or TTL)
- Development/Sandbox to play in and test out new ideas
You would periodically want to take backups from (1) and restore to (2) and (3). Additionally, (1) and (2) are kept pristine except when implementing approved changes, while (3) is there to hammer away at when you are feeling creative.
Thanks very much for this detailed contribution. unfortunately, we have found that Test2Live is not fit for purpose, as it stands, as it synchronises data that we don't want to be synchronised. We have submitted an enhancement reuest, which we hope that you will feel able to support:
Thanks and best wishes
We have a separate development domain in which the dev servers reside. The firewall rules between the domains have been set up so that I can read from the production domain, but not write to it. A number of times this has saved my bacon when I've inadvertently done an MDM on the production database.
If you can stretch to it - I have development 2 servers as suggested by Brian that I use when I'm busy testing an upgrade, with the 2 servers using the different installed versions, each pointing to their own database. This enables me to experiment with Design Transferring my functionality accross, or prepping the database for what I need post upgrade,
I've not used Test2Live yet - all my dev design work gets Design Transferred in chunks and tested through before applying the DT's to production.
Many thanks for this contribution. I am keen to know how you transfer design changes safely and reliably between the 3 environments.
We were going to use the Test2Live tool, but we have found that it is not fit for purpose, as it synchronises data that we don't want to be synchronised. We have submitted an enhancement request, which we hope that you will feel able to support:
Just to clarify, do you use the Design Transfer tool? If so, how do you find it? Is it reliable?
Hi Mark, Yip, I use DT for everything that it allows me to do. But you do need to test the transfer as well, and make sure that you only bring accross what you want. I create the DT export files in chunks for big pieces of new stuff. I also normally always exclude dependencies so that I am sure I pick only the elements I want - on the import it will tell you if you are missing something. (sometimes though it does bring over dependencies that I don't expect, so I have to figure out why, remove as appropriate, and the re-export to re-import)
Objects and reference lists / categories
And them import them in the above order, and work through any errors. You can normally import over and over until I've got the correct DT file, but remember to take regular backups if you think you may break something - but these days I seldom have to resort to restore.
Then check the objects, processes, windows & queries in their designers and tick them off the list and make sure any ones that I did not want did not come over as a dependency.
Then check the functionality again as different roles (I usually get a couple of users to do this as well)
The bits I know do not come over in Design Transfer, and there fore have to be done manually
- Filters applied to objects
- Web windows
- Windows rules (because the web windows need to be "re-created" they have different guids)
- updates to existing queries, windows and processes - you have to create new ones which leads to loads of obsolete metadata to delete which is very time consuming.
- I'm not sure exactly how permissions come over in DT - I often have to apply these afterwards again
- Any shortcuts needs to be updated.
I work through it all, document exactly what elements I select to DT, what order to transfer them in, and also all the manual steps I need to do, so I know exactly whats required step by step when putting it into Production.
It seems that you have largely worked out the limitations of the Design Transfer tool, and have developed processes that work well, within its limitations. Many thanks for your extremely helpful reply.