Archive for the ‘Window Server 2012 R2’ Category


I am in the process of migrating a SBS 2011 server to Windows 2012 R2.  It is mostly, but not entirely done, and some essential tasks have been deferred until time permits.  Both of these servers are Hyper-V VM instances.  The host server and both VM servers use iSCSI targets for a number of key disks.  The virtual machines and disks reside on such a volume.

In spite of a dedicated UPS for the host server and the iSCSI device, they both power recycled for some reason late last week.  I always takes the iSCSI much longer to reboot than the host server, and I expect a few minutes of delay until the VMs start.  However, when I checked later, the 2012 R2 server was not restarted but reporting a failure and asking to do a repair.  A few times trying that made no difference.

How I Fixed This

I selected the tools option on the failure start screen and tried starting in safe mode.  No luck, it still failed.  I also tried low video resolution, same problem.  Then to my delight selecting  directory services restore mode allowed a successful boot.  That made me realize that the NTDS database was probably corrupted.  NOTE:  you will have to logon with a local administrator account.  AD does not start and none of the credentials in it are available.

The first thing I tried was to navigate to the database folder, C:\Windows\NTDS.  I copied the folder contents to C:\Windows\NTDS\Save after creating that folder, then from an elevated command prompt, ran ntdsutil and then the following commands

  • files <enter>
  • info <enter>  This will list the files for the database and logs
  • compact to <full path>  You probably want to create a new folder and provide path to it.
  • quit twice to return to the command prompt

Ideally, you will have a new and well formed NTDS.DIT file in that directory, and you should copy it to C:\Windows\NTDS and overwrite the corrupted file.  Don’t worry about losing anything since you have a copy saved.

Now reboot your computer and it should start normally.


I was so focused on getting my server back that I can only vaguely recall that the compact command did not work, saying there were log files that had not been applied.  Well, it thought that is what compact would do.  Or maybe it did and the server still did not restart properly.

In any case, I switched to using Esenttutl instead of ntdsutil.

Run an elevated command prompt and type

  • esentutl /g c:\windows\ntds\ntds.dit
  • esentutl /r c:\windows\ntds\ntds.dit

The first is an integrity check, and mine predictably failed.  The second is a recovery command, and that, too, failed with a JET database engine error. So I ran the repair option, /P, instead of /R on the command line.  Voila!  It completed successfully and I reboot to a normal windows server.

So What Was That All About?

In general, Windows databases do not update directly but write transaction log files.  Later, these log files are “played back” and make the actual transactions update the database itself. When an unexpected shutdown occurs, as in my case, it is possible that the database does not close properly and has a corrupted element somewhere in it.

Esentutl is also used for Exchange databases if they become corrupted, and it has saved me many times with SBS errors.  While I was hoping the /R recovery function would work, I was not particularly worried about the /P repair option, and it did work.

You might ask yourself, why didn’t I just restore the directory from the last backup?  Remember those tasks not yet done?  Er, server backup was the next item on the to-do list.  Happy to say it has now been done.

 Virtual Machines Have Prevented Disasters More than Once

Let me tell you about the latest situation where I look like a hero instead of a fool.  How can you not love someone who does that for you?

I have a client who is still on SBS 2011 for a variety of reasons.  Let’s sum them up by saying it is unlikely to change for a while.

A few years back, I suggested making SBS a virtual machine and running on a Hyper-v host.  The OS for the host was Windows Server 2008 R2.  Earlier this year, both of the USB drives they were using for Windows Backup (one for the host, one for SBS) had to be replaced.  The new drives were formatted NTFS with 4096 byte sectors.  If you don’t know already, Windows Backup in 2008 R2 and earlier can’t create a backup on these targets.  So for a while, the system has been running without backups.

Why not Just Upgrade?

Duh, why didn’t I think of that?  I did, but an inplace upgrade to 2012 R2 kept failing.  Finally, we located a 2012 Standard .iso and license for sale and grabbed that.  The in place upgrade went well, very well.  Much to our chagrin, the product key would not activate even though it was valid, and the client got his money back.  But there we were with an OS that was about to die from lack of activation.

So I tried the upgrade from 2012 to 2012 R2, and it succeeded.  Problem solved, right?

You Probably Picked the Wrong Answer

When it finally rebooted after the upgrade, a colorful blue screen appeared with the message


The scarce number of articles I found relating to this indicated that it was an invalid product key (I knew that) and re-installing would fix it.  So in goes the DVD and we boot from it.  Enter the correct 2012 R2 product key, select upgrade, and we are instructed to remove the disk and reboot.  When we do the same nasty error above appears.

So I Said…

Let’s just forget about the host system and create a new one.  I didn’t format any disks, just let the installation go.  It completed fine, booted into 2012 R2, and I added the Hyper-v role, reset the static IP address, and got down to setting up a new virtual machine.

I pointed to the existing .vhd for SBS and the virtual disks for Exchange, SharePoint, and data that were on physical drives on the host and attached them through ISCSI controllers, started the virtual machine and bingo!  There is was.  Almost.

I Nearly Cried when It First Started

Active directory showed NO users, NO joined computers, and SBS Console said the OS was not operative.  While I played around for a bit, then looked again after about 5-10 minutes, AD values were back!!  But there was no Internet connection and nothing looked right on the SBS Console network tab.

First I ran Connect to the Internet, and that restored the connection.  Then I ran Fix my network, and suddenly there was the trusted certificate and all the other goodies.  It has been running like a champ ever since.

One Last Thing

The 4096 sector drive for SBS still doesn’t work, so I am trying a WD drive that emulates 512 sectors,  I am going to create another post about this, although there is a lot of information on this topic out there already.

So, to sum it up, your Hyper-v host machine is disposable.  You can trash it and provided you don’t lose the date, you can reconstruct your workhorse servers.  I highly recommend this approach.

Even better, use an iSCSI device (like QNAP, which I love as well) and keep all your virtual information on the drives apart from your computer.  That means the entire platform is disposable.

Strange Behavior

I first noticed this for a client who had to reboot their server during the middle of the day.  Suddenly, a server that was running just fine, was no longer “visible” to client machines.  They could not connect to shares, could not ping the server, and were seemingly disconnected.  What was even stranger was that the server had no difficulties “seeing” those client machines.  Moreover, I was unable to remote desktop into the server from anywhere.

When I finally got on the computer, I looked at Network and Sharing Center and was shocked to see that the network connection showed Public and the network identification was for an unknown network.  How did that happen, and how could I make that go away?

What Didn’t Work

I tried restarting the server, restarting the router, restarting the switch, restarting the client machines all to no avail.  Then I hit on this:

The Solution

I opened Services and scrolled down to Network Location Awareness.  It was running, but it was set to start automatically.  I changed that to Automatic – Delayed Start, then restarted the service.

Voila.  The network went back to Domain with proper identification and suddenly everybody and everything on the network was connected again.

Seems as though the service did not have enough time to detect the network and set it properly.  I wish I had a great answer for why this starting happening, but I don’t as of yet.  Just happy that the fix was easy and hope it helps you at some point.  Actually I hope it doesn’t which means you don’t have the problem.

I have seen this on one and only one server. It was a 2012 R2, but I have subsequently seen the issue reported (but not solved) for 2008 R2 as well.