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

Friday, September 29, 2017

Adding SAN (Subject Alternative Name” into “Additional Attributes” field on a Microsoft Certificate Authority certificate request form does not generate a certificate with a SAN entry

Problem

You’ve completed the process of creating a new keystore with a CSR from the Portecle utility:

http://portecle.sourceforge.net/

image

Since the Portecle utility does not provide the feature to include SAN entries:

https://www.sslsupportdesk.com/portecle-advanced-keystore-creation-and-manipulation-tool/

image

This isn’t usually a problem because it is possible to add SAN entries in the Additional Attributes field when submitting the CSR to a Microsoft Certificate Authority server as described here:

How to add a subject alternative name to a secure LDAP certificate
https://support.microsoft.com/en-us/help/931351/how-to-add-a-subject-alternative-name-to-a-secure-ldap-certificate

An example of the format of the string to include is:

san:dns=corpdc1.fabrikam.com&dns=ldap.fabrikam.com

You proceed to submit the request:

image

… but notice that the generated certificate does not include a SAN entry.

Solution

One of the reasons why performing the above would not generate a certificate that includes a SAN entry is if the issuance policy of the Microsoft CA is not configured to accept the Subject Alternative Name(s) attribute via the CA Web enrollment page.  To correct this, execute the following command:

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

image

Once the above command is executed, stop and start the certificate authority with:

net stop certsvc
net start certsvc

Proceed to use the CA web enrollment page to generate the certificate with the SAN entry.

---------------------------------------------------------------------------------------------------------------------------

Security Concerns:

Note that as per the following Microsoft article:

https://technet.microsoft.com/en-us/library/ff625722(v=ws.10).aspx

It is not recommended to enable the acceptance of the SAN attribute for the CA Web enrollment page so please review the Security best practices for allowing SANs in certificates section in the article above to be aware of the security concerns.

Friday, September 22, 2017

Attempting to assign a certificate to the Lync Server 2013 services via the Certificate Wizard console fails and generates the error message: “Command execution failed: The process does not possess the 'SeSecurityPrivilege' privilege which is required for this operation.”

Problem

You’ve created a new certificate for your Lync Server 2013 services and attempt to assign it to Server default and Web services internal:

image

However, the assignment fails and the following error message is displayed:

Command execution failed: The process does not possess the 'SeSecurityPrivilege' privilege which is required for this operation.

image

Solution

One of the reasons why the certificate assignment would fail with the error message above is if an administrator or group policy has removed the administrators group from the Lync Server’s Manage auditing and security log policy as shown in the following screenshot:

image

To correct the problem, simply grant the local administrators group the Manage auditing and security log policy permissions:

image

You should be able to assign certificates to Lync Server 2013 services once the above has been completed.

Tuesday, September 19, 2017

A recent change to the SQL authentication account for an SRM database causes the VMware vCenter Site Recovery Manager Server to no longer start

Problem

You’ve recently had to reset the password to the SQL authentication account used by your VMware vCenter Site Recovery Manager to connect to the SRM database so you proceed to update the ODBC System DSN as such:

imageimage

imageimage

However, attempting to start the VMware vCenter Site Recovery Manager service fails with the following error:

image

The VMware vCenter Site Recovery Manager Server service on Local Computer started and then stopped. Some services stop automatically if they are not in use by other services or programs.

image

The following event error is logged in the event logs after the failed start:

Log Name: Application

Source: vmware-dr

Event ID: 3

Level: Error

DBManager error: Could not initialize Vdb connection: ODBC error: (28000) - [Microsoft][SQL Server Native Client 10.0][SQL Server]Login failed for user 'vmware'.

image

Attempting to modify the installation of SRM will display the following error:

A database error has occurred.

image

Solution

The reason why the service is unable to start is because other than updating the ODBC System DSN, you’ll also need to use one of the steps in the following KB to update the password:

Migrating an SRM server to run on a different host (1008426)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008426

The step required to get the environment in this example up is #7:

Run the installcreds.exe utility to register account credentials on the new host with the old DSN:
installcreds.exe -key db:new_SRM_DSN -u sql_admin_user
The installcreds.exe utility can be found in the bin directory of the SRM installation:
C:\Program Files\VMware\VMware Site Recovery Manager\bin

The following is an example of the executed command:

C:\Program Files\VMware\VMware vCenter Site Recovery Manager\bin

C:\Program Files\VMware\VMware vCenter Site Recovery Manager\bin>installcreds.exe -key db:SRMDR -u vmware
VMware internal use only. This program is intended for use only by the SRM installer.
Enter Password:
Installed new credentials for db:SRMDR

C:\Program Files\VMware\VMware vCenter Site Recovery Manager\bin>

image

The service should now start as the password has been updated:

image

Saturday, September 9, 2017

Update: Securing Citrix NetScaler VPX to score A+ rating on SSL Labs

Those who have used my previous blog post:

Securing Citrix NetScaler VPX to score A+ rating on SSL Labs
http://terenceluk.blogspot.com/2016/06/securing-citrix-netscaler-vpx-to-score.html

… to score an A+ on Qualys SSL Labs (https://www.ssllabs.com/ssltest/) may have noticed that they are now scoring an A- due to some minor changes to the criteria. 

There is no support for secure renegotiation. Grade reduced to A-. MORE INFO »

The server does not support Forward Secrecy with the reference browsers. Grade reduced to A-. MORE INFO »

image

The required changes to the configuration are minimal so this blog post serves to demonstrate the tweaks required to bring the score back to an A+.

The version of the NetScaler VPX I’ll be using for this demonstration is:

NS11.1: Build 49.16.nc

image

Step #1 – Confirm that the SSL certificate used is SHA2/SHA256 signature

Ensure that the SSL certificate used to secure the site uses the SHA2/SHA256 signature for both the root and intermediate.

image

Step #2 – Confirm that SSVLv3 is disabled and TLSv12 is enabled

With the appropriate certificate assigned begin by ensuring that SSLv3 is disabled and TLSv12 is enabled for the SSL Parameters of the virtual server:

image

Step #3 – Update Custom Ciphers

The ciphers listed in my previous post is outdated so proceed to remove the existing configuration or appending the new ciphers in, or creating a new one with the following ciphers:

TLS1.2-ECDHE-RSA-AES256-GCM-SHA384
TLS1.2-ECDHE-RSA-AES128-GCM-SHA256
TLS1.2-ECDHE-RSA-AES-256-SHA384
TLS1.2-ECDHE-RSA-AES-128-SHA256
TLS1-ECDHE-RSA-AES256-SHA
TLS1-ECDHE-RSA-AES128-SHA
TLS1.2-DHE-RSA-AES256-GCM-SHA384
TLS1.2-DHE-RSA-AES128-GCM-SHA256
TLS1-DHE-RSA-AES-256-CBC-SHA
TLS1-DHE-RSA-AES-128-CBC-SHA
TLS1-AES-256-CBC-SHA
TLS1-AES-128-CBC-SHA
SSL3-DES-CBC3-SHA

The following command can be used to create a new custom cipher with the required ciphers:

add ssl cipher Custom-VPX-Cipher

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-ECDHE-RSA-AES256-GCM-SHA384

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-ECDHE-RSA-AES128-GCM-SHA256

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-ECDHE-RSA-AES-256-SHA384

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-ECDHE-RSA-AES-128-SHA256

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-ECDHE-RSA-AES256-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-ECDHE-RSA-AES128-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-DHE-RSA-AES256-GCM-SHA384

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-DHE-RSA-AES128-GCM-SHA256

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-DHE-RSA-AES-256-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-DHE-RSA-AES-128-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-AES-256-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-AES-128-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName SSL3-DES-CBC3-SHA

With the custom cipher created, ensure that the virtual server is configured to use it:

image

Step #4 – Configure Deny SSL Renegotiation to FRONTEND_CLIENT

Navigate to Traffic Management > SSL > Change advanced SSL settings:

image

Change the Deny SSL Renegotiation setting from ALL to FRONTEND_CLIENT:

image

image

Alternatively, the following command can be executed to change the configuration:

set ssl parameter -denySSLReneg FRONTEND_CLIENT

image

-------------------------------------------------------------------------------------------------------------------------

You should now score an A+ with the adjustments listed above configured:

image

Remember to save the configuration!

Thursday, August 24, 2017

Attempting to mount Exchange Server 2016 DAG database with 1 of 2 nodes down throws the error: “Error: An Active Manager operation failed. Error: An Active Manager operation encountered an error. To perform this operation, the server must be a member of a database availability group, and the database availability group must have quorum. Error: Automount consensus not reached (Reason: ConcensusUnanimity does not allow auto mount. (IsAllNodesUp: False)).”

Problem

You have two Exchange 2016 mailbox servers configured as a DAG and one server providing witness servers.  One of the mailbox server experiences an issue and goes down so the remaining mailbox server continues to service mailbox requests and has the databases mounted.  The remaining operational server is restarted and you immediately notice that the databases are not mounted after the restart: 

image

Attempting to mount the databases with the Mount-Database command throws the following error:

[PS] C:\Windows\system32>Mount-Database contoso-edb16-01

Failed to mount database "contoso-edb16-01". Error: An Active Manager operation failed. Error: An Active Manager operation

encountered an error. To perform this operation, the server must be a member of a database availability group, and the

database availability group must have quorum. Error: Automount consensus not reached (Reason: ConcensusUnanimity does

not allow auto mount. (IsAllNodesUp: False)). [Server: contoso-MBX16-01.contoso.NET]

    + CategoryInfo          : InvalidOperation: (contoso-EDB16-01:ADObjectId) [Mount-Database], InvalidOperationException

    + FullyQualifiedErrorId : [Server=contoso-MBX16-01,RequestId=ae45aaee-8113-4908-a0fd-34e3d4a032a2,TimeStamp=17/08/2017

    12:20:16] [FailureCategory=Cmdlet-InvalidOperationException] A5CACA44,Microsoft.Exchange.Management.SystemConfigu

  rationTasks.MountDatabase

    + PSComputerName        : contoso-mbx16-01.contoso.net

[PS] C:\Windows\system32>Get-DatabaseAvailabilityGroup

image

Executing the Get-DatabaseAvailabilityGroup cmdlet displays the following message:

Warning: Unable to get Primary Active Manager information due to an Active Manager call failure. Error: An Active Manager operation failed. Error: An Active Manager operation encountered and error. To perform this operation, the server must be a member of a database availability group, and the database availability group must have a quorum. Error: Automount consensus not reached (Reason: ConcensusUnanimity does not allow auto mount. (IsAllNodesUp: False)).

image

Executing the Get-MailboxDatabaseCopyStatus * cmdlet indicates the status of the mailbox databases in the DAG as Unknown:

image

Solution

The reason why the databases would not automount and manually mounting them would fail is because the DAG has Datacenter Activation Coordination (DAC) mode enabled and this forces starting DAG members to acquire permission in order to mount any mailbox databases.  In the example above, the DAG is unable to achieve a quorum with the second node down and therefore the DAG isn’t started and databases would not be able to mount.  If you are sure that the second node is down as in the example above, you can manually start the DAG with the cmdlet:

Start-DatabaseAvailabilityGroup -Identity <DAG NAME> -MailboxServer <MailboxServerName>

image

The status of the mailbox databases should now be listed from Unknown to Dismounted once the DAG has been started and issuing the Mount-Database cmdlet will now successfully mount the databases:

image

The following are TechNet blog posts that provide a more in depth explanation of DAG and DAC:

Part 1: My databases do not automatically mount after I enabled Datacenter Activation Coordination
https://blogs.technet.microsoft.com/timmcmic/2012/05/21/part-1-my-databases-do-not-automatically-mount-after-i-enabled-datacenter-activation-coordination/


Part 5: Datacenter Activation Coordination: How do I force automount consensus?
https://blogs.technet.microsoft.com/timmcmic/2013/01/27/part-5-datacenter-activation-coordination-how-do-i-force-automount-consensus/

Wednesday, August 23, 2017

Attempting to export an Exchange Server mailbox to PST throws the error: “Couldn’t locate a database suitable for storing this request.”

I’ve noticed that many of my colleagues and clients have asked me about the following error that is thrown when they attempt to export an Exchange Server mailbox to PST so I thought it would be a good idea to quickly write a post about the error.

Problem

You attempt to export a mailbox to PST via the Exchange Admin Center but received the following error:

Couldn’t locate a database suitable for storing this request.

image

Using the New-MailboxExportRequest feature displays a similar error:

[PS] C:\Windows\system32>New-MailboxExportRequest -Mailbox mbraithwaite -FilePath "\\tmrfp09\archive$\Outlook Archive\mb
raithwaite.pst"
Couldn't locate a database suitable for storing this request.
     + CategoryInfo          : InvalidArgument: (mbraithwaite:MailboxOrMailUserIdParameter) [New-MailboxExportRequest],
     MailboxDatabase...manentException
     + FullyQualifiedErrorId : [Server=contBMEXMB01,RequestId=c7446094-7d17-4e06-90c4-07be8ca10829,TimeStamp=8/23/2017 2
    :46:00 PM] [FailureCategory=Cmdlet-MailboxDatabaseVersionUnsupportedPermanentException] 4B192EAA,Microsoft.Exchang
   e.Management.Migration.MailboxReplication.MailboxExportRequest.NewMailboxExportRequest
     + PSComputerName        : contbmexmb01.contoso.com

[PS] C:\Windows\system32>

image

Solution

The reason why this error would be thrown is if you are trying to export a mailbox that is on a different version than the admin console you are working from.  In the example above, the attempt was made from the Exchange 2016 admin center but the mailbox actually resides on an Exchange 2010 server.  Simply execute the export job from the PowerShell prompt of one of the Exchange 2010 servers to get the mailbox to export.