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!!
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.
•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
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.
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:
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.
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!
VMware Cloud Foundation (VCF) 9.1 is here — and it’s one of the most feature‑packed releases in years. This update isn’t just incremental; it’s a strategic modernization of compute, storage, networking, security, and operations across the entire private cloud stack.
.
Let’s break down the biggest enhancements and why they I think they matter.
Modernizing Infrastructure Economics with vSphere Foundation 9.1
VCF 9.1 brings several powerful updates to the vSphere layer, aimed at improving performance efficiency and reducing operational overhead.
Enhanced NVMe Memory Tiering
Workloads that demand high throughput and low latency benefit from smarter memory tiering. NVMe-based memory tiers now deliver improved performance and flexibility. (And yes — many are hoping Secure Boot support lands here as well.)
Parallel Processing of DRS vMotion
DRS can now process multiple vMotions in parallel, dramatically reducing cluster balancing times. This is especially impactful in large-scale environments with frequent workload mobility.
Live Patching for TPM-Enabled Hosts
Live patching now works even on hosts with TPM enabled — a huge win for security-conscious organizations that previously had to choose between uptime and compliance.
Networking Updates: Scale, Simplicity, and Smarter Automation
VCF 9.1 introduces major networking enhancements that streamline operations and expand connectivity options.
Enhanced Day-2 VM Lifecycle Management
Networking changes for VMs — including NIC updates, IP changes, and security policies — are now easier and more automated.
Existing VLAN Connectivity via Distributed Transit Gateways
You can now bridge existing VLAN-based networks into VCF environments more seamlessly, reducing migration friction and simplifying hybrid designs.
VCF 9.1 now supports EVPN-VXLAN interoperability with the physicalnetwork fabric. This is a major step toward fully integrated, fabric-aware cloud networking.
Network Assessment & VPC Planning
New tools and workflows help architects plan VPC layouts, assess network readiness, and avoid misconfigurations before deployment.
Optimize, Modernize & Protect Storage with vSAN in VCF 9.1
Storage gets a significant upgrade in this release, especially for environments focused on efficiency and resilience.
Encryption for vSAN Global Deduplication
Global dedupe is now compatible with data-at-rest encryption — a long-awaited capability for secure, space-efficient storage.
Enhanced Stretched Cluster Capabilities
Improved resilience and smarter failure handling strengthen business continuity for mission-critical workloads.
Automated Storage Policy Management
Policies now adjust automatically based on cluster configuration changes, reducing manual tuning and risk of misalignment.
Strengthening Zero Trust Security & Platform Resilience
Security is a major theme in VCF 9.1, with improvements across the stack.
Data-at-Rest Encryption for Global Dedupe
This ensures encrypted storage without sacrificing dedupe efficiency — a rare combination in enterprise storage.
Quick Patching for vCenter
Faster patch cycles reduce exposure windows and simplify maintenance.
Live Patching for TPM-Enabled Hosts
As mentioned earlier, this is a major operational win for secure environments.
Continuous Compliance & Integrated Cyber Recovery
VCF 9.1 pushes deeper into automated compliance and recovery workflows.
Compliance Monitoring & Desired State Remediation
The platform now continuously checks VCF components against desired state and can automatically remediate drift.
VPC Policy-Based Connectivity
Security and connectivity policies can now be applied consistently across VPCs, improving governance and reducing misconfigurations.
VMware Data Services Manager 9.1: Modern Databases for AI & Cloud
Microsoft SQL Server 2022 Now GA
SQL Server 2022 is now fully supported and generally available through DSM 9.1, enabling automated lifecycle management for modern database workloads — including those powering AI and analytics.
Want to See It in Action?
VMware has published a full VCF 9.1 video podcast series that dives deeper into the new capabilities:
Enough to do in my Homelab Starting with Upgrade and testing the new features!!
In June 2026 Secure boot certs start to going to expire for physical en virtual machines Servers en Clients. PS not only Windows but also Linux!!
PS. Make sure Client en Servers all installed with latest updates!!
Made a little Risk Assessment:
The expiration and replacement of Microsoft Secure Boot certificates pose a high risk to IT environments. If not properly managed, systems may fail to boot, updates may fail, and security risks may increase. This is particularly critical in automated and virtualized environments.
Key risks:
•Systems failing to boot after updates
•Incompatibility during OS or hypervisor upgrades
•Increased security risks due to outdated certificates
Recommended actions:
1.Update firmware and Secure Boot certificates
2.Test all workloads in a lab environment
3.Update golden images and automation pipelines
A phased rollout and proper validation are essential to prevent disruptions.
1. Scope
This document describes the risks, impact, and mitigations related to the expiration of Microsoft Secure Boot certificates in enterprise environments.
2. Affected Components
•Systems with UEFI firmware (Servers, Desktops, Virtual Machines)
•Microsoft UEFI CA certificates
•Operating Systems (Servers, Clients) (Windows, Linux)
•Automation tools like (Packer, MDT, SCCM)
3. Risk Analysis
Key risks:
•Incompatibility during upgrades
•Security vulnerabilities caused by outdated trust stores
•Errors in automation pipelines
•Firmware incompatibility
4. Risk Matrix
•Upgrade Issues: High
•Security Exposure: High
•Automation Failures: Medium
•Firmware Issues: High
5. Mitigations
•Update firmware on all systems
•Apply Microsoft Secure Boot updates
•Verify Event ID 1808
•Rebuild images with updated certificates
•Perform a phased rollout
6. Validation & Testing
•Test OS boot scenarios
•Validate Secure Boot status
•Verify automation pipelines
7. Conclusion
Changes to Secure Boot certificates must be treated as critical infrastructure updates. Proper preparation, testing, and phased implementation are essential to avoid disruptions.
.Microsoft has released patch’s for the following OS.
Windows 11 (23H2/24H2/25H2) Windows Server 2016/2019/2022/2025.
VMware is creating a “Fix or Update” for this
* I did not test versions with extended support like Windows 2012 R2 and Windows 10.
I recently created 3 version of a FixSecureBoot script — a lightweight alternative inspired by the excellent work of haz-ard-9, the author of FixSecureBootBulk.ps1. Their script is powerful and absolutely the right choice if you rely on BitLocker or need a fully automated, safety‑first workflow.
However, at roughly 3,000 lines of code, the original script is understandably complex. It includes many checks and safeguards, which are great for production environments but made it harder for me to fully understand what was happening under the hood. I wanted something simpler, easier to read, and tailored to my own workflow.
So I took the time to study the original script, copied only the parts I needed, and built a much more compact version that gives me exactly the result I want — which show the verification step that every thing is correct updated.
What My Script Does
Here’s the full sequence of actions my simplified script performs:
1.Shuts down the VM
2.Creates a snapshot
3.Enables UEFI Setup Mode
4.Clears VMRAM (for older VMs)
5.Upgrades virtual hardware if the VM is below version 21 (vSphere 8)
6.Starts the VM and waits for VMware Tools
7.Checks that the guest OS is fully online
8.Downloads the required certificates (only once)
9.Uploads the two certificates to the VM if not exist
10.Installs the new boot certificates
11.Shuts down the VM and clears Setup Mode
12.Boots the VM and sets AvailableUpdates to 0x5944 (certs ready for install)
13.Reboots until AvailableUpdates becomes 0x4100 (may require multiple reboots)
14.Reboots and runs Secure-Boot-Update again
15.Reboots and runs Secure-Boot-Update again, then checks for Event ID 1808 (if found, everything is good)
I’ve tested this workflow successfully on:
•Windows 11 (23H2, 24H2, 25H2)
•Windows Server 2016, 2019, 2022, and 2025
Downloads
** link the links for downloading the original files from Microsoft Github page.
If you want a script that’s easier to read, easier to modify, and still gets the job done (as long as you’re not using BitLocker), this simplified version might be exactly what you need.
Let me know if you want me to share the script itself or write a follow‑up post about how it works internally. .
So now I want to deploy a template with Terraform, which was created earlier by Packer.
First, we need to ensure we have the Terraform downloaded and the vSphere provider Initialized.
Install Terraform: You can download it from the official Terraform website and follow the installation instructions for your operating system.
I made my life a little easier to create a PowerShell script that downloads the latest version: Download Terraform.ps1
Initialize Your Terraform Configuration: Create a directory for your Terraform configuration files. Inside this directory, create a `main.tf` file (or any `.tf` file) where you will define your provider and other configurations. Define the vSphere Provider in Your main.tf: Add the following block to your Terraform configuration file to specify the use of the vSphere provider:
terraform {
required_providers {
vsphere = {
source = “HashiCorp/vsphere”
version = “> 2.11”
}
}
}
provider “vsphere” {
user = vcenter_username
password = vcenter_password
vsphere_server = vcenter_server
# If you have a self-signed cert
allow_unverified_ssl = true
}
Replace ”vcenter_username”, ” vcenter_password” , ”vcenter_server” with your actual vSphere credentials and server address.
Basic Terraform Commands
Terraform.ps1
# Go to the Terraform download folder
$terraformfolder = ‘d:\automation\terraform\’
Set-Location $terraformfolder
# Download Terraform plugins
.\terraform.exe init
# Test Run
.\terraform.exe plan
# Run Terraform
.\terraform.exe apply
# Clean Up what you created
.\terraform.exe Destroy
Initialize the Terraform Working Directory: Run the following command in your terminal from the directory where your Terraform configuration file is located:
terraform init
This command will download the vSphere provider and initialize your Terraform working directory. It sets up and downloads the necessary provider plugins for Terraform to interact with vSphere.
Verify the Installation: After running `terraform init`, you should see output indicating that the vSphere provider has been successfully installed. You can now proceed to create Terraform configurations to manage your vSphere resources.
Deploy a Template VM within vSphere
In this example, we are deploying a VM running Windows Server 2022.
Terraform Module Structure
variables.tf: Define the variables for the module.
main.tf: Contains the main configuration for the VM.
outputs.tf: Define the outputs for the module.
Variables.tf
variable “vsphere_user” {
default = “<your_vcenter_username_here>”
description = “vSphere username to use to connect to the environment – Default: administrator@vsphere.local”
Websites store cookies to enhance functionality and personalise your experience. You can manage your preferences, but blocking some cookies may impact site performance and services.
Essential cookies enable basic functions and are necessary for the proper function of the website.
Name
Description
Duration
Cookie Preferences
This cookie is used to store the user's cookie consent preferences.
30 days
Statistics cookies collect information anonymously. This information helps us understand how visitors use our website.
Google Analytics is a powerful tool that tracks and analyzes website traffic for informed marketing decisions.
Contains information related to marketing campaigns of the user. These are shared with Google AdWords / Google Ads when the Google Ads and Google Analytics accounts are linked together.
90 days
__utma
ID used to identify users and sessions
2 years after last activity
__utmt
Used to monitor number of Google Analytics server requests
10 minutes
__utmb
Used to distinguish new sessions and visits. This cookie is set when the GA.js javascript library is loaded and there is no existing __utmb cookie. The cookie is updated every time data is sent to the Google Analytics server.
30 minutes after last activity
__utmc
Used only with old Urchin versions of Google Analytics and not with GA.js. Was used to distinguish between new sessions and visits at the end of a session.
End of session (browser)
__utmz
Contains information about the traffic source or campaign that directed user to the website. The cookie is set when the GA.js javascript is loaded and updated when data is sent to the Google Anaytics server
6 months after last activity
__utmv
Contains custom information set by the web developer via the _setCustomVar method in Google Analytics. This cookie is updated every time new data is sent to the Google Analytics server.
2 years after last activity
__utmx
Used to determine whether a user is included in an A / B or Multivariate test.
18 months
_ga
ID used to identify users
2 years
_gali
Used by Google Analytics to determine which links on a page are being clicked
30 seconds
_ga_
ID used to identify users
2 years
_gid
ID used to identify users for 24 hours after last activity
24 hours
_gat
Used to monitor number of Google Analytics server requests when using Google Tag Manager
You must be logged in to post a comment.