Ouch. I fell your pain. Personally I have stopped using T2L wherever possible because it is often too hard to lock the production system down by simply telling people. It desperately needs a product based locking tool. T2L is OK for short periods of time, say a week, even then you should rehearse to make sure no-one has changed anything they shouldn't have.
Personally I prefer to use DT because I know what it is doing and I have a number of queries which help me know what has been changed in the design. So just take the following as some thoughts by someone who has been burned by T2L and chooses to use DT. LD best practice might well be differet and I'd seak their advice too to make an informed choice.
I use queries I developed to DT in the following order:
All the attributes with filters
All other attributes
Roles and Groups
Queries only, no filters
The main issues to look out for (IMHO) are making sure you import in order and if anything is missing, go back to the source and add anything missing, possibly as another DT file. Repeat until the Destination is OK for that phase of the DT, then move on.
Be prepared to do a pool recycle if you get stuck - this often helps recycle the metadata that the framework thinks is there with the application.
I don't use dependencies because by getting the order right you know what should be created.
Be prepared to restore the destination database and redo a bit. This will give you a clean rehearsal so PROD will be easy.
You'll need to keep some notes on what needs to be done manually as some things will still need to updated e.g. what is the new default process, business object UIP for existing attributes have to be done manually.
I'm not the best person to ask about T2L because I have spent waaaay too many support hours sorting out issues with it. It's a great tool and in the right hands with the right time-frame is brilliant. e.g. updating a process. But I think your timeframes for using it were a bit too long. A week and you'd be fine and you have changed all the admin passwords now haven't you? So if you want to use T2L, break things into manageable chunks, lock down the admin passwords in PROD, be prepared to fix up new categories that still get created or deleted by using DT from PROD back to the master design.
I believe LD are working on a new way of doing this sort of synchronization - but don't quote me as I don't work there :-)
Thanks for your swift response.
You have covered many of the points that we are interest in trying to get a grasp of.(Far more than LD support did). In terms of process comments I totally agree with you and we have made recommendations from day 1 on process requirements. Hopefully this time those above us understand the reason why we stressed such strict rules!
One of the biggest problems we are currently struggling with is working out the changes between our source and target properly. Visually it is easy to do but how do you measure this? Interestingly you mentioned that you use an number of queries which help you know what has changed in the design. Would it be possible for you to expand on this and possibly give us an idea of how to set this up on our system so that we can measure what is changing when we are carrying out the Design Transfer.
Hi Josh - if you get to the right person within the LD consulting team, I'm certain you'll get some additional information. Just keep plugging away via your account manager.
In terms of the queries I developed, I'm afraid we have rather too much IP in them to publish. This probably isn't in the general spirit of sharing on the community, but we make a living from providing LANDESK services, so I hope you understand. It is likely that LANDESK consultants have developed much the same, or better, so your account manager might be able to put the squeeze on them? :-)
As a first step, I'd start by writing a query against Metadata/Attribute Type and add in class,module, title, last update date and anything else vaguely interesting. That will give you a list of attributes that have been modified since a given date. If you cannot see Metadata in the list of modules to write queries against, add the following to your console64.exe.config file...
<add key="BOD_ShowAllObjects" value="true" />
Dave is very much correct in that you have to export your design in the right way and import in the right order. One method I use is if I know what I am looking for in terms of design to export. I have design transfer open on both the live and test environments and I have both open on the export tab. By comparing the objects in both views I can see what needs to be exported and is generally pretty accurate.
Some other things I do:
When modifying existing windows for design transfer,copy the original window. On the copy, make your changes to the window to be design transferred.
When exporting reference list objects, don't include the deleted object, as this can cause design transfer to fail.
Hope that helps
Thanks for you replies.
We have attempted to carry out the design Transfer however things haven't quite gone to plan...
We have encountered a lot of these for business objects, queries, windows etc....
which we have answered, Do not create new query and keep only existing one... would this be the recommended approach or should we be creating ones with the modified title?
We also hit this brick wall when trying to export one of our process' out...
I assume these isn't anything we can do for this?
I always use the Do not option to make sure I'm using the item I know I have exported. With the second one I would suspect a process condition calculation or value type calculation which has a dependency or attributes used which are not strictly isn't on the process domain. For some calculations you may need to remove that from the calculation and put it back on afterwards.
What metadata type is used to query to get a list Windows?