Windows Small Business Server 2011 Standard Top Support Issues

At this time these are just early early results of support cases and what you see here represents a single case each.  Thus it's not a valid indicator at this time of what the real top issues may be.

1.  Migration hung at AD replication - Error message - AD replication is taking longer than expected.

This is an indication that there are underlying issues with Active Directory that you should look into first.   My recommendation is to proactively run the IT Health Scanner tool (http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=10116) and review all the tips for success - http://msmvps.com/blogs/bradley/archive/2010/12/23/sbs-2011-migration-keys-to-success.aspx.



2.  Exchange 2010 - Insufficient Permissions to perform Exchange Administration Tasks.

    Client was performing a migration and could not complete the migration of mailboxes.  Turns out the permissions on the mail store and public folders were set incorrectly.  Permissions were reset using ADSIedit and migration completed.

    This is how you fix it:

    ADSIEdit could be run from any server. If they are in the same domain, then it will not matter. The same information will be displayed, unless there could be any AD replication issues.

    In Configuration partition, go to:
Service > Microsoft Exchange > expand your Exchange organization > Administrative groups > First Administrative Group (This is a default AG name for legacy version, unless any other changes made otherwise) > Folder Hierarchies > CN=Public Folders

Check On the Security tab of properties of both "Folder Hierarchies" & "CN=Public Folders" When we click on Advanced button, we should have "Allow inheritable permissions..." checkbox checked.

 Then do the same thing again for the Mailbox Store (cite: http://social.technet.microsoft.com/Forums/en-US/smallbusinessserver/thread/f7d38c2f-fa99-4ed4-bec9-1d9044164946)


3.  SharePoint Configuration 

     When you need to repair SharePoint, keep in mind that you didn't set it up.  As per Robert Crane, SMB SharePoint expert:  

Ensure that you have "Set your SharePoint farm password. As I have detailed before inthis post, on SBS 2011 the SharePoint farm password is set to a random value. This means that in the case of a DR and you needing to repair the SBS 2011 SharePoint installation you are potentially going to need to know the SharePoint farm password to connect to the existing installation. If you don't then it is an uninstall/reinstall of SharePoint Foundation on SBs 2011, which not something you want to do if it can be avoided. Thus, use the Powershell commands in the post to set the password to something you KNOW.

For more information see:  http://supportweb.ciaops.net.au/blog/archive/2010/12/04/search-server-story-sequel.aspx  and    http://supportweb.ciaops.net.au/blog/archive/2011/02/04/sbs-2003-companyweb-migration-–-part-7.aspx

4.  Repair Companyweb.

    Customer installed trial version of SBS 2011.  He then installed the final version of SBS 2011.  He saved off the data, formatted the box and tried to import the data back in.  The resolution here is that you do not need to reinstall from scratch, you can merely put in your real key code into the server and "rekey" it.  There is no need to reinstall the server.  As noted above, repairing SharePoint, you need to set a password properly.

5.  Disk Configuration.

    Customer was doing an install and rebooted into SBS 2011.  Upon the reboot, it failed to reboot.  They had to go in and set the system partition and the active partition on the disk to get the system to boot properly.

6.  Mailbox Still on Legacy Exchange Server instead of on Exchange 2010.

    Customer was noticing issues with clients logging into OWA.  Turns out that the mailboxes were not yet moved over to Exchange 2010.  Ensure that you have followed the instructions to migrate mailboxes and remove the last legacy Exchange server.

7.  Migrate Public Folders.



8.  RDS Configuration.

    The symptoms were that clients couldn't stay logged in for more than 5 minutes.  The underlying problem was that there was a configuration problem with Remote Desktop Gateway.

9.  Policies do not apply as expected.

    This is not unique to SBS 2011, but ensure before you begin the migration from SBS 2003 that any non default/custom group policy settings that may interfere with the migration are temporarily disabled.  If you have any group policies that were set to deploy applications to new computers, that SBS 2011 is a "new computer" to that group policy and may inadvertantly get something they shouldn't.

10.  Invalid Redirection Settings in IIS (OWA).

    Customer migrated to SBS 2011 and could not log into OWA.  They had set up a redirection in IIS for their OWA virtual directory to go to the \Exchange virtual directory in 2003.  IIS just needed to be reset back to normal.  It comes in handy to have a clean SBS 2011 in HyperV or VMware to compare baseline settings to.

11.  RPC Client Access Service Configuration (service not started).

    You may see this during the middle of the migration when SBS 2003 and SBS 2011 are both running.  Once you remove the SBS 2003 you will see this issue go away.  If suddenly your clients Outlook are having issues receiving email, make sure this service is running on the server. 

12.  Exchange 2010 not installed during the migration.

    The root cause was various things in each case but it can be summed up with the recap below and in this thread.  

    RECAP OF ALL RESOLUTIONS of the three different failures in this thread: 

    RESOLUTION : (or rather the best reason based on the redo) Appears to be that the original install was done on HyperV with differential disks.  Differential disks are not supported by Exchange in virtualization.  Thus it's recommended that you not use this.  In fact I'd say used fixed in production would be very wise. 

    RESOLUTION:  On this server a leftover Exchange 2000 was causing the failure. 
[02/02/2011 19:53:57.0933] [1] [REQUIRED] One or more servers in the existing organization is running Exchange 2000 Server. Please upgrade these servers to Exchange Server 2003 (or later) or remove them.  Installation cannot proceed until existing Exchange 2000 servers are upgraded or removed. To prevent this, review ADSIEDIT and make sure all Exchange 2000's in the network have been properly removed. 

    RESOLUTION as a fyi for others: This one the AD that was icky and missing was "they were missing the junction point all together, no windows\sysvol\domain folder on the source server" The tool catches journal wrap, but not this one that is not common.  That said to prevent this run dcdiag ahead of time on the source server -- both SBS 2003 and SBS 2008.  SBS 2003 you can also do netdiag from the win2k3 admin tools.  SBS 2008 you can't as the tool was deprecated. The failures can be found by looking in the SBSsetup.log and the Exchange setup log.  Please review the tips at www.sbsmigrationtips.com for running dns diagnostic tools ahead of time.

If you install and the migration indicates that it failed, stop.  Restore the SBS 2003 system state.  Start the migration over.  Do not plow ahead and think that merely reinstalling Exchange 2010 is best.  The Exchange server will be unlicensed and you will be missing integration with SharePoint and the SBS console.

12.  Server not completing the install and leaving the server in a possibly inconsistent state.

If you say yes during the install of the server you may find that the system reboots at an inopertune time.  If it reboots and it's not complete, review the SBSsetup.log file to see if it's similar to the following:

http://social.technet.microsoft.com/Forums/en-US/smallbusinessserver/thread/1f958eb9-5929-4b2d-be63-b47bb5b30cc0

The trigger here was saying yes to updates during the install process which rebooted the server in an awkward way.

[UPDATED 2/11 - New Resolution - Provided by John Bay, Sr. SEE in CSS]
Primary Failing Task: None - Setup never completed
Last entries  in the SBSSETUP.LOG are NOT:
Setup: We made it all the way through the Wizard.
Setup: Removed the password.
Setup: Removed SBSSetup from the RunOnce.
Setup: Rebooting the box.
Key Error or Exception from the Log:
Task: Task ("MUPhase2Task") execution complete.
TaskManagement: Previous Task required us to stop processing Tasks for a restart, failure, or cancel.
TaskManagement: A Reboot was required. Now=True,Finished=False,Redo=True
Setup: TME needs a reboot: bTMEHasMoreToDo=True bPrepareOnly=False
Setup: Setting RebootPendingValue to true.
Setup: Back from running the TME
Setup: Setting ResultFile value to C:\Program Files\Windows Small Business Server\Data\TME\Results\TaskStatusResults634104809850346319.xml
Wizard: Admin:QueryNextPage(sbssetup.mainprogress) = null
Wizard: WizardChainEngine Next Clicked: Last page, so the wizard isdone, closing wizard frame and returning
Setup: Setting ShowBillboards to False
Wizard: sbssetup.mainprogress exited with the button: Next
Wizard: TOC sbssetup.finish is NO longer on ExpectedPath
Setup: We are back from the wizard after user clicked Next.
Setup: Get Stage = <null>
Setup: We have a reboot pending.
Setup: Rebooting the box
Most Common Cause:
The server went for the reboot but the setup never resumed. This can happen due to some source environment conditions and a timing issue during the setup during certain installs. Once it happens, the setup is not completed and steps are required to finish it. This assumes that all setup tasks that have completed up until this point have worked.
Resolution Summary:
1-Use Notepad to create the following registry file, save it and import it (within the cut here blocks, do not include them). Save the file as import.reg, then double click the file to trigger the import.

--cut here--
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SmallBusinessServer\Setup\Internal]
"Stage"="MainProgress"
"InProgress"="True"
--cut here--

2- Then you must recreate the info.xml file.  The file will be saved as SBSSetup-runtimedata.dat
Copy c:\program files\windows small business server\data\tme\enginestate\sbssetup-runtimedata.dat to c:\program files\window small business server\data\info.xml (replace the existing file.

3- Once the registry keys are in place, and the info.xml has been recovered, you can attempt to continue the setup by running c:\program files\windows small business server\bin\sbssetup.exe . Make sure you are using the same administrative account used during the setup

This issue is documented here:  http://blogs.technet.com/b/sbs/archive/2010/08/03/the-ultimate-guide-to-sbs-2008-setup-failures.aspx