The Software Portal
Common Terms and Acronyms
General Setup
Software Publishing
Software Resource Publishing
Managed Software Delivery Policy (MSD) Publishing
Software Request
User Resources Intro
Disable "Request Unlisted Software"
User Interaction
Requests and Updates
Request Dialogs
Software Approval
Portals
User Resources
Filtering the Admin or Manager Portals
Quick Delivery or MSD Fulfilment
Listed Software
Managed Software Delivery Policy
Populating the Portal
Tables in Use
Known Issues
Troubleshooting
Tracking Deployments
Task Server Statuses
Provided Reports
Conclusion
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.
Common Terms and Acronyms
The following acronyms will be used commonly throughout this section:
- SMP - Symantec Management Platform
- NS - Notification Server
- Child - A child Notification Server within a hierarchy
- Parent - The parent or top level Notification Server within a hierarchy
- SWP - Software Portal -
NOTE: Often the code base that runs the Software Portal, including the Assemblies and code called through the Altiris Service, will be referred to as the "Software Portal", or "SWP"
- SWM - Software Management Solution
- SMF - Software Management Framework
- MSD - Managed Software Delivery Policy
- AD - Active Directory
- SID - Security Identifier
- SLA - Service Level Agreement
First, the Portal must be properly configured for your environment. This involves the selection or configuration of what domains the Symantec Management Platform will use when analyzing users who access the portal. This is essential to avoid timeouts in multi-domain environments.
In ITMS 7.1 SP1 and later versions the ability exists to enable\disable Software publishing information to trusted domains from the Software Portal settings page . Also there is a registry key for this feature that allows you to define domains that should be included in analyzing when loading the Software Portal.
|
|
If trusted domains analyzing is disabled there is possibility to define an include domains list in the windows registry that will extend list of domains that will be analyzed when Software Portal is opened . It's a registry multi-string value "includeDomainList" in the "HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\SWM" registry key. Domains enumerated in this list will "extend" the NS domain. Any software published for NS domain can be also published for users and groups that are in domains from the include domain list.
|
Include domain list must have FQDN - Full Qualified Domain Name (long) and NetBIOS (short) domain names. For example If "Publish Software across all trusted domains" option is disabled and IncludeDomainList is defined - Administrator is able to publish Software/MDP for users that are in NS domain and in domains from IncludeDomainList
Also this registry key is ignored when publishing for trusted domains is enabled on NS server, e.g Administrator is allowed to publish Software resource\Managed Delivery Policies for Users/Groups that are inside NS domain and all trusted domains, not only those domains that are defined in the IncludeDomainsList
There are two basic objects that can be published to the Software Portal. A Software Resource can be published directly to the Portal, and in MR4 each Command Line available in the Resource can be individually published. A Managed Software Delivery can also be published directly to the Software Portal.
While this article will not cover the basic usage in any details, know that you can publish to single users or groups, and there are two settings associated with each user or group:
- Approved or Requires Approval radial - This allows administrators to control when software is pushed to a user who requests it, or allow free approval for common applications.
- Recommended - This checkbox should be checked for any Software you want to appear in the Portal by default when a user launches the SWP.
When a Resource or Policy is published to the portal, a record is logged into the Item table, with a set of referenced records in the table SWP_PublishingItemSetting (See Figure 3 - Software Portal tables). These references allow the security settings tie into Users who load the Software Portal. The relationship between the Publishing Item (in the Item table) and the Publishing item settings in SWP_PublishingItemSetting are a one-to-many relationship.
When you save the settings and users or groups assigned under a Software Publishing tab (whether for a MSD Policy or a Software Resource) the stored procedure spSWP_UpdatePublishingSettings is called to add the appropriate entries to the SWP_PublishingItemSetting table.
These references are made using the ItemReference table. This table contains the following columns:
- ParentItemGuid - The parent of the reference, by Item or Resource Guid.
- ChildItemGuid - The child of the reference, by Item or Resource Guid.
- Hint - This is the type of reference that the row represents.
The Publishing Item, located in the Item table, has only one type of reference, as illustrated by this table:
| Reference hint |
Reference type |
Parent Item |
Child Item |
| PublishingItem to Software |
Depended child |
Software Resource or MDP |
Publishing Item |
Note that the Hint is "PublishingItem to Software", which is the exclusive type for the Software Portal's reference from a Publishingitem to its PublishingItemSettings.
Please see Figure 1 - PublishingItem Diagram for more information.
The Command-lines are published directly, giving the flexibility that was found in the 6.x Portal, while still providing the more user-friendly 7.x Software Portal.
When a specific Command Line is published to the Portal, a PublishingItem is created for that publication. This means if multiple command lines within the Software Resource are published, each command-line will have its own PublishingItem, with corresponding PublishingItemSettings.
For the radial setting "approved" or "requires approval", two PublishingItemSettings are created, for each user and group in the list, one for approved and one for requires approval.
Figure 1 - Publishing Software
The basic associations and references created for a Managed Software Delivery Policy are the same as for a Software Resource and its command lines. A MSD Policy is ever only a single PublishingItem, though the same variety of PublishingItemSettings are available depending how many groups and users and what settings are selected, as shown in Figure 2.
Figure 2 - Publishing MSD
This section may have additional items added as additional research is conducted on the Software Portal and how it works in conjunction with a MSD Policy.
Figure 3 - PublishingItem Diagram
A Software Request is a key feature of the Software Portal. It's what makes the Portal work when an end-user or an IT administrator or Helpdesk user requests to install Software on a system they are logged onto. Whether a user has any Software selected for them or not, directly from their user account or through a domain group, they will be able to open the Portal.
To put it more succinctly, as long as the User can authenticate on the Domain, they will be able to load the Software Portal by putting in their credentials when prompted to load the SWP.
When a user first accesses the Software Portal, if the user already exists within the SMP (whether through a Connector Solution or an Active Directory import) the Portal will tie into that User Resource object. If no user exists within the NS, a User Resource with a naming scheme of name.domain is created. The user will be prompted to fill out information concerning their profile, including their email addresses for notification purposes.
More technical information is not available on the initial user setup or User Profile at this time. Please see User Resources section under the Software Approvals for more information on User Resources.
There are ways to manipulate how this Profile page appears when users first access the SWP. These are unsupported. If a problem occurs while trying any of these customizations, Symantec is not obligated or required to assist fixing the issue.
Disable "Request Unlisted Software"
While speaking with a user he indicated there was nothing to stop an end user from making any random request for software using the "Request Unlisted Software" option, a request that may fall into a black hole if the Portal is not setup to require approval. If you decide to try some of these customizations, please backup the files you edit before making changes so you will have the ability to revert your changes should you have unexpected results.
NOTE: These changes are not supported and are provided "as is". Use at your own risk as there are no guarantees and no support if you implement one or more of these methods. See the instructions below to ensure you backup the original configuration before applying changes in case you need to revert.
To hide the "Request Unlisted Software" button, there is a registry key that can be added to version 7.5 SP1 or later.
Several Registry keys have been added to hide / unhide the button.
Update 28.08.2014
From 7.5 sp1 onwards it is possible to disable the button "Request Unlisted Software" by adding the 'DisableUnlisted' reg key value (String) with any value data in it (i.e. '1') to the SMP server:
You can add it under:
HKEY_LOCAL_MACHINE\Software\Altiris\SWM
or
HKEY_LOCAL_MACHINE\Software\Altiris\PointFixes
After the change you do not need to take any actions, just refresh or access again to SW Portal page, you will see the button as grayed out.
To restore simply remove the whole registry value added.
User Interaction
Users who access the Software Portal will only view and request published Software Resources and MSD items (with a publisheditem) that are available for him or her. The Software Portal is designed to work with NT users and groups (local), or Microsoft Active Directory. For any software to show up on the portal, the accessing user must have assignments of a PublishingItem to his or her User account, whether directly or through Group assignment.
Every local or AD User has a SID (Security Identifier), which is a unique identifier in Active Directory, or within the local NT security for the NS. Every NT group also is assigned such a SID.
The SWP_PublishingItemSetting table contains relations between PublishingItems and SIDs of users and groups for which these publishing items are available. Figure 4 shows how this association is represented in the table:
Figure 4 - SID Associations
Any PublishingItem can have none or many associated Request Items. Basically whenever someone makes a request of a piece of software (hence the PublishingItem) a RequestItem is generated and associated to the PublishingItem. As with the PublishingItem, A RequestItem is stored in the Item table. Yet this is only half of the request. The other half is stored in the SWP_SoftwareRequest table.
When a request is made the requires approval, or an administrator fulfils, denies, or asks for more information on the request, a Comment, labelled RequestComment, is generated. Any RequestItem can have none or many Comments, depending on how many notes are made during the process. Any Comment is stored in SWP_RequestComment table.
When a RequestItem is created or updated, the Software Portal uses the stored procedure named spSWP_UpdateRequestTable to insert or update records in the SWP_SoftwareRequest table.
A RequestItem has 4 types of references. Like a PublishingItem, these references are found in the ItemReference table, as shown in this grid:
| Reference hint |
Reference type |
Parent Item |
Child Item |
| SoftwareRequest to PublishingItem |
Related child |
Publishing Item |
Request Item |
| SoftwareRequest to Task |
Singleton child |
Delivery Software ? |
Request Item |
| SoftwareRequest to PortalUser |
Singleton child |
User Resource |
Request Item |
| softwarerequest created resourcetarget |
Related child |
Target Resource |
Request Item |
Please see Figure 5 - Software Portal tables that illustrates the associations within a RequestItem.
Legend:
- 1 ------- n - This association means a one to many, or 1 to (number) associations or references.
- Red box: PublishingItem
- Blue box: RequestItem
- Red line: PublishingItem association
- Blue line: RequestItem association
Figure 5 - Software Portal tables
The RequestComment object is created by using the Request Details dialog. Please see Figure 6 - Request Details for a screenshot of the dialog. Note that comments are not required, so no RequestComment association is required during the Approval process. In many cases the administrator will not comment when approving a request, only when denying. No one wants to receive a call because of a mysterious denial with no reason given, so it is highly recommended!
Figure 6 - Request Details
When requesting Software that is available but requires approval, the dialog Provides a number of options for the User to fill in. Certain inputs are strictly data driven, meaning they do not affect how the Portal handles the request. They are separated in this list:
Data only:
- Date required - This is a notification only. This will not change how the Administrator receives the request, but is added so that users can provide a needed-by date as an FYI.
- Comment
Functional options:
- Override maintenance windows - If a user removes the check from this option, it will affect how quickly software is delivered, if maintenance windows are in use in the environment. It is recommended to steer users away from this as most users will want software as soon as possible if they've gone through the trouble to request it.
- Send an email when the request status changes
- Send an email when comments are added
- Email Address: - This option is typically greyed out as the User will have already supplied an Email address when they initially setup their User Profile on first Portal load.
Figure 7 - Listed Software Request
The next dialog, found in Figure 8 - Unlisted Software Request, has turned out to be a bit controversial. Most administrators do not want to worry about providing possibly unmanaged software to users. The button, therefore, gives End-users potentially unrealistic expectations on how unlisted software requests are handled. Previously, under the User Resources section, a method for removing this button is provided (with a disclaimer, be careful!).
In the Unlisted Software Request dialog, most of the fields are data-only. The email checkboxes are the only functional ones. It is this open-ended mechanism that can be problematic for Administrators as these requests appear as the User inputted them. On the flipside it does allow users to request software that is not available to them in the Software Portal. If the SLA of IT or the Helpdesk includes this level of service, then it is built-in to the Portal.
The administrators will receive the request much like any request, only the fulfilment of this request will need to be done manually by creating a Software Resource and publishing it, or pushing it out via a Quick Delivery or MSD Policy.
Figure 8 - Unlisted Software Request
When a RequestItem that requires approval is generated, the Portal Administrators and possibly Portal Managers are sent the request. The Manager or Administrator can then do one of several things:
- Approve
- Deny
- Place on Hold - This will leave the request unanswered, and the end-user can see that the request is on hold. It is recommended to add a comment as to why an item is on Hold. For example:
- Commented - Portal Admin added comment: "IT is in the process of acquiring more licenses for the application you have requested. When obtained, this Software will be approved and delivered to your computer."
What is the difference between the Administrator and the Manager Portals? Please see Figure 9 - Administrator Portal Page, and Figure 10 - Manager Portal Page for screenshots of the Portals.
Figure 9 - Administrator Portal Page
Figure 10 - Manager Portal Page
The Administrator Portal can be accessed through the Symantec Management Console (SMC) and gives the Admin full access to all Software Requests currently in the system. This portal is found at AdminPortal\ViewSoftwareRequest.aspx. Any action available for a Request can be done by the Admin as he or she has full privileges. It is NS Role and Scope security that defines who has access to the Administrator Portal. By default the Application Identity and all Symantec Administrators have rights.
The Manager Portal is only accessed from the actual Software Portal. When a user who has Manager rights loads the Software Portal, they will get three "tabs" available as opposed to the usual two. The Manage tab provides access to requests that Manager has access to. This portal is found at ManagerPortal\ViewSoftwareRequest.aspx.
The Portal Manager can only edit requests from his subordinates. These subordinates are defined on the User Profile Page under the section "Add users" (this section is visible only for Portal Managers and Administrators). See Figure Figure 11 - User Profile Page for a screenshot.
Figure 11 - User Profile Page (UserProfile.aspx)
The "Add User" button allows the usage of both NT Local users and groups, and AD Domain users and groups. If AD is setup correctly, the Managers can add those they have access to at this UI. This will automatically route requests for any users in the list, or users who belong to groups in the list to the Manager Portal, allowing the Manager to fulfil the request.
If a subordinate is a domain group it means that ALL users from this group and from ALL children groups (recursively) are subordinates, and this Manager will be able to access and fulfil all requests.
Any Portal User, including the Portal Administrator and all Portal Managers create or update a User Resource in the SMP. This Resource is used as the Portal identity for any user that needs access to the Software Portal. This "Link" to existing User Resources within SMP, or the creation of a new Resource, occurs when any users opens the Software Portal for the first time and is prompted to full out the User Profile page.
See Figure 12 - Resource User data mapping to see how the data maps: Legend:
- Red Line: This links the two halves of the User Resource together.
- Green Line: Data for the primary User Resource table
- Blue line: Data for the auxiliary User table that contains additional details
Figure 12 - Resource User data mapping
Warning! The data the user enters in the User Profile page is added or created as part of that User's User Resource in the Symantec Management Platform. This may allow a user, as one IT manager told me, to name himself "Captain Kangaroo", with a job title of "Admiral", in the "Oceanography" department.
When a user first accesses the Software Portal, the following process is used to either promote the existing User Resource to a Portal User, or create a User Resource to give that user access to the Portal:
- The User accesses the Portal for the first time and is prompted for credentials. They enter their Domain credentials.
- The Software Portal attempts to find the User Resource within the SMP by the user's login name, namely Name.domain. The Stored Procedure used is: "spSWP_GetPortalUserGuidFromNT".
- The SWP will create a new User Resource if one is not found.
- If values already exist in the target tables for existing User Resources, it will skip those fields. Otherwise, the SWP will insert the User Resource fields from the User Profile Page and commit it (see mapping in Figure 12).
- Lastly, it takes the subordinates a Manager or Administrator may have added and saves the Parent Resource Associations for them. See Figure 13 - Relation between Portal Manager and Subordinates.
If a Manager of Administrator fills out the Users, additional steps are taken to create or use existing User Resources for their subordinates. This is true for any User or Group. Relation between Portal Manager and his subordinates is implemented as a Parent Resource Association between the User Resources with Guid "7AE2308D-84FC-41e9-AAF9-8E2C6BE51735", as shown in Figure 13.
Figure 13 - Relation between Portal Manager and Subordinates
Depending on the size of the organization, and the availability of Managers for the Software Portal, filtering may be crucial to properly administering the various Software Requests that may exist.
A Portal Administrator can filter out requests by the following criteria:
- Status: Any (default), Open, Approve, On Hold, Deny
- Request type: Any (default), Listed, Unlisted
- Request category: Any (default), Approved Software, Software Requiring Approval, Approved MDP, MDP Requiring Approval, All Approved, All Requiring Approval
- Assignment: Any (default), Admin, Manager
- Managers: Any (default), [List of ALL Portal Managers - uses the spSWP_GetAllManagers stored procedure]
A Portal Manager can filter out requests from his subordinates by:
- Status: Any, Approved, Denied, Open (default), On Hold
- Request type: Any (default), Listed, Unlisted
- Show only requests from users who report directly to this manager or show requests from subordinates of subordinates of this manager (recursively), if such relationships exist.
The first step in the process when an administrator or manager of the Software Portal logs onto the Administrator or Manager portals, respectively, is to filter out requests according to the selected Status, Request type, Request category, and Assignment options. For the Administrator portal, the stored procedure used is quite simple, namely spSWP_Admin_GetFiltereRequest. This stored procedure executes the following type of SQL query:
SELECT req.*, i.Name
FROM SWP_SoftwareRequest req, Item i @WhereQuery
The @WhereQuery point is a single parameter of the stored procedure, and is a WHERE clause that the Software Portal constructs from the Web.AdminPortal.ViewSoftwareRequest.aspx page according to the selected filter options.
In the case of a Portal Manager the stored procedure spSWP_Manager_GetFilteredRequest is used. Its input parameters are request's state, status and category (see SWP_SoftwreRequest table, State, Status, Category fields). In this way the Portal is using the Manager's own assignments to populate what requests he or she sees. This leads into the next step.
The Manager Portal then filters out requests based on what users or subordinates the Manager has assigned to him or her. This step is optional for Portal Administrator (only if a manager is selected in the filter). Of course for a Manager the filter happens automatically. This filtering is implemented inside the Software Portal's .NET assemblies within the GAC, and is common for both a Portal Manager and the Portal Administrator.
The SWP then uses an Algorithm with input that is the set of request items filtered for in the first step, and is executed as follows:
- Get unique requesters (map of Resource User Guid to Resource User Name) from all requests. This is done in the Code and is not available via SQL or other visible methods.
- Next the SWP gets ALL Managers if one is selected in the Administrator Portal, or automatically selects the Manager who is logged into the Manager Portal. Also show requests from subordinates of subordinates. The SWP uses the stored procedure spSWP_GetAllManagers to accomplish this.
- The SWP now Matches requesters that are subordinates of the Portal Manager:
- First, the SWP gets ALL subordinates of the Portal Manager. The stored procedure spSWP_GetUsersByManager is used. This procedure returns all subordinates analysing only the Notification Server's database. The main obstacle here is that a subordinate of the Portal Manager may be An AD or local group, but a requester is always a user. The SWP needs to know - is the requester a member of a group that is the Portal Manager's subordinate or not? For example - We have a group "G1" in domain "Dom1", and this group is a subordinate of the Portal Manager. Requester X is member of the group "G1". The Portal Manager can manage requests from user X. This is a simplest case.
- Second, the SWP Iterates through all the subordinates. If a subordinate is an AD user - try to find a matched requester (duplicate). If matched - remove the option "remember this requester" and remove it from the unique requesters map. If the subordinate is an AD group - remember it for future analysis.
- Third, the SWP Iterates through all the subordinates that are AD groups. It finds requesters that are direct or indirect members of the subordinates groups. To optimize this matching, the SWP does it in "bidirectional" and "simultaneously (asynchronously) in multithreads". Bidirectional means that the SWP first gets a map of all parent groups (including the primary group) for all users and the requester. Following that it processes the group - subordinate and find it in the requester's parent groups. It accomplishes this recursively for all child groups of the subordinate group. The algorithm has been optimized for better performance, in that it remembers all analysed groups to avoid repeating and cyclic dependencies. It stops analysing if no more requesters are found, and it analyses simultaneously in several threads. This process only uses a .NET API, with no database stored procedures in use.
- Lastly, the SWP does it recursively for all sub-managers that are subordinates of the Portal Manager, if applicable.
- The next step done is to exclude requests from the initial set where the requester is not a subordinate of the Portal Manager. See Figure 14 for a graphical representation of this process.
Figure 14 - Filter Portal Manager Subordinate
For ease in administering Portal requests, a Change Status control allows very quick approval or disapproval. The Administrator or Manager can also use the Edit control if some of the default settings or a comment needs to be added. See Figure 15 for a screenshot of the edit window.
The change of status is saved in the SWP_SoftwareRequest table. If a comment has been added, it is saved in the SWP_RequestComment table as new record (see Figure 5 - Software Portal tables).
Figure 15 - Edit Request
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.
Listed Software
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).
- 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.
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).
- 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.
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.
a. To find all Parent groups the type of LDAP queries that are used are, for example: "Select all the groups that have <user> member"
b. 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.
a. The first analysed domain is the user's domain.
b. 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.
The 7.5 Portal has been heavily optimized based on feedback learned during the use of previous versions. However be aware that 7.5 SP1 prior to HF3 there was a change that caused serious issues. You should upgrade if you are using SP1 GA, HF1, or HF2.
The following items cover troubleshooting the use of the Software Portal. Resolution steps should be reviewed with care to ensure you have the issue they are to address.
Portal takes a long time to load or times out
While this used to be a common problem, a basic configuration resolves this issue in most circumstances. Please follow these steps to resolve the issue.
- In the Symantec Management Console, browse under Settings > All Settings.
- In the left-hand pane, browse under Software > Software Portal Settings > and select Software Portal Settings.
- Uncheck the box labeled "Publish software across all trusted domains".
- On the Symantec Management Platform server, run Regedit from the Run field or command prompt.
- Browse in the registry under HKEY_LOCAL_MACHINE > SOFTWARE > Altiris.
- Right-click on the Altiris key and choose New > Key.
- Name the key: SWM
- Right-click on the newly created SWM key and choose New > Multi-string value.
- Name the value: IncludeDomainList
- Enter all Domains to be used within the Portal. Note that the more domains you add, the most impact it will have on performance.
NOTE: Enter both the basic name and the FQDN of the Domains needed.
- Click OK to save the string. This will allow the Portal to restrict what domains it uses.
Software Requests cannot be made
This one has come up enough that the process to resolve should be included. While following the steps to resolve you'll be able to tell if the resolution will work or not based on if you can follow the steps or not. This issue includes the following symptoms:
- A certain piece of Software cannot be requested by any user
- All software cannot be requested by any user
- All software cannot be requested by a specific user
- A certain piece of Software cannot be requested by a specific user
Steps to resolve:
- In the Symantec Management Console browse under Settings > All Settings.
- In the left-hand pane browse under Software > Software Portal Settings > and select Administrator Portal.
- In this list look for Software Requests in an "Open" state.
- If it is only a specific piece of software that cannot be requested, look for that software that has a request in an Open state.
- If it is only a user that cannot request software, search for that user.
- You may use the column headers to sort.
- If the Request Type is Approved, and the Status Open, that is a sure sign of a problem with the request.
- For any of these requests, try to complete them by approving them. Often this will fail or not change the status from Open.
- Write down the IDs for all software that are Open and cannot be fulfilled.
- In SQL, run the following query to remove the request:
DELETE FROM SWP_SoftwareRequest
WHERE RequestID = '1'
AND RequestID = '34'
AND RequestID = '185'
- That should clear up the issue. If it happens again, look for the same symptom of Open requests that cannot be fulfilled.
After you've setup your Quick or Managed Deliveries, now you need the ability to track the deployments. This can be accomplished in two basic ways: Task Server Status grids, and the Software Management Reports. Both methods provide insight into the degree of success for a quick deployment or a Managed deployment.
Task Server Statuses
The status grid and drilldowns provided by Task Server are not available for Managed Delivery. The main reason for this is that the Tasks executed during a Managed Delivery are not initiated from the server, but are client-initiated tasks. This leaves Quick Delivery as the consumer of this feature.
To demonstrate how this works, I'll use the test deployment of SQL 2008 previously configured. In this example I want to check to see how the Quick Delivery Task operated.
- In the Symantec Management Console, browse under Manage > Jobs and Tasks.
- Browse down through Jobs and Tasks > System Jobs and Tasks > Software > Quick Delivery.
- When you select your Task, in this example SQL 2008, you'll receive the following screen:
- As seen, this deployment failed.
- Double-click on the scheduled instances to drill down into this instance.
- This gives you a more in-depth view of statuses. If this rollout had multiple target computers, you'd have the ability to see status per resource. See this screenshot for an example:
- To receive all status information for a particular execution attempt, drill down by double-clicking on the row desired.
- The following screenshot demonstrates this screen:
- As you can see, the Task was terminated based on the execution time exceeding the Task timeout value set under the Advanced Settings.
For tasks, this grid system allows you to view the status at multiple layers, with greater granularity the further you drill down.
Provided Reports
Reports offer flexibility in how you want to view the results of a managed or quick deployment. The following reports are available for use in tracking deployments.
For Task Server Quick Delivery reports, they are found in the Symantec Management Console under Reports < All Reports < Software < Delivery (some reports contained in the root) < and Status.
NOTE: These are for Quick Delivery Tasks only:
- Software Delivery - Download Status
- Software Delivery - Download Summary
- Software Delivery - Execution Attempts
- Software Delivery - Execution Failures
- Software Delivery - Execution Status
- Software Delivery - Execution Summary
- Status > Quick Delivery Details by Task
- Status > Quick Delivery Details by Computer
- Status > Software Delivery - Status (All Instances)
- Status > Software Delivery - Summary (All Executions)
Obviously some reports are better than others for giving you an idea how compliant your target systems are. For my example I will use the Software Delivery - Execution Status in tracking the previous SQL rollout.
- Load the report Status > Software Delivery - Status (All Instances).
- Change the date range to start at the date you initially configured and rolled out your task.
- If necessary, choose a specific Task to track. In my example I only had 2 and left the field as All.
- Click Refresh.
- See the following screenshot for the results:
- Manipulate the parameters as needed to tune your results. Most of the reports listed above have the same parameters.
For Managed Software Delivery Policies, the Reports are found in the Symantec Management Console under Reports < All Reports < Software < Compliance. The following reports are available:
- Software Compliance by Computer
- Software Compliance by Managed Delivery Policy
- Software Compliance Detailed Summary
- Software Compliance Details by Computer
- Software Compliance Details by Managed Delivery Policy
- Software Compliance Remediation Summary
- Software Compliance Status
- Software Compliance Summary
These reports fit the nature of a Managed Delivery Policy. For example browse to the report: Software Compliance Summary. I've included all MSDs I've deployed in the example shown in the screenshot below:
Other reports provide more specific details for any given MSD. Review them all to find the one that gives you the best representation of the data you require.
I hope this best practices article helps ease you into the use of Software Management on the Symantec Management Platform 7.5. As new versions are released, some of this information may become out of date. Keep this in mind if you come across a screen you see or a step that doesn't fit. There have been changed in 7.6 where the UI may look a little different, but all points still apply.
Symantec Software Management 7.5 Troubleshooting and Best Practices: Part 1
Symantec Software Management 7.5 Troubleshooting and Best Practices: Part 2
Symantec Software Management 7.5 Troubleshooting and Best Practices: Part 3
Symantec Software Management 7.5 Troubleshooting and Best Practices: Part 4
Symantec Software Management 7.5 Troubleshooting and Best Practices: Part 5
Symantec Software Management 7.5 Troubleshooting and Best Practices: Part 6