Troubleshooting issues where the Software Portal is not working correctly can be challenging. Much of what happens is not visible in either the Software Portal itself, or through the Symantec Management Console. This white paper provides greater details in how the Software Portal works, which should provide methods to assist in resolving issues. These details can be used to assist in troubleshooting as the process can be followed from start to finish, from when the user loads the Software Portal to when the Software is delivered to the target machines.
This article contains the following:
Note: This article is provided "as is". If you are not using the version stated in the title of this article, mechanisms and functions may be different.
Note: This article is a work in progress, and not all details are available at this time.
Quick Delivery or MSD fulfillment
When a Software Request is approved automatically and a user requests such software, or if an Administrator of Manager approves a request, a new Client Software Delivery Task is created. This is for listed software published directly from the Software Resource. For a Managed Software Delivery Policy, the Policy itself is used. The following two processes detail how Portal requests, via Listed Software or an MSD Policy respectively, are handled by the Software Portal on the Notification Server.
The Software Portal uses a Manager class to process any incoming requests for Software. The logic used by this process is detailed here:
- The SWP obtains the Software Request. This can contain multiple approvals if the Request required approval and the approval was executed against multiple requests for the same software.
- Next, the SWP gets a Publishing Item associated with the selected Request Item. The association are unique because a request item references to one publishing item (see Figure 5).
- Once the Publishing Item is obtained, the SWp gets ALL Task GUIDs for the Publishing Item. To do this, it uses the stored procedure spSWP_GetTaskGuidByPublishingUtemGuid. This Task GUID is stored in the SWP_SoftwareRequest table, TaskGuid field (see Figure 5 - Software Portal tables in Part 1).
- The SWP looks at the resulting list of tasks and tries to find a Task with the same command line and package as the listed software just requested.
- The SWP will create a new Task if an existing one is not found. The Task type is Altiris.SoftwareManagement.Tasks.DeliverySoftwareEx. The parent folder for these tasks is defined in Folder.cofig XML (Software Management Solution). The folder name is "Software Request Item Folder", the GUID is "0C682F39-25BF-4b57-99A3-0C0116D933FC", and the attributes are "no delete" and "hidden".
- The SWP then either Schedules the existing task, or schedules the new task. The scheduling is done via Task Server, using both TaskSchedule and TaskExecutionHelper classes of the Task Server .NET assemblies. The schedule time is set at now or, if the user set a schedule in their request, the user's schedule time. Computers for this task are taken from the Request Item's Machine GUID or GUIDs.
- If the Administrator sets the listed software as already approved, when the User Requests it the Quick Delivery task will be executed using the User's Schedule, or if none is specified the Quick Delivery Task will be executed at the Current Date time +5 minutes.
- If there are multiple users who request the same publishing item (same resources and same command line) then for every user in the Quick Delivery Task a separate scheduled task will be created within the same QD.
Managed Software Delivery Policy
The basic same method is called as for listed software, a Software Resource:
- The SWP obtains the Software Request. This can contain multiple approvals if the Request required approval and the approval was executed against multiple requests for the same Managed Software Delivery Policy.
- Next, the SWP gets a Publishing Item associated with the selected Request Item, in this case which is a MSD Policy. The associations are unique because a request item references to one publishing item (see Figure 5 in Part 1).
- The SWP then gets a Resource Target using the spSWP_GetResourceTagetGuidForPublishing stored procedure.
- Regardless of what targets may already exist on the MSD Policy, the SWP will add the computers the requests were made from to the MSD Policy.
- The Portal will then execute a Save of the MSD Policy.
- Lastly, the SWP will Schedule an ASAP Update Client Configuration Task, set at Date time Now +5 minutes.
Populating the Portal
Having configured a group of users to have access to certain Software, how does the Portal know what software to display when a user logs onto it? While the eventual target of the Software will be the Computer the user is logged onto, the computer makes no difference to what is populated on the Portal (assuming that the Software Management Solution Agent is properly installed, if it is not the Portal will throw a message indicating such). It is the User who populates the Portal, and the computer is only involved when the user requests Software.
To determine what software is published and available for the user, the Software Portal must collect all the Groups that user is a member of, either directly or indirectly. This means Groups that have nested groups within add to the complexity of this collection of data. This also applies to trusts within a multi-domain environment. To accomplish this, the SWP collects the Security IDs that the user is a part of.
Once all the SIDs are gathered, those SIDs are compared against all Software Resource, and thus command lines thereof, and Managed Software Delivery Policies to see which ones the user has access to. Since there are two possible options for each PublishedItem, it is possible that a User, through different Group assignments, will have more than one return per PublishedItem. Specifically this is when, through one group, the user has rights to request software that requires approval, and through another group the user has rights to request the software immediately, as in already approved.
It is the SIDs of the Groups and the User that makes all the connections via the Symantec Database.
This analysis of user Groups is done directly in .NET on the Notification Server. The SWP, which is housed on the SMP, calls an Active Directory Service API to fetch all SIDs associated with the user. .NET also uses SQL via the stored procedure spSWP_GetSoftwarePublishingItem to match all the SIDs fetched via AD to PublishingItems, or what Software that user can request.
See Figure 16 for a diagram representing the Portal Request Process.
TechTip: GetRemoteUserMembership is the primary method on the ContextUtil class that is used to get the SIDs for the user accessing the Software Portal.
The process or analysis of obtaining the SIDs, and subsequently the PublishedItems, uses the following Algorithm:
- The Software Portal obtains the Active Directory entry of the user accessing the Portal.
- If the User is local, then the SWP analyses only the local context. .For the .NET API this means that the name of the local machine is used for the corresponding LDAP queries. The machine name is taken from the user context that is entered as the credentials when launching the Software Portal (it is possible the User is logged on as a user that is automatically passed to the SWP, so no prompt was given. In this case it's the user's logged on context).
- If the user is a Domain User, The SWP must first analyse the domain relations (including relations between multiple domains), and then analyse its local context (as with step 2) because the domain user may also be a member of a local group.
- Next, the SWP Analyses relations between groups, meaning that it obtains a SID for every group, whether local or domain, which the User belongs to.
- The SWP executes a Parent group search that is a recursive process. First, the SWP looks for groups that the user belongs directly to, and then for each matched group it looks for groups that include this group, etc. For the purpose of optimization and to prevent the analysis of cyclic dependencies, the SWP remembers groups already analysed and does not analyse them a second time.
- To find all Parent groups the type of LDAP queries that are used are, for example: "Select all the groups that have <user> member"
- The LDAP queries the SWP executes are within a single domain.
- There can be trusted relationships between domains. This means that the groups of one domain may be the Parent groups of another domain, and in this case trusted Domain group's analysis are required.
- The first analysed domain is the user's domain.
- After the user relations analysis are completed within the user's domain, the SWP searches for all domains that have trusted relations with the current user domain.
- Relations between groups, which are found in any trusted domains, are also analysed.
- Trusted domain analysis is a recursive process. For optimization purposes and to prevent the analysis of cyclic dependencies, the SWP remembers relationships between all the domains.
- The analysis process ends when all domains and groups within trusted domains are discovered and all SIDs have been obtained.
Tables in Use
As SMP is heavily database driven, knowing some basic schema details can help when troubleshooting issues. The following tips stem from the question: What tables are used to determine what software is available?
A method exists (by name: SearchSoftwarePublishingItems) that uses 3 parameters in order to obtain Software for a User who has loaded the Software Portal.
- SearchValue = what to search (by default it is %)
- OnlyRecommended = search for only recommended software, toggled by the Recommended button on the Portal
- TrusteeSids = search for software for current SIDS only
This method calls the stored procedure spSWP_GetSoftwarePublishingItem, which obtains publishing items for the current SIDs.
This stored procedure uses the view vSWP_PublishingItem and the SWP_PublishingItemSetting table to determine which software is available.
For the 7.0 SP2 MR4 release, many of the issues we encountered originally are resolved. At the time of this article, there is only one item that is under investigation. This involves untrusted domains, where the user has rights in the user's domains, but other domains in the structure are not trusted. This causes the Portal to fail for that user.
Issues for MR3/MR2:
- Before MR4 an issue existed when approving multiple requests with the same publishing item. In this case, if the administrator or manager approves more than 1 request (multiple selections) from different clients who wants same software, the Quick Delivery task for every user will run more than 1 time.
- Poor Portal Performance - Many optimizations were made in MR4. MR3 contains some performance optimizations, but the real heavy hitters were released with MR4.
This document is provided "as is", and should be considered a reference when troubleshooting issues stemming from the Portal. Much of this technical data is subject to change in new versions of SMP and Software Management Solution. As of the publication of this document, much of the 7.1 release will also apply to this document.
Return to: Part 2