Software Management Group

The Software Portal
   Common Terms and Acronyms
   Software Publishing
      Software Resource Publishing
      Managed Software Delivery Policy (MSD) Publishing
   Software Request
      User Resources Intro
      User Interaction
      Requests and Updates
      Request Dialogs
   Software Approval
      Portals
      User Resources
      Filtering The Admin or Manager Portals
   Quick Delivery or MSD Fulfillment
      Listed Software
      Managed Software Delivery Policy
   Populating The Portal
      Tables In Use
   Known Issues

The Software Portal

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 too 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

Software Publishing

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:

1. 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.
2. 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:

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.

Software Resource Publishing

Previous to SWM 7.0 SP2 MR4, the Software Portal choose the default Command-line for the type "Install" automatically when you published it to the Software Portal. While this works for basic end-user publication, it did not fit those who gave greater access to command-types to their Helpdesk or IT personnel. In light of this now the Command-lines can be associated directly, giving the flexibility that was found in the 6.x Portal, while still providing the more user-friendly 7.0 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

Managed Software Delivery Policy (MSD) Publishing

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

Software Request

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.

User Resources Intro

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.

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.

One button that an administrator might not want his Symantec Administrators to use in the Software Portal is the "Manage" button.

Change the style="display:none" for the Manage button in the Home.aspx file found under the Software Portal installation directory <ADDIT>

                                <td rowspan="2" class="toolbarButton" id="btnManage" runat="server" onmouseover="ToolbarButton_OnMouseOver(this,'background-image: url(../images/headerToolbarBackgroundHighlighted.png)');"
                                    onmouseout="ToolbarButton_OnMouseOut(this);" onclick="ToolbarButton_OnMouseClick('/Altiris/SoftwarePortal/ManagerPortal/ViewSoftwareRequest.aspx');"
                                    style="background-image: url(../images/headerToolbarBackground.png); display: none">
                                    <div style="height: 41px; width:64px;">
                                        <img alt="" src="../images/btnManage.gif" class="toolbarImage" id="btnManageImg" runat="server"/>
                                        <div class="toolbarText" style="color: #000000;">
                                            <%= GetLocalisedString("Manage") %></div>
                                    </div>
                                </td>

To hide the "Request Unlisted Software" button, there are several methods, including rewriting the ManualRequestConfirmation.aspx to state that this button shouldn't be used for now, but for most of us making a simple edit is the preferred method.

To remove this button, add Javascript code into the AddRemoveProgram.aspx page that would hide the Request Unlisted Software button. Into the existing <script> add:

                function DisableRequestUnlisted()
                {
                                var toolbar = ExpSecCtrlAvailableSoftware_gcSoftwareToolbar;
                                if (toolbar == null)
                                {
                                                setTimeout('DisableRequestUnlisted', 200);
                                }
                                else
                                {
                                                toolbar.toolbarButtonControls[2].setEnabled(false);
                                }
                }

And to the body tag add attribute onload="DisableRequestUnlisted()"

You must verify how does gcSoftwareToolbar gets resolved. This control can get a different name depending on the version of ASP/IIS.

Other modifications can customize the initial User Profile prompt and the Software Portal itself. If you do this extensively, please make two copies of all files, one for the custom portal and one for the default. This will enable Symantec Support to troubleshoot issues that do not stem from customizations by accessing the default Portal.

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

Requests and Updates

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 fulfills, 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:

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.
2. Red box: PublishingItem
3. Blue box: RequestItem
4. Red line: PublishingItem association
5. Blue line: RequestItem association

Figure 5 - Software Portal tables

Request Dialogs

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:

1. 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.
2. Comment

Functional options:

1. 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.
2. Send an email when the request status changes
3. Send an email when comments are added
4. 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 flip side 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 fulfillment 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

Software Approval

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."

Portals

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 fulfill 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 fulfill all requests.

User Resources

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:

1. The User accesses the Portal for the first time and is prompted for credentials. They enter their Domain credentials.
2. 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".
3. The SWP will create a new User Resource if one is not found.
4. 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).
5. 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

Filtering the Admin or Manager Portals

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:

1. 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.
2. 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.
3. The SWP now Matches requesters that are subordinates of the Portal Manager:
   1. First, the SWP gets ALL subordinates of the Portal Manager. The stored procedure spSWP_GetUsersByManager is used. This procedure returns all subordinates analyzing 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.
   2. 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.
   3. 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" (This is new in 7.0 MR4 and 7.1). 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 analyzing 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.
   4. Lastly, the SWP does it recursively for all sub-managers that are subordinates of the Portal Manager, if applicable.
4. 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). If you are not using MR4 of 7.0 or later, please see the Known Issues section for a limitation when using the Change Status control.

Figure 15 - Edit Request

Quick Delivery or MSD fulfilment

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:

1. 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.
2. 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).
3. 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).
4. 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.
5. 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".
6. 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.
7. 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.
8. 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:

1. 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.
2. 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).
3. The SWP then gets a Resource Target using the spSWP_GetResourceTagetGuidForPublishing stored procedure.
4. 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.
5. The Portal will then execute a Save of the MSD Policy.
6. 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:

1. The Software Portal obtains the Active Directory entry of the user accessing the Portal.
2. 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).
3. 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.
4. 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.
5. 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.
   1. To find all Parent groups the type of LDAP queries that are used are, for example: "Select all the groups that have <user> member"
   2. The LDAP queries the SWP executes are within a single domain.
6. 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.
   1. The first analysed domain is the user's domain.
   2. 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.
7. Relations between groups, which are found in any trusted domains, are also analysed.
8. 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.
9. 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.

1. SearchValue = what to search (by default it is %)
2. OnlyRecommended = search for only recommended software, toggled by the Recommended button on the Portal
3. 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.

Known Issues

The 7.1 Portal has been heavily optimized based on feedback learned during the use of 7.0.

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:

1. 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.
2. Poor Portal Performance - Many optimizations were made in MR4. MR3 contains some performance optimizations, but the real heavy hitters were released with MR4.

Return to Symantec Software Management 7.1 Best Practices, Part 6

Coming soon: Symantec Software Management 7.1 Best Practices, Part 8