Welcome to Dirteam.com/ActiveDir.org Blogs Sign in | Join | Help

Active Directory Replication Types

I find myself quite often trying to keep straight all the different replication activities that can occur within an Active Directory (AD) domain.

There is:

· Intrasite Replication

· Urgent Replication

· Intersite Replication

· Intersite Change Notification Replication

· Reciprocal Replication

· Immediate Replication

· Manual Replication

Replication between Domain Controllers (DC’s) occurs without administrative intervention. Replication provides the multimaster database that AD uses to allow all DC’s to have equivalent objects within a given time frame so an object modified at one location can be stored and forwarded to all other DC’s in its domain. How quickly objects are replicated to the rest of the domain, by an individual dc, is computed by the replication rules that exist and/or applied against them.

Intrasite Replication:

Replication between DC’s within a site don’t need to worry about connectivity speed, so the connections between dc’s are optimized for speed. Intrasite Replication within a site notifies a partner DC 15 seconds after a change has occurred and all subsequent DC’s it communicates are delayed by 3 seconds. For Windows 2000’s partners the initial time delay was 300 seconds (5 minutes) and subsequent partners was 30 seconds. So after the delay a partner DC is notified that the notifier has an update. It is up to this partner DC to request the modification. The notifying DC only notifies, it doesn’t push the change. It is up to the notified DC to pull the change. Also, all DC’s within a site are never more than 3 hops away from all other DC’s due to the KCC generating a bidirectional ring topology. This also ensures a quicker convergence within a site.

Urgent Replication:

Urgent notification is just that, it is not bound by the 15 second (Or 5 minutes) time delay of Intrasite Replication. Partner DC’s are immediately notified of changes, this only holds true for intrasite DC’s except if change site notification is enabled.

Intersite Replication:

DC’s between sites don’t follow the same set of rules that intrasite replication does. Changes between sites are setup on a schedule. The schedule is broken up in 15 minute increments, this schedule can also be set to only allow changes to occur at certain times of the day, thereby saving bandwidth at key points of time. The shortest time span for intersite to occur is 15 minutes and the longest is once a week. Note once replication begins between DC’s, the process will not stop until complete. So you won’t have to worry about incomplete replication activity due to time constraints.

Intersite Change Notification Replication:

With bandwidth pipes becoming cheaper and available, many organizations are becoming more well connected, 15 minutes can be a long time. Imagine having to wait for a password unlock not being reset in the proper site and having to wait 15 minutes for replication to occur. Obviously you can force replication but the point is 15 minutes between sites sometimes just isn’t realistic. To bypass the scheduled notification delays you can enable, Intersite Change Notification. Once enabled partners in different sites will be treated equivalently as intrasite replication, with the exception this only holds for NTDS, NTFRS still works on the schedule.

Reciprocal Replication:

Sometimes connectivity isn’t always available, for example a Navy/Cruise ship or a dial up connection.  With this type of topology both sides need to take advantage of the connect time, so both sides can replicate at the same time.  So when the remote site connects up to the Data Center the replication pair should both request and receive any delta’s that are available.  Hence, replication is initiated on the basis of change rather than on a schedule.

Immediate Replication:

If an administrator resets a password for a user who has forgotten their password, the change is immediately replicated back to the PDCe. This isn’t a situation where the PDCe is notified about the change but instead the change is immediately pushed to it. The reason this is so important is that if a user attempts to logon and the password they attempt to use fails, the DC will send the hash from the password (Password itself is never sent over the wire) back to the PDCe to check to see if the password is correct, since there is latency in replication.

Manual Replication:

Manual replication is triggered by the admin. This can occur from either the repadmin command or from AD Sites and Services. This will cross intersite replication schedules if requested. So if you have a Lag Site and the network is enabled, even though your site isn’t scheduled to replicate for possibly days a forced replication will cause the replication to occur. So you need to be aware of this, in a lag site I had set up I had a schedule task that actually enabled and disabled replication to prevent this.

 

Over the next few weeks I hope to expand and add some diagrams to help make this easier to follow, as well as some helpful links.

This can be confusing and I hope I have helped in you grasping this concept.

 

Preventing Lingering Object Replication in Active Directory

One thing you want to prevent in Active Directory is an Islanded DC, one in which you have lost connectivity to.  If a DC is disconnected beyond its "Tombstone Lifetime" it will begin to accumulate Lingering objects.  This isn't something you ever want to happen and if you are put in this situation I would strongly recommend you just flatten the DC, clean up the metadata in your domain and repromote the server.

Read my blogpost on AD clean up for assistance if you do need to remove a failed dc:

If you have an Islanded DC and for some unknown reason it is reconnected, you surely don't want to start replicating tombstoned objects to healthy DC's.  There is a simple fix for this, just enable "Strict Replication Consistency".  This registry setting will prevent replication from a corrupt partner.  You can simply open up the registry and make the modification on each dc in your domain/forest:

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
    Strict Replication Consistency
       0 = Disable (Loose)
       1 = Enabled (Strict)

More information: http://technet.microsoft.com/en-us/library/cc784245(WS.10).aspx

Better yet, using RepAdmin just update all DC's from a command prompt (You need to elevate if on Vista/2008 or greater) in your forest.  I pipe the output and save the text file for documentation.

repadmin /regkey * +strict > c:\temp\dcListStrict.log

This will ensure that all your DC's are protected from any partners that are unhealthy and hopefully save you some real headscratching problems that can occur with Lingering objects.  In the example below you can see that only one of the three DC's needed to be updated.  You will also notice that rerunning this does not have an adverse effect.

The output of the above command would look like:

Repadmin: running command /regkey against read-only DC DC01.acme.com
HKLM\System\CurrentControlSet\Services\NTDS\Parameters: "Strict Replication Consistency" REG_DWORD 0x00000001 (1)
New HKLM\System\CurrentControlSet\Services\NTDS\Parameters: "Strict Replication Consistency" REG_DWORD 0x00000001 (1)

Repadmin: running command /regkey against full DC DC02.acme.com
HKLM\System\CurrentControlSet\Services\NTDS\Parameters: "Strict Replication Consistency" REG_DWORD 0x00000001 (1)
New HKLM\System\CurrentControlSet\Services\NTDS\Parameters: "Strict Replication Consistency" REG_DWORD 0x00000001 (1)

Repadmin: running command /regkey against full DC DC03.acme.com
HKLM\System\CurrentControlSet\Services\NTDS\Parameters: "Strict Replication Consistency" value does not exist
New HKLM\System\CurrentControlSet\Services\NTDS\Parameters: "Strict Replication Consistency" REG_DWORD 0x00000001 (1)

Windows 7/Vista clients require elevated privileges to install or update a print driver

Our Help Desk support staff was really perplexed.  They were getting hammered by phone calls whenever a print driver was updated and the Windows 7 clients attempted to upgrade the print driver.  Windows XP clients had no problems upgrading, so obviously there was a UAC issue.

After doing some research a new setting was discovered that by default was set to require elevated permissions to install a new or upgraded print driver.  To allow users to update or install a new driver there are two new gpo settings that need to be configured for your users.

Both reside at the following location:

Computer Configuration / Policies / Administratice Templates / Printers

When installing drivers for a new Connection: "Do not show warning or elevation prompt"

When updating drivers for an existing connection: "Do not show warning or elevation prompt"

By setting both vales as defined above, users will now be able to connect and update their workstations without a Help Desk support visit.

Restoring a DC from a Snapshot

Restoring a Virtual DC from a Snapshot

Sorry about the formatting, I will have to retype at some point... 

This covers Windows 2008 R2 and all previous Windows o/s's

Let me start off by saying, if you are considering using this procedure, it should be your LAST option.  This is by no means is a supported Microsoft procedure and use of it could damage Active Directory.  In moving forward with this, you should also be reassessing your environment and take the proper steps to ensure this recovery model doesn’t have to be used again.

A little background, before the required steps:

Each Domain Controller’s DIT file (NTDS.DIT) is assigned a unique GUID, the name assigned to the DIT is its Invocation Id.  When an AD aware restoration occurs the Invocation Id is modified and any changes that have occurred on this DC between the restoration date and the current date need to be replicated back to this DC from its replication partners.  If a non-AD aware restore occurs the Invocation Id remains the same and the replication partners within the domain won’t replicate back changes.  These changes could be adds, changes or deletes with can creates orphans or within the AD world it is known as Update Sequence Number (USN) rollback.

 

To better understand this, consider the following scenario:

You have three DC’s, in one site, in your domain.  Each DC will keep track of the highest USN received for each partition (At a minimum three -Domain Naming, Configuration and Schema) of its replication partner(s); this is better known as the High Watermark Vector Table (HWVT). 

 

 

Please note the Invocation Id’s are actually 32 (GUID’s) characters in length.  To keep it simple I reduced the length for simplicity.  Also, the last used USN on each DC is noted as the Highest Committed USN.

 

Being it is a Friday, we are going to ensure we take a snapshot of DC-Accounting.  We need to ensure we have a full backup of a highly complex application that maintains all the corporate data.  Losing this data could cripple the business.

 

In figure 1, you will see that the three DC’s have fully replicated with one another, if you inspect the Highest Committed USN and compare it to the HWVT of the other DC’s you will see they are all equivalent.

 

 

Figure 1

DC-Accounting

Invocation Id = 580907

Highest Committed USN = 24873

 

Replication Partner

Invocation Id

HWVT

DC-Engineering

274369

16874

DC-HumanResources

999245

12568

 

 

DC-Engineering

Invocation Id = 274369

Highest Committed USN = 16874

 

Replication Partner

Invocation Id

HWVT

DC-Accounting

580907

24873

DC-HumanResources

999245

12568

 

 

DC-HumanResources

Invocation Id = 999245

Highest Committed USN = 12568

 

Replication Partner

Invocation Id

HWVT

DC-Accounting

580907

24873

DC-Engineering

274369

16874

 

 

Next let’s look at what happens after an event creates a Change Notification to its replication partners.

 

It is Monday morning and 5 employees were recently hired and the object creation is reflected against the DC, DC-Accounting.  You will note that the Highest Committed USN has incremented from 24873 à 24878.  If you notice (Figure 2) neither DC, DC-Engineering or DC-HumanResources knows about the newest objects.  During the replication cycle each DC will let its replication partner know about the highest USN it has within its DIT, which is determined by transmitting the HWVT.  If the Highest Committed USN (On the requested DC)is larger than the USN sent from its requesting DC then the requested DC will replicate those USN’s that are greater than the requesting DC is aware of.

 

 

Figure 2

DC-Accounting

Invocation Id = 580907

Highest Committed USN = 24878

 

Replication Partner

Invocation Id

HWVT

DC-Engineering

274369

16874

DC-HumanResources

999245

12568

 

 

New Objects

USN

User – Jimmy Falon

24874

User – Karen Wallace

24875

User – Michele Jacobs

24876

User – David O’Shannon

24877

User – Steve Berger

24878

 

 

DC-Engineering

Invocation Id = 274369

Highest Committed USN = 16874

 

Replication Partner

Invocation Id

HWVT

DC-Accounting

580907

24873

DC-HumanResources

999245

12568

 

 

DC-HumanResources

Invocation Id = 999245

Highest Committed USN = 12568

 

Replication Partner

Invocation Id

HWVT

DC-Accounting

580907

24873

DC-Engineering

274369

16874

 

 

 

As you can see, in Figure 3 the replication has completed. 

 

As the morning rolls on, disaster strikes, a water pipe in the ceiling bursts and destroys the HOST virtual machine hosting the guests of this server, one of which was DC-Accounting.  Recovering this DC and its application takes the highest priority, the companies financial systems have come to a halt and can’t move forward until the guest server, DC=Accounting is recovered.

 

 

Figure 3

DC-Accounting

Invocation Id = 580907

Highest Committed USN = 24878

 

Replication Partner

Invocation Id

HWVT

DC-Engineering

274369

16874

DC-HumanResources

999245

12568

 

 

DC-Engineering

Invocation Id = 274369

Highest Committed USN = 16874

 

Replication Partner

Invocation Id

HWVT

DC-Accounting

580907

24878

DC-HumanResources

999245

12568

 

 

DC-HumanResources

Invocation Id = 999245

Highest Committed USN = 12568

 

Replication Partner

Invocation Id

HWVT

DC-Accounting

580907

24878

DC-Engineering

274369

16874

 

 

Note: If you recall earlier, the snapshot used for the recovery will have to come from Friday night prior to when the 5 new employees were entered into Active Directory and specifically, they were created on DC-Accounting.

 

You are quickly able to restore the guest DC-Accounting  on a different Host virtual server and getting the DC back online, bringing great praise from the boss and even a nice note from the president.  Little does anyone know that problems lurk that have the potential to create a nightmare.

 

If you examine Figure 4, you will note that both DC-Engineering and DC-HumanResources have HWVT values for DC-Accounting that are greater than what DC-Accounting itself knows about.  In other words both DC-Engineering and DC-HumanResources have objects that were created on DC-Accounting that DC-Accounting doesn’t know about.  Since the restore was unaware of the restoration of the DIT file no steps were taken to notify the partners to  DC-Accounting that it needs to be updated from its own missing records. 

 

To make matters worse, the next five objects created on DC-Accounting will go unreplicated since the USN values for these objects is less than what the other DC’s currently have as DC-Accounting’s HWVT.  This will create more problems since the next 5 USN’s will represent objects other than the 5 previous objects created prior to the water pipe break disaster.

 

 

Figure 4

DC-Accounting

Invocation Id = 580907

Highest Committed USN = 24873

 

Replication Partner

Invocation Id

HWVT

DC-Engineering

274369

16874

DC-HumanResources

999245

12568

 

 

DC-Engineering

Invocation Id = 274369

Highest Committed USN = 16874

 

Replication Partner

Invocation Id

HWVT

DC-Accounting

580907

24878

DC-HumanResources

999245

12568

 

 

DC-HumanResources

Invocation Id = 999245

Highest Committed USN = 12568

 

Replication Partner

Invocation Id

HWVT

DC-Accounting

580907

24878

DC-Engineering

274369

16874

 

 

 

The way the DC’s will know to replicate this data back is if the Invocation Id were to change, since the DC’s manage the object replication comparison via the Invocation and its associated HWVT.  If you don’t follow the steps noted below which will generate a new Invocation Id, you will create lingering objects and a whole lot of trouble for yourself.  To take this one step further, you will also need to do an non-authoritative restore on the sysvol, since sysvol also uses USN’s and can also end up with lingering objects!  So sysvol also needs to be properly updated.

 

 

 

Use at your own risk!

 

 

1)      Do your clone recovery

2)      Configure your nic to be unable to talk to the network

3)      Note the value of your Invocation Id

a.       From a command prompt run the following command

                                                               i.      Repadmin /showrepl

4)      Reboot your DC, make sure you boot into Directory Services Restore Mode (DSRM)

5)      Stop the NTFRS service

6)      Start up regEdit

a.       Drill down to HKLM\System\CurrentControlSet\Services\NTDS\Parameters

                                                               i.      Modify the RegKey “Database restored from backup” = 1

1.       If this RegKey doesn’t exist create one as a DWORD and set to a 1

                                                             ii.      If the RegKey DSA Previous Restore Count exists in the same path, note its value.  Upon reboot it should increment by one.  If it didn’t exist it should be created and it should be set to a value of 1.

b.      Drill down to HKLM\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process

                                                               i.      Modify the RegKey BurFlags to D2

7)      Reboot the server

8)      Log into the DC

a.       Verify that the Invocation Id has changed

b.      In the Event Log look for the Event Id 1109 (AD restored from backup)

9)      If both events have occurred in bullet 8 then, enable the nic

 

 

Thanks to Ulf and Jorge for assistance

Windows DCDiag Generating - Error 0x6ba "The RPC server is unavailable."

Once you arrive to Windows 2008 with Advanced Firewall and you run DCDiag you could end up with "error 0x6ba The RPC server is unavailable."  This is the result of the remote DC not allowing RPC connections from the firewall being enabled.

To remove this error and allow DCDiag to be run remotely, open up the following rule on the remote DC's Firewall settings:

Remote Service Management (RPC)

To not open this up to widely, I configure the "Scope" tab to only those ip addresses that will be running DCDiag remotely

Upgrade Certificate Server from 32 to 64 bit

In some older documents Microsoft stated that there was no support for upgrades from 32 to 64 bit:  

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

This is no longer the situation and there is support to migrate 32 to 64 bit, the Active Directory Certificate Services Migration Guide covers the steps required: 

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

This process went smooth and the previous tech doc was all that was needed.



 

Windows 7/2008 Kerberos Default Encryption and Windows 2003/2000

With the latest o/s release Microsoft modified the default encryption method from RC4 to AES when first attempt to commenicate with a Ticket Granting Ticket Service Request.  As long as the client whether it be Windows 7 or Windows 2008, communicates with a Windows 2008 R2 Domain Controller (DC) everything is all good.  However if the client talks to a Windows 2003/2000 DC then the default of the client is AES and these DC's don't speak in AES.  The clients are intelligent enough to then attempt other encryption methods but the DC will generate an error 27 in the System Event log, giving you the impression that you have problems, as seen below.

Event Type: Error
Event Source: KDC
Event Category: None
Event ID: 27
Date:  9/28/2010
Time:  1:21:04 PM
User:  N/A
Computer: DC
 
Description:

While processing a TGS request for the target server krbtgt/DOMAIN.COM, the account Windows7Client@MNPOWER.COM did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 8). The requested etypes were 18.  The accounts available etypes were 23  -133  -128  3  1.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

 

The key to this mystery is the line "The requested etype were 18."  This etype is defined in the RFC3962, http://www.ietf.org/rfc/rfc3962.txt.

Unfortuantely there is no way to stop the Event Log errors, so you will have to modify the default value the clients start with when attempting a Kerberos session.

 

HKLM\System\CurrentControlSet\Control\LSA\Kerberos\Parameters

Value Name:  DefaultEncryptionTypeValue

Type:  Reg_DWORD

Value Data:  0x17(23)

This will now set RC4 as the default value and still allows AES if needed.

 

Since I have a mid-sized environment that was continuously adding new Win7 clients I wasn't about to ask our pc support staff to manually change the registry since that would be a difficult task and once we are up to Windows 2008 R2 FFL, I would like my default to be AES once again.  So I decided to build a WMI Group Policy and apply it to our Workstations OU. Make sure that under the "Common" tab of the new registry key to be sure to select "Remove this item when it is no longer needed", this will then remove the entry if the client doesn't have the policy applied against it.

So I built a preference GPO with the registry settings above and applied it to all my Win7 clients via the WMI Filter below:

select * from Win32_OperatingSystem where Version like "6.1%" and ProductType = "1"

 

How to apply a WMI Filter
http://technet.microsoft.com/en-us/library/cc779036(WS.10).aspx

Note:
This will capture both 2008 R2 and Windows 7 Clients so if you only want to apply this against Windows 7, make sure that the GPO is linked to an OU that doesn't contain Windows 2008 R2 servers.

 

Thanks to Mark Parris for his invaluable assistance in this blog.

Posted by Paul Bergson | 1 Comments
Filed under: , , , ,

Invalid service type: RpcSs when running DCDIAG

After recently bringing up a RODC in my default site, all my 2003 RWDC's in all my sites flipped to a single process which is not a good thing for DC's.  I can't be absolutely certain this was the cause but the errors occured on the same day of the RODC promotion.

The erorr in DCDiag should look like something similar to below:

 WIN32_OWN_PROCESS, expected value WIN32_SHARE_PROCESS

You can easily fix this either by running an SC command or from RegEdit.  I would recommend SC just to ensure that it is properly configured.

From a command prompt key in the following.  Make sure that you include the "Space" after the "=" otherwise you will get an error.

sc config rpcss type= share  (Remotely ->   sc \\RemoteServer config rpcss type= share)

If you want to do this manually then open up the Registry Editor and drill down

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RpcSs\Type

The value should be Equal to 10 (Hex) if the single process is configured and 20 (Hex) if Multi-Process is configured

 

RODC - Password Replication Policy and Password Cache Management

With the advent of Read Only Domain Controllers (RODC) remote offices no longer have to present a risk for your Active Directory (AD) enterprise secrets.  RODC's by default do not cache ANY user or computer passwords.  This can present a problem if there is a loss of connectivity between the remote site's RODC and a Read Write Domain Controller (RWDC), since without caching since neither a user or computer will be able to authenticate.  You can however specifiy that their passwords be cached either by including a group or specific user in the Password Replication Policy on the RODC at the remote site.  Access to this policy is gained by opening up the RODC computer object and selecting the "Password Replication Policy" tab. 

It is realtively simple to add and remove user and computer objects, simply click on the "Add" or "Remove" button and modify the membership.  Problem is this can be very dynamic, users and computers are consisting coming and going and management of this can become extremely tedious.  Even if you are using group membership, this still has to be maintained.

I have found the use of Powershell was the piece I needed to resolve the problem.  It was important though that I am able to determine where a user or computer exists.  There is no software out there that can determine where an object exists without some clear definition.  Fortunately for me I have a nightly syncronization program between HR and AD that keeps all my users objects address accurate.  Now I just need a way to determine my machine object location. 

After doing some thinking I quickly realized that I already know which machines reside at any one site by the subnet definitions within AD Sites and Services. 

Now that I had things clear in my process, I had to find a way to gather all the information.  I decided that Powershell would be the best path to go, since I had two defined process. 

    • Determine the ip subnets within the site I wanted to build my group for
    • Query for all DNS records within the doman the RODC belongs to
    • Query AD to determine which of the DNS hosts are members of the AD domain
    • Update the computer objects location with a value that defines this sites lcoation
    • Since the users and computers move around so much clear out the current group membership
    • Read all computer and user objects and those that have the specific location defined add to the Site Group

 I have posted both scripts below, you will note that the users "City" attribute is not touched since this should be a managed attribute by your HR department.  Both scripts can be run on within a single task, just make sure that the Dynamic Security group sub-task is run second.

Note: Script 2 will generate churn for DC replication.  This rebuilds the group everytime it is run, so it will cause the group and its membership to be rereplicated wether or not there were any changes.  Not a big deal for small to midsized shops without expensive links or significant numbers of DC's, but if you have 100,000's of objects or 100's of dc's this is not efficient.  I hope to rewrite this to manage delta's only.

1)

import-module activeDirectory
#
# Script       - UpdateSiteLocation.ps1
# Author       - Paul Bergson
# Date Written - 09/22/2010
# Description  - Script will populate the location field of all computer accounts that reside in a specific site
#                  When used in association with the Powershell script to dynamically populate the members
#                  of a security group of all computer and user accounts with the same location.  This group can
#                  be part of the Password Replication Policy (PRP) for an RODC in the defined site.

$ErrorActionPreference = "SilentlyContinue"

# Get the subnets associated with Boswell and place them in the array $ipSubNetAry
$ipSubNetAry = @()                          # Create an empty array
$UpdateSite = "Site-Timbuktu"                # Define the site that you want to build the array for
$locationName = "Timbuktu"                  # Define the value you want populated in the object's "Location" attribute

$forest = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()
$sites = $forest.Sites
Foreach ($site in $sites)
   {
    $MPSubNets = $site.Subnets
    ForEach($MPSubNet in $MPSubNets)
       {
        If($MPSubNet.site.name -eq $UpdateSite)
           {
            $ipSubNetAry = $ipSubNetAry + $MPSubNet.Name.Substring(0,($MPSubNet.Name.Length-5))
           }
       }
   }
  
# Go get the host records from the sites in the array of the subnets
$dnsRecords = gwmi -computername computer.domain.com -namespace root\microsoftDNS -Query ('select OwnerName, IPAddress from MicrosoftDNS_AType where DomainName = "domain.com"')

# Now that all host records have been captured look for matching subnet's and see if they reside in Active Directory
ForEach ($hostRecord in $dnsRecords)
    {$ServerIpAddress = $HostRecord.IpAddress

         ForEach($ipSubNet in $ipSubNetAry)
             {
              $FoundMatch = $ServerIpAddress.StartsWith($IpSubNet)
            
              if ($FoundMatch)
                {
                    $FQDN = $hostRecord.OwnerName
                    $Sam = $FQDN.Split(".")
                    # Get the AD computer object to see if it needs to be updated
                    # Sam[0] holds the host name from the fqdn when the array is formed
                    $ComputerObj = $Null                         # Clear prior to call otherwise old value stays in object variable
                    $ComputerObj = get-adcomputer -identity $Sam[0] -properties Location
                    if ($error[0])                               # Don't process if host not available          
                       {
                        ForEach($NewComputer in $ComputerObj)
                           {
                           if ($NewComputer.Location -ne $locationName)
                              {write-output $NewComputer.samAccountName     # Not really needed other than if run locally
                               write-output $FoundIpAddress                 # it will provide feedback on the machines updated
                               # Next line does the actual update.  It should be commented out during any testing
                               Set-ADComputer $NewComputer.samAccountName -Location $locationName
                               }
                            }
                       }
                  }
              }
       }

2)

# Program buildDynamicSecurityGroup
# Author  Paul Bergson
# Date Written   September 20, 2010
# Description    This will recreate the membership list of the AD security group "DynamicSecurityGroup".  This group is used to manage
#                whose passwords are cached on the RODC in Timbuktu
#                By using the attribute City on USers and Location on Computers this is a Dynamic Security Group
#                This script is run nightly


# Get the ad cmdlets imported
import-module ActiveDirectory
$siteName = "Timbuktu"

# Clear all current members
  get-adgroupmember DynamicSecurityGroup | %{remove-adgroupmember DynamicSecurityGroup $_.SamAccountName -Confirm:$false}

# Add all users and computers to the $SiteName global security group
 get-aduser -filter{city -like $siteName} | %{Add-ADGroupMember DynamicSecurityGroup $_.SamAccountName}
 get-adcomputer -filter{location -like $siteName} | %{Add-ADGroupMember DynamicSecurityGroup $_.SamAccountName}

KMS Server won't activate additional servers

I have had my KMS server up and running for several years without any problems.  Recently I was working on a new 2008 Standard Server and it wouldn't activate.

I attempted to first use the standard GUI on the Windows Activation screen.  I was even surprised it popped up since KMS usually just works.  I selelcted "Activate Windows online now", a few moments later it came back with the response "The Product key you typed is already in use".

What does that mean? So I thought: forget it, I'm jumping to an elevated command line.

I ran slmgr -ato and I got the message it was activating and waiting for a click on the Ok button.  This was followed by the error message (What can't they open up a window within the program???).

Run 'slui.exe 0x2a 0xc004C008' to display the error text. Error: 0xC004C008

So I ran it as requested:

An error has occured

Code: 0xC004C008

Description: The activation server determined that the specified product key could not be used.

 

Finally something to work with.  It turns out there are limits placed on your KMS server and you have to contact Microsoft to get your KMS server limits increased.  So my sales rep and I contacted Microsoft Licensed Support at 1-866-230-0560.

They requested we send an upgrade request to the address kmsadd@microsoft.com

Ask for an increase in X number of activations on the key with the following details included:

  • Enrollment Number:
  • Company Name:
  • # of Activations:
  • KMS Key to modify:

It sure would have been helpful if Microsoft could have just said, "Hey Dude you have used up all your KMS licenses.  Please contact your local sales rep to get your count increased."

I have now gone through the requested steps and emailed my request but I still have to wait up to two business days for it to complete. 

The email response from their robot:

Thank you for your request for additional KMS activations. You can expect to receive a response within two business days. 

All support and responses provided through this alias will be in English.

 

Please reference Case ID:xxxxxxx for any questions regarding this request.

 

Hopefully the tags on this page help others to quickly solve this problem.              

 

Thanks to Josh Bussiere for his assistance.

 

Changing the Weight and Priority of a Domain Controller Within a Site

If you have multiple domain controllers (dc) within a site and you would like to have one of these dc's refered to more often or only if no other dc is available.  Selection of a dc within a site is controlled by both the weight and priority. 

Weight of a Domain Controller

By default all dc's have a weight of 100, the heavier the weight the more often the dc is referred to.  The formula for the referral is based is an elementary math.  If there are two servers in a site and one has a weight of 100 and the other 200.  The dc with twice the weight will receieve twice the referals.

To modify the weight of a dc the registry key:

 HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\LdapSrvWeight is used.

 

Priority of a Domain Controller

By default all dc's have a priority of 0, the lower the priority the first in priority.  The dc with the lowest priority in the site will receive ALL authentication requests unless it is unavailable.  If the lowest priority dc is unavailable then the next lowest dc in the site will receive all requests, etc...

To modify the priority of a dc the registry key:

 HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\LdapSrvPriority is used.

 

For additional information see: http://technet.microsoft.com/en-us/library/cc787370(WS.10).aspx

Posted by Paul Bergson | 0 Comments
Filed under: , ,

Moving the NTP service to a new PDCe

Want to move the time service to the new PDCe? 

This is something that is required if you have just moved the PDCe to a new Domain Controller.

First you need to reset the old PDCe time service, so that it is part of the domain heirarchy (Or you just want to reset a client back to default).
 
From a command prompt on the old NTP server
 "net time /setsntp: "                  (Note the blank space prior to the end ")
  The prior command line tells the DC to delete the current registry settings for the time service

Follow this by: 
 w32tm /config /syncfromflags:domhier /update
  The prior command line should reset the domain time hierarchy

Follow this by:
 net stop w32time && net start w32time
  This DC should now be part of the time domain heirarchy

Next you need to assign the NTP service to the new PDCe

To verify the PDCe role run the following from a command prompt

Netdom query fsmo

Once you have established the correct DC, follow the steps below as taken from KB816042

  1. Change the server type to NTP. To do this, follow these steps:
    1. Click Start, click Run, type regedit, and then click OK.
    2. Locate and then click the following registry subkey:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\Type
    3. In the right pane, right-click Type, and then click Modify.
    4. In Edit Value, type NTP in the Value data box, and then click OK.
  2. Set AnnounceFlags to 5. To do this, follow these steps:
    1. Locate and then click the following registry subkey:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\AnnounceFlags
    2. In the right pane, right-click AnnounceFlags, and then click Modify.
    3. In Edit DWORD Value, type 5 in the Value data box, and then click OK.
  3. Enable NTPServer. To do this, follow these steps:
    1. Locate and then click the following registry subkey:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer
    2. In the right pane, right-click Enabled, and then click Modify.
    3. In Edit DWORD Value, type 1 in the Value data box, and then click OK.
  4. Specify the time sources. To do this, follow these steps:
    1. Locate and then click the following registry subkey:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters
    2. In the right pane, right-click NtpServer, and then click Modify.
    3. In Edit Value, type Peers in the Value data box, and then click OK.

      Note Peers is a placeholder for a space-delimited list of peers from which your computer obtains time stamps. Each DNS name that is listed must be unique. You must append ,0x1 to the end of each DNS name. If you do not append ,0x1 to the end of each DNS name, the changes made in step 5 will not take effect.
  5. Select the poll interval. To do this, follow these steps:
    1. Locate and then click the following registry subkey:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient\SpecialPollInterval
    2. In the right pane, right-click SpecialPollInterval, and then click Modify.
    3. In Edit DWORD Value, type TimeInSeconds in the Value data box, and then click OK.

      Note TimeInSeconds is a placeholder for the number of seconds that you want between each poll. A recommended value is 900 Decimal. This value configures the Time Server to poll every 15 minutes.
  6. Configure the time correction settings. To do this, follow these steps:
    1. Locate and then click the following registry subkey:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\MaxPosPhaseCorrection
    2. In the right pane, right-click MaxPosPhaseCorrection, and then click Modify.
    3. In Edit DWORD Value, click to select Decimal in the Base box.
    4. In Edit DWORD Value, type TimeInSeconds in the Value data box, and then click OK.

      Note TimeInSeconds is a placeholder for a reasonable value, such as 1 hour (3600) or 30 minutes (1800). The value that you select will depend upon the poll interval, network condition, and external time source.
    5. Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\MaxNegPhaseCorrection
    6. In the right pane, right-click MaxNegPhaseCorrection, and then click Modify.
    7. In Edit DWORD Value, click to select Decimal in the Base box.
    8. In Edit DWORD Value, type TimeInSeconds in the Value data box, and then click OK.

      Note TimeInSeconds is a placeholder for a reasonable value, such as 1 hour (3600) or 30 minutes (1800). The value that you select will depend upon the poll interval, network condition, and external time source.
  7. Quit Registry Editor.
  8. At the command prompt, type the following command to restart the Windows Time service, and then press ENTER:
    net stop w32time && net start w32time

 Reference - "Keeping the Domain on Time" a Microsoft Blog
http://blogs.msdn.com/b/w32time/archive/2007/09/04/keeping-the-domain-on-time.aspx

Reference - Ryan Sizemore's blogs on time
http://blogs.msdn.com/b/w32time/

AD Clients Not Authenticating to its Local Site

Ever have a Branch Office or Site that has clients that doesn't authenticate to the local dc?  Adminstrators get confused and start looking at the client to try and figure out what is wrong, when it is most likely and incorrectly configured Sites and Services subnet situation.  When a workstation first logs on (Machines log onto the domain, just like users) it sends out a dns query to locate a service record of the closest DC for the subnet this workstation resides on. 

There are three possible scenarios for a client to attach to a DC:

  1. The subnet that this machine resides on has been properly defined in Sites and Services
  2. The site this machine belongs to doesn't have a domain controller within its site
  3. This machine's subnet hasn't been defined in Sites and Services

There is no reason to go over scenario one, since everything is working as expected

Scenario two should be working as well, since auto site coverage was implemented in Windows 2003.  Domain Controllers should register their DNS service (SRV) records in nearby sites that contain no DC's.  This action is known as "Automatic Site Coverage" (ASC),  ASC has to factor in the link costs associated with a site to compute the cheapest route for the DC less clients with in the site.

Scenario three is a mistake in the Sites and Services defined topology by the administrator.  Although the client and Domain Controller both exist in the same subnet, the subnet hasn't been defined in Sites and Services.  Therefore when the client machine hatches the DC Locator service, the DC in the local site isn't offered to authenticate the machine or the user.  Instead a Dc from the default-site within Sites and Services is presented to the client.  Also the log file netlogon.log on the authenticating DC is updated with a line noting the missing subnet.  I check this log file weekly to verify that our network crew didn't add any new subnets without our group being notified. 

Just run the following from a command prompt on your default-site DC's to see if there are any undefined subnet's:

notepad.exe %systemroot%\Debug\Netlogon.log

You will need to examine each DC to verify that all your sites are defined.

To clear out this log, the NetLogon service needs to be stopped before saving it.

Best Practices - Sites and Services
http://technet.microsoft.com/en-us/library/cc755768(WS.10).aspx

Want to know which site a computer think it belongs to?  Check the registry value at:
HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\DynamicSiteName\

For complete details check out the following URL:
http://blogs.technet.com/b/askds/archive/2008/09/24/domain-locator-across-a-forest-trust.aspx

 

Active Directory Cleanup - The Most Common Question I See

I am out in the Microsoft NewsGroups and quite often I see someone having trouble with their Active Directory (AD) domain.  The number one issue I see is they will lose a Domain Controller (DC) and just move on without realizing that without letting the rest of the DC’s know that this machine is not coming back –or– they attempt to reintroduce a DC back into the domain with the same name without cleaning up the metadata within AD.

 

To clean up AD after a lost DC is relatively simple and a script has been released that now makes it so there is no need to use ntdsutil.  The few times I have had to clean up AD, I still use the manual method but I like to feel in control of things and see what is happening.  There should be nothing wrong in using the script.

frsMember object cleanup
http://blogs.dirteam.com/blogs/paulbergson/archive/2013/06/24/clean-up-dcs-sysvol-frs-member-object.aspx
 

The KB article to manually cleanup the metadata is 216498

The TechNet script to clean up the metadata is linked here addmvb04

 

Once you have cleaned things up you still have to go into Active Directory Sites and Services and remove the lost DC from the site in which it belonged.  This is a requirement even if you had a successful demotion.  The steps for this are outlined at the end of each section within the manual cleanup.

 

Update 

With the release of 2008, there have been enhancements to no longer require scripting or command line.  Just be sure to use the 2008 console of Sites and Services outlined in the link below:

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

Posted by Paul Bergson | 1 Comments
Filed under:

Disabling IPv6 on Windows 2008

I have run into nothing but trouble with IPv6.  Not that there is anything in particular that is wrong, but not all apps understand and can work with it.  For example I am running a geographically dispersed cluster on a Windows server with 2008 Exchange 2007 on a Dell 2950.  I am getting these odd Event Log errors 2501, 2601 and 2604. 

When updating security for a remote procedure call (RPC) access for the Exchange Active Directory Topology service, Exchange could not retrieve the security descriptor for Exchange server object xxxxxxx - Error code=8007077f.  The Exchange Active Directory Topology service will continue with limited permissions.

For my experience it turns out a tunnel adapter on the 2950 is mapping a DNS record on IPv6.  I thought I had disabled all the IPv6 pieces but I was mistaken. 

The following recipe should be what is needed to disable all pieces of IPv6 on Windows Server 2008 (As well as Vista) as well as enabling ping on IPv4.


Enable Pings, Firewall doesn't allow IPv4 pings
                Server Manager / Configuration / Windows Firewall with Advanced... / Inbound Rules
                                Action / New Rule
                                                Select Custom
                                                                Next
                                                Select All Programs
                                                                Next
                                                Protocol Type = ICMPv4
                                                                Next
                                                Local Ip Address = Any
                                                Remote IP Address = Any
                                                                Next
                                                Select allow the connection
                                                                Next
                                                Check Domain
                                                Check Private
                                                Check Public
                                                                Next
                                                Name = IPv4
                                Finish
 
Network
                Right Click Network Places
                Select Manage Network Connections For each enabled and used NIC
                                Right Click - Local Area Connection - Select Properties
                                                Networking Tab                               
                                                                DeSelect IPv6
                                                Close
 
Disables tunneling but not the loopback interface
                Regedit  (For additional info http://technet.microsoft.com/en-us/library/bb878057.aspx)
                                Add the following key
                                                HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\DisabledComponents
                                                                DWORD => FFFFFFFF
 
Change the Nic Provider Order
                Network Connections
                                Advanced
                                                Advanced Settings
                                                                Provider Order
                                                                                Move Microsoft Windows Networks to the top

Posted by Paul Bergson | 9 Comments