A common error generated by ISA seems to cause a great deal of confusion and frustration for people who don’t work with ISA on a regular basis. However, this is actually one of the easiest issues to identify and then resolve with ISA. The exact error message that is seen in the browser is:

403 Forbidden - The server denies the specified Uniform Resource Locator (URL). Contact the server administrator. (12202)
Internet Security and Acceleration Server

What this means, simply, is that the server address entered into the browser does not match the web site name that ISA is expecting. An easy way to see this for yourself is to try to access the Remote Web Workplace of an SBS box by entering the address as https://ipaddress/remote instead of https://site.domain.com/remote (provided that you have your SBS box configured to use site.domain.com as the public address). Boom, instant 403 Forbidden error.

So how can you tell what URL ISA is expecting to get from the browser? Also easy. Once you get the 403 Forbidden page, click on the Certificate Error tag in the browser address bar (you will always get a certificate error in this condition, by the wat) and view the certificate. The address in the certificate is what ISA is expecting to see. This is because ISA actually advertises the public certificate in the web listener to decrypt the incoming SSL transmission from the client. When it decrypts the transmission, if the URL it’s listening for does not match the URL that was requested, the connection is refused and ISA returns the 403 Forbidden error.

A common mistake made by those new to SBS is entering the wrong name for the SSL in the Connect to the Internet wizard. In a non-ISA setup, this will work, but it’s still wrong. The reason it works is that users can still bypass the Invalid Certificate warning that they see in IE. Only in this case, the invalid certificate warning is generated because the name on the certificate does not match the URL entered. Many times I’ve seen people enter the internal name of the server in the SSL certificate field of the CEICW, and by pure happenstance it hasn’t been a problem for them. Until ISA gets in the mix. ISA will not redirect traffic to the internal web site if the requested URL does not match the URL that ISA is advertising.

The best solution for ensuring that ISA is working correctly is to acquire and install a valid third party SSL certificate on the SBS server, then instruct your users to never go through to a site that lists an invalid certificate. Steps for requesting and installing a third party SSL cert for ISA on an SBS box can be found at the Official SBS Blog.

Looks like there might be an issue with installing KB948110 via Automatic Updates or Microsoft Updates if you have Sharepoint on the server. I’m tracking this down at a client site, but have heard of several other instances this morning. The behavior is this:

• After installing KB948110, Sharepoint/Companyweb is not available. The message “Cannot connect to the configuration database. For tips on troubleshooting this error, search for article 823287 in the Microsoft Knowledge Base at http://support.microsoft.com.” appears in the browser when accessing the site.
• The Application Log has numerous Sharepoint errors: #50070: Unable to connect to the database STS_Config on SERVER\SharePoint. Check the database connection information and make sure that the database server is running.
• The ERRORLOG file in C:\Program Files\Microsoft SQL Server\MSSQL$SHAREPOINT\log contains the following at the end of the log: Database ‘master’ has invalid schema.

If you go into services.msc, you will see that MSSQL$SHAREPOINT is set to Automatic but not started. If you start the service, it will appear to start, but on a refresh it will show as stopped again. Attempts to uninstall KB948110 may not show the Sharepoint instance in the list. A successful uninstall of 948110 may not restore operation to Sharepoint, either.

I’m working with Microsoft on this and will update this post as new information becomes available.

UPDATE: 1:45pm
One of the factors leading to the issue has been identified. The 948110 update is not correctly identifying the Service Pack level on some MSDE instances. In cases where MSDE 2000 is at SP3, the 948110 update should not be installing, yet it is. This was the cause of the problem on the system I was working with. Other factors are involved as well, and those are still being investigated. More info as it becomes available.

UPDATE: 4:00pm
The SBS CSS support team is now officially recommending that you hold off on installing this update on SBS servers, per their blog post: http://blogs.technet.com/sbs/archive/2008/07/09/hold-off-on-installing-hotfix-948110-on-sbs-2003-servers.aspx. I’m taking the stance that I will not be installing this update on any servers with Sharepoint until another update is released.

UPDATE: 7/10/08 7:00am
OK, a few other items have been identified as causes for this issue. I’ve already mentioned the Sharepoint database being on WMSDE 2000 SP3 instead of WMSDE 2000 SP4. Turns out there are also cases where Sharepoint is running on MSDE 2000 instead of WMSDE 2000, and that can cause problems as well. Not sure how Sharepoint is getting installed on MSDE 2000 instead of WMSDE 2000, as with the SBS 2003 install it goes on WMSDE for sure (and I think the default install of WSS 2.0 does as well), but there have been some instances where this is the case.

If you look in the ERRORLOG file in the path mentioned earlier, you may see something like this at the top of the file:

Microsoft SQL Server 2000 - 8.00.2039 (Intel X86)
May 3 2005 23:18:38
Copyright (c) 1988-2003 Microsoft Corporation
Desktop Engine on Windows NT 5.2 (Build 3790: Service Pack 2)

The last line above is the tell-tale indicator of which version of SQL that the Sharepoint database uses. If it says “Desktop Engine” like in the example above, Sharepoint is sitting on MSDE (which has a 2GB file size limit and the real reason it wants to sit on WMSDE). Instead, the line should read “Desktop Engine (Windows)” which indicates that it’s sitting on WMSDE.

Also, the SBS Blog has an update on how to get Companyweb working again if you hit this scenario. this is a workaround, as their advise is to roll back the BINN directory under MSSQL$SHAREPOINT to the content it had before the update. This can be done by restoring from backup, or by using the Previous Versions feature if VSS has been enabled on the volume. Regardless, if you have NOT installed this update yet, DO NOT install it yet. This update has been pulled out of our process for installing updates on our managed servers until the installer gets fixed.

Still, if your Sharepoint database instance has not been updated to WMSDE 2000 SP4, you should probably look to do that at you earliest convenience.

Ran across an unusual one this week that’s worth sharing. A site had two users who could not log in to Outlook Web Access hosted on SBS 2003. All other users could log in to OWA without issue, but these two could not. The employees do shift work and sign on to a shared workstation and only access e-mail via OWA, no Outlook client was installed on the workstation. The error encountered when trying to log in was “username or password is incorrect.” The password for the accounts were changed, and the accounts were checked to make sure they were not locked out. Attempts to access OWA from any workstation failed, internally and externally.

We checked the status of the mailbox in Exchange System Manager to make sure the mailbox had not been disconnected on either account, and the mailboxes were connecting fine. We tried to access the mailbox by creating an Outlook profile on another workstation and could access the contents of the mailbox, so we knew the mailbox was not corrupt. We tried to access the user mailbox through the Administrator’s OWA logon (after granting the Administrator account full access to the user mailbox) and as soon as we attempted to open the path to the user’s mailbox, we got a login prompt instead of access to the mailbox.

We tried to access the mailbox via Outlook Mobile Access, and got an “access denied” error after three login attempts. That prompted us to go look in the Security Log on the server, and that’s where we found the clue – we got a login failure for the user on the server. We found out that the local administrator had tried to restrict the user’s ability to log in to only one workstation in their AD account properties. In the Account tab, in the Log On To button, the only machine listed was the workstation. We added the server to the list of machines the user could log into, and we were able to access the account through OWA from all workstations.

Trying to restrict the user’s ability to log in to a single workstation is a good idea. But the actual authentication for OWA/OMA actually takes place on the server, which is where the service runs to grant access to the user. If you choose to use the Log On To feature of Active Directory to limit where the user can log in, be sure to add the server as one of those machines so network services can be accessed by the user account.

Microsoft released KB948496 which is an update that disables ALL of the Scalable Networking components that were added into Windows Server 2003 SP2 last year. The previous update only disabled two of the four components, and in practice, systems have continued to have problems when any of the Scalable Networking components were enabled.

This update could come down with Automatic Updates this month, but may not get automatically installed. If you are running SBS 2003 with Windows Server 2003 SP2, you need to install this update.