How to Export Auto-Generated Passwords to CSV in VCF 9.1

Introduction

Introduction

When deploying VMware Cloud Foundation (VCF) 9.1, the VCF Installer automatically generates passwords for various infrastructure components. These credentials are essential for managing and maintaining your VCF environment.

After successfully completing the deployment through the VCF Installer UI, you have the option to view and download these auto-generated passwords before finishing the deployment workflow and accessing VCF Operations.

But what happens if you forget to download the passwords?

Fortunately, the credentials can still be retrieved after deployment. To make this process easier, I created a script that exports the usernames and passwords from the SDDC Manager appliance(VCF-Installer) into a CSV file that can be imported into KeePass Password Safe.

What Happens to the VCF Installer After Deployment?

One interesting change in VCF 9.1 is how the VCF Installer operates after completing the deployment.

Instead of remaining a separate virtual appliance, the VCF Installer transitions into the SDDC Manager component. This eliminates the need for an additional virtual machine while preserving access to deployment information.

By default, opening the SDDC Manager FQDN in your browser redirects you to the SDDC Manager user interface.

However, the VCF Installer UI remains accessible through a specific URL.

For example:

https://sddcm01.vcf.lab/vcf-installer-ui/

Simply replace sddcm01.vcf.lab with the FQDN of your own SDDC Manager appliance.

This allows you to revisit the VCF Installer interface and access deployment-related information, including the auto-generated credentials, subject to the permissions and functionality available in your environment.

Exporting Auto-Generated Passwords

Although the VCF Installer provides an option to download the generated passwords, I wanted a more convenient way to organize these credentials.

Manually copying usernames and passwords into a password manager can be time-consuming, especially when managing multiple VCF deployments.

To simplify this process, I created a script that:

1.Retrieves the auto-generated usernames and passwords from the SDDC Manager appliance.
2.Organizes the credentials into a structured format.
3.Exports the information to a CSV file.
4.Prepares the CSV file for importing into a KeePass password database.

This makes it easier to store and manage your VCF infrastructure credentials in one central location.

Importing the Credentials into KeePass

Once the script has generated the CSV file, you can import the credentials into KeePass.

The goal is to avoid manually creating individual entries for every VCF component.

Depending on the CSV structure, the imported entries can include the component name, username, and password.

After importing the credentials, you can organize them into groups within your KeePass database.

Security consideration: The exported CSV file contains sensitive credentials in plain text. Store it only in a secure location, restrict access to authorized administrators, and securely remove temporary copies after verifying that the credentials have been imported successfully into KeePass.

Conclusion

Forgetting to download the auto-generated passwords after a VMware Cloud Foundation 9.1 deployment does not necessarily mean those credentials are lost.

Because the VCF Installer remains accessible through the SDDC Manager appliance, administrators can revisit deployment information and potentially retrieve the generated credentials.

With my export script, I wanted to make this process even easier by converting the credentials into a CSV file suitable for importing into KeePass.

This provides a convenient way to organize and securely manage the credentials required for your VCF infrastructure.

Download the Script

The script and additional instructions will be available on my GitHub repository.

https://github.com/WardVissers/VCF-Public/blob/main/Get-VcfOpsDeploymentSpec.ps1

Disclaimer: This script is intended for authorized administrators managing their own VMware Cloud Foundation environments. Always follow your organization’s credential-management and security policies.

 

.

How to Set Up a Powerful Offline Ubuntu Depot for VCF 9.1

I had my first build from Offline Depot. Here is the link: https://www.wardvissers.nl/2025/11/10/upgrade-vcf-to-9-0-1-setting-up-an-offline-depot-on-ubuntu/.

So it was time for a revision.

Prerequisites

First, download the required bundle files from Offline Depot. This includes the enterprise components you need.

• vcf-download-tool-9.1.1.0.25713929.tar

The Offline Depot runs on Ubuntu on the Depot Server.

Sizing for the disk is 70GB of Offline Depot OS files.

Offline Depot provides 1 TB for data files and /Data.

Login


Login with the user account that you create


Sudo passwd root


Vim /etc/ssh/sshd_config


 if the following line exists, possibly commented out (with a # in front):


PermitRootLogin


Then change it to the following, uncommenting if needed (remove the # in front):


PermitRootLogin yes


sudo service ssh restart


now you can login as root


Install Apache and tools


Sudo update


sudo apt install apache2 openssl apache2-utils unzip


Create a certificate config file


nano ~/vcf-openssl.cnf


Paste the following:


[ request ]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn
x509_extensions = v3_req
[ dn ]
C = US
ST = CA
L = LA
O = TS
OU = IT
CN = flt-depot.wardhomelab.nl
emailAddress = ab.c
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = flt-depot.wardhomelab.nl
IP.1 = 192.168.150.246


Replace the values with your organization’s details.


Generate the certificate


cd /etc/apache2
sudo mkdir ssl


sudo openssl request -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/vcf.key -out /etc/apache2/ssl/vcf.crt -config /etc/apache2/ssl/vcf-openssl.cnf


Create a basic auth user


Sudo htpasswd -c /etc/apache2/.htpasswd vcfadmin


Configure Apache


sudo nano /etc/apache2/sites-available/default-ssl.conf


Paste the following:


<VirtualHost *:443>


    ServerAdmin webmaster@localhost


    DocumentRoot /data/html


# SSL


    SSLEngine on


    SSLCertificateFile /etc/apache2/ssl/vcf.crt


    SSLCertificateKeyFile /etc/apache2/ssl/vcf.key


    SSLProtocol -all +TLSv1.2 +TLSv1.3


    SSLHonorCipherOrder On


    SSLCompression Off


# Main VCF Depot


<Directory /data/html>


Options Indexes FollowSymLinks


        AllowOverride None


        AuthType Basic


        AuthName “VCF Depot”


        AuthUserFile /etc/apache2/.htpasswd


Require valid-user


</Directory>


# VCF Components


<Directory /data/html/PROD/COMP>


        AuthType Basic


        AuthName “VCF Depot”


        AuthUserFile /etc/apache2/.htpasswd


Require valid-user


</Directory>


# VCF Metadata


<Directory /data/html/PROD/metadata>


        AuthType Basic


        AuthName “VCF Depot”


        AuthUserFile /etc/apache2/.htpasswd


Require valid-user


</Directory>


# VxRail VVS Cookie Validation


<Directory /data/html/PROD/COMP/Compatibility>


<Files “VxrailCompatibilityData.json”>


<If “%{HTTP:Cookie} == ‘session=ngsso-token'”>


Require all granted


</If>


</Files>


</Directory>


# vSAN HCL – no authentication required


<Directory /data/html/PROD/vsan/hcl>


Require all granted


</Directory>


# Required for VCF 5.1.0.0


Alias /products/v1/bundles/lastupdatedtime /data/html/PROD/vsan/hcl/lastupdatedtime.json


Alias /products/v1/bundles/all /data/html/PROD/vsan/hcl/all.json


# UMDS patch store – no authentication required


<Directory /data/html/umps-patch-store>


Options Indexes FollowSymLinks


        AllowOverride None


Require all granted


</Directory>


.


</VirtualHost>


Enable modules and restart Apache


sudo a2enmod ssl headers


sudo a2ensite default-ssl


sudo systemctl restart apache2


Extract the metadata ZIP


Sudo chmod 777 /data


Upload vcf-9.0.1.0-offline-depot-metadata.zip /data/ with Winscp


Sudo unzip vcf-download-tool-9.1.1.0.25713929.tar -d /data


Create your Download token


Create your Download token in the Broadcom portal


Create a token file in /home folder


Upload the VCF download tool


Upload the tool in /data folder


tar -xf vcf-download-tool-9.1.1.0.25713929.tar.tar.gz


Sudo chmod 755 /data/vcf-download-tool-9.1.1.0.25713929


.


sudo reboot


Run the following


cd/data/vcf-download-tool-9.1.1.0.25713929/bin/


./vcf-download-tool configuration generate –software-depot-id


.


# Versions download


List the latest install components


./vcf-download-tool binaries list –sku VCF –vcf-version 9.1.1 –depot-download-activation-code-file /data/activation-code.txt –type INSTALL –automated-install


Download the latest install components


./vcf-download-tool binaries download –sku VCF –vcf-version 9.1.1 –depot-download-activation-code-file /data/activation-code.txt –type INSTALL –automated-install –depot-store /data/html


.


List the latest Upgrade components
./vcf-download-tool binaries list –sku VCF –vcf-version 9.1.1 –depot-download-activation-code-file /data/activation-code.txt –type UPGRADE


.


Download the latest upgrade components
. /vcf-download-tool binaries download –sku VCF –vcf-version 9.1.1 –depot-download-activation-code-file /data/activation-code.txt –type UPGRADE –depot-store /data/html


.


List not the latest components


./vcf-download-tool binaries list –sku VCF –vcf-version 9.1.1 –depot-download-activation-code-file /data/activation-code.txt –latest=false –type UPGRADE


Download not the latest components


./vcf-download-tool binaries download –sku VCF –vcf-version 9.1.1 –depot-download-activation-code-file /data/activation-code.txt –latest=false –type UPGRADE –depot-store /data/html


.


ESX Download


./vcf-download-tool esx configuration -G


./vcf-download-tool esx configuration \
-D embeddedEsx-6.7-INTL \
-D esxio-9.1-INTL \
-D armEsx-9.1-INTL \
-D embeddedEsx-8.0-INTL \
-D embeddedEsx-7.0-INTL \
-D embeddedEsx-9.0-INTL \
-D esxio-8.0-INTL \
-D esxio-9.0-INTL


./vcf-download-tool esx configuration -G


./vcf-download-tool esx download –depot-download-activation-code-file /data/activation-code.txt –depot-store /data/html





.

More Memory, Less Money: Exploring Memory Tiering in VCF 9

My VCF 9 lab is getting bigger and bigger. I still need more and more resources.
I have not even running vDefend or AVI.

Currently, VCF services run with high availability even in my small lab.
The investment that I did is paying out.

VCF 9 supports memory tiering. Which is great because of these memory prices. Buying memory is not fun anymore. Because the modules that i want are not even produced anymore.

Memory tiering through NVMe drives is 2/3 cheaper than buying memory that is not produced anymore.

It works great. I still have some testing to do with Windows VM’s.


.

Note: Memory tiering works over time not directly!!

.

.

.

.

.

VCF 9.1 Enable High Availability for a Small VCF Deployment for VCF Management Services (VCFMS)

I still working on my shutdown en startup script for VCF 9.1

Because it is a small lab you have only 1 control plane and 3 workers.
A option to have second control plane vm would be nice for easier recovery.


Then I read about: William Lam: VCF 9.1 – Enabling High Availability for a Small VCF Management Services (

VCF

) Deployment

Tried it:

Checked operations.

Checked vCenter

I have now also logs running in VCF management services.
Go back to a single control plane is the same way disable HA.

When I have some time i want to test: Leaha’s Blog: VCF 9 Management Services Lab Downsize

VCF 9.1 Critical JV Certificate Caching Bug Can Cause Silent Outage

A field experience with VCF Operations and Fleet Lifecycle Management

The problem I encountered

Over the last few weeks, I encountered a strange issue in VMware Cloud Foundation 9.1. The Build > Software and Build > Lifecycle functionality was no longer working correctly.

Figure 1. Lifecycle functionality failing in the VCF interface.

My first thought was that something had gone wrong with the VCF Services Runtime control plane. I did not immediately know why it had failed, and unfortunately I did not have a VM-level backup of the VCF Services virtual machines available.

After investigating the symptoms, I suspected that I had run into a VCF 9.1 certificate-related bug.

Update: critical certificate caching issue

VCF 9.1 contains a critical issue in which the Java Virtual Machine (JVM) caches an internal security certificate during the initial bootstrap.

Issue details

Although the system correctly rotates the certificate in the background, the application does not dynamically reload the renewed certificate. Because these certificates have a strict 90-day validity period, environments deployed at General Availability (May 12, 2026) can begin experiencing silent outages around August 10, 2026.

Impact

The failure can occur without advance health-check warnings. Once the 90-day certificate threshold is reached, the environment may experience:

• Generic “503 Service Unavailable” errors
• Loss of access to affected UI functionality and blockage of component deployments
• Failure of day-two operations within Fleet Lifecycle Management (Fleet LCM)

What this looked like in my environment

In my case, the symptoms appeared in the VCF Build and Lifecycle areas and initially looked like a failure of the VCF Services Runtime control plane. The certificate-caching issue provides a plausible explanation for this behavior.

Action required

 

If you are running VCF 9.1, review the relevant Broadcom Knowledge Base articles and apply the documented workaround for the affected component. The source document identifies the following KB topics:

Takeaway

A certificate can be successfully rotated on the platform while an application continues using an older certificate cached by its JVM. That makes this issue particularly difficult to recognize: certificate rotation may appear healthy even though application communication eventually starts failing.

For VCF 9.1 environments approaching or exceeding 90 days since deployment, certificate-related TLS errors and unexplained 503 responses should therefore be investigated promptly.

What Changed in VCF LOG Deployment with 9.1.0.400

Platform changes since VCF 9.1.0.400

Since VCF 9.1.0.400, a lot has changed in the platform.

One of the more noticeable shifts is how log management works.

It now runs as a service inside the VCF Management Services Cluster. This is the same Kubernetes-based runtime that also hosts Fleet Management and the other core management components.

Additionally, in this blog I walk through how to deploy VCF Log Management in 9.1.0.400.

What Changed

Log Management changes in VCF

In VCF 9.0 and earlier, Log Management (formerly Aria Operations for Logs) was deployed as its own appliance VM. It also used a separate appliance cluster for management and access.

Additionally, from 9.1.0.400 onward, it is a built-in, containerized core service that runs natively on the VCF Management Services Platform. The deployment has changed the way configuration, access control, and alerting are managed.

Deployment, lifecycle management, configuration, access control, and alerting are now handled centrally through VCF Operations. This replaces the prior model of using a separate product UI.

Prerequisites

• DNS: A DNS-registered FQDN (with both forward and reverse lookup working)
• Capacity in the VCF Services Runtime: Deploying Log Management can trigger an automatic resize of the underlying Kubernetes cluster, so plan for the additional compute ahead of time.
• Sizing decision: The deployment size you choose determines how much compute and storage each node gets.
• Networking: Deployment currently supports VLAN-backed networks for the VCF Management Services; overlay networking is not yet supported for this component.

Resource Requirements for Log Management Deployments.

Size

vCPUs per Node

Memory per Node

Storage per Node

Number of Nodes

Small

8

16 GB

575 GB

1-19

Medium

24

48 GB

575 GB

3-19

Large

32

64 GB

575 GB

3-19

Procedure

1.Log in to the VCF Operations user interface at https://<vcf_operations_fqdn
2.Navigate to Build Lifecycle VCF Management.
3.On the Components tab, select Add Component Log management and configure the parameters for the deployment.


Now click Next to proceed to the Summary page for final review before deployment. Click Finish to start the deployment. As soon as the Deployment is done, you will see Log Management is running under VCF Operations -> Build -> Lifecycle.

Additionally, you can find the logs under VCF Operations -> Operate -> Log..

If you click on Log Sources, you will get an overview of the currently configured integrations, but this does not mean, that the Log collection itself is enabled.

Additionally, navigate to VCF Operations -> Operate -> Administration -> Configurations -> Log Collection to check Status within the system interface. Follow the on-screen prompts to reach the Status view and confirm whether logging is active or paused, so you can verify the current configuration.

However, under Status, the Log collection is not enabled.

If you click on the “i” under Status you will see:

This is strange in my opinion, but yes, you must switch back to the Integrations page in VCF Operations.

Additionally, proceed to edit your VMware Cloud Foundation Account from there, where the status changed, under Operate, Administration, Integrations.

From the Account page switch to Domains:

Next, on the Domain Page, start with vCenter to activate Logs Collection by clicking ‘Activate Log Collection’ and SAVE.

Same procedure i.e. NSX:

Additionally, after activation of Log collection you will see more Logs inside VCF Operations:


.

Next, go to VCF Operations Operate Administration Configuration Log Collection. Next, click Edit and scroll down.

Additionally, enable (Edit Log collection configuration).

.

Essential Lessons from a Minimal 2-Node VCF 9 Deployment

2 node vcf 9 deployment

After three great VMUG sessions in Amsterdam, online, and VMUGNL Summer Sessions, I received requests to share the slides.

The talks cover the session 2 node vcf 9 deployment, showing what you can learn from a minimum resources lab.

The response was great.

Additionally, in the slide deck, you will find the items.

The Start of My VCF Story marks the journey into practical creation and evaluation. It begins with a clear objective to explore a 2 node vcf 9 deployment in a real-world setting, testing how components interact under load and how failures are detected and recovered. This early phase framed every subsequent decision.

The first challenge was understanding core VCF concepts and practical limits, then translating them into a workable build plan. I weighed licensing, hardware, and timing constraints, while documenting assumptions so the team could reproduce results. Throughout, the focus remained on reliable deployment patterns rather than theoretical ideas.

The Road ahead combined hands-on testing, documentation, and stakeholder reviews to align goals and timelines. From these efforts, I learned practical lessons about resilience, observability, and change control, which shaped next steps for improving the process. I will continue refining configurations and sharing findings to guide future deployments.

VCF 9.1 How to Safely Shut Down the Services Runtime Cluster Using PowerShell

Broadcom provides an official procedure for gracefully shutting down a VMware Cloud Foundation (VCF) 9.1 Services Runtime cluster. The provided solution uses a Linux shell script (vcf_services_runtime_shutdown.sh), which works well on Linux systems but is less convenient for Windows administrators.

Rather than using Windows Subsystem for Linux (WSL) or a separate Linux machine, I converted the official shell script into a native PowerShell version. This allows the entire shutdown procedure to be executed directly from a Windows workstation while following the same workflow as the original Broadcom script.

Downloads

📦 VCF 9.1 Shutdown VCF Services VMs.ps1
📦 vcf_services_runtime_shutdown.ps1

📄 Original Broadcom Knowledge Base vcf_services_runtime_shutdown.sh

Why Use the Official Shutdown Procedure?

• Kubernetes workloads are gracefully terminated.
• Running services are stopped in the correct order.
• Databases remain in a consistent state.
• Cluster metadata is preserved.
• The shutdown process completes without leaving services in an inconsistent state.

Prerequisites

• VMware Cloud Foundation 9.1
• PowerShell 7.x (recommended)
• Latest VCF PowerCLI
• vCenter Administrator credentials
• Network connectivity to the Control Plane node

Before You Begin

• Power off any VCF Automation virtual machines before shutting down the Services Runtime cluster to avoid interference with automation tasks.

Determine the Control Plane Node IP Address

• Open VCF Operations.
• Navigate to Build → Lifecycle → Components.
• Select VCF Services Runtime.
• Scroll to the Nodes section.
• Locate a Control Plane node and note its IP address.

PowerShell Wrapper Script

• Detects the current script location.
• Changes to the correct working directory.
• Calls the shutdown script with the required parameters.
• Simplifies execution.

Download Wrapper Script

➡ Download: Shutdown VCF Services.ps1

# VCF Services shutdown by Ward Vissers

# Variables

switch ((get-host).Name) {

‘Windows PowerShell ISE Host’ { $vcf_folder = $psISE.CurrentFile.FullPath -replace ($psISE.CurrentFile.DisplayName,””) }

‘ConsoleHost‘ { $vcf_folder = $myInvocation.MyCommand.Path -replace ($myInvocation.MyCommand.Name,”“) }

‘Visual Studio Code Host‘{ $vcf_folder = $psEditor.GetEditorContext().CurrentFile.Path | Split-Path }

}

# Go to the VCF folder

Set-Location $vcf_folder

$Credential = Get-Credential –UserName “administrator@vsphere.local” -Message “vCenter Login Creds”

# Shutdown Test Run

.\vcf_services_runtime_shutdown.ps1 –DryRun –NodeIp <your_node_here> –Credential $Credential

# Shutdown Run

.\vcf_services_runtime_shutdown.ps1 –DryRun –NodeIp <your_node_here>  –Credential $Credential

Authenticate Securely

• Use Get-Credential instead of storing passwords in the script.

Perform a Dry Run

• Run the script with -DryRun to validate connectivity, authentication, environment configuration and cluster discovery without shutting down services.

.

Execute the Shutdown

• Connect to vCenter.
• Discover the Services Runtime cluster.
• Validate runtime nodes.
• Gracefully terminate Kubernetes workloads.
• Shut down runtime nodes.
• Verify successful completion.

Expected Result

• All VCF Services Runtime virtual machines are powered off in the correct order and the console reports a successful shutdown.

.

.

Conclusion

The PowerShell implementation follows the same workflow as Broadcom’s Linux script while allowing Windows administrators to perform the shutdown natively from Windows without WSL.

What’s Next?

• Automated startup & shutdown script for VCF 9.1 environment

VCF 9.1: Fixing Root Account Password Expiration Issues

.

One of the first post-deployment tasks after installing VMware Cloud Foundation (VCF) 9.1 is configuring a password policy to ensure compliance with your organization’s security standards.



While the password policy is successfully applied to most managed accounts, you may notice that the root accounts of the VCF Operations appliance and the VCF Proxy appliance do not follow the configured password expiration policy.

As a result, the expiration date shown in VCF Management remains unchanged, even though a password policy has been configured.

Symptoms

You may observe one or more of the following:

• A password policy is configured successfully in VCF Management.
• Compliance checks complete without errors.
• The root account of the VCF Operations appliance still shows an incorrect or outdated password expiration date.
• The same behavior occurs on the VCF Proxy appliance.

This can be confusing because the password policy appears to be configured correctly, but it is not enforced for these Linux root accounts.

Why Does This Happen?

The password policy configured in VCF does not automatically update the Linux root account password aging settings on the VCF Operations and Proxy appliances.

Instead, these appliances continue to rely on the Linux ‘chage’ configuration to determine when the root password expires.

VMware has documented this behavior and provided a straightforward workaround.
https://knowledge.broadcom.com/external/article/441344/configured-password-policy-is-not-being.html

Resolution

Before making any changes, enable SSH access on the VCF Operations appliance if it is currently disabled.
https://knowledge.broadcom.com/external/article/315976/enabling-ssh-access-in-aria-operations.html

Step 1 – Connect to the VCF Operations Appliance

SSH to the VCF Operations appliance using an administrative account.

ssh admin@<vcf-operations-appliance>

Step 2 – Verify the Current Password Expiration

Run:

sudo chage -l root

Step 3 – Configure the Password Expiration

Configure a 365-day password lifetime:

sudo chage -M 365 root

Step 4 – Verify the Change

Run:

chage -l root

Step 5 – Repeat for the VCF Proxy Appliance

Repeat the same commands on the VCF Proxy appliance, either through SSH (if enabled) or via the VMware console.

Wait for VCF to Update

Notes

The updated password expiration date is not reflected immediately in the VCF Management interface.

VCF periodically refreshes password information, so it may take 10–30 minutes (or longer depending on your environment) before the new expiration date appears.

.

• This change only affects the Linux root account.
• Verify the setting after appliance upgrades.
• Adjust the password lifetime (90, 180, 365 days, etc.) according to your security policy.

Conclusion

Although VCF 9.1 allows administrators to centrally configure password policies, the Linux root accounts on the VCF Operations and VCF Proxy appliances continue to rely on the local Linux password aging configuration.

Updating the password expiration with the chage command ensures that the root account complies with your organization’s password policy. Once VCF completes its next inventory synchronization, the correct expiration date is displayed in the VCF Management interface.

VCF 9.0 Automate VMware Cloud Foundation Startup and Shutdown with PowerCLI

Powering your VMware Cloud Foundation “lab” environment on and off shouldn’t be a manual process.

A complete shutdown of a VMware Cloud Foundation (VCF) environment is uncommon, but for some energy savings and some time you does not use your lab often, you want a repeatable, reliable, and automated procedure, manually powering dozens of virtual machines in the correct order is both time-consuming and error-prone.

To solve this problem, I created two lightweight PowerCLI scripts:

• VCF 9.0 Small Startup Script
• VCF 9.0 Small Shutdown Script

.

vCenter and ESX hosts are manual (For vSAN cluster I did not find the correct code yet!)
Let me know if you have any questions or addons

Both scripts are available on GitHub and are designed to automate the startup and shutdown of a VMware Cloud Foundation management domain.

GitHub Repository

.

Note: Both Scripts do not work with VCF 9.1!!!!

.

Why These Scripts?

Although VMware Cloud Foundation automates the deployment and lifecycle of the platform, a full platform shutdown still requires the administrator to respect service dependencies.

For example:

• Domain Controllers must be available before authentication works.
• DNS must be online before many VMware services can resolve hostnames.
• vCenter must be operational before SDDC Manager can communicate with the infrastructure.
• NSX components depend on both networking and vCenter.
• VCF services should only start after the management platform is healthy.

Powering everything on simultaneously often results in services that need additional time—or even manual intervention—to recover.

These scripts automate the entire sequence descripted als following:

Start the Management Domain (VCF 9.0)’

Shut Down the Management Domain (VCF 9.0)

Typical Use Cases

These scripts are useful in many environments, including:

• Home labs
• Demonstration environments
• Disaster Recovery testing
• UPS maintenance
• Complete datacenter power outages
• Scheduled maintenance windows
• Hardware replacements

I personally use them in my VCF lab, where powering the environment up or down manually became repetitive and unnecessarily time-consuming. Automating the sequence not only saves time but also ensures a consistent and predictable startup every time.

Customizing the Scripts

Every VMware Cloud Foundation deployment is different.

The scripts are intentionally straightforward so you can easily adapt them by:

• Changing the startup order
• Adding custom virtual machines
• Removing components you don’t use
• Increasing wait times
• Adding health checks
• Integrating notifications
• Extending the logging

Because everything is written in PowerCLI, modifications are simple and require only basic scripting knowledge.

Future Improvements

Some ideas I’m considering for future releases include:

• Automatic dependency discovery
• Email notifications
• Automatic service validation
• Parallel startup where dependencies allow

Contributions and suggestions from the community are always welcome.

Lessons Learned

During development I discovered:

• VMware Tools are the best indicator that a guest OS is ready.
• Fixed sleep timers are unreliable because boot times vary.
• Starting all VMs simultaneously doesn’t necessarily reduce the total startup time.
• Graceful shutdowns significantly reduce recovery issues.
• Simplicity makes the scripts easier to customize.

Download

You can download the latest version from my public GitHub repository:

You can also find more VMware Cloud Foundation automation projects, PowerCLI scripts, and lab guides on my website:

Conclusion

A VMware Cloud Foundation environment consists of many interconnected services, and those services should be started and stopped in the correct order.

These lightweight PowerCLI scripts automate that process, making startup and shutdown predictable, repeatable, and significantly less error-prone. Whether you’re running a production management domain or a small VCF lab, automating these operational tasks saves time and reduces the risk of mistakes.

If you have ideas for improvements or additional features, feel free to open an issue or submit a pull request on GitHub. Happy automating!

.

Translate »