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.

Blank Live Communication Server (LCS) 2005 MMC Snap-In

Description

You have successfully install your Live Communication Server (LCS) 2005 or LCS 2005 with SP1. However when you start the Live Communication Server Administration tool you got blank page only.
There's nothing appear at the left hand side of the mmc window. The account that you are using already have the correct permission.

Resolution

Create a new MMC snap-in to manage the Live Communication Server 2005.

> Click Start, click Run, type mmc, and then click OK.
> In the Console1 MMC snap-in, click Add/Remove Snap-in on the File menu.
> In the Add/remove Snap-in dialog box, click Add, click Live Communications Server 2005 in the Add Standalone Snap-in dialog box, click Add, click Close, and then click OK.
> On the File menu, click Save As.
> In the Save As dialog box, locate the %WINDIR%\System32 folder.
> In the File name box, type wrtcsnap2.msc, and then click Save.
> Click Yes when you are prompted to overwrite the existing wrtcsnap2.msc file.

For details, please see http://support.microsoft.com/kb/926921