VBO 365 upgrade failed at Step 2 of 6 - Error 1603

[dhayes16]

Hello. We have not opened a ticket yet but we tried to update to 8.2 and it keeps bombing at Step 2 of 6. The resources of the server are more than enough. The error being thrown is 1603 in the setup logs. The OS is windows 2019 with all the latest updates. Plenty of space. Running as Admin, license is good, no pending reboots, etc.

I do not want to lose the local repo we have on this server. That would be very bad.

Since I can not launch VBO to pull/collect the logs, where would I pull the logs to upload to the ticket to provide to tech support? I want to make sure they have everything they need.

We upgraded 6 other customer systems and they upgraded fine.

Thanks for any help.
Dave

[Mildur]

Hi Dave

Logs are in C:\programdata\veeam\backup365.
There should be a folder for setup logs. Just create a zip archive of the entire folder.

You can also ask the support engineer which logs he requires from you.
Please don‘t forget to share the case number here.

Thank you,
Fabian

[mjr.epicfail]

Check your eventlogs of the windows host, you will probably find an error there.
Can you share that one on here (if it doesnt have any private info) ?

[dhayes16]

Hi Dave

Logs are in C:\programdata\veeam\backup365.
There should be a folder for setup logs. Just create a zip archive of the entire folder.

You can also ask the support engineer which logs he requires from you.
Please don‘t forget to share the case number here.

Thank you,
Fabian

Thanks for the reply. I opened Case # 07874511

Once again very much appreciated.

[dhayes16]

Check your eventlogs of the windows host, you will probably find an error there.
Can you share that one on here (if it doesnt have any private info) ?

Thanks for your reply. I poked around in the event logs and did not see anything glaring. I opened a ticket with Veeam so we will see how it goes. I will dig in further later today

[DanielJ]

We too got hit by this error, leaving an unusable server instead of doing a rollback. I have a P1 case open: 07868274. I was called by a support tech who clearly was reading from a script instead of having any actual knowledge of the issue. We started the setup again, which now said "Install" instead of "Update", and it seemed like it could reuse the existing database, but it could not reconnect to the running NATS server which was installed by the v8 upgrade. We verified that port 4222 was responding. The support tech stopped the NATS server, renamed C:\ProgramData\Veeam\Backup365\nats to nats_old, then tried to restart the service which failed expectedly, then retried the installation and again tried to connect to the existing NATS server. I asked why he was doing this since the server now wasn't running and couldn't respond, but he thought it would start by itself. He then tried port 4222 again with tnc and was puzzled that it didn't respond. I said that of course it won't respond and asked if we shouldn't create a new NATS instance instead, but he said "It doesn't say I should do that..." probably referring to his script.

I don't want to critisize a support tech doing his best, but if "the best" is like this, where does that leave your customers? I also don't want to just try creating a new NATS instance, since I'm not sure what that will do with the current configuration. Since it's possible to connect to the old one, it seems like that would be the correct thing to do, but it was not possible even when it was running. We can't end up in a situation where we have to contact all customers to do device logins during a weekend.

I have a backup of the whole server, but that backup is from yesterday before the most recent job runs, and I can't be sure how the database would react to that. Support could not answer this. The case would get escalated to the next tier but there is no guarantee that someone will contact me today.

I am terribly disappointed with being left with this mess after applying a supposedly simple patch, which has passed QA even though it can fail this destructively.

[DanielJ]

Well, I am happy to add that this was resolved quickly by the next tier. I learned that there is no need to reuse the NATS server, it can simply be uninstalled and a new instance deployed. There was no problem connecting to the current database, but the proxy servers could not be updated normally. After uninstalling one proxy and readding it, the others suddenly showed the updated version as well. Since there is no config backup the support tech advised me to install Postgres tools and schedule pgbackup to be on the safe side. I will do that but it would sure be nice if it was done automatically.

[mjr.epicfail]

I know the are working or having something in the roadmap for config backups, something similar like vbr config backup.

[Nicolas1202]

Hi,
I have the same issue with the update to the version 8.2.0.2202.
The update fails and remove Veeam O365.

I reverted my snapshot so i am fine (but i need to update my version because of the issue "Item has been changed during the backup...").
I have a case open, and the logs folder has been sent as well.
I am waiting for the answer of the support.
Do you know what was the problem during the installation?

Thanks
Best regards,
Nicolas

[tm67]

Maybe the setup fails because some files are locked by a running process. Try to stop all Veeam services and then run the upgrade again. I remember that I had this issue once, and this solved it.
If you have vb365 uninstalled now, you can just install the new version like a new installation. But you need to enter postgresql and nats server credentials during the installation. This will reconnect to the already existing configuration.

[mjr.epicfail]

VB365 has to be running before upgrade can start.
You can try to reboot the machine first to clear any pre existing conditions.

Also it will help to close down the shell and check with taskmanager if all Veeam.shell processes are exited, if not then just end them.
Windows Defender and other AV should be disable entirely, 1 it will speed up the process of starting the setup, but it will avoid issues with files being marked suspicious and or being blocked from accessing.

[Nicolas1202]

Hi,

Thanks for your answers.
I already tried twice and once with the service stop before to start the update.
I will tried again in checking before if i have occurences of Veeam.shell in the task manager.
Otherwise i am still waiting for the logs analysis by the support.

[DanielJ]

I never got to know what the actual problem was. It was good enough that it was possible to do a new install and reuse the database so nothing was lost. Of course, the setup procedure should fail more gracefully.

[DaStivi]

Hi,
I think I just ran into the same issue: VB365 upgrade to version 8.2 failed with error 1603.

You can find the logs under:
C:\ProgramData\Veeam\Backup365\Logs

The file Veeam.Archiver.Autorun_<year>_<date>_<time>.log shows the MSI call and points to another detailed log:

[Info] MSI start: /i "F:\Backup\Veeam.Backup365.msi" ADDLOCAL="BR_OFFICE365,CONSOLE_OFFICE365,PS_OFFICE365,REST_OFFICE365" REMOVE="" STARTSERVICES="1" /qn ACCEPT_THIRDPARTY_LICENSES=1 ACCEPT_EULA=1 /norestart /l*v
"C:\ProgramData\Veeam\Backup365\Logs\Setup\Veeam.Backup365_2025_11_11_13_38_30.log"

In this detailed log, I found the following reason for the error:

Invoking remote custom action. DLL: C:\windows\Installer\MSI5450.tmp, Entrypoint: WixQuietExec64
WixQuietExec64: Veeam Backup for Microsoft 365 Service wird gestartet.
WixQuietExec64: Veeam Backup for Microsoft 365 Service konnte nicht gestartet werden.
WixQuietExec64:
WixQuietExec64: Ein Systemfehler ist aufgetreten.
WixQuietExec64:
WixQuietExec64: Systemfehler 1067 aufgetreten.
WixQuietExec64:
WixQuietExec64: Der Prozess wurde unerwartet beendet.
WixQuietExec64:
WixQuietExec64: Error 0x80070002: Command line returned an error.
WixQuietExec64: Error 0x80070002: QuietExec64 Failed
WixQuietExec64: Error 0x80070002: Failed in ExecCommon method

In that detailed log, the reason for the error seems to be:
“A system error has occurred” and “Process terminated unexpectedly” (translated from German).
Additionally:

There is a System Event Log entry indicating that the service crashed.
In the Application Log, I found an entry from Veeam.Archiver.Service itself, which might provide more details:

Category: Microsoft.Extensions.Hosting.Internal.Host
EventId: 11

Hosting failed to start

Exception:
System.IO.FileNotFoundException: Could not load file or assembly 'C:\Program Files\Veeam\Backup365\Veeam.Jet.Net.v12.2.0.dll'. Das angegebene Modul wurde nicht gefunden.
File name: 'C:\Program Files\Veeam\Backup365\Veeam.Jet.Net.v12.2.0.dll'
at Veeam.Archiver.Controller.ServiceConfiguration.PostgresDatabaseConfiguration.ConfigureJetAndSqliteToPostgresUpgrade(IServiceCollection services)
at Veeam.Archiver.Controller.ServiceConfiguration.PostgresDatabaseConfiguration.Configure(IServiceCollection services)
at Veeam.DI.MicrosoftExtensions.ServiceConfiguration.CompositeConfiguration.Configure(IServiceCollection services)
at Veeam.DI.MicrosoftExtensions.ServiceConfiguration.CompositeConfiguration.Configure(IServiceCollection services)
at Veeam.DI.MicrosoftExtensions.ServiceConfiguration.ServiceProviderBuilder.BuildServiceCollection[TConfiguration](Action`1 initialConfigure, Action`1 postConfigure)
at Veeam.DI.MicrosoftExtensions.ServiceConfiguration.ServiceProviderBuilder.Build[TConfiguration](Action`1 initialConfigure, Action`1 postConfigure)
at Veeam.Archiver.Service.ServerServiceInitializationContextCreator.CreateServiceProvider()
at Veeam.Archiver.Service.ServerServiceInitializationContextCreator.CreateContext()
at Veeam.Engine.Hosting.ServiceWorker.StartAsync(CancellationToken cancellationToken)
at Microsoft.Extensions.Hosting.Internal.Host.<StartAsync>b__15_1(IHostedService service, CancellationToken token)
at Microsoft.Extensions.Hosting.Internal.Host.ForeachService[T](IEnumerable`1 services, CancellationToken token, Boolean concurrent, Boolean abortOnFirstException, List`1 exceptions, Func`3 operation)

My heart nearly stopped when I realized that VB365 was no longer installed after the failed upgrade – there was no rollback, the product was just gone!

A reinstallation and pointing it to the existing PostgreSQL database “fixed” the issue, but honestly, this behavior doesn’t feel very trustworthy…

i've just opened a case (#07883323 ) for support to check if this could be some more common issue with the setup routine... this shouldn't happen!

[admd]

Also had the error "Could not load file or assembly 'C:\Program Files\Veeam\Backup365\Veeam.Jet.Net.v12.2.0.dll"

Stayed on the same PostgreSQL DB, but
I had to uninstall the NATS service : sc.exe delete nats-server
And resinstall a new instance.

After that I rebooted all my linux proxies and updated them (apt upgrade)
Then after multiple rescan, even if they showed "Offline" I tried to update them and I worked.
No problems for my Windows proxies.

It took longer than expected but I saved time thanks to this thread.

[DaStivi]

The outcome of my case showed that the error was related to NATS being unavailable during the upgrade process. Initially, I wasn’t sure if I just rebooted my dedicated NATS server while I just upgraded VB365, causing the issue, but it turns out this seems to be a more common issue.

Glad to hear my tips via PM were helpful . Hopefully, sharing this here will help others facing similar problems.