1 of 1 people found this helpful
Its a little difficult to get a full understanding of how you'd like to configure your packages without discussing it directly. It would probably be best for you to call in to LANDESK and go over your requirements with an engineer. As a possible side note though I believe using some LDMS queries, in place of the LDAP queries, would help narrow things down for you. We do store LDAP info in the inventory and so you can query it form there as well, enabling you to still query based on LDAP membership but add in other metrics as well such as OS version, or other requirements.
1 of 1 people found this helpful
So one of the limitations of bundles/groups is that it does not support alias/forking. So for the distribution package if you use the dame distribution package in multiple bundles, this creates a management nightmare when you have to change the distro package. For this I would vote on the following ER SWD - Package Bundles - Allow package "aliases". Grouping is great for organization but the console's search feature only does one level, so keep this in mind when considering deeper hierarchies. Some of the issues can be softened by using a strict descriptive naming convention for distribution package, scheduled tasks, bundle/group, and category names. For OS determination you could name your distro, sched tasks, categories with OS name. So a scheduled task name of something like
NLGO - Global - Citrix - Install - Not sure what date is for - W7
So that way when you search for the object using the all branch you can eyeball the task and see where it belongs. It would be better if there was a column for group & the search supported multiple levels. Remember you can make the sched task as descriptive as possible and what is displayed to the user is from the distribution package. Categories is also another way to filter the scheduled tasks in the DM/Portal Manager. Currently we decided to stay away from sub grouping in lieu of more specific naming. As far as packages for multiple os, it may take somewhat longer to package for multiple OS, but it is well worth it. A great simple and free tool for this is Inno Studio.Inno Setup make sure you download the IDE QuickStart Pack. I did a Lync package for multiple conditions OS with only a few lines of code.
As far as LDAP targeting from a DAL, this does have limitations. 1. You have to rely on the inventory record being accurate and then waiting for the core to resolve (LDAP group Enumeration on the client should happen much quicker and the load is somewhat dispersed onto the clients). 2. If you need combine LDAP/DAL tyoe query you can target based on LDAP and use a prereq query for other inv items.
Thankx for help. Yeh experienced that distribution from package is not really workable. Its strange as you wanna keep package number as low as possible but you have to make one only for another name.
Got a package that i run silently and one that use the Software portal... i have to make to packages, one for the description so the IT -er can understand and one so the user can understand what a package is for when they see it in the Software Portal, make a new package just for naming ... as the description and name is taken of the package.
Ok the goal i want to reach is go from Site deployment to public deployment,
The core applications where added by an Active Roles query that was looking for new computers. The admins had to check this but they didnt. So when a task got stuck lots of users would have old programs or no new ones because the Site admins task didnt run.
To counter that i have the Core applications distributed as desired in the Software Portal. These task are targetted to all admin accounts. So.. when a admin logs in a computer, does inventory and policy sync it would get the list of Core appliations ( Core all enlgish )
Its in test fase know but the admins are happy they have control back and see what is happening.
The package that need to be in the Portal will get a category "IT Portal" so when an admin log in they press IT Portal select all distributions and they have installed all "Core applications" when something goes wrong they can do the troubleshoot per task.
Downside i also make a ldms query that will check if the Core applications are present and if not put it in the silent distribution task to silently install, they will get category "Core' same app but not published in portal so need other category.
To make it more difficult we are managing the syncronisation of the software share by DFS to all different sites, we also have an non trusted domain configured via the LANDesk CSA but have the same pacakge only dsitributed by http:// instead of UNC because of the bad internet line. Category = Gateway
Also we have all applications that are Core like Office in english but we also have countries like China, Germany Brasil that use there own MUI's they are categorised as SITE as the MUI for German is only available for Germany.
Last but not least we have packages like Webex that are targetted to all users so are have the category Global.
Than still the OS version/bit are not covered ..
You have to group for Package and tasks
duanting task that i still not figured completely out as i dont want to make a packages that does excactly the same but just need an other name.
The final edit for our environment, hope it can help new LANDESK engineers.
We have a Global company with more than 50 sites, they all have Site IT admins that can access the LANDESK console and have different levels of IT skill.
To service the different levels of IT I have used all LANDESK options in distribution.
I have tried to get the same setup in every group as this will give uniformity and easy overview.
Global Admin task;
These are task for our development team and not visible for the other Site IT engineers.
Software (view only); ( to many times an engineer dragged and dropped devices in a task with queries and didn't started the task afterwards, stopping the Global task )
Policy task that are targeted with LDAP group ( directory management ) targeted to only computers.
IT portal tasks that are LDAP targeted to all Site IT users. The LDAP groups that give access to the LANDESK console are targeted.
Here I have located the Push task to stop the manual installation from the software share.
All packages have 3 tasks,
Software ( view only ) ( to many occasions that a engineer dragged and dropped a device in here and didn't restarted the task so the task would stop working )
Global - For distribution with LDMS queries and/or LDAP group queries.
IT Portal - For distribution to the LANDESK software portal; Used for only IT users that are installing software after they image the computer. It gives them a complete list of software and give them a view of what is happening with the installations.
Push - task for quick and low number of distribution; is stopping the IT engineers to have to resort to manual installation from the software share; when they don't know what they are waiting for.
All Packages have,
Detections for non-msi packages
Prerequisites to be sure computers don't get installation that won't work or shouldn't be installed on some computers/servers.
The following categories are used ( to display in the portal and to know what the task is for )
Core: All standard software packages, they need to be installed on every computer
Fix: Tasks that apply quick fixes to software
Gateway: for task that service computers outside our domain
Global: Global tasks
IT: For IT tools, for example procmon
Portal: Tasks that are displayed in all users their software portal
Site: Site specific software
Uninstall: Task that uninstall software
Hi @CRB just wondering how you created the "Global Admin packages" packages group, as I don't seem to be able to create groups outside of Public. Also the "Global Admin tasks".