We are in the middle of our update from 2020 R1 Patch 6 to 2021 R1 Patch 3. We just rolled out ICUserApps to some pilot users and discovered that SIP Soft Phone does not work. When provisioning the SIP Soft Phone users get an error that says "The Host Cannot Be Reached." We have confirmed their network connection and that the correct host name is entered etc. According to Genesys Support SIP Soft Phone does not work in 2020 R4 + unless users have "Full Control" rights to C:\Users\User Name>\Interactive Intelligence\Certificates. My organization is going to have a big issue with giving regular users "Full Control" to anything so this is a show stopper for us. Genesys admitted that this issue is not documented on their website so we wouldn't have know about it before proceeding with updating. Just wondering if anyone else has run into this issue and if any of these workarounds worked for you. We are almost 100% SIP Soft Phone. 

Below is what I was told by Genesys support:

"Hi Michael,

 As we discussed on call there was no documentation for this known issue. Once the fix go live we will update the document into known issues. Please find the SCR IC-160249

On comparing between the path differences between 2019 version and 2020 R4 P4 Version, the one with known issue, they found the below.

Neither version (2019 or 2020) of the SSP has access to the C:\Program Files (x86)\Interactive Intelligence\Certificates\ folder.
During the startup of the SSP, both versions create folders under C:\Users\User Name>\Interactive Intelligence\Certificates\ after failing to create them under C:\Program Files (x86)\Interactive Intelligence.
The difference between the two is that the 2019 version will use the newly created folders and files under C:\Users\etc., but 2020 R4 P4 does not. The 2020 R4 P4 SSP goes back to the folders under C:\Program Files (x86)\ and fails. As seen in the logs, this cycle continues for several cycles until it times out.


The workarounds provided by the DEV team are as follows:

"Add the launching user to the local admins group on the system, add the launching user with "full" rights to the folder or to modify the "Users" group permissions on the folder.

Another workaround would be to use a transform (MST) to modify the "SecureObjects" table...perhaps change the "Users" group permission there or to add "Authenticated Users" with the required permissions. The transform would need to be specified when the MSI is installed (using the TRANSFORMS=<pathToMSTFile> property)."


I've attached the transform to this mail. It will add the "Authenticated Users" group to the "Certificates" share with the same permissions as that given to the installing user.
DEV also found another workaround that is explained at the end of Notes. It is for systems that already run the install without a transform.

DEV tested the transform and applied the MSI, MSP and transform (MST) at the same time and "Authenticated Users" showed up on the folder as expected:



Notes
The transform must be applied when the MSI is installed. After that, it is cached by the installer and will be applied whenever the install is run again (patches, repairs, etc.)
The transform cannot be applied if the MSI has already been run and the product is installed. In that case, either the product needs to be uninstalled and then reinstalled using the transform OR the permissions could be added to the "Certificates" folders using the "icacles" utility.
To use the transform, the "TRANSFORMS" property is used (as seen in the snippet) with the path to the MST file assigned to it. The property name should be in all caps.

2nd workaround
This second workaround could be used instead of the transform on new product installs and could also be used on systems that had the product installed without a transform (thereby saving the uninstall
reinstall with transform steps). This workaround uses the "icacls" Windows utility to set the permissions on the "Certificates" folder after the install is run. I've attached a .txt file with the command lines to use. To see information about the utility, type "icacls /?" at the command line.

In case the transform/mst is used, full path needs to be provided for the msi, msp and mst while running the command). The transform (mst file) attached to this CC is the only transform that needs to be used to circumvent this issue if the product is not already installed(there are no other transforms for this purpose). Alternatively, the icacls utility can be used if the product is already installed without the mst (utility can also be used for new product installs, please refer Mike's detailed comments).

As we discussed in call if you are not acceptable with this work around provided, we can suggest you to downgrade the SSP version that being used before."

Thanks,
Mike Bishop

 #sipsoftphone #upgrade #Implementation #2021r1 #SCR



​​​​​​​
#SIP/VolP

------------------------------
Michael Bishop
UnitedHealth Group/Optum
------------------------------

This is what we were seeing in the SIPSoftPhone Logs

Snippet from Y:\Mike\sipsoftphone_6.ininlog

Timestamp (UTC-04:00)	Message	Topic	Thread
		SIPSoftStation_Application	0x2818
12:19:18.8559118_0000	iccertificates::create_and_get_default_root_configuration_directory() : Current user has NO access to: C:\Program Files (x86)\Interactive Intelligence\Certificates, as specified under the HKEY_LOCAL_MACHINE\SOFTWARE\Interactive Intelligence\Certificates key.	ICCertificatesConfigurationFile	0x10ac
12:19:18.8749115_0000	CertificatesStoreLoader::read_configuration_file_data() : ERROR locating configuration file: C:\Program Files (x86)\Interactive Intelligence\Certificates\LHTU05CG9217LL2_ININ_Certificates.xml. CANNOT read configuration file data.	I3CertificatesCertificateStorageImpl	0x10ac
12:19:18.8749115_0001	CertificatesStoreLoader::read_raw_certificates_and_keys() : ERROR locating configuration file: C:\Program Files (x86)\Interactive Intelligence\Certificates\LHTU05CG9217LL2_ININ_Certificates.xml. CANNOT decrypt the certificate and key files.	I3CertificatesCertificateStorageImpl	0x10ac
12:19:18.8798674_0000	iccertificates::create_and_get_default_root_configuration_directory() : Current user has NO access to: C:\Program Files (x86)\Interactive Intelligence\Certificates, as specified under the HKEY_LOCAL_MACHINE\SOFTWARE\Interactive Intelligence\Certificates key.	ICCertificatesConfigurationFile	0x10ac

------------------------------
Michael Bishop
UnitedHealth Group/Optum
------------------------------

Original Message:
Sent: 06-24-2021 11:42
From: Michael Bishop
Subject: 2021 R1 SIP Soft Phone not working (The Host Cannot Be Reached)

We are in the middle of our update from 2020 R1 Patch 6 to 2021 R1 Patch 3. We just rolled out ICUserApps to some pilot users and discovered that SIP Soft Phone does not work. When provisioning the SIP Soft Phone users get an error that says "The Host Cannot Be Reached." We have confirmed their network connection and that the correct host name is entered etc. According to Genesys Support SIP Soft Phone does not work in 2020 R4 + unless users have "Full Control" rights to C:\Users\User Name>\Interactive Intelligence\Certificates. My organization is going to have a big issue with giving regular users "Full Control" to anything so this is a show stopper for us. Genesys admitted that this issue is not documented on their website so we wouldn't have know about it before proceeding with updating. Just wondering if anyone else has run into this issue and if any of these workarounds worked for you. We are almost 100% SIP Soft Phone.

Below is what I was told by Genesys support:

"Hi Michael,

 As we discussed on call there was no documentation for this known issue. Once the fix go live we will update the document into known issues. Please find the SCR IC-160249

On comparing between the path differences between 2019 version and 2020 R4 P4 Version, the one with known issue, they found the below.

Neither version (2019 or 2020) of the SSP has access to the C:\Program Files (x86)\Interactive Intelligence\Certificates\ folder.
During the startup of the SSP, both versions create folders under C:\Users\User Name>\Interactive Intelligence\Certificates\ after failing to create them under C:\Program Files (x86)\Interactive Intelligence.
The difference between the two is that the 2019 version will use the newly created folders and files under C:\Users\etc., but 2020 R4 P4 does not. The 2020 R4 P4 SSP goes back to the folders under C:\Program Files (x86)\ and fails. As seen in the logs, this cycle continues for several cycles until it times out.


The workarounds provided by the DEV team are as follows:

"Add the launching user to the local admins group on the system, add the launching user with "full" rights to the folder or to modify the "Users" group permissions on the folder.

Another workaround would be to use a transform (MST) to modify the "SecureObjects" table...perhaps change the "Users" group permission there or to add "Authenticated Users" with the required permissions. The transform would need to be specified when the MSI is installed (using the TRANSFORMS=<pathToMSTFile> property)."


I've attached the transform to this mail. It will add the "Authenticated Users" group to the "Certificates" share with the same permissions as that given to the installing user.
DEV also found another workaround that is explained at the end of Notes. It is for systems that already run the install without a transform.

DEV tested the transform and applied the MSI, MSP and transform (MST) at the same time and "Authenticated Users" showed up on the folder as expected:



Notes
The transform must be applied when the MSI is installed. After that, it is cached by the installer and will be applied whenever the install is run again (patches, repairs, etc.)
The transform cannot be applied if the MSI has already been run and the product is installed. In that case, either the product needs to be uninstalled and then reinstalled using the transform OR the permissions could be added to the "Certificates" folders using the "icacles" utility.
To use the transform, the "TRANSFORMS" property is used (as seen in the snippet) with the path to the MST file assigned to it. The property name should be in all caps.

2nd workaround
This second workaround could be used instead of the transform on new product installs and could also be used on systems that had the product installed without a transform (thereby saving the uninstall
reinstall with transform steps). This workaround uses the "icacls" Windows utility to set the permissions on the "Certificates" folder after the install is run. I've attached a .txt file with the command lines to use. To see information about the utility, type "icacls /?" at the command line.

In case the transform/mst is used, full path needs to be provided for the msi, msp and mst while running the command). The transform (mst file) attached to this CC is the only transform that needs to be used to circumvent this issue if the product is not already installed(there are no other transforms for this purpose). Alternatively, the icacls utility can be used if the product is already installed without the mst (utility can also be used for new product installs, please refer Mike's detailed comments).

As we discussed in call if you are not acceptable with this work around provided, we can suggest you to downgrade the SSP version that being used before."

Thanks,
Mike Bishop

 #sipsoftphone #upgrade #Implementation #2021r1 #SCR



​​​​​​​
#SIP/VolP

------------------------------
Michael Bishop
UnitedHealth Group/Optum
------------------------------

Hi Michael,

when we moved to a Single Signed Cert environment we ran into a similar issue. What we did is we gave read/write access to Authenticated Users on the XML file and that resolved our issue. Not sure if this will work for your solution, as the XML file was something that was created when we installed the SIPCert and not the original XML file created when we installed the application. If that doesn't work might try adding Authenticated user to the Cert Folder and allow it to inherit in the directory below.

------------------------------
Scott Williams
Missouri Higher Education Loan Authority
------------------------------

Original Message:
Sent: 06-24-2021 11:46
From: Michael Bishop
Subject: 2021 R1 SIP Soft Phone not working (The Host Cannot Be Reached)

This is what we were seeing in the SIPSoftPhone Logs

Snippet from Y:\Mike\sipsoftphone_6.ininlog

Timestamp (UTC-04:00)	Message	Topic	Thread
		SIPSoftStation_Application	0x2818
12:19:18.8559118_0000	iccertificates::create_and_get_default_root_configuration_directory() : Current user has NO access to: C:\Program Files (x86)\Interactive Intelligence\Certificates, as specified under the HKEY_LOCAL_MACHINE\SOFTWARE\Interactive Intelligence\Certificates key.	ICCertificatesConfigurationFile	0x10ac
12:19:18.8749115_0000	CertificatesStoreLoader::read_configuration_file_data() : ERROR locating configuration file: C:\Program Files (x86)\Interactive Intelligence\Certificates\LHTU05CG9217LL2_ININ_Certificates.xml. CANNOT read configuration file data.	I3CertificatesCertificateStorageImpl	0x10ac
12:19:18.8749115_0001	CertificatesStoreLoader::read_raw_certificates_and_keys() : ERROR locating configuration file: C:\Program Files (x86)\Interactive Intelligence\Certificates\LHTU05CG9217LL2_ININ_Certificates.xml. CANNOT decrypt the certificate and key files.	I3CertificatesCertificateStorageImpl	0x10ac
12:19:18.8798674_0000	iccertificates::create_and_get_default_root_configuration_directory() : Current user has NO access to: C:\Program Files (x86)\Interactive Intelligence\Certificates, as specified under the HKEY_LOCAL_MACHINE\SOFTWARE\Interactive Intelligence\Certificates key.	ICCertificatesConfigurationFile	0x10ac

------------------------------
Michael Bishop
UnitedHealth Group/Optum

Original Message:
Sent: 06-24-2021 11:42
From: Michael Bishop
Subject: 2021 R1 SIP Soft Phone not working (The Host Cannot Be Reached)

We are in the middle of our update from 2020 R1 Patch 6 to 2021 R1 Patch 3. We just rolled out ICUserApps to some pilot users and discovered that SIP Soft Phone does not work. When provisioning the SIP Soft Phone users get an error that says "The Host Cannot Be Reached." We have confirmed their network connection and that the correct host name is entered etc. According to Genesys Support SIP Soft Phone does not work in 2020 R4 + unless users have "Full Control" rights to C:\Users\User Name>\Interactive Intelligence\Certificates. My organization is going to have a big issue with giving regular users "Full Control" to anything so this is a show stopper for us. Genesys admitted that this issue is not documented on their website so we wouldn't have know about it before proceeding with updating. Just wondering if anyone else has run into this issue and if any of these workarounds worked for you. We are almost 100% SIP Soft Phone.

Below is what I was told by Genesys support:

"Hi Michael,

 As we discussed on call there was no documentation for this known issue. Once the fix go live we will update the document into known issues. Please find the SCR IC-160249

On comparing between the path differences between 2019 version and 2020 R4 P4 Version, the one with known issue, they found the below.

Neither version (2019 or 2020) of the SSP has access to the C:\Program Files (x86)\Interactive Intelligence\Certificates\ folder.
During the startup of the SSP, both versions create folders under C:\Users\User Name>\Interactive Intelligence\Certificates\ after failing to create them under C:\Program Files (x86)\Interactive Intelligence.
The difference between the two is that the 2019 version will use the newly created folders and files under C:\Users\etc., but 2020 R4 P4 does not. The 2020 R4 P4 SSP goes back to the folders under C:\Program Files (x86)\ and fails. As seen in the logs, this cycle continues for several cycles until it times out.


The workarounds provided by the DEV team are as follows:

"Add the launching user to the local admins group on the system, add the launching user with "full" rights to the folder or to modify the "Users" group permissions on the folder.

Another workaround would be to use a transform (MST) to modify the "SecureObjects" table...perhaps change the "Users" group permission there or to add "Authenticated Users" with the required permissions. The transform would need to be specified when the MSI is installed (using the TRANSFORMS=<pathToMSTFile> property)."


I've attached the transform to this mail. It will add the "Authenticated Users" group to the "Certificates" share with the same permissions as that given to the installing user.
DEV also found another workaround that is explained at the end of Notes. It is for systems that already run the install without a transform.

DEV tested the transform and applied the MSI, MSP and transform (MST) at the same time and "Authenticated Users" showed up on the folder as expected:



Notes
The transform must be applied when the MSI is installed. After that, it is cached by the installer and will be applied whenever the install is run again (patches, repairs, etc.)
The transform cannot be applied if the MSI has already been run and the product is installed. In that case, either the product needs to be uninstalled and then reinstalled using the transform OR the permissions could be added to the "Certificates" folders using the "icacles" utility.
To use the transform, the "TRANSFORMS" property is used (as seen in the snippet) with the path to the MST file assigned to it. The property name should be in all caps.

2nd workaround
This second workaround could be used instead of the transform on new product installs and could also be used on systems that had the product installed without a transform (thereby saving the uninstall
reinstall with transform steps). This workaround uses the "icacls" Windows utility to set the permissions on the "Certificates" folder after the install is run. I've attached a .txt file with the command lines to use. To see information about the utility, type "icacls /?" at the command line.

In case the transform/mst is used, full path needs to be provided for the msi, msp and mst while running the command). The transform (mst file) attached to this CC is the only transform that needs to be used to circumvent this issue if the product is not already installed(there are no other transforms for this purpose). Alternatively, the icacls utility can be used if the product is already installed without the mst (utility can also be used for new product installs, please refer Mike's detailed comments).

As we discussed in call if you are not acceptable with this work around provided, we can suggest you to downgrade the SSP version that being used before."

Thanks,
Mike Bishop

 #sipsoftphone #upgrade #Implementation #2021r1 #SCR



​​​​​​​
#SIP/VolP

------------------------------
Michael Bishop
UnitedHealth Group/Optum
------------------------------

Hi Michael,

Our team is also experiencing a similar issue upgrading to 2021R1.  In some computers, Sip Soft Phone does not have write access to the certificate folder in "Program Files"

Our approach is to remove the Windows Environment Variable for the ININ Certificates.   We consulted this with Genesys Support, and they confirmed that it is advisable as the workaround. By doing this, The SSP will reference to the user directory after failing to write to Program Files.  We do have concern if this workaround would impact any future Genesys Apps configuration and they said no.

But at first, they advised us to change the Windows Environment Variable to point to user profile

Changing the Environment Variable for the Certificates to point to the User profile instead can be considered as an workaround.
The SIPSoftPhone(SSP) is provisioned properly with new user's location at the end. We do not see any problem.

Next….

Question: They have found that simply deleting the environmental variable is enough for the SIP soft phone to write to and reference the Users directory after failing to write to Program Files. Is this not advisable?

Answer: Yes, it is advisable.

When SSP starts to run, it cannot find the environment variable as it is deleted.

12:17:12.091_0003[6510][Warning] CertificatesStoreLoader::set_configuration_file_path(): The: ININ_Certificates environment variable has NOT been set. This variable is usually configured by the install to point to the certificates configuration file.

So, SSP will use the path of USER profile instead.

12:17:12.091_0004[6510]CertificatesStoreLoader::set_configuration_file_path(): Using the configuration file path of: C:\Users\<user>\Interactive Intelligence\Certificates\xxxx_ININ_Certificates.xml.

That is equivalent to the suggestion we did, change the Environment Variable for the Certificates to point to the User Profile instead.

------------------------------
Sanjaya
------------------------------

Original Message:
Sent: 06-24-2021 16:15
From: Scott Williams
Subject: 2021 R1 SIP Soft Phone not working (The Host Cannot Be Reached)

Hi Michael,

when we moved to a Single Signed Cert environment we ran into a similar issue. What we did is we gave read/write access to Authenticated Users on the XML file and that resolved our issue. Not sure if this will work for your solution, as the XML file was something that was created when we installed the SIPCert and not the original XML file created when we installed the application. If that doesn't work might try adding Authenticated user to the Cert Folder and allow it to inherit in the directory below.

------------------------------
Scott Williams
Missouri Higher Education Loan Authority

Original Message:
Sent: 06-24-2021 11:46
From: Michael Bishop
Subject: 2021 R1 SIP Soft Phone not working (The Host Cannot Be Reached)

This is what we were seeing in the SIPSoftPhone Logs

Snippet from Y:\Mike\sipsoftphone_6.ininlog

Timestamp (UTC-04:00)	Message	Topic	Thread
		SIPSoftStation_Application	0x2818
12:19:18.8559118_0000	iccertificates::create_and_get_default_root_configuration_directory() : Current user has NO access to: C:\Program Files (x86)\Interactive Intelligence\Certificates, as specified under the HKEY_LOCAL_MACHINE\SOFTWARE\Interactive Intelligence\Certificates key.	ICCertificatesConfigurationFile	0x10ac
12:19:18.8749115_0000	CertificatesStoreLoader::read_configuration_file_data() : ERROR locating configuration file: C:\Program Files (x86)\Interactive Intelligence\Certificates\LHTU05CG9217LL2_ININ_Certificates.xml. CANNOT read configuration file data.	I3CertificatesCertificateStorageImpl	0x10ac
12:19:18.8749115_0001	CertificatesStoreLoader::read_raw_certificates_and_keys() : ERROR locating configuration file: C:\Program Files (x86)\Interactive Intelligence\Certificates\LHTU05CG9217LL2_ININ_Certificates.xml. CANNOT decrypt the certificate and key files.	I3CertificatesCertificateStorageImpl	0x10ac
12:19:18.8798674_0000	iccertificates::create_and_get_default_root_configuration_directory() : Current user has NO access to: C:\Program Files (x86)\Interactive Intelligence\Certificates, as specified under the HKEY_LOCAL_MACHINE\SOFTWARE\Interactive Intelligence\Certificates key.	ICCertificatesConfigurationFile	0x10ac

------------------------------
Michael Bishop
UnitedHealth Group/Optum

Original Message:
Sent: 06-24-2021 11:42
From: Michael Bishop
Subject: 2021 R1 SIP Soft Phone not working (The Host Cannot Be Reached)

We are in the middle of our update from 2020 R1 Patch 6 to 2021 R1 Patch 3. We just rolled out ICUserApps to some pilot users and discovered that SIP Soft Phone does not work. When provisioning the SIP Soft Phone users get an error that says "The Host Cannot Be Reached." We have confirmed their network connection and that the correct host name is entered etc. According to Genesys Support SIP Soft Phone does not work in 2020 R4 + unless users have "Full Control" rights to C:\Users\User Name>\Interactive Intelligence\Certificates. My organization is going to have a big issue with giving regular users "Full Control" to anything so this is a show stopper for us. Genesys admitted that this issue is not documented on their website so we wouldn't have know about it before proceeding with updating. Just wondering if anyone else has run into this issue and if any of these workarounds worked for you. We are almost 100% SIP Soft Phone.

Below is what I was told by Genesys support:

"Hi Michael,

 As we discussed on call there was no documentation for this known issue. Once the fix go live we will update the document into known issues. Please find the SCR IC-160249

On comparing between the path differences between 2019 version and 2020 R4 P4 Version, the one with known issue, they found the below.

Neither version (2019 or 2020) of the SSP has access to the C:\Program Files (x86)\Interactive Intelligence\Certificates\ folder.
During the startup of the SSP, both versions create folders under C:\Users\User Name>\Interactive Intelligence\Certificates\ after failing to create them under C:\Program Files (x86)\Interactive Intelligence.
The difference between the two is that the 2019 version will use the newly created folders and files under C:\Users\etc., but 2020 R4 P4 does not. The 2020 R4 P4 SSP goes back to the folders under C:\Program Files (x86)\ and fails. As seen in the logs, this cycle continues for several cycles until it times out.


The workarounds provided by the DEV team are as follows:

"Add the launching user to the local admins group on the system, add the launching user with "full" rights to the folder or to modify the "Users" group permissions on the folder.

Another workaround would be to use a transform (MST) to modify the "SecureObjects" table...perhaps change the "Users" group permission there or to add "Authenticated Users" with the required permissions. The transform would need to be specified when the MSI is installed (using the TRANSFORMS=<pathToMSTFile> property)."


I've attached the transform to this mail. It will add the "Authenticated Users" group to the "Certificates" share with the same permissions as that given to the installing user.
DEV also found another workaround that is explained at the end of Notes. It is for systems that already run the install without a transform.

DEV tested the transform and applied the MSI, MSP and transform (MST) at the same time and "Authenticated Users" showed up on the folder as expected:



Notes
The transform must be applied when the MSI is installed. After that, it is cached by the installer and will be applied whenever the install is run again (patches, repairs, etc.)
The transform cannot be applied if the MSI has already been run and the product is installed. In that case, either the product needs to be uninstalled and then reinstalled using the transform OR the permissions could be added to the "Certificates" folders using the "icacles" utility.
To use the transform, the "TRANSFORMS" property is used (as seen in the snippet) with the path to the MST file assigned to it. The property name should be in all caps.

2nd workaround
This second workaround could be used instead of the transform on new product installs and could also be used on systems that had the product installed without a transform (thereby saving the uninstall
reinstall with transform steps). This workaround uses the "icacls" Windows utility to set the permissions on the "Certificates" folder after the install is run. I've attached a .txt file with the command lines to use. To see information about the utility, type "icacls /?" at the command line.

In case the transform/mst is used, full path needs to be provided for the msi, msp and mst while running the command). The transform (mst file) attached to this CC is the only transform that needs to be used to circumvent this issue if the product is not already installed(there are no other transforms for this purpose). Alternatively, the icacls utility can be used if the product is already installed without the mst (utility can also be used for new product installs, please refer Mike's detailed comments).

As we discussed in call if you are not acceptable with this work around provided, we can suggest you to downgrade the SSP version that being used before."

Thanks,
Mike Bishop

 #sipsoftphone #upgrade #Implementation #2021r1 #SCR



​​​​​​​
#SIP/VolP

------------------------------
Michael Bishop
UnitedHealth Group/Optum
------------------------------

I faced this Issue as well. Version 2021 R1 P5
But I was able to fix it after copying the Certificates folder from User profile path to C:\Program Files (x86)\Interactive Intelligence\
This will work.

Thanks,
Vishnu

------------------------------
Vishnu Prasad
AEA International Holdings Pte. Ltd.
------------------------------

Original Message:
Sent: 06-25-2021 10:46
From: Sanjaya Purnomo
Subject: 2021 R1 SIP Soft Phone not working (The Host Cannot Be Reached)

Hi Michael,

Our team is also experiencing a similar issue upgrading to 2021R1.  In some computers, Sip Soft Phone does not have write access to the certificate folder in "Program Files"

Our approach is to remove the Windows Environment Variable for the ININ Certificates.   We consulted this with Genesys Support, and they confirmed that it is advisable as the workaround. By doing this, The SSP will reference to the user directory after failing to write to Program Files.  We do have concern if this workaround would impact any future Genesys Apps configuration and they said no.

But at first, they advised us to change the Windows Environment Variable to point to user profile

Changing the Environment Variable for the Certificates to point to the User profile instead can be considered as an workaround.
The SIPSoftPhone(SSP) is provisioned properly with new user's location at the end. We do not see any problem.

Next….

Question: They have found that simply deleting the environmental variable is enough for the SIP soft phone to write to and reference the Users directory after failing to write to Program Files. Is this not advisable?

Answer: Yes, it is advisable.

When SSP starts to run, it cannot find the environment variable as it is deleted.

12:17:12.091_0003[6510][Warning] CertificatesStoreLoader::set_configuration_file_path(): The: ININ_Certificates environment variable has NOT been set. This variable is usually configured by the install to point to the certificates configuration file.

So, SSP will use the path of USER profile instead.

12:17:12.091_0004[6510]CertificatesStoreLoader::set_configuration_file_path(): Using the configuration file path of: C:\Users\<user>\Interactive Intelligence\Certificates\xxxx_ININ_Certificates.xml.

That is equivalent to the suggestion we did, change the Environment Variable for the Certificates to point to the User Profile instead.

------------------------------
Sanjaya

Original Message:
Sent: 06-24-2021 16:15
From: Scott Williams
Subject: 2021 R1 SIP Soft Phone not working (The Host Cannot Be Reached)

Hi Michael,

when we moved to a Single Signed Cert environment we ran into a similar issue. What we did is we gave read/write access to Authenticated Users on the XML file and that resolved our issue. Not sure if this will work for your solution, as the XML file was something that was created when we installed the SIPCert and not the original XML file created when we installed the application. If that doesn't work might try adding Authenticated user to the Cert Folder and allow it to inherit in the directory below.

------------------------------
Scott Williams
Missouri Higher Education Loan Authority

Original Message:
Sent: 06-24-2021 11:46
From: Michael Bishop
Subject: 2021 R1 SIP Soft Phone not working (The Host Cannot Be Reached)

This is what we were seeing in the SIPSoftPhone Logs

Snippet from Y:\Mike\sipsoftphone_6.ininlog

Timestamp (UTC-04:00)	Message	Topic	Thread
		SIPSoftStation_Application	0x2818
12:19:18.8559118_0000	iccertificates::create_and_get_default_root_configuration_directory() : Current user has NO access to: C:\Program Files (x86)\Interactive Intelligence\Certificates, as specified under the HKEY_LOCAL_MACHINE\SOFTWARE\Interactive Intelligence\Certificates key.	ICCertificatesConfigurationFile	0x10ac
12:19:18.8749115_0000	CertificatesStoreLoader::read_configuration_file_data() : ERROR locating configuration file: C:\Program Files (x86)\Interactive Intelligence\Certificates\LHTU05CG9217LL2_ININ_Certificates.xml. CANNOT read configuration file data.	I3CertificatesCertificateStorageImpl	0x10ac
12:19:18.8749115_0001	CertificatesStoreLoader::read_raw_certificates_and_keys() : ERROR locating configuration file: C:\Program Files (x86)\Interactive Intelligence\Certificates\LHTU05CG9217LL2_ININ_Certificates.xml. CANNOT decrypt the certificate and key files.	I3CertificatesCertificateStorageImpl	0x10ac
12:19:18.8798674_0000	iccertificates::create_and_get_default_root_configuration_directory() : Current user has NO access to: C:\Program Files (x86)\Interactive Intelligence\Certificates, as specified under the HKEY_LOCAL_MACHINE\SOFTWARE\Interactive Intelligence\Certificates key.	ICCertificatesConfigurationFile	0x10ac

------------------------------
Michael Bishop
UnitedHealth Group/Optum

Original Message:
Sent: 06-24-2021 11:42
From: Michael Bishop
Subject: 2021 R1 SIP Soft Phone not working (The Host Cannot Be Reached)

We are in the middle of our update from 2020 R1 Patch 6 to 2021 R1 Patch 3. We just rolled out ICUserApps to some pilot users and discovered that SIP Soft Phone does not work. When provisioning the SIP Soft Phone users get an error that says "The Host Cannot Be Reached." We have confirmed their network connection and that the correct host name is entered etc. According to Genesys Support SIP Soft Phone does not work in 2020 R4 + unless users have "Full Control" rights to C:\Users\User Name>\Interactive Intelligence\Certificates. My organization is going to have a big issue with giving regular users "Full Control" to anything so this is a show stopper for us. Genesys admitted that this issue is not documented on their website so we wouldn't have know about it before proceeding with updating. Just wondering if anyone else has run into this issue and if any of these workarounds worked for you. We are almost 100% SIP Soft Phone.

Below is what I was told by Genesys support:

"Hi Michael,

 As we discussed on call there was no documentation for this known issue. Once the fix go live we will update the document into known issues. Please find the SCR IC-160249

On comparing between the path differences between 2019 version and 2020 R4 P4 Version, the one with known issue, they found the below.

Neither version (2019 or 2020) of the SSP has access to the C:\Program Files (x86)\Interactive Intelligence\Certificates\ folder.
During the startup of the SSP, both versions create folders under C:\Users\User Name>\Interactive Intelligence\Certificates\ after failing to create them under C:\Program Files (x86)\Interactive Intelligence.
The difference between the two is that the 2019 version will use the newly created folders and files under C:\Users\etc., but 2020 R4 P4 does not. The 2020 R4 P4 SSP goes back to the folders under C:\Program Files (x86)\ and fails. As seen in the logs, this cycle continues for several cycles until it times out.


The workarounds provided by the DEV team are as follows:

"Add the launching user to the local admins group on the system, add the launching user with "full" rights to the folder or to modify the "Users" group permissions on the folder.

Another workaround would be to use a transform (MST) to modify the "SecureObjects" table...perhaps change the "Users" group permission there or to add "Authenticated Users" with the required permissions. The transform would need to be specified when the MSI is installed (using the TRANSFORMS=<pathToMSTFile> property)."


I've attached the transform to this mail. It will add the "Authenticated Users" group to the "Certificates" share with the same permissions as that given to the installing user.
DEV also found another workaround that is explained at the end of Notes. It is for systems that already run the install without a transform.

DEV tested the transform and applied the MSI, MSP and transform (MST) at the same time and "Authenticated Users" showed up on the folder as expected:



Notes
The transform must be applied when the MSI is installed. After that, it is cached by the installer and will be applied whenever the install is run again (patches, repairs, etc.)
The transform cannot be applied if the MSI has already been run and the product is installed. In that case, either the product needs to be uninstalled and then reinstalled using the transform OR the permissions could be added to the "Certificates" folders using the "icacles" utility.
To use the transform, the "TRANSFORMS" property is used (as seen in the snippet) with the path to the MST file assigned to it. The property name should be in all caps.

2nd workaround
This second workaround could be used instead of the transform on new product installs and could also be used on systems that had the product installed without a transform (thereby saving the uninstall
reinstall with transform steps). This workaround uses the "icacls" Windows utility to set the permissions on the "Certificates" folder after the install is run. I've attached a .txt file with the command lines to use. To see information about the utility, type "icacls /?" at the command line.

In case the transform/mst is used, full path needs to be provided for the msi, msp and mst while running the command). The transform (mst file) attached to this CC is the only transform that needs to be used to circumvent this issue if the product is not already installed(there are no other transforms for this purpose). Alternatively, the icacls utility can be used if the product is already installed without the mst (utility can also be used for new product installs, please refer Mike's detailed comments).

As we discussed in call if you are not acceptable with this work around provided, we can suggest you to downgrade the SSP version that being used before."

Thanks,
Mike Bishop

 #sipsoftphone #upgrade #Implementation #2021r1 #SCR



​​​​​​​
#SIP/VolP

------------------------------
Michael Bishop
UnitedHealth Group/Optum
------------------------------