How to patch ESXi with Update Manager

In a previous post, I wrote about how one can go about patching ESXi from the command line using the esxcli software vib command. This is all well and good when you only have a couple of hosts at hand. What would you do instead when faced with a significant number of hosts you need to update? The short answer is, use vSphere Update Manger (VUM). I’ve written about VUM in the past, so I’m skipping the how to install and configure it bits. If you’d like to learn more, have a look at these:

• All You Need to Know About vSphere Update Manager – Part 1
• All You Need to Know About vSphere Update Manager – Part 2

One of the features I like most about vCSA 6.5, is that VUM comes readily installed with the appliance, something that was on everybody’s wishlist since the appliance first shipped out. If you’re running vCenter Server for Windows, well, you’re stuck with installing VUM manually.

Today, I’ll be using vCenter Server Appliance 6.5 to update an ESXi 6.5 GA host to 6.5.0 d. The 4-part update process is as follows:

• Import an ESXi image to VUM
• Create a baseline
• Attach the baseline
• Remediate

vSphere Update Manager

Update Manager comes as a vCenter plug-in which is accessible from a number of places within vSphere Web client. To load it, click on the Update Manger icon from the Home screen or simply select the vCenter Server hostname in Navigator and change over to the Update Manger tab. The interface consists of two main views, Admin and Compliance. The Admin view allows you to configure various aspect of VUM itself as well as manage baselines, the patch repository and ESXi images. The Compliance view, on the other hand, is where you carry out tasks such as attaching baselines, scanning for applicable updates and remediating.

Figure 1 – The Update Manager icon on the Home screen in vSphere Web Client

How to import an ESXi image

So, the first thing we need to do to update ESXi via VUM, is to download the respective image from my.vmware.com and import it to Update Manager.

Step 1 – Highlight the vCenter Server name in Navigator, select the Update Manager tab and click on the Go To Admin View button.

Figure 2 – Changing to VUM’s Admin view in vSphere Web client

–

Step 2 – Once in Admin view, select the ESXi Images tab and click on Import ESXi Image. Doing so, loads another dialog box where you specify the ESXi image (ISO file) you want imported. Click on Browse and navigate to the folder where the image is stored. Select the ISO file and click OK. The file will upload as shown in Fig. 3. The upload progress bar, shows the remaining time and the speed at which the file is being uploaded.

Figure 3 – Importing an ESXi ISO image to VUM

–

Step 3 – Once the ISO is uploaded, details about the ESXi image are displayed as per Figure 4.

Figure 4 – Product and version details for the ESXi image just imported

–

Creating a baseline

Step 4 – Next, we create what’s called a Host Baseline. To do this, we simply right-click on the image just imported and select Create baseline as shown in Figure 5.

Figure 5 – Creating an ESXi host baseline

–

Step 5 – Type in a name for the baseline and press OK. The baseline should now be listed under the Hosts Baselines under Custom as per Fig. 6.

Figure 6 – The freshly created baseline as listed under the Hosts Baselines screen

–

Attaching a baseline

Step 6 – We’re almost there. The idea now is to attach the baseline to one or more hosts. We then run a compliance check to determine if the upgrade or update is actually required. To do this, one must change over to Compliance view. Just hit the Go to compliance view button at the top-right corner as shown in Fig. 7.

Figure 7 – Changing over to Compliance view

The baseline can in fact be attached to a number of objects including a datacenter, cluster or an individual ESXi host. This is what allows you to patch multiple hosts. It is important to note though that you may inadvertently hit hosts not earmarked for updates so be careful when attaching baseline to higher level objects.

In the example that follows, I’ve attached the baseline to one of three ESXi hosts forming a cluster.

Figure 8 – Attaching a baseline to a host

–

Step 7 – Next, we carry out a scan on the host to verify that the update/upgrade is in fact required. From the same screen, click on Scan for Updatesand select Upgrades on the dialog that pops up followed by OK. This will initiate a scan the results of which are displayed under the Compliance Status column after the scan completes.

Figure 9 – Scanning a host for compliance

As expected, the host is found to be non-complaint, meaning that the 6.5.0d update is in fact applicable.

Figure 10 – A non-compliant result indicates that the host is missing one or more updates

How to remediate the host

In this case, remediating is the act of pushing a patch or update to an ESXi host. A host is remediated by clicking on the Remediate button. Alternatively, right-click on the ESXi hostname (or IP address) in Navigator and select Remediate from the Update Manager menu.

Figure 11 – Remediating a host from the context menu

Step 1 – The remediation process starts by selecting the baseline image you want applied. In this case, I’ve selected the one created for the 6.5.0d upgrade.

Figure 12 – Remediation Step 1 – Select the baseline applied

Step 2 – Next, select the host you wish to remediate. In this case, only one host is listed which is the one highlighted in Navigator. If say, the baseline had been attached to a cluster, then you’d have all the hosts within that cluster listed as target objects.

Figure 13 – Remediation Step 2 – Selecting the target to remediate

Step 3 – Accept the EULA by ticking the box at the bottom.

Figure 14 – Remediation Step 3 – Accept the End User License Agreement

Step 4 – The next screen, gives you the option to postpone remediation tasks to a later date and time. You can also set the task to ignore warnings in reference to unsupported devices and such.

Figure 15 – Remediation Step 4 – Scheduling the remediation task (Optional)

–

Step 5 – In all probability, the ESXi being remediated will be hosting VMs. This screen gives you control over what happens to the VMs currently powered on. You can choose to have them powered off, suspended or leave them in their current state. Like it or not, powered on VMs must be migrated or shut down for the remediation process to complete. Your options are to migrate VMs manually to some other host or simply power them off prior to remediating. Alternatively, set the VMs to power down by selecting the Power Off virtual machines option from the VM Power State drop-down box as shown in Fig. 16. You can also set the task to disconnect removable media from any hosted VMs as this may cause the remediation task to stall.

Figure 16 – Remediation Step 5 – Configuring the host remediation options

–

Step 6 – If the host being remediated is a cluster member, you can control various aspects related to clustering as shown in Fig. 17. Further details on each setting are available here.

Figure 17 – Remediation Step 6 – Configuring the cluster remediation options

Step 7 – The Pre-check Remediation tasks runs a series of checks and generates a report of what exactly is carried out on the host. Press Finish to initiate the remediation task.

Figure 18 – Remediation Step 7 – Completing the remediation task

The remediation task’s progress is displayed in the Recent Tasks window in vSphere Web client.

Figure 19 – A remediation task in progress

The host should enter maintenance mode and later disconnect while the update is being applied. It should then reboot and re-connect automatically, assuming the remediation processes succeeded in updating the host.

Figure 20 – A host is disconnected while being updated as can be seen in vSphere client and DCUI

Once remediation completes, you can easily verify that the host is running the latest version by inspecting the host details on the Summary screen. Fig. 21 compares the host’s summary pre and post remediation.

Figure 21 – Comparing ESXi version details pre and post remediation

This VMware KB article helps you correlate build and version numbers if needed. As per the partial table below, you can see that in our case, the ESXi host updated from 6.5 GA to 6.5.0d.

Figure 22 – Correlating ESXi version and build numbers

SQL Server: Restrict Login from Valid Machine IPs Only (Using Logon Trigger)

SQL Server: Restrict Login from Valid Machine IPs Only (Using Logon Trigger)

Today, I have practically learned how to stop valid database users to login on SQL Server instance from invalid machines (IPs).

Process is very simple. Just create a Logon Trigger and check if login user is coming from valid IP or not. If not, then just kick him out.

Download Script 

USE master

GO

-- Create table to hold valid IP values

CREATE TABLE ValidIPAddress (IP NVARCHAR(15)

CONSTRAINT PK_ValidAddress PRIMARY KEY)

-- Declare local machine as valid one

INSERT INTO ValidIPAddress

SELECT ''

-- Create Logon Trigger to stop logins from invalid IPs

CREATE TRIGGER tr_LogOn_CheckIP ON ALL SERVER

    FOR LOGON

AS

    BEGIN

        DECLARE @IPAddress NVARCHAR(50) ;

        SET @IPAddress = EVENTDATA().value('(/EVENT_INSTANCE/ClientHost)[1]',

                                           'NVARCHAR(50)') ;

        IF NOT EXISTS ( SELECT  IP

                        FROM    master..ValidIPAddress

                        WHERE   IP = @IPAddress )

            BEGIN

            -- If login is not a valid one, then undo login process

                SELECT  @IPAddress

                ROLLBACK --Undo login process

            END

    END

Once trigger is created, you can find it under Server Objects -- > Triggers tab

From invalid IP, which you have not added in secure list will see following error on log-in attempt.

Original Post : http://www.connectsql.com/2012/07/sql-server-restrict-login-from-valid.html

Moving a virtualized vCenter Server virtual machine between ESXi/ESX hosts with different processor types (2058684)

---

Document Id

---

2058684

---

Symptoms

---

---

Purpose

---

This article provides steps to move a vCenter Server from one processor type host to another processor type host.

---

Cause

---

---

Resolution

---

Moving vCenter Server when there is shared storage between the hosts

Note: If you are running vCenter Server 5.1 and Single Sign-On (SSO) is on the virtual machine, then moving to another ESXi/ESX host with different hardware may impact SSO. For more information, see After making a change or restarting Single Sign On server system, vCenter Server 5.1.x fails to start (2036170).

Warning: If the vCenter Server virtual machine is running on a Virtual Distributed Switch (vDS), move the vCenter Server virtual machine to a standard vSwitch before proceeding with these steps.

To move vCenter Server between hosts when there is shared storage:

1. Shut down vCenter Server after making a note of the host on which it is running and the datastore on which it is residing. Both can be found on the Summary tab of the vCenter Server virtual machine.
2. Connect with the vSphere Client directly to the source ESXi/ESX host on which vCenter Server was running.
3. Right-click vCenter Server and click Remove from Inventory.
4. Connect with the vSphere Client directly to the destination ESXi/ESX host on which you want the vCenter Server virtual machine to run.
5. Right-click the datastore on which vCenter Server is stored and click Browse datastore.
6. Open the directory for vCenter Server, right-click the .vmx file and click Add to Inventory.
7. Power on the vCenter Server virtual machine.

Note: The first time you power up a moved virtual machine, a uuid.altered message displays. Select I moved it to keep the existing uuid. There may be a slight delay for vCenter Server virtual machine to correct its own location in the vCenter Server database.

Moving vCenter Server when the hosts do not have shared storage

To move vCenter Server between hosts when storage is not shared, perform one of these options:

Note: These options require the MAC of the virtual machine to be manually set. For more information, see Setting a static MAC address for a virtual NIC (219).

• Clone vCenter Server from one host to another:

1. Select the vCenter Server virtual machine from the Inventory.
2. Right-click the virtual machine and click Clone.
3. Select the destination ESXi/ESX host.
4. Power off vCenter Server on the source host.
5. Power on the vCenter Server virtual machine on the destination ESXi/ESX host.

• Export vCenter Server as an Open Virtual Machine Format (OVF):

1. Connect the vSphere Client to the ESXi/ESX host running the vCenter Server virtual machine.
2. Power off the vCenter Server virtual machine.
3. Click File > Export > Export OVF Template.
4. Connect the vSphere Client directly to the destination ESXi/ESX host.
5. Click File - Deploy OVF Template.
6. Power on the vCenter Server virtual machine

Original Post : https://kb.vmware.com/s/article/2058684

Error 1009 in vSphere Web Client

An error that frequently comes up in the vSphere Web Client is Error 1009. This issue occurs in vCenter Server 5.1, 5.5, and 6.0 when navigating through inventory. Typically when this error message pops up you have to refresh your entire session. This issue is almost always caused by cached objects with bad references. These cached objects are stored in the SerenityDB folder under the users name, if by chance any of the cached objects are deleted, but the cache still exists, you get bad Object ID references which will crash the web client.

In order to resolve this issue, you will need to clear the cache by performing the following steps.

Note: It’s always best practice to backup these folders before deleting them.

Windows based vCenter Server 5.x

Step 1. Stop the vSphere Web Client Service

Step 2. Delete the contents of the folders below.

C:\programdata\vmware\vSphere Web Client\SerenityDB\serenity

Step 3. Start the vSphere Web Client Service

Windows based vCenter Server 6.x

Step 1. Stop the vSphere Web Client Service

# cd C:\Program Files\VMware\vCenter Server\bin
# service-control --stop vspherewebclientsvc

Step 2. Delete the contents of the folders below.

C:\programdata\vmware\vCenterServer\data\vSphere Web Client\SerenityDB\serenity

Step 3. Start the vSphere Web Client Service

service-control --start vspherewebclientsvc 

vCenter Server Appliance 5.x

Step 1. Stop the vSphere Web Client Service

# service vsphere-client stop

Step 2. Remove the Contents

# rm -rf /etc/vmware-vsphere-client/SerenityDB/serenity/*

Step 3. Start the vSphere Web Client Service

# service vsphere-client start

vCenter Server Appliance 6.x

Step 1. Stop the vSphere Web Client Service

# service vsphere-client stop

Step 2. Remove the Contents

# rm -rf /storage/vsphere-client/SerenityDB/serenity/*

Step 3. Start the vSphere Web Client Service

# service vsphere-client start

Original Post : http://www.virtually-limitless.com/troubleshooting/vsphere-web-client-displays-error-1009-in-vcenter-server-5-1-5-5-and-6-0/