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:
Software Approval
Portals
User Resources
Filtering the Admin or Manager Portals
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.
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 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:
- 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
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:
- 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:
- 3.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.
- 3.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.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.
- 3.4 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 Part 1). 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
Return to: Part 1
Read: Part 3