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.
Labels: 2008, https, iis, remote web workplace, rww, sbs 2008, terminal server, ts gateway, windows
permalink posted by Brian Reid : 9:55 AM
0 comments 
The Microsoft Dynamics CRM 4.0 Outlook client software, when installed on a terminal server (Microsoft or Citrix) results in the CRM toolbar (which is part of the CRM Outlook Add-in) appearing for all users of the server regardless of whether or not they require the functionality of CRM and irrespective of whether or not they have an account on the CRM system.
The CRM toolbar appears because the Outlook CRM Add-in is loaded, and the add-in is loaded because of the following registry key:
HKCU\Software\Microsoft\Office\Outlook\Addins\crmaddin.addin
Removal of this key from the users' registry stops the add-in appearing under Outlook and stops the add-in loading. There is though one problem with this. At the users login a program runs that recreates this key if it is missing, so that registry key needs to be removed as well. This one is:
HKLM\SOFTWARE\Microsoft\Windows\Current Version\run and the deletion of the MSCRM value (keeping a copy of the data in this value for later).
For all users logging into a computer running the CRM Outlook client would now only get the add-in if the first registry key above exists, so existing CRM users are not affected by this change. Remove the first registry key above from any user who does not use CRM and remove the second key one from the machine and all new users will not get CRM. To give new users the CRM Outlook add-in just run the command line that was the data of the MSCRM registry value (where x is the drive where the CRM software is installed):
x:\program files\microsoft dynamics
crm\client\configwizard\crmforoutlookinstaller.exe /activateaddin
All the above works fine on a standard client, but if you need to do the above on a terminal server then you need to be aware of the shadow copy of the registry keys that terminal servers use to create the initial users profile the first time they login. Because the CRM client is initially installed with the CHANGE USER /INSTALL command active the registry stores a copy of the first registry key above so that it can be applied to users when their profile is created. This registry key needs to be removed as well. You will find this key at:
HKLM\SOFTWARE\Microsoft\Windows NT\Terminal
Server\Install\Software\Microsoft\Office\Outlook\Addins\crmaddin.addin
Note that you do not need to be in change user install mode when you make this change, as we are not uses these changes to affect existing user profiles, just stopping new user profiles from loading the CRM add-in if they do not need to. To change existing user profiles just delete the first registry key above from their profile using a script or manual action or whatever method you prefer. Of course you will need to have done the other steps above before this or the registry key will be recreated the next time they login.
Labels: citrix, crm, terminal server
permalink posted by Brian Reid : 9:43 AM
0 comments
Archive
March 2005
July 2005
February 2006
May 2006
November 2006
March 2007
May 2007
June 2007
August 2007
April 2008
May 2008
June 2008
September 2008
October 2008
November 2008
January 2009
February 2009
March 2009
April 2009
May 2009
June 2009
July 2009