I've looked into this before and I know there's a good reason for the locked copies...but I can't recall it off the top of my head. Anyways, the purpose of my response is to address your organization question.
You only see the locked templates if you view All Templates. That's why we've created groups within Provisioning and then created shortcuts to the various templates in those groups. This way our tech's out in the field go to the group instead of all templates and therefore never see all the locked copies. It also makes it easier for us from a management standpoint. Of course you'll still want to go in there once a week/month/etc. and clear out the locked templates. At least this way, though, it's a little "cleaner" and easier to manage. Below is an example...
- Provisioning Templates
- My Templates
- Create Images
- Deploy Images
All my templates (all the locked tempaltes will show up in here along with your templates)
So let's say I wanted to deploy an image. I'd go to Deploy Images where I have a shortcut for my deploy image tasks. No matter how many I schedule from there, the locked templates will always show up in All my templates and not in the Deploy Images group.
Hope this helps. We were a Ghost shop to so Provisioning has been quite an adjustment...but it is so much more powerful!
1 of 1 people found this helpful
Templates get duplicted once they get scheduled and started. You will see a date appended to the name of the template which indicates a dupliacted template. The reason is that once a template is in use, its locked because during the provisioning, you don't want there to be a collision of 2 machines (or multiples) trying to access/copy the files at the same time. Its not like multicasting an image to several machines at once where they are all recieving the push at the same time. Well, it is and its not... Additionally, the "master" template can be modified where as a scheduled template can't while it is in use.
Ok, after reading the above, I'm not sure if it made anything is any much clearer (even to myself) but its just the way things work in LANDesk so after working with this for the past while, I guess I just accepted it.
In regard to the purpose of these locked duplicate templates I see them as extremely useful in managing the history of your provisioning tasks. If you wanted to keep all of these duplicates you would have a complete catalogue of all provisioning tasks executed along with their corresponding devices. Within some organisations I imaging there is a need to maintain a history of when devices were built and with what image.
Brandons folder structure and use of shortcuts is the same method I have always employed. That way it keeps these locked templates invisible to the end user.
There is an interesting .pdf regarding this issue and offers a possible method of perging these locked templates. The .pdf is titled "Managing Template Copies in Provisioning Rev 1.0.pdf".
So one of the points that I failed to make in the original post was that I was becoming frustrated with what seemed to me to be an uncontrolled proliferation of provisioning templates.
Like the 2nd poster, I created several folders and started managing my provisioning templates by organizing them according to task types. This was fine, initially, but over time this has gotten out of hand. Periodically I might clone or condense a template and then rename it. Maybe I'll just rename a template by itself. What I have discovered is that the folder containing ALL PROVISIONING TEMPLATES is huge. It has all sorts of stuff in it and I can't honestly make heads or tails of much of it because I see all of these templates which are not listed in any of my folders.
What I really hate about this interface is that whatever organization one creates is made up of 'shortcuts' to the actual items. When a shortcut gets changed, copied, deleted, etc it doesn't get reflected in the ALL PROVISIONING TEMPLATES folder. There are several templates that I have deleted yet they still exist in that folder. This is really a problem.
Lets say I create a template for "DEPLOY WINDOWS 7 TO COMPUTER LAB". Over time I make some changes to it, maybe I clone it or condense it and I get some spawned copies of the template-not just LOCKED versions of the templates but actual copies. Lets say that I decide to delete it because I now have a new template that I am using called "DEPLOY WINDOWS 7 TO COMPUTER LAB-NEW". When I delete the original and try to rename the NEW copy I can't do this because the original still exists in the ALL TEMPLATES folder.
This whole process is way too cumbersome. If I delete a template I should just be able to delete it; I shouldn't have to go looking for copies of it to also delete so that it is truly gone.
This sounds like an ER. I suppose it is but I just don't like posting ERs because they get ignored.
Am I the only one who hates the way Landesk has implemented this?
Easy way to find out is jam an ER in the system and see what happens. I personally think they need a tiger team and approach OSD/Provisioning from a new foundation - see what makes sense and what does not and throw away what does not and start over. When they do they need to fully support native 64 bit from the ground up (pe -> client - > core). I have an email from LANDesk a while back saying yeah on the 64bit PE, still have not seen anything. They need to understand the OSD/Provisioning is the foundation of EVERYTHING LANDesk! If the OS is not deployed easily and correctly then nothing they produce will work correctly. If you add an ER let us know and I will vote. I'm planning on another slew of ERs - been using freemind to trap them._____________________________________________________________Please consider voting for these ERs:Provide Better Pre/Post LDMS Patch/Sp/.0 Information To The CommunityCumlative Patch List for LANDesk ProductsQuery Builder ImportProvide bulk client deletions without carpal tunnel syndrome.Core Synchronization Allow Mirror functionality from Master Core
1 of 1 people found this helpful
I hope I can add some clarity to some of the "why" questions about the templates being cloned and locked when they are deployed. I won't try and defend the "why" behind the decision, but I'll try to let you know what the behavior is and some insight into the basic use case that went into it. Hopefully this will at least help you understand what the impact of different decisions is. Also, that will give you a great starting point for writing ERs.
The idea behind locking templates comes out of the idea that provisioning is inherently flexible, with nesting, (fairly) easy to make changes, etc. This flexibility in design is great while building/testing, but becomes a bit of a scary topic when you talk about deploying a template to hundreds or thousands of machines. When you get into an enterprise-wide deployment scenario all the sudden what you want is consistency instead of flexibility. Again, this may or may not be what you believe to be true, but it is the mindset that went into the design.
Here's the use case (as originallly designed). You use the unlocked/easily modifiable template for testing. Once you have your template complete you should have a locked copy that was used during your successful test run. This locked copy is thought of to be similar to a Gold Image for OS Deployment purposes. It is the template that has everything approved and should be used for all runs within the scope of whatever project you're doing. The key thing is that if you schedule the locked template it does not create a new cloned copy of itself. The idea is that you add a folder, or move to public, or do anything else you want to do to flag these as the templates to use, and you or your technicians who actually schedule and run the tasks schedule based on the locked template. Obviously the idea is that any failed tests should have their locked template deleted, then the master is tweaked which will create a new locked one. The final locked template is the one to schedule off, not the original.
Once again, I'm presenting the use case as is and without trying to defend the decisions made. The big key is that to schedule against the original for testing/design and then schedule against the locked copy for deployment will keep the proliferation of provisioning templates to a minimum.
Let me know if you have any questions about this, or any clarification I can give. Also, if you'd like to see use cases that aren't covered by this system make sure you get an ER in so we can build some enhancements into it. I'm committed to making Provisioning the best tool possible, so your feedback is definitely vital to make sure we can hit the mark.
Mach6 absolutely could not have explained this better. We were never presented with a use case, but kind of fell into this exact situation. We organize our templates into two groups under "Public Templates". One is called "Development" where we build, test, and deploy templates. Once we know they're working, we delete any locked copies that were created except for the last one. That one we move to another group under "Public Templates" called "Production". The great thing about this setup is that any time the locked copy is executed, an entry is stored in the "History" tab of that template. This allows you to see how often the template is used, how successful it is, etc. This is a very high level overview of how we organize our provisioning.
If you're more interested in the details, I've attached a screenshot of the actual breakdown of our Public Provisioning Template folder structure. Also on a somewhat unrelated note, just for the original posters benefit, we spent weeks perfecting the provisioning process. In it's native form, it certainly has it's issues and is somewhat unreliable. With a few adjustments on our end, primarily revolving around application deployment and hardware independent imaging, we've been able to turn LANDesk Provisioning into an amazing tool. I'd be happy to share some of our methods with you if you encounter similar issues. Don't give up on provisioning. Having a single .wim image and using provisioning to install apps and configure the machines compared to our old system of creating numerous Ghost images with all applications and configurations on them has been by far one of the best transitions we've made.
great explanation. The practice you describe was not covered in the landesk class that I took. The information that you provided certainly helps clarify what was intended in the design and it will change the way I use the tool. It also helps to answer a previously unanswered question of mine:
-are templates and scheduled tasks actually linked?
In the ghost solution suite tasks and templates were just combined into one item. It was possible to schedule them to run, but if ever changed the actual task any scheduled execution of it would reflect the changes.
My understanding today is that once you get a landesk scheduled task it is a locked item which is not updated when the details of the originating template are changed. Is this correct?
For example; I have a production template that points to a current image file and I create a scheduled task for it. Per your instructions I will use the scheduled task to push the images but I'll also set aside the locked template in a production provisioning folder. Later I modify the original template to reflect a new image file....in this case I have create a new scheduled task because I am locking a new template file for the task. I assume this is all correct.
I have one other question that maybe you can answer.
?) if you create a scheduled task for an agent deployment or maybe software distribution, what happens when you change the originating item? Lets say I deploy an agent config w/o power management and later add power management. Would I need to create a new scheduled task or could I keep using the original one?
Regarding spawning of provisioning templates, I am going to be able to cut down on some of these now that I will make use of locked templates instead of constantly deleting them. However I still don't like the idea that I can't organize the real templates into separate folders. I do appreciate the ALL TEMPLATES folder but I would rather have it be a list of shortcuts and the other folders contain the real deal. It comes back to one simple reality for me: I will always work out of multiple containers of limited scope instead of working out of a single huge container with everything. And whenever I delete something I will always have to delete it in two different containers to make sure that it is gone. I just think this is bad design.
-thanks again for the help
I'll show this thread to the training instructors so they can decide how to implement this information into future classes. It's not a very well documented scenario, but knowing how it's designed definitely makes it easier to work with.
Your understanding of the relationship between the scheduled task and the template is correct. When a task is scheduled the template is first flattened (ie, any nesting is removed, so you end with a series of actions) and frozen or locked (ie, read only). Then the task is associated with this frozen/flattened template, and not the original. The task cannot be reassigned to any other template, and the template is read only. In this way the task/template become static. You can always create more tasks based on the same template, but if you delete the template that task will never work again. For changes to the template, see below.
Some things can still be tweaked within a template. Those include agent configuration changes, changes to a software distribution package, or anything that is a variable. In all those scenarios you don't change the action itself, or any settings on an action. For example, if you have a software dist package called, "Newest version of Adobe Reader" and you go from version 9 to version 10 (or X or whatever it is) from the same package, it will begin installing the new software correctly. If, however, you create a new distribution package and change the action to point to that distribution package instead, you will need to re-lock the template. If your image file is hardcoded and you change it, you will need to re-lock the template, but if your image file name is the same, or you use a variable for your image file name then the same template will work. Basically the software distribution action says, "Run software Package 12345," and that runs real time with whatever settings that package has. If that package changes between one run and the next those changes will be reflected, because it's a real time change. Variables, agent config stuff, security and patch stuff all do the same for obvious reasons.
Thanks for the feedback about the UI and experience. I can see that having the delete button not actually delete something seems like a counterintuitive interface. Did I simplify that too much? [-8 I'll pass that feedback along.
I hope this helped clarify rather than confuse. As always, if you have any questions or feedback, feel free to let me know.
Great posts Mach6, I so wish this method had been used before I inherited it here.
Is there a white paper for provisioning including this sort of information and more, if not then I think there’s a strong case to publish one.
One point I’m not sure if I’m missing; why are we not able to rename a locked template? i.e. remove the date/time and put a release number instead? When I try I get 'another template with this name already exists....' (although I know it doesn't).
I'm not aware of a whitepaper, but I'll check with the support guys (they are usually a lot more on top of what documentation we have then I am).
I'm not sure why you can't rename a locked template, but I'll try and look into that and see if I can figure out what it's trying to do that's blocking it. Thanks for the heads up on it and sorry it took so long to reply.
Thank you for very good explanation. I have little bit out of topic question. On my test env the locked templates are not being created (after recent upgrade to 2017.3, butmay not be related to that) - question is where to look first?