Managed software delivery policy timeout

[deemacgee]

Hi all,

I've been building a set of configurations for a new environment in our organisation, and have run into an issue when adding a specific piece of software to an MSD policy.

The problem manifests when saving a policy with Microsoft Office 2016: after hitting Save changes, the Console window will process and then eventually timeout.



The log indicates the same error as mentioned in this thread (link): Item State has exceeded the 65,536 KB limit specified in the core settings
Of course the Tech notes article in that thread seems not to exist, so I can't read up on it.

Given the core settings are now more easily exposed, I tracked down the specific item and dialled it up from 64MB to 96MB, and then again to 128MB, but that hasn't fixed anything. The only difference now is that the Item State[...] log entry no longer appears. The other error messages, though, do (GUIDs redacted):

As alluded to in the linked thread, Office 2016 does have many associated patches (dozens, if not hundreds), which show up under the Service Pack and Update Tasks node. The other entities in this specific MSD do not have anywhere near as many patches - 10-15 at most.

I'm not sure how best to proceed with this. The workaround is a simple install task instead of a proper Software Delivery, which I can use for now, but won't do as a long-term solution.

Has anyone seen this before? Can it be fixed? Platform is ITMS 8.5 RU3.

TIA

------------------------------
--None--
------------------------------

[Arthur Prosso]

Hello! 

How does the "Microsoft Office 2016"  software release look like if it is opened in the "Software Component Edit"  page ->Associations tab?
How many associated SPs and updates are there in your case ? (dozens, if not hundreds  was mentioned) - what is the exact number ?
Is there any supersedence or dependencies data for the "Microsoft Office 2016"  as well ?
Same question for precise number of  OTHER included in the policy components' (if any)  dependencies/supersedence/updates as well.

Is the problem just with policy SAVING or it is also a problem viewing the policy after unsuccessful Save()  (i.e. corrupted policy) ?

How to workaround?
I would recommend to get rid of SP/Updates/dependencies associations that you know for sure are not needed or outdated for installation of "Microsoft Office 2016". Even if they are not selected as "needed for installation" in the components tree UI they will contribute to the stateXML data (to remember the installation settings).
This may be accomplished via the "Microsoft Office 2016" association editing.
If the policy is not even viewable now it might turn out that it must be created from the beginning.

If that does not help and if you the issue is "hot" for your environment then If you have a proper Broadcom support channel available, I would recommend to escalate the issue to DEV via support.
Software management solution currently does not restrict inclusion of unlimited amount of components with their unlimited amount of associations and is "unaware" of the policy serialization problems.

Regards,
Arthur





------------------------------
Software Engineer 5
Broadcom Inc.
------------------------------

[deemacgee]

Hi Artur,

Thanks for your reply. I've navigated to the Software Update associations for Office 2016 and the list presents 786 (!) items in the Software resources that update this software resource table.

These are the same updates which appear listed in red in the Managed Software Delivery policy after adding Office 2016, under the Service Pack and Update Tasks node.

Are these update associations not automatically purged?

------------------------------
--None--
------------------------------

[Arthur Prosso]

Hi David!

If the updates appear in red in Managed Delivery Policy UI it means they are not deliverable, i.e. there are neither package not command line associated with them.
Managed delivery Policies are designed to work with software components imported into the software catalogue.
It seems like Office 2016 release that you would like to distribute originates from Patch Solution  metadata and not from something imported manually into the software catalog (looks like you have not associated 786 updates manually ???). If that is the case then please do not de-associate these updates manually - these associations will come back during the next full patch data import anyway.

I would recommend to start "building" the "Office 2016"  component from scratch by importing installer EXE into the software catalogue - then you will have an isolated component without non-deliverable associated updates. Then there are already existing Managed delivery policies with Office 2016 you may replace the previous "Office 2016" with the new one. 

Best regards,
Artur


------------------------------
Software Engineer 5
Broadcom Inc.
------------------------------

[deemacgee]

Hi Artur,

I have definitely not imported ~800 patches manually! :) These are coming from Patch Management, which is fine, it's just that there are so many that it breaks MSD creation. I manually de-associated ~200 yesterday afternoon, which allowed the MSD to be created successfully. Patch data import is configured for an incremental run nightly so I'm guessing those associations won't be restored any time soon.

The source for our Office 2016 install MSD was added exactly as you've suggested - we did this some time ago; it's only now that we're mass migrating to Office 2016 that we've started using it in policy and, therefore, running into issues.

I suppose my follow-up questions are: is this behaviour normal, and, how do we best handle/rectify it?

------------------------------
--None--
------------------------------

[Arthur Prosso]

Hi David!
Thanks for raising the problem with broken MSD serialization use-case - we will fix it in the next releases.

The problem is that Patch data is NOT intended to be used in the Software Management  (Managed delivery and quick delivery)  use-cases.  I would agree it sounds strange since ITMS is supposed to be a monolithic product, but historically we have not succeeded to "merge" the patch and software use-cases  from the  DB data management perspective. One of the reasons is that Patch Data is something "well defined" and has a single source of origin, but Software Components is something admins would create manually and creation of logically duplicate components is unavoidable.
Also Patch data is something that MUST win in the end from the data definition perspective  (associations/etc). Otherwise security compliance reporting is under question if admins manage the Broadcom-provided patch data manually 

The use-cases difference: 

• Patch management data - automated data definition and delivery 
• Software Management  data - Manual / ad hoc data definition and delivery

Thus, currently path data is ISOLATED from Software Catalog (Menu Manage-> Software Catalog-> All software releases).  Patch data's software releases are not shown there !

How you succeeded to define package and commandlines to Office 2016? Which UI did you use?  Taking into account the above statement it looks that most probably was done not  via Software Catalog.

> "Is this behaviour normal, and, how do we best handle/rectify it?"
Do not use Patch Data for Managed delivery! If Managed delivery  you created works , then good for now.
How to distinguish Patch data from non-patch data ?  For Software delivery use-cases (packages/commandline definition) please work with components appearing in the Software Catalog view only.

To answer definitely whether "behaviour is normal"   we first need to answer the question above.
Looks like it is not normal if one is allowed to create a Managed Delivery with 800 not deliverable updates :)  

Best regards,
Artur
 


------------------------------
Software Engineer 5
Broadcom Inc.
------------------------------

[JOE.PS1]

Dee, we are also users of ITMS 8.5 and deploy Office365 via managed software delivery.  I have not run into the problem you describe and when I look at the associations tab, I see no associations.  Are you sure you created your own O365 package and did not choose one downloaded by patch for your SWD policy?  One other possible difference is we do not deploy Office updates via Patch management as we were never able to get that working properly.  We've configured our O365 packages to self-update.  

[deemacgee]

Hi Joe, Artur,

Thanks for comments, appreciate the input. Reasonably certain we've followed proper process on this - I will double-check when given the chance.
Probably worth noting that this is not the first time I've seen unusual behaviour - I have used various Altiris-branded platforms on-and-off for nearly 20 years now and each of them has manifested some oddity or another. Quite often there's some sort of homebrew workaround to address the concern, but this... this one has been a bit of a killer.

Other products we deploy via MSD also list possible patches - Adobe Reader X (yes, we're still on X, long story), for example, will list all the 10.x point updates available to the software, and this has been the case since this instance of the platform was deployed. There aren't as many as Office 2016 (or  2013, or 2010), so policy creation was not overly impeded.

Further to my last post: once the updates were de-associated, we had much less trouble creating the and deploying the policy - our upgrade project is now chugging along reasonably well for both internal and CEM-connected clients. Everything beyond policy creation has been working exactly as expected so we're OK for now.

I'll provide more info once I have it.

Cheers
DMcG

------------------------------
--None--
------------------------------

[JOE.PS1]

DMcG,  can you share the high-level steps you use to create a software package for delivery?  There must be some difference from how you do it an how we do it since we don't get any automatic service pack / patch dependencies. 

Joe

[deemacgee]

Hi Joe,

Apologies for the delay getting back in here, quite busy of late.

The short answer to your question is as follows - in this example, Office 2016:

- Select the default Office 2016 Standard software product from Manage --> Software
- Open the Delivery flip panel
- Click Import and add the install source (as per any package) as a new Software Release in the Software Library, click Next
- Retain the existing association, click OK
- Build installation command lines, etc

We use the same process for all our software. If an application isn't in the list of pre-populated major vendor apps (Microsoft, Adobe, Symantec, etc), we create an entry from the unmanaged software list and then go through the above steps - but only those predefined Software Product entries will list associated patches when building MSD policies.

Cheers
DMcG

------------------------------
Tech Monkey/IT Primate
------------------------------

[Arthur Prosso]

Hello David!

Specifically for Office 2016 Standard at the step "Click Import and add the install source (as per any package) as a new Software Release in the Software Library, click Next".

Do you add EXE or MSI as installation file?
If EXE - do you specify/correct the software component name which is displayed on such dialog ?

What are currently the resource keys of the Office 2016 Standard  Software Release (not the product) ?
Please run in SQL 
select * from ResourceKey where ResourceGuid = <office 2016 guid>

It seems like for some reason your imported Office 2016 Software Release is merged with the one from Patch Data - at the moment the root cause is unclear to me - could not reproduce that.

Are there any entries in the Evt_Resource_Merge table related to Office 2016 standard?

Regards, 
Artur.







------------------------------
Software Engineer 5
Broadcom Inc.
------------------------------

[JOE.PS1]

DMcG,

I notice your normal method of creating software package is different from ours.  We create each package separately and do not start with an existing software from the library.  I think the key step that's causing you issues is your answer to "keep existing associations" which seems likely to be linking your new software package with all the patches which are causing you issues.  So either change your answer on that step or create an entirely new software package without starting on an existing item in the software library.  You can do this using the "Add Software" button in the top left of the Manage / Software screen.  if you're ITMS is not current, I believe this button used to be under the Software Library menu.  

One other question, what version of Office are you deploying?  Office365 is much different from Office2016 even though they both have internal version markers of 16.x, especially in the way that these products are licensed, activated, and patched (MSI uses traditional MSP patches where-as Click-to-run O365 is virtual and streams its own updates directly).  Make sure you are not confusing the two and associating an Office365 package with the old Office2016 software and patches.

[Chris Farrell]

I agree. "Software Products" are what are managed; this is really what a catalog entry is. You choose how it is defined - application metering, inventory, software licensing, etc. You can also import packages, "Software Resources." You can also associate files. A "Software Product" is a collection of associations you define which can be edited. So starting with importing a package to create a "Software Resource" is what I recommend. You can the create a managed software product from the software Resource, define the inventory associations, and move them from other products such as the pre-defined ones if desired.

https://knowledge.broadcom.com/external/article/175693/software-management-best-practices-and-t.html