Pages

Friday, October 13, 2017

VMware VDP 6.1.2.19 backups fail with the error message: “An attempt made to backup a client failed because no data was found that matches the type of data that the job was configured for.”

Problem

You’ve noticed that backup jobs within VDP have been failing with the following errors:

VDP: An attempt made to backup a client failed because no data was found that matches the type of data that the job was configured for.

VDP: An unexpected error occurred with the following error code: 30983. More information may be available in the client logs which can be downloaded from the configuration application (https://<VDP hostname>:8543/VDP-configure).

image

Viewing the task failure report displays the following:

Reason: VDP: An attempt made to backup a client failed because no data was found that matches the type of data that the job was configured for.

Log file retrieved is empty.

image

Reason: VDP: An unexpected error occurred with the following error code: 30983. More information may be available in the client logs which can be downloaded from the configuration application (https://<VDP hostname>:8543/VDP-configure).

Failed to retrieve log file. This can happen if:

* Management Services were recently restarted.

* Regular log maintenance has removed old log files.

* Logs may be empty or non existent.

*An error may have occurred.

image

Solution

One of the reasons why the VDP backup jobs have failed and will continue to fail is if you have a mismatch between supported versions of VDP with the vCenter version that you are running.  In the example above, the failures started when the vCenter server was upgraded to:

Version: vCenter Server 5.5 Update 3e

Release Date: 2016-08-04

Build Number: 4180647

Installer Build Number: 4180646

image

The VDP appliance in the environment was at version 6.1.2.19:

image

The supported version for vCenter Server 5.5. Update 3e was 6.1.3 so updating the VDP appliance to 6.1.3.70 corrected the problem:

image

Thursday, October 12, 2017

ThinPrint redirected printer printing issue with VMware Horizon View Client 4.6.0

I recently ran into a strange issue with a client that had a satellite office with 4 users who use a Lenovo Windows 10 PC and VMware Horizon View client to connect back to their desktops in the main datacenter.  The satellite office is relatively new so the VMware Horizon View client installed onto the PCs were version 4.5.0 but two of the desktops recently had to be swapped out due to hardware failures and since a newer 4.6.0 client was out, I decided to go with the latest version.  Shortly after the new Lenovo PCs with the newer client were deployed, I received reports that:

  1. Attempting to print a multiple paged email from their Outlook 2010 client would insert blank pages in between pages with content and/or skip some pages all together
  2. Attempting to print attachments (e.g. PDF) on emails would send the print job but nothing prints
  3. Word documents print properly

I originally did not suspect this was related to VMware Horizon View so I sent my colleague out to have her check the drivers and any other Windows components worth reviewing.  A day goes by without a resolution so the issue was escalated to me and that was when I realized the only difference between the two non-working PCs and the other ones that were working was the newer VMware Horizon Client 4.6.0.9732:

image

Having exhausted most options that could be tried on the Windows 10 operating system, I quickly downgraded the client to 4.5.0.8090 and printing immediately functioning as expected:


image

I’m not completely sure there is a known bug for this client as the release notes here does not mention such an issue:

VMware Horizon Client 4.6 for Windows Release Notes
https://docs.vmware.com/en/VMware-Horizon-Client-for-Windows/4.6/rn/horizon-client-windows-46-release-notes.html

I hope this blog post will be able to help anyone who may come across this issue and in case anyone wants to compare operating version versions, below is the Windows OS on the Lenovo details:

image

Monday, October 2, 2017

Installing Exchange Server 2016 CU7 fails with the error: “…was run: "System.Security.Cryptography.CryptographicException: The certificate is expired.”

Problem

You’ve started the installation of Exchange Server 2016 Cumulative Update 7 but notice that it fails at the step Mailbox role: Transport service with the following error:

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.Task.Task.ThrowError(Exception exception, ErrorCatagory errorCatagory, Object target,

String helpUrl)

at Microsoft.Exchange.Management.SystemConfigurationTasks.InstallExchangeCertificate.InternalProcessRecord()

at Microsoft.Exchange.Configuration.Tasks.Task.<ProcessRecrod>b_91_1()

at Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolen

terminatePipelinelfFailed)”.

image

Solution

The reason why the installation of the CU update failed is because the process attempts to validate the certificate Exchange Server 2016 is using for its services and if an expired certificate is found to be binded to a service, the update will fail.  What usually causes panic at this point is that the Exchange server services are not going to be up and trying to launch the Management Shell would prompting show that Exchange PowerShell cmdlets are not available:

image

To get through this issue, you can simply assign a valid certificate via the Internet Information Services (IIS) Manager console:

image

Note that the screenshot above has the binding configured with the self-signed certificate generated by the initial Exchange 2016 installation.  Using the self-signed certificate is a good way to workaround not being able to proceed with the CU install while you renew the certificate.

With the certificate bindings configured with a valid certificate, proceed to rerun the CU update and it should complete as expected:

imageclip_image002