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!

.

Config a VCF (vSAN ESA) host the Easy Way

A while ago i created: 

V1: Config vSAN ESA host or VCF ESA vSAN Host the easy way with Config-VSAN-ESA-VCF-Lab-Host Script.

V2: Config a VCF (vSAN ESA) host the Easy Way

With the release of VCF 9.1 is now time for again a updated version!

What does the script now:

âś… Disable ipv6

âś… Set DNS domain name

âś… Rename local datastore

âś…Configure NTP

âś… MTU 9000

✅ Installs the vSAN ESA Hardware Mock VIB &

âś… Workaround to reduce impact of resync traffic in vSAN ESA clusters utilizing a 10G network

✅ Installs the Synology NFS Plug-in for VMware VAAI

âś… Memory Optimalisation Additional Transparent Page Sharing management capabilities and new default settings

 ✅ AMD Zen4/Zen5 IPMI Thermal Driver for ESX AMD Zen4/Zen5 IPMI Thermal Driver for ESX Fling

✅ Generate new certificate on the ESXi host (for the VCF verification check)

âś… Ask are you running Miniforum MS-A2(AMD) host & Optimalization see
VCF 9.1 – Comprehensive ESX Configuration Workarounds for Lab Deployments (Except the vSAN Compression Algorithm)

 ✅ Enable Memory Tiering for 9.1 and 9.0 and older (Filter OS Disk)

vSAN ESA Mock and the AMD Zen4/Zen5 IPMI Thermal Driver can be download on the Broadcom Fling page.

(https://support.broadcom.com/group/ecx/free-downloads) section and select Flings (https://support.broadcom.com/group/ecx/productdownloads?subfamily=Flings&freeDownloads=true)

You need to download the vibs separately!
For the installs put the vib’s in the same map as the script
.

You can download the script: HERE

.

VCF 9.1 What fixed the stuck deployment at “Deploy and Configure VCF Management Platform”

Overview

While deploying VMware Cloud Foundation (VCF) 9.1 in a homelab environment, the installation repeatedly failed during the ‘Deploy and Configure VCF Management Platform’ stage. Despite performing nine completely clean installations, the deployment consistently stopped at the same point.

Error Observed

The deployment task failed with the message: ‘Add VM Name Prefix to NSX Firewall Exclusion List’. The failure was identified in /var/log/vmware/vcf/domainmanager/domainmanager.log

Initial Research

Several Broadcom Knowledge Base articles appeared relevant, including KB440449 and KB 441122. Although the symptoms were similar, neither article fully resolved the issue.

VMSP Configuration Review

The original VMSP configuration used a name value matching the prefix of the fleetFqdn. The configuration was modified to use a unique VMSP cluster name. While this appeared promising, the issue persisted.

Additional Troubleshooting

Additional troubleshooting included changing VMSP IP ranges, rebuilding DNS records, validating forward and reverse DNS resolution, and reviewing deployment logs for networking issues.

Root Cause Analysis

The issue was ultimately not caused by the NSX firewall exclusion configuration. Multiple infrastructure issues contributed to deployment instability.

Resolution

1. Configure a single authoritative NTP source, preferably the domain controller.
See the planning and preparation workbook
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/planning-and-preparation.html
2. Verify DNS records and name resolution.
3. Upgraded to a dedicated 10G Switch Ubiquiti UniFi Pro XG 8 PoE ipv 2.5GB Ubiquity Switch
Switch Pro XG 8 PoE - Ubiquiti Store Europe
4. Replace faulty network components.

Conclusion

Although the deployment failure appeared to indicate an NSX firewall exclusion issue, the underlying cause was network instability combined with infrastructure configuration problems. After correcting NTP configuration, validating DNS, upgrading network connectivity, and replacing the defective SFP+ module, the VCF 9.1 deployment completed successfully.

What’s New in Private Cloud: VMware VCF 9.1 Enhancements

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.

Streamlined Firewalls & Automated Inter-VPC Security

Security policies between VPCs are now automated, reducing manual rule creation and improving consistency across tenants.

Terraform Provider Enhancements

Better support for tenant-level policy and content management means more automation and cleaner IaC workflows.

Simplified Workload Connectivity & Enhanced Network Scale

EVPN-VXLAN Interoperability

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!!

Running VCF 9 in a Nested Lab using vSAN ESA on a single host is that not great?

For the deployment I used a server that has 16 cores en 32 cores total and a lot of ram!

Installation on Nested ESX VM’s

For the nested ESX VMs I am using the generic ESX image. In my lab I’m using 4 nested ESX nodes for vSAN ESA (Minimum is needed is 3).

  • Ideally add 24 vCPUs to the nested ESX, but VCF Automation is capable of being deployed with 16 vCPUs
  • Check Expose hardware assisted virtualization to the guest OS under CPU
  • Add a NVME controller and connect disks to this controller if planning to use vSAN ESA (Don’t forget to remove the old Controller)
  • Add at least two VMXNET3 nics connected to the same network
  • Choose VMware ESXi 8.0 or later as the Guest OS version.
  • Change the IDE CD-ROM to SATA ROM (Failed to locate kickstart on Nested ESXi VM CD-ROM in VCF 9.0)

Afbeelding met tekst, schermopname, nummer, LettertypeDoor AI gegenereerde inhoud is mogelijk onjuist.

Config the 4 Host for vSAN ESA

To config the 4 Hosts for vSAN ESA I used my own powercli script where I blogged about here: Config vSAN ESA host or VCF ESA vSAN Host the easy way with Config-VSAN-ESA-VCF-Lab-Host Script

You can download the script HERE!

Installing the Vib works still great. No problem with ESA  Pre-check: ✅

If you have problems check this great blog from William Lam: vSAN ESA Disk & HCL Workaround for VCF 9.0

VCF installer.

At first you have to deploy the VMware Cloud Foundation

The name of the installer is a little off: VCF-SDDC-Manager-Appliance-9.0.0.0.24703748.ova

Download token

If you don’t have a download token from the Broadcom support then it’s a little complicated. I won’t go into this in depth now but here is a nice article if you have a Synology Nas: VCF 9.0 Offline Depot using Synology

(Note: For any vExpert reading this… You need to claim your own domain name because build your profile is not working with a @hotmail.com or @gmail accounts, Noted by Broadcom)

Afbeelding met tekst, schermopname, Parallel, ontwerpDoor AI gegenereerde inhoud is mogelijk onjuist.

I looks something like this!
Afbeelding met tekst, schermopname, LettertypeDoor AI gegenereerde inhoud is mogelijk onjuist.

10GBE Nic Pre-Check Issue

Next thing to do was: Disable 10GbE NIC Pre-Check in the VCF 9.0 Installer or this should also work: How to change the vmxnet3 link speed of a VM (Not tested)

Afbeelding met tekst, elektronica, schermopname, softwareDoor AI gegenereerde inhoud is mogelijk onjuist.

Deployment

I have deployed the beta in a earlier state. For deployment I used the same json file to start with.

VCF Automation will deployed automatically that was only the change that I changed it

Afbeelding met tekst, schermopname, nummer, softwareDoor AI gegenereerde inhoud is mogelijk onjuist.

Afbeelding met tekst, schermopname, Website, ontwerpDoor AI gegenereerde inhoud is mogelijk onjuist.

It’s running!
Afbeelding met tekst, schermopname, scherm, nummerDoor AI gegenereerde inhoud is mogelijk onjuist.

Afbeelding met tekst, lijn, nummer, LettertypeDoor AI gegenereerde inhoud is mogelijk onjuist.

Performance running Nested!!

Afbeelding met tekst, lijn, Perceel, LettertypeDoor AI gegenereerde inhoud is mogelijk onjuist.

Above the screenshot from the host with de Nested VCF lab deployment it’s quite cpu intensive (2 x CPU 8cores / 16 Threads)

Optimalization

After the deployment I did three things
– On the vSAN ESA Cluster (Disable Auto Disk Claim) (Keep the warning away)
– On the NSX VM reduce the cpu reservation from 6000 🡪 2000 (It helps but not enough)
– VCF automation VM 24 cores to 16 cores.

NSX en VCF automation are really CPU intensive.

I had deployed also two Edge servers but the server did not like that. Edges are also CPU intensive.

I am thinking about adding MS-01 or MS-A2 for splitting some load.

Config vSAN ESA host or VCF ESA vSAN Host the easy way with Config-VSAN-ESA-VCF-Lab-Host Script.

William Lam created the vSAN ESA HCL hardware mock VIB for Nested ESXi.
It works great for vSAN ESA or for VCF vSAN ESA Nested nodes.

You can download the needed vib here

A whale ago I found a easy way to the deployment of a VMware SDDC based on vSAN ESA: VCF automated lab deployment with vSAN ESA

It works great. I a few hours you have a working VCF management domain on vSAN ESA.

Sow what about the script

For the Workload domain domain I created de nested ESXi vm’s manually .
And I did some testing for VCF 9 which I created the nested ESXi host also manually.

Configure by hand takes a lot of time. So I did some scripting and I used some code
from: VCF automated lab deployment with vSAN ESA

So I created a script that does the following:

  • Login on DHCP address en configure a Fixt IP address based on DNS name
  • Disable IPv6
  • Rename the local datastore to a uniek name with the name of the host
  • Configure NTP
  • Install the vSAN ESA VIB mock en restart vSAN mgmt.
  • Generate new certificate for the host with the correct domain name in it.
  • Enable KB372309 (10GB ethernet for vSAN ESA)

It works great for ESXi Nested nodes (ESXi 8.0u3b and ESXi9.X beta)

You can find the script HERE!!

Afbeelding met tekst, schermopname, nummer, LettertypeDoor AI gegenereerde inhoud is mogelijk onjuist.

Afbeelding met tekst, schermopname, nummer, LettertypeDoor AI gegenereerde inhoud is mogelijk onjuist.

Deploying VCF Workload Domain with One NSX Manager

For your VCF homelab you wan to keep the resources small with a little bit overhead.
In this post I will talk about how i managed to deploy a VCF Workload Domain with a single NSX Manager, instead of the standard three nsx nodes.

Warning: Use this only in a Homelab!

The trick is to SSH into your SDDC Manager using the vcf user, and the password used during bring-up of the management domain.

When logged in, run su and log in as root using the password used during bring-up.

run: vi /etc/vmware/vcf/domainmanager/application-prod.properties

Hit i in your keyboard to go into insert mode. Go to the end of the file, and append the following:

nsxt.manager.formfactor=medium
nsxt.manager.resources.validation.skip=true
nsxt.manager.cluster.size=1
nsxt.manager.wait.minutes=120

This will make it so that any workload domain you deploy has one NSX Manager, and that it uses a smaller size. Once done, hit ESC in your keyboard, then type :wq and hit enter to save the file. (w = write, q = quit).

Then run systemctl restart domainmanager and you are good to go!

This worked in my nested Cloud Foundation deployment in my lab running 5.2.1.0.

You will still have to fill in the information for the extra nodes in the UI.

Deploying Windows VMs with Terraform and Packer

A whale ago, I started using Packer for creating Windows Templates for using in my home lab.
I blogged about it here: Windows Server 2025 “Preview” deployment with Packer

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.

  1. 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

  1. 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.

  1. 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

Afbeelding met tekst, schermopname, Lettertype, softwareDoor AI gegenereerde inhoud is mogelijk onjuist.

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

  1. variables.tf: Define the variables for the module.
  2. main.tf: Contains the main configuration for the VM.
  3. 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”

}

variable “vsphere_password” {

  default     = “<your_vcenter_password_here>”

  description = “vSphere vCenter password”

}

variable “vsphere_server” {

  default = “<your_vcenter_here>”

  description = “vSphere vCenter server”

}

variable “datacenter” {

  default = “<your_datacenter_here>”

  description = “vSphere datacenter”

}

variable “cluster” {

  default = “<your_cluster_here>”

  description = “vSphere cluster”

}

variable “network” {

  default = “<vcenter_network>”

  description = “vSphere network”

}

variable “datastore” {

  default = “<your_destination_datastore_>”

  description = “vSphere datastore”

}

variable “template” {

  default = “<your_template_name_here>”

  description = “Template VM”

}

variable “customization_specifications” {

  default = “<vcenter_customization_specifications>”

  description = “Customization Spec”

}

When you run “.\terraform plan” you do a test run to check your coding

Afbeelding met tekst, schermopname, LettertypeDoor AI gegenereerde inhoud is mogelijk onjuist.

Afbeelding met tekst, schermopname, Multimediasoftware, softwareDoor AI gegenereerde inhoud is mogelijk onjuist.

When you run “.\terraform apply” build your virtual machine

Afbeelding met tekst, schermopname, LettertypeDoor AI gegenereerde inhoud is mogelijk onjuist.

Afbeelding met tekst, schermopname, Lettertype, softwareDoor AI gegenereerde inhoud is mogelijk onjuist.

Based on: https://vminfrastructure.com/2025/03/11/deploying-a-vm-using-terraform/

It works but it need some tweaking and fixing.

Adding a TPM2.0 security device does not work right now
Server 2025 customization does not work

ESXi Unattend Install on Dell BOSS controller

I had the opportunity to test a Dell vSAN node. I had a older unattend install esxi iso.
This installed the ESXi OS on the wrong disk.

I hate to type a very complex password twice.
So automation is the key.
I love de ks.cfg install option

Sow following the following guide did not the trik:
https://www.dell.com/support/kbdoc/en-us/000177584/automating-operating-system-deployment-to-dell-boss-techniques-for-different-operating-systems

VMware ESXi Automated Install

This did not work:
install –overwritevmfs –firstdisk=”DELLBOSS VD”

After doing a manual install:
Afbeelding met tekst, schermopnameAutomatisch gegenereerde beschrijving

What works:

# For Dell Boss Controller “Dell BOSS-N1″

install –overwritevmfs –firstdisk=”Dell BOSS-N1”

Translate »