The easiest way to change the expiration date for your server’s SSL certificate is to re-run the CEICW. When you get to the page asking about the web certificate, create a new one:

Obviously what you put in the “Web server name” box should match what you had there before – the external hostname of your server. SBS will generate a new certificate, whose expiration date will be five years in the future.

Because third-party SSL certificates from GoDaddy and others are so inexpensive these days, there is little reason to continue using self-signed certificates in SBS. However, if you want to stick with a self-signed cert for more than five years, now you know how.

There are few if any people on the planet more familiar with Small Business Server than Microsoft’s Sean Daniel. Sean recently posted a feature comparison between SBS 2003 and SBS 2008. What strikes me about this list is how little is striking. Almost all the new features are benefits for the network administrator, not the end users, and many of those new features apply only to the initial installation and configuration of the product.

I’m still not seeing any compelling reason to upgrade from SBS03 to SBS08 unless there’s a particular feature of Exchange 2007 that the organization wants to deploy. I’ve heard a lot of folks saying "we’ll upgrade our clients to SBS08 when it’s time to replace their server hardware." But when will that be? I’ve got servers that are four-plus years old running SBS03 and doing just fine. What exactly is going to warrant a server hardware replacement? Have there been any changes in CPU technology that would have a meaningful impact on the productivity of a typical small business?

I hope I’m missing something. The leaps between SBS 4.5, SBS 2000, and SBS 2003 were simply extraordinary. I’d hate to think that the SBS 2008 is going to be a big fat "ho-hum." So please comment and tell me where I’m wrong.

It turned out that the problem was caused by an expanding log file created by Windows SharePoint Services 3.0. I’ve updated my WSS-on-SBS instructions to acknowledge the problem and point people toward the fix, but I don’t have step-by-step instructions for fixing (or better yet, preventing) the problem quite yet.

If there’s another WSS-on-SBS’er who’s already got a fix for this and who wouldn’t mind contributing to the instructions so I don’t have to write them up from scratch, I’d love to hear from you.

Unexpected difficulty: I tried to follow the excellent instructions for installing a public 3rd-party SSL certificate on IIS on SBS 2003 at the Official SBS Blog. But in step 5 of those instructions, you are told to “select a Host Header value for this Web site that does not conflict with existing sites.” In the example they provide, they set the Host Header equal to the FQDN of the server: mail.contoso.com. In my case, though, the Host Header “mail.myclient.com” did conflict with an existing site — the one with the expired SSL certificate. So I got an error message when I tried to create the site (step 6).

Solution: The name of the temporary web site and its Host Header value do not need to match the FQDN of the server. I ended up creating a web site called Temp Cert Request with a Host Header of tempcertrequest.myclient.com. I used that web site to generate the CSR request, making sure to put mail.myclient.com in as the common name in the wizard (step 11). I used “2008 mail.myclient.com” as the Friendly Name (step 9) just to make sure I knew which certificate was which.

Thanks to Andy Harper and David Houston for assuring me that I didn’t need to worry about matching Host Header with FQDN.

Feel free to take your own shot at me via comments on this post or in responses to Kevin’s or Susan’s blog. Or, if the spirit so moves you, feel free to agree with me as well.

I get asked this question at least once a month, so I figured it was worth writing up here.

If Outlook loses its connection to the Exchange server for a while, it may go into Offline mode. As long as Outlook is set to work offline, you will not be able to send and receive messages in the background – you will have to hit the Send/Receive button.

To see whether Outlook is working online or offline, look in the lower right corner of the screen. If you are connected to Exchange, it will look like one of these two pictures:

(Outlook 2007)

(Outlook 2003)

If you are working offline, it will look like this:

(Outlook 2007)

(Outlook 2003)

To remedy the problem, click the arrow to the right of “Offline” and uncheck the Work Offline option:

If you are still unable to connect to the Exchange server after unchecking Work Offline, it may look like this:

If that’s the case, then the problem is more serious and you need to figure out why your computer is not communicating with the Exchange server at all.

Here was the scenario:

• Server: SBS 2003 Standard SP1, Exchange 2003 SP2
• Don and Jorge have WM5 phones
• Don had absolutely no problem synchronizing his phone with Exchange.
• Jorge cannot sync either over the air or while cabled to a laptop. We had tried with three different WM5 devices (Treo 700w, Motorola Q, XV6700) over the air and while cradled from two completely separate remote locations. We had tried using both ActiveSync 4.5 on XP and the Mobile Device Center on Vista.
• Server is using a GoDaddy SSL certificate. SSL settings on the server had been triple-checked, and as noted above Don could sync without difficulty (on two different devices, no less).
• Jorge was able to get to log into OWA and see his mail from the WM5 device.
• David – a domain admin account being used for test purposes – was unable to sync from one of the same devices successfully synched for Don.
• Mabel – another (non-domain-admin) account also used for test purposes  – was also unable to sync from that device.

The error on the server when trying to sync was:

Log: Application
Type: Error
Event: 3005
Time: Oct 2 2007 5:44PM
Source: Server ActiveSync
Category: None
Username: jorge
Computer: SERVER
Description: Unexpected Exchange mailbox Server error: Server: [server.internaldomain.com] User: [jorge@externaldomain.com] HTTP status code: [409]. Verify that the Exchange mailbox Server is working correctly.

The error on the device when trying to sync was:

Your account in Microsoft Exchange Server does not have permission to synchronize with your current settings. Contact your Exchange Server administrator. Support code: 0×85010004.

I checked Jorge’s Exchange Features in Active Directory and all are enabled. Jorge is in the same AD OU and same security groups as Don.

Unfortunately, these error messages are rather non-specific. I went through dozens of pages found via Google searches. Most suggested that the problem was related to SSL certificates, host headers, firewall settings, and other issues that turned out not to be the cause.

Fortunately, I am a Microsoft Small Business Specialist, and that entitles me to free support from Microsoft engineers in Shanghai through a managed newsgroup. I posted my problem there, and got this thorough troubleshooting checklist:

Step one:
Please install the hotfix below to see if it helps:
Error message when you try to synchronize a Windows Mobile 5.0-based device in Exchange Server 2003: “0×85010004″
http://support.microsoft.com/kb/919864/en-us
 
Step two:
This issue can be caused if you have a Firewall and not allowed a rule on the Firewall for Microsoft-Server-ActiveSync. So I would like to check if you have run the CEICW Wizard. Please open Server Management console, navigate to ‘To Do List’ and click ‘Connect to the internet’ in the right panel. The wizard can help us configure the networking settings for a SBS server. It automatically creates the ISA rules for internet access and site publishing. It’s strongly recommended to use the wizard to configure the SBS server. More info:
825763 How to configure Internet access in Windows Small Business Server
2003
http://support.microsoft.com/?id=825763
XCSI/PRE/E2K3/Unable to synchronize with Exchange server using Active Sync
http://support.microsoft.com/default.aspx?scid=kb;EN-US;924216

Step three:
Please checked the properties of Microsoft-Server-ActiveSync, is the
Directory Security properties for IP Address and Domain Name Restrictions
configured as ” DENIED ACCESS”? To check it:
1. Open IIS.
2. Expand Web Sites -> Default Web Site.
3. Open the Properties page of Microsoft-Server-ActiveSync.
4. In Directory Security tab, click Edit under “IP address and domain name
restrictions”.
5. Make sure that you configured as Granted access.

Step four:
Please check the following IIS settings:

For Exchange/Exchange-oma virtual directory:
1. Open IIS Manager
2. Open properties of virtual directory Exchange/Exchange-oma
3. Select Directory Security tab
4. Select Edit in Authentication and access control box. Make sure the authentication setting as below:
Authentication Methods
Enabled Basic authentication
Enabled Integrated Windows authentication
Disabled anonymous access

For OMA virtual directory and Microsoft-Server-ActiveSync virtual directory:
1. Open IIS Manager
2. Open properties of OMA virtual directory and Microsoft-Server-ActiveSync virtual directory respectively.
3. Select Directory Security tab
4. Select Edit in Authentication and access control box. Make sure the
authentication setting as below:
Authentication Methods
Uncheck Enable anonymous access
Uncheck Integrated Windows authentication
Check Basic authentication

Of all the items that were listed here, the only ones that were off on my server were that the hotfix had not been installed and that anonymous access on Exchange-oma was not disabled. I made both of these changes, and I am 99% sure that it was the Exchange-oma change that finally solved the problem.

Fortunately, there are a few ways to figure out who’s got that address, and this article explains them.