Domain Upgrade to Server 2012 R2: DNS Servers ""The server with this IP address is not authoritiative for the required zone." & “An unknown error occurred while validating the server.” when Configuring Cross Forest Name Resolution

After a recently domain upgrade from Windows Server 2008 to Windows Server 2012 R2 a number of inconsistent DNS issues have started causing issues for users accessing resources in a remote domain. At present there are two domains (which are the forest root domains) in separate forests, there is a two-way trust between these domains. For it to function correctly each domain should host a secondary zone containing a copy of the trusted domains Forward Lookup Zone.

This was worked before the domain upgrade but since then I have been receiving the error "The server with this IP address is not authoritative for the required zone.” this is preventing the zone being replicated to the secondary zone within the trusted domain. 

A similar error is happening on the other domain when I try to configure a zone transfer the error on this side is “An unknown error occurred while validating the server.”

There was nothing obvious in the DNS Server Event Logs on either side so I decided to run the DNS BPA from the Windows Server 2012 Server Manager. It raised a number of alarming errors the first being “Error DNS:Zone_msdcs.domain.com is an Active Directory integrated DNS Zone and must be available. The Active Directory Integrated DNS Zone _msdcs.domain.com was not found.

After some research I came across the following TechNet article http://technet.microsoft.com/en-us/library/ff807395(v=ws.10).aspx although this was no good to be as I could not get a backup copy of the zone. I checked on the DNS server and I could see the _mcdsc zone underneath the domains Forward Lookup Zone.

I then created a new Primary Zone on the Server 2012 R2 side.

As this was the only domain in the forest I configured it to replicate To all DNS servers running on domain controllers in this domain: domain.bom.

I named the zone _msdcs.domain.com.

After a few minuted I reloaded the DNS zone and it was populated with all the required records.

The next stage was to delete the old zone folder, this was under the domains Forward Lookup Zone.

Now when I run the DNS BPA there is only two minor errors raised, both of which can be ignored at this stage.

Now when I try to configure Zone Transfers from both sides the remote servers resolve correctly.

As my new Domain Controllers had to have secondary copy of the remote domains DNS zone I created a new Secondary zone on the new DC.

I named it the same as the remote domain’s FLZ.

It resolved correctly.

Now clients and devices in each domains can resolve resources in each domains using their local DNS server.

"How to recover SA password on Microsoft SQL Server 2008 R2" by Gert Van Gorp

This is not one of my posts, it is something I came across that I used today that was very helpful. 

http://v-consult.be/2011/05/26/recover-sa-password-microsoft-sql-server-2008-r2/#comment-20767

I created a new SQL Server 2008 R2 instance to support a new EPOS system for a customer, the EPOS system required a number of SQL modification before it could be installed. I needed to have "sq" admin rights on the SQL Server before it would work, this post gives a great step-by-step guide on how to reset the "sa" password on SQL Server 2008 R2.

Hyper-V 2012 R2 "Hyper-V cannot be installed: A hypervisor is already running." when you try to install the Hyper-V role on a Virtual Machine

Recently I was setting up an environment of two Hyper-V 2012 R2 servers, my plan was to manage these instances of core Hyper-V from a full Windows Server running 2012 R2 to benefit from the GUI Hyper-V Manager. I decided to use my Domain Controller so the first step was to install the Hyper-V server role, when I did this I received the following error "Hyper-V cannot be installed: A hypervisor is already running." this was of course because my Domain Controller is actually a Virtual Machine.

The work around for me in this case was to use PowerShell to install only the Hyper-V Management Tools to allow for remote management. I used the following PowerShell command to find the exact name of the feature I had to install;

Get-WindowsFeature *rsat*

To install the management tools use the following command;

Install-WindowsFeature RSAT-Hyper-V-Tools

After a reboot you should be able to launch the Hyper-V Manager, you can then use the Connect to Server.... button to establish connections to the Hyper-V servers.

If you actually want to run Hyper-V 2012 R2 as a nested hypervisor capable of running nested Virtual Machines, please consult the following blog post http://blog.ryanbetts.co.uk/2014/06/using-vmware-workstation-10-to-run.html you basically have to add hypervisor.cpuid.v0 = "FALSE" and mce.enable = "True" to the Hyper-V VM's VMX file (if you are using VMware Workstation).

Removing a Failed Exchange Server from Active Directory using ADSI Edit

Removing a failed Exchange Server from your Active Directory domain is very easy. You basically go into ADSI Edit and select the Server object, and that is it. Off course the ideal way to remove an Exchange Server would be to gracefully uninstall it from the environment. as this is not always the case this post will help remove an Exchange Server.

Open ADSI Edit, you can do this in Windows Server 2008 R2 from the Administrative Tools list but if you are in Windows Server 2003 you must manually add the ADSI Edit into an MMC console. Right click on ADSI Edit and select Connect...

From the Connection Settings dialog box, change the Naming Content to Configuration and click OK.

Expand the following folders Configuration\CN=Configuration\CN=Services\CN=DOMAIN\CN=Administrative Groups\CN=Exchange Administrative Group (FYD)\CN=Servers\ right click on the failed Exchange Server and selected Delete. Accept the warnings to remove the object and everything within it.

 

Also remove the Active Directory Computer object for the Exchange Server. If you return to the Exchange Management Console the Exchange Server will have been removed.

Any old Mailbox Databases that resided on the failed Exchange Server will also have been deleted. This should have stopped a number of event log errors about failed servers and mailbox databases.

Exchange 2010 SP1 Trouble Connecting a Single User's iPhone via ActiveSync "An exception occurred and was handled by Exchange ActiveSync. This may have been caused by an outdated or corrupted Exchange ActiveSync device partnership. This can occur if a user tries to modify the same item from multiple computers. If this is the case, Exchange ActiveSync will re-create the partnership with the device. Items will be updated at the next synchronization."

A single user cannot connect their iPhone to Exchange with ActiveSync. The partnership appears to be created as contacts and calendars are synced OK but mail is not (although mail folders are...) the event logs are showing "An exception occurred and was handled by Exchange ActiveSync. This may have been caused by an outdated or corrupted Exchange ActiveSync device partnership. This can occur if a user tries to modify the same item from multiple computers. If this is the case, Exchange ActiveSync will re-create the partnership with the device. Items will be updated at the next synchronization."

The first thing I tried was to remove the device using the ECP. This made no difference.

I then ensured the "Allow inheritable permissions from the parent to propagate to this object and all child object. Include these with entries explicitly defined here." was selected and clicked the Default button to reset the permissions.

Using the same logic I did in this post http://blog.ryanbetts.co.uk/2014/10/exchange-2010-sp3-event-id-1053.html I decided to try and give the Exchange Servers principal Full Control access to the object.

I re synced the iPhone and mail started to flow again.

Forcibly Removing a Public Folder's SMTP Address from Exchange 2010 SP3

After a massive Exchange outage ending in the server being rebuild I was asked why a user was no longer seeing e-mails from the info@domain.com UK address. At the time I was not sure if address was a mailbox, a secondary SMTP address for a user or even a mail-enabled public folder.

I used the following PowerShell command to see if the info@ address belonged to a mailbox and/or user.

Get-Mailbox –an info

It returned no results, so I searched the domain to find where the SMTP address resided within Active Directory, this can be done using the Active Directory Users and Computers MMC, using Find and a Custom Search. You will notice that info@ belongs to a mail-enabled Public Folder.

I used the following command to determine the state of the Public Folders, I knew as I had just rebuild and restored the Mailbox Databases that the Public Folder databases had not been restored.

Get-PublicFolder info

As expected PowerShell returned the error "Couldn't find an available public folder database. Make sure that there is a public folder database on at least one server". I consulted with the customer and they decided that the content in the info@ Public Folder was mostly junk and could be forgotten about.

The next step was to remove the failed Public Folder database from ADSI Edit, as the Domain Controller I had access to was Windows Server 2003 R2 I had to manually add the ADSI Edit snap-in from a custom MMC. Ensure you change the Naming Content to Configuration and click OK.

Expand Configuration\CN=Services\CN=Microsoft Exchange\CN=DOMAIN\CN=Administrative Group (FYxx)\CN=Databases right click on the CN=Public Folder DB Name and select Delete you will be asked twice to confirm you want to remove it.

Now the Public Folder database instance was removed from the domain the event log errors would stop, the next step was to remove the info Active Directory object. You need to use the View menu to enable Advanced Features then click on Microsoft Exchange System inside this container should be an object info that is listed as type Public Folder. Right click and Delete this.

Following the steps above has removed the info@domain.com account from the SMTP Routing Domain. This means you are free to create another object with that SMTP address, Exchange Server tends to appenx a number, such as 2 on duplicate SMTP addresses. For example if you have a mail-enabled Public Folder with the SMTP address of info@, Exchange will let you create a new user with the e-mail address info@ it is not util you look at the SMTP address of that user you will notice a 2 has been added.

To verify the info@ SMTP address had been removed I performed another search on Active Directory. As you can see it had removed it successfully.

In Exchange Server 2010 Public Folders are horrible to manage, therefore we decided the best way forward was to move to shared mailboxes. I used the Exchange Management Console to create a new account with the SMTP address info@domain.com. Public Folders are also a thing Microsoft seem to have been threating to remove since about Exchange Server 2007.

When the object created the Primary SMTP Address remains as info@ this is because there is no longer a duplicate within the SMTP domain.

As this was a shared mailbox I had to delegate permissions to allow other users to open it from their Outlook, this can be doing by right clicking on the mailbox and selecting Manage Full Access Permissions....

Use the Add button to add delegated user accounts to the Full Access Permissions group.

To add the shared mailbox to an existing users account you can edit the MAPI profile and use the Advanced tab and Add to simply point to the new mailbox.

Tested and it works.

This has obviously been an easy fix as there was no requirement to retain the data stored within the old Public Folders database. If you do need to recover the data there is a number of way to do it, you can patch up the database using ESEUTIL and hope for the best. Or you can use a 3rd party tool which can read and dump EDB files contents out to PST files. This would then allow you to do a manual restore from Outlook clients.

Exchange 2013 SP1: Performing a Mailbox Database Restore using Database Portability in Exchange Server 2013

Since Exchange Server 2007 you have been able to perform Mailbox Databases restore using a feature called "Database Portability", this allows you to take an Exchange EDB file, copy it to another Exchange Server in the Organization and mount it. It's a great feature for disaster recovery.

I have written this post after having done it in production for a client running Exchange Server 2010 SP3, it is my notes should I never have to do it again. Hopefully it is also going to help you.

Step One: Repairing the Exchange EDB Database

Whatever has happened to your Exchange Server that has failed you must one way or another get a copy of the Exchange EDB file. This could be from means of extracting it from the failed server or restoring it from backup. When you get the EDB file you must use ESEUTIL to determine the "State" of the database file.

The following command can be used to determine the state of the Exchange EDB file.

ESEUTIL /mh “Database EDB Path”

In my example the state is "Clean Shutdown" this is mainly because I am doing it in my lab to document the process for myself. There is a very high chance that if you have found this blog post you are looking to restore an Exchange Database from a failed Exchange server. If your Exchange Server lost power suddenly or has suffered corruption there is a high chance the Exchange Database state will be "Dirty Shutdown".

If when you use ESEUTIL against your Exchange Database it reports a "Dirty Shutdown" it is because there are transaction logs that have not been committed to the database. From the ESEUTIL output window the fields Log Required and Log Committed will give you an indication exactly what log files have not been committed.

In the event the failed Exchange Server was designed and configured properly and you have access to the log files you can use the following command to "play back" the log files manually into the Exchange Database.

The following command integrity checks the Transaction Logs to see if they are in a state to be committed to the Exchange Database.

ESEUTIL /ml “Transaction Logs Path”

If the output states the Transaction Logs are "OK" you can use the following command to commit them to the databases. The only variable that is maybe not obvious here is the "E00" this is the prefix of the Transaction Logs.

ESEUTIL /r E00 /l “Transaction Logs Path”  /d "Database EDB Path"

As you can see from a vanilla Exchange Server the Transaction Logs all start with "E0" when each Transaction Log reaches 1MB in size it is written to disk and a new log created.

.

It is also possible that your Transaction Logs are either unavailable or corrupt, in which case means you cannot commit them to the Exchange Database. The following command can be used to perform a hard repair.

ESEUTIL /p "Database EDB Path"

When you run ESEUTIL with the /p switch you will get a warning on screen "You should only run Repair on damaged or corrupted databases. Repair will not apply information in the transaction log files to the database and may cause information to be lost. Do you wish to process?" if you have tried to recovery the database and it has not worked you have no choice, click OK. After you click OK the ESEUTIL tool with perform a defragmentation the database.

The time ESEUTIL takes to complete largely depends on the size of the EDB file. It is why when I am designing Exchange Server solutions I try to have multiple databases, to keep the sizes of the individual mailstores smaller.

Step Two: Configuring the Recovery Mailbox Database

The next step is to ensure you have a new Exchange Server or Server's built to host the Mailbox Database, please note that the versions of Exchange (and builds) must be exactly the same or you will experience an error when trying to mount the recovered database. This TechNet article that states all of the Exchange Server build numbers;

http://social.technet.microsoft.com/wiki/contents/articles/240.exchange-server-and-update-rollups-build-numbers.aspx

When you have a new Exchange Server you must now create a new Mailbox Database to restore into. The following command can be used to create a new mailbox database with PowerShell.

New-MailboxDatabase –Name “Mailbox DB Name” –EDBFilePath “Path to Store EDB with .edb” Server: ServerHostname

You must make one configuration change from the ECP in Exchange Server 2010 you could use the "-AllowFileRestore:$true" switch when creating the new database, this seems to be deprecated in Exchange Server 2013. If you know the new equivalent please comment below.

To make the change from the ECP browse to Servers\Databases click the new mailbox database and use the pencil icon to edit the properties. Click on the Maintenance tab and select "This database can be overwritten by a restore" option, click OK.

Now if it is not already, dismount the newly created mailbox database. Then browse to the path the database is stored at and rename the EDB file that is for the newly created database. I usually just put a dash before the name, once this is done copy the recovered mailbox database into the same location and rename that to match that of the newly created mailbox database.

Delete the Transaction Logs for the new databases, don't worry these will be created when the recovered database is mounted.

Mount the recovered database again from the ECP or using PowerShell. In my instance I am mounting the "Mailbox Mailstore - Recovered" database for clarity.

Step Three: Reconfigure Users Mailboxes

The following command will display all the users mailboxes that are hosted on the old, failed or corrupt mailbox database.

Get-Mailbox –Database “Old Database”

Then to perform the reconfiguration pipe Set-Mailbox -Database "Recovered Database" onto the previous command.

Get-Mailbox –Database “Old Database” | Set-Mailbox –Database “Recovered Database”

The last step is to perform a mailbox cleanup using the following PowerShell command.

Clean-MailboxDatabase “Recovered Mailbox Database”

Now you have successfully completed an Exchange Server Mailbox Database restore using Database Portability.