Monday, December 5, 2016

Attempting to upgrade Citrix StoreFront (Xenpp 7.6) to (XenApp 7.11) fails with: “An error occurred during installation. Please ensure all the required prerequisites have been installed an run the installer again.”


You’re attempting to upgrade your XenApp 7.6 environment to 7.11 but noticed that the upgrade for Citrix StoreFront


… to fails with:

StoreFront did not install

An error occurred during the installation.

StoreFront failed.

Citrix StoreFront failed.

An error occurred during installation. Please ensure all the required prerequisites have been installed an run the installer again.


Reviewing the Application log events show the following error logged:

Log Name: Application

Source: Citrix Extensible Meta-Install

Event ID: 0

Level: Error


Timestamp: 12/3/2016 11:41:18 AM

Category:Error, WinError

Message:Installation of '..\CitrixStoreFront-x64.msi' failed with error code 1603. Fatal error during installation


Reviewing the installation log CitrixMsi-CitrixStoreFront-x64-2016-12-03-11-41-06.log file does not provide a reason why the installation failed other than indicating that it did:

Property(S): OutOfNoRbDiskSpace = 0

Property(S): PrimaryVolumeSpaceAvailable = 0

Property(S): PrimaryVolumeSpaceRequired = 0

Property(S): PrimaryVolumeSpaceRemaining = 0

Property(S): INSTALLLEVEL = 1

MSI (s) (98:E8) [11:41:18:642]: Note: 1: 1708

MSI (s) (98:E8) [11:41:18:642]: Product: Citrix StoreFront -- Installation failed.

MSI (s) (98:E8) [11:41:18:643]: Windows Installer installed the product. Product Name: Citrix StoreFront. Product Version: Product Language: 1033. Manufacturer: Citrix Systems, Inc.. Installation success or error status: 1603.

MSI (s) (98:E8) [11:41:18:650]: Deferring clean up of packages/files, if any exist

MSI (s) (98:E8) [11:41:18:650]: MainEngineThread is returning 1603

MSI (s) (98:F0) [11:41:18:653]: RESTART MANAGER: Session closed.

MSI (s) (98:F0) [11:41:18:655]: RESTART MANAGER: Session closed.

MSI (s) (98:F0) [11:41:18:655]: No System Restore sequence number for this installation.

=== Logging stopped: 12/3/2016 11:41:18 ===

MSI (s) (98:F0) [11:41:18:662]: User policy value 'DisableRollback' is 0

MSI (s) (98:F0) [11:41:18:662]: Machine policy value 'DisableRollback' is 0

MSI (s) (98:F0) [11:41:18:662]: Incrementing counter to disable shutdown. Counter after increment: 0

MSI (s) (98:F0) [11:41:18:662]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2

MSI (s) (98:F0) [11:41:18:663]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2

MSI (s) (98:F0) [11:41:18:663]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1

MSI (s) (98:F0) [11:41:18:663]: Destroying RemoteAPI object.

MSI (s) (98:10) [11:41:18:663]: Custom Action Manager thread ending.

MSI (c) (A8:D8) [11:41:18:665]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1

MSI (c) (A8:D8) [11:41:18:666]: MainEngineThread is returning 1603

=== Verbose logging stopped: 12/3/2016 11:41:18 ===



While there could be various reasons as to why this error would be thrown during the upgrade of StoreFront to 3.7, one of the reasons that could cause this is if you have applied customizations to the UI of the legacy 2.6 StoreFront.  The environment above environment had the following customization applied so that allow the applications were displayed and placed into appropriate folders:

The links to the package in the above blog post no longer work so if you come across an environment with these customizations applied and not sure how it is configured, the following are the files bundled in the package:


The ReadMe.txt file contains the following instructions:

This folder contains customization files for Citrix Receiver for Web 2.5 to provide a folder view for a mandatory store:





If you have not customized your Receiver for Web site, simply copy all the files to the contrib folder of your site.

If you have modified any of custom.script.js, and custom.wrstrings.en.js, you have to manually merge the files in the folder with your modified files and copy the remaining files.

In addition, if you need to support other languages, you have to translate the string "Main" and insert the translated string into custom.wrstrings.<lang-code>.js.





The following files located in C:\inetpub\wwwroot\Citrix\<yourCitrixSite>Web\contrib  are the ones that were replaced:

  • custom.script.js
  • custom.wrstrings.en.js
  • FolderClosed32.png
  • folderview.min.js

The easiest way to get the original UI back is simply navigate to the \contrib folder of a Citrix StoreFront site that wasn’t customized and copy the files back over.  If there is no additional StoreFront site to use then create a new temporary one and copy the files over:


Once the files are over, restart the StoreFront server (an iisreset does not appear to be enough), rerun the upgrade and process should now complete:


Wednesday, November 30, 2016

Attempting to connect to a VMware Horizon View virtual desktop from external throws the error: “The display protocol for this desktop is currently not available. Please contact your system administrator.”


You attempt to connect to a virtual desktop from the internet with the VMware View Horizon Client which passes the traffic to VMware Horizon View Security server which then contacts the View Connection server which then attempts to establish a connection to the VDI but fails with the following message:

The display protocol for this desktop is currently not available. Please contact your system administrator.



While there are various reasons why this error would be thrown, one of them is if your View Connection server has a stale DNS entry to the virtual desktop. A client recently contacted me to troubleshoot this error message and what the problem ended up to be was that the virtual desktops were changed to another port group and while the DNS entries were updated on the domain controllers in the same Active Directory site, the View Connection servers were using DNS servers from a different Active Directory Site so the changes to the DNS entries were not immediately available causing this error to be thrown.

Wednesday, November 23, 2016

Server Manger displays the following message for Remote Desktop Services: "There are no RD Connection Broker servers in the server pool"

I’ve been asked several times this year about a seemingly trivial task that I tend to forget myself so I thought I’d write a quick blog post about it in case someone encounters the same situation and for myself to refer to in the future.


You’ve in one of the following situations:

1. You’ve deployed a new RDS server and added it to an existing collections and would like to perform administrative tasks from that server

2. You’ve asked another administrator to administer an existing RDS server but this administrator uses an account that has never performed these tasks

The problem encountered here in either of the cases above is that when you log onto an RDS server that was recently added to a collection or with an account that has never administered the RDS collections before, you will notice that the options to administer the servers are not available in Server Manager:


Navigating to the Remote Desktop Services section will display the following message:

There are no RD Connection Broker servers in the server pool.

To manage a deployment, you must add all the servers in the deployment to the server pool.

To create a new deployment, run the Add Roles and Features Wizard and select the Remote Desktop Services installation option.



I find that most administrators including myself would eventually figure this out but I tend to forget a few months afterwards. To get the Remote Desktop Services collection to show up in the Server Manager console, click on the Manage button on the top right hand corner and then Add Servers:


You will need to add all of the RDS servers in the collection into this Window but if you only know of one because you’re not familiar with the environment, you can go ahead and add just the one you know of:



Hitting the OK button will bring you back to the Dashboard:


Clicking on the Remote Desktop Services section will display a message telling you that you need to add the rest of the servers in the deployment:

The following servers in this deployment are not part of the server pool:

The servers must be added to the server pool.


Proceed by adding the servers listed:



You should now see the collections in the deployment once the servers have been added:



Thursday, November 17, 2016

Security Alert with certificate error presented when users launch Outlook 2013 or 2016 in an Exchange Server 2016 environment


You have recently migrated from an earlier version of Exchange 2010 or 2013 to Exchange Server 2016 and noticed that users are now receiving a Security Alert with a certificate error when they launch Outlook:

Information you exchange with this site cannot be viewed or changed by others. However, there is a problem with the site’s security certificate.


Clicking on the View Certificate button will show the certificate you’ve assigned to the Exchange server and the reason why it is showing an error is because the certificate does not have a SAN entry for the internal server FQDN as shown in the screenshot.


While some administrators would choose to proceed by adding the internal server FQDN onto the certificate to get around this issue, it is actually not required.  The first and most important reason is that public Certificate Authorities no longer issue certificates with internal domain names such as .local which means if your internal domain used a non-routable suffix then there would be no way to get the FQDN into the certificate as a SAN entry.

One of the reasons why this error would be thrown when users launch their Outlook is that the Service Connection Point (SCP) for Autodiscover has not been updated yet.  Begin by executing the following cmdlet to review the AutoDiscoverServiceInternalUri configuration:

Get-ClientAccessService -identity <serverName> | FL


Note how the AutoDiscoverServiceInternalUri references FQDN of the internal server name which would cause this error to be thrown if your internal certificate did not have the internal server’s FQDN as a SAN entry.  To correct this issue, simply use the following cmdlet to configure it to use the autodiscover URL that you would have added as a SAN entry in the certificate and usually resolves to a record that load balances traffic to the Exchange servers in the organization or directly to an Exchange server is there is only one in the organization:

Set-ClientAccessService -identity <serverName> -AutoDiscoverServiceInternalUri

With the above configuration corrected, users will now be directed to the autodiscover URL that has an entry on the certificate assigned to the Exchange servers.

As stated earlier, note that this error can be thrown by various reasons and the solution stated here may not apply to every instance of this message.

Friday, November 11, 2016

Installing Microsoft Exchange Server 2016 Cumulative Update 3 throws the error: “… System.Security.Cryptography.CryptographicException: The certificate is expired.”


You’re attempting to install the latest cumulative update onto your Exchange 2016 server (Microsoft Exchange Server 2016 Cumulative Update 3 in this example) but notice that the process fails at:

Step 4 of 11: Mailbox role: Transport service

… with the following error message:

The following error was generated when "$error.Clear();
          Install-ExchangeCertificate -services IIS -DomainController $RoleDomainController
          if ($RoleIsDatacenter -ne $true -And $RoleIsPartnerHosted -ne $true)
            Install-AuthCertificate -DomainController $RoleDomainController
        " was run: "System.Security.Cryptography.CryptographicException: The certificate is expired.
   at Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception, ErrorCategory category, Object target, Boolean reThrow, String helpUrl)
   at Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception, ErrorCategory category, Object target)
   at Microsoft.Exchange.Management.SystemConfigurationTasks.InstallExchangeCertificate.InternalProcessRecord()
   at Microsoft.Exchange.Configuration.Tasks.Task.<ProcessRecord>b__b()
   at Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)".


The installation does not proceed and you are forced to close the installer.  Attempting to run the installer again will restart the process but fail with the same error message.


One of the reasons why this error would be thrown is if you have an expired certificate still binded in IIS as shown in the following screenshot where one of the two https directories have the updated certificate but the other one does not:


To correct the issue, simply update the binding or bindings with a non-expired certificate and rerun the installation.  Note that it is ok to have the expired certificate in the local store of the server but it should not be binded.

Wednesday, November 9, 2016

Upgrading VMware Horizon View to 7.0.x causes vCenter Server Status to be red with “Untrusted Certificate” but clicking on the “Verify” button does nothing


I’ve had a several clients call me in regards to a common issue when upgrading VMware Horizon View to veresion 7.0.x where their vCenter Servers status is labeled with the red colour and the Status is listed as Untrusted Certificate but clicking on the Verify button does nothing:

Status: Untrusted Certificate Verify

For self-signed certificate, click ‘Verify’. If the vCenter Server certificate can be validated, make sure that the trusted store on the Connection Server system has the correct Certification Authorities.

SSL Certificate: Invalid



I find that this issue throws a lot of administrators off because previous versions simply allow you to click on the Verify button, accept the self-signed certificate, and you’re on your way but version 7 appears to render the button clickable but does nothing when you click on it other than give you a click symbol as if it was doing something:



The reason why this would happen is if the vCenter in the environment is running an earlier release of vCenter Server 5.0, 5.1, and 5.5 where only TLSv1.0 is supported. VMware Horizon 7 and later components have TLSv1.0 disabled and thus causes this strange behavior to occur.  More information can be found in the deployment guide here:

View Installation
VMware Horizon 7 Version 7.0
VMware Horizon 7 Version 7.0.1
VMware Horizon 7 Version 7.0.2


To resolve this issue, either upgrade vCenter Server to 6.0 Update 1B or workaround the issue by re-enabling TLSv1.0 on the VMware View Composer as outlined in the following KB:

Unable to verify vCenter certificate in VMware View Administrator (2144967)

Re-enable TLSv1.0 on enable VMware View Composer

To re-enable TLSv1.0 on enable VMware View Composer:

1. Click Start > Run, type regedit, and click OK. The Registry Editor window opens.

2. Navigate to HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS1.0\Client
Note: If this key does not already exist, create the key.

3. Delete the value Enabled if it exists.

4. Edit the DWORD value DisabledByDefault and set it to 0.


5. Restart the VMware View Composer service. TLSv1.0 connections from View Composer to vCenter are now enabled.

6. Navigate to HKLM\SOFTWARE\VMware,Inc.\VMware View Composer.

7. Create or edit the String value EnableTLS1.0 and set it to 1.

8. If the View Composer host is a 64-bit machine, navigate to HKLM\SOFTWARE\WOW6432Node\VMware,Inc\VMware View Composer.

9. Create or edit the String value EnableTLS1.0 and set it to 1.


10. Restart the VMware Horizon View Composer service.TLSv1.0 connections from View Composer to ESXi hosts are now enabled.

Re-enable TLSv1.0 on enable VMware Connection Server

To re-enable TLSv1.0 on enable VMware Connection Server:

1. Start the ADSI Edit utility on your View Connection Server host.

2. In the console tree, select Connect to.

3. In the Select or type a Distinguished Name, type the distinguished name DC=vdi,DC=vmware, DC=int.

4. In the Computer pane, select or type localhost:389 or the fully qualified domain name (FQDN) of the View Connection Server host followed by port 389.


5. Expand the ADSI Edit tree, expand OU=Properties, select OU=Global, and double-click CN=Common.

6. In the Properties dialog box, edit the pae-ClientSSLSecureProtocols attribute to add this entry:


7. Click OK.

8. Restart the VMware Horizon View Connection Server service on each connection server instance.


Tuesday, November 8, 2016

Unable to move, copy or rename a long file name on a Windows file server – error message: “The filename or extension is too long.”

Ran into an interesting problem this week that seemed trivial but ended up causing quite a bit of headache so I thought it would be great to write this short blog post in case someone else runs into the same issue.


You’ve noticed that one of your file servers contain a file that has a name too long to move or copy to another destination because the following message is presented when an attempt is made:

The file name(s) would be too long for the destination folder. You can shorten the file name and try again, or try a location that has a short path.


Reviewing the file name shows that it is extremely long:


This file name is so long that the server doesn’t provide the choice to rename it and it would fail even if an attempt is made to copy it onto the C drive:


Note the only options available in the screenshot above when you right click on the file are:

  • Open with
  • Send to
    • Compressed (zipped) folder
    • Desktop (create shortcut)
    • Mail recipient

Attempting to use the command prompt to rename the file would throw the following error:

The filename or extension is too long.


Other troubleshooting steps that were tried but yield the same results are as follows:

  1. Copy and paste to a higher level folder (no surprise as copying it to the C drive which would have generated the shortest path did not work)
  2. Copying to the desktop
  3. Copying to another network drive
  4. Renaming a top level folder
  5. Attempting to open the file with Adobe Acrobat so we could resave it


After trying to other steps such as renaming the top level folders and not being able to, what we found was that if we used an application such as WinRAR to compress the file into a .rar file, we would then be able to rename it to a shorter file name within the compressed file, then extract the new renamed file back onto the file server.

Hope this helps anyone who may encounter such an issue on their file server.