WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
    • VMware Cloud Foundation 9.1
    • VMware Cloud Foundation 9.0
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

Search Results for: kickstart

Automating ESXi 5 Kickstart Tips & Tricks

07.13.2011 by William Lam // 58 Comments

There are some minor changes with kickstarting ESXi 5.0 but the majority of your existing ESXi 4.1 kickstart configurations can be re-used with a few modifications. One of my goals during the vSphere 5.0 beta was to automate as much of the configurations of an ESXi host as possible within the kickstart process. I also converted as many of the legacy esxcfg-* commands as I could over to the enhanced esxcli namespaces as the esxcfg-* commands will eventually be deprecated in favor of esxcli. Hopefully the tips & tricks and the example kickstart configuration file will be useful in aiding the transition to ESXi 5.0.

As usual, before diving in and creating an ESXi 5.0 kickstart configuration, make sure you spend some time going over the documentation provided by VMware, specifically the ESXi Installable and vCenter Server Setup Guide. If you would like to get a sense for what a ESXi 5.0 kickstart could look like, please jump to the bottom of this post to get a complete working example displaying the various types of configurations.

[Read more...]

Categories // Uncategorized Tags // ESXi 5.0, kickstart, ks.cfg, vSphere 5.0

How to automatically add ESX(i) host to vCenter in Kickstart

03.29.2011 by William Lam // 66 Comments

While recently updating my Automating Active Directory Domain Join in ESX(i) Kickstart article, it reminded me an old blog post by Justin Guidroz who initially identified a way to add an ESXi host to vCenter using python and the vSphere MOB. The approach was very neat but was not 100% automated as it required some user interaction with the vSphere MOB to identify certain API properties before one could potentially script it within a kickstart installation.

I decided to revisit this problem as it was something I had investigated awhile back. There are numerous ways on getting something like this to work in your environment, but it all boils down to your constraints, naming convention and provisioning process. If you have a well defined environment and utilizing a good naming structure and can easily identify which vCenter a given ESX(i) host should be managed from, then this can easily be integrated into your existing kickstart with minor tweaks. This script was tested on vCenter 4.1 Update 1 and ESXi 4.1 and 4.1 Update1.

UPDATE (09/08/2025) - Please see this blog post for an updated solution to this use case

UPDATE (02/01/2013) - I have provided a download link to the joinvCenter.py script below as there have been some funky formatting issues when displaying the script. For ESXi 5.x hosts, you will need to ensure httpClient is enabled (disabled by default) on the ESXi firewall else it will not be able to connect to your vCenter Server. Please refer below for the instructions.

UPDATE (03/29/2011) - Updated the IP Address extraction to use gethostbyname and added proper logout logic after joining vCenter.

[Read more...]

Categories // Uncategorized Tags // ESXi 4.1, kickstart, vCenter Server

Automating Active Directory User Management in ESXi Kickstart

02.24.2011 by William Lam // 2 Comments

In the previous post we looked at Automating Active Directory Domain Join in ESXi Kickstart. We are now going to look at adding domain users without having to manually go through vSphere Client or external scripts after an ESXi host has been provisioned. We are going to be leveraging vim-cmd to accomplish this during the kickstart installation. Before doing so, you will need to know the the available roles on a default ESXi host and the syntax for a given permission.

To see the available roles, you can run the following command on an already provisioned ESXi host:

vim-cmd vimsvc/auth/roles | less

The default roles on an ESXi host are:

  • NoAccess
  • ReadOnly
  • Admin

To see the existing permissions, you can run the following command on an already provisioned ESXi host:

vim-cmd vimsvc/auth/permissions

These entries will match what you see in the vSphere Client and dictate who has login access to the ESXi host.

To add a new permission, we will be using the "vim-cmd vimsvc/auth/entity_permission_add" and it requires five parameters.

  • First - Entity (This can be found by looking at the output from permissions)
  • Second - Username
  • Third - Boolean on whether this is a group or not (should be false)
  • Fourth - The role to be applied to the user
  • Fifth - Boolean on whether to propagate this permission

If you manually add a domain user, you can easily verify the user can login by running the "id" command which will perform a look up on the user. If it is successful, it should return an entry corresponding to something like this:

Note: We need to use the double slash "\" to escape the initial slash when running the query. Also make note of the domain name as it may or may not match your full domain name.

We are now ready to craft a simple script that will add domain users as part of the ESXi kickstart process. The following snippet should be placed in the %firstboot section of your kickstart and after your Active Directory domain join code. Make sure you replace the DOMAIN_NAME variable along with the usernames. In the example I have two separate for loops to handle ReadOnly and Admin users, you do not need both if you are only adding one type of users.

The script basically performs a simple 60sec sleep to ensure the domain join process has completed before continuing. If you do not place a sleep, the subsequent code will fail to execute. The next step is to validate the user by doing a simple lookup using "id" command and upon successful look up of the user, we add the appropriate permissions.

Note: We only have two add these two entities: "vim.Folder:ha-folder-root" and "vim.ComputeResource:ha-compute-res" to properly add a permission.

If everything was successful, after your ESXi installation you now should have your host joined to your Active Directory and a list of domain users who now have permission to login to the ESXi host. You can verify by using the vSphere Client and taking a look at the Permissions tab.

If you would like to create custom roles on your ESXi host, you can use the following command:

vim-cmd vimsvc/auth/role_add

Note: The syntax for the privileges parameter lists only five, but it actually accepts as many as you need with the custom role

Categories // Uncategorized Tags // active directory, ESXi 4.1, kickstart, mob, vimsh

  • « Previous Page
  • 1
  • …
  • 4
  • 5
  • 6
  • 7
  • 8
  • …
  • 34
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • VCF 9.1 - Enabling High Availability for a Small VCF Management Services (VCFMS) Deployment 06/22/2026
  • Clarifying Minimum Required ESX Hosts for VCF Deployments 06/18/2026
  • VCF 9.1 - Auditing VCF Management Services (VCFMS) IP Pool Usage  06/17/2026
  • VCF 9.1 - Auditing vCenter Server Connections using the Connection Utilization API 06/15/2026
  • Quick Tip: Resolving OVFTool "Failed to Send File" Errors on macOS 06/13/2026
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.

To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2026