Messages

I don't see a way to change the per patch source location in WPP. 

I used Internet Explorer to test.   The WPP dev DCourtel still at PatchMyPC?  Maybe some insight to what is occurring. 

I did manage to use a workaround to get patches imported.   

1. Download FileZilla_3.58.0_win32-setup.exe & FileZilla_3.58.0_win64-setup.exe to \\localhost\PatchMyPCRepository
2. Grabbed & extracted latest "PatchMyPC.cab"
3. Modified 94c08616-b308-4fc5-9db5-e95f30d6b980.sdp OrginUri=\\localhost\PatchMyPCRepository\FileZilla_3.58.0_win32-setup.exe
4. Modified 47dd53d9-2725-4d9a-83b4-f9df8078e5a1.sdp OrginUri=\\localhost\PatchMyPCRepository\FileZilla_3.58.0_win64-setup.exe
5. Modified PatchMyPC.xml OrginUri=\\localhost\PatchMyPCRepository\FileZilla_3.58.0_win32-setup.exe
5. Modified PatchMyPC.xml OrginUri=\\localhost\PatchMyPCRepository\FileZilla_3.58.0_win64-setup.exe
6. Created new CAB
7. Imported updates from new CAB

Thanks,

I've not used that software before, but is there a way to reference a local file?

Yes - Patches like AnyConnect and TeamViewer that obtain patch files from \\localhost\PatchMyPCRepository import fine in WPP. 

Anyone running into issues with latest "FileZilla Client 3.58.0" getting a 403 error on download when try to import via "WSUS Package Publisher"
I dug up what I think are URLs download from which work fine in a browser.

https://download.filezilla-project.org/client/FileZilla_3.58.0_win32-setup.exe
https://download.filezilla-project.org/client/FileZilla_3.58.0_win64-setup.exe

Thanks in advance

Hey MTREICHLER, this is weird. IÔÇÖve just tested and, even though WPP doesnÔÇÖt show the "Not" group, there are indeed imported from the catalog. Actually, if you export the update and open the XML file you will see the "Not" group in the "IsInstalled" element.

You are correct.  If I export the update I see the proper "Not" conditions, both installed and installable rules.

Sounds like everything should work fine and I don't have to create custom rule to avoid LTSR patching.  I'll test it out with LTSR install and mark thread.  Guessing maybe something with WPP rule editor maybe off.  I couldn't create that rule via GUI so maybe doesn't read rule properly.

Great,  Here is how I was customizing the rules in past to avoid LTSR patching, which is only accounting for command line situation.

Code Select Expand


<lar:And>
<bar:RegValueExists Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\CitrixOnlinePluginPackWeb" Value="DisplayVersion" RegType32="true"/>
<bar:RegSz Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\CitrixOnlinePluginPackWeb" Value="DisplayName" Comparison="Contains" Data="Workspace" RegType32="true"/>
<bar:RegSzToVersion Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\CitrixOnlinePluginPackWeb" Value="DisplayVersion" Comparison="LessThan" Data="21.6.0.47" RegType32="true"/>
<bar:WindowsVersion Comparison="GreaterThan" MajorVersion="6" MinorVersion="1" ProductType="1"/>
<lar:Not>
<bar:RegExpandSz Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Citrix\ICA Client\AutoUpdate\Commandline Policy" Value="LTSROnly" Comparison="EqualTo" Data="true" RegType32="true"/>
</lar:Not>
</lar:And>


"Citrix Workspace 21.7.0.44"

I also created rule with proper NOT conditions and imported.   NOT conditions were stripped out.

We are importing our patches into WSUS with WSUS Package Publisher, not going though SCCM.   Maybe the installable ruleset on native WSUS SCUP API is more limited than SCCM.  I know the NOT condition does work on registry conditions as that is how I was avoiding patching my LTSR by keying off LTSROnly NOT true.

Your logic is correct on LTSR probably just related to missing NOT condition.

Thanks for the reply.

When I export the 21.7.0.44 installable rule there isn't NOT condition to proceed the OR statements. 

Code Select Expand


<lar:And>
<bar:RegValueExists Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\CitrixOnlinePluginPackWeb" Value="DisplayVersion" RegType32="true"/>
<bar:RegSz Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\CitrixOnlinePluginPackWeb" Value="DisplayName" Comparison="Contains" Data="Workspace" RegType32="true"/>
<bar:RegSzToVersion Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\CitrixOnlinePluginPackWeb" Value="DisplayVersion" Comparison="LessThan" Data="21.7.0.44" RegType32="true"/>
<bar:WindowsVersion Comparison="GreaterThan" MajorVersion="6" MinorVersion="1" ProductType="1"/>
<lar:Or>
<lar:And>
<bar:RegValueExists Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Citrix\ICA Client\AutoUpdate\Commandline Policy" Value="LTSROnly" RegType32="true"/>
<bar:RegSz Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Citrix\ICA Client\AutoUpdate\Commandline Policy" Value="LTSROnly" Comparison="EqualTo" Data="true" RegType32="true"/>
</lar:And>
<lar:And>
<bar:RegValueExists Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Policies\Citrix\ICA Client\AutoUpdate" Value="LTSROnly" RegType32="true"/>
<bar:RegSz Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Policies\Citrix\ICA Client\AutoUpdate" Value="LTSROnly" Comparison="EqualTo" Data="true" RegType32="true"/>
</lar:And>
</lar:Or>
</lar:And>


Adobe is pretty much a dumpster fire for their releases and support.  I've signed up for their notification on releases and 1/4 of the time PatchMyPC notifies us before Adobe notifies.  21.005.20060 for example, not a security update, but no notification from Adobe to date.

With Citrix Workspace 21.7.0.44 release on 7/29 seems some changes how Workspace is targeted changed.

With Workspace version prior to 21.7.0.44 (non LTSR)  4 conditions for patch to be installable.

--------------------
1. RegValueExists Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\CitrixOnlinePluginPackWeb" Value="DisplayVersion" RegType32="true"

2. RegSz Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\CitrixOnlinePluginPackWeb" Value="DisplayName" Comparison="Contains" Data="Workspace" RegType32="true

3. RegSzToVersion Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\CitrixOnlinePluginPackWeb" Value="DisplayVersion" Comparison="LessThan" Data="21.6.0.47" RegType32="true"

4.  WindowsVersion Comparison="GreaterThan" MajorVersion="6" MinorVersion="1" ProductType="1"
--------------------

With 21.7.044 there seems to be some additional conditions that also target off "HKLM\SOFTWARE\Citrix\ICA Client\AutoUpdate\Commandline Policy"  & "HKLM\SOFTWARE\Policies\Citrix\ICA Client\AutoUpdate" LTSROnly=true conditions.


Overall some thoughts on regular Workspace vs LTSR Workspace.

If LTSROnly=true that indicates either a GPO is set or command line was used to limit auto upgrades to LTSR versions.  If PatchMyPC upgrades LTSR Workspaces to regular Workspace installs that is ignoring the configured setting installer or admins are configuring. 

Our environment for example majority of our Workspace installs are LTSR as we need the cerification and stability of LTSR over cutting edge feature of Workspace.  In the past I've modified the Workspace installable rules to avoid patching our LTSR installs. 

Wanted to start a discussion and suggest that targeting of Workspace & Workspace LTSR with different approach.  What may make sense is if any LTSROnly=false or values do not exist then Workspace patch permitted.  If LTSROnly=true then only LTSR installs are permitted.  Customers like us would need to have both Workspace & Workspace LTSR patches approved, but it keeps the Workspace on Workspace and LTSR on LTSR. 

Thanks,

PatchMyPC with WSUS

DCU 4.2.0 has installable rule where DCU has to be 3.0 or higher to install.  Do we know why the 3.0 or greater limitation exists?  I could adjust the rule to upgrade legacy versions, but rather not if known issues with legacy upgrades.

Somewhat related there are 2 version of DCU.  Classic & UWP DCU 4.2.0 only installs on Classic.  Any plans for UWP DCU update?

Thanks,
 

Whoops.... Forgot to reply to this.

Here are 2 older versions.

https://drive.google.com/open?id=1moWdLlQCcnh995KBx0S4ZTCK2ENv_JZZ


Current version is 4.2.0229.   Product name also changed from TigerText Desktop Messenger to TigerConnect Desktop Messenger

Thanks,

Yes

Pushing people towards their paid versions.   

Probably  for the best.  Even though not always installing the junkware the presence of that in their installers causes few AV vendors to flag it.  The used to support installer option  /LOADINF= where you could specify components too from answerfile, but that could be disabled now or next release as well..

Program isn't as needed with Win10 including an adequate basic PDF Printer now.

From release notes:

PDFCreator 3.0 requires the .Net Framework 4.5.1 and therefore Windows Vista or above. Windows XP is no longer supported. If you need Windows XP support, please use PDFCreator 2.x instead.

http://docs.pdfforge.org/pdfcreator/latest/en/pdfcreator/introduction/whats-new/

PDFCreator will install if requirements are not met, but will error when running application.  Can PatchMyPC detection account for .NET Framework 4.5.1 requirement?   Application failures can be high if upgrading from older PDFCreator prior to 3.0 with .NET 4.5.1 or newer.

New version released 5/31/2018

http://docs.pdfforge.org/pdfcreator/latest/en/pdfcreator/introduction/whats-new/