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

Summary Flexera performs vulnerability tracking of the software used by customers of Flexera. When there is a missing title in the database that blocks you to add that product to your Watch Lists for further vulnerability tracking, you should send your suggestion to Flexera and we will add the missing product.  This article describes the correct steps to perform suggestions for tracking of missing product titles in SVR. If you are using the SVM 2019 solution by Flexera (formerly CSI), this article is not intended for you. Synopsis The Flexera SVR product covers more than 60,000 unique products. Flexera continuously expands this number by adding more software programs and versions for vulnerability analysis, based on customer requests that can easily be performed through the SVR interface.  Discussion Search for your program in the SVM interface under Research -> Products Database first. If you can't find the desired application and/or version there, then you can suggest it to Flexera. Use the exact steps listed next to perform your suggestions:  1. Navigate to Research -> Products Database -> Suggest Software. Find the Suggest Software menu in the Research section of SVR 2. Click on the green "Suggest Software" button (don't download the software suggestion tool) Choosing the correct option here is important to avoid missteps 3. In the new window that opens up, populate the required information under the "Single Software" tab: Full Product Name. Enter the exact version you are asking Flexera to add in the database (e.g 1.x, 2.x...) Official Product Home Page URL (official page hosted by the vendor) Enter any additional comments in the "Comments" section if your case is special. 4. Click Save NOTE: do not go the path to "Upload File" - this is not needed for adding a new product in SVR.  Additional Information Q&A: How much time does it take to add a newly recommended product? Flexera is committed to responding to individual software suggestions within 48 hours of receipt. If sending a list of requests, we will still strive to respond quickly, but expect increased delays as the number of suggestions increases. How can I suggest a larger number of programs at the same time, without adding each suggestion separately? You can compile a CSV file that includes the required information needed by Flexera to add products for tracking to the Software Vulnerability Database of Secunia Research.  The following format should be used when making bulk suggestions:  You should include your own email with your request (or inside the Excel sheet), to allow communication pertaining to the suggestion. In order for a product to be listed in scan results, the file information of a file from the suggested product must also be included. Generally, this file would be the main executable file that launches the program, which includes correct information about the product. After compiling a list of the products you wish to be added, you can send it to binaries@flexerasoftware.com directly. ... View more

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

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

Summary The article describes the steps necessary to clean up and remove old third-party packages created by the Software Vulnerability Manager 2018 (SVM) from your local Windows Server Update Services (WSUS) server. While this reference is helpful is designed to help you with your SVM installation, you should redirect any questions about WSUS to Microsoft forums.  Synopsis With the use of the SVM over time, the number of packages created in WSUS begins to stack up and take up valuable disc space on the server that is facilitating the WSUS role. Simply declining and deleting package in SVM does not remove the packages from the \UpdateServicePackages folder where SVM packages reside. This article describes how to reclaim disk space used by these packages. Discussion Method 1  Clean up any old or irrelevant packages from the SVM web Interface under the Patching > Available menu Go through the created packages and determine which packages are no longer relevant. For example, every package older than the latest "Patched Version" is now vulnerable and should be considered for removal. Decline and then Delete the old or irrelevant package entries you see listed the Available menu. If you are using System Center Updates Publisher (SCUP), it may be necessary to run the cleanup wizard for SCUP: To clean up your WSUS database from old package metadata information: Open the WSUS console from Server Manager and navigate to the Options area. Select the Server Cleanup Wizard. Run the Server Cleanup Wizard. Run WsusUtil with the parameter listunreferencedpackagefolders and delete packages that it lists. Open a CMD shell window as an Administrator Execute: cd "C:\Program Files\Update Services\Tools" WsusUtil.exe listunreferencedpackagefolders > c:\temp\deletefolders.txt​ Open C:\temp\deletefolders.txt and see the declined and deleted from SVM packages.   Remove the beginning lines of the file that read: The following folders are not referenced by any of the updates in your WSUS server.​ In front of each remaining line add: 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 to delete unreferenced packages from the filesystem. Method 2  The following PowerShell commands can be used delete all the third-party packages from your WSUS server:     [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 }     These commands should be executed on your WSUS server with administrator rights. Workaround The packages you've so far deleted were patches that you removed from your SVM interface, patches not being used by WSUS and patches that are tagged with Declined status. Sometimes this will not be enough though. In the event, you installed new WSUS on top of your old one and you configured new certificates for your new installation, you may end up 'leaving behind' updates that are still active. Since Update Packages are signed with certificates, patches published previously having been signed with older (currently unused certificate): These may not be visible in SVM These same patches will not be seen in the WSUS Server Console either. These packages are physically present at \UpdateServicesPackages and they may remain Approved. They may as well be distributed by WSUS to Clients (or synced with Downstream servers) as long as the Clients are suitable for these updates and request it. These patches were signed with a certificate that is no longer used. Therefore, you can't reuse the patches. You can't Decline them either. You can't even see them in SVM. They became unusable (and soon there will be new versions anyway. You must force the deletion of all patches by physically going to C:\Program Files\Update Services\UpdateServicesPackages\ and deleting those. If you have a doubt which patches (sitting in folders with long numerical ID names) are to be deleted, then: Enter one of the GUID folders Find the.CAB file that has the same name as the GUID Right-click and select properties Open 'Digital Signatures' TAB Double-click on the certificate in the middle window Select 'View Certificate' in the new window Select 'Details' in the new (third) window and find the Serial Key field. The 'serial key' is unique and it will show you if the certificate that code-signed this package is the one you are using in your domain actively. You can open MMC > File > Add or Remove Snap-In > Certificates > Local Computer on the WSUS. Enter the 'WSUS' folder and check the certificate's serial key there. This is the certificate you currently use. Do not delete any patches signed with your current certificate - delete patches signed with a certificate that is not in the WSUS Certificate store.   ... View more

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 &#39;Publisher.invoke&#39; Code: -2146233079 Failed to sign package; error was: 2147942421 --&gt; 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

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

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

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

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

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

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

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