Patch to 12.1.2.172 some modules still 12.1.0.2131

[dali@iae.nl]

Patched today with the patch to 12.1.2.172.
Install gave some errors because Microsoft System CLR Typers for SQL Server 2014 was not present (?) even when we use Postgres.
Installed the CLR Types and ran again without errors.

Is it correct that some modules are still 12.1.0.2131: vPowerNFS, VSS Integration, Hyper_V Integration
Case #07271760

Beside that a minor issue: all THROUGHPUT gives Speed 0 KB/s but figure and speeds are OK.

[Dima P.]

Hello Da Li,

Thank you for your post! Investigating, stay tuned.

[Dima P.]

Is it correct that some modules are still 12.1.0.2131: vPowerNFS, VSS Integration, Hyper_V Integration

Correct. Patches bring modifications only to the components / modules that were changed due to improvements / fixes. The mentioned ones were not changed, so they still have the old version.

[dali@iae.nl]

Great thanks for confirmation.

The 0 KB/s is maybe a little bug?

[Dima P.]

The 0 KB/s is maybe a little bug?

Can you please share a screenshot where such stats are displayed incorrectly? We've looked across multiple backup activities and were not able to confirm it. Thank you!

[SnakeSK]

My view on this that with version upgrade, all components should be upgraded to let the user know everything is fine. We had numerous cases when we had to manually update Veeam installer service to the latest version because that is not autoupgraded and support blamed various problems on version difference.

Even if nothing changes, the latest installed component should reflect the version of the base VBR

[dali@iae.nl]

Screenshot of the 0KBps is in the ticket Case #07271760
(hard to get an image in here )

[m.novelli]

My view on this that with version upgrade, all components should be upgraded to let the user know everything is fine. We had numerous cases when we had to manually update Veeam installer service to the latest version because that is not autoupgraded and support blamed various problems on version difference.

Even if nothing changes, the latest installed component should reflect the version of the base VBR

Fully agree

Marco

[Gostev]

@SnakeSK this would obviously require rewriting each and every module with a new build of the same module, even if there were no changes made to the module. Which in turn means the size of each product update will be equal to the full size of the product.

Is this an acceptable tradeoff for having all product files display the same build number, which is essentially just about making the installation "pretty" w/out any technical benefits? But with the drawbacks of bigger update size and longer update installation time.

Just a question, I'm not trying to imply the correct answer by how I formulated it.

[SnakeSK]

Anton, creating a .msp file which would rewrite version numbers for unupdated modules is exactly 10kb . So no need to tradeoff anything.

[Gostev]

https://imgflip.com/i/8rqvt8

[SnakeSK]

Installed version is stored in the registry. No need to sign or modify anything regarding files. Keep the dlls on whatever version you want, present the user with same codebase

[JPMS]

Just a question, I'm not trying to imply the correct answer by how I formulated it.

I'm sure there is a 'wink' emoticon missing there.

Systems people tend to be anally retentive. It's what makes us good at our jobs so I get the desire to have everything neat and tidy with the same version number. Fortunately I have had enough therapy to just about cope with the way it currently is.

However, I must confess to always having had an issue with the Veeam Installer Service, which has always been upgraded with patch updates but has always shown the old version number in Programs and Features. I read somewhere here that this was to do with the way the upgrade of this component is done but confess to manually running the installation program for the Installer Service after the patch so it shows the correct version number.

This time however, the Veeam Installer Service version number showed the correct version number 12.1.2.172 after the patch but only on the main installation. Other components, like our Hyper-V host and Windows repo still showed the old version number for the Veeam installer Service, 12.1.0.2131 despite other components being upgraded (I ticked upgrade remote components automatically). Now I'm not sure if the Installer Service actually got upgraded or not so I made sure I reinstalled that component on the remote components.

From this experience it seems that Veeam may have hit the worst of all worlds regarding the Installer Service. Updating it on all components but showing different version numbers depending on whether it is the main local installation or a remote component. I think I'm going to need to book myself another therapy session to cope with the version number disparity.

[Gostev]

No wink because devs have been pushing for this approach internally to further simplify some of their processes. But my worry has been the size of updates...

[SnakeSK]

I want my nickname in the Release notes if this gets pushed through