3 Replies Latest reply on Aug 19, 2014 10:34 AM by mmorales

    Using TTL, Prepping Development and Test servers

    Expert

      Hi everyone, I am going to be trying/testing TTL for our 771 HF1 environment.  I have a couple questions that I haven't read anywhere, maybe it is just me being overcautious and curious on this subject.

       

      1.  I am going to begin testing the use of TTL from my Development server to my Test server.  When I do this, I am going to take a full backup(.BAK) from my production and restore it to both the Development and Test servers.  Upon restoring it to Development, I am going to shrink the DB and rebuild the indexes(I know I should do this during the backup).

       

      Question:  Are there any issues caused by performing a db shrink or rebuild of indexes?  I am planning some build, tests, etc in the Development environment prior to running TTL to the Test server.

       

      2.  As part of our restore process/steps, we remove email addresses and queued emails for all users and processes.  When restoring back to Test, will this also be transferred back emptied?(we remove these items since someone "accidentally" started BG and Outbound services, which then spammed countless emails and messages )  Once again, I am going to be testing this, but would like to know what to expect.

       

      Thanks,

      Mike

       

      I forgot to ask...

      Will content like the Web Access URL need to be changed before the TTL "button" is clicked?

        • 1. Re: Using TTL, Prepping Development and Test servers
          dmshimself ITSMMVPGroup

          1.Nope, you'll be fine

          2. If your restore process is to remove these when you restore, then you'd zap these in both Dev and Test unless you are doing something special in Test?  I would if I were you for the same reasons as you have now!

          3. Once you have done your mods in DEV and run TTL, you'll then probably need to carry out some manual mods such as WebAccess links.  Check through the list of things TTL syncs up from the manual and fix up any that remain to be done by hand.

           

          Personally I've moved away from TTL unless it is for a very, very short length of time.  It can be very hard to lock down PROD sufficiently even over a fairly short period of time for you to be really confident that when you press the button nothing will come back to life that you previously deleted.Did you modify any queries, delete the odd list item or category, alter a mail in a process and so on.  Did you crate a category that you didn't also mirror back in DEV  If you are not sure TTL may not be for you.  If LD could provide a tool to 'lock' production, that would be excellent.  Until then, I'd take a look at Design Transfer.  It takes some time to get used to, but you really know what is moving across from one environment to the other.

           

          Just some thoughts by the way, YMMV and other people may well disagree with me- and that is all good.

          1 of 1 people found this helpful
          • 2. Re: Using TTL, Prepping Development and Test servers
            sprooney Apprentice

            Just thoguht I'd add a touch in here.  Being fairly new to the whole LANDesk thing myself you'll possibly have found some of my questions and queries on a similar topic.

             

            We still choose to use TTL over design transfer, being honest I've struggled to find the time to get a handle on Design Transfer and LANDesk support and consultants suggest the use of TTL.  So long as you have a small group of people who can make administrative changes you should be ok.

            A couple of rules i have 'stumbled' across...

             

            1. User administration, do in live

            2. Configuration Management, do in live (although we only use Services in here I assume they are all the same)

            3. Don't DELETE anything from either environment during TTL, wait until you have synced and then delete whatever you need

            4. If you use Webdesk - Gadgets seem to update sometimes but not always, haven't nailed this one down exactly yet

            5. If you have any scheduled reports, make sure that in DEV, prior to running TTL you update the next run date, for example if you have reports running on the 1st of the month and your TTL period overlaps the 1st, on running the system copies across the next run time as a date in the past and re-runs all your scheduled reports

            6. If you do make changes in Live, write them down, it is possible to 'rectify' a change and if you know what the change(s) was it helps

            7. I'm still learning what does and doesn't move across and happy to be corrected on any of the above

             

            Cheers,

            Steve

            1 of 1 people found this helpful
            • 3. Re: Using TTL, Prepping Development and Test servers
              Expert

              We've postponed the build out of TTL, as there are just too many issues.  I am not sure if this is a SQL 2012 or TTL Application requirement but TTL seems to validate everything in the database, which is now requiring MSDTC to be enabled and fully configured for use, as opposed to just using remote databases as a read only via Linked Servers.  This means every view has to be valid, even those that are no longer in use.  I know best practices would dictate that we remove these old views etc.  I am not a DBA, nor do I even try to portray one.

               

              Besides for TTL, our data access to foreign databases via Linked Servers are all operating appropriately.

               

              Thanks,

              Mike