Friday, September 28, 2012

Secure channel between the DC’s broken

Secure channel between the DC’s broken:

Follow these steps to reset KDC password :-
1. Stop the Key Distribution Center (KDC) service on Server2. To do so, open
a Command Prompt, type net stop KDC, and press Enter.
2. Load Kerbtray.exe. You can do so by clicking Start, clicking Run, and
then typing c:\program files\resource kit\kerbtray.exe and pressing Enter.
You should see a little green ticket icon in your system tray in the lower
right corner of your desktop.
3. Purge the ticket cache on Server2, right-click the green ticket icon in
your system tray, and then click Purge Tickets. You should receive a
confirmation that your ticket cache was purged. Click OK.
4. Reset the Server domain controller account password on Server1 (the PDC
To do so, open a command prompt and type: netdom /resetpwd /server:server2
/\administrator /passwordd:password, and then press Enter.
5. Synchronize the domain. To do so, open a command prompt, type repadmin
/syncall, and then press Enter.
6. Start the KDC service on Server2. To do so, open a command prompt, type
net start KDC, and press Enter. This completes the process, and the domain
controllers should be replicating success-fully now

Original Post:

How to restore a Virtualized Domain Controller and prevent USN Rolllback

How to restore a Virtualized Domain Controller and prevent USN Rolllback

This summarizes the steps needed to properly restore a backup copy of a Virtualized DC to the Active Directory forest. The copied Virtual DC can be returned to the domain and can have all updates replicated to it with the following procedure. Use this procedure only under the following conditions:
•Updates included with Knowledge Base article 875495 (Windows Server 2003) or article 885875 (Windows 2000 Server with SP4) were installed on the domain controller prior to the failure.
•The backup image of the domain controller has not been booted.
•The current domain controller is offline.
•The backup image of the domain controller is not older than the Tombstone lifetime of object in Active Directory (60 days by default).
•The backup image of the domain controller does not hold any FSMO roles.
This procedure can only be used when the backup image of the Virtualized DC has not been booted since being created.
When restoring a backup image of a virtualized domain controller using this method do not restart the domain controller in normal operation mode. Simply starting a domain controller in normal operation mode, even if it is disconnected from the network, causes changes in the directory service that will increment USNs on the domain controller. You must start the domain controller in Directory Services Restore mode and then use the recovery steps in the following procedure.
How to restore a Virtualized DC image to prevent USN Rollback from occurring:
1)Using the Virtualized DC image, start the domain controller in Directory Services Restore mode.
a.In a registry editor, if the entry “DSA Previous Restore Count” under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters is visible, make a note of the value. If the entry is not visible, assume a value of 0. Do not add the entry.
b.Add the registry entry “Database restored from backup” under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
i. Data type: REG_DWORD
ii. Value=1
c.This setting creates a valid system state backup and immediately restores the backup.
The “Database restored from backup” entry is available on domain controllers that are running Windows 2000 Server with SP4 and domain controllers that are running Windows Server 2003 with updates included with Knowledge Base article 875495 installed.
2)Restart the domain controller normally.
3)In the registry, check to be sure that the value in DSA Previous Restore Count is equal to its previous value plus 1.
4)In the Directory Service event log, check to see that event ID 1109 appears.
a.This event confirms that the virtualized DC has been restored and the invocation ID has been changed. Event ID 1109 places the following information in the log:
Active Directory has been restored from backup media, or has been configured to host an application partition. The invocationID attribute for this directory server has been changed. The highest update sequence number at the time the backup was created is a%n
%nInvocationID attribute (old value):%n%1
%nInvocationID attribute (new value):%n%2
%nUpdate sequence number:%n%3
%n The invocationID is changed when a directory server is restored from backup media or is configured to host a writeable application directory partition.
More Information:
USN Rollback occurs when an Active Directory Domain Controller is restored via a snapshot or imaging process. Microsoft considers this a non-supported method of restoring Active Directory and it is this type of method that causes an Update Sequence Number (USN) rollback, because it results in the USN on the restored DC to be lower than what the other Domain Controllers are using.
To properly backup and restore Active Directory you should use an “Active Directory-aware backup utility” like NTBackup, etc.

Original Post:

Domain Rename in Windows2003/2008

Prerequisites for a domain rename in a simple single domain forest for windows 2003/2008:
  • Enterprise Administrator credentials are required.
  • The domain should be well formed and healthy. Ran dcdiag /q and repadmin /replsum to check for any errors and fix the same before you proceed. Ran gpotool can check all the policies are OK.
  • The forest functional level must be Windows Server 2003 or 2008, and all DC’s running at least Server 2003.
  • A DNS zone for the new domain must be in place.
 The Rendom and Gpfixup tools must be copied to a domain member workstation to perform the rename operations. The operations should not be initiated from a domain controller.
See the TechNet link below for details on requirements if you’re using DFS redirection, roaming profiles, running a CA, or Exchange Server.
The domain rename is performed using the Rendom tool, which is installed with Active Directory when running dcpromo. Once this process is started, you must ensure that no changes are made to the forest configuration until complete. The steps are as follows.
1.       To generate the current forest description file
Run “rendom /list” to generate a state file named Domainlist.xml. This file contains the current forest configuration.
2.       To edit the domainlist.xml file
Using a simple text editor such as notepad, edit the state file, changing the <DNSname> and <NetBiosName> fields to the desired values for the new domain name.
3.       To review the new forest description in domainlist.xml
 Run “rendom /showforest” to show the potential changes; this step does not actually make any changes.
4.       To generate the domain rename instructions and upload them to the domain naming master
Run “rendom /upload” to upload the rename instructions to the configuration directory partition on the domain controller holding the domain naming operations master role. The instructions are then replicated to all other DC’s in the forest. Once replicated to all DC’s, the rename instructions are ready to be carried out. You can force replication by running the “repadmin /syncall” command.
 5.       To verify the readiness of domain controllers in the forest
Run “rendom /prepare” to verify the readiness of each domain controller in the forest to carry out the rename instructions. This should contact all DC’s successfully and return no errors before proceeding.
 6.       To execute the domain rename instructions on all domain controllers
Run “rendom /execute”, this verifies readiness of all DC’s, then performs the rename action on each one. There will be a service interruption during this period. Upon completion domain controllers will be rebooted. If an error occurs on a DC during this phase, the entire transaction is rolled back. Any DC’s that don’t complete successfully after this phase must be demoted and removed from service.
 7.       To fix up Group Policy in every renamed domain
 Run “gpfixup” to refresh all intradomain references and links to group policy objects.
For example,
Gpfixup / / /oldnb: xyz /newnb: abc /
 8.       Reboot client computers and member servers twice to obtain new domain name.
Because the GUID’s of the domain remain the same during the rename process, domain membership is not affected. The DNS suffix of the client machines will also be updated assuming the default option of “Change primary DNS suffix when domain membership changes” is enabled.
 9.       To perform attribute clean up after domain rename
Run “rendom /clean” to remove references of the old domain name from Active Directory.
 10.   To unfreeze the forest configuration
 Run “rendom /end” to unfreeze the forest configuration and allow further changes. This was frozen during the rendom /upload step.
Should you have any problems with clients recognizing the new domain name, you can remove them by running “netdom remove <machine-name> /Domain :< old-domain> /Force”, rebooting, and then rejoining the new domain. Once the rename is complete, there is one final change required on domain controllers. The DNS suffix of a DC is not changed as part of this process. This must be changed manually or the DC’s will have a DNS suffix that differs from the AD domain name.
For further details on renaming Server 2008 domains, reference this TechNet article:

Original Post:

Authoritative /Non-Authoritative Restore in Windows2008

How to restore Server 2008 Active Directory (Non-Authoritative / Authoritative Restore)

Windows Server Backup
Windows Server Backup the Windows Server Backup feature provides a basic backup and recovery solution for computers running the Windows Server® 2008 operating system. Windows   Server Backup introduces new backup and recovery technology and replaces the previous Windows Backup (Ntbackup.exe) feature that was available with earlier versions of the ntbackup.
The ntbackup command is not available in Windows Vista or Windows Server 2008. Instead, you should use the wbadmin command and subcommands to back up and restore your computer and files from a command prompt. You cannot recover backups that you created with ntbackup by using wbadmin.
How to take systemstate backup.
To perform a system state backup, you must be a member of the Backup Operators group or the Administrators group, or you must have been delegated the appropriate permissions. In addition, you must run wbadmin from an elevated command prompt. (To open an elevated command prompt, click Start, right-click Command Prompt, and then click Run as administrator
Syntax: Wbadmin start systemstatebackup –backupTarget: <VolumeName>[-quiet]
Example: Wbadmin start systemstatebackup –backupTarget: F:
How to Restore Server 2008 Active Directory (non-authoritative)
1. On Server 2008 DC, open the command prompt on the server.
2. Run below commands to enter Directory Services Restore Mode (DSRM).                                          
 Bcedit / set safeboot dsrepair
 Shutdown –t 0 -r

Note: To manually boot in Directory Services Restore Mode, press the F8 key repeatedly. Do this immediately after BIOS POST screen, before the Windows logo appears. (Timing can be tricky; if the Windows logo appears you waited too long.) A text menu menu will appear. Use the up/down arrow keys to select Directory Services Restore Mode or DS Restore Mode. Then press the Enter key.
3. Login using administrator and DSRM password.
4. Run below command (note that e: is the drive letter of your backup), this will show you the version identifier of the backup.
Wbadmin get versions –backuptarget:e:
5. Run below command to start the restore.
Wbadmin start systemstaterecovery -version:10/08/2011-17:27–backuptarget :e:
6. After the restore process is completed, run following commands to reboot.
Bcedit /deletevalue safeboot
Shutdown –t 0 -r

How to Restore Server 2008 Active Directory if Someone Accidentally Deletes an Object. (Authoritative restore)
1.Restore Server 2008 Active Directory (non-authoritative), do not reboot the server
2. Open command prompt, run following commands, where CN=JIM,OU=HR,DC=TEST,DC=LOCAL is the object you wish to restore.
ntdsutil: activate instance ntds
Active instance set to “ntds”.
ntdsutil: authoritative restore
authoritative restore: restore object CN=JIM,OU=HR, DC=TEST,DC=LOCAL
3. Once it’s completed. Type quit
4. After the restore process is completed, run following commands to reboot.
     Bcedit /deletevalue safeboot
     Shutdown –t 0 -r

Original Post:

Universal groups, global groups, domain local groups

AD Group types: universal groups, global groups, domain local groups

Distribution Groups — Used for email. Useful for programs such as MS Exchange.
Security Groups – Used to secure file/folders, printers, etc.
Local – Stored on the local SAM (Local Computers)
Domain Local – Stored on Domain Controllers.
Global Groups – Gives you a greater group scope.
Universal – Gives you an even broader group scope.
Group Scopes
Group scope normally describes the type of users that should be clubbed together in a way that is easy for their administration. Therefore, groups play an important part in domain. One group can be a member of other group(s), which is known as Group nesting. One or more groups can be members of any group in the entire domain(s) within a forest.
  • Domain Local Group: Use this scope to grant permissions to domain resources that are located in the same domain in which the domain local group was created. Domain local groups can exist in all mixed, native, and interim functional level of domains and forests. Domain local group memberships are not limited as users can add members as user accounts and universal and global groups from any domain. Nesting cannot be done in a domain local group. A domain local group will not be a member of another Domain Local or any other groups in the same domain.
  • Global Group: Users with similar functions can be grouped under global scope and can be given permission to access a resource (like a printer or shared folder and files) available in local or another domain in the same forest. Simply put, global groups can be use to grant permissions to gain access to resources that are located in any domain but in a single forest as their memberships are limited. User accounts and global groups can be added only from the domain in which the global group is created. Nesting is possible in Global groups within other groups as users can add a global group into another global group from any domain. They can be members of a Domain Local group to provide permission to domain specific resources (like printers and published folder). Global groups exist in all mixed, native, and interim functional level of domains and forests.
  • Universal Group Scope: these groups are precisely used for email distribution and can be granted access to resources in all trusted domain as these groups can only be used as a security principal (security group type) in a windows 2000 native or windows server 2003 domain functional level domain. Universal group memberships are not limited like global groups. All domain user accounts and groups can be a member of a universal group. Universal groups can be nested under a global or Domain Local group in any domain. 
Universal Group: can contain users and groups (global and universal) from any domain in the forest.  Universal groups do not care about trust.  Universal groups can be a member of domain local groups or other universal groups but NOT global groups.
Global Group: can contain users, computers and groups from same domain but NOT universal groups.  Can be a member of global groups of the same domain, domain local groups or universal groups of any domain in the forest or trusted domains.
Domain Local Group:  Can contain users, computers, global groups and universal groups from any domain in the forest and any trusted domain, and domain local groups from the same domain.  Can be a member of any domain local group in the same domain.
The short answer is that domain local groups are the only groups that can have members from outside the forest. And use global groups if you have trust, universal groups if you don’t care about trust.
When do we need to use local, global and universal group permission?
Use global security groups to group user (or computer) accounts with similar characteristics, for example members of Sales department.
Use domain local security groups to define access to resources (share, NTFS, printer),
for example you would create domain local group “DL ColorPrinter Print” and assign print permission to this group. Then you would put global security group Sales in “DL ColorPrinter Print” group to enable printing for sales department. If marketing department wants to use the same printer you have to create global group Marketing and put this group in “DL ColorPrinter Print” group. This strategy is called A-G-DL-P. Put accounts in global groups, global groups in domain local groups and assign permissions to domain local groups and you will assign permission only once. Everything else happens in Active Directory Users and Computers when you modify groups memberships.
Universal groups should only be used in multiple domain forest. Universal groups are used to nest global groups. Group strategy is then called A-G-U-DL-P.
In shot below are the details
Global Groups:
Use these to group users with similar needs within the organisation, sales people, finance people, manager’s etc
Domain Local Groups:
Use these to specify access to resources e.g. database users, Colour Printer Users.
Universal Groups
Use only in mulitiple domains to give forest wide privileges.

Original Post:

How to determine your AD and Exchange Schema version

How to tell what version of AD/Exchange you have.
To find the current Active Directory Schema Version, you can use one of the following methods:
Note: The internal root domain that we use in this demo is: “ “.
1. Using “ADSIEdit.msc” or/and “LDP.exe” tools:

Navigate to:
and review the current “objectVersion” attribute.
  2. Using “DSQuery” command line:
 ”dsquery * cn=schema,cn=configuration,dc=domainname,dc=com -scope base -attr objectVersion
C:\Documents and Settings\nocadmin>dsquery * cn=schema,cn=configuration,dc=KINETICSYSTEMS,dc=Local -scope base -attr objectversion
 Note: Here the Objectversion is 31 and domain name is KINETICSYSTEMS.Local

The following information provide a mapping between the ”objectVersion” attribute value, to
the Active Directory Schema commutability:
 13 -> Windows 2000 Server
30 -> Windows Server 2003 RTM, Windows 2003 With Service Pack 1, Windows 2003 With Service Pack 2
31 -> Windows Server 2003 R2
44 -> Windows Server 2008 RTM
47-> Windows Server 2008 R2

 To find the current Exchange Schema Version, you can use one of the following methods:

 Note: The internal root domain that we use in this demo is: ““.
1. Using “ADSIEdit.msc ” or/and “LDP.exe” tools:

Navigate to:
and review the current “rangeUpper” attribute.
2. Using “DSQuery” command line:
dsquery * CN=ms-Exch-Schema-Version-Pt,cn=schema,cn=configuration,dc=domain,dc=com -scope base -attr   rangeUpper

 The following information provide a mapping between the ”rangeUpper” attribute value, to
the Exchange Schema commutability:
4397 -> Exchange Server 2000 RTM
4406 -> Exchange Server 2000 With Service Pack 3
6870 -> Exchange Server 2003 RTM
6936  -> Exchange Server 2003 With Service Pack 3
10628 -> Exchange Server 2007
11116 -> Exchange 2007 With Service Pack 1
14622->  Exchange 2007 With Service Pack 2

Original Post:

How to find and remove lingering objects in Active Directory

How to Troubleshoot Lingering Objects

Lingering Object : An object which has been deleted on a domain controller and even garbage collected but it still remains on another domain controller is termed as a Lingering Object
Some of the biggest annoyances for any Active Directory administrator are odd little things called lingering objects. These have existed since Windows 2000 Server and will probably never go away completely, although Microsoft has worked to give us some great tools to get rid of them and protect our domain controllers.
While there are already some good articles out there describing lingering objects, I’d like to put my own spin on the issue based on experiences I’ve had with them. I still find many Active Directory admins who either don’t understand what lingering objects are or don’t know what to do about them. Put simply, a lingering object is any Active Directory object that has been deleted, but gets reanimated when a DC has not replicated the change during the domain’s tombstone lifetime period.
Preventing Lingering Objects
Of course, it’s most desirable to prevent lingering objects from being created in the first place. There is a registry key called StrictReplicationConsistency — which we’ll refer to as Strict Mode — that will protect a DC from lingering objects:
ValueName = Strict Replication Consistency
Data Type = Reg_DWORD
Value Data = 1 = Strict 0=Loose
If this value is set to 1, it will prevent a partner from replicating lingering objects to the DC it is defined on. Thus, if every domain controller has Strict Mode enabled, they are protected from lingering objects
How to Find and Remove Lingering Objects in Active Directory
Event ID 1988 proves the presence of Lingering Object in the domain below is the example for the same.
Event Type:       Error
Event Source:   NTDS Replication
Event Category:               Replication
Event ID:            1988
Date:                     5/31/2011
Time:                    11:58:46 PM
User:                     NT AUTHORITY\ANONYMOUS LOGON
Computer:          EXCHANGE1
Active Directory Replication encountered the existence of objects in the following partition that have been deleted from the local domain controllers (DCs) Active Directory database.  Not all direct or transitive replication partners replicated in the deletion before the tombstone lifetime number of days passed.  Objects that have been deleted and garbage collected from an Active Directory partition but still exist in the writable partitions of other DCs in the same domain, or read-only partitions of global catalog servers in other domains in the forest are known as “lingering objects”.
This event is being logged because the source DC contains a lingering object which does not exist on the local DCs Active Directory database.  This replication attempt has been blocked.
 The best solution to this problem is to identify and remove all lingering objects in the forest.
Source DC (Transport-specific network address):
CN=932c938c-2b18-4704-bb6a-0bbe4ce02dacADEL:781d5c06-bdd9-4423-9772-2f51ef1763cc, CN=Deleted Objects, CN=Configuration, DC=rootcon, DC=local
Object GUID:
 User Action:
 Remove Lingering Objects:
 The action plan to recover from this error can be found at
 If both the source and destination DCs are Windows Server 2003 DCs, then install the support tools included on the installation CD.  To see which objects would be deleted without actually performing the deletion run “repadmin /removelingeringobjects <Source DC> <Destination DC DSA GUID> <NC> /ADVISORY_MODE”. The eventlogs on the source DC will enumerate all lingering objects.  To remove lingering objects from a source domain controller run “repadmin /removelingeringobjects <Source DC> <Destination DC DSA GUID> <NC>”.
If either source or destination DC is a Windows 2000 Server DC, then more information on how to remove lingering objects on the source DC can be found at or from your Microsoft support personnel.
 If you need Active Directory replication to function immediately at all costs and don’t have time to remove lingering objects, enable loose replication consistency by unsetting the following registry key:
Registry Key:
HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Strict Replication Consistency
Replication errors between DCs sharing a common partition can prevent user and compter accounts, trust relationships, their passwords, security groups, security group memberships and other Active Directory configuration data to vary between DCs, affecting the ability to log on, find objects of interest and perform other critical operations. These inconsistencies are resolved once replication errors are resolved.  DCs that fail to inbound replicate deleted objects within tombstone lifetime number of days will remain inconsistent until lingering objects are manually removed by an administrator from each local DC.
Lingering objects may be prevented by ensuring that all domain controllers in the forest are running Active Directory, are connected by a spanning tree connection topology and perform inbound replication before Tombstone Live number of days pass.For more information, see Help and Support Center at
The description of the Event ID 1988 is quite descriptive. It gives the following Information
1. The GUID of the source domain controller from where the lingering objects are coming.
Source DC (Transport-specific network address):

2. The DN of the Lingering Object (This piece of information is helpful in determining the location of the lingering object with respect to the naming context – domain partition, configuration partition , global catalog)
CN=932c938c-2b18-4704-bb6a-0bbe4ce02dacADEL:781d5c06-bdd9-4423-9772-2f51ef1763cc, CN=Deleted Objects, CN=Configuration, DC=rootcon, DC=local
 3. The event also gives the command that needs to be run to remove lingering objects
Repadmin /RemoveLingeringObjects <Name of the Source DC> <GUID of the DC which do not have the Lingering Objects>
Name of the Source DC: The Event ID 1988 mentions the GUID of the source DC. From this GUID, we need to get the name of that DC
GUID of the DC which do not have the Lingering Objects: DC on which we are getting Event ID 1988is the one on which we do not have the Lingering Objects.
Remember this; there is no “Bad” domain controller or “Good” domain controller. There is domain controller which has lingering objects and domain controller which do not have lingering objects. The presence of lingering objects does not make a domain controller “Bad”
Ping the GUID which is mentioned in the Event 1988. This is the GUID of the domain controller which has Lingering Objects. By pinging the GUID, we will get the name of the domain controller having lingering objects
C:\>ping 039c75ff-f65c-4f31-90b4-d68570ff4142._msdcs.rootcon.local
Pinging authserver.Rootcon. Local [] with 32bytes of data
pinging with 32 bytes of data:
Reply from bytes=32 time<1ms TTL=127
Reply from bytes=32 time<1ms TTL=127
Reply from bytes=32 time<1ms TTL=127
Reply from bytes=32 time<1ms TTL=127
Ping statistics for
                Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
                Minimum = 0ms, Maximum = 0ms, Average = 0ms
Now we need to get the GUID of the domain controller which does not have lingering objects. The domain controller on which we get 1988 is the one which does not have lingering objects. We can get the GUID of this domain controller from DNS.
As stated earlier, the Event ID 1988 contains the DN of the lingering object which can help us to identify the naming context (partition) in which we have the lingering objects
CN=932c938c-2b18-4704-bb6a-0bbe4ce02dacADEL:781d5c06-bdd9-4423-9772-2f51ef1763cc, CN=Deleted Objects, CN=Configuration, DC=rootcon, DC=local
To remove the lingering object run Repadmin /RemoveLingeringObjects
The same command can be run with “Advisory Mode” and without “Advisory Mode”
With “Advisory Mode”: This only shows the number and name of the Lingering Objects in the form of Events in the Event Viewer. This does NOT removes the Lingering Objects
C:\Documents and Settings\noc>repadmin /removelingeringobjects Authserver 04dc247f-cb35-43ac-8856-23f4603076b0 CN=configuration, DC=rootcon, DC=local/advisory_mode
RemoveLingeringObjects sucessfull on authserver.

Without “Advisory Mode”: This actually removes the Lingering Objects
Run the command on the domain controller on which you are getting the Event 1988
C:\Documents and Settings\noc>repadmin /removelingeringobjects Authserver 04dc247f-cb35-43ac-8856-23f4603076b0 CN=configuration, DC=rootcon, DC=local
RemoveLingeringObjects sucessfull on authserver.
Events gets generated after running the command with the “Advisory Mode”
Running the actual command without “Advisory Mode” in event log it shows that the Removal of Lingering Objects has begun. Finally Event stating that the Lingering Object has been Removed will be logged Directory Service.
Users on Authserver which were present in AD as Lingering Objects are now removed from the Active Directory.
To remove lingering objects from other Directory Partition below are the sample examples.
Repadmin /removelingeringobjects ServerName ServerGUID Directory Partition /advisory_mode .The distinguished name of the directory partition that is identified in the event message. For example,
 DC=rootcon, DC=local   for a domain directory partition,
 CN=configuration, DC=rootcon, DC=local   for the configuration directory partition, or CN=schema, CN=configuration, DC=rootcon, DC=local for the schema directory partition
C:\Documents and Settings\noc>repadmin /removelingeringobjects authserver 04dc24
7f-cb35-43ac-8856-23f4603076b0 DC=rootcon, DC=local
RemoveLingeringObjects sucessfull on authserver.
C:\Documents and Settings\noc>repadmin /removelingeringobjects authserver 04dc24
7f-cb35-43ac-8856-23f4603076b0 CN=configuration, DC=rootcon, DC=local
RemoveLingeringObjects sucessfull on authserver.
C:\Documents and Settings\noc>repadmin /removelingeringobjects authserver 04dc24
7f-cb35-43ac-8856-23f4603076b0 CN=schema, cn=configuration,DC=rootcon,DC=local
RemoveLingeringObjects sucessfull on authserver.
Reference KB article for lingering object:

Original Post:

Metadata Cleanup of a Domain controller

Delete orphan DCs from Active Directory
The following commands should be run to cleanup orphan domains and domain controllers.
At the command prompt, type ntdsutil
ntdsutil: metadata cleanup
Metadata cleanup: connections
Server connections: connect to server (i.e. the root forest domain controller) Binding to ……. Connected to using credentials of locally logged on user server connections: quit (You are now connected to the domain controller)
Metadata cleanup: select operation target
Select operation target: list domains
(Lists all domains in the forest) Found 7 domains(s)
0 – DC=yourserver, DC=yourdomain, DC=com
1 – DC=……….. (Listing of all domains in the forest)
Select operation target: select domain x
(Where x is the number of the domain to be deleted and/ or where the domain controller to be deleted is located) No current site
Domain – DC=….. No current server
No Current Naming Context
Select operation target: list sites
Found 1 site(s)
0 – CN=yoursite, CN=Sites, CN=Configuration, DC=yourserver, DC=yourdomain, DC=com
Select operation target: select site x
(Where x is the number of the site where the domain and/or the domain controller to be deleted is located)
Site – CN=yoursite, CN=Sites, CN=Configuration, DC=yourserver, DC=yourdomain, DC=com
Domain – DC=……..
No current server No current Naming Context
Select operation target: list servers in site
Found 6 server(s) 0 – CN=……… 1 – CN=………. (Listing of all servers found in the site selected)
Select operation target: select server x
(Where x is the number of the server to be deleted from the list displayed in the previous operation)
Site – CN=yoursite, CN=Sites, CN=Configuration, DC=yourserver, DC=yourdomain, DC=com
Domain – DC=……
Server – CN=…….
DSA object – CN=NTDS Settings, CN=…….. (Display of the domain, server and settings for the domain controller to be deleted)
No current Naming Context
select operation target: quit
Metadata cleanup: remove selected server
“CN=……..” server being removed (A popup window is also displayed verifying you really want to delete this domain controller) removed from server “” (verifies the removal of the domain controller) metadata cleanup: remove selected domain
“DC=…….” removed from server “” (verifies the removal of the domain)
Note: At this point, Active Directory confirms that the domain controller was removed successfully. If you receive an error that the object could not be found, Active Directory might have already removed from the domain controller.
Metadata cleanup: quit
Ntdsutil: quit
Disconnecting from …………
To remove the failed server object from the sites
1. In Active Directory Sites and Services, expand the appropriate site.
2. Delete the server object associated with the failed domain controller.
To remove the failed server object from the domain controllers container
1. In Active Directory Users and Computers, expand the domain controllers container.
2. Delete the computer object associated with the failed domain controller.
To remove the failed server object from DNS
1. In the DNS snap-in, expand the zone that is related to the domain from where the server has been removed.
2. Remove the CNAME record in the _msdcs.root domain of forest zone in DNS. You should also delete the HOSTNAME and other DNS records.
3. If you have reverse lookup zones, also remove the PTR record of the server from these zones.
For more details refer below articles:

Original Post:

Step-By-Step: Learn how to transfer and seize FSMO roles in Active Directory

Windows administrators know that one of the most important aspects involved with managing Active Directory is understanding the various roles that servers need to play. Previously, I discussed the functions of the five flexible single-master operations (FSMO) roles in Active Directory. Now I'm going to talk about the placement of those roles within the forest and domain, and explain how to go about moving those roles to other domain controllers, either by transferring them or seizing them.

Placing FSMO roles in the network
As I mentioned in the first article, the two forest-level roles—schema master and domain naming master—are installed by default on the first domain controller in the forest. The three domain-level roles—RID master, PDC emulator, and infrastructure master—are all installed by default in the first domain controller in the domain.

In a small office with one domain, it is very likely that all five roles are found on a single domain controller. But in a large enterprise network, you should not allow that to happen. It's best to make sure that the two forest-level roles are located in their own domain controller, with domain-level roles separate from them. If you choose to install the roles on more than one domain controller, those DCs should be replication partners.

At the same time, you can't ignore the domain controllers that host the global catalog. Remember that the domain-naming master must be on a DC hosting the global catalog. Not only that, but the infrastructure master must not be on a DC hosting the global catalog. (The only exception to that is if all the DCs are global catalog servers, which should not be the case in an enterprise network.) There are numerous ways you may decide to place your FSMO roles. Figure A shows one example.

Figure A

Transferring roles
There are two basic reasons for moving an FSMO role from one DC to another. One reason is because you want to. That is, the movement is planned for some reason, such as decommissioning a server that holds one or more of the FSMO roles. When you are carrying out a planned move, it is called transferring the role.

The other reason to move a role is because you have to. For instance, you might be forced to move a role when a server that holds one or more FSMO roles has suffered catastrophic hardware failure. When you carry out an unplanned move, it is called seizing the role. You should never seize a role unless you absolutely have to.

Transferring a role can be done either through the graphic user interface (GUI) or through the command line interface (CLI), while seizing a role can only be carried out via the command line.

Whether done through the GUI or the CLI, moving a role is done in two steps:
  1. Connect to a domain controller
  2. Transfer or seize the role

Let's first look at transferring a role through the GUI. After that, I'll show you how it's done using the CLI.

Using the GUI
To change a domain-level role, click on Start | Administrative Tools | Active Directory Users And Computers. Next, as shown in Figure B, right-click on the domain and then select Connect To Domain Controller…

Figure B

Next, you will see a dialog box in which you can specify to which DC you want to connect (see Figure C).

Figure C

Once you have connected to the domain controller to which you will transfer a role, right-click once again on the domain and select "Operations Masters…" This will bring up the dialog box you see in Figure D.

Figure D

This dialog box will allow you to transfer a domain-level role from one DC to another, provided that you have already connected to that DC. If you have not connected to the DC, the same name will appear in both boxes. To change a forest-level role, click on Start | Administrative Tools | Active Directory Domains and Trusts.

Next, as shown in Figure E, right-click on Domains and Trusts, and then select Connect To Domain Controller…

Figure E

Once you have connected to the other DC, right-click once again on Active Directory Domains And Trusts, and select Operations Master… This will bring up a dialog box (see Figure F) similar to the one you used to transfer a domain-level role.

Figure F

Using the command line interface
You can perform all of these same operations from the command line, using the Active Directory Diagnostic Tool, ntdsutil.exe. This tool is interactive, in that, when you invoke it, you have several submenus at your disposal. In this case, since I am talking about transferring and seizing roles, I will use the "Roles" submenu.

To do that, type "ntdsutil" at the command line. The prompt will then change to reflect the current level of the menu. In this case, at the "ntdsutil" prompt, you would type "roles." The command prompt will then change to FSMO Maintenance (as you'll see below in Figure G).

The commands available from the Roles submenu are:
  • Connections
  • Seize domain naming master
  • Seize infrastructure master
  • Seize PDC
  • Seize RID master
  • Seize schema master
  • Select operation target
  • Transfer domain naming master
  • Transfer infrastructure master
  • Transfer PDC
  • Transfer RID master
  • Transfer schema master

Figure G illustrates using the tool to make a connection to another domain controller.

Figure G

Figure H illustrates using ntdsutil to transfer a role.

Figure H

Seizing a role
Transferring can only be done if the original DC is alive on the network. If a domain controller hosting a single operations master role is no longer available (possibly due to catastrophic failure), you will not be able to transfer that role to another domain controller. If that is the case, then you can move that role to another DC by seizing the role.

Seizing a role can only be done through the command line interface using ntdsutil.exe. It is extremely important to remember two things about seizing FSMO roles:
  1. Never seize a role unless it is your last resort. If a DC hosting a role is only going to be down temporarily, don't worry about it. Your network will survive a short time without it.
  2. If either the schema master, domain naming master, or RID master role is seized from a domain controller, that domain controller must never be allowed to come back online.

Take FSMO roles seriously
Networks using Active Directory still tend to be relatively young, so in all likelihood there has been very little need for administrators to concern themselves much with FSMO roles up until now. But as the network ages and it comes time for servers to be replaced, great care will need to be taken to preserve the integrity of those roles. At some point, domain controllers hosting FSMO roles will need to be replaced. Admins will need to understand where the roles are located and how to transfer the roles if an outage is planned, or how to seize a role if the outage is unplanned.

Original Post:

What happens when FSMO roles fails?

each one of them fails then below are the effects of the same:-

Schema Master - Schema updates are not available - These are generally planned changes and the first step when doing a schema change is normally something like "make sure your environment is healthy". There isn't any urgency if the schema master fails, having it offline is largely irrelevant until you want to make a schema change.

Domain Naming Master - No new domains or application partitions can be added - This sort of falls into the same "healthy environment" bucket as the schema master. When we upgraded the first DC to a beta Server 2003 OS which included the code to create the DNS application partitions, we couldn't figure why they weren't instantiated until we realized that the server hosting the DNM was offline (being upgraded) at the same time. Infrastructure Master - No cross domain updates, can't run any domain preps - Domain preps are planned (again). But no cross-domain updates. That could be important if you have a multi-domain environment with a lot of changes occurring.

RID Master - New RID pools unable to be issued to DC's - This gets a bit more complicated, but let me see if I can make it easy. Every DC is initially issued 500 RID's. When it gets down to 50% (250) it requests a second pool of RID's from the RID master. So when the RID master goes offline, every DC has anywhere between 250 and 750 RIDs available (depending on whether it's hit 50% and received the new pool).

PDC - Time, logins, password changes, trusts - So we made it to the bottom of the list, and by this point you've figured that the PDC has to be the most urgent FSMO role holder to get back online. The rest of them can be offline for varying amounts of time with no impact at all. Users may see funky behavior if they changed their password, but replication will probably have completed before they call the help desk so nothing to worry about, and trust go back to that whole "healthy forest" thing again.

How to transfer or seize FSMO roles

How to transfer or seize FSMO roles

The first Microsoft Windows 2000 Active Directory (AD) domain controller in a forest is granted five FSMO roles when you run the Dcpromo.exe program and install the AD. There are two FSMO roles that are forest wide and three that are per domain. If child domains are created, the two forest wide roles do not change. A forest with two domains would have eight FSMOs; two for the forest and three domain specific FSMO roles in each domain.
The five FSMO roles are:
• Schema master – Forest wide and one per forest.
• Domain naming master – Forest wide and one per forest.
• RID master – Domain Specific and one for each domain.
• PDC emulator – Domain Specific and one for each domain.
• Infrastructure master – Domain Specific and one for each domain.
If you only have one server (like SBS) it holds all the roles, if you have multiple domain controllers there is a chance that the roles have been divided to other servers (by whomever installed the forest…).
In order to find out which server holds which role you can use the following command on one of the servers:
Ntdsutil roles Connections “Connect to server<ServerName> ” Quit “select Operation Target” “List roles for connected server” Quit Quit Quit
**replace <ServerName> with the name of one of your DC’s
Open command prompt and type netdom query fsmo
To move the FSMO roles from one computer to another, you can use two different methods. You can use the first method if both computers are running. This method is a Transfer and is the method that is recommended. Use the second method if the FSMO roles holder is offline. The second method requires you to use the Ntdsutil.exe tool to seize the roles.
NOTE: Only seize the FSMO roles to the remaining Active Directory domain controllers if you are removing the FSMO role holder from the domain or forest.
Transfer FSMO roles
To transfer the FSMO roles by using the Ntdsutil utility, follow these steps:
1. Log on to a Windows 2000 Server-based or Windows Server 2003-based member computer or domain controller that is located in the forest where FSMO roles are being transferred. We recommend that you log on to the domain controller that you are assigning FSMO roles to. The logged-on user should be a member of the Enterprise Administrators group to transfer Schema master or Domain naming master roles, or a member of the Domain Administrators group of the domain where the PDC emulator, RID master and the Infrastructure master roles are being transferred.
2. Click Start, click Run, type ntdsutil in the Open box, and then click OK.
3. Type roles, and then press ENTER.
Note To see a list of available commands at any one of the prompts in the Ntdsutil utility, type? and then press ENTER.
4. Type connections, and then press ENTER.
5. Type connect to server servername, and then press ENTER, where servername is the name of the domain controller you want to assign the FSMO role to.
6. At the server connections prompt, type q, and then press ENTER.
7. Type transfer role, where role is the role that you want to transfer. For a list of roles that you can transfer, type? at the fsmo maintenance prompt, and then press ENTER, or see the list of roles at the start of this article.
For example,
To transfer the Domain Naming master role, type transfer naming master
To transfer the infrastructure master role, type transfer infrastructure master
To transfer the Domain Naming master role, type transfer pdc
To transfer the RID master role, type transfer rid master
To transfer the Domain Naming master role, type transfer schema master
Note: The one exception is for the PDC emulator role, whose syntax is transfer pdc, not transfer pdc emulator.
8. At the fsmo maintenance prompt, type q, and then press ENTER to gain access to the ntdsutil prompt. Type q, and then press ENTER to quit the Ntdsutil utility.
Seize FSMO roles
To seize or transfer the FSMO roles by using Ntdsutil, follow these steps:
2. Click Start, click Run, type ntdsutil in the Open box, and then click OK.
3. Type roles, and then press ENTER.
4. Type connections, and then press ENTER.
5. Type connect to server servername, and then press ENTER, where servername is the name of the domain controller you want to use.
6. At the server connections prompt, type q, and then press ENTER.
7. Type seize role, where role is the role that you want to seize. At the fsmo maintenance prompt, and then press ENTER,
For example,
To seize the Domain Naming master role, type seize naming master
To seize the infrastructure master role, type seize infrastructure master
To seize the Domain Naming master role, type seize pdc
To seize the RID master role, type seize rid master
To seize the Domain Naming master role, type seize schema master
Notes• Under typical conditions, all five roles must be assigned to “live” domain controllers in the forest. If a domain controller that owns a FSMO role is taken out of service before its roles are transferred, you must seize all roles to an appropriate and healthy domain controller.
If the domain controller that formerly held any FSMO role is not present in the domain and if it has had its roles seized by using the steps in this post, remove it from the Active Directory by following the procedure that is outlined in the following Microsoft Knowledge Base article: 216498 ( How to remove data in active directory after an unsuccessful domain controller demotion.

Original Post:

Active Directory Group Scope - Local Domain, Global Group, Universal Group

Domain Local-

You can add members from any domain in your forest but you can give them access to the resources which are available only in  the domain where you create this DL.


You can add members only from the domain where you create this DL, and this DL can be given acess to any resources in any other domains in the forest.
For ex, you have Domain A and B. Your users in domain A , need to access a resource in Domain B. How to accomplish this?
From your domain A ,create a Global DL--- create a Domain Local DL in domain B. Add the Domain 'A's Global DL as a member to the Domain B's Domain Local Group.. Give access to the resource in Domain B. It's done..


Add members from any domain, access resources in any domain of the forest.

Hope it helps.. :)

How to verify that SRV DNS records have been created for a domain controller

This article applies to a different version of Windows than the one you are using. Content in this article may not be relevant to you. Visit the Windows 7 Solution Center
For a Microsoft Windows 2000 version of this article, see 241515.


This article describes how to verify Service Location (SRV) locator resource records for a domain controller after you install the Active Directory directory service.


The SRV record is a Domain Name System (DNS) resource record that is used to identify computers that host specific services. SRV resource records are used to locate domain controllers for Active Directory. To verify SRV locator resource records for a domain controller, use one of the following methods.

DNS Manager

After you install Active Directory on a server running the Microsoft DNS service, you can use the DNS Management Console to verify that the appropriate zones and resource records are created for each DNS zone.

Active Directory creates its SRV records in the following folders, where Domain_Name is the name of your domain:
Forward Lookup Zones/Domain_Name/_msdcs/dc/_sites/Default-First-Site-Name/_tcp Forward Lookup Zones/Domain_Name/_msdcs/dc/_tcp

In these locations, an SRV record should appear for the following services:


If you are using non-Microsoft DNS servers to support Active Directory, you can verify SRV locator resource records by viewing Netlogon.dns. Netlogon.dns is located in the %systemroot%\System32\Config folder. You can use a text editor, such as Microsoft Notepad, to view this file.

The first record in the file is the domain controller's Lightweight Directory Access Protocol (LDAP) SRV record. This record should appear similar to the following:


Nslookup is a command-line tool that displays information you can use to diagnose Domain Name System (DNS) infrastructure.
To use Nslookup to verify the SRV records, follow these steps:
  1. On your DNS, click Start, and then click Run.
  2. In the Open box, type cmd.
  3. Type nslookup, and then press ENTER.
  4. Type set type=all, and then press ENTER.
  5. Type _ldap._tcp.dc._msdcs.Domain_Name, where Domain_Name is the name of your domain, and then press ENTER.
Nslookup returns one or more SRV service location records that appear in the following format, where Server_Name is the host name of a domain controller, and where Domain_Name is the domain the domain controller belongs to, and Server_IP_Address is the domain controller's Internet Protocol (IP) address:
Server: localhost
SRV service location:
 priority = 0
 weight  = 100
 port  = 389
 srv hostname = Server_Name.Domain_NameServer_Name.Domain_Name  internet address = Server_IP_Address


For more information about the SRV records that are registered by Netlogon, please see the "SRV Records Registered by NetLogon" section in the TechNet document How DNS Support for Active Directory Works. To view this document, visit the following Microsoft web site:

Original Post:

Use Wireshark to inspect packets on your network

Takeaway: Scott Reeves illustrates how you can use Wireshark to inspect packets, looking specifically at various points in the OSI layer, to troubleshoot network issues.

I’ve been using Wireshark in a number of my posts to show aspects of network performance and to illustrate areas of TCP/IP such as the three way TCP handshake. This week, I thought I’d delve a little more into Wireshark itself and illustrate how the OSI layer works.
Two previous posts have shown the TCP three-way handshake (see, for example, my previous post “Using jperf and Wireshark for troubleshooting network issues“), so I will omit covering it in this post. What I will do is draw attention to the way you can look inside a packet captured using Wireshark. For this example, I used a capture of a network session run using a jperf client and a server. Figure A is a sample from this capture.

Figure A

Click to view larger versions of images.
Looking at Figure A, you can see that the first line shows a summary of the frame. The other lines show the data link layer, the network layer, the transport layer, and finally, the actual data contained within the frame. I will step through each line in order.
One note before beginning: Wireshark will highlight the bytes in hex in the bottom pane (as shown in Figure A). You can change this to binary if desired.

Data Link

Figure B

Moving to the Ethernet layer (shown in Figure B), we can see that it is pretty simple. It contains a destination address and a source address. The data link layer is relatively simple in that it is only concerned with getting a frame to the next adjacent node on the physical medium. The main point of interest is the Organizational Unique Identifier (OUI), which takes up the first three bytes of an Ethernet address. The IEEE assigns the OUI to manufacturers of Ethernet equipment. If you want to take a look at assigned OUIs, the list is maintained at
Wireshark makes it easy for you to check on the manufacturer of a card; you can highlight the field (as shown in Figure B) and extract the OUI. You can then plug the number into the website,, and obtain the manufacturer.


The Ethernet layer is concerned with node to node. The IP layer is concerned with moving between networks, hence the original meaning of the term internetwork, from whence Internet was derived. Highlighting the network layer shows more details. From Figure C, we can see the source and destination IP addresses as well as the IP header length (20 bytes in this case).

Figure C

We can also see the Differentiated Services (DiffServ) area. This would be where extra information relating to the packet’s type of service goes. For most packets on a LAN this is set to zero, which means best effort. There are several other levels, such as Expedited Forwarding, which generally has low loss, low delay, and low jitter. Diff Serv levels can be used when looking to implement a Quality of Service on IP networks.


The transport layer is where applications communicate via the use of ports. Looking at the capture shown in Figure D, we can see that the source port is 40519, while the destination port is 5001.

Figure D

Other areas of interest are the header length (32 bytes in this case) and the sequence number.  The sequence number generally will change for each packet.


The final part of the capture is the data part; this is shown in Figure E. Here you will see what data is being sent over the medium. This is where you will find applications such as ssh are very important: using ssh means that a login name and password are encrypted.  In contrast, rsh and rlogin are not encrypted; data is sent in clear text, meaning that you can capture a packet and read the login name and/or password from the data section of the captured packet.

Figure E


The size of the data part of the frame is 1448 bytes in this case. There is some overhead due to the headers used by TCP, IP and Ethernet. From Figure E, we can see that the actual frame size is 1514 bytes, whereas the size of the data is 1448 bytes. The overhead in this case is 64 bytes. Of this, 12 bytes is Ethernet, 20 bytes is IP and 32 bytes is TCP.
Wireshark offers many other features, other than the ability to inspect frames. This post touches on how to look at various points in the OSI layers, which can act as an aid in troubleshooting network problems. It can also help you to understand what sort of traffic is going over the network.

Original Post:

Thursday, September 27, 2012

What are DDoS Attacks & How to Deal with them

The internet is abuzz with talks of the recent outage faced by Domain Registrar Godaddy. The outage was suspected to be because of a Distributed Denial of Service Attack (commonly known as a DDoS attack) that targeted Godaddy’s DNS servers, affecting several websites as well as email services. (However, a recent statement by Godaddy mentions that it was an internal network error that caused the interruption in services)
DDoS attacks are a fairly common occurrence on the internet and are something we’ve experienced in the past as well. Here is some more information on DDoS attacks, who they affect and how we mitigate such attacks.
What is a DDoS attack?
A Denial of Service attack aims to make a website unavailable to users by flooding the website’s servers with an extremely high number of requests. These multiple incoming requests can make website resolution exceedingly slow and can even cause servers to crash.
A Distributed Denial of Service (DDoS) attack is essentially a DoS attack that originates from multiple sources. Such attacks are usually carried out using thousands of unsuspecting zombie machines known as botnets.
DDoS attacks have traditionally been used by cyber criminals to extort money from website owners that rely on the accessibility of their websites. However ‘Hacktivists’ have also initiated such attacks in the past to bring down company and government websites in protest of certain policies or decisions.
A  popular recent example is anonymous’ attack in protest of the Megaupload Raids that targeted various government and music industry sites.
Who can it affect?
DDoS attacks are difficult to safeguard against completely and can affect large and small websites alike.
Having suffered a DDoS attack on our DNS servers in the past, we understand that such attacks can occur and the best solution is to have systems in place that allow you to mitigate the attack and get systems back online as soon as possible.
Which leads us to – How do we mitigate DDoS attacks?
While there isn’t a lot that can be done to prevent DDoS attacks, there are certain techniques that we employ to mitigate DDoS attacks and restore services.
To help mitigate DDoS attacks we’ve employed the services of Prolexic Technologies that is a global leader in DDoS Protection & Mitigation. While there are multiple ways in which Prolexic helps mitigate DDoS attacks, here is a simplified version of how Prolexic works.
  • BGP Routing:
    With BGP routing, when a DDoS attack occurs, our traffic gets routed through Prolexic’s servers where malicious and legitimate traffic is segregated and legitimate users can continue to access our services.
  • Advanced Filtering:
    As the traffic gets routed through Prolexic’s servers, their filtering technology identifies anomalies which are then “red flagged” by the system. Moreover, research is then conducted by Prolexic engineers to determine whether this activity should be blocked on the network. Once malicious activity has been determined, it is labeled in the system and blocked.
How can you independently mitigate attacks?
As a individual website owner you have limited control over a server but you can use CloudFlare to protect your websites from attacks.
CloudFlare protects your websites by routing traffic through their intelligent global network – a little like what Prolexic does for us :)
We already provide CloudFlare on our Hosting servers so Resellers can enable and start using it immediately. More information on how CloudFlare can protect you can be found here -
How Web Hosting Providers should deal with a DDoS Attack:
DDoS attacks are a very real threat to website owners and hosts worldwide but like I said before, there is no foolproof way for anyone to really protect themselves against such an attack.
As a Web Hosting provider yourself, I’m sure you’ve come across Customers that consider leaving you in the aftermath of a DDoS attack. You might have felt the same of your upstream provider as well. However, it’s important to remember that anyone can be a target.
An indicator of a good Host isn’t one that hasn’t been attacked yet but one that can effectively restore services and reduce damage.
How Web Hosts handle the situation is also an important indicator. I’ve always seen that the ones that do handle attacks effectively provide detailed information on the following: (This actually applies to most issues/interruption in services)
  1. Which services were affected?
  2. Are the services back up or how long will it take to restore services?
  3. Does the Client need to do anything?
  4. Why did this happen i.e. details of the DDoS attack
  5. How was the attack mitigated?
  6. Can this happen again?
  7. Who can Clients contact if they have any concerns?
Being honest and straightforward will go a long way in assuring your Customers that you’re doing everything you can to resolve the issue and they’ll respect you for keeping them in the loop.

So there you have it – everything you need to know about DDoS Attacks and how you can deal with them! I’d love to know what you think so do comment and let me know your thoughts.

Original Post

Friday, September 21, 2012

Windows Memory Dump

Windows Memory Dump

Hello Techies,

It is very often we see the blue screen on the Microsoft based OS.Basically we called this blue screen as 
Blue Screen Of Death (BSOD).

I have asked the question "what is BSOD" from many guys during the interviews but usually they replied
that it happened due to RAM or HDD failure, they simply reply that in this case they will replace either RAM or HDD to fix this issue on the server. 

So today i will give a idea about this BSOD and how to analyze this issue on windows platform.

->What is BSOD ?
->The Blue Screen of Death , displayed by the Microsoft Windows family of operating systems upon encountering a critical error,of a non-recoverable nature, that causes the system to crash.Stop errors are hardware or driver related, causing the computer to stop responding in order to prevent damage to the hardware or data.

->Type of memory dump ?
->There are three type of dumps created

1. Complete Memory Dump
2. Kernal Memory Dump
3. Small Memory Dump

1. Complete Memory Dump:-A Complete Memory Dump is the largest kernel-mode dump file. This file contains all the physical and virtual memory for the machine at the time of the fault.If you select the complete memory dump option, you must have a paging file on the boot volume The Complete Memory Dump file is written to %SystemRoot%\Memory.dmp by default.The Complete memory dump option is not available on computers that are running a 32-bit operating system and that having 2 gigabytes (GB) or more of RAM (by default).

2. Kernal Memory Dump:  A Kernel Memory Dump contains all the memory in use by the kernel at the time of the crash.The dump file will be around one-third the size of the physical memory on the system. This dump will not include unallocated memory or any memory allocated to applications. It only includes memory allocated to Windows kernel.The Kernel Memory Dump file is written to %SystemRoot%\Memory.dmp by (default)

3. Small Memory Dump:- A Small Memory Dump is much smaller than the other two crash dump files. It is exactly 64 KB in size (128KB on 64-bit systems) .This kind of dump file can be useful when space is greatly limited. However, it contains very less information for the reason of the crash.

                              How to enable memory dump on a windows server

Here i am going to configure the memory dump on Win-7/server 2008

1. Right click on my computer and click on properties then click on 2. Advance system setting option on left side ,then click on 3. Advance tab, Now click on 4. setting under Startup and recovery.Below are the screenshot

Same you can configure from the registery as well from the location as mentioned below

All the things that you can configure via GUI can be configured via registery as well.

  • Write an event to the System Log checkbox = LogEvent
  • Automatically Restart checkbox = AutoReboot
  • Write Debugging Information drop-down = CrashDumpEnabled
  • Dump File text box = DumpFile
  • Overwrite any existing file checkbox = Overwrite 

                              How to Crash the server manually using keyboard

Now you have configured the memory dump on the server and now you can check as well if it is creating the memory dump file on the server or not.Also when you need to create memory dump file manually after a crash ,do the following to configure the same.

Using PS/2 keyboard :-

1. Start Registry Editor.
2. Locate the following registry subkey:


3. On the Edit menu, click Add Value, and then add the following registry entry:

Name: CrashOnCtrlScroll
Data Type: REG_DWORD
Value: 1

4. Exit Registry Editor, and then restart the computer.

 Using USB keyboad:

1. Start Registry Editor.
2. Locate the following registry subkey:


3. Make sure that the following registry entry is enabled:

Name: CrashOnCtrlScroll
Data Type: REG_DWORD
Value: 1

4. Exit Registry Editor.

If You can generate a system memory dump by holding down the right CTRL key and pressing the SCROLL LOCK key twice. (Ctrl+Scroll lock twice)

Note: Pressing left CTRL key does not generate the system memory dump.

Will come with new Blog shortly on How to Analyze the memory dump....... ;)

Original Post: