Category: Active Directory

When you create a domain, all FSMO roles assigned to the first domain controller in the forest by default. You can transfer FSMO roles from one DC to another both the Active Directory graphics snap-ins and the PowerShell command line.

To get FSMO role: netdom query fsmo

Moving FSMO roles using AD PowerShell has the following benefits:

  • You do not need to connect with a MMC snap-ins to the future role owner;
  • Transferring or seizing FSMO roles does not require a connection to the current or future role owner. You can run AD-PowerShell module cmdlets on a Windows 7 client or on a member server running Windows Server (with the RSAT package installed);
  • To seize the FSMO role (if the current owner is not available), it suffices to use an additional parameter -force.
  • Important. After the FSMO roles has been seized, the domain controller from which the roles was seized should never be connected to the domain.

To get the current forest level FSMO role owners (Domain Naming Master and Schema Master roles) you can use the following PowerShell command:


o transfer FSMO roles between Active Directory domain controllers use the PowerShell cmdlet Move-ADDirectoryServerOperationMasterRole.

To use the Move-ADDirectoryServerOperationMasterRole cmdlet, you must meet the following requirements:

  • There must be at least one domain controller with a version of Windows Server 2008 R2 or higher;
  • Installed PowerShell 3.0 or newer;
  • Imported Active Directory module (2.0  or newer).

First of all, you need to load the Active Directory PowerShell module:

import-module activedirectory

Move-ADDirectoryServerOperationMasterRole -Identity "serverdc2" PDCEmulator

To simplify the command, you can replace the names of roles with numbers from 0 to 4. The correspondence of names and numbers is given in the table:

Move-ADDirectoryServerOperationMasterRole “severdc2” –OperationMasterRole 0,1,2,3,4
PDCEmulator 0
RIDMaster 1
InfrastructureMaster 2
SchemaMaster => be sure to be on the schema admins group before ! 3
DomainNamingMaster 4

Important. After the FSMO roles has been seized (-force parameter), the domain controller from which the roles was seized should never be connected to the domain.


Azure AD password protection is now generally available:


Azure AD password protection – how to eliminate bad passwords:



Architecture (to cover also onprem AD domain controllers):






  • A number of organizations use AD FS for SSO capabilities, but all such organizations do not have HA or Site resilience added to AD FS Deployment
  • The Password Sync option can be a great backup solution while AD FS is offline or while you are fixing AD FS problems
    • DirSync is already a core component required for AD FS, just required to enable the Password Sync feature
    • Alternatively, you could have Password Sync enabled running all the time. Does not interfere with SSO
    • During AD FS failure, fallback to Password Sync can be done through couple of methods. But it will takes time (up to 72 hours) to be effective for the users. Those methods must be only enabled in case of Disaster.

Implementation Method1


  • Method 1: Using Set-MsolDomainAuthentication cmdlet
    • This cmdlet is a good temporary option, as it,
      • Does not require AD FS to be online
      • Will only update the settings in Microsoft Online Services
      • Will not remove the Office 365 relying party trust information from AD FS
      • Will not change the User objects (from federated to standard)
    • Process to switch to Password sync:
        • Enable Password Sync (if not already enabled)


    • Set-MsolDomainAuthentication –DomainName <Domain Name> -Authentication Managed
      • Use Get-Msoldomain cmdlet to check if the domain is in mode Managed and not Federated
      • Force full Password sync, if required
    • Revert to AD FS or SSO:
      • Convert-MsolDomainToFederated –DomainName <DomainName> (requires AD FS online)
      • This cmdlet will revert the domain back to Federated, and will re-establish the relying party trust
      • Use Get-Msoldomain cmdlet to check if the domain is in mode Federated and not Managed

Implementation Method 2


  • Method 2: Using Convert-MsolDomainToStandard cmdlet
    • Is good for either temporary or exclusive switch over to Password Sync
      • Requires AD FS to be online
      • Will remove relying party trust information from MFG and on-premises AD FS (cleans-up)
      • Optionally converts Federated users to Standard users (which enables ‘change password’ option for them in portal)
      • Resets and generates temporary passwords for these users (can be overwritten with Password Sync)
      • Limited to process only 1000 user objects (use Convert-MsolFederatedUser or this script for more than 1000 objects)
      • Use Get-Msoldomain cmdlet to check if the domain is in mode Managed and not Federated
    • Process to switch to Password sync:
      • Enable Password Sync (if not already enabled)
      • Convert-MsolDomainToStandard -DomainName <Domain Name> -SkipUserConversion $True or, for permanent switchover that could take two hours, use -SkipUserConversion $false
      • 3. Force full Password sync
    • Revert to AD FS or SSO:

Convert-MsolDomainToFederated –DomainName <DomainName> (requires AD FS online)

      • Use Get-Msoldomain cmdlet to check if the domain is in mode Federated and not Managed

Collection of Web resources about dig usage:

Download dig (part of Bind):

Some commands:

What is the website’s IP address ?

dig +short

How to identify the name servers associated with a domain ?

dig NS +short

What does the delegation path to my zone look like ?

dig +trace

Which Mail Server is responsible for a domain ?

dig MX

Which value is in cache in a given resolver ?

dig @

Which domain name is this IP associated with ?

dig +short -x

Which are the name servers of a TLD ?

dig +short NS nl.

When will the cache of an answer expire ?

dig +noall +answer

Is the zone synchronized to all my NS ?

dig +nssearch

Is a zone existing on this name server ?

dig SOA

Using Dig to Retrieve Different Record Types?

dig srv

How to Troubleshoot Active Directory Replication Issues

In the previous article:

we explained all the methodology to troubleshoot AD replication:

This second article will deep dive with the most well known and out of the box AD utility called REPADMIN.exe

This utility recommended to run as Domain Administrator or Enterprise Administrator.

repadmin /replsummary /bydest

above command summarizes the replication status for all domain controllers based on the replication destination. This parameter does not display the source domain controller.

repadmin /replsummary /bysrc

above command summarizes the replication status for all domain controllers based on the replication source. This parameter does not display the destination domain controller.

repadmin /showrepl

above command shows the replication partners for serverdc1.mydomain.comand the status of last sync attempt.

repadmin /showrepl /errorsonly

above command will list down the replication partners which have replication errors (last sync attempt failed)

we also can view results in CSV format.

repadmin /showrepl /csv

repadmin /syncall serverdc1 dc=mydomain,dc=com

above command initiates domain directory partition synchronization with all replication partners of serverdc1.

It will also indicate if there were any issues by doing it.

repadmin /queue

above command shows if there are any unprocessed inbound replications requests. If system keep que requests it can be due to high number of AD changes, System resource issue or too many replication partners.

repadmin /showchanges serverpdc1 e4f89917-5fff-40a8-scc2-b148b60d9359 dc=mydomain,dc=com

above command list down the changes which are not replicated between server serverpdc1 and serverdc1. In here serverdc1 is the source server and it is listed with object GUID.
repadmin /replicate serverdc1 serverpdc1 dc=mydomain,dc=com

above command initiate immediate directory partition replication from serverpdc1 to serverdc1.

Apart from the repadmin, there are certain PowerShell cmdlets which we can use to troubleshoot replication issues. Get-ADReplicationFailure cmdlet is one of those which can collect data about replication failures.

Get-ADReplicationFailure -Target serverdc1

Above command will collect information about replication failures associated with serverdc1.
This also can do with multiple servers.

Get-ADReplicationFailure -Target serverdc1,serverpdc1

Further we can target all the domain controllers in the domain.

Get-ADReplicationFailure -Target “” -Scope Domain

Or even entire forest

Get-ADReplicationFailure -Target “” -Scope Forest

Get-ADReplicationConnection cmdlet can list down replication partner details for the given domain controller.

Get-ADReplicationConnection -Filter *

Above command will list down all replication connection for the domain controller you logged in.

We also can filter the replication connections based on the attributes.

Get-ADReplicationConnection -Filter {ReplicateToDirectoryServer -eq “serverdc1”}

Above command will list down the replication connections with destination server as serverdc1.
We also can force sync object between domain controllers.

Sync-ADObject -object “foo” -source serverdc1 -destination serverpdc1

Above command will sync user object foo from serverdc1 to serverpdc1

Best practices for DNS forwarding:

To create a conditional forwarder zone in powershell:

read this reference doc:


To create a conditional forwarder zone (stored in the registry of the DNS Server):

Add-DnsServerConditionalForwarderZone -Name “” -MasterServers 2001:4898:7020:f100:458f:e6a2:fcaf:698c, -PassThru

ZoneName                            ZoneType        IsAutoCreated   IsDsIntegrated  IsReverseLookupZone  IsSigned

——–                            ——–        ————-   ————–  ——————-  ——–                         Forwarder       False           False           False


This command creates an Active Directory-integrated conditional forwarder zone for

Add-DnsServerConditionalForwarderZone -Name “” -ReplicationScope “Forest” -MasterServers 2001:4898:7020:f100:458f:e6a2:fcaf:698c,


To change an existing conditional forwarder zone, use the cmdlet:


By default Azure AD connect will synchronize disabled accounts from AD to AAD. It is normal and is it recommended due to Exchange hybrid and EXO requirements.


It is possible to create a custom rule on AD Sync rules editor to not synchronize disabled AD accounts:


AADConnect filtering options

With AAD Connect,

The following filtering configuration types can be applied to the Directory Synchronization tool:

  • Group based: Filtering based on a single group can only be configured on initial install using the installation wizard. It is not further covered in this topic.
  • Domain-based: This option enables you to select which domains will synchronize to Azure AD. It also allows you to add and remove domains from the sync engine configuration if you make changes to your on-premises infrastructure after you installed Azure AD Connect sync.
  • Organizational-Unit–based: This filtering option enables you to select which OUs will synchronize to Azure AD. This option will be on all object types in selected OUs.
  • Attribute–based: This option allows you to filter objects based on attribute values on the objects. You can also have different filters for different object types.

You can use multiple filtering options at the same time. For example you can use OU-based filtering to only include objects in one OU and at the same time attribute-based filtering to filter the objects further. When you use multiple filtering methods, the filters use a logical AND between the filters.

Filtering can be applied both on the inbound from Active Directory to the metaverse and outbound from the metaverse to Azure AD. It is recommended to apply filtering on inbound since that is the easiest to maintain. Outbound filtering should only be used if is required to join objects from more than one forest before the evaluation can take place.

Articles about AAD Connect filtering customization:


When a full synchronization is required?

In general, a full synchronization cycle is required because you have added new attributes to both the Active Directory and Azure AD Connector schemas, and introduced custom synchronization rules or modified the OU filtering.




As we prepare for the migration from on-premises Skype for Business to Skype for Business Online, there are a few important considerations to bear in mind before you take the leap. I will be covering these in a series of posts (hopefully), today I want to share with you a common scenario we will face while preparing for migration.

We are well aware of the pre-requisite for Office 365 that demands an Active Directory synchronised user must have a publically routable User Principal Name (UPN). So critical is this requirement that it is now engrained in every consultant’s mind and increasingly customers are becoming more aware of this without us even mentioning it. However, this can often produce its own unique challenges.

Many organisations set their users up with an ambiguous username, something that does not immediately identify a user by name e.g. rather than This is to avoid name conflicts and was often used as an additional domain security measure. When a user is synchronised to Office 365 their UPN is used to provision the identity and service addresses for Exchange and Skype for Business. Often the case is that users UPNs do not match their publically available contact information such as their e-mail address. E-mail addresses are usually more personable to each users and contain their true identity e.g In order to integrate Skype for Business Online with Exchange properly it is important that the user’s SIP address matches their primary e-mail address i.e. and not

However, when you perform an AD Sync with Office 365 the user’s Skype for Business Online identity is provisioned using the UPN like so:

On-premises Identity (UPN =

Synchronised Identity in Office 365 Portal also

PowerShell output showing primary SIP Address in Skype for Business Online

In order to change this, the solution is to look and edit the on-premises identity, as this is the source of authority for this person’s cloud identity. Specifically, we need to modify an attribute on the user’s Active Directory account called msRTCSIP-PrimaryUserAddress. In order to find this attribute, your on-premises Active Directory domain is required to be prepared for Lync / Skype for Business On-premises. Therefore, you may need to download the on premises software and run AD schema preparation to have this property available. I say may read on.

First change find and change this attribute

Click on edit and enter the desired address in this format:

Perform directory synchronisation using AADSync and then check the SIP Address of the online identity. You should see that is has changed

Please note that this only works for synchronised identities. Cloud identities must be provisioned with the primary SIP address as the username.

If you have not prepared your Active Directory domain from on-premises Lync / Skype for Business and do not have the msRTCSIP-PriamryUserAddress attribute, there is an alternative method you can use. Instead we can use the ProxyAddresses attribute that is natively part of Active Directory. This attribute is the same on you use for provisioning e-mail addresses to get around the same issue as we have. Open the ProxyAddressess attribute and add a new Proxy Address into the list using the following format:

Perform a directory synchronisation and test the SIP address has been updated correctly




Other references: