Informing users and clients how to connect their Windows PC to a VPN connection is easy, but could be easier. There are a few questions to answer and having the user type this in might mean wrong answers, and therefore a supsequent support call would be required.
To ease this issue, and reduce the support call costs Microsoft have made available for a number of years the Connection Manager Administration Kit (CMAK). Lots of websites and blogs describe how to make CMAK profiles but to date none that I can find solve the problem of installing CMAK on a x64 version of Windows 2008 (for example Small Business Server 2008, but any x64 bit architecture will do) and attempting to deploy the resulting executable on a i386 XP architecture.
The CMAK program within Windows 2008 (added to the default installation by adding a feature) has options for the creation of a "downlevel" build (i.e. XP, 2003 and 2000) as well as a Vista build (which covers 2008 and Windows 7 as well) but the resulting executable made from the downlevel option is not valid.
The reason for this is many. Firstly the executable is constructed using iexpress.exe on an x64 machine - resulting in a x64 installer that will not run on a i386 machine. Fix this problem (see below for steps) and you find that the installer runs a program to actually create the connection object in the Network settings area of Control Panel, but this program (cmstp.exe) is also x64 architecture and so will not run on an i386 architecture machine.
Before we go into the steps to do this successfully, here (for the benefit of the search engines) are the different errors that you will see:
- This profile was not built for this processor architecture. Please contact your Administrator to get the appropriate profile for this architecture.
- profile.exe is not a valid Win32 application.
- Error creating process <c:\docume~1\user\locals~1\temp\ixp000.tmp\.\cmstp.exe>. Reason: C:\WINDOWS\system32\advpack.dll
To fix this and create an i386 connection profile on an x64 architecture machine involves modifying the file that controls the creation of the executable (the .sed file) and getting two files from either an i386 Windows Server 2003 installation or an i386 XP installation.
First for those extra files. On the Windows 2008 Server that has CMAK installed, and having successfully created a profile (see windowssecurity.com and uksbsguy for profile creation steps) you need to create a folder called i386 inside C:\Program Files\CMAK\Support\en-US (C: and en-US might be different on your installation). This is best done from an elevated command prompt. Inside this folder place advpack.dll and cmstp.exe from an i386 installation of Windows Server 2003 or XP Professional (ensure latest service packs and patches on the source machine as well). Both of these files are found in \windows\system32 on the source installation.
Secondly, also from the elevated command prompt, you need to create a copy of the .sed file for each architecture you want to build for. The .sed file is named after the profile name that you have created and is located in a subfolder of C:\Program Files\CMAK\Profiles\Downlevel where the subfolder is the name of the profile. The default .sed file will work on x64 XP. Therefore to create a .sed file for i386 XP copy profile.sed to profile-i386.sed and then open this file in notepad (by typing notepad profile-i386.sed from the elevated command prompt).
The third step is to edit this .sed file so that the entries that point to the location of cmstp.exe and advpack.dll are to the new files you copied in the first step. Therefore change the line that starts FILE0= and the line that starts FILE1=. These should read something like the following:
- FILE0=C:\Program Files\CMAK\Support\en-US\i386\advpack.dll
- FILE1=C:\Program Files\CMAK\Support\en-US\i386\cmstp.exe
Additionally, but not required, I also change the TargetName= value from profile.exe to profile-i386.exe so that it does not overwrite the x64 executable that has already been created by the CMAK wizard and I edit the InstallPrompt= value to include something that indicates that I am about to install the i386 version of the connection object.
Now close and save the changes made to the new .sed file.
Finally you can build the executable. But the fun does not stop here. You might have noticed from the errors above that one of the errors is that the executable is not a valid win32 executable. This occurs if the x64 version of iexpress.exe is used to create the installation program. You need to use the 32 bit version that is installed on the x64 machine. The 32 bit version of the program is found in c:\windows\syswow64 (this stands for Windows On Windows 64) and so from the elevated command prompt type \windows\syswow64\iexpress /N profile-i386.sed (this is one command on one line if your browser happens to wrap the text over two lines). This will create the executable named after the TargetName value in the .sed file. This can then be copied to your software installation share and deployed to your users.
Labels: cmak, i386, pptp, sbs 2008, sstp, vista, vpn, windows 2003, windows 2008, windows 7, x64, x86, xp
permalink posted by Brian Reid : 8:32 AM
0 comments 
There is a published problem with EBS 2008 where Outlook prompts for a password all the time when connected over HTTP/RPC (Outlook Anywhere) - see the Microsoft EBS Team Blog. We have found that the same problem is also exposed in the Remote Web Workplace when trying to connect over Remote Desktop to your PC or to the servers.
The problem is that the authentication for the Remote Desktop is broken because Outlook has failed to connect based on the published issue mentioned above. The failure of Outlooks authentication breaks the DefaultAppPool is IIS. Recycling the application pool fixes the issue - but only for a short while. It breaks again at the next failed Outlook login. And because the breaks in authentication are due to Outlook it is difficult to see why Remote Desktop ceases to operate.
But apply the same fixes from the above blog and Remote Desktop begins to work and stays working.
To fix, run the following four commands from an elevated command prompt on the messaging server:
- %windir%\System32\inetsrv\appcmd.exe unlock config -section:system.webServer/security/authentication/windowsAuthentication
- %windir%\System32\inetsrv\appcmd.exe set config "Default Web Site/ews" -section:windowsAuthentication -useKernelMode:False /commit:apphost
- %windir%\System32\inetsrv\appcmd.exe set config "Default Web Site/AutoDiscover" -section:windowsAuthentication -useKernelMode:False /commit:apphost
- %windir%\System32\inetsrv\appcmd.exe set config "Default Web Site/OAB" -section:windowsAuthentication -useKernelMode:False /commit:apphost
The above commands are probably wrapped for reading on your screen - each bullet point is a single command to be entered as one line. Instructions for making changes via the GUI can be seen on the above blog post.
Labels: 2008, ebs 2008, remote desktop, remote web workplace, sbs 2008, windows
permalink posted by Brian Reid : 3:16 PM
0 comments
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 SBS 2008 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! The following is a brief guide to the steps. Exact step by step instructions are not included, as you should be someone with RRAS and certificates experience before approaching this, and if you are not but have a business need for SSTP VPN (and who doesn't!) then call C7 Solutions in the UK on 0845 257 1777 for help and assistance. This is not at all easy to configure and get working.
- 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). With the default self signed certificate SSTP will not work as the client on the internet will not be able to reach the certificate revocation location. Using the installed Certificate Services and creating your own issued certificate requires publishing to the internet the certificate revocation information and so adds steps that are not entirely necessary given that certificates are inexpensive and would cost less to buy than the time taken to go through all the extra steps needed with your own issued certificates.
- Enable remote access from the SBS Console > Network > Connectivity page and choose Configure a Virtual Private Network link under Connectivity Tasks on the right-hand side of the window.
- 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 and set the number of connections to a suitable number for your organization. Leave PPTP enabled as Windows XP does not support SSTP VPN tunnels (only Vista SP1 and later will do so).
- Create an MMC and add in the local computers Certificate snap-in. View the properties of your trusted certificate that you are using for Remote Web Workplace and note down the Thumbprint value of this certificate.
- Ensure that this certificate is associated with 0.0.0.0:443 and [::]:443 network 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).
- If the certificate hash is not the same for both the remote web workplace certificate and the netsh bindings information in the previous two steps or if you are missing the IPv6 binding then you need to reset the bindings. If they are same then jump to step 7.
a) Ensure that the certificate bound to the remote web workplace is correct. From the client machine browse to http://remote.your_domain.com. You should be automatically forwarded to https://remote.your_domain.com/remote and the login page. If you get any certificate errors during this in the web browser you must fix them now before continuing.
b) If the certificate on the remote web workplace site is incorrect then run the Fix My Network wizard and the Set Up Your Internet Address wizard in the SBS Console (both found in the Network > Connectivity > Connectivity Task pane).
c) Repeat the test in step a and if the certificate that is now associated with the site is incorrect also run the Add A Trusted Certificate wizard which is found in the same place as above. This step should not be needed if a trusted certificate has already been installed on the server and it matches the remote.your_domain.com name and the wizards in step b will associate the correct certificate to the website.
d) From an elevated command prompt delete the certificate binding for IPv4 by typing netsh http delete sslcert ipport=0.0.0.0:443. The binding should be deleted successfully.
e) From an elevated command prompt delete the certificate binding for IPv6 by typing netsh http delete sslcert ipport=[::]:443. The binding should be deleted successfully if an IPv6 binding existed, otherwise expect to see an error which can be ignored.
f) Delete the certificate binding in the RRAS configuration by deleting these registry keys, if they exist, "HKLM\ System\ CurrentControlSet\ Services\ Sstpsvc\ Parameters\ Sha256CertificateHash" and "HKLM\ System\ CurrentControlSet\ Services\ Sstpsvc\ Parameters\ Sha1CertificateHash"
g) Connect the correct certificate to the IPv4 and IPv6 bindings by typing the following entries from an elevated command prompt where xxx is the certificate hash of the trusted certificate used for the Remote Web Workplace. netsh http add sslcert ipport=0.0.0.0:443 certhash=xxx appid={ba195980-cd49-458b-9e23-c84ee0adcd75} certstorename=MY and netsh http add sslcert ipport=[::]:443 certhash=xxx appid={ba195980-cd49-458b-9e23-c84ee0adcd75} certstorename=MY.
h) Close any open copy of IIS Manager and restart the program. Ensure that the bindings for the SBS Web Applications site is correctly bound to your trusted remote web workplace certificate.
i) Note that binding SSTP to the IPv4 and IPv6 listeners on port 443 will cause TS Gateway administration to display error messages (specifically that the certificate is not bound and that the IIS web site is not configured). These errors can be ignored on SBS 2008 but if you click the links to fix the errors then all will work fine. The only condition is that this fixing of errors must be done after SSTP is configured correctly (so ensure SSTP connectivity works and then come back to this step to fix). Future changes to the certificate in IIS or TS Gateway might break the SSTP binding. - From a client machine browse to https://remote.your_domain.com/sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/ and ensure that no errors occur. Note that you will not see anything in the web browser. View the properties of the certificate, specifically the CRL Distribution Points (CDP) value. Note that you should not have got any certificate errors when browsing to this site and if you did you need to resolve them before continuing further in these steps.
- Browse to the CDP URL in the above certificate - you should be able to reach this location on the web without error. The web browser should attempt to download the CDP file.
- On a Vista (SP1 or later) or Windows 7 client create a new VPN connection and in properties of the connection object choose the Security tab and ensure that the Type of VPN is set to SSTP. For regular everyday use set this to Auto, and it will find a working protocol (starting with PPTP) and so if PPTP does not work due to NAT or firewall/proxy issues SSTP will be tried and succeed (but for testing set the VPN connection 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. Errors regards certificate trust will appear if you have used the self issued certificate, even if you have added the certificate to your certificate store and have the certificate working in Internet Explorer. Once you have connected you can confirm from the RRAS management console that you are connected over an SSTP VPN connection. To confirm this click Ports in the RRAS management console and the active connection should be utilizing an SSTP port.
- Congratulate yourself on getting this far - this is not easy!
Labels: networking, pki, sbs 2008, sstp, vpn
permalink posted by Brian Reid : 11:54 AM
0 comments
Thirty days after installing Essential Business Server 2008 your licence restrictions take effect. This means that users are shown as unlicenced in the EBS Management Console will only be able to log into licenced devices (as shown in the EBS Management Console as well). Only licenced users will be able to log into any computer on the network (unless group policy restrictions so limit them).
The licencing enforcement is implemented by the Log On To restriction on the user account. This restriction (on the Account tab of the users object in Active Directory Users and Computers administration program) lists the workstations, by NetBIOS name, that the user can log into and all unlicenced users will have a list of device licenced machines. All licenced users will be set to allow them to log into any workstation. This list is reset at a regular basis each day, but if you are approaching 30 days since installation get your user and device licences correct, don't miss anyone or any shared device off the list or they will not be able to login or the shared computer will not be accessable to any of the unlicenced users.
Labels: ebs 2008, sbs 2008, windows
permalink posted by Brian Reid : 12:40 PM
0 comments
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
Remote Web Workplace (RWW) is a feature of Windows Essential Business Server 2008 (WEBS) and Small Business Server 2008 (SBS). Both of these operating systems provide a web portal to view internal resources such as Outlook Web Access (OWA), SharePoint and Remote Desktop to your own PC.
I have noticed on a number of installations the following error:
There is a problem in Remote Web Workplace. A logon error occurred: There is a problem communicating with the Outlook Web Access server.
There are two reasons for this that I know about. The outcome of this for the user is a popup with the above error in it when clicking the E-Mail or SharePoint link within RWW.
The first is if you have changed the URL of your RWW site then the Single Sign-On (SSO) functionality is configured to connect to the old URL and so fails. The second reason is if the external URL for RWW is not accessible internally (for example if the internal Active Directory DNS name is the same internally and externally and the internal DNS zone does not have an A record for the RWW URL).
To fix the first issue you need to make a backup of the web.config file located in "c:\program files\Windows Essential Business Server\Bin\webapp\Remote" and then edit this file (using Notepad or the like) so that the ssoApplications node reads as follows:
<wssg>
<ssoapplications>
<ssoapplication application="OutlookWebAccess" servername="remote.fabrikam.com">
</ssoapplications>
Where the serverName value is correct for your environment. Note also that if SharePoint is installed and the Company Web link appears on RWW, this XML node will contain some Sharepoint information that will need changing too.
To fix the second issue you need to add an A record to your internal DNS that points to your RWW site and to use the external IP address of this site. If your internal AD/DNS zone is the same as your external zone (i.e. fabrikam.com in the above example) then create a new A record for remote.fabrikam.com on an internal DNS server that has the external IP address of the site as IP address. If you internal and external DNS zones are separate ensure that the SBS server or the WEBS Messaging Server resolve the external value correctly.
If neither of these solve your problems with RWW then the place to look is the RWW debug log file. This is located in "c:\program files\Windows Essential Business Server\Logs\WebWorkplace\w3wp" and you need to read the bottom of the file to find the most recent login error (search the file from the bottom upwards for the word "error").
The above two problems where solved based on the errors found in this debug log file.
Labels: ebs 2008, rww, sbs 2008
permalink posted by Brian Reid : 9:10 PM
0 comments
The following errors are reported in the Event Log Windows Logs/Application when you run the built-in backup that is part of Small Business Server 2008 (SBS) or Windows Essential Business Server 2008 (WEBS):
Event ID 565 - Consistency check for component StorageGroup-GUID\'Microsoft Exchange Server\Microsoft Information Store\SERVER' failed. Application 'Exchange' will not be avaliable in the backup done at time 'date time'
The Event Viewer log at Application and Services Logs/Microsoft/Windows/Backup/Operational shows that everything completed fine but the Windows Server Backup administrative tool says backup completed with warnings. Double-clicking the backup record shows:
Application will not be available for recovery from this backup. Consistency
check failed for component Microsoft Exchange Server\Microsoft Information
Store\Server-Name\Store-GUID
This seems to be related to having enabled Local Continous Replication (LCR) on the Exchange mailbox database. This is unfortunate as LCR is such a useful tool in recovery for Exchange Servers that I would want to enable it as a matter of course, and spec my SBS servers to have enough disk space to store LCR copies. Note that the actual Exchange databases and log files are backed up as part of the volume backup, just not as part of the application aware backup and that might result in invalid restores as the volume level backup is not Exchange aware.
Please Microsoft, will you make the VSS backup for Exchange 2007 that is included in SBS and WEBS LCR aware. Thanks.
Labels: backup, ebs 2008, exchange, sbs 2008, windows
permalink posted by Brian Reid : 2:05 PM
0 comments
If when you log into Remote Web Workplace on Small Business Server 2008 or Essential Business Server 2008 as a non-administrator user you get the following error messages:
Cannot connect to the Remote Web Workplace site. To continue, contact your network administrator.
Event Viewer/Application Log/ASP.NET 2 Warning: Event ID 1309
ArgumentOutOfRangeException "Index was out of range. Must be non-negative and less than the size of the collection." Request URL: https://server:443/remote/menu.aspx
You need to do the following to fix this error. On the server you need to modify the permissions of the RWWConfig.xml file. This file is located in "C:\Program Files\Windows Small Business Server\Data" or "C:\Program Files\Windows Essential Business Server\Data" depending upon the product that you are running.
- Ensure the permissions on the above file are
Authenticated Users - Read (not inherited)
NETWORK SERVICE - Read (not inherited)
SYSTEM - Full Control (inherited from parent folder)
Administrators - Full Control (inherited from parent folder) - Make sure the Authenticated Users group is a member of the Pre-Windows 2000 Compatible Access group.
- Run iisreset from the command line on the server
- Attempt the login again, but first close any copy of Internet Explorer that was running (or attempting to run) RWW.
Labels: ebs 2008, rww, sbs 2008
permalink posted by Brian Reid : 10:39 AM
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
I got error 0xc00000e9 when attempting to boot into a new guest Hyper-V image, using an ISO image as my boot CD. Using the real CD in the host worked fine.
So I downloaded the ISO again and all was well this time - must have been a dodgy download - now to go play with Windows Small Business Server 2008.
Labels: hyper-v, sbs 2008, server core, virtual server, windows
permalink posted by Brian Reid : 6:08 PM
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