Build numbers

[Gostev]

@Gostev - are you expecting our management system to pick up something ( Pyyyymmdd) that Veeam isn't specifying as the software version in the only place that matters in Windows?

No, I definitely don't expect anything that was not specifically designed, implemented and tested to work. Sure, some things may work arbitrarily with some management systems - but it's definitely not "expected" and is rather pure luck.

We can certainly discuss and consider this as any other feature (I mean support for "your" management system), especially if it is a simple fix. For example, changing it in the Add/Remove Programs will likely not be simple because the cumulative patch does not install a new build, but merely replaces some modules in the existing installation. But may be we can update it somewhere else where your management system can easily pick it up.

[AlexHeylin]

Perhaps a temp workaround of

Code: Select all

$version = (Get-ChildItem C:\ProgramData\Veeam\Backup\Svc.VeeamUI.log | Select-String -Pattern "version=" | Select-Object -Last 1).ToString().Split('=') | Select-Object -last 2
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Veeam Backup & Replication" -Name "DisplayVersion" -Value ($version[0].Split('&patch')[0] + "." + $version[1].Split('P')[1]) -Force

to correct the version string to '11.0.1.1261.20220302' format (including the patch number) might be the best option until Veeam can decide what they're really calling things and stick to it everywhere. That format won't require my SQL comparison modification as the existing recursive comparison code will work fine.

'11.0.1.1261.20220302' format does work fine using the inbuilt version comparison, so please let me alter my original request of "Please stop using this weird format" to "Please write '11.0.1.1261.20220302' format into the DisplayVersion and any other appropriate fields in the "program library" (Uninstall registry) of Windows so that Windows and 3rd party inventory software can correctly identify Veeam software versions"

As this hasn't been implemented by Veeam yet, and it shouldn't break anything please implement using '11.0.1.1261.20220302' format (not '11.0.1.1261P20220302' or '11.0.1.1261 P20220302' etc) as being the most compatible (assume each segment is converted to a signed integer for processing, which in this case they are, and is a likely implementation elsewhere). At least sticking to pure integers gives more chance this will parse without special handling.

Please note - I got the registry path wrong (wrong VBR component) in an earlier post, but it doesn't make any difference because none of the DisplayVersion fields currently get updated with patch numbers.

Thanks. Surely sensible people have better things to do all of Wednesday evening than this...

[AlexHeylin]

We can certainly discuss and consider this as any other feature (I mean support for "your" management system), especially if it is a simple fix. For example, changing it in the Add/Remove Programs will likely not be simple because the cumulative patch does not install a new build, but merely replaces some modules in the existing installation. But may be we can update it somewhere else where your management system can easily pick it up.

Sorry @Gostev - This isn't, and never was, about "my" management system. It's about providing the version of the installed software in the standard Windows way, and in a form which is readily parsable. If you tell Windows the correct info - everything and everyone will get the correct info because they (nearly) always read it from Windows. That's the standard way. In 25 years I've only seen one system that didn't do it that way, and that's because it was a Y2K inventory tool written to support DOS and Win 3.1 (Wow, now I feel old!). In Windows-Land (since Win95) you don't get software versions by parsing 3rd party text files, or reading 3rd party registry keys. You read the DisplayName and DisplayVersion of each entry under
HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
and on 64 bit Windows also
HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall

As '11.0.1.1261.20220302' should always version compare as larger (newer) than '11.0.1.1261.20211211' and that as newer than '11.0.1.1261' this seems an elegant and compatible solution. Doesn't it?

Thanks

[Gostev]

We're just keep going in circles. Hotfixes don't change the build number or "the version of the installed software" and this IS a standard way to issue them: for the specific build.

If all "your" management software can understand is a build number, then it is just not flexible enough to detect installed hotfixes. Please understand that we're not going to stop issuing hotfixes just because your software is unable to detect their presence due to its limited capabilities. Nor we're going to start issuing each hotfix as a new build as you wish we did, because that's just insane in terms of overhead. But we CAN make the patch level more easily consumable, and for that we just need to know what is the best way to exhibit one for software management systems like yours.

Honestly, until we agree on some base parameters like the fact that hotfixes don't change the build number, and finally stop expecting it to change, this conversation is a pure waste of time for both of us. So I suggest we stop it.

[AlexHeylin]

@Gostev
I disagree with many of the points you raised, but it wouldn't be constructive for me to argue with you about them.

we CAN make the patch level more easily consumable, and for that we just need to know what is the best way to exhibit one for software management systems like yours.

Thanks. '11.0.1.1261.20211211' (take your release name and replace ' P' with a '.') is the least worst and most likely to be compatible. It's also the easiest to understand and process. Set the DisplayVersion string as mentioned earlier.

With that in place, Windows and all 3rd party management tools will be able to read the rollup (P) number. If they're able to correctly compare versions will depend on how they've implemented their compare function. The default function in "my" software (LabTech / Connectwise Automate) will handle it as long as all segments are positive integers.

Thanks for agreeing to make this important information visible to Windows and 3rd party software.

There is one thing I think we should touch on here ahead of implementation. What about the "sub-products" such as "Veeam Explorer for xyz". Those might be installed stand alone or bundled as part of either VBR or VBM365 (possibly others too). I don't know if they get updated by a P rollup, my guess is they might be. I suggest that if they are updated, the same numbering should be applied. Now I realise that VBR version '11.0.1.1261' might include "Veeam Explorer for xyz" version '9.12.5.324" - I suggest that if the P rollout updates "Veeam Explorer for xyz" then its version should be changed to '9.12.5.324.yyyymmdd". This seems to make sense, and because the yyyymmdd is a date string, there should be no conflict between the completely different version numbers of the two software ('11.0.1.1261' vs '9.12.5.324'). I'm not trying to be difficult here, I'm hoping to avoid this question arising again for the sub-products and ensure the best data is always available. If you know a reason that this would cause problems, then obviously don't do it - otherwise does it makes sense to do it?

Thanks again.

[Gostev]

'11.0.1.1261.20211211' (take your release name and replace ' P' with a '.') is the least worst and most likely to be compatible. It's also the easiest to understand and process. Set the DisplayVersion string as mentioned earlier.

With that in place, Windows and all 3rd party management tools will be able to read the rollup (P) number.

You're yet again talking about changing the build number of the installed software though - but as we already established many times, a hot fix simply cannot do this. A hot fix merely replaces some of the binary files of the already installed software with updated files.

[Egor Yakovlev]

+ 2 more methods of retrieving a current version(as an alternative to "via parsing logs" example above):

a) via WMI \ Powershell (query on Instance root\VeeamBS, class BackupServer, property DisplayName)

Code: Select all

$DisplayVersionWithDot = (Get-CIMInstance -Namespace Root\VeeamBS -classname BackupServer |Select-Object -Property DisplayVersion).DisplayVersion.Replace(" P",".")

b) via Get-VBRPrivateFixes cmdlet. It lists all changed files and applied fixes, easily filtered and parsed

Code: Select all

$LastPatchedFileVersion = Get-VBRPrivateFixes | Where-Object {$_.FixKind -eq "HotFix" } | Select-Object -Property Fileversion,PrivateFix | Sort-Object -Property PrivateFix | Select-Object -Last 1
$VersionWithDot = $LastPatchedFileVersion.FileVersion + "." + $LastPatchedFileVersion.PrivateFix

/Hope that helps!

[RubinCompServ]

You're yet again talking about changing the build number of the installed software though - but as we already established many times, a hot fix simply cannot do this. A hot fix merely replaces some of the binary files of the already installed software with updated files.

I think what he's suggesting is just tricking software into thinking that the build number has changed, even though it hasn't. In essence, if I understand the thread correctly, there is one field that contains the data '11.0.1.1261' and a separate field that contains the data 'P20211211'' and those two fields get concatenated (along with a space) in various instances. What he's suggesting is to NOT change the fields where the build & hotfix numbers are stored, but just to change the data contained in the hotfix field to say '.20211211' instead of 'P20211211' and then concatenate without the space. This is something the hotfix should be able to do, since it's already updating that second field anyway. In other words, this is purely a cosmetic change, with no changes to the underlying data structure; the build number won't actually change, it will just look like it has.

[AlexHeylin]

You're yet again talking about changing the build number of the installed software

Hi @Gostev,
Perhaps we're talking at cross purposes... you're currently putting this numbering scheme 'Major.Minor.Point.Build' into the registry. I'm suggesting 'Major.Minor.Point.Build.Patch' (patch = the yyyymmdd from the P release). You're changing the installed software (but keeping the same build), thus it's correct to use and increment the patch section of the DisplayVersion string.
I'm not talking about changing the build number, I'm talking about adding / incrementing the Patch section which comes after the Build number section.

as we already established many times, a hot fix simply cannot do this

We've not established that at all. An installer, which is how you're applying the P releases certainly can set a registry entry. Even if you were installing your P rollups using only something basic like a batch file, the registry entry could still be set.

A hot fix merely replaces some of the binary files of the already installed software with updated files.

If it can write new executables, DLLs, and image files to disk I'm sure it's capable of writing a registry entry. I'd be willing to bet ££££ that Veeam have already published at least one hotfix / P rollup which writes a registry entry.

Here's a statement by a Veeam product manager in another thread which confirms Veeam hotfixes already can include registry changes.

Yes, the hotfix includes this registry key as well as other minor fixes for issues reported by other users.

veeam-one-f28/veeam-one-alert-performan ... 30403.html

As Egor has demonstrated - P rollups are already writing this info in 'Major.Minor.Point.Build Pyyyymmdd' format into wherever this is stored,

Code: Select all

Get-CIMInstance -Namespace Root\VeeamBS -classname BackupServer |Select-Object -Property DisplayVersion

and this includes the information you're saying you can't write to the DisplayVersion string in the uninstall entry in the registry.

Based on the code Egor kindly provided, an approximate of some code to do this right now would be

Code: Select all

$DisplayVersionWithDot = (Get-CIMInstance -Namespace Root\VeeamBS -classname BackupServer |Select-Object -Property DisplayVersion).DisplayVersion.Replace(" P",".")
Set-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Veeam Backup & Replication" -Name "DisplayVersion" -Value "$DisplayVersionWithDot" -Force

I hope we can agree that Veeam's P rollup installers would be capable of running this code. Obviously it would make sense to do this properly in the installer rather than call PowerShell afterwards. I'm just demonstrating that the thing you're saying

a hot fix simply cannot do

can be done.

Given Veeam are capable of writing amazing software, I think writing one registry value during a P rollup installation is something your Dev team would find boringly easy to do.

At this point, I already have a way forward in getting the data I need written to the registry via the above code. Thanks @Egor!
I'm still going to suggest that it would be an improvement is Veeam would set the DisplayVersion of the uninstall entry to 'Major.Minor.Point.Build.Patch'. If you're absolutely convinced this can't / shouldn't be done, then we're going to have to agree to disagree and I'll use the code above to set the DisplayVersion of the uninstall entry to 'Major.Minor.Point.Build.Patch' which will work perfectly.

Thanks

[Gostev]

We're not "putting this numbering scheme into the registry". These values are created by and belong to that complexity monster called Windows Installer. And normally we can't just update them directly without screwing up other things... but I'll double check with the devs.

[AlexHeylin]

I've made the recommendation, and stated how Veeam could do it. Do it or don't do it - that's up to Veeam. I'm going to use our RMM to run the code above to overwrite the DisplayVersion with the 'Major.Minor.Point.Build.yyyymmdd" variant, and I don't expect that this will cause any additional problem at all.

Thanks

[spiritie]

I can agree on @AlexHeylin frustrations, he is not the first or last person to have stumbled across this frustrating problem of retrieving the full build number from Veeam in a "easy" fashion. To demonstrate this look at this "hackish code" we ended up using to get this build number as I simply could not figure other elegant methods of getting the full build number out of Veeam native PowerShell cmdlets or Windows WMIC. I'll replace my code with Egor's better version, as it seems to be able to retrieve it more precise as my code relied on a specific DDL.

Code: Select all

$CorePath = Get-ItemProperty -Path "HKLM:\Software\Veeam\Veeam Backup and Replication\" -Name "CorePath"
$CoreDLLPath = Join-Path -Path $CorePath.CorePath -ChildPath "Veeam.Backup.Core.dll" -Resolve

$VeeamVersion = Get-Item -Path $CoreDLLPath

Write-Host $VeeamVersion.VersionInfo.ProductVersion "|" $VeeamVersion.VersionInfo.Comments

It would not hurt to have some native PowerShell cmdleds from Veeam to simply get this piece of information in the future.

[m.novelli]

We're just keep going in circles. Hotfixes don't change the build number or "the version of the installed software" and this IS a standard way to issue them: for the specific build.

If all "your" management software can understand is a build number, then it is just not flexible enough to detect installed hotfixes. Please understand that we're not going to stop issuing hotfixes just because your software is unable to detect their presence due to its limited capabilities. Nor we're going to start issuing each hotfix as a new build as you wish we did, because that's just insane in terms of overhead. But we CAN make the patch level more easily consumable, and for that we just need to know what is the best way to exhibit one for software management systems like yours.

Honestly, until we agree on some base parameters like the fact that hotfixes don't change the build number, and finally stop expecting it to change, this conversation is a pure waste of time for both of us. So I suggest we stop it.

Gostev , Veeam position about this matter is wrong from the beginning. If it was right, such thread shouldn't exist.

I don't care about patch, hotfixes , any name you prefer: me , like other, just want to easily check installed Veeam version AND be updated to latest version

How you reach that? It's your job, we pay a license for that.

Marco

[Gostev]

Finally we can agree on something with you I actually said exactly the same right at the beginning of this thread, but no one heard me it seems.

[DanielJ]

> b) via Get-VBRPrivateFixes cmdlet. It lists all changed files and applied fixes, easily filtered and parsed

Is this method local only? I am looking for a way to get the installed version/patch level from remote VBR servers, and this looks promising, but errors out if I have a current VBR session open (even locally).

[Egor Yakovlev]

By default it works in localhost context.
You can use it with -Server -Port parameters to connect remotely without need of open session.

[AlexHeylin]

I actually said exactly the same right at the beginning of this thread, but no one heard me it seems.

Woosh - and just like that my reply to this got moved to another thread, effectively removing it from this conversation. OK, I can take a hint.

[Mgamerz]

I don't want to get into an argument about anything here but here's my 2 cents on the matter.

One example of the current build numbers being an issue the Remote Code Execution vulnerability that Veeam had recently. We use Tenable for vulnerability detection, but I also use PDQ Inventory for software inventory locally, which uses a semantic version for basic product version detection. I don't have the ability to control that it uses that. I also don't have the ability to write my own plugins for Tenable. Tenable has its own plugins it can use to accurately determine things, but I don't know of a published standard where you can accurately get version information about the Veeam installation.

An external registry key could work - maybe a list of hotfixes - but when I went into PDQ Inventory to see if I was up to date on my instances - there was no real way to tell without manually logging into each Veeam server, since by default it uses the version number that was done by Windows Installer. I could add a scanner for this key and then make a filter on it - so that could be a (less than desirable) solution, but it could work.

Which is the problem. I don't know of another way to get the info. There needs to be an easy STANDARD, RELIABLE way to pull the Veeam version + optionally patches (be it a single up-to-date build number, or some auxiliary thing to read), because if you just go by the build number on the windows installer string (as it stands now), it's not really helpful.

Earlier in the thread there was mention of X.Y.Z.P.Q, but this is also not a valid semantic version (e.g. .NET cannot parse this with it's 'Version' class), so that doesn't seem like a better than the current system, you're trading one problem for another.

[Gostev]

What way to pull the Veeam version + patches would be ideal for you? Would a dedicated PowerShell cmdlet work for example? Or a registry key on the backup server?

[spiritie]

@Gostev +1 for an dedicated PowerShell cmdled

[Mgamerz]

PowerShell commandlet would work. Maybe even a file (like a blank dll) that held the right version would also work, but not sure how internally your versioning is done. I do software dev (not anywhere near Veeam''s scale) so I know that while this may appear simple, software internally is like a big jenga tower, you can't just swap out a block

A blank dll that held the version number - again, not sure if this works with your system, since you could have 3 hotfixes for diff issues on a single build, that aren't all cumulative - but if there is a way to have *a* file with the right version, it'd probably be easiest for vendors to just scan the version number on the file to determine it, if the registry key isn't a workable solution. Powershell would also be nice, or like VeeamCLI.exe --version (example)

Essentially, what I'm seeing is the windows installer build number system changing isn't really an option. So the path forward is to find another solution that could fill the need for easy-to-determine veeam backup server. Registry key, version of a dll, powershell cmdlet, etc could all work.

[Gostev]

@oleg.feoktistov can you please investigate adding such cmdlet?

@Egor Yakovlev I may be mistaken but I believe every cumulative patch always brings the newly recompiled licensing DLL inside. Could we have a patch name as a part of its version string?

[oleg.feoktistov]

We don't see any issues with adding such cmdlet in the nearest product version. Also, I believe version and patch values should be represented in distinct dedicated properties. Consider it duly noted as a requirement. Thanks!

[AlexHeylin]

Just to add to this - I found a VBR instance yesterday which VAC claimed was running 11.0.1.1261 P20220302 but the Veeam Distribution Service was actually older and running a version prior to 11.0.1.1265 (which is the DisplayVersion shipped as part of VBR 11.0.1.1261 P20220302). I don't know how this happened, and I'm not going to investigate. I can only assume the patch install process screwed up and left a highly vulnerable subcomponent in place but updated all your internal indicators to say that 11.0.1.1261 P20220302 was fully installed. The point I'd like to make is that as this clearly can happen - when vulnerabilities in a sub component like this are patched it would be good if the info from Veeam included the minimum required subcomponent version to resolve the vulnerability.

Despite VAC and the GUI having sight of this system neither showed any signs of this subcomponent not having been upgraded. I spotted it by comparing the DisplayVersion of the installed subcomponents across all our VBR instances by using our RMM. This is an example of why making the correct data available is important. If you can't add the P release to the DisplayVersion for reasons - that's fine. Listing the minimum required subcomponent version would have allowed us to have checked that (using our RMM) instead of the VBR version in the first place and avoided this problem. It is likely a better option anyway (for security issues like this) as it checks that the subcomponent is actually installed, not just that the P patch has been installed and the subcomponent should have been upgraded.

Thanks

[TWuser]

Very helpful thread. +1 for a dedicated powershell command, I imagine that could be adapted to query all remote servers.

I think only 1 user mentioned it already, but if the full version was displayed in Enterprise Manager that would be incredibly simple and useful for verifying VBR versions across a larger environment.

[Egor Yakovlev]

if the full version was displayed in Enterprise Manager

That should be done. Already logged required tasks for devs.

/Thanks!

[spiritie]

@Veeam, did this make it into v12?

[Gostev]

What specifically are you referring to? There are a few different asks above.

[spiritie]

What way to pull the Veeam version + patches would be ideal for you? Would a dedicated PowerShell cmdlet work for example? Or a registry key on the backup server?

This one with "dedicated PowerShell cmdlet"

[oleg.feoktistov]

The dedicated Powershell cmdlet for getting server build + patches didn't make it to v12, unfortunately. Will be following up this thread as soon as I have any updates. Thanks!