ads

Style6

Style3[OneLeft]

Style3[OneRight]

Style4

Style5[ImagesOnly]

Style2

Domain Controller Preference Order












Outline:

How to configure locator preferences for domain controllers (DCs).  How to set priority and weight on domain controllers.  Force clients to consistently connect to the same domain controller.

Problem: 

Clients connect to different DCs within the same site.  IPv4 DNS server search has no effect on this random behavior.  

Solution:

(a) Assign priority and weights to DNS SRV-records via GPO (i.e., registry changes);
(b) Or, change subnet topology for simple DC Subnet Prioritization;

Assumptions:

All DCs are located within the same Active Directory (AD) site.

Domain Controller Priority within a Site

Domain DNS SRV-records assign priority and weight values that determine DC preference.  Clients connect to the domain controller (DC) with the lowest priority value.  By default, priority for all DCs is set to zero.  For example, assume a site has two DCs:
  • ·     DC-X with a priority of 0 (i.e., preferred).
  •        DC-Y with a priority of 2.
In this example, Windows clients connect to DC-X because it has the lowest priority value.  Clients only connect to DC-Y when DC-X is unavailable (e.g., maintenance).  

Domain Controller Weights

What happens when all the DCs share the same priority?  In this situation, DC preference is determined by SRV-record weight values.  Unlike priority, clients prefer higher weight values over lower values.

What happens if all DCs have the same weight values?  By default, DCs weight value is set to 100.  Clients connect round-robin when all DCs use the same priority and weight values.

What happens when same-site DCs have the same priority and different weight values?  Weight is not absolute.  Weight is proportionate.  In other words, clients may disproportionately connect to any available DC. 

Clients are more likely to connect to DCs with higher weights.  Clients are less likely to connect to lower weights DCs.  Weight preference uses a simple formula:  DC weight (i.e., single server) divided by the sum of all DCs weights:

          
For Example, assume three DCs within a single AD site (Table 1):

Table 1
Determine domain controller preference based on weights.

Domain
Controller
Priority
 (Default)
Weight
Formula
Connection Odds
DC10
0
10
10/(10+20+30)
 = 10/60
 = 1/6
17%
DC20
0
20
20/(10+20+30)
 = 20/60
 = 2/6
33%
DC30
0
30
30/(10+20+30)
 = 30/60
 = 1/2
50%
Note:  This assumes client and domain controllers reside in the same site and use the same priority values.

DC Preference Configuration

  1. Set priority and weight via the registry:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
  2. Create new 32-bit DWORDs:
    LdapSrvWeight
    LdapSrvPriority
  3. Assign DC priority and weight values.
  4. Restart the NETLOGON service to publish to SRV records

Subnet Prioritization

Clients prefer to connect to DCs on the same IP subnet.  For example, let’s say we have a single AD site.  This site consists of one Windows 10 client and two DCs (Table2):

Table2
Subnet Prioritization

Host
Priority
Weight
IP address
Preferred DC
WIN-10


192.168.1.1/24

DC-X
0
100
192.168.1.100/24
Yes
DC-Y
0
100
192.168.2.100/24
No
  Note:  All hosts reside in the same AD site.  DC01 and DC02 use default weight and priority values.

In this situation, all hosts belong to the same AD-site.  Both DCs have the same preference values (i.e., default).   WIN-10 and DC-X belong to the same IP subnet.  However, DC-Y resides on a separate IP subnet.  DC-X is the preferred DC.  Clients only connect to DC-y when DC-X is unavailable (e.g., maintenance).  

Additional Thoughts:

I recommend minimal registry changes –especially to DCs.  Implement priority and weight changes with caution.  Also consider, registry changes can be difficult to troubleshoot.  Therefore, it’s prudent to push these changes out via GPO. 
 
Subnet Prioritization seems to be the simplest approach.  That is, if you’re comfortable with internetworking.  Simply create a new gateway.  Add routes.  Assign the subnet to the second DC.  Done.

That’s It!

References:


Force AD DC Replication CMD


Goal:  

Synchronize Active Directory in a flash.

Problem:  

How to quickly force domain controller replication throughout the domain.

Solution:

   repadmin /syncall /AdeP


That's It!

Restricted AD Groups for Local Admins

Summary:  

Create a domain security group that manages local administrators.  This process allows domain users (i.e., non-domain administrators) to administer computers. 

Problem:  

System Administrators log onto workstations and servers with their domain admin account.  Casual use of domain administrator accounts put the entire organization at risk of compromise from malware, keyloggers, and hash attacks.

Additionally, attackers may compromise services or scheduled tasks run with local system privileges.  This can provide a foothold that compromises the system. 

Goal:  

Prevents network administrators from using their Domain Admin accounts for general purposes.  Implement a general purpose administrative account.

Solution:  

Implement GPO restricted groups provide administrator (i.e., non-domain admin) to manage computers. Steps:

  1. Create new security group in AD.  This group will be used to manage computers.  Add domain users to this group as needed.
     
  2. Create Restricted Group GPO.

    Computer Configuration\Policies \Windows Settings\Security Settings\Restricted Groups\

  3. Right click on Restricted Groups.  Left click on Add Group. 
  • Members of this group (i.e., domain group):  New AD security group created in Step 1.
  •  The Group is a member of (i.e., local group):  This is the local security group for each workstation (e.g., Administrators).
      4.  Assign new GPO to AD OU.  Wait for change to propagate.
  No more unnecessary use of domain admin accounts.  That's It!

References:

https://support.microsoft.com/en-us/kb/279301
http://social.technet.microsoft.com/wiki/contents/articles/20402.active-directory-group-policy-restricted-groups.aspx


How to Fix Primary Domain Trust Failures

Error:  

The trust relationship between this workstation and the primary domain failed.

Problem:  

Domain computers use internal passwords to authenticate with Active Directory (AD).  Servers and workstations automatically reset their passwords every 30 days.  Suspended virtual machines or server backups may not logon domain users if the computer has a new password in AD.

Solution:   

Fix domain trust issues: (1) in AD, and (2) on the computer.

  1.    Reset the computer account in Active Directory Users and Computers (ADUC). 

    Open ADUC → Computers OU → Right-Click on the computer → Reset Accout

  2.  Reset the computer with PowerShell.  N.B., This step requires local Administrative rights.  We can't reset the computer, or even re-join the domain, with out the ability to log on locally.

    From PowerShell:  Reset-ComputerMachinePassword 
That's It!

References:  http://technet.microsoft.com/en-us/library/hh849751.aspx

Back up Windows 2012 Active Directory (AD) with DPM 2010


Last updated  October 13th, 2013 by Steven Jordan


Backup 2012 AD with 2010 DPM.

Disclaimer:  Microsoft does not support DPM 2010 backup for Windows 2012 servers.  I have found however, the backup process still works.  I have only run into 2 (resolvable) issues so far:
  1. Automatic installation of the DPM 2010 installation agent on Windows 2012 servers no longer works.  The DPM agent must be installed manually.  See my previous post on DPM for instructions.
  2. DPM 2010 backups of the system state for Windows 2012 server with Active Directory (AD) server installed failed. 

    Windows Server Backup must be installed on the Windows 2010 AD server in order to backup the system state.  This is only true for 2012 servers with AD roles installed.  After the Windows Server Backup feature was installed there were no longer problems with related DPM backups. 

Enable Windows Remote Assistance

Problem:   

 IT support staff require an easy method to support remote staff.  Microsoft Lync provides remote desktop viewing but it does not provide Administrative assistance.  Third-party solutions exist but require subscriptions, etc. 

Solution:

 Enable Windows Remote Assistance (RA).  Windows Remote Assistance has improved from the Vista days when it was first released.  When properly enabled, IT staff can initiate an unsolicited RA session to any workstation on the domain; the entire process is simple and intuitive.

Enable RA:

   First, create a "Remote Assistance" GPO within Group Policy Management. Within the GPO there should be 2 policies enabled:
    First GPO:
Computer Configuration\Administrative Templates\Network\Network Connections\Windows Firewall\Domain Profile\Windows Firewall\Define inbound program exceptions:  enabled.
    Add Exceptions to GPO Attribute:
%WINDIR%\SYSTEM32\Sessmgr.exe:*:Enabled:Remote Assistance
%WINDIR%\PCHealth\HelpCtr\Binaries\Helpsvc.exe:*:Enabled:Offer Remote Assistance
%WINDIR%\PCHealth\HelpCtr\Binaries\Helpctr.exe:*:Enabled:Remote Assistance – Windows Messenger and Voice
   Second GPO:
Computer Configuration\Administrative Templates\System\Remote Assistance\Configure Offer Remote Assistance:  enabled.
    Create RA Security Group:
  • Specify AD security group or users to permit remote control of domain workstations.
  • Assign the RA GPO to workstations OU.

  • Once the RA policy has propagated the workstations are ready for administrative remote assistance.

    Managing RA: 

       Providing remote desktop support is a simple process.  IT staff can run the following command to start the remote session:
    Msra.exe /offerRA computer-name
       The Msra command works with both hostname (i.e. computer name) or IP address.  Msra starts the remote session with an end-user request.  The end-user receives a pop-up window that requests permission to start the RA session.

    That's It!

    References:

    http://technet.microsoft.com/en-us/magazine/ff356868.aspx




    The last token starts with 'd'


    Problem:   I recently demoted a Certificate Authority server from Windows 2008.  While deleting the remaining CA objects from Active Directory per:  

         ldifde -i -f remainingCAobjects.ldf

         I received the following error:  

    There is a syntax error in the input file failed on line 3.  The last token starts with 'd'  0 entries modified successfully.  An error occurred in the program.

    Resolution:  Edit the the ldf file so that there is not any data/ text below the "changetype:  delete" line.  If we were adding or modifying AD entries additional directives are expected.  When deleting AD entries the LDIF file only needs the DN and the "changetype=delete" directive.  Working example:   

         dn: cn=Bill Gates,ou=people,dc=microsoft,dc=com  

         changetype: delete

    P.S.  This post has been surprisingly popular.   Please leave comments.  Thanks!  -SMJ


    References:
    http://docs.oracle.com/cd/B14099_19/idmanage.1012/b15883/ldif_appendix002.htm#CHDFECDI
    http://support.microsoft.com/kb/889250