SYSVOL is a folder shared by domain controller to hold its logon scripts, group policies and other items related to AD. All the domain controllers in network will replicate the content of SYSVOL folder. The default path for SYSVOL folder is %SystemRoot%\SYSVOL. This folder path can define when you install the active directory. 
Windows Server 2003 and 2003 R2 uses File Replication Service (FRS) to replicate SYSVOL folder content to other domain controllers. But Windows server 2008 and later uses Distributed File System (DFS) for the replication.  DFS is more efficient than FRS. Since windows server 2003 is going out of support, most people already done or still looking for migrate in to latest versions. However migrating FSMO roles WILL NOT migrate SYSVOL replication from FRS to DFS. Most of the engineers forget about this step when they migrate from windows 2003 to new versions. 
For FRS to DFS migration we uses the Dfsrmig.exe utility. More info about it available on https://technet.microsoft.com/en-au/library/dd641227(v=ws.10).aspx
For the demo I am using windows server 2012 R2 server and I migrated FSMO roles already from a windows server 2003 R2 server. 
In order to proceed with the migration forest function level must set to windows server 2008 or later. So if your organization not done this yet first step is to get the forest and domain function level updated. 
You can verify if the system uses the FRS using dfsrmig /getglobalstate , To do this
1)    Log in to domain controller as Domain admin or Enterprise Admin
2)    Launch powershell console and type dfsrmig /getglobalstate. Output explains it’s not initiated DFRS migration yet. 

Before move in to the configurations we need to look into stages of the migration. 
There are four stable states going along with the four migration phases. 
1)    State 0 – Start
2)    State 1 – Prepared
3)    State 2 – Redirected 
4)    State 3 – Eliminated 
State 0 – Start
With initiating this state, FRS will replicate SYSVOL folder among the domain controllers. It is important to have up to date copy of SYSVOL before begins the migration process to avoid any conflicts. 
State 1 – Prepared
In this state while FRS continues replicating SYSVOL folder, DFSR will replicate a copy of SYSVOL folder. It will be located in %SystemRoot%\SYSVOL_DFRS by default. But this SYSVOL will not response for any other domain controller service requests. 
State 2 – Redirected
In this state the DFSR copy of SYSVOL starts to response for SYSVOL service requests. FRS will continue the replication of its own SYSVOL copy but will not involve with production SYSVOL replication.
State 3 – Eliminated
In this state, DFS Replication will continue its replication and servicing SYSVOL requests. Windows will delete original SYSVOL folder users by FRS replication and stop the FRS replication. 
In order to migrate from FRS to DFSR its must to go from State 1 to State 3.
Let’s look in to the migration steps.
Prepared State
1.    Log in to domain controller as Domain admin or Enterprise Admin
2.    Launch powershell console
3.    Type dfsrmig /setglobalstate 1 and press enter

4.    Type dfsrmig /getmigrationstate to confirm all domain controllers have reached prepared state

Redirected State

1.    Log in to domain controller as Domain admin or Enterprise Admin
2.    Launch powershell console
3.    Type dfsrmig /setglobalstate 2 and press enter


4.    Type dfsrmig /getmigrationstate to confirm all domain controllers have reached redirected state

Eliminated State

1.    Log in to domain controller as Domain admin or Enterprise Admin
2.    Launch powershell console
3.    Type dfsrmig /setglobalstate 3 and press enter

4.    Type dfsrmig /getmigrationstate to confirm all domain controllers have reached eliminated state

This completes the migration process and to confirm the SYSVOL share, type net share command and enter.

Also make sure in each domain controller FRS service is stopped and disabled.

Windows Server 2003 Active Directory에서 Windows Server 2008 이상 버전 (Windows Server 2008, 2008 R2, 2012, 2012 R2) 으로 마이그레이션 한 후에는 SYSVOL 복제 방식을 변경하는 것을 권장합니다.

도메인 기능 수준과 포리스트 기능 수준을 최소 Windows Server 2008 이상으로 올린 후, SYSVOL 복제 방식을 기존 File Replication Service에서 DFS-R 로 변경합니다.

작업이 완료되면 SYSVOL 폴더가 SYSVOL_DFSR 폴더로 대체됩니다.

1. 작업 전 확인

1. 현재 공유 중인 SYSVOL 정보 확인 (net share)

 
2. ADSIEDIT에서 복제 설정 확인 (NTFRS 로 표시됨)

3. 서비스 확인 – 파일복제 서비스와 DFS Replication 서비스 모두 실행 중

2. 복제 설정 변경

1. powershell 실행 후 아래 명령 실행
dfsrmig.exe /GetGlobalState

2. dfsrmig.exe /CreateGlobalObjects

3. dfsrmig.exe /GetGlobalState

4. dfsrmig.exe /GetMigrationState

 
5. dfsrmig.exe /SetGlobalState 0

6. dfsrmig.exe /SetGlobalState 1

 
7. dfsrmig.exe /GetMigrationState

 
8. 위 명령을 계속 수행하여, 아래와 같은 결과가 나올 때 까지 대기

 
9. 탐색기에서 SYSVOL_DFSR 폴더가 생성되었는지 확인

 
10. ADSIEDIT에서 Domain Controller 아래에 아래와 같이 DFSR-LocalSettings 가 표시되는지 확인

11. dfsrmig.exe /SetGlobalState 2

 
12. dfsrmig.exe /GetMigrationState (결과가 아래와 같이 나올 때까지 대기)

13. Registry 편집기에서 SYSVOL 경로가 변경되었는지 확인

14. dfsrmig.exe /SetGlobalState 3

 
15. dfsrmig.exe /GetMigrationState (결과가 아래와 같이 나올 때까지 대기)

16. dfsrmig.exe /GetGlobalState

17. 탐색기에서 SYSVOL 폴더가 삭제되었는지 확인

18. ADSIEDIT에서 NTFRS Subscriptions 가 삭제되었는지 확인

3. 작업 후 확인

1 DFS 관리 콘솔에서 확인
복제에 Domain System Volume 이 생성되었습니다.

 
2 서비스 확인
File Replication Service가 중지되고 사용 안 함으로 변경된 것을 확인.

 
3 SYSVOL 공유 확인
net share 

끝.

사용자 지정 Active Directory 특성 만들기

기존 특성을 사용할 수 없는 사용자 지정 Active Directory 특성을 만드는 방법에 대해 설명합니다. 예를 들어 사용자의 "메디케어 카드 번호"를 보유할 속성을 만듭니다.

 

사용자 지정 특성을 추가하려면 스키마 관리자 및 엔터프라이즈 관리자 그룹의 구성원이어야 하는 AD 스키마의 수정이 포함됩니다. 기본적으로 관리자 계정은 스키마 관리자 그룹의 구성원입니다.

또는 스키마를 확장하는 대신 스키마를 확장하지 않고 사용자 지정 데이터를 저장하는 데 사용할 수 있는 ExtensionAttribute1부터 ExtensionAttribute15까지의 기존 특성이 있습니다.

사용자 속성의 속성 편집기 탭을 통해 사용자 개체 속성을 볼 수 있습니다.

스키마에 속성을 추가하기 전에 기본적으로 Active Directory 스키마는 관리 콘솔에서 사용할 수 없으므로 스키마 스냅인을 등록해야합니다.

• 시작 > 실행 >mmc로 이동합니다.

• 파일 열기 > 스냅인 추가/제거를 엽니다.

 

• "활성 디렉토리 스키마"가 없음을 알 수 있습니다.

• 스키마 스냅인을 등록하려면 실행 텍스트 상자에 RegSvr32 SchmMgmt.dll를 입력하고 확인을 누릅니다.

• SchmMgmt.dll 등록에 성공하면 Windows에 정보 메시지 상자가 표시됩니다.

 

• 스키마 스냅인을 엽니다. 시작 > 실행 > mmc.exe > 파일 >스냅인 추가/제거 >Active Directory 스키마 > 추가

• Active Directory 스키마를 확장하고 특성을 마우스 오른쪽 단추로 클릭한 다음 "특성 만들기.."를 클릭합니다.

• 계속을 클릭하면 스키마 개체 생성 경고 메시지가 표시됩니다.

다음 단계를 진행하려면 고유 X500 개체 ID 필드에 대한 OID(개체 식별자)를 생성해야 합니다.
PowerShell 또는 VBScript를 사용하여 OID를 생성할 수 있습니다.

PowerShell을 사용하여 OID 생성(Microsoft Link):

Windows PowerShell > Windows PowerShell
> 모든 프로그램 > 액세서리 >시작 시작으로 이동하여 PowerShell 창에 다음 문을 복사하여 붙여넣습니다.

#---
$Prefix="1.2.840.113556.1.8000.2554"
$GUID=[System.Guid]::NewGuid(). ToString() $Parts=@()

$Parts+=[UInt64]::P arse($guid. SubString(0,4),"AllowHexSpecifier")
$Parts+=[UInt64]::P arse($guid. SubString(4,4),"AllowHexSpecifier")
$Parts+=[UInt64]::P arse($guid. SubString(9,4),"AllowHexSpecifier")
$Parts+=[UInt64]::P arse($guid. SubString(14,4),"AllowHexSpecifier")
$Parts+=[UInt64]::P arse($guid. SubString(19,4),"AllowHexSpecifier")
$Parts+=[UInt64]::P arse($guid. SubString(24,6),"AllowHexSpecifier")
$Parts+=[UInt64]::P arse($guid. SubString(30,6),"AllowHexSpecifier")
$OID=[String]::Format("{0}.{ 1}. {2}. {3}. {4}. {5}. {6}. {7}",$prefix,$Parts[0],$Parts[1],$Parts[2],$Parts[3],$Parts[4],$Parts[5],$Parts[6])
$oid
#---

OID 문자열(점으로 구분된 숫자 문자열)을 복사하여 고유한 X500 개체 ID 필드에 붙여넣습니다.

VBScript (마이크로 소프트 링크)를 사용하여 OID 생성 :
웹 브라우저에서 다음 링크를 열고 VB 스크립트 코드를 복사하여 메모장에 붙여 넣습니다.

 

http://gallery.technet.microsoft.com/scriptcenter/56b78004-40d0-41cf-b95e-6e795b2e8a06

C: 드라이브에

"OIDGen.vbs"(큰따옴표로 묶음, 그렇지 않으면 접미사 .txt .vbs 뒤에 접미사) 이름으로 메모장 파일 저장 명령 프롬프트를 열고이 스크립트를 실행하십시오. 시작 > cmd.exe >> CScript.exe C:\OIDGen.vbs
OID 문자열(점으로 구분된 숫자 문자열)을 복사하여 고유한 X500 개체 ID 필드에 붙여넣습니다.

• 새 속성 만들기 대화 상자에 일반 이름(이 경우 메디케어 번호)을 입력합니다.
• LDAP 표시 이름 필드는 일반 이름(공백 없음)에서 자동으로 채워집니다.
• 이전 단계에서 생성한 OID 문자열을 고유 X500 개체 ID 필드에 붙여넣습니다.
• 텍스트 상자에 설명을 씁니다.
• 드롭다운 목록에서 적절한 구문을 선택하여 속성 유형(이 경우 Medicare 번호는 숫자 값)을 선택합니다. 이것은 다른 유형일 수 있으며 각 특성의 사용법에 따라 다릅니다)
• 확인을 클릭합니다.

사용자 지정 속성 medicareNumber가 생성됩니다.

• 이제 이 새 특성을 User 클래스에 추가/연결합니다. 클래스 리프로 이동하여 사용자 클래스를 선택합니다.
• 사용자를 마우스 오른쪽 버튼으로 클릭하고 속성을 클릭합니다.

• 속성 탭으로 이동합니다. 추가를 클릭합니다.

• 메디케어넘버 속성을 찾아 확인을 클릭한 후 다시 확인을 클릭합니다.

• 특성이 User와 연결되었는지 확인하려면 User, 속성을 마우스 오른쪽 단추로 클릭하고 속성 탭으로 이동합니다. medicareNumber 속성은 선택적 속성 목록에 있어야 합니다.

이것으로 사용자 지정 특성 만들기가 완료됩니다.

사용자 및 컴퓨터 스냅인을 열고 사용자 지정 특성에 대한 사용자 속성을 확인합니다.


이 속성의 값은 편집 버튼을 클릭하고 적절한 값을 입력하여 설정할 수 있습니다.


메디케어 카드 번호가 설정된 모든 사용자를 보려면 다음 명령줄 문을 실행할 수 있습니다.

DSQuery * -Filter (medicareNumber=*) -Attr Name, medicareNumber

끝.

[Windows] Event Log를 필터링하기(XML을 통한 Custom View생성)

1. 보안 이벤트에서 이벤트 ID 5061과 로그인 사용자가 gmkim 혹은 mani4u 값으로 조회, 24시간 이내 값만

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
*[System[(EventID=5061) and TimeCreated[timediff(@SystemTime) &lt;= 86400000]]]
and
*[EventData[Data[@Name='SubjectUserName'] and (Data='gmkim'  or Data='test9')]] 
</Select>
  </Query>
</QueryList>

2. 모든 스키마에서 검색 데이터 값이 있으면 모두 쿼리

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
*[EventData[Data and (Data="gmkim" or Data="mani4u")]]
</Select>
  </Query>
</QueryList>

Advanced XML filtering in the Windows Event Viewer | Microsoft Learn

특정 사용자 계정잠금 예외처리는 Active Directory 관리 센터를 이용하여 가능 합니다.

[특정 사용자 계정 잠금 예외 처리 방법]

1. AD 서버 접속

2. 시작> Windows 관리 도구> Active Directory 관리 센터         

3. 도메인명(로컬)>system>Password Settings Container 선택       

4. 새로 만들기 > 암호 설정 선택         

5. 암호 설정 만들기 속성 값 설정

   5-1. 이름, 우선 순위 필수 값 입력

   5-2. 계정 잠금 정책 적용 체크 박스 해제

   5-3. 암호 정책 설정 값은 기존 회사 기준 값으로 설정 된 GPO를 참고 하시거나 임의로 넣으시면 됩니다.      

6. 적용 대상 추가

7. 계정 잠금 예외 처리 할 계정 입력 및 확인    

 8. 확인      

 9. 정책 적용

대상 컴퓨터에서 적용은 최대 90분이 소요 될 수 있습니다.

빠르게 하기 위해서는 대상 컴퓨터에서도 gpupdate 명령을 실행 해주시면 됩니다.

끝.

Default group policy GUIDs are as follows:

Default Domain Policy

31B2F340-016D-11D2-945F-00C04FB984F9

Default DC Policy

6AC1786C-016F-11D2-945F-00C04FB984F9

Recreates the default Group Policy Objects (GPOs) for a domain. To get to the Group Policy Management Console (GPMC), you must install Group Policy Management as a feature through Server Manager.

Syntax

dcgpofix [/ignoreschema] [/target: {domain | dc | both}] [/?]

Parameters

Examples

To manage the default Account Policies settings, Password Policy, Account Lockout Policy, and Kerberos Policy, while ignoring the Active Directory schema version, type:

dcgpofix /ignoreschema /target:domain

To configure the Default Domain Controllers Policy GPO only to set user rights and audit policies, while ignoring the Active Directory schema version, type:

dcgpofix /ignoreschema /target:dc

Disclaimer

I am writing this blog  and others to explain how things work and some ways deployment and operational tasks can be handled. In other words, these postings are for demonstration purposes only. Since I am not familiar with your organization or environment I do not know if these steps are applicable to your environment or are even safe to perform in your environment. It is recommended that you contact Microsoft Support prior to making changes in your environment to ensure that these steps are applicable to your environment, and are safe to perform in your environment. By writing this blog I am in no way recommending that you perform these steps in your own environment. If you choose to follow the steps outlined in this or other blog postings on this site, you are assuming the risk for your actions.

1              Troubleshooting Active Directory Replication

1.1                 Repadmin.exe

Repadmin is a tool for checking replication status and troubleshooting replication issue.  Below is a table highlighting commonly used syntax of the repadmin tool.

Additional information on Repadmin.exe is available here: https://technet.microsoft.com/en-us/library/cc736571(v=ws.10).aspx

1.2                 Repadmin /replsummary

As seen in the screenshot below repadmin /replsummary will give statistics for replication with replication partners.  The output also lists any errors that were encountered with replication. This is useful for getting an overview of any replication issues the DC is having.

You can also sort the output.  In the example below, the output is sorted by the largest delta since last replication.

1.3                 Repadmin /showrepl

As seen below repadmin /showrepl shows the replication status with all of the DCs replication partners and is sorted by the Naming Context that is being replicated.

One trick that can be used to get a more manageable output is to use repadmin to send its output to a CSV and the use PowerShell to convert the CSV to a GridView.  The command to do this is repadmin /showrepl * /csv | ConvertFrom-CSV | Out-GridView

The resulting output is in a manageable GUI.

In GridView you can sort and filter.  Below is an example of filtering on Number of Failures, so that I can easily see what failed.

1.4                 Repadmin /showutdvec

Replications changes are tracked through incrementing numbers called USNs.  There are times where you will want to know what knowledge each DC has about other DCs current state.  The up-to-dateness vector is the knowledge that a DC as about the current state of other DCs.  This information can be useful when trying to troubleshoot replication issues such as USN Rollback.  USN Rollback is when a DC is restored from an unsupported method such as a snapshot.  In that case the up-to-dateness vector would be much larger than the actual USN of the DC. Since, there is going to be some delay in replication you will notice some differences but the numbers should be relatively close.  For example, if you compare the up-to-dateness vector for DC01 across DCs you will notice the following: for itself DC01 has USN of 17347, DC02 has a USN of 17346 for DC01, and DC03 has a USN of 17346 for DC01.  So, we can see the numbers are relatively close and that DC01 potentially has one change that it needs to replicate to DC02 and DC03.

1.5                 Repadmin /showobjmeta

The /showobjmeta switch shows detailed information for attributes of an object.  It is most commonly used when comparing the output of the command from 2 DCs to see if they are in sync and the current status of the attributes.  Differences can be used to identify replication problems.

1.6                 Repadmin /syncall

Repadmin /syncall is used to force replication between domain controllers.  You can easily view options for the /syncall switch with the following command: repadmin /syncall /?

A normal use of repadmin /syncall is with the /AeP switch

1.7                 Repadmin /showmsg

The /showmsg switch is used to convert an error message you may receive as the result of a repadmin command and converts it to human readable text.

1.8                 Repadmin /viewlist

Repadmin /viewlist is used to get a list of domain controllers.

1.9                 PowerShell

PowerShell is an object oriented scripting language that allows enterprises to automate IT tasks.

Below is a conversion table that shows the PowerShell command that can be used in place of the Repadmin command.  So, why would you choose to use PowerShell?  The output of PowerShell commands are objects those objects can be filtered with properties, piped through other PowerShell commands and manipulated to many useful things including great control in how the data is presented to the user.

Get-ADReplicationParnerMetadata is very similar to running repadmin /showrepl.  Without passing the output through another cmdlet the formatting is a bit different then to what you get with repadmin.

However, the advantage is that the output of the command are objects.  You can constrain your views to certain properties.

The other advantage is that you can pass objects through other cmdlets.  As seen here I am passing the output of Get-ADReplicationPartnerMetadata through Output-GridView.

Once in GridView you have the ability to sort and filter the data.

Here is another example of the usefulness of using PowerShell over repadmin.  In this example I take the output of Get-ADReplicationPartnerMetadata then passing it through Select-Object so that we can then limit what objects are presented in GridView.

Here we see the output of that command.

1.10             Replication Errors

Here is a list of replication errors you may come across in either the Directory Services event log or while running repadmin.

2              Troubleshooting Steps for Common Replication Issues

2.1                 Troubleshooting -21468930222  (The target principal name is incorrect)

On the DC that is the cause of the error, perform the following steps:

Step 1: Open Services.msc

Step 2: Configure KDC Service for Manual

Step 3: Stop the Service

Step 4: Restart the Domain Controller

Step 5: Open PowerShell as an Administrator

Step 6: Run: $cred = Get-Credential

Step 7: Enter Credentials and click OK

Step 8: Run, Reset-ComputerMachinePassword –Server <ServerName> -Credential $cred

Step 9: Restart the server

Step 10: Set the KDC service to Automatic, Start the service and click OK.

2.2                 Troubleshoot Replication Error 8606, Event ID 1388, and Event ID 1988

These issues are caused by lingering objects.  Lingering objects can be caused when a domain controller is taken offline for an extended period of time, does not replicate for longer than the tombstone lifetime, or is restored from a backup that is older than the tombstone lifetime. 

When an object is deleted it is put in a tombstone state.  After the tombstone lifetime passes (typically 180 days), DC run garbage collection and those tombstone objects are deleted.  If a DC was offline for the entire TSL and then were brought back online they may have objects that have since been deleted, tombstoned, and garbage collected.  Any objects that were deleted will still exist on that DC.  These objects go unnoticed until a change is made to that object then the DC attempts to replicate that object, and at that point that is where it is either re-introduced into the environment or if strict replication consistency is enabled, blocked. 

2.2.1   How to Determine TSL

Run the following command: dsquery * “cn=directory service,cn=windows nt,cn=services,cn=configuration,<Forest DN>” –scope base –attr tombstonelifetime

2.2.2   How to Remove Lingering Objects

2.2.2.1          Repadmin /removelingeringobjects

One way to remove lingering objects is to user repadmin with the /removelingeringobjects switch.  First you must identify a clean source of the partition.  The syntax of the command is repadmin /removelingeringobjects <Dest DC Name> <Source DC Guid> <Naming Context>.  So, in other words you need to identify the source DCs guid and the Naming Context you want to clean.  The naming context will be available in the Event 1388 or 1988 you receive in the event long.  Once you find a clean source you can obtain the guid by opening DNS Manager and opening up the _msdcs Zone and obtaining the CName record for the DC in question.

Below is an example of running the repadmin /removelingeringobjects command

You will receive an Event 1937 when the removal of lingering objects begins.

You will then receive an Event 1939 when removal completes.

2.2.2.2          Repadmin /rehost

An alternative to using repadmin /removelingeringobjects command is to unhost the partition so that the domain controller no longer has that partition and then rehosting the entire partition with a good source.

The repadmin syntax for unhosting the partition is repadmin /unhost <DC Name> <Partition Name>

You will receive an event an event 1658 when the removal begins.

You will receive an event 1660 when the removal completes

The syntax for rehosting the partition is: repadmin /rehost <Dest DC Name> <Partition> <Source DC Name>

2.3                 Troubleshooting Event ID 2042

Review event log for any 1988 or 1388 errors.  If found use the previous section to remove the lingering objects from the domain controller. 

Option 1: Re-hosting the partition that has not replicated

If the partition is a GC partition consider unhosting and rehosting the partition. Instructions for unhosting and rehosting are in the previous section called Repadmin /rehost

Option 2: Removing and then re-adding the domain controller to Active Directory

Another option is removing the DC from Active Directory and Re-promoting the Domain Controller

Step 1: Run Import-Module ADDSDeployment

Step 2: Run: Uninstall-ADDSDomainController –DemoteOperationMasterRole:$true –Force:$true

Step 3: Enter and confirm the new local password

Step 4:  Next you will need to run the Install –ADDSDomainController cmdlet.  Below is a sample that you can use.  You will need to modify the template to meet the requirements of your environment. 

Install-ADDSDomainController –NoGlobalCatalog:$false –CreateDnsDelegation:$false –CriticalReplicationOnly:$false –DatabasePath “C:\Windows\NTDS” –DomianName “fabrikam.com” –InstallDNS:$true –LogPath “C:\Windows\NTDS” –ReBootOnCompletion:$false –ReplicationSourceDC “DC01.fabrikam.com” –SiteName “Default-First-Site-Name” –SysvolPath “C:\Windows\SYSVOL” –Force:$true

Option 3: Enabling Replication with Divergent and Corrupt Partner

Due to the risk of adding lingering objects to Active Directory the final consideration should be enabling the following setting: Allow Replication With Divergent and Corrupt Partner. 

Step 1: To enable this setting run the following command on the domain controller:

repadmin /regkey <hostname> +allowDivergent

Step 2: Let replication complete

Step 3: Disable the setting with the following command: repadmin /regkey <hostname> -allowDivergent

2.4                 Troubleshooting Event ID 1311

Event 1311 is caused when there is not complete connectivity between domain controllers. There are a number of reasons there may not be complete connectivity. 

2.4.1   ISTG

The Inter-Site Topology Generator (ITSG) is responsible for building the replication topology.  So to determine what the scope of the connectivity issues it is important to identify the ISTGs that are logging 1311. 

To find the ISTGs in your environment you need to use ldp.exe

Below are the steps for locating the ISTGs:

Step 1: Launch ldp.exe

Step 2: When LDP opens, select Connection and then Connect…

Step 3: In the Connect dialog box, enter the name of a Domain Controller for the Server you want to connect to and then click OK

Step 4: Click on Connection and then click Bind…

Step 5: In the Bind dialog box, click OK

Step 6: Select the Browse menu and then select Search

Step 7: In the search enter the following:

Base DN: CN=Sites,CN=Configuration,<DN of Forest Root> (example: CN=Sites,CN=Configuration,DC=fabrikam,DC=com)

Filter: (CN=NTDS Site Settings)

Scope: Subtree

Attributes: Append the following to the attributes that are already listed: ;interSiteTopologyGenerator

Step 8: Click Run

Step 9: For each site you will then need to look for interSiteTopologyGenerator to determine the ITSG for each site.

2.4.2   BASL

By default, Bridge All Site Links (BASL) is enabled in Active Directory.  If your environment is not fully routed, then you will want to disable BASL.  By fully routed we mean each site can contact every other site.  If BASL is configured on a network which is not fully routed, the KCC will generate site bridges that cannot actually be reached. To determine if BASL is enabled launch Active Directory Sites and Services (dssite.msc). 

Expand Sites, then Inter-site Transports.

Right-click on IP and select Properties from the context menu

If Bridge all site links is enabled, there will be a check box next to it.  To disable BASL, uncheck the checkbox and click OK.

2.4.3   Site Link Bridges

If you disable BASL you can still bridge site links.  You would do that if you wanted two spoke sites to communicate directly if they could not communicate with the hub site.  In a hub and spoke configuration the cost of crossing to site links (bridging a site link) will typically be a higher then just connecting directly to the hub site.  So, ordinarily you would not have to worry about the Site Link Bridge being used instead of a direct site link.  That being said, there are not a whole lot of scenarios where you would need to create Site Link bridges.

The following steps will allow you to bridge two site links.

Step 1: Open the Active Directory Sites and Services MMC.

Step 2: Expand Sites and then expand Inter-site Transports

Step 3: Select New Site Link Bridge… from the context menu

Add at least two sites to the Site Link Bridge, give it a Name, and click OK

And the Site Link Bridge has been completed.

2.4.4   Verify that all Sites are in a Site Link

Step 1: Run the following command in a PowerShell Console: Get-ADObject –LDAPFilter ‘(objectClass=site)’ –SearchBase (Get-ADRootDSE).ConfigurationNamingContext –Property Name | Format-Table Name

Step 2: In another PowerShell Console run: Get-ADObject –LDAPFilter ‘(objectClass=sitelink)’ –SearchBase (Get-ADRootDSE).ConfigurationNamingContext –Property Name, Cost, Description, Sitelist | Format-List Name, Sitelist

Step 3: Verify that each site that was listed in Step 1 exists in one of the site lists returned in Step 2

If not all sites are contained in a site link that you need to determine what site link that site needs to be added to or if a new site link needs to be created.

And that is all I have for replication troubleshooting for today.

출처 : Troubleshooting Active Directory Replication – xdot509.blog

$user = Import-csv C:\temp\sid.csv

$user | foreach{Get-ADUser -Identity $_.samaccountname -Properties * | Select-Object samaccountname, SID} | Export-Csv C:\temp\s_sid.csv -Delimiter "|" -Encoding Unicode -NoTypeInformation

or 

dsquery * -filter “&(objectcategory=user)(samaccountname=계정)”-attr objectsid sIDHistory

$list = Import-Csv C:\Temp\sam.csv

New-Item -Path C:\Temp -Name sam_check_y.csv -ItemType file -Value ("id" + [Environment]::NewLine)
New-Item -Path C:\Temp -Name sam_check_n.csv -ItemType file -Value ("id" + [Environment]::NewLine)

foreach($user in $list )
 {
       $check_id = $user.id

        $user_yn = (Get-ADGroup -identity "EDGE_Dev@1" -properties Member).Member | Get-ADUser | where-object  {$_.SamaccountName -eq $check_id} | Select-Object samaccountname

        if($user_yn -eq $NULL) {
         $check_id |Add-Content -Path C:\Temp\sam_check_n.csv
         }

         if($user_yn -ne $NULL) {
          $check_id |Add-Content -Path C:\Temp\sam_check_y.csv
          }

}