Video Screencast Help

Software Management Solution with 32/64-bit Packages

Created: 02 May 2013 | 6 comments

My Newly Discovered Software list includes 32-bit and 64-bit resources for a particular application we installed on most of our desktops.  To turn these into deliverables, am I simply editing each software resource to add the package/rules/associations then should that "Managed Software Delivery" option show up in the Actions right-click menu?

Operating Systems:

Comments 6 CommentsJump to latest comment

Andrew_Shishkov's picture

Yes, it should. If it doesn't by some reason, then you can create Managed Software Delivery policy for this resource also using SMC -> Actions -> Software -> Managed Software Delivery menu item or using SMC -> Manage -> Policies -> Managed Software Deliveries -> <right click menu> ->  New -> Managed Software Delivery option.

Thanks,

Andrew.

Clint's picture

I was able to edit the discovered 32/64-bit resources just fine although had an issue with package creation for the 64-bit one.  Starting with the 32-bit resource, I added the package to my library after which I actually saw the files in the share.  However, when I did the same for the 64-bit resource, the hashed folder was there but it was empty!

Then I proceeded to delete the 64-bit package and try again where the files showed up after a couple attempts.  Don't know why this occurred but went ahead and created a managed s/w delivery policy from this s/w resource.  Now an unusually small percentage of the 32-bit targets appear to be installing the app just fine although 64-bit ones are universally throwing "The system cannot find the file specified. (-2147024894)" error 1 in the client's alog.

I'm thinking of disabling/deleting the policies and going the right-click "Import Software" route instead of modifying the discovered resources as I did.  Actually, in all of the Software Management Solution demos/videos that I've watched, don't think I've ever seen anyone modify discovered resources and turn them into deliverables so perhaps I should start at Import Software the next time around and make it a policy to "Never" update an existing resource (i.e. always create a new one)?  Curious if anyone else has seen this odd behavior before?

Clint

Andrew_Shishkov's picture

Actually the only difference of adding packages to already discovered software resource comparing to importing new software resource is that detection check not added automatially if you add MSI based installation package (if you check "Automatically generate command lines" checkbox). Have you added 32bit and 64bit packages to the same discovered software resource or to 2 separate software resources?

And there are some advantages in adding package for discovered software resource. In this case you will avoid situation when you will have duplicated software resources in software catalog - one imported and another discovered (which you will have to resolve by merging these resources manually). This may happen in case combination of software Name, Company and Version retrived from software package during import differs from the same combination received from client as part of software inventory (which is quite frequent problem).

Thanks,

Andrew.

andykn101's picture

A better approach would be to import your Package and then find the discovered resource to import it it to. Then the console will generate a command line for you and detection rule if it's an msi.

Authorised Symantec Consultant (ASC) with Endpoint Management Limited, an Authorised Symantec Delivery Provider based in the UK.

Connect Etiquette: Please "Mark as Solution" posts that fix your problem.

Clint's picture

I tried using this approach and agree with what you're saying!

Went to Import Software first then opted to update the existing software resource.  Unlike my previous method of editing the newly discovered s/w resource first, this one generated multiple command lines (install, install silent and uninstall) and even pulled in the appropriate 32 or 64-bit msi code for each package.

Had no glitches with my packages getting created in my Library this time around so crossing my fingers that this deployment will go smoothly.

Clint

andykn101's picture

I always edit the msi command lines automatically created to delete all the install ones except the silent auto one and add:

REBOOT=ReallySuppress /l*v "%temp%\AppName.log"

I check the Package Server tab of the Package to make sure it's assigned to the Package Servers I require. If you have separate 32 and 64 bit Software Resources you want to add an applicability rule for each to make sure they'll only run on 32 and 64 bit OSs respectively.

Authorised Symantec Consultant (ASC) with Endpoint Management Limited, an Authorised Symantec Delivery Provider based in the UK.

Connect Etiquette: Please "Mark as Solution" posts that fix your problem.