Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.

Technical White Paper for the Software Portal in Software Management Solution 7.1, Part 1

Created: 14 Feb 2011 • Updated: 15 Feb 2011 | 1 comment
Language Translations
Joel Smith's picture
+2 4 Votes
Login to vote

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:

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

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.

Common Terms and Acronyms

The following acronyms will be used commonly throughout the article:

  • 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:

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.

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 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 Related child Target Resource Request Item
resourcetarget      

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

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

Read: Part 2

Comments 1 CommentJump to latest comment

yabru's picture

Hi Joel,

Any chance you have a PDF version on this?

Regards Steve

0
Login to vote