Share iT…

When you try to connect a client computer to your Small Business Server 2008 or 2011 network via the http://connect you get “Internet Explorer cannot display the webpage” or the wizard stops with error: “An error occurred during the download of Connect Computer. Please go to http://connect and try again.”

Both problems had to do with DNS issues. In my case I had configured the client with static TCP/IP settings (IP address and DNS) instead of using the dhcp settings. To solve the problem I had to enter the sbs domain name in my network settings properties on the DNS tab, to append the DNS suffix like below.

After adding this, the connect computer program worked fine.

As microsoft already released documentation about migrating from SBS 2003 to SBS 2011, now they released some more migration scenarios. Here a overview of al released scenarios:

Migrate to Windows Small Business Server 2011 Standard from Windows Small Business Server 2003

Migrate to Windows Small Business Server 2011 Standard from Windows Small Business Server 2008

Migrate Windows Small Business Server 2011 Standard to New Hardware

Move all SharePoint Foundation 2010 databases for Windows SBS 2011 Standard to another server

When accidentally set a http redirect for your OWA on your Exchange 2007 / 2010 and SBS 2008 via IIS7 and inherited to all virtual sub directories and then try to remove it for the virtual directories public, exchange, exadmin and exchweb you get an error like this one:

HTTP Redirect:
There was an error while performing this operation.
Details:
Filename: \\?BackOfficeStorage\yourdomain.extension\Public Folders\web.config
Error: Cannot write configuration file

Solution: This error is generated because these virtual directories don’t have a physical path.
You can solve this issue by opening a command prompt window. Change directory to Windows\system32\Inetsrv. Then run this command: appcmd set config “/” /section:httpredirect /enabled:false -commit:apphost. Change and for your specific environment.

More information about this topic and setting http redirect for owa can be found here: Simplify the Outlook Web App URL

I have written before here about this and mentioned to change the search account, but as now known this will create problems installing updates like SharePoint 3 Service Pack 2.

So changing the accounts is no solution because it creates new problems. Additional information about this problem is found here.

Browsing above problem I found another possible sollution for solving the Event ID:
2436 Windows SharePoint Services 3 Search

The start address cannot be crawled.
Context: Application ‘Search inde file on the search server’, Catalog ‘Search’
Details:
Access is denied. Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to crawl this repository. If the repository being crawled is a SharePoint repository, verify that the account you are using has “Full Read” permissions on the SharePoint Web Application being crawled. (0×80041205)

1. Click Start, click Run, type regedit, and then click OK.
2. In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
3. Right-click MSV1_0, point to New, and then click Multi-String Value.
4. Type BackConnectionHostNames, and then press ENTER.
5. Right-click BackConnectionHostNames, and then click Modify.
6. In the Value data box, type the URL mentioned in the above warning event, and then click OK. (With URL is meant only the remote.domain.com part.)
7. Quit Registry Editor, and then restart the IIS service.

Source: the Official SBS Blog

Update:
It seems that changing the search accounts, creates a problem with installing SharePoint updates like SP2. So before changing the search accounts read this article!

After installing a ssl certificate on a SBS 2008 server you get 2 different SharePoint Services 3 Search event errors.

Event ID: 2424
The update cannot be started because the content sources cannot be accessed. Fix the errors and try the update again

Event ID: 2436
The start address cannot be crawled.
Context: Application ‘Search inde file on the search server’, Catalog ‘Search’
Details:
Access is denied. Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to crawl this repository. If the repository being crawled is a SharePoint repository, verify that the account you are using has “Full Read” permissions on the SharePoint Web Application being crawled. (0x80041205)

Solution: Got this solution from my brother, thanx for that:

First we have to create 2 service accounts: SPSearch and SPContent

1. On your SBS, open Active Directory Users & Computers (Start –> Administrative Tools –> Active Directory Users & Computers.
2. Within ADU&C, navigate to the Organizational Unit where you want to create the new user accounts.
3. Right-click on the OU and select New –> User
4. On the first page of the new user window, enter the following info:
   o First Name: SPSearch
   o Last Name:
   o Username: spsearch
5. Click Next.
6. Enter a strong password for the new account.
7. Uncheck the option “User must change password at next login”
8. Check the option “User cannot change password”
9. Check the option “Password never expires”
10. Click Next
11. Click Finish.
12. Repeat steps 3-11, using “SPContent” instead of “SPSearch” in step 4

We do not have to worry about granting any access or permissions to the two new accounts we created.
After the accounts have been created, close Active Directory Users & Computers, then open SharePoint Central Administration (Start –> Administrative Tools –> SharePoint 3.0 Central Administration).

1. When SharePoint 3.0 Central Administration opens, go to the Operations tab.
2. Click on the “Services on Server” link
3. In the Action column, click the link to Stop the “Windows SharePoint Services Search” service.
   o You will receive a warning that stopping the search service will remove existing indices. Click OK to acknowledge the warning.
4. When you return to the SharePoint Central Administration Operations tab, the Windows SharePoint Search Service will show as stopped. Click the link to Start the Windows SharePoint Services Search service. This will open the Search service configuration page.
5. In the Service Account section, select the “Configurable” option
   o. For a username, enter \SPSearch (where is your AD domain).
   o. For a password, enter the strong password you assigned to the SPSearch account.

1. In the Content Access Account section, select the “Configurable” option
   o. For a username, enter \SPContent (where is your AD domain)
   o. For a password, enter the strong password you assigned to the SPContent account.
2. In the Search Database section, change the database name by appending and underscore 1 (“_1”) to the database name.
   o By default, the database name should be WSS_Search_[SERVERNAME], so we’re changing it to WSS_Search_[SERVERNAME]_1.
   o Changing the name is necessary because the default database name already exists with search data. If we attempted to use the default database name, SharePoint would throw an error that the database contains user-defined schema and cannot be used. By changing the search database name on this configuration page, SharePoint Central Administration will create a new database using this name and configure search to use this new database. Since the new database is empty, we won’t encounter any errors.

1. Accept the remaining defaults and click the OK button.

After clicking OK, the settings should be applied and you should return to the “Services on Server” page in SharePoint Central Administration, and the Windows SharePoint Services Search” service should be listed as started.

Close SharePoint Central Administration and open the Services MMC (Start –> Administrative Tools –> Services). Restart the Windows SharePoint Services Search service. Verify that the Windows SharePoint Services Search service is configured to login with the SPSearch account you created.

And as last we have to create the following registry key:
[HKLM\System\CurrentControlSet\Control\Lsa] “DisableLoopbackCheck”=dword:00000001

When installing SBS 2008 or SBS 2011 in Hyper-V you get the error “The User Role Cannot be found. Select a different User Role” during installation.

Solution: Problem is caused by different time zone settings. If Hyper-V has enabled time synchronization, this is the default settings, the time zone of the host and the guest has to be the same. If not this error will occur and only solution is to start over and reinstall SBS.

Recommendation is to turn off time syncronization for the SBS Hyper-V.
Start Hyper-V manager, select your SBS server and choose settings.
At the management part choose Intergration Services.

Then uncheck Time synchronization.

More information can be found here: KB 2097035

Update: error also occurs with SBS 2011.

When you see the following evntlog error: Event ID 10016, Source:’DistributedCOM. “The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {61738644-F196-11D0-9953-00C04FD919C1} to the user NT AUTHORITY\NETWORK SERVICE SID (S-1-5-20) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.”

Solution: If you don’t know witch application is given this error, you can copy the GUID behind CLSID and start the registry editor (regedit.exe) and search for the GUID. You will find witch application is creating this error.
After you know that you start Administrative Tools – Component Services. Expand Component Services, Computers, My Computer, DCOM Config. Then find the found application, in this case IIS WAMREG, choose properties and go to the security tab.

Then at Launch and Activation Permissions, choose customize (if not already chjoosen) and Edit.
Add the user account given in the event error, in this case Network Service account and give the account allow Local Launch and Local Activation rights. After that close all windows and restart IIS service.

Update: There is a similar error about another CLSID but the options to change permissions are greyed out. Read here how to solve this issue.

When using remote desktop connection to connect to windows server 2008, 2008 R2, sbs 2008, vista or windows 7 and would use saved credentials. This doesn’t work when you start the connection you get the following error:

“Your system administrator does not allow the use of saved credentials to logon to the remote computer computername/ipadress because its identity is not fully verified. Please enter new credentials.” “The logon attempt failed”

Solution: This happens when trying to connect to a computer / server in another domain and no trust relationships exists. Windows then steps back to use NTLM and the default domain machine policy prohibits use of saved credentials. You can change this domain based or for a individual machine:

Start local group policy editor, start – run – gpedit.msc
Go to Local Computer Policy –> Computer Configuration –> Administrative Templates –> System –> Credentials Delegation
Edit “Allow Delegating Saved Credentials with NTLM-only Server Authentication”
Enable the policy, click Show and enter the value “TERMSRV/*” into the list.

Do the same thing for the following policies:
“Allow Delegating Saved Credentials”, “Allow Delegating Default Credentials with NTLM-only Server Authentication” en “Allow Delegating Default Credentials”

Close the policy editor,
open a command prompt and use “gpupdate /force” to apply the policy directly

The setup of Exchange 2007, Exchange 2010 or even SBS 2008 stops with the error “Access control list (ACL) inheritance is blocked”

Solution: Exchange setup requires that permission inheritance is enabled for the following objects:
Exchange Organization object, Exchange Administrative Group object, Exchange Servers container object, Exchange Address List object, Exchange Public Folder object and Exchange Public Folder tree object.

For Exchange 2003 start Exchange system manager and goto the objects and right click and choose properties, then on the security tab choose advanced and make sure “Allow inheritable permissions from the parent to propagate to this object and all child objects” is enabled. After that restart the Exchange server.

If security tab isn’t available you have to create the following registry value:
Value Name: ShowSecurityPage, Data Type: REG_DWORD, Radix: Binary, Value: 1 At the HKEY_CURRENT_USER\Software\Microsoft\Exchange\EXAdmin key.

For Exchange 2007 and 2010 use adsiedit, and browse to the object you want to change. Right click and choose properties, then on the security tab choose advanced and make sure “Allow inheritable permissions from the parent to propagate to this object and all child objects” is enabled. Wait till Active Directory replication has replicated the changes.

After migrating your Exchange server (I’ve seen this in transition to exchange 2007 and 2010) the PublicFolderDatabase for your OfflineAddressBook is still pointing to the old servers public folder store.

When you run the get-OfflineAddressBook | fl command in a exchange management shell on your new server, you get a result like this:

At Server you see the new servername and the PublicFolderDatabase is still pointing to your old server. Public folder replica’s and offline address book generation server are already moved to the new server.

Solution: I found if you do the following steps you can change the PublicFolderDatabase.
First start adsiedit and browse to CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=First Organization, CN=Address Lists Container, CN=Offline Address Lists and open the properties of CN=Default Offline Address List

Look for the siteFolderServer attribute, here you will see the old public folder store. Choose clear and close with ok, now you may close adsiedit.

Now go to the exchange management console, Organization Configuration, Mailbox, Offline Address Book open the properties of the Default Offline Address List and go to the tab distribution.

Uncheck “Outlook version 2 and 3” at client support and “Enable public folder distribution”. Make sure “Web-based distribution” is enabled. Choose apply and ok, then right click on Default Offline Address List and choose update. After that go back to properties and distribution and check “Outlook client support version 2 and 3” and “Enable public folder distibution”. Again choose apply and ok and right click and choose update.

When you go back to the exchange management shell and repeat get-OfflineAddressBook | fl you now will see the public folder store on your new server.