Upgrading from 12.3.0.310 to 12.3.2.3617 stopped at the database check with “Failed to connect to PostgreSQL server localhost:5432.” The fix was to map the exact Windows identity that launched setup in pg_ident.conf, restart PostgreSQL, and rerun the installer. No reinstall needed.
Environment
-
Single VBR on Windows Server 2022 with multiple NICs for LAN and storage
-
Local workgroup admin account
-
Embedded PostgreSQL 15 for the configuration database
What I saw
During the Configuration Check I got:
Failed to connect to PostgreSQL server localhost:5432.
An existing connection was forcibly closed by the remote host
Daily jobs were fine, which told me services already had access. The installer, running under my current login, did not.
What I checked first
Live installer log
I tailed the newest SuiteEngine log to see exactly where setup stalled:
Get-Content -Wait (Get-ChildItem 'C:\ProgramData\Veeam\Setup\Temp\SuiteEngine_*' -File |
Sort-Object LastWriteTime -Descending | Select-Object -ExpandProperty FullName -First 1)
PostgreSQL baseline
I proved the database was up and listening before touching config:
# Service should be Running
# Name often looks like postgresql-x64-15
# Then confirm the listener
Test-NetConnection localhost -Port 5432
With TcpTestSucceeded : True, I focused on authentication.
The root cause I found
Embedded PostgreSQL on Windows uses SSPI with a username map. The installer account must match an entry in pg_ident.conf. My services used mapped identities, but my current login was not in the map.
The exact steps that fixed it
Step 1. Get the identity PostgreSQL actually sees
I looked in the newest PostgreSQL log:
C:\Program Files\PostgreSQL\15\data\log\
I searched for:
no match in usermap "veeam" for user "postgres" authenticated as "SOMETHING"
I also confirmed my current session:
whoami
whoami /upn
In my case the identity was:
veeambackup12\Administrator
Step 2. Confirm the auth method and mapC:\Program Files\PostgreSQL\15\data\pg_hba.conf included SSPI with the veeam map:
host all all 127.0.0.1/32 sspi map=veeam
host all all ::1/128 sspi map=veeam
Step 3. Add the mapping
I edited C:\Program Files\PostgreSQL\15\data\pg_ident.conf and appended the exact string:
veeam "veeambackup12\Administrator" postgres
If your log shows a different format, for example Administrator@HOSTNAME or DOMAIN\User, use that exact value.
Step 4. Reload and retry
I restarted PostgreSQL and ran setup again:
Restart-Service -Name 'postgresql-x64-15' -Force
The Configuration Check moved past the database step and the upgrade continued.
Quick verification
- No new
no match in usermap "veeam"entries in the latest PostgreSQL log - Veeam services started normally and jobs were visible
- SuiteEngine log advanced to the next component
If it still fails
Sometimes the installer spawns with a slightly different identity string. If I saw a new authenticated as "X" value, I added that exact line to pg_ident.conf, restarted PostgreSQL again, and retried. On hardened servers I also confirmed Windows Script Host was enabled for the setup stage.
If you want the next bit in the same style for Broker on 9501 and Threat Hunter on 6175, I can add those sections with the exact tests and fixes I used.
Second error, similar but that the root cause is the same
SSPI authentication for user postgres failed
Here’s a Community-friendly second part you can paste. It acknowledges there’s a KB, states the fix is similar to the first error, and focuses on the different troubleshooting you did. First person, concise, no links in the body, and clean code blocks.
Follow up: SSPI authentication for user postgres failed
Context
Yes, there is a KB for this. The solution is essentially the same as my first error: map the exact Windows identity in pg_ident.conf, reload PostgreSQL, and retry. What is different here is the troubleshooting path. By this point the installer was already reaching PostgreSQL on 5432, so I focused only on authentication rules and the user map.
Symptom I saw
SSPI-Authentifizierung für Benutzer „postgres“ fehlgeschlagen
Which is “SSPI authentication for user ‘postgres’ failed.”
Why this was different from Error 1
Network reachability was already proven. Test-NetConnection localhost -Port 5432 was True and services were healthy. The failure was strictly the SSPI mapping applied to my current installer session.
What I verified before changing anything
Auth rules for localhost
I confirmed PostgreSQL would actually consult the veeam map for local connections:
C:\Program Files\PostgreSQL\15\data\pg_hba.conf
Lines in place:
host all all 127.0.0.1/32 sspi map=veeam
host all all ::1/128 sspi map=veeam
Exact identity I was using
From the same elevated session I ran:
whoami
whoami /upn
In my case:
veeambackup12\Administrator
The change I made
I ensured the identity was mapped, and I kept the SYSTEM line for service operations:
C:\Program Files\PostgreSQL\15\data\pg_ident.conf
veeam "veeambackup12\Administrator" postgres
veeam "NT AUTHORITY\SYSTEM" postgres
Then I reloaded:
Restart-Service -Name "postgresql-x64-15" -Force
Quick proof before retrying setup
I validated SSPI from my current session:
& "C:\Program Files\PostgreSQL\15\bin\psql.exe" -U postgres -h 127.0.0.1 -c "select version();"
Seeing the version string confirmed the mapping was effective.
Result
I reran the installer, the database step passed, and SuiteEngine moved on. If you see a different “authenticated as …” value in the PostgreSQL log, add that exact line to pg_ident.conf, reload, and retry.
Closing note
There are two KB articles that explain how to fix both errors. This KB4542 and this one KB4543
My short write up adds what the KBs do not. How I troubleshoot them in practice, how to read what the logs are saying, and how to avoid guesswork next time. Use a live tail on SuiteEngine and the PostgreSQL log, prove service and port state, capture the exact “authenticated as” value, update the map, restart, and retry. On your next install or upgrade, start with the tail and let the evidence guide every step.
