Using SMTP for Active Directory Replication

SMTP replication is used only for replication between sites.
You also cannot use SMTP replication to replicate between domain controllers in the same domain—only inter-domain replication is supported over SMTP (that is, SMTP can be used only for inter-site, inter-domain replication).
SMTP replication can be used only for schema, configuration, and global catalog partial replica replication. SMTP replication observes the automatically generated replication schedule.

DNS Tombstones in Windows 2003 and 2008

When DNS records are deleted from AD integrated zones, they are not immediately tombstoned in the way normal AD object deletions are. Instead, they go through a DNS tombstone process. This includes setting dnsTombstoned=True for the object.

When set to True, the DNS console and tools will ignore the presence of the record. You will still see the objects through LDP/ADSIEDIT/LDIFDE alongside the other DNS records. Each DNS server is hard coded to perform a cleanup process every morning at 2 a.m. to delete any dnsTombstoned=True records that are seven days old or older.

It is at this time that the objects are tombstoned like normal AD deletions (isDeleted=True) and moved to the Deleted Objects container. This is important to know in case someone deletes records, such as enabling scavenging for the first time, and wants to know why they still see the objects in Active Directory. The reason for the seven days of dnsTombstoned=True is to prevent frequent database churn. This is because workstation records may get de-registered or scavenged and then re-created within a short period of time.

Prevent Registration of Certain Domain Controller DNS Records

There are times when you want to restrict a Domain Controller from registering certain resource records in the DNS. One of the scenario is when you have hub - spoke topology, it is preferable that if all domain controllers/global catalogs in a satellite site become unavailable, a client that is searching for a domain controller/global catalog in that site will fail over to a domain controller/global catalog in a central hub and not in another satellite site.
To achieve this behavior, the domain controllers/global catalogs in the satellite offices should not register generic (non-site-specific) domain controller locator DNS records

To restrict the DNS resource records that are updated by NetlLogon

1. Open Registry Editor.
2. In Registry Editor, navigate to the following registry key:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
3. Add the following multistring value (REG_MULTI_SZ) value:
   DnsAvoidRegisterRecords
4. In this value, specify the list of data corresponding to the DNS resource records that should not be registered for this domain controller by the Net Logon service. The following table contains the list of data.

<>

<>

Domain Controller -Specific Records

Mnemonic	Type	DNS Record
LdapIpAddress	A
Ldap	SRV	_ldap._tcp.
DcByGuid	SRV	_ldap._tcp..domains._msdcs.
Kdc	SRV	_kerberos._tcp.dc._msdcs.
Dc	SRV	_ldap._tcp.dc._msdcs.
Rfc1510Kdc	SRV	_kerberos._tcp.
Rfc1510UdpKdc	SRV	_kerberos._udp.
Rfc1510Kpwd	SRV	_kpasswd._tcp.
Rfc1510UdpKpwd	SRV	_kpasswd._udp.

Global Catalog-Specific Records

Mnemonic	Type	DNS Record
Gc	SRV	_ldap._tcp.gc._msdcs.
GcIpAddress	A	gc._msdcs.
GenericGc	SRV	_gc._tcp.

Infrastructure Master & Global Catalog placement

Infrastructure Master (IM) is FSMO role that responsible to updates cross-domain references and phantoms from the global catalog. It is comparing objects of the local domain against objects in other domains of the same forest.

Single domain forest:

In a forest that contains a single Active Directory domain, there are no phantoms. Therefore, the infrastructure master has no work to do. The infrastructure master may be placed on any domain controller in the domain, regardless of whether that domain controller hosts the global catalog or not.

Multidomain forest:

If every domain controller in a domain that is part of a multidomain forest also hosts the global catalog, IM won't ever see any differences, since the global catalog holds a partitial copy of every object in the forest itself. So there are no phantoms or work for the infrastructure master to do.

In this case, the infrastructure master may be put on any domain controller in that domain. In practical terms, most administrators host the global catalog on every domain controller in the forest.

When do you require a Global Catalog?

There are certain time when you would need Global Catalog role available instead of just Domain Controller role.

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 (multidomain), 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).

Active Directory Replication Terminology - Part II

Automatic Site Coverage:
To ensure that clients can locate a domain controller in the nearest available site, domain controller advertises itself (registers a site-related SRV record in DNS) in any site that does not have a domain controller for that domain and for which its site has the lowest-cost connections. This functionality is commonly known as "automatic site coverage."

To disable automatic site coverage on a domain controller:

1. Click Start, click Run, type regedit, and then click OK.
2. Navigate to the following registry subkey:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
3. Click Edit, point to New, and then click DWORD Value.
4. Type AutoSiteCoverage as the name of the new entry, and then press ENTER.
5. Double-click the new AutoSiteCoverage registry entry.
6. Under Value data, type 0 to disable automatic site coverage or type 1 to enable it.

Automatic Site Link Bridge
By default, all site links are bridged, or transitive. This allows any two sites that are not connected by an explicit site link to communicate directly, through a chain of intermediary site links and sites. One advantage to bridging all site links is that your network is easier to maintain because you do not need to create a site link to describe every possible path between pairs of sites.

Bridge All Site Link
The setting inside AD Sites and Services to enable or disable site link bridges. If you disable site link bridging and you are using File Replication Service (FRS) to replicate DFS replicas, which include the SYSVOL share, the DFS site-costing ability is also disabled.

To turn off automatic site link bridging for KCC operation without hampering the ability of DFS to use Intersite Messaging to calculate the cost matrix. This site option is set by running the command repadmin /siteoptions +W2K3_BRIDGES_REQUIRED. This option is applied to the NTDS Site Settings object (CN=NTDS Site Settings,CN=SiteName,CN=Sites,CN=Configuration,DC=ForestRootDomain). When this method is used to disable automatic site link bridging (as opposed to turning off Bridge all site links), default Intersite Messaging options enable the site-costing calculation to occur for DFS

Site Costed Referall,
Defining the SiteCostedReferrals Registry value on the domain controllers will alter the DFS referrals so that all local domain controllers are listed first, randomly ordered, then the “next best” site’s domain controllers, and then all others. The “next best” logic is based on site link costs where the lower cost is preferred.

Active Directory Replication Terminology - Part I

Following is some of the day to day Active Directory terminology.

> BridgeHeads Servers,
A bridgehead is a point at which a connection leaves or enters a site.

> ISTG (Intersite Topology Generator),
The single KCC in a site that manages intersite connection objects for the site.

> KCC (Knowledege Consistency Checker),
The Knowledge Consistency Checker (KCC) is an Active Directory component that is responsible for the generation of the replication topology between domain controllers.

So what is the relation between those three?

Knowledge Consistency Checker (KCC), runs as an application on every domain controller and communicates through the distributed Active Directory database. KCC reads configuration data and reads and writes connection objects.
One domain controller in each site is selected as the Intersite Topology Generator (ISTG). To enable replication across site links, the ISTG automatically designates one or more servers to perform site-to-site replication. These servers are called bridgehead servers.

The ISTG creates a view of the replication topology for all sites, including existing connection objects between all domain controllers that are acting as bridgehead servers. The ISTG then creates inbound connection objects for those servers in its site that it determines will act as bridgehead servers and for which connection objects do not already exist. Thus, the scope of operation for the KCC is the local server only, and the scope of operation for the ISTG is a single site.

For more information please see:
http://technet.microsoft.com/en-us/library/cc755994(WS.10).aspx

How to lock Internet Explorer setting through GPO

To lock changes in Proxy settings using GPO check the following GPO option:
User configuration->Administrative Templates->Windows Components->Internet Explorer->"Disable changing proxy settings"

Set the option ->"Disable changing proxy settings" to enable.

Useful command in managing Active Directory

Here's some of the list that common to use on day to day administration and troubleshooting of Active Directory:

> To summarizes the replication state and health of a forest:
Repadmin /Replsum /BySrc /ByDst

> To show the state of the last inbound replication for specified domain controller:
Repadmin /Showreps
Repadmin /Showrepl

> To show the state of the last inbound and outbound replication (change notification) for specified domain controller:
Repadmin /Showrepl /repsto

> To display the replication queue list:
Repadmin /queue
> To display all the Domain Controller in the forest:
Repadmin /Viewlist *
> To display the Intersite Topology Generator (ISTG) server for specified site:
Repadmin /ISTG
> To display the Bridgeheads servers for specified site:
Repadmin / Bridgeheads

> To synchronize a sepecified domain controller with all of the replication partners
Repadmin /syncall (DC_name) /A /e

> To list the name of Domain Contollers in a domain:
Nltest /dclist:(domainname)

> To verify if we can locate a domain controller:
Nltest /dsgetdc:(domainname)

> To display the servers that hold FSMO role:
Netdom query FSMO

> To chek the health of DNS settings:
DCdiag /test:DNS

> To query the tombstonelifetime setting in a forest:
dsquery * "cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,dc=contoso,dc=com" -scope base -attr tombstonelifetime

Site Costed Referrals

Windows Server 2003 and above supports the ability to provide finer control over how DFS referrals are returned for the SYSVOL and NETLOGON shares.

By default, in Windows Server 2003 the DFS referral list will contain all local domain controllers of the client’s domain in the local site, randomly ordered, and then all other domain controllers in the domain randomly ordered.
Defining the SiteCostedReferrals Registry value on the domain controllers will alter the DFS referrals so that all local domain controllers are listed first, randomly ordered, then the “next best” site’s domain controllers, and then all others. The “next best” logic is based on site link costs where the lower cost is preferred.

Windows Server 2008 uses the SiteCostedReferrals behavior by default and does not require the Registry value to be set. Windows 2000 Server does not support this feature.

The SiteCostedReferrals Registry value should be defined across all domain controllers in a domain to ensure consistent behavior. The DFS service must be restarted or the domain controllers rebooted for the change to take effect.

This behavior is controlled via the following Registry value:

HKLM\System\CurrentControlSet\Services\Dfs\Parameters

Value: SiteCostedReferrals

Type: REG_DWORD

Data:

• Windows 2003

= Disabled

0 = Disabled

1 = Enabled

• Windows 2008

= Enabled
0 = Disabled
1 = Enabled

Automatic Site Coverage

For various reasons, it is possible that no domain controller exists for a particular domain at the local site.
To ensure that clients can locate a domain controller in the nearest available site, domain controllers attempt to register their DNS service location (SRV) resource records. These resource records pertain to sites that contain no domain controller for the domain of which they are a member. This functionality is commonly known as "automatic site coverage."

Automatic site coverage factors in the cost associated with the site links of a site without a domain controller. This cost helps determine which domain controller registers its SRV resource records for that site. The SRV resource records are registered by domain controllers from the site that has the lowest cost between its site link and the site that has no domain controller. This makes it possible for clients in the site without a domain controller to use the least expensive network connection to contact a domain controller in another site.

Source:
http://technet.microsoft.com/en-us/library/cc732322(WS.10).aspx
http://technet.microsoft.com/en-us/library/cc978016.aspx

How to Clean Up Lingering Object in Active Directory

Quote from: http://blogs.technet.com//b/glennl/archive/2007/07/26/clean-that-active-directory-forest-of-lingering-objects.aspx

Consider the following illustration that explains how the above methodology is the most efficient and thorough approach possible with repadmin /removelingeringobjects.
DC1,2,3 all host a writable copy of domain A. DC5,6,7 host a read only copy of domain A.

DC1 will be chosen as an initial target for this illustration. DC1 may be clean or dirty with respect to lingering objects.
1) Clean a target DC.

• Repadmin /removelingeringobjects
• Repadmin /removelingeringobjects

DC1 is now clean as compared to DC2,3.
DC1 now becomes the source to be used to clean DC2,3.

2) Clean remaining DCs using the target in 1) above as the source DC.

• Repadmin /removelingeringobjects
• Repadmin /removelingeringobjects   

DC2,3 are now clean with respect to DC1. This approach makes DC1,2,3 consistent with each other.
At this point any writable DC for domain A can be used as a source to clean the DCs hosting a read only copy of domain A. DC1 will be chosen as the source DC for cleaning the DCs hosting read only copies of domain A.

3) Clean all DCs hosting a read only copy of domain A.

• Repadmin /removelingeringobjects
• Repadmin /removelingeringobjects
• Repadmin /removelingeringobjects

At this point all DCs hosting a read only copy of domain A are consistent with each other and are consistent* with the writable DCs for domain A.

Cannot Publish Post to Blogger using Internet Explorer 9

Description:

You can edit/create your post in blogger.com, however you cannot click the publish post button. You are using Internet Explorer 9.

Resolution:

There are two options:

• First, you can enable Compatibility View as a workaround. At Internet Explorer 9, please go to Tools > Compatibility View Settings. Add blogger.com to the list. Click Close and restart your IE 9. Open your post again and you should be able to publish it now. However you may still encounter issue with font sizes, etc.
• Second is to change the setting at the blogger site. Please go to Settings > Select Post Editor > choose Updated Editor > click save settings. Open your post again and you should be able to create/edit/post to your blog again. You will also gain new editing feature such us improved image handling and new preview window.