Archive for the ‘Server’ Category

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.

1479

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}

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

1394

Advertisements

 

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.

Issue:

This kind of issue is basically related to Task Scheduler, Normally you observe that the Tasks are not running as scheduled, when you try to check the properties of task, you get this error.

TaskSCerror

When you click “Ok”, you get the Properties of the task, but nothing works even though you make the changes.

Note: Backup all the information related to Logon Credentials used to run the specified tasks.

Resolution:

You need to clear the folder “S-1-5-18”

You can find the folder in the below location:

“C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA”

RSA Folder

 

S1518

Once you have deleted the folder, you can go back to Tasks and open the task properties, this time you won’t get the error.

Make sure to re-enter the logon credentials used to run the tasks.

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.

 

  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.

 

The FSMO role owners are stored in Active Directory in different locations depending on the role. The DN of the server holding the role is actually stored as the FSMO Role Owner attribute of various objects. For the Ignitedsoul.com domain, here are the containers that hold that attribute in the following order: PDC Role Owner, Infrastructure Master, RID Master, Schema Master, and Domain Naming Master:

LDAP://dc=Ignitedsoul,dc=com

LDAP://cn=Infrastructure,dc=Ignitedsoul,dc=com

LDAP://cn=RID Manager$,cn=System,dc=Ignitedsoul,dc=com

LDAP://cn=Schema,cn=Configuration,dc=Ignitedsoul,dc=com

LDAP://cn=Partitions,cn=Configuration,dc=Ignitedsoul,dc=com

The information in the attribute is stored as a DN, representing the NTDS Settings object of the domain controller that is the role owner. So, example contents for this attribute are:

CN=NTDS Settings, CN=MYSERVER1, CN=Servers, CN=My Site, CN=Sites,

CN=Configuration, DC=Ignitedsoul, DC=com

 

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 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. A Kerberos 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 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.

 

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 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.

Note: Make sure to backup the information of the tasks scheduled.

Symptoms:

–          Error while trying to open the Configured Tasks.

–          Error while trying to access the properties of the tasks.

–          Status message of tasks as: “Could not Start”

–          This normally happens in Microsoft Windows 2003 / 2003 R2

Error

Could_not_start

 

Resolution:

–          Stop the “Task Scheduler “Service.

–          Delete all the files in this path: C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\S- 1 – 5 – 18

–          Restart the Service and check if it works.

–          If not then restart the server.

–          The issue will be resolved.