Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

The 'Version' attribute is invalid

Hi All,

Trying to create a new package for Cisco Anyconnect. As part of this, I am doing a "installed rule" option, so that it looks at following:

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Cisco\Cisco AnyConnect Secure Mobility Client

InstallPathWithSlash

vpnagent.exe

Comparision: Greater Than or Equal to

4.4.01054

This version is correct: 4.4.01054

However at final hurdle it falls over with the follow error:

*****

FULL ERROR:

Source: Csla

Exception occurred at 23/03/2017 14:30:22: The 'Version' attribute is invalid - The value '4.4.01054' is invalid according to its datatype 'http://schemas.microsoft.com/wsus/2005/04/CorporatePublishing/BaseTypes.xsd:Version' - The Pattern constraint failed.

DataPortal_Execute method call failed

DataPortal.Update failed

Stack: at Microsoft.UpdateServices.Administration.Internal.UpdateServicesPackage.Verify(String packageFile)

at Microsoft.UpdateServices.Administration.Internal.UpdateServicesPackage.Save(String packageFile)

at EminentWare.BusinessObjectLayer.SoftwarePackage.SoftwarePackage.SDPToXML(SoftwareDistributionPackage sdp, DateTime creationdate)

at EminentWare.BusinessObjectLayer.SoftwarePackage.SoftwarePackage.MakeDefaultSoftwareDistributionPackageWithCreationDate(SoftwarePackage sp, DateTime creationdate)

at EminentWare.BusinessObjectLayer.SoftwarePackage.SoftwarePackage.VerifyPackageCommand.DataPortal_Execute()

at Csla.MethodCaller.CallMethod(Object obj, MethodInfo info, Object[] parameters)

at Csla.MethodCaller.CallMethod(Object obj, String method, Object[] parameters)

at Csla.Server.SimpleDataPortal.Update(Object obj, DataPortalContext context)

at Csla.DataPortal.Update(Object obj)

at Csla.DataPortal.Update[T](T obj)

at Csla.DataPortal.Execute[T](T obj)

at EminentWare.BusinessObjectLayer.SoftwarePackage.SoftwarePackage.Verify(SoftwarePackage package)

at EminentWare.UI.Publisher.PackageWizard.CreateOrEditPackage(Object obj)

END ERROR

*****

Tried to search this on google and on these forums but not able to find any details around this, the link in error also doesn't work. Not sure what I'm doing wrong here. Can someone provide some guidance?

regards

Ricky

Find more posts tagged with

Accepted answers

frgpugs

I am nowhere near sure on this but just something tickles my brain about needing 4 numbers in the value with periods. Something like 4.4.01054.0

Either way you can do the rule another way and just look for file with version instead of registry. Creating custom packages sucks hard with patch manager and sometimes what SHOULD work just doesnt and you have to play with it to find what does. I have not been able to find out what the differences are when I have to find other rules to get things to install. I also havent cared much and just used PDQdeploy or something instead.

All comments

frgpugs

I am nowhere near sure on this but just something tickles my brain about needing 4 numbers in the value with periods. Something like 4.4.01054.0

ricky.taylor

Hi frgpugs,

You appear to be correct here. I think this is more a windows feature on file versioning.

Cisco Anyconnect version: 4.4.01054

vpnagent.exe file version: 4.4.1054.0

Checked few other files and I think windows file version are always in 4 subnets (possibly removing leading 0's at start of subnets as well). Either way, just use the file version listed by windows on details tab for this.

Changed the version number to be identical to how windows sees it in the details tab and this has allowed the package to be created.

kellytice

I would question whether that rule should be "greater than or equal to".
usually, for the installed rule you would make it just "equal to"

if you leave it as greater than or equal to, if a machine happened to have a later version of the same software, WSUS would think that this machine also has this version installed so that might give you some screwy reporting results.

ricky.taylor

how would that affect newer versions installed thou, as it would not see this older one as being installed (so wouldn't it tell it to be installed, reverting it to older version)?

Or I guess I should cover this by superseding this with the newer version, when it comes about? Sorry if this is a basic question, Solarwinds patching and really whole app packaging is all new to me (only really done WSUS before).

kellytice

My comment above is assuming that both packages were left on the WSUS server.

Apologies if this is a huge digression for the original topic, but to (hopefully) clarify what i mean:

When a WSUS client 'checks in' to the WSUS server, it will evaluate all the updates on the WSUS server. It essentially checks, for each update, for things like:

"is that update approved for me?" - this is determined by whether the update is "Approved" for the target machine's WSUS group
"is that update applicable to me?" - this is determined by looking at the Prerequisite and Applicability rules that were defined in the package.
"is that update already installed on me?" - this is determined by the Installed rule(s) that were defined in the package.

and then it reports information on what it found for all the updates back to the WSUS server.

Let's say i make a package for CoolNewApp version 2.0.0 and define the following rules:

Prereq Rules: The target machine must be x64 and must be at least windows version 6.0 or higher

Applicability: This update will only be applicable to target machine if a File Version check on C:\program files\coolnewapp\coolnewapp.dll shows a version less than 2.0.0.

Installed: I make this rule essentially the same as the Applicability one, but with a "greater than or equal to" condition

I publish that into WSUS and have some machines evaluate it and at least some of my WSUS clients end up installing the CoolNewApp 2.0.0 software on their next scheduled patching cycle.

So, after a few days, some WSUS clients will show that update as "not installed" and some that have already gotten it will show it as "installed" based on that last rule.

A couple of months later, CoolNewApp version 2.0.1 comes out, so i clone the old package, update the version specified in the Applicability and Installed rulesets. I publish that, and some machines get it on their next patching cycle.

If both CoolNewApp 2.0.0 and CoolNewApp 2.0.1 are updates available on the WSUS server, when one of my Client machines that has 2.0.1 checks in again and gets to evaluating the Installed ruleset, that will now evaluate as true for BOTH of those packages since 2.0.0 and 2.0.1 are both 'greater than or equal to" 2.0.0.

Essentially, WSUS will now think that the client has both updates currently installed. That shouldn't happen though, if the packages' Installed Rule was just "equal to" instead of "greater than or equal to" since in that case only one of the two packages Installed rule would evaluate as True.