In order to manage Azure AD, we use Azure Active Directory option in https://portal.azure.com. By default, any user under Azure AD can access this option event they do not have a Directory role. In my demo setup, I have a user called "Emily Braun". She doesn't have any Directory role assigned. 

Then I log in to Azure portal https://portal.azure.com as the user and then go to Azure Active Directory option. It didn't block me accessing it. 

I can go to All users and see user account details. 

I even can see the Groups memberships details. 

Also, can view application assignments. 

As an end user I also can see the Azure AD Connect details. 

In one of my previous post I explained how we can manage AD administration privileges using ACLs. If you didn’t read it yet you can find it using http://www.rebeladmin.com/2018/02/step-step-guide-manage-active-directory-permissions-using-object-acls/

This Delegate Control method also works similar to ACLs, but its simplified the process as its uses,

• Delegation of Control Wizard which can use to apply delegated permissions. 

• Allows to use predefined tasks and assign permission to those

The Wizard contain following predefined tasks which can use to assign permissions. 

• Create, delete, and manage user accounts

• Reset user passwords and force password change at next logon

• Read all user information

• Create, delete and manage groups

• Modify the membership of a group

• Manage Group Policy links

• Generate Resultant Set of Policy (Planning)

• Generate Resultant Set of Policy (Logging)

• Create, delete, and manage inetOrgPerson accounts

• Reset inetOrgPerson passwords and force password change at next logon

• Read all inetOrgPerson information

This also allows to create custom task to delegate permissions, if it’s not covered from the common task list. 

Similar to ACLs, Permissions can apply in,

1) Site – Delegated permission will valid for all the objects under the given Active Directory Site. 

2) Domain – Delegated permission will valid for all the objects under the given Active Directory Domain. 

3) OU – Delegated permission will valid for all the objects under the given Active Directory OU.

As an example, I have a security group called Second Line Engineers and Scott is a member of it. I like to allow members of this group to reset password for objects in OU=Users,OU=Europe,DC=rebeladmin,DC and nothing else. 

1) Log in to Domain Controller as Domain Admin/Enterprise Admin

2) Review Group Membership Using 

Get-ADGroupMember “Second Line Engineers”

3) Go to ADUC, right click on the Europe OU, then from list click on “Delegate Control”

4) This will open new wizard, in initial page click Next to proceed. 

5) In next page, Click on Add button and add the Second Line Engineers group to it. Then click Next to proceed.

6) From the task to delegate window select Delegate the following common tasks option and from list select Reset user passwords and force password change at next logon. In this page, we can select multiple tasks. If none of those works, we still can create custom task to delegate. Once completes the selection, click next to proceed. 

7) This completes the wizard and click on Finish to complete. 

8) Now it’s time for testing. I log in to Windows 10 computer which has RSAT tools installed as user Scott. 

According to permissions, I should be able to reset password of an object under OU=Users,OU=Europe,DC=rebeladmin,DC

Set-ADAccountPassword -Identity dfrancis

This allows to change the password successfully. 

However, it should not allow to delete any objects. we can test it using,

Remove-ADUser -Identity "CN=Dishan Francis,OU=Users,OU=Europe,DC=rebeladmin,DC=com"

And as expected, it returns access denied error. 

This marks the end of this blog post. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

Users or groups access and permissions to a shared folder is controlled by its Access Control List (ACL). Similar way we can define permissions to Active Directory Objects. This can apply to individual object or apply to AD Site/Domain/OU and then inherit to lower level objects. 

As an Example, I have a security group called “First Line Engineers” and Liam is a member of this group. Liam is engineer of Europe office. In active directory environment, he should allow to add user objects under any sub OU in “Europe” OU. But he should not be allowed to delete any object under it. Let’s see how we can do it using ACLs. 

1) Log in to Domain Controller as Domain Admin/Enterprise Admin

2) Review Group Membership Using 

Get-ADGroupMember “First Line Engineers”

3) Go to ADUC, right click on the Europe OU and click properties. Then go to Security tab.

4) In security tab, click on Add 

5) In the new window, type First Line Engineers and click Ok. After, In Security Tab, select First Line Engineers and click on Advanced

6) In next window, select the First Line Engineers from the list and click on Edit

7) From Applies to list select “This object and all descendant objects”. Then it will apply permission to all child objects. 

8) Under the Permissions section, tick Create All child objects and click Ok. 

9) Then keep clicking Ok until all permission window closed. 

10) Then I log in to Windows 10 computer which has RSAT tools installed as user Liam. 

11) According to permissions, he should be able to add user account under Europe OU. 

New-ADUser -Name "Dale" -Path "OU=Users,OU=Europe,DC=rebeladmin,DC=com"

This successfully add the user. Let’s see if we can add another user on different OU. 

New-ADUser -Name "Simon" -Path "OU=Users,OU=Asia,DC=rebeladmin,DC=com"

And as soon as I run it, I gets access denied error. 

According to applied permissions, I should not be able to delete any object under OU=Users,OU=Europe,DC=rebeladmin,DC=com either. Let’s check it using, 

Remove-ADUser -Identity "CN=Dishan Francis,OU=Users,OU= Europe,DC=rebeladmin,DC=com"

And as soon as I run it, I gets access denied error. 

As above confirms we can manage permissions for AD management tasks in granular level. 

This marks the end of this blog post. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

When we talk about active directory we refer it as one service but AD DS attached to many other components as well. DNS, Group Policies, SYSVOL replication are few example for this. Each of these components need to operate well in order to run healthy active directory environment. It doesn’t come easy, its involve with investment on resources, time and skills. In Active Directory Service, the core values are centralized identity management, authentication and authorization capabilities. All these extra components make it easy to archive its core values but same time it also opens up risks such as dependencies and security. Failure or compromise of these components/service will make impact on entire active directory infrastructure. 

Microsoft Windows Core and Nano Servers also count as “Operating Systems”. These doesn’t have fancy GUIs, sparkly applications running. But it is still doing the job of operating system. It allows users to build it from scratch according to their requirements. It also increases the server up time (less updates), reliability, performance and security. Soon after Microsoft releases the First Active Directory version, there were conversation start specially from application developers by requesting a version with pure LDAP capabilities. They wanted to element all these dependencies and management requirements, so they can focus on application development upon core AD functions. After windows server 2003, Microsoft releases Active Directory Application Mode (ADAM) which allowed administrators to run “cut down” version of active directory without group policies, Kerberos, file replication etc. It can run on desktop computer or member server similar to any other windows service. Same time it was providing all core values of Active Directory Service. With Windows server 2008, Microsoft renamed it to “Active Directory Lightweight Directory Services” and allow to install the role using Server Manager. This version provided more control and visibility to administrators to deploy and managed LDS instances. This was continued with all the AD DS versions after that and included in windows server 2016 too. 

LDS installation 

In Windows server 2016 Operating system, it can install using Server Manager. in order to install LDS, User need to log in with local administrator privileges. 

Once log in to the Server Manager, click on Add Roles and Features. Then follow the wizard and select Active Directory Lightweight Directory Services under server roles and proceed with the enabling the role. 

Once the role is installed, click on Post-Deployment Configuration wizard in Server Manager. LDS can setup two way. One is as a unique instance and other one as a replica of an existing instance. Replica option is similar to clone copy of an existing instance. This is useful especially in development environment where engineers can maintain number of application versions. 

In next window, we can define name and description for the LDS instance. 

In next window, we can define the LDS port. By default, LDAP port is set to 389 and SSL port is set to 636. if you running multiple instance these can be change accordingly. 

After that, we can create application directory partition. This allows applications to use this partition as data repository to store application related data. If application is capable of creating partition this step is not necessary and can create relevant partition during the application deployment process. When defining the application partition name, it need to provide as distinguished name format. 

Next step is to define location to store LDS data files. After that it gives option to specify service account for LDS. If its workgroup environment you can use network service account or local user account for it. if its domain environment it can be AD user account.

After that we need to define AD LDS administrator account. By default, it selects the user account that used for the installation. If needs it can change to different account or group.

Once we define the administrator account, next step is to define which LDIF file to import. It is a text file which represent data and commands which will use by LDAP instance. It can contain one or more LDIF files. These files are depending on application requirements.  As example if its users’ functionalities the relevant file will be MS-User.LDF.

This will complete the AD LDS installation and once it completed we can create relevant object and manage them. There is two way to connect to it. one way is to connect using ADSI edit tool. 

LDS objects also can manage using PowerShell cmdlets. It is same commands which users for AD DS and only difference is to define the DN and Server. 

New-ADUser -name “tidris” -Displayname “Talib Idris” -server ‘localhost:389’ -path “CN=webapp01,DC=rebeladmin,DC=com”

The above command will create user account called tidris on local LDS instance runs on 389. Its DNS path is “CN=webapp01,DC=rebeladmin,DC=com”

Get-ADUser -Filter * -SearchBase "CN=webapp01,DC=rebeladmin,DC=com" -server ‘localhost:389’ 

Above command going to list all the user accounts in LDS instance CN=webapp01,DC=rebeladmin,DC=com

AD LDS also can install in desktop operating system using windows features option under Program and Features. The installation steps are similar to server version. once enabled the feature, the setup wizard can find under Administrative Tools. 

This marks the end of this blog post. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

Once object is added to a domain controller, it needs to replicate to all other domain controllers. otherwise users will face issues on login, using AD integrated application and services etc. The replication is depending on many different facts such as replication schedule, intra site connectivity. However sometime it is required to force the replication between domain controllers for fast results. Following script can use to replicate a object from one DC to another forcefully. 

## Replicate Object to From Domain Controller to Another ##

$myobject = Read-Host 'What is your AD Object Includes?'

$sourcedc = Read-Host 'What is the Source DC ?'

$destinationdc = Read-Host 'What is the Destination DC ?'

$passobject = (Get-ADObject -Filter {Name -Like $myobject})

Sync-ADObject -object $passobject -source $sourcedc -destination $destinationdc

Write-Host "Given Object Replicated to" $destinationdc

Above script will ask for few questions, 

1) Name of Object – This no need to be DN. All need is text included in object Name field

2) Source DC – Hostname of Source DC

3) Destination DC – Hostname of Destination DC

Once relevance info provided, the object will be replicated forcefully. 

This marks the end of this blog post. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

Item-level targeting can use to target group policy preference settings based on application settings and properties of users and computers in granular level. we can use multiple targeting items in preference settings and make selections based on logical operators (AND, OR, IS, IS NOT).

Item-level targeting in group policy preferences can setup/manage using GPMC. To do that open the group policy settings > Go to relevant Preference settings > right click and select properties 

In my example I am using GPO created for IE 10 Settings, there for the path for it is User Configuration > Preferences > Internet Settings > Internet Explorer 10. Then right click and select properties. 

From properties window, then select Common tab > tick item-level targeting > then click on Targeting button. 

In next window, we can build granular level targeting based on one item or multiple items with logical operators. 

In above example I have built a query based on three setting which is NetBIOS name, Operating System and IP address. In order to apply the preference setting, all three statements should give TRUE value as result as I used AND logical operator. If its OR logical operator the result can have True or False values. 

In the window, New Item menu contained items we can use of targeting. Add Collections allows to create parenthetical grouping. Item Options menu is responsible for defining logical operators. 

WMI Filters is another way of targeting objects in group policies. We will look in to it in next blog post. 

This marks the end of this blog post. Hope this was useful. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

In one of my previous blog posts I talked about managed service accounts. Before start on this I really recommend you to read it to have better understanding. It can find on http://www.rebeladmin.com/2018/01/active-directory-managed-service-accounts-powershell-guide/ . As I explained in there one managed service account only can use with one computer. But there are operation requirements which required to share same service account in multiple hosts. Microsoft network load balancer, IIS server farms are good example for these. All the hosts in these server groups required to use same service principal for authentications. Group Managed service accounts provides the same functionalities as managed service accounts but its extend its capabilities to host group levels. This is first introduced with windows server 2012. 

Group managed service accounts got following capabilities,

• No Password Management 

• Supports to share across multiple hosts

• Can use to run schedule tasks (Managed service accounts do not support to run schedule tasks)

• It is uses Microsoft Key Distribution Service (KDC) to create and manage the passwords for the gMSA. 

Key Distribution Service was introduced with the windows server 2012. KDS shares a secret (root Key ID) among all the KDS instance in the domain. This value will change periodically. When gMSA required a password, windows server 2012 domain controller will be generated password based on common algorithm which includes root key ID. Then all the hosts which shares the gMSA will query from domain controllers to retrieve the latest password. 

Requirements for gMSA

• Windows server 2012 or higher forest level

• Widows server 2012 or higher domain member servers (Windows 8 or upper domain joined computers also supported)

• 64-bit architecture to run PowerShell command to manage gMSA

Tip – gMSA not supported for the Failover Clustering setup. But it is supported for services which is run upon Failover clusters. 

In order to start the configuration process, we need to create KDS root key. This need to run from domain controller with domain admin or enterprise admin privileges. 

Add-KdsRootKey –EffectiveImmediately

Once this is executed, it has default 10 hours’ time limit to replicate it to all the domain controllers and start response to gMSA requests. In testing environment with one domain controller, it can force to remove this waiting time and start to response gMSA immediately. This is NOT recommended for production environment. 

Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

After that we can create the first gMSA account. First I have created an AD group “IISFARM” and add all my IIS servers to it. This farm will be using the new gMSA account. 

New-ADServiceAccount "Mygmsa1" -DNSHostName "web.rebeladmin.com" –PrincipalsAllowedToRetrieveManagedPassword "IISFARM"

In above Mygmsa1 is the service account and web.rebeladmin.com is the FQDN of the service. Once its processed we can verify the new account using,

Get-ADServiceAccount “Mygmsa1”

Next step is to install it on server in IIS Farm. It needs active directory PowerShell module to run it. It can be install using RSAT. 

Install-ADServiceAccount -Identity "Mygmsa1"

Tip – If you created the server group recently and add the host, you need to restart the host computer to reflect the group membership. Otherwise above command will fail. 

Once its executed we can test the service account by running,

Test-ADServiceAccount " Mygmsa1"

Similar to managed service account, when you configure the gMSA with any service, leave the password as blank. 

Uninstall Service Account

There can be requirements to remove the managed service accounts. This can be done by executing, 

Remove-ADServiceAccount –identity “Mygmsa1”

Above command will remove the service account Mygmsa1. This is applying to both type of managed service accounts. 

This marks the end of this blog post. Hope this was useful. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts. 

Active Directory Infrastructure is depending on healthy replication. Every domain controller in the network should aware of every change which has made. When domain controller triggers a sync, it passes the data through the physical network to the destination.

In active directory environment, there are mainly two types of replications.

1) Intra-Site Replication 

2) Inter-Site Replication

Intra-Site Replication

As the name confirms, this covers the replication happens with in a site. By default, (according to Microsoft) any domain controller will aware of any directory update within 15 seconds. Within site despite the number of domain controllers, any directory update will be replicate in less than one minute. 

Within the site, the replication connections are performing in ring topology. Which mean an any give domain controller have two replication links (of cause if there is minimum of three domain controllers). this architecture will prevent domain controllers having endless replication loops. As example if there are 5 domain controllers and if all are connected to each other with one-to-one connection each domain controller will have 4 connection and when there is an update in one of the domain controller it will need to advertise it to 4 domain controllers. then the first one to receive update will advertise to its 4 connected domain controllers and its go on and on. It will be too much replication processes to advertise, listen and sort out the conflicts. But in ring topology, despite the number of domain controllers in the site, any given domain controller only need to advertise or listen to two domain controllers in any given time. This replication topology is no need to configure manually and active directory will automatically determine the connections it need to make. When number of domain controllers grow, the replication time can grow as well as its in ring topology. But to avoid the latency active directory will create additional connections. This is also determined automatically and we do not need to worry about these replication connections. 

Inter-Site Replication

If active directory infrastructure contains more than one site, a change happens in one site need to replicate over to other sites. This is called as inter-site replication and its topology is different from the intra-site replication. Replication with in site is always benefited from the high-speed links. But when it comes to between sites bandwidth, latency and reliability comes to considerations. In previous section, we discussed about site-links, site costs and replication schedules when we can use to control the inter-site replication. 

When it comes to inter-site, the replication will happen via site links. The replication with in each site still uses the ring topology. In above example let’s assume an object been added to REBEL-DC-02 in London Site. Now based on the topology it will be advertise to REBEL-DC-03 too. But apart from been domain controller, this particular domain controller is bridgehead server as well. So, it is this server’s responsibility to advertise the updates it received in to the bridge server in Canada Site which is REBEL-DC-04. Once it receives the update it will advertise to other domain controllers in the site. The replication between sites still need to obey the rules which is applied to control the replication. Active Directory domain services automatically selects the bridgehead server for a site. But if need we can decide what should act as bridgehead server for site. 

This marks the end of this blog post. Hope this was useful. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

There are few ways to create user objects in Active Directory. If it’s using GUI, it can be done using Active Directory Administrative Center or Active Directory Users and Computers MMC. If it is using command line, it can be done using windows command-line or PowerShell. In this demo, I am going to show how we can create user object using PowerShell. 

In order to create user object in active directory we can use New-ADUser cmdlet in PowerShell. You can view the full syntax for the command along with the accepted data types using,

Get-Command New-ADUser -Syntax

In order to create a New User account using PowerShell the minimum value you need to pass is -Name. it will create a disabled user account and you still can define values for other attributes later. 

This is a sample which can use to create a user account,

New-ADUser -Name "Talib Idris" -GivenName "Talib" -Surname "Idris" -SamAccountName "tidris" -UserPrincipalName "tidris@rebeladmin.com" -Path "OU=Users,OU=Europe,DC=rebeladmin,DC=com" -AccountPassword(Read-Host -AsSecureString "Type Password for User") -Enabled $true

In the command,

Name – Defines the Full Name

Given Name – Defines the First Name

Surname – Defines the Surname

SamAccountName – Defines the User Name

UserPrincipalName – Defines the UPN for the user account

Path – Defines the OU path. The default location is “CN=Users,DC=rebeladmin,DC=com”

AccountPassword – This will allow user to input password for the user and system will convert it to the relevant data type

Enable – defines if the user account status is enabled or disabled. 

You can create a user account with minimum attributes such as Name and UPN. Then later can define a password and enable the account. User account cannot enable without a password. To define password can use Set-ADAccountPassword -Identity cmdlet and to enable account can use Enable-ADAccount -Identity cmdlet. 

 

Instead of executing multiple commands to create multiple user objects, we can create a CSV (comma-separated values) file which include data for attributes and use it to create accounts in one go. 

 

In demo I am using following CSV file. 

 

Import-Csv "C:\ADUsers.csv" | ForEach-Object {

$upn = $_.SamAccountName + “@rebeladmin.com” 

New-ADUser -Name $_.Name `

 -GivenName $_."GivenName" `

 -Surname $_."Surname" `

 -SamAccountName  $_."samAccountName" `

 -UserPrincipalName  $upn `

 -Path $_."Path" `

 -AccountPassword (ConvertTo-SecureString “Pa$$w0rd” -AsPlainText -force) -Enabled $true

}

 

In above script Import-Csv cmdlet used to import the CSV file created. I have defined parameter $upn = $_.SamAccountName + “@rebeladmin.com” to use for the  -UserPrincipalName value. In script, I have defined a common password for all the accounts using -AccountPassword (ConvertTo-SecureString “Pa$$w0rd” -AsPlainText -force) 

 

 

This marks the end of this blog post. Hope this was useful. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

This is my first blog post in 2018. So, first of all Happy New year to my blog readers!

In many occasions, I have written articles about Active Directory Migrations. But still I get lots of emails from readers to clarify things about AD migrations. So, I thought to revisit it by covering most common questions I gets. Also in this blog post, I will show how to do the AD migration only using PowerShell.

Migration task itself is very straight forward. But there are other things you need to consider before you do an AD migration. In below I listed a checklist you can use in many occasions. 

Active Directory Migration Check List 

 Evaluate business requirement for active directory migration 

 Perform Audit on Existing Active Directory Infrastructure to verify its health status

 Create Plan for implementation Process

 Prepare Physical / Virtual resources for Domain Controller

 Install Windows server 2016 Standard / Datacenter

 Patch Servers with latest Windows Updates

 Assign Dedicate IP address to Domain Controller

 Install AD DS Role

 Migrate Application and Server Roles from the Existing Domain Controllers

 Migrate FSMO roles to new Domain Controllers

 Add New Domain controller to the Existing DR Solution

 Decommission old domain controllers 

 Raise the Domain and Forest Functional level

 On Going Maintenance 

Tips – During audit process you need to verify if your applications will support new AD schema. it is very rare but I have seen legacy applications which is not support newer schema versions. 

 

Also in some scenarios, it is hard to replace primary dc with a DC running with different IP address. AD is supported for IP changes even after FSMO role changes. There for if need you can swap IP addresses after you migrate FSMO roles. 

 

Topology

 

In my demo environment, I have an existing domain controller running with windows server 2012 R2. I am going to migrate it to a windows server 2016 server.

 

 

In the demonstration, REBEL-WIN-DC01 is the domain controller with windows server 2012 R2 and REBEL-SDC01 is the domain controller with windows server 2016. 

 

Tip – When you introduce new domain controllers to the existing infrastructure it is recommended to introduce to the forest root level first and then go to the domain tree levels.

 

Add Additional Domain Control 

 

As per plan I need to add a new domain controller with windows server 2016 to existing domain first.

 

1) Log in to the Server (Windows server 2016) as a member of local administrators group. 

2) Add server to the existing domain as member. 

3) Log in to domain controller as enterprise administrator.  

4) Verify the static IP address allocation using ipconfig /all.

5) Launch the PowerShell Console as an Administrator

6) Before the configuration process, we need to install the AD DS Role in the given server. In order to do that we can use Following command. 




Install-WindowsFeature –Name AD-Domain-Services -IncludeManagementTools

 

7) After successful role service Installation, next step is to configure the domain controller. It can be done using following PowerShell command. 

 

Install-ADDSDomainController

-CreateDnsDelegation:$false

-InstallDns:$true

-DomainName "rebeladmin.com"

-SiteName "Default-First-Site-Name"

-ReplicationSourceDC "REBEL-WIN-DC01.rebeladmin.com"

-DatabasePath "C:\Windows\NTDS"

-LogPath "C:\Windows\NTDS"

-SysvolPath "C:\Windows\SYSVOL"

-Force:$true 

Once execute the command it will ask for SafeModeAdministrator Password. Please use complex password to proceed. This will be used for DSRM.

 

After configuration completed, restart the system and log back in as administrator to check the AD DS status. 




Get-Service adws,kdc,netlogon,dns

 

Move FSMO Roles 

 

Now we have additional domain controller and next step is to migrate FSMO roles to the new server. 

 

We can migrate all five FSMO roles to the New domain controller using following powershell command,

 

Move-ADDirectoryServerOperationMasterRole -Identity REBEL-SDC01 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster

 

In above the REBEL-SDC01 is domain controller running with windows server 2016. Once its completed, we can verify the new FSMO role holder using 

 

Netdom query fsmo

 

Decommission Old Domain Controller 

 

Now we moved FSMO roles over and next step is to decommission old DC which is running with windows server 2012 R2. 

In order to do that, log in to old DC as enterprise administrator and run following powershell command,




Uninstall-ADDSDomainController -DemoteOperationMasterRole -RemoveApplicationPartition

 

After execute the command it will ask to define password for the local administrator account.

 

 

Once its completed it will be a member server of the rebeladmin.com domain.

 

Raise Domain and Forest Functional level

After you remove your last domain controller running with windows server 2012 r2 (if its 2012 or 2008 r2 same thing apply) we can raise Domain and Forest Functional level to windows server 2016. You need it to have features comes with AD 2016. 

To upgrade domain functional level, you can use following powershell command

 

Set-ADDomainMode –identity rebeladmin.com -DomainMode Windows2016Domain

 

To upgrade forest function level, you can use following command




Set-ADForestMode -Identity rebeladmin.com -ForestMode Windows2016Forest

 

After the migration completes we still need to verify if its completes successfully.

 

Get-ADDomain | fl Name,DomainMode

 

This command will show the current Domain functional level of the domain after the migration. 

 

Get-ADForest | fl Name,ForestMode

 

Above command will show the current forest functional level of the domain. 

Also, you can use

 

Get-EventLog -LogName 'Directory Service' | where {$_.eventID -eq 2039 -or $_.eventID -eq 2040} | Format-List

 

To search event ID 2039 and 2040 in the “Directory Service” log which will show the forest and domain functional level updates.

 

 

Event ID 1458 will verify the transfer of the FSMO roles. 




Get-EventLog -LogName 'Directory Service' | where {$_.eventID -eq 1458} | Format-List

 

You can use following to verify the list of domain controllers and make sure the old domain controller is gone. 

 

Get-ADDomainController -Filter * | Format-Table Name, IPv4Address

 

Apart from these you also can go through Directory Service and DNS Logs to see if there’s any issues recorded.

 

This marks the end of this blog post. Hope this was useful. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.