Tests fail due to low resolution using Lab Service (SSE) with auto-login feature

Automated tests failing, usually due to object not found in application under test

The ALM Lab Service, using the auto-login functionality, will establish a remote session on the host machine.

The native resolution of the session is determined by the video drivers used on the physical machine or virtual machine.

In some cases this causes a lower than normal screen resolution such as 800×600 which causes UFT to not locate the objects on the screen of the application under test.

To fix this upgrade and/or configure new video drivers on the physical box or VM which support the screen resolution established when the automated test was recorded using UFT.

Make sure the native resolution provided by the video drivers supports the same resolution when the test was recorded.

To set the resolution use: https://social.msdn.microsoft.com/Forums/azure/en-US/1c215514-aeef-41d9-b47b-5c838a0bf83f/how-to-change-the-vm-default-screen-resolution?forum=WAVirtualMachinesforWindows

Setting keyword mapping in SAP Solution Manager

After creating some keyword mapping, in SAP Solution Manager, to synchronize some custom fields of SAP Blueprints with User Defined fields (UDF) of ALM Requirements, the synchronization does not seem to work.

For example, as illustrated in the two next screenshots, after setting the keyword mapping in SAP Solution Manager, the next synchronization does not update the requirements’ UDF in ALM:

•Setting keyword mapping in SAP Solution Manager:


•The UDF remains empty after next synchronization:


Apparently, the requirements’ User Defined Fields have been created in the customization of the ALM project but they were not set to be in the requirement type (each requirement type can be customized to contain or not specific UDFs and each new UDF created in an ALM project is, by default, not part of any requirement type).

In the Customization section of the ALM project, the “Requirement Types” option should be modified so each requirement type related to the SAP synchronization (if they are not known, modify every requirement type in the ALM project) is set to have the User Defined Fields in their definition as illustrated in the next screenshot:

•Customize the Requirement type to contain the UDFs:


•The UDFs should be successfully synchronized after this:


“Failed to Restore Project” error


Failed to Restore Project;

Stack Trace:

org.bouncycastle.crypto.InvalidCipherTextException: pad block corrupted

at org.bouncycastle.crypto.paddings.PKCS7Padding.padCount(PKCS7Padding.java:63)

at org.bouncycastle.crypto.paddings.PaddedBufferedBlockCipher.doFinal(PaddedBufferedBlockCipher.java:286)

at com.hp.sw.bto.ast.security.lwcrypto.LWBlockCrypto.decrypt(LWBlockCrypto.java:114)

wrapped in com.hp.sw.bto.ast.security.lwcrypto.LWCryptoException: Unable to finalize decryption for the following 16 bytes: [ -49, 70, 121, 104, -37, -48, -11, -24, 77, -2, -69, 17, 52, -16, -27, -102, ], 0 bytes were already precessed. Current configuration is: com.hp.sw.bto.ast.security.lwcrypto.LWBlockCrypto[ cipher: AES/CBC, Encoding mode: Base64Url, forEncryption: false, keysize: 256]

at com.hp.sw.bto.ast.security.lwcrypto.LWBlockCrypto.decrypt(LWBlockCrypto.java:118)

at com.hp.alm.platform.crypto.QcCipher.decrypt(QcCipher.java:168)

Issue happens since the password in the dbid.xml does not match with the data in Application Lifecycle Management (ALM).

Steps to fix the issue:

· Create a new project.

· Go to the repository of the newly created project.

· Open the dbid.xml file

· Copy the Password

· Open the dbid.xml file of the project we are trying to restore.

· Make sure the password is the same for both new and failed to restore project.

· If different change the password.

· Restore the project again.

Error HTTP 503 when trying to access Mtours

The error message appears when trying to access Mtours from Application Lifecycle Management (ALM)

Error Message: HTTP 503

The cause of this problem is because Mtours is disabled by default if it was not enabled during the intallation of ALM.

To fix this issue and enable Mtours, follow these steps:

1. Open and edit the “start.ini” file located in the following location: C:\ProgramData\HP\ALM\server\conf

2. In the file locate the following line: jetty-testrealm.xml

3. Edit this line and remove the ‘#’ character at the beginning of the line.

4. Save and close the file

5. Restart the ALM server.

6. Check if the problem is resolved.

Error:” Invalid URL” when trying to login to Quality Center

When trying to login to Quality Center (QC) users receive the following error:

Invalid URL

The problem is caused by a product defect.

After a client machine has been used to connect to a Quality Center instance deployed via SSL, subsequent connections to QC are attempted via port 443. This results in a failure to connect to the application.

The defect is known to R&D and a fix is being prepared. The ETA for this patch is not yet known.

The setting is stored in the registry. There are two ways to correct the wrong value:

1) Use the QC WebGate Customization Tool (available at http://qcserver:port/qcbin/Apps) and uncheck the box labeled ‘Login SSL Mode’

2) Open regedit and navigate to the affected key: HKEY_CURRENT_USER\Software\Mercury Interactive\TestDirector\WEB\LoginSSLMode. The value should be changed from ‘Y’ to ‘N’.

How to proceed with the migration from ALM 11 to ALM 11.5 when the confidential data passphrase is not known

If the Application Lifecycle Management (ALM) Configuration Wizard fails and in the upgdare.txt log file the following error is logged:

ERROR: Unable to finalize decryption for the following 16 bytes:

This means that the used confidential data passphrase is wrong.

When upgrading from ALM 11 to ALM 11.5x and the confidential data passphrase is unknown, the old "qcConfigFile.properties" file from ALM 11 which was used in the previous installation needs to be used. This file has the encrypted confidential data passphrase inside. It is stored in the <InString> key. This file needs to be placed in <ALM Deployment Path/conf> of the new installation.

Note: Using this file will give the option to keep the current settings. Using this option allows using the same passphrase and change the other values. This workaround will not extract the password from the file.

Confidential Data Passphrase issues during migration of Lab Management project, when migrating from ALM 11.0 to ALM11.5

What to do when Performance Center related Lab management project is migrated from Application Lifecycle Management (ALM) 11.0 to 11.5 and the passphrase is wrong. If the password is wrong or not known the Verify process will fail.

There are 2 ways to deal with the situation :

1. Fix the Confidential Data Passphrase of the server so it is the same as in the source server (ALM11.0)

2. Reset the passwords in the Lab project before the Verify. Then after the upgrade login to Lab Management and update the passwords of the AUT hosts, Diagnostic Server and Standalone Unix Load generator.

More details may be found in the ALM Administrators guide Appendix A – Upgrade preparation troubleshooting.- ‘Encrypted Values’.