Closing Your Automation Gap with VMware Cloud…

See how VMware Cloud Foundation closes a big gap in data center automation. It steps in as a unique solution and automates steps which almost always are done manually in data centers today, despite the broad range of available tools.

VMware Social Media Advocacy

The post Closing Your Automation Gap with VMware Cloud… appeared first on VMtoday.

VMware Cloud Foundataion – Networking Overview

VMware Cloud Foundataion – Networking Overview. Learn more at https://vmware.com/go/cloudfoundation

VMware Social Media Advocacy

The post VMware Cloud Foundataion – Networking Overview appeared first on VMtoday.

• May 2009: vShield Zones 1.0 released, providing an application-aware firewall built for VMware vCenter Server integration.  vSphere 4.0 is the current version of vSphere.  vSphere Advanced, Enterprise and Enterprise Plus editions are entitled to vShield Zones.
• August 2010: VMware vShield 4.1 is released along with vSphere 4.1.  vShield Edge, App and Endpoint are introduced and packaged with vShield Zones. All vShield components are managed by vShield Manager. vShield (Suite) is available as add-on licenses.  vShield Zones remains a part of vSphere Enterprise and Enterprise Plus licensing.
• July 2011: vShield Data Security is announced.
• September 2011: VMware vShield 5.0 is released, along with vSphere 5.0.  vShield 5.0 adds vShield Data Security capabilities.  If you were running ESX 4.1 with vShield Zones 4.1, and wanted to upgrade to ESXi 5.0, you must manually uninstall vShield Manager 4.1 and Zones 4.1, upgrade to ESXi 5.0, then install vShield Manager 1.0 and Zones 1.0 that were released with vSphere 5.0.  Yes, this is confusing at best….  vShield Endpoint is made available as part of the VMware View 4 Premier Edition bundle.
• August 2012: vShield Zones 4.1 reaches End of Availability (EOA) and End of General Support (EOS).  However, vShield Zones 1.0 that was released with vSphere 5.0 remains available for download through vSphere 5.1.  The vShield Zones virtual firewall provided very basic segmentation and traffic filtering capabilities using the VMsafe API, which is deprecated (thus further investment for feature development or support can not be justified). VMware plans to continue to invest in vCloud Networking and Security, which covers the majority of use cases for vShield Zones.
• July 2012: VMware acquires Nicira for $1.26 Billion.  VMware NSX will eventually come from this acquisition.
• August 2012: vShield Endpoint is now included in every vSphere Edition (except vSphere Essentials).  The licensing change makes vShield Endpoint available for all customers, with an active SnS, running vSphere 5.1.x, vSphere 5.0.x, or vSphere 4.1 U3! 
• August 2012: vSphere 5.1 and vCloud Networking and Security (vCNS) 5.1 are announced.  vCNS includes vShield Edge, App and Endpoint.  vCNS is available as an add-on license to vSphere, and is included with vCloud Director.  With the general availability of VMware vCloud Networking and Security 5.1 in September 2012, VMware announced an end of availability date of October 15, 2012 for the standalone vShield family of products (i.e, vShield Edge, vShield App, vShield Data Security and vShield Endpoint.) VMware will continue to support maintenance releases for the vShield products until September 1, 2013.
  • vCloud Networking and Security is sold in two editions:
    • Standard Edition -­‐ provides the following features: firewall, VPN, VXLAN, vCloud Ecosystem framework, Network Address Translation, and Dynamic Host Control Protocol.
    • Advanced Edition – Provides all the features of Standard Edition plus high availability, load balancing, and data security.

• August 2012: vCloud Suite 5.1 is announced.  This first iteration of the vCloud Suite bundled vSphere, vCloud Director, vCloud Connector, vFabric Application Director, vCloud Networking and Security 5.1, vCenter Operations Management Suite, vCenter Site Recovery Manager and vCloud Automation Center.  VMware offered a $1 upgrade from vSphere Enterprise Plus to vCloud Suite Standard – customers who took advantage of this deal are now licensed for vCloud Networking and Security through the vCloud Suite.
  • With vCloud Suite, VMware is now selling vCloud Networking and Security with two licensing options: bundled with the vCloud Suites and licensed per processor; or sold stand alone, and licensed per VM.
• September 2013: vCloud Suite 5.5 is released.  vCloud Suite 5.5 includes vCloud Networking and Security 5.5; vCloud Networking and Security 5.5 is only available as part of VMware vCloud Suite 5.5 and is not available as a standalone product.  At the same time, VMware announced the End of Availability (“EOA”) of the VMware vCloud Networking and Security 5.1 Standard and Advanced editions for sale as standalone products effective September 30, 2013.
• September 2013: VMware announces general availability of VMware NSX.  NSX is a stand-alone product with some functionality that overlaps vCNS.
• March 2015: vSphere 6.0 and vCloud Suite 6.0 are announced.
  • vCloud Networking and Security is removed from the vCloud Suite bundle – this means that vCNS has reached End of Availability because it was only available through the vCloud Suite bundle. However, vCNS 5.5 remains supported through September 2016 for customers who were already licensed.
  • NSX is not included in the vCloud Suite.  vCloud Suite customers who are ready to take advantage of advanced software-defined networking and security services have the option to purchase NSX for vSphere at a reduced add-on price. NSX provides layer 2 to layer 7 network virtualization, with security policies that follow workloads across the data center for faster network provisioning and management.

And that brings us to today – At first glance, it would appear that all vShield and vCloud Networking and Security products are end of availability and not available for use with vSphere 6.0.  vShield Manager, a component of vCNS, is needed to deploy and mange the vShield Endpoint agent on ESXi hosts, so customers began to question whether vShield Endpoint was licensed and compatible with vSphere 6.0 (and I suspect some of our security partners also began to wonder).  So what’s the deal?

vShield Endpoint is supported with vSphere 6.0, and licensing is included in vSphere editions Essentials Plus and above! vCloud Networking and Security was updated to version 5.5.4.x to support vSphere 6.0.  This VMware KB sheds a little light on this: Implementation of VMware vShield Endpoint beyond vCloud Networking and Security End of Availability (EOA) (2110078).  Be sure to check the VMware Product Interoperability Matrixes to verify you have the supported version of vCNS for your version of vSphere (vCenter AND ESXi).

So how do you use vShield Endpoint with vSphere 6.0?  vShield Endpoint requires vCNS  (specifically, vShield Manager/vCloud Networking and Security Manager) for configuration and management.  Any entitled customers will be able to download vCNS to obtain vCloud Networking and Security Manager.  Sounds good, except that until very recently vCloud Networking and Security was not included in the vSphere 6.0 downloads (and it is still not listed under vSphere with Operations Management 6.0 downloads or vCloud Suite 6.0 downloads sections on https://my.vmware.com.  If you don’t see vCloud Networking and Security in your product downloads on https://my.vmware.com use the search functionality in the downloads section to look for “vShield 5.5.4”.  Note that as of today, the latest version is 5.5.4.1.

So what happens after vSphere 6.0?  As far as I know, vCloud Networking and Security will not be available – features in NSX will replace vCNS/vShield features.  NSX supports Guest Introspection. Guest Introspection strengthens security for virtual machines while improving performance for endpoint protection by offloading antivirus and anti-malware agent processing to a dedicated Security Virtual Appliance that is delivered and supported by VMware partners (such as Symantec, McAfee, TrendMicro).  As of today, you have to acquire NSX licenses as add-on licensing to vCloud Suite or a la carte to your vSphere/vSOM environment (i.e. NSX is not included in vCloud Suite).  I have no insight into whether vCloud Suite or NSX licensing will change for future versions.

Customers who choose to go the NSX path will be able to upgrade from vShield Endpoint 5.5 to vShield Endpoint 6.0 and use NSX Manager to perform administration and operations on vShield Endpoint (see this documentation for more: https://pubs.vmware.com/NSX-6/index.jsp#com.vmware.nsx.install.doc/GUID-45B09850-AB5A-4232-AE7C-6A80541A2AF0.html).

vShield Endpoint partner solutions will continue to be supported per this VMware KB article: Support for partner integrations with VMware vShield Endpoint and VMware vCloud Networking and Security (2105558)

Bottom line: vShield Endpoint is supported with vSphere 6.0, and licensing is included in vSphere editions Essentials Plus and above!  Verify with your 3rd party security vendor that they support vCloud Networking and Security Manager v.5.5.4.x and vSphere 6.0.  If so, upgrade vCloud Networking and Security Manager to v.5.5.4.x and then upgrade vSphere to version 6.0.  Note that the official Update sequence for vSphere 6.0 and its compatible VMware products (2109760) has you upgrading vCenter and ESXi to 6.0 before vShield Endpoint to 5.5.4.x, but I don’t think it is correct (because vShield 5.5.3 and earlier do not support vSphere 6.x, but vShield 5.5.4.x supports vSphere 5.5 and earlier).  Check with VMware Support, the VMware Product Interoperability Matrixes and, of course, test your upgrade in a lab.  Hope this helps clear up any confusion.

The post vShield Endpoint with vSphere 6.0 appeared first on VMtoday.

The biggest issue with this bit of nastyware is that it intercepts all your web traffic – including encrypted traffic – to analyze it and use it to offer you targeted ads.  To do this, it needs to break the encryption (that Google, your bank or email provides) and then use it’s own encryption certificate to send traffic to its original destination.  There are many problems with this approach, but perhaps the biggest issue is that the encryption certificates that Visual Discovery uses (issued by Superfish, Inc.) all share the same private encryption key, and that key is easy to crack.  This makes it easy for the bad guys to create websites that impersonate valid websites (like your bank), including an encryption certificate that appears to be valid for your bank (but is really using the Superfish certificate).  Any data you send to the fake sites can be intercepted and read in plain text – your user name, password, mother’s maiden name, first born and the university major of your best friend’s cousin’s nephew’s neighbor’s college roommate during the second half of her freshman year, before she decided to become a gym teacher.  But I digress….

Several sites offer removal instructions for Visual Discovery and Superfish, but many are incomplete (including Lenovo’s).  To completely remove Visual Discovery and Superfish, you need to follow a few steps:

First, open the Windows Control Panel, click ‘Uninstall Programs’ and find ‘Superfish, Inc. Visual Discovery’, and click Uninstall.

Next, you need to remove the Superfish encryption certificate from your PC.  To do this, use Windows Search to look for ‘mmc.exe’.

Execute the program and an empty Microsoft Management Console (MMC) opens (Lenovo’s removal instructions tell you to use the ‘Manage Computer Certificates’ link in the Control Panel, but this won’t expose everything you’ll need to remove.  The same with using the certmgr.msc instructions on other sites….).

Now we need to add a couple snap-ins to the MMC. From the File menu, choose ‘Add/Remove Snap-in…’.  Select the ‘Certificates’ snap-in and click the ‘Add >’ button.

You’ll be prompted to choose a certificate store to open.  Choose ‘My user account’, then click Finish.

Now repeat the Add/Remove snap-in steps, this time choosing ‘Computer account’ in the final step.

Choose ‘Local Computer’ when prompted.

Expand the Certificates – Current User node.  Then expand ‘Trusted Root Certification Authorities’ and look for the ‘Superfish, Inc.’ certificate.  Right-click the certificate and choose delete.

Acknowledge the warning about deleting certificates by clicking Yes.

Now repeat the previous steps under the ‘Certificates – Local Computer’ node.

If you’re a Firefox user, verify that the Superfish certificate isn’t trusted by the browser.  Open the Firefox menu and click ‘Options’.

Switch to the ‘Advanced’ tab, then select the ‘Certificates’ tab and finally click the ‘View Certificates’ button.

Switch to the ‘Authorities’ tab. Scroll through the list of certificates and look for Superfish. If you find it, delete it.

At this point, Superfish Visual Discovery should be gone, but it’s still a good idea to run a scan for traces of the junkware (note that most antivirus programs don’t check for malicious certificates – that’s why we manually removed them).  Use your antivirus program first.  If you don’t have a 3rd-party scanner (Norton, McAfee, etc.), search for ‘Windows Defender’ on your computer and run this built-in virus scanner from Microsoft.

Next, use Malwarebytes to scan for Superfish Visual Discovery and any of its friends.  A basic version of Malwarebytes is free, or you can buy a full featured version from Amazon here: https://amzn.to/1Exp7gb.  Quarantine and remove anything that Malwarebytes discovers.

Final step – visit this site to verify that Superfish can’t intercept your web traffic: https://filippo.io/Badfish/.  If this site shows that Superfish isn’t intercepting your connections your connections you should be good to go.  Now run antivirus and Malwarebytes on a regular basis, don’t let toolbars and other unknown apps get installed, and choose unique and complex passwords for any website logins that you value!

The post How To Remove Superfish Adware from Lenovo Laptops appeared first on VMtoday.

Losing my DNS Server settings caused me all sorts of issues – my vCenter Server couldn’t find ESXi hosts by name, AD authentication failed, and general mayhem ensued.  I reviewed some logs on the appliance and poked around in /etc/sysconfig/network/config, but nothing jumped out at me as being wrong.  I even went so far as to manually update /etc/resolv.conf with the correct settings but after a reboot the DNS server settings were lost.  I needed some help to figure this one out, so I visited my Universal Troubleshooting Accelerator Dispensing Machine, poured a pint of my Rye Porter homebrew and took a step back to think outside the box (or outside the VCSA as it were).

If the problem is not coming from inside the appliance, it’s got to be coming from somewhere outside the appliance.  Either my incorrect DNS is getting set by DHCP or some other mechanism.  I’m using a Static IP so DHCP isn’t handing out a DNS server.  Think, dummy, think (absorb, beer, absorb)!  Ah ha!  I didn’t deploy the VCSA – it was deployed by the data center administrator to a separate management cluster before I had built an AD or DNS infrastructure on the hosts my VCSA was managing.  Because the administrator didn’t know about my non-existent DNS servers, he used a default setting when he set the properties of the vApp while deploying the OVF.  The OVF vApp settings were injected into the appliance and applied at each reboot, overwriting my settings.

I always like to dig a bit deeper when I run into a problem, so let’s look briefly at how vApp Options are applied to better understand this mechanism.  When a virtual appliance is imported via OVF, it either used VMware Tools to read the vApp Options through the vami service (see /opt/vmware/share/vami) or a virtual CD-ROM was mounted that contained an XML file with the vApp Options.  On the vCenter Virtual Appliance (based on SUSE Linux Enterprise 11), the vApp Options are written to /opt/vmware/etc/vami/ovfEnv.xml.  The vami service reads the settings in from the XML and applies them at subsequent boot (via /opt/vmware/share/vami/subsequentboot).  You can read a bit more about this process here: https://blogs.vmware.com/vapp/2009/07/selfconfiguration-and-the-ovf-environment.html.

Ultimately, the fix is an easy one – shut down the VM (the vApp Options can only be modified on a powered-off VM), update the vApp Options on the VM and start the VM.  In the vSphere Web Client, Edit Settings of the appliance, switch to the vApp Options tab, expand Networking Properties and update as desired.  Note that this issue is not unique to the vCenter Virtual Appliance (VCSA) – other virtual appliances that rely on the vApp Options properties will be impacted (Log Insight, vCenter Operations, vSphere Replication, vSphere Management Assistant (vMA) and other third party appliances).

As I explained in my primer on analytic troubleshooting, it’s not enough to identify the root cause and stop with a simple fix.  You need to stair-step the solution to figure out what else could be effected by the root cause and to prevent the problem from occurring again.  To prevent future problems, we could simply disable the vApp Options on a VM.  Quick fix, but doing so could have unanticipated consequences depending on how VMware or your ISV are using vApp Options.  Your virtual appliance vendor probably used VMware Studio to create the appliance with settings to pull vApp options into the appliance – you could break dependencies…. You’re probably better off updating your VMs vApp Options and making the task of updating your vApp Options a part of your change management process or run-book as a long-term strategy

If you want to save yourself some clicks, you can automate the process of changing vApp settings if you’re doing it often for several machines.  Official documentation for vApp PropertyInfo settings can be found here https://pubs.vmware.com/vsphere-55/topic/com.vmware.wssdk.apiref.doc/vim.vApp.PropertyInfo.html.  Here is an example of PowerCLI code for issuing a shutdown to a VM and waiting for it to be in a powered-off state, then updating vApp DNS Server settings on that VM, then powering it back on.  Note that this code is specific to my environment any probably will NOT work in yours as the property[] value and key value may be different for each VM.

function Wait-VMPowerState {
<# function from https://powershell.com/cs/media/p/17924.aspx #>
[CmdletBinding()]
Param(
        # The name of a VM
        [Parameter(Mandatory=$true,
                   ValueFromPipelineByPropertyName=$true,
                   Position=0)]
        $VMName,
        # The operation (up or down)
        [Parameter(Mandatory=$true,
                   ValueFromPipelineByPropertyName=$true,
                   Position=1)]
                   [ValidateSet("Up","Down")]
        $Operation
    )
begin{
    $vm = get-vm -Name $vmname
    }
process{
    switch ($operation) {
        down {
                if ($vm.PowerState -eq "PoweredOn") {
                    Write-Verbose "Shutting Down $vmname"
                    $vm | Shutdown-VMGuest -Confirm:$false
                    #Wait for Shutdown to complete
                    do {
                       #Wait 5 seconds
                       Start-Sleep -s 5
                       #Check the power status
                       $vm = Get-VM -Name $vmname
                       $status = $vm.PowerState
                    }until($status -eq "PoweredOff")
                }
                 elseif ($vm.PowerState -eq "PoweredOff") {
                    Write-Verbose "$vmname is powered down"
                }
            }
         up {
                if ($vm.PowerState -eq "PoweredOff") {
                    Write-Verbose "Starting VM $vmname"
                    $vm | Start-VM -Confirm:$false
                    #Wait for startup to complete
                    do {
                       #Wait 5 seconds
                       Start-Sleep -s 5
                       #Check the power status
                       $vm = Get-VM -Name $vmname
                       $status = $vm.PowerState
                    }until($status -eq "PoweredOn")
                }
                 elseif ($vm.PowerState -eq "PoweredOn") {
                    Write-Verbose "$vmname is powered up"
                }
            }
        }
    }
end{
    $vm = Get-VM -Name $vmname
    $vm
    }
}

$newValue = "10.152.190.20,10.152.190.21"
$MyvApp= get-VM -Name "VSOM-VCVA-5.5-01"
$vm = Wait-VMPowerState -VMName $MyvApp -Operation down
$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.changeVersion = $MyvApp.ExtensionData.Config.ChangeVersion
$spec.vAppConfig = New-Object VMware.Vim.VmConfigSpec
$spec.vAppConfig.property = New-Object VMware.Vim.VAppPropertySpec[] (1)
$spec.vAppConfig.property[0] = New-Object VMware.Vim.VAppPropertySpec
$spec.vAppConfig.property[0].operation = "edit"
$spec.vAppConfig.property[0].info = New-Object VMware.Vim.VAppPropertyInfo
$spec.vAppConfig.property[0].info.key = 2
$spec.vAppConfig.property[0].info.value = $newValue
$Reconfig = $MyvApp.ExtensionData
$Configtask = $Reconfig.ReconfigVM_Task($spec)
start-sleep -s 5
start-vm -VM $MyvApp -confirm $false

Have anything to add? Know a better way to automate? Share it in the comments below!

*I have been rightly corrected on the proper acronym for the vCenter Server Appliance. Depending on where you read, you may see it called the by VCVA. This is not correct – it should be VCSA.

The post vCenter Virtual Appliance Network Settings Reverting appeared first on VMtoday.

Download Links:
Visio 2013 Stencil

Visio 2003-2010 Stencil

This stencil joins my other Visio stencils for VMware Horizon View and other generic VMware Visio stencils and resources – see here for the others.

Let me know if you have ideas for other shapes in this stencil or have ideas for improvements!  Note that this is not an official VMware release and is not supported by VMware – it’s just a little something I did in my spare time over a cold beer.  Cheers!

The post vCenter Orchestrator Visio Stencil appeared first on VMtoday.

Before we get too carried away, let’s first make sure our vCenter server has the correct time.  If you installed your vCenter Server on a Windows host, it should get it’s time from your Active Directory.  For a vCenter Server Virtual Appliance (VCVA), you need to set the NTP settings manually.  To do this, log into the admin interface of the VCVA (https://<VCVA-name-or-IP>/5480/).  On the vCenter Server tab, click either the ‘Time’ menu button or the ‘Configure Time’ link.

You have several options for time synchronization on the VMware vCenter Server Appliance:

1. No synchronization – just don’t…
2. NTP synchronization – sync with an upstream NTP server.  Use an authoritative source on your own network if available, otherwise use something like ntp.org’s servers.
3. VMware Tools synchronization – Use the pre-installed VMware tools package to read time from the ESXi host that the VCVA is running on.  If the host’s time is incorrect or changes, the VCVA time will change too.  If you vMotion the VCVA from one host to another and the hosts time is not in sync, the VCVA will experience a time shift.
4. Active Directory synchronization – If you joined your VCVA to your Microsoft Active Directory, VCVA will read the time from your domain’s authoritative time source (usually the domain controller holding the PDC Emulator FSMO role).

I prefer Active Directory if one is available and correctly configured to pull time from a trusted higher stratum server.  See this TechNet article for tips on how to configure an Active Directory forest for reliable time synchronization.  Next I would choose the NTP synchronization option, followed by VMware tools sync, and never the no time synchronization.

Once the VCVA has accurate time, we can focus on the ESXi hosts.  As I mentioned above, this can be done manually in either the vSphere Client (the legacy C# client) or the vSphere Web Client.  Here’s the screenshot for where to click in the vSphere Web Client for a single host.

That’s too many clicks for me, so I put together a quick script in PowerCLI that will do several things for me:

1. Clear existing NTP servers from ESXi hosts.
2. Manually set the time on all ESXi hosts to match the local system time (the system you are running the script on).  This is very helpful if you have servers with date-time values that are way out of whack.  The ESXi NTP client will not correct time on the host when the offset (i.e. difference) between the host time and the NTP server time is greater than the preset sanity limit of 1000 seconds.  Per VMware KB 1005092, If you have a greater than 1000 second offset you may find entries like the following in /var/log/messages or /var/log/hostd.log (better yet, see them in VMware Log Insight!!!)

    ntpd[263140]: time correction of  seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.
    [info 'ha-eventmgr'] Event 91 : NTP daemon stopped. Time correction 1206 > 1000 seconds. Manually set the time and restart ntpd.

3. Configure DNS servers on the management network (useful if you find your NTP servers by name instead of IP.
4. Configure NTP servers on ESXi hosts, configure the NTP daemon to start automatically with the host, open the ESXi firewall for outbound NTP requests, and restart the NTP service to be sure everything is working correctly.

I have a simple menu driving the script to make changes easy without having to remember to pass variables and whatnot.  You’ll see the first menu option for ‘Delete all existing DNS Servers values’ is not working.  PowerCLI can’t write null values with the Set-VMHostNetwork -DNSAddress command, and the UpdateDnsConfig method in VMware.Vim.HostDnsConfig was not behaving for me (probably because my PowerCLIfu is weak).  Adding new DNS servers will overwrite any existing values, so the option is kinda silly to have I guess….

Feel free to modify or suggest improvements.  The code is on github (https://github.com/joshuatownsend/set-vmware-ntp-dns), and displayed below for you to use:

<######################################################################
Menu-driven PowerCLI script to delete, add, and update DNS and NTP on
VMware ESXi hosts.

**Save as set-ntp.ps1
**Switch to directory ps1 is saved in and run
** MAKE SURE LOCAL SYSTEM TIME IS CORRECT!!!!

v1.0    27 February 2014:   Initial draft
v1.1	27 February 2014:	Changed menu option 1 to dark gray cause no worky.

Written By Josh Townsend

All Code provided as is and used at your own risk.
######################################################################>
$xAppName    = ‘set-ntpdns’
[BOOLEAN]$global:xExitSession=$false

# Add PowerCLI snapin if not already loaded
if ((Get-PSSnapin -Name VMware.VimAutomation.Core -ErrorAction SilentlyContinue) -eq $null ) {Add-PsSnapin VMware.VimAutomation.Core; $bSnapinAdded = $true}

# Prompt for vCenter or ESXi server
$vCenter = Read-host "Enter the name of your vCenter Server or ESXi host" 
$domain = Read-host "Domain name (leave blank if using local ESXi account)"
$user = Read-host "vCenter or ESXi user account"
$password = Read-host -Prompt "Enter password" -AsSecureString
$decodedpassword = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto([System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($password))
Connect-VIServer $vCenter -user $domain\$user -Password $decodedpassword

#Some other connection options:
#Option 1 - Show menu of recently used ESXi or vCenter Servers
#Write-host "Choose from the list below or enter the name of your vCenter Server or ESXi Host, then enter credentials as prompted" -ForegroundColor Yellow
#Connect-VIServer -Menu $true
#option 2 - Hard code it.  This leaves your password in plain text.  Consider using the new-VICredentialStore option to securely store your credentials!
#Connect-VIServer -Server 10.10.10.10 -User root -Password vmware

$esxHosts = get-VMHost

Function Clear-DNS{
#foreach ($esx in $esxHosts) #{
#Write-Host "Deleting existing DNS servers from $esx" -ForegroundColor Green
# Get Current Values for required properties
#$currenthostname = Get-VMHost | Get-VMHostNetwork | select hostname
#$currentdomainName = Get-VMHost | Get-VMHostNetwork | select domainname

# ------- UpdateDnsConfig -------
#$config = New-Object VMware.Vim.HostDnsConfig
#$config.dhcp = $false
#$config.hostName = $currenthostname
#$config.domainName = $domainname

#$_this = Get-View -Id 'HostNetworkSystem-networkSystem'
#$_this.UpdateDnsConfig($config)
#}
    #Write-Host "Old DNS Values Cleared! Press any key to return to menu..." -ForegroundColor Green
    Write-Host "Sorry, this function not supported because we cannot delete or write null values for DNS Server Addresses using PowerCLI. `nUse the Add Additional menu option to overwrite existing DNS servers. `nPress any key to return to the menu." -ForegroundColor Magenta
    $x = $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")
    LoadMenuSystem
   }

Function Clear-NTP{
   foreach ($esx in $esxHosts) {
     Write-Host "Deleting existing NTP servers from $esx" -ForegroundColor Green
     $existingNTParray = $esxhosts | Get-VMHostNTPServer
     Remove-VMHostNTPServer -NtpServer $existingNTParray -Confirm:$false
   }
    Write-Host "Old NTP Values Cleared! Press any key to return to menu..." -ForegroundColor Green
    $x = $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")
    LoadMenuSystem
}

Function Clear-NTPDNS{
   Clear-NTP
   Clear-DNS

   Write-Host "Done!  Press any key to return to menu...." -ForegroundColor Green
   $x = $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")
   LoadMenuSystem
}

Function Manual-Time{
   # First set all hosts in vCenter to use time of local system to prevent too large drift for NTP to correct
   Write-Host "Updating manual time on $esx to match local system time" -ForegroundColor Green
   $esxhosts | Where-Object {
     $t = Get-Date
     $dst = $_ | %{ Get-View $_.ExtensionData.ConfigManager.DateTimeSystem }
     $dst.UpdateDateTime((Get-Date($t.ToUniversalTime()) -format u))
    }
   Write-Host "Done!  Press any key to return to menu...." -ForegroundColor Green
   $x = $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")
   LoadMenuSystem
}

Function Set-DNS{
# Prompt for Primary and Alternate DNS Servers
$dnspri = read-host "Enter Primary DNS"
$dnsalt = read-host "Enter Alternate DNS"

# Prompt for Domain
$domainname = read-host "Enter Domain Name"

foreach ($esx in $esxHosts) {

   Write-Host "Configuring DNS and Domain Name on $esx" -ForegroundColor Green
   Get-VMHostNetwork -VMHost $esx | Set-VMHostNetwork -DomainName $domainname -DNSAddress $dnspri , $dnsalt -Confirm:$false

   Write-Host "Done!  Press any key to return to menu...." -ForegroundColor Green
   $x = $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")
   LoadMenuSystem
 }
}

Function Set-NTP{

#Prompt for NTP Servers
$ntpone = read-host "Enter NTP Server One"
$ntptwo = read-host "Enter NTP Server Two"

foreach ($esx in $esxHosts) {

   Write-Host "Configuring NTP Servers on $esx" -ForegroundColor Green
   Add-VMHostNTPServer -NtpServer $ntpone , $ntptwo -VMHost $esx -Confirm:$false

   Write-Host "Allow NTP queries outbound through the firewall on $esx" -ForegroundColor Green
   Get-VMHostFirewallException -VMHost $esx | where {$_.Name -eq "NTP client"} | Set-VMHostFirewallException -Enabled:$true

   Write-Host "Starting NTP service on $esx" -ForegroundColor Green
   Get-VmHostService -VMHost $esx | Where-Object {$_.key -eq "ntpd"} | Start-VMHostService
   
   Write-Host "Configuring NTP Client Policy on $esx" -ForegroundColor Green
   Get-VMHostService -VMHost $esx | where{$_.Key -eq "ntpd"} | Set-VMHostService -policy "on" -Confirm:$false

   Write-Host "Restarting NTP Client on $esx" -ForegroundColor Green
   Get-VMHostService -VMHost $esx | where{$_.Key -eq "ntpd"} | Restart-VMHostService -Confirm:$false
   }
   Write-Host "Done!  Press any key to return to menu...." -ForegroundColor Green
   $x = $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")
   LoadMenuSystem
}

Function Set-NTPDNS {
   Set-DNS
   Set-NTP
   
   Write-Host "Done!  Press any key to return to menu...." -ForegroundColor Green
   $x = $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")
   LoadMenuSystem
}

# Menu to select functions
function LoadMenuSystem() {
[int]$xMenuChoiceA = 0
[BOOLEAN]$xValidSelection=$false
while ( $xMenuChoiceA -lt 1 -or $xMenuChoiceA -gt 8 ){
CLS
# ------ Menu Choices -------
    Write-Host “Choose an option below to modify all ESXi hosts DNS and NTP settings.`n” -ForegroundColor Magenta
    Write-host "`t1. Delete all existing DNS Servers values (not working)" -ForegroundColor DarkGray
    Write-host "`t2. Delete all existing NTP Server values" -ForegroundColor Cyan
    Write-host "`t3. Delete all existing DNS & NTP Servers (not working)" -ForegroundColor Cyan
    Write-host "`t4. Manually set time on all hosts to match your local system time.*" -ForegroundColor Cyan
    Write-host "`t*This option prevents NTP sync problems due to large offset" -ForegroundColor Gray
    Write-host "`t5. Add additional DNS Server values**" -ForegroundColor Cyan
    Write-host "`t**This will overwrite any existing values" -ForegroundColor Gray
    Write-host "`t6. Add additional NTP Server values and set NTP to start with host.***" -ForegroundColor Cyan
    Write-host "`t***Verifyr DNS values are correct if using names instead of IPs." -ForegroundColor Gray
    Write-host "`t7. Add both NTP & DNS Server values and set NTP to start wtih host" -ForegroundColor Cyan
    Write-host "`t8. Quit and exit`n`n" -ForegroundColor Yellow
# ------ Menu Choices -------
# Get and Validate Choice
[Int]$xMenuChoiceA = read-host "Please select an option [1-8]"
if( $xMenuChoiceA -lt 1 -or $xMenuChoiceA -gt 8 ){
    Write-Host “`tInvalid Selection.`n” -Fore Red;start-Sleep -Seconds 1
   }
    
# Survey Says....

Switch( $xMenuChoiceA ){#… User has selected a valid entry.. load menu
  1{ Clear-DNS }
  2{ Clear-NTP }
  3{ Clear-NTPDNS }
  4{ Manual-Time }
  5{ Set-DNS }
  6{ Set-NTP }
  7{ set-NTPDNS }
default { $global:xExitSession=$true;break }
  }
 }
}


LoadMenuSystem
If ($xExitSession){
Exit-PSSession    #… User quit & Exit
} Else {
.\set-ntp.ps1    #… Loop the function
}

Enjoy!

If you found this helpful, consider voting for my site in the vSphere-Land Top vBlog 2014 poll here: https://www.surveygizmo.com/s3/1553027/Top-VMware-virtualization-blogs-2014

The post PowerCLI Script to Set DNS and NTP on ESXi Hosts appeared first on VMtoday.

At the same time, I’ve been quietly asked by customers, peers and pundits if VMware’s act is up. They suggest that with competing hypervisors, beefier servers that can do more with less ESXi, the year of VDI – again, maybe, someday, a perceived brain drain, and ‘cloud’ cutting in on VMware’s sales, that maybe the past decade’s monumental shift from physical to virtual courtesy of VMware’s innovation is it for the company.  And then they point out (and I indeed did witness) that with pressure to consume public clouds, customers had begun investigating alternatives on on-premise infrastructure. What I saw was that often these investigations turned to evaluations, which turned to running a production workload in a cloud (like AWS). Pop the cork, let’s celebrate – we’ve checked off the ‘To the Cloud’ checkbox. But when the fizz wore off, it became clear that nothing more was accomplished than making something run ‘there’ instead of ‘here’ (kinda like ‘I lift things up and put them down‘?) with no real strategy developed to actually support, manage, monitor, or migrate that workload going forward.  Putting something in the cloud for the sake of not putting it ‘here’ accomplished little and more often than not, saved nothing.

And so as I reflected on the current state of things I had a decision to make – is VMware a one-trick pony with little potential for the cloudy future, or are we on the cusp of another major shift in technology where automation, seamless management, and intelligent placement of workloads (here, there or anywhere) running in a data center whose boundaries are defined in software, not by the physical infrastructure underlying them.  If the former is true, I had better unhitch my horse and ride off into some cloudy sunset.  But if the latter is true – and I believe it is – the Software Defined Data Center will provide the framework and strategy necessary to manage evolving workloads, changing business demands, increasingly mobile users and morphing infrastructure technologies (hyper-converged server/storage, flash, etc.) in a truly revolutionary way.  As I surveyed the landscape, I saw that no company has done more already to contribute the technology, mindshare, and momentum to the Software Defined Data Center than VMware.  And with that my answer was easy – no one trick, not a single act.  VMware is driving the future, and I want to be a part of it.

So I put my mouth where my money is and joined VMware in December as a Sr. Technical Marketing Manager for the vCloud Suite, the rapidly evolving suite of tools needed to build, manage and orchestrate a true SDDC that enables hybrid cloud and secure mobility for tomorrow’s data centers.  My decision to join VMware has been validated repeatedly over the past two months as I have moved from a long standing member of the community (partner, vExpert, VMUG) to an employee in a company with outstanding individuals (brain drain my ass – try brain gain), an amazing culture of values and dedication, and a ton of exciting innovations just waiting to be released.  At the risk of sounding like a vFanBoy, I am ecstatic to just be on the team, playing my small part as a stage hand in VMware’s exciting second act.

My role at VMware is a bit of a change for me – leaving the always on-call, firefighting and hands-on building that I’ve done for the past decade as an engineer, IT Manager and consultant.  I’ll be drawing on my experience as a partner (I did consulting, engineering, troubleshooting, pre-sales engineering, and a touch of marketing at Clearpath) to focus on helping VMware’s partners and SEs successfully communicate, demonstrate and accelerate SDDC technologies.  Where most of the kick-ass technical marketing team is focused on a specific piece of the technology stack (eg. Availability, Storage, Security, vCenter, etc.), I’ll be paying special attention to how we can help partners and VMware’s field teams easily deploy Proof of Concept (PoC) environments of the vCloud Suite, and be better prepared to help customers realize the benefits of embracing a SDDC mindset through adoption of the vCloud Suite.  I’ll also be contributing to VMware Product Walkthroughs, updates to concept and getting started videos, Technical Papers, blogs, the VMware Mobile Knowledge Portal (Apple and Android – seriously, check it out) and some cool partner focused tools that the tech marketing team will be showing off at PEX.

If you are a VMware partner (or customer for that matter), I’d love to hear from you about your challenges in deploying PoC of the vCloud Suite.  What works, what hurts, what do you think we could do or build for you to help with PoC deployments, or training that you need to be more successful in communicating VMware’s SDDC vision.  I’ll be at VMware Partner Exchange (PEX) next week – grab me if you’re there, I want to hear from YOU!

Before I sign off, I wanted to give a quick word of thanks to Clearpath.  The opportunity I had as Virtualization Practice Manager was outstanding as I was able to work with so many amazing customers on a huge variety of projects, was priviledged to speak at VMUGs, VTUGs, and other events in Virgina, DC, Baltimore, Boston, Philly, Atlanta, and Connecticut, and got to work with some top industry talent at Clearpath.

I’m going to miss seeing many of the great folks I’ve met in Boston during my many trips there, but with such talented individuals and top partners in the area I’m sure we’ll be in touch.  My blogging on this site will probably not be as frequent as it has been over the past couple years (says the guy who hasn’t posted since August – to be fair, life got a bit crazy as my wife was back in the hospital and then on a lengthy bedrest due to her chronic CSF leaks) as I’ll be posting on VMware blogs, but don’t unsubscribe just yet – I’ll still share some of the cool things I learn along my journey on VMtoday.

I couldn’t be more excited and honored to be on a great team at a great company at such a unique time in the industry, happy to play my little part painting the set, setting the stage, supporting an all-star cast of team-mates and customers, and spell-checking the script in VMware’s promising second (and certainly not final) act!

The post A Stage Hand in Act Two – Thoughts on Joining VMware appeared first on VMtoday.