sysvol and netlogon shared folders missing after a non-authoritative restore

This is an issue I face with a client side and had to spend hours time to sort it out. Thought of sharing my experience with other fellow minded techies.

First let’s have a look into the issue, Client has a non functional Domain controller due to a power failure. Basically Domain controller has lost it’s database and other critical data (Eg: DNS records, wins records..etc)

Even though additional domain controller has been existed FMSO roles has been assigned to the failed domain controller. Moving forward when we reach the site as a solution they have already restored the domain controller with a system state backup, and then move forward restoring the system state backup to the second domain controller as well. This has caused issues to bring both DC’s to a halt.

Looking into the event viewer found out both DC’s couldn’t find a proper DC’s to sync the sysvol contents though both are trying to find a health DC. To make things shorter I’ve tried to set one DC to set as authoritative and not look for another DC to get the sysvol contents by following the kb290762. After that brought the second DC online and set the “BurFlags” value to D2 in the registry path.

(HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup)

Found out after some time both DC’s got the sysvol folder shared without any contents in it. Netlogon folder also not appearing! Another frustration on the way!!

Next step restore the sysvol to alternative location and reterive the contents in the sysvol folder and then copy to one DC’s “C:\Windows\SYSVOL\sysvol\<Domain Name”\” One that complete following instruction been followed,

Stop File Replication Service in that particular DC, change the following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup

Key: BurFlags

Value: D4(hexadecimal)

Start File Replication Service, after we see the event ID 13516 in FRS event log.

Restart Netlogon service, then the NETLOGON is shared out.

Stop File Replication Service in the other DC, change the following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup

Key: BurFlags

Value: D2(hexadecimal)

Start File Replication Service, after we see the event ID 13516 in FRS event log.

Once that complete both DC’s has same contents in the sysvol folder and the netlogon has been restarted as well. Confirmed users can authenticate and rest of the applications are working fine Smile

Almost everything is running perfectly but as a precaution requested to take full backup of the DC’s. Time for a beer but again it’s midnight so no way to make that as well Smile

Summary: Above mention effected domain controllers are Windows 2003 R2. But as a thumb rule one thing to keep in mind is AD replication is multi-threaded, multi-master replication engine and it can take time and patient is a virtue.

Following links has been referred during the troubleshooting process,

http://support.microsoft.com/kb/315457

http://support.microsoft.com/kb/257338

http://support.microsoft.com/kb/229896

Advertisements

Running exchange 2010 in hyper-v environment

Running mission critical apps in the virtual environment suggestion always raise a concern to IT mangers and System administrators who are new in Virtualization. During my customer and partner engagement I’ve see this and also have to admit some customers are extremely happy to use virtualization with their past experience. It’s a fact that virtualization is here to stay as the next generation wave, and the question is we need to as is why do we need physical machine’s for these apps.

In this series of articles we’ll focus on key attributes for virtualizing one of the Microsoft flagship product on it’s own Virtualization hyper-visor, Exchange 2010.

Exchange 2010 is a product Microsoft fully support running under virtualization platforms. You can refer to more information about this by visiting the windows Server Virtualization Validation Program (SVVP) carried out by Microsoft. Apart from that official guide to run Exchange in virtualization platform guides can be found over here.

Now moving back to Exchange server architecture side and hardware requirements it is very clear Exchange 2010 with SP1 has very clear improvements in Storage side as well as memory usage patterns. Complete list of improvements can be found over here. As for the virtualization deployment side we’re happy to focus on the disk subsystem improvements as well. some of the key improvements are,

IO Reductions: Exchange 2010 delivers up to a 50% reduction in disk IO from Exchange 2007 levels. This means that more disks meet the minimum performance required to run Exchange, driving down storage costs.

Optimizations for SATA Disks: IO patterns are optimized so that disk writes do not come in bursts. This removes a barrier that had previously limited the use of Serial Advanced Technology Attachment (SATA) desktop class hard disk drives disks.

Automatic Page Patching: Exchange Server 2010 is more resilient to storage problems. When corruption is caused by minor disk faults, Exchange automatically repairs the affected database pages using one of the database copies configured for high availability. Automatic detection and repair of data corruptions from minor disk errors means that you can take advantage of lower-cost storage options while maintaining system reliability.

JBOD Support: Exchange 2010 can be deployed with up to 16 replicated copies of each mailbox database, and fast database-level failover makes it possible for administrators to swap failed drives with minimal impact to users. This application-level redundancy allows RAID-less (JBOD) storage configurations to be used, resulting in dramatic cost savings.
(Taken from TechNet page)

In the HYPER-V  world we have several types of Virtual Hard Disks (VHD),

  • Dynamic Disk: Dynamic Disk is a VHD file that starts small scale and keep on growing as you add data into that VHD. Due to the nature of the design Dynamic disk  cause some overhead to the host system and a delay. This is a disk method not supported disk subsystem by Exchange team. Personally I believe this disk method is suitable for the R&D test labs and not the production network. You can deploy your Exchange servers under this method and they will work quite ok, but simply not supported by Microsoft and you’ll not get their support on this method.
  • Fixed Disk: A fixed disk is also a .VHD file appear on the host system but with a fixed size. This will not bring an additional overhead for the host system. This is the recommended method for most of the virtual machine disk subsystem. Exchange 2010 fully support Fixed Disk.
  • Differential Disk: In this scenario you’ll have a parent disk and child disk. Parent disk can be consist of the operating system and some applications. Differential disk can contains the changes. You can have several VM’s sharing same parent disk and have each VM’s changes saved in the child disk.
    Differntial disk
  • Pass through Disk:  Under this method you can now expose a host disk to the guest without even putting a volume on it using a pass-through disk. Hyper-V will let you “bypass” the host’s file system and access a disk directly. This raw disk, which is not limited to 2040 GB in size, can be a physical HD on the host or a logical unit on a SAN. To make sure the host and the guest are not trying to use the disk at the same time, Hyper-V requires the disk to be in the offline state on the host. This is referred to as LUN pass-through, if the disk being exposed to the guest is a LUN on a SAN from the host perspective. With pass-through disks you will lose some nice, VHD-related features, like VHD snapshots, dynamically expanding VHDs and differencing VHDs. This is one method I find really beneficial for the Exchange Mailbox server deployment.

Pass-through-disk

Considering the above mention disk subsystems and also referring to the Microsoft guidelines in Exchange disk requirements we can come into following conclusions,

1. Exchange OS and Program files can reside on a fixed disk which would provide required performance.

2. Exchange mailbox, database storage can be located in fixed VHD or in Pass-through Disks. Number of mailboxes and their quota size and mail exchange ratio per day will paly key role to take decision.

Summary: In the above articles we have discussed about the Exchange 2010 deployment in HYPER-V environment validation supportability and key point for the disk subsystem for Exchange deployment. In the next articles we’ll have a look into the memory and network subsystem requirements and also some of the pitfalls we nee dot avoid when virtualizing Exchange 2010.