On a tip from a colleague at MS, we started to look for a possible memory leak in the system. I worked with my colleague to set up perfwiz and poolmon to try to identify the process (or processes) that were leaking. The theory was that a runaway leak could strip the server of valuable no-paged pool memory which could cause the SBCore check to fail and generate the errors and shutdown event. I must admit, perfwiz and poolmon never were my strong points, so even after we got some results back, the review didn’t come up with a smoking gun.

Then my associate found a tip that I’d not heard of before, even though I regularly modify settings where this tip was found. He opened the Task Manger on the server, selected the Processes tab, then opened Select Columns under the View menu. In here, he enabled the “Memory – Non-paged Pool” column and then sorted the Task Manager process list by that column. Sure enough, he not only quickly found the culprit, but also could sit and watch the Non-paged Pool count grow steadily right before his eyes. The service causing the problem? spoolsv.exe, the print spooler service.

A quick bit of Googling on his part ultimately led him to this post from Tek-Tips which helped him identify the root cause of the problem: HP Standard TCP/IP ports for printers on the sever. He changed the port types for the printers from HP Standard TCP/IP ports to Standard TCP/IP ports, and the server hasn’t shut down again since.

Turns out, there is a KB on this situation, too, MS KB 933999. And in going back and looking further, the server was logging the Srv 2019 errors in the event logs as well. Since we were sidetracked by the anomalous SBCore behavior, we did overlook the 2019 as a possible factor as well.

In the end, I learned two things from this. One, you can track non-paged pool memory usage in Task Manager (which really isn’t a *revelation* per se, just something that I wouldn’t have necessarily deliberately gone out and looked for), and two, memory leak issues can cause anomalous SBCore errors and the shutdown of an SBS server. The good news is that the server was shutting down “normally” because of the SBCore misfire instead of totally running out of non-paged pool memory and crashing, as MS KB 933999 points out can happen. Bottom line, customer happy, and tech support further educated!

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.

From the iPhone:

1. Press the Home button to bring up the Home screen.
2. Select Settings from the Home screen.
3. Select Mail, Contacts, Calendars from the Settings page.
4. Select Add Account.
5. Select Microsoft Exchange.
6. In the Email field, enter the e-mail address for the account.
   NOTE: this e-mail address must match EXACTLY with the default e-mail address on the account, case included. If the default e-mail address is First.Last@domain.com and you enter first.last@domain.com, you will run into issues with Calendar sync, and possibly other areas as well.
7. In the Username field, enter the domain user information in the format Domain\Username (i.e., smallbizco\jondough).
8. In the Password field, enter the account password.
9. If desired, you can change the Description field.
10. Select Next.
11. If you have a self-signed SSL certificate, you may get an “Unable to Verify Certificate” warning. Select Accept to continue.
12. In the Server field, enter the full public domain name for your server. This is the same as the web address you use to connect to Outlook Web Access. If your OWA address is https://mail.smallbizco.net/exchange, then enter mail.smallbizco.net in the Server field.
13. Select Next.
14. If you have a self-signed or unrecognized SSL certificate on the Exchange server, you will receive an “Unable to Verify Certificate” warning. Select Accept to continue.
15. Once the account has been verified, you will be able to select which information you want to synchronize: Mail, Contacts, and Calendar. Select the items you wish to synchronize to the iPhone by selecting On or Off for each item.
16. Select Save to create the account.
17. On some Exchange servers, you may be prompted after completing the account setup to configure a passcode for the device. Enter a passcode for the device and keep record of that passcode.

At this point, your iPhone is connected and ready to go. The first time the iPhone attempts to synchronize with the server, you may get the “Unable to Verify Certificate” warning again if you do not have a recognized SSL certificate. If you get this warning, select Accept. Otherwise, your selected items will sync to the iPhone from Exchange. You can go back to the home page and open the Mail app to review your mesages.

• 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.

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.

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.

We had already installed the firewall client, so I knew it wasn’t an issue with not having the client installed. I ran a monitoring scan in ISA, and saw the connections from the workstation getting denied by the SBS Internet Access rule. I checked that the Internet Users security group got created during the ISA installation, and I checked that all the users had been added to the Internet Users security group. I checked that the SBS Internet Access rule was built as it was supposed to be. All these things checked out.

I connected to the workstation and ran a manual telnet to port 110 on the POP server expecting the connection to be refused. It wasn’t. It worked as expected.

Google to the rescue again. I found this article on isaserver.org that pointed out the default configuration of the ISA firewall client in ISA 2004 is to ignore connections from outlook.exe. When this happens, ISA will treat connections from the workstation as a SecureNAT client when the connection comes from Outlook, and that is specifically denied by the SBS rules.

The workaround in the article is to change the default settings for the firewall client in the ISA Management Console so that the Firewall Client will take connections from outlook.exe and pass them through ISA as a firewall client and not a SecureNAT client, and this change allowed the workstation to pull e-mail down from the remote mail server as it had before ISA was installed.

Long term, the my client will be moving to direct SMTP delivery of e-mail. Near term, he will be configuring the POP3 connector to pull mail into Exchange instead. But it was the first time I’d worked with a setup where Outlook on the client was pulling e-mail from a remote POP mail server behind an ISA server, and it caught me by surprise. Hopefully this post will help someone else in this situation find the solution a little quicker.

First, if the Active Directory login name matches either the Full Name or shortname of a local Macintosh account, you will not be able to authenticate against active directory. What seems to be happening in this instance is that the Mac OS authentication mechanism looks first at the local user directory before looking at any remote user directories when attempting authentication. If the name entered at login matches an accoun in the local user directory, Mac OS will attempt to authenticate against that user instead of the account in the remote user directory. This means an AD account named “jane” will not authenticate against AD if there is a local account with the shortname “jane” or the long name “Jane Dough.” Even if the shortname for “Jane Dough” is “admin,” the authentication will fail.

To resolve this issue, first create another local Mac user account with a long name and short name that have no close matches to any account in Active Directory. Make that user an administrator over the local machine. Then log in with that new user and remove any local accounts with names similar to the AD login name. If the user has been using that local account for a while, you will need to take steps to move the local user profile information into another account, which is not a trivial task. Only after you delete the local account with a similar name to the AD account will you be able to authenticate against the AD account. This happens whether you join the Mac to Active Directory or not.

Second, I have seen two instances where joining a fresh Leopard (10.5) install to an SBS network have been problematic. Specifically, when you log in with AD credentials, the process can take 5 or more minutes to process the login. Unfortunately, I have not been able to troubleshoot these two instances the way I had wanted, and I have not been able to replicate the behavior on demand. I believe that there is an issue/delay with the Mac doing LDAP lookups in AD to get the account information for authentication, but I cannot be sure withouth further testing.

If anyone has seen this problem and is willing to work with me to do some more in-depth troubleshooting on the problem, please let me know. Given the number of systems that I’ve connected and that have been done following the instructions on this blog and the smallbizserver.net site, this specific behavior is very rare. But now that I’ve seen it twice, I’d like to know what’s going on and modify these instructions as needed to help prevent that problem in the future.

There are still issues, however, and those must be worked around when SP2 is installed on SBS 2003. This document serves as the road map I am using to install SP2 on SBS servers. Note that I do not guarantee that following this step-by-step process will result in a trouble-free installation. But this is the process I have been following and have not had any issues on client systems.

Install SP2:

1. Check for available disk space. If you don’t have at least 2GB free on C:, you could run into space issues. One option is to have the uninstall folder on a different drive/partition (discussed below).
2. Grab a System State Backup. Easiest way to do this is run ntbackup, select System State as the item to back up, and save it to a file on disk. Don’t put it on C: if you can avoid it.
3. Restart the SBS 2003 server. This is not required, but it falls in with my general recommendation to restart a server prior to installing any updates, so if there is an issue that would keep the server from coming up cleanly, it will be identified prior to the installation of any updates or service packs.
4. Disable on-access anti-virus scanning of the server. This can be restored once the service pack installation is complete.
5. Install SP2. When prompted for an uninstall folder, consider putting on a separate partition or volume. This can help with space on C: and make future cleanup of the Windows folder a bit easier if you still want to be able to do an uninstall of SP2 later.
6. Reboot the server when finished.

ISA 2004:

If you have ISA 2004 installed on the server, download and install ISA 2004 SP3.

Clean up Help and Support:

1. Open a Command Prompt.
2. Enter the following command exactly as shown and press Enter:
   %windir%\pchealth\helpctr\binaries\HelpSvc.exe /regserver /svchost netsvcs /RAInstall
3. Enter the following command exactly as shown and press Enter:
   %windir%\pchealth\helpctr\binaries\HSCUpd.exe -i %windir%\pchealth\helpctr\binaries\hscmui.cab
4. Enter the following command exactly as shown and press Enter:
   %windir%\pchealth\helpctr\binaries\HSCUpd.exe -i %windir%\pchealth\helpctr\binaries\hscsp_l3.cab
5. Enter the following command exactly as shown and press Enter:
   services.msc
6. In the Services Control Panel, look for the Help and Support service. Start the service if it is not started.
7. From the Start menu, open the Help and Support item. Confirm that the Help and Support tool launches correctly.

Clean up Scalable Networking Settings:
Note – this section provides instructions for modifying the registry. MIcrosoft gives all kinds of warnings about bad things that can happen when you edit the registry incorrectly. They’re not kidding. If you do this incorrectly, you could put your server into a non-bootable configuration. Do this at your own risk.

1. Open the Registry Editor (Start -> Run -> regedit).
2. Expand HKEY_LOCAL_MACHINE -> SYSTEM -> CurrentControlSet -> Services -> Tcpip -> Parameters.
3. Look for the EnableRSS value.
1. If the EnableRSS value exists, change its data to 0.
2. If the EnableRSS value does not exist:
1. Right-click on Parameters under Tcpip and select New -> DWORD Value.
2. Name the value EnableRSS.
3. Change the Data in ENableRSS to 0.
4. Look for the EnableTCPA value.
1. If the EnableTCPA value exists, change its data to 0.
2. If the EnableTCPA value does not exist:
1. Right-click on Parameters under Tcpip and select New -> DWORD Value.
2. Name the value EnableTCPA.
3. Change the Data in ENableTCPA to 0.
5. Look for the EnableTCPChimney value.
1. If the EnableTCPChimney value exists, change its data to 0.
2. If the EnableTCPChimney value does not exist:
1. Right-click on Parameters under Tcpip and select New -> DWORD Value.
2. Name the value EnableTCPChimney.
3. Change the Data in ENableTCPChimney to 0.
6. Look for the DisableTaskOffload value.
1. If the DisableTaskOffload value exists, change its data to 1. (It very likely will not exist.)
2. If the DisableTaskOffload value does not exist:
1. Right-click on Parameters under Tcpip and select New -> DWORD Value.
2. Name the value DisableTaskOffload .
3. Change the Data in DisableTaskOffload to 1.
7. Close the Registry Editor.
8. Restart the Server.

Confirm Normal Operation:

After restarting the server, check to make sure clients can access the server, Outlook can interact with Exchange, clients can access the Internet, etc. Also go through the event logs and look for any unexpected or unusual errors or warnings. After following the steps in this document, the interaction between the workstations and the server should continue as it had prior to the installation of SP2.

Notes:

Information in this post came from a number of sources at Microsoft. Where possible, KB articles referencing the specific changes have been noted below. In one case, the best reference for the change came from the SBS Best Practice Analyzer and is noted as such. Several of the referenced KB articles make reference to a hotfix. In my experience, the workaround listed in the KB article provides a sufficient resolution without the need to call in and request the hotfix or worry about adding to the installed hotfix table on the server.

Help and Support fix: http://support.microsoft.com/kb/937231/
EnableRSS fix: http://support.microsoft.com/kb/936594 (Step 3, Method 2)
EnableTCPA fix: http://support.microsoft.com/kb/936594 (Step 4)
EnableTCPChimney fix: Referenced in the SBS BPA with a command-line process, and discussed in http://support.microsoft.com/kb/912222
DisableTaskOffload fix: http://support.microsoft.com/kb/904946/

Note: Before you start, make sure the local user name on the Macintosh does not match the Active Directory login name that will be used to access resources on the SBS network. This includes both the long name and the short name for the local Macintosh account. If the local Mac account for Jane Dough has a long name of “Jane Dough” and a short name of “jane” and the Active Directory account for the user is “jane,” you will not be able to authenticate to active directory properly. See “ Outstanding Macintosh Connectivity Issues” for more details.

Phase 1 – Network Configuration

If the SBS 2003 server is set up properly and the Macintosh is getting its network information from DHCP, the network settings should be ready to go out of the box, so to speak. These steps will confirm proper network settings on the Macintosh to work with the SBS network.

1. Open the System Preferences application from the Dock or from the Apple Menu.
2. Select the Network panel from the System Preferences application.
3. Review the settings for the active network connection. You should see settings that match the values expected for the SBS network. You will also see the DNS server address listed (but grayed out) as well as the internal domain name in the Search Domains field. If these values to not match your SBS network, make the necessary adjustments. The DNS server should point to the internal IP address of your SBS server, and the Search Domains field should contain the internal domain name of the network (i.e., domainname.local).
4. Click the Advanced button in the Network pane.
5. Click the WINS tab.
6. Select the correct NetBIOS domain name from the Workgroup drop down list. The WINS server address should already be populated and be the internal IP address of the Server.
7. Click OK and then Apply in the main Network panel.
8. Close System Preferences.
9. Open the Macintosh HD icon and select the Application icon from the navigation tree.
10. Open the Utilities folder and scroll down to the Terminal icon.
11. Open the Terminal application. Ping the SBS server by its short name (i.e., if the fully-qualified domain name for the server is servername.domainname.local, ping servername).
12. If the Mac is getting proper DNS resolution, the internal IP of the address will respond to a ping. Note that you will need to press Control-C to stop the ping command. If you do not get the proper IP address of the server from the ping command, go back and review the network setup steps.
13. Close the Terminal application.

Phase 2 – Accessing Server Resources

Mac OS 10.5 can access shares from the SBS server via the SMB (server message block) protocol like earlier versions of OS X. There are some key differences, however. You must still disable SMB Signing on the server in order for the Mac to be able to read and write files to the server share (see  this post for instructions on how to disable SMB signing on the server). If you have Windows 2003 Service Pack 2 on the server, you also need to make sure that all scalable networking components are disabled as well. See MS KB936954 and the step 4 in this post on the Official SBS Blog for instructions on disabling the scalable networking components.

The key difference between Leopard and previous versions of the Mac OS are that you will be able to authenticate against the server and open shares on the server even if SMB signing is not disabled. However, you will not be able to read or write files in the server shares. In previous versions of the OS, you would not be able to authenticate against the server at all if SMB signing were still enabled.

Once you have disabled SMB signing on the server, follow these steps to access the shares on the server from the Mac.

1. From the Finder, select Connect to Server from the Go menu, or press Command K to open the Connect to Server window.
2. Enter the server path as smb://servername in the Server Address field and click Connect.
3. You will be prompted to enter your domain username and password to access the share. Enter the username in the domainname\username format.
4. After you authenticate, you will be presented with a list of shares on the server that you may connect to. Select the share and click OK.
5. Another key difference in Leopard from previous versions of the Mac OS is that the network share no longer appears as a mounted disk volume on the Mac. Instead a new window will open to the share, and the server will appear under the Shared area of the navigation tree with an Eject symbol next to it. If you close the window and need to get back to the share, you can click on the server name in the navigation tree and see a list of the shares available on the server.
6. In the Connect to Server window, you can enter the full path to a share in the format smb://servername/sharename. You can save the path in the Favorite Servers list by clicking the plus sign next to the Server Address field. You can also open a folder on the share directly by using the format smb://servername/sharename/foldername.
7. When you click Connect in the Connect to Server window, a new window will open to the path specified in the Server Address window. If you selected a folder under a share, that folder window will open directly.

Phase 3 – Joining Active Directory

By default, you will have to enter your domain username and password every time you access a server resource when that resource is not connected to the Mac (i.e., right after bootup, after a share has been “ejected”, or if a network connection drops the connection to the server). By joining the Macintosh to Active Directory, you can log into the Mac with your Active Directory user credentials and not have to enter them every time you access a shared resource. To be able to log in to the Mac with Active Directory credentials, follow these steps.

1. From the Utilities folder in the Applications folder, open the Directory Utility application.
2. Once the application opens and finishes the process of detecting directory servers on the network, click the Show Advanced Settings button.
3. When the Advanced Settings appear, click the Services icon.
4. Click the lock to get access to the panel. You will be prompted for credentials. Enter your Macintosh username and password, then click OK.
5. Double-click on the Active Directory line to open the Active Directory configuration.
6. Click on the Show Advanced Options triangle.
7. Enter the internal domain name in the Active Directory Domain field (i.e., domainname.local).
8. Change the name of the Mac to a shorter name in the Computer ID field if desired.
9. Turn on the Create mobile account at login checkbox.
10. Select the Administrative tab.
11. Turn on the Prefer this domain server checkbox and enter the fully-qualified domain name of the SBS server (i.e., servername.domainname.local).
12. Turn on the Allow administration by checkbox.
13. Click Bind to join the Macintosh to the domain.
14. Enter the domain administrator username and password when prompted. The Macintosh will be placed in the Computers container by default. This can be changed in Active Directory later if needed.
15. Once the join process is complete, you will see both the Active Directory Forest and Active Directory Domain fields populated.
16. Confirm that the Active Directory checkbox is enabled in Directory Utility and close the application.
17. Open System Preferences and click the Accounts icon.
18. Click the lock to make changes and enter the password for the local Mac account.
19. Click on the Login Options icon in the navigation tree.
20. Set Automatic Login to Disabled.
21. Close System Preferences.
22. Log out of the Mac account by selecting Log Out from the Apple menu. You do not need to restart the Mac to be able to log in with your Active Directory credentials.
23. When you get the login screen, click Other.
24. Enter your Active Directory credentials as domainname\username.
25. You will be prompted to create a mobile account. Click Create Now.
26. Once login completes, open System Preferences and open the Accounts pane.
27. Click the lock to make changes.
28. When you are prompted to enter an administrator credentials, you will need to enter information for the local Macintosh account. You will need to enter the short name as the account name. If you are not sure what the short name is, log back in as the Mac user and look for the name of the home folder. The home folder is named with the short name of the account.
29. After you enter the authentication information, turn on the Allow user to administer this computer checkbox.
30. You will get a message that you need to log out and log back in for the settings to take effect. Click OK.
31. Log out and log back in with the Active Directory credentials.
32. Open a new Finder window and select the server name in the Shared section of the navigation tree. All of the shares on the server will appear and can be selected from here. You can also use the Connect to Server method described earlier in this document to connect. The difference is that you will not be prompted to enter a username and password when you enter the network resource you wish to use.
    A version of the document complete with screen shots will be available at smallbizserver.net in the near future. 

But there’s still one thing that you really, really need to do when working with image backups – System State Backup. This is a special backup process that backs up Active Directory and other key server information such as the registry and other Windows configuration settings. I can’t count the times I’ve run across a situation that would have been easily resolved by restoring a system state backup. AD corruption, GPO corruption, etc. Sure, you could restore the entire C: image with your imaging tool, but then you lose any other data that was added to the drive following the backup.

But there are also some cases where an image-based backup fails to do its job. I spoke briefly with someone today who was having trouble because the image-based backup tool he was using was not correctly restoring the data to the system partition and the system was not bootable. He had gone around and around with the vendor of the backup software, and they could not get it to work. My first question to him was “do you have a system state backup?” Unfortunately, no. If he’d had a system state backup, he could have done a core install of the server OS, restored the system state, then gone into the backup software and done a file-based restore of the remaining contents of the system partition.

A system state backup can be captured very easily from ntbackup on a server, and can be saved to a file on local disk or on a share to another machine on the network. Either way, the backup file should be stored someplace that it can be easily accessed in case a restore is needed.

1. The SBS server is a healthy setup and is configured according to best practices (DHCP running on the server, private IP address range on the internal network, etc.).
2. The Macintosh has been updated with the latest available security patches from Apple.

Note: Before you start, make sure the local user name on the Macintosh does not match the Active Directory login name that will be used to access resources on the SBS network. This includes both the long name and the short name for the local Macintosh account. If the local Mac account for Jane Dough has a long name of “Jane Dough” and a short name of “jane” and the Active Directory account for the user is “jane,” you will not be able to authenticate to active directory properly. See “ Outstanding Macintosh Connectivity Issues” for more details.

Phase 1 – Network Configuration

1. Open the System Preferences either by selecting the System Preferences icon in the Dock or by selecting System Preferences from the Apple menu.
2. Click the Network icon under Internet & Network.
3. Confirm that the Macintosh has an active network connection in Network Status. Double-click on the active network adapter.
4. Confirm that the network settings provided by the DHCP server are correct. The DNS Servers field will be empty and should remain that way (the DHCP server provides the DNS server entries and those are not displayed in the interface).
5. Turn off IPv6 by clicking on the Configure IPv6 button and selecting Off from the available options.
6. Enter the internal domain name in the Search Domains field. If the internal domain is .local, no other configuration is necessary in Mac OS 10.4.
7. Click Apply Now, then close the Network panel.
8. Open the hard drive and open the Applications folder by selecting the Applications icon in the navigation tree.
9. Open the Utilities folder in the Applications folder.
10. Open the Terminal application in the Utilities folder.
11. Ping the SBS server by fully-qualified domain name (i.e., servername.domainname.local) to confirm proper DNS lookup for the FQDN. [Note: you will need to press Control-C to stop the ping process in the Terminal window.]
12. Ping the SBS server by NetBIOS name (i.e., servername) to confirm proper DNS lookup for the nodename.
13. Quit the Terminal application after confirming proper DNS lookup. At this point, you should have the correct network settings needed to communicate with the SBS server via DNS and IP.

Phase 2 – Active Directory Configuration

1. Open the Directory Access application in the Utilities folder.
2. Click the lock in the lower left corner of the Directory Access window to make changes to the configuration.
3. Enter the password for the local Macintosh account to open the Directory Access settings.
4. Select SMB/CIFS from the list and click Configure.
5. Enter the NetBIOS domain name for the Workgroup (i.e., domainname instead of domainname.local) and the internal IP address of the SBS server as the WINS server, then click OK.
6. Turn on the checkbox for Active Directory.
7. With Active Directory selected, click Configure.
8. Click the Show Advanced Options arrow to display the full set of options.
9. Enter the internal domain name (i.e., domainname.local) in the Active Directory Domain field.
10. Turn on the Create mobile account at login checkbox.
11. Turn off the Use UNC path from Active Directory to derive network home location checkbox.
12. Click the Administrative tab.
13. Turn on the Prefer this domain server checkbox and enter the fully-qualified domain name of the server (i.e., servername.domainname.local).
14. Turn on the Allow administration by checkbox.
15. Change the name of the Macintosh in the Computer ID field if necessary (the default name of the Macintosh may be too long).
16. Click Bind to join the Macintosh to Active Directory.
17. When prompted, enter the domain administrator username and password. Note the default location of the Macintosh object will be in the Computers container of Active Directory. This location is fine and can be modified later in Active Directory.
18. Click OK and the Macintosh will join the domain.
19. When the domain join completes, quit the Directory Access application.
20. Open the System Preferences and select the Accounts icon under System.
21. Click the lock in the lower left hand corner of the Accounts panel to make changes. Make note of the Short Name of the default Macintosh account in the Accounts page. [Note: If this short name is the same as the Active Directory username, you will not be able to log in to Active Directory.]
22. When the Accounts panel is unlocked, click the Login Options icon.
23. Turn off the Automatically log in as checkbox.
24. Close the Accounts panel.
25. Reboot the Macintosh. When the Macintosh comes up, you will see an icon for the default account in the login pane. Wait until another icon named “Other” appears to get the Active Directory login.
26. Click the Other icon when it appears and enter the Active Directory login information as domainname\username.
27. When prompted to create a portable home directory, click Yes.
28. Open System Preferences and select the Accounts icon under System.
29. Note the Active Directory account now appears under My Account. Click the lock to make changes.
30. When prompted for an administrator’s name and password, enter the Short Name of the default Macintosh account that you noted earlier and the password for that account.
31. Turn on the Allow user to administer this computer checkbox.
32. Close System Preferences and log out.
33. Log back in using Active Directory credentials and now you will have full access to the Macintosh.

Phase 3 – Accessing Server Resources

1. From the Finder, select the Go menu and select Connect to Server.
2. In the Connect to Server window, enter smb://servername and click Connect to get a list of shares from the server.
3. You may get an error saying the computer could not connect to the server because the username or password is not correct. This is either because SMB signing has not been disabled on the server or because Windows Server 2003 SP2 has been installed and the scalable networking options have not been disabled. To learn how to disable SMB signing on the SBS server, see How to Disable SMB Signing in SBS 2003. To disable the scalable networking additions of Service Pack 2, see KB 936594 and follow Step 4 in this post from the SBS blog.
4. If communication is set properly on the SBS server, you will see a list of available shares. Select the desired share and click OK.
5. Once you select the share, the share will open a new window on the desktop. It will also appear as a volume in the navigation tree.
6. In the Connect to Server window, you can also specify the full path to a share (i.e., smb://servername/users) and you can save paths on the network to the favorites list by clicking the plus sign next to the server address when you have the path entered correctly.

Other Resources:
Automounting network shares on a Macintosh at logon time:
http://www.smallbizserver.net/Articles/tabid/266/articleType/ArticleView/articleId/97/Automounting-SMB-Shares-on-a-Macintosh.aspx (with screen shots)
http://simultaneouspancakes.com/Lessons/2005/11/27/automounting-sbs-shares-on-a-macintosh/ (text only)

The Alternative to RWW for the Macintosh:
http://www.smallbizserver.net/Articles/tabid/266/articleType/ArticleView/articleId/84/The-alternative-for-RWW-for-Mac.aspx

A version of this document with screen shots will be available at smallbizserver.net.

This behavior has been noted by several folks in the community, but it’s been a hit and miss prospect to figure out what’s going on. Well, at the time you’re trying to get updates installed for a client, you’re not really all that concerned about the “why” of it all. You just really want to get the server back to a point where you can connect in to it again without having to go onsite. And given that we manage servers all across the US, going on site just isn’t an option.

Some folks have taken to using third party remote control tools to access their servers rather than relying just on RDP. Still it’s possible that these services, like the TS service, get stopped when the server restart command is issued and a remote connection still isn’t possible.

Fortunately, with SBS, we still have an option available to us to help get the server restarted so we can get back in: Remote Web Workplace. In all of the cases we encountered this weekend, it was only the TS service that got shut off, so we were able to log in to RWW, connect to a workstation at the site, and get the server restarted from there.

But wait, that’s the real magic of this post – how to remotely restart the server when you cannot connect to it by other methods, but it’s still alive on the network. Here’s how:

1. Log in to the workstation via RWW as the domain administrator.
2. Verify that the server is actually “alive” by connecting to the server with the Computer Management console:
1. Right-click on My Computer on the workstation and select Manage.
2. Right-click on Computer Managemen (Local) and select “Connect to another computer.”
3. Enter the name of the server and click OK.
4. If the connection succeeds and you can browse the event logs on the server, you’ve got a good connection.
5. From within the Computer Management console, you may be able to restart the service that got stopped, in this case the Terminal Server service. expand Services and Applications and click on Services to see the list of services. Find the service in question and see if you can start it. This may still not get you what you want, so you may need to proceed with the steps to restart the server.
3. Open a command prompt on the workstation.
4. Type “shutdown -r -m \\servername -t 5″ (without the quotes) and press Enter. This will restart the server servername after a 5 second delay.
5. When you get kicked out of the RWW session to the workstation, you know the server has finally restarted.

There are lots of things you can do with the shutdown command. Type “shutdown /?” to see what the various options are.

If you encounter this problem and do NOT have an SBS server (and therefore no RWW to access another workstation), you could make a VPN connection to the network and remotely control another workstation from there. The key thing is to make sure that you are authenticated as the domain administrator when you issue the shutdown command or you’ll get access denied errors and still won’t be able to do anything. Or if you have remote access into a workstation on the network using some other means, the same shutdown option will still work.

To help protect account credentials, as well as e-mail contents, IMAP can be set up over SSL, which encrypts the entire transaction process, not just username and password. The iPhone and other devices can be easily set up to use IMAP over SSL, but you have to first set up the Exchange server on SBS to provide the secure mail transport. This document covers this implementation with SBS 2003 Premium running ISA 2004. If you have a firewall running in front of ISA, you will need to configure the port forwarding in that firewall as well, but steps for doing that are outside the scope of this document.
Follow these steps to enable and configure IMAP using SSL over ISA 2004.

1. Enable the IMAP service on SBS 2003
   1. Open the Services control panel (Start -> Run -> services.msc or Start -> All Programs -> Administrative Tools -> Services)
   2. Scroll down to find Microsoft Exchange IMAP4.
   3. Double-click on the service to open the properties.
   4. In the General tab, change the Startup Type to Automatic.
   5. Click Start to start the IMAP service.
   6. Click OK to close the Properties window.
   7. Confirm that the IMAP service is started and set to Automatic in the services list.
2. Configure IMAP services in Exchange
   1. Open Exchange System Manager (Start -> All Programs -> Microsoft Exchange -> Exchange System Manager).
   2. Expand Servers, your server name, Protocols, and IMAP4.
   3. Select the Default IMAP4 Virtual Server, right click and select Properties.
   4. Select the Access tab, then click on the Certificate button under “Secure communication”.
   5. Go through the Web Server Certificate Wizard. Click Next to start.
   6. Select “Assign an existing certificate” and click Next.
   7. Select the public certificate name and click Next.
   8. Verify the proper certificate has been selected and click Next.
   9. Complete the wizard by clicking Finish.
   10. Select the “General” tab and click the “Advanced” button.
   11. Confirm the ports for IMAP are 143 and 993 (for SSL) and the IP address is “All Unassigned”.
   12. Click OK to close the Advanced dialog box, then click OK to close the properties of the IMAP4 Default Virtual Server.
3. Enable SSL connections for the SMTP service
   1. Open Exchange System Manager.
   2. Expand Servers, your server name, Protocols, SMTP, and select the Default SMTP Virtual Server.
   3. Right-click on the Default SMTP Virtual Server and select Properties.
   4. Select the Delivery tab, then click Advanced.
   5. In the “Fully-qualified domain name” field, enter the full public DNS name of the server and click OK.
   6. Select the Access tab and click the Certificate button under “Secure communication”.
   7. Select “Assign an existing certificate” and click Next.
   8. Select the public certificate name, and click Next.
   9. Confirm the correct certificate selection and click Next.
   10. Click Finish to complete the wizard.
   11. In the Access tab, click Communication under “Secure Communication.”
   12. In the Security dialog box, ensure that the “Require secure channel” checkbox is turned off.
   13. Click OK to close the Security dialog, then click OK to close the Default SMTP Virtual Server properties.
4. Configure ISA 2004 to accept connections for IMAP SSL
   1. Open the ISA 2004 Management Console.
   2. Select Firewall Policy in the left pane, then select the Tasks tab in the right pane.
   3. Click the Create New Server Publishing Rule task to start the wizard.
   4. Name the new rule and click Next.
   5. Enter the internal IP address of the SBS server as the Server IP Address and click Next.
   6. In the Select Protocol page, select IMAPS Server from the drop-down list and click Next.
   7. In the IP Addresses page, select the External checkbox and click Next.
   8. Review the settings and click Finish to complete the wizard.
   9. Click Apply to accept the updates, then close the ISA 2004 Management Console.

At this point, you are able to make SSL connections to both the IMAP4 service as well as the SMTP service.

This post is now available with screen shots and in PDF format at smallbizserver.net. Also, check out Tim’s post on actually configuring the iPhone. However, you should set IMAP to use SSL on the iPhone. Not sure why it didn’t work for him…

Because of the release of the iPhone, there has been an increase in interest in configuring IMAP and POP3 services on SBS servers. In this author’s opinion, providing access to e-mail via IMAP is better than POP3. The approach of IMAP more closely emulates how Exchange provides e-mail services in that messages are maintained on the server, and the IMAP client only pulls down what is needed. There are still security issues with IMAP, however, in that the default protocol still transmits the username and password information across the internet in clear text, and even though fewer sniffers are trained on IMAP ports to try and discover account credentials, the risk is still there.

To help protect account credentials, as well as e-mail contents, IMAP can be set up over SSL, which encrypts the entire transaction process, not just username and password. The iPhone and other devices can be easily set up to use IMAP over SSL, but you have to first set up the Exchange server on SBS to provide the secure mail transport. This document covers this implementation with SBS 2003 Standard and no ISA. You will need to configure your firewall to forward the appropriate ports to the SBS server, which is beyond the scope of this document.

Follow these steps to enable and configure IMAP using SSL.

1. Enable the IMAP service on SBS 2003
   1. Open the Services control panel (Start -> Run -> services.msc or Start -> All Programs -> Administrative Tools -> Services)
   2. Scroll down to find Microsoft Exchange IMAP4.
   3. Double-click on the service to open the properties.
   4. In the General tab, change the Startup Type to Automatic.
   5. Click Start to start the IMAP service.
   6. Click OK to close the Properties window.
   7. Confirm that the IMAP service is started and set to Automatic in the services list.
2. Configure IMAP services in Exchange
   1. Open Exchange System Manager (Start -> All Programs -> Microsoft Exchange -> Exchange System Manager).
   2. Expand Servers, your server name, Protocols, and IMAP4.
   3. Select the Default IMAP4 Virtual Server, right click and select Properties.
   4. Select the Access tab, then click on the Certificate button under “Secure communication”.
   5. Go through the Web Server Certificate Wizard. Click Next to start.
   6. Select “Assign an existing certificate” and click Next.
   7. Select the public certificate name and click Next.
   8. Verify the proper certificate has been selected and click Next.
   9. Complete the wizard by clicking Finish.
   10. Select the “General” tab and click the “Advanced” button.
   11. Confirm the ports for IMAP are 143 and 993 (for SSL) and the IP address is “All Unassigned”.
   12. Click OK to close the Advanced dialog box, then click OK to close the properties of the IMAP4 Default Virtual Server.
3. Enable SSL connections for the SMTP service
   1. Open Exchange System Manager.
   2. Expand Servers, your server name, Protocols, SMTP, and select the Default SMTP Virtual Server.
   3. Right-click on the Default SMTP Virtual Server and select Properties.
   4. Select the Delivery tab, then click Advanced.
   5. In the “Fully-qualified domain name” field, enter the full public DNS name of the server and click OK.
   6. Select the Access tab and click the Certificate button under “Secure communication”.
   7. Select “Assign an existing certificate” and click Next.
   8. Select the public certificate name, and click Next.
   9. Confirm the correct certificate selection and click Next.
   10. Click Finish to complete the wizard.
   11. In the Access tab, click Communication under “Secure Communication.”
   12. In the Security dialog box, ensure that the “Require secure channel” checkbox is turned off.
   13. Click OK to close the Security dialog, then click OK to close the Default SMTP Virtual Server properties.

At this point, you are able to make SSL connections to both the IMAP4 service as well as the SMTP service.

A PDF version of this post complete with screenshots is also available at smallbizserver.net. Also, check out Tim’s post on actually configuring the iPhone. However, you should set IMAP to use SSL on the iPhone. Not sure why it didn’t work for him…

Folks, please don’t do this.

I don’t care that KB 320202 gives instructions on how to remove and reinstall IIS on a server running Exchange. If you scroll down to the bottom of that KB, you might notice that Small Business Server is NOT listed in the “Applies To” section. Yeah, yeah, yeah, I know that most of the time we say that SBS is the “same as” Windows 2003 Server Standard, but in this case we are most decidedly NOT.

SBS has so much more tied in with IIS than just Exchange, so if you did decide to remove/reinstall IIS, you’re going to break a whole bunch of things: Backup, Monitoring and Reporting, Companyweb, Remote Web Workplace, ConnectComputer. KB 320202 doesn’t address those tools at all, just Exchange.

If you end up getting your hands on a box that has already had IIS removed and reinstalled, you might be able to fix several things by reinstalling the Administration Tools in the SBS integrated setup, but even that is going to be a longshot at best.

If you’re reading this before you remove and reinstall IIS, good. STOP NOW! Don’t do it. Troubleshoot the actual errors you’re getting and find and fix the problem. Ignore KB320202. And should you be in one of those rare cases where someone affiliated with Microsoft has suggested that you remove and reinstall IIS, please let me know immediately. Or let Marina know over at smallbizserver.net. Or find someone in the SBS community to get a second opinion with. But DON’T UNINSTALL IIS on your SBS box without getting at least a second or third opinion. Please. Chances are, you’ll deeply regret it if you do.

I was setting up a workstation for a client and there were two profiles that they needed “kept” as part of the ConnectComputer wizard process. No problem, handles that like a dream. Except both came back with the dreaded “The following user settings are private” error. There is a Microsoft KB article ( KB886210) on this error, but buried at the bottom is the real meat of the resolution – how to find the actual file/folder that’s tripping up the wizard.

Fortunately, you can look in the SBSNetSetup.log file (stored by default in the C:\Program Files\Microsoft Windows Small Business Server\Clients folder on the workstation) and scroll down to the end of the file to find the file or folder that’s tripping up the wizard. Usually (I recall this now, mind you) it’s a file somewhere in the Temporary Internet Files that can be deleted to fix the issue, but the log file will tell you specifically which file it is.

What the KB doesn’t mention, however, is that there may be more than one file that will interrupt the wizard, and you won’t know what it is until you hit the next run of the wizard. Don’t panic, though, as you simply check the SBSNetSetup.log file after each failure of the wizard to find the next file that is causing problems. Once you clear all the files, the wizard will complete as expected.

I wish I knew what was causing this to happen (at least in my world) much more frequently of late, but now that I remember the issue enough to blog it, it should cause less constarnation in the future.

A System error has occurred while processing your request. Please try again. If the problem persists, contact your administrator.

Outlook Web Access worked fine on the server, as did the full Outlook client. It was just OMA that was having fits.

I got in and looked at the event logs on the server (after verifying that other accounts got the same error with OMA) and found an MSExchangeOMA 1503 error. The full text of the message is really verbose, so I won’t paste it all here. I dug around Google and eventid.net, but didn’t really find anything that pointed to a fix.

Finally contacted another resource who pointed me to the solution. Turns out that at some point during the migration, the homeMTA attribute for the user accounts got munged. The homeMTA attribute value looked similar to this:

CN=Microsoft MTA\0ADEL:111e6f10-7865-41da-8c30-8d249bf3a050,CN=Deleted Objects,CN=Configuration,DC=domain,DC=local

Well, the Deleted Objects container was a clue that it wasn’t pointing to the correct place. I created a new test user on the server and looked at the homeMTA attribute value for that user, which was:

CN=Microsoft MTA,CN=LEONSERVER,CN=Servers,CN=first administrative group,CN=Administrative Groups,CN=LS,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=local

After changing the homeMTA attribute on the Administrator account, OMA worked fine. All user objects that were present prior to the migration had incorrect values for homeMTA, and I adjusted them all. Case closed, OMA working.

Where do you find the homeMTA attribute? In ADSIEDIT. ADSIEDIT is not for the faint of heart. It’s actually more invovled that registry diving. But if you encounter this error, the fix is relatively straightforward.

First, you need to install the Support Tools package on the server. In an SBS install, the Support Tools installer is on CD #2 in the \SUPPOR\TOOLS folder, and the installer is named SUPTOOLS.MSI. Once you install that, you can access ADSIEDIT by running adsiedit.msc from a command prompt. Expand the Domain node, and browse into DC=domain,DC=local -> OU=MyBusiness -> OU=Users -> OU=SBSUsers. Right-click on a user object and select Properties. Then scroll down the list of attributes until you find the hostMTA entry. Find the user that will have the correct value and copy the value, then paste it into the user that has problems. Apply the changes and OMA should immediately work.

I was working with someone who was having a number of problems on his new SBS box. We got a number of them fixed, then we were trying to join a workstation to the domain. He had tried many variations of this previously, but all had failed. Once we resolved his IIS issues, we decided to see what would happen with the ConnectComputer wizard.

Problem 1: You can’t get to the ConnectComputer wizard. We continually got a “page cannot be found” error when trying to connect to http://server/conectcomputer, just like the Add Client Workstation wizard says to do. We could access the page at http://internalIP/connectcomputer, but this doesn’t always work, either. We were finally able to get the page to load and at least get through the main portion of the wizard using https://server/connectcomputer/

Problem 2: The ConnectComputer wizard encountered errors and could not complete. This happened at the end of the wizard as it was trying to change network settings to initiate the reboot that would join the machine to the domain, etc., etc., etc. We looked in the client-side log for the ConnectComputer wizard (which is in C:\Program Files\Microsoft Windows Small Business Server\Clients\SBSNetSetup.log, by the way) and found the following error in the log:

NetJoinDomain() failed [1727]

Google found only a few posts about this specific error, mostly having to do with trying to join a workstation over a VPN when ISA is involved. Well, this server had ISA installed, but this is a local workstation and not over a VPN. Also worth noting is that it’s the first workstation to join the domain. But I digress. We followed the advise about turning off Strict RPC checking in ISA (which I regularly forget to do and hate that I have to in the first place) but that had no effect. Just when I was about to punt, I discovered that SP2 had been installed on the box.

Yes, the dreaded Windows 2003 Server SP2. The one that has actually been causing more issues than MS cares to admit right now. And the only reason he installed it when he built the server? Because it was listed in Microsoft Updates through the web, and since it’s up there, it must be safe to install, right? In this case, I certainly wouldn’t have installed it, but that’s just me. Oops, digressing again.

So I reviewed the Official SBS Blog for stuff about SP2 and found the note on the Receive Side Scaling. The server had broadcomm NICs (which have issues in themselves), so I went into the NIC settings through Network Connection Properties and disabled Receive Side Scaling on both the internal and external NIC. Viola! ConnectComputer not only ran successfully, but we were able to access it through http://server/connectcomputer without SSL.

I’ll be darned if I can understand exactly why changing this setting when SP2 and ISA are on the box had this type of impact on local networking, but as soon as I changed it, everything worked. I liken this to the other bizarre resolution where changing the internal name on a security group allows the Connect to the Internet wizard to run correctly (look down at the last entry in the thread for the real resolution) – can’t explain fully why it works, but it does.

Moral of the story – read everything about SP2 on the SBS blog and even if you think you may not be affected, look at each one of the items listed there. Or don’t put SP2 on any of your boxes just yet. The latter is the direction I’m taking when I have an option.