Messages

okey, thank you for the information, 1.49.1 has been released by MS anyway so I think you can close it.

[Is the version which has been published on July 31rd usable? or shall we delete the package and the update and use this latest recent one?]

Hi,

We have noticed that 'Azure Data Studio 1.49.0' has been published twice, first 31st of July, second 7th of August
We found the info in your feed about the 'source hash changes' but it was Microsoft who has changed it without any notification or it hasn't been fully downoloaded by PMP first time?
We do not see anything anywhere on MS site about the change in the source files.

Main question here is: Is the version which has been published on July 31rd usable? or shall we delete the package and the update and use this latest recent one?
We are scanning daily and we have already started deploying this version from 31st of July.

BR
Grzegorz Mazur

Hey,
we have had it installed globally everywhere but not from PMP base install package.
After pushing out your base install package problem is gone, so you can close this case.

Thx

Hey,

cool, thx for the update

small update from me;) seems like I was looking at wrong reg hive (x64 not x32) when I was checking how you are doing detection, but anyway we have seen 'not applicable' status for "Update for Microsoft Edge" package.
This morning I have disabled 'required' assignment for base app so I will let you know how the latest "update" package is behaving right now. 

BR,
Grzegorz

[Update for]

Hello,

could I ask you to double check detection for "Update for Microsoft Edge", it looks like after recent change to  "Microsoft Edge for Business"(https://learn.microsoft.com/en-us/deployedge/microsoft-edge-for-business) Microsoft did a change to registry entries.
Those which are being checked by you in your detection method are gone so the update is NOT applicable.

I have tried to run the latest "base" application version (which we have published as available) and it has updated the Edge just fine to the latest version.

SCREENSHOT

BTW.

Right click option 'Manage Installation logging' in this case is greyed out, but you could pass here logging argument for MSI (I believe I could find some other packages as well with similar issue)

Just a thought for future consideration

HI Hugo,

it worked, thx! I suggest mentioning it somewhere in your KB cause looking into your 'scriptrunner.log' it is misleading when trying to analyze the issue on your own.

That's how the syntax looks like in 'scriptrunner.log'

Code Select Expand

Running application install: MindManager_64bit_22.2.366_redist.exe with arguments: /clone_wait /S /v/qn /v"/qn LICENSEKEY=XXXX-XXX-XXXX-XXXX-XXXX USERNAME=USER /l*v c:\logs\logname.log"
So the params are doubled and when you do not know how the 'scriptrunner wrapper' behaves it is sometimes difficult to narrow dwon the issue.

anyway thank you for quick answer.

BR,
Grzegorz

Hey PMP Team,

We are having an issue to properly configure additional parameters for 'Mindmanger 22' application.

The exe installer contains MSI inside, The hardcoded arguments by you are "/clone_wait /S /v/qn" so after adding additional public properties for MSI installation (using right click option in the publisher) command looks like this:

Code Select Expand

MindManager_64bit_22.2.366_redist.exe /clone_wait /S /v/qn LICENSEKEY=XXXX-XXX-XXXX-XXXX-XXXX USERNAME=USER /l*v c:\logs\failed_installation_from_PMP.log
This won't do anything, exe installer won't even unpack the MSI as it has an issue with the syntax. In the scriptrunner log there is an error 1203.

I have tried to install it silently on my own using same installer and your arguments and imho command syntax needs to be adjusted, something like below is doing the job ok:

Code Select Expand

MindManager_64bit_22.2.366_redist.exe /clone_wait /S /v"/qn LICENSEKEY=XXXX-XXX-XXXX-XXXX-XXXX USERNAME=USER /l*v c:\logs\succesfull_install_from_pmp.log"
/v - is telling the exe that next quoted string are the properties/args for MSI

Btw.
I know that there is an MSI available without the the exe file which could be used but is not present in the publisher maybe it is worth considering it


Regards,
Grzegorz Mazur

Hi Ben,

cool,thx for quick response, keep us updated please, thx in advance.

BR,
Grzegorz Mazur

Hi,

could you tell me if 'VMware Remote Console' latest version will be supported ?

I have noticed that you are hosting this update yourself that's why I am asking.

latest release:

https://customerconnect.vmware.com/en/downloads/details?downloadGroup=VMRC1204&productId=1325

no issues here, installing just fine

  thanks for the udpate

[Value="LibexecPath" Comparison="EqualTo" Data="C:\Program Files\Git\mingw64\libexec\git-core" />]

Hi,

we noticed that 'Git' software is not properly detected if custom installation directory is defined.
You can adjust it by adding additional argument in the command line "DIR='custompath'".

Detection method in the publisher has hardcoded path which is being checked.

Comparison="GreaterThanOrEqualTo" Data="2.38.1.0" />
    <bar:RegSz Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\GitForWindows" Value="LibexecPath" Comparison="EqualTo" Data="C:\Program Files\Git\mingw64\libexec\git-core" />

What do you say about adjusting detection method to check InstallPath value from the registry instead?

ahh damn, got it, thank you for super-fast reply

Hello,

what do you guys say about adjusting the title of 'Vmware Tools' package in the publisher so it could be shown on the compliance reports more precisely?

Right now the shorter build number is being shown (see att. pic), we would prefer to see on the reports full build number as it is presented on vmware site. (https://docs.vmware.com/en/VMware-Tools/12.1/rn/VMware-Tools-1210-Release-Notes.html)

What do you think?