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 
This is a long list of pre-requisites, but for your information they do not work together.
- If you have a web site that uses Access as its data storage and you migrate that site to an x64 Windows machine then access to the Access MDB file ceases with the following error: "'Microsoft.Jet.OLEDB.4.0' provider is not registered on the local machine".
- On IIS 6.0 you need to set the entire web server to 32 bit mode, but on Windows 2008/IIS 7.0 you can set each application pool to 32 or 64 bit. This is a property found under Advanced Settings for the application pool. To gain access to Access MDB files the application pool needs to run in 32 bit mode.
- If you have TSWeb installed, then you also have installed the RPC/HTTP proxy component.
- If you have the RPC/HTTP proxy component installed any 32 bit application pool will fail upon starting - Error 5139 for Microsoft-Windows-WAS.
So to use Access databases in a legacy web application migrated to Windows 2008, 64 bit, with TSWeb also installed either uninstall TSWeb (and RPC/HTTP proxy), or use a different server, or rewrite the web application to use SQL Express. Supposedly this will be fixed in the first service pack for Windows 2008.
There - it only took 6 hours to work that one out!
Labels: 2008, 64 bit, access, iis, oledb, proxy, sql express, windows, x64
permalink posted by Brian Reid : 7:47 PM
0 comments
Updated 31st March 2008: Please see http://www.c7solutions.com/blog/2009/03/configuring-sstp-vpn-on-small-business_31.aspx as this new article replaces the below, as the below refers to a pre-release version of SBS 2008. The working instructions for configuring SSTP on SBS 2008 is much more complicated than the steps below.SSL based VPN's are great. In short it is VPN without firewall or NAT issues (both of which you get with PPTP and IPSec VPN's). But the current release of SBS 2008 (RC0) does not enable SSTP VPN's by default. It uses RRAS, so SSTP is possible, but it is not as easy as it first looks!
- Ensure that you have run the connecting to the internet wizard, and that you are using a third party certificate (as there are less steps if you do this).
- Enable remote access from the SBS Console > Network > Connectivity page.
- Add some SSTP ports to the VPN in the Routing And Remote Access management program. Right-click Ports and choose Properties and enable SSTP for remote access inbound connections. Leave PPTP enabled as Windows XP does not support SSTP VPN tunnels (only Vista SP1 does at this time).
- View the properties of your certificate and note down the Thumbprint value.
- Ensure that this certificate is associated with 0.0.0.0:443 and [::]:443: certificate bindings on the server. Type "netsh http show ssl" from elevated command prompt to get this information. You typically get four entries with IP:port being the first line of each. Check for IP:port reading "0.0.0.0:443" and [::]:443 as this shows the IPv4
and IPv6 mappings for SSL certificates on the server. Ignore the :8172 and :987 entries (these are for IIS Management Service and companyweb). - For both "0.0.0.0:443" and [::]:443 make a note of the Certificate Hash. It needs to be the same for both and the same as the earlier Thumbprint value (ignore any spaces).If not see
http://blogs.technet.com/rrasblog/archive/2007/11/08/configuring-iis-on-the-sstp-server-implications-and-how-to-resolve.aspx for instructions on resetting this, noting that you need to ensure that the correct certificate is bound to the SBS Web Applications website on the SBS 2008 server (in IIS manager). - Install the "Certificate Authority Web Enrollment" role service to Active Directory Certificate Services snapin within Server Manager. This adds a virtual directory to the default website in IIS called CertEnroll which contains the certificate revocation list for the certificate you are using. Only do this if you are using the built in default issued certificate. If you are using certificates from a third party then you need to ensure you can reach
their CRL publishing site without issue - see the certificate details for information on the CRL publishing site location. - Expand the Certificate Authority on your server and right-click Revocated Certificates. Under tasks choose Publish. This updates the CRL with the new publishing location that SSTP needs to connected to. Again, use a third party certificate to make this easy!
- On a Vista SP1 client create a new VPN connection and in properties > networking ensure that the Type of VPN is set to SSTP (for normal use set this to Auto, and it will find the best (starting with PPTP), but for testing set it specifically to SSTP). Also ensure that the name of the server you are connecting to is the same name that the certificate uses for the certificate common name.
- Connect the VPN and all should work.
Labels: 2008, iis, rras, sbs 2008, sstp, vpn, windows
permalink posted by Brian Reid : 9:34 AM
0 comments
A new feature in digital certificates is the Subject Alternative Name property. This allows you to have a certificate for more than one URI (i.e. www.c7solutions.com and www.c7solutions.co.uk) in the same certificate. It also means that in web servers such as IIS you can bind this certificate to the site and use up only one IP address.
A number of commercial companies now sell certificates with the Subject Alternative Name field set, but this article describes how to use the Exchange Server 2007 command line to create certificate requests for other web sites that can be uploaded to Microsoft Certificate Server (which does not support this property in its own web pages) to create certificates for web servers such as IIS (which also do not support this property in the requests that they make).
The command that you need to run is via PowerShell, and specifically via the Microsoft Exchange Server 2007 extensions to PowerShell. So start up the Microsoft Management Shell and enter the following (replacing your domain names as indicated:
New-ExchangeCertificate -GenerateRequest:$true -Path c:\newCert.req -DomainName www.domain.com,sales.domain.com,support.domain.com -PrivateKeyExportable:$true -FriendlyName "My New Certificate" -IncludeAcceptedDomains:$false -Force:$true
The DomainName property is set to each URL that you want the certificate to be valid for, with the first value in the string being the value for the Subject field and all the values each being used in the Subject Alternative Name field.
Once you have executed the command above you will have a file with the name set in the Path property. This file can be opened in Notepad and used in Microsoft Certificate Services:
- Browse to your Microsoft Certificate Services URL and click Request a certificate
- Click advanced certificate request
- Click submit a certificate...
- Copy and paste the entire text of the certificate request from notepad into the Saved Request field on this page and select Web Server as the Certificate Template. Click Submit.
- With a default installation the Web Server template value will not be present and that needs to be enabled by your Certificate Services administrator for your user account
- With the default installation of Certificate Services, the certificate will now be ready to download. Click Download certificate (or Download Certificate Chain if the end server does not trust your issuer) to save your certificate to the computer.
- Install the certificate on to the same computer that you issued the request from (this is a very important step), and then you can export the certificate and import it on your web server or firewalls.
To install the certificate, run the Import-ExchangeCertificate powershell command on the same computer as the request was issued from (this is a very important, it must be on the same computer). This is a simpler command to run that the creation of the request above.
The syntax of this command is (where the filename is the name of the file downloaded above):
Import-ExchangeCertificate c:\newCert.cer
To export the certificate to your web server or firewall you need to open the local computer certificate store in the Microsoft Management Console - run mmc, add a snap-in and choose Certificates, Computer account. You will find your certificates under the Personal store. You can right-click these certificates and export them (with the private key) to a .pfx file. This file can then be imported using the MMC tool on the web server or firewall ready for importing using an mmc with the certificates/computer account snap-in load into it.
Labels: 2007, certificates, exchange, iis, microsoft, pkcs, powershell, web
permalink posted by Brian Reid : 9:26 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