Aside

Summary:

If you are an Appassure Administrator, there are a few common errors that may occur in your virtualized/non virtualized environment. Below are some tips and tricks that may help you in your daily duties.

 
 

Daily Appassure Admin Checks

Appassure is not a fire and forget backup system.

  • Check Event Logs on Source and Target Cores for failures:
    • View each failure and research the error using the Appassure Online Knowledge base.
  • Verify that Nightly Rollup Jobs Are Working:
    • If Nightly Rollups are failing, your repository space will be consumed by recovery points not expiring. When this occurs your repository will fail and backups will no longer run.
  • Set a Low Disk Space alerts for your repositories so you know when action needs to be taken.

 
 

Common Troubleshooting Situations

  1. VSS Errors:

VSS errors most likely occur when a system is shutdown dirty or while a backup was being performed that was otherwise interrupted. This can be a result of system utilization volume (CPU, RAM and Network Bandwidth) at the time of failure.

 
 

To correct a VSS error, identify the health of the VSS writers using the VSSADMIN LIST WRITERS command. The command shows the health of the writers. You want to see No error for last error and Stable for the state. A reboot best corrects errors with VSS writers. You may also restart the Volume Shadow Copy service if you are unable to perform a reboot. Chances are you may need to schedule downtime. Below is an example of what healthy VSS writers look like.

 
 

Microsoft Windows [Version 6.3.9600]

(c) 2013 Microsoft Corporation. All rights reserved.

 
 

C:\Users\administrator.NE>vssadmin list writers

vssadmin 1.1 – Volume Shadow Copy Service administrative command-line tool

(C) Copyright 2001-2013 Microsoft Corp.

 
 

Writer name: ‘Task Scheduler Writer’

Writer Id: {d61d61c8-d73a-4eee-8cdd-f6f9786b7124}

Writer Instance Id: {1bddd48e-5052-49db-9b07-b96f96727e6b}

State: [1] Stable

Last error: No error

 
 

Writer name: ‘VSS Metadata Store Writer’

Writer Id: {75dfb225-e2e4-4d39-9ac9-ffaff65ddf06}

Writer Instance Id: {088e7a7d-09a8-4cc6-a609-ad90e75ddc93}

State: [1] Stable

Last error: No error

 
 

 
 

  1. Low Disk Space on Boot Volume: Free up the “System Volume Information” Folder

Windows creates a small 100MB boot volume during installation. Once the System Volume Information folder becomes full, VSS will fail. Generally VSS logging is circular and the log truncates. When the Shadow Copy performs a snapshot, the transaction of the snapshot is stored in a file (AA_logs) located in the “System Volume Information” folder. This folder is only visible on all disk drives by un hiding protected operating system files. Go to folder options and check Show hidden files, folders and drives. Uncheck Hide protected operating system files and folders.


 
 

Dell Puts out a nice KB on how to free up space on the System Volume Information Folder. These instructions are the safest way to free up space in the System Volume Information Folder. If you delete the logs, the VSS subsystem is not aware of the delete as it did not perform the delete. So do not manually delete logs.

https://support.software.dell.com/kb/117838?utm_source=redirects&utm_medium=aquisition&utm_campaign=AppAssure_301_Support

 
 

I have used this method in KB 117838 for a variety of errors to correct VSS Errors. My result was success.

 
 

  1. You Are Using Shadow Copies:

When you see a lot of Shadow Copies for a selected volume.

You can manually force the Shadow Copies to Clear up by setting a Limit of 320MB and then adding No Limit. This will remove the conflicting Shadow Copies that may be causing issues with the VSS writers. If you do not need Shadow Copies, Disable it.


 
 

 
 

  1. Maintain The Cores “Source ” and Target”

    As I indicated earlier, you have to get in the habit of reading the log files on a daily basis. This allows you to identify trends. As trends occur, log the times so you can target the incident. I use VMware, so therefore I have Vcenter Operations Manager to shows me what occurred around the time of failure. ( High CPU, Disk Latency, Bandwidth, Memory)

 
 

 
 

  1. Replication Partners and Rollups

    I check my replication target on a daily basis because it allows me to verify backup integrity. When you manage a replication partner you may be tasked with no looking at the system at all because it is out of sight and out of mind. The most common situation that occurs with replication partners, would be lack of administration and attention to log files.

     
     

  • Recently, the target partner had orphans. When your recovery points have an orphan in the retention chain, rollups will fail for the agent protecting the server. You will then have more recovery points and space being used than planned. Orphans will also cause repository and integrity checks to fail. When this happens you will have to open a ticket with Dell Support. Dell can only perform a hard delete on an orphan. Dell support uses special scripts that unlock features within the Appassure Console that the public does not have access to. Dell does this to prevent admins from accidentally deleting what looks like a phantom orphan vs a real orphan. If a hard delete is performed on what may not be an orphan, you can blow away your backup recovery chain for a protected agent.

     
     

  • Use this PowerShell script to list Orphans. This beats manually looking at every single recovery point for all of your agents.

     
     

    https://support.software.dell.com/appassure/kb/118248

     
     

    When you have a situation of dealing with recovery points on a target core that are not rolling up, options are limited.

  • You can force a rollup by changing the Nightly Job by adding five minutes to the current time in your zone. However, you need to pause replication on your source server. This is a clever way of forcing a rollup for all protected agents. Appassure does not allow a force rollup option for every protected agent.

     
     

  • You can force a rollup per agent. This is a long process and is manual.

     
     

  • You can run a PowerShell script that performs rollups agent by agent automatically.

    https://support.software.dell.com/appassure/kb/129963

     
     

  1. Repository Space

    Do not expect to big gains in freed up space after a rollup. Appassure has a special file called the ” Deferred File” This file is used to perform a restore on deleted data in the event that the data was not supposed to be deleted. The blocks in this file are exponentially expired on an algorithm which frees up space in time within the repository through time.

     
     

  2. Expanding VM Disk Drives ” Be Careful”

    Use caution when expanding a volume. The new Appassure agents check the drive offset moving forward. At times, the geometry on the disk volume may indicate a byte size different than the offset of the drive. This can happen when you convert from RDM to VMDK or shrinking a drive and even using a V2V/P2V migration tool.

     
     

    See Example Error Of Drive Offset

    ERROR 2014-10-17T15:40:54 [26] – Replay.Agent.Implementation.Transfer.TransferDataChannel (RemoteEndPoint=10.1.1.24:53679)

    Sending of volume data at byte offset 0x1b7fcfe000, byte length 0x2000 failed

    System.AggregateException: One or more errors occurred. —> Replay.Common.Contracts.Win32Api.Win32ApiFailedException: I/O operation  – The drive cannot find the sector requested

       at Replay.Common.Implementation.Win32Api.NativeIOReader.EndTransmitFile(IAsyncResult asyncResult)

       at Replay.Common.Implementation.Win32Api.NativeIOReader.<>c__DisplayClass4.<StartTransmitFile>b__3(IAsyncResult ar)

       — End of inner exception stack trace —

     
     

    This is the KB we must apply.

    https://support.software.dell.com/appassure/kb/130883

 
 

 
 

 
 

 
 

 
 

 
 

 
 

Appassure Daily Checks and Admin Tips

Advertisements
Aside

Summary: Installed a new vCenter server from scratch. Was unable to log on to the vCenter server using the VIC as well as the web client with Active Directory credentials.

 

Errors:

Cannot Complete Login due to an incorrect username or password


 

You do not have permission to login to the server: vcenter.domain


 

Provided credentials are not valid


 

Solution: You have to configure the permissions in the SSO using the web client. This must be done using the local credentials of the Web Client.

 

1. Use Administrator@vsphere.local or Administrator@<yourDomain> for the first instance login.

2. After login, navigate to Administrator, Configuration and select Identify Sources tab.

 


 

  • Next Add the domain you desire to include in the active environment. Choose Active Directory

    Integrated Windows Authentication.


     

  • This adds the domain in my example NE.local


     

     

  • Select Users and Groups and select the Administrators Group. This provides full admin access to the web client with an AD integrated account.


 

  • Next Define the AD account a role within the web client. Select Users And Groups under Single Sign on.
  • Select the administrators group
  • From Add Principals select your domain and select the users you want to add to the Administrator Role. This add the AD account to the web clients Administrator Group.


 

 

  •  Next we need to define the AD administrator account in Vcenter.
Using the VIC, you next need to logon to the Vcenter using the local Administrator

 

  • loging in with the default master credentials ie vsphere.local\Administartor

 

 

  • Select The Permissions Tab. You can see the Domain Administrator AD account is not listed.


 

  • Select Add


     

  • Select your domain from the pick list. The domain will not show up unless you add it as an identity source.


     

  • Add your selected user to the Role. I chose the domain NE and administrator for the Assigned role of Administrator.


     

  • After this part is completed, Log back on the VIC using the AD account and it will work.

Configuring SSO and Vcenter Permissions

Aside

Summary: Defending against Microsoft IE Zero Day Exploit with EMET 4.1 using Deployment techniques and Strategies.

Reference: http://www.zdnet.com/microsoft-advises-on-ie-zero-day-vulnerability-7000026532/


  • The first steps to secure your browser would be to patch them as referenced in the link below. This ensures that your browser is patched and secured from most exploits.

    Locate your browser from here and download the latest security updates.

  • In this example we choose two browsers IE 8 and IE10 which run on Windows Server 2008 R2 for x64-based Systems Service Pack 1

    https://technet.microsoft.com/library/security/ms13-097

    IE 8 Update

    http://www.microsoft.com/en-us/download/details.aspx?id=41870

    IE 10 Update

    http://www.microsoft.com/en-us/download/details.aspx?id=41482

     
     

    Once you have downloaded and patched your browser with the latest security updates, setup a controlled test platform, you need to decide on a migration tactic.

    Deploy EMET 4.1 with GPO Software Distribution

    Group Policy supports two methods of deploying a MSI package:

    • Assign software – A program can be assigned per-user or per-machine. If its assigned per-user, it will be installed when the user logs on. However, if its assigned per-machine then the program will be installed for all users when the machine starts.
    • Publish software – A program can be published for one or more users. This program will be added to the Add or Remove Programs list and the user will be able to install it from there.

    2. Create a distribution point

    The first step in deploying a MSI through GPO is to create a distribution point on the publishing server. This can be done by following these steps:

    • log on to the server as an Administrator user
    • create a shared network folder (this folder will contain the MSI package)
    • set permissions on this folder in order to allow access to the distribution package
    • copy the MSI in the shared folder

    3. Create a Group Policy Object

    A MSI package is deployed (distributed) through GPO as a Group Policy Object. In order to create an object for your package, you can follow these steps:

    • click on the Start button, go to Programs, select Administrative Tools and then select Active Directory Users and Computers
    • right-click your domain name in the console tree and select the Properties context menu
    • select the Group Policy tab and click New
    • set the name of the policy (for example MSIApplication)
    • click Properties and select the Security tab
    • check the Apply Group Policy checkbox only for the groups to which the policy will be applied
    • click on the OK button

    4. Assign a MSI package

    A package can be assigned per-user or per-machine. Also, if the package is assigned, it will automatically be installed silently. In order to assign a package you can follow these steps:

    • click on the Start button, go to Programs, select Administrative Tools and then select Active Directory Users and Computers
    • right-click your domain name in the console tree and select the Properties context menu
    • go to the Group Policy tab, select the object you want and click Edit
    • expand Software Settings under Computer Configuration
    • right-click Software Installation, select the New context menu and then click on Package
    • in the Open dialog type the full UNC path of the shared package you want to assign
    • click on the Open button
    • click on Assigned and then click OK (the package will be added to the right pane of the “Group Policy” window)
    • close the Group Policy snap-in, click OK and exit the Active Directory Users and Computers snap-in
    • when the client computers start, the assigned package will be installed automatically

      Do not use the Browse button in the Open dialog to access the UNC location. Make sure that you use the UNC path to the shared package.

    5. Publish a MSI package

    When using Group Policy, you can publish a package in order to allow the target user to install it by using Add or Remove programs. The steps for publishing a package are:

    • click on the Start button, go to Programs, select Administrative Tools and then select Active Directory Users and Computers
    • right-click your domain name in the console tree and select the Properties context menu
    • go to the Group Policy tab, select the object you want and click Edit
    • expand Software Settings under User Configuration
    • right-click Software Installation, select the New context menu and then click on Package
    • in the Open dialog type the full UNC path of the shared package you want to publish
    • click on the Open button
    • click on Publish and then click OK (the package will be added to the right pane of the “Group Policy” window)
    • close the Group Policy snap-in, click OK and exit the Active Directory Users and Computers snap-in
    • test the package:
      • log on to the target computer
      • click on the Start button and go to Control Panel
      • double-click the Add or Remove programs applet and select Add New Programs
      • in the Add programs from your network list select the program you published
      • use the Add button to install the package
      • click OK and then Close

    Do not use the Browse button in the Open dialog to access the UNC location. Make sure that you use the UNC path to the shared package.

    6. Redeploy a MSI package

    Sometimes you may need to redeploy a package (for example when doing an upgrade). For redeploying a package you can follow these steps:

    • click on the Start button, go to Programs, select Administrative Tools and then select Active Directory Users and Computers
    • right-click your domain name in the console tree and select the Properties context menu
    • go to the Group Policy tab, select the object you used to deploy the package and click Edit
    • expand the Software Settings element (per-user or per-machine) which contains the deployed package
    • expand the Software Installation element which contains the deployed package
    • right-click the package in the right pane of the Group Policy window
    • select the All Tasks menu and click Redeploy application
    • click the Yes button for reinstalling the application wherever it is installed
    • close the Group Policy snap-in, click OK and exit the Active Directory Users and Computers snap-in

    7. Remove a MSI package

    Group Policy also allows you to remove packages which have been deployed in the past. Here are the steps for removing a package:

    • click on the Start button, go to Programs, select Administrative Tools and then select Active Directory Users and Computers
    • right-click your domain name in the console tree and select the Properties context menu
    • go to the Group Policy tab, select the object you used to deploy the package and click Edit
    • expand the Software Settings element (per-user or per-machine) which contains the deployed package
    • expand the Software Installation element which contains the deployed package
    • right-click the package in the right pane of the Group Policy window
    • select the All Tasks menu and click Remove
    • select from the following options:
      • Immediately uninstall the software from users and computers
      • Allow users to continue to use the software but prevent new installations
    • click the OK button to continue
    • close the Group Policy snap-in, click OK and exit the Active Directory Users and Computers snap-in

    Sited Credit http://www.advancedinstaller.com/user-guide/tutorial-gpo.html

    Deploy EMET 4.1 with a batch file via GPO

    • Click on the Start button, go to Programs, select Administrative Tools and then select Active Directory Users and Computers
    • right-click your domain name in the console tree and select the Properties context menu
    • go to the Group Policy tab, select the object you want and click Edit
    • expand Windows Settings under Computer Configuration
    • Select scripts startup/shutdown.
    • Right click startup
    • Select Add
    • In the browse section, this is a secret. In the open space, right click and select new text document.
    • Pate the following code in the test document

      If exist “%Programfiles%\EMET 4.1\EMET_GUI.exe” (goto End) 

      @Echo “Installing EMET4.1” 

      \\networkshare\deploy\EMET4.1\EMETSetup.msi /qn

      :End

     
     

    • Save the file as EMET.CMD
    • In the script name filed select the file you just created “EMET.CMD”
    • Select okay.
    • This will install the MSI via a batch file on startup when assigned to the computer accounts Organizational Unit.

    Controlling EMET4.1 via GPO

    If you want to integrate EMET4.1 within group policy, there are admx files that are included under your program files\EMET\Deployment\Group Policy folder. You need to copy the .admx files to your SYSTEMDRIVE\Windows\PolicyDefinitions folder and the .adml files to SYSTEMDRIVE\Windows\PolicyDefinitions\en-US. When you move them there you can get to the policies through Computer Configuration -> Administrative Templates -> Windows -> Components -> EMET GPO. Below is a screenshot of what options you have available:


     
     

    Sited Credit https://www.trustedsec.com/july-2013/emet-4-0-security-strategy-and-installation-step-by-step/

    EMET DEMO

    Hats off to the author of this video, he does a great job of explaining EMET.

    http://www.youtube.com/watch?v=zSJ-AFQGpPs

EMET 4.1 Zero Day Protection

Link

FAX Server Card Solution

The newest addition to the intelligent fax board lineup, the Mainpine IQ Express 2 Port RF5120 card provides customers with the speed, reliability and performance of enterprise-class fax hardware at an exceptional price-to-performance guarantee.

Configure Net flow ASR or Router

Summary: Configuring Netflow on a Cisco ASR or Cisco Router is quite simple. In this example the Router/ASR has two interfaces. GigabitEthernet0/0/1 is the Routed Network between the production Servers and WAN. GigabitEthernet0/0/0 is a trunk port which carries the VLANS for the branch sites.

 
 

Part 1.

Check if you have SNMP access to your router. If you don’t have SNMP set up on your devices, you will need to configure them using the command line:

•Open a command prompt and telnet into your router.

Login to the device.

•Go into privilege mode by typing in enable. This allows you to make configuration changes.

•Type in conf t to give the device configuration commands.

•You’ll see a banner to enter in configuration commands. You will now need to enter in 3 lines of commands to tell the router to start NetFlow and export the data:

•ip flow-export source GigabitEthernet0/0/1 (export and source traffic to GigabitEthernet0/0/1)

•ip flow-export source version 5 (this exports ver. 5 NetFlow, the best to start with)

•ip flow-export destination <IP> <port> (location of NMS to send the data to)

 
 

Setup The Net flow on the Routed Interface that has an IP address GigabitEthernet0/0/1

 
 

enter the commands

ip flow-export source GigabitEthernet0/0/1

ip flow-export destination 192.168.1.8 2055

 
 

Part 2.

Specify the interface you want to analyze the traffic on by using the interface fastethernet0/0 command. Tell that interface what traffic you require:

•ip flow egress (monitor outbound flow)

•ip flow ingress (monitor inbound flow)

•ip route-cache flow

 
 

Configure The Branch VLANS. You must specify the bandwidth of the circuit and direction of the traffic. IN-OUT or Ingress or Egress

 
 

 
 

Enter the Commands on the Interface to be monitored:

 
 

interface GigabitEthernet0/0/0.123

description Branch Site


bandwidth 6000

encapsulation dot1Q 123

ip address 174.16.1.9 255.255.255.252

ip flow ingress

ip flow egress

 
 

 
 

Part 3.

Exit the interface, exit privilege mode, and type in one more important command:

•wr mem (saves configuration data)

 
 

 
 

 
 

SettinUp Storage iSCSI Bindings

 
 

Issue configuring software iSCSI – The selected physical network adapter is not associated with VMkernel with compliant teaming and failover policy (2009119)

Symptoms

  • You have set up what you believe is an appropriate iSCSI port group (or port groups).
  • When you attempt to add Network Adapters under Storage Adapters > iSCSI software adapter > Properties > Network Configuration, you see this error in a pop-up window:

    Only VMkernel adapters compatible with the iSCSI port binding requirements and available physical adapters are listed.

    If a targeted VMkernel adapter is not listed, go to Host > Configuration > Networking to update its effective teaming policy.

  • If you click on the vmnic that you are planning on binding, you see this message in the bottom portion of the window:

    The selected physical network adapter is not associated with VMkernel with compliant teaming and failover policy. VMkernel network adapter must have exactly one active uplink and no standby uplinks to be eligible for binding to the iSCSI HBA.

Cause

The issue occurs because iSCSI port binding in ESXI 5.x requires that there can only be one vmnic configured as Active Adapter for the iSCSI portgroup. Other vmnics must be set to Unused.

Resolution

For example, a typical vSwitch setup that yields this error:

 
 

vSwitch with two NICs, e.g. vmnic2 and vmnic3

iSCSI Port Group 1 –> vmnic2 active, vmnic3 standby

iSCSI Port Group 2 –> vmnic3 active, vmnic2 standby

The above portgroups cannot contain standby adapter or multiple active adapters for iSCSI binding to work.

 
 

To resolve this issue, modify the status of the vmnic adapters.

  • Log in to vSphere Client.
  • Click on the ESXi 5.x host to select it.
  • Click the Configuration tab.
  • Under Hardware, click Networking.
  • Click Properties for the vSwitch.
  • In the vSwitch Properties dialog box, click the Portgroup containing the iSCSI vmkernel adapter.
  • Click Edit.
  • In the Portgroup Properties dialog box, click the NIC Teaming tab.
  • Select Override switch failover order

    Note: The vmnic adapters are now editable.

  • Move down the standby adapters or the second Active Adapter to Unused Adapters.

    Note: Only one vmnic should be under Active Adapters.

  • Click OK.
  • Repeat the process for each additional iSCSI portgroups. Ensure you use alternate vmnics as Active and move the rest to Unused.

You can now add each active adapter. After you add each active adapter, the adapters are appropriately bound.

Additional Information

For detailed information, see Setting up iSCSI Network in the vSphere 5.5 Storage Guide.

 
 

Note: The instructions are valid for ESXi 5.0, 5.1 and 5.5.

Update History

11/06/2013 – Added a cause, extra steps to Resolution section and ESXi 5.1 and 5.5 to Product Versions.

Request a Product Feature

To request a new product feature or to provide feedback on a VMware product, please visit the Request a Product Feature page

 
 

From <http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2009119>

 
 

 
 

Applying Critical and Non Critical Patches to an ESXi Host

Summary: We will apply critical and non-critical patches to an ESXi Host. This picks up from our earlier lab to where we left off with upgrading ESXi 5.1 to ESXi 5.5.

 
 

You can begin by placing your ESXi host into maintenance mode if not already placed into maintenance mode.

 
 

Once in maintenance mode, select Update Manager and All from the Attached Baselines. Select Scan. This will scan for updates needed for the ESXi host. The scan may take some time to complete, but be patient while it works.


 
 

The scan completed and we can see that our host is non-compliant as it needs 4 patches.


 
 

Next we can Stage the patch deployment or Remediate.

 
 

I will Remediate now installing the 4 patches. Select Remediate. Select Patch Baselines and select next.


 
 

Select Next


 
 

Enter a Task Description and Next


 
 

Leave Defaults and Next


 
 

Select Finish


 
 

The patches are being installed.


 
 

Upgrading an ESX Host to 5.5 With Update Manager

Summary: We will use VMware Update Manager to install ESXi 5.5 to a ESXi host running ESXi 5.1

 
 

 
 

Attach an Image and Create Upgrade Baseline

Launch Update manager


 
 

Choose EXSi Image

Import ESXi Image

Browse to the path of the image


 
 

 
 

Uploading Image

 
 


 
 

Upload Successful

 
 


 
 

 
 

Create a Baseline


 
 

Now that we have the baseline we can apply it to an ESXi Host in this example ESX042


 
 

 
 

Applying an Upgrade baseline to an ESXi Host

 
 

Select your ESXi Host from Compliance View that you want to upgrade


 
 

 
 

Select Attach and check off your upgrade baseline.


 
 

It’s important to note that you should evacuate the ESXi guest VMs to other ESXi hosts in the cluster and place the ESXi Host that you are upgrading into maintenance mode.


 
 

From the Attached baselines select ESX5.5

 
 


 
 

Select the Remediate Button


 
 

 
 

Accept the EULA


 
 

Select next


 
 

Provide a task description for the update task


 
 

Select Next


 
 

Select Finish


 
 

We can see our Progress


 
 

 
 

The ESXi Host will reboot and stay stuck at a percentage. However, vCenter will receive the installation handler calls to resume and complete the reaming stages of the installation. Do not touch anything, wait patiently while the progress bar is stuck and things look grim.

 
 

As you can see, the installer is wrapping up last minute tasks and is at 89% completion.

 
 


 
 

We can see that the Upgrade task completes and took almost 30 minutes to complete. See start time and end time.


Take your host out of maintenance mode and you have completed upgrading your ESXi host to version 5.5.

 
 

Next, We will scan for updates and apply them to the new ESXi 5.5 Host.

Update Patch Manager

After you update Vcenter to 5.5, you will need to update the Update Manager.

 
 

Looks like Update Manager Services is off. I logged into Vcenter server and turned on the Update Manager Service.

 
 


 
 

Select vSphere Update Manager


 
 

The installer detected my existing version of Update Manager. Great move on…


 
 


 
 

 
 


 
 


 
 

Enter your vcenter username and password.


 
 


 
 


 
 


 
 


 
 

Upgrading VCenter From5.1 to 5.5

Summary: Upgrading ESX5.1 VCenter Server to VCenter Serve 5.5

 
 

Steps:

In this example, I chose Simple Install. The wizard will walk you through each part of the installation. There are four parts to the installation method

  1. vCenter Single Sign-On
  2. vSphere Web Client
  3. vCenter Inventory Service
  4. vCenter Server

 
 

 
 

SSO


 
 

Select Next


 
 

Select Next


 
 

Select Next


 
 

Enter the password to which you logged into on the server while performing the upgrade.Select Next


If you receive a password complex error, get out and change the account your logged into with

Using a complex password.


 
 

Select Next


 
 

Inventory Service


 
 

After the installer runs 30 minutes, you will be prompted with Upgrading Vcenter


 
 

Select Install


 
 

Enter Your License Key


 
 

Select Next


 
 

Makes Sense. You have to Update the “Update Manager”


 
 

Select Next


 
 

Select Next


 
 

Select Next. This step can get a lot of folks into trouble. You have to use the Local System Account or Domain Account. Remember what account you use so you do not get permission denied when logging into Vcenter afterwards.


 
 

Select Next


 
 

Select Next


 
 

Select Next


 
 

Select Finish


 
 

Completed