Active Directory

IgNiTeD SoUL
The Technical Information Hub
stay updated via rss
Posts Tagged ‘Active Directory’
This source server failed to generate the changes
Posted: January 16, 2014 in Active Directory, Domain Controller, Registry, Replication, Server, Server
2003, Server 2008
Tags: Active Directory, Active Directory Domain Services, database version, directory service, Registry,
Replication, Server, Server 2003, Server 2008
0
Alert: This source server failed to generate the changes
Description: This directory service failed to retrieve the changes requested for the following directory partition.
As a result, it was unable to send change requests to the directory service at the following network address.
(http://ignitedsoul.files.wordpress.com/2014/01/1479.jpg)
Event ID: 1479
Active Directory Domain Services could not update the following object in the local Active Directory Domain
Services database with changes received from the following source directory service. Active Directory Domain
Services does not have enough database version store to apply the changes.
User Action
Restart this directory service. If this does not solve the problem, increase the size of the database version store. If
you are populating the objects with a large number of values, or the size of the values is especially large, decrease
the size of future changes.

Additional Data
Error value:
8573 The database is out of version store.

Resolution:
{MS has provided the resolution in this Link (http://support.microsoft.com/kb/974803)}
Note: Take Backup of Registry before changing

Registry Location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

You need to add the Registry value “EDB max ver pages” with 32 Bit DWord Decimal value as you need with
reference below:
9600 = 152 MB
12800 = 202 MB
16000 = 252 MB
19200 = 302 MB
Reboot the Server once the changes have been done.
Check the Event viewer after restart; you need to get event 1394 in ADS Logs
(http://ignitedsoul.files.wordpress.com/2014/01/1394.jpg)
The version store has reached its maximum size because of
unresponsive transaction
Posted: July 26, 2013 in Active Directory, Domain Controller, Server, Server 2008
Tags: Active Directory, Server 2008, technology
0

This Alert occurs in 2008 R2 Servers
——————————————————————————
Alert: Active Directory cannot update object due to insufficient memory
Last modified by: System
Last modified time: 7/18/2013 1:02:10 PM
Alert description: Active Directory Domain Services could not update the following object in the local Active
Directory Domain Services database with changes received from the following source directory service. Active
Directory Domain Services does not have enough database version store to apply the changes.
User Action
Restart this directory service. If this does not solve the problem, increase the size of the database version store. If
you are populating the objects with a large number of values, or the size of the values is especially large, decrease
the size of future changes.
——————————————————————————-
Additional Data
Reboot will clear the version table but it does nothing to identify or resolve the core issue.
The version store has reached its maximum size because of unresponsive transaction. Updates to database are
rejected until the long-running transaction is omitted or rolled back. TechNet suggested looking for event IDs-
1022, 1069,623 and none of these event ids could be found in event viewer.
Resolution:
Below is the solution but it is your own risk to change registry setting.
Backup the Registry before Proceeding

1. Update ‘Version Store Size’ (the Ops Mgr Agent queue/cache Db) by using Regedit to change
“HKLM\System\CurrentControlSet\Services\HealthService\Parameters\”Persistence Version Store
Maximum”.
Value should be 5120 (decimal) (equates to 80MB).
2. Update value for ‘MaximumQueueSizeKb’ in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HealthService\Parameters\Management
Groups\<ManagementGroupName> Value should be 102400 (decimal)
“Please reboot the server”
Check in the Event Viewer for Event ID 1394 “All Problems preventing updates to the Active Directory Domain
Services database have been cleared. New Updates to the Active Directory Domain Services database are
succeeding. The Net Logon service has restarted”
You can find this event in “Directory Services” Log of the Domain Controller.
Troubleshooting Group Policy application
Posted: June 12, 2013 in Active Directory, Group Policy, Server, Server 2003, Server 2008, Windows 7,
Windows XP, WorkStation
Tags: Active Directory, gpresult, Group Policy, Group Policy Management, group policy objects,
Server, Server 2003, Server 2008
0
Summary: Group Policy application seems straightforward enough: Group Policy Objects (GPOs) are linked to
organizational units (OUs); users and computers are in OUs. All the GPOs from a user’s OU hierarchy filter
down to the user.
Things get more complicated, though, when you remember that GPOs can be linked to a domain and to sites—
meaning you’ll have to open a whole new console to see what’s going on. You also have to consider local security
policies, which exist solely on the client computer and are applied before any domain-based policies arrive. Throw
in options such as Block Policy Inheritance, No Override, and loopback processing, and it’s no wonder why
there’s such a robust market for third-party GPO tools. However, with some patience and a methodology, you
can do quite a bit of quality troubleshooting on your own.
Start from the Scratch
Too many administrators try to start at the top, working their way down the hierarchy of GPOs and figuring out
which ones apply. That method is time-consuming, error-prone, and just plain boring. It’s a lot easier to start at
the bottom—the client—and work your way up the tree. Windows XP’s Gpresult tool, for example, is a great
troubleshooting tool. Run from the command line, it will tell you which groups the current user is a member of
(which can affect GPO application), and give you a list of every GPO that is currently affecting the user. You’ll
also see the last time that GPOs were applied to the computer. What Gpresult is displaying is called resultant set
of policy (RSOP). It sorts through all the blocked inheritance, no overrides, and conflicting policies to sort out
exactly which policies are being applied.
By default, Gpresult doesn’t show you which individual policies are applied or what they are set to; because
GPOs successively overwrite one another as they are applied, you can still be left with a troubleshooting task to
figure out which of the GPOs listed is responsible for the settings you’re seeing. Fortunately, Gpresult has a
“superverbose” mode, enabled by running
Gpresult /z
This mode not only displays which GPOs have been applied, but lists every single policy that’s enabled in each
GPO, allowing you to see which GPO modified which setting, and which GPO finally won out in the end. Figure
36.1 shows a portion of Gpresult’s superverbose output. In this example, the GPO being applied is Local Group
Policy, and you can see exactly which registry keys each setting is modifying.
Superverbose mode also breaks down the user and computer policies, allowing you to see every setting that is
affecting the current users or their machines.
How does Active Directory enable Centralized Administration?
Posted: February 22, 2013 in Active Directory, Server, Server 2003, Server 2008
Tags: Active Directory, directory object, policy settings, Server, Server 2003, Server 2008
0

1. Active Directory contains information about all objects and their attributes. The attributes hold data that
describes the resource that the directory object identifies. Because information about all network resources is
stored in Active Directory, a single administrator can centrally manage and administer network resources.
2. Active Directory can be queried by using protocols such as LDAP. Administrators can easily locate
information about objects by searching for selected attributes of the object, using tools that support LDAP.
3. Active Directory allows you to group objects with similar administrative and security requirements into
organizational units. Organizational units provide multiple levels of administrative authority for both
applying Group Policy settings and delegating administrative control. This delegation of administrative
authority simplifies the task of managing these objects and allows administrators to structure Active Directory
to fit their needs.
4. Active Directory uses Group Policy to provide administrators with the ability to specify Group Policy settings
for a site, domain, or organizational unit. Active Directory then enforces these Group Policy settings for all of
the users and computers within the container.

Structures of Active Directory
Posted: February 20, 2013 in Active Directory, Domain Controller, Server 2008
Tags: Active Directory, administrative boundary, grouping objects, Server 2008
1
Active Directory (http://ignitedsoul.com/tag/active-directory/) is made up of components that constitute its logical
and physical structure. To administer Active Directory, we must understand the purpose of these components

Logical Structure: The logical structure of Active Directory provides methods for organizing network resources
such as computers, printers, users and groups. It is made up of objects, organizational units, domains,
domain trees, and forests.

1. Objects
The object is the most basic component of the logical structure. Object classes are template for the types of objects
that can be created in Active Directory. Each object class is defined by a group of attribute. Attributes define the
possible values that can be associated with an object. Each object has a unique combination of attribute values.

2. Organizational units
Organizational units are container objects that are used to group other objects in a manner that supports your
Organizational units are container objects that are used to group other objects in a manner that supports your
administrative purposes. By grouping objects by organizational unit in a logical fashion, it becomes easier to
locate and administer objects. We can also delegate the authority to administer an organizational unit.
Organizational units can be nested in other organizational units. By nesting organizational units, we can further
simplify the administration of objects.

3. Domains
Domains are the core functional units in the Active Directory logical structure. A domain is a collection of objects
that share a common directory database, security policies, and security relationships with other domains.
Domains provide the following three functions:
• Serve as an administrative boundary for objects
• Help to manage security for shared resources
• Serve as a unit of replication for objects

4. Domain Trees
Domains can be grouped together in hierarchical structures that are called trees. When a second domain is added
to a tree, it becomes a child of the tree root domain. The domain to which a child domain is attached is called the
parent domain. A child domain may in turn have its own child domain. The name of a child domain is combined
with the name of its parent domain to form its own unique Domain Name System (DNS) name. In this manner,
a tree has a contiguous namespace.

5. Forests
Forests are made up of one or more trees, although a single two-level tree is recommended for most
organizations. A two-level tree is when all child domains are made children of the forest root domain to form one
contiguous tree. The first domain in the forest is called the forest root domain, and the name of that domain is
used to refer to the forest. A forest is a complete instance of Active Directory. By default, the information within
Active Directory is shared only within the forest. In this way, the forest is a security boundary for the information
contained in the instance of Active Directory.

Physical Structure: The physical structure of Active Directory models the physical structure of the network, and
is made up of domain controllers and sites. The physical structure of Active Directory defines where and when
replication and logon traffic occur, and is used to and manage network traffic. The physical structure enables you
to optimize network traffic by determining when and where replication and logon traffic occur. The elements of
the Active Directory physical structure are:

1. Domain controllers (http://ignitedsoul.com/category/domain-controller/)Domain controller performs
storage and replication functions. A domain controller can support only one domain. A domain can have one or
more domain controllers.

2. Active Directory (http://ignitedsoul.com/tag/active-directory/) sites Created mainly to optimize
replication traffic and to enable users to connect domain controllers by using reliable, high speed connection. A
site is a group of well-connected computers. When sites are established, domain controllers within a single site
communicate frequently. This communication minimizes the latency within the site. Latency is the time required
for a change that is made on one domain controller to be replicated on other domain controllers. You create sites
to optimize the use of bandwidth between separated domain controllers. There can be multiple domains in a
single site and single site can have multiple sites.

Note: We use Logical structure to organize the network resources and Physical structure to manage the network
traffic.

How Active Directory Enables a Single Sign-on?
Posted: February 20, 2013 in Active Directory, Domain Controller, Server, Server 2003, Server 2008
Tags: Active Directory, kerberos, Server 2003, Server 2008, Single Sign ON
1
Active Directory (http://ignitedsoul.com/tag/active-directory/) enables a single sign-on, which makes the complex
processes of authentication and authorization transparent to the user. A single sign-on is made up of
authentication, which verifies the credentials of the connection attempt, and authorization, which verifies that the
connection attempt is allowed. With a single sign-on, users do not have to manage multiple sets of credentials and
can access the resources for which they are authorized without thinking about the processes that occur behind
the scenes. However, as a systems engineer, we must understand how these processes work in order to
troubleshoot the Active Directory (http://ignitedsoul.com/tag/active-directory/) structure.

The single sign-on process occurs as follows:

1. The user enters credentials at a workstation to perform an interactive logon.
2. The credentials are encrypted by the client and sent to a domain controller for the client’s domain.
3. The encrypted credentials that are sent from the client are matched against the encrypted credentials on the
domain controller (http://ignitedsoul.com/category/domain-controller/). A Kerberos
(http://ignitedsoul.com/2011/08/01/kerberos-troubleshooting-tools/) service, the Key Distribution Center
(KDC), resides on each domain controller and stores the encrypted user credentials. If the credentials sent by
the client match the credentials stored by the KDC, the process continues.
4. The domain controller creates a list of the domain-based groups to which the user belongs.
5. The domain controller queries the global catalog (http://ignitedsoul.com/tag/global-catalog/) to identify the
universal groups to which the user belongs. If the domain controller has Universal group membership
caching enabled, the global catalog is not queried and the Universal group memberships are obtained from
the cache on the domain controller.
6. The KDC issues the client a ticket-granting ticket (TGT). The TGT contains the encrypted security identifiers
(SIDs) for the groups of which the user is a member.
7. The client requests access to a resource that resides on a specific server.
8. The client uses the TGT to gain access to the ticket-granting service (TGS), on the domain controller.
9. The TGS issues a service ticket, which is also called a session ticket, for the server where the resource resides to
the client. The session ticket contains the SIDs for the user’s group memberships.
10. The client presents the session ticket to the server where the resource resides. The Local Security Authority
(LSA) on the server uses the information in the session ticket to create an access token.
11. The LSA compares the SIDs in the access token with the groups that are assigned permissions in the resources
discretionary access control list (DACL). If they match, the user is granted access to the resource.

Resource Record types in DNS
Posted: February 20, 2013 in Active Directory, DNS, Server, Server 2003, Server 2008
Tags: Active Directory, CNAME, DNS, mx mail, ns name server, PTR, record maps, Resource Records,
Server, Server 2003, Server 2008, SRV
0
Record type Name Description
A Address Record Maps a hostname to an IP address
PTR Pointer Record Maps an IP address to a hostname
CNAME Alias Record Maps an alias to a hostname
MX
Mail Exchanger
Record
Specifies a mail route for a domain
NS
Name Server
Record
Specifies name servers for a given domain
SOA
Start of Authority
Record
Contains administrative data about a zone, including the primary
name server
SRV Service Record Maps a particular service (e.g., LDAP) to one or more hostnames
One important resource record to note is the SRV record type. SRV records are used extensively by domain
controllers and Active Directory clients to locate servers that have a particular service.

AGDLP (Accounts, Global groups, Domain Local
groups, Permissions)
Posted: January 18, 2013 in Active Directory, Server, Server 2003, Server 2008, System Information
Tags: Active Directory, AGDPL, Distribution Groups, domain resource, global groups, Groups, Role
Based Access Control
0
AGDLP briefly summarizes Microsoft’s recommendations for implementing role based access controls (RBAC)
using nested groups in a native-mode Active Directory (AD) domain: User and computer accounts are members
of global groups that represent business roles, which are members of domain local groups that describe
resource permissions or user rights assignments.
AGDLP, which stands for Accounts, Global groups, Domain Local groups and Permissions, refers to the practice
you use to properly assign permissions to your network resources and utilize groups in such a way that
managing those permissions and group memberships is simplified and configured to allow for multiple domain
resource access.
AGDLP is applied when planning and implementing the construction of users and groups as well as the setting
of NTFS permissions on the resources concerned.”
Using AGDLP allows admins to set up their Windows environments so they can greatly reduce problems related
to user account management and permissions management headaches. Yet even those who have gone through
MCSE training still fail to use this simple strategy when setting up their strategy for groups and permission
assignments.
There have been many times I’ve had to correct my customers’ groups/permissions-related issues because they
chose to only use individual accounts, or just Domain Local groups or just Global Groups, when assigning
permissions to their resources. Then they add a new domain, create a new resource, add a new user or when
someone leaves an organization and is replaced, it becomes a serious nightmare when trying to get the
permissions setup properly after those changes have been made.
Using AGDLP gives you the following benefits:
You can assign local resource access to users in other domains
A user’s access to a resource can be removed, simply by removing their account from the appropriate group.
If you set up your permissions properly, when a new user is created, you only need to add them to the
appropriate group and their permissions will setup little to no additional work.
Following an AGDLP strategy:
1. A: Create a user Account(s)
2. G: Create a global group and add the user account(s) you created in step as members
3. DL: Create a Domain Local group in the domain that contains the resource you wish to give access to and
then add the global group from step 2 as a member of this Domain Local group
4. P: Assign permissions on the resource using the domain local group created in a step.
System Error 8: Not Enough storage is available to process
this command
Posted: October 9, 2012 in Active Directory, Registry, Server, Server 2003, Server 2008
Tags: Active Directory, DNS, Not Enough storage is available to process this command, Registry,
Server, Server 2003, Server 2008, System Error 8
1
Symptoms:
- The Server service fails to start and the below events are recorded
Event ID: 7023
Source: Service Control manager
Type: Error
Description: The Server service terminated with the following error: More data is available.
- Not Enough storage is available to process this command.
Event ID: 7001
Source: Service Control manager
Type: Error
Description: The Netlogon service depends on the server service which failed to start because of the following
error: More data is available.
- System Error 8 has occurred. Not enough storage is available to process this command.
- If you try to start the Server Service manually, the following errors may occur: A System error has
occurred: System Error 234 has occurred.
- You will not be able to execute any command in the Server.
- You get error message when you open the Network connections (ncpa.cpl)
Observations:
- Other services may fail to start because these services are dependent on the Server Service.
- The Server service queries the registry value above for its entries. The buffer for the amount of information
that the Server service can accept when it queries is approximately 32 KB. If there are more than 32 KB in that
entry, the Server service will fail to start and return the error “More data is available,” or “Not enough storage is
available.”
- It looks like certain software’s can also cause for this error, those maybe the Norton Antivirus, Acronis
trueImage, Seagate DiscWizard, IBM antivirus, Microsoft Bitdefender, Symantec Endpoint Protection or AVG,
Try Disabling them or uninstalling and check if the problem persists.
- You can instantly rectify this error if you restart the server, but the error re-occurs in 2 to 3 days.
Resolution:
PLEASE BACKUP YOUR REGISTRY FIRST BEFORE YOU MAKE ANY CHANGES
This issue may be cause of two reasons, one is the NullSessionPipes and the other is IRPStackSize.
1. NullSessionPipes
The Cause of these errors is due to too much data stored in the following registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\NullSessionPipes
The Server service queries the registry value above for its entries. The buffer for the amount of information that
the Server service can accept when it queries is approximately 32 KB. If there are more than 32 KB in that entry,
the Server service will fail to start and return the error “More data is available,” or “Not enough storage is
available.”
The Solution is to remove any unnecessary entries from this value in the registry.
The Default information stored in this key is:
COMNAP
COMNODE
SQL\QUERY
SPOOLSS
LLSRPC
EPMAPPER
LOCATOR
1. IRPStackSize
Go to the below Registry entry to edit the IRPStackSize
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
If you do not have the Registry entry then create one manually, but make sure the name should be correct as it is
case sensitive.
To create the Registry entry follow the below steps:
- Open REGEDIT
- Proceed to the following location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
- Click Edit, and point to New and then click DWORD Value
- Type IRPStackSize , Click Edit and then modify the Value
- The Value should be 0×00000050 in Hexadecimal or 80 in Decimal. This should resolve your issue,
normally values are provided to 1 to 15 in decimal notation. Better if you provide higher value so that the
problem doesn’t come back.
- Restart the Server after the changes are done.
Cannot login to Domain Controllers / Issue to login into
Domain Controllers
Posted: September 17, 2012 in Active Directory, Domain Controller, Server, Server 2003, Server 2008
Tags: Active Directory, Directory Service Restore Mode, Domain Controllers, Logon Issues, low disk
space, Server, Server 2003, Server 2008
1
You may get the error message as below:
(http://ignitedsoul.files.wordpress.com/2012/09/error.jpg)
Symptoms:
- Not able to login to Domain Controllers due to low disk space in the systems drive.
- You get the above error message and the server reboots every time.
- Users not able to login in the particular network.
- Users not able to access the shared resources from the Domain Controller.

Resolution:
- Reboot the server and login using Windows directory restore mode.
- Go To Start > Run and type ‘Cleanmgr’ and clean up the drive space of C
- If you have lost the Restore Mode password then follow the below steps to reset the DSRM Password:
Go to Command Prompt from the nearest Domain Controller and type the below command:
ntdsutil
set dsrm password
reset password on server ServerName
- Once you have cleared the Space in the Systems drive, reboot the Server.
- After Reboot login normally to the Domain Controller and everything should be back to normal.
- Everyone should be able to access the Shared Resources from the Server.
Create a free website or blog at WordPress.com. | The Greyzed Theme.
Follow
Follow “IgNiTeD SoUL”
Powered by WordPress.com