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.”

Problem

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.

Solution

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.

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.

Problem

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.

Solution

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:

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

Problem

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.

Solution

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 https://autodiscover.domain.com/Autodiscover/Autodiscover.xml

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.

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

Problem

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:

Error:
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.

Solution

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.

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

Problem

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:

Solution

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
http://pubs.vmware.com/horizon-7-view/topic/com.vmware.ICbase/PDF/view-70-installation.pdf

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)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=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:
\LIST:TLSv1.2,TLSv1.1,TLSv1

7. Click OK.

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

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.

Problem

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

Solution

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.

Certificate template not showing up in web enrollment request options for Microsoft Certificate Authority

I ran into an interesting problem at a client this week when I had to request a new certificate from their 2-tier, standalone Root CA and subordinate Enterprise CA, certificate authority infrastructure where a certificate template that we created by duplicating the Web Server template naming it Web Server Exportable then published would not show up in web enrollment request options.  The following are screenshots of the behavior of the web enrollment page after removing all of the published certificate templates and leaving the one I want to use:

https://<subordinateCA>/certserv

No certificate templates could be found. You do not have permission to request a certificate from this CA, or an error occurred while accessing the Active Directory.

Note the (No templates found!) listed in the Certificate template: drop down box:

After troubleshooting for a couple hours and attempting the following solutions found on the internet:

Verified the following KB was not the issue: https://support.microsoft.com/en-us/kb/811418

1. Check to ensure the security permissions for the certificate template was set appropriately
2. Ensure that Supply in the request was selected under the Subject Name tab
3. Created a new application pool and assigned the Certsrv directory to it
4. Ensure certificate template compatibility was the same or below the domain and forest functional level
5. Changed the application pool’s advanced settings identity from ApplicationPoolIdentity to NetworkService

... which did not correct my issue, I went ahead and opened a case with Microsoft.

What we noticed was that we would be able to get the published template to show up if we changed the name from Web Server Exportable to Web_Server_Exportable, using a a different name.  This lead the engineer to suspect that there might be something lingering in AD that was causing the template with the original name not to show up in the web enrollment webpage.  To troubleshoot, we exported the Configuration container information to a text file via the ldifde command as such:

ldifde -f out.txt -d "CN=Configuration,DC=ad,DC=domain,DC=bm"

We then did a find on the exported out.txt file and immediately found an entry for WebServerExportable:

What we found was that another certificate authority in Active Directory which was an Enterprise Root CA  had a template published with the same name.  Logging onto that server and launching the Certificate Authority administration console showed the following:

The template listed as <Unknown> was what caused the template on the other CA to not be displayed so we went ahead and removed the template, forced an Active Directory replication with repadmin /syncall /AdePq, reran the ldifde export to confirm the template was no longer listed under this CA, then confirmed that the template is now shown in the web enrollment page.

Hope this post helps anyone who may come across a situation similar to this.

Quick and easy way of upgrading or installing VMware Horizon View Agent with Group Policy GPO

While most enterprise organizations typically have deployment applications such as SCCM for new or upgrades of applications, some smaller companies may not and tasks such as upgrading the VMware Horizon View agent may become quite labour intensive if the environment uses full clone desktops that exceed a count of, say, 20. This was the scenario I faced recently at a small organization and rather than manually logging into each full clone virtual desktop to upgrade the VMware Horizon View agent, I decided to use Group Policy GPO for the task.

The first item we need prior to setting up the GPO is to obtain the command that performs a silent install of the VMware Horizon View agent and this command can be found in the following KB:

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1019862

The install switches is shown in line item #4:

4. Open a command prompt on the desktop and run this command:

VMware-viewagent.exe /S /V"/qn REBOOT=Reallysuppress"

Note: REBOOT=Reallysuppress suppresses a reboot after the install. If you remove REBOOT=Reallysuppress, the machine automatically reboots after the install.

Since we would like to automatically install the VMware View Agent without any administrator intervention, we will remove the REBOOT=Reallysuppress switch so an auto reboot would be triggered after the install.

As a result, the switches added to the installation executable we’ll be running would be as such: VMware-viewagent.exe /S /V"/qn

Placing the VMware View Agent executable onto a share named ViewAgentShare on a file server named fileserver would look as such:

\\fileserver\ViewAgentShare\VMware-viewagent-x86_64-7.0.2-4368292.exe /S /V"/qn

With the above prepared, the next step is to create a GPO, navigate to Computer Configuration > Policies > Windows Settings > Scripts (Startup/Shutdown), double click on Startup then create a batch file as shown in the screenshot below:

Once the GPO has been created, proceed to create an OU for the VMware Horizon View agent deployment, place the full clone virtual desktops’ computer objects into the OU, restart the actual VDI and you should see the agent being silently installed.

The only caveat with this method is that you will need to move the computer object out of the deployment OU once the deployment has started or before the desktop reboots or it would attempt to perform another silent install after the restart.

Hope this helps anyone looking for a quick way to deploy a new or upgrade an existing VMwar View agent.