If CRM 4 Client is installed on a Citrix/Terminal Services server and the initial installation (done when in CHANGE USER /INSTALL mode) also includes starting Outlook for the first time then a registry key is set in the Terminal Services registry shadow. This means that once you go into CHANGE USER /EXECUTE mode and a new user logs in they get the registry keys set during installation as part of their profile.
This is by design if the registry keys that are set are not needed to be unique per person. And CRM has one registry key that needs to be unique for each user logged into the terminal server. This is the ClientRemotingChannel registry value located at HKCU\Software\Microsoft\MSCRMClient.
If more than one person is connected to the terminal server and running Outlook with CRM configured then behind the scenes the CRM hoster application will be running. The ClientRemotingChannel registry key controls the ability of this application to communicate with Outlook and the CRM server and therefore this registry value must be unique for every logged in user on the terminal server at the same time. If more than one user has the same value (which they will if initial installation is done as above) then the 2nd concurrent user will fail to connect to CRM via Outlook – web access will work fine.
Therefore ensure that the shadow registry value for this (HKLM\SOFTWARE\Windows N\…\MSCRMClient) is not set and that all users that already have a duplicate value have the registry value deleted. The hoster application will recreate the registry value when it starts with a unique value if the registry setting is missing.
A clue to the existence of this error will be the application event log error “Failed to create an IPC Port: Access is denied”.
A recent installation of a second SharePoint site on Small Business Server 2008 broke the Remote Web Workplace site for access from the internet. Intranet access to the site worked fine, but from the internet where the http request to the site is redirected to https had stopped working.
Opening up IIS 7 Manager and checking the bindings of the SBS Web Applications site showed that the site had two http bindings and a https binding. The https binding was for * under IP Addresses and port 443. Clicking the Edit button on this binding showed that the certificate was not correct. This was the reason the site was not working, as a https site requires a certificate.
So I selected the correct certificate and clicked OK. And got the following error:
A specified logon session does not exist. It may already have been terminated. (Exception from HRESULT: 0x80070520)
The reason is that the installation of the SharePoint site, and the installation of the certificate to support that site broke the binding for the TS Gateway role on the Windows 2008 machine. The broken binding on the SBS Web Applications site was because of this broken TS Gateway configuration and to fix the above error in IIS required fixing the TS Gateway issue. Note that at no point in the configuration of the SharePoint application was the TS Gatway role configuration changed – the installation of another certificate on the server broke the TS Gatway which broke the Remote Web Workplace SBS Web Applications site.
Opening Server Manager and navigating to the Roles/Terminal Services/TS Gateway/Servername area showed a message in the middle pane of the Server Manager saying that configuration of the TS Gateway was not complete. Clicking this link brought up the TS Gateway SSL Certificate page of the Properties dialog. Click Browse Certificates and select the correct certificate. In SBS 2008 this will be the Remote Web Workplace certificate. Click OK to close the dialog and you will now be able to check the https binding on the SBS Web Applications website. The error will now not occur, and the https binding will be bound to the correct certificate.
If you are not running SBS 2008 then the above is possible, just it is more likely to be a problem with the Default Web Site bindinging instead.
Additionally, I noticed after I had written the above that this error also occurs if you delete the certificate used by the TS Gateway from the IIS box and as well as breaking TS Gateway (which would be expected) it also breaks the “Add a trusted certificate” wizard in the SBS Server Console. The Add a trusted certificate wizard crashes when started with just a failed application message and nothing in the event log. To fix make sure the SBS Web Application IIS site is bound to a valid digital certificate.