This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
rpachevurova
Community Manager
- Revenera Community
- :
- About rpachevurova
Jun 15, 2021
07:31 AM
Do you have an accompanying script that will display the current size limit? I think that would be helpful before blindly changing this setting.
... View more
Sep 18, 2020
01:24 PM
Question
Where does the SVM (console and SC plugin) store its log files?
Answer
The log file is named as csi_pluginlog.txt and SC plugin log file is named as secunia_sc2012_plugin.log located under Documents folder.
Additional Information
The package log is located in C:/Windows/secuniapackage.log file.
SCCM Plugin Log is toggled by going to SCCM Manager Console->Software Library->Flexera Software->Right-Click->Toggle Logging.
Registry Key to Toggle Logging is under HKCU\Software\Secunia\SCCM Plugin\
String Value: LogFile (Set to path\filename where log file is to be stored.)
DWORD 32bit Value: Logging (Set to 1 to enable logging, Delete to Disable.)
... View more
Labels:
Apr 08, 2020
01:58 AM
1 Kudo
We've now added an Adobe best practice guide.
As you might expect, to meet the constant evolution of our industry, our best practice guides are often updated, so I'd recommend that those who have used them subscribe and/or revisit them to see if there's new content.
... View more
Mar 06, 2019
11:50 AM
Software Vulnerability Research tracks more than 60,000 unique products. Flexera continuously expands this number by adding more software programs and versions for vulnerability analysis based on requests. If a software product is not in our database to track vulnerabilities, you can send software suggestions to Flexera.
Instructions
First, Search for your program in the Software Vulnerability Management interface at Research > Products Database. If you can't find the desired application or version there, follow the steps below to suggest it.
Go to Research > Products Database > Suggest Software.
Select the Suggest Software button.
In the Single Software tab, populate the following information:
Software name: Full product name
Software version: Enter the version you want added (for example, 1.x, 2.x)
Software URL: Official product vendor homepage URL
Email: Email that will be contacted regarding the software suggestion. Multiple email addresses can be added in the Email field. Use a semi-colon or comma to separate them.
Comment: Enter any additional notes if your case is unique
Select Save.
After submitting your suggestion
We normally respond to software suggestions within 48 hours of receipt. If you send a list of requests, expect an increased timeframe as the number of suggestions increases.
Learn more
If you want to suggest multiple applications simultaneously, see Submit multiple software suggestions at once.
... View more
Feb 25, 2019
10:52 AM
1 Kudo
Summary
SVM Patching Plugin is installed with an elevated admin account but it fails to load when a web page is refreshed. It displays a '"An error occurred while loading the SVM Plugin" related to signature checksum.
Symptoms
SVM Patching Plugin is installed with an elevated admin account but it fails to load when a web page is refreshed. Internet Explorer displays '"An error occurred while loading the SVM Plugin" related to signature checksum failure.
Cause
This issue occurs because the root certificate of Thawte and Verisign are not installed or are not updated correctly on the local system. There could be some security settings on your system or in your browser settings that prevent the install/update of root certificates from these vendors.
There could be something blocking the CRL check for these certs.
Steps To Reproduce
Under Patching/Configuration/WSUS/System Center (Disconnected) you get an error message saying "Digital signature could not be verified"
The option 'Configure Upstream Server' is disabled for configuration.
When you hover your mouse over the message "An error occurred while loading the SVM Plugin" additional information on the specific error shows: Unable to verify checksum signature: 12029 Unable to verify checksum signature: 12038 Unable to verify checksum signature: 12045 Unable to verify checksum signature: 12057
Resolution
Replace with the correct ones, or install from scratch, the following certificates in the Trusted Root Certification Authority store (MMC/...Certificates/Computer Account) Here are a few ways to do this: 1. You can download the certificates yourself from the vendors' websites or you can download the certs attached to this article.
Certificate Names (there might be more added, check CRL-related articles in the community too):
Thawte Extended Validation SSL CA
Thawte Primary Root CA
VeriSign Class 3 Public Primary Certification Authority - G5
VeriSign
http://www.symantec.com/content/en/us/enterprise/verisign/roots/roots.zip
Generation 5 (G5) PCA should be imported to the trusted root certification authority
Thawte
https://www.thawte.com/roots/
Root 1 should be imported to the trusted root certification authority
2. You can export them from a computer certificates store where you have SVM loading the plugin. 3. You can request them from Flexera Customer Support Center.
Workaround
In the event you have a Proxy server which may be blocking the certificate validation requests of your clients, you may white-list the following entries:
http://crl.verisign.com
http://crl.thawte.com
http://ws.symantec.com
https://*.secunia.com
See more...
This should be safe to do and it may release all Clients at once to perform CRL validation. This helps with CRL validation not only to load SVM's patching plugin, but it's also required for Agents connections and Daemon as well. This workaround is a prerequisite and it shall be considered in all cases.
... View more
Labels:
Feb 21, 2019
09:11 PM
Summary
This article teaches you to create and configure Custom SVM Agent Uninstall package, that can be deployed to domain clients using WSUS/SCCM that will uninstall SVM Local Agent installed on them.
Discussion
After you log into your Software Vulnerability Manager account, go to Patching > Agent Deployment. Click on "Create Software Vulnerability Manager Agent Package" to proceed.
Click on the "Import XML" button and import the XML template you have downloaded from this thread. The file you are uploading contains the file that is required to perform the uninstallation on the clients.
Enable the checkbox "Use Flexera Custom Naming" if you will be deploying updates through System Center Configuration Manager.
Continue forward with "Next" until you reach the last configuration page. Use the "WSUS" radio button under "Publish Options" even when you are working with SCCM. Click "Publish" to deliver the package at the original WSUS Server (SUP) package repository (default).
Depending on whether you are working with WSUS or SCCM, do the following:
WSUS:
Navigate to Patching > Available. Find your published package and "Decline" if auto-approved. This can happen because of WSUS rules. Right-click on the package again and "Approve" it for the desired recipients. After the package is approved, clients will connect WSUS and always get it as long as they are Approved.
Once the package is downloaded on the client, it will run once and it will wipe the Agent. Then it will be cleaned up by WSUS automatically at the next reboot. It will be set by WUA as installed (not required).
SCCM
Enter the SCCM Console interface, then open Software Library/Software Updates/All Software Updates.
Use the "Run Synchronization" feature to find available Software Updates. Wait until it's complete.
Search 'Flexera' in the list to filter out your third-party packages.
Once it appears, take the usual SCCM repackaging steps as you would take for MS update deployments.
Related KB Articles
Uninstall SVM Agents with GPO Logon Script
Additional Information
The Agent Uninstall Package includes a primary setting named 'Mark Package as AlwaysInstallable'. Such package deployments will not be regulated by your deployment server as a regular update - that is, based on package's 'Applicability Rules'. Such packages only require an approved target computer as they are marked to bypass restrictions and deploy to 100% targets.
... View more
Jan 28, 2019
07:10 PM
1 Kudo
With the use of the Software Vulnerability Manager over time, the number of packages created in Windows Server Update Services (WSUS) can begin to take up valuable disc space on the server that is facilitating the WSUS role. Simply declining and deleting packages in Software Vulnerability Manager does not remove the packages from the \UpdateServicePackages folder where Software Vulnerability Manager packages reside.
This article describes the steps necessary to review and remove old third-party packages created by Software Vulnerability Manager from your local WSUS server to reclaim disc space.
NOTE: This article is intended to help with removing packages related to Software Vulnerability Manager. If you have any questions specifically about WSUS, contact Microsoft.
Remove obsolete patch packages
Remove patches via the Software Vulnerability Manager interface
In Software Vulnerability Manager, go to Patching > Available.
Review the packages and determine which are no longer relevant. For example, every package older than the latest patched version is now vulnerable and should be considered for removal.
Select Decline and then delete the old or irrelevant package entries.
Run the Cleanup Wizard for SCUP
If you are using System Center Updates Publisher (SCUP), you may need to run the Cleanup Wizard for SCUP.
Open the WSUS administration console from Server Manager and navigate to Options > Server Cleanup Wizard.
By default, the wizard will remove unneeded content and computers that have not contacted the server for 30 days or more. Select all options you’d like to remove, then click Next.
The wizard will begin the cleanup process and then show a summary of what will be removed. Select Finish to complete the process.
Delete packages with WSUSutil
Run WSUSutil with the parameter listunreferencedpackagefolders and delete the packages that it lists.
Open the Command Prompt as an Administrator.
Execute the following commands to export the list of declined and deleted packages in WSUS to a text file (for example, deletefolders.txt ).
cd "C:\Program Files\Update Services\Tools"
WsusUtil.exe listunreferencedpackagefolders > c:\temp\deletefolders.txt
Open the below file to review the list of declined and deleted packages in WSUS:
C:\temp\deletefolders.txt
Delete the beginning lines of the file that say the following:
The following folders are not referenced by any of the updates in your WSUS server.
In front of each remaining line, add the following line:
rmdir /q /s
For example: rmdir /q /s C:\Sources\WSUS\UpdateServicesPackages\598ecbc7-2208-401b-9f0c-8eb57488aee
Save the file with the name deletefolders.cmd .
Double-click on the deletefolders.cmd file to run it and delete unreferenced packages from the filesystem.
Delete all third-party packages using PowerShell
As an alternative to the above instructions, the following PowerShell commands can be used to delete all the third-party packages from your WSUS server. These commands should be executed on your WSUS server with Administrator rights.
[Reflection.Assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer();
$wsus.GetUpdates() |
Where { $_.UpdateSource -ne "MicrosoftUpdate" } |
ForEach-Object {
$wsus.DeleteUpdate($_.Id.UpdateId.ToString())
Write-Host $_.Title removed
}
Additional steps for certain use cases
In some scenarios, you may need to follow additional steps to remove the remaining obsolete packages. If your WSUS has had an in-place reinstall with new certificates, old packages signed with the old certificates may remain in the content directory.
In this situation, you’ll need to force the deletion of all patches by going to C:\Program Files\Update Services\UpdateServicesPackages\ and deleting them.
If you need help determining which patches to delete, follow the instructions below.
Enter one of the GUID folders.
Find the CAB file that has the same name as the GUID.
Right-click on the file and select Properties.
Select the Digital Signatures tab.
Double-click on the certificate in the Signature List.
Select View Certificate in the new window.
Select the Details tab in the new window and find the Serial Key field. The serial key is unique. It will show you if the certificate that code-signed this package is the one you are using in your domain actively. To check this:
In WSUS, open MMC > File > Add or Remove Snap-In > Certificates > Local Computer.
Openand check the certificate's serial key there. This is the certificate you currently use.
Delete patches signed with a certificate that is not in the WSUS Certificate store. Don’t delete any patches signed with your current certificate.
... View more
Labels:
Jan 09, 2019
06:31 PM
1 Kudo
Summary
This article is a deeper-dive guide to troubleshooting problems with publishing Flexera SPS packages to Windows Server Update Services that can also be installed in configuration with System Center Configuration Manager as a "Software Update Point" [SUP]. It provides you with the required logic to follow problems with publishing to their root cause and eliminate it efficiently.
Symptoms
The user receives an error message from WSUS along the lines of 'failed to publish' with a 32-bit unsigned integer as the error code. Example: [06/09 13:42:55.495] Failed to create package: : -2147352567 , In 'Publisher.invoke' Code: -2146233079 Failed to sign package; error was: 2147942421 --> System.InvalidOperationException: Failed to sign package; error was: 2147942421 ...
Cause
WSUS errors can have a number of causes depending on the different scenarios created by the infrastructure in question. In order to better understand the problem, you should work through the following list of factors to investigate. The basics:
Is the WSUS service on the WSUS server running?
Is the WSUS server connection information correct?
This can be found by using a remote Snap-In connection to your WSUS server interface
Is the code-signing certificate correctly placed at the Trusted Publishers, Trusted Root Certification Authorities, and WSUS stores?
This can be found using the Certificates snap-in [Run > certlm.msc]
Or via Powershell [dir cert:\LocalMachine\ -recurse]
NOTE: You can also try using Powershell ISE and some where {} clause filtering:
dir cert:\LocalMachine\ -Recurse | where {$_.HasPrivateKey -eq $True} | select Subjectdir cert:\LocalMachine\ -Recurse | where {$_.HasPrivateKey -eq $True} | select Subject
Continue further if the keys and placement of your code-signing certificate was by the books.
Does the certificate in the WSUS store contain the private key?
This can be verified by double-clicking the certificate inside the WSUS store.
Is the WSUS code signing certificate valid? Error 2148204810 usually indicates that the certificate has expired. Check and renew if needed.
[07/16 12: 46: 04.202] Failed to create package:: -2147352567, In & # 39; Publisher.invoke & # 39;
Code: -2146233079
Error signing the package: 2148204810
- & gt; System.InvalidOperationException: Error signing package: 2148204810
More troubleshooting options: If the above checks don't seem to indicate where the problem lies then you should try some more advanced troubleshooting techniques. The items below describe some pitfalls that can cause problems with WSUS integration.
Is there enough space on WSUS?
Check the storage space available on the volume where the UpdateServicesPackages directory is located
Privileges (UpdateServicesPackages directory)?
Does the user account context being used with CSI via Internet Explorer have write access to this directory?
Has the update store been moved recently? (UpdateServicesPackages directory/WSUS Local Content Cache location)
This can cause problems if the move wasn't done according to Microsoft's guidelines
Is there an alias record for the WSUS server that's different than the computer name?
Here you'll want to check to see where your DNS record is pointing to.
Check the UpdateServicesPackage location (WSUS Local Content Cache location) defined in WSUS database
If your WSUS server uses the default internal database then install MS SQL management studio. Open SQL Management Studio and then use one of the following two possibilities depending on the version you're running for the instance name: \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query (2003-2008) or \\.\pipe\MICROSOFT##WID\tsql\query (2012) . This style of instance name is required because connecting to the Internal Database requires named pipes.
If you're running your WSUS DB on another instance you'll want to open SQL Management Studio and connect using the instance name and authentication settings that fit to your environment.
You'll then run the following query:
USE [SUSDB] SELECT [LocalContentCacheLocation] FROM [dbo].[tbConfigurationB]
Which should give a result similar to the following:
Check the registry value for the UpdateServicesPackages Directory to ensure it's correct.
This can be found under HKLM\Software\Microsoft\Update Services\Server\Setup
If you require more information to troubleshoot further in-depth than this guide provides details for, you'll need to look deeper into the error code for your specific issue. If you take a look at the example error message from earlier in the article: "[06/09 13:42:55.495] Failed to create package: : -2147352567" you can see that you get an interesting number back from WSUS. You can make use of the following javascript function to translate it into something a bit more useful:
function DumpHR(hr) { if (hr < 0 ) hr += 0x100000000; if (hr & 0x80000000) console.log("Error code"); else console.log("Success code"); var facility = (hr & 0x7FFF0000) >> 16; console.log("Facility " + facility); var scode = hr & 0x0000FFFF; console.log("SCode " + scode); } DumpHR(-2147352567);
In the example above, the Facility Code is 2 and the SCode is 9. What this tells us is that the error comes from the COM Dispatch Facility and the error code of 9 tells us that the problem is a 'bad address block'. The Facility code reference can be found here and the SCode reference here.
What the example results imply is that there was a problem writing to disk on the WSUS server during the publishing process. In most cases, one of the causes described above is the culprit, however, if you happen to have one of the odd cases that are outside these bounds this information might be useful, especially if you open a case with Microsoft.
Resolution
The solutions to these problems will vary depending on which path brought you to a conclusion. However, these scenarios can be broken down to provide some fairly easy fixes:
Is the WSUS service on the WSUS server running?
If not, try to start it again. If that doesn't work a reboot and/or tracing the event log to find a cause will be necessary.
Is the WSUS server connection information correct?
If not you can adjust the information you're using in the CSI console to match what you found in the WSUS snap-in.
Is the CSI console/Internet Explorer running with administrator privileges?
Make sure to run the CSI console or Internet Explorer by explicitly right-clicking and choosing "Run as administrator".
The User running the Internet Explorer is part of WSUS administrator group.
Make sure to add the user under which Internet Explorer is running is added to the WSUS administrator group which is the local group on the WSUS server.
Is the code signing certificate in the Trusted Publishers, Trusted Root Certification Authorities, and WSUS stores?
If the certificate is not in the appropriate stores you can either create a new one or, if the export is available with the private key, it can be imported into those stores on the WSUS server.
Does the certificate in the WSUS store contain the private key?
If not then create a new certificate with the appropriate key, or if the export is available to import it into the appropriate stores.
There isn't enough space available for WSUS
In the case where this is the problem you simply need to increase the size of the volume that contains the UpdateServicesPackages directory (WSUS Local Content Cache location)
NTFS Permissions for the UpdateServicesPackages (WSUS Local Content Cache location) directory are incorrect:
Here you'd need to adjust the NTFS permissions for the user(s) accounts making use of the CSI console so that they have write access to this location. They should also be in the WSUS Administrators group on the WSUS server.
The update store moved since publishing worked (UpdateServicesPackages directory)
Ensure that one uses the guidelines specified by Microsoft when moving the store. Use those steps to verify that all of these tasks have been accomplished.
There is an alias record for the WSUS server that's different than the NETBIOS computer name
You should verify your DNS configuration and make use of the appropriate DNS name when making use of the CSI console.
The WSUS Local Content Cache location for WSUS is incorrect in the WSUS internal Database
This can be corrected with the following query example. Bear in mind this is an example and must be verified on your own infrastructure.
USE [SUSDB] Update dbo.tbConfigurationB set LocalContentCacheLocation = 'C:\Updates\WsusContent'
In the above example, the location I've placed in quotes is one possibility (and the default value). This may need to be different in your environment.
The Registry value for the UpdateServicesPackages Directory (WSUS Local Content Cache) is incorrect.
Using Regedit to edit the key at HKLM\Software\Microsoft\Update Services\Server\Setup should fix the issue.
... View more
Labels:
Nov 16, 2018
04:45 PM
Summary
A full guide on how to create a GPO to distribute WSUS certificate and Windows update settings.
Synopsis
This short guide describes how to create a Group Policy Object (GPO) for CSI-WSUS by using the Group Policy Management console. Once the GPO is created and linked to the correct Organizational Unit (OUs), the computers in that OU will download the WSUS publisher's self-signed certificate and Windows settings so that third-party updates can be downloaded correctly.
Discussion
Login to your Software Vulnerability Manager account. Navigate to Patching > Configuration > WSUS / System Center > Configure Upstream Server. Connect to the WSUS server and then click Next. On Step 2, click "Export Signing Certificate" which will be saved to your documents folder.
Example of exporting the certificate
Launch the Group Policy Management Console on your Domain Controller.
Navigate to Group Policy Management > Forest > Domains > Organizational Unit
Right-click the Organizational Unit > Create a GPO in this domain, and Link it here > Name the GPO e.g. ''CSI-WSUS' or as per your policy.
Right-click the GPO and click Edit
Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies
Import the previously exported "wsuskey.cer" Certificate in the ''Trusted Root Certification Authorities'' and ''Trusted Publishers'' Folders
Navigate to Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Update.
Double-click the Windows Update Folder.
Double-click "Specify Intranet Microsoft update service location" and change the Settings to Enabled (Please specify your WSUS server address on ''Set the intranet update service for detecting updates'' and apply (Note: This setting should only be changed if you are using WSUS. Don't configure this setting if you are using SCCM). If you have another GPO which points your machines to the correct WSUS server, then re-specifying WSUS is not required.
Double-click "Allow signed updates from an intranet Microsoft update service location" and change the Settings to "Enabled".
Click Apply > Ok and close the GPO editor.
Additional Information
Computers will download the Policy after the next policy refresh interval or reboot. You can force the policy to apply by running the command:
gpupdate /force
Sometimes it may take several hours for the policy to actually propagate. You can verify that the GPO is being applied to the machine by checking to see if the certs have been added to the appropriate cert stores on any given machine.
If the GPO has not been applied yet, or it is not being applied to the machine in question, then you will receive an error (0x800b0109) when deploying third-party updates.
... View more
Labels:
Nov 15, 2018
07:36 PM
Summary
On systems running Windows Server 2012, 2012R2, 2016 - WSUS no longer issues self-signed certificates as this is disabled by default by Microsoft. You can use a workaround to enable the feature in the machine registry and thus you can go around the problem.
Symptoms
You are integrating the Software Vulnerability Manager for the first time, or you are just configuring a new machine with the interface. After connecting to the deployment server, you attempt to create a certificate in the second step of the Software Vulnerability Manager integration wizard for WSUS/System Center Configuration Manager.
Your account has been added as a member of the WSUS-local security group WSUS Administrators. Your account is at least a Local Administrator on the local system as well. You have started Internet Explorer with the 'Run as Administrator' option (needed for UAC bypass) Even so, certificate creation fails with an error and it does not allow you to move along with your setup.
Cause
Microsoft has disabled the WSUS feature that allows you to create a WSUS self-signed certificate on Server 2012 R2.The Software Vulnerability Manager can issue a code-signing certificate through this feature by requesting Windows to create one through the WSUS Certificate Server service.
This is the default in SVM. It is only provided as a minimal alternative for cases when it's possible to get a private CA-issued certificate quickly and it is needed to patch. Flexera advises you to use private certificate for improved security.
Resolution
It is possible to restore the legacy behavior on Windows Server 2012, 2012R2 and 2016 by setting a registry key. Open Regedit on the WSUS server and go to:
HKLM\Software\Microsoft\Update Services\Server\Setup\
Create DWORD with value:
EnableSelfSignedCertificates = 1
Your server should no longer deny you the request for issuing a WSUS Self-signed certificate while the setting remains enabled (1). Retry to create the certificate through Software Vulnerability Manager.
References
http://blogs.technet.com/b/wsus/archive/2013/08/15/wsus-no-longer-issues-self-signed-certificates.aspx
... View more
Nov 15, 2018
07:31 PM
Summary
When the WSUS Server and WSUS console are not on the same Patch Level and not on the same WSUS server version, an error message for version mismatch is displayed and publishing of packages fails. This is caused by a known incompatibility of different versions of the WSUS Server console and it is purely a Microsoft problem. As SVM leverages the standard WSUS APIs, it is affected indirectly by this issue.
Symptoms
The error appears when you attempt to publish a package from a remote to the WSUS system.
SPS returns known error that the version of the console and remote server do not match.
The problem is global and it exists for all SVM packages - nothing can be published through SPS.
Error message for version mismatch identified with general error Code: -2146233079
Cause
WSUS Server Console is a different major version than the remotely installed RSAT tools for WSUS.
Publishing will fail due to a known Microsoft WSUS console version incompatibility.
Sometimes the console versions may be on the same version but different Patch levels.
That could also cause the incompatibility problem to occur.
Steps To Reproduce
Users in the following situations are likely to experience the problem:
WSUS is installed on Windows 2008 and you try publishing from Windows 8/8.1/10
WSUS is installed on Windows 2012 R2 and you attempt publishing from Windows 7/10
WSUS is installed on Windows 2016/2019 and you are trying to publish via Windows 7/8/8.1
Resolution
Verify that versions match first
You must first ensure that your versions match. If you have decided to host the Software Vulnerability Manager console on a separate system than the actual WSUS, then you must plan the setup before implementing it. If your setup has already encountered this error, you may have to correct that.
To do that, perform the following steps of planning and implementation:
Find out what is the exact version of your installed WSUS Server Role (and its OS version).
Determine what Windows OS flavor/version is appropriate and compatible for remote publishing
Install and/or configure this Windows OS version with the required installations:
Install the Software Vulnerability Manager Plugin for Internet Explorer
Download and install RSAT tools for WSUS for exactly this Windows OS version/flavor
Connect the Software Vulnerability Manager to WSUS (using the Patching menu)
Attempt publishing and confirm packages are publishing successfully error-free.
To determine what Windows OS version/flavor you would need for your corresponding WSUS, use this:
WSUS on Windows 2008 = publishing will work only from remote Windows 7/2008 system
WSUS on Windows Server 2012 = publishing will work only from remote Windows 8/2012
WSUS on Windows Server 2012 R2 = publishing will work only from Windows 8.1/2012 R2
WSUS on Windows 2016/2019 = publishing will work only from Windows 10/2016/2019
Match Patch Levels if the problem still occurs
When you have matched the WSUS versions, required OS flavors, and have installed the correct RSAT tools for WSUS, you may still have to match the patch levels of both systems. If one of the systems has some particular KB patches while the other does not have the very same, publishing can still fail.
You can see what has been installed from appwiz.cpl > Installed Updates menu as shown next:
At the bottom of the list, you will find the WSUS updates installed. The range of KB numbers that will fix the incompatibility (or the patch difference) boils down to KB2720211, KB2734608, and KB2828185.
These updates will be required particularly in Windows 2008 WSUS setups and WS 2012 R2 installations. In Windows 10/2016/2019, these should be handled by default and included in the source code already.
Workaround
Another workaround is to simply install the SVM interface on the very WSUS system and work with the console and WSUS through a single API interface thus eliminating the remote vector that essentially eliminates the version mismatch problem immediately. Many customers prefer this approach instead.
... View more
Labels:
Nov 15, 2018
05:41 PM
Summary
When publishing a package from the Software Vulnerability Manager, the following error appears:
"Failed to publish package - Code: -2147024809 - Unable to find database configuration value"
Symptoms
The related issue is a Microsoft WSUS API issue that can appear under the following circumstances : 1. Software Vulnerability Manager is installed on a remote machine (not the WSUS, SCCM, SQL server) 2. the WSUS server and its repository are installed on different systems (Not SCCM, SQL) 3. SCCM/SQL has been installed on different systems (do not include the WSUS server or repository) When publishing a package from the interface the following error appears : Failed to publish package Code: -2147024809 Unable to find database configuration value.
Cause
The WSUS API call looks for the registry on the local server where the Software Vulnerability Manager interface *(Plugin for Internet Explorer) is installed, instead of looking in the registry of the actual WSUS server to find the SQL server name. This call fails and hence publishing operation fails too.
Resolution
Copy the relevant registry strings from the WSUS server and copy them into the remote system where the console has been installed : 1. On the WSUS server, Open Regedit and navigate to the following key :
HKLM\Software\Microsoft\Update Services\Server\Setup
2. Check if the following SQL keys are present (#5) 3. Right-click the key and choose to export, provide a name and click OK 4. Right-click the file that has been exported (xxxxx.reg) and choose edit. This opens in Notepad. 5. Locate the relevant SQL keys within the file and remove all other, so the output is similar as below: 6. Save the file and move the file to the remote system running the Software Vulnerability Manager.
7. Import the key by double-clicking the file.
8. Open the registry on the remote system, check HKLM\Software\Microsoft\Update Services\Setup, and verify if the key now is present on this system.
9. Navigate to the SVM Interface (or your SCCM plugin) and republish the package successfully.
... View more
Labels:
Nov 15, 2018
05:38 PM
Summary
This article describes the general steps that can be taken to troubleshoot a package that was published by the Software Vulnerability Manager and its Flexera Package System where the package was provided as silently installable out-of-the-box through the default installation configuration enabled by Flexera.
SPS packages as they are known are advanced installers which [1] contain the vendor installer that the vendor intended and delivered to the public [2] while also containing improvements in the package installation handling procedures that create a bridge between the WUA functionality and all the supported for silent installation third-party software vendors together with their disadvantages.
Customers using SVM or SVR solutions are welcome to contact support if they want to achieve specific scenarios with their Flexera products and that extends to patching where Support can be helpful.
Synopsis
A Secunia package (sps.exe) contains a minimum of two files.
One file is the script that executes the installer that comes at index 1 (2) as the second file in the package execution flow. The script sets package execution logging to occur at C:\Windows\SecuniaPackage.log. This file contains all relevant installation information regarding the SPS package and it is heavily used for detecting problems and error codes that need solving.
You should always try your luck looking at C:\Windows\WindowsUpdate.log too. Windows Update Agent handles the execution of packages for both WSUS and SCCM, and it represents the parent executory process of the SPS.exe installer threads that start underneath WUA's PID. That's where data comes first.
Discussion
Troubleshooting package deployment:
Open C:\Windows\SecuniaPackage.log on the system where the package was deployed.
At this point:
If the package has started installing, it would have written anything, error or success. If the package did not write anything, then the package never started running.
Next steps: If Error
If you have an error for that same package, try finding more about it in the current KB article. If the error is not listed here, try finding another KB article in the community as there are few others. No success should leave you with a good choice to send it to Support and we'll help with our best.
Next steps: If no Error
When the package is executed it will have the type of reference as shown next: [08/18 10:59:38.257 00000fa8] Running package Deployment package for Secunia CSI Agent, version 7.1.0.3, created Tue Aug 18 2015 10:58:56 GMT+0200 (Romance Daylight Time)[08/18 10:59:38.267 00000fa8] GUID : 7f72ff70-1530-420a-8280-983588115663
When the Windows Update Agent runs the downloaded patch successfully, you will see return code 0.
[08/18 11:00:00.873 000003b0] Finished running package Deployment package for Secunia CSI Agent, version 7.1.0.3, created Tue Aug 18 2015 10:58:56 GMT+0200 (Romance Daylight Time) [08/18 11:00:00.885 000003b0] Returning 0
If you don't see a reference to the package, this could be caused by the deployment script not being run. You should look in WindowsUpdate.log to get an insight on what did WUA report back as a result too.
Often this log file will contain the root cause of the failure. Does it say anything about the package you are expecting? Are you able to find the package when you use Ctrl+F and the name of the package? If the answer is no, this means that your package is not applicable to that system.
Briefly explained, each package contains applicability stamped on it just like a post letter has stamps. It can and will be delivered only when the recipient of the patch, that is every client in the domain, indeed matches all required rules. Briefly, these are patch applicability, version applicability, and approval.
Finally, some particular reasons for a package failure can be:
- Internal Installer Error
- WUA executes through LocalSystem and this account doesn't have access there, where the system requires authentication with password requirements.
For instance, the LocalSystem account cannot anything that has a requirement for password exchange and authentication packages trying to install in C:\Users will fail via WUA installation because that requires a UAC permission bypass and LocalSystem can't handle the password part.
Error Codes and Useful References:
These are Windows system error codes that can be compared against: https://msdn.microsoft.com/en-us/library/windows/desktop/ms681382(v=vs.85).aspx Common System error codes are :
ERROR_SUCCESS
0 (0x0) Description: The operation completed successfully.
ERROR_SHARING_VIOLATION
32 (0x20)
Description: The process cannot access the file because it is being used by another process. (This could be the case while updating Adobe Flash or Oracle Java, where Java/flash is at that moment actively running in the browser or as a process and the uninstaller can not access the locked file.
ERROR_INSTALL_FAILURE
1603 (0x643)
Description: Fatal error during installation. Find more about this error in the hyperlinked KB article.
ERROR_INSTALL_SUSPEND
1604 (0x644)
Description: Installation suspended, incomplete.
ERROR_UNKNOWN_PRODUCT
1605 (0x645)
Description: This action is only valid for products that are currently installed.
ERROR_PRODUCT_VERSION
1638 (0x666)
Description: Find more about this error in the hyperlinked KB Article.
Another version of this product is already installed. The installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs in the Control Panel. This could be the case while updating Adobe Reader, where Adobe Reader installer fetches some old registry setting that point to a previous Adobe Reader update location/path/MSI file.
Detecting and removing this path from the registry resolves the issue. To do so, download the Adobe reader update installer from adobe and run it via the GUI, the installation should stop requesting an MSI file at a specific location/path. If this event occurs, you will have reversed the problem and allocated it.
Packages in which failure is associated with an MSI installer may be failing to obtain the source MSI file to proceed with software removal before update or an upgrade. Sometimes the MSI installer will be missing on the system. Then, in the middle of a BITS-orchestrated operation, the installation is blocked and no message can be returned to the user. The installer waits for a little and it times out, errors out.
... View more
Nov 15, 2018
05:35 PM
Summary
While attempting publishing of a Software Vulnerability Manager security patch to your deployment server, The package publishing process consumes an excessive amount of time, fails, and returns an error Code: -2146232060.
Symptoms
Cause
This is a timeout issue that usually happens when the WSUS is terribly busy downloading Windows Updates and/or when lots of clients are querying the WSUS for available updates. You might have hit a very wrong moment to publish a package e.g. while WSUS is running scheduled full synchronization.
Resolution
The best option is to wait until resources become available on WSUS and try again. Otherwise, if a restart of WSUS service or the server itself is possible, then restart the Windows Update Service on the WSUS server. Sometimes it also helps to clean up the WSUS using the WSUS Cleanup Wizard to remove old, expired and superseded updates.
... View more
Labels:
Nov 15, 2018
05:35 PM
Summary The Internet Explorer plugin of the CSI Server edition does not load with error: Invalid document location Symptoms After installing the browser plugin of the CSI Server edition the plugin does not load but presents the following error: Cause The browser plugin is secured with a so called "Sitelock" which will prevent it from being loaded from any other website than the one stated in COOKIE_DOMAIN and CA_DOMAIN in the config.ini of the CSI Server installation.
This locking mechanism is case sensitive. Workaround The only way to workaround this issue is to make sure that the COOKIE_DOMAIN and CA_DOMAIN are written in lower case as the Internet Explorer will automatically change an uppercase written address to lowercase.
... View more
Activity Feed
- Kudoed AdminStudio Evolves Beyond "Standard" for bkelly. Sep 13, 2021 02:06 PM
- Got a Kudo for Thanks. Mar 22, 2019 03:06 PM
Contact Me
Online Status |
Offline
|
Date Last Visited |
Mar 22, 2024
02:12 AM
|