Friday, November 11, 2016

Notes from the field




During a recent engagement I ran into a perplexing situation as everything was working great, then everything went downhill from there!

Sudden duplicate IP address on network - affecting both static and DHCP assigned addresses.

Customer built out infrastructure servers for Horizon View, joined systems to domain, everything functioned normally. We were able to register vCenter with the Connection server, all seemed fine.

The next morning we completed the composer server installation. Returning to the Connection Server management interface, we proceeded to register the stand-alone composer server, which failed. During this time period we were also focusing on optimizing the gold image for the linked-clones.

With the priority focused on at least confirming functionality of the Horizon View Infrastructure, we cloned the optimized parent image to allow creation of a manual desktop pool which would validate communication between the desktop with the Horizon Agent and Connection Server. As we brought the cloned image online we received a duplicate IP address error.  This led me down the path of reviewing and removing any non-present hidden devices, reviewing the registry, validating the necessary MS hotfixes were in place for issues related to cloning and the vmxnet3 adapter. All of this checks out,

While banging my head against a wall - which does become painful after a bit, I get word that other infrastructure servers along with our SQL server, no longer could communicate with Active Directory. This validates for me it has nothing to do with our gold image or the configuration of the Horizon environment. The basic troubleshooting question "What changed", which is often met with 'nothing' or 'its not the network!' became the focus.

I was able to determine that while we were completing the built out of the Horizon View infrastructure that morning, the network team opened up external access for the zone in which the Horizon View infrastructure servers reside. This was done to allow the Windows servers to be patched from Windows Update external services as an internal solution was not available.

After a few minutes with google I quickly found similar behaviors related to Proxy-ARP being enabled on the internal interface of the Cisco ASA.  I was able to convince the Network team to look at the settings, and sure enough, Proxy-ARP was enabled. Upon disabling, everything returned to normal - Thankfully!

A good link related to proxy-arp:

https://lkhill.com/proxy-arp-sucks/

Horizon View 6 and vSphere build out




Physical Hardware build-out:
Confirm IP and Hostname assignments
Build out VMware vSphere® hosts
Configure networking
Configure storage

Prepare Active Directory
Create vCenter Service account
Create Composer Service account
OU Containers for View Desktops and View Users

Build out Virtual Machines OS
(ensure Windows Servers are joined to AD prior to performing installation)

vCenter Server
Composer Server 
Connection Server

Security Server (exception: do not join to domain)

Software Installation - vCenter Server
Install .Net Framework 3.5 (Install from roles & features)
Install SQL Native Client (version 10 for Windows Server 2008)
Install vCenter Server simple mode (Run as administrator)
(using bundled SQL Server 2008 Express database)
Install SQL Server Management Studio
Create Composer and Events databases
Create ODBC connection to newly created databases

Software Installation - View Composer Server
Add domain user account to local administrators account
Install .Net Framework 3.5 (Install from roles & features)
Install SQL Native Client (version 10 for Windows Server 2008)
Install View Composer

Software Installation - View Connection Server
Add domain user account to local administrators account
Install .Net Framework 3.5 (Install from roles & features)
Install SQL Native Client (version 10 for Windows Server 2008)
Install View Composer



User Accounts required for vsphere 5.5 and Horizon View 5.3 Installation



Where to Use the vCenter Server User and Domain User for View Composer
After you create and configure these two user accounts, you specify the user names in View Administrator.


You specify a vCenter Server user when you add vCenter Server to View Manager.
You specify a domain user for View Composer when you configure View Composer for vCenter Server.

You specify the domain user for View Composer when you create linked-clone pools.
SQL DB Account - domain account
Must install .Net Framework 3.5



ADSI Edit Notes



NOTE: Backup ADAM DB prior to making changes.


Connect to View ADAM DB:
  • Connection Point: dc=vdi,dc=vmware,dc=int
  • Computer: localhost:389

Note: Before removing entries from the ADAM database, note the virtual machine name of the desktops that are being removed for reference when editing the Composer database.
  1. Connect to the View ADAM database. For more information on connecting to the ADAM database with ADSI Edit, see Connecting to the View ADAM Database (2012377).

    Note: If you connect to ADSI and Connection server using RDP using a user account that does not have administrator privileges, you may see the error:

    Operation Failed. Error code: 0x8000500d. The directory property cannot be found in the cache

    To prevent this issue, log in to the Connection server through RDP using a user account with administrative privileges.
  2. Locate the virtual machine(s) for removal.

    1. Right-click the Connection View ADAM Database [localhost:389], and click New > Query.
    2. Provide a query name such as VM Search.
    3. Under Root of Search, click Browse and select the Servers organizational unit.
    4. Click OK.
    5. In the Query String, paste this search string:

      (&(objectClass=pae-VM)(pae-displayname=VirtualMachineName))

      Where VirtualMachineName is the name of the virtual machine for which you are trying to locate the GUID. You may use * or ? as wildcards to match multiple desktops.
    6. Click OK to create the query.
    7. Click the query in the left pane. The virtual machines that match the search are displayed in the right pane.
  3. Check the properties of the items returned by the query to confirm the correct virtual machine(s) were found, and delete the pae-VM object(s) to remove them from the database.
Notes:
  • Check if there are entries under OU=Server Groups and OU=Applications in the ADAM database.
  • A broken pool that does not contain any desktops can be removed from View Manager by removing the pool entry from both the Server Groups and Applications organizational units. However, removing one entry and not the other from the ADAM database results in the java.lang.nullpointerexception error when attempting to view the pools or desktops inventory in View Manager.
http://kb.vmware.com/kb/2015112

    1. Record the [GUID] in cn=<GUID>.
  1. Delete the [pae-VM object] from the ADAM database:
    1. Locate the [OU=SERVERS] container.
    2. Locate the corresponding virtual machine’s GUID (from above) in the list which can be sorted in ascending or descending order, choose [Properties] and check the pae-DisplayName attribute to verify the corresponding linked clone virtual machine object.
    3. Delete the pae-VM object.
  2. Check if there are entries under OU=Desktops and OU=Applications in the ADAM database.
  3. Check for entries in both the [OU=Server Groups] and [OU=Applications] and remove both. Removing one entry and not the other from the ADAM database results in the java.lang.nullpointerexception error when attempting to view the pools or desktops inventory in View Manager.
  4.  

Wednesday, May 6, 2015

Horizon View Log Locations



Connection Server, Transfer Server, and Security Server logs

The Connection Server, Security Server, and Replica Server logs reside on the servers themselves:
  • Windows 2008
    • DriveLetter:ProgramData\VMware\VDM\logs
  • ADAM Replication Errors
    • Show the ADAM replication neighbors, and the last time they replicated by using the following command:

      C:\WINDOWS\adam\repadmin.exe /showrepl localhost:389 DC=vdi,DC=vmware,DC=int

View Agent logs

View Agent log files are found in:


  • Windows Vista and Windows 7 and 8:

    DriveLetter:\ProgramData\VMware\VDM\logs

PCoIP logs

The virtual desktop PCOIP logs are called pcoip_agent*.log and pcoip_server*.log and they are located in the same location as the agent logs on the view desktop.

The client PCoIP logs are called pcoip_client*.txt and are located in the user's %temp% directory on Windows Clients.

Note: The PCOIP logs are also gathered in the Client and Agent log bundle

 

QuickPrep/Sysprep Script and Composer Customization logs

The View Composer Guest Agent log contains information about QuickPrep and Sysprep script execution. This log records the start and end time of script execution and contains output or error messages. The View Composer Guest Agent log is located in the Windows Temp directory on the linked clone desktop at:

%system_drive%\Windows\Temp\vmware-viewcomposer-ga-new.log

 

Composer logs

View Composer logs are located in the computer in which View Composer and vCenter Server are installed.
  • In Windows 2003, the logs are located at:

    C:\Documents and Settings\All Users\Application Data\VMware\View Composer\Logs\

  • In Windows 2008, the logs are located at:

    C:\ProgramData\VMware\View Composer\Logs\