Software Management Group

 View Only

Symantec Software Management 7.1 Best Practices, Part 4 

Aug 30, 2011 01:34 PM

Managed Software Delivery
   General Configuration
   Software Resource Settings
   Advanced Options

Managed Software Delivery

Managed Software Delivery Policies are the intelligent way to deploy and manage software. These policies are versatile, and enable you to make use of the functionality discussed in configuration terms about the Software Components. Unlike Quick Delivery Tasks, Managed Software Delivery policies are Agent-based. The policies and executions are tracked on the Agent side.

General Configuration

Setting up a basic Managed Delivery policy is easy. Most of the configuration is done on the front end when you create the Software Resource. The following walkthrough takes you through the basic setup of a Managed Software Delivery (MSD) Policy.

  1. In the Symantec Management Console browse under the Manage menu and click Policies.
  2. In the upper left-hand pane browse down through Software > and select Managed Software Delivery.
  3. Right-click on the Managed Software Delivery folder and choose New > Managed Software Delivery.
  4. Name the Policy. As the name is not initially selected it is easy to fail to name it, which may result in confusion as the default name New Managed Software Delivery. Click on the name field to activate it.
  5. If desired, add a description by clicking on Add description found below the Name field.
  6. Under the section Policy Rules/Actions, under the Software tab, click the + Add button and select a Software resource.
  7. In the picker use the Search field to find the applicable or desired Software Resource and click OK. See this screenshot for an example of an added Software Resource:

  8. In the right-pane you can select what Package and Command line the Policy will use. Be sure to select the correct command line. If an uninstall command-line is selected inadvertently, this policy will not behave as expected.
    Note that the above example shows "A detection rule is not defined for the software." This does not mean the Policy will not run any Detection Rule, in fact it will run one. The default detection rule uses the Softwarecache.xml where the Software Discovery data is held. When software is installed, an entry is put into this cache to be reported the next time Inventory runs. If no detection rule is defined it will look for the software using this information in the cache file
  9. Scroll down and open the Applied to section by clicking on the expand/shrink arrow button.
  10. Click Apply to v dropdown and choose Computers.
  11. The Filter interface should be familiar if you walked through the Quick Delivery section concerning creating a Target. Add machines using the same method described on page 32.
  12. You should now see a row for the Computer List you just created, including a Count column that shows you how many machines are targeted for the Policy.
  13. Scroll down and open the Schedule section by clicking the arrow button.
  14. Starting with 7.0 MR4 and 7.1, there are two schedules that can be applied to a Managed Software Delivery Policy. The first schedule is the Compliance check, the second the remediation.
    A common request involves having target clients download the package in advance, or even well in advance, of the execution. The download is tied directly to the compliancy check (running of the detection rule). Set the Compliance check well in advance to allow systems time to download the package. This is useful for large packages or servicing WAN sites.
  15. Under the Compliance section click the Add schedule v Dropdown and select an appropriate Schedule option. The different settings here will be covered later.
  16. 16. Under the Remediation section, either leave the default set to immediately or set a schedule later than the compliance schedule. Here is a screenshot showing the two schedule options:

  17. After adding the schedules, browse back to the top and be sure to turn the Policy on by clicking on the On/Off toggle dropdown and selecting On.
  18. Click Save changes to save and commit the policy.
How do I get the ASAP option to run a Compliance check immediately? This is a common question, especially from those customers who were familiar with the ASAP option found in version 6.x of Software Delivery. In the above screenshot, you'll notice there is a reoccurring schedule and a run once schedule with no repeat. ASAP is achieved by having a Run Once > No repeat schedule where the Start date is in the past. If you want ASAP to work right out of the gate, click Advanced and change the start date to the day prior.

Software Resource Settings

After you've added a Software Resource to a Managed Software Delivery Policy, you have a myriad of options in how the policy interacts with the Software Resource during detection and deployment. This section covers all the settings involved. When selecting a Software Resource in the Rules/Actions list, the right-hand pane presents the settings surrounding the Resource.

Compliance settings

By default the Compliance Settings will automatically choose what Detection Rule was selected during the creation of the Software Resource. You can toggle the detection on or off by checking or removing the check to the box labeled: Perform software compliance check using:. You can also manipulate the detection rule by clicking on the hyper link named after the Detection Rule name. You will see the View Rule dialog, which allows you to edit the Expressions and rules defined.

WARNING: Changing a Detection Rule in this window will result in the Software Resource being updated with the changes. Only make changes that you wish to make to the Software Resource directly. Also note the default detection rule explained under the Managed Delivery Policy walkthrough preceding this section.

Remediation settings

By default the Install Command-line is selected in the Command-line dropdown. If the Resource has more than one command-line, use the selection dropdown to choose the appropriate one. Below the dropdown the Command-line is listed for reference so you can ensure you've selected the right one. The Package dropdown allows you to select a different Package if the Software Resource has more than one Package defined. For most use cases typically only one package is required or specified.

Supersede settings

The two checkboxes listed here allow greater control of how updates and newer versions are handled in regards to the Policy. The logic to allow automatic updates or to avoid applying a lower version than what's already installed avoids any issues stemming from the wrong versions being applied.

  • Automatically upgrade software that has been superseded by this software - Any software detected that this software supersedes will initiate the update.
  • Do not install if a newer version of this software is already installed - This uses any Software Resources marked as superseding the selected Resource.

Note that the options will be grayed out if no Supersede associations are found for the selected Software Resource.

Advanced options

At the bottom of the Remediation settings section Advanced options are offered. While these are similar to those Advanced Options covered earlier for Quick Delivery Tasks, there are key differences. This section covers the different options and how they affect the Policy. First I'll details the options, and then provide a walk-through for some of the more popular options.

Download Options

By default the Altiris Agent will download files to the following location: install_path\Program Files\Altiris\Altiris Agent\Agents\SoftwareManagement\Software Delivery\. Each package is placed inside a folder matching the GUID of the Package and a subsequent Cache folder. At times an administrator may want to put the package in a non-default location. Change the Destination download location radial to Location on destination computer. The path will be local relative to the target systems.

The Download using: options present a unique situation. In versions 6.x the defaults found here were also found under the Altiris Agent Configuration Policies. This is no longer the case. The settings for Downloading in the Altiris Agent Configurations and the options here are exclusive. While it does add to confusion, it allows you to configure more options than previously. There are two primary use cases for manipulating the options here:

  1. Control limited bandwidth between the Package source and target clients, particularly in WAN environments or poor VPN connections.
  2. Have the execution occur locally directly from the Package Server instead of downloading it first.
The two checkboxes can be checked, giving the appearance that the two settings can be used together. Since they are mutually exclusive concerning downloading or running remotely, you should only use one at a time.

The option: Delete package from client computer can be used to control how long the source files are available. For most Managed Software Delivery Policies the default is 7 days. You may need to increase this, or deselect the option altogether when considering how long the source files should stay for the circumstance.

The nature of installations may suggest you'll only need the files for the Installation. Check the option to delete the package to clean these up, especially if hard drive space is at a premium. One type of exception is for those applications that install via an MSI and where the Source files may be needed in the future for a Repair, Component addition, etc.

Run

The Run As options provides options for what user context will be used for the installation.

The default option on a Managed Software Delivery Policy was changed to be the Symantec Management Agent credentials. The policy will use the Agent credentials to elevate the execution from a logged on user that will allow this configuration to work even for users that do not have install rights. Note that we execute in a separate session so any rights elevation will not be usable by the logged on user. We have seen occasional rights issue despite the elevation, so unless there is a reason to target the logged on user, it is advised to only use this when the installation requires the user's own session.

Generally the Symantec Management Agent credentials are sufficient for an install. Since the package is downloaded, all necessary rights exist on the local system. Some exceptions to this are detailed here:

  • The install accesses network resources or location during the install. This does not include the ability of the application to contact network resources after the installation.
  • The source files for the install will be executed from a remote location, such as a UNC or the option to execute from the Package Server is selected.
  • The application must be run under the User's context that will launch the application for use.

For the first two use-cases, Specific user should be used, one that has rights to the resources or network locations to be used during the execution. For the last one the execution must be set to Current logged-on user.

For applications that only work when installed under the user's own context, use the configuration Current user credentials and it will elevate the install session for that user to allow the install to proceed. Occasionally we've seen issues with this, so test before deployment.

User run conditions allow greater control over how and when the policy executes. The following options are available:

  1. Task can run: - This option allows an administrator to control in what state the system is in for execution regarding user log on. Scenarios include:
    1. Only when user is logged on - This is the only option if you selected Current logged-on user under the Run As section, though if you selected another Run As you can still specify this to ensure someone is logged on when the execution occurs. This is important if your installation requires some sort of user interaction when it executes.
    2. Whether or not the user is logged on - This option is used to allow the install no matter what user state the system is running under. This one will allow the policy to execute the soonest.
    3. Only when no user is logged on - This allows an administrator to restrict resource intensive installs to run when no user is actively using the system.
      Option C can cause difficulties depending on how users manage the power state of their computers. For example if they log on quick enough after booting up the computer the execution may miss the small window of opportunity. Also if users don't typically log out, but shut down their systems at the end of the day, this can also delay the remediation.
  2. Repeat this task for each logged on user - if the installation you are running requires to run under the user's profile to apply correctly, this option is very useful to ensure it runs for every user who uses the system.
  3. Allow user to interact with installation software - To put it simply, this pipes the execution to the User's desktop, running in interactive mode. You can also select how the execution shows, from the following list:
    • Normal
    • Hidden
    • Maximized
    • Minimized
  4. Prompt user before running - This setting allows the user to defer the execution. This helps mitigate any work the user is conducting when the installation begins to happen. Users can save their work before the installation to avoid any potential data loss.
    This screenshot shows a typical configuration of this tab:

Results-based actions

Outside of the actual execution of the Software Resource, these settings allow how the Symantec Management Agent and Plug-ins interact with the task.

  • Upon success: This allows the Task to execute a Log off or reboot of the system after a successful completion.
    It is highly recommended to allow the Symantec Management Agent to initiate a reboot. This allows the Agent to properly handle all Agent processes so nothing is lost on the reboot. For example the progress of the Managed Software Delivery may be lost if the installer executes the reboot (stored in the file AeXSWDPolicy.xml). In the command-line suppress the reboot and select the Upon success option to initiated the reboot.
    • Allow user to defer action up to: Use this option to allow the user to save and make any other preparations for the reboot. This is highly recommended when configuring a reboot to minimize user disruption.
    • Force running applications to close - If an open application prevents the shutdown, this option will forcibly end the application to conduct the reboot. Use with caution.
  • Terminate after: This option is a fail-safe to prevent hung or sluggish installs from locking up the Altiris Agent Policy queue. Generally putting in a value that is safely beyond the expected execution time, but not too long to paralyze the Agent, should be used.
  • Upon failure: The following selections are available:
    • Abort - This will stop the MSD from continuing. If you've configured more than one resource or task in the MSD, any subsequent items will not be run.
    • Continue - this will instruct the MSD to continue on to subsequent items in the MSD.
    • Restart - This will retry the remediation execution. Max retries should be set to an appropriate number.

Walkthrough

The following process uses common settings to configure the Advanced options of a Managed Software Delivery Policy.

  1. Select the Managed Software Delivery Policy to configure, or if you are still in the creation process, click the Advanced options button under the selected Software Resource.
  2. Under the Download Options tab, under the Delete package from client computer settings, check the box labeled: If unused for:.
  3. From the drop down select an appropriate length of time. For this example I set 7 days.
    This setting only comes into effect when the Managed Software Delivery Policy no longer applies to the targeted system. This means under normal circumstances the package will not be deleted. If you use a dynamic filter, or you disable the policy, then the setting will apply to the Package.
  4. Click the Run tab.
  5. Change the option to Symantec Management Agent credentials.
  6. Leave the option checked: Allow user interaction. Since you can suppress visually the execution via the command line or by the setting of how it starts (choosing hidden), this option can remain checked. In few occasions we've found user-based installs to work using this option checked.
  7. Check the option Prompt user before running.
  8. Check the option Allow user to defer up to a total of.
  9. Input an appropriate length of time, such as 30 minutes or 1 hour.
  10. Click the Results-based actions tab.
  11. Change the Terminate after: setting to 5 hours (in 7.1 this is the default).
  12. Change the option Upon Failure to Abort. See this screenshot for an example:

  13. Click OK to save the changes.
  14. If newly creating a Managed Policy, Click OK to create it. If editing an existing Managed Policy, click Save changes to apply the new settings.

Return to Part 3

Coming Soon: Part 5

Statistics
0 Favorited
1 Views
4 Files
0 Shares
0 Downloads
Attachment(s)
jpg file
ssm71-4-01.jpg   50 KB   1 version
Uploaded - Feb 25, 2020
jpg file
ssm71-4-02.jpg   59 KB   1 version
Uploaded - Feb 25, 2020
jpg file
ssm71-4-03.jpg   51 KB   1 version
Uploaded - Feb 25, 2020
jpg file
ssm71-4-04.jpg   33 KB   1 version
Uploaded - Feb 25, 2020

Tags and Keywords

Comments

Mar 26, 2014 06:36 AM

Does this still pertain to 7.5?

May 30, 2013 08:31 PM

Hi Guys

Thanks for the followup, Joel.

An update to our situation. We were experiencing the issue decribed here: (We went for option 2)

http://www.symantec.com/business/support/index?page=content&id=TECH146168

Our database blew out in size and overall performance degraded to a point where compliancy checks were timing out and the entire Altiris infrastructure was grinding to a halt. It seems that compliancy checks do do immediate communications with the database - I thought these would be handled locally then sent off afterwards. Resolving the issue in the above tech note shrunk the size of the DB enourmously. In addition to this, the TempDB on our database server was also filling up when we hit certain config pages to actually fix the database issue. We were stuck on this for quite a while! We ended up modifing the database directly (not recommended) to get around this issue.

However over time, it has stabilised. We have over 600 active managed software delivery policies. These have been modified so that the remediation frequency is 6 hours instead of one hour which has helped.

We still have issue with the TempDB filling up drivespace on the SQL server from time to time. Our admins allocated 20G on this drive, and we frequently use this up. A dedicated SQL server is in the works.

regards

Tonos

May 30, 2013 06:37 PM

I checked with the Notification Server team who covers the Agent UI and neither they nor I am familiar with this issue. I recommend logging a case with Symantec Support.

May 30, 2013 10:23 AM

Any word on this? We're starting to rn into the same sort of thing and ned a way to prioritize some things.

Feb 13, 2013 10:40 AM

I'd like to see some response to this.  I'm seeing issues with our managed delivery policies for new machine deployment.  After imaging the base OS, it joins the domain and the console then gets 20-30 polices for software installs.  It seems like they all just run at the same time.  There doesn't seem to be any way to prevent multiple remediations running at the same time.  So with Office, Java, Reader, Flash, etc all running together, the install time takes much longer than normally expected.  

Jan 17, 2013 05:41 PM

Hi Joel

 

Thanks for the response. Are there recommended limits for the amount of MSD policies sent to any given client? We're testing a software loadout, so we've piled quite a few MSD's on to the one computer. The client seems to be choking a lot, and eventually the UI doesnt respond (but you can still see installers running in the background). When the UI is working, it is in a constant state of refresh and pretty much unusable till some of the work is complete - way way slower than the NS6 client was. Ive also seen anecdotal evidence that running software resources directly from the server (for large packages) will choke the client much more than downloading and running locally.

Policies are set to run a command line within a packaged software resource (mostly MSI), and there are the odd packages with dependancy and/or update tasks. Each resource has its own detection rule set. In the advanced options, a custom - but common to all clients local destination is set. We found the default path could cause 'pathname too long' errors in some installs. The default local cache file path is huge!! Most policies are set to use default management settings to download - but several packages >5GB are set to run from the server.

On average, I terminate any install after 30 minutes, with some larger installs set to 55 minutes. This would fit running each MSD policy in a sequence, but I cant work out the sequence if any between policies - and if it is affecting install times.

We have 3 schdules set for each policy. One set at 00:00 to trigger immediate installs once the client has received updated configurations. This is not repeated

Another for remediation - to check at computer startup

And another set to use a time window - all day, to check each hour during the window for compliancy. This was set to pick up any 'Stopped Tasks' timing out (repeated daily) - the issue from my previous post. The thought was the client would eventually right itself.

My test machine currently receives about 40+ policies - which the client service appears to internally handle - but the UI constantly seems to be updating - after sub tasks complete im guessing. In the end, the UI just gives up. In the task history, I notice there are a heap of tasks 'in progress' at once from multiple MSD policies and I cant see anywhere to manage MSD policy queueing. They seem to all just go for it like a bull at a gate, running their tasks in the correct order within the policy, but seemingly synchronously with other MSD policies. The client handles under 10 policies much better, but we had software loadouts using NS6 with this many and the client handled it no worries. Overall we have seen the NS7 client a LOT slower than the NS6, especially the UI when either a configuration update is occurring, or tasks within a MSD policy complete/fail and the client updates itself to move on to the next task. On top of all this im seeing random detection tasks fail (immediately) -but succeeding on the very next run. 

We currently manage a fleet of about 8000 PC's, with just under half being student computing labs. The labs currently run on NS6 still and we're hoping to upgrade to NS7 to be in line with our staff machines. It just seems that the NS7 client is struggling for some reason. And our labs have a much heavier software loadout than staff machines.

Having said all this, our server seems to be performing fine with load you would expect to see.

It probably will need a support ticket, but id love to know the logic the NS client uses when processing multiple MSD policies on a single client with multiple software resources within them. Are there limits? How does the client decide what MSD policy to run next etc. Can I just set the client to run MSD polcies... one at a time.

cheers

Tonos

Jan 17, 2013 11:34 AM

Hi Tonos,

Policies should not run at the same time (the remediation action). The timeouts are for the execution only. The detection checks and downloads are separate, unless you've added a Quick Delivery task? It is recommended to add the software direction and let the policy mechanisms handle the queuing. Can you let me know how he policy is setup?

If his requires investigation I recommend calling in a support case.

Regards,

Joel

Jan 14, 2013 08:10 PM

Hi Joel

You mention the option 'Terminate After' should be set to an appropriate value to avoid hogging the policy queue. Could you elaborate on the Policy Queue and any logic the client uses behind this? I believe im having an issue at the moment related to this - for example in this scenario:

App 1 - Adobe CS6

App 2 - Matlab 2012b

App 3 - Flash runtimes

By default, I set the terminate after to around 55 minutes for large apps, and 15 for apps which pretty much install in under 10 seconds. I noticed in each policy, several apps may be 'in progress' for the execution of their main command line - but of course only one is actually installing at any one time. Im starting to see some smaller apps time out as I think this 'queuing' might be starting their install timer before its actually installing. For the above example, all three apps would eventually be 'In Progress' for their installer, while in this case only Adobe CS6 is running. This is because all policies would have downloaded their software resources and made all compliancy checks before the first app would have finished installing. It usually is ok for the first two with their timer set at 55 minutes as both would manage to complete within 55 minutes, but for the if the flash installer set at 15 minutes would run last in this queue, im starting to see 'Task Stopped' as the 15 minute time frame would have passed long ago.

Is there any logic in how the client chooses to start multiple MSD policies sent to a client - or is it alphabetical order? size order?. I believed NS6 in addition to its 'Priority' setting ran packages that were smaller in size first.

I regularly deploy to lab environments - this occurs mainly after image refreshes where the client would need to download and install a heap of applications at once. This issue is usally fixed with remediation schedules set up, but if an install timer begins while it is queued then that would seem like a bit of a bug.

Ideally we would love to see larger MSDs run last, but I cant find any setting or documentation on how the client manages the policy queue for multiple MSDs.

- Tonos

Oct 18, 2012 06:15 PM

Hi Joel, can you handle the Case # 420-136-919 please ? I was providing all customer contact. In the error above we are facing a more critical problem. Those script was working "before" MP1 install.

And we can workaround this issue, changing the "application credential" to a "domain admin account"... The customer confirms they do not add GPO/change rights, so the MP1 install seems the cause of this issue.

This workaround is not a "best practice", We do not like using a "domain admin" to push on XML files all client computers, all the same a little bit crypted.

We also wonder if MP1 really cause, and what Symantec change into agent processing to get this issue.

We defintively need Symantec escalation for this investigation, as we don't know Symantec code :) Thanks,

Oct 18, 2012 08:26 AM

To correct myself, we have to keep "cmd /c MyBacth.cmd", or "wscript MyScript.vbs" in the command line, I was not remember Altiris do that for us auto. That's why I was thinking not necessary in the command line, but it seems to be required. Sorry the mistake.

Oct 18, 2012 08:20 AM

Hi Joel, Yes I will escalate and create a Symantec case for that. The customer complain about the fact previous policies was working before, and are faulting now, after the MP1. So we need to investigate and report this customer. I will proceed to(my)might (CESTime). Best regards.

Oct 16, 2012 04:20 PM

Hi Pascal,

This is defintely some invovled questions. If you can open a Support request my team can put the details together for you. If I knew it all off the top I'd provide the answers, but this will take some investigation.

Regards,

Joel

Oct 16, 2012 02:09 PM

Thanks again Joel. I must ask for:

When you use default: NOT "run from the server", the download is done using the "application credential" or the one "Agent Connectivity Credential " specified in Global NS agent settings "authentication TAB".

That's clear.

The command will launch using the "local system" = Symantec Agent credential (if installed as default): Is it correct ?

We notice on XP the option "Allow user to interact" was working any time, but with Windows 7, only if logged on user is with local admin elevated rigths.

BUT when using above "Run From the server" + "Agent Credential": which credential is used to open the UNC and launch the "command line" ?

"application credential" for a net use "no drive letter",
runas "local system" the <server UNC path>\<commande line>

And which "context path" is setup ? I guess it is:

C:\program files\altiris\altiris agent\software\SoftwareManagement\

Is it?

So if you get error message in agent logs:

Unable to map network drive for account '<application credential>' to <server UNC path>
...
Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed.

And the script run popup:

Can not find script file "C:\program files\altiris\altiris agent\software\SoftwareManagement\MyScript.vbs".

That is because the same "server" already got a "net use" from another user...  As message told. Hum: Does Win7 not able to allow the computer, multiple user session to map same UNC each using own credential ? Should we not able to let "application credential" map a drive, and "current logged user" mapping also this drive ??? I should see my colleague MS expert for that.

I see also in the "command line" type allow to specify if installer is a :

  • MSI: but I must specify the command line: 'MSIEXEC /I MyPackage.msi /qb!'
  • BAT or CMD: I do not need to specify cmd /c "batch..bat", I can only 'batch.bat" if installation file type set to "Windows Batch Installation File" ?
  • VBS: Do I need to specify 'wscript "MyScript.vbs"', or can I only 'MyScript.vbs' if set type to "Windows Script Installation File ?

If my batch or VBS is running a MSI, should I keep "MSI software Installation File" type ? But in this case, I will have to specify "wscript or cmd /c" in command line...

I do not play enough often all those, I will try taking time for :)

There are often multiple ways for doing the same thing, and from time to time, some combinations results strange :)

Sep 07, 2011 03:15 PM

I can't tell you how delighted I am to see such a well-written best practice series posted. Kudos! Off to implement...

Related Entries and Links

No Related Resource entered.