Share iT…

After finishing a successful server migration from SBS 2003 to multiple Windows Server 2008 R2 servers there were some DNS issues. After a restart of the domain controller it looked like DNS is not working as it should the servers are also signaling they don’t have an internet connection. Restarting the DNS service fixes all problems for that time, but after a new restart same problem comes back every time.

Looking at the system event log there are a lot warnings and error events from the Source: NETLOGON

Event ID: 5774

ADDITIONAL DATA
Error Value: DNS name does not exist.

And:

Event ID: 5781

‘DomainDnsZones.domain.local.’
‘ForestDnsZones.domain.local.’

As we run DCDIAG /C before this didn’t give any error, but when we now run DCDIAG /test:dns we see the following result:

Running enterprise tests on : domain.local
Starting test: DNS
Test results for domain controllers:

TEST: Delegations (Del)
Error: DNS server: OLDSERVERNAME. domain.local.
IP: [Missing glue A record]

As you can see the test is trying to resolve the old servername at the Delegations test.

Solution:

At the end the problem was when looking in DNS manager and going to the domain.local – _msdcs subzone, the NS record had still the old servername entered.

Just change the record and change the data to the new server information. This resolved the first error, but the second stayed.

This error occures because there are one or more DNS zones are not correctly saved within Active Directory. You can easy see this by using the Registry editor regedit.exe and browse to HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ DNS Server \ Zones. All you dns zones should be located over here.

When you select a zone it would look like this:

As you can see there isn’t a REG_SZ value DirectoryPartition DomainDnsZones.domain.local or ForestDnsZones.domain.local these are the problem zones. I had to delete these zones (both were manual made zones in the past on the old DC) and recreate them. After recreation the REG_SZ value DirectoryPartition value was set and the event warnings didn’t come back as after restarts no problems have raised anymore.

During an Exchange 2003 – 2010 transition, when moving a mailbox you see the database gives an “Object not found” message.

If you continue the mailbox move will fail with the following error: “Mailbox database “Servername\First Storage Group\Mailbox Store (SERVERNAME)” doesn’t exist.”

Probably you would also see some Event ID 3113, MSExchangeIS errors in your Application log indicating the Mailbox of Public Folder Store was not found in the directory. The item may have been deleted.

Solution: The problem is caused because the “Allow inheritable permissions from the parent to propagate to this object and all child objects. Include these with entries explicitly defined here.” is not set on the Exchange 2003 server object.

Open Exchange System Manager, browse to Administrative Groups, first administrative group, Servers and choose properties on your Server. Select the Security tab and choose advanced. Place a check at “Allow inheritable permissions from the parent to propagate to this object and all child objects. Include these with entries explicitly defined here.” and select OK.

If you cannot see the security tab you need create the ShowSecurityPage registry key. Open regedit browse to HKEY_Current_user\Software\Microsoft\Exchange\EXAdmin and create a new DWORD value ShowSecurityPage and set the value data to 1. Now restart Exchange system manager and you should be able to see the security page.

When you try to remove an Accepted domain within Exchange 2010 you get the following error:

“Can’t remove the domain ‘yourdomain.com’ because it’s referenced in an e-mail address policy by the proxy address template ‘smtp:@yourdomain.com’.”

But when you go to your e-mail address policies and view the properties this domain is listed in none of your e-mail address policies.

Solution: The domain was still set as a disabledGatewayProxy address on one of your e-mail address policies. Probably this is a leftover from a transition from exchange 2003.

You can remove this by using Adsiedit, open Configuration naming context, Services, Microsoft Exchange, Organization Name, Recipient Policies, do properties on a Policy and find disabledGatewayProxy. Remove the address you would like to delete, repeat this for all policies. After removing the address from all policies you should be able to remove the accepted domain.

Because I get and see a lot of questions on the forums about migrations, how to’s but also about failures and people who don’t have backups to start over. So in this article I would put down some information what you could do to get your migration to a good end. Of course there is no one hundred percent guarantee, but there are some basics you should do that will help to bring it to a good end. I am writing this for a SBS migration but the steps can be used for most migration paths, SBS – SBS, Windows Server – SBS, SBS – Windows Server, Windows Server – Windows Server but also for Exchange migrations. It would be wise to read all information before you start your migration.

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.

.

When you try to migrate a Virtual Machine with System Center Virtual Machine Manager 2008 R2 from one server to another you get a processor-specific feature not supported Rating Explanantion error message:

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

When running the Windows Small Business Server 2011 Standard Migration Preparation Tool it errors out with: “Error is found in DNS Zone domain.local”.

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.

I have posted about this issue before, this was about this CLSID {61738644-F196-11D0-9953-00C04FD919C1}, click here to read.

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.

When running the Windows Small Business Server 2011 Standard Migration Preparation Tool, keeps coming with the following popup error:

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.

After a migration to a SBS 2011 server I got the following event error message:

Event ID: 11, Source: Kerberos-Key-Distribution-Center
The KDC encountered duplicate names while processing a Kerberos authentication request. The duplicate name is RPCSS/Pc.domain.local (of type DS_SERVICE_PRINCIPAL_NAME). This may result in authentication failures or downgrades to NTLM. In order to prevent this from occuring remove the duplicate entries for RPCSS/Pc.domain.local in Active Directory.

This will occur when two or more computer accounts have the same service principal name registered.

Solution:
Run the following command from a command prompt:

ldifde -f check_SPN.txt -t 3268 -d “” -l servicePrincipalName -r “(servicePrincipalName=HOST/pc.domain.local*)” -p subtree

Change the pc.domain.local with the name given in the event log.

The outcome will give you two or more entries like this:

dn: CN=PC1,OU=SBSComputers,OU=Computers,OU=MyBusiness,DC= domain,DC=local
changetype: add
servicePrincipalName: HOST/PC1
servicePrincipalName: HOST/Pc1.domain.local

dn: CN=PC2,OU=SBSComputers,OU=Computers,OU=MyBusiness,DC=domain,DC=local
changetype: add
servicePrincipalName: HOST/PC2
servicePrincipalName: HOST/Pc1.hessingnl.local

As you see both (or all) will have the same Service principal name.

In my case the additional computers with the wrong service principal name didn’t exist anymore only in Active directory users and computers, so I could just delete those computer accounts.
If the computers still exist you can remove the affected computers from your domain and re join them or use adsiedit and change the service principal name to the right value.

Additional information can be found here: kb 321044

During migration to Windows Small Business Server (SBS) 2011 you receive an error:

“Cannot connect to the domain”

“Verify that the domain name and log on credentials are correct, and then try again.”

Click the error away by pressing the OK button.

First thing to start with, make sure you entered all fields correct, if there was an error change it and try it again.

Second possibility is your network adapter need some time to load the configuration, it times out the first time, wait 30 seconds after hitting the OK button and try again.

Then third thing to try press < shift > < F10 > on the SBS 2011 this will open a command prompt, try if you can do a “ping sourceserver” and ping “sourceserver.domain.local”.

Fourth possibility the date or time differs with the source server. Make sure the date and time are set correctly on the source server. If this is all right go back to the SBS 2011 installation press or go to the command prompt if open from the previous step. At the command prompt type “date”, verify that the date is right, then type “time”, verify the time is right. You can enter the right date and / or time manually or sync it with the source server with the following commands:

“Net use * \\sourceserver\netlogon /user:domain\administrator”

The command will prompt for the administrator password you have to enter. After that enter this command to synchronize the time with the source server:

“Net time \\sourceserver /set /y”

Fifth option if time and date are right it could that the time zones differs, check the time zone on the source server and then on the SBS 2011 installation press or go to the command prompt if open from the previous step. At the command prompt type “control timedate.cpl”, make sure time zones are equal.

If these steps won’t help you could look at the setup log for errors that may point you to the right direction. Press or go to the command prompt if open from the previous step. At the command prompt enter “notepad “C:\Program Files\Windows Small Business Server\Logs\SBSSetup.log””