I had high hopes for this, because WHS v1 has done very well by me, and I was excited to see a newer version which might address some quirks of v1. However, I am disappointed.

Windows Home Server 2011 is, in my professional opinion, a train wreck.

• It is bloated. Its hardware requirements are more than triple that of the original version, and when you just meet them, it runs very, very slowly.
• It has an agent that wants the user to sign in, so you have to create user accounts.
• It doesn’t seem to want to run the backups if the agent is not signed in.
• When you do create an account and try to sign in, it often complains that the server appears to be offline.
• I’ve read some other blogs of some folks having difficulties getting the restore to work in situations that v1 handled without issue. I haven’t gotten as far as getting a successful backup yet, so have not tested the restore. Yet, I’m frustrated enough with it to abort my testing right now and get on with my life.

The only good thing I can think of to say about it is that the warning screen you get when you log into the console, telling you to be careful what you do when logged into the console, is now a wallpaper instead of a web page pop-up.

I will continue to use WHS v1 for the time being, despite its little quirks.

You may receive the following message when you try to connect to a company workstation using Remote Web Workplace on SBS 2011:
“This computer can’t connect to the remote computer because no certificate was configured to use at the terminal services gateway server.”

There are a number of possible causes for this error, but in this case, we were NOT using the self-signed certificate, and had carried over the SSL certificate from a previous server and manually added it to the SSL site bindings in IIS Management.

In order to eliminate the error, we needed to tell Remote Desktop Gateway which SSL certificate to use. I found a handy help topic in SBS for this. But first we had to find Remote Desktop Gateway Manager.

It’s not installed by default. First you have to go into Server Manager and “Add Feature”. It’s under Remote Server Administration Tools -> Role Administration Tools -> Remote Desktop Services Tools. Check the box for

Here’s the SBS help topic:

Select an Existing Certificate for Remote Desktop Gateway
After you obtain and install a certificate for the RD Gateway server, you must map the certificate to the RD Gateway server by using Remote Desktop Gateway Manager. If you map an RD Gateway server certificate by using any other method, RD Gateway will not function correctly.

Note:
This procedure is not required if you created a self-signed certificate for RD Gateway.

To import the Remote Desktop Gateway certificate:

1. On the RD Gateway server, open Remote Desktop Gateway Manager. To open Remote Desktop Gateway Manager, click Start, point to Administrative Tools, point to Remote Desktop Services, and then click Remote Desktop Gateway Manager.
2. In the Remote Desktop Gateway Manager console tree, right-click the local RD Gateway server, and then click Properties.
3. In the Properties dialog box for the RD Gateway server, on the SSL Certificate tab, click Select an existing certificate from the RD Gateway <RD Gateway Server Name> Certificates (Local Computer)/Personal store, where <RD Gateway Server Name> is the name for the computer on which the RD Gateway server is running.
4. Click “Import Certificate”.
5. In the Import Certificate dialog box, click the certificate that you want to use, and then click Import.
6. Click OK to close the Properties dialog box for the RD Gateway server.

If this is the first time that you have mapped the RD Gateway certificate, after the certificate mapping is completed, you can verify that the mapping was successful by viewing the RD Gateway Server Status area in Remote Desktop Gateway Manager. Under Configuration Status and Configuration Tasks, the warning stating that a server certificate is not yet installed or selected and the View or modify certificate properties hyperlink are no longer displayed.

Tags: SBS 2011

• These instructions are based on Windows Server 2003 and Watchguard XTM 11.3.2 on an XMT 23 appliance, using Policy Manager version 11.3.2-B290753.
• You can view the documentation that this configuration is based on here.

Overview:

• In the firewall, configure the Active Directory Authentication Server.
• In the firewall, configure the Moobile User VPN with SSL.
• On the Active Directory Domain Controller, create a security group named “SSLVPN-Users” and populate it with users.
• On the workstation, install the Watchguard Mobile VPN with SSL Client.

Details below.

Set up the Authentication Server in the Firewall:

1. Click Setup -> Authentication -> Authentication Servers.
2. Click the Active Directory tab.
3. Check the box to enable it.
4. Type the IP address of the Active Directory Domain Controller server.

Note: if your AD server is on the other side of a BOVPN tunnel, see the WG documentation for how to configure this.


5. In the port field, put either 389 (if the DC is NOT a Global Catalog server) or 3268 (if the DC is a GC server).
6. In the Search Base field, type your LDAP search base.

Note: If your internal AD domain name is “company.local” and your security groups are in an OU called “CompanyGroups”, then your search base might be “CN=CompanyGroups,DC=company,DC=local”. You can shorten this to just “DC=company,DC=local” if you’re not sure of the path to your OU and you don’t mind it searching the entire AD.
If you need help finding your search base, refer to the WG documentation.

7. The Group String should already be set to “memberOf”. Leave it at default.
8. You only need a DN and password of Searching User under special circumstances. Refer to the WG documentation if you have any questions about this. Most configurations will not require this, so leave it blank if you’re not sure.
9. Click OK.

Set up Mobile VPN with SSL in the Firewall:

1. Click VPN -> Mobile VPN -> SSL.
2. Check the box to activate Mobile VPN with SSL.
3. Drop down the Authentication Server list and choose Active Directory.
4. Select the external IP address for the users to connect to.

Note: If you have any inbound port translation rules for SSL, for example Outlook Web Access or Remote Web Workplace, you will need to use a different IP address that does not have a conflicting rule, or change the port number on the Advanced tab of Mobile VPN with SSL properties. If you change the port, you reduce the likelihood of the VPN working in diverse environments such as airports, hotels, wireless hotspots, etc. where they may have restricted ports for internet access.

5. Drop down the Network and IP Address Pool list and choose Bridge VPN traffic.

Note: you may choose to configure your setup differently. This step does not change the configuration of the authentication server. If you might want to connect via routed traffic instead of bridged traffic, see the WG documentation for details.

6. If you are using Bridging, then drop down the “Bridge to interface” list and select “Trusted”.
7. Specify a start and end IP address for the firewall to draw from. Document these and exclude them from your DHCP pool to avoid IP address conflicts.
8. Click the Advanced tab.
9. If needed, you can adjust the Authentication and Encryption methods here as well as keepalive settings. Most configurations will not require this.
10. If port 443 is in use on the Primary Firebox IP Address you specified on the General tab, you will need to change the port in the “Data channel” area.
11. Specify a DNS domain name. This should match your internal Active Directory domain name, for example “company.local”.
12. Specify a DNS server for DNS name resolution.
13. If appropriate to your network, specify a WINS server for netBIOS name resolution.
14. Click OK.

On the Domain Controller:

1. Create a Global Security Group in or under the OU you specified in your Search Base earlier.
2. The name of the security group MUST BE “SSLVPN-Users”. It is case sensitive.
3. Populate the security group with VPN users.

On the Workstation:

1. Open a web browser and connect to https://(firewall IP address or FQDN)[:port]/sslvpn.html. You can leave off the colon and the port if the port is 443.

Note: You can also download the client software from the WG website and distribute it manually.

2. Accept the SSL certificate warning (if any) and proceed to the web page.
3. Log into the Watchguard firewall using a domain user account that is in the SSLVPN-Users security group.
4. Download one of the client packages and install it.

• When the client software asks for the server information, use the external IP address or FQDN of the firebox. Add a colon and a port number if it is not using 443. For example: “mail.company.com:444″.
• The username and password is their domain username/password, assuming that it is a member of the SSLVPN-Users security group. You do not need to qualify the user account with “domain\”.

Tags: AD Authentication, Mobile User VPN, VPN, Watchguard

You may received the following event in the Application log:

Application log generated Error Event 12016 on server.domain.local
Log: Application
Type: Error
Event: 12016
Source: MSExchangeTransport
Category: TransportService
Computer: server.domain.local
Description: There is no valid SMTP Transport Layer Security (TLS) certificate for the FQDN of server.domain.com. The existing certificate for that FQDN has expired. The continued use of that FQDN will cause mail flow problems. A new certificate that contains the FQDN of server.domain.com should be installed on this server as soon as possible. You can create a new certificate by using the New-ExchangeCertificate task.

If you are not using TLS, you might not notice any ill effects of this error, but it’s annoying anyway.

You’re probably confused as to why you’re seeing this error, since you have a current, valid SSL certificate.
If so, there’s a good chance you used IIS to get your new certificate, and Exchange simply doesn’t know about it.
All you have to do to fix this is run a simple command line to tell Exchange to use your new certificate.

Before you can do this, you need to know the “thumbprint” of the certificate you’re going to replace the expired one with.

Here’s how to find it:
1. Run “MMC”.
2. Add the Certificates snap-in to your MMC console. Choose “Computer Account” and “Local Computer” when adding the snap-in.
3. Navigate to where your certificate is in the Certificates snap-in.
4. Double-click to view your certificate.
5. Click the Detail tab and scroll down the list of fields until you find Thumbprint (usually near the bottom).
6. Open Notepad, and paste the following command line below into it:
enable-exchangecertificate -thumbprint [your thumbprint here] -services SMTP
7. Copy the thumbprint’s hexadecimal sequence into the command line, replacing “[your thumbprint here]“, and remove the spaces.
8. Open Exchange Management Shell and paste the adjusted command line into the powershell.
9. When prompted, press Y to confirm the replacement of your expired certificate.
10. Make yourself a note on how to do this next time the cert expires.

Note: You could make yourself a self-signed certificate WAY into the future and use that one to avoid messing with this on a regular basis.

Tags: SMTP Transport, SSL, TLS

This kind of thing has come up for me a couple of times in the last month so I thought I’d post about it.

Basically, what’s going on is that Microsoft’s DNS implementation has gotten port-happy recently, interfering with other services. For example, Internet Authentication Service starts and then stops again because port 1645 is already in use. However, if you stop the MS DNS Server servcie, then start IAS, it stays running. Then you can start DNS again and all is well until the next reboot.

More recently, I started getting this error:

Log: Application
Type: Error
Event: 3015
Agent Time: 7:12:18 pm 22-Dec-10
Event Time: 3:12:18 am 23-Dec-10 UTC
Source: Server ActiveSync
Category: None
Username: N/A
Computer: [removed]
Description: IP-based AUTD failed to initialize because the processing of notifications could not be setup. Error code [0x80004005]. Verify that no other applications are currently bound to UDP port [2883], or try specifying a different port number.

Once again, reserving a port was the answer. This time it was port 2883, for the AUTD service.

I’ve created a .reg file with a bunch of reserved ports for services that have been reported to have conflicts due to this problem.

Here’s the Technet blog post where I got the list of ports from.

Here’s the .reg file:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
“ReservedPorts”=hex(7):31,00,30,00,38,00,30,00,2d,00,31,00,30,00,38,00,30,00,\
00,00,31,00,34,00,33,00,33,00,2d,00,31,00,34,00,33,00,34,00,00,00,31,00,36,\
00,34,00,35,00,2d,00,31,00,36,00,34,00,36,00,00,00,31,00,37,00,30,00,31,00,\
2d,00,31,00,37,00,30,00,31,00,00,00,31,00,37,00,32,00,30,00,2d,00,31,00,37,\
00,32,00,30,00,00,00,31,00,37,00,34,00,35,00,2d,00,31,00,37,00,34,00,35,00,\
00,00,31,00,38,00,30,00,31,00,2d,00,31,00,38,00,30,00,31,00,00,00,31,00,38,\
00,31,00,32,00,2d,00,31,00,38,00,31,00,33,00,00,00,32,00,38,00,38,00,33,00,\
2d,00,32,00,38,00,38,00,33,00,00,00,33,00,33,00,34,00,33,00,2d,00,33,00,33,\
00,34,00,33,00,00,00,34,00,35,00,30,00,30,00,2d,00,34,00,35,00,30,00,30,00,\
00,00,00,00