top of page
This site was designed with the
.com
website builder. Create your website today.Start Now

vDeploy

I have completed base development of vDeploy. vDeploy is a set of PowerCLI/PowerShell scripts used to automatically deploy VMs to your VMware environment. vDeploy is 100% visual, based on Microsoft Windows PowerShell Forms. This allows for easy configuration by the end user. vDeploy is currently primarily designed to deploy Windows VMs, but could be modified easily to deploy Linux or other OS type VMs as well.

vDeploy Highlights

-Automatic Logging

-Auto Answer File creation

-Automatic Credential storage with AES encryption

-Dynamic Application/Plugin Support

-Integration with NSX Security Tags (if you have NSX)

-Dynamic NSX Security Tags based on Applications or Server builds

-Integration with VM Tags

-Dynamic vSphere VM Tags based on Applications or Server Builds

-Detailed Dynamic Email Reporting

 

Installation

Simply download the code from my github site: vDeploy

Save it to your script server. Please note that because of the way the PowerShell logging works, if you put this on a network share, please run it from a mapped network drive.

 

Recommendations

Create a user account that has admin rights in vCenter and verify that this user account can connect via PowerCLI prior to running this script. This user account is used to run all tasks of creating the new VM. This allows it so non-admins can create VMs if they wish, but use this with care. Storing the vDeploy PowerShell scripts using Windows folder NTFS Security Permissions is a good way to lock down access to this.

 

Prerequisites

This does require some things be setup prior to first run in your environment. This is the same if you use VMware Orchestrator, Automation, or vDeploy/PowerCLI.

For Windows with Active Directory

-Create an AD service account

-Set said AD service account up with administrator rights in vCenter

-Create an OU for your servers to be built at. In the script the default is Domain\Server_OU\Build.

-Setup AD Delegation on the AD Build OU so that the AD service account can create and delete computer accounts. The script will automatically put new AD Computer accounts in this OU during the build process. If you have multiple domains, do not fear, vDeploy is designed for this. Simply create a service account in each AD domain and create the same OU structure for your VMs to be created at.

-Create an AD GPO so that the AD service account has admin rights on computers that are in the build OU. This is used to deploy applications to the VM after initial VM creation.

-For Application deployment, setup a Windows CA (if your company has not already done so). You will need to deploy WinRM certificates to all computers. This is used to SSL encrypt WinRM Traffic. Follow DarkOperator's guide here: DarkOperator. I have included all the necessary scripting in a WinRM plugin that is a part of vDeploy to fully configure SSL WinRM.

-Create an OS Customization in vCenter. You may want to use the same AD service account that you use to create AD computer accounts with to put the VM on the domain with.

 

First Time Run

Run the PowerShell script as Administrator if possible. This is done, as I have the code automatically check if you have the proper PowerShell modules and versions installed. If the script finds you do not have the proper ones it will download them and install them for you. You can also simply read my script and do this manually if you feel more comfortable with that. It will install VMware.PowerCLI, PowerNSX, and ActiveDirectory Powershell modules.

Fill in all the blanks

You will be asked a series of questions as shown below. Simply fill in information with what you know. See my examples below.

Questions Include:

  1. vCenter FQDN/IP.

  1. NSX Manager FQDN/IP (leave blank if you don't wish to use)

  1. SMTP Server FQDN/IP

  1. SMTP Port

  1. Does SMTP Server Require SSL?

  1. Does SMTP Server require Credentials?

  1. Email From

  1. Email To

  1. SysPrep Timeout

  1. VMware vCenter and NSX Manager Credentials

  1. SMTP Server Credentials (if required)

After all of the basic information is filled out, it is not asked of you again, as it is stored in the Answer File or in AES encrypted PowerShell XML based credential files.

 

Fill in the vDeploy Form

You will presented with a form that will request most of all the information you need to deploy a virtual machine successfully.

Fields Include:

  1. VM Name

  2. # of CPUs

  3. GBs of RAM

  4. VM Template to base new VM on

  5. VM Designation Check boxes - DEV/DMZ/PCI (production if not selected)

  6. Replace Existing VM Check box

  7. Replace VM VM Name

  8. VM Site (VMware vSphere Metro Clustering)

  9. Data Center

  10. Cluster or No Cluster

  11. Host Name

  12. Port Group

  13. Datastore

  14. OS Customization (used for sysprep/VM Naming/etc.)

  15. VM HD Type (more on this later on)

  16. VM Folder Path

  17. VM Notes

  18. VM Owner (put in with the Notes)

  19. Apps/Plugins to Install/Run

  20. Override DHCP Check Box

  21. Override DHCP IP

  22. Override DHCP Subnet Mask

  23. Override DHCP Default Gateway

  24. Override DNS IP 1

  25. Override DNS IP 2

  26. VM Tags

  27. NSX Tags

Fill in the blanks as you need.

  • Put in a VM Name. Name must be 15 characters or less and is always uppercase for standardization. 15 characters maximum is for Netbios reasons.

  • # of CPUs adds that # of vCPUs to a VM. Try to always follow NUMA best practices for this if you can

  • GBs of RAM has a minimum that is specified in the script. Change the minimum if needed.

  • VM Template will show all VM templates in your environment.

  • DMZ Designation Check boxes are used if you need to do special things for these VM types (install apps later, setup specific backups, set special NSX rules, etc.)

  • Checking the Replace Existing VM Check box allows you to type in the name of a present VM. Doing this will copy the VM and NSX tags from the original VM to the new one. Leave this unchecked if you do not wish to use this feature (default).

  • Select your Site. This is for vSphere Metro Clusters. Even if you do not have Metro clusters, it will place this VM in either a Production VMs or DR VMs DRS group. This is needed for Metro Cluster failure domains.

  • Datacenter - Specify the Datacenter the VM is to be placed

  • Cluster/No Cluster - Specify the Cluster Name or No cluster to select any nonclustered host.

  • Host - Specify your Host

  • Port Group - specify the port group you wish to use. This supports standard, distributed/NSX port groups.

  • Datastore - Places all of the newly built VM VMDKs and VMX files on 1 datastore. If you wish to seperate this VM's VMDKs, you will need to do so after the VM is created. This field sorts by datastores with the most space first.

  • OS Customization - used to Sysprep the VM, specify the administrator password, VM naming convention, etc. By default we use this to name the OS based on the VM's name and DHCP for IP configuration

  • VM HD Type - uses the VMHDTypeList.CSV as a primer to ask you what type of Hard drive configuration your VM needs. You can have as many types as you want and be specific about special build types for any configuration. This is very granular and allows for many many options. The forms are setup for 6 VMDKs by default, but the scripting is setup for a maximum of 10 VMDKs should you need it.

  • VM Folder Path - specify the folder in the datacenter you selected to place the VM in. (Thanks goes to LucD for most of the scripting for this)

  • VM Notes - specify what this VM is used for and any other details you wish.

  • VM Owner - specify whom to contact if the VM has issues. This is placed in the VM Notes field during build.

  • Apps/Plugins to Install/Configure - uses the AppList.CSV file to present a user with things to run/do after the VM is fully online/on a windows domain. Very basic, but fully customizable. This also allows for VM and NSX tags to be allied based on specific application/plugins that are selected during the selection process. A note about Antivirus, I always place it last on this list so that it does not interfere with other processes prior.

  • Override DHCP - Specify a Static IP address for the vNIC on the new VM.

  • VM Tags - Select these manually to add tags where needed. There can be default tags. These are specified in the script.

  • NSX Tags - Select these to manually add NSX tags where needed. There can be default NSX tags. These are specified in the script.

Hit OK to continue

Various Checks

Checks are done to verify that all fields are filled in properly, VM names are not used already, AD computer accounts do not already exist with the VM name/OS Customization Domain you specified, and many other basic checks.

If the Domain's user credentials are not already present, the script will ask you to specify credentials for a user account that will have administrative rights on the VM post Sysprep. For Windows Domain VMs, use Group policy to add a user to the administrators group for this purpose. This AD user account is used for AD Computer account creation and WinRM remote management.

VM Hard Disk Type Selection

After basic checks are completed, depending upon VM HD Type selected, you will be asked to specify how large to make the VM's hard disks. This varies depending upon the VM HD Type you specified in the vDeploy main form. Note that you should always specify a minimum value for each disk. This ensures that each VM is built with a certain storage standard. The minimum value is controlled via the VMHDListType.csv file and is easily changeable should you need to up the base hard disk size for any disk in your configuration.

Verification

Verification is done. This presents you with an overview of all the settings you specified in early forms. If everything looks good, hit OK and everything else is automated to build the VM from this point forward.

 

Build Process

  1. Active Directory computer account is created for VM based on the VM name you specified in the vDeploy main form

  2. VM is built in a powered off state using the OS Customization you specified. If you specified a static IP address, the IP is set at this set.

  3. Upgrade the VM Hardware Version is automatically upgraded to whatever ESXi Type the VMware host presently is. This is done for standardization and allows you to have older templates that can be added to any cluster and brought up to the current VM hardware version type.

  4. Set CPUs on the VM

  5. Set RAM on the VM

  6. Set the Port Group on the VM

  7. Set Notes on the VM. This adds many fields to the notes including VM Owner, build date, built by, etc.

  8. If the selected Host the VM is on is part of a cluster, put the new VM in the proper DRS Metro cluster site (Production/DR).

  9. Expand VM VMDK for primary disk if needed

  10. Add extra VMDKs and SCSI controllers if required depending upon the VM HD Type specified in the vDeploy main form.

  11. Set NSX Tags - Checks are done to see if NSX is used. If it is used, verify that the host is part of a cluster, if the cluster in question has NSX setup, and that NSX is in a good working state. positives and any errors in the script. If all of this is true, add NSX Tags to the VM. Sets NSX tags based on what you specified in the vDeploy main form. It also sets NSX tags based on the VM Application/Plugins selected during input from the vDeploy main form. This ensures that there are no false configurations or errors.

  12. Set VM Tags - Sets VM tags based on what you specified in the vDeploy main form. It also sets VM tags based on the VM Application/Plugins selected during input from the vDeploy main form.

  13. Verify VM Tags - Verifys what VM Tags are set on the VM post setting them.

  14. Power on the VM - This ensures that there is 0% that any NSX rules/VM Tags were not applied prior to the VM being turned on.

  15. Verify that the VM is SysPrep'd before proceeding - This also uses the SysPrep timeout should the SysPrep not complete successfully, the VM is deleted and automatically cleaned up.

  16. Verify that VM is completely online and not restart post Sysprep

  17. Verify that the VM's vCenter registered IP matches DNS. This is needed for all WinRM or SSH commands for customization that will come during the later stage. If DNS does not match what vCenter states is the IP, steps are taken to fix this or fail the build process. As DNS is an external system that is critical to a successful build process it is very important that this be checked immediately after the VM is built.

  18. Attempt to update group policy on the new VM. This ensures that everything is ready for the Application/Plugin process to proceed without issues. In most cases this is not needed, but is good to do prior to application/plugin deployment.

  19. Install all applications/plugins. This is a very detailed process. It uses the AppList.csv file to get the name of the application/plugins you specified in the vDeploy main form and runs them. Each application/plugin folder should have 3 sub folders including: Local, Verify, VMware.

  20. Install all applications/plugins - Copy Files.This process first copies over any files needed that are in the Local folder.

  21. Install all applications/plugins - VMware Scripts. Runs all scripts in the VMware folder. It runs the scripts in alphanumeric order, so specify your scripts in order from 1-x. This can include VMware or WinRM tasks. I stole this from Alan Renouf's awesome vCheck projects. Thank you Alan for the idea. Note that this process requires WinRM SSL certificates be deployed via Windows CA prior to the VMs being build. This is only needed for Windows VMs. For Windows VMs, first step should always be to Install/Configure/Verify WinRM is setup.

  22. Install all applications/plugins - Verification Scripts. Runs all the scripts in the Verify folder. This verifies the processes you did during the VMware scripts phase. This ensures that you verify you work after doing things like installing apps/configuration/etc.

  23. Install all applications/plugins - Add email addresses to email distribution. Based on the apps/plugins you use, email addresses can be automatically added to the email report. This allows for SQL Server builds be passed to the SQL team, similar for IIS, or any other example depending upon app/plugin selected. Email addresses are specified in the AppList.CSV file and are easily configurable.

  24. Install all applications/plugins - Loop for all Apps/Plugins. Loops until all apps are done.

  25. Restart the VM Post all application/plugins are run. This ensures that any credentials that were in the VM's RAM and that all process for the install/configuration are cleared out of RAM prior to production.

  26. Document all VM configuration Details post all configuration. This is used for email reporting.

  27. Disconnect any open PS Sessions

  28. Disconnect from vCenter and NSX Server

  29. Build the Email Body (HTML Formatting)

  30. Export Email Body information for proper formatting

  31. Import Email Body in RAW formatting

  32. If an email server is specified, email the report along with the PowerShell VM Build log to the users.

 

Email Reporting

Any good automation system has great email reporting and logging. vDeploy is no different. It provides a multitude of information to the end user after all build processes are completed. I attempted to make this very detailed, as I wanted to know as much information about the build and how much time it took for most major tasks. This helps to pinpoint issues with application installs/scripting, slow storage, etc.

Example report

Subject:

VM Build Process for HAMTESTRH911P - Completed

Email Body:

Attached is the log file from this VM Build Process for HAMTESTRH911P New VM HAMTESTRH911P Build Creation : Success VM Info VM Name : HAMTESTRH911P VM Domain : Hamker.local VM vCPU(s) : 1 VM RAM : 4 GBs VM Template : Windows 2016 Datacenter - Template VM HW Version : v13 VM Datacenter : Data Center VM Cluster : Cluster VM DRS Site : Production VM Port Group : (1) Server VM Datastore : HAMNAS01_iSCSI VM HD Type : Generic1 VM HD Count : 1 VM HD Capacity(s) : 60 GBs VM OS Customization : Hamker.local VM Folder : Data Center/Test VMs VM Owner(s) : Russ Hamker VM Notes : Test VM VM TAGS : WinRM VM TAGS Applied for Apps : WinRM DEV : False PCI : False DMZ : False VM replace : Unchecked VM Current Host : hamesxi03.hamker.local VM VMware Tools Version : 10.2.0 VM VMware Tools Build Version : 10304 VM Current IPv4 Address : 192.168.1.131 VM MacAddress(es) include: 00:50:56:be:37:b3 VM Current DNS Name is : HAMTESTRH911P.hamker.local NSX Info NSX Tags : App-LogInsight, App-Symantec, App-WinRM, New-Servers NSX Tags Applied for Apps : App-LogInsight, App-Symantec, App-WinRM NSX Manager : 192.168.1.60 NSX Manager Version : 6.4.0 NSX Manager Build Version : 7564187 NSX Cluster Version : 6.4.0.7564187 Application/Plug-in Info Applications/Plug-ins Installed Include : SSL WinRM Hard Drive Config LogInsight Symantec Application Verification SSL WinRM install: Success LogInsight install: Success Symantec install: Success Application Elapsed Time SSL WinRM elapsed install time: 4.720762375 Minutes Hard Drive Config elapsed install time: 0.48096613 Minutes LogInsight elapsed install time: 0.395215643333333 Minutes Symantec elapsed install time: 3.86259561166667 Minutes vCenter Info vCenter Server Name : hamvc01.hamker.local vCenter Server Version : 6.5.0 vCenter Server Build Version : 7312210 VM Build Host Info VM Build Host : hamesxi01.hamker.local VM Build Host ESXi Version : 6.5.0 VM Build Host ESXi Build Version : 7388607 Build Info Start Time : Mar-04-2018 21-09-08 Completion Time : Mar-04-2018 21-42-26 Total Build Run Time : 33.29450383 Minutes Total VM Clone Time : 1.32301737 Minutes Total VM Clone/Configuration Time : 1.56814073166667 Minutes Total VM SysPrep Time : 4.79490507333333 Minutes VM Built By : HAMKER\rhamker VM Built by Script Server : HAMPC01.hamker.local VM deployed with vDeploy

 

Why use vDeploy?

I developed vDeploy for a multitude of reasons. One of the larger ones is that I felt that VMware Orchestrator is not for me. It requires detailed knowledge of how to write in Java Script, saves passwords in clear text, requires that you use CredSSP for WinRM (major security risk), and still requires a PowerShell Host to do a majority of the heavy lifting that is not currently built into Orchestrator. Having to have a PowerShell host along with Orchestrator also means more infrastructure to build out a VM. It is more complex to pass information back and forth and has the possibility for more errors to occur between 3 systems (Orchestrator, PowerShell Host, and the VM to be built) instead of 2 (PowerShell Host and the VM to be built).

Doing all things in PowerShell simplifies all processes, allows for secure credentials storage, more logging, simplified VM build infrastructure, better email reporting, etc. Doing everything in code also means that all your documentation can be your code as long as you document your code well. I have tried to document things well for you.

This also helped me prove out that PowerShell and a good scripting scheduler can be your full Orchestration option as long as you write everything correctly and test accordingly.

How does vDeploy work in the Cloud?

Simply spin up a VM with PowerShell on it. With PowerCLI 10 you can now use a Linux or MacOS to be your PowerShell host for VM deployment. vDeploy does require a Windows VM however, as all of the forms in vDeploy are Windows Form based.

What other things are required for vDeploy?

Windows Environments

  1. Windows Domain Controllers

  2. Windows Certificate Authorities for certificate deployment

  3. DHCP (not required)

  4. User account in vCenter with admin rights to create new VMs

  5. User account in NSX Manager with Security administrator rights to set NSX tags

  6. User account in the Windows domain the VM is placed on for application/plugin installation/deployment

  7. PowerShell host to run the scripts/store apps for deployment from

Where does vDeploy fall short?

Any good developer knows what they have missed. At present vDeploy currently does not support VMware Resource Pools. I am needing a good function to build out all the Resource Pools to present them to the end user during the vDeploy Main Form presentation.

How did I build the vDeploy Main Form

I used Microsoft Visual Studio 2017 Community Edition (Free) along with the PowerShell Pro Tools (add-on for VS). This allowed me to easily model the GUI. After creating the base GUI I wrote all the custom code using NotePad++ with a lot of trial and error. Good article about how to do this yourself at Wandering Life. You may also want to check out POSHGUI as a free alternative.

Things I will be adding

I will be adding a good example how to install IIS or SQL via the plugins I have provided. I will be as detailed as possible and provide as much documentation as possible with this. I will also be adding a CSV attachment that will be true CSV format to provide all the same details in the email body. This will be helpful as some people want to save their build processes in an Excel document or a SharePoint type interface for long term documentation.

Questions/Comments

Please let me know what you think. Use Github to ask for any offical changes to the vDeploy scripting.

Single Post: Blog_Single_Post_Widget
bottom of page