Original Publishing Date: 2021-10-04 Symptoms A domain transfer sales order fails with the following output: Registrar declined request for domain transfer. Domain transfer could not be carried out successfully. ; You are using a charset that is not supported by the registry. (EF03078) Domain status:Prepared. Service Creation Failed: Domain transfer failed /var/log/httpd/payment-sdk.log on the BA Application node contains the same error: [Fri Oct 01 16:52:02 2021] [pid 3103] AH01215: You are using a charset that is not supported by the registry.EF03078errorOWNERC/organizationcompany\xc3\name\xe2\x80\x8bE0104Domain transfer could not be carried out successfully.errordomaindomain.com20211001-app2-218485 Cause \xe2\x80\x8b from the account name corresponds to U+200B, which is a Zero Width Space. This character is prohibited by the registry and must not be used. Resolution Change the account name removing the invisible character and send a new transfer request to registrar by resubmitting the order.

Original Publishing Date: 2021-12-01 Symptoms From UX1, Provider or Reseller attempted to import catalog for Marketplace, but it completed with error: Diagnostic info: Category ‘*’: The category ‘’ cannot be imported because it contains some of the unsupported characters: %\&*+_!{\}. You can rename the category in CB Billing and try again. Example: 1) UX1 UI > Sales Channels > Home Page > click on Import Catalog 2) Then the event notification alerted that the import has been completed but with aforementioned error or similar as below: Cause UX1 Marketplace does not support these characters as below to be used on Sales Category name: % \ & * + _ ! { \ } Example: Resolution 1) Navigate to Provider/Reseller CP > Billing > Service Plans > Sales Categories 2) Rename all Category Name which has the aforementioned unsupported characters in its name to a name with does not contain the unsupported characters. 3) In Sales Channels, implement the Import Catalog again. Internal

Original Publishing Date: 2022-12-21 Symptoms In UX1 CP for any Reseller with PSA integrations activated, when trying to Download the template .xlsx file from 'MAP using file' menu: This error is visible from the browser dev tools: { "error": "INTERNAL", "packageId": "6534405f-042b-4b0b-ac49-d316c30669dd", "message": "", "http_request": "GET http://psa-integration-backend:8080/application/a3c28d3c-8719-4ecc-a997-77688ca59db4/xlsDocuments/download", "code": 13 } Cause The download of the template for bulk mapping is not working due to software issue with id PSA-2869. Resolution Update PSA integrations to 4.2.1569 (November 29, 2022) or higher version.

Original Publishing Date:  2023-11-14 Symptoms We have a problem with our CloudBlue license expiry date on our platform. Although it was updated this month, the expiration date is shown to be next month. The license should have been updated with an expiration date of 1 year from now. Cause The license expiry date shown in the control panel (PCP > System > Information > PRODUCT LICENSE tab) is usually different from the real expiration date on our licensing server. License in the platform is automatically updated every month, at least 2 weeks in advance, and the expiration date is shifted by 1 month during the process, until it reaches the real expiration date. Resolution If the expiry date shown in CP is more than 2 weeks from the current date, there is no need to worry or do anything. If it is less, or if you want to verify that automatic license updates will not fail when the time comes, you may do the following: 1. Verify that the license installed on your platform is not trial, but a permanent one.  Trial licenses usually end with ".0000", while permanent ones have some non-zero number at the end.  If in doubt, you may ask your TAM to verify it. 2. Verify that "License update" periodic task is not failing in oss: 3. Verify the connectivity between your oss pod (or OA MN/osscore server for version 20.5) and our licensing server. Example commands with "good" output: To enter the pod: [root@linjmpb ~]# kubectl exec -ti oss-node-0 -- bash Defaulted container "core-ear" out of: core-ear, conf (init) [root@oss-node-0 /]# To check the connectivity: [root@oss-node-0 /]# nc -w 2 -v keys.odin.com 5224 </dev/null Ncat: Version 7.70 ( https://nmap.org/ncat ) Ncat: Connected to 52.29.203.196:5224. Ncat: 0 bytes sent, 0 bytes received in 0.14 seconds. [root@oss-node-0 /]#

Symptoms We have a problem with our CloudBlue license expiry date on our platform. Although it was updated this month, the expiration date is shown to be next month. The license should have been updated with an expiration date of 1 year from now. Cause The license expiry date shown in the control panel (PCP > System > Information > PRODUCT LICENSE tab) is usually different from the real expiration date on our licensing server. License in the platform is automatically updated every month, at least 2 weeks in advance, and the expiration date is shifted by 1 month during the process, until it reaches the real expiration date. Resolution If the expiry date shown in CP is more than 2 weeks from the current date, there is no need to worry or do anything. Only if it is less than 2 weeks from now, or if you want to verify that automatic license updates will not fail when the time comes, you may do the following: 1. Verify that the license installed on your platform is not trial, but a permanent one.  Trial licenses usually end with ".0000", while permanent ones have some non-zero number at the end, e.g. ".0073".  If in doubt, you may ask your TAM to verify it. 2. Verify that "License update" periodic task is not failing in oss: 3. Verify the connectivity between your oss pod (or OA MN/osscore server for version 20.5) and our licensing server. Example commands with "good" output: To enter the pod: [root@linjmpb ~]# kubectl exec -ti oss-node-0 -- bash Defaulted container "core-ear" out of: core-ear, conf (init) [root@oss-node-0 /]# Generic To check the connectivity: [root@oss-node-0 /]# nc -w 2 -v keys.odin.com 5224 </dev/null Ncat: Version 7.70 ( https://nmap.org/ncat ) Ncat: Connected to 52.29.203.196:5224. Ncat: 0 bytes sent, 0 bytes received in 0.14 seconds. [root@oss-node-0 /]# Generic

Question How to update a brand session and token timeouts from Keycloak? Answer In IDP, Keycloak admin control panel provides granular control over a certain brand *session and token timeouts settings. In Keycloak, the brand aformentioned settings arelocated under a corresponding realm settings which bear the same id as the brand. 1.0 Ascertaining the realm that requires update:     1.1 Go to PCP > System > Settings > Brands < using the search filter search for the brand in concern.     1.2 Notice the id of the brand as this is the id of the corresponding realm in Keycloak. 2.0 Accessing Keycloak admin control panel:     2.1 URL of a Keycloak control panel: https:///auth/admin .     2.2 Default username is admin (case sensitive).     2.3 Password can be obtained from idp-backend secret from the K8S resource secret.         #> kubectl -n get secret idp-backend -o jsonpath="{.data.keycloakadminpassword}"| base64 -d 3.0 Navigating to a realm Tokens tab     3.1 On the Keycloak admin control panel, click on Select realm.     3.2 In the dropdown menu click on the realm that requires update. The realm name starts with 'sr' and followed by brand id. The brand id is the brand id observed from step 1.2 above.     3.3 Click tab Tokens. This is the location of session and token settings.     3.4 **Updates the settings according to requirements. Note: *Explanation of what each filed means can be obtained from Keycloak official documentation here. It is maintained by Keycloak hence kindly report directly to Keycloak for any discrepancies found. **Warning: Updating Keycloak settings requires caution! Before proceeding, please ensure you: - Understand how Keycloak works and the meaning of each setting. Modifying settings without proper knowledge can significantly impact CloudBlue Commerce platform uptime and access management. THERE IS NO BACKUP TO THE SETTINGS. Hence, there is no rollback.  - Have thoroughly tested any changes in a non-production environment. This helps to identify and mitigate potential issues before they affect live users. - Possess the necessary expertise in Keycloak administration. If unsure, consult with an experienced administrator to ensure safe and effective updates. **Failing to adhere to these precautions can lead to: - Reduced platform uptime: Critical services may become unavailable, disrupting user workflows. - Compromised access management: Unauthorized access to sensitive data may occur. - Data loss or corruption: Improper configuration can result in irreversible data loss. Proceed with utmost caution and only if you are confident in your ability to perform the updates safely and effectively.

Original Publishing Date: 2020-01-23 Symptoms It is not possible to switch to PBA from OA PCP, instead of BA CP parts of OA CP frames is displayed. The following could be observed in /var/log/pa/pui/pui.log on UI node: 21:32:25.724 [default task-36] DEBUG c.p.p.c.e.b.billing_manager.BMHelper - loginToBM failure details: com.plesk.p2.cp.ext.billing.billing_manager.LoginToBMException: Session ID was not found in response from Business Automation. Please check password is correct. And the following could be found in /var/log/pa/billing._amt_.log on BAFE: [18-12-06 20:16:13.879 AHRC_Object RQ08266 TH21728 NTE] Entering method AHRC.AuthorizeUserByLogin(user = -1, SID = 0, lang = en, request = 0, localObject = 0, transaction = 0 (HP)) ... [18-12-06 20:16:13.883 AHRC_Object RQ08266 TH21728 TRC] +++[4] bool bIntUsers::isPasswordValid(Int, Str)(1) [18-12-06 20:16:13.893 AHRC_Object RQ08266 TH21728 TRC] ---[4] bool bIntUsers::isPasswordValid(Int, Str) [18-12-06 20:16:13.893 AHRC_Object RQ08266 TH21728 TRC] +++[4] Int bIntUsersBan::loginFailed(Int, Str, Int)(UserID: 1, sIPAddress: 79.170.244.251, continueBan: 1) ... [18-12-06 20:16:13.897 AHRC_Object RQ08266 TH21728 NTE] Finished method AHRC.AuthorizeUserByLogin(user = -1, SID = 0, lang = en, request = 0, localObject = 0, transaction = 0 (HP)) [18-12-06 20:16:13.897 AHRC_Object RQ08266 TH21728 NTE] AuthResult { FAILURE(Login or Password is incorrect. ) } Cause Switch to PBA compares bm.common.password hash with AMT RootPassword hash on BAFE. This error means that OA bm.common.password and AMT RootPassword does not match. Resolution Check that RootPassword in /usr/local/bm/conf/_amt_service_.res matches the ones in PBARoleConf and OrderManagement components. Internal content Link on internal Article

Symptoms After upgrade UX1 Marketplace to 7.5.2068,  search function in public mode is not working, and any search returns: Something went wrong, please, contact support The error is reproducible by Go to public Marketplace >> type whatever search characters entry and press enter: Cause Unfortunately, it's by design. Public Marketplace will not work properly with the latest versions of Marketplace. Resolution Please follow our release notes about implementation of feature request for supporting public mode PFR-6971.

Symptoms When trying to search the marketplace with specific keyword, for example "Google", the UX1 marketplace returns an error: Value cannot be null. (Parameter 'stringToEscape') There is also a referral plan that contains that specific string, in this example "Google One". Cause Software related issue #CMP-11342 where referral plan causing error on search result page, due to referral plan does not have a valid APS UID. Resolution For temporary workaround, please hide referral plan from "Service Plan" page in "Sales Channel" in UX1. For permanent resolution, please check with your TAM to further track the status of the issue #CMP-11342.

Symptoms We get this error when trying to install an SSL certificate to a brand: Invalid data Private key does not match the certificate Cause Your private key does not match the certificate. Resolution Verify that the results of the below commands for your certificate file and private key file are the same (substitute your real file names): $ openssl x509 -noout -modulus -in cert.crt  | openssl md5 MD5(stdin)= 8d46280202f224747c544ab3ec64915d $ openssl rsa -noout -modulus -in private_key.pem | openssl md5 MD5(stdin)= 52198de8819908c8f74ccbed3407b100 Note: The above commands should work fine for crt/pem/key extensions. If the above two commands return different results (as in the above example), double-check that you are using a correct key pair.