SBS 2008 SharePoint Install Breaks Default SBS Web Site

Posted on Leave a commentPosted in 2008, https, iis, remote web workplace, rww, sbs 2008, terminal server, ts gateway, windows

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.

How to Configure CRM 4 on a Terminal Server When Not All The Users Use Microsoft Dynamics CRM 4.0

Posted on Leave a commentPosted in citrix, crm, terminal server

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.

Setting Remote Desktop to an Alternate Port

Posted on 6 CommentsPosted in terminal server, Terminal Services

The default port for Remote Desktop is 3389, but there are cases where it is useful to change this port, for example on the external interface of a firewall should you be providing remote support of said firewall. These steps are known to work on Windows XP and Windows Server 2003. They have not been tested by me on other versions of Windows.

On the Remote Desktop Server

    1. Start Registry Editor (Regedt32.exe).
  • Locate the following key in the registry:HKEY_LOCAL_MACHINE\ System\ CurrentControlSet\ Control\ TerminalServer\ WinStations\ RDP-Tcp\ PortNumber
  • On the Edit menu, click Modify, click Decimal, type the new port number, and
    then click OK.

 

  • Quit Registry Editor.

 

 

On the Client

    1. Click Start, click All Programs, point to Accessories,
      point to Communications, and then click Remote Desktop Connection.
  • In the Computer box, type the computer name or IP address of the
    computer to which you want to connect, followed by a colon (:) and the port
    number you want to use.For example, to connect to port 3390 on a computer named “MyXPPro,”
    type the following information: MyXPPro:3390

    To connect to port 3391 on a computer with IP address 10.10.10.1,
    type the following information: 10.10.10.1:3391

 

More information at

http://support.microsoft.com/default.aspx?scid=kb;en-us;306759
and

http://support.microsoft.com/default.aspx?scid=kb;en-us;304304