VCF 9 Fleet Management on Cosmin.us

Fixing Expired Password Sync in VCF 9.1 Fleet Management

Cosmin Trif — Tue, 07 Jul 2026 17:30:00 +0000

In VCF 9.1, Fleet Password Management accounts can get stuck in EXPIRED status, and the password workflows changed compared to 9.0. In 9.0, you may have seen UI actions such as Disconnected or Remediate. In the 9.1 environment I was working on, those actions were not available. The UI exposed Update, and the Fleet Password Management API provides the same kind of workflow: query password accounts, then update or rotate the password.

Symptoms

The issue in this case was simple to describe but easy to chase in the wrong place:

Some password accounts showed as EXPIRED in Fleet password management.
The VCF Operations root password had already been changed outside Fleet.
The 9.1 UI did not expose the older remediation-style options, so the useful paths were the Update action for single accounts and the API for repeatable remediation.

This post walks through the recovery path I used for VCF 9.1.

What Changed in VCF 9.1 Password Management

The important realization is that VCF 9.1 Fleet Password Management does not expose a documented “store this already changed password in the vault” workflow.

The UI exposes Update for a password account. For automation or for working through a larger list of expired entries, the official API exposes:

POST /suite-api/api/fleet-management/password-management/accounts/query
PUT /suite-api/api/fleet-management/password-management/accounts/{passwordAccountKey}/password

The update workflow requires both the current password and the new password. In the API these fields are currentPassword and newPassword; in the UI they are entered through the Update action. Either way, this is a rotation workflow. If a password was already changed directly on the appliance, you need to provide that current real password and rotate once more through Fleet so the appliance password, the vault, and the expiration metadata are back in sync.

References:

Get a VCF Operations API Token

The VCF Operations API supports OpsToken authorization. Set the VCF Operations API host first:

OPS="https://<vcf-operations-fqdn>"

Note: These examples use curl -k, which skips TLS certificate verification — common in labs where the appliance still has its self-signed certificate. With -k you are sending credentials to whatever answers on that FQDN. In production, drop -k and trust the VCF Operations CA instead, for example curl --cacert /path/to/vcf-ops-ca.pem ..., or add the CA to the system trust store.

Use an account that is authorized to call the Fleet password management APIs. Avoid echoing the password back to the terminal. The read -rp / read -rsp prompts in this post use bash syntax; if your interactive shell is zsh, either start bash first or use the zsh form, for example read -rs 'VCFOPS_PASSWORD?VCF Operations password: '.

Acquire a token:

read -rp "VCF Operations username: " VCFOPS_USERNAME
read -rsp "VCF Operations password: " VCFOPS_PASSWORD; echo

TOKEN=$(jq -nc \
 --arg u "$VCFOPS_USERNAME" \
 --arg p "$VCFOPS_PASSWORD" \
 '{username:$u,password:$p}' |
 curl -sk -H 'Content-Type: application/json' -d @- \
 "$OPS/suite-api/api/auth/token/acquire" | jq -r .token)

unset VCFOPS_PASSWORD
[ -n "$TOKEN" ] && [ "$TOKEN" != "null" ] || echo "Token acquisition failed" >&2

Test the token:

curl -sk \
 -H "Authorization: OpsToken $TOKEN" \
 "$OPS/suite-api/api/versions/current" | jq .

Query Expired Password Accounts

Now query the expired password entries:

curl -sk \
 -H "Authorization: OpsToken $TOKEN" \
 -H 'Content-Type: application/json' \
 -d '{"status":"EXPIRED"}' \
 "$OPS/suite-api/api/fleet-management/password-management/accounts/query?pageSize=200" \
 | tee /tmp/expired-password-accounts.json | jq .

For a cleaner table:

jq -r '.vcfPasswordAccounts[] |
 [.appliance, .applianceFqdn, .userName, .credentialType, .expiryDate, .passwordAccountKey] |
 @tsv' /tmp/expired-password-accounts.json

I usually sort the output into a tracking table like this:

Appliance	FQDN	User	Credential Type	Action
VCF_OPERATIONS	`<vcf-operations-fqdn>`	root	SSH	Update in UI or rotate through API
SDDC_MANAGER	`<sddc-manager-fqdn>`	root	SSH	Confirm current password, then rotate
VCF_SERVICES_RUNTIME	`<vcf-services-runtime-fqdn>`	vmware-system-user	SSH	Confirm ownership before rotating

Do not blindly rotate everything at once. Some accounts may be service users, some may belong to appliances that are temporarily unreachable, and some may be stale entries for components that no longer exist. Also note that domain-level credentials such as ESXi, vCenter, and NSX are owned by SDDC Manager rather than the Fleet vault — those rotate through the SDDC Manager /v1/credentials API instead.

Update an Expired Password Account

For a single account, you can do this from the VCF Operations UI by selecting the expired password account and using Update. Enter the current working password and the new final password.

For repeatable remediation, use the API equivalent below.

One important CLI note: do not paste passwords with special characters directly into an inline curl or shell variable assignment. Passwords that contain an exclamation mark can be changed or rejected by the shell before they ever reach the API because ! may trigger history expansion in interactive shells.

If you are using Bash, disable history expansion for the session:

set +H

If you are using Zsh, disable bang history expansion:

unsetopt BANG_HIST

The safer pattern is to prompt for the password and let jq build the JSON payload.

Pick one expired entry and export the key:

KEY="<passwordAccountKey>"

Run the update call. The currentPassword must be the password that works on the target right now. The newPassword is the new final password you want Fleet to set and store.

read -rsp "Current password: " CUR; echo
read -rsp "New password: " NEW; echo

jq -nc --arg c "$CUR" --arg n "$NEW" \
 '{currentPassword:$c,newPassword:$n}' |
curl -sk -X PUT \
 -H "Authorization: OpsToken $TOKEN" \
 -H 'Content-Type: application/json' \
 -d @- \
 "$OPS/suite-api/api/fleet-management/password-management/accounts/${KEY}/password" \
 | tee /tmp/pwupdate-task.json | jq .

unset CUR NEW

The response should create a password update workflow request. Track the task in VCF Operations, or use the returned request ID if your environment exposes the workflow request endpoint.

After the task completes, query the account again. Filter by the FQDN of the appliance you just updated — it is in your tracking table or /tmp/expired-password-accounts.json — so the result does not depend on how many password accounts the fleet has:

curl -sk \
 -H "Authorization: OpsToken $TOKEN" \
 -H 'Content-Type: application/json' \
 -d '{"applianceFqdn":"<appliance-fqdn>"}' \
 "$OPS/suite-api/api/fleet-management/password-management/accounts/query?pageSize=200" \
 | jq --arg KEY "$KEY" '.vcfPasswordAccounts[] | select(.passwordAccountKey==$KEY)'

You want to see the account move out of EXPIRED and show a new expiryDate.

If the Password Was Already Changed Outside Fleet

This was the awkward case in my environment.

If the password has already been changed manually on the appliance, the Fleet vault may still have the old value. Since 9.1 does not provide a documented vault-only update, use the actual current appliance password as the current password and rotate once more to a new final password through the UI Update action or the API.

That gives Fleet a successful workflow and lets it update:

The appliance password
The stored credential
The expiration metadata
The password account status

If you want to keep the exact same password that was already set manually, that is where the product gap shows up. The documented workflow wants a change from current to new.

If the Current Password Is Unknown

If nobody knows the current password, Fleet cannot update it because the workflow requires the current password.

Use the native recovery method for that appliance first. For example:

Open the VM console.
Reset the account to a temporary known password.
Confirm SSH or console login works.
Immediately rotate from temporary to final through the UI Update action or the Fleet API.

Do not leave the temporary password as the final state. The point is to re-enter the supported Fleet workflow as quickly as possible.

If an Entry Looks Stale

Before rotating, verify that the appliance still exists and belongs to the environment:

curl -sk \
 -H "Authorization: OpsToken $TOKEN" \
 -H 'Content-Type: application/json' \
 -d '{"applianceFqdn":"<appliance-fqdn>"}' \
 "$OPS/suite-api/api/fleet-management/password-management/accounts/query?pageSize=50" \
 | jq .

Also check DNS and reachability from the shell where you are running the remediation:

getent hosts <appliance-fqdn>
curl -k -I https://<appliance-fqdn>

If the component has been removed but the password entry remains, do not delete database rows manually. Open a support case or use the supported inventory cleanup path for that component.

Verification Checklist

After the expired entries are addressed, verify the following:

The expired account query returns fewer entries, ideally zero for the scope you remediated.
Updated accounts show a refreshed expiryDate.
The password update workflow completed successfully.
Direct login to the target appliance works with the new password.

Query all remaining expired entries:

curl -sk \
 -H "Authorization: OpsToken $TOKEN" \
 -H 'Content-Type: application/json' \
 -d '{"status":"EXPIRED"}' \
 "$OPS/suite-api/api/fleet-management/password-management/accounts/query?pageSize=200" \
 | jq '.vcfPasswordAccounts'

Finally, clean up the working files, since they contain fleet inventory details such as appliance FQDNs, usernames, and password account keys:

rm -f /tmp/expired-password-accounts.json /tmp/pwupdate-task.json

Final Notes

The main lesson is that VCF 9.1 password management needs to be treated as an update or rotation workflow. The password account state is exposed through VCF Operations Fleet Password Management, and expired entries need to be handled through the UI Update action or the documented account query and password update API calls. This is the same rotate-only philosophy the platform has had since the vRSLCM Locker password management days — the tooling changed, the workflow shape did not.

For this kind of issue, I would avoid two shortcuts:

Do not use VCF 9.0 UI guidance for VCF 9.1.
Do not update Fleet LCM database rows by hand.

The reliable path is to update expired accounts through the UI or API and verify the resulting password account state.

Scripted Components Cleanup from VCF Operations 9.1: A Step-by-Step Guide

Cosmin Trif — Wed, 03 Jun 2026 10:30:00 +0000

If you’ve been working with VCF Operations 9.1, you may have noticed that on the Build > Lifecycle > VCF Management > Components page, manually-added components such as VCF Operations for Networks, Log Management, Real-Time Metrics or VCF Automation no longer have a “Delete” option available in the UI.

In VCF Operations 9.0, this was possible on the Fleet Management > Lifecycle > Components page by clicking the three vertical dots next to a component and selecting Delete. That option is gone in 9.1.

Broadcom has published KB article 441333 with an attached Python script (cleanup_component.py) that fills this gap. In this post I walk through how to use it for each component type.

Prerequisites

Before running the cleanup script, make sure the following are in place:

Python installed on the system where you will run the script (can be any system with network access to the Fleet and VCF Management Services components).
Network access to the Fleet LCM appliance and VCF Services Runtime.
Credentials — use username admin as the value for the VCF Services Runtime username. The password is the same as the vmware-system-user password.
FQDN values — replace all placeholder FQDNs such as <fleet-lcm-fqdn> with the actual values. These can be obtained from VCF Operations UI -> Build -> Lifecycle -> VCF Management -> Components (e.g., vsp01.example.com for <vcf-services-runtime-fqdn>).

Warning: Prior to deletion, verify that you have a backup of any critical component data which needs to be retained, such as logs or database backups.

Download and Verify the Script

Download cleanup_component.py from KB 441333 (attached at the bottom of the article).

Verify the SHA256 checksum before running:

sha256sum cleanup_component.py

Expected checksum:

27A82D393333D17261EF1E8629A69AD6C40659A8537DF961DE95E545FE656F5B

What the Script Does

The LCM component cleanup script enables administrators to manage Day-N deployed components visible in the VCF Operations UI:

List components — View all deployed components currently eligible for removal.
Delete components — Safely remove inoperable or misconfigured components from the system so they can be redeployed later through VCF Operations.

Important notes:

If a component is running a version older than 9.1, it is removed solely from the Fleet lifecycle. The script does not delete the corresponding infrastructure deployments such as vCenter or VCF Services Runtime.
VSP refers to VCF Management Services.

1. OVA Components

Deleting an OVA-based deployment removes it from Fleet lifecycle and also deletes the associated virtual machines from vCenter.

List Components Deployed on vCenter

python cleanup_component.py list ova-component --fleet-fqdn <fleet-lcm-fqdn> --vcf-services-runtime-fqdn <vcf-services-runtime-fqdn> --vcf-services-runtime-username <vcf-services-runtime-username>

Delete Component Deployed on vCenter

python cleanup_component.py delete ova-component --component-id <ova-component-id> --fleet-fqdn <fleet-lcm-fqdn> --vcf-services-runtime-fqdn <vcf-services-runtime-fqdn> --vcf-services-runtime-username <vcf-services-runtime-username> --vcenter-username <vcenter-username>

The script will prompt for the required passwords. Once confirmed, the OVA component will be removed from Fleet lifecycle and its associated VMs deleted from vCenter.

2. VCF Management Services (VSP) Components

Deleting a VSP-based deployment removes it from Fleet lifecycle and also deletes the associated deployment from VCF Services Runtime.

List Components Deployed on VCF Services Runtime

python cleanup_component.py list vsp-component --fleet-fqdn <fleet-lcm-fqdn> --vcf-services-runtime-fqdn <vcf-services-runtime-fqdn> --vcf-services-runtime-username <vcf-services-runtime-username>

Delete Component Deployed on VCF Services Runtime

python cleanup_component.py delete vsp-component --component-id <vsp-component-id> --fleet-fqdn <fleet-lcm-fqdn> --vcf-services-runtime-fqdn <vcf-services-runtime-fqdn> --vcf-services-runtime-username <vcf-services-runtime-username>

3. VCF Automation

VCF Automation is a multi-component deployment consisting of:

VCF Automation
Migration Service Engine
VCF Automation VCF Services Runtime

Important: You must remove VCF Automation and the Migration Service Engine before you remove the VCF Automation VCF Services Runtime. Follow the order below.

Step 1: Remove VCF Automation and Migration Service Engine

List Components Deployed on VCF Services Runtime

python cleanup_component.py list vsp-component --fleet-fqdn <fleet-lcm-fqdn> --vcf-services-runtime-fqdn <vcf-services-runtime-fqdn> --vcf-services-runtime-username <vcf-services-runtime-username>

Delete Component Deployed on the VCF Automation VCF Services Runtime

python cleanup_component.py delete vsp-component --component-id <vsp-component-id> --fleet-fqdn <fleet-lcm-fqdn> --vcf-services-runtime-fqdn <vcf-services-runtime-fqdn> --vcf-services-runtime-username <vcf-services-runtime-username> --vcfa-vcf-services-runtime-fqdn <vcfa-vcf-services-runtime-fqdn> --vcfa-vcf-services-runtime-username <vcfa-vcf-services-runtime-username>

Run the delete command for both the VCF Automation component and the Migration Service Engine component before proceeding to Step 2.

Step 2: Remove the VCF Automation VCF Services Runtime

Warning: Deleting a VCF Services Runtime requires this script to be executed as the root user inside the SDDC Manager virtual machine.

List VCF Services Runtime

python cleanup_component.py list vsp-cluster --fleet-fqdn <fleet-lcm-fqdn> --vcf-services-runtime-fqdn <vcf-services-runtime-fqdn> --vcf-services-runtime-username <vcf-services-runtime-username>

Delete VCF Services Runtime

python cleanup_component.py delete vsp-cluster --component-id <vsp-cluster-id> --fleet-fqdn <fleet-lcm-fqdn> --vcf-services-runtime-fqdn <vcf-services-runtime-fqdn> --vcf-services-runtime-username <vcf-services-runtime-username> --vcenter-username <vcenter-username>

Summary

The cleanup_component.py script is a handy workaround for the missing “Delete” option in VCF Operations 9.1. The key things to remember:

Back up any critical component data before running delete operations.
For OVA components, deletion also removes VMs from vCenter.
For VSP components, deletion also removes the deployment from VCF Services Runtime.
For VCF Automation, always delete VCF Automation and Migration Service Engine first, then delete the VCF Services Runtime — and run that last step as root on the SDDC Manager VM.
Always verify the script checksum before running it.

After removing components, also check Fleet password management for leftover or expired password accounts — I covered that remediation in Fixing Expired Password Sync in VCF 9.1 Fleet Management.

For the official script download and additional details, refer to Broadcom KB article 441333.

I hope this helps!

Deploying VCF Fleet Management 9 from OVA: A Step-by-Step Guide

Cosmin Trif — Thu, 09 Oct 2025 13:04:27 +0000

Deploying the VCF Fleet Management (Operations / Fleet Manager) appliance using an OVA is a common approach when standing up a new VMware Cloud Foundation (VCF) 9 environment or re-deploying the component. Below is a refined guide covering the deployment, configuration, and integration steps.

1. Prerequisites & Downloading Binaries

Before you deploy the OVA:

Log into the Broadcom Support Portal and obtain the required binaries and OVA files for the Fleet Manager. Direct link can be found here.

Ensure DNS, IP addresses, and network configurations for the appliance are defined (fully qualified domain name, subnet, gateway, DNS servers, etc.).
Ensure your vCenter / ESXi environment meets the compatibility and resource requirements (CPU, RAM, storage).
Map the hostname, IP, and other parameters you’ll use for the Fleet Manager appliance.

2. Deploy the OVA via vCenter

In vCenter, choose Deploy OVA (or OVF template).
Select the Fleet Manager OVA file (downloaded from the portal).

Provide a VM name and select the inventory location (folder, cluster, or host).

Choose the compute resource (ESXi host or cluster) for placement.

Review the details and click Next.

Select the target storage (datastore) for the VM’s disks.

Choose the network(s) to attach the appliance.

When prompted, fill in the customization metadata:
- Root / admin passwords
- FQDN / hostname
- IP address, subnet mask, gateway
- DNS server(s), domain name
- NTP server(s)

Review the settings and click Finish to deploy the OVA.

Power on the appliance once deployment completes.

3. Initial Configuration & Connection

Access the Operations appliance UI admin interface via its FQDN (e.g. https://<fleet-mgr-fqdn/admin>) in a browser.
In the UI, go to the Fleet Management or Connect tile.

Enter the IP / FQDN and admin credentials for the new appliance, then test the connection.
Accept any SSL / certificate warnings as needed.

Supply credentials for your primary VCF Operations node (or cluster).

Wait for a couple of minutes, the Fleet Management box should reflect as Connected

4. Import / Add Existing Components

Once Fleet Manager is reachable, the next steps are to integrate it with any existing Operations / Logs instances:

Go to Operations user interface -> Fleet Management -> Lifecycle -> VCF Management -> Under operations click Import. this should start a task

Provide the credentials, FQDN, and vCenter info. Submit the job.

Review the details and click submit. This will start a task to import VCF Operations under management.

5. Configure the Depot & Deploy VCF Automation (Optional Next Step)

In the UI, configure the Depot / Binary Management settings (online or offline depot).
After the depot is set up and binaries are synchronized, you can use the UI to deploy VCF Automation, the next piece of your stack.

6. Verification & Post-Deployment Checks

In Lifecycle → Overview / Components, confirm that Operations and Fleet Manager show successful integration.
Check connectivity, dashboard health, metrics, and logs to ensure no errors or warnings.
Verify that future Lifecycle / patching tasks are visible and manageable under this new Fleet Manager hierarchy.

Upgrading VCF 9.0.0 Fleet Management to 9.0.1: A Step-by-Step Guide

Cosmin Trif — Thu, 09 Oct 2025 12:49:44 +0000

Upgrading your VCF Fleet Management from version 9.0.0 to 9.0.1 is a relatively modest patch update, but careful execution ensures minimal disruption. Below is a step-by-step guide to walk you through the process safely.

Download the Patch

Download the patch by going to Fleet Management -> Binary Management -> Patch Binaries -> Select fleet management -> Download.

Upload & Stage the Patch

Once the download is complete go to Settings -> System Patches -> New Patch

Select the Patch that was just downloaded and click Next to proceed

Review the release notes and click Install

This will create a Task that patches the appliance. Click Return to Tasks

Wait & Confirm

Allow several minutes for the task to complete. Do not interrupt the process. Once the patch job is finished, go to the Settings tab and verify that the Fleet Management component now shows 9.0.1.

The SDDC Manager side of the 9.0.1 patch is covered in this guide, and if PostgreSQL won’t start after a reboot on 9.0.1, see this fix.

Fixing “PostgreSQL won’t start after reboot” on VCF Operations Fleet Management 9.0.1 — and automating it

Cosmin Trif — Tue, 30 Sep 2025 21:23:32 +0000

When upgrading the VCF Operations Fleet Management appliance to 9.0.1, you might hit a reboot surprise: vPostgres fails to start, and the fleet-management certificate is regenerated. You’ll see journal errors like:

pg_ctl: could not open PID file "/var/vmware/vpostgres/current/pgdata/postmaster.pid": Permission denied
systemd[1]: vpostgres.service: Control process exited, code=exited, status=1/FAILURE

Broadcom’s KB confirms the symptoms and provides the manual steps to fix permissions on the Postgres data dir and to normalize the regenerated cert/key filenames, followed by service restarts. If you are also moving the analytics side to the same release, I covered upgrading VCF Operations to 9.0.1 using a .PAK file separately.

(manual steps)

Fix pgdata permissions

chmod 700 /var/vmware/vpostgres/current/pgdata/

Normalize the regenerated certificate & key in /opt/vmware/vlcm/cert by renaming the timestamped server.crt.* / server.key.* back to server.crt / server.key, then restart services (nginx, vrlcm-server.service) and verify status/logs.

One-shot automated remediation (idempotent)

Run this as root on the Fleet Management appliance (e.g., via SSH). It:

Fixes the Postgres data directory permissions
Backs up any existing certs
Picks the newest timestamped server.crt.* and server.key.* and makes them active
Ensures sane file permissions
Restarts nginx and vrlcm-server.service
Shows health checks + log tail hints

#!/usr/bin/env bash
# vcf-ops-fleet-901-postgres-cert-fix.sh
# Automates KB 412351 remediation on VCF Operations Fleet Management 9.0.1
# Source: https://knowledge.broadcom.com/external/article/412351

set -euo pipefail

LOG="/var/log/vrlcm/vmware_vrlcm.log"
PGDATA="/var/vmware/vpostgres/current/pgdata"
CERT_DIR="/opt/vmware/vlcm/cert"
BACKUP_DIR="${CERT_DIR}/backup-$(date +%Y%m%d-%H%M%S)"

echo "[*] Ensuring Postgres data dir permissions (700) …"
if [ -d "$PGDATA" ]; then
 chmod 700 "$PGDATA"
 echo "[+] chmod 700 ${PGDATA} done"
else
 echo "[!] ${PGDATA} not found; continuing…"
fi

echo "[*] Working in ${CERT_DIR} …"
cd "$CERT_DIR" || { echo "[!] ${CERT_DIR} not found"; exit 1; }

# Back up current active certs (if any)
mkdir -p "$BACKUP_DIR"
for f in server.crt server.key; do
 if [ -f "$f" ]; then
 cp -a "$f" "${BACKUP_DIR}/"
 echo "[+] Backed up $f to ${BACKUP_DIR}/"
 fi
done

# Find newest timestamped variants
NEWEST_CRT="$(ls -1t server.crt.* 2>/dev/null | head -n1 || true)"
NEWEST_KEY="$(ls -1t server.key.* 2>/dev/null | head -n1 || true)"

if [ -z "$NEWEST_CRT" ] || [ -z "$NEWEST_KEY" ]; then
 echo "[!] Could not find timestamped server.crt.* and/or server.key.* files."
 echo " If the KB's certificate regeneration occurred, these should exist. Aborting."
 exit 1
fi

echo "[*] Activating newest certificate and key:"
echo " CRT: ${NEWEST_CRT}"
echo " KEY: ${NEWEST_KEY}"

# Move into place atomically
cp -a "$NEWEST_CRT" server.crt
cp -a "$NEWEST_KEY" server.key

# Tighten permissions
chmod 600 server.key || true
chmod 644 server.crt || true

# Optionally set ownership if required by your distro:
# chown root:root server.crt server.key

echo "[*] Restarting services (nginx, vrlcm-server.service) …"
systemctl restart nginx
systemctl restart vrlcm-server.service

echo "[*] Waiting 10s and checking status …"
sleep 10
systemctl --no-pager --full status vrlcm-server.service | sed -n '1,50p' || true

echo
echo "[i] Tail the Lifecycle Manager log for readiness:"
echo " tail -f ${LOG}"
echo
echo "[✓] Remediation attempted. If issues persist, also verify vpostgres status:"
echo " systemctl status vpostgres.service"

Save this as vcf-ops-fleet-901-postgres-cert-fix.sh, then:

sudo bash vcf-ops-fleet-901-postgres-cert-fix.sh

Why not rename with mv? Using cp -a keeps the timestamped copies intact (for quick rollback) while still placing active server.crt / server.key in the expected paths.

Verification checklist

systemctl status vrlcm-server.service shows active (running).
UI/API flows that depend on Lifecycle Manager respond normally.
Optional: confirm vpostgres.service is active (running) and that the PID file error is gone.
tail -f /var/log/vrlcm/vmware_vrlcm.log shows normal startup without repeated cert/permission complaints.

FAQ

Q: Does this script change ownership of certs?

A: The KB doesn’t require ownership changes—only renaming the timestamped files and restarting services. The script tightens file perms (600 for key, 644 for cert) which is generally safe. Adjust ownership in environments with stricter policies.

Q: Can I safely re-run the script?

A: Yes. It’s idempotent: it always selects the newest timestamped cert/key, backs up existing actives, and restarts services.

Q: Why fix Postgres permissions?

A: The KB explicitly calls for chmod 700 on the Postgres pgdata directory to resolve the PID file “Permission denied” during startup.

References

Broadcom KB 412351 — “PostgreSQL Service fails to start after rebooting Fleet Management appliance post VCF Operations 9.0.1 upgrade” (symptoms, manual steps, service restarts).