• Welcome to Support Forum: Get Support for Patch My PC Products and Services.
 
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - cmacnichol

#1
Quote from: Andrew Jimenez on November 02, 2020, 11:54:23 AM
So does Option 1 not work on newer clients? We may be able to incorporate Option 2 as a post-script, we'll discuss internally and see if we can add this directly to the product.

Thank you so much for providing this info!

I have not tested the registry option, mostly as they specifically called out that it did not work with later versions.  Here is the full script I am now using, take whatever you need from it.

#requires -version 3
<#
    .SYNOPSIS
    WorkspacesClient_Custom_PostInstall

    .DESCRIPTION
    PatchMyPC Customization Script for Amazon Workspaces Client

    .NOTES
    Version:        1.0
    Author:         Christopher Macnichol
    Creation Date: 11/02/2020
    Purpose/Change: Initial script development
    11/02/2020 - 1.0 - Chris Macnichol - Initial Script Development
   
#>

try
{
  $configFileX64 = "${env:ProgramFiles(x86)}\Amazon Web Services, Inc\Amazon WorkSpaces\workspaces.dll.config"
  $configFileX86 = "$env:ProgramW6432\Amazon Web Services, Inc\Amazon WorkSpaces\workspaces.dll.config"

  If (Test-Path -Path $configFileX64 -ErrorAction SilentlyContinue){ $configFile = $configFileX64}
  elseif (Test-Path -Path $configFileX86 -ErrorAction SilentlyContinue){ $configFile = $configFileX86}
  else {$configFile = $null}


  If ($configFile) {
    $xml = [xml]([System.IO.File]::ReadAllText($configFile))
    $xml.PreserveWhitespace = $true

    # Remove Update URL from Attribute
    $key = $xml.SelectNodes('//configuration/appSettings/*') | Where-Object {$_.key -eq 'UpdateUrl'}
    $key.Value = ''

    #Settings object will instruct how the xml elements are written to the file
    $settings = New-Object -TypeName System.Xml.XmlWriterSettings
    $settings.Indent = $true
    #NewLineChars will affect all newlines
    $settings.NewLineChars ="`r`n"
    #Set an optional encoding, UTF-8 is the most used (without BOM)
    $settings.Encoding = New-Object -TypeName System.Text.UTF8Encoding -ArgumentList ( $false )

    $file = [System.Xml.XmlWriter]::Create($configFile, $settings)
    try{
      $xml.Save( $file )
    } finally{
      $file.Dispose()
    }
  }
}
catch
{
  ('Error was {0}' -f $_)
  $line = $_.InvocationInfo.ScriptLineNumber
  ('Error was in Line {0}' -f $line)
  Exit 1602
}

Exit 0
#2
Quote from: Andrew Jimenez on May 08, 2020, 10:54:12 AM
We'll definitely keep an eye out, and if you are able to determine how to block updates, please let us know and we will add it to the product. Thanks!

Hi Andrew,

We were finally able to get an answer out of Amazon on how to disable the updates for this product.  It is still being tested on our side, but so far it does appear to work.  I have included the information that Amazon provided as well as the (barebones) powershell script we are using to update the file.  Note, I have not updated the script yet to handle 32bit machines.

QuoteOption 1: Disable client updates via Windows registry (For clients up to 2.5.x)

1. Login to Windows WorkSpace Client workstation.
2. Open registry editor
3. Navigate to registry path: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Amazon\
4. Create a new key "Amazon WorkSpace Client", if doesn't exist already.
5. Create a new string type "clientUpgradeDisabled" and add Value:1

Path: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Amazon\Amazon WorkSpaces Client\clientUpgradeDisabled

Type: REG_SZ

Value: 1

This registry entry can be applied to other windows workstations using Group-policy or other third party windows application management tools.


Option 2: Make changes in the WorkSpace.dll.config file in the WorkSpace Client installation directory (for client v3.x.x)


1. Navigate to WorkSpace Client Installation directory: C:\Program Files (x86)\Amazon Web Services, Inc\Amazon WorkSpaces
2. Open WorkSpace.dll.config file
3. Rename the "UpdateUrl" tag or remove the update url and save the file (You will need Admin privileges).

Please note that this workaround is only at the individual user level and a re-installion of WorkSpace client will update the .config file back to default.

$configFile = "C:\Program Files (x86)\Amazon Web Services, Inc\Amazon WorkSpaces\workspaces.dll.config"

$xml = [xml]([System.IO.File]::ReadAllText($configFile))
$xml.PreserveWhitespace = $true

# Remove Update URL from Attribute
$key = $xml.SelectNodes("//configuration/appSettings/*") | Where-Object {$_.key -eq 'UpdateUrl'}
$key.Value = ""

#Settings object will instruct how the xml elements are written to the file
$settings = New-Object System.Xml.XmlWriterSettings
$settings.Indent = $true
#NewLineChars will affect all newlines
$settings.NewLineChars ="`r`n"
#Set an optional encoding, UTF-8 is the most used (without BOM)
$settings.Encoding = New-Object System.Text.UTF8Encoding( $false )

$file = [System.Xml.XmlWriter]::Create($configFile, $settings)
try{
    $xml.Save( $file )
} finally{
    $file.Dispose()
}


Let us know if this could be incorporated into your package.

Thanks,
Chris
#3
That is exactly what I needed.  Wouldn't hurt to add a note on the Transforms option to the Cmd Line help fields when editing the command line.  That Idea you linked is the only place I can find where the option is even referenced.

Thanks for the help.
#4
I just noticed today when I went to enable Adobe Acrobat Reader that the Updates tab has the option to add an MST File.  However, the COnfigMgr Apps tab does not, it is grayed out, for the same product.

Is there a reason for this?  Or if you are using the EXE Install, which actually appears to be the case, can you add the MSI Install option?  Shouldn't be too hard to extract the MSI from the installer for the base install version as well.

We have customization that we apply through the MST during install that we currently cannot add.
#5
Yeah, I have been messing with this on and off for months.  It appears that the only way to disable updates is to do it for every user in the directory the workspace is attached too.  Further, the update controls of the Installer Amazon is using do not get honored when set in the registry.  I am unable to disable updates for the entire directory as I have some machines that are not managed.

If you ever figure out a way to block updates, let me\us know as it is sorely needed.
#6
I think this was brought up before, but it has been a while.  Has the Amazon Workspaces application been reviewed recently to see if it is possible to disable the Auto update notification?  I am still packaging this one normally as a user application due to this.  Installing as System just causes issues as users keep trying to update it when they cannot.
#7
Quote from: Justin Chalfant on August 23, 2019, 09:13:14 AM
Can you email us the application logs https://patchmypc.com/faq-scup-catalog#log-files using our technical support page https://patchmypc.com/technical-support

Hi Justin,

I wanted to chime in on this as I am currently in the process of testing your Service during the trial period.  We came across the issue with Flash not being detected properly and did a little digging into the issue.

From what I can tell, this all comes down to the detection script.  For example, in my case, it is detecting as already installed for Flash PPAPI when NPAPI is already installed.

For this particular problem, if the correct version (32.0.0.238) of NPAPI is already installed when PPAPI attempts to install, the detection script will return an Installed status.  This is due to how to are checking against the application name on line 55-59.

    $InstalledSoftwares = Get-InstalledSoftwares | Where-Object {
        $version = GetVersionFromName $_.DisplayName
        ($_.DisplayName -like $appName -and -not($_.DisplayName -like "*$except*") -and
(($_.DisplayVersion -ne $null -and $_.DisplayVersion.Trim() -ge $appVersion) -or $version -ge $appVersion)) -or
($_.PSChildname -eq $msiCode)


If you check the variables for both NPAPI and PPAPI, the only difference is the MSI Code.

NPAPI
$AppToSearch = 'Adobe Flash Player*'  # A pattern used to search for displayName in the uninstall registry key.
$AppToAvoid = ''                # A pattern used to reject similar applications.
$AppMSICodeToSearch = '{73534489-BFE7-4E2D-9769-FDBA5C886DC2}' # A MSI code used to search for in the uninstall registry key.
$AppVersionToSearch = '32.0.0.238'     # Version >= check to determine if application is installed and greater than or equal to this version.


PPAPI
$AppToSearch = 'Adobe Flash Player*'  # A pattern used to search for displayName in the uninstall registry key.
$AppToAvoid = ''                # A pattern used to reject similar applications.
$AppMSICodeToSearch = '{1ED4AB04-200D-412B-A06A-0B8E7217CCFD}' # A MSI code used to search for in the uninstall registry key.
$AppVersionToSearch = '32.0.0.238'     # Version >= check to determine if application is installed and greater than or equal to this version.


Looking at the detection logic, it will return a True if either the Name OR the MSI match.  Because both names are identical except for the last half, which is covered by the Universal Like operator, it will always come up with a match if the name is the same.

Simplest fix for this is to just add *NPAPI* and *PPAPI* to the respective exception parameter in each detection script.  Might be better in the long run to alter it and confirm that the MSI matches as well though.

Make sense?


Regards,
Chris