Active Directoy Active Directory Auditing Tool https://www.manageengine.com/products/active-directory-audit/account-management-events/event-id-4729.html Event ID 4729 - A member was removed from a security-enabled global group Event ID 4729 Category Account management Sub category Security group management Description A member was removed from a security-enabled global group When Active Directory objects such as an user/group/computer is removed from a security group, event ID 4729 gets logged.  This log data gives the following information: Subject: User who performed the action Security ID Account Name Account Domain Logon ID Member: Object removed from the security group Security ID Account Name  Group: Security group from which the object was removed Security ID Group Name Group Domain Additional Information Privileges Why event ID 4729 needs to be monitored? Prevention of privilege abuse Detection of potential malicious activity Operational purposes like getting information on user activity like user attendance, peak logon times, etc. Compliance mandates Pro tip: ADAudit Plus audits, reports, and alerts group management actions performed on distribution and security groups making Active Directory auditing much easier.  Event 4729 applies to the following operating systems:  Windows Server 2008 R2 and Windows 7 Windows Server 2012 R2 and Windows 8.1 Windows Server 2016 and Windows 10 Corresponding event ID for 4729 in Windows Server 2003 and older is 633 Active Directory: Add a Domain Controller to PowerShell https://247-it.io/en/active-directory-add-a-domain-controller-to-powershell/#:~:text=Domain%20Controller%20Promotion%20in%20PowerShell,-Always%20from%20a&text=Enter%20the%20password%20of%20the,Wait%20during%20the%20promotion%20operation%20%E2%80%A6 . Active Directory: Add a Domain Controller to PowerShell Table Of Contents Introduction Prerequisites Installing the ADDS role in PowerShell Domain Controller Promotion in PowerShell Complements Introduction In this tutorial, we will see how to add an Active Directory domain controller to an existing domain using PowerShell. To do this through the GUI, I invite you to read this article:  Add an AD DS Domain Controller to an Existing Domain.  (fr) Adding a domain controller to PowerShell is done in two command lines, which saves time…. Prerequisites On the server that is going to be promoted domain controller, it is necessary: A fixed IP address. Configure an existing domain controller as a DNS server on the network adapter. Make sure the ping of the domain name answers. Dans le cas d’ajout où vous ajoutez un contrôleur de domaine sur une autre plage IP et que vous en novice, je vous conseille avant la lecture du l’article pour le faire en mode graphique et l’article suivant :  Active Directory : configuration multi sites, sous réseau et réplication . Installing the ADDS role in PowerShell From a Powershell command prompt launched as administrator enter: Install-WindowsFeature AD-Domain-Services -IncludeManagementTools Wait during the installation …. The AD DS role is installed: Domain Controller Promotion in PowerShell Always from a Powershell command prompt enter: Install-ADDSDomainController -DomainName "domain.tld" -InstallDns:$true -Credential (Get-Credential "DOMAIN\administratreur") Enter the password of the account passed as a parameter in the login window, then in the Powershell console enter the password of the directory recovery mode and confirm the promotion as a domain controller. Wait during the promotion operation …. After the operation completes, the following message appears and the server restarts. At reboot the server is domain control. Complements There are 3 different Powershell commands that allow promotion as a domain control. Each of the commands is to be used in a particular case: Install-ADDSForest  : which is used for creating a new Active Directory forest. Install-ADDSDomain  : which is used to create a domain in an Active Directory forest ( adding a child domain ). Install-ADDSDomainController  : which is used to add an Active Directory domain controller to an existing domain. Add a domain to the Active Directory https://lazyadmin.nl/it/add-a-domain-to-the-active-directory/ How to add a domain to the Active Directory Login to your domain controller   Open the “Active Directory Domains and Trusts”   Open the Properties of Active Directory Domains and Trusts Right-click on the top item in the left tree view and select properties Add the new Domain Name In the UPN Suffixes dialog, enter the new domain name in the “ Alternative UPN Suffixes ” field and click on  Add Apply the settings Click Apply and close the windows. The domain is now added to the domain controller. (optional) for replication to other domain controllers If you have multiple domain controllers you can force the replication with the following command in PowerShell / CMD:  repadmin /syncall /AdeP You should now be able to use the new domain name in the Active Directory or in the Exchange Administration Center. Add a Mapped Drive to a User Profile Using GPO Log into the Group Policy Management console Create a new group policy and link it to the OU as needed Using Security Filtering remove all group from the filter. Then add back the single group that was used to assign File Permissions Right click the GPO and select the Edit option Navigate to User Configuration > Preferences > Windows Settings > Drive Maps Right click and select create a new drive map Under the action tab set to update when creating a new drive map or when updating an existing map Under location set the full network path of the network share Check the reconnect box Label the drive with whatever you wish For drive letter, best practice is to use the same drive letter every time. Select something not likely to be taken by something else. Select OK to save the drive map Close the GPO editor Run a Gpupdate /force on the client computers The new network drive should appear in the file explorer Add all users in OU to security group While working on figuring out how to add all of RS domestic to a security group quickly, developed this powershell script.   It will quickly add all the users in the listed OU to the specific security group listed.         Import-Module ActiveDirectory   $ou = "OU=RHSC,DC=RHSC,DC=local"   $grp = "SafetySite-Read"   Get-ADUser -SearchBase $ou -Filter * | ForEach-Object {Add-ADGroupMember -Identity $grp -Members $_ }                 #see who is not a member of a security group within an OU     $ou = "OU=RHSC,DC=RHSC,DC=local"   $grp = "RSHub-Read"   $results = @()   $users = Get-ADUser  -SearchBase $ou  -Properties memberof -Filter *    foreach ($user in $users) {   $groups = $user.memberof -join ';'   $results += New-Object psObject -Property @{'User'=$user.name;'Groups'= $groups}   }   $results | Where-Object { $_.groups -notmatch $grp } | Select-Object user     Add Extension Attribute to User Description This article will detail how to add an extension attribute to a user that will allow them to access the dynamic Sharepoint security groups Resolution Domain Controller - Active Directory Users and Computers Enable View -> Advanced Features Attribute Editor -> "extentionAttribute1" The following powershell command can be used on a Domain Controller First we run this command to check the current extensionattribute1 value. You do not want to overwrite that, but add to it. Get-ADUser -Identity $User -Properties extensionAttribute1 For example, the command might return the user has Williams Winterset Albion already as extension attributes Run this command to set the new attribute string, including what was already done Set-ADUser –Identity $User -add @{"extensionattribute1"="MyString"} Finally run "Get-ADUser -Identity $User -Properties extensionAttribute1" one last time to confirm ADSI Purge (&(Name=WHCC-01-VSRV03*))   (&(Name=LAFAD01*))                     Clean Up Server Metadata   Change Windows Desktop Background Using Group Policy How to Change Windows Desktop Background Using Group Policy This demonstration is using a Windows Server 2012 R2 as the Domain Controller and a Windows 7 Ultimate as the client machine. The topology is as follows: Details: Active Directory  and  Domain Name Service (DNS)  has been configured already Client machine has been  joined to the domain Policy will be applied at the user level Wallpaper image file is stored in the local drive of the Domain Controller server Target username is “Arranda Saputra” resides within an OU named “MustBeGeek” with structure as shown below: Follow the step by step below to set wallpaper using  Group Policy : 1. Creating the Group Policy Object On the Group Policy Management console, expand the forest and domain, right click on  Group Policy Objects  and select  “New” Give name for the new policy object. In this example, the policy name is  “Wallpaper Policy” 2. Editing the policy object The newly created policy will be listed on the Group Policy object list. Right click on it and select  “Edit” An editor window will show up. On the left pane, go to  User Configuration > Administrative Templates > Desktop > Desktop . On the right pane, double click on  Desktop Wallpaper  setting. Change the option to  Enabled , and then specify the  wallpaper location  and the  wallpaper style . In this example we are specifying a local path because the image file for desktop wallpaper background is stored in the local drive of the Domain Controller server, and the wallpaper style that we used is  “Fill” . Once configured, click  OK  and close the editor window. 3. Applying the policy object Back to the Group Policy Management console window, right click on “MustBeGeek” OU and select  “Link an Existing GPO” Select the  Wallpaper Policy  and click  OK. Verify that  Wallpaper Policy  is now listed under the “MustBeGeek” OU 4. Check the result on client machine Once the client machine has received the policy update, the wallpaper will changed. Policy update is a process that happens periodically in the background so it doesn’t require any action from the user. However, in this demonstration we want to expedite the process so we will force the policy update to run right away by opening CMD and use command  gpupdate /force . To verify the policy has been applied, user can run command  gpresult /r  on the CMD. Find the policy named “Wallpaper Policy” under section “Applied Group Policy Objects”. After the policy applied, notice that the desktop background wallpaper has been changed. Conclusion With Desktop Wallpaper Group Policy, desktop background will be consistent for all targeted users and cannot be changed unless it is configured via the Group Policy. Sometimes, if the client machine is running Windows 7 or Windows Server 2008 R2, the Desktop Wallpaper Group Policy setting cannot be applied correctly (either background does not change or just goes to blank). When it happens, install this hotfix on the client machine:  http://support.microsoft.com/kb/977944 . And that’s how you change Windows desktop background using Group Policy. Checking Active Directory Domain Controller Health and Replication https://woshub.com/check-active-directory-health-and-replication/ How to Check AD Domain Controller Health Using Dcdiag? Dcdiag is a basic built-in tool to check Active Directory domain controller health. It must always be run on an Admin Command Prompt To quickly check the state of an AD domain controller, use the command below: dcdiag /s:DC01 The command runs different tests against the specified domain controller and returns a state for each test ( Passed / Failed ). Typical tests: Connectivity  – checks if the DC is registered in DNS, establishes test LDAP and RPC connections; Advertising  – checks roles and services published on the DC; FRSEvent  – checks if there are any errors of file replication service (SYSVOL replication errors); FSMOCheck  – checks if the DC can connect to KDC, PDC, and Global Catalog server; MachineAccount  — checks if the DC account is registered in AD correctly and if the  domain trust relationship  is correct; NetLogons  – checks the logon privileges to allow replication to proceed; Replications  – checks the state of replication between domain controllers and if there are any errors; KnowsOfRoleHolders  – checks the availability of the domain controllers with  FSMO roles ; Services  – checks if services on the domain controllers are running; Systemlog  – checks if there are any errors in the DC logs; Etc. You can find a full description of all available dcdiag tests  here . Besides default tests, you can run additional domain controller checks: Topology  – checks if KCC has generated full topology for all DCs CheckSecurityError CutoffServers  – finds a DC that is not replicated since its partner is unavailable DNS  – 6 DNS checks are available ( /DnsBasic ,  /DnsForwarders ,  /DnsDelegation ,  /DnsDymanicUpdate ,  /DnsRecordRegistration ,  /DnsResolveExtName ) OutboundSecureChannels VerifyReplicas  – checks if the application partitions are replicated correctly VerifyEnterpriseReferences For example, to check if DNS is working correctly on all domain controllers, use the following command: dcdiag.exe /s:DC01 /test:dns /e /v It will result in a summary table showing test results on how DNS resolves names on all DCs (if it is OK, you will see  Pass  in every cell). If you see  Fail , you need to run this test against the specified DC: dcdiag.exe /s:DC01 /test:dns /DnsForwarders /v To get more information from domain controller test results and save it to a text file, use this command: dcdiag /s:DC01 /v >> c:\ps\dc01_dcdiag_test.log The following PowerShell command displays only a summary information on the performed dcdiag tests: Dcdiag /s:DC01 | select-string -pattern '\. (.*) \b(passed|failed)\b test (.*)' To get the state of all domain controllers, use: dcdiag.exe /s:woshub.com /a If you want to display only the errors you have found, use the  /q  option: dcdiag.exe /s:dc01 /q In my example, the tool has detected some replication errors: There are warning or error events within the last 24 hours after the SYSVOL has been shared. Failing SYSVOL replication problems may cause Group Policy problems. ......................... DC01 failed test DFSREvent To make dcdiag automatically fix the Service Principal Names errors for the DC account, use the  /fix  option: dcdiag.exe /s:dc01 /fix Checking Active Directory Replication Errors Between DCs The built-in  repadmin  tool is used to check replication in the Active Directory domain. Here is the basic command to check AD replication: repadmin /replsum The tool has returned the current replication status between all DCs. Ideally, the  largest delta  value should be less than 1 hour (depends on the AD topology and intersite replication frequency settings), and the number of errors = 0. In my example, you can see that one of the latest replication took 14 days, but now it is OK. To check replication for all DCs in the domain: repadmin /replsum * To test intersite replication: repadmin /showism To view the replication topology and errors (if any), run this command: repadmin /showrepl The command will check the DCs and return the time and date of the last successful replication for each directory partition ( last attempt xxxx was successful ). To display additional replication info, use this command: repadmin /showrepl * To run password replication from a writable domain controller to a  read-only domain controller (RODC) , the  /rodcpwdrepl  option is used. The  /replicate  option starts the replication of the specified directory partition to a specific DC immediately. To synchronize a specified DC with all its replication partners, use the command below: repadmin /syncall To view the replication queue: repadmin /queue Ideally, the replication queue should be empty. Check when the  latest backup of the current domain controller  was created: Repadmin /showbackup * You can also check the replication state using PowerShell. For example, the following command will display all replication errors it finds in the  Out-GridView table : Get-ADReplicationPartnerMetadata -Target * -Partition * | Select-Object Server,Partition,Partner,ConsecutiveReplicationFailures,LastReplicationSuccess,LastRepicationResult | Out-GridView I have uploaded a PowerShell script I often use to check the replication state in AD to my GitHub repository. The script generates an HTML file and can send it by email using the  Send-MailMessage cmdlet . https://github.com/maxbakhub/winposh/blob/main/ADHealthCheck.ps1 ## Active Directory Replication Health Check Script (PowerShell) ## Script uses repadmin to generate HTML report and sends it to admin e-mail #Variables $report_path = " C:\Report " $date = Get-Date - Format " yyyy-MM-dd " $array = @ () #Powershell Function to delete files older than a certain age $intFileAge = 8 #age of files in days $strFilePath = $report_path #path to clean up #create filter to exclude folders and files newer than specified age Filter Select-FileAge { param ( $days ) If ( $_ .PSisContainer ) {} # Exclude folders from result set ElseIf ( $_ .LastWriteTime -lt ( Get-Date ).AddDays( $days * -1 )) { $_ } } #get-Childitem -recurse $strFilePath | Select-FileAge $intFileAge 'CreationTime' |Remove-Item Function send_mail ([ string ] $message , [ string ] $subject ) { $emailFrom = " sender@woshub.com " $emailTo = " to@woshub.com " $emailCC = " cc@woshub.com " $smtpServer = " smtp.woshub.com " Send-MailMessage - SmtpServer $smtpServer - To $emailTo - Cc $emailCC - From $emailFrom - Subject $subject - Body $message - BodyAsHtml } ###Test all forest #$myForest = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest() #$dclist = $myforest.Sites | % { $_.Servers } ### ###Test specific AD domain $Domain = " woshub.com " $dclist = ( Get-ADDomain $Domain - Server $Domain ).ReplicaDirectoryServers ### $html_head = " " foreach ( $dcname in $dclist ){ ###Test all forest #$source_dc_fqdn = ($dcname.name).tolower() ### ###Test specific domain $source_dc_fqdn = ( $dcname ).tolower() ### $ad_partition_list = repadmin / showrepl $source_dc_fqdn | select-string " dc= " foreach ( $ad_partition in $ad_partition_list ) { [ Array ] $NewArray = $NULL $result = repadmin / showrepl $source_dc_fqdn $ad_partition $result = $result | where { ([ string ]::IsNullOrEmpty(( $result [ $_ ]))) } $index_array_dst = 0 .. ( $result.Count - 1 ) | Where { $result [ $_ ] -like " *via RPC " } foreach ( $index in $index_array_dst ){ $dst_dc = ( $result [ $index ]).trim() $next_index = [ array ]::IndexOf( $index_array_dst , $index ) + 1 $next_index_msg = $index_array_dst [ $next_index ] $msg = " " if ( $index -lt $index_array_dst [ -1 ]){ $last_index = $index_array_dst [ $next_index ] } else { $last_index = $result.Count } for ( $i = $index + 1 ; $i -lt $last_index ; $i ++ ){ if (( $msg -eq " " ) -and ( $result [ $i ])) { $msg += ( $result [ $i ]).trim() } else { $msg += " / " + ( $result [ $i ]).trim() } } $Properties = @ { source_dc = $source_dc_fqdn ; NC = $ad_partition ; destination_dc = $dst_dc ; repl_status = $msg } $Newobject = New-Object PSObject - Property $Properties $array += $newobject } } } $status_repl_ko = "

Active Directory Replication Problem :
" $status_repl_ok = "

Active Directory Replication OK :
" $subject = " Active Directory Replication status : " + $date $message = "

The full Active Directory Replication report is available here
" $message += $status_repl_ko if ( $array | where { $_ .repl_status -notlike " *successful* " }){ $message += $array | where { $_ .repl_status -notlike " *successful* " } | select source_dc , nc , destination_dc , repl_status | ConvertTo-Html - Head $html_head - Property source_dc , nc , destination_dc , repl_status send_mail $message $subject } else { $message += " No problem detected
" } $message += $status_repl_ok $message += $array | where { $_ .repl_status -like " *successful* " } | select source_dc , nc , destination_dc , repl_status | ConvertTo-Html - Head $html_head - Property source_dc , nc , destination_dc , repl_status $message | Out-File " $report_path \ad_repl_status_ $date .html " view raw ADHealthCheck.ps1  hosted with ❤ by  GitHub You can also check the state of ADDS basic services on a domain controller using  the Get-Service cmdlet : Active Directory Domain Services ( ntds ) Active Directory Web Services ( adws ) – all cmdlets from the  AD PowerShell module  connect to this service DNS ( dnscache  and  dns ) Kerberos Key Distribution Center ( kdc ) Windows Time Service ( w32time ) NetLogon ( netlogon ) Get-Service -name ntds,adws,dns,dnscache,kdc,w32time,netlogon -ComputerName dc01 So, in this article, we have shown basic tools, commands, and PowerShell scripts you can use to diagnose the health of your Active Directory domain. You can use them in all supported Windows Server versions, including the  domain controllers running in the Server Core mode . Clean Up Server Metadata This is the guide to use when a Domain Controller (DC) crashes and cannot be removed from the domain using normal DCPromo removal method.     Domain Controller Decommission   Use this first to clean up the metadata   Clean/Purge from Sites & Services    Clean/Purge from AD Users & Computers   Clean/Purge from DNS   Clean/Purge from ADSI  (&(Name=RHSC-44-VSRV01*))   ADSI purge          c:\> ntdsutil   ntdsutil:   ntdsutil:  metadata cleanup   metadata cleanup:  connections   server connections:  connect to server   server connections: q   metadata cleanup:  select operation target   select operation target:  list domains   Found 1 domain(s)   select operation target:  Select domain 0     blah blah   select operation target:  list sites   blah blah   select operation target:  select site   blah blah   select operation target:  list servers in site   Found 2 server(s)   0- probably old   1 - probably new   select operation target:  select server   select operation target:  q   metadata cleanup:  remove selected server     Clean Up Server Metadata   Updated: November 1, 2012   Applies To: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012   Metadata cleanup is a required procedure after a forced removal of Active Directory Domain Services (AD DS). You perform metadata cleanup on a domain controller in the domain of the domain controller that you forcibly removed. Metadata cleanup removes data from AD DS that identifies a domain controller to the replication system. Metadata cleanup also removes File Replication Service (FRS) and Distributed File System (DFS) Replication connections and attempts to transfer or seize any operations master (also known as flexible single master operations or FSMO) roles that the retired domain controller holds.   You can clean up server metadata by using the following:   Clean up server metadata by using GUI tools     Clean up server metadata using the command line     Clean up server metadata by using a script       Note   If you receive an “Access is denied” error when you use any of these methods to perform metadata cleanup, make sure that the computer object and the NTDS Settings object for the domain controller are not protected against accidental deletion. To verify this right-click the computer object or the NTDS Settings object, click  Properties , click  Object , and clear the  Protect object from accidental deletion  check box. In Active Directory Users and Computers, the  Object  tab of an object appears if you click  View  and then click  Advanced Features .   Clean up server metadata by using GUI tools   When you use Remote Server Administration Tools (RSAT) or the Active Directory Users and Computers console (Dsa.msc) that is included with Windows Server 2008 or Windows Server 2008 R2 to delete a domain controller computer account from the Domain Controllers organizational unit (OU), the cleanup of server metadata is performed automatically. Previously, you had to perform a separate metadata cleanup procedure.   You can also use the Active Directory Sites and Services console (Dssite.msc) to delete a domain controller’s computer account, which also completes metadata cleanup automatically. However, Active Directory Sites and Services removes the metadata automatically only when you first delete the NTDS Settings object below the computer account in Dssite.msc.   As long as you are using the Windows Server 2008, Windows Server 2008 R2, or RSAT versions of Dsa.msc or Dssite.msc, you can clean up metadata automatically for domain controllers running earlier versions of Windows operating systems.   Membership in  Domain Admins , or equivalent, is the minimum required to complete these procedures. Review details about using the appropriate accounts and group memberships at  Local and Domain Default Groups  ( http://go.microsoft.com/fwlink/?LinkId=83477 ).   To clean up server metadata by using Active Directory Users and Computers   Open Active Directory Users and Computers: On the  Start  menu, point to  Administrative Tools , and then click  Active Directory Users and Computers .   If you have identified replication partners in preparation for this procedure and if you are not connected to a replication partner of the removed domain controller whose metadata you are cleaning up, right-click  Active Directory Users and Computers , and then click  Change Domain Controller . Click the name of the domain controller from which you want to remove the metadata, and then click  OK .   Expand the domain of the domain controller that was forcibly removed, and then click  Domain Controllers .   In the details pane, right-click the computer object of the domain controller whose metadata you want to clean up, and then click  Delete .   In the  Active Directory Domain Services  dialog box, click  Yes  to confirm the computer object deletion.   In the  Deleting Domain Controller  dialog box, select  This Domain Controller is permanently offline and can no longer be demoted using the Active Directory Domain Services Installation Wizard (DCPROMO) , and then click  Delete .   If the domain controller is a global catalog server, in the  Delete Domain Controller  dialog box, click  Yes  to continue with the deletion.   If the domain controller currently holds one or more operations master roles, click  OK  to move the role or roles to the domain controller that is shown.   You cannot change this domain controller. If you want to move the role to a different domain controller, you must move the role after you complete the server metadata cleanup procedure.   To clean up server metadata by using Active Directory Sites and Services   Open Active Directory Sites and Services: On the  Start  menu, point to  Administrative Tools , and then click  Active Directory Sites and Services .   If you have identified replication partners in preparation for this procedure and if you are not connected to a replication partner of the removed domain controller whose metadata you are cleaning up, right-click  Active Directory Users and Computers , and then click  Change Domain Controller . Click the name of the domain controller from which you want to remove the metadata, and then click  OK .   Expand the site of the domain controller that was forcibly removed, expand  Servers , expand the name of the domain controller, right-click the NTDS Settings object, and then click  Delete .   In the  Active Directory Domain Services  dialog box, click  Yes  to confirm the NTDS Settings deletion.   In the  Deleting Domain Controller  dialog box, select  This Domain Controller is permanently offline and can no longer be demoted using the Active Directory Domain Services Installation Wizard (DCPROMO) , and then click  Delete .   If the domain controller is a global catalog server, in the  Delete Domain Controller  dialog box, click  Yes  to continue with the deletion.   If the domain controller currently holds one or more operations master roles, click  OK  to move the role or roles to the domain controller that is shown.   Right-click the domain controller that was forcibly removed, and then click Delete.   In the  Active Directory Domain Services  dialog box, click  Yes  to confirm the domain controller deletion.   Clean up server metadata using the command line   As an alternative, you can clean up metadata by using Ntdsutil.exe, a command-line tool that is installed automatically on all domain controllers and servers that have Active Directory Lightweight Directory Services (AD LDS) installed. Ntdsutil.exe is also available on computers that have RSAT installed.   To clean up server metadata by using Ntdsutil   Open a command prompt as an administrator: On the  Start  menu, right-click  Command Prompt , and then click  Run as administrator . If the  User Account Control  dialog box appears, provide Enterprise Admins credentials, if required, and then click  Continue .   At the command prompt, type the following command, and then press ENTER:   ntdsutil   At the ntdsutil: prompt, type the following command, and then press ENTER:   metadata cleanup   At the metadata cleanup: prompt, type the following command, and then press ENTER:   remove selected server   Or   remove selected server on       Value   Description   ntdsutil: metadata cleanup   Initiates removal of objects that refer to a decommissioned domain controller.   remove selected server   Removes objects for a specified, decommissioned domain controller from a specified server.   or   The distinguished name of the domain controller whose metadata you want to remove, in the form cn= ServerName ,cn=Servers,cn= SiteName , cn=Sites,cn=Configuration,dc= ForestRootDomain . If you specify only one server name, the objects are removed from the current domain controller.   on   Specifies removing server metadata on , the Domain Name System (DNS) name of the domain controller to which you want to connect. If you have identified replication partners in preparation for this procedure, specify a domain controller that is a replication partner of the removed domain controller.   In  Server Remove Configuration Dialog , review the information and warning, and then click  Yes  to remove the server object and metadata.   At this point, Ntdsutil confirms that the domain controller was removed successfully. If you receive an error message that indicates that the object cannot be found, the domain controller might have been removed earlier.   At the metadata cleanup: and ntdsutil: prompts, type quit, and then press ENTER.   To confirm removal of the domain controller:   Open Active Directory Users and Computers. In the domain of the removed domain controller, click  Domain Controllers . In the details pane, an object for the domain controller that you removed should not appear.   Open Active Directory Sites and Services. Navigate to the  Servers  container and confirm that the server object for the domain controller that you removed does not contain an NTDS Settings object. If no child objects appear below the server object, you can delete the server object. If a child object appears, do not delete the server object because another application is using the object.   Clean up server metadata by using a script   Another option for cleaning up server metadata is to use a script. For information about using a script to clean up metadata, see Remove Active Directory Domain Controller Metadata ( http://go.microsoft.com/fwlink/?LinkID=123599 ).     Machine generated alternative text: News Windows  Virtualization  Cloud Computing Of  Dcpromo process will still find the old object and therefore w'll refuse to re-create the objects  In the event that the NTDS Settings object is not removed correctly you can use the Ntdsutil.ex  NTDS Settings object.  If you eve the new domain controller the same name as the failed computer, then you need p  to clean up metadata, which removes the NT DS Settings Object Of the failed domain controller  controller a different name, then you need to perform all three procedures: clean up  Object from the site, and remove the computer Object from the domain controllers container.  You will need the following tool: Ntdsutil.exe, Active Directory Sites and Services, Active Direct(  Also, make sure that you use an account that is a member of the Enterprise Admins universal  Caution: Using the Ntdsutil utility incorrectly may result in partial or complete loss of Active Di  To clean up metadata  1. At the command line, type Ntdsutil and press ENTER.  2 ntdsutil  2. At the Ntdsutil: prompt, type metadata cleanup and press Enter.  ntdsutil: metadata cleanup  2 metadata cleanu  3. At the metadata cleanup: prompt, type connections and press Enter.  metadata cleanup: connections  2 server connections  4. At the server connections: prompt, type connect to server gervername, where «serverna  (any functional domain controller in the same domain) from which you plan to clean up the  controller. Press Enter.  Machine generated alternative text: News  server connections.  Windows  Virtualization  Cloud Computing  Of  Note: Windows Server 2003 Service Pack 1 eliminates the need for the above step.  Type qu 't and press Enter to return you to the metadata cleanup: prompt.  5.  server connections: q  2 metadata cl eanu  Type select operation target and press Enter.  6.  metadata cleanup: Select operation target  2 select operation target  Type list domains and press Enter. This lists all domains in the forest with a number associi  7.  1 select operation target: list domains  Found 1 domain(s)  Ø - DC—dpetri , DC—net  select o eration tar et  4  . Type select domain where is the number corresponding to the dorm  8  was located. Press Enter.  I select operation targe  Select domain  NO current site  Domain - DC.dpetri , DC.net  4  NO current server  NO current Naming Context  6 select 0 ration tar e t  Type list sites and press Enter.  9.  1 select operation target: List sites  Found 1 site(s)  Ø CN—Defoult-Fi rst-Site-Name , CN—Si tes , CN—Configuration, DC—dpetri , DC—net  4  select o ration tar et  Type select site where refers to the number of the site in which the  10.  member. Press Enter.  Machine generated alternative text: News  4 No current server  No current Naming Context  6 select operation target  Windows  Virtualization  Cloud Computing  Of  11. Type list servers in site and press Enter. This will list all servers in that site with a correspon  I select operation target  List serwers in site  2 Found 2 server(s)  ø — CN—SERVER2øø , CN—Servers , CN—Sites , CN—Configuration, DC—dpetri ,  CN—SERVERIW , CN—Servers , CN—De fault-Fi r s , CN—Sites , CN—Confi on, DC—dpetri , DC:  5 select 0 ration tar et  12. Type select server qurnbep and press Enter, where c:numbep refers to the domain contr  1 select operation target: Select server  CN—Defou1 t -Fi rst-Si te-Name , CN—Si tes , CN—Configuration , DC—dpetri , DC—net  Domain - DC-dpetri DC-net  4 Server CN—SERVER2ØØ , CN—Servers , DC—dpetr  DSA object - CN—NTDS Settings,  DNS host name  server2ØØ. dpetri net  Computer object  CN-SERVER2ØØ , OU—Domain Control lers , DC—dpetri  8 No current Naming Context  g select o ration tar et  13. Type qu.t and press Enter. The Metadata cleanup menu is displayed.  I select operation target  2 metadata cleanu  14. Type remove selected server and press Enter.  You will receive a warning message. Read it, and if you agree, press Yes.  Machine generated alternative text: News  metadata cleanup: Remove selected server  Windows  Virtualization  Cloud Computing  solarwtnds  Of  " CN—SERVER2Øø , CN—Servers , CN—Defaul t -F i rst-Si te- Name , CN—Si tes , CN—Configurati on , DC—dpetri , DC—net  3 metadata cleanu  At this point, Active Directory confirms that the domain controller was removed successfully. If  object could not be found, Active Directory might have already removed from the domain conl  15. Type qu.t, and press Enter until you return to the command prompt.  To remove the failed server object from the sites  16. In Active Directory Sites and Services, expand the appropriate site.  17. Delete the server Object associated with the failed domain controller.  To remove the failed server object from the domain controllers container  18. In Active Directory Users and Computers, expand the domain controllers container.  19. Delete the computer object associated with the failed domain controller.  Machine generated alternative text: News Windows  Virtualization  Cloud Computing Of  article, would you...) Select "This DC is permanently offline..."  and click on the Delete button  21. AD will display another confirmation window. If you're sure that you want to delete the failE  To remove the failed server object from DNS  22. In the DNS snap-in, expand the zone that is related to the domain from where the server h,  23. Remove the CNAME record in the msdcs.root domain of forest zone in DNS. You should al  other DNS records.  24. If you have reverse lookup zones, also remove the server from these zones.  Other considerations  Also, consider the following:  • If the removed domain controller was a global catalog server, evaluate whether application  offline global catalog server must be pointed to a live global catalog server.  • If the removed DC was a global catalog server, evaluate whether an additional global catalo  address site, the domain, or the forest global catalog load.  • If the removed DC was a Flexible Single Master Operation (FSMO) role holder, relocate thos  • If the removed DC was a DNS server, update the DNS client configuration on all member w  and other DCs that might have used this DNS server for name resolution. If it is required,  the removal of the DNS server.  CONFIGURE NTP TIME SYNC USING GROUP POLICY https://theitbros.com/configure-ntp-time-sync-group-policy/#:~:text=Configure%20Client%20Time%20Sync%20Settings%20Using%20GPO&text=To%20do%20this%2C%20create%20a,policy%20Configure%20Windows%20NTP%20Client . DO NOT DO THIS ON A VIRTUALIZED DOMAIN CONTROLLER, USE AND EXTERNAL SOURCE FOR VIRTUALIZED VM Time accuracy between workstations/member servers and Active Directory domain controllers is one of the key requirements for the normal functioning of the Active Directory domain. Kerberos authentication is based on timestamps, and if the time difference between the workstation and DC is more than 5 minutes, your user will not be able to authenticate to AD. In this article, we will look at the basics of time synchronization in Active Directory, how to configure PDC sync with an authoritative time source, and how to configure the NTP time sync in the domain using Group Policies. In the AD environment, the time synchronization is performed according to a domain hierarchy: domain-joined computers and servers get the time from the nearest domain controller on which they are logged on, all domain controllers synchronize their time with a single DC that holds the PDC (Primary Domain Controller) Emulator  FSMO role . By default, the forest root domain PDC emulator gets its time from the BIOS (CMOS) clock. This configuration is not optimal because the time on all computers in the domain depends on the BIOS time setting on the PDC host and may differ from the global time. You need to configure your PDC Emulator to sync time with an authoritative external time source (NTP provider). The external time source is usually one or more public NTP (Network Time Protocol) servers, like time.windows.com or the NTP server of your provider. Table of Contents How Does Time Sync Works in AD Domain? Configure Primary Domain Controller (PDC) to Sync Time with External NTP Source Configure External NTP Source on PDC with GPO Configure Domain Client Time Sync Settings Using GPO How to Manually Sync Time with NTP Server on a Windows Client How Does Time Sync Works in AD Domain? Windows Time service (W32Time) is used to synchronize the time in the AD organization. A computer can be both a client and an NTP server. By default, the Windows Time Service in Active Directory is configured as follows: After performing a clean Windows installation, an NTP client is launched on the computer, which is synchronized with an external time source (time.windows.com); When you join PC to domain, the time sync setting changes. All client computers and member servers in the domain synchronize their time with AD domain controllers; When a member server is  promoted to a domain controller , it can be used as a time source for domain computers. All domain controllers synchronize their time with a domain controller with the PDC emulator role; The PDC emulator in the root domain is the main time source for the entire organization. It synchronizes with an external time source, or with the server’s hardware clock in CMOS/BIOS (this method of time synchronization is not recommended); The PDC emulator in the child domain synchronizes its time with the domain controller in the parent AD domain; This time synchronization scheme (according to the AD DS hierarchy) works properly in most cases and doesn’t require admin intervention. However, the structure of the time service in Windows may not follow the domain hierarchy. The NTP server is enabled on all DCs by default. The following registry setting provides this: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer]: Enabled=1 If you are facing a problem when the time on clients and domain controllers is different, most likely your domain has a problem with time synchronization and then this article can be very useful for you. First of all, it is necessary to select an NTP server you want to use. The NTP time server can be on your local network or you can use an Internet-based (external) NTP source. The list of public NTP atomic clock servers is available at http://ntp.org. In our example, we will use 0.us.pool.ntp.org, 1.us.pool.ntp.org, 2.us.pool.ntp.org, and 3.us.pool.ntp.org. Configuring domain time synchronization using Group Policy consists of 2 steps: Create a GPO for the domain controller with a PDC role; Create a GPO for Windows client computers in the AD Domain. Configure Primary Domain Controller (PDC) to Sync Time with External NTP Source First of all, you need to configure the PDC and enable the NTP service on it. To locate the name of the server with the PDC role in the domain, run the command: netdom /query fsmo Connect to the specified DC, open a command prompt, and run: w32tm /query /source If you see in the output: Local CMOS Clock — the time source on this server is its local hardware clock; VM IC Time Synchronization Provider — then your domain controller with the PDC role is a virtual machine that synchronizes the time with the host. Disable time synchronization with the hardware clock on the host via the registry: Set the Enabled parameter to 0 in the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider and restart the W32Time service: Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider -Name Enabled -Value 0 Restart-Service "Windows Time" If you are using virtualized domain computers, disable the time sync with the hypervisor host in the VM properties. The screenshot below shows how to disable the time synchronization of the VM with the Hyper-V host using the Time Synchronization option in the Integration Services section. If you are running a virtualized domain controller on VMware vSphere/ESXi, you can disable time sync in the virtual machine settings (Edit Settings > VM Options > VMware Tools > Time, uncheck the option  Synchronize guest time with host ). The best approach is to configure the PDC emulator to synchronize the time directly with an external time source. Check that the external NTP servers you have chosen are accessible from the primary domain controller (outbound port UDP 123 must be open to the PDC host). Get the current time from an external NTP server using the command: w32tm /stripchart /computer:0.us.pool.ntp.org In this example, the specified NTP server is available and you have successfully obtained the current time from it. You can manually configure the time synchronization of the PDC host with an external NTP source using the w32tm.exe tool: net stop w32time w32tm /config /syncfromflags:manual /manualpeerlist:"1.us.pool.ntp.org,0x8 1.us.pool.ntp.org,0x8 2.us.pool.ntp.org,0x8 3.us.pool.ntp.org,0x8" w32tm /config /reliable:yes w32tm /config /update net start w32time Check your current configuration: w32tm /query /configuration Configure External NTP Source on PDC with GPO The PDC Emulator  role can be transferred  between domain controllers, so you need to make sure that GPO is applied only to the current holder of the Primary Domain Controller role. To do this, open the Group Policy Management Console (GPMC.msc). Select the WMI Filters section and create a new WMI filter with the name  Filter PDC Emulator  and the following WMI query in the root\CIMv2 namespace  Select * from Win32_ComputerSystem where DomainRole = 5 . Create a new GPO and link it to the  AD OU  named Domain Controllers. Select this GPO and switch to the Edit mode. Go to the following section of Group Policy Editor Console: Computer Configuration > Administrative Templates > System > Windows Time Service > Time Providers. Enable the following policy settings: Configure Windows NTP Client: Enabled (policy settings are described below); Enable Windows NTP Client: Enabled; Enable Windows NTP Server: Enabled. Specify the following settings in Configure Windows NTP Client policy: NtpServer: us.pool.ntp.org,0x1 1.us.pool.ntp.org,0x1 2.us.pool.ntp.org,0x1 3.us.pool.ntp.org,0x1; Type: NTP; CrossSiteSyncFlags: 2; ResolvePeerBackoffMinutes: 15; Resolve Peer BAckoffMaxTimes: 7; SpecilalPoolInterval: 3600; EventLogFlags: 0. Do not forget to configure your firewall properly and allow your PDC to access the external NTP servers and allow your internal client to connect to the NTP source on PDC. This means that you will need to open UDP port 123 on the domain controller for both inbound and outbound traffic. You can open the NTP port on Windows Defender Firewall using PowerShell: New-NetFirewallRule -Name 'NTP_Server_123_UDP_In' -DisplayName 'NTP Server In' -Description 'Allow Inbound Connections to NTP Server' -Profile Any -Direction Inbound -Action Allow -Protocol UDP -Program Any -LocalAddress Any -LocalPort 123 New-NetFirewallRule -Name 'NTP_Server_123_UDP_Out' -DisplayName 'NTP Server Out' -Description 'Allow Outbound Connections to External NTP Time Source' -Profile Any -Direction Outbound -Action Allow -Protocol UDP -Program Any -LocalAddress Any -LocalPort 123 Note . Also open outbound UDP port 123 for your PDC on any perimeter firewall (if used). Assign a WMI filter “Filter PDC Emulator “  that you created earlier to the GPO. It remains to update the Group Policy settings on PDC using the command: gpupdate /force Perform a manual time synchronization with your NTP source: w32tm /resync And check the current NTP settings: w32tm /query /status Run the command: w32tm /monitor When running on a domain controller, this command shows how much time is different between other domain controllers and the external time source for which the PDC is configured. Tip . If something does not work, try to restart the Windows Time service and reset its configuration: net stop w32time w32tm.exe /unregister w32tm.exe /register net stop w32tim Configure Domain Client Time Sync Settings Using GPO By default in Active Directory, domain clients synchronize their time with domain controllers (option Nt5DS — synchronize time to domain hierarchy). Typically, this behavior does not need to be reconfigured. However, if there are problems with time sync on your domain clients, you can try to specify the time server directly on clients using GPO. To do this, create a new GPO and assign it to the OU with computers. In the GPO Editor go to the following section Computer Configuration > Administrative Templates > System > Windows Time Service > Time Providers and enable the policy Configure Windows NTP Client. As an  NTP server  specify the name of your domain (preferred) or IP address/FQDN of the PDC: NTP Server: lon-dc1.adatum.com,0x9 Set Type: NT5DS CrossSiteSyncFlags: 2 ResolvePeerBackoffMinutes: 15 ResolvePeerBackoffMaxTimes: 7 SpecialPollInterval: 3600 EventLogFlags: 0 Possible values for the Type parameter: NoSync  — the NTP server is not synchronized with any external time source. The system clock built into the server’s CMOS chip is used; NTP  — the  NTP server is synchronized with external time servers , which are specified in the NtpServer registry parameter (this is the default behavior on a stand-alone computer); NT5DS  — the NTP server performs synchronization according to the domain hierarchy (used by default on domain-joined computers); AllSync  — the NTP server uses all available sources for time synchronization. Update Group Policy settings on the clients and check the received time sync settings as described above. Hint . By default, domain client systems automatically synchronize their clocks with the NTP server once every hour (3,600 seconds). This is configured through the registry value  SpecialPollInterval  under  HKLM\SYSTEM\ControlSet\Services \W32Time\TimeProviders\NtpClient. By default, Windows Server and Windows Client domain member systems synchronize their clocks once per hour (3,600 seconds). How to Manually Sync Time with NTP Server on a Windows Client In this section, we will describe how to manually  sync time to domain controller  on Windows clients. You can use this guide to configure time synchronization on non-domain (workgroup) Windows computers. First, reset all settings for the time service and remove the service: w32tm /unregister Restart the computer and then re-register the time service: w32tm /register Start the w32Time service: net start w32Time Configure the synchronization of the Windows client with the NTP server (your PDC): w32tm /config /manualpeerlist:"lon-dc01.adatum.com,0x9" /syncfromflags:manual /reliable:yes /update Restart the service: net stop w32time && net start w32time Update the time configuration settings: w32tm /config /update Synchronize the time: w32tm /resync Check the status: w32tm /query /status Enable automatic startup of the Time Service using PowerShell: Set-Service –Name w32tm–StartupType Automatic Hint . If you need to quickly synchronize your Windows device with an accurate time server, run: net time \\your_ntp_server_name /set /y Create a Group to Assign Permissions to Access Files Best practice is to always create a security group , and assign that security group file permissions. You can then assign members or users to that group for file access. Log into the Active Directory Users and Computers MMC on a Domain Controller or other Computer Navigate to where you want the new group to be located Create the security group. Best practice is to create the group as Domain Local for assigning permissions. Follow the acronym AGDLP Account > Global Group > Domain Local Group > Permission It is best to assign users to Global Groups to collect, then assign the Global Groups to the Domain Local groups that have the file permissions. Create WMI Filters for the GPO Applies To: Windows Server 2012 To make sure that each GPO associated with a group can only be applied to computers running the correct version of Windows, use the Group Policy Management MMC snap-in to create and assign WMI filters to the GPO. Although you can create a separate membership group for each GPO, you would then have to manage the memberships of the different groups. Instead, use only a single membership group, and let WMI filters automatically ensure the correct GPO is applied to each computer. No text is specified for bookmark or legacy link '#bkmk_1'. No text is specified for bookmark or legacy link '#bkmk_2'. Administrative credentials To complete these procedures, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. First, create the WMI filter and configure it to look for a specified version (or versions) of the Windows operating system. To create a WMI filter that queries for a specified version of Windows On a computer that has the Group Policy Management feature installed, click  Start , click  Administrative Tools , and then click  Group Policy Management . In the navigation pane, expand  Forest:   YourForestName , expand  Domains , expand  YourDomainName , and then click  WMI Filters . Click  Action , and then click  New . In the  Name  text box, type the name of the WMI filter.  Note Be sure to use a name that clearly indicates the purpose of the filter. Check to see if your organization has a naming convention. In the  Description  text box, type a description for the WMI filter. For example, if the filter excludes domain controllers, you might consider stating that in the description. Click  Add . Leave the  Namespace  value set to  root\CIMv2 . In the  Query  text box, type: Copy select * from Win32_OperatingSystem where Version like "6.%" This query will return  true  for computers running Windows 8, Windows 7, Windows Vista, Windows Server 2012, Windows Server 2008, and Windows Server 2008 R2. To set a filter for just Windows 8 and Windows Server 2012, use "6.2%". To specify multiple versions, combine them with or, as shown in the following: Copy ... where Version like "6.1%" or Version like "6.2%" To restrict the query to only clients or only servers, add a clause that includes the ProductType parameter. To filter for client operating systems only, such as Windows 8 or Windows 7, use only ProductType="1". For server operating systems that are not domain controllers, use ProductType="3". For domain controllers only, use ProductType="2". This is a useful distinction, because you often want to prevent your GPOs from being applied to the domain controllers on your network. The following clause returns  true  for all computers that are not domain controllers: Copy ... where ProductType="1" or ProductType="3" The following complete query returns  true  for all computers running Windows 8, and returns  false  for any server operating system or any other client operating system. Copy select * from Win32_OperatingSystem where Version like "6.2%" and ProductType="1" The following query returns  true  for any computer running Windows Server 2012, except domain controllers: Copy select * from Win32_OperatingSystem where Version like "6.2%" and ProductType="3" Click  OK  to save the query to the filter. Click  Save  to save your completed filter. After you have created a filter with the correct query, link the filter to the GPO. Filters can be reused with many GPOs simultaneously; you do not have to create a new one for each GPO if an existing one meets your needs. To link a WMI filter to a GPO On a computer that has the Group Policy Management feature installed, click  Start , click  Administrative Tools , and then click  Group Policy Management . In the navigation pane, find and then click the GPO that you want to modify. Under  WMI Filtering , select the correct WMI filter from the list. Click  Yes to accept the filter. Cross Forest Resource Security Cross-forest resource security     To grant access to resources from one forest to another:   Create/ensure they have a forest level transitive trust   Create a domain local security group   This group will be what is assigned to the resources.   File shares, delegated AD permissions, etc should point to the domain local group   Create a universal security group   This will be what the users are added to   Assign the universal groups as a member of the domain local groups       Demote or Promote Domain Controller Both of these commands need to be ran under credentials that have authority to demote the server.   Both of these commands will prompt for new local administrator password       #This command will test if there are any problems with demotion   Test-ADDSDomainControllerUninstallation        #This will demote the server   Uninstall-ADDSDomainController                     Install-WindowsFeature -name AD-Domain-Services -IncludeManagementTools     Install-ADDSDomainController -DomainName "centurionind.com" -InstallDns:$true -Credential (Get-Credential "centurionind.com\administrator")           **************************************************************   #   # Windows PowerShell script for AD DS Deployment   #     Import-Module ADDSDeployment   Install-ADDSDomainController `   -NoGlobalCatalog:$false `   -CreateDnsDelegation:$false `   -CriticalReplicationOnly:$false `   -DatabasePath "C:\Windows\NTDS2" `   -DomainName "RHSC.local" `   -InstallDns:$true `   -LogPath "C:\Windows\NTDS2" `   -NoRebootOnCompletion:$false `   -SiteName "RSI-Russia-DolinaSemyan" `   -SysvolPath "C:\Windows\SYSVOL2" `   -Force:$true   **************************************************************   #   # Windows PowerShell script for AD DS Deployment   #     Import-Module ADDSDeployment   Install-ADDSDomainController `   -NoGlobalCatalog:$false `   -CreateDnsDelegation:$false `   -CriticalReplicationOnly:$false `   -DatabasePath "C:\Windows\NTDS" `   -DomainName "RHSC.local" `   -InstallDns:$true `   -LogPath "C:\Windows\NTDS" `   -NoRebootOnCompletion:$false `   -SiteName "RSI-Russia-DolinaSemyan" `   -SysvolPath "C:\Windows\SYSVOL" `   -Force:$true   **************************************************************   New Domain ->   **************************************************************   #   # Windows PowerShell script for AD DS Deployment   #     Import-Module ADDSDeployment   Install-ADDSForest `   -CreateDnsDelegation:$false `   -DatabasePath "C:\Windows\NTDS" `   -DomainMode "WinThreshold" `   -DomainName "LemanEng.local" `   -DomainNetbiosName "LEMANENG" `   -ForestMode "WinThreshold" `   -InstallDns:$true `   -LogPath "C:\Windows\NTDS" `   -NoRebootOnCompletion:$false `   -SysvolPath "C:\Windows\SYSVOL" `   -Force:$true     **************************************************************       Determine AD forest and domain level Get-ADDomain   |   select   domainMode ,   DistinguishedName    Get-ADForest   |   select   forestMode     From < https://www.petri.com/raise-active-directory-domain-and-forest-functional-levels-using-powershell >    Disable "These files might be harmful to your computer" warning? https://superuser.com/questions/149056/disable-these-files-might-be-harmful-to-your-computer-warning I found a fix by changing "internet options" -- so I guess Windows is detecting the "internet" as my own network.. sigh. Click Start / Control Panel / Internet Options Click  Security  tab. Click  Local Intranet Click  Sites  button. Click  Advanced  button. Enter the IP Address of the other machine or server (wildcards are allowed) and click  Add Click  Close , then  OK , then  OK  again. Disconnect, and reconnect the network drive This worked for me, but it's a bummer I have to manually enter IPs here.. it would be nice if Windows could detect this is a local network file copy and skip the irritating (and pointless) warning about "dangerous" files. Sidenotes: If you are using a DNS name to map the network drive, adding the IP address of the server to the zone will not work. You will need to add the DNS name, and vica-versa. When adding an IP address, you can use wildcards like so: 192.168.1.* Whan adding a DNS name, you can use wildcards like so: *.example.com Using Windows 7, I added my IP address with a wildcard: 10.55.25.* Now all the ip's in this range are part of the "Local Intranet". Disabling and Enabling Outbound Replication Disabling and Enabling Outbound Replication Last Updated: July 7, 2024 Disabling and Enabling Outbound Replication if you are implementing the major changes to active directory like extending the schema version. it is recommended that you should disable the outbound replication on schema master domain controller. After disabling the replicating, do the changes and test the changes if you find that changes you have made are unacceptable, you can just rollback the changes from schema master domain controllers rather than being faced with the prospect of performing a disaster recovery operation on your entire domain. It is very important and recommended to disabling outbound replication on a domain controller will not have any effect on inbound replication; the DC will still receive updates from its other replication partners unless you disable inbound replication on them as well. To stop outbound replication for a specific DC, Use this command Disabling Outbound Replication     When your replication is disabled, warning events 1115 will be generated from source NTDS General will be logged in the Directory Service event log. warning events 1115 To start outbound replication for a specific DC, Use this command Enabling the Outbound Replication When your replication is enable, warning events 1116 will be generated from source NTDS General will be logged in the Directory Service event log. warning events 1116   In a worst-case scenario, you can disable replication for an entire forest by issuing the following command: c:\> repadmin /options * +DISABLE_INBOUND_REP Domain Controller DNS Best Practice It is best practice when using multiple domain controllers with the DNS role to set the servers as each others primary DNS. For example, AD01 and AD02 servers. AD01 should be using AD02 server as it's primary DNS, while AD02 uses AD01 as it's primary DNS server. This should prevent the two servers from drifting apart and having replication issues. Domain Trust Periodically we will get a call where the person cannot log into their computer and they get an error message stating that the computer has a domain trust issue     This is due to the background password for the computer being different between the computer and the domain.  That has to be reset       Unplug the network cable and the person will be able to log in.  Once logged in, have them plug the cable back in.   Find the AD object for the computer within Active Directory Users & Computers   Right click on the object and reset it.  That clears account information and allows the computer to be rejoined to the domain   On the computer  -> Control Panel -> System Then rejoin the computer to the domain.  Note: it will require a domain admin account to join.     Once that is done it should function as normal.  This should not be a long process and should be done onsite since it needs domain network connection.               ********************************************************************************     Netdom resetpwd /Server:DC01 /UserD:JDoe /PasswordD:Str0NGestP@$       DC01 - Domain controller that is good that you want to authenticate with   Jdoe - Domain admin account   Str0NGestP@$ - account password, this command can only work with the password typed in clear text.  Don't do it in front of end user.   Force reinstall of applications deployed by software GPO after uninstall https://social.technet.microsoft.com/Forums/ie/en-US/82f1e144-78a3-4446-8aaf-18843c890cdc/force-reinstall-of-applications-deployed-by-software-gpo-after-uninstall?forum=winserverGP 0 Sign in to vote In testing one of our first software deployments using a GPO, a rather glaring issue seems to have appeared.  It appears that if a user uninstalls an application that was deployed by GPO, the application is not reinstalled unless an update for that software is applied to the GPO.  For example: 1.)  Application gets installed to client machine via software group policy (Computer policy, assigned install) 2.)  User of client machine uninstalls application that was installed via GPO 3.)  When restarted, the client machine does NOT reinstall the removed software.  Is this expected behavior?  Ideally, we'd like to have applications that are deployed by GPO either, a.) automatically reinstalled if they are removed or b.) prohibited from being uninstalled in the first place.  Any suggestions? Thanks! Aaron P. Monday, March 22, 2010 7:24 PM Answers 1 Sign in to vote Howdie! Am 22.03.2010 20:24, schrieb AP83: > 1.) Application gets installed to client machine via software group > policy (Computer policy, assigned install) > > 2.) User of client machine uninstalls application that was installed via GPO > > 3.) When restarted, the client machine does NOT reinstall the removed > software. > Is this expected behavior? Ideally, we'd like to have applications that > are deployed by GPO either, a.) automatically reinstalled if they are > removed or b.) prohibited from being uninstalled in the first place. > > Any suggestions? Yeah, that is expected behavior. The CSE behaves like that. Only administrators can remove Software from a computer. Make your users normal users on their boxes and remove their admin abilities -- that's how you solve it. Here's a blog posting I've setup: http://www.frickelsoft.net/blog/?p=103 Cheers, Florian Microsoft MVP - Group Policy (http://www.frickelsoft.net/blog) Proposed as answer by   Alan Burchill   Monday, March 22, 2010 10:13 PM Marked as answer by   Bruce-Liu   Monday, March 29, 2010 9:56 AM Monday, March 22, 2010 9:30 PM All replies 1 Sign in to vote Howdie! Am 22.03.2010 20:24, schrieb AP83: > 1.) Application gets installed to client machine via software group > policy (Computer policy, assigned install) > > 2.) User of client machine uninstalls application that was installed via GPO > > 3.) When restarted, the client machine does NOT reinstall the removed > software. > Is this expected behavior? Ideally, we'd like to have applications that > are deployed by GPO either, a.) automatically reinstalled if they are > removed or b.) prohibited from being uninstalled in the first place. > > Any suggestions? Yeah, that is expected behavior. The CSE behaves like that. Only administrators can remove Software from a computer. Make your users normal users on their boxes and remove their admin abilities -- that's how you solve it. Here's a blog posting I've setup: http://www.frickelsoft.net/blog/?p=103 Cheers, Florian Microsoft MVP - Group Policy (http://www.frickelsoft.net/blog) Proposed as answer by   Alan Burchill   Monday, March 22, 2010 10:13 PM Marked as answer by   Bruce-Liu   Monday, March 29, 2010 9:56 AM Monday, March 22, 2010 9:30 PM   1 Sign in to vote So what do you do if an admin accidently uninstalls a program installed by GPO.  How do you get the GPO to reinstall the program? @ndyP Thursday, July 29, 2010 5:17 PM   7 Sign in to vote Simply delete corresponding key from: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\AppMgmt More info here  www.mysysadmintips.com/active-directory/210-force-applications-to-be-re-installed-by-group-policy Proposed as answer by   Robert Wagner1   Tuesday, May 28, 2013 2:35 PM Tuesday, February 7, 2012 9:14 AM   0 Sign in to vote Thank you.  This is very helpful when tweaking GPO software installs. Tuesday, May 28, 2013 2:38 PM   0 Sign in to vote Thanks, Florian.  That is very helpful, but I swear that years ago when I was learning about GPSI one of the advantages was that it would self-maintain.  I thought I remember reading that it would get reinstalled automatically if needed or even "repair" itself if program files got corrupted.  I know that you are correct because I have seen the evidence myself, but if my memory serves me well, this goes against the way it's supposed to behave, or at least the way it did in the past. Thursday, January 16, 2014 8:54 PM   0 Sign in to vote Dunno where this was introduced, but I'd like to add that in Windows Server 2012 R2 there's an option to "redeploy" a package (all tasks / redeploy application). No registry hacking needed anymore. Tuesday, November 25, 2014 12:21 AM   0 Sign in to vote > Dunno where this was introduced, but I'd like to add that in Windows > Server 2012 R2 there's an option to "redeploy" a package (all tasks /   That's available since the very beginning... :)   Martin Mal ein  GUTES Buch über GPOs  lesen? NO THEY ARE NOT EVIL, if you know what you are doing:  Good or bad GPOs? And if IT bothers me -  coke bottle design refreshment  :)) Tuesday, November 25, 2014 9:03 AM   0 Sign in to vote Hi, I'm also the same issue. Can you please help anyone. Tuesday, January 24, 2017 3:04 PM   0 Sign in to vote This may have worked 7 years ago but when I look in that registry location there is nothing there even though I have deployed a package via 'Assigned Application'. Does anyone know how to get an application deployed in this manner to reinstall for one user in a more recent AD environment.   Tuesday, October 22, 2019 10:55 PM   0 Sign in to vote OK I found it, for anyone else who is having problems with this there are a couple of caveats that you need to be aware of. 1. If it was deployed as a User package then the path is actually HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\Appmgmt\ 2. If this is the case you need to be logged in to the users PC but do not run Regedit as administrator (I had originally loaded regedit as administrator as I was expecting it to be in HKLM). Tuesday, October 22, 2019 11:17 PM   0 Sign in to vote If someone still looking for this: Open your GPO wich installs the software, navigate to:   Computerkonfiguration - Richtlinien - Softwareeinstellungen - Softwareinstallation   Rightklick on your Software Package and Choose "Alle Aufgaben"   (All Tasks) Erneut Bereitstellen (Reinstall??)   Sorry, have it in German. Have Fun! Get Password Info DSQUERY // ADComputer          Get listing of all accounts with info:   Get-ADUser -filter * -properties passwordlastset, passwordneverexpires | ft Name, Passwordlastset, passwordneverexpires     Get listing of user accounts that have their passwords set to never expire   Get-ADUser -filter 'passwordneverexpires -Eq "True"' -properties passwordlastset, passwordneverexpires | ft Name, Passwordlastset, passwordneverexpires, enabled     Get Last AD profile change such as update password   Get-ADUser -filter * -properties whenChanged, passwordlastset, passwordneverexpires | ft Name, whenChanged, passwordneverexpires         Get last logon    Get-ADUser -filter 'passwordneverexpires -Eq "True"' -properties name, passwordlastset, passwordneverexpires | Get-ADObject -Properties lastLogon | FT Name,  @{N='LastLogon'; E={[DateTime]::FromFileTime($_.LastLogon)}}        Get-ADUser -filter 'passwordneverexpires -Eq "True"' -properties passwordlastset, passwordneverexpires | ft Name, Passwordlastset, passwordneverexpires     CSV of user accounts set to never expire   Get-ADUser -filter 'passwordneverexpires -Eq "True"' -properties passwordlastset, passwordneverexpires |  Select-Object Name, Passwordlastset, passwordneverexpires, enabled | export-csv -path c:\Accent\UserPassNeverExpire.csv -NoTypeInformation     Inactive & disabled users   Dsquery user -inactive 5 -disabled       Remove password never expires to inactive accounts   Dsquery user -inactive 50 | dsmod user -pwdneverexpires no     Set all disabled user accounts removing the password never expires   dsquery user -disabled | dsmod user -pwdneverexpires no       Get listing of disabled users and last update to their account (presumably when disabled)   Get-ADUser -filter 'Enabled -Eq "False"' -properties passwordlastset, passwordneverexpires, WhenChanged | ft Name, enabled, WhenChanged       Table Fields:   DistinguishedName   Enabled   GivenName   Name   ObjectClass   ObjectGUID   PasswordLastSet   PasswordNeverExpires   SamAccountName   SID   Surname   UserPrincipalName        get-localuser | Disable-LocalUser     Onboarding Commands   To get a list of all users in a domain and exported to CSV file   get-aduser -filter * -Properties *| Select-Object Name, enabled, SamAccountName, UserPrincipalName | export-csv -path c:\Accent\test10.csv -NoTypeInformation   How To Add Local Administrators via GPO (Group Policy) https://thesysadminchannel.com/add-local-administrators-via-gpo-group-policy/ In every organization there will always be the need to have administrators of some sort manage some number of the machines in the domain. We also want to follow the path of least privilege, so using your Domain Admin (DA) account to do your daily admin tasks is not going to cut it. Remember, DA accounts should only be used for tasks that require such privileges, tasks such as  Finding Lockout Sources in Active Directory . A Domain Admin should not be used for logging into a random workstation or server to perform certain tasks. For this reason, we need the ability to  add local administrators via GPO  and separate privileges for admin accounts. Best Practices is an admin that has a DA account should have the following accounts with privileges. Domain Admin:  Used for very limited tasks that actually require DA access. Server Admin:  Used for logging into servers. This account is NOT a Domain Admin and is not an admin on any workstations. Workstation Admin:  Used for administering end user workstations. This account is NOT a Domain Admin and is not an admin on any Servers. Regular Account:  Account used for email and general day to day tasks. This account is not an admin on any servers or any end user workstations.   Typically, I find that it is generally easy to remember if you insert a prefix along with your username. da-bsmith:  Domain Admin Account. sa-bsmith:  Server Admin Account. wa-bsmith:  Workstation Admin Account. bsmith:  Regular everyday account.   Add Local Administrators via GPO (Group Policy) So unless you already have delegated privileges, you will need Domain Admin access to enable or create group policies (ironically enough).  Here are the steps to add local administrators via GPO . Open Group Policy Management Editor (GPMC) Create a New Group Policy Object and name it  Local Administrators – Servers Navigate to  Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Restricted Groups . Right Click on the right panel and select  Add Group Browse for the Active Directory Group you wish to add as a local admin Select  This group is a member of  (#1 Below) –  This step is extremely important. Selecting Members of this group will wipe out all current admins . Select  Browse  (#2) Type  Administrators  (#3) –  Note: Be sure to add “s” at the end Click  Check Names  (#4) to make sure it resolves and  click OK Close out of the window Highlight the Local Administrators – Server Policy and go to the Details Tab. On the GPO Status Dropdown select  User Configuration Settings Disabled The final GPO should look like my screenshot below   Apply the Group Policy to your Organizational Unit Right Click your preferred OU and select  Link an Existing GPO Select  Local Administrators – Servers GPO Close out of GPMC.   Verifying Your Group Policy Works Login to any server in the OU you applied the policy to Open up a command prompt or  Powershell  Window Type  GPUpdate /force Check Local Adminstrators Group and you group should be added How to Audit User Account Changes in Active Directory https://www.lepide.com/how-to/audit-user-account-changes-in-active-directory.html#:~:text=To%20track%20user%20account%20changes%20in%20Active%20Directory%2C%20open%20%E2%80%9CWindows,to%20find%20the%20relevant%20events . Auditing user account changes in Active Directory is crucial for ensuring the security, integrity, and accountability of an organization’s IT environment. Here are the key reasons why auditing AD user account changes is important: User account changes, such as password resets, account lockouts, or privilege modifications, can be indicators of unauthorized access attempts or insider threats. Auditing these changes allows for the early detection of suspicious activities and potential security breaches, enabling organizations to take immediate action to mitigate risks and protect sensitive information. In addition, many regulatory frameworks, including the Health Insurance Portability and Accountability Act (HIPAA) and the Sarbanes-Oxley Act (SOX), require organizations to maintain comprehensive audit trails of user account changes. Auditing user account changes helps demonstrate compliance with these regulations, ensuring that the organization’s IT environment is being monitored and controlled effectively. In the event of a security incident or a compliance violation, auditing user account changes provides valuable forensic evidence. The audit logs can be used to reconstruct events, track the actions of specific users, and determine the root cause of the incident. This information is essential for conducting thorough investigations and implementing remedial measures. Auditing user account changes also supports effective change management practices. It helps administrators track and verify modifications made to user accounts, ensuring that changes are authorized, properly documented, and comply with the organization’s policies and procedures. This facilitates better control over user access and reduces the risk of unauthorized changes or misconfigurations. In this article, you will learn how to audit user account changes in Active Directory both natively and using Lepide Active Directory Auditor. Audit Active Directory User Account Changes using Event Logs Step 1: Enable “User Account Management” Audit Policy Perform the following steps to enable “User Account Management” audit policy: Go to “Administrative Tools” and open “Group Policy Management” console on the primary “Domain Controller”. In “Group Policy Management”, create a new GPO or edit an existing GPO. It is recommended to create a new GPO, link it to the domain and edit. To create a new GPO, right-click the domain name in the left panel, and click “Create a GPO in this domain, and Link it here”. It shows the “New GPO” window on the screen. Provide a name (User Account Management in our case) and click “OK”. The new GPO appears in the left pane. Right-click it and click “Edit” in the context menu. “Group Policy Management Editor” appears on the screen. In this window, you have to set “Audit User Account Management” policy. To do that, navigate to “Computer Configuration” ➔ “Windows Settings” ➔ “Security Settings” ➔ “Advanced Audit Policy Configuration” ➔ “Audit Policies”. Select “Account Management” policy to list all of its sub-policies. Double-click “Audit User Account Management”’ policy to open its “Properties” window Note:  Instead of configuring “Local Policy, it is recommended to configure above policy in “Advanced Audit Policy Configuration”. This is because you have to enable all account management policies in “Local Policy” that will generate huge amount of event logs. To minimize the noise, “Advanced Audit Policy Configuration” should be preferred. Figure 1: The “Audit User Account Management” policy In policy properties, click to select “Define these policy settings” checkbox. Then, select the “Success” and the “Failure” attempts check boxes. You can choose any one or both the options as per your need. In our case, we have selected both of the options as we want to audit both the successful and the failed attempts. Figure 2: Properties of “Audit User Account Management” policy Click “Apply”, and “OK” to close the properties window. It is recommended to update the Group Policy instantly so that new changes can be applied on the entire domain. Run the following command in the “Command Prompt”: Gpupdate /force In the following image, you can see the “Gpupdate” command run. Figure 3: Updating the Group Policy Step 2: Search Relevant Event IDs to Track User Account Changes To track user account changes in Active Directory, open “Windows Event Viewer”, and go to “Windows Logs” ➔ “Security”. Use the “Filter Current Log” option in the right pane to find the relevant events. The following are some of the events related to user account management: Event ID Description Event ID 4720 shows a user account was created. Event ID 4722 shows a user account was enabled. Event ID 4740 shows a user account was locked out. Event ID 4725 shows a user account was disabled. Event ID 4726 shows a user account was deleted. Event ID 4738 shows a user account was changed. Event ID 4781 shows the name of an account was changed. In our lab environment, we have enabled a disabled user account. The following image shows the event’s properties window’s screenshot (event Id 4722). The user’s name who enabled the account is shown under “Subject ➔ Account Name” field, and the account-enable time is displayed under “Logged” field. Figure 4: A user who enabled the account (Subject) To see the user’s name whose account was enabled, you will have to scroll down the event’s property window’s side bar. In the following image, you can see the user’s name under “Target Account ➔ Account Name” field. Figure 5: The user’s name whose account was enabled (Target) How Lepide Active Directory Auditor Tracks User Account Changes Often cited as being both quicker and easier than native auditing methods,  Lepide Active Directory Auditor  enables you to track user account changes in your Active Directory in a much better way. Lepide presents critical information about user account changes in Active Directory, including when a user account was created, deleted, locked out, disabled, deleted, changed, or when the name of an account was changed. All of this information is presented in easy-to-read, filterable, searchable and sortable reports. The following example shows the “User Status Modifications” report. All audit information about a when the status of a user account has changed is shown in a single line record: Figure 6: “User Enabled and Disabled” report In the above image, you can see that the status of one particular user has changed multiple times. We can see all the important audit information, including the user name, who made the change, when it happened, the current status, and more. The below image shows user created, deleted and more changes report Figure 7: “User Created and Deleted” report How to Change the Default Lock Screen Image using GPO Step-by-step: How to Change the Default Lock Screen Image using GPO This example below will demonstrate how to change the default lock screen image in client PC running Windows 10  Enterprise or Education editions . Client PC is joined to the domain asaputra.com with  domain controller installed in Windows Server 2012 R2  named asaputra-dc1. Image file used for lock screen is named LockscreenMBG.jpg and saved in a shared folder in the DC with UNC path \\ asaputra-dc1\DomainShared\LockscreenMBG.jpg . 1. Ensure the image file is accessible Make sure that the targeted users has at least read access on the folder sharing properties and able to see the image file. 2. Creating the Group Policy Object In this example, a new policy object named “ Global Branding ” is created on the Group Policy Management Console. The setting that we must apply is named “ Force a specific default lock screen image ” and it is located at  Computer Configuration > Policies > Administrative Templates > Control Panel > Personalization . Double click the setting name to configure it. 3. Specify the lock screen image location After set it to  Enabled , type the network path where the image file resides. 4. Apply the GPO to Computer OU Since the policy applies to computer, then we must link the GPO to the OU where the computer is resides. 5. Verify the result on client computer When the policy is refreshed, you can try  signing out  or  lock the computer  to see the new lock screen image being applied. Before After Troubleshooting Tips We can always force the GPO to update right away by using command  gpupdate /force  on command prompt. When this GPO is applied successfully it will create a registry value named  LockScreenImage  in  HKLM\Software\Policies\Microsoft\Windows\Personalization  containing the image file path. If the path and file name is correct and accessible, then lock screen image will be applied without problem. And that’s how to change the default lock screen image using GPO. How to create and manage the Central Store for Group Policy Administrative Templates in Windows https://learn.microsoft.com/en-us/troubleshoot/windows-client/group-policy/create-and-manage-central-store Overview Administrative Templates files are divided into .admx files and language-specific .adml files for use by Group Policy administrators. The changes that are implemented in these files let administrators configure the same set of policies by using two languages. Administrators can configure policies by using the language-specific .adml files and the language-neutral .admx files. Administrative Templates file storage Windows uses a Central Store to store Administrative Templates files. The ADM folder is not created in a Group Policy Object (GPO) as it is done in earlier versions of Windows. Therefore, Windows domain controllers do not store or replicate redundant copies of .adm files. The Central Store To take advantage of the benefits of .admx files, you must create a Central Store in the sysvol folder on a Windows domain controller. The Central Store is a file location that is checked by the Group Policy tools by default. The Group Policy tools use all .admx files that are in the Central Store. The files that are in the Central Store are replicated to all domain controllers in the domain. We suggest keeping a repository of any ADMX/L files that you have for applications that you may want to use. For example, operating system extensions like Microsoft Desktop optimization Pack (MDOP), Microsoft Office, and also third-party applications that offer Group Policy support. To create a Central Store for .admx and .adml files, create a new folder named PolicyDefinitions in the following location (for example) on the domain controller: \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions When you already have such a folder that has a previously built Central Store, use a new folder describing the current version such as: \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions-1803 Copy all files from the PolicyDefinitions folder on a source computer to the new PolicyDefinitions folder on the domain controller. The source location can be either of the following ones: The  C:\Windows\PolicyDefinitions  folder on a Windows 8.1-based or Windows 10-based client computer The  C:\Program Files (x86)\Microsoft Group Policy\\PolicyDefinitions  folder, if you have downloaded any of the Administrative Templates separately from the links above. The PolicyDefinitions folder on the Windows domain controller stores all .admx files and .adml files for all languages that are enabled on the client computer. The .adml files are stored in a language-specific folder. For example, English (United States).adml files are stored in a folder that is named  en-US . Korean .adml files are stored in a folder that is named  ko_KR , and so on. If .adml files for additional languages are required, you must copy the folder that contains the .adml files for that language to the Central Store. When you have copied all .admx and .adml files, the PolicyDefinitions folder on the domain controller should contain the .admx files and one or more folders that contain language-specific .adml files.  Note When you copy the .admx and .adml files from a Windows 8.1-based or Windows 10-based computer, verify that the most recent updates to these files are installed. Also, make sure that the most recent Administrative Templates files are replicated. This advice also applies to service packs, as applicable. When the operating system collection is completed, merge any OS extension or application ADMX/ADML files into the new PolicyDefinitions folder. When this is finished, rename the current PolicyDefinitions folder to reflect that it's the previous version, such as PolicyDefinitions-1709. Then, rename the new folder (such as PolicyDefinitions-1803) to the production name. We suggest this approach as you can revert to the old folder in case you experience a severe problem with the new set of files. When you don't experience any problems with the new set of files, you can move the older PolicyDefinitions folder to an archive location outside sysvol folder. Group Policy administration Windows 8.1 and Windows 10 do not include Administrative Templates that have an .adm extension. We recommend that you use computers that are running Windows 8.1 or later versions of Windows to perform Group Policy administration. Updating the Administrative Templates files In Group Policy for Windows Vista and later version of Windows, if you change Administrative Templates policy settings on local computers, sysvol folder isn't automatically updated to include the new .admx or .adml files. This behavior is implemented to reduce network load and disk storage requirements, and to prevent conflicts between .admx and .adml files when changes are made to Administrative Templates policy settings across different locations. To ensure that any local updates are reflected in sysvol folder, you must manually copy the updated .admx or .adml files from the PolicyDefinitions file on the local computer to the Sysvol\PolicyDefinitions folder on the appropriate domain controller. The following update enables you to configure the Local Group Policy editor to use Local .admx files instead of the Central Store: An update is available to enable the use of Local ADMX files for Group Policy Editor . You can also use this setting to: Test a newly built folder as  C:\Windows\PolicyDefinitions  on an Administrative Workstation against your Domain Policies, before you copy it to the Central Store on sysvol folder. Use older PolicyDefinitions folder to edit policy settings that don't have an ADMX file in the latest build of your Central Store. One common example would be policies that have settings for older versions of Microsoft Office that are still in the Group Policies. Microsoft Office has a separate set of ADMX/L files for each release. Known Issues Issue 1 After you copy the Windows 10 .admx templates to the sysvol folder Central Store and overwrite all existing .admx and .adml files, select the  Policies  node under  Computer Configuration  or  User Configuration . In this situation, you may receive the following error message: Namespace 'Microsoft.Policies.Sensors.WindowsLocationProvider' is already defined as the target namespace for another file in the store. File \\\SysVol\Policies\PolicyDefinitions\Microsoft-Windows-Geolocation-WLPAdm.admx, line 5, column 110  Note In the path in this message,   represents the domain name. To resolve this problem, see  "'Microsoft.Policies.Sensors.WindowsLocationProvider' is already defined" error when you edit a policy in Windows . Issue 2 Updated ADMX/L files for Windows 10 version 1803 contain only SearchOCR.ADML. It is not compatible with an older release of SearchOCR.ADMX that you still have in the Central Store. For more information about the problem, see  "Resource '$(string ID=Win7Only)' referenced in attribute displayName could not be found" error when you open gpedit.msc in Windows . Both issues can be avoided by building a pristine PolicyDefinitions folder from a base OS release folder as described above. How to Disable NTLM Authentication in Windows Domain https://woshub.com/disable-ntlm-authentication-windows/ The key  NTLMv1  problems: weak encryption; storing password hash in the memory of the LSA service, which can be  extracted from Windows memory in plain text  using various tools (such as Mimikatz) and used for further attacks using pass-the-has scripts; the lack of mutual authentication between a server and a client, leading to data interception and unauthorized access to resources (some tools such as Responder can capture NTLM data sent over the network and use them to access the network resources); and other vulnerabilities. Some of these have been in the next version  NTLMv2  which uses more secure encryption algorithms and allows to prevent of common NTLM attacks. NTLMv1 and LM authentication protocols are disabled by default starting with Windows 7 and Windows Server 2008 R2. How to Enable NTLM Authentication Audit Logging? Before completely disabling NTLM in a domain and switching to Kerberos, it is a good idea to ensure that there are no applications in the domain that require and use NTLM auth. There may be legacy devices or services on your network that still use NTLMv1 authentication instead of NTLMv2 (or Kerberos). To track accounts or apps that use NTLM authentication, you can enable audit logging policies on all computers using GPO. Open the  Default Domain Controller Policy , navigate to the Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options section, find and enable the  Network Security: Restrict NTLM: Audit NTLM authentication in this domain  policy and set its value to  Enable all.   In the same way, enable the following policies in the Default Domain Policy: Network Security: Restrict NTLM: Audit Incoming NTLM Traffic  – set its value to  Enable auditing for domain accounts Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers : set  Audit all Once these policies are enabled, events related to the use of NTLM authentication will appear in the  Application and Services Logs-> Microsoft -> Windows -> NTLM  section of the  Event Viewer. You can analyze the events on each server or collect them to the central Windows Event Log Collector. You need to search for the events from the source Microsoft-Windows-Security-Auditing with the Event ID  4624  – “ An Account was successfully logged on “. Note the information in the “ Detailed Authentication Information ” section. If there is  NTLM  in the  Authentication Package  value, then the NTLM protocol was used to authenticate this user. Look at the value of  Package Name (NTLM only) . This line shows which protocol (LM, NTLMv1, or NTLMv2) was used for authentication. So you need to identify any servers/applications that are using the legacy protocol.   Also, if NTLM is used for authentication instead of Kerberos, Event ID  4776  will appear in the log: The computer attempted to validate the credentials for an account Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 For example, to search for all NTLMv1 authentication events on all domain controllers, you can use the following PowerShell script: $ADDCs =  Get-ADDomainController  -filter $Now = Get-Date $Yesterday = $Now.AddDays(-1) $NewOutputFile = "c:\Events\$($Yesterday.ToString('yyyyddMM'))_AD_NTLMv1_events.log" function GetEvents($DC){ Write-Host "Searching log on " $DC.HostName $Events = Get-EventLog "Security" -After $Yesterday.Date -Before $Now.Date -ComputerName $DC.HostName -Message "*NTLM V1*" -instanceid 4624 foreach($Event in $Events){ Write-Host $DC.HostName $Event.EventID $Event.TimeGenerated Out-File -FilePath $NewOutputFile -InputObject "$($Event.EventID), $($Event.MachineName), $($Event.TimeGenerated), $($Event.ReplacementStrings),($Event.message)" -Append } } foreach($DC in $ADDCs){GetEvents($DC)} Once you have identified the users and applications that use NTLM in your domain, try switching them to use Kerberos (possibly using SPN). To use Kerberos authentication, some applications need to be slightly reconfigured ( Kerberos Authentication in IIS ,  Configure different browsers for Kerberos authentication ,  Create a Keytab File Using Kerberos Auth ). From my own experience, I see that even large commercial products are still using NTLM instead of Kerberos, some products require updates or configuration changes. The idea is to identify which applications use NTLM authentication, and now you have a way to identify that software and devices. Small open-source products, old models of various network scanners (which store scans in shared network folders), some NAS devices and other old hardware, legacy software and operating systems are likely to have authentication problems when NTLMv1 is disabled. Those apps that cannot use Kerberos can be added to the exceptions. This allows them to use NTLM authentication even if it is disabled at the domain level. To do it, the  Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain  policy is used. Add the names of the servers (NetBIOS names, IP addresses, or FQDN), on which NTLM authentication can be used, to the list of exceptions as well. Ideally, this exception list should be empty. You can use the wildcard character  * .   To use Kerberos authentication in an application, you must specify the DNS name of the server, instead of its IP address. If you specify an IP address when connecting to your resources, NTLM authentication will be used. Configuring Active Directory to Force NTLMv2 via GPO Before completely disabling NTLM in an AD domain, it is recommended that you first disable its more vulnerable version,  NTLMv1 . The domain administrator needs to make sure that their network does not allow the use of NTLM or LM for authentication, as in some cases an attacker can use special requests to get a response to an NTLM/LM request. You can set the preferred authentication type using the domain GPO. Open the  Group Policy Management Editor  ( gpmc.msc ) and edit the Default Domain Controllers Policy. Go to the GPO section  Computer Configurations -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options  and find the policy  Network Security: LAN Manager authentication level . There are 6 options to choose from in the policy settings:: Send LM & NTLM responses; Send LM & NTLM responses – use NTLMv2 session security if negotiated; Send NTLM response only; Send NTLMv2 response only; Send NTLMv2 response only. Refuse LM; Send NTLMv2 response only. Refuse LM& NTLM. The NTLM authentication options are listed in the order of their security improvement. By default, Windows 7 and later operating systems use the option  Send NTLMv2 response only . If this option is enabled, client computers use NTLMv2 authentication, but AD domain controllers accept LM, NTLM, and NTLMv2 requests. NTLMv2 can be used where the Kerberos protocol has failed and for some operations (for example,  managing local groups and accounts  on the  domain-joined computers ) or in workgroups. You can change the policy value to the most secure option  6  : “ Send NTLMv2 response only. Refuse LM & NTLM ”. This policy causes domain controllers to reject LM and NTLM requests as well. You can also disable NTLMv1 through the registry. To do this, create a DWORD parameter with the name  LmCompatibilityLevel  with a value between 0 and 5 under the registry key  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa . Value 5 corresponds to the policy option “Send NTLMv2 response only. Refuse LM NTLM”.   Make sure that the  Network security: Do not store LAN Manager hash value on next password change  policy is enabled in the same GPO section. It is enabled by default starting with Windows Vista / Windows Server 2008 and prevents the creation of an LM hash.     Once you have ensured that you are not using NTLMv1, you can go further and try to disable NTLMv2.  NTLMv2  is a more secure authentication protocol but loses significantly to Kerberos in terms of security (although there are fewer vulnerabilities in NTLMv2 than in the NTLMv1, but there is still a chance of capturing and reusing data, as well as it doesn’t support mutual authentication). The main risk of disabling NTLM is the potential use of legacy or misconfigured applications that may still be using NTLM authentication. If this is the case, they will need to be updated or specially configured to switch to Kerberos. If you have a  Remote Desktop Gateway server  on your network, you will need to make an additional configuration to prevent clients from connecting using NTLMv1. Create a registry entry:   REG add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\TerminalServerGateway\Config\Core" /v EnforceChannelBinding /t REG_DWORD /d 1 /f   Restrict NTLM Completely and Use Kerberos Authentication in an AD To check how authentication works in different applications in a domain without using NTLM, you can add the accounts of the required users to the  Protected Users  domain group (it is available since the Windows Server 2012 R2 release). Members of this security group can only authenticate using Kerberos (NTLM, Digest Authentication, or  CredSSP  are not allowed). This allows you to verify that Kerberos user authentication is working correctly in different apps. Then you can completely disable NTLM on the Active Directory domain using the  Network Security: Restrict NTLM: NTLM authentication in this domain  policy. The policy has 5 options: Disable:  the policy is disabled (NTLM authentication is allowed in the domain); Deny for domain accounts to domain servers:  the domain controllers reject NTLM authentication attempts for all servers under the domain accounts, and the “NTLM is blocked” error message is displayed; Deny for domain accounts:  the domain controllers are preventing NTLM authentication attempts for all domain accounts, and the “NTLM is blocked” error appears; Deny for domain servers:  NTLM authentication requests are denied for all servers unless the server name is on the exception list in the “Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain” policy; Deny all:  the domain controllers block all NTLM requests for all domain servers and accounts. Although NTLM is now disabled on the domain, it is still used to process local logins to computers (NTLM is always used for local user logons). You can also disable incoming and outgoing NTLM traffic on domain computers using separate  Default Domain Policy  options: Network security: Restrict NTLM: Incoming NTLM traffic  = Deny all accounts Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers  = Deny all After enabling auditing, Event Viewer will also display EventID  6038  from the LsaSRV source when using NTLM for authentication: Microsoft Windows Server has detected that NTLM authentication is presently being used between clients and this server. This event occurs once per boot of the server on the first time a client uses NTLM with this server. NTLM is a weaker authentication mechanism. Please check: Which applications are using NTLM authentication? Are there configuration issues preventing the use of stronger authentication such as Kerberos authentication? If NTLM must be supported, is Extended Protection configured? You can check that Kerberos is used for user authentication with the command: klist sessions This command shows that all users are Kerberos-authenticated (except the  built-in local Administrator , who is always authenticated using NTLM). If you are experiencing a lot of  user account lockout events  after disabling NTLM, take a close look at the events with ID  4771  ( Kerberos pre-authentication failed ). Check the Failure Code in the error description. This will indicate the reason and source of the lock. To further improve Active Directory security, I recommend reading these articles: Securing administrator accounts in Active Directory How to Disable LLMNR and NetBIOS over TCP/IP ? How to Export Active Directory Users to CSV and Build Reports https://adamtheautomator.com/export-active-directory-users-to-csv/ For many Active Directory (AD) admins, retrieving users from AD was an entry point to PowerShell. PowerShell is a powerful tool for interrogating systems, and Active Directory is no exception. Searching for and returning AD users with PowerShell is just the beginning. Let’s take that up a notch and export Active Directory users to CSV! Not a reader? Watch this related video tutorial!” Not seeing the video? Make sure your ad blocker is disabled. In this tutorial, you will learn how to perform some basic AD queries with PowerShell and create handy reports. Using PowerShell, you will learn to format output by renaming columns, merging text fields, and performing calculations to develop valuable reports. Manage and Report Active Directory, Exchange and Microsoft 365 with ManageEngine ADManager Plus.  Download Free Trial! Prerequisites This tutorial will be a hands-on demonstration. If you’d like to follow along, be sure you have the following: Logged into an AD-joined computer with a domain user. PowerShell – This tutorial uses PowerShell Version 7.1.4, but any version of PowerShell should work. Windows Remote System Administration Tools (RSAT) Getting Comfortable with the  Get-ADUser  PowerShell Cmdlet Before creating reports, you must first figure out how to find the AD users you’d like to export Active Directory users to CSV. To do that, you’ll use the  Get-ADUser  cmdlet. The  Get-ADUser  cmdlet is a PowerShell cmdlet that comes with the PowerShell ActiveDirectory module. Open a PowerShell console and run the  Get-ADUser  cmdlet using the  Filter  parameter and argument of  * . Using an asterisk with the  Filter  parameter tells  Get-ADUser  to return all AD users. You’ll create more sophisticated filters a bit later. Get-ADUser -Filter * Copy The Get-AdUser cmdlet returning all users By default, the  Get-ADUser  cmdlet will return the following properties: DistinguishedName  – The full LDAP name of the user object. Enabled  – Is the user enabled, true or false. GivenName  – The user’s first name. Name  – The user’s full name. ObjectClass  – The type of AD object this is. ObjectGUID  – The ID of the AD object. SamAccountName  – This was the login name up to Windows NT4.0 SID  – Another type of Object ID. Surname  – The user’s last name. UserPrincipalName  – The user’s login name. In your report, you probably don’t need all of these properties. By default,  Get-ADUser  also returns the built-in domain Administrator and Guest accounts. You almost certainly want to exclude those. You’ll learn how in the following sections. Limiting Searches to OUs with the  SearchBase  Parameter AD users can be spread across sometimes dozens of organizational units (OUs). Sometimes, you need to limit the search to only a particular OU. To do that, you can use the  SearchBase  parameter. The  SearchBase  parameter allows you to specify a single OU as a starting point to search for users. For example, perhaps you have an ATA-Users OU with various department OUs inside, as shown below. Inside the department OUs contains all of the user accounts you’d like to include in your export to CSV. Example AD OU structure You can define the  SearchBase  argument as ATA-Users OU’s distinguished name (DN) like below to limit the search to the ATA-Users OU and all OUs inside. Get-ADUser -Filter * -SearchBase "OU=ATA-Users,DC=ATA,DC=local" Copy Get-AdUser Unfiltered Searchbase The output above displays many different properties for each user, but let’s limit that down a bit only to show the properties you might be interested in. To do this, use the  Select-Object  cmdlet only to return the  Name  and  UserPrincipalName  properties. Related: Back to Basics: Understanding PowerShell Objects Get-ADUser -Filter * -SearchBase "OU=ATA-Users,DC=ATA,DC=local" | select Name,UserPrincipalName Copy Get-ADUser Searchbase2 Perhaps you’d like to only export Active Directory users to CSV in the Sales OU. To do that, specify the  Sales  OU in the  SearchBase  parameter like below. Get-ADUser -Filter * -SearchBase "OU=Sales,OU=ATA-Users,DC=ATA,DC=local" | select Name,UserPrincipalName Copy Get-ADUser Unfiltered Searchbase3 Filtering AD User Accounts from  Get-ADUser Up to this point, you have ignored the  Filter  parameter by simply specifying an asterisk to return all users. But if you need to query only certain users matching specific criteria, the  Filter  parameter is your friend. Let’s say you’d like to eventually export all Active Directory users to a CSV inside of the ATA-Users OU, but only if they have their  Department  AD attribute set to  Sales  like the example user account below. An AD user account with Sales as a Department attribute Using the  Filter  parameter on  Get-ADUser , specify the AD attribute ( Department ), the operator  -eq  equating to “equal to” and the value of the  Department  attribute ( Sales ). Related: Understanding PowerShell Comparison Operators By Example Get-ADUser -Filter {Department -eq "Sales"} -SearchBase "OU=ATA-Users,DC=ATA,DC=local"| select Name,UserPrincipalName Copy If you have users inside the ATA-Users OU with the  Department  attribute set to  Sales ,  Get-ADUser  will only return those users. Get-ADUser only returning Sales users Maybe you’d like to include the  Department  attribute in the output. To do that, you’d typically specify the  Department  property as another property to show via the  Select-Object  ( select ) cmdlet, as shown below. But notice the  Department  property doesn’t show up. Including Department Attribute By default, the  Get-ADUser  cmdlet does not return all properties. To return all non-default properties, you must use the  Properties  parameter. In this case, tell  Get-ADUser  to return the  Department  property. Get-ADUser -Filter {Department -eq "Sales"} -SearchBase "OU=ATA-Users,DC=ATA,DC=local" -Properties Department | select Name,UserPrincipalName Copy Now that you have a basic filter, you can continue to add more criteria to the  Filter  as necessary, combining them with the PowerShell  and  and  or  operators. Below, for example,  Get-ADUser  will return all AD users that are enabled that are either in the  Sales  or  Finance  departments. Adding Criteria to the Filter In the tutorial’s environment, Steve James is an account in the  Sales  department, but his account is not enabled, so his account will not show up via the command above. Account not Enabled Exporting Active Directory Users to CSV You now have the foundational knowledge to retrieve AD users with PowerShell. The final step is to export those Active Directory users to a CSV file to create a report you can share. Related: What is a CSV File, How to Create, Open and Work with Them Let’s say you’ve built your  Get-ADUser  command, and it’s returning the users you’d like to include in your CSV report like below. This command: Retrieves all AD users in the ATA-Users OU and all child OUs. Outputs extra properties like  Department ,  PasswordLastSet , and  PasswordNeverExpires . Limits the properties returned via  Select-Object  to include in the report like  Name ,  UserPrincipalName ,  Department , and any property that begins with  Password . Notice  password*  in this example. Using an asterisk with  Select-Object  tells  Select-Object  to return all properties that start with  password . Get-ADUser -Filter * -SearchBase "OU=ATA-Users,DC=ATA,DC=local" -properties Department,PasswordLastSet,PasswordNeverExpires | Select-Object Name,UserPrincipalName,Department,password* Copy To export the Active Directory users, this command returns to CSV, pipe the objects to the  Export-Csv  cmdlet. The  Export-Csv  cmdlet is a PowerShell cmdlet that allows you to send various objects to (AD user accounts in this example) and then append those objects as CSV rows. Related: Export-Csv: Converting Objects to CSV Files To export each AD user returned in the command above, append  | Export-Csv .csv  to the end. This action pipes all of the objects that  Select-Object  returns and “converts” them into a CSV file. Get-ADUser -Filter * -SearchBase "OU=ATA-Users,DC=ATA,DC=local" -properties Department,PasswordLastSet,PasswordNeverExpires | Select-Object Name,UserPrincipalName,Department,password* | Export-CSV pass_report.csv Copy You’ll see below that  Export-Csv  creates a CSV file called  pass_report.csv  that includes headers as object property names and one row per AD user account. Example output from Export-CSV Customizing CSV Headers with  Select-Object The report you can now generate contains all the required information, but the CSV headers are not grammatically correct and can be misleading. A manager may not know what a  UserPrincipalName  is, and having column headings with multiple words without spaces is good English. To export the Active Directory users to CSV and create custom CSV headers, use the  Select-Object  cmdlet’s  calculated properties . The calculated properties feature is a way you can define custom property names and values. The  Select-Object  cmdlet’s calculated properties feature requires you to define a hashtable with two key/value pairs;  Name  to indicate the name of the property and  Expression  to represent the code to manipulate the original object property value or simply the actual property name. In this example, let’s say you’d like the CSV to show a header name of: Login Name  instead of  UserPrincipalName Password Last Set Date  instead of  PasswordLastSet Password Never Expires  instead of  PasswordNeverExpires Password Last Set Date  instead of  PasswordLastSet  that’s represented with a  short date . To make these changes, you’d first build a hashtable for each property like below. @{Name="Login Name";Expression="UserPrincipalName"} @{Name="Password Last Set Date";Expression="PasswordLastSet"} @{Name="Password Never Expires";Expression="PasswordNeverExpires"} @{Name="Password Last Set Date";Expression={$_.PasswordLastSet.ToShortDateString()}} Copy Now that you have the hashtables add them to the list of properties you provide to the  Select-Object  cmdlet just like you would a typical property name. The  Select-Object  cmdlet’s  Property  parameter accepts an array. If you have many properties to pass, you can create an array first and then pass that array to the  Property  parameter for easier readability. $properties = @( Name, @{Name="Login Name";Expression="UserPrincipalName"}, Department, @{Name="Password Last Set Date";Expression="PasswordLastSet"}, @{Name="Password Never Expires";Expression="PasswordNeverExpires"}, @{Name="Password Last Set Date";Expression={$_.PasswordLastSet.ToShortDateString()}} ) Select-Object -Property $properties Copy Combining  Get-ADUser  with the new  Select-Object  construct created above gives you the below code snippet. $properties = @( Name, @{Name="Login Name";Expression="UserPrincipalName"}, Department, @{Name="Password Last Set Date";Expression="PasswordLastSet"}, @{Name="Password Never Expires";Expression="PasswordNeverExpires"}, @{Name="Password Last Set Date";Expression={$_.PasswordLastSet.ToShortDateString()}} ) Get-ADUser -Filter * -SearchBase "OU=ATA-Users,DC=ATA,DC=local" -Properties Department,PasswordLastSet,PasswordNeverExpires | Select-Object -Property $properties | Export-CSV pass_report.csv Copy Once complete, PowerShell will create a CSV file for you that looks like the example below. CSV export of AD users using calculated properties Manage and Report Active Directory, Exchange and Microsoft 365 with ManageEngine ADManager Plus.  Download Free Trial! Conclusion PowerShell is a powerful tool for reporting on Active Directory Users. This tutorial showed you how to find and filter users based on various criteria and create a CSV file from that output using just a few lines of code. Now that you have the foundational knowledge to query AD users and export Active Directory users to CSV, where do you see yourself using this knowledge in your daily work life? How to find the source of failed logon attempts Step 1: Enable 'Audit Logon Events' policy Open 'Server Manager' on your Windows server Under 'Manage', select 'Group Policy Management' to view the 'Group Policy Management Console'. Navigate to forest>Domain>Your Domain>Domain Controllers Either create a new group policy object or you can edit an existing GPO. In the group policy editor, navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy. In Audit policies, select 'Audit logon events' and enable it for 'failure'. Step 2: Use Event Viewer to find the source of failed logon events The Event Viewer will now record an event every time there is a failed logon attempt in the domain. Look for event ID 4625 which is triggered when a failed logon is registered. Open Event Viewer in Active Directory and navigate to Windows Logs> Security. The pane in the center lists all the events that have been setup for auditing. You will have to go through events registered to look for failed logon attempts. Once you find them, you can right click on the event and select Event Properties for more details. In the window that opens, you can find the IP address of the device from which the logon was attempted. How To Fix Group Policy: Error Windows could not determine if the user and computer accounts are in the same forest If you have an issue where the User Policy doesn’t get updated and gives you an error about the user and computer accounts being in the same forest, then you’re in luck. The solution is actually rather simple, although an odd one that you usually wouldn’t run into. The full error message probably looks like this: PS C:\WINDOWS\system32> gpupdate Updating policy… Computer Policy update has completed successfully. User Policy could not be updated successfully. The following errors were encountered: The processing of Group Policy failed. Windows could not determine if the user and computer accounts are in the same forest. Ensure the user domain name matches the name of a trusted domain that resides in the same forest as the computer account. HOW TO FIX GROUP POLICY: ERROR WINDOWS COULD NOT DETERMINE IF THE USER AND COMPUTER ACCOUNTS ARE IN THE SAME FOREST To fix this error, you just need to start a Windows Service and you’ll probably want to set it to automatic to prevent the issue from coming back in the future. Click on  Start Type in  Services  and select the one with the gear icon Scroll down and look for  Netlogon , if the status is not Running, then that’s why you’re getting this issue Double-Click on  Netlogon  and change the Startup Type to  Automatic  and click the  Start  button Once the service is running, click the  OK  button Now try running  gpupdate  again How to install and configure Microsoft LAPS https://4sysops.com/archives/how-to-install-and-configure-microsoft-laps/ Download LAPS LAPS comprises three components. The interface—A PowerShell module and a fat client GUI An AD schema extension and a group policy extension The client-side component, which performs the password reset and updates Active Directory Begin by  downloading  the installation file directly from Microsoft. Note: Be sure to pay attention to the "bitness" of the installer. This walkthrough will assume a 64-bit environment. The LAPS interface does not need to be installed on a specific server. It can be installed on a purpose-built server or a shared server. You should select a server that your intended audience can already log on to and which is joined to the domain you intend to manage. Install LAPS Log on to your target server with local admin rights. Click  Next  on the Welcome screen. Welcome screen Select all available components and click  Next . Selecting the components Extend the AD Schema For this step, the logged-on user account will need to be a member of the Schema Admins group in Active Directory. Extend the AD schema by running the following commands from the LAPS PowerShell module you just installed: Import-module AdmPwd.PS Update-AdmPwdADSchema Extending the schema Check and set the necessary admin permissions Check and set the permissions on each OU that you will manage with LAPS by using these PowerShell commands: Find-AdmPwdExtendedRights -Identity “Workstations” | ft Check existing permissions By default, only the local system account and the domain admins group will have access to the passwords stored in AD. If your domain admins are not the same people that will manage the target machines, you can remove them from this group and add your own custom group. Be sure you don't skip these steps. Not setting the permissions correctly could expose administrator passwords to inappropriate users. To remove access from an existing user or group, open the security properties for each LAPS-managed OU in Active Directory Users and Computers. Open the  Advanced Security Settings  and select the security principal to be modified. Remove the  All Extended Rights  permission, and click  OK  on the permissions window and each parent window. Remove permissions Verify that the security group has been removed by rerunning the  Find-AdmPwdExtendedRights  PowerShell command: Find-AdmPwdExtendedRights -Identity "Workstation" | ft Confirm permissions removed Add the permissions for the group that will have access to the passwords: Set-AdmPwdReadPasswordPermission -Identity "Workstations" -AllowedPrincipals "EndPointPasswordManagers" Note that these permissions are recursive and will apply to the selected OU and everything below it in the tree. After adding the permissions, verify again using the  Find-AdmPwd  command. Add permissions and confirm Grant REST permission to computers The next step is to allow the computers to update their own admin passwords in the new AD attributes. This needs to be done on all LAPS-managed OUs and is done using the following command: Set-AdmPwdComputerSelfPermission -Identity “Workstations” Add computer permissions Create the Group Policy Now that Active Directory is ready to receive and store passwords and the appropriate permissions have been assigned to view the passwords, we need to create a policy to configure the LAPS client component. I recommend using a test OU or a test group of machines to begin with until you are confident that everything works. Open the Group Policy Management Editor on your administration machine or domain controller. Locate the "Workstations" OU, and right-click it. Select Create a  GPO in this domain, and Link it here . Give the Group Policy a meaningful name and click  OK . Creating the GPO Right-click your new GPO and select  Edit . Navigate to  Computer Configuration > Policies > Administrative Templates > LAPS . Review the settings and apply the values appropriate for your scenario and your organization. Policy settings The  Password Settings  policy determines the length of the password and the maximum age it can reach before it resets. When the password is reset, the timestamp of the reset date will be recorded in AD. If the time elapsed since the timestamp date and the current date exceeds this value, the computer will reset the password and update AD with the new password and current date and time. Password settings Name the administrator account to manage. If you want to manage the built-in administrator account, leave this setting alone. LAPS will identify the account by the SID even if the account has been renamed. If you have a specific account you want to manage, such as a company admin account, select  Enabled  and enter the account name. Selecting the admin account Do not allow a password expiration time that is longer than required by policy. Set this to  Enabled . This will ensure that passwords cannot be forced to have a longer validity period than has been defined in your policy. Password expiration settings Enable local admin password management. Set this to  Enabled . This will enable the passwords to be managed for all machines within the scope of this group policy. Enabled local admin password The following settings will distribute the LAPS client to all in-scope machines. The LAPS client is the tool that will run on each Windows machine to ensure the local password complies with policy. It also updates the AD attributes with the timestamp and new password. This can be done in any number of ways, from a GPO to an SCCM or InTune package to a third-party software deployment tool. Any system that will deliver and install the executable can be used. In this guide, I have used the same Group Policy that will configure the client. To create the software deployment policy, you first need to place the installation file on a share that will be accessible to all users/machines. I have shared a subfolder of the domain controller  netlogon  folder. The advantage of this is that it will replicate to all domain controllers automatically, so by using \\domain\share, each client will get the software from their local AD site (note you still need to create the share on each DC unless you put the installer in  netlogon ). In the GPMC, navigate to  Computer Configuration > Policies > Software Settings > Software installation . Right-click  Software installation  and select  New > Package . Browse to the share referenced above, select the installer, and click  Open . Again, be sure to use the correct "bitness." Here, I am using x64 since all of my machines are 64-bit. Client software push Select the  Assigned  installation type and click  OK . This will ensure that the software is delivered to machines without user intervention. Software push assigned You will then be returned to the Group Policy settings, where you will see the new software installation settings. You can now close the Group Policy Editor. LAPS software push policy You are now ready to use LAPS. It will take some time for the group policy to be delivered to all machines and for the client to install—so don't expect immediate results. But over the next few hours, or if machines are rebooted, you will see the policies begin to take effect. Accessing passwords Now that your machines are generating random passwords and storing them in Active Directory, you need to be able to get to them. Open the LAPS UI on the management server you used when you installed LAPS at the beginning of this guide. If you are in the security group that was granted access to the LAPS AD attributes, you will be able to paste the machine name and search for the corresponding details: LAPS GUI If you need to query multiple machines, or you just prefer the command line, you can also use the PowerShell module to query the password: Get-AdmPwdPassword -ComputerName "AZ-0183-3116-95" LAPS PowerShell command Trust but verify Once your deployment is complete, you're going to want to test it before rolling it out to everyone. To test, simply select a test machine that you have access to and retrieve the password using either of the methods above. Log in as a restricted user, then locate an application such as Notepad. Right-click (or shift-right-click) the shortcut and select  Run as different user . Run As Test Enter the credentials that you got from the LAPS UI or PowerShell output into the security prompt. Test password If everything has gone according to plan, the application will open with elevated access. You can now adjust the scope of your GPO to apply it to all target devices. How to Remove (Demote) a Domain Controller in Active Directory Removing an Active Directory Domain Controller and ADDS Role (Step-by-Step) If you are going to decommission one of your AD domain controllers (common DC or  read-only domain controller – RODC ), you have to take some preparatory steps before demoting your domain controller to a member server and removing the Active Directory Domain Services (ADDS) role. Check the state of your domain controller, Active Directory, and replication. There is a separate article on how to  check a domain controller’s health and replication in AD  using  dcdiag ,  repadmin , and PowerShell scripts. Fix the issues if found. To display a list of errors on a specific domain controller, run the following command:  dcdiag.exe /s:mun-dc03 /q Make sure that the AD FSMO roles are not running on the domain controller:  netdom query fsmo    If needed,  move the FSMO roles to another DC . Make sure that the DHCP server role is not running on the domain controller. If it is, migrate it to another server; Change DNS settings for the DHCP scopes that are assigning IP addresses to the clients. Change the configuration of the DHCP scopes so that they assign a different DNS server address (wait for the IP lease time to expire so that all clients get new DNS server settings). You can display a list of DNS servers set for all zones ( DNS Servers Option 006 ) on a server using the following PowerShell command (learn more about  how to manage DHCP in Windows Server using PowerShell ):  Get-DhcpServerv4Scope -ComputerName mun-dhcp.woshub.com| Get-DhcpServerv4OptionValue | Where-Object {$_.OptionID -like 6} | FT Value Some clients may be manually set to use a DNS server on the DC (network devices, servers, printers, scanners, etc.). You need to find such devices and reconfigure them to another DNS server. It is easier to find such devices accessing your DNS server by its logs. Here is a detailed article:  How to Audit Client DNS Queries in Windows Server ; If a Certificate Authority role is running on the domain controller, migrate it to another server; If other services (like a  KMS server , Radius/NPS,  WSUS , etc.) are running on the domain controller, decide whether you want to move them to other hosts; Use the  Test-ADDSDomainControllerUninstallation  cmdlet to make sure if there are any dependencies or issues you may come across when removing a DC. If the cmdlet returns  Success , you may move on.  You are now ready to demote the domain controller to a member server. Prior to Windows Server 201, the  dcpromo  command was used for this. In modern Windows Server editions, this tool is deprecated and is not recommended to be used. You can demote your domain controller using the  Server Manager . Open Server Manager -> Remote Roles and Features -> uncheck  Active Directory Domain Services  in the Server Roles section. Click  Demote this domain controller . The Active Directory Domain Services Configuration Wizard appears.  Force the removal of this domain controller  option is used to remove the last domain controller in adomain.  Do not  use it. Later we will delete all DC metadata manually. In the next screen, check the  Proceed with removal  option. Then set the local server administrator password. Then you just need to click  Demote . Wait till the domain controller demotion is over. The following message will appear:  Successfully demoted the Active Directory Domain Controller . Restart your Windows Server host. Open the Server Manager again to remove the Active Directory Domain Services role. When removing the ADDS role, the following components will be removed by default: Active Directory Module for Windows PowerShell AD DS and AD LDS Tools feature Active Directory Administrative Center AD DS Snap-ins and Command-line Tools DNS Server Group Policy Management Console  ( gpmc.msc ) Run the  Active Directory Users and Computers console (dsa.msc)  and make sure that the domain controller computer account has been removed from the Domain Controllers OU. You can also uninstall a domain controller using the  Uninstall-ADDSDomainController  PowerShell cmdlet. The command will prompt you to set a local administrator password and confirm the DC demotion. After the restart, you will just  remove the ADDS role using PowerShell : Uninstall-WindowsFeature AD-Domain-Services -IncludeManagementTools Then open the Active Directory Sites and Services ( dssite.msc ) console, find the domain controller site, and its account in the Servers section. Expand the DC, right-click the NTDS Settings, and select  Delete . Confirm the DC removal by checking  Delete This Domain controller anyway. It is permanently offline and can no longer be removed using the removal wizard . Then delete the server account. Wait till the AD replication is over and check the domain state using  dcdiag  and  repadmin  commands (described above). How to Remove a Failed Domain Controller in Active Directory? If your domain controller has failed (physical server or virtual DC files on storage) and you are not going to  restore the DC  from the  domain controller backup  created earlier, you can force delete it. Important . A domain controller removed in this way should never be brought online. In Windows Server 2008 R2 or earlier, the  ntdsutil  tool was used to remove a failed domain controller and clear its metadata from AD. In the current Windows Server 2022/2019/2016/2012, you can delete the failed DC and clear its metadata correctly using graphic AD management MMC snap-ins. Open the ADUC console ( dsa.msc ) and navigate to the  Domain Controllers . Find your DC account and delete it. A window to confirm deleting the domain controller appears. Check  Delete this Domain Controller anyway . Click  Delete . Active Directory will automatically clear the metadata of the removed DC from the ntds.dit database. Then delete the domain controller in the AD Sites and Services console as shown above. And the last step is to remove the domain controller records from the DNS. Open the DNS Manager ( dnsmgmt.msc ). Remove the server from the Name Servers list in the zone settings. Remove static Name Servers (NS) records related to the deleted DC in your DNS zone and  _msdcs ,  _sites ,  _tcp ,  _udp  sections, as well as PTR records in the reverse lookup zone. Or use  PowerShell to find and remove records in DNS . Here is a step-by-step guide showing how to uninstall a domain controller or delete a failed DC from Active Directory. How to Remove (Demote) a Domain Controller in Active Directory https://woshub.com/remove-domain-controller-active-directory/ Removing an Active Directory Domain Controller and ADDS Role (Step-by-Step) If you are going to decommission one of your AD domain controllers (common DC or  read-only domain controller – RODC ), you have to take some preparatory steps before demoting your domain controller to a member server and removing the Active Directory Domain Services (ADDS) role. Check the state of your domain controller, Active Directory, and replication. There is a separate article on how to  check a domain controller’s health and replication in AD  using  dcdiag ,  repadmin , and PowerShell scripts. Fix the issues if found. To display a list of errors on a specific domain controller, run the following command:  dcdiag.exe /s:mun-dc03 /q Make sure that the AD FSMO roles are not running on the domain controller:  netdom query fsmo    If needed,  move the FSMO roles to another DC . Make sure that the DHCP server role is not running on the domain controller. If it is, migrate it to another server; Change DNS settings for the DHCP scopes that are assigning IP addresses to the clients. Change the configuration of the DHCP scopes so that they assign a different DNS server address (wait for the IP lease time to expire so that all clients get new DNS server settings). You can display a list of DNS servers set for all zones ( DNS Servers Option 006 ) on a server using the following PowerShell command (learn more about  how to manage DHCP in Windows Server using PowerShell ):  Get-DhcpServerv4Scope -ComputerName mun-dhcp.woshub.com| Get-DhcpServerv4OptionValue | Where-Object {$_.OptionID -like 6} | FT Value Some clients may be manually set to use a DNS server on the DC (network devices, servers, printers, scanners, etc.). You need to find such devices and reconfigure them to another DNS server. It is easier to find such devices accessing your DNS server by its logs. Here is a detailed article:  How to Audit Client DNS Queries in Windows Server ; If a Certificate Authority role is running on the domain controller, migrate it to another server; If other services (like a  KMS server , Radius/NPS,  WSUS , etc.) are running on the domain controller, decide whether you want to move them to other hosts; Use the  Test-ADDSDomainControllerUninstallation  cmdlet to make sure if there are any dependencies or issues you may come across when removing a DC. If the cmdlet returns  Success , you may move on.  You are now ready to demote the domain controller to a member server. Prior to Windows Server 201, the  dcpromo  command was used for this. In modern Windows Server editions, this tool is deprecated and is not recommended to be used. You can demote your domain controller using the  Server Manager . Open Server Manager -> Remote Roles and Features -> uncheck  Active Directory Domain Services  in the Server Roles section.   Click  Demote this domain controller . The Active Directory Domain Services Configuration Wizard appears.  Force the removal of this domain controller  option is used to remove the last domain controller in adomain.  Do not  use it. Later we will delete all DC metadata manually. In the next screen, check the  Proceed with removal  option. Then set the local server administrator password.   Then you just need to click  Demote . Wait till the domain controller demotion is over. The following message will appear:  Successfully demoted the Active Directory Domain Controller . Restart your Windows Server host. Open the Server Manager again to remove the Active Directory Domain Services role. When removing the ADDS role, the following components will be removed by default:   Active Directory Module for Windows PowerShell AD DS and AD LDS Tools feature Active Directory Administrative Center AD DS Snap-ins and Command-line Tools DNS Server Group Policy Management Console  ( gpmc.msc ) Run the  Active Directory Users and Computers console (dsa.msc)  and make sure that the domain controller computer account has been removed from the Domain Controllers OU. You can also uninstall a domain controller using the  Uninstall-ADDSDomainController  PowerShell cmdlet. The command will prompt you to set a local administrator password and confirm the DC demotion. After the restart, you will just  remove the ADDS role using PowerShell : Uninstall-WindowsFeature AD-Domain-Services -IncludeManagementTools Then open the Active Directory Sites and Services ( dssite.msc ) console, find the domain controller site, and its account in the Servers section. Expand the DC, right-click the NTDS Settings, and select  Delete . Confirm the DC removal by checking  Delete This Domain controller anyway. It is permanently offline and can no longer be removed using the removal wizard .   Then delete the server account. Wait till the AD replication is over and check the domain state using  dcdiag  and  repadmin  commands (described above). How to Remove a Failed Domain Controller in Active Directory? If your domain controller has failed (physical server or virtual DC files on storage) and you are not going to  restore the DC  from the  domain controller backup  created earlier, you can force delete it. Important . A domain controller removed in this way should never be brought online. In Windows Server 2008 R2 or earlier, the  ntdsutil  tool was used to remove a failed domain controller and clear its metadata from AD. In the current Windows Server 2022/2019/2016/2012, you can delete the failed DC and clear its metadata correctly using graphic AD management MMC snap-ins. Open the ADUC console ( dsa.msc ) and navigate to the  Domain Controllers . Find your DC account and delete it. A window to confirm deleting the domain controller appears. Check  Delete this Domain Controller anyway . Click  Delete . Active Directory will automatically clear the metadata of the removed DC from the ntds.dit database. Then delete the domain controller in the AD Sites and Services console as shown above. And the last step is to remove the domain controller records from the DNS. Open the DNS Manager ( dnsmgmt.msc ). Remove the server from the Name Servers list in the zone settings. Remove static Name Servers (NS) records related to the deleted DC in your DNS zone and  _msdcs ,  _sites ,  _tcp ,  _udp  sections, as well as PTR records in the reverse lookup zone. Or use  PowerShell to find and remove records in DNS . Here is a step-by-step guide showing how to uninstall a domain controller or delete a failed DC from Active Directory.   How to store BitLocker keys in Active Directory https://coady.tech/store-bitlocker-keys-in-ad/ BitLocker is a fantastic way to protect the data stored on computers and thwart some offline tampering attacks. However, if you’re using BitLocker within a business environment, keeping track of the recovery keys can be quite burdensome. Thankfully Microsoft has developed a way to automatically save BitLocker recovery keys to active directory. In this post I’m going to be going through the process, step-by-step, to enable BitLocker recovery key saving to active directory. Plus we’ll take a look at how computers that are already encrypted can retrospectively have their recovery keys backed up to active directory. 1.0 Requirements Windows 7 or newer client (Must be either Pro or Enterprise) Windows Server 2012 or newer domain controller Domain schema level of at least ‘Windows Server 2012’ Latest group policy  ADMX files This guide will show the steps specifically for Windows 10 1909 and Windows Server 2019. 2.0 Setup Steps 2.1 Installing BitLocker So that we can access the Bitlocker recovery keys, we’ll need to install the BitLocker feature on a domain controller (DC). This feature will add an additional tab within Active Directory Users and Computers to access the recovery keys. It doesn’t mean the domain controller will be encrypted, just that the necessary GUI administration tools will be installed. On a domain controller open Server Manager and then launch the Add Roles and Features Wizard. Tick the ‘BitLocker Drive Encryption’ option under Features. You will be prompted to install additional tools. Select ‘Add Features’. Leave the feature install to complete. The BitLocker administrator tools will now be installed. Later in the guide we’ll use those tools to view the stored BitLocker recovery keys. 2.2 Update group policy Client computers will need to forward their recovery keys to active directory. In order to do this we’ll use group policy. In my experience the correct group policy options aren’t always shown out-of-the-box, so I’m going to use the latest template file. Plus it’s always good practice to use the latest group policy templates. Download the latest ADMX files for your build of Windows  here . Inside of the ZIP archive will be many group policy ADMX files along with folders for each language. Extract these files to the ‘PolicyDefinitions’ folder within the SYSVOL share on a domain controller. E.g. C:\Windows\SYSVOL\mydomain.local\Policies\PolicyDefinitions Tip If you don’t have a ‘PolicyDefinitions’ folder now would be a great time to create one. The folder is used by a feature called the ‘Group Policy Central Store’. It ensures all domain administrators are using the same group policy template files. Once finished you should have a setup similar to mine, as shown below: 2.3 Configuring BitLocker Create a new group policy object targeted at your computers. Open the policy for editing and then browse to: Computer Configuration > Policies > Administrative Templates > Windows Components > Bitlocker Drive Encryption > Operating System Drives. Configure the policy “Choose how BitLocker-protected operating system drives can be recovered” and set it as shown below: Save the changes and then exit the group policy editor. We’re done! Now it’s time to test our changes. 3.0 Encrypting computers If you’ve completed the previous steps, BitLocker should be automatically saving recovery keys to active directory when the OS volume is encrypted. For the purpose of this guide I’m going to encrypt my test client machine the simple way – by right-click’ing on the C volume and following the ‘Turn BitLocker on’ wizard. 4.0 Recovering the BitLocker key Following our work in Step 1, a new ‘BitLocker Recovery’ tab will be present within active directory computer objects. On a domain controller open Active Directory Users and Computers and then locate the relevant computer account. Double click on the computer account to open the properties dialogue. Select the ‘BitLocker Recovery’ tab. This will list all of the recovery keys for the computer in question. If there are multiple entries select the top one. Multiple entries will show up if the computer has been encrypted/decrypted multiple times. The recovery password (circled in red) can be entered into the BitLocker recovery screen on a client device like so: 5.0 Backup existing BitLocker keys to AD Backing up the recovery keys to active directory on already encrypted devices is possible too. Open PowerShell as an administrator on an encrypted computer and run the command: 1 manage-bde -protectors -get C: This will return an output similar to the following: Note the ID number for the numerical password above (circled in red). Use that in the following command: 1 manage-bde -protectors -adbackup C: -id {87F55347-BF79-4110-BB3F-6F4B69A7A518} That’s it! If you now check the computer object in active directory it will have the client’s key stored. 6.0 Summary In this post I’ve gone over the steps needed to automatically store BitLocker recovery keys in active directory for new BitLocker installations, and covered one method to add recovery information for existing PC’s too.   Data security and protecting sensitive information is a top priority for organizations of all sizes. One crucial aspect of data security is ensuring that data stored on devices like laptops and desktops is encrypted and can be recovered in case of emergencies or user lockouts. BitLocker, a disk encryption program with Windows operating systems, provides a robust solution. BitLocker offers a feature that allows administrators to store BitLocker recovery keys using Active Directory, ensuring that these critical keys are securely managed and easily accessible when needed. In this blog post, we will explore the process of enabling BitLocker recovery key backup via Group Policy Objects (GPO) and several ways to retrieve BitLocker recovery keys. Table of Contents Requirements Active Directory Schema Windows Client Enabling BitLocker Recovery Key Backup via GPO Turn On BitLocker Protection on Drives Retrieving BitLocker Recovery Keys Using the BitLocker Recovery Tab in the Computer Properties Using the “Find BitLocker recovery password” Tool Using PowerShell Script Delegating Permissions to View BitLocker Recover Keys in AD Conclusion Requirements Active Directory Schema BitLocker recovery data storage feature is based on the extension of the Active Directory schema. And it brings you extra  Active Directory custom attributes . You must verify if your AD schema version has attributes required to store BitLocker recovery keys in Active Directory and check if you need to  update the AD schema . To do this, run the following command from the  PowerShell Active Directory module : Import-module ActiveDirectory Get-ADObject -SearchBase ((GET-ADRootDSE).SchemaNamingContext) -Filter {Name -like 'ms-FVE-*'} There should be five following attributes: ms-FVE-KeyPackage ms-FVE-RecoveryGuid ms-FVE-RecoveryInformation ms-FVE-RecoveryPassword ms-FVE-VolumeGuid These  attributes  are available by default starting from Active Directory version on Windows Server 2012. This article uses Windows Server 2022. Windows Client BitLocker works with Windows 10 and 11 Pro, Education, and Enterprise. This article will be using Windows 11 22H2. Enabling BitLocker Recovery Key Backup via GPO Users make changes to their computers, and that’s inevitable. Then they reboot their computers, and BAM! Windows is asking for the BitLocker recovery key (password). In this situation, users will contact the helpdesk or system administrators to help recover their BitLocker recovery keys. Administrators must enable their backup to Active Directory to ensure the BitLocker keys are recoverable. Log in to the domain controller or computer with RSAT installed. Open the  Group Policy Management Console  (GPMC) by running  gpmc.msc . Within the GPMC, create a new Group Policy Object (GPO) or edit an existing one that you want to use for BitLocker recovery key backup. Ensure that the GPO is linked to the organizational unit (OU) containing the computer objects to which you wish to apply BitLocker. In this example, I’m creating a new GPO named “ BitLocker-WS-Policy ” in the “ Workstations ” OU. Open the GPO for editing and navigate to  Computer Configuration → Policies → Administrative Templates → Windows Components → BitLocker Drive Encryption . Double-click on “ Store BitLocker Recovery information in Active Directory Domain Services. ” Set the policy to  Enabled , leave the default selection, as shown below, and click  OK . This step enables backing up the BitLocker recovery information in Active Directory. Next, select one of the following folders, depending on which drive types you want BitLocker recovery keys to become retrievable. Operating System Drives Fixed Data Drives Removable Data Drives In this example, I’ll choose “ Operating System Drives ” and open the “ Choose how BitLocker-protected system drives can be recovered ” policy. Select  Enabled  and tick the box, “ Do not enable BitLocker until recovery information is stored in AD DS for  .” These settings enable the recoverability of BitLocker keys, and BitLocker will not be enabled until recovery information is stored in AD DS. The policy will be updated on the target computers in the next cycle. But if you want to force it, run  gpupdate /force  on the affected computers. Then, check if the policy is applied: gpresult /r Turn On BitLocker Protection on Drives Now that the policy is deployed to back up BitLocker recovery keys in AD, let’s test it by turning on BitLocker protection. Open the File Explorer, navigate to “ This PC ,” right-click on the drive, and click “ Turn on BitLocker .” And go through the steps to finish enabling BitLocker encryption. Refer to  Turn on device encryption  for the complete steps the user can follow. Retrieving BitLocker Recovery Keys You can find available recovery keys for each computer on the new tab “BitLocker Recovery”. It is located in the computer account properties in the  Active Directory Users and Computers snap-in . But first, the BitLocker Management Tools must be installed on the domain controller. To do so, run the following command to install the BitLocker Management Tools. Install-WindowsFeature RSAT-Feature-Tools-BitLocker-BdeAducExt Using the BitLocker Recovery Tab in the Computer Properties After the installation, re-open ADUC, open the computer’s properties, and navigate to the “ BitLocker Recovery ” tab. You’ll see the recovery password that you can provide to the user so they can unlock their BitLocker-protected drive. Using the “Find BitLocker recovery password” Tool If the user can provide the first eight characters of the BitLocker password ID, you can also use the  Find BitLocker recovery password  tool in ADUC. Open ADUC, click Action → Find BitLocker recovery password. Enter the first eight characters of the password ID and click  Search . If the partial password ID is valid, you will see the corresponding BitLocker recovery password, as shown below. Using PowerShell Script Using a PowerShell script to retrieve the BitLocker recovery keys can be quick, convenient, and handy. It only requires the ActiveDirectory PowerShell module; all necessary commands are already included. Copy the script below and save it to your computer as Get-BitLockerRecoveryPassword.ps1. This script accepts two parameters:  ComputerName  and  KeyId . You can only use one parameter at a time. # Get-BitLockerRecoveryPassword.ps1 [CmdletBinding(DefaultParameterSetName = ‘byComputerName’)] param ( [Parameter(Mandatory, ParameterSetName = ‘byComputerName’)] [string] $ComputerName, [Parameter(Mandatory, ParameterSetName = ‘byKeyId’)] [string] $KeyID ) if ($PSCmdlet.ParameterSetName -eq ‘byComputerName’) { try { $computerObj = Get-ADComputer $ComputerName -ErrorAction Stop $blObj = Get-ADObject -Filter { objectclass -eq ‘msFVE-RecoveryInformation’ } -SearchBase $computerObj.DistinguishedName -Properties * -ErrorAction Stop } catch [Microsoft.ActiveDirectory.Management.ADIdentityNotFoundException] { “The AD computer [$($ComputerName)] is not found.” | Out-Default } catch { } } if ($PSCmdlet.ParameterSetName -eq ‘byKeyId’) { if ($KeyID.Length -eq 8) { $keyId = “*{$keyID*” $blObj = Get-ADObject -Filter { objectclass -eq ‘msFVE-RecoveryInformation’ -and CN -like $KeyID } -Properties * } else { “The KeyId must be exactly the first 8 characters of the Password ID.” | Out-Default } } if ($blObj) { [PSCustomObject]$([ordered]@{ ‘Computer Name’ = $(($blObj.DistinguishedName -split ‘,’)[1].Replace(‘CN=’, ”)) ‘Password ID’ = $(([regex]::Match($blObj.DistinguishedName, ‘\{(.*?)\}’)).Groups[1].Value) ‘Recovery Password’ = $($blObj.’msFVE-RecoveryPassword’) }) } You can also download this script from this Gist →  Get BitLocker Recovery Password from AD . After saving the script, open PowerShell and change the working directory to the script location. cd Run the command below to get the BitLocker recovery key by computer name. .\Get-BitLockerRecoveryPassword.ps1 -ComputerName You’ll see the following result if the computer exists and has a BitLocker recovery password. If the computer does not exist, you’ll get this error: There will be no output if the computer exists but has no BitLocker recovery keys. Run the command below to get the BitLocker recovery key by looking up the first eight characters of the Password ID. .\get-BitLockerRecoveryPassword.ps1 -KeyID 12345678 If the password ID matches, you’ll get the following result. You’ll get the following error if the Key ID you provided is not eight characters. If the password ID is not found, there will be no result. Delegating Permissions to View BitLocker Recover Keys in AD Administrators have better things to do than retrieving BitLocker recovery passwords. This is why the task can be delegated to a group whose primary role is to support end users, such as the Help Desk. You can delegate the permissions to view information about BitLocker recovery keys in AD, and here’s how. Create a group (or select an existing group) that will be delegated to view BitLocker recovery keys. In this example, I created a security group called “ BitLocker Password Viewers .” Add members to this group as needed. Right-click on the  Active Directory OU  that contains the computer objects with BitLocker recovery keys and click  Delegate Control . Add the delegate group to the list and click  Next . Select the “ Create a custom task to delegate ” option and click  Next . Select the “ Only the following objects in the folder ” option, tick the “ msFVE-RecoveryInformation objects ” box, and click  Next . Select the “Read” permissions, as shown below, and click  Next . Review the delegation summary and click  Finish . All users added to the “ BitLocker Password Viewers ” group can view the Recovery tab with BitLocker recovery information. Conclusion Safeguarding sensitive data is a paramount concern. Integrated with Windows, BitLocker offers a robust solution for encrypting and protecting data on devices like laptops and desktops. It securely manages and readily provides BitLocker recovery keys via Active Directory. This blog post covers enabling BitLocker recovery key backup via Group Policy Objects (GPO) and retrieving keys. Prerequisites include an updated Active Directory schema and compatible Windows clients. Follow the steps for GPO configuration to ensure recoverability and secure storage in Active Directory. We also explore three key retrieval methods: the BitLocker Recovery tab in Active Directory Users and Computers, the “Find BitLocker recovery password” tool, and a PowerShell script. These options offer flexibility for different scenarios. Lastly, we discuss delegating permissions to specific groups, like a Help Desk team, to view BitLocker recovery keys in Active Directory efficiently. BitLocker simplifies data security and management, enhancing organizations’ data protection strategies. Joining Active Directory Error https://www.truenas.com/community/threads/joining-active-directory-error.97316/ Hi everyone, Im kinda new to TrueNAS and I'm working on a small proof of concept for school. I'm stuck with one problem: When I'm trying to join my domain it gives this error: I can ping the domain and the domain controller. Anyone knows a fix? anodos Sambassador iXsystems Joined Mar 6, 2014 Messages 9,407 Dec 9, 2021 #2 What version is this? SMB Permissions Overview B bartqn4 Dabbler Joined Dec 9, 2021 Messages 10 Dec 9, 2021 #3 anodos said: What version is this? 12.0 Samuel Tai Never underestimate your own stupidity Moderator Joined Apr 24, 2020 Messages 5,357 Dec 9, 2021 #4 What's the full version? 12.0 doesn't tell us that much. Show :  13.0-U5.3 build, running since 9.3 (2015) B bartqn4 Dabbler Joined Dec 9, 2021 Messages 10 Dec 9, 2021 #5 Samuel Tai said: What's the full version? 12.0 doesn't tell us that much. CORE 12.0 Is that the full version name? Samuel Tai Never underestimate your own stupidity Moderator Joined Apr 24, 2020 Messages 5,357 Dec 9, 2021 #6 bartqn4 said: CORE 12.0 Is that the full version name? What does the version show in System Information widget in the Dashboard? We're looking for something like 12.0-U7. Show :  13.0-U5.3 build, running since 9.3 (2015) B bartqn4 Dabbler Joined Dec 9, 2021 Messages 10 Dec 9, 2021 #7 Samuel Tai said: What does the version show in System Information widget in the Dashboard? We're looking for something like 12.0-U7. 12.0-U5 Samuel Tai Never underestimate your own stupidity Moderator Joined Apr 24, 2020 Messages 5,357 Dec 9, 2021 #8 For the domain account name, try just the account without the domain in front. It's probably prepending the domain in front of your domain\account, so of course there won't be an account matching domain\domain\account. Show :  13.0-U5.3 build, running since 9.3 (2015) anodos Sambassador iXsystems Joined Mar 6, 2014 Messages 9,407 Dec 9, 2021 #9 12.0-U5 update to U7, there is a critical winbindd security vulnerability in U5, otherwise Samuel Tai is right. Later versions also have better error reporting. SMB Permissions Overview B bartqn4 Dabbler Joined Dec 9, 2021 Messages 10 Dec 9, 2021 #10 Samuel Tai said: For the domain account name, try just the account without the domain in front. It's probably prepending the domain in front of your domain\account, so of course there won't be an account matching domain\domain\account. I tried that already, didn't work B bartqn4 Dabbler Joined Dec 9, 2021 Messages 10 Dec 10, 2021 #11 anodos said: update to U7, there is a critical winbindd security vulnerability in U5, otherwise Samuel Tai is right. Later versions also have better error reporting. Did this, same error. Should be something with the domain account then right? Samuel Tai Never underestimate your own stupidity Moderator Joined Apr 24, 2020 Messages 5,357 Dec 10, 2021 #12 Are you leaving the \ in front of the account? Show :  13.0-U5.3 build, running since 9.3 (2015) B bartqn4 Dabbler Joined Dec 9, 2021 Messages 10 Dec 10, 2021 #13 Samuel Tai said: Are you leaving the \ in front of the account? Both not working, so DOMAIN\Administrator and Administrator not working Samuel Tai Never underestimate your own stupidity Moderator Joined Apr 24, 2020 Messages 5,357 Dec 10, 2021 #14 How is your domain set up? This smells like password authentication for Administrator has been disabled. Also, have you looked at the manual?  https://www.truenas.com/docs/core/directoryservices/activedirectory/ You've already stated DNS is working. How about NTP? Are you sync'ed to the DC? Are you using the NetBIOS domain or the DNS domain for your forest? Show :  13.0-U5.3 build, running since 9.3 (2015) B bartqn4 Dabbler Joined Dec 9, 2021 Messages 10 Dec 10, 2021 #15 Samuel Tai said: How is your domain set up? This smells like password authentication for Administrator has been disabled. Also, have you looked at the manual?  https://www.truenas.com/docs/core/directoryservices/activedirectory/ You've already stated DNS is working. How about NTP? Are you sync'ed to the DC? Are you using the NetBIOS domain or the DNS domain for your forest? Yes, NTP is enabled. I think I'm using the DNS domain. How do I check password authentication option? anodos Sambassador iXsystems Joined Mar 6, 2014 Messages 9,407 Dec 10, 2021 #16 The particular place you're failing at is when we try to kinit to get a kerberos ticket. You can try to kinit from CLI by running command `kinit administrator@fqdn`. It might give more useful information. SMB Permissions Overview B bartqn4 Dabbler Joined Dec 9, 2021 Messages 10 Dec 10, 2021 #17 anodos said: The particular place you're failing at is when we try to kinit to get a kerberos ticket. You can try to kinit from CLI by running command `kinit administrator@fqdn`. It might give more useful information. I haven't set up Kerberos or anything tho, should I do that? Kinda new to this stuff. Samuel Tai Never underestimate your own stupidity Moderator Joined Apr 24, 2020 Messages 5,357 Dec 10, 2021 #18 AD  requires  Kerberos. No wonder it's not working. You're just trying to join an ordinary domain. Show :  13.0-U5.3 build, running since 9.3 (2015) B bartqn4 Dabbler Joined Dec 9, 2021 Messages 10 Dec 10, 2021 #19 Samuel Tai said: AD  requires  Kerberos. No wonder it's not working. You're just trying to join an ordinary domain. Thanks! Will try that tomorrow anodos Sambassador iXsystems Joined Mar 6, 2014 Messages 9,407 Dec 10, 2021 #20 AD  requires  Kerberos. No wonder it's not working. You're just trying to join an ordinary domain. In theory if you have properly-functioning DNS, the OS kerberos client should allow you to kinit if you specify the FQDN. This probably indicates a DNS issue. Perhaps relevant SRV records for kerberos are not able to be queried through the configured nameservers. SMB Permissions Overview Keytab file A keytab is a file that contains the encrypted password for a user and should allow for joining the domain without providing credentials This has been done on the TrueNAS server. TrueNAS documentation on Keytab Windows Documentation on Keytab Example command ktpass /princ host/User1.contoso.com@CONTOSO.COM /mapuser User1 /pass MyPas$w0rd /out machine.keytab /crypto all /ptype KRB5_NT_PRINCIPAL /mapop set actual command that was used C:\Users\admin.colt>ktpass -princ admin.colt@coltscomputer.services -pass ScurvyCom.modore8602 -crypto all -ptype KRB5_NT_PRINCIPAL -kvno 0 -out c:\admin.colt.KEYTAB LAPS_OperationsGuide   Local Administrator Password Management Detailed Technical Specification   Published: June 2015   Authors: Tom Ausburne, Microsoft Jiri Formacek, Microsoft   Abstract: This document summarizes fundamental Operational procedures for Local Administrator Password Solution (LAPS)   Copyright © 2015 Microsoft Corporation. All rights reserved.     Table of Contents 1 Installation . 1 1.1 Management Computers . 2 1.2 Managed Clients . 4 2 AD Preparation . 5 2.1 Modifying the Schema . 5 2.2 Permissions . 6 2.2.1 Removing Extended Rights . 6 2.2.2 Adding Machine Rights . 7 2.2.3 Adding User Rights . 7 3 Group Policy . 9 3.1 Changing the Group Policy Settings . 9 3.2 Enabling the local administrator password management . 9 3.3 Password parameters . 9 3.3.1 Administrator account name . 10 3.4 Protection against too long planned time for password reset . 11 4 Managing Clients . 12 4.1 Viewing password settings . 12 4.2 Resetting the password . 15 5 Troubleshooting . 16 5.1 Event Logging and Auditing . 16 5.1.1 Client Logging . 16 5.1.2 Event IDs . 16 5.2 Problem Scenarios . 18 5.3 Auditing . 19       1 Installation There are two parts to the installation, the management computers and the clients you want to manage. The installation of binaries and related files is handled by the MSI package. This will install the following: - GPO CSE: must be present on each managed machine - Management tools: o Fat client UI o PowerShell module AdmPwd.PS o Group Policy Editor admin templates The default is to install the CSE only.   The management tools are installed on demand.   File Reference The installation for the Fat client UI is done to folder: %ProgramFiles%\LAPS AdmPwd.UI.exe AdmPwd.Utils.config AdmPwd.Utils.dll The installation for the PowerShell modules is done to folder: %WINDIR% \System32\WindowsPowerShell\v1.0\Modules\AdmPwd.PS AdmPwd.PS.dll AdmPwd.PS.format.ps1xml AdmPwd.PS.psd1 AdmPwd.Utils.config AdmPwd.Utils.dll %WINDIR% \System32\WindowsPowerShell\v1.0\Modules\AdmPwd.PS\en-us AdmPwd.PS.dll-Help.xml The installation for the CSE is done to folder: %ProgramFiles%\LAPS\CSE AdmPwd.dll The installation for the Group Policy files is done to folders: %WINDIR% \PolicyDefinitions AdmPwd.admx %WINDIR% \PolicyDefinitions\en-US AdmPwd.adml   1.1 Management Computers Double click on the appropriate MSI installer for your platform (LAPS..msi) to get started. Click Next . Accept license agreement and click Next For the first management machine, you should enable all the installation choices for management tools Click Next .     Click Install . Click Finish .       1.2 Managed Clients This installation uses the same install files, AdmPwd.Setup.x64.msi and AdmPwd.Setup.x86.msi as on the management computers.   These can be installed/updated/uninstalled on clients using a variety of methods including the Software Installation feature of Group Policy, SCCM, login script, manual install, etc.   If you want to script this you can use this command line to do a silent install: msiexec /i \LAPS.x64.msi /quiet or   msiexec /i \LAPS.x86.msi /quiet   Just change the to a local or network path.   Example:   msiexec /i \\server\share\LAPS.x64.msi /quiet   Alternative method of installation to managed clients is to copy the AdmPwd.dll to the target computer and use this command: regsvr32.exe AdmPwd.dll Note : If you install by just registering the dll it will not show up in Program and Features as shown below.   Once this is installed you can see it in Programs and Features.   1.2.1 Writable domain controller access required Managed clients must have access to a writable domain controller in order to update the password. One way to confirm such access exists is by running the nltest.exe utility on the managed client as follows: nltest.exe /dsgetdc: /writable /force On success the utility will output the details of the specific domain controller that was found. The Get-ADDomainController cmdlet may also be used for this purpose using the following syntax: Get-ADDomainController -Discover -Writable -ForceDiscover   2 AD Preparation   2.1 Modifying the Schema The Active Directory Schema needs to be extended by two new attributes that store the password of the managed local Administrator account for each computer and the timestamp of password expiration. Both attributes are added to the may-contain attribute set of the computer class. ms-Mcs-AdmPwd – Stores the password in clear text ms-Mcs-AdmPwdExpirationTime – Stores the time to reset the password   To update the Schema you first need to import the PowerShell module.   Open up an Administrative PowerShell window and use this command: Import-module AdmPwd.PS   You update the Schema with this command: Update-AdmPwdADSchema   Note : If you have an RODC installed in the environment and you need to replicate the value of the attribute ms-Mcs-AdmPwd to the RODC, you will need to change the 10 th bit of the searchFlags attribute value for ms-Mcs-AdmPwd schema objet to 0 (substract 512 from the current value of the searchFlags attribute). For more information on Adding Attributes to or Removing attributes from the RODC Filtered Attribute Set, please refer to http://technet.microsoft.com/en-us/library/cc754794(v=WS.10).aspx . Note : Managed clients cannot update the ms-Mcs-AdmPwd attribute on an RODC, even once the above steps are performed. Managed clients must always have access to a writable domain controller in order to update the password. See section 1.2.1.     2.2 Permissions The Active Directory infrastructure offers advanced tools for implementation of the security model for this solution by allowing for per-attribute Access Lists (ACLs) and implementing confidential attributes for password storage. There are four sets of rights that need to be modified.   2.2.1 Removing Extended Rights To restrict the ability to view the password to specific users and groups you need to remove “ All extended rights ” from users and groups that are not allowed to read the value of attribute ms-Mcs-AdmPwd. This is required because the All Extended rights/permissions permission also gives permission to read confidential attributes. If you want to do this for all computers you will need to repeat the next steps on each OU that contains those computers. You do not need to do this on subcontainers of already processed OUs unless you have disabled permission inheritance. 1. Open ADSIEdit 2. Right Click on the OU that contains the computer accounts that you are installing this solution on and select Properties . 3. Click the Security tab 4. Click Advanced 5. Select the Group(s) or User(s) that you don’t want to be able to read the password and then click Edit . 6. Uncheck All extended rights Important : This will remove ALL extended rights, not only CONTROL_ACCESS right, so be sure that all roles will retain all necessary permissions required for their regular work. To quickly find which security principals have extended rights to the OU you can use PowerShell cmdlet.   You may need to run Import-module AdmPwd.PS if this is a new window. Find-AdmPwdExtendedrights -identity : | Format-Table     2.2.2 Adding Machine Rights The Write permission on the ms-Mcs-AdmPwdExpirationTime and ms-Mcs-AdmPwd attributes of all computer accounts has to be added to the SELF built-in account. This is required so the machine can update the password and expiration timestamp of its own managed local Administrator password.   This is done using PowerShell.   You may need to run Import-module AdmPwd.PS if this is a new window. Set-AdmPwdComputerSelfPermission -OrgUnit Repeat this procedure for any additional OUs that contain computer accounts that are in scope of the solution and are not subcontainers of already processed containers.   2.2.3 Adding User Rights Add the CONTROL_ACCESS permission (extended right) on ms-Mcs-AdmPwd attribute of the computer accounts to group(s) or user(s) that will be allowed to read the stored password of the managed local Administrator account on managed computers.   Set-AdmPwdReadPasswordPermission -OrgUnit -AllowedPrincipals Use the same –OrgUnit name(s) as in the previous command.   Note : You can use multiple groups and users in the same command separated by comma.   Example: Set-AdmPwdReadPasswordPermission -OrgUnit Servers -AllowedPrincipals contoso\Administrator,contoso\HelpDesk,contoso\PwdAdmins   Add the Write permission on ms-Mcs-AdmPwdExpirationTime attribute of computer accounts to group(s) or user(s) that will be allowed to force password resets for the managed local Administrator account on managed computers. Set-AdmPwdResetPasswordPermission -OrgUnit -AllowedPrincipals   Use the same –OrgUnit name(s) as in the previous commands. Note : You can use multiple groups and users in the same command separated by comma.   Example: Set-AdmPwdResetPasswordPermission -OrgUnit Servers -AllowedPrincipals contoso\Administrator,contoso\HelpDesk,contoso\PwdAdmins 2.2.4 Security implications of domain-join-by-privilege Active Directory by default allows ordinary users to join machines to the domain, up to the limit imposed by the msDS-MachineAccountQuota attribute.   The user must have local Administrator privileges on a machine in order to perform the join. When a machine is joined this way, the resultant security configuration on the machine account allows the joining user to read the value of the ms-Mcs-AdmPwd attribute, even after the user in question no longer has local Administrator privileges on a machine. Machine that have been joined this way can be discovered by querying the msDS-CreatorSid attribute attribute, for example: Get-ADComputer -LdapFilter '(msds-CreatorSid=*)' -SearchBase '' -SearchScope Subtree You can prevent this issue by disabling the ability of ordinary users to join machines to the domain. This can be done by setting the ms-DS-MachineAccountQuota attribute to zero. Additional background context can be found in the following topics: Default limit to number of workstations a user can join to the domain MS-DS-Creator-SID attribute MS-DS-Machine-Account-Quota attribute Microsoft would like to thank Metin Yunus Kandemir for finding this issue. 3 Group Policy 3.1 Changing the Group Policy Settings The settings are located under Computer Configuration\Administrative Templates\LAPS.   3.2 Enabling the local administrator password management Management of password of local administrator account must be enabled so as the CSE can start managing it:   3.3 Password parameters By default this solution uses a password with maximum password complexity, 14 characters and changes the password every 30 days.   You can change the values to suit your needs by editing a Group Policy.   You can change the individual password settings to fit your needs.   3.3.1 Administrator account name If you have decided to manage custom local Administrator account, you must specify its name in Group Policy.   Note: DO NOT configure when you use the built-in admin account, even if you renamed it. That account is auto-detected by well-known SID. DO configure when you use a custom local admin account. 3.4 Protection against too long planned time for password reset If you do not want to allow setting planning password expiration of admin account for longer time than maximum password age, you can do it in GPO:   4 Managing Clients 4.1 Viewing password settings Once everything is configured, and Group Policy has refreshed on the clients, you can look at the properties of the computer object and see the new settings. The password is stored in plain text.   The Expiration date is stored as the number of 100-nanosecond intervals that have elapsed since the 0 hour on January 1, 1601 untill the date/time that is being stored. The time is always stored in Greenwich Mean Time (GMT) in the Active Directory. If you want to manually convert it use this command: w32tm /ntte     There is also a graphical interface available.   When you install the program on a computer where you want the ability to easily retrieve the password just select the Fat client UI option.     The program you want to run is C:\Program Files\LAPS\AdmPwd.UI.exe . It will be in the menu and looks like this: Or this on Windows 7.       Launch the interface, enter the client name and click Search .   You can also get the password using PowerShell. Get-AdmPwdPassword -ComputerName   What happens if a user who hasn’t been granted rights to see the local Administrators password tries to access it?   If they were to gain access to the GUI interface the password won’t be displayed.   If they have installed the RSAT tools and run Active Directory Users and Computers (ADUC) to view the password it will show as .   This information is not seen because the extended rights were removed and only certain individuals and groups were granted the rights to see this. 4.2 Resetting the password To manually reset the password, just click the Set button in LAPS UI tool. When a Group Policy refresh runs, password will be reset. You can also plan password expiration for the future. To do so, enter desired expiration date/time into respective field.   You can also reset the password using PowerShell. Reset-AdmPwdPassword -ComputerName -WhenEffective     5 Troubleshooting This solution has a variety of logging options for troubleshooting purposes. 5.1 Event Logging and Auditing 5.1.1 Client Logging The CSE logs all events in the Application Event Log of local computer. Log messages are English only, but can be localized or additional language can be added, if necessary. The amount of events that are logged is configurable via the following registry REG_DWORD value: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{D76B9641-3288-4f75-942D-087DE603E3EA}}\ExtensionDebugLevel This value is not there by default and must be added.   Possible values are as follows: Value Meaning 0 Silent mode; log errors only When no error occurs, no information is logged about CSE activity This is a default value 1 Log Errors and warnings 2 Verbose mode, log everything   5.1.2 Event IDs The Event source for all events reported by CSE is always “AdmPwd”.   The following table summarizes the events that can occur in the Event Log: ID Severity Description Comment 2 Error Could not get computer object from AD. Error %1 This event is logged in case that CSE is not able to connect to computer account for local computer in AD. %1 is a placeholder for error code returned by function that retrieves local computer name, converts it to DN and connects to object, specified by the DN 3 Error Could not get local Administrator account. Error %1 This event is logged in case that CSE is not able to connect to managed local Administrator account. %1 is a placeholder to error code returned by function that detects the name of local administrator’s account and connects to the account 4 Error Could not get password expiration timestamp from computer account in AD. Error %1. This event is logged in case that CSE is not able to read the value of ms-Mcs-AdmPwdExpirationTime of computer account in AD %1 is a placeholder for error code returned by function that reads the value of the attribute and converts the value to unsigned __int64 type 5 Error Validation failed for new local admin password against local password policy. Error %1. This event is logged when password validation against local password policy fails. 5 Information Validation passed for new local admin password. This event is logged when password is successfully validated against local password policy 6 Error Could not reset local Administrator's password. Error %1 This event is logged in case that CSE is not able to reset the password of managed local Administrator account. %1 is a placeholder for error returned by NetUserSetInfo() API 7 Error Could not write changed password to AD. Error %1. This event is logged in case that CSE is not able to report new password and timestamp to AD. %1 is a placeholder for error code returned by ldap_mod_s call 10 Warning Password expiration too long for computer (%1 days). Resetting password now. This event is logged in case that CSE detects that password expiration for computer is longer than allowed by policy in place while protection against excessive password age is turned on 11 Information It is not necessary to change password yet. Days to change: %1. This event is logged after CSE detects that it is not yet the time to reset the password %1 is a placeholder for number of 24-hour’s intervals that remain till the password will be reset 12 Information Local Administrator's password has been changed. This event is logged after CSE resets the password of managed local Administrator account 13 Information Local Administrator's password has been reported to AD. This event is logged after CSE reports the password and timestamp to AD 14 Information Finished successfully This event is logged after CSE performed all required tasks and is about to finish 15 Information Beginning processing This event is logged when CSE starts processing 16 Information Admin account management not enabled, exiting This event is logged when admin account management is not enabled   Note: Generally, all events with severity “Error” are blocking. When any error occurs, no other tasks are performed and CSE terminates processing.   5.2 Problem Scenarios   Symptom : Client gets Event ID 7, “ Could not write changed password to AD. Error 0x80070032” in the Event log. Solution : The client is not in a managed OU.   Move it to a managed OU or run the PowerShell commands to add the Machine Rights to the OU the client is in.   Symptom : When importing AdmPwd.PS module, you get error “ Import-Module: Could not load file or assembly 'file:///C:\Windows\system32\WindowsPowerShell\v1.0\Modules\admpwd.ps\AdmPwd.PS.dll' or one of its dependencies.   This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded. ” Solution : You need to allow PowerShell to load .NET Framework 4. To allow this, you need to change powershell.exe.config to contain this: < configuration > < startup useLegacyV2RuntimeActivationPolicy = " true " > < supportedRuntime version = " v4.0.30319 " /> < supportedRuntime version = " v2.0.50727 " />   Symptom : Everything is installed but the password isn’t updating on the client and nothing is logged in the Event Log. Solution : The CSE hasn’t been enabled with a Group Policy that applies to the client. Set the policy “Enable local admin password management” to Enabled   Symptom : Everything is installed but the password isn’t getting updated in Active Directory Solution : The client does not have network connectivity to a writable domain controller. Ensure that the client is able to see a writable domain controller. See section 1.2.1.   Symptom : After running the Schema update, the new attributes aren’t showing in the computer properties. Solution : If the status of the Schema update was successful you may be experiencing replication issues or latency.   In larger environments this attribute population may take some time to propagate.   Symptom : Users that haven’t been specifically granted permissions can still see the password. Solution : This is usually due to not removing the “All Extended rights” permission from groups and users. Check the effective rights on the computer in question.   5.3 Auditing Auditing users who successfully query and read the local administrator password for a computer can be accomplished by using a PowerShell cmdlet.   You may need to run Import-module AdmPwd.PS if this is a new window. Set-AdmPwdAuditing –OrgUnit: -AuditedPrincipals: :   When a password is successfully read, a 4662 event is logged in the Security log of the Domain Controller.     You will notice that the schemaIDGUID is reflected in the Event properties.   Migrate user domain profile from one domain to another domain https://community.spiceworks.com/how_to/145014-migrate-user-domain-profile-from-one-domain-to-another-domain fgorovodsky2   Jul 20, 2017 2 Minute Read Spice (34) Reply  (8) Subscribe   Share This is quite similar to migrating local to domain. The difference is about setting permissions and joining to domain. As you know to be able to add domain account to permissions TAB, computer needs to be joined to domain. When computer is a member of a different domain already it might be confusing. So what we need to do: 13 Steps total Step 1: Step 1 Login to local admin account Step 2: Step 2 Join new domain providing credentials to it, reboot computer Step 3: Step 3 Login again as local administrator making sure the computer is joined to the new domain – computer properties Step 4: Step 4 Now, we need to add user from new domain to permissions of user files and registry. Just repeat step 3 Step 5: Step 5 Now, the registry part, it is a bit tricky since we need to load external registry because we won’t be able to log on old domain account. Step 6: Step 6 Open regedit, select HKLM, then select file/load registry hive. Navigate to old domain user account folder, select file NTUSER.DAT (hidden by default), specify a temporary name for that hive, like user-reg. Step 7: Step 7 Now right-click on user-reg, click permissions Step 8: Step 8 In new window click Advanced, then Add, and then type in NEW DOMAIN ACCOUNT NAME. You may need to provide domain admin credentials to query AD. Step 9: Step 9 Select user, then check following options: 9a) Apply to: This Key and subkeys 9b) Full Control 9c) DO NOT SELECT LAST CHECKBOX – apply these permissions to objects and/or containerswithin this container only Step 10: Step 10 Click Ok, then ok, then ok. Step 11: Step 11 Now navigate to HKLM\Software\Microsoft\Windows_NT\CurrentVersion\Profile List 11A) Find the one, with old domain path to profile in key: ProfileImagePath, copy value of this key, eg. C:\Users\test.olddomain 11B) Find the other one with newly created profile path, eg. C:\Users\test.newdomain 11C) Replace value of ProfileImagePath from old profile, eg. C:\Users\test.olddomain with C:\Users\test.newdomain Step 12: Step 12 Double check permissions for folders, check value of the keys. Step 13: Step 13 If everything is ok, reboot your computer and try to login using username from new domain. That would be all. If you login to new domain account and cannot see/open a folder or file it is generally related to permissions. Just reboot computer, login to local admin or domain admin, select user profile and re-add permissions with propagation to child objects. If you login and are presented with temporary profile, you need to re-set permissions for registry for new user. Basically it isn’t a big magic behind this, just simple permissions editing with path to profile swapping. That’s all:) Modify Group Policy's refresh interval https://www.itprotoday.com/compute-engines/how-can-i-modify-group-policys-refresh-interval A.  By default, Group Policy refreshes every 90 minutes for typical machines and users and every 5 minutes for domain controllers (DCs). To change these intervals, perform the following steps: Open the relevant Group Policy Object (GPO). For example, open the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, right-click the organizational unit (OU) or domain, select Properties, select the Group Policy tab, select the GPO, then click Edit. Expand Computer Configuration, Administrative Templates, System, Group Policy. Double-click "Group Policy refresh interval for computers," then select Enabled. Enter the new refresh rate and the maximum random time to wait for the refresh (to avoid all machines updating at the same time), then click OK. If required, double-click "Group Policy refresh interval for domain controllers," then select Enabled. Enter the new refresh rate, which should be significantly less than the average computer policy refresh rate, and the maximum random time to wait for the refresh (to avoid all machines updating at the same time), then click OK. Click here to view image Expand User Configuration, Administrative Templates, System, Group Policy. Double-click "Group Policy refresh interval for users." Again, select Enabled, set the necessary values, then click OK. Close the Group Policy Editor (GPE). You don't have to configure both the user and computer value--you can modify just one of them. You shouldn't set these values too low: Every update requires processing and adds to the network traffic, and short refresh rates can quickly cause larger network problems. For example, setting the update frequency to 0 would result in Group Policy attempting a refresh every 7 seconds, which probably isn't good for anyone. Move FSMO Roles Move-ADDirectoryServerOperationMasterRole -Identity CM-01-HVSRV16 -OperationMasterRole InfrastructureMaster   Move-ADDirectoryServerOperationMasterRole -Identity CM-01-HVSRV16 -OperationMasterRole SchemaMaster   Move-ADDirectoryServerOperationMasterRole -Identity CM-01-HVSRV16 -OperationMasterRole DomainNamingMaster   Move-ADDirectoryServerOperationMasterRole -Identity CM-01-HVSRV16 -OperationMasterRole PDCEmulator   Move-ADDirectoryServerOperationMasterRole -Identity CM-01-HVSRV16 -OperationMasterRole RIDMaster   Move-ADDirectoryServerOperationMasterRole https://learn.microsoft.com/en-us/powershell/module/activedirectory/move-addirectoryserveroperationmasterrole?view=windowsserver2022-ps Description The  Move-ADDirectoryServerOperationMasterRole  cmdlet moves one or more operation master roles to a directory server. You can move operation master roles to a directory server in a different domain if the credentials are the same in both domains. The  Identity  parameter specifies the directory server that receives the roles. You can specify a directory server object by one of the following values: Name of the server object (name) The distinguished name of the NTDS Settings object The distinguished name of the server object that represents the directory server GUID (objectGUID) of server object under the configuration partition GUID (objectGUID) of NTDS settings object under the configuration partition For Active Directory Lightweight Directory Services (AD LDS) instances the syntax for the server object name is  $ . The following is an example of this syntax: asia-w7-vm4$instance1 When you type this value in Windows PowerShell, you must use the backtick (`) as an escape character for the dollar sign ($). Therefore, for this example, you would type the following: asia-w7-vm4`$instance1 You can also set the parameter to a directory server object variable, such as  $ . The  Move-ADDirectoryServerOperationMasterRole  cmdlet provides two options for moving operation master roles: Role transfer , which involves transferring roles to be moved by running the cmdlet using the  Identity  parameter to specify the current role holder and the  OperationMasterRole  parameter to specify the roles for transfer. This is the recommended option. Operation roles include PDCEmulator, RIDMaster, InfrastructureMaster, SchemaMaster, or DomainNamingMaster. To specify more than one role, use a comma-separated list. Role seizure , which involves seizing roles you previously attempted to transfer by running the cmdlet a second time using the same parameters as the transfer operation, and adding the  Force  parameter. The  Force  parameter must be used as a switch to indicate that seizure, instead of transfer, of operation master roles is being performed. This operation still attempts graceful transfer first, then seizes if transfer is not possible. Unlike using Ntdsutil.exe to move operation master roles, the  Move-ADDirectoryServerOperationMasterRole  cmdlet can be remotely executed from any domain joined computer where the Active Directory module for Windows PowerShell administration module is installed and available for use. This can make the process of moving roles simpler and easier to centrally administer as each of the two command operations required can be run remotely and do not have to be locally executed at each of the corresponding role holders involved in the movement of the roles, for instance, role transfer only allowed at the old role holder, role seizure only allowed at the new role holder. Examples Example 1: Move a PDC emulator to a domain controller PowerShell Copy PS C:\> Move-ADDirectoryServerOperationMasterRole -Identity "USER01-DC1" -OperationMasterRole PDCEmulator This command moves the primary domain controller (PDC) Emulator role to the domain controller USER01-DC1. Example 2: Move the PDC emulator and schema master roles to a domain controller PowerShell Copy PS C:\> Move-ADDirectoryServerOperationMasterRole -Identity "USER02-DC2" -OperationMasterRole PDCEmulator,SchemaMaster This command moves the PDC Emulator and schema master roles to the domain controller USER02-DC2. Example 3: Move the schema master FSMO owner to the AD LDS instance on a server PowerShell Copy PS C:\> Move-ADDirectoryServerOperationMasterRole -Identity User03-DC`$instance1 -OperationMasterRole schemaMaster -Server User03-DC:50000 This command moves the schema master flexible single master operations (FSMO) owner to the AD LDS instance instance1 on the server User03-DC. Example 4: Seize specific roles for a specified user PowerShell Copy PS C:\> Move-ADDirectoryServerOperationMasterRole -Identity USER04-DC1 -OperationMasterRole RIDMaster,InfrastructureMaster,DomainNamingMaster -Force This command seizes the roles RID master, infrastructure master, and domain naming master. Example 5: Transfer roles to a specific domain controller PowerShell Copy PS C:\> $Server = Get-ADDomainController -Identity "TK5-CORP-DC-10.fabrikam.com" PS C:\> Move-ADDirectoryServerOperationMasterRole -Identity $Server -OperationMasterRole SchemaMaster,DomainNamingMaster,PDCEmulator,RIDMaster,InfrastructureMaster This command transfers the FSMO role to the specified domain controller. When using the fully qualified domain name (FQDN) to identify the domain controller, the  Get-ADDomainController  cmdlet must be used first as a preliminary step. There is a known issue where the  Move-ADDirectoryServerOperationMasterRole  cmdlet fails when an FQDN is specified directly as the value of the  Identity  parameter. Parameters -AuthType Specifies the authentication method to use. The acceptable values for this parameter are: Negotiate or 0 Basic or 1 The default authentication method is Negotiate. A Secure Sockets Layer (SSL) connection is required for the Basic authentication method. Expand table Type: ADAuthType Accepted values: Negotiate, Basic Position: Named Default value: None Required: False Accept pipeline input: False Accept wildcard characters: False -Confirm Prompts you for confirmation before running the cmdlet. Expand table Type: SwitchParameter Aliases: cf Position: Named Default value: False Required: False Accept pipeline input: False Accept wildcard characters: False -Credential Specifies the user account credentials to use to perform this task. The default credentials are the credentials of the currently logged on user unless the cmdlet is run from an Active Directory module for Windows PowerShell provider drive. If the cmdlet is run from such a provider drive, the account associated with the drive is the default. To specify this parameter, you can type a user name, such as User1 or Domain01\User01 or you can specify a  PSCredential  object. If you specify a user name for this parameter, the cmdlet prompts for a password. You can also create a  PSCredential  object by using a script or by using the  Get-Credential  cmdlet. You can then set the  Credential  parameter to the  PSCredential  object. If the acting credentials do not have directory-level permission to perform the task, Active Directory module for Windows PowerShell returns a terminating error. Expand table Type: PSCredential Position: Named Default value: None Required: False Accept pipeline input: False Accept wildcard characters: False -Force Indicates that the cmdlet is used for seize operations on domain controllers with the flexible single master operations (FSMO) role. Expand table Type: SwitchParameter Position: Named Default value: None Required: False Accept pipeline input: False Accept wildcard characters: False -Identity Specifies an Active Directory server object by providing one of the following values. The identifier in parentheses is the Lightweight Directory Access Protocol (LDAP) display name for the attribute. Name of the server object (name) For Active Directory Lightweight Directory Services (AD LDS) instances the syntax is of a name is  $ . Note: When you type this value in Windows PowerShell, you must use the backtick (`) as an escape character for the dollar sign ($). For instance,  asia-w7-vm4`$instance1 . For other Active Directory instances, use the value of the name property. The distinguished name of the NTDS Settings object The distinguished name of the server object that represents the directory server GUID (objectGUID) of server object under the configuration partition GUID (objectGUID) of NTDS settings object under the configuration partition The cmdlet searches the default naming context or partition to find the object. If two or more objects are found, the cmdlet returns a non-terminating error. This parameter can also get this object through the pipeline or you can set this parameter to an object instance. Expand table Type: ADDirectoryServer Position: 0 Default value: None Required: True Accept pipeline input: True Accept wildcard characters: False -OperationMasterRole Specifies one or more operation master roles to move to the specified directory server in Active Directory Domain Services. The acceptable values for this parameter are: PDCEmulator or 0 RIDMaster or 1 InfrastructureMaster or 2 SchemaMaster or 3 DomainNamingMaster or 4 To specify multiple operation master roles, use a comma-separated list. Expand table Type: ADOperationMasterRole [] Accepted values: PDCEmulator, RIDMaster, InfrastructureMaster, SchemaMaster, DomainNamingMaster Position: 1 Default value: None Required: True Accept pipeline input: False Accept wildcard characters: False -PassThru Returns an object representing the item with which you are working. By default, this cmdlet does not generate any output. Expand table Type: SwitchParameter Position: Named Default value: None Required: False Accept pipeline input: False Accept wildcard characters: False -Server Specifies the Active Directory Domain Services instance to connect to, by providing one of the following values for a corresponding domain name or directory server. The service may be any of the following: Active Directory Lightweight Domain Services, Active Directory Domain Services or Active Directory snapshot instance. Specify the Active Directory Domain Services instance in one of the following ways: Domain name values: Fully qualified domain name NetBIOS name Directory server values: Fully qualified directory server name NetBIOS name Fully qualified directory server name and port The default value for this parameter is determined by one of the following methods in the order that they are listed: By using the  Server  value from objects passed through the pipeline By using the server information associated with the Active Directory Domain Services Windows PowerShell provider drive, when the cmdlet runs in that drive By using the domain of the computer running Windows PowerShell Expand table Type: String Position: Named Default value: None Required: False Accept pipeline input: False Accept wildcard characters: False -WhatIf Shows what would happen if the cmdlet runs. The cmdlet is not run. Expand table Type: SwitchParameter Aliases: wi Position: Named Default value: False Required: False Accept pipeline input: False Accept wildcard characters: False Inputs ADDirectoryServer A directory server object is received by the  Identity  parameter. Outputs None or Microsoft.ActiveDirectory.Management.ADDirectoryServer Returns the modified directory server object when the  PassThru  parameter is specified. By default, this cmdlet does not generate any output. Notes This cmdlet does not work with an Active Directory snapshot. This cmdlet does not work with a read-only domain controller. Related Links Move-ADDirectoryServer AD DS Administration Cmdlets in Windows PowerShell Netlogon Logging To enable NetLogon Logging, use the following command on a domain controller:   nltest /dbflag:0x2080ffff   When finished, disable NetLogon Logging with this command:   nltest /dbflag:0x0     From < http://tritoneco.com/2013/05/21/troubleshoot-ad-account-lockouts-with-netlogon-logging/ >      Powershell export AD users in OU to CSV ###########################################################   # AUTHOR  : Victor Ashiedu   # WEBSITE : iTechguides.com   # BLOG : iTechguides.com/blog-2/   # CREATED : 08-08-2014    # UPDATED : 19-09-2014    # COMMENT : This script exports Active Directory users   # to a a csv file. v2.1 adds the condition to    # ignore all users with the info (Notes) field   # found on the Telephones tab containing the    # word 'Migrated'.    ###########################################################       #Define location of my script variable   #the -parent switch returns one directory lower from directory defined.    #below will return up to ImportADUsers folder    #and since my files are located here it will find it.   #It failes withpout appending "*.*" at the end     $path = Split-Path -parent "C:\Accent\ExportADUsers\*.*"     #Create a variable for the date stamp in the log file     $LogDate = get-date -f yyyyMMddhhmm     #Define CSV and log file location variables   #they have to be on the same location as the script     $csvfile = $path + "\ALLADUsers_$logDate.csv"     #import the ActiveDirectory Module     Import-Module ActiveDirectory       #Sets the OU to do the base search for all user accounts, change as required.   #Simon discovered that some users were missing   #I decided to run the report from the root of the domain     $SearchBase = "OU=Dumas,OU=RHSC,DC=RHSC,DC=local"     #Get Admin accountb credential     $GetAdminact = Get-Credential     #Define variable for a server with AD web services installed     $ADServer = 'RHSC-01-VSRV01'     #Find users that are not disabled   #To test, I moved the following users to the OU=ADMigration:   #Philip Steventon (kingston.gov.uk/RBK Users/ICT Staff/Philip Steventon) - Disabled account   #Joseph Martins (kingston.gov.uk/RBK Users/ICT Staff/Joseph Martins) - Disabled account   #may have to get accountb status with another AD object     #Define "Account Status"    #Added the Where-Object clause on 23/07/2014   #Requested by the project team. This 'flag field' needs   #updated in the import script when users fields are updated   #The word 'Migrated' is added in the Notes field, on the Telephone tab.   #The LDAB object name for Notes is 'info'.      $AllADUsers = Get-ADUser -server $ADServer `   -Credential $GetAdminact -searchbase $SearchBase `   -Filter * -Properties * | Where-Object {$_.info -NE 'Migrated'} #ensures that updated users are never exported.     $AllADUsers |   Select-Object @{Label = "First Name";Expression = {$_.GivenName}},   @{Label = "Last Name";Expression = {$_.Surname}},   @{Label = "Display Name";Expression = {$_.DisplayName}},   @{Label = "Logon Name";Expression = {$_.sAMAccountName}},   @{Label = "Full address";Expression = {$_.StreetAddress}},   @{Label = "City";Expression = {$_.City}},   @{Label = "State";Expression = {$_.st}},   @{Label = "Post Code";Expression = {$_.PostalCode}},   @{Label = "Country/Region";Expression = {if (($_.Country -eq 'GB')  ) {'United Kingdom'} Else {''}}},   @{Label = "Job Title";Expression = {$_.Title}},   @{Label = "Company";Expression = {$_.Company}},   @{Label = "Directorate";Expression = {$_.Description}},   @{Label = "Department";Expression = {$_.Department}},   @{Label = "Office";Expression = {$_.OfficeName}},   @{Label = "Phone";Expression = {$_.telephoneNumber}},   @{Label = "Email";Expression = {$_.Mail}},   @{Label = "Manager";Expression = {%{(Get-AdUser $_.Manager -server $ADServer -Properties DisplayName).DisplayName}}},   @{Label = "Account Status";Expression = {if (($_.Enabled -eq 'TRUE')  ) {'Enabled'} Else {'Disabled'}}}, # the 'if statement# replaces $_.Enabled   @{Label = "Last LogOn Date";Expression = {$_.lastlogondate}} |      #Export CSV report     Export-Csv -Path $csvfile -NoTypeInformation   Rejoining an "untrusted" workstation and primary domain Test-ComputerSecureChannel -Repair is all you need to do on the client Reset-ComputerMachinePassword -Server DomainController -Credential DomainAdmin Rename Domain Found this article which looks like it is very good     http://www.rebeladmin.com/2015/05/step-by-step-guide-to-rename-active-directory-domain-name/           Step-by-Step guide to rename Active Directory Domain Name   MAY 14, 2015 BY DISHAN M. FRANCIS 47 COMMENTS   Few of the blog readers asked me on few occasions if they can change the AD domain name to the different domain name. Answer is yes you can, but you need to aware of the issues it can occur as well. Otherwise you will be end up in a mess with non-functioning infrastructure. Idea of this post is to demonstrate how to rename AD and also to point out some issues you may face with a domain rename.     Following are the critical points you need to consider before AD rename.     1. Forest Function Level – Forest Function level must be windows server 2003 or higher to perform AD rename.   2. Location of the Domain – in forest it can have different level of domains. Those can be either complete different domains or child domains. If you going to change the location of the dc in the forest you must need to create trust relationships between domains to keep the connectivity.   3. DNS Zone – DNS Zone files must be created for the new domain name prior to the rename process in relevant DNS servers.   4. Folder Path Change – if DFS folder services or roaming profiles are setup, those paths must change in to server-based share or network share.   5. Computer Name Change – Once the domain is renamed the computers host names will also renamed. So if those are configured to use by applications or systems make sure you prepare to do those changes.   6. Reboots – Systems will need to reboot twice to apply the name changes including workstations. So be prepare for the downtime and service interruptions.   7. Exchange Server Incompatibility – Exchange server 2003 is the only supported version for AD rename. All other versions are not supported for this. Also there can be other applications in environment which can be not supported with rename. Make sure you access these risks.   8. Certificate Authority (CA) – if CA is used make sure you prepare it according to https://technet.microsoft.com/en-us/library/cc816587     Once your infrastructure is ready, to perform the rename process we need an administrative computer or server. It must be a member of domain and should not a DC. It must have “Remote Server Administration Tools” installed. For windows 2012 server it can be add as feature via server manager. For windows 8 or later can download it from http://www.microsoft.com/en-us/download/details.aspx?id=28972     In demo, I am going to rename contoso.com domain to canitpro.local domain. It is runs with windows server 2012 R2.     I have prepare a server which runs windows server 2012 R2 as member server to perform the rename. You can install Remote Server Administration Tools by Server manager > Add roles and features. Make sure you select AD DS and AD LDS tools under the RSAT.     rename1     Before we start the rename make sure forest domain activities are stopped. Such as adding new DC, changing forest configuration etc.     Also I went ahead and create the relevant DNS zone for new domain name in primary DNS server. (in my blog you can find complete dns article which explain about DNS zone setup)     rename2     Then in the member server log in as domain admin and open the command prompt with admin rights.     First we need to create a report which explains the current forest setup. To do that type rendom /list and press enter.     rename3     This will create an xml file with name Domainlist.xml in the path above command is executed. In my demo its C:\Users\Administrator.CONTOSO     rename4     To proceed it need to be edited to match with the new domain name. Make sure you save the file after edits.     rename5     Then type rendom /upload command from same folder path.     rename6     To check the domain readiness before the rename process type rendom /prepare     rename7     Once its pass with no errors, execute rendom /execute to proceed with rename. It will reboot all domain controllers automatically.     rename8     rename9     All workstations and servers will needs to reboot twice to apply changes. Username and password will not change, but the domain name will be new one.     With rename process domain controllers will not be renamed. Those need to change manually.     rename10     It can do using command netdom computername DC.contoso.com /add:DC.canitpro.local     rename11     Then type netdom computername DC.contoso.com /makeprimary:DC.canitpro.local once complete, reboot the DC.     rename12     We can see it’s changed after reboot.     rename13     The next thing we need to fix is the group policies. It’s still uses the old domain name.     rename14     To fix this type and enter gpfixup /olddns:contoso.com /newdns:canitpro.local     rename15     Then run gpfixup /oldnb:CONTOSO /newnb:canitpro     rename16     We done with that too. The only thing we need to run is rendom /end to stop the rename process and unfreeze the DC activity.     rename17     This ends the rename process and we have a dc now with a new domain name.     If you have any question about this feel free to contact me on rebeladm@live.com     repadmin This command syncs all DC to this one   repadmin /syncall RHSC-00-VSRV18 /d /e       repadmin /syncall RHSC-00-VSRV18 /APeD   repadmin /syncall RHSC-00-VSRV18 /d /e   pause     Powershell   Get-ADDomainController -Filter * | %{repadmin /syncall /edjQSA $_.hostname}   Repairing Broken Trust Relationship Between Workstation and AD Domain https://woshub.com/repair-trust-relationship-workstation-with-ad-domain/ In this article we’ll show how to fix a broken trust relationship between a workstation and an Active Directory domain when a user cannot logon to their domain computer. Let’s consider the root cause of the problem and easy way to repair trust between a computer and a domain controller over a secure channel without rebooting the computer and domain rejoining.       Contents: The Trust Relationship Between This Workstation and the Primary Domain Failed. Machine (Computer) Account Password in the Active Directory Domain Check and Restore the Trust Relationship Between Computer and Domain Using PowerShell Repair the Domain Trust Using Netdom   The Trust Relationship Between This Workstation and the Primary Domain Failed. The problem manifests itself when a user tries to logon to the workstation or member server using domain credentials and the following error occurs after entering the password: The trust relationship between this workstation and the primary domain failed. The error may also look like this: The security database on the server does not have a computer account for this workstation trust relationship.   Machine (Computer) Account Password in the Active Directory Domain When a  computer is joined to an Active Directory domain , a separate computer account is created for it. Like users, each computer has its password to authenticate the computer in the domain and establish a trusted connection with the domain controller. However, unlike  user passwords , computer passwords are set and changed automatically. Here are some important things about computer account passwords in AD: Computer passwords in AD must be changed regularly (once in 30 days by default). Tip.  You can configure the maximum computer password age using the  Domain member: Maximum machine account password age  policy located under Computer Configuration-> Windows Settings-> Security Settings-> Local Policies-> Security Options. A computer password lifetime may last from 0 to 999 days (30 days by default);  Unlike user passwords, a computer password cannot  expire . The password change is initiated by the computer, not the domain controller. A computer password is not subject to the  domain password policy ; Even if a computer has been turned off for 30 days or more, you can turn it on, and it will be authenticated on your DC with its old password. Then the local  Netlogon  service will change the computer password in its local database (the password is stored in the registry  HKLM\SECURITY\Policy\Secrets\$machine.ACC ) and then it will update the computer account password in Active Directory. A computer password is change on the nearest DC, the changes are not sent to the domain controller with the PDC emulator  FSMO role  (i. e., if a computer has changed its password on one DC, it won’t be able to authenticate on another DC till AD changes are  replicated ). If the hash of the password that the computer sends to the domain controller doesn’t match the computer account password in AD database, the computer cannot establish a secure connection with the DC and returns trusted connection errors. Why the problem occurs: A computer has been restored from an old restore point or a snapshot (in case of a virtual machine) created earlier than the computer password was changed in AD. If you roll the computer back to its previous state, it will try to authenticate on the DC using its old password. It is the most typical issue; A computer with the same name has been created in AD, or somebody has reset the computer account in the domain  using the ADUC console  ( dsa.msc );  The computer account in the domain has been disabled by the administrator (for example, during a regular procedure of disabling  inactive AD objects ); Quite a rare case when the  system time on a computer is wrong . Here is the classical way to repair trust relationship between the computer and domain: Reset the computer account in AD; Move the computer from the domain to a workgroup under the local administrator; Reboot; Rejoin the computer to the domain; Restart the computer again The method seems simple, but it is too clumsy, requires at least two restarts of the computer and takes 10-30 minutes. Also you may face problems with using old local user profiles. There is a smarter way to repair trust relationship using PowerShell without rejoining the domain or restarting the computer.   Check and Restore the Trust Relationship Between Computer and Domain Using PowerShell If you cannot authenticate on a computer under a domain account and the following error appears:  The trust relationship between this workstation and the primary domain failed , you need to logon to the computer using your local administrator account. You can also unplug the network cable and authenticate on the computer with the domain account logged on to the computer recently using Cached Credentials. Open the elevated PowerShell console and using  Test-ComputerSecureChannel  cmdlet make sure if the local computer password matches the password stored in AD. Test-ComputerSecureChannel –verbose If the passwords do not match and the computer cannot establish trust relationship with the domain, the command will return  False  –  The Secure channel between the local computer and the domain woshub.com is broken . To force reset the computer account password in AD, run this command: Test-ComputerSecureChannel –Repair –Credential (Get-Credential)   To reset a password, enter the credentials of a user account having the privilege to reset a computer account password. The user must be  delegated the permissions to manage computers in Active Directory  (you may also use a Domain Admins group member). Then run Test-ComputerSecureChannel again to make sure it returns  True  ( The Secure channel between the local computer and the domain woshub.com is in good condition ). So the computer password has been reset without a restart or manual domain rejoin. Now you can logon to the computer using your domain account. Also to force reset a password, you may use the  Reset-ComputerMachinePassword  cmdlet.   Reset-ComputerMachinePassword -Server mun-dc01.woshub.com -Credential woshub\adm_user1 mun-dc01.woshub.com  is the name of the closest DC to change the computer password on.   It is worth to reset a computer password each time before creating a virtual machine snapshot or a computer restore point. It will be easier for you to roll back to the previous computer state. If you have a development or test environment, where you often have to recover a previous VM state from a snapshot, you may want to disable password change in the domain for these computers using GPO. To do it, set the  Domain member: Disable machine account password changes  policy located in Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options. You can target the policy to the OU with test computers or  use GPO WMI filters .   Using the  Get-ADComputer cmdlet  (from the  Active Directory module for Windows PowerShell ), you can check the date of the last computer password change in AD: Get-ADComputer –Identity mun-wks5431 -Properties PasswordLastSet The Test-ComputerSecureChannel and Reset-ComputerMachinePassword cmdlets are available starting from  version PowerShell 3.0 . You will have to  update PowerShell version  in Windows 7/Windows Server 2008 R2. You can also check if there is a secure channel between a computer and a DC using this command: nltest /sc_verify:woshub.com The following lines confirm that trust has been successfully repaired: Trusted DC Connection Status = 0 0x0 NERR_Success Trust Verification Status = 0 0x0 NERR_Success Repair the Domain Trust Using Netdom In Windows 7/2008R2 and in previous Windows versions without PowerShell 3.0, you cannot use Test-ComputerSecureChannel and Reset-ComputerMachinePassword cmdlets to reset a computer password and repair trust relationship with the domain. In this case, use the  netdom.exe  tools to restore a secure channel with the domain controller. Netdom  is included in Windows Server 2008 or newer, and can be installed on users’ computers from  RSAT  (Remote Server Administration Tools). To repair trust relationship, log on under local administrator credentials (by typing  .\Administrator  on the logon screen) and run the following command: Netdom resetpwd /Server:DomainController /UserD:Administrator /PasswordD:Password The machine account password for the local machine has successfully reset. Server  is the name of any available domain controller UserD  is the name of the user with the domain administrator permissions or having delegated privileges on the OU containing the computer account PasswordD  user password Netdom resetpwd /Server:mun-dc01 /UserD:jsmith /PasswordD:Pra$$w0rd After running the command, you do not need to reboot the computer: just log off and log on again using your domain account. As you can see, it is quite easy to repair trust between a computer and a domain. Restore Default Domain Policy Examples   Restore the Default Domain Policy GPO to its original state. You will lose any changes that you have made to this GPO. As a best practice, you should configure the Default Domain Policy GPO only to manage the default Account Policies settings, Password Policy, Account Lockout Policy, and Kerberos Policy. In this example, you ignore the version of the Active Directory schema so that the  dcgpofix  command is not limited to same schema as the Windows version in which the command was shipped.   dcgpofix /ignoreschema /target:Domain     Restore the Default Domain Controllers Policy GPO to its original state. You will lose any changes that you have made to this GPO. As a best practice, you should configure the Default Domain Controllers Policy GPO only to set user rights and audit policies. In this example, you ignore the version of the Active Directory schema so that the  dcgpofix  command is not limited to same schema as the Windows version in which the command was shipped.     From < https://technet.microsoft.com/en-us/library/hh875588(v=ws.11).aspx >    Securing Active Directory: Who can add computers to the domain? Only the domain admin? https://sid-500.com/2017/09/09/securing-active-directory-who-can-add-computers-to-the-domain-only-the-domain-admin-are-you-sure/ “Only Domain administrators can add computers to the domain.” I can’t count how often I have heared these words. But when installing a new domain, a counter is configured and this counter allows each domain user to add up to 10 computers to the domain. This is the default setting. The setting can be changed and must be considered in the IT security concept. The ms-DS-MachineAccountQuota The setting can be found in dsa.msc (enable advanced features!) Open dsa.msc (Active Directory Users and Computers). If not already enabled, enable Advanced Features. Next open the properties of your domain (right click), click on Attribute editor and navigate to the Attribut ms-DS-MachineAccountQuota. Are you surprised? Every user (Domain User) can add up to 10 Computers. Or run a simple One-Liner in PowerShell. Don’t care about the domain name. We call it from Get-ADDomain. Get-ADObject ((Get-ADDomain).distinguishedname) -Properties ms-DS-MachineAccountQuota Who added client01 to the domain? Who has added client01 to the domain? Petra is a domain user and added client01 to the domain. We can see it by running a simple one-liner. Ok, I have to admit it’s a three liner. We examine the ms-DS-CreatorSID attribute of the computer account. Get-ADComputer client01 -Properties mS-DS-CreatorSID | Select-Object -Expandpropert y mS-DS-CreatorSID | Select-Object -ExpandProperty Value | Foreach-Object {Get-ADUser -Filt er {SID -eq $_}} Changing the default value A value of 0 means that domain users are are not allowed to add computer accounts. Open the properties of the domain and double click ms-DS-MachineAccountQuota. Modify the value. The number represents the number of computers that you want users to be able to add to the domain. I recommend changing it to 0. Or use PowerShell. Again: Don’t worry about the domain name. It will be filled in automatically. Set-ADDomain (Get-ADDomain).distinguishedname -Replace @{"ms-ds-MachineAccountQuota"="0"} The impact The user is informed that the maximum number has been reached. The following error occured attempting to join the computer to the domain: Security Groups https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#what-is-a-security-group-in-active-directory What is a security group in Active Directory? Active Directory has two forms of common security principals: user accounts and computer accounts. These accounts represent a physical entity that is either a person or a computer. A user account also can be used as a dedicated service account for some applications. Security groups are a way to collect user accounts, computer accounts, and other groups into manageable units. In the Windows Server operating system, several built-in accounts and security groups are preconfigured with the appropriate rights and permissions to perform specific tasks. In Active Directory, administrative responsibilities are separated into two types of administrators: Service administrators : Responsible for maintaining and delivering Active Directory Domain Services (AD DS), including managing domain controllers and configuring AD DS. Data administrators : Responsible for maintaining the data that's stored in AD DS and on domain member servers and workstations. How Active Directory security groups work Use groups to collect user accounts, computer accounts, and other groups into manageable units. Working with groups instead of with individual users helps you simplify network maintenance and administration. Active Directory has two types of groups: Security groups : Use to assign permissions to shared resources. Distribution groups : Use to create email distribution lists. Security groups Security groups can provide an efficient way to assign access to resources on your network. By using security groups, you can: Assign user rights to security groups in Active Directory. Assign user rights to a security group to determine what members of that group can do within the scope of a domain or forest. User rights are automatically assigned to some security groups when Active Directory is installed to help administrators define a person’s administrative role in the domain. For example, a user who you add to the Backup Operators group in Active Directory can back up and restore files and directories that are located on each domain controller in the domain. The user can complete these actions because, by default, the user rights  Backup files and directories  and  Restore files and directories  are automatically assigned to the Backup Operators group. Therefore, members of this group inherit the user rights that are assigned to that group. You can use Group Policy to assign user rights to security groups to delegate specific tasks. For more information about using Group Policy, see  User Rights Assignment . Assign permissions to security groups for resources. Permissions are different from user rights. Permissions are assigned to a security group for a shared resource. Permissions determine who can access the resource and the level of access, such as Full control or Read. Some permissions that are set on domain objects are automatically assigned to allow various levels of access to default security groups like the Account Operators group or the Domain Admins group. Security groups are listed in Discretionary Access Control Lists (DACLs) that define permissions on resources and objects. When administrators assign permissions for resources like file shares or printers, they should assign those permissions to a security group instead of to individual users. The permissions are assigned once to the group instead of multiple times to each individual user. Each account that's added to a group receives the rights that are assigned to that group in Active Directory. The user receives permissions that are defined for that group. You can use a security group as an email entity. Sending an email message to a security group sends the message to all the members of the group. Distribution groups You can use distribution groups only to send email to collections of users by using an email application like Exchange Server. Distribution groups aren't security enabled, so you can't include them in DACLs. Group scope Each group has a scope that identifies the extent to which the group is applied in the domain tree or forest. The scope of a group defines where in the network permissions can be granted for the group. Active Directory defines the following three group scopes: Universal Global Domain Local  Note In addition to these three scopes, the default groups in the Builtin container have a group scope of Builtin Local. This group scope and group type can't be changed. The following table describes the three group scopes and how they work as security groups: Expand table Scope Possible members Scope conversion Can grant permissions Possible member of Universal Accounts from any domain in the same forest Global groups from any domain in the same forest Other Universal groups from any domain in the same forest Can be converted to Domain Local scope if the group isn't a member of any other Universal group Can be converted to Global scope if the group doesn't contain any other Universal group On any domain in the same forest or trusting forests Other Universal groups in the same forest Domain Local groups in the same forest or trusting forests Local groups on computers in the same forest or trusting forests Global Accounts from the same domain Other Global groups from the same domain Can be converted to Universal scope if the group isn't a member of any other Global group On any domain in the same forest, or trusting domains or forests Universal groups from any domain in the same forest Other Global groups from the same domain Domain Local groups from any domain in the same forest, or from any trusting domain Domain Local Accounts from any domain or any trusted domain Global groups from any domain or any trusted domain Universal groups from any domain in the same forest Other Domain Local groups from the same domain Accounts, Global groups, and Universal groups from other forests and from external domains Can be converted to Universal scope if the group doesn't contain any other Domain Local group Within the same domain Other Domain Local groups from the same domain Local groups on computers in the same domain, excluding built-in groups that have well-known security identifiers (SIDs) Special identity groups Special identities are referred to as groups. Special identity groups don't have specific memberships that you can modify, but they can represent different users at different times depending on the circumstances. Some of these groups include Creator Owner, Batch, and Authenticated User. For more information, see  Special identity groups . Default security groups Default groups like the Domain Admins group are security groups that are created automatically when you create an Active Directory domain. You can use these predefined groups to help control access to shared resources and to delegate specific domain-wide administrative roles. Many default groups are automatically assigned a set of user rights that authorize members of the group to perform specific actions in a domain, like logging on to a local system or backing up files and folders. For example, a member of the Backup Operators group can perform backup operations for all domain controllers in the domain. When you add a user to a group, the user receives all the user rights that are assigned to the group, including all the permissions that are assigned to the group for any shared resources. Default groups are located in the Builtin container and in the Users container in Active Directory Users and Computers. The Builtin container includes groups that are defined with the Domain Local scope. The Users container includes groups that are defined with Global scope and groups that are defined with Domain Local scope. You can move groups that are located in these containers to other groups or organizational units within the domain, but you can't move them to other domains. Some of the administrative groups that are listed in this article and all members of these groups are protected by a background process that periodically checks for and applies a specific security descriptor. This descriptor is a data structure that contains security information that's associated with a protected object. This process ensures that any successful unauthorized attempt to modify the security descriptor on one of the administrative accounts or groups is overwritten with the protected settings. The security descriptor is present on the AdminSDHolder object. If you want to modify the permissions on one of the service administrator groups or on any of its member accounts, you must modify the security descriptor on the AdminSDHolder object so that it's applied consistently. Be careful when you make these modifications because you're also changing the default settings that are applied to all your protected administrative accounts. Step-By-Step: Manually Removing A Domain Controller Server https://techcommunity.microsoft.com/t5/itops-talk-blog/step-by-step-manually-removing-a-domain-controller-server/ba-p/280564 Use of DCPROMO is still the proper way to remove a DC server in an Active Directory infrastructure. Certain situations, such as server crash or failure of the DCPROMO option, require manual removal of the DC from the system by cleaning up the server's metadata. The following detailed steps will help you accomplish this: Step 1: Removing metadata via Active Directory Users and Computers Log in to DC server as Domain/Enterprise administrator and navigate to  Server Manager > Tools > Active Directory Users and Computers   Expand the  Domain > Domain Controllers     Right click on the Domain Controller you need to manually remove and click  D elete       Click  Yes  to confirm within the Active Directory Domain Services dialog box     In next dialog box, select  This Domain Controller is permanently offline and can no longer be demoted using the Active Directory Domain Services Installation Wizard (DCPROMO)  and click  Delete        If the domain controller is global catalog server, in next window click  Yes  to continue with deletion   If the domain controller holds any FSMO roles in next window, click  Ok  to move them to the domain controller which is available Step 2: Removing the DC server instance from the Active Directory Sites and Services Go to  Server manager > Tools > Active Directory Sites and Services   Expand the Sites and go to the server which need to remove   Right click on the server you which to remove and click  Delete        Click  Yes  to confirm   Step 3: Remove metadata via ntdsutil  Right Click on Start > Command Prompt (admin)   Type  ntdsutil  and enter      You are then presented with the  metadata cleanup  prompt     Next type  remove selected server NOTE:  Replace with domain Controller server you wish to remove     Click  Yes  to proceed when presented with the warning window   Execute the  quit command twice to exit out of the console USER PROFILES AND USER FOLDERS REDIRECTION USING GPO http://dalaris.com/user-profiles-and-user-folders-redirection-using-gpo/ Assume that you have a Microsoft Windows Server 2012 R2 installed and ADDS is configured, up and running. The following guide will show you how to configure a few policies using Group Policy Objects (GPO) to: Redirect User Profile (1) Redirect all personal stuff such as desktop, documents, Favourites, Contacts, Downloads, Links Music, Pictures, Saved Games, Searches, Start Menu, and Video. (2) Configure Drive Mapping to map N: drive to a public share such as \\DCD2\Shared. Set domain users’ home folder. Some other essentials properties for users. In this above list, it is worthwhile to note that User Profile Redirection (1) – also called Roaming Profile is different from Folder Redirection (2). It is recommended (best practice) to redirect user profiles to a different location than where we store users’ foldes such as Desktop, Documents, Music, etc… If we were to place user profile and folder redirection destination to the same location, we would have defeated the purpose of folder redirection. Folder redirection is meant to detach users’ folders away from their profiles so that the OS startup and logoff is faster. Setup two shared locations on the AD server called: UsersProfiles and UsersFolders The first step is to setup two shared locations for user profiles and user folders respectively. In D:\ Drive, or a separate partition different than the OS partition on the server, make new Directories called  UsersProfiles  and  UsersFolders  respectively. Do the following for both of the above folders, one at a time. Right-click on the folder, click Properties. Choose the Sharing tab. Click  Advanced sharing  and share it as  UsersProfiles$  (the $ is to make the share hidden). Click Permission and make sure the sharing permission is set as follows. Everyone  = FULL Also add System and Administrators and assign share permission as follows: System  = FULL Administrators  = FULL Choose the  Security  tab, hit  Advanced At the Permission tab, click Disable Inheritance. Click  Remove all inherited permissions from this object . Click the  Add  button. Click  Select a principal . Type  Everyone , click  OK . Choose  This folder Only  and click  Show advanced permissions. Choose the following Traverse folder / execute file List Folder / read Data Read Attributes Read Extended Attributes Create Folders / Append Data Read Permissions Hit  OK . Click Add. Click  Select a principal . Enter  Creator Owner . Click OK and give it  Full Control . Click Add, click Select a principal. Enter  System,  click OK and give it Full Control. Click Add, click Select a principal. Enter  Domain Admins , click OK and give it Full Control. Remember to do the same thing for  UsersFolders . We will end up with the following. Now launch  gpmc.msc  to open  Group Policy Management Console . Drill down to the domain DM.LOCAL, right-click on it and choose Create new GPO in this domain and link it here. Name is RedirectMapGPO and click OK. Right-click on the newly created Policy and click Edit… Now note that the Group Policy Management Editor is divided into two types of configurations: Computer Configuration and User Configuration. To Redirect the Desktop Folder: Under  User Configurations  click  Policies ,  Windows Settings ,  Folder Redirrection , Right-click  AppData(Roaming)  and choose  Properties . In the Target tab, choose  Basic – Redirect everyone’s folder to the same location Target Folder Location choose  Create a folder for each iuser under the root path Root Path: \\DCD2\UsersFolders$. Click  Apply . Yes to continue. Click the  Settings  tab. Checkmarks on the following items: Grant the user exclusive rights to Desktop Move contents of Desktop to new location Under  Physical Removal , choose  Leave folder in the new location when the policy is removed. Click  OK  when done. Repeat the same settigs for the following folders: Desktop, Start Menu, Documents, Pictures, Music, Videos, Favourites, Contacts Downloads, Links, Searches, and Saved Games. Folder Redirection is now completed. Let’s move on to redirecting user profiles. Redirecting System/User Profiles The following section describes how to redirect System / User profile to a remote network location. You can redirect user’s profile to a network location using mainly two methods. The first method is through the Computer Configuration. The second method is through User Properties. Configure User Profile Redirection through Computer Configuration. Go to Computer Configuration, Policies, Administrative Templates: Policy, System, User Profiles, click on it. Locate the setting called “Set roaming profile path for all users logging into this computer.” Double-click this setting. Select  Enabled . Enter the path for user profiles to be: \\DCD2\UsersProfiles$\%Username% Configure User Profile Redirection through User’s Properties. Note that this is the method I am using in this lab, so in the “Set roaming profile path for all users logging onto this computer” described above is set to  Disabled , as shown. Now we configure the user’s profile redirection based on the user’s properties. Launch dsa.msc, go to each user and choose Properties. Make sure of the followings Or, instead of doing one by one on a per user basis, select all users at once and choose Properties. Change their profile path as follows: This means that the user “test” will have its profile stored in \\DCD2\UsersProfiles$\test as shown. User profile redirection is now completed. Let’s configure a few more settings to perfect our GPO configuration for use in a domain environment. Mapped Drives Now we want to provide a mapped drive called H: that links to the users Home Directory. This is the UsersFolders path. To do this, we enable the following under User Configurations. Under User Configuration, click Preferences, expand Windows Settings, click Drive Maps. Right-click in an empty area and choose New, Mapped Drive. The drive mapping options are as follows: This is the final result. Accessory Policies (Optional) Let’s perfect our GPO by providing the following policies as well for the domain environment. This has nothing to do with Folder/Profile redirection but I include here for completeness. Computer Configurations, Policies, Windows Settings, Local Policies, Security Options, Domain controller: Refuse machine account password changes Enabled Domain member: Disable machine account password changes Enabled Interactive logon : Do not display last user name  Enabled Interactive logon : Do not require CTRL+ALT+DEL  Enabled Under Computer Settings, Policies, Administrative Templates, System, also enable the following settings. Display highly detailed status messages  Enabled Under Computer Settings, Policies, Administrative Templates, System, Logon Assign a default domain for logon:  Enabled Default Logon domain:  DM.LOCAL Update the GPO The settings are all done, now we need to update the GPO. Launch the command prompt and type gpupdate /forge This is to update the policy to make it effective. When prompting to log off, type N as we do not to log off from the server. Testing Test by logging into a computer with a domain credentials. Verify that all the settings stay on the server. If you have a compuer already on the domain and logged in, remember to restart it and also perform a gpupdate /force on it. Let’s log into a Windows 7 workstation to check out the settings. Login as  test . Click Start then right-click on Computer. Choose Properties. Choose Advanced System Settings. Under User Profiles click Settings. You can see that the user test is actually using Roaming Profile. Now, let do a few things. Create a folder and a file on the desktop Change the desktop background Make a Bookmark in Firefox Store a folder and a file in Documents Launch an application such as notepad and resize the windows. All of the above settings should persist across all computers. This is tested in my environment that it is so. Using NTDSUTIL Metada Cleanup to Remove a Failed/Offline Domain Controller Object. https://chinnychukwudozie.com/2014/01/27/using-ntdsutil-metada-cleanup-to-remove-a-failedoffline-domain-controller-object/ In this post, I would like to talk about using the ntdsutil utility for metadata cleanup. A domain controller failure ‘DC00’ recently occurred in my lab. Running the  repadmin /replsum  command confirmed a replication error and showed DC00 as unavailable: Since a dcpromo was obviously out of the question, I used the Ntdsutil metadata cleanup command to effect the removal in the following steps. Start the Ntdsutil Tool: Open a command prompt as an administrator. At the prompt, type ntdsutil and press enter. This put me directly in the ntdsutil mode. Entering ‘help’ shows all the options directly available : At the Ntdsutil prompt, select and type  metadata cleanup  command and press enter. At the metadata cleanup prompt, type  connections  and press enter. At the server connections prompt, type  connect to server ws2012r2  and press enter. Where ws2012r2 is a domain controller dns name. After connecting to the domain controller, type quit at the server connections prompt to exit out to the  metadata cleanup  prompt. Now at the  metadata cleanup  prompt, type  select operation target  and press enter. Entering this mode, will enable me select the sites, domains and servers I intend to work with. From the help options available at  select operation target , select, and type  list domains . Press enter. At the  select operation target  type  select domain 0 . Where domain 0 is the intended domain. At the next  select operation target  prompt, type list sites and press enter. At the next  select operation target  prompt, type  select site 0  and press enter. At the next  select operation target  prompt, type  list servers in site  and press enter. At the next  select operation target  prompt, type  select server 1  where server 1 is the offline domain controller object I intend to remove. Press enter. At the next  select operation target  prompt, type  quit  to exit out to the  metadata cleanup  prompt. At the next  metadata cleanup  prompt, type  Remove selected server . At the ‘Server Remove Confirmation Dialog’, click yes to remove the failed Domain Controller server object.After the removal is successful, I exit out of the  ntdsutil  tool by typing  quit  all the way up. I ran the  repadmin /replsummary  command again to verify and the result shows no replication errors. I still had to go into the DNS forward lookup and reverse lookup zones to manually remove references to the offline domain controller object.I hope this helps. Wrong error message for missing .adml files Symptoms SR symptoms: EN-US Domain Controller tries to create a settings report for a GPO. The report is created with the message: An appropriate resource file could not be found for file  \\domainname.com\sysvol\domainname.com\Policies\PolicyDefinitions\anyfile.admx  (error = 2): The system cannot find the file specified. The .admx Files reported as missing are present in the specified folder. Repro symptoms: Renaming the folder that contains the appropriate .adml files returns the error: An appropriate resource file could not be found for file  \\domainname.com\sysvol\domainname.com\Policies\PolicyDefinitions\anyfile.admx  (error = 3): The system cannot find the path specified. This error also happens when the EN-US folder does not exist and is missing. Editing the affected GPOs becomes impossible, reports are inaccurate. The problem does not happen in the same way when other language files and folders are missing as EN-US is the fallback language and it will be loaded instead when another language is missing. Cause In order to generate reports or edit the GPO, the .admx file needs to be loaded as well as the appropriate .adml language file. Depending on the native language user requesting the edit / reporting operation the .adml file is searched for in the appropriate language folder (en for en, de for de, an so on). If, for example, the querying user wants english and the GPO central store only has the german .adml files installed such an error would occur. The error reporting is incorrect since it is referring to the .admx file as missing, while this file is present at the specified location. Resolution Making the .adml files available for the language queried for in the correct folder solves the problem. See  How to create the Central Store for Group Policy Administrative Template files in Windows Vista . Data collection If you need assistance from Microsoft support, we recommend you collect the information by following the steps mentioned in  Gather information by using TSS for Group Policy issues . Transferring/Seizing FSMO Roles to Another Domain Controller https://woshub.com/transfer-seize-fsmo-roles-in-active-directory/ Transferring/Seizing FSMO Roles to Another Domain Controller In this article, we’ll consider how to find domain controllers with FSMO roles in Active Directory, how to transfer one or more FSMO roles to another ( additional/secondary) domain controller , and how to seize FSMO roles in case of a failure of the domain controller FSMO role owner.   Contents: Understanding FSMO Roles in Active Directory Domain How to List FSMO Role Owners in a Domain? How to Transfer FSMO Roles with PowerShell? Transferring FSMO Roles using Active Directory Graphic Snap-ins Using Ntdsutil.exe to Transfer FSMO Roles from the Command Prompt Seizing AD FSMO Roles   Understanding FSMO Roles in Active Directory Domain What are FSMO ( Flexible Single Master Operation ) roles in an Active Directory domain? You can perform most standard operations in Active Directory (like creating  new user accounts  and security groups or joining a computer to a domain) on any domain controller. The AD  replication  service is responsible for distributing these changes throughout the AD directory. Different conflicts (for example, simultaneous renaming of a user account on several domain controllers) are resolved using a simple principle — the last one is right. However, there are several operations during which a conflict is unacceptable (for example, when creating a new child domain/forest, changing the AD schema, etc.). To perform operations that require uniqueness, you need the domain controllers with the FSMO roles. The main task of the FSMO roles is to prevent such conflicts. There may be  five  FSMO roles in an Active Directory domain. Two roles  are unique for an AD  forest : The  Schema master  is responsible for making changes to the Active Directory schema (for example, when extending the AD schema using the  adprep /forestprep  command; The  Domain naming master  provides unique names for all domains and application sections you create in your AD forest (to manage it you need “Enterprise admins” privileges). There are  three  roles for each  domain  (to manage them, your account must be a member of the “Domain Admins” group): The  PDC emulator  is the main browser in your Windows network  ( Domain Master Browser is used  to show computers in the network environment ), it tracks  user lockouts when entering wrong passwords , it is the main NTP server in your domain, it is used to provide compatibility with clients running Windows 2000/NT, it is used by DFS root servers to update the namespace information ; The  Infrastructure Master  is responsible for updating the cross-domain object links; and the  adprep /domainprep  command is run on it; The  RID Maste r — the server distributes RIDs (in packs by 500 pieces) to other domain controllers to create unique object identifiers ( SIDs ). How to List FSMO Role Owners in a Domain? How can you find out which domain controllers are FSMO role holders in your Active Directory domain? To find all FSMO role owners in the domain, run the command: netdom query fsmo Schema master dc01.test.com Domain naming master dc01.test.com PDC dc01.test.com RID pool manager dc01.test.com Infrastructure master dc01.test.com You can view FSMO roles for another domain: netdom query fsmo /domain:woshub.com In this example, you can see that all FSMO roles are located on the DC01. When deploying a new AD forest (domain) , all FSMO roles are placed in the first DC. Any domain controller, except  RODC , may be a holder of any FSMO role. Accordingly, the domain administrator can transfer any FSMO role to any other domain controller. You can get the information about FSMO roles in your domain via PowerShell using the  Get-ADDomainController cmdlet  (the  RSAT   Active Directory for PowerShell module  must be installed): Get-ADDomainController -Filter * | Select-Object Name, Domain, Forest, OperationMasterRoles |Where-Object {$_.OperationMasterRoles} Or you can view the forest or domain-level FSMO roles as follows: Get-ADDomain | Select-Object InfrastructureMaster, RIDMaster, PDCEmulator Get-ADForest | Select-Object DomainNamingMaster, SchemaMaster Here are the general Microsoft recommendations for FSMO role placement in the domain: Place forest-level roles (Schema master and Domain naming master) on the root domain that is the Global Catalog server at the same time; Place all three domain FSMO roles on one domain controller with suitable performance; All forest DCs must be Global Catalog servers since it improves AD reliability and performance. Then the Infrastructure Master role is not necessary. If you have a DC without the Global Catalog role, place the Infrastructure Master role on it. Don’t place any other tasks on the FSMO roles owner DCs. You can transfer FSMO roles in Active Directory using several methods: using AD MMC graphic snap-ins,  ntdsutil.exe  or  PowerShell . Transferring FSMO roles is relevant when optimizing your AD infrastructure, or a DC that holds an FSMO role has suffered catastrophic hardware/software failure. There are two ways of moving FSMO roles:  transferring  (when both DCs are available) or  seizing  (when a DC with an FSMO role is not available or has been broken). How to Transfer FSMO Roles with PowerShell? The easiest and fastest way to transfer FSMO roles in a domain is using the  Move-ADDirectoryServerOperationMasterRole  PowerShell cmdlet. You can transfer one or more FSMO roles at a time to the specified DC. The following command will move two roles to DC02: Move-ADDirectoryServerOperationMasterRole -Identity dc03 -OperationMasterRole PDCEmulator, RIDMaster In the  OperationMasterRole  argument, you can specify either the name of the FSMO role or its index according to the following table: PDCEmulator 0 RIDMaster 1 InfrastructureMaster 2 SchemaMaster 3 DomainNamingMaster 4 The previous command in a shorter form looks like this: Move-ADDirectoryServerOperationMasterRole -Identity dc02 -OperationMasterRole 0,1 To transfer all FSMO roles at once to the additional domain controller, run this command: Move-ADDirectoryServerOperationMasterRole -Identity dc03 -OperationMasterRole 0,1,2,3,4 Transferring FSMO Roles using Active Directory Graphic Snap-ins To move FSMO roles, you can use standard Active Directory graphic snap-ins. The transfer operation is preferably performed on a DC with the FSMO role. If the server’s local console is not available, use the  Change Domain Controller  option and select the domain controller in the MMC snap-in. How to Transfer RID Master, PDC Emulator & Infrastructure Master Roles To transfer domain-level roles (RID, PDC, Infrastructure Master), the  Active Directory Users and Computers (DSA.msc) console  is used. Open the Active Directory Users and Computers (ADUC) snap-in; Right-click your domain name and select  Operations Master ; A window with three tabs (RID, PDC, Infrastructure) appears. Use these tabs to transfer the corresponding roles by specifying new FSMO owner and clicking the  Change  button. How to Transfer Schema Master Role To transfer the forest-level Schema Master FSMO, the Active Directory Schema snap-in is used. Before starting the snap-in, you must register the schmmgmt.dll library by running  regsvr32 schmmgmt.dll  in the command prompt; Open the MMC console, by typing  MMC  in the command prompt; Select  File  ->  Add/Remove snap-in  from the menu and add the  Active Directory Schema  console; Right-click the console root (Active Directory Schema) and select  Operations Master ; Enter the domain controller name you want to transfer the Schema Master role to, then click  Change  and OK. If the button is not available, make sure that your account is a member of the Schema Admins group. How to Transfer Domain Naming Master FSMO To transfer the Domain Naming Master FSMO role, open the  Active Directory Domains and Trusts  console; Right-click the name of your domain and select  Operations Master ; Click  Change , enter the name of the domain controller, and click OK. Using Ntdsutil.exe to Transfer FSMO Roles from the Command Prompt Important.  Use the ntdsutil.exe tool carefully and make sure you know what you are doing or you can break your Active Directory domain! Run the command prompt on your domain controller and run:  ntdsutil Enter this command:  roles Then:  connections Then you must connect to the DC you want to transfer FSMO roles to. To do it, enter:  connect to server Type  q  and press Enter; To transfer an FSMO role, use this command:  transfer  , where is the role you want to transfer. For example:  transfer schema master ,  transfer RID , etc; Confirm the FSMO role transfer; When it is done, press  q  and then Enter to quit ntdsutil.exe; Restart the domain controller. Seizing AD FSMO Roles If a DC with one of FSMO roles has been broken (and cannot be recovered) or is unavailable for a long time, you can force seize any of its roles. However, it is very important to make sure that the server you seize the role from must never appear in the network if you do not want any new problems with AD (even if you later restore the DC from the backup ). If you want to return the broken DC to the domain, the only correct method is to remove its computer account from AD, perform a clean Windows install with a new hostname, install the ADDS role, and promote the server to the domain controller. You can seize FSMO roles using PowerShell or NTDSUtil. The easiest way to seize an FSMO role is through PowerShell. To do it, the same Move-ADDirectoryServerOperationMasterRole cmdlet is used, but the  –Force  parameter is added to it. For example, to seize the PDCEmulator role and force transfer it to DC02, run the command: Move-ADDirectoryServerOperationMasterRole -Identity DC2 -OperationMasterRole PDCEmulator –Force You can also seize FSMO roles to your DC02 server using ntdsutil.exe. The role seizure is similar to the common transfer. Use the following commands: ntdsutil roles connections connect to server DC02  (the server you transfer a role to) quit To seize different FSMO roles, use these commands: seize schema master seize naming master seize rid master seize pdc seize infrastructure master quit Raise domain and forest functional levels in Active Directory Domain Services Raise domain and forest functional levels in Active Directory Domain Services Article 11/01/2024 4 contributors Applies to: ✅  Windows Server 2025 , ✅  Windows Server 2022 , ✅  Windows Server 2019 , ✅  Windows Server 2016 Feedback In this article Prerequisites View the current functional level Raise the functional level Related content Functional levels determine the available Active Directory Domain Services (AD DS) domain or forest capabilities. Functional levels also determine which Windows Server operating systems you can run on domain controllers in the domain or forest. Level changes happen when you use later versions of your domain controller operating system, the domain, or your forest functional level. This article describes how to raise Active Directory domain and forest functional levels. We recommend you upgrade Active Directory Domain Service servers to the latest release. To enable the latest domain features, all domain controllers in the domain must run the version of Windows Server that matches or is newer than the desired functional level. If they don't meet this requirement, the administrator can't raise the domain functional level. To enable the latest forest-wide features, all domain controllers in the forest must run the Windows Server operating system version that matches or is newer than the desired functional level. The current domain functional level must already be at the latest level. If the forest meets these requirements, the administrator can raise the forest functional level. The domain and forest functional levels only affect how the domain controllers operate together as a group. The clients that interact with the domain or with the forest are unaffected by the changes. Applications are also unaffected by these changes. However, applications can use new features found in later versions of Windows Server once the administrator raises the domain level. For more information about the functional levels, see  Active Directory Domain Services functional levels .  Warning Changes to the domain and forest functional levels are irreversible. In order to undo the change, you must perform a forest recovery to revert to an earlier point in time. Prerequisites You need to complete the following things to raise the domain functional level: All domain controllers in the domain are running at least the version of Windows Server that you want to raise the domain functional level to. For example, to raise the domain functional level to Windows Server 2025, all domain controllers in the domain must be running Windows Server 2025. If you have domain controllers running earlier versions of Windows Server, you must upgrade them to Windows Server 2025 before you can raise the domain functional level. Before you can promote a machine running Windows Server 2025 to a domain controller in an existing domain, that domain must also be at least at the Windows Server 2016 functional level. Earlier versions of Windows Server don't support Windows Server 2025 domain controllers. Your Active Directory forest and domain is operational and free from replication errors. To learn more about replication errors, see  Diagnose Active Directory replication failures . Identify all your DCs hosting the Global Catalog (GC) and FSMO roles. Create and verify backups of these domain controllers before making changes. You must be a member of the Enterprise Admins group or equivalent to raise the forest functional level. You must have a computer with either of the following Remote Server Administration Tools (RSAT) installed: AD DS Tools. OR Active Directory module for Windows PowerShell. To view the domain or forest functional level using PowerShell, follow these steps. Sign in to a computer with the AD DS Remote Server Administration Tools (RSAT) installed. Open PowerShell as an administrator. Run the following command to view the current domain functional levels of all domains in the forest. PowerShell Copy Get-ADForest | Select-Object -ExpandProperty Domains | ForEach-Object { Get-ADDomain $_ } | Select-Object Name, DomainMode Run the following command to view the current forest functional level, replacing   with the forest name. PowerShell Copy Get-ADForest -Identity | Select-Object ForestMode For more information about the  Get-ADDomain  and  Get-ADForest  cmdlets, see  Get-ADDomain  and  Get-ADForest . To raise the domain or forest functional level using PowerShell, follow these steps. Sign in to a computer with the AD DS Remote Server Administration Tools (RSAT) installed. Open PowerShell as an administrator. Run the following command to raise the domain functional level, replacing   with the domain name and   with the desired domain functional level. PowerShell Copy Set-ADDomainMode -Identity -DomainMode To confirm the change, select  Y . Once the domain functional level is raised, run the following command to raise the forest functional level, replacing   with the desired forest functional level. PowerShell Copy Set-ADForestMode -Identity -ForestMode To confirm the change, select  Y . You've now raised the domain and forest functional level. For more information about the  Set-ADDomainMode  and  Set-ADForestMode  cmdlets, see  Set-ADDomainMode  and  Set-ADForestMode .