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

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

And if you do take the time to download and test the software, please make the effort to provide feedback to the development team. This could include bugs, feature suggestions, or compliments on implementations that have been done correctly. There may not be much that can be done with the product in terms of changes at this stage, but if you do find something that causes problems and do not report it, it may not get reported by anyone else, and the team really does want that feedback. But whatever you do, please do not expect to use this version in production. If and when subsequent releases of the public preview are made, there will not be an “upgrade” process to move from one public preview build to another build.

More thoughts about SBS 2008 can be found at OnQ under the SBS 2008 category.

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.

Fear not, the maximum # of users/devices that will be licensed with SBS 2008 is still 75. Yes, Microsoft has targetted SBS 2008 for the 1-50 user market and EBS 2008 for the 50-250 user market, but the technical limitations on the maximum number of users/devices has not changed. You can find the 75 figure listed at http://www.microsoft.com/windowsserver/essential/products.mspx and http://www.microsoft.com/windowsserver/essential/choose-solution.mspx.

The serious IT Professional knows that the number of licenses is not the only factor in determining which product will be the best solution for a particular company. Some 50-75 user companies will do just fine on SBS 2008. I know of a couple of 20 user companies (and smaller) that EBS 2008 would be an excellent match for. It all boils down to need and resource availability. Will you be able to run a 75-user company on an SBS 208 box that was designed for 15-20 users? Yes, but it may not perform as well as expected. Would the three-server implementation of EBS 2008 be complete overkill for some 60 user businesses? Absolutely.

With EBS in the product options now, there are more considerations to make when planning an SBS/EBS implementation for a business. The maximum number of user/device licenses is simply one consideration. There will be many, many others.

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.