Unable to reinstall VMware Tools onto virtual desktop

I recently ran into an interesting issue where I went through a series of troubleshooting steps that eventually led me to reinstalling the VMware Horizon View Agent on a master image but quickly realized I wasn’t able to.  The error messages I was presented wasn’t too helpful so I thought writing this blog post may help others who may encounter the same problem.

The whole process started off with an administrator asking me to look at why a user wasn’t able to connect to their virtual desktops after we recompose their VDI with the latest snapshot that recently had 2GB of Windows updates installed.  The user would attempt to log onto the View environment as such:

The Connection Server is preparing the desktop…

They would see a black screen as such:

Then they would get cut off and displayed the following error message:

VMware Horizon Client

The connection to the remote computer ended.

Suspecting the PCoIP logs would assist with the troubleshooting, I browsed over to the desktop’s VDM\logs folder:

\\VDI-001\c$\ProgramData\VMware\VDM\logs

… then opened one of the pcoip_agent logs to review the entries.  Some of the entries I noticed were:

Server died.

… and:

disconnect reason: 0

The follow log entries are as follows:

11/17/2015, 14:02:36.374> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: {s_tag:0x9bd8fbc8ee73a36a} [5] Adding session to list.

11/17/2015, 14:02:36.374> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: {s_tag:0x9bd8fbc8ee73a36a} [5] Total number of active sessions = 1

11/17/2015, 14:02:36.374> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: {s_tag:0x9bd8fbc8ee73a36a} [5] Sending connection response ok.

11/17/2015, 14:02:36.374> LVL:2 RC: 0 AGENT :pcoip_agent_connect_req: {s_tag:0x9bd8fbc8ee73a36a} [5] connection_response (end), 0

11/17/2015, 14:02:36.562> LVL:2 RC: 0 AGENT :monitor_soft_hosts: {s_tag:0x9bd8fbc8ee73a36a} Server died.

11/17/2015, 14:02:36.671> LVL:2 RC: 0 AGENT :tera_agent_disconnect [soft host]: agent close code: 6, disconnect reason: 0

11/17/2015, 14:02:36.671> LVL:2 RC: 0 AGENT :tera_agent_disconnect: {s_tag:0x9bd8fbc8ee73a36a} disconnect is ** NOT ** pending (hndl: 5, pid: 924, process handle: 0000060c)

11/17/2015, 14:02:36.671> LVL:2 RC: 0 AGENT :tera_agent_disconnect: {s_tag:0x9bd8fbc8ee73a36a} Server process already exited (hndl: 5, pid: 924, process handle: 0000060c)

11/17/2015, 14:02:36.671> LVL:2 RC: 0 AGENT :tera_agent_finish_disconnect_thread: connection_closed 6

11/17/2015, 14:02:36.703> LVL:2 RC: 0 AGENT :sSERVER_SESSION::~sSERVER_SESSION: {s_tag:0x9bd8fbc8ee73a36a} Closing pcoip server process handle 000000000000060C

Reviewing the View Connection server’s logs from the folder:

C:\ProgramData\VMware\VDM\logs

… reveal the entry:

2015-11-17T14:17:10.024-04:00 DEBUG (0C70-094C) <e1f29aa5-68ed-437b-ad9f-cc1759d63d8b> [DesktopTracker] onEvent: PENDING_EXPIRED - UserName:a-tluk;DomainName:CONTOSO;UserDn:cn=s-1-5-21-206374890-975330658-925700815-10626,cn=foreignsecurityprincipals,dc=vdi,dc=vmware,dc=int;UserSid:null;GroupSids:null;BrokerUserSid:S-1-5-21-206374890-975330658-925700815-10626;ConnectionId:fcca_***_1220;Protocol:null;ClientName:null;ClientAddress:null;ServerDn:cn=a34734d6-4e78-4d07-83c4-5ce3d1ce31cd,ou=servers,dc=vdi,dc=vmware,dc=int;ServerPoolDn:cn=standard_CON_desktop,ou=server groups,dc=vdi,dc=vmware,dc=int;ServerDnsName:CONFSTAWKST-158.tokiomillennium.com;DynamicIpAddress:10.23.0.92;ManagedObjectId:null;Id:e1f29aa5-68ed-437b-ad9f-cc1759d63d8b;State:PENDING_EXPIRED;SessionGuid:c80b-***-2d5b;PreviousSessionGuid:null;LoggedInAsDomain:CONTOSO;LoggedInAsUser:a-tluk;SessionType:DESKTOP;RemotableContent:null

Reviewing the Events database in the View Administrator console reveals the following:

The pending session on machine <VDIname> for user contoso\a-tluk has expired.

What I’ve done in the past for troubleshooting black screen disconnection issues was to reinstall the VMware Horizon View agent but what I noticed was that attempting to install the View Agent on the master image after uninstalling it would briefly show the splash screen, disappear and nothing would happen.  From there, I proceeded to uninstall VMware Tools and reinstall it but quickly noticed that the install would fail with the message:

VMware Product Installation

This installation package could not be opened. Contact the application vendor to verify that this is a valid Windows Installer package.

Attempting to copy the installer onto the desktop and run the install would generate the following error message:

Setup failed to extract the files necessary to install VMware Tools.

From here on, what ended up being the cause of all these issues was actually because there was no space in the %temp% directory to extract the installation files. The reason why this was the case was because the environment I was working in had SanDisk’s ioVDI solution deployed and the %temp% folder was redirected to a disposable disk that also stored the page file which had already filled up the disk.  This was why the installer for VMware Tools and the Horizon View Agent would fail and it was also why the user had connection issues.

The whole ordeal concluded in a way that I did not expect so I hope the error messages I outlined here would be able to help anyone who happens to come across a similar issue with the same cause.

Reconfiguring a domain previously federated via ADFS with another Azure directory

I recently had to remove the federation between an on-prem Active Directory and an Azure Directory so that we could re-federate the on-prem Active Directory to a new Azure Directory.  The process is quite easy but there doesn’t appear to be clear documentation for the steps so I thought it would be worth while writing this blog post just in case I ever had to do this again in the future.

Begin by removing the domain from the Azure Directory that you no longer need it to be federated to.  The tasks required are as follows:

• Stop the DirSync
• Disable ADFS federation
• Delete the directory (you can’t have the same on-prem directory added to more than one Azure Directory)

Within the new Azure Directory that you are going to federate the on-prem directory to:

• Create a new global admin account for this Azure Directory
• Add the new domain to Azure Directory
• Create the required TXT record to verify the domain
• Launch the WAAD console and execute Connect-MsolService
• Log in with the global admin account for the Azure Directory
• Execute Get-MsolDomain to ensure that the on-prem domain is listed and the Authentication field is listed as Managed

• Execute Set-MsolADFSContext -computer <yourInternalADFSserverFQDN>
• Execute Convert-MsolDomainToFederated -DomainName <domainToFederateFQDN>

• The federation to the previous Azure Directory would have created a Microsoft Office 365 Identity Platform in the Relying Party Trusts folder in the AD FS console as shown here:

• Proceed by deleting it:

• Then recreating it by executing Update-MsolFederatedDomain -domainname <domainToFederateFQDN>

• Refreshing the Relying Party Trusts folder should now show a recreated Microsoft Office 365 Identity Platform
• Reconfigure and then run DirSync now to synchronize the on-prem Active Directory with the Azure Directory

Unable to delete newly created Active Directory in Azure

Problem

You’ve recently created a new Directory in Azure but noticed that you created it in the wrong Location and since it is a new directory with no objects created, you decide to delete quickly notice that you are unable to with the following message presented:

Delete directory

Cannot delete ‘<Directory Name>’

The following issue(s) prevent deletion of this directory:

Directory contains one or more applications that were added by a user or administrator.

Solution

The reason why a seemingly new directory cannot be deleted is because the creation process automatnically creates applications that needs to be manually deleted.  The following KB outlines the process:

You can’t delete a directory through the Azure Management Portal
https://support.microsoft.com/en-us/kb/2967860

The suggested cmdlet that the KB above suggest to be executed is:

Get-MsolServicePrincipal | Remove-MsolServicePrincipal

What I’ve noticed from most colleagues or clients who ask me about this is that they are unsure as to how to run this safely without accidentally deleting applications associated with directories and objects that are in their Azure account.

With this in mind, the correct method of deleting applications associated with the directory you want to delete is to log in with the global administrator of your subscription account that you used to create this directory and create a new global admin for this directory itself:

Ensure that Global Admin is selected:

Continue to create the temporary password:

As this is a new account with a temporary password, you will need to log into the https://login.microsoftonline.com portal once to configure a password first otherwise you won’t be able to log in via remote PowerShell:

Once the password has been set, proceed to launch the Windows Azure Active Directory Module for Windows PowerShell and execute the Connect-MsolService cmdlet, authenticate and execute Get-MsolServicePrincipal:

The list of applications display should only be specific to the directory you are attempting to delete as you are logged into the account that was just created.  Proceed to execute the cmdlet Get-MsolServicePrincipal | Remove-MsolServicePrincipal to delete the applications:

Note that there will be some applications that can’t be deleted as shown in red so it is safe to ignore them.

With the applications deleted, continue by logging in as the global administrator subscription account used to create the directory, delete account that was created and finally delete the directory:

Delete directory

Select the checkbox to delete ‘<Directory Name>’. This can take an hour or more.

Deleting ‘<Directory Name>’ cannot be reversed, and will delete all resources in the directory.

Hope this clarifies the process of safely removing an Azure hosted directory.

Accessing the Update Password webpage published by an ADFS server displays the error: “An error occurred. Contact your administrator for more information.”

Problem

You’ve successfully deployed ADFS in your on-prem environment and would like to use the password change portal that the server provides but you notice that navigating to https://adfs.domain.com/adfs/portal/updatepassword displays the following error:

Expanding the Error details displays the following:

Error details

· Activity ID: 00000000-0000-0000-1400-0080000000d3

· Error time: Wed, 16 Sep 2015 14:02:27 GMT

· Cookie: enabled

· User agent string: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; InfoPath.2; MS-RTC LM 8; .NET CLR 1.1.4322; .NET CLR 3.5.30729; .NET CLR 3.0.30729; MS-RTC EA 2; .NET4.0C; .NET4.0E)

Solution

The reason why the portal is not functioning properly is because you are attempting to use a workstation that isn’t joined to the domain to access this page.  The initial design of this service requires authenticated or registered devices that are joined to the domain but Microsoft changed the relaxed the requirement after receiving feedback from customers.  The patch that relaxes this constraint can be found in the following KB:

https://support.microsoft.com/en-us/kb/3035025#/en-us/kb/3035025

The webpage should function as expected once the patch is applied:

More information about the setup and why the requirement was relaxed can be found in the following MSDN blog post:

Note: ADFS 2012 R2 required authenticated/registered devices (a.k.a ‘workplace join’) to allow the change of passwords. Based on customer feedback, we have relaxed this constraint and allow this from all devices. You will need to apply 3035025 hotfix on all the ADFS servers.

http://blogs.msdn.com/b/samueld/archive/2015/05/13/adfs-2012-r2-now-supports-password-change-not-reset-across-all-devices.aspx

Citrix XenDesktop 7.6 published through a NetScaler throws the error: "This webpage has a redirect loop" error after upgrading from NS11.0 55.20.nc to NS11.0 63.16.nc

Problem

You have a working Citrix XenDesktop 7.6 with StoreFront 3.0 published through a NetScaler VPX appliance NS11.0 55.20.nc that has been stable for quite some time and have decided to upgrade the NetScaler to the latest NS11.0 63.16.nc.  You proceed to go through the upgrade of the appliance:

The appliance appears to be operational as navigating to the portal URL displays the authentication page presented by the NetScaler:

However, you notice that you are not able to successfully log into the portal after entering the credentials because the Internet Explorer browser simply presents a white screen:

You attempt to use Chrome to test instead:

Then notice that instead of a white page, the browser terminates the attempt and displays the message:

This webpage has a redirect loop

ERR_TOO_MANY_REDIRECTS

Expanding the Details option displays the following:

This webpage has a redirect loop

ERR_TOO_MANY_REDIRECTS

Reload

Hide details

The webpage at https://access.domain.com/ has resulted in too many redirects. Clearing your cookies for this site or allowing third-party cookies may fix the problem. If not, it is possibly a server configuration issue and not a problem with your computer.

Learn more about this problem.

Solution

While there may be various causes as to why this error would be thrown, the cause for the environment I worked in was because the upgraded NetScaler did not appear to like the redirect configuration I had in IIS on the StoreFront server:

The Web Interface Address in the NetScaler Gateway Session Profile was configured without the full directory path:

https://storefront.domain.com

What ended correcting the issue was to remove the redirect configured on the IIS properties of the StoreFront server:

… and using the full URL path for the StoreFront website:

https://storefrontdr.domain.com/Citrix/UKWeb

Note that I’ve also tried upgrading the StoreFront server to 3.0.1.55 but that did not correct the issue:

Unable to connect to SQL server instance with SQL Server Management Studio with administrator account even though domain admins group is assigned with sysadmin permissions

Problem

You’re logged directly into a SQL Server 2012 server with an account that belongs to the domain admins group, launch SQL Server Management Studio and attempt to use Windows Authentication to connect to a database instance but notice that you receive the following error:

Cannot connect to <SQLserverName>\<DatabaseInstance>.

Additional information:

Login failed for user ‘<domainName>\<userName>’. (Microsoft SQL Server, Error: 18456)

You’ve confirmed that the Domain Admins group is assigned to the Security > Logins folder and assigned sysadmin permissions:

You noticed that you do not have this problem if you directly add the account you’re logged in as to the logins folder.

Solution

One of the reasons why this issue occurs is if the SQL server exhibiting this behavior has UAC turned on.  If this is the case, the problem will go away if SQL Server Management Studio as ran as an administrator.

Updating an AppStack in VMware App Volumes

This post serves as a continuation of my previous post:

Creating and AppStack with VMware App Volumes
http://terenceluk.blogspot.com/2015/11/creating-and-appstack-with-vmware-app.html

… mainly to demonstrate the process of updating an AppStack that has already been created.

Step #1 – Select the AppStack that needs to be updated

Begin by logging into the App Volumes Manager, navigate to Volumes, AppStacks, expand the AppStack that you would like to update and click on the Update button:

Provide a new name for the AppStack and select (or use the default) storage configuration:

Confirm the prompt for updating the AppStack:

Upon completion, you would now notice a new AppStack created in addition to the one that you are trying to update.  What the wizard basically did was duplicate the existing AppStack to create one for you to modify hence why you had to use a new and unique name.  Proceed by clicking on the Provision button:

Select the virtual machine that you’ll be using to mount this AppStack on and then update the associated application:

Confirm the provisioning:

You will now be brought back to AppStack summary basically displaying the same information that would be presented if you were creating a new one:

Step #2 – Update the application

Proceed to logging onto the virtual machine that you are using for the provisioning process and install the update to the application:

The following message will be displayed:

Installation complete? System will reboot

Click YES to finish and reboot computer.

Or Click No to continue provisioning.

Proceed by clicking on the Yes button then OK:

The following message will be displayed once you have logged in after the restart:

Provisioning successful (exit code 0)

Click OK, then return to the App Volumes Manager to assign the AppStack.

Navigating back to the App Volumes Manager will show that the AppStack is now ready to be assigned: