karthik's blog

2019-02-02T21:50:00.001+05:30

How to convert Windows error code into Simple English decription

2013-11-08T19:21:00.000+05:30

While troubleshooting, most of the times you can see Windows OS is throwing error in Hexadecimal code. You may find this error in event viewer or msi logs, or CBS logs. Most of the time there wont be any description for this error code in the logs or events. You can convert this error codes into Simple error description. Here I am going to show how to do this. Lets take the below error code as an example.

You can see from the above error message that calling of vbscript.dll was failed with error code 0x80004005. The error code is in Hexadecimal. You have to convert the code into decimal before finding out its error description. Lets convert the code 0x80004005 in to decimal. You donot need to convert whole number into decimal. Take only last four or three last digits from the error code. Here we are going to convert last 3 digit of the error code "005".

Open the calculator in Programmer mode.

Enter the value in Hexadecimal

Click on Decimal to get the decimal value

Copy the decimal value. Open a command prompt and run the command net helpmsg <decimalnumber>
in our example command will be net helpmsg 5

You can see the error description for decimal value 5 as "Access is denied". You can further investigate the issue according to the error description. There might be permission issue to access the regitsry location of vbscript.dll in our example, hence the windows throwed the error. Below are some more error codes and its description

0x80070490 - Element not found.

0x80004005 - Access is denied.

0x8007054f - An internal error occurred.

0x80070bc2 - The requested operation is successful. Changes will not be effective until the system is rebooted.

0x80070643 - Fatal error during installation.

resolution for “Unable to Start Windows Event Log service”.

2013-09-20T14:45:00.000+05:30

resolution for “Unable to Start Windows Event Log service”.

When you try to start the Windows Event Log service from the services console on
either Windows Server 2008 computers, the Windows Event Log service fails.
Additionally, you receive the following error message:
"Error 5: Access denied"
CAUSE

This problem happens if any of the following conditions are true.
1. The built-in security group EventLog missing permission on folder
C:\Windows\System32\winevt\Logs
2. Local Service account do not have default permission on registry key
HKLM\Software\Microsoft\Windows\CurrentVersion\Reliability

*** Resolution ***

Default permissions on C:\Windows\system32\winevt\logs Folder should be

Authenticated user - List folder/read data, Read attributes, Read Extended
attributes, Read permissions
Administrators - Full control
SYSTEM - Full control
EventLog - Full control

To restore default permissions on folder "C:\Windows\system32\winevt\logs", follow
these steps.

1. Right click on C:\Windows\system32\winevt\logs and select properties.
2. Select the security tab.
3. Click Edit button and click Add button in permissions dialog box.
4. In Select users, computers, or Groups dialog box ensure that under object types
Built in Security Principals and the location as local computer name is selected.
5. Enter the object name as "NT SERVICE\EventLog" without quotes. And click OK.
This group should have full control on the folder.
6. Once EventLog group is added add the rest of the groups with above mentioned
permissions.
7.start the service

Microsoft Clustering

2013-09-20T14:41:00.001+05:30

Microsoft provides two types of cluster:
1. Network load balancing
2. Windows Fail over cluster (For 2008 on wards servers), Microsoft Cluster service (For 2003 and before servers).
First one is to distribute the network traffic on servers Using virtual IP address.

NLB (Network Load Balancing)
Suppose there are two nodes in NLB , both the nodes will host the website. Client accessing the website will be redirected to anyone of the node depending upon configuration of NLB (By default it works on round robin methods)

Microsoft Cluster Service (MSCS)

Unlike NLB , in MSCS, resource will be online at only one of the nodes at a time .
Microsoft Cluster Service is based on the shared-nothing clustering model. The shared-nothing model dictates that while several nodes in the cluster may have access to a device or resource, the resource is owned and managed by only one system at a time.

There are mainly three Components of MSCS:
1.Cluster service
2. Resource monitor
3.Resource DLL.

Suppose You have cluster software to install, inside cluster server you will have these three components along with cluster administrator (GUI to manage the cluster.)

Cluster service:
The Cluster Service is the core component and runs as a high-priority system service. The Cluster Service controls cluster activities and performs such tasks as coordinating event notification, facilitating communication between cluster components, handling fail over operations and managing the configuration. Each cluster node runs its own Cluster Service.

Resource Monitor

The Resource Monitor is an interface between the Cluster Service and the cluster resources, and runs as an independent process. The Cluster Service uses the Resource Monitor to communicate with the resource DLLs.

Resource DLL
Every resource uses a resource DLL, through that DLL it communicates to Cluster service using Resource monitor.

How this cluster works:

Suppose we have two node MSCS cluster:
One which is owning the resource will be the active node.
Another one which is on stand by will be the passive node.

In a server cluster, only one node is active at a time. The other node or nodes are placed in a sort of stand by mode. They are waiting to take over if the active node should fail. The reason that it is possible for a node to take over running an application when the active node fails is because all of the nodes in the cluster are connected to a shared storage mechanism.
One of the shared storage in a cluster works as quorum.
What is a Quorum?

To put it simply, a quorum is the cluster’s configuration database. Although the quorum is just a configuration database, it has two very important jobs. First of all, it tells the cluster which node should be active.
It is extremely important for nodes to conform to the status defined by the quorum. It is so important in fact, that Microsoft has designed the clustering service so that if a node can not read the quorum, that node will not be brought online as a part of the cluster.
The other thing that the quorum does is to intervene when communications fail between nodes. Normally, each node within a cluster can communicate with every other node in the cluster over a dedicated network connection. If this network connection were to fail though, the cluster would be split into two pieces, each containing one or more functional nodes that can not communicate with the nodes that exist on the other side of the communications failure.
When this type of communications failure occurs, the cluster is said to have been partitioned. The problem is that both partitions have the same goal; to keep the application running. The application can’t be run on multiple servers simultaneously though, so there must be a way of determining which partition gets to run the application. This is where the quorum comes in. The partition that “owns” the quorum is allowed to continue running the application. The other partition is removed from the cluster.

Quorum is the basic concept to understand the cluster.
For Pre requirements , installation, and details of cluster you can refer to technet articles.

Windows Fail over cluster (For 2008 on wards servers):
In fail over cluster lots of changes has been done from MSCS.
1. Quorum Model has been changed.
2. In MSCS Cluster service was running under user account but in fail over cluster 2008 it has been changed to Local.
In Windows Server 2008 Fail over Clusters, the cluster service no longer runs in the context of a domain user account. Instead, the cluster service runs in the context of a local system account that has restricted rights to the cluster node.
During the Create Cluster process, a computer object is created in Active Directory Domain Services. This computer object is known as the Cluster Name Object (CNO).
The CNO creates all other Network Name resources that are created in a Failover Cluster as part of a Client Access Point (CAP). These Network Name resources are known as Virtual Computer Objects (VCOs).
3. Support of DHCP ip.
4. Can validate two servers before creating cluster using Validation tool.
5. Increased number of nodes.

Quorum Model :

Clustering supports four quorum modes. They are:
Node Majority,
Node and Disk Majority,
Node and File Share Majority, and
Majority: Disk Only (Legacy).
In failover cluster 2008 ,there is no particular quorum disk , in fact there are two witness resources who participates in voting along with nodes of the cluster.

-----------------------------------------------------------------------------------------------------------------------------
• Disk Witness Resource – A clustered disk can contribute towards the cluster’s quorum. This disk resides in the cluster group. Besides providing a vote for the quorum, this resource serves two other critical functions.
o Stores a constantly-updated version of the cluster database. This allows the cluster to maintain its state and configuration independently of individual node failures, which ensures that nodes will always have the most up-to-date copy of the database.
o The quorum resource enforces cluster unity, preventing the “split-brain” scenario described earlier.
• File Share Witness (FSW) Resource – A file share accessible by all nodes of the cluster can contribute to the cluster’s quorum. Besides provide a vote for the quorum, it also helps with the “split brain” scenario. However, file share witness doesn’t contain the cluster database.
• Vote – The quorum calculation is based on votes. Cluster nodes, disk witness resources and file share witness resources may have a vote base on the quorum configuration. The table in the next section shows the relationship between quorum mode and votes.
-------------------------------------------------------------------------------------------------------------------------
When the cluster is first created, the most appropriate quorum mode is automatically assigned which is based on the number of nodes and available cluster storage. This can always be changed.
The cluster will attempt to configure quorum so that there is always an odd number of votes. If there is an odd number of nodes, the cluster will select Node Majority as the quorum type to keep the odd number of votes. If there are an even number of nodes, and disks in Available Storage, the cluster will select Node and Disk Majority, giving a disk a single vote, so that there is an odd number of total votes. If there is an even number of nodes, but no Available Storage, the cluster will select Node Majority and issue a warning message. The cluster will never select Node and File Share Witness since it requires additional configuration, and it will never select No Majority: Disk Only as this is not recommended because it is a single point of failure.

Default Profile Favorites do not get copied when new user logs in

2013-09-20T14:17:00.001+05:30

The default user profile is located in C:\Users\default and it is used for customizing the user profiles for the new users logging in to the machine. When the new user logs into the machine it will fetch the profile configuration information from the default folder and creates its own new user profile in C:\users\%username%. For examples if we decide what are the favorites links should appear in new user’s internet explorer, we need to just copy the favorite links to the default folder in C:\users\default\. So that the new user logs in to the machine for the first time, all the favorites will be copied into the C:\users\%username%\favorites folder.

I have found an issue where the favorites links are not copying to the new users directory. The issue was that the files are copying from the default folder to the new user’s favorites folder when he logs in. But it got deleted automatically when user launches IE. I have reset the IE settings but still the issue was persist. Later I decided to explore IE program files and found a “custom” folder. This Custom folder contains IE related settings which are customized by using IEAK ( IE administration KIT). IEAK is used for doing Branding on IE and customize few settings such as favorites, feeds, quick link etc. I have opened the INSTALL.INS under C:\Program Files\Internet Explorer\CUSTOM\ in a notepad. I saw a lot of entries related to different IE settings. I had a machine where the problem was not there. I opened the same file INSTALL.INS from the working machine and compared with non working machine . Most of all the entries were looks similar, but I found one extra entry FavoritesDelete=0x708F from the INSTALL.INS file on the non working machine.

I did delete the entry FavoritesDelete=0x708F and saved the file from the administrator user. Later I created a new user and logged into the machine. Hurray ..All the favorites which I copied on default user were appearing on the IE of the new user. The entry FavoritesDelete=0x708F was created during the IEAK customization of IE package to delete all the entries in the Favorites as a default for each user.

Ananlyzing Blue screen of Death using Windbg tool

2013-07-05T12:45:00.003+05:30

Here I am going to show you how to analyze the minidump file to identify the cause of BSOD which happend in my laptop. The minidump file will be located in C:\Windows\minidump\ where we can find the dump file in date month year time format. eg:150513-22994-01.dmp.

You have to download the Windbg tool from the below link to analyze the minidump file.
http://msdn.microsoft.com/en-US/windows/hardware/gg463009/

After installation of the Windbg tool, you have to configure the sysmbol path before analayzing the dump file. You can set the sysmbol path by going to File menu, Select Symbol file path and add the below line

SRV*c:\localsymbols*http://msdl.microsoft.com/download/symbols

Now your Windbg tool is ready for analyzing the dump file. You can open the dump file by clicking on File menu and then open crashdump. Then enetr the command !analyze -v in the console as shown in the below figure.

After executing the command you can see a lot of information. If you scrol dwn, you can see the stack memory information during the time of crash. In the below figure you can see that the psfilenc, nt, hal are present in the stack during crash. nt and hal are microsoft drivers and it probably may not be the cause for the crash. We can suspect on psfilenc driver which belongs to Pointsec Encryption software installed in my laptop.

If you scroll down again you can get the diver file information psfilenc.sys.

I have resolved the problem by uninstalling the Pointsec Encryption software and reinstalling it back. Then after I never faced BSOD.

Blank Windows feature on or off issue

2013-07-04T19:11:00.000+05:30

If you want to enable features like Telnet , ISS in Windwso 7 you may have to go to Windows feature on or off from Programs and features of control panel. Some times you may get a blank window as below

There may be multilple reason you may get this above issue. I have come accross same issue and resolved it. The generic steps for resolving the issue is explained here.

Step 1: Perform a SFC /Scannow to scan all protected system files and repair it.
Ref: http://support.microsoft.com/kb/931712

Step 2: If step 1 doesnot helped you, then run System update readiness tool on the machine and look for the errors generated in C:\windows\logs\cbs\checksur.log. You can download the system update readiness tool from microsoft.

32bit : http://www.microsoft.com/en-us/download/details.aspx?id=3132
64bit : http://www.microsoft.com/en-us/download/details.aspx?id=20858

I ran the tool on the problamatic machine and found the following entries in it.
------------------------------------------------------------------------------------------------------
Checking System Update Readiness.
Binary Version 6.1.7601.21645
Package Version 19.0
2013-07-02 21:57
Checking Windows Servicing Packages
Checking Package Manifests and Catalogs
(w) CBS Catalog Expired 0x800B0101 servicing\Packages\Package_2_for_KB2705219~31bf3856ad364e35~amd64~~6.1.1.1.cat
(w) CBS Catalog Expired 0x800B0101 servicing\Packages\Package_3_for_KB2705219~31bf3856ad364e35~amd64~~6.1.1.1.cat
(w) CBS Catalog Expired 0x800B0101 servicing\Packages\Package_5_for_KB2722913~31bf3856ad364e35~amd64~~6.1.1.0.cat
(w) CBS Catalog Expired 0x800B0101 servicing\Packages\Package_for_KB2731847_SP1~31bf3856ad364e35~amd64~~6.1.1.2.cat
Checking Package Watchlist
Checking Component Watchlist
Checking Packages
Checking Component Store
(w) CSI Catalog Expired 0x800B0101 winsxs\Catalogs\5ecdd16d7678267e96a8c15964d5ca11bcf7f6f5cd1bd7bf28103ffbea31d9c1.cat ccb3aa159d2..53a473e1121_31bf3856ad364e35_6.1.7601.22044_eb09bf772e4bea12
(w) CSI Catalog Expired 0x800B0101 winsxs\Catalogs\f1c7c5a3cc1162153614fe17164933ea85a923dd79b8906ba59f851dc570675f.cat 01800be40f3..2c39cffa780_31bf3856ad364e35_6.1.7601.22044_eb01e5b08795f850
(w) CSI Catalog Expired 0x800B0101 winsxs\Catalogs\ee5a5ccda08ece8ca0c956f9159b0816481a1fd86b674da5cdf423f2c66a0795.cat c3b1ce67cd2..31e568a2078_31bf3856ad364e35_8.0.7601.17874_8387078378158e41
Summary:
Seconds executed: 1424
No errors detected
CSI Catalog Expired Total count: 3
CBS Catalog Expired Total count: 4
------------------------------------------------------------------------------------------------------------

You can see from the logs that , there are 3 CSI Catalog and 4 CBS Catalog are expierd. The KB2705219, KB2722913, KB2731847 patches are signed by microsoft security certificate. I have gone to the specified directory which is mentioned in the above log ie: C:\Windows\Packages\Package_2_for_KB2705219~31bf3856ad364e35~amd64~~6.1.1.1.cat. Then I checked the properties of the cat file and looked for the certificate tab. I found that the certificate got expired and this was the cause of the issue.

Step 3: Microsoft has release a non security patch for fixing this expired certificate of signed Microsoft update binaries. I have downloaded the patch from the below link and installed on the machine. The issue got resolved and the Windows feature was working perfectly.

Download Link KB2749655 : http://support.microsoft.com/kb/2749655
Microsoft Security Advisory (2749655) : http://technet.microsoft.com/en-us/security/advisory/2749655

How to analyze SFC /scannow logs

2013-06-27T18:23:00.001+05:30

Sfc /scannow will inspect all of the important Windows files on your computer, including Windows DLL files. If System File Checker finds an issue with any of these protected files, it will replace it.
You can find the sfc logs inside CBS.log under C:\Windows\logs\CBS\ folder.
There will be a lot of entries in cbs logs. You can filter out the log for SFC by running the below command.

findstr /c:"[SR]" cbs.log > sfcdetails.txt

The above command will search for the string [SR] and if it found , then it copies the corresponding entry in to the sfcdetails.txt

Below is sample text extracted from CBS log by using the above command
-----------------------------------------------------------------------------------------------------------
2013-06-24 12:55:44, Info                  CSI    00000210 [SR] Verify complete
2013-06-24 12:55:44, Info                  CSI    00000211 [SR] Verifying 100 (0x00000064) components
2013-06-24 12:55:44, Info                  CSI    00000212 [SR] Beginning Verify and Repair transaction
2013-06-24 12:55:48, Info                  CSI    00000214 [SR] Verify complete
2013-06-24 12:55:48, Info                  CSI    00000215 [SR] Verifying 100 (0x00000064) components
2013-06-24 12:55:48, Info                  CSI    00000216 [SR] Beginning Verify and Repair transaction
2013-06-24 12:55:53, Info                  CSI    00000218 [SR] Verify complete
2013-06-24 12:55:54, Info                  CSI    00000219 [SR] Verifying 88 (0x00000058) components
2013-06-24 12:55:54, Info                  CSI    0000021a [SR] Beginning Verify and Repair transaction
2013-06-24 12:55:57, Info                  CSI    0000021c [SR] Verify complete
2013-06-24 12:55:57, Info                  CSI    0000021d [SR] Repairing 1 components
2013-06-24 12:55:57, Info                  CSI    0000021e [SR] Beginning Verify and Repair transaction
2013-06-24 12:55:57, Info                  CSI    00000220 [SR] Cannot repair member file [l:24{12}]"PhotoAcq.dll" of Microsoft-Windows-PhotoAcquire, Version = 6.1.7600.16385, pA = PROCESSOR_ARCHITECTURE_INTEL (0), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, hash mismatch
2013-06-24 12:55:57, Info                  CSI    00000222 [SR] Cannot repair member file [l:24{12}]"PhotoAcq.dll" of Microsoft-Windows-PhotoAcquire, Version = 6.1.7600.16385, pA = PROCESSOR_ARCHITECTURE_INTEL (0), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, hash mismatch2013-06-24 12:55:57, Info                  CSI    00000223 [SR] This component was referenced by [l:178{89}]"Microsoft-Windows-PhotoBasicPackage~31bf3856ad364e35~x86~~6.1.7600.16385.PhotoBasicUpdate"
2013-06-24 12:55:57, Info                  CSI    00000226 [SR] Could not reproject corrupted file [ml:520{260},l:82{41}]"\??\C:\Program Files\Windows Photo Viewer"\[l:24{12}]"PhotoAcq.dll"; source file in store is also corrupted
2013-06-24 12:55:57, Info                  CSI    00000228 [SR] Repair complete
2013-06-24 12:55:57, Info                  CSI    00000229 [SR] Committing transaction
2013-06-24 12:55:57, Info                  CSI    0000022d [SR] Verify and Repair Transaction completed. All files and registry keys listed in this transaction have been successfully repaired
---------------------------------------------------------------------------------------------------------------------------------

From the above log you can see that there are only entries with [SR] line which is generated by sfc. There are some entries by sfc where sfc cannot repair some of the dll files which is highlighted above. Here in this case PhotoAcq.dll was not repaired by sfc. We can resolve this issue by copying the same dll file from a working machine and replacing it.

In few cases you may have to copy the file into C:\Windows\winsxs or C:\Windows\servicing, where you may not have permission to copy the file. You can take ownership and give full permission to the location by running the below commands.

takeown /f C:\Windows\winsxs\folder or file name where you want to take ownership

icacls C:\Windows\winsxs\folder or file name /grant Administrators:F

Userenv logging (User Environment logging)

2012-10-02T15:19:00.000+05:30

When you enable userenv logging, you can perform debug logging of the user profile and the system policy processes. Userenv log files also contain information about the status of each Group Policy extension, such as Application Deployment, Security, and Folder Redirection. Userenv log files reveal what is occurring in the background as a user logs on

Userenv.log file located in the %SystemRoot%\Debug\UserMode folder

Userenv log files contains information about the following:

Group Policy settings that are not processed or not applied as expected
Folder redirection that does not occur
Profile or registry hive load, unload, or deletion failures
Logon script, or script not applied as expected
Default behaviors occurring because a slow link was detected
Roaming profile issues
Slow logon issues
Whether a given GPO is accessible, and if not, why access was denied.
The name of the domain controller that is accessing SYSVOL.

The Userenv log has a maximum size of 1 megabyte (MB). At system startup, if the log file exceeds 1 MB, the contents is copied into a Userenv.bak file and a new Userenv log is created. If the system remains running and is not restarted, the log file exceeds 1 MB.

Use Registry Editor to add or to modify the following registry entry:

Subkey:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

Entry: UserEnvDebugLevel
Type: REG_DWORD
Value data: 10002 (Hexadecimal)

UserEnvDebugLevel can have the following values:

NONE 0x00000000
NORMAL 0x00000001
VERBOSE 0x00000002
LOGFILE 0x00010000
DEBUGGER 0x00020000

The default value is NORMAL|LOGFILE (0x00010001).

Understanding How to Read a Userenv Log : http://blogs.technet.com/b/askds/archive/2008/11/11/understanding-how-to-read-a-userenv-log-part-1.aspx

Windbg: debugging commands

2012-06-14T18:21:00.002+05:30

1. !thread/!process [address] e - on x64 will not show you the meaningless Args to Child information.

2. .frame /c [FrameNumber] - sets context to specificied stack frame. On x64 provides more reliable register information than .trap.

3. kn - Dumps call stack with frame numbers, easier than counting stacks for .frame.

4. .frame /r [FrameNumber] - same as .frame /c, but shows registers without changing context.Note: With .frame /c or /r you can only trust the nonvolatile registers.

5. k=rbp rip FrameCount - Dumps call stack starting at rbp/rip on x64. Useful when the stack is corrupt.

6. .process/.thread /p /r [address] - sets new process context, sets .cache forcedecodeuser, and reloads user symbols.

7. !process [address] 17 - Sets the context for this command, avoids the need for .process to see user stacks. Try !process 0 17

8. ~~[ThreadID]s - Changes threads in user mode. Use Thread ID number from output such as !locks. Ex: ~~[1bd4]s

9. !heap -p -a <address> - Shows information about the heap block containing <address>, even if you aren't using pageheap.

10. ub - Unassembles starting at a location prior to your address. Accepts l<number> to specify how many instructions to go back. ub . l20

11. !stacks 2 [FilterString] - Finds kernel mode call stacks that contain the FilterString in a symbol.

12. !thread [address] 17 (or 1e on x64) - Sets context for this command, avoids the need for .thread/.process for user stacks.

13. .hh [Text] - Opens the debugger help. [Text] is the topic to lookup in the index. Example: .hh !pte

14. ?? can dump structs using C++ style expressions. Ex: ??((nt!_KTHREAD*)(0xfffffa800ea43bb0))->ApcState

15. bp /t EThread - Sets a kernel mode breakpoint that only triggers when hit in the context of this thread.

16. bp /p EProcess - Sets a kernel mode breakpoint that only triggers when hit in the context of this process.

17. gc - If you run 'p' and hit a breakpoint, gc takes you where p would have gone if you had not hit the bp.

18. gu - Go until the current function returns. Effectively this unwinds one stack frame. #windbg

19. pc - Steps through until the next 'call' instruction. Combine with other commands to find who returned your error> pc;p;r eax

20. pt - Steps through until the next 'ret' instruction. Similar to gu, but pt stops on the ret and gu stops after the ret.

21. .ignore_missing_pages 1 - supresses the error: "Page 2a49 not present in the dump file. Type ".hh dbgerr004" for details"

22. .exr -1 shows the most recent exception. Useful in user dumps of crashes, especially for no execute crashes (NX/DEP).

23. wt - Trace calls until they return to the current address. More useful with -or to get return values. Use -l for depth.

24. .thread /w - Changes to the WOW64 32-bit context from 64-bit kernel mode. Wow64exts doesn't work in kernel mode.

25. ??sizeof(structure) - Gets the size of a structure, it's easier than counting.

26. sxe ld:module.dll - Enables an exception which will break into the debugger when module.dll is loaded.

27. vertarget - Shows OS version of the debug target. Also shows machine name, uptime, and session time (when the dump was taken).

28. !vm 1 - In a kernel debugger, shows basic information about memory usage. Available, committed, pagefile, pool, sysptes, etc.

29. .time - Shows session time (when dump was taken) and system uptime. In user mode shows process uptime, kernel/user time.

30. ba w size [address] - Break on write access only. Replace size with the num bytes you want to watch. Ex: ba w 4 005d5f10

31. .process -i <address> - Make the process active and break into the debugger. Use in live kernel debugs to get into process context.

32. .reload /f /o - Overwrites cached files in your downstream symbol store. Useful when your store has corrupt pdbs.

33. ->* - Use with dt to dump pointers. Example: dt _EPROCESS [Address] ObjectTable->*

34. !for_each_module s -a @#Base @#End "PTag" - Find the drivers using pool tag "PTag".

35. .unload [DllName] - Unloads the debug extension you didn't intend to load. Omit DllName to unload the last dll loaded.

36. !exqueue dumps the executive worker queues. Use flags 7f to dump the worker threads and the queues.

37. lmvm <module> - Dumps information about the module. Remember to use <module> and not <module.dll>.

38. !thread -t TID - Dump a thread using thread ID rather than thread address. Useful when working with a critical section.

39. !list - Walks a linked list and displays informatino for each element in a list. See blog later today for an example.

40. .time -h # - Shows the debug session time using the timezone offset of #. Ex: .time -h 0 shows when a dump was taken in UTC.

41. !session - Lists all of the user session IDs. A quick way to list the active sessions from a dump of a terminal server.

42. !session -s SessionID - Changes the current session context to SessionID. Useful when looking at GDI, or other per session data.

43. | ProcNum s - Switches to process number ProcNum. Use when debugging multiple dumps, or processes, in one windbg.

44. !! - Launches a shell process and redirects its output to the debugger. The same as .shell, but "bang bang" sounds cooler.

45. uf Function - Dumps the assembly for Function (name or address). Useful for optimized code that is not contiguous in memory.

46. uf /c Function - Shows all of the calls made by Function (can be function name or address).

47. !wow64exts.sw - switches between x64 and x86 contexts. Often used to reverse .thread /w context switch.

Address Windowing Extensions

2012-03-19T18:38:00.003+05:30

Address Windowing Extensions (AWE) is a set of extensions that allows an application to quickly manipulate physical memory greater than 4GB. Certain data-intensive applications, such as database management systems and scientific and engineering software, need access to very large caches of data. In the case of very large data sets, restricting the cache to fit within an application's 2GB of user address space is a severe restriction. In these situations, the cache is too small to properly support the application.
AWE solves this problem by allowing applications to directly address huge amounts of memory while continuing to use 32-bit pointers. AWE allows applications to have data caches larger than 4GB (where sufficient physical memory is present). AWE uses physical nonpaged memory and window views of various portions of this physical memory within a 32-bit virtual address space.
AWE places a few restrictions on how this memory may be used, primarily because these restrictions allow extremely fast mapping, remapping, and freeing. Fast memory management is important for these potentially enormous address spaces.

Virtual address ranges allocated for the AWE are not sharable with other processes (and therefore not inheritable). In fact, two different AWE virtual addresses within the same process are not allowed to map the same physical page. These restrictions provide fast remapping and cleanup when memory is freed.
The physical pages that can be allocated for an AWE region are limited by the number of physical pages present in the machine, since this memory is never paged – it is locked down until the application explicitly frees it or exits. The physical pages allocated for a given process can be mapped into any AWE virtual region within the same process. Applications that use AWE must be careful not to take so much physical memory that they cause other applications to page excessively or prevent creation of new processes or threads due to lack of resources. Use the GlobalMemoryStatusEx function to monitor physical memory use.
AWE virtual addresses are always read/write and cannot be protected via calls to VirtualProtect (that is, no read-only memory, noaccess memory, guard pages, and the like can be specified).
AWE address ranges cannot be used to buffer data for graphics or video calls.
An AWE memory range cannot be split, nor can pieces of it be deleted. Instead, the entire virtual address range must be deleted as a unit when deletion is required. This means you must specify MEM_RELEASE when calling VirtualFree.
Applications can map multiple regions simultaneously, provided they do not overlap.
Applications that use AWE are not supported in emulation mode. That is, an x86 application that uses AWE functions must be recompiled to run on another processor, whereas most applications can run without recompiling under an emulator on other platforms.

This solution addresses the physical memory issues in a very general, widely applicable manner. Some of the benefits of AWE are:

A small group of new functions is defined to manipulate AWE memory.
AWE provides a very fast remapping capability. Remapping is done by manipulating virtual memory tables, not by moving data in physical memory.
AWE provides page size granularity appropriate to the processor (for example, 4 KB on x86), which is more useful to applications than large pages (for example, 2MB or 4MB on x86).

An application must have the Lock Pages in Memory privilege to use AWE. To obtain this privilege, an administrator must add Lock Pages in Memory to the user's User Rights Assignments. For more information on how to do this, see "User Rights" in the operating system help.
The following functions make up the Address Windowing Extensions (AWE) API.

what is _msdsc in DNS?

2012-01-07T18:39:00.002+05:30

. Active Directory (AD) uses DNS as its locator service to support the various types of services that AD offers, such as Global Catalog (GC), Kerberos, and Lightweight Directory Access Protocol (LDAP). Other non-Microsoft services can be advertised in the DNS, including--but not restricted to--non-Microsoft implementations of LDAP and GC. However, sometimes clients might need to contact a Microsoft-hosted service. For that reason, each domain in DNS has an _msdcs subdomain that hosts only DNS SRV records that are registered by Microsoft-based services. The Netlogon process dynamically creates these records on each domain controller (DC). The _msdcs subdomain also includes the globally unique identifier (GUID) for all domains in the forest and a list of GC servers.
If you install a new forest on a system that runs Windows Server 2003 and let the Dcpromo wizard configure DNS, Dcpromo will actually create a separate zone called _msdcs.&ltforest name&gt on the DNS server. This zone is configured to store its records in a forestwide application directory partition, ForestDNSZones, which is replicated to every DC in the forest that runs the DNS service. This replication makes the zone highly available anywhere in the forest.

What is Active Directory Naming Context or Directory Partition

2012-01-07T17:32:00.003+05:30

All of the objects in the Active Directory forest are represented in the Directory Tree. A Directory Tree is a hierarchy of objects and containers in a directory that can be viewed graphically as an upside-down tree, with the root object at the top. A tree shows how objects are connected in terms of the path from one object to another.

The Directory Tree of Active Directory tree is partitioned to allow sections to be distributed (replicated) to domain controllers in different domains within the forest. Each domain controller stores a copy of a specific part of the directory tree, called a “Naming Context” also know as Directory Partition. “Naming Context” is replicated as a unit to other domain controllers in the forest that contain a replica of the same sub tree. A “Naming Context” is also called a Directory Partition.

In Active Directory, a single server always holds at least three naming contexts:

Schema Naming Context

Schema Naming Context contains definitions of objects that can be created in the forest and the attributes those objects can have. Objects in the schema partition must be replicated to all domain controllers in all domains in the forest.

Configuration Naming Context

Configuration Naming Context contains objects that represent the logical structure of the forest, including the domain structure and replication topology. Objects in the configuration partition must be replicated to all domain controllers in all domains in the forest.

Domain Naming Context

Domain Naming Context contains all of the objects stored in a domain. Objects in the domain partition can be replicated only to domain controllers within the domain.

OU, Container and group difference.

2012-01-07T14:09:00.003+05:30

OU are logical containers in a domain. They can contain users group, computers and other OUs, but only from home domain. you cant put gloal groups or computers from other domains into your domains OU

An OU is a container , but not just as container like the users container in DSA.MSC. you can delegate control of container , ut you cant apply group policy to one.

How are OU different from groups? a user can e a member of many groups but can only e in one OU at a time. Like groups OU can contain other OU. Groupname appear in ACL (Access control list) but not OU

What is new in 2008 ADDS

2012-01-07T00:56:00.000+05:30

What’s New in Windows Server 2008 Active Directory Domain Services?

Active Directory Domain Services in Windows Server 2008 provides a number of enhancements over previous versions, including these:

Auditing—AD DS auditing has been enhanced significantly in Windows Server 2008. The enhancements provide more granular auditing capabilities through four new auditing categories: Directory Services Access, Directory Services Changes, Directory Services Replication, and Detailed Directory Services Replication. Additionally, auditing now provides the capability to log old and new values of an attribute when a successful change is made to that attribute.

Fine-Grained Password Policies—AD DS in Windows Server 2008 now provides the capability to create different password and account lockout policies for different sets of users in a domain. User and group password and account lockout policies are defined and applied via a Password Setting Object (PSO). A PSO has attributes for all the settings that can be defined in the Default Domain Policy, except Kerberos settings. PSOs can be applied to both users and groups.

Read-Only Domain Controllers—AD DS in Windows Server 2008 introduces a new type of domain controller called a read-only domain controller (RODC). RODCs contain a read-only copy of the AD DS database.

Restartable Active Directory Domain Services—AD DS in Windows Server 2008 can now be stopped and restarted through MMC snap-ins and the command line. The restartable AD DS service reduces the time required to perform certain maintenance and restore operations. Additionally, other services running on the server remain available to satisfy client requests while AD DS is stopped.

AD DS Database Mounting Tool—AD DS in Windows Server 2008 comes with a AD DS database mounting tool, which provides a means to compare data as it exists in snapshots or backups taken at different times. The AD DS database mounting eliminates the need to restore multiple backups to compare the AD data that they contain and provides the capability to examine any change made to data stored in AD DS.

memory dump

2012-01-06T19:04:00.000+05:30

The debugging information can be written to different file formats (also known as memory dump files) when your computer stops unexpectedly because of a Stop error (also known as a "blue screen," system crash, or bug check). You can also configure Windows not to write debugging information to a memory dump file.

Windows can generate any one of the following memory dump file types:

Complete memory dump
Kernel memory dump
Small memory dump (64 KB)

Complete memory dump

A complete memory dump records all the contents of system memory when your computer stops unexpectedly. A complete memory dump may contain data from processes that were running when the memory dump was collected.

If you select the Complete memory dump option, you must have a paging file on the boot volume that is sufficient to hold all the physical RAM plus 1 megabyte (MB).

If a second problem occurs and another complete memory dump (or kernel memory dump) file is created, the previous file is overwritten.

Notes

In Windows Vista, Windows 7, Windows Server 2008 and in Windows Server 2008 R2, the paging file can be on a partition that differs from the partition on which the operating system is installed.
In Windows Vista and Windows Server 2008, to put a paging file on another partition, you must create a new registry entry that is named DedicatedDumpFile. You can define the size of the paging file by using a new registry entry that is named DumpFileSize.

For more information about how to do this, visit the following Microsoft Web site:
969028 How to generate a kernel or a complete memory dump file in Windows Server 2008

In Windows 7 and Windows Server 2008 R2, to put a paging file on another partition, it is not mandatory to use DedicatedDumpFile registry entry.
The Complete memory dump option is not available on computers that are running a 32-bit operating system and that have 2 gigabytes (GB) or more of RAM. For more information, see the Specify what

Kernel memory dump

A kernel memory dump records only the kernel memory. This speeds up the process of recording information in a log when your computer stops unexpectedly. You must have a pagefile large enough to accommodate your kernel memory. For 32-bit systems, kernel memory is usually between150MB and 2GB. Additionally, on Windows 2003 and Windows XP, the page file must be on the boot volume. Otherwise, a memory dump cannot be created.

This dump file does not include unallocated memory or any memory that is allocated to User-mode programs. It includes only memory that is allocated to the kernel and hardware abstraction layer (HAL) in Windows 2000 and later, and memory allocated to Kernel-mode drivers and other Kernel-mode programs. For most purposes, this dump file is the most useful. It is significantly smaller than the complete memory dump file, but it omits only those parts of memory that are unlikely to have been involved in the problem.

If a second problem occurs and another kernel memory dump file (or a complete memory dump file) is created, the previous file is overwritten when the 'Overwrite any existing file' setting is checked.

Small memory dump

A small memory dump records the smallest set of useful information that may help identify why your computer stopped unexpectedly. This option requires a paging file of at least 2 MB on the boot volume and specifies that Windows 2000 and later create a new file every time your computer stops unexpectedly. A history of these files is stored in a folder.

This dump file type includes the following information:

The Stop message and its parameters and other data
A list of loaded drivers
The processor context (PRCB) for the processor that stopped
The process information and kernel context (EPROCESS) for the process that stopped
The process information and kernel context (ETHREAD) for the thread that stopped
The Kernel-mode call stack for the thread that stopped

This kind of dump file can be useful when space is limited. However, because of the limited information included, errors that were not directly caused by the thread that was running at the time of the problem may not be discovered by an analysis of this file.

If a second problem occurs and a second small memory dump file is created, the previous file is preserved. Each additional file is given a distinct name. The date is encoded in the file name. For example, Mini022900-01.dmp is the first memory dump generated on February 29, 2000. A list of all small memory dump files is kept in the %SystemRoot%\Minidump folder.

Configure the dump type

To configure startup and recovery options (including the dump type), follow these steps.

Note Because there are several versions of Microsoft Windows, the following steps may be different on your computer. If they are, see your product documentation to complete these steps.

Click Start, and then click Control Panel.
Click Performance and Maintenance, and then click System.
On the Advanced tab, click Settings under Startup and Recovery.

NOTE: You must restart Windows in order for your changes to take affect.

Tools for the various dump types

You can load complete memory dumps and kernel memory dumps with standard symbolic debuggers, such as I386kd.exe. I386kd.exe is included with the Windows 2000 Support CD-ROM.

Load small memory dumps by using Dumpchk.exe. Dumpchk.exe is included with the Support Tools for Windows 2000 and Windows XP. You can also use Dumpchk.exe to verify that a memory dump file has been created correctly.

For more information about how to use Dumpchk.exe in Windows XP, click the following article number to view the article in the Microsoft Knowledge Base:

315271 How to use Dumpchk.exe to check a memory dump file

For more information about how to use Dumpchk.exe in Windows 2000, click the following article number to view the article in the Microsoft Knowledge Base:

156280 How to use Dumpchk.exe to check a memory dump file

For more information about Windows debugging tools, visit the following Microsoft Web site:

How to enable Windows Installer logging

2012-01-06T11:08:00.000+05:30

Windows includes a registry-activated logging service to help diagnose Windows Installer issues. This article describes how to enable this logging service.
Windows Installer can use logging to help assist in troubleshooting issues with installing software packages. This logging is enabled by adding keys and values to the registry. After the entries have been added and enabled, you can retry the problem installation and Windows Installer will track the progress and post it to the Temp folder. The new log's file name is random, but begins with the letters "Msi" and end with a .log extension. To locate the Temp folder location, type the following line at a command prompt:

cd %temp%

Let me fix it myself

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

322756 How to back up and restore the registry in Windows

To enable Windows Installer logging

To enable Windows Installer logging yourself, open the registry with Regedit.exe and create the following path and keys:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer

Reg_SZ: Logging
Value: voicewarmupx

The letters in the value field can be in any order. Each letter turns on a different logging mode. Each letter's actual function is as follows for MSI version 1.1:

v - Verbose output
o - Out-of-disk-space messages
i - Status messages
c - Initial UI parameters
e - All error messages
w - Non-fatal warnings
a - Start up of actions
r - Action-specific records
m - Out-of-memory or fatal exit information
u - User requests
p - Terminal properties
+ - Append to existing file
! - Flush each line to the log
x - Extra debugging information. The "x" flag is available only on Windows Server 2003 and later operating systems, and on the MSI redistributable version 3.0, and on later versions of the MSI redistributable.

"*" - Wildcard, log all information except for the v and the x option. To include the v and the x option, specify "/l*vx".

Note This should be used only for troubleshooting purposes and should not be left on because it will have adverse effects on system performance and disk space. Each time you use the Add/Remove Programs tool in Control Panel, a new Msi*.log file is created.

Back to the top

Enable Windows Installer logging with Group Policies

You can enable logging with Group Policies by editing the appropriate OU or Directory Group Policy. Under Group Policy, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then select Windows Installer.

Double-click Logging, and then click Enabled. In the Logging box, enter the options you want to log. The log file, Msi.log, appears in the Temp folder of the system volume.

For more information about MSI logging, please see Windows Help. To do so, search using the phrase "msi logging" and select "Managing options for computers through Group Policy".

Note The addition of the "x" flag is available natively on Windows Server 2003 and later operating systems, and on the MSI redistributable version 3.0, and on later versions of the MSI redistributable.

Windows Installer logging

Windows Installer handles its installations through Msiexec.exe. The logging options offered by this tool allow you to create different types of logs, depending on the information you need about the installation. These options are:

i - Status messages
w - Nonfatal warnings
e - All error messages
a - Start up of actions
r - Action-specific records
u - User requests
c - Initial UI parameters
m - Out-of-memory or fatal exit information
o - Out-of-disk-space messages
p - Terminal properties
v - Verbose output
x - Extra debugging information
+ - Append to existing log file
! - Flush each line to the log
* - Log all information, except for v and x options

The logging command is issued by the /L parameter. The above options can be used only after this parameter (the options cannot be used by themselves).

Create a log

The most used logging command is /L*V. This command will create a verbose log which offers a lot of information about the installation. Here are the steps for creating a log:

find out the path of the MSI file, for example C:\MyPackage\Example.msi
decide the path of the log, for example C:\log\example.log
open cmd.exe (you can use any command shell)
use the msiexec command line to launch the MSI with logging parameters

Install Log
For creating an installation log, you can use a command line which looks like this:

msiexec /i "C:\MyPackage\Example.msi" /L*V "C:\log\example.log"

The /i parameter will launch the MSI package. After the installation is finished, the log is complete.

The example command line uses the sample paths in this How-To. For your package you must use the path of your MSI file.

Note that any logging command line should have this form:

msiexec /i <path_to_msi> /L*V <path_to_log>

After you use the logging command, you need to specify the log's complete path. If you want the log to be created next to the MSI, you can specify only the name of the log file:

msiexec /i "C:\MyPackage\Example.msi" /L*V "example.log"

When the package is included in an EXE bootstrapper, the command line no longer uses "msiexec". For example, the command line can look like this:

"C:\MyPackage\Setup.exe" /L*V "example.log"

Uninstall Log
In order to create a log for an uninstall process, you can replace the /i parameter with /x. Therefore, a command line which creates a log for an uninstall can look like this:

msiexec /x "C:\MyPackage\Example.msi" /L*V "C:\log\example.log"

The package path can also be replaced by the package Product Code (it can be obtained by using the Project -> Options menu inside the project). The command line would look like this:

msiexec /x {B40D5AC5-6120-4AD6-BBD4-AF5EF7E04351} /L*V "C:\log\example.log"

When the package is included in an EXE bootstrapper and it's already installed on the machine, you can launch the installer again with the logging command. For example:

"C:\MyPackage\Setup.exe" /L*V "example.log"

This will make the package go into maintenance mode and you can choose to uninstall it. Since the package was launched with logging, an uninstall log will be generated.
Patch Install Log
You can create a log for a patch installation by using the /p parameter instead of /i:

msiexec /p "C:\MyPackage\Patch.msp" /L*V "C:\log\patch.log"

Use the EXE boostrapper
Another approach is to create a log file by using the /L*V parameters in the command line of the Advanced Installer Bootstrapper. Also, these parameters can be always passed to the MSI when the package is launched through the EXE bootstrapper.
If you want your installation package to always create a log, you can follow these steps:

open your installation package's Advanced Installer project
go to the Media page and select the Bootstrapper tab
check the Create EXE setup file option
set the MSI Command Line field to: /L*V "C:\package.log"

This way, when the user launches the installation through the bootstrapper, an installation log ("package.log") will be created automatically in the "C:\" drive.

The command line received by the bootstrapper overrides the command line in the "MSI Command Line" field. Therefore, if you launch an EXE package with logging parameters, these parameters will be used for creating the log.

Automated logging with the Windows Installer Logging Policy

The logging policy is particularly useful for troubleshooting Active Directory/Group Policy deployments, in which case the installation is carried out without a user interface and there is no possibility to specify a command line for the MSI package.
In order to enable this option, you need to import the registry settings below. Please create a new text file with a ".reg" extension and then copy the following lines into it. After this, double click the ".reg" file you just created and answer "Yes" to the confirmation prompt.

REGEDIT4
          
[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer]
"Logging"="voicewarmup"
"Debug"=dword:00000007

The .LOG file will be created in the currently logged on user's Temp folder and will have a name in the following format: "MSI*.LOG".

In case of a Active Directory/GPO deployment, there will be no logged on user at the time the installation occurs. In this case the log file will be created in the "Windows\Temp" folder.

This option should not be left active since every install/uninstall operation of a MSI package will create a new log file, thus unnecessarily occupying disk space. Therefore, this option should only be used for debugging purposes.

In order to disable the debugging policy, you can delete the registry values you have previously added using "RegEdit.exe" or you can import the following .reg file as you did with the previous one:

REGEDIT4
          
[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer]
"Debug"=-

ADSI Edit

2012-01-04T20:30:00.000+05:30

ADSI Edit (adsiedit.msc)

Updated: March 19, 2010
Applies To: Windows SBS 2008, Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2
Active Directory® Service Interfaces Editor (ADSI Edit) is a Lightweight Directory Access Protocol (LDAP) editor that you can use to manage objects and attributes in Active Directory. ADSI Edit (adsiedit.msc) provides a view of every object and attribute in an Active Directory forest. You can use ADSI Edit to query, view, and edit attributes that are not exposed through other Active Directory Microsoft Management Console (MMC) snap-ins: Active Directory Users and Computers, Active Directory Sites and Services, Active Directory Domains and Trusts, and Active Directory Schema.
This topic includes the following sections:

Note
Another LDAP editor that Microsoft provides is Ldp. To learn more about Ldp, see Ldp Overview (http://go.microsoft.com/fwlink/?LinkId=143517). For an example of Ldp being used, see article 224543 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=23064).

Installing ADSI Edit

To install ADSI Edit on computers running Windows Server® 2003 or Windows® XP operating systems, install Windows Server 2003 Support Tools from the Windows Server 2003 product CD or from the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=100114). For more information about how to install Windows Support Tools from the product CD, see Install Windows Support Tools (http://go.microsoft.com/fwlink/?LinkId=62270).
On servers running Windows Server 2008 or Windows Server 2008 R2, ADSI Edit is installed when you install the Active Directory Domain Services (AD DS) role to make a server a domain controller. You can also install Windows Server 2008 Remote Server Administration Tools (RSAT) on domain member servers or stand-alone servers. For specific instructions, see Installing or Removing the Remote Server Administration Tools Pack (http://go.microsoft.com/fwlink/?LinkId=143345).
To install ADSI Edit on computers running Windows Vista® with Service Pack 1 (SP1) or Windows 7, you must install RSAT. For more information and to download RSAT, see article 941314 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=116179).

Note
Adsiedit.msc will not run unless the Adsiedit.dll file is registered. This happens automatically if the support tools are installed. However, if the support tool files are copied instead of installed, you must run the regsvr32 command to register Adsiedit.dll before you run the Adsiedit.msc snap-in. To register adsiedit.dll, type the following command (you must navigate to the directory containing the adsiedit.dll file): regsvr32 adsiedit.dll You can run ADSI Edit from a client computer or server. The computer does not have to be a member of a domain. However, to see domain objects using Adsiedit.msc, you must have the rights to view the Active Directory domain that you connect to. By default, members of the Domain Users group have these rights. To modify objects using ADSIEdit, you must have at least the Edit permission on the Active Directory objects that you want to change. By default, members of the Domain Admins group have this permission.

Note

Adsiedit.msc will not run unless the Adsiedit.dll file is registered. This happens automatically if the support tools are installed. However, if the support tool files are copied instead of installed, you must run the regsvr32 command to register Adsiedit.dll before you run the Adsiedit.msc snap-in. To register adsiedit.dll, type the following command (you must navigate to the directory containing the adsiedit.dll file):
```
regsvr32 adsiedit.dll
```
You can run ADSI Edit from a client computer or server. The computer does not have to be a member of a domain. However, to see domain objects using Adsiedit.msc, you must have the rights to view the Active Directory domain that you connect to. By default, members of the Domain Users group have these rights. To modify objects using ADSIEdit, you must have at least the Edit permission on the Active Directory objects that you want to change. By default, members of the Domain Admins group have this permission.

Using ADSI Edit

ADSI Edit (Adsiedit.msc) is an MMC snap-in. You can add the snap-in to any .msc file through the Add/Remove Snap-in menu option in MMC, or just open the Adsiedit.msc file from Windows Explorer. The following figure illustrates the ADSI Edit interface. In the console tree on the left, you can see the major partitions Domain, Configuration, and Schema. The figure shows the Builtin container of the Contoso.com domain selected. In the details pane on the right, you can see the Builtin groups of Active Directory.

Note
Adsiedit.msc automatically attempts to load the current domain to which the user is logged on. If the computer is installed in a workgroup or otherwise not logged on to a domain, the message "The specified domain does not exist" displays repeatedly. To resolve this issue, you may want to open an MMC, add the ADSI Edit snap-in, make connections as appropriate, and then save the console file.

ADSI Edit Node

To view the following commands, in the console tree click the ADSI Edit node, click the Action menu, and then click one of the following:

Connect To

The Connection Settings dialog box appears. You can use the Connection Settings dialog box to create a connection point to an object in Active Directory. The following text boxes are located in the Connection Settings dialog box:
Name. You should not change the text in this box because it might cause an error when you attempt to make a connection. The text in this box is updated automatically, if necessary, when you configure or select a Connection Point.
Path. Displays the URL for the selected object. It cannot be edited. If the path is not correct, click Cancel, and then select the correct object.

Connection Point Section

Click either Select or type a Distinguished Name or Naming Context or Select a well known Naming Context.

If you click the Select or type a Distinguished Name or Naming Context radio button, type the distinguished name of the object that will be the connection point in Active Directory. For example, if your domain name is contoso.com and you want to connect to the Users container, type cn=users,dc=contoso,dc=com.
If you click the Select a well known Naming Context radio button, select the directory partition that will be the connection point in Active Directory in the list of partitions in the selection menu.

Tip
Previous LDAP connections are remembered by the ADSI Edit tool. In versions earlier than Windows Server® 2008, the tool automatically attempts to load the current domain to which the user is logged on. If the computer is installed in a workgroup or otherwise not logged on to a domain, the message "The specified domain does not exist" appears repeatedly. To avoid these issues, open Mmc.exe, add the ADSI Edit snap-in manually, make any connections that are appropriate for you with whatever credentials are necessary, and then save the console file. This gives you your own default console that works with ADSI Edit.

Tip

Previous LDAP connections are remembered by the ADSI Edit tool. In versions earlier than Windows Server® 2008, the tool automatically attempts to load the current domain to which the user is logged on. If the computer is installed in a workgroup or otherwise not logged on to a domain, the message "The specified domain does not exist" appears repeatedly. To avoid these issues, open Mmc.exe, add the ADSI Edit snap-in manually, make any connections that are appropriate for you with whatever credentials are necessary, and then save the console file. This gives you your own default console that works with ADSI Edit.

Computer Section

Specifies whether you connect to the local computer or a remote computer. Click either Default (domain or server that you are logged in to) or Select or type a domain or server. You can enter the domain name or computer name in Domain Name System (DNS) format or NetBIOS format, or you can enter an IP address.

Advanced Button

Click the Advanced button to specify alternate credentials or alternate port numbers or to change the protocol that is used to connect to Active Directory. The Advanced dialog box contains the following text boxes:
Specify Credentials. Use this box to specify alternate credentials. Unless otherwise specified, the currently logged-on user's credentials are used.
Port Number. Type a port number if you do not want to use the default port for the LDAP or the LDAP Global Catalog protocol. The default LDAP port is 389. The default port for the Global Catalog is 3268.

Protocol Section

Click either LDAP or Global Catalog. The URL in Path might change, based on your selection. LDAP is used by default. To view the Path box, on the Advanced tab, click OK or Cancel.

Refresh

To update the object from Active Directory, right-click an object, and then click Refresh. The Refresh command removes the current objects in the container and repopulates the container with updated information from Active Directory.

Directory Partition Node

To view the following commands, select the directory partition node that you want to manage (that is, Domain, Configuration, and Schema), click the Action menu, and then click one of the following:

Settings

The Connection Settings dialog box appears, which provides the same configuration options as previously discussed in the Connect To section.

Remove

Removes the connection point that connects ADSI Edit to a directory partition or container within Active Directory. This command affects only what is shown in the ADSI Edit console. To remove objects from Active Directory, use the Delete command.

Update Schema Now

Reloads the schema information from Active Directory into the local computer's cache.

New

Click Query to create a new query. For more information about creating LDAP queries, see LDAP Query Basics (http://go.microsoft.com/fwlink/?LinkId=143553).

Refresh

Object Node

To view the following commands, click an object in the details pane (for example, Account Operators is an object in the previous figure), click the Action menu, and then click one of the following:

Move

Moves the object to another container in Active Directory. Opens a dialog box that you can use to select the destination container.

New Connection From Here

Creates a new connection point node and adds it to the console.

New

The New menu command reveals another menu that contains the Object command, which creates a new child object in the selected container. This command opens a set of chained dialog boxes that begins with the class of the object. If you do not have the appropriate permissions to create an object in the selected container, no classes will be listed. After you select a class, a dialog box opens for each required attribute. In the final dialog box, click More to view and edit any optional attributes.

Delete

Deletes the selected object from Active Directory. A dialog box appears asking you to confirm the deletion. This command does not appear in the menu if you do not have permissions to delete an object from Active Directory.

Rename

Changes the name of the object in Active Directory.

Refresh

Adding ADSI Edit to MMC

If you are running ADSI Edit on a computer that is not logged on to a domain or if you want to create a customized MMC, you may want to add the ADSI Edit snap-in to the console.

To add the ADSI Edit Snap-in to MMC

Open your existing console or create a new console. To create a new console, click Start, click Run, type mmc, and click OK, or at a command line, type mmc, and then press ENTER.
Click Add/Remove Snap-in, and then click Add.
In the Add Standalone Snap-in dialog box, click ADSI Edit in the list. If ADSI Edit does not appear here, see Installing ADSI Edit at the beginning of this topic.
Click Add, click Close, and then click OK.

WMI filtering in GPMC

2012-01-04T19:52:00.002+05:30

WMI filtering using GPMC

Updated: January 21, 2005

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

WMI filtering

Windows Management Instrumentation (WMI) filters allow you to dynamically determine the scope of Group Policy objects (GPOs) based on attributes of the target computer.

When a GPO that is linked to a WMI filter is applied on the target computer, the filter is evaluated on the target computer. If the WMI filter evaluates to false, the GPO is not applied (except if the client computer is running Windows 2000, in which case the filter is ignored and the GPO is always applied). If the WMI filter evaluates to true, the GPO is applied.

WMI makes data about a target computer available for administrative use. Such data can include hardware and software inventory, settings, and configuration information. For example, WMI exposes hardware configuration data such as CPU, memory, disk space, and manufacturer, as well as software configuration data from the registry, drivers, file system, Active Directory, the Windows Installer service, networking configuration, and application data.

A WMI filter consists of one or more queries based on this data. If all queries are true, the GPO linked to the filter will be applied. The queries are written using the WMI Query Language (WQL), a SQL-like language. Queries can be combined with AND and OR logical operators to achieve whatever effect the administrator wants. Each query is executed against a particular WMI namespace. When you create a query, you must specify the namespace. The default is root\CIMv2, which is appropriate for most WMI queries.

The WMI filter is a separate object from the GPO in the directory. To apply a WMI filter to a GPO, you link the filter to the GPO. This is shown in the WMI filtering section on the Scope tab of a GPO. Each GPO can have only one WMI filter, however the same WMI filter can be linked to multiple GPOs.

WMI filters, like GPOs, are stored on a per-domain basis. A WMI filter and the GPO it is linked to must be in the same domain.

Notes

Client support for WMI filters exists only on Windows XP, Windows Server 2003, and later operating systems. Windows 2000 clients will ignore any WMI filter and the GPO is always applied, regardless of the WMI filter.
WMI filters are only available in domains that have at least one Windows Server 2003 domain controller. In an environment consisting only of Windows 2000 domains, the WMI filter node in Group Policy Management Console (GPMC) is not shown.

Using WMI filters with GPMC

Using GPMC, you can create and delete WMI filters, link and unlink WMI filters, copy and paste WMI filters, import and export WMI filters, and view and edit attributes of WMI filters.

Sample code

The following table shows sample code for several WMI filters.

Criterion	Administrator's intent	WMI filter
Configuration	Avoid turning on netmon on computers that can have multicasting turned on.	Select * from Win32_NetworkProtocol where SupportsMulticasting = true
Time zone	Apply policy on all servers located on the East Coast of the United States.	Root\cimv2 ; Select * from win32_timezone where bias =-300
Hotfix	Apply a policy on computers that have a specific hotfix.	Root\cimv2 ; Select * from Win32_QuickFixEngineering where HotFixID = 'q147222'
Software inventory	Assign software only on computers already having either of two software packages.	Root\cimv2;Select * from Win32_Product where name = "MSIPackage1" OR name = "MSIPackage2"
Operating system	Only target computers running Windows XP Professional.	Root\CimV2; Select * from Win32_OperatingSystem where Caption = "Microsoft Windows XP Professional"
Resources	Target only machines that have at least 600 megabytes (MB) available.	Root\CimV2; Select * from Win32_LogicalDisk where FreeSpace > 629145600 AND Description <> "Network Connection"
Make or model	Target Toshiba Tecra models 800 and 810.	Root\CimV2; Select * from Win32_ComputerSystem where manufacturer = "Toshiba" and Model = "Tecra 800" OR Model = "Tecra 810"

See Also

Concepts

Registry hives

2012-01-04T16:56:00.000+05:30

A hive is a logical group of keys, subkeys, and values in the registry that has a set of supporting files containing backups of its data.

Each time a new user logs on to a computer, a new hive is created for that user with a separate file for the user profile. This is called the user profile hive. A user's hive contains specific registry information pertaining to the user's application settings, desktop, environment, network connections, and printers. User profile hives are located under the HKEY_USERS key.

Registry files have the following two formats: standard and latest. The standard format is the only format supported by Windows 2000. It is also supported by later versions of Windows for backward compatibility. The latest format is supported starting with Windows XP. On versions of Windows that support the latest format, the following hives still use the standard format: HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE\SAM,HKEY_LOCAL_MACHINE\Security, and HKEY_USERS\.DEFAULT; all other hives use the latest format.

Most of the supporting files for the hives are in the %SystemRoot%\System32\Config directory. These files are updated each time a user logs on. The file name extensions of the files in these directories, or in some cases a lack of an extension, indicate the type of data they contain. The following table lists these extensions along with a description of the data in the file.

Extension	Description
none	A complete copy of the hive data.
.alt	A backup copy of the critical HKEY_LOCAL_MACHINE\System hive. Only the System key has an .alt file.
.log	A transaction log of changes to the keys and value entries in the hive.
.sav	A backup copy of a hive. Windows Server 2003 and Windows XP/2000: Copies of the hive files as they looked at the end of the text-mode stage in Setup. Setup has two stages: text mode and graphics mode. The hive is copied to a .sav file after the text-mode stage of setup to protect it from errors that might occur if the graphics-mode stage of setup fails. If setup fails during the graphics-mode stage, only the graphics-mode stage is repeated when the computer is restarted; the .sav file is used to restore the hive data.

The following table lists the standard hives and their supporting files.

Registry hive	Supporting files
HKEY_CURRENT_CONFIG	System, System.alt, System.log, System.sav
HKEY_CURRENT_USER	Ntuser.dat, Ntuser.dat.log
HKEY_LOCAL_MACHINE\SAM	Sam, Sam.log, Sam.sav
HKEY_LOCAL_MACHINE\Security	Security, Security.log, Security.sav
HKEY_LOCAL_MACHINE\Software	Software, Software.log, Software.sav
HKEY_LOCAL_MACHINE\System	System, System.alt, System.log, System.sav
HKEY_USERS\.DEFAULT	Default, Default.log, Default.sav

The Microsoft Computer Dictionary, Fifth Edition, defines the registry as:

A central hierarchical database used in Microsoft Windows 98, Windows CE, Windows NT, and Windows 2000 used to store information that is necessary to configure the system for one or more users, applications and hardware devices.

The Registry contains information that Windows continually references during operation, such as profiles for each user, the applications installed on the computer and the types of documents that each can create, property sheet settings for folders and application icons, what hardware exists on the system, and the ports that are being used.

The Registry replaces most of the text-based .ini files that are used in Windows 3.x and MS-DOS configuration files, such as the Autoexec.bat and Config.sys. Although the Registry is common to several Windows operating systems, there are some differences among them.

A registry hive is a group of keys, subkeys, and values in the registry that has a set of supporting files that contain backups of its data. The supporting files for all hives except HKEY_CURRENT_USER are in the %SystemRoot%\System32\Config folder on Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003, and Windows Vista. The supporting files for HKEY_CURRENT_USER are in the %SystemRoot%\Profiles\Username folder. The file name extensions of the files in these folders indicate the type of data that they contain. Also, the lack of an extension may sometimes indicate the type of data that they contain.

Registry hive	Supporting files
HKEY_LOCAL_MACHINE\SAM	Sam, Sam.log, Sam.sav
HKEY_LOCAL_MACHINE\Security	Security, Security.log, Security.sav
HKEY_LOCAL_MACHINE\Software	Software, Software.log, Software.sav
HKEY_LOCAL_MACHINE\System	System, System.alt, System.log, System.sav
HKEY_CURRENT_CONFIG	System, System.alt, System.log, System.sav, Ntuser.dat, Ntuser.dat.log
HKEY_USERS\DEFAULT	Default, Default.log, Default.sav

In Windows 98, the registry files are named User.dat and System.dat. In Windows Millennium Edition, the registry files are named Classes.dat, User.dat, and System.dat.

Note Security features in Windows NT, Windows 2000, Windows XP, Windows Server 2003, and Windows Vista let an administrator control access to registry keys.

The following table lists the predefined keys that are used by the system. The maximum size of a key name is 255 characters.

Folder/predefined key	Description
HKEY_CURRENT_USER	Contains the root of the configuration information for the user who is currently logged on. The user's folders, screen colors, and Control Panel settings are stored here. This information is associated with the user's profile. This key is sometimes abbreviated as "HKCU."
HKEY_USERS	Contains all the actively loaded user profiles on the computer. HKEY_CURRENT_USER is a subkey of HKEY_USERS. HKEY_USERS is sometimes abbreviated as "HKU."
HKEY_LOCAL_MACHINE	Contains configuration information particular to the computer (for any user). This key is sometimes abbreviated as "HKLM."
HKEY_CLASSES_ROOT	Is a subkey of HKEY_LOCAL_MACHINE\Software. The information that is stored here makes sure that the correct program opens when you open a file by using Windows Explorer. This key is sometimes abbreviated as "HKCR." Starting with Windows 2000, this information is stored under both the HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER keys. The HKEY_LOCAL_MACHINE\Software\Classes key contains default settings that can apply to all users on the local computer. The HKEY_CURRENT_USER\Software\Classes key contains settings that override the default settings and apply only to the interactive user. The HKEY_CLASSES_ROOT key provides a view of the registry that merges the information from these two sources. HKEY_CLASSES_ROOT also provides this merged view for programs that are designed for earlier versions of Windows. To change the settings for the interactive user, changes must be made under HKEY_CURRENT_USER\Software\Classes instead of under HKEY_CLASSES_ROOT. To change the default settings, changes must be made under HKEY_LOCAL_MACHINE\Software\Classes. If you write keys to a key under HKEY_CLASSES_ROOT, the system stores the information under HKEY_LOCAL_MACHINE\Software\Classes. If you write values to a key under HKEY_CLASSES_ROOT, and the key already exists under HKEY_CURRENT_USER\Software\Classes, the system will store the information there instead of under HKEY_LOCAL_MACHINE\Software\Classes.
HKEY_CURRENT_CONFIG	Contains information about the hardware profile that is used by the local computer at system startup.

Note The registry in 64-bit versions of Windows XP, Windows Server 2003, and Windows Vista is divided into 32-bit and 64-bit keys. Many of the 32-bit keys have the same names as their 64-bit counterparts, and vice versa. The default 64-bit version of Registry Editor that is included with 64-bit versions of Windows XP, Windows Server 2003, and Windows Vista displays the 32-bit keys under the following node:

HKEY_LOCAL_MACHINE\Software\WOW6432Node

For more information about how to view the registry on 64-Bit versions of Windows, click the following article number to view the article in the Microsoft Knowledge Base:

305097 How to view the system registry by using 64-bit versions of Windows

The following table lists the data types that are currently defined and that are used by Windows. The maximum size of a value name is as follows:

Windows Server 2003, Windows XP, and Windows Vista: 16,383 characters
Windows 2000: 260 ANSI characters or 16,383 Unicode characters
Windows Millennium Edition/Windows 98/Windows 95: 255 characters

Long values (more than 2,048 bytes) must be stored as files with the file names stored in the registry. This helps the registry perform efficiently. The maximum size of a value is as follows:

Windows NT 4.0/Windows 2000/Windows XP/Windows Server 2003/Windows Vista: Available memory
Windows Millennium Edition/Windows 98/Windows 95: 16,300 bytes

Note There is a 64K limit for the total size of all values of a key.

Name	Data type	Description
Binary Value	REG_BINARY	Raw binary data. Most hardware component information is stored as binary data and is displayed in Registry Editor in hexadecimal format.
DWORD Value	REG_DWORD	Data represented by a number that is 4 bytes long (a 32-bit integer). Many parameters for device drivers and services are this type and are displayed in Registry Editor in binary, hexadecimal, or decimal format. Related values are DWORD_LITTLE_ENDIAN (least significant byte is at the lowest address) and REG_DWORD_BIG_ENDIAN (least significant byte is at the highest address).
Expandable String Value	REG_EXPAND_SZ	A variable-length data string. This data type includes variables that are resolved when a program or service uses the data.
Multi-String Value	REG_MULTI_SZ	A multiple string. Values that contain lists or multiple values in a form that people can read are generally this type. Entries are separated by spaces, commas, or other marks.
String Value	REG_SZ	A fixed-length text string.
Binary Value	REG_RESOURCE_LIST	A series of nested arrays that is designed to store a resource list that is used by a hardware device driver or one of the physical devices it controls. This data is detected and written in the \ResourceMap tree by the system and is displayed in Registry Editor in hexadecimal format as a Binary Value.
Binary Value	REG_RESOURCE_REQUIREMENTS_LIST	A series of nested arrays that is designed to store a device driver's list of possible hardware resources the driver or one of the physical devices it controls can use. The system writes a subset of this list in the \ResourceMap tree. This data is detected by the system and is displayed in Registry Editor in hexadecimal format as a Binary Value.
Binary Value	REG_FULL_RESOURCE_DESCRIPTOR	A series of nested arrays that is designed to store a resource list that is used by a physical hardware device. This data is detected and written in the \HardwareDescription tree by the system and is displayed in Registry Editor in hexadecimal format as a Binary Value.
None	REG_NONE	Data without any particular type. This data is written to the registry by the system or applications and is displayed in Registry Editor in hexadecimal format as a Binary Value
Link	REG_LINK	A Unicode string naming a symbolic link.
QWORD Value	REG_QWORD	Data represented by a number that is a 64-bit integer. This data is displayed in Registry Editor as a Binary Value and was introduced in Windows 2000.

REPLICATION SEQUENCE

2011-12-09T13:58:00.001+05:30

Replication Sequence

AD REPLICATION PROTOCOLS

2011-12-09T13:40:00.001+05:30

The protocols that are used by Active Directory replication are described in the following table. RPC and SMTP are the replication transport protocols. LDAP is a directory access protocol, and IP is a network wire protocol.

Active Directory Access and Replication Protocols

Protocol	Description
LDAP	The primary directory access protocol for Active Directory. Windows Server 2003 family, Windows XP, Windows 2000 Server family, and Windows 2000 Professional clients, as well as Windows 98, Windows 95, and Windows NT 4.0 clients that have the Active Directory client components installed, use LDAP v3 to connect to Active Directory.
IP	Routable protocol that is responsible for the addressing, routing, and fragmenting of packets by the sending node. IP is required for Active Directory replication.
Replication RPC	The Directory Replication Service (Drsuapi) RPC protocol, used in the enabling of administration and monitoring of Active Directory replication, to communicate replication status and topology and network topology from a client running administrative tools to a domain controller. RPC is required by Active Directory replication.
Replication Simple Mail Transfer Protocol (SMTP)	Replication protocol that can be used by Active Directory replication over IP network transport for message-based replication between sites only and for non-domain replication only.

mx record

2011-12-04T01:28:00.001+05:30

Adding Mail Exchange Servers

MX records identify mail exchange servers for the domain. These servers are responsible for processing or forwarding mail within the domain. When you create an MX record, you must specify a preference number for the mail server. A preference number is a value from 0 to 65,535 that denotes the mail server's priority within the domain. The mail server with the lowest preference number has the highest priority and is the first to receive mail. If mail delivery fails, the mail server with the next lowest preference number is tried.

You create a MX record by doing the following:

In the DNS console, expand the Forward Lookup Zones folder for the server you want to work with.

Right-click the domain you want to update, and then from the pop-up menu, choose New Mail Exchanger. This opens the dialog box shown in Figure 19-10.

You can now create a record for the mail server by filling in these fields:

Host Or Domain Enter the optional host name.

Mail Server Enter the fully qualified host name.

Mail Server Priority Enter a preference number for the host from 0 to 65,535.

Figure : Mail servers with the lowest preference number have the highest priority.

Tip Assign preference numbers that leave room for growth. For example, use 10 for your highest priority mail server, 20 for the next, and 30 for the one after that.

Click OK.

What Is the Global Catalog?

2011-12-02T20:10:00.001+05:30

The global catalog is a distributed data repository that contains a searchable, partial representation of every object in every domain in a multidomain Active Directory Domain Services (AD DS) forest. The global catalog is stored on domain controllers that have been designated as global catalog servers and is distributed through multimaster replication. Searches that are directed to the global catalog are faster because they do not involve referrals to different domain controllers.

Note
In Windows Server® 2003 and Microsoft Windows® 2000 Server, the directory service is named Active Directory. In Windows Server 2008 R2 and Windows Server 2008, the directory service is named Active Directory Domain Services. The rest of this topic refers to AD DS, but the information is also applicable to Active Directory.

In addition to configuration and schema directory partition replicas, every domain controller in a forest stores a full, writable replica of a single domain directory partition. Therefore, a domain controller can locate only the objects in its domain. Locating an object in a different domain would require the user or application to provide the domain of the requested object.

The global catalog provides the ability to locate objects from any domain without having to know the domain name. A global catalog server is a domain controller that, in addition to its full, writable domain directory partition replica, also stores a partial, read-only replica of all other domain directory partitions in the forest. The additional domain directory partitions are partial because only a limited set of attributes is included for each object. By including only the attributes that are most used for searching, every object in every domain in even the largest forest can be represented in the database of a single global catalog server.

Note
A global catalog server can also store a full, writable replica of an application directory partition, but objects in application directory partitions are not replicated to the global catalog as partial, read-only directory partitions.

The global catalog is built and updated automatically by the AD DS replication system. The attributes that are replicated to the global catalog are identified in the schema as the partial attribute set (PAS) and are defined by default by Microsoft. However, to optimize searching, you can edit the schema by adding or removing attributes that are stored in the global catalog.

In Windows 2000 Server environments, any change to the PAS results in full synchronization (update of all attributes) of the global catalog. Later versions of Windows Server reduce the impact of updating the global catalog by replicating only the attributes that change.

In a single-domain forest, a global catalog server stores a full, writable replica of the domain and does not store any partial replica. A global catalog server in a single-domain forest functions in the same manner as a non-global-catalog server except for the processing of forest-wide searches.
Common Global Catalog Scenarios

The following events require a global catalog server:
Forest-wide searches. The global catalog provides a resource for searching an AD DS forest. Forest-wide searches are identified by the LDAP port that they use. If the search query uses port 3268, the query is sent to a global catalog server.

User logon. In a forest that has more than one domain, two conditions require the global catalog during user authentication:

In a domain that operates at the Windows 2000 native domain functional level or higher, domain controllers must request universal group membership enumeration from a global catalog server.

When a user principal name (UPN) is used at logon and the forest has more than one domain, a global catalog server is required to resolve the name.

Universal Group Membership Caching: In a forest that has more than one domain, in sites that have domain users but no global catalog server, Universal Group Membership Caching can be used to enable caching of logon credentials so that the global catalog does not have to be contacted for subsequent user logons. This feature eliminates the need to retrieve universal group memberships across a WAN link from a global catalog server in a different site.

Note
Universal groups are available only in a domain that operates at the Windows 2000 native domain functional level or higher.

Exchange Address Book lookups. Servers running Microsoft Exchange Server rely on access to the global catalog for address information. Users use global catalog servers to access the global address list (GAL).

Search Requests

Because a domain controller that acts as a global catalog server stores objects for all domains in the forest, users and applications can use the global catalog to locate objects in any domain within a multidomain forest without a referral to a different server.

When a forest consists of a single domain, every domain controller has a full, writable copy of every object in the domain and forest. However, it is important to retain the global catalog on at least one domain controller because many applications use port 3268 for searching. For example, if you do not have any global catalog servers, the Search command on the Start menu cannot locate objects in AD DS.

The replicas that are replicated to the global catalog also include the access permissions for each object and attribute. If you are searching for an object that you do not have permission to access, you do not see the object in the list of search results. Users can find only objects to which they are allowed access.
User Logon Support

In addition to its role as a search provider, in a forest that has more than one domain, the global catalog has a role as an identity source during the user logon process. Universal groups can provide access to resources outside of the user’s domain. User principal names (UPNs) can specify a domain other than the domain of the user. By making universal group membership and UPN domain-user mapping information available on all global catalog servers, the global catalog provides the definitive source for groups that are capable of providing access in more than one domain and names that do not unequivocally identify the domain of the user.
Universal Group Membership

During the domain logon process, the user must be authenticated. During the authentication process, the user is validated (the domain controller verifies the identity of the user) and the user receives authorization data for access to resources. To provide authorization data of a user, the authenticating domain controller retrieves the security identifiers (SIDs) for all security groups of which the user is a member and adds these SIDs to the user’s access token. In a forest that has more than one domain, the global catalog is the only location where memberships of all universal groups in that forest can be ascertained. For this reason, access to a global catalog server is required for successful authentication in a domain that can have universal groups.

The global catalog stores the membership (the member attribute) of only universal groups. The membership of other groups can be ascertained at the domain level.

Because a universal group can have members from domains other than the domain where the group object is stored and can be used to provide access to resources in any domain, only a global catalog server is guaranteed to have all universal group memberships that are required for authentication.

For example, a user might be a member of a universal group that has its group object stored in a different domain but provides access to resources in the user’s domain. To ensure that the user can be authorized to access resources appropriately in this domain, the domain controller must have access to the membership of all universal groups in the forest.

If a global catalog server is not available, the user logon fails.
User Principal Name

A user principal name (UPN) is a logon name that takes the form of an e-mail address. A UPN specifies the user ID followed by a DNS domain name, separated by an "@" character (for example, jsmith@contoso.com). UPNs allow administrative management of the UPN suffix to provide logon names that:
Match the user’s e-mail name.

Do not reveal the domain structure of the forest.

When a user account is created, the UPN suffix is generated by default as userName@ DnsDomainName, but it can be changed administratively. For example, in a forest that has four domains, the UPN suffix might be configured to map to the external DNS name for the organization. The userPrincipalName attribute of the user account identifies the UPN and is replicated to the global catalog.

When you use a UPN to log on to a domain, your workstation contacts a global catalog server to resolve the name because the UPN suffix is not necessarily the domain for which the contacted domain controller is authoritative. If the DNS domain name in the UPN suffix is not a valid DNS domain, the logon fails. Assuming the UPN suffix is a valid DNS name, the global catalog server returns the name of the AD DS domain to your workstation, which then queries DNS for a domain controller in that domain.

If a company has more than one forest and uses trust relationships between the domains in the different forests, a UPN cannot be used to log on to a domain that is outside the user’s forest because the UPN is resolved in the global catalog of the user’s forest.
Universal Group Membership Caching

Universal Group Membership Caching eliminates the need for a domain controller in a multidomain forest to contact a global catalog server during the logon process in domains where universal groups are available. Caching group membership reduces WAN traffic, which helps in sites where updating the cached group membership of security principals, including user and computer accounts, generates less traffic than replicating the global catalog to the site.

Use the following criteria to determine if a site is a good candidate for Universal Group Membership Caching:
Number of users and computers in the site: The site has less than 500 combined users and computers, including transient users who log on occasionally but not on a regular basis. The cache of a user who logs on once continues to be updated periodically for 180 days after the first logon. A general limit of 500 membership caches can be updated at a time. If greater than 500 security principals have cached group memberships, some caches might not be updated.

Number of domain controllers: Each domain controller performs a refresh on every user in its site once every eight hours. Depending on the number of domains in the forest, 500 security principals and two domain controllers could generate more WAN traffic than placing a global catalog server in the site. Therefore, you need to rationalize the WAN costs when exceeding 500 security principals and two domain controllers.

Tolerance for high latency in group updates. Because domain controllers in the site where Universal Group Membership Caching is enabled update the membership caches every eight hours, and because credentials are always taken from the cache, updates to group memberships are not reflected in the security principal’s credentials for up to eight hours.

Address Book Lookups

Exchange Server uses the global catalog to store mail recipient data that enables clients in a forest to send and receive e-mail messages.
Global Catalog Dependencies and Interactions

Global catalog servers have the following dependencies and interactions with other Windows Server technologies:
AD DS installation. When AD DS is installed on the first domain controller in a forest, the installation application creates that domain controller as a global catalog server.

AD DS replication. The global catalog is built and maintained by AD DS replication:

Subsequent to forest creation, when a domain controller is designated as a global catalog server, AD DS replication automatically transfers PAS replicas to the domain controller, including the partial replica of every domain in the forest other than the local domain.

To facilitate intersite replication of global catalog server updates, AD DS replication selects global catalog servers as bridgehead servers whenever a global catalog server is present in a site and domains that are not present in the site exist in other sites in the forest.

Domain Name System (DNS). Global catalog server clients depend on DNS to provide the IP address of global catalog servers. DNS is required to advertise global catalog servers for domain controller location.

Net Logon service. Global catalog advertisement in DNS depends on the Net Logon service to perform DNS registrations. When replication of the global catalog is complete, or when a global catalog server starts, the Net Logon service publishes service (SRV) resource records in DNS that specifically advertise the domain controller as a global catalog server.

Domain controller Locator: When a global catalog server is requested (by a user or application that launches a search over port 3268, or by a domain controller that is authenticating a user logon), the domain controller Locator queries DNS for a global catalog server.

In the following diagram, global catalog interactions include tracking a global catalog server through the following interactions, which are indicated by boxes:
Active Directory installation of a new forest: Global catalog creation occurs during AD DS installation of the first domain controller in the forest.

Net Logon registration: Resource records are registered in DNS to advertise the domain controller as a global catalog server.

AD DS replication:

When a new domain controller (DC2) is created and an administrator designates it as a global catalog server, replication of the PAS from DC1 occurs.

DC1 in DomainA replicates changes for DomainA to DC2, and DC2 replicates updates to data for DomainB to DC1.

DC location: The dotted lines enclose the processes whereby two clients locate a global catalog server by querying DNS:

A through C: (A) ClientX sends a query to the global catalog, which prompts (B) a DNS query to locate the closest global catalog server, and then (C) the client contacts the returned global catalog server DC2 to resolve the query.

1 through 5: (1) ClientY logs on to the domain, which prompts (2) a DNS query for the closest domain controllers. (3) ClientY contacts the returned domain controller DC3 for authentication. (4) DC3 queries DNS to find the closest global catalog server and then (5) contacts the returned global catalog server DC2 to retrieve the universal groups for the user.

Interactions with Other Windows Technologies The global catalog solves the problem of how to locate domain data that is not stored on a domain controller in the domain of the client that requires the information. By using different ports for standard LDAP queries (port 389) and global catalog queries (port 3268), AD DS effectively separates forest-wide queries that require a global catalog server from local, domainwide queries that can be serviced by the domain controller in the user’s domain

AD restore types

2011-12-02T20:01:00.001+05:30

Overview

Active Directory is backed up as part of system state, a collection of system components that depend on each other. You must back up and restore system state components together.

Components that comprise the system state on a domain controller include:

System Start-up Files (boot files). These are the files required for Windows 2000 Server to start.

System registry.

Class registration database of Component Services. The Component Object Model (COM) is a binary standard for writing component software in a distributed systems environment.

SYSVOL. The system volume provides a default Active Directory location for files that must be shared for common access throughout a domain. The SYSVOL folder on a domain controller contains:

NETLOGON shared folders. These usually host user logon scripts and Group Policy objects (GPOs) for non-Windows 2000based network clients.

User logon scripts for Windows 2000 Professionalbased clients and clients that are running Windows 95, Windows 98, or Windows NT 4.0.

Windows 2000 GPOs.

File system junctions.

File Replication service (FRS) staging directories and files that are required to be available and synchronized between domain controllers.

Active Directory. Active Directory includes:

Ntds.dit: The Active Directory database.

Edb.chk: The checkpoint file.

Edb*.log: The transaction logs, each 10 megabytes (MB) in size.

Res1.log and Res2.log: Reserved transaction logs.

Note: If you use Active Directory-integrated DNS, then the zone data is backed up as part of the Active Directory database. If you do not use Active Directory-integrated DNS, you must explicitly back up the zone files. However, if you back up the system disk along with the system state, zone data is backed up as part of the system disk.If you installed Windows Clustering or Certificate Services on your domain controller, they are also backed up as part of system state. Details of these components are not discussed in this guide.
Top of page

General Guidelines for Backup

The backup tool in Windows 2000 Server supports multiple types of backup: normal, copy, incremental, differential, and daily. However, because Active Directory is backed up as part of system state, the only type of backup available for Active Directory is normal. A normal backup creates a backup of the entire system state while the domain controller is online. In addition, the backup tool marks each file as a backed up file, which clears the archive attribute of the file.

Considerations for ensuring a good backup

To ensure a successful restore from backup, you must know what defines a good backup.

Which domain controllers to back up

At a minimum, back up two domain controllers in each domain, one of which should be an operations master role holder (excluding the relative ID (RID) master, which should not be restored). Note that backup data from a domain controller can only be used to restore that domain controller. You cannot use a backup of one domain controller to restore another.

Contents

A good backup includes at least the system state and the contents of the system disk. Backing up the system disk ensures that all the required system files and folders are present so you can successfully restore the data.

Note: Best performance practice states that the Active Directory's logs and database files should be on separate disks. If you have configured your domain controllers in this manner you will have Active Directory components spread out on multiple drives, such as D:\Winnt\NTDS for your logs and E:\Winnt\NTDS for your database. You do not need to specify these log and database locations in order for them to be backed up; the backup utility will automatically locate and include them when you back up system state.

Age

A backup that is older than the tombstone lifetime set in Active Directory is not a good backup. At a minimum, perform at least two backups within the tombstone lifetime. The default tombstone lifetime is 60 days. Active Directory incorporates the tombstone lifetime into the backup and restore process as a means of protecting itself from inconsistent data.

Deleting an object from Active Directory is a two-step process. When an object is deleted in Active Directory, the object gets converted into a tombstone, which is then replicated to the other domain controllers in the environment to inform them of the deletion. Active Directory purges the tombstone when the tombstone lifetime is reached.

If you restore a domain controller to a state prior to the deletion of an object, and the tombstone for that object is not replicated to the restored domain controller before the tombstone expires, the object remains present only on the restored domain controller, resulting in inconsistent data. Thus, you must restore the domain controller prior to expiration of the tombstone, and allow inbound replication from a domain controller containing the tombstone to complete prior to expiration of the tombstone.

Active Directory protects itself from restoring data older than the tombstone lifetime by disallowing the restore. As a result, the useful life of a backup is equivalent to the tombstone lifetime setting for the enterprise.
Top of page

General Guidelines for Restore

You can start the restore process by using either the Windows 2000 Server backup utility or another supported utility. You can perform either a non-authoritative restore or an authoritative restore.
Top of page

How to Select the Appropriate Restore Method

You select the appropriate restore method by considering:

Circumstances and characteristics of the failure. The two major categories of failure, from an Active Directory perspective, are Active Directory data corruption and hardware failure. Active Directory data corruption occurs when the directory contains corrupt data that has been replicated to all domain controllers or when a large portion of the Active Directory hierarchy has been changed accidentally (such as deletion of an OU) and this change has replicated to other domain controllers.

Roles and functions of the failed server.

Non-authoritative restore of Active Directory

A non-authoritative restore returns the domain controller to its state at the time of backup, then allows normal replication to overwrite that state with any changes that have occurred after the backup was taken. After you restore the system state, the domain controller queries its replication partners. The replication partners replicate any changes to the restored domain controller, ensuring that the domain controller has an accurate and updated copy of the Active Directory database.

Non-authoritative restore is the default method for restoring Active Directory, and you will use it in most situations that result from Active Directory data loss or corruption. To perform a non-authoritative restore, you must be able to start the domain controller in Directory Services Restore Mode.

Non-authoritative restore of SYSVOL

When you non-authoritatively restore the SYSVOL, the local copy of SYSVOL on the restored domain controller is compared with that of its replication partners. After the domain controller restarts, it contacts its replication partners, compares SYSVOL information, and replicate the any necessary changes, bringing it up-to-date with the other domain controllers within the domain.

Perform a non-authoritative restore of SYSVOL if at least one other functioning domain controller exists in the domain. This is the default method for restoring SYSVOL and occurs automatically if you perform a non-authoritative restore of the Active Directory.

If no other functioning domain controller exists in the domain, then perform a primary restore of the SYSVOL. A primary restore builds a new File Replication service (FRS) database by loading the data present under SYSVOL on the local domain controller. This method is the same as a non-authoritative restore, except that the SYSVOL is marked primary.

Authoritative restore of Active Directory

An authoritative restore is an extension of the non-authoritative restore process. You must perform the steps of a non-authoritative restore before you can perform an authoritative restore. The main difference is that an authoritative restore has the ability to increment the version number of the attributes of all objects in an entire directory, all objects in a subtree, or an individual object (provided that it is a leaf object) to make it authoritative in the directory. Restore the smallest unit necessary, for example, do not restore the entire directory in order to restore a single subtree.

As with a non-authoritative restore, after a domain controller is back online, it will contact its replication partners to determine any changes since the time of the last backup. However, because the version number of the object attributes that you want to be authoritative will be higher than the existing version numbers of the attribute held on replication partners, the object on the restored domain controller will appear to be more recent and therefore will be replicated out to the rest of the domain controllers within the environment.

Unlike a non-authoritative restore, an authoritative restore requires the use of a separate tool, Ntdsutil.exe. No backup utilities— including the Windows 2000 Server system tools— can perform an authoritative restore.

An authoritative restore will not overwrite new objects that have been created after the backup was taken. You can authoritatively restore only objects from the configuration and domain-naming contexts. Authoritative restores of schema-naming contexts are not supported.

Perform an authoritative restore when human error is involved, such as when an administrator accidentally deletes a number of objects and that change replicates to the other domain controllers and you cannot easily recreate the objects. To perform an authoritative restore, you must start the domain controller in Directory Services Restore Mode.

Authoritative restore of SYSVOL

By authoritatively restoring the SYSVOL, you are specifying that the copy of SYSVOL that is restored from backup is authoritative for the domain. After the necessary configurations have been made, Active Directory marks the local SYSVOL as authoritative and it is replicated to the other domain controllers within the domain.

The authoritative restore of SYSVOL does not occur automatically after an authoritative restore of Active Directory. Additional steps are required.

As with Active Directory authoritative restore, you typically perform an authoritative restore of SYSVOL when human error is involved and the error has replicated to other domain controllers. For example, you might perform an authoritative restore of SYSVOL if an administrator has accidentally deleted an object that resides in SYSVOL, such as a Group Policy object.

Recover a domain controller through reinstallation

To recover a domain controller through reinstallation, you do not restore the system state from backup media; instead, you reinstall Windows, install Active Directory, and allow replication partners to bring the recovered domain controller up to date.

Recovering a domain controller through reinstallation can quickly return the computer to service if the following conditions exist:

A domain controller has failed and you cannot restart in Directory Services Restore mode. If failure was caused by a hardware failure, you have resolved the hardware problem (for example, by replacing the disk).

There are other domain controllers in the domain, to serve as replication partners.

The computer is functioning only as a domain controller (it does not run other server services such as Exchange), and it does not contain other data that needs to be recovered from a backup.

Restore a domain controller through reinstallation and restore from backup

This method involves first reinstalling Windows 2000, to enable you to start in Directory Services Restore Mode. During the Windows 2000 Server setup process, you will obtain more information about the nature of the failure and you can then determine whether you can reinstall Windows 2000 Server into the same partition as it was previously installed or whether you will need to re-partition the drive. After you successfully reinstall Windows 2000, you can start in Directory Services Restore Mode and perform a normal non-authoritative restore from backup media.

Restore a domain controller through reinstallation and restore the system state from backup if the following conditions exist:

A domain controller has failed and you cannot restart in Directory Services Restore mode. If failure was caused by a hardware failure, you have resolved the hardware problem (for example, by replacing the disk).

You have the following information about the failed domain controller:

Disk configuration. You need a record of the volumes and sizes of the disks and partitions. You use this information to recreate the disk configuration in the case of a complete disk failure. You must recreate all disk configurations prior to restoring system state. Failure to recreate all disk configurations can cause the restore process to fail and can prevent you from starting the domain controller following the restore.

Computer name. You need the computer name to restore a domain controller of the same name and avoid changing client configuration settings.

Domain membership. You must know the domain name because even if the computer name does not change, you might need to re-establish a new computer account.

Local Administrator password. You must know the local computer's Administrator password that was used when the backup was created. Without it, you will not be able to log on to the computer to establish a domain account for the computer after you restore it. If you are not part of the domain, you will not be able to log on by using a domain account, even if you are a domain administrator. The local Administrator password is also required to restore the system state on a domain controller.

The domain controller is running other server services such as Exchange, or contains other data you must restore from a backup.

You have a good backup, made within the tombstone lifetime.

Considerations for restoring operations masters

To restore an operations master role holder, you must perform one of the following procedures:

Restore the failed operations master from backup.

Seize the role to another domain controller within the environment. Seize the operations master role only if you do not intend to restore the original role holder from backup. For more information about seizing operations master roles, see "Managing Operations Masters" in this guide.

Restoring the RID Master can result in Active Directory data corruption, so it is not recommended.

Restoring the Schema Master can result in orphaned objects, so it is not recommended.

Considerations for recovering global catalog servers

To recover the global catalog server you can either:

Restore the failed global catalog server from backup.

Assign a new global catalog to compensate for the loss of the original.

Restoring from backup is the only way that a domain controller that was functioning as a global catalog at the time of backup can automatically be restored to the role of global catalog. Restoring a domain controller by reinstallation does not automatically reinstate the global catalog role. In a multi-domain environment, be aware that restoring a global catalog server from backup requires more time than restoring a domain controller that does not host the global catalog.

As there are no real disadvantages in configuring multiple global catalogs, you might want to create a new global catalog in your environment if you anticipate an extended downtime for the failed global catalog server. Creating a new global catalog server is particularly relevant if users associated with the original global catalog server can no longer access a global catalog server, or if the requirement for the global catalog service is significant in your environment, such as when you are running Exchange 2000.

For more information about creating a new global catalog server, see "Managing Global Catalogs Servers" in this guide.

Note: Configuring multiple global catalogs servers in a forest increases the availability of the system, but also increases replication traffic and database size. If you do restore the failed domain controller and maintain its role as a global catalog server, you might want to remove any additional global catalogs servers that you configured during its absence.

Considerations for restoring onto different hardware

It is possible to restore a domain controller onto different hardware. However, you should consider the following issues:

Different hardware abstraction layers (HALs). By default, the Hal.dll is not backed up as part of system state, however the Kernel32.dll is. Therefore, if you try to restore a backup onto a computer that requires a different HAL (for example, to support a multiprocessor environment) compatibility issues exist between the new HAL and the original Kernel32.dll. To overcome this incompatibility, manually copy the Hal.dll from the original computer and install it on the new computer. The limitation is that the new computer can use only a single processor.

Incompatible Boot.ini File. If you backup and restore the boot.ini file, you might have some incompatibility with your new hardware configuration, resulting in a failure to start. Before you restore it, ensure that the boot.ini file is correct for your new hardware environment.

Different Network or Video Cards. If your new hardware has a different video adapter or multiple network adapters, then uninstall them before you restore data. When you restart the computer; the normal Plug and Play functionality makes the necessary changes.

Disk Space and Partition Configuration. Partitions on the new computer must match those on the original computer. Specifically, all the drive mappings must be the same and the partition size must be at least equal to that on the original computer.

Considerations for authoritative restores

Performing an authoritative restore can affect group membership and passwords for trusts and computer accounts.

Impact on group membership

By performing an authoritative restore, you risk possible loss of group membership information.

Because group membership is a multi-valued attribute, and because of how Active Directory handles links, back links and deletions, an authoritative restore can produce varying results to group membership. These variations are based on which objects replicate first after an authoritative restore: the User object or the Group object.

If the un-deletion of the user replicates first, then the group membership information of both the group (the members it contains) and the user (the groups to which the user belongs) will be represented correctly.

If the un-deletion of the group replicates first, the replication partners will drop the addition of the (locally) deleted user from the group membership. The only exception to this is the user's primary group, which is always represented correctly both from the user and group reference.

You cannot control which object replicates first after you perform an authoritative restore. If your environment is affected by this situation, the only option is to modify the group membership attribute of the affected groups on the domain controller where you performed the authoritative restore.

This issue stems not from the integrity of the restored data, but from the way in which the data is replicated. By looking at this domain controller, administrators can view the way the directory should look and take steps to replicate the accurate directory information to the other domain controllers within the domain.

The best way to do this is to add a fictitious user and then delete that same fictitious user to and from each group that was involved in the authoritative restore.

A group is involved in the restore if it was either authoritatively restored itself or if it had members restored who did not have that group defined as their primary group.

By doing this, you force the correct group membership information to be replicated out from the source domain controller (the domain controller on which you performed the original authoritative restore) and update the group membership information on its replication partners. These updated objects reflect the correct memberships and also correct the information represented in the Member of tab of the restored user objects' properties.

You must ensure that no additions are made to group membership (for the affected groups and users) on any of the other domain controllers within the environment.

If you do not adhere to this process, the accurate version of the directory (held on the domain controller where the restore was performed) can become corrupted by the incorrect membership information. If the accurate version of the directory becomes corrupted, you must either update group membership manually or perform another authoritative restore of the objects by using the verinc option, and perform the process again.

Impact on trusts and computer accounts

In Windows 2000, trust relationships and computer account passwords are negotiated at a specified interval (by default 30 days for trust relationships and computer passwords).

When you perform an authoritative restore, you might restore previously used passwords for the objects in the Active Directory that maintain trust relationships and computer accounts.

In the case of trust relationships, this can impact communication with other domain controllers from other domains, causing permissions errors when users try to access resources in other domain. To rectify this, you must remove and recreate NTLM trust relationships to Windows 2000 or Windows NT 4.0 domains.

In the case of a computer account password, this can impact communications between the member workstation or server and a domain controller of its domain. This effect might cause users on Windows NT or Windows 2000 computers to have authentication difficulty due to an invalid computer account.
Top of page

Backup and Restore Tasks and Procedures

Table 1.8 shows the tasks and procedures for backup and restore.

Table 1.8 Backup and Restore Tasks and Procedures

Tasks

Procedures

Tools

Frequency

Back up Active Directory and associated components.

Back up system state on a domain controller.

Back up system state and system disk on a domain controller.

NTBackup.exe

At least twice within the tombstone lifetime

Perform a non-authoritative restore.

Restart the domain controller in Directory Services Restore Mode (locally or remotely).

Restore from backup media.

Verify Active Directory restore.

NTBackup.exe

Ntdsutil.exe

Event Viewer

Repadmin.exe

As needed

Perform an authoritative restore of a subtree or leaf object.

Restart in Directory Services Restore Mode.

Restore from backup media for authoritative restore.

Restore system state to an alternate location.

Perform authoritative restore of the subtree or leaf object.

Restart in normal mode.

Restore applicable portion of SYSVOL from alternate location.

Verify Active Directory restore.

NTBackup.exe

Ntdsutil.exe

Event Viewer

Repadmin.exe

As needed

Perform an authoritative restore of the entire directory.

Restart in Directory Services Restore Mode.

Restore from backup media for authoritative restore.

Restore system state to an alternate location.

Restore the database.

Restart in normal mode.

Copy SYSVOL from alternate location.

Verify Active Directory restore.

NTBackup.exe

Ntdsutil.exe

Event Viewer

Repadmin.exe

As needed

Recover a domain controller through reinstallation.

Clean up metadata.

Install Windows 2000 Server.

Install Active Directory.

Ntdsutil.exe

Active Directory Sites and Services

Active Directory Users and Computers

Dcpromo.exe

As needed

Restore a domain controller through reinstallation and subsequent restore from backup.

Install Windows 2000 Server on the same drive letter and partition as before the failure, partitioning the drive if necessary.

Restore from backup media (non-authoritative restore).

Verify Active Directory restore.

NTBackup.exe

As needed

Top of page

Backing Up Active Directory and Associated Components

To back up Active Directory and associated components on a domain controller, you can back up only system state or you can back up both system state and the system disk.
Top of page

Procedures for Backing Up Active Directory and Associated Components

Use one of the following procedures to back up Active Directory and associated components. Procedures are explained in detail in the linked topics.

Back up system state.

Back up system state and the system disk.
Top of page

Performing a Non-Authoritative Restore

Non-authoritative restore is the default method for restoring Active Directory, and you use it in most situations that result from Active Directory data loss or corruption. You must be able to start in Directory Services Restore Mode to perform a non-authoritative restore. After you restore the domain controller from backup media, replication partners use the standard replication protocols to update both the Active Directory and FRS on the restored domain controller.
Top of page

Procedures for Performing a Non-Authoritative Restore

Use the following procedures to perform a non-authoritative restore of a domain controller. Procedures are explained in detail in the linked topics.

Restart the domain controller in Directory Services Restore Mode (locally or remotely).

Restore from backup media.

Verify Active Directory restore.
Top of page

Performing an Authoritative Restore of a Subtree or Leaf Object

An authoritative restore of a subtree or leaf object restores that subtree or leaf and marks it as authoritative for the directory. You begin by restoring from backup media, just as in a non-authoritative restore, but then you perform additional steps to complete an authoritative restore.
Top of page

Procedures for Authoritative Restore of a Subtree or Leaf Object

Use the following procedures to perform an authoritative restore of an Active Directory subtree or leaf object. Procedures are explained in detail in the linked topics.

Restart the domain controller in Directory Services Restore Mode (locally or remotely).

Restore from backup media for authoritative restore.

Restore system state to an alternate location.

Perform authoritative restore of the subtree or leaf object.

Restore applicable portion of SYSVOL from alternate location if necessary.

Verify Active Directory restore.
Top of page

Performing an Authoritative Restore of Entire Directory

Authoritative restore of the entire directory is a major operation. Perform an authoritative restore of the entire directory only after consultation with a Microsoft Support professional. Do not perform an authoritative restore of the entire directory if only one domain controller exists in the domain.
Top of page

Procedures for Authoritative Restore of the Entire Directory

Use the following procedures to perform an authoritative restore of the entire Active Directory. Procedures are explained in detail in the linked topics.

Restart the domain controller in Directory Services Restore Mode (locally or remotely).

Restore from backup media.

Restore system state to an alternate location.

Perform authoritative restore of entire directory.

Restore SYSVOL from alternate location.

Verify Active Directory restore.
Top of page

Recovering a Domain Controller Through Reinstallation

Recovering through reinstallation is the same process as creating a new domain controller. It does not involve restoring from backup media. This method relies on Active Directory replication to restore a domain controller to a working state, and is only valid if another healthy domain controller exists in the same domain. This option is normally used on computers that function only as a domain controller.
Top of page

Bandwidth Considerations

The primary consideration when recovering a domain controller through replication is bandwidth. The bandwidth required is directly proportional to the size of the Active Directory database and the time in which the domain controller is required to be at a functioning state. Ideally, the existing functional domain controller is located in the same Active Directory site as the replicating domain controller (new domain controller) in order to reduce network impact and restore duration.
Top of page

Procedures for Recovering a Domain Controller Through Reinstallation

Use the following procedures to recover a domain controller. Procedures are explained in detail in the linked topics.

Clean up metadata.

Reinstall Windows 2000 Server. (This procedure is not covered in this guide.)

Install Active Directory. During the installation process, replication occurs, ensuring that the domain controller has an accurate and up to date copy of the Active Directory. For more information about seizing operations master roles, see "Installing Active Directory" in this guide.
Top of page

Restoring a Domain Controller Through Reinstallation and Subsequent Restore from Backup

If you cannot restart a domain controller in Directory Services Restore Mode, you can restore a domain controller through reinstallation and subsequently restore Active Directory from backup. This option is normally used on domain controllers that also run other services, such as Exchange, or have other data you want to recover.
Top of page

Procedures for Restoring a Domain Controller Through Reinstallation and Subsequent Restore from Backup

To restore a domain controller through reinstallation and subsequently restore Active Directory from backup, you must ensure that you install Windows 2000 Server on the same drive letter and on a partition that is at least as large as the partition used before the failure. You must repartition the drive if necessary. After you reinstall Windows 2000, perform a non-authoritative restore of the system state and the system disk. Procedures are explained in detail in the linked topics.

Install Windows 2000 Server on the same drive letter and partition as before the failure. (This procedure is not covered in this guide.)

Restore from backup media.

Verify Active Directory restore.