“Your computer can’t connect to the remote computer because the Remote Desktop Gateway server is temporarily unavailable. Try reconnection later or contact your network administrator for assistance.”

In this case it happened because there was installed a third party web application. This application needed to run as a 32-bit application. So the DefaultAppPool in Internet Information Server (IIS) was set to Enable 32-Bit Applications to True.

Solution: Start Administrative Tools, Internet Information Server Manager, choose Application Pools and select DefaultAppPool and choose Advanced Settings… on the right menu.

To get the Remote Web Access working again you need to change the Enable 32-Bit Applications setting to Disabled again.

Please note, this would probably destroy your web application, so before changing the setting contact you third party web application supplier to make sure there is a solution available or you have to move the application to another server.

Backup

First thing before you even start should be to make sure you have a good backup. Make sure you have tested your server backup, so might something go wrong during migration you always can go back to the original situation. It sounds like something you should take for granted, but you would not be the first one that starts the migration and something went wrong and would go for recovery and then they came to the conclusion there wasn’t a good backup at all. So always test it before you start!

If your original server is a SBS 2003 server you can use the built in backup solution, see this document how to use it: Backing Up and Restoring Windows Small Business Server 2003.

Getting familiar with the migration process

Second before you even start with the migration would be getting yourself familiar with the migration process. What migration you are going to do (there are more guides available) you should at least read through the complete guide so you know what you can expect. Better would be to do a test migration, make a copy of your original server (backup or image) to another physical or virtual machine in a separated network environment and complete the migration process. Than you know exactly what you can expect during the migration. If you do not get a good feeling by the process just do it over and over again or get yourself some help by another it professional before you start the migration for real.

If you are not familiar with SBS 2011 there is a lot of online material (video’s, click thru’s, hands-on labs, etc) that can help you getting familiar with the configuration: Link 1, Link 2

Check the health of your source server

Next thing to do is to make sure your source (original) server is in a clean state and configured correctly. If the source server has already got problems before you start the migration, this will certainly end up in problems or failures.

What you at least should do, make sure your server is up to date with updates, service packs, fixes, etc. Run the best practice or health analyzers for your product(s), it will give you all kind of information about what is configured wrong. Run tools like dcdiag.exe and netdiag.exe to check your server configuration. Check your servers even logs for warning en error messages.
Make sure you fix all problems before you start the migration!

Beside the information given in the migration guides, these articles will give you some good advice about preparing your source server:

• Demazter, Migration tip 1 source server health
• SBS Diva, Making sure you have a clean AD
• SBS Team, Standard migration keys to success

Setup phase

When your server is completely healthy, configured right, read all information in the previous steps and you are prepared. Make sure you follow your migration guide step by step and only continue when you are absolute sure you’ve completed the step entirely. Take your time; no one will notice anything from the migration until you are going to move data.

There are still some issues you could run into during the setup phase:

One of the problems that could give a failure is there is a time or time zone difference between the source and destination server. Make sure the time on the destination server is setup correctly in the bios.
Do not choose to install updates during the installation, this would take a lot of extra time and can give all kind of troubles during the installation / migration. It is best practice to install updates after you completed the installation.

Also see this article for some other known issues: SBS Team keys to success part 2 the setup phase.
When you run into a “Cannot connect to the domain” error message in the early stage of the installation there are still some steps you could do, see this article.

Now the actual installation can start, please not that this will take a couple of hours, so when the blue progress bar appears you could leave the server alone for a while.

Post Setup phase

When installation went successful you will see a screen Installation Finished, Run the Migration Wizard to continue migrating to Windows SBS. But if you ran into any problem, error or something else goes wrong, don’t just continue; make sure you completely understand what your problem is. Look at the SBS Team keys to success part 3 post setup and common failures for some known issues and resolutions. If your error is not there and you have no clue, ask some professional or try some community forum like: SBS Technet Forum or Expert Exchange they might have a solution. Otherwise it would be good to start over because continue with errors will in most cases end up in a bigger unresolvable problem.

Guides:

Here you will find some links to additional useful information and migration guides:

• Microsoft SBS migration portal
• Demazter migration guides, good step by step guides
• Susan Bradley’s adds to the SBS 2003 SBS 2011 migration guide
• Mpecs sbs 2003 – 2011 migration guide

For a different migration approach with support you also take a look at SBS migration.

For a lot of SBS 2011 information also take a look at my SBS 2011 index file with a lot of installation and configuration and all kind of other information.

.

2011 was a year of mixed feelings, both on personal as professional view. Started with receiving the Microsoft Community Contributor Award and the birth of our second daughter Wendy the year started well. But in the second half of the year was a hard time on the business and the hardest time was when our oldest daughter had to be hospitalized for over two weeks, after that it were just ups and downs. So it went a little quit on the blog and community contributions.

Statistic wise it was a good year, this was my first full year blogging. The views grew from 5000 views in January to over 40000 in December. The best viewed articles where the Windows Small Business Server 2011 installation and configuration articles with the SBS 2011 index file as most visited. Beside that also the Exchange posts “Recover deleted public folders Exchange 2010 with ExFolders” and “OfflineAddressBook, PublicFolderDatabase still points to old server” were visited very well.

So hopeful 2012 will be a big change, a healthful year with some more time to post new helpful blog posts, I have plenty of ideas and do some more community contribution. Thanks for visiting my blog and hope you found the information very useful.

Event ID: 8
Source: SQLBrowser
Description: “The SQLBrowser service was unable to process a client request.”

I have seen this on multiple servers and it looks like the issue occurs when you install an additional SQL instance and enables the SQL Browser service. This does not occur on a standard SBS 2008 server, because the SQL browser service is disabled by default.

Solution: After some research and found all kind of possible solutions, in my cases the problem was solved by enabling Named Pipes on the protocols for SBSMONITORING within SQL Server Configuration manager. If you have more SQL instance enable Named Pipes for all instances.

To change this go to, Start, All Programs, Microsoft SQL Server 2005, Configuration Tools, SQL Server Configuration Manager. Browse to SQL Server 2005 Network Configuration (32bit) select Protocols for SBSMONITORING and rightclick Named Pipes and select Enable. Repeat this for every Instance you have additional created.

Also checked this only occurs to SBS 2008 servers with SBS 2011 never seen this problem.

“virtual machine ServerName is using processor-specific features not supported on host vmhost.domain.local To allow for migration of this virtual machine to a server with a different processor, modify the virtual machine settings to limit the processor features used by the virtual machine.”

This message wil appear when you try to move between to different hardware processor types. If you want to migrate virtual machines between different processor types you can check the following option within the virtual machine properties. Choose Hardware Configuration, Processor and check “Allow migration to a virtual machine host with a different processor”

This option can only be set when the virtual machine is stopped. So shutdown the virtual machine, change the setting and start the virtual machine, now you are able to migrate the server using System Center Virtual Machine Manager. It would be wise to enable this option by default if you want to create a high available solution between servers with different hardware processor types.

Description: In DNS zone domain.local, your local server is not in the name server records. Migration will fail without fixing this issue. Go to http://support.microsoft.com/kb/2578426 for more details.

When you just follow the link proposed you will find some possible solution for checking if the dns zone is set to Type: Active Directory-Integrated and that Dynamic updates is set to Secure only. Also to make sure on the Name Servers tab the source server is listed with correct name and / or ip address.

All those settings were correct but the error keeps occuring. After some more research I found this thread with the same issue, solution for this thread was contacting microsoft support who complete rebuild the dns zone. With this information I had seen a minor difference with other SBS dns servers.

In this customers DNS server when you take a look within the domain.local forward zone there was no _msdcs entry. There was a _msdcs.domain.local zone, so everything was like this picture accept the record within the red circle was missing.

After noticing that the solution is as follows:

1. First delete the _msdcs.domain.local dns zone (of course it would be wise to start with making a good backup, but this should have been done before you even start with running the migration preparation tool)
2. Create a new primary forward dns zone, _msdcs.domain.local
3. Open a command prompt and run ipconfig /registerdns
4. Last restart the net logon service. After restaring the net logon service all the _msdcs.domain.local and the _mcdcs record are automatically recreated.

Re-run the migration preparation tool and the error was gone.

Update: There has now been a official SBS Team post on this issue, read here for additional information.

To disable or change this feature open Exchange Management Console, go to Organization Configuration, Client Access and choose the Exchange ActiveSync Mailbox Policies. Do properties on the Default policy and select the Passwords tab.

To completely disable the password remove the check at Require password. Of course you can also change the settings to your own requirements.

You can also create separate Mailbox policies with different settings, so you can set other policies for different users. When you create a new policy and want to attach it to a user, go to Recipient Configuration, Mailbox, do properties for the Mailbox user you want to change the policy.

Select the Mailbox Features tab, select Exchange ActiveSync and choose properties, now you can browse to select the other policy you have created.

Some additional information about what settings you can control with the ActiveSync policy are listed over here: Understanding Exchange ActiveSync Mailbox Policies

Please note not all features are supported with all kinds of mobile clients, so before you configure the settings make sure the settings are supported with your type of mobile devices.

When you are creating a new user account via the SBS Console, the creation of the e-mail address fails with the following warning: “Administrator Adminname does not have Exchange administrative rights.”

And when the wizard finished there was no mailbox created. When you go to the Exchange management console you can create mailboxes without any problem.

Solution: This problem occurs when the SBS Administrator account has it’s primary group set to Domain Admins, when you change it back to “Domain Users” the problem does not occur anymore. The primary group can be set by using Active directory users and computers go to the properties of the admin user and than to the Member of tab, select the Domain users group and tick Set Primary Group.

Beside that error, probably after a recent update I have seen this similar error:

The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID
{000C101C-0000-0000-C000-000000000046}
and APPID
{000C101C-0000-0000-C000-000000000046}
to the user domain\spfarm SID (S-1-5-21-1813126608-4190571182-3204100927-3160) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.

The big difference with the other error is when you go to the Dcom config, security the option are all greyed out. So you need to do some additional steps:

Open registry editor (run regedit.exe), browse to Hkey_classes_root\AppID\{000C101C-0000-0000-C000-000000000046} right click and choose permissions.

Choose Advanced

Go to the Owner tab, select the Administrators (Domain\Administrators) group under Change owner to and select the replace owner on subcontainers and objects. Choose OK to close the window. You will return to the permissions window.

Select Administrators (Domain\Administrators) and set Allow Full Control permissions.

After you have done the above settings you go to Administrative Tools – Component Services. Expand Component Services, Computers, My Computer, DCOM Config. Scroll way down till you find the {000C101C-0000-0000-C000-000000000046} icon, right click and choose properties.

Go to the security tab, select customize at Launch and Activation Permissions and choose Edit…

Select the SharePoint Farm Account and set the Local Activation right.

To prepare the source server for migration, you must be a member of all of the following security groups: Enterprise Admins, Schema Admins, and Domain Admins. For additional information, see the article at http://go.microsoft.com/fwlink/?LinkId=190413

But despite the account is member of all the given security groups, it won’t continue and keeps giving this message.

Solution: The message will also keeps popping up when one of the three groups is configured as the primary group. Change the primary group via Active directory users and computers to Domain Users.