Update Manager Cmdlets are now included in PowerCLI since 6.0 R2

 Allgemein, Knowledge Base, Updates, VMware, VMware Partner, VMware Virtual Infrastructure, vSphere  Kommentare deaktiviert für Update Manager Cmdlets are now included in PowerCLI since 6.0 R2
Jan 122016
 

It’s always great to have new features, functionality, and updates included in releases of any product. One of the changes to PowerCLI in 6.0 Release 2 is that we have included the vSphere Update Manager cmdlets into the installer. No longer will you have to search through MyVMware to find the additional executable to install the Update Manager cmdlets.

How do I install VUM cmdlets now?

You will now see the VUM cmdlets in the installation wizard, just as we introduced the vCloud Air and vCD PowerCLI cmdlets in the wizard a few releases ago. You can just select the drop-down next to the “vSphere Update Manager” feature and choose to install it or not during PowerCLI installation. The VUM cmdlets are selected to be installed by default.

What if I already have VUM cmdlets installed?

If you already have VUM cmdlets for PowerCLI installed, you will need to uninstall them before installing PowerCLI 6.0 R2 or higher

What versions of VUM does this support?

VUM for PowerCLI included in the installer works back to Update Manager 5.5. If you are running an older version of Update Manager, you will need to install PowerCLI 6.0 R2 or higher (de-selecting the Update Manager cmdlets during installation) and then install the old VUM PowerCLI cmdlets executable from MyVMware which corresponds to your version of VUM.

We hope you enjoy the new functionality and having one less thing to worry about, find, and install. What are your thoughts on the current version of PowerCLI? What else would you like to see in the future?

Have you updated to PowerCLI 6.0 R3 yet? Why not? Did you know it supports all the way back to vCenter Server 5.0? Download it today from here and gain the latest benefits.

The post Update Manager Cmdlets are now included in PowerCLI since 6.0 R2 appeared first on VMware PowerCLI Blog.

Updating to VMware Tools 10 – Must Read

 Allgemein, Knowledge Base, Updates, VMware, VMware Partner, VMware Virtual Infrastructure, vSphere  Kommentare deaktiviert für Updating to VMware Tools 10 – Must Read
Nov 052015
 

In September we announced that VMware Tools 10.0.0 Released and that VMware is now shipping VMware tools outside of the vSphere releases. Since then, we have received a lot of feedback from the community, customers, and internal folks alike. I would like to let everyone know that we have listened and we continue on our path to make VMware Tools lifecycle (and ESXi lifecycle for that matter) easier and less painful than how it may appear today.

 

Before I get too far into this post, I thought I would add a FAQ section to try to answer some of the more common questions we have received:

FAQ

    • Where is the VMware Tools Download?
      • https://my.vmware.com/web/vmware/details?downloadGroup=VMTOOLS1000&productId=491
    • Why aren’t all the files from the ESXi tools directory found in the VMware Tools Download?
      • As of November 2nd, 2015 they are! We listened loud and clear. Now when users go to download VMware tools they will be presented with the option of downloading a VMware Tools packages ZIP or TAR.GZ file. Both have the exact same content but are in two separate formats for users to choose from. Once downloaded and extracted, you will find all the files that you would normally see within an ESXi host’s tools directory. This just makes life easier for the admins to have everything in one place.
    • I see files for Legacy VMware Tools packages for Windows and Netware OS, what is that?
      • These files are for any virtual machines running pre-Windows 2000 operating systems, hence the term ‘legacy’ if you have any of these in your environment, you will want to copy and paste these folders into each of your hosts, or into the shared product locker.
    • Can this set of VMware Tools be used with Update Manager (VUM)?
      • Yes it can, however I will explain how this works further down in the blog post. Click here to jump
    • Can you use the VM setting “Check and upgrade Tools during Power Cycling”?
      • Yes you can, you must first ensure that the VMware Tools files are in their correct locations (either within the host or in a shared product locker location). You can use PowerCLI to update this setting for every single virtual machine with the following code:

    # Create the config object

    $Config = New-Object VMware.Vim.VirtualMachineConfigSpec
    $Config.Tools = New-Object VMware.Vim.ToolsConfigInfo
    $Config.Tools.ToolsUpgradePolicy = “UpgradeAtPowerCycle”

     

    # run through each virtual machine. ***NOTE*** this can be tweaked to look for specific VMs or groups of VMs

    Get-View -ViewType VirtualMachine | foreach {
    $_.ReconfigVM($Config)
    }

    #you can then disable this and set it back to the default value with this:

    $Config = New-Object VMware.Vim.VirtualMachineConfigSpec
    $Config.Tools = New-Object VMware.Vim.ToolsConfigInfo
    $Config.Tools.ToolsUpgradePolicy = “manual”

    Get-View -ViewType VirtualMachine | foreach {
    $_.ReconfigVM($Config)
    }

      • My VMs are not showing as out-of-date since I updated my VMware Tools files, why is that?
        • VMware Tools versions are recorded in each virtual machine’s VMX file. A Baseline query uses the version of VMware Tools found on the host (or sharedLocker) to determine if a VM’s Tools are out of date. This only happens when a VM is powered-on, vMotioned, or when the VMTools service is restarted within the guest VM. Currently the VM’s cached status can be refreshed via a vMotion or a full VM power-off/power-on or by restarting “VMtools”. We’ve recognized this as a limitation and are working to make this easier in a future release. For now, if you choose to restart the service to have it update the version check, here is a little PowerCLI script that can help you for Windows machines:

      # Get all Virtual Machines that have the “windowsguest” attribute in ExtensionData.Guest.GuestFamily, and that are powered on

      $windows = Get-View -ViewType VirtualMachine | where {$_.guest.guestfamily -eq “windowsguest” -and $_.runtime.PowerState -eq “poweredOn”}

      # Foreach virtual machine from the results, run “restart-service” within the guest **Note the username and password will need to be updated. if all vm’s have the same admin account or an Admin AD account, use that… you can also use the –GuestCredential if you have the credentials (get-credential) stored in a variable, in place of the –GuestUser and –GuestPassword parameters. This way you won’t have to place your password in a script.

      foreach ($vm in $windows) { Invoke-VMscript -ScriptText “restart-service -Name VMTools” -VM $vm.name -GuestUser “administrator” -GuestPassword “VMw@re123″ -errorAction SilentlyContinue }

      #**Note that I use the –ErrorAction SilentlyContinue parameter. This is because Invoke-VMScript uses VMtools to invoke the command in the guest. Since we are restarting the VMTools service, this command will come back with an error, however if you check the windows logs you’ll see the command functions properly and this error is only because the Tools connection is being reset during the command execution (this is normal when running the restart-service VMTools command)

      • Can you use this with AutoDeploy?
        • Yep! Using this with the shared productlocker will allow you to use this with Auto Deploy. Click here to jump
      • Which version of tools should I use? VMware Tools 10 was released before vSphere 5.5u3 but u3 has a lower build number?
        • If you are trying to decide which version of tools to use, know that you can use either version without problems. However the out-of-band release will most likely be the latest release. In general, a single version of tools used in a vSphere release may be older than what is seen on the VMware Tools download page if it ran into the release freeze before the out-of-band version came out. (it’s a lot easier to ship newer versions of VMware Tools outside of ESXi)
      • Is there a VMware tools VIB that can be downloaded and used?
        • There is not. VIBs (vSphere Installation Bundles) are convenient when distributing a collection of files. However, most VIBs are relatively small. VMware Tools would be roughly 150 Megabytes and this is not conducive to a clean and small deployment of ESXi. Note that a VIB is similar to a ZIP archive which means that not only would distributing tools as a VIB require 150MB for the VIB itself, but ~150MB more once extracted to the VMware Tools folder, increasing the size of ESXi by 50%.

      Getting Started

      By default, ESXi includes VMware Tools under the /productLocker folder (which is actually a Symlink to the location on it’s local storage.. see the image below). When running ‘ls –n’ you will see that productLocker (cyan) just points to /locker/packages/5.5.0 (dark blue meaning the path exists. You also can tell this is an ESXi 5.5 host). ‘ls –n /productLocker’ will return only that line and be a little easier on the eyes for those who are not as familiar with unix.

      Inside of the given folder are two other folders: “floppies” and “vmtools” these contain all necessary ISOs and files to allow VMware tools to be installed and updated on each supported VM on the host. If you are updating VMware Tools packages on each individual ESXi host, the new files would go in these two folders.

      Know that if you are not just updating the tools within each ESXi Host, there are several steps you will need to take (these are also discussed in the FAQ as well as below in the AutoDeploy/Host Profiles section):

      1. Update the UserVars.ProductLockerLocation
      2. Add the VMware tools to it’s own folder in a shared datastore
      3. Update the ESXi Symlink that points to the location of the files on the shared datastore (OR) restart the ESXi host to have it update itself automatically

      How Update Manager (VUM) works with VMware Tools Updates

      To better understand how to make the VMware Tools lifecycle easier, you must first understand how VMware’s products, like Update Manager, interact with the environment. Update Manager does a great job of patching hosts and updating VMware Tools, but what’s actually going on under the covers? Update Manager uses APIs to talk to each ESXi host to perform remediation tasks. What this means is that Update Manager will use whichever version of VMware tools is installed locally on each host, unless that host is using a shared productLocker. VUM uses whatever configuration the host has, it does not have a Tools repository or additional logic to point to some other location. Keep in mind that if we are trying to update VMware Tools via Update Manager, we will either need to add the new version of VMware Tools to each host individually, or configure a shared product locker and point each ESXi host to it.

      Once the VMware Tools are placed in the appropriate location, Update Manager will be able to perform updates of VMware Tools for each virtual machine in vCenter.


      How Auto Deploy/ Host Profiles works with Shared ProductLocker

      As I’ve mentioned in previous blog posts, when using Auto Deploy you have two options for ESXi:

      • Standard ESXi image
      • xxxx-no-tools image

      The Standard ESXi image is what you find in any other deployment method, or if you were to perform the ESXi default manual installation. This will install VMware Tools on the ESXi host and the total image size will be roughly 300 Megabytes.

      The xxxx-no-tools image is exactly that; an ESXi image without the VMware Tools folders. This drops the size of the installation in half down to roughly 150 Megabytes. There are definitely many PROS to doing it this way: Faster boot times, less network saturation, single location for VMware Tools (easier to manage Tools binaries), etc. However, just using xxxx-no-tools image with Auto Deploy is not enough, you must also configure your Host Profiles to point to the Shared Product Locker.

      During your Host Profile creation, ensure that you add the ProductLockerLocation information into the profile. In the “Edit Host Profile” window, expand the “Advanced Configuration Settings”, “Advanced Options”, and “Advanced configuration option”. Click the Green “Add” button to add an additional advanced option.

      In the Advanced Option drop-down box, select “Configure a fixed option”. The name of the option should be “UserVars.ProductLockerLocation” and the value of the option should be “/vmfs/volumes/<name of shared datastore>/<name of product locker folder>” in my case it was /vmfs/volumes/CPBU_PM_PMM1/productLocker. ***You need to make sure that this Datastore/folder is a shared datastore accessible by each host that will be using this Host Profile***. Also note that the value is CASE SENSITIVE!!!

      Once you have your Host Profile created the Host Profile, you can attach it to a cluster or an Auto Deploy rule and you are good to go. Just make sure that the Datastore/folder includes the two folders ‘floppies’ and ‘vmtools’ and their contents from the VMware Tools download ZIP/TAR.GZ

      When the ESXi hosts are booted via Auto Deploy and the Host Profile is applied, the symlink will be updated to reflect the shared product locker location and all hosts booting this way will share this location.

      Can we Automate Some More Please?

      While I mentioned earlier in the post about this, I will mention again, that we are aware of the effort that takes place to update VMware Tools and we are working to make this easier on the customers in a future release. Rest assured, we are working on it. However, until then I have created a script that can help assist you in your efforts. It can be found on my personal blog (http://www.vtagion.com) as the script is not supported by VMware and has not been tested by GSS. However, I have used it several times in both of my environments without problem. As always when using someone else’s scripts you should read through every line and make sure you understand what is happening (BEFORE) running the script; secondly, you should always test things (OUTSIDE) of production. That being said, you can find the script and read more about it HERE.

      Additional Resources

      General VMware Tools installation instructions (1014294)

      http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1014294

      The post Updating to VMware Tools 10 – Must Read appeared first on VMware vSphere Blog.

      Updating to VMware Tools 10 – Must Read

       Allgemein, Knowledge Base, Updates, VMware, VMware Partner, VMware Virtual Infrastructure, vSphere  Kommentare deaktiviert für Updating to VMware Tools 10 – Must Read
      Nov 052015
       

      In September we announced that VMware Tools 10.0.0 Released and that VMware is now shipping VMware tools outside of the vSphere releases. Since then, we have received a lot of feedback from the community, customers, and internal folks alike. I would like to let everyone know that we have listened and we continue on our path to make VMware Tools lifecycle (and ESXi lifecycle for that matter) easier and less painful than how it may appear today.

       

      Before I get too far into this post, I thought I would add a FAQ section to try to answer some of the more common questions we have received:

      FAQ

        • Where is the VMware Tools Download?
          • https://my.vmware.com/web/vmware/details?downloadGroup=VMTOOLS1000&productId=491
        • Why aren’t all the files from the ESXi tools directory found in the VMware Tools Download?
          • As of November 2nd, 2015 they are! We listened loud and clear. Now when users go to download VMware tools they will be presented with the option of downloading a VMware Tools packages ZIP or TAR.GZ file. Both have the exact same content but are in two separate formats for users to choose from. Once downloaded and extracted, you will find all the files that you would normally see within an ESXi host’s tools directory. This just makes life easier for the admins to have everything in one place.
        • I see files for Legacy VMware Tools packages for Windows and Netware OS, what is that?
          • These files are for any virtual machines running pre-Windows 2000 operating systems, hence the term ‘legacy’ if you have any of these in your environment, you will want to copy and paste these folders into each of your hosts, or into the shared product locker.
        • Can this set of VMware Tools be used with Update Manager (VUM)?
          • Yes it can, however I will explain how this works further down in the blog post. Click here to jump
        • Can you use the VM setting “Check and upgrade Tools during Power Cycling”?
          • Yes you can, you must first ensure that the VMware Tools files are in their correct locations (either within the host or in a shared product locker location). You can use PowerCLI to update this setting for every single virtual machine with the following code:

        # Create the config object

        $Config = New-Object VMware.Vim.VirtualMachineConfigSpec
        $Config.Tools = New-Object VMware.Vim.ToolsConfigInfo
        $Config.Tools.ToolsUpgradePolicy = “UpgradeAtPowerCycle”

         

        # run through each virtual machine. ***NOTE*** this can be tweaked to look for specific VMs or groups of VMs

        Get-View -ViewType VirtualMachine | foreach {
        $_.ReconfigVM($Config)
        }

        #you can then disable this and set it back to the default value with this:

        $Config = New-Object VMware.Vim.VirtualMachineConfigSpec
        $Config.Tools = New-Object VMware.Vim.ToolsConfigInfo
        $Config.Tools.ToolsUpgradePolicy = “manual”

        Get-View -ViewType VirtualMachine | foreach {
        $_.ReconfigVM($Config)
        }

          • My VMs are not showing as out-of-date since I updated my VMware Tools files, why is that?
            • VMware Tools versions are recorded in each virtual machine’s VMX file. A Baseline query uses the version of VMware Tools found on the host (or sharedLocker) to determine if a VM’s Tools are out of date. This only happens when a VM is powered-on, vMotioned, or when the VMTools service is restarted within the guest VM. Currently the VM’s cached status can be refreshed via a vMotion or a full VM power-off/power-on or by restarting “VMtools”. We’ve recognized this as a limitation and are working to make this easier in a future release. For now, if you choose to restart the service to have it update the version check, here is a little PowerCLI script that can help you for Windows machines:

          # Get all Virtual Machines that have the “windowsguest” attribute in ExtensionData.Guest.GuestFamily, and that are powered on

          $windows = Get-View -ViewType VirtualMachine | where {$_.guest.guestfamily -eq “windowsguest” -and $_.runtime.PowerState -eq “poweredOn”}

          # Foreach virtual machine from the results, run “restart-service” within the guest **Note the username and password will need to be updated. if all vm’s have the same admin account or an Admin AD account, use that… you can also use the –GuestCredential if you have the credentials (get-credential) stored in a variable, in place of the –GuestUser and –GuestPassword parameters. This way you won’t have to place your password in a script.

          foreach ($vm in $windows) { Invoke-VMscript -ScriptText “restart-service -Name VMTools” -VM $vm.name -GuestUser “administrator” -GuestPassword “VMw@re123″ -errorAction SilentlyContinue }

          #**Note that I use the –ErrorAction SilentlyContinue parameter. This is because Invoke-VMScript uses VMtools to invoke the command in the guest. Since we are restarting the VMTools service, this command will come back with an error, however if you check the windows logs you’ll see the command functions properly and this error is only because the Tools connection is being reset during the command execution (this is normal when running the restart-service VMTools command)

          • Can you use this with AutoDeploy?
            • Yep! Using this with the shared productlocker will allow you to use this with Auto Deploy. Click here to jump
          • Which version of tools should I use? VMware Tools 10 was released before vSphere 5.5u3 but u3 has a lower build number?
            • If you are trying to decide which version of tools to use, know that you can use either version without problems. However the out-of-band release will most likely be the latest release. In general, a single version of tools used in a vSphere release may be older than what is seen on the VMware Tools download page if it ran into the release freeze before the out-of-band version came out. (it’s a lot easier to ship newer versions of VMware Tools outside of ESXi)
          • Is there a VMware tools VIB that can be downloaded and used?
            • There is not. VIBs (vSphere Installation Bundles) are convenient when distributing a collection of files. However, most VIBs are relatively small. VMware Tools would be roughly 150 Megabytes and this is not conducive to a clean and small deployment of ESXi. Note that a VIB is similar to a ZIP archive which means that not only would distributing tools as a VIB require 150MB for the VIB itself, but ~150MB more once extracted to the VMware Tools folder, increasing the size of ESXi by 50%.

          Getting Started

          By default, ESXi includes VMware Tools under the /productLocker folder (which is actually a Symlink to the location on it’s local storage.. see the image below). When running ‘ls –n’ you will see that productLocker (cyan) just points to /locker/packages/5.5.0 (dark blue meaning the path exists. You also can tell this is an ESXi 5.5 host). ‘ls –n /productLocker’ will return only that line and be a little easier on the eyes for those who are not as familiar with unix.

          Inside of the given folder are two other folders: “floppies” and “vmtools” these contain all necessary ISOs and files to allow VMware tools to be installed and updated on each supported VM on the host. If you are updating VMware Tools packages on each individual ESXi host, the new files would go in these two folders.

          Know that if you are not just updating the tools within each ESXi Host, there are several steps you will need to take (these are also discussed in the FAQ as well as below in the AutoDeploy/Host Profiles section):

          1. Update the UserVars.ProductLockerLocation
          2. Add the VMware tools to it’s own folder in a shared datastore
          3. Update the ESXi Symlink that points to the location of the files on the shared datastore (OR) restart the ESXi host to have it update itself automatically

          How Update Manager (VUM) works with VMware Tools Updates

          To better understand how to make the VMware Tools lifecycle easier, you must first understand how VMware’s products, like Update Manager, interact with the environment. Update Manager does a great job of patching hosts and updating VMware Tools, but what’s actually going on under the covers? Update Manager uses APIs to talk to each ESXi host to perform remediation tasks. What this means is that Update Manager will use whichever version of VMware tools is installed locally on each host, unless that host is using a shared productLocker. VUM uses whatever configuration the host has, it does not have a Tools repository or additional logic to point to some other location. Keep in mind that if we are trying to update VMware Tools via Update Manager, we will either need to add the new version of VMware Tools to each host individually, or configure a shared product locker and point each ESXi host to it.

          Once the VMware Tools are placed in the appropriate location, Update Manager will be able to perform updates of VMware Tools for each virtual machine in vCenter.


          How Auto Deploy/ Host Profiles works with Shared ProductLocker

          As I’ve mentioned in previous blog posts, when using Auto Deploy you have two options for ESXi:

          • Standard ESXi image
          • xxxx-no-tools image

          The Standard ESXi image is what you find in any other deployment method, or if you were to perform the ESXi default manual installation. This will install VMware Tools on the ESXi host and the total image size will be roughly 300 Megabytes.

          The xxxx-no-tools image is exactly that; an ESXi image without the VMware Tools folders. This drops the size of the installation in half down to roughly 150 Megabytes. There are definitely many PROS to doing it this way: Faster boot times, less network saturation, single location for VMware Tools (easier to manage Tools binaries), etc. However, just using xxxx-no-tools image with Auto Deploy is not enough, you must also configure your Host Profiles to point to the Shared Product Locker.

          During your Host Profile creation, ensure that you add the ProductLockerLocation information into the profile. In the “Edit Host Profile” window, expand the “Advanced Configuration Settings”, “Advanced Options”, and “Advanced configuration option”. Click the Green “Add” button to add an additional advanced option.

          In the Advanced Option drop-down box, select “Configure a fixed option”. The name of the option should be “UserVars.ProductLockerLocation” and the value of the option should be “/vmfs/volumes/<name of shared datastore>/<name of product locker folder>” in my case it was /vmfs/volumes/CPBU_PM_PMM1/productLocker. ***You need to make sure that this Datastore/folder is a shared datastore accessible by each host that will be using this Host Profile***. Also note that the value is CASE SENSITIVE!!!

          Once you have your Host Profile created the Host Profile, you can attach it to a cluster or an Auto Deploy rule and you are good to go. Just make sure that the Datastore/folder includes the two folders ‘floppies’ and ‘vmtools’ and their contents from the VMware Tools download ZIP/TAR.GZ

          When the ESXi hosts are booted via Auto Deploy and the Host Profile is applied, the symlink will be updated to reflect the shared product locker location and all hosts booting this way will share this location.

          Can we Automate Some More Please?

          While I mentioned earlier in the post about this, I will mention again, that we are aware of the effort that takes place to update VMware Tools and we are working to make this easier on the customers in a future release. Rest assured, we are working on it. However, until then I have created a script that can help assist you in your efforts. It can be found on my personal blog (http://www.vtagion.com) as the script is not supported by VMware and has not been tested by GSS. However, I have used it several times in both of my environments without problem. As always when using someone else’s scripts you should read through every line and make sure you understand what is happening (BEFORE) running the script; secondly, you should always test things (OUTSIDE) of production. That being said, you can find the script and read more about it HERE.

          Additional Resources

          General VMware Tools installation instructions (1014294)

          http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1014294

          The post Updating to VMware Tools 10 – Must Read appeared first on VMware vSphere Blog.

          vSphere Update Manager – Fully Integrated Interface with the vSphere Web Client

           Allgemein, Knowledge Base, Updates, vCenter Server, VMware, VMware Partner, VMware Virtual Infrastructure, vSphere  Kommentare deaktiviert für vSphere Update Manager – Fully Integrated Interface with the vSphere Web Client
          Sep 112015
           

          You read it right. As of vSphere 6.0 Update 1, the vSphere Update Manager (VUM) now has it’s interface fully-integrated in the vSphere Web Client! What does this mean for you? Now you truly have no excuse not to ditch the c# client and move directly into the Web Client!

          Getting Started

          To be able to take advantage of what I think is one of the two best features of vSphere 6 Update 1 (the other being the re-introduction of the VAMI) you must download the vCenter 6.0 Update 1 and the vSphere Update Manager bits. Currently (and hopefully we will get this changed in the near future) the Update Manager bits are only found in the Windows vCenter Server ISO, so if you are deploying the VCSA with Update Manager you will have to download both the VCSA ISO and the Windows vCenter Server ISO.

          Download Page: https://my.vmware.com/web/vmware/details?downloadGroup=VC600U1&productId=491&rPId=8762

          Once the bits have been downloaded and vCenter has been deployed (or upgraded), you will then install vSphere Update Manager.

          Log out of vCenter and log back in. You should now see the Update Manager icon on the homepage.

          The first step is to then select the corresponding Update Manager. This will allow you to manage all the VUM settings. Work your way through the tabs in the left-side menu. You will find these settings are the same settings you would have seen in the Windows version of Update Manager.

          Once you’ve gone through all the settings, it’s time to setup your Baselines. Move across the top VUM tabs. Use the “Plus” icon to add new custom baselines.

          When creating new VA baselines, you’ll find a new popup window that will walk you through the rule creation and product selection.

          Moving into the Patch Repository, not only can you set VUM to get patches from specific sources (VMware or other), you have the ability on this page to import patches directly into VUM via the Web Client.

          You can upgrade multiple hosts of different versions simultaneously by using specified ESXi images here.

          VA Upgrades page shows you all of the virtual appliances and their upgrade versions, you can click on the “EULA” link next to specific versions and accept the EULA beforehand as to not need to do so when deploying.

          Notice each page has the “Go to compliance view” button, which will take you the compliance view of vCenter, allowing you to attach baselines, scan for Updates, stage the patches, and Remediate.

          You can also jump to the Update Manager page of each object by right-clicking on an object, and hovering over the Update Manager menu item.

          For more information about the VUM integration with the Web Client as well as the What’s New, Installation, and Upgrade notes, please visit the release notes page (see below):

          Release Notes

          VUM 6.0 U1: http://pubs.vmware.com/Release_Notes/en/vsphere/60/vsphere-update-manager-60u1-release-notes.html

          The post vSphere Update Manager – Fully Integrated Interface with the vSphere Web Client appeared first on VMware vSphere Blog.

          vSphere Update Manager – Fully Integrated Interface with the vSphere Web Client

           Allgemein, Knowledge Base, Updates, vCenter Server, VMware, VMware Partner, VMware Virtual Infrastructure, vSphere  Kommentare deaktiviert für vSphere Update Manager – Fully Integrated Interface with the vSphere Web Client
          Sep 112015
           

          You read it right. As of vSphere 6.0 Update 1, the vSphere Update Manager (VUM) now has it’s interface fully-integrated in the vSphere Web Client! What does this mean for you? Now you truly have no excuse not to ditch the c# client and move directly into the Web Client!

          Getting Started

          To be able to take advantage of what I think is one of the two best features of vSphere 6 Update 1 (the other being the re-introduction of the VAMI) you must download the vCenter 6.0 Update 1 and the vSphere Update Manager bits. Currently (and hopefully we will get this changed in the near future) the Update Manager bits are only found in the Windows vCenter Server ISO, so if you are deploying the VCSA with Update Manager you will have to download both the VCSA ISO and the Windows vCenter Server ISO.

          Download Page: https://my.vmware.com/web/vmware/details?downloadGroup=VC600U1&productId=491&rPId=8762

          Once the bits have been downloaded and vCenter has been deployed (or upgraded), you will then install vSphere Update Manager.

          Log out of vCenter and log back in. You should now see the Update Manager icon on the homepage.

          The first step is to then select the corresponding Update Manager. This will allow you to manage all the VUM settings. Work your way through the tabs in the left-side menu. You will find these settings are the same settings you would have seen in the Windows version of Update Manager.

          Once you’ve gone through all the settings, it’s time to setup your Baselines. Move across the top VUM tabs. Use the “Plus” icon to add new custom baselines.

          When creating new VA baselines, you’ll find a new popup window that will walk you through the rule creation and product selection.

          Moving into the Patch Repository, not only can you set VUM to get patches from specific sources (VMware or other), you have the ability on this page to import patches directly into VUM via the Web Client.

          You can upgrade multiple hosts of different versions simultaneously by using specified ESXi images here.

          VA Upgrades page shows you all of the virtual appliances and their upgrade versions, you can click on the “EULA” link next to specific versions and accept the EULA beforehand as to not need to do so when deploying.

          Notice each page has the “Go to compliance view” button, which will take you the compliance view of vCenter, allowing you to attach baselines, scan for Updates, stage the patches, and Remediate.

          You can also jump to the Update Manager page of each object by right-clicking on an object, and hovering over the Update Manager menu item.

          For more information about the VUM integration with the Web Client as well as the What’s New, Installation, and Upgrade notes, please visit the release notes page (see below):

          Release Notes

          VUM 6.0 U1: http://pubs.vmware.com/Release_Notes/en/vsphere/60/vsphere-update-manager-60u1-release-notes.html

          The post vSphere Update Manager – Fully Integrated Interface with the vSphere Web Client appeared first on VMware vSphere Blog.

          Enabling the VMware vCenter Update Manager plugin in 4.x generates an error

           Allgemein, Knowledge Base, Updates, vCenter Server, VMware, VMware Update Manager  Kommentare deaktiviert für Enabling the VMware vCenter Update Manager plugin in 4.x generates an error
          Sep 042009
           

          Source: http://kb.vmware.com/

          Symptoms

          You may experience these symptoms:
          Attempting to enable the VMware vCenter Update Manager plugin fails
          You receive the following error:

          There was an error connecting to vmware vcenter update manager – IPADDRESSOFVC:8084
          Vmacore::Exception: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

          or

          The request failed because of a connection failure.

          Resolution

          Enabling the VMware vCenter can fail if you are using a remote SQL database with Windows authentication and the Update Manager service is set to log on as the local system account.
          Change the service to login as the same Windows NT account that has been given dbo permissions to the SQL database.

          Make sure the vci-integrity.xml file, located at C:\Program Files\VMware\Infrastructure\Update Manager, has the correct vCenter IP address. If the IP address is incorrect, update it and restart the Update Manager service.