Category Archives: vCenter - Page 2

Auditing and Alerting on vCenter Permissions – Part 2

In my previous post I discussed auditing permissions in vCenter via PowerCLI.  Going through the process of identifying account and group permissions and what objects they have been set on.  In this second of a two part post, I look at creating a vCenter Alarm in PowerCLI that will trigger when a permission is Added / Removed / or Modified which will then show up in vCenter Alarms.

Part 2 -- Generating a custom alarm on a vCenter permission change

The objective here is not to catch someone out (though you could see how it could help).  The Alarm is by no means meant to be as a deterrent or even used for auditing.  Where it’s useful is as an identifier that a permission add / remove / modification as taken place.  Once triggered a person can review the new permissions and acknowledge the alarm.

Working with vCenter Alarms in PowerCLI hasn’t reached the maturity as many other Cmdlets.  So creating new alarms with PowerCLI is not as straight forward as using a Cmdlet.  To create a new alarm ww have to use the powerful Get-View Cmdlet which exposes us to all the richness of the SDK APIs of vCenter.

Creating an alarm requires a few pieces of information.  First we create the alarm object, give it a name, description, and set its state.

Next we create our Triggers or expressions.  Creating the expression is where the magic lays.  The key piece is the EventTypeID.  This is the specific vCenter event that will trigger the alarm.  I found finding this information through VMware was extremely difficult.    With a little searching though, and playing around, I found the information I was after with Get-View eventManager.

$event = get-view eventManager
$eventman.description.eventinfo | Where-Object {$_.key -like "*permission*"}

Running the above without any filters returned a huge amount of information with possible events to trigger on.  Using the Where-Object Cmdlet I was able to filter the results to anything with the word ‘permission’.  This narrowed down the results to just four.  The key three being  PermissionAddEvent,  PermissionRemoveEvent, and PermissionUpdatedEvent.  Of course if you want to see everything just remove the pipe and everything after it.

With these events and a little more research I had enough information to now create a script for an alarm.  Below I created three expressions.  One for each Permission event and set it’s status to Yellow if triggered.  The alarm is created in the root of vCenter and will propagate down to all objects.

$alarmMgr = Get-View AlarmManager

# Create AlarmSpec object
$alarm = New-Object VMware.Vim.AlarmSpec
$alarm.Name = "Permission Modification"
$alarm.Description = "Track permission changes"
$alarm.Enabled = $TRUE

# Event expression 1 - Permission Added
$expression1 = New-Object VMware.Vim.EventAlarmExpression
$expression1.EventType = "EventEx"
$expression1.EventTypeId = "vim.event.PermissionAddedEvent"
$expression1.ObjectType = "VirtualMachine"
$expression1.status = "Yellow"

# Event expression 2 - Permission Removed
$expression2 = New-Object VMware.Vim.EventAlarmExpression
$expression2.EventType = "EventEx"
$expression2.EventTypeId = "vim.event.PermissionRemovedEvent"
$expression2.ObjectType = "VirtualMachine"
$expression2.status = "Yellow"

# Event expression 3 - Permission Modified
$expression3 = New-Object VMware.Vim.EventAlarmExpression
$expression3.EventType = "EventEx"
$expression3.EventTypeId = "vim.event.PermissionUpdatedEvent"
$expression3.ObjectType = "VirtualMachine"
$expression3.status = "Yellow"

# Add event expressions to alarm
$alarm.expression = New-Object VMware.Vim.OrAlarmExpression
$alarm.expression.expression += $expression1
$alarm.expression.expression += $expression2
$alarm.expression.expression += $expression3

# Create alarm in vCenter root
$alarmMgr.CreateAlarm("Folder-group-d1",$alarm)

# Add action to email alarm
#Get-AlarmDefinition $alarm.Name | New-AlarmAction -Email -Subject "vCenter Permission Modification Occurred" -To [email protected]
#Get-AlarmDefinition $alarm.Name | Get-AlarmAction | New-AlarmActionTrigger -StartStatus 'Green' -EndStatus 'Yellow'

Commented out is also the ability to email a notification out when an event occurs.  This just feels a little overkill but never the less is a notification option.

The beauty of this script is that it can also easily be modified to alarm on any trigger-able event in vCenter.  Whether you need one expression or multiple expressions it’s easily modifiable.

Virten.net has a good article on how to create custom alarms and find events that I used for a reference.  If you don’t want to search for your own events to alarm on.  Virten maintains a database of all events that can be alarmed on.  I’m not sure how current it is but it’s a good starting point.

References

How to create custom vCenter Alarms from Events | Virten.net

Vmware Data Object -- EventAlarmExpression

Auditing and Alerting on vCenter Permissions – Part 1

In this two part post I discuss and cover how to audit vCenter permission using PowerCLI.  How to enumerate basic permissions and then expand it out and send it to a CSV file for further auditing.  In Part 2, I’ll discuss how to create custom alerts using PowerCLI to trigger an event on a vCenter permission modification.

Part 1 -- Auditing vCenter Permissions

Reviewing and auditing vCenter permissions has always been awkward at the best of times.  Unless you’re on top of permissions from day one, over time you can be left with a mess of vCenter permissions.  If you’re not explicitly looking for it you won’t know it either.  This is certainly what I found recently in one of my vCenter environments.

There are a few different ways to view permissions in the C# and Web Client.  You can click on an object and view the Permissions tab or you can go to Roles.  The Roles section is certainly much more useful but still far from ideal.  You have to click on each Role and there is no way to export that information.  Using PowerCLI on the other hand you can consolidate the above two methods into one view and have it exportable.  The quickest and easier way to get started is with Get-VIPermission once connected to a vCenter in PowerCLI.

Get-VIPermission | Format-Table -AutoSize

Get-VIPermission in its default form gives you a quick overview of all Principals / Users defined with explicit permissions along with their Role, whether it’s a group, and if it’s set to propagate down the tree .  Ideally you’ll only have a few groups listed here and nothing else.  Unlike myself, where I had a large amount of individual users explicitly listed on many different objects.

When using Format-Table we loss a little information on the screen. Namely, we can’t see on what objects these permissions are set on.  So we can work with the Get-VIPermission cmdlet to expand it out a little further.

 Get-VIPermission | sort | Format-Table Entity, EntityID, Role, Principal -AutoSize

The two extra values we are looking for here are Entity and EntityID.  In most cases Entity will aid in identifying the vCenter object that has the explicit permissions set on it so you can review.  The Entity could be a Virtual Machine, a Cluster, or a Datastore.  In some cases, though, you will find the Entity is blank.

Again, in my case I had a lot of permissions with a blank Entity.  Using EntityID I could see that the objects appeared to be networking related.  So in this case we need to get a little more creative with the querying of the SDK APIs using Get-View.

Get-VIPermission | sort | ft @{N=”ObjectName”;E={(get-view -Id $_.EntityID).name}}, Entity, EntityID, Role, Principal -AutoSize

This now gets us 95% of the way there.  We use Get-View using the EntityID as the Get-View ID to find the actual name of the vCenter object for that missing Entity value.  In the case of the networking objects we will now get the exact names of the networking switches.

get-vipermission01

Putting it all together.  In this last part I turn the one liner into a little script, make sure the correct snap-in is loaded, make it a little easier to read, and have it output to a CSV file that can be used to audit and review at a later stage.

# Import Snap-in
if ((Get-PSSnapin | where {$_.Name -ilike "Vmware*Core"}).Name -ine "VMware.VimAutomation.Core")

{
Write-Host "Loading PS Snap-in: VMware VimAutomation Core"
Add-PSSnapin VMware.VimAutomation.Core -ErrorAction SilentlyContinue
}

$Date = (get-date).tostring("yyyyMMddHHmm")
$result = Get-VIPermission | sort-object -Property Principal | Select @{N="ObjectName";E={(get-view -Id $_.EntityID).name}}, EntityID, Role, IsGroup, Principal

$result | Export-CSV -Path "$pwd\vCenter_PermissionAudit-$date.csv" -NoTypeInformation -UseCulture

In the above script the results are outputted to a CSV file appended with the date.  The benefit of doing this is you can schedule it to run and now have a history of the state of permissions over time.  Simple as it is, I think it’s really handy.

In the next post I will look at creating a basic Alarm in vCenter that will trigger when a permission is modified on an object.

Patch Release ESXi550-201601501-BG breaks connectivity to vCenter

A few days back I upgraded an ESXi host from ESXi 5.1 to 5.5.  I had downloaded the latest image my vCenter and hardware would support.  The upgrade went well.  Once the host rebooted and was connected back in vCenter I performed a patch scan to see missing patches.

I had about six missing patches.  One being ESXi550-201601501-BG, released only a few days beforehand on 4 Jan.  It was marked as a Critical Bugfix.  As I have always done with Critical Bugfixes I Remediated.  After all, it was Critical and a Bugfix.  Once the host remediated and rebooted I found that I could no longer connect to the host via vCenter.  Receiving the below error when attempting to connect.

Cannot contact the specific host (hostname). The host may not be available on the network, a network configuration problem may exist, or the management services on this host may not be responding.

I opened a C# Client and was able to successfully connect to the ESXi host directly.  So all looked good there.  I decided to look up the KB article of this latest patch (KB 2141207) to see what it fixed.  Nothing came up.  No page could be found!

With a lack of information on this patch the best thing I could do was just to revert the patches.  The fix was simple.  I rebooted the host.  During the Loading VMware Hypervisor I pressed Shift R for Recovery mode.

recovery01

The VMware Hypervisor Recovery screen then appears.  It shows the current build and the previous build that it will Roll Back to.  Pressing Y starts the process.  It was quick and simple and I was back up and going on the previous 5.5 build I had just upgraded to without the addition patches I installed.

recovery02
(The above screenshot was not the host that I Rolled Back but rather is a base 5.1 image)

The KB article page now works.  It is quite clear you shouldn’t update to version 5.5 Update 3b before you upgrade your vCenter to the same version of 5.5 Update 3b.  The interesting note here is that I didn’t realise that I was updating the host to ESXi 5.5 Update 3b.  My upgrade image was ESXi 5.5 Update 3a and I thought I was just installing a critical bugfix patch.  Where I can undone was this was an esx-base patch that brought the effective build number of the ESXi host up to the same level of a full ESXi 5.5 Update 3b build.

So what was actually going on with this patch…

Reading the KB article isn’t entirely obvious what’s going on.  Yes, we now know not to update unless vCenter is on Update 3b but why?  The article states that the patch updates the esx-base vib to resolve an issue when upgrading from ESXi 5.5 to 6.x, where some VMs and objects may become inaccessible or report non-compliant.  That’s clearly, though, not what we’re doing here.

The KB article now has a new link to a second KB article (KB 2140304) which describes the issue you will face if you don’t upgrade vCenter first.  What it describes is that SSLv3 is now disabled by default in this esx-base vib.  So I can only presume that vCenter wants to connect to the ESXi host using SSLv3.

Fortunately the resolution wasn’t that complex.  I was able to resolve the issue and get the host up and going relatively quickly and all within my outage window.  This is the first time I have experienced an ESXi patch break a host.  I’m surprised that a patch is actually changing the default behaviour of a host.  I can understand, and even support, VMware making the change in the latest ISO image build of ESXi 5.5 but not in a patch.

The Lesson…

So the lesson here (and there’s probably a few but I’m going with), stay away from any esx-base patches that have been released post 4 Jan 2016 until vCenter is upgraded to 5.5 Update 3b.

As a side note I would assume SSLv3 could be re-enabled on the host but I haven’t looked into this yet.

References

After upgrading an ESXi host to 5.5 Update 3b and later, the host is no longer manageable by vCenter Server (2140304)

VMware ESXi 5.5, Patch ESXi550-201601501-BG: Updates esx-base (2141207)

VCSA 6.0 Update 1 returns the VAMI

Earlier this month Update 1 for the vCenter Server Appliance 6.0 was released.  With all the cool things coming out of VMworld, like vSphere Integrated Containers, Photon, EVO SDDC, I think Pfft, Update 1 for vCenter and the return of the VAMI was the most exciting thing for me.  But no, seriously, this has been something I’ve been hanging out for.  I always found it odd that it was missing in vCenter 6.  It appears that it was really just a priority issue and not being ready in time for the GA release of 6.0.

If you’re not familiar with VAMI or as it’s better known now as Appliance Management User Interface.  It’s been in the vCenter Server Appliance since version 5.0.  It allowed an easy way to manage host based settings on the appliance such as networking, time & NTP, and the ever important patching.  When I started moving to VCSA 6.0 I had to learn new ways to configure these settings.  So thank God I can now forget.  The Interface has been completely rewritten in HTML5 keeping to the VMware theme.

Photos-000239

Access to the new Appliance Management User Interface (I guess AMUI for short now???) is on the same original port of 5480, (https://<fqdn or ip>:5480).  Log in with the root account and password.

When you log in you are faced with a Summary screen.  Here you get an overview of your Health Status, SSO status, version and Installation Type along with options to Reboot and Shutdown.

Photos-000240

On the left you have the Navigation Pane.  From here you can select and modify a number of different settings.  The Access page allows you to enable SSH and the Shell.  Networking for your DNS and IP details.  Time is a big one.  Prior to this you had to use the Shell to modify NTP settings, I recently wrote up a post on the process to modify VCSA NTP settings with the VAMI.

The Update page is also another important one.  Checking for patches is now no harder than a simple click or better yet a daily scheduled time.  Installation is just as easy with another click.

VMware Appliance Management-000241

The last page is Administration.  Here you can easily change the root password and change the Root Password expiry mode.  Most places may want this on but if your managing many vCenters it can be quite hard to stay on top of and if using strong passwords maybe not that critical.

VMware Appliance Management-000242If you’re currently running a vCenter Server Appliance you can get to version 6.0 Update 1 by either Upgrading or Patching.  The two methods are very different.  The upgrade method, by all accounts, is similar to previous.  It involves deploying a new appliance and performing a migration.  All relatively simply.

The patching process on the other hand is a little less involved and my preferred option.  It requires downloading a much smaller ISO and mounting it to the appliance.  You’ll need to already be on version 6.0.  As mentioned above the VAMI doesn’t currently exist so it has to be patched from the console.  I’ve written previously about patching a vCenter Server Appliance from the Shell.  The process is essentially the same and worth a look if you’re not familiar with it.

I highly recommend reading the Release Notes and looking at patching up to this latest version.  It resolves a number of outstanding issues from previous releases.  JRE has been updated along with SSLv3 being disabled.  My initial home lab upgrade took only 10 minutes.

So get to it!

References

Update for VMware vCenter Server Appliance 6.0 Update 1 (2119924)

VMware vCenter Server 6.0 Update 1 Release Notes

Increase vSphere Web Client Idle Timeout on VCSA 6

What I really like about the vCenter C# Client was that you could stay logged indefinitely.  Maybe not the best thing from a security stand point but it was damn convenient.  The vSphere Web Client on the other hand has always had an idle timeout value.  From a home lab point of view it’s really frustrating constantly being logged out.

The default idle timeout in the vCenter Server Appliance 6 (VCSA) is 120 minutes.  I know of no way to modify this via the Web Client itself but it is modifiable via the Shell.  The timeout value is contain in the webclient.properties file.  The location of this file has changed from previous versions of the VCSA.    Prior to version 6 it was found in /var/lib/vmware/vsphere-client/.  In version 6 it’s found in /etc/vmware/vsphere-client/.

At the Command prompt of the VCSA type the following to enable Shell access.

Command> shell
Shell is disabled.
Command> shell.set --enabled true
Command> shell
vc01:~ #

Now at the Shell type the following below and locate session.timeout.

cat /etc/vmware/vsphere-client/webclient.properties

You should find something similar to session.timeout = 120 as this is the default value.

Make a backup copy of webclient.properties.

cp /etc/vmware/vsphere-client/webclient.properties /etc/vmware/vsphere-client/webclient.properties.bak

If you’re comfortable using an editor like VI go ahead and use that to increase or decrease the value in minutes.  The timeout value, though, can quickly and easily be modified using the sed command.

The sed command below locates the specific string session.timeout = 120 and replaces it with session.timeout = 1440, which is 24 hours.  Change 1440 to however many idle minutes you want.  If sed doesn’t find the specific string, don’t worry, it won’t modify anything.  To set the client to never idle timeout set the value to 0.

sed -i “s/session.timeout = 120/session.timeout = 1440/g” /etc/vmware/vsphere-client/webclient.properties

Run the cat command again and check that the session.timeout value has changed.

cat /etc/vmware/vsphere-client/webclient.properties

If the session.timeout value has been modified correctly we now have to stop and restart the vsphere-client service by running the following commands below.  I covered stopping and starting services on a VCSA in a previous post.

service-control --stop vsphere-client
service-control --start vsphere-client

Wait a few minutes for the service to start up fully and open a new browser windows to the vSphere Web Client.  It should now be running with a new idle timeout.

As a general disclaimer you should only be going into the Shell on the VCSA if you are comfortable with what you are doing.  Of course make a backup of any files you are modifying and, of course, to play it safe take a snapshot of the VCSA VM.

References

Configure the vSphere Web Client Timeout Value

Stopping and Starting Services on vCenter Service Appliance 6 (VCSA)

In my previous post I wrote about patching a VCSA box.  At the end of that patching processes a reboot (according to VMware) is an optional step.  However, in my case, the vCenter Web Services didn’t appear to have restarted correctly.  A reboot ultimately did resolve that issue for me, but it did start me thinking about how would I go about restarting VCSA services if the Web Client was down.  It turns out vCenter 6 has a new recommended way of restarting services using the Service Control command for both the VCSA and the Windows version.

As with my post on modifying NTP settings.  Restarting services can be done via two methods, the Web Client or via the console.  Method 1 is the easiest when access to the Web Client is there.  Method 2 relies on using the VCSA console when access to the Web Client doesn’t exist or is lost.k

Method 1.
Restarting services via the Web Client

On the Home screen of the Web Client select Administration -> System Configuration

enable_ssh-000182

Click on the Services button on the right pane.

restart_ssh-000210

As I’ve mentioned previously finding what you want in the Web Client isn’t always intuitive as you might think.  Clicking on Services in the left pane isn’t what you want.  Rather clicking on the Services tab button on the right pane gives you a better overall status of services.

restart_ssh-000219

From here was can right click on any services, start, stop, restart, edit startup, and change settings on that service.  Not all services have modifiable settings via the Web Client.  This options will show up grayed out.  Once you change the state of a service you’ll find you have to refresh the page for the next state to be displayed correctly.

restart_ssh-000220

Method 2.
Restarting services via the Console

I’ll assume you already know how to enable and have access to SSH or at least the Remote Console.  If not I cover enabling SSH here.

You may come across doco that says you have to enable and enter the pi shell / bash, but this isn’t required.  Everything can be done from the VMware Command prompt

We can start of by running a command that simply lists services.

Command> service-control --list

This will list all vCenter specific services.  We can then run service-control --status for a bit of a messy view of what’s currently Running and Stopped.

Command> service-control --status

Unlike the Web Client there is no restart Service Control switches, Only start and stop.  To stop a service we run the below at the prompt.  servicename being the name of a service displayed using --list

Command> service-control --stop servicename

or to start

Command> service-control --start servicename

You can also use the --all switch in place of servicename.  I see this as a bit of a catch all.  Using this switch will only start services that have a startup type of Automatic and are currently stopped.  If a service is currently running it will be skipped.  This is a great way to get everything back up and running quickly.

Command> service-control --start --all

The reverse is true when using --all to stop services.  All services that have a startup type of Automatic and are currently running will attempt to be stopped.  Everything else will be skipped.

Command> service-control --stop --all

There are two final switches that can also be used with the --all.  --ignore and --dry-run.  The --ignore will continue to start or stop all services if an error is encountered at any point.  --dry-run will display what actions the take place with the service without actually changing anything.

Command> service-control --start --all --ignore
Command> service-control --start --all --dry-run

References

Stopping, starting, or restarting VMware vCenter Server Appliance 6.0 services (2109887)

 

Patching vCenter Server Appliance 6 (VCSA)

The biggest thing I miss from the v5.x release of the vCenter Server Appliance was the VMware Appliance  Management Interface (VAMI).  I first realised it was missing in VCSA 6 when I needed to modify NTP settings.  What I liked about the VAMI was that it could auto check and install patches.  With it now removed we’re back to a manual check and apply process 🙁

So to get started… The easiest way to check what build you are on is in the vSphere Web Client.  Navigate to vCenter Inventory Lists -> vCenter Servers and click on your VC.

Windows 8.1 Pro - VMware Workstation-000174

Once you know what build you are on head over to Product Patches at https://my.vmware.com/group/vmware/patch#search

Select VC as the product and 6.0.0 as the version.  Note the releases.  One will be for the Windows version and one for the Appliance.  Windows versions still require downloading the full product to update.  While the Appliance gets away with a smaller yet still relatively large 1 GB patch file.  Both releases, though, can still apply minor patches individually.

https___my.vmware.com_group_vmware_patch#search-000175

Download the 1 GB ISO file (or whatever is current at the time).  Mount the ISO to the vCenter Appliance VM as you normally would with any ISO file.

vcsa_patch-000176

Now login to a console session on the Appliance and run the following command

software-packages install --iso --acceptEulas

vcsa_patch-000177

The --acceptEulas is optional.  If you choose to leave it out you will have to scroll through the VMware End User License Agreement and type yes to accept.

Command> software-packages install --iso
[2015-06-13T12:21:59.164] : Staging software update packages from ISO
[2015-06-13T12:21:59.164] : ISO mounted successfully
[2015-06-13 12:21:59,076] : Running pre-stage script…..
[2015-06-13T12:22:00.164] : Verifying staging area
[2015-06-13T12:22:00.164] : Validating software update payload
[2015-06-13T12:22:00.164] : Validation successful
VMWARE END USER LICENSE AGREEMENT

Do you accept the terms and conditions? [yes/no] yes

This process will now automatically Stage the patches to the VC and proceed to immediately install.  During this process management to the VC will be lost.  So keep this in mind for your users.

Once complete you will receive a message that a Reboot is required to complete the installation.  According to VMware doco this is an optional step.  That said, after my upgrade completed, I still had no management connectivity via the Web Client or C# client and so ran shutdown reboot -r and proceeded to reboot the appliance.

[2015-06-13T12:29:53.164] : Packages upgraded successfully, Reboot is required to complete the installation.
Command> shutdown reboot -r “I have been patched”

Additional Commands (optional)

If you want to see the last patches that were applied run the below command

Command> software-packages list --history
[2015-06-13T12:54:03.164] :
‘Name’ ‘Install Date’
VC-6.0.0a-Appliance-FP 2015-06-13 12:29:52

References

VMware reference doco
Patching the vCenter Server Appliance

 

 

Enable SSH on vCenter Server Appliance 6 (VCSA)

If you’re running the Appliance version of vCenter 6 at some stage you may want console access via SSH.  When you install VCSA 6 for the first time you have the option during installation to enable SSH.  Depending on your security stance you may have left SSH off and now you want it on.

There are a few different methods for enabling SSH on VCSA.  The below two methods both use the web client.

Method 1.
Directly enabling SSH in the Web Client.

This method is probably the easiest and quickest way.  The settings just happen to be in a non-intuitive location.

On the Home screen of the Web Client select Administration -> System Configuration

enable_ssh-000182

Select Nodes and right click on your vCenter server.

enable_ssh-000179

Select Edit Settings

enable_ssh-000181

Select the Checkbox Enable SSH login

enable_ssh-000180

Click OK.

You should now be able to SSH to the vCenter name or IP.

 

Method 2.
Enabling SSH via the Remote Console.

Navigate to your vCenter Appliance VM.  Click on Launch Remote Console.

enable_ssh-000184

Press ALT + F1 to get a login TTY session and login as root

enable_ssh-000183

Run the below commands to enable SSH.  ssh.get shows the current status.  ssh.set allows you to change the state of SSH.  Use ‘false’ instead of true to disable SSH.

Command> ssh.get
Enabled: False
Command> ssh.set --enabled true
Command> ssh.get
Enabled: True
Command>

The above methods takes effect immediately, no need to reboot.  When disabling SSH, current sessions stay active and don’t end.  So if someone has an open SSH session they won’t be kicked out until they logoff or their session times out.

References

VMware vCenter 6 Documentation
Edit Access Settings to the vCenter Server Appliance

 

PowerCLI A Syslog Server To All ESXi Hosts In vCenter

I was recently tasked with configuring all ESXi hosts within a number of vCenter environments to use a Syslog Server.  Each of these environments contained numerous clusters and ESXi hosts.  Too many to manually want to configure a Syslog Server by hand.  Using our lab environment I played around with a few different ways of quickly pushing out some Syslog settings via PowerCLI.

I came across two different PowerCLI cmdlets that would do the job.  The  first was Set-AdvancedSetting and the second was Set-VMHostAdvancedConfiguration.  The latter being a deprecated cmdlet.  Both cmlets do the job equally well.  Ideally you would want to be using the newer Set-AdvancedSetting cmdlet rather than the deprecate one.

Where I didn’t like the newer Set-AdvancedSetting was that it would ask for confirmation before making a change.   I didn’t fully realise how annoying this would be till after I had wrote my script.   Once a connection to a vCenter is made in PowerCLI the script I created prompts for a Syslog Server then gets all ESXi hosts in the vCenter, applies the Syslog Server value, reloads syslog, and finally opens the syslog ports.  All simple and basic except that you will be prompted to apply the syslog value to each host.  Fine if you’re very cautious or if you want to omit specific hosts.

Perform operation?
Modifying advanced setting ‘Syslog.global.logHost’.
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is “Y”):y

I then decided to test out Set-VMHostAdvancedConfiguration and found I preferred this cmdlet over Set-AdvancedSetting.  Each time it set a syslog value on a host it would flash up a friendly yellow little warning and go ahead with the change.  Much more convenient for large changes.  At some point in a future PowerCLI version I assume this cmdlet won’t work but until then it works a treat.

WARNING: Set-VMHostAdvancedConfiguration cmdlet is deprecated. Use
Set-AdvancedSetting cmdlet instead.

The below code block uses the newer Set-AdvancedSetting cmdlet.

# This script will set a Syslog Server all all ESXi hosts within a vCenter once connected.
# Uses the newer Get / Set-AdvancedSetting cmdlet.
# This cmdlet will require confirmation for each host being modified.
# Created by Mark Ukotic
# 04/04/2015

Write-Host "This script will change the Syslog Server on all hosts within a vCenter, restart Syslog, and open any required ports."

Write-Host

$mySyslog = Read-Host "Enter new Syslog Server. e.g. udp://10.0.0.1:514"

Write-Host

foreach ($myHost in get-VMHost)
{
#Display the ESXi Host being modified
Write-Host '$myHost = ' $myHost

#Set the Syslog Server
$myHost | Get-AdvancedSetting -Name Syslog.global.logHost | Set-AdvancedSetting -Value $mySyslog

#Restart the syslog service
$esxcli = Get-EsxCli -VMHost $myHost
$esxcli.system.syslog.reload()

#Open firewall ports
Get-VMHostFirewallException -Name "syslog" -VMHost $myHost | set-VMHostFirewallException -Enabled:$true
}

This second code block uses the deprecated Set-VMHostAdvancedConfiguration, which I prefer.

# This script will set a Syslog Server all all ESXi hosts within a vCenter once connected.
# The deprecated Set-VMHostAdvancedConfiguration cmdlet is used.
# Seems to run a little more cleaner with this cmdlet and doesn't ask for confirmation
# Created by Mark Ukotic
# 04/04/2015

Write-Host "This script will change the Syslog Server on all hosts within a vCenter, restart Syslog, and open any required ports."

Write-Host

$mySyslog = Read-Host "Enter new Syslog Server. e.g. udp://10.0.0.1:514"

Write-Host

foreach ($myHost in get-VMHost)
{
#Display the ESXi Host being modified
Write-Host '$myHost = ' $myHost

#Set the Syslog Server
Set-VMHostAdvancedConfiguration -Name Syslog.global.logHost -Value $mySyslog -VMHost $myHost

#Restart the syslog service
$esxcli = Get-EsxCli -VMHost $myHost
$esxcli.system.syslog.reload()

#Open firewall ports
Get-VMHostFirewallException -Name "syslog" -VMHost $myHost | set-VMHostFirewallException -Enabled:$true
}

Modifying vCenter Server Appliance 6 (VCSA) NTP settings

For some unknown reason that I’m yet to learn.  The VAMI in vCenter Server Appliance 6 has been removed.  VAMI is the management interface that you usually connect to on port 5480 for most VMware appliances.  Prior to vCenter 6 you could connect to your VCSA appliance on port 5480.  In the VAMI you could check that status of the appliance services, change its network settings, perform updates, and change NTP settings.

vcsa_ntp0

It’s this last  setting that quickly alerted me to this change shortly after deploying my first VCSA 6.  During the initial deployment of my vCenter Appliance I would specify my NTP servers when prompted.  During my first two attempts the deployment would error out and fail because my NTP time sources specified were timing out.  So on the third attempt I decided to skip the NTP servers and configure them post install.

Here in lies the new way of modifying NTP settings on a vCenter 6 Appliance.

Firstly we need to log into the appliance via SSH or via the console using the root account.

vcsa_ntp01

We will be presented with a VMware shell with instructions on how to enable BASH.  For this task and many other vCenter tasks the current shell is good enough.  From here we can run our NTP commands.  If we type ntp followed by the ‘TAB’ key we get a list of ntp commands we can run.

vcsa_ntp02

Typing ntp.get lists the current status of NTP and what NTP servers are configured.  In this case the status is Down and no servers have been configured.

Command> ntp.get
Config:
Status: Down
Servers:
Command>

As we have no NTP servers listed we can use the ntp.server.set command.  This will override any current servers that may also be listed.

Command> ntp.server.set --servers 0.au.pool.ntp.org
Command> ntp.get
Config:
Status: Down
Servers: 0.au.pool.ntp.org
Command>

We now have one NTP time source set.  If we wish to make modifications to the list of servers without overriding them we can use the ntp.server.add command.

Command> ntp.server.add --servers 1.au.pool.ntp.org
Command> ntp.get
Config:
Status: Down
Servers: 0.au.pool.ntp.org 1.au.pool.ntp.org
Command>

With our NTP time sources set we now enable and start NTP using the command timesync

Command> timesync.set --mode NTP
Command> timesync.get
Config:
Mode: NTP

Command> ntp.get
Config:
Status: Up
Servers: 0.au.pool.ntp.org 1.au.pool.ntp.org

And that’s really all that is required.  Relatively straight forward to perform.  From my point of view it’s certainly not as convenient as using the VAMI web portal from previous versions.  As mentioned above.  I don’t know why it was removed.  Perhaps time constraints meant that it will be introduced in a future update.  Or perhaps it’s just hidden on a different port I’m not aware of.  In any case it would be nice to officially know.

Note; ‘--servers’ above is a double dash.

References

Add or Replace NTP Servers in the vCenter Server Appliance Configuration