Pre-upgrade

First, if you have Azure (Entra) AD Connect installed on the server, an in-place upgrade will mess things up quite badly. What Microsoft suggests is to use the Swing migration to set the original server in stage mode and temporarily move the Azure (Entra) AD Connect to a different server.

You will also need to prepare the AD schema before the in-place upgrade. Mount the Windows Server 2019 or 2022 Installation ISO media, go to the support\adprep folder and run the following commands.

adprep /forestprep
adprep /domainprep

Once done, run the following PowerShell cmdlet to confirm the result about the schema version you are about to upgrade to.

Get-ADObject (Get-ADRootDSE).schemaNamingContext -Property objectVersion

Here is the schema version value table for your reference.

Windows Server 2012 R2 - 69
Windows Server 2016 - 87
Windows Server 2019 - 88
Windows Server 2022 - 88

The actual upgrade

Now, it is good to go with the in-place upgrade. The actual process will be quite straightforward and should be done fairly quickly.

Post-upgrade

Everything should be up and running right away, including DNS, AD services as well as group policy setups. Two things might require your attention.

The DHCP server might need to be re-authorized to be used again.

Also, if you are using the SMTP services from the legacy IIS 6, you might need to re-configure everything. The settings were wiped out during one of my upgrades. It’s a good idea to document the setup before doing the upgrade.

References:

• Microsoft Entra Connect: Upgrade from a previous version to the latest
• Upgrade domain controllers to a newer version of Windows Server

It’s actually way easier. To retrieve the logon activities from a remote computer for the past 7 days, all you need is to run this.

Get-EventLog System -Source Microsoft-Windows-WinLogon -After (Get-Date).AddDays(-7) -ComputerName $computer

However, in order to pull the event log from a remote computer, the Remote Registry service needs to be running on that computer. It’s disabled by default for security reasons.

You will need to reenable the service and start it before pulling the log entries.

Invoke-Command -ComputerName $computer -ScriptBlock {
    $service = 'RemoteRegistry'
    Set-Service -Name $service -StartupType Manual
    Start-Service -Name $service
}

Once done, you will need to stop and disable it too.

Invoke-Command -ComputerName $computer -ScriptBlock {
    $service = 'RemoteRegistry'
    Stop-Service -Name $service
    Set-Service -Name $service -StartupType Disabled
}

So, putting everything all together,

$computer = Read-Host "Coomputer Name:"
Invoke-Command -ComputerName $computer -ScriptBlock {
    $service = 'RemoteRegistry'
    Set-Service -Name $service -StartupType Manual
    Start-Service -Name $service
}
$logs = Get-EventLog System -Source Microsoft-Windows-WinLogon -After (Get-Date).AddDays(-7) -ComputerName $computer
ForEach ($log in $logs){
    $user = Get-ADUser -Filter * | Where-Object {$_.SID -eq $log.ReplacementStrings[1]}
    $log.TimeGenerated.ToString() + ' - ' + $user.Name + ' - ' + $log.Message
}
Invoke-Command -ComputerName $computer -ScriptBlock {
    $service = 'RemoteRegistry'
    Stop-Service -Name $service
    Set-Service -Name $service -StartupType Disabled
}

Bonus point, I’ve formatted the output with a real username as well.

Guess I was wrong. I kept getting this error message telling me that either the credential is wrong or something like below.

So, what went wrong?

The problem is more in the wording. While it says “Log On To” and “Logon Workstations”, it actually means the computers from both ends. For example, if User-A needs to RDP in Computer-B from Computer-A. Both Computer-A and Computer-B’s names need to be in the Logon Workstations list. Missing either one will result in not being able to remote in.

But as you can see, it doesn’t have the Remote Desktop Service Profile tab. So how do you batch update this property to a large number of users when needed?

Here is a quick example of using PowerShell to find all users that belong to a specific OU and update them with the new network path for remote desktop service profiles.

$users = Get-ADuser -Filter * -SearchBase "OU=Test, DC=Test, DC=LOCAL"
$newpath = ''

ForEach ($user in $users){
    $userinfo = [ADSI]"LDAP://$($user.DistinguishedName)"
    $userinfo.psbase.invokeset('TerminalServicesProfilePath', $newpath)
    $userinfo.setinfo()
    $user.name + ' ' + $userinfo.TerminalServicesProfilePath
}

Enjoy.

Assume you already have your on-premises Active Directory cleaned up and prepared for Azure AD Connect, here are the steps that would make it happen.

First off, keep the accounts that you want to convert off the OU that will be synced up with Azure AD Connect. If you already have accounts duplicated in Microsoft 365, permanently delete these accounts first before moving forward.

Then, update the Cloud account’s UPN to match the one on on-premises AD.

Once done, run the following PowerShell cmdlets to match on-premises AD’s GUID with Cloud account’s Immutable ID. Making both IDs match tells Azure AD that the account is linked with on-premises Active Directory.

Connect-MsolService
$upn = "name@domain.com"
$id = [system.convert]::ToBase64String((Get-ADUser -filter {userprincipalname -eq $UPN}).objectGUid.ToByteArray())
Set-MsolUser -UserPrincipalName $upn -ImmutableId $id

Thanks to here for the ImuutableID trick.

If you encounter any cmdlet not found error, install and import the MSOnline module first from an elevated PowerShell window.

Install-Module MsOnline

Finally, move these accounts back to the syncing OU and sync them all to Microsoft 365.

The process of setting it up isn’t hard but it’s not easy and straightforward either. Here is a quick guide on how to make it happen.

Local AD Preparation

If your local domain has the same name as the one verified in Microsoft 365, preparation is easy. All you need to do is to make sure the UPN (UserPrincipalName) attribute matches the one you are planning to use in Microsoft 365.

However, if your local AD domain is a non-routable domain such as .local, you will need to add a second UPN suffix and update your users to it. The synced accounts with .local UPN will be automatically assigned the default onmicrosoft.com domain.

To Add a new UPN suffix

First, open Active Directory Domains and Trusts. Right-click Active Directory Domains and Trusts and choose Properties.

And add a new UPN suffix in the Properties window that pops up.

To update UPN suffix for existing users

You can update it in the Account tab in each user account’s properties window. But a much better way is to use PowerShell.

$adusers = Get-ADUser - Filter * -SearchBase "OU=OU Name, DC=domain, DC=local" | Sort-Object Name
$adusers | ForEach {$_ | Set-ADUser -UserPrincipalName ($_.SamAccountName + '@domain.com')}

The IdFix tool

There are other attributes in your AD that might need to be cleaned up, such as proxyAddresses, SAMAccountName, etc. The best way is to use a tool like IdFix to identify and remediate the majority of directory synchronization errors.

You can download the tool in your Micrsoft 365 Directory Sync Status page and run it directly on your domain-joined Windows 10 computer.

An Account for Azure AD Sync

The Azure AD Connect tool will help set it up during the setup wizard but it’s easier to have it ready before you run the configuration wizard.

Create a regular domain account with a password that matches the AD’s password complicity policy. And you will have to grant the user the following two permissions. Or the password hash sync will fail.

• Replicating Directory Changes
• Replicating Directory Changes All

To do so,

1. Open Active Directory Users and Computers
2. Go to View and select Advanced Features.
3. Right-click the main domain name and choose Properties.
4. In Security tab, add the account you want to use to directory sync and Allow the above two permissions.

Azure AD Connect

Now, let’s download the Azure AD Connect, install it on the Active Directory server, and run the configuration wizard. Follow up the wizard and it should be up and running shortly.

A few notes though that I hope would help.

You can sync the entire directory or the OUs of your choice.

There two ways you can stage your AD sync process. You can either enable the Stage mode in Azure AD Connect, or filter users via a specified group.

Note that if you use the Group filter option with the selected OUs, make sure the group resides inside that OU. Or, no accounts will be sync’d up.

To force a sync to start out of the scheduled window, run the following PowerShell cmdlet.

Start-ADSyncSyncCycle -PolicyType Delta

To initiate a complete sync,

Start-ADSyncSyncCycle -PolicyType Initial

If you are seeing an error telling you that the cmdlet is not recognized, run this.

Import-module ADSync

Resources

• Microsoft 365 integration with on-premises environments
• Set up directory synchronization for Microsoft 365
• Prepare for directory synchronization to Microsoft 365
• Prepare a non-routable domain for directory synchronization
• Azure AD Connect Sync: understand and customize synchronization

In order to use PowerShell to communicate with Active Directory, you will need the Active Directory module installed for PowerShell. The easiest way is to install RAST (Remote Server Administration Tools) on your Windows 10 computer.

Import photos to Active Directory

To save a photo for a specific user, Get-Content of the picture in a sequence of bytes and then use Set-ADUser to replace the ThumbnailPhoto property.

$photo = [byte[]](Get-Content $photopath -Encoding byte)
Set-ADUser $username -Replace @{thumbnailPhoto=$photo}

You can name all the photos to match usernames in Active Directory’s and use the combination of Get-ADUser and Set-ADUser to import a bunch of photos at once.

$users = Get-AdUser -Filter * -SearchBase "OU=users, DC=domain, DC=local" -properties thumbnailphoto
foreach ($user in $users) {
    $photopath = "path\" + $user.samaccountname + '.jpg'
    $photo = [byte[]](Get-Content $photopath -Encoding byte)
    Set-ADUser $user -Replace @{thumbnailPhoto=$photo}
}

Export photos from Active Directory

To export the photo from a specific user, use Get-ADDUser to locate the user with a particular property named ThumbnailPhoto. Then extract the ThumbnailPhoto property and encode it to a sequence of bytes.

$user = Get-ADUser $username -Properties thumbnailPhoto
$user.thumbnailPhoto | Set-Content $photopath -Encoding byte

To export all photos attached to all users from a specific OU, you can do something similar like below:

$users = Get-AdUser -Filter * -SearchBase "OU=User, DC=domain, DC=local" -properties thumbnailphoto
foreach ($user in $users) {
    $photo = "\\sharepoint\c$\inetpub\wwwroot\cisco\" + $user.samaccountname + '.jpg'
    $user.thumbnailphoto | set-content $photo -encoding byte
}

And that’s about it. It works like a charm in my case. Enjoy.

Here is a checklist of things you need to know when it comes to syncing time in a Windows domain based network.

Firs of all, where to check to know what the exact time is right now?

Time.is is that place that tells you not only what the time is now but checks if your computer clock is off.

How to sync time for Domain Controller

Since my domain controller is virtualized, I don’t actually need to do anything on AD level. All I need is to make sure the host that all VMs rely on has an accurate time all the time. Basically, I can enable the NTP Client on the host and have it sync to specified NTP servers.

If setting up NTP on the host level isn’t an option, maybe because the host doesn’t have the access to the internet, here is what you can also do.

Open an elevated Command Prompted window on the domain controller and run the following command:

net stop w32time
w32tm /config /manualpeerlist:"0.uk.pool.ntp.org,0x1 1.uk.pool.ntp.org,0x1 2.uk.pool.ntp.org,0x1 3.uk.pool.ntp.org,0x1"
w32tm /config /reliable:yes
net start w32time

Now, running w32tm /resync should be completed successfully.

How to sync time on domain workstations

The quickest way to sync your computer with the domain time is to run the following command in an elevated Command Prompt window.

net time /domain

You can schedule it or put it as part of your login script so it runs frequently enough to keep the time synced with AD all the time. But obviously, it’s not ideal because it’s better done in Group Policy level if you are in an AD environment.

Open the Group Policy assigned to an OU that includes all the workstations on your network and then navigate to the following location:

Computer Configuration > Policies > Administrative Templates > System > Windows Time Service > Time Providers

Enable the Configure Windows NTP Client policy and set yourdc.yourdomain,0x1 as the NtpServer.

And enable the “Enable Windows NTP Client” policy afterwards.

To test it out, you can either reboot a workstation or run GPUpdate /Force to update the policy on the local computer and run the following to display the status of the time service.

w32tm /query /status

That’s about it. Here are a few w32tm command options that you use to find more information:

w32tm /query /configuration – check NTP configuration

w32tm /query /source – display time source

w32tm /query /peers – display the list of all configured NTP servers and their status

What is KRBTGT?

The KRBTGT is a local default account that acts as a service account for the Key Distribution Center (KDC) service. It’s created automatically when a new domain is created.

• It cannot be deleted
• its name cannot be changed
• it cannot be enabled
• it only belongs to the following two groups
  • Domain Users
  • Denied RODC Password Replication Group

KDC service handles all Kerberos ticket requests so KRBTGT account in AD plays a key role that encrypts and sign all Kerberos tickets for the domain.

You can also use the PowerShell code to get the account’s detail as well:

Get-AdUser krbtgt -property created, passwordlastset, enabled, sid, distinguishedname

How it works:

1. User logs on with AD user name and password to a domain-joined computer (usually a workstation).
2. The user requests authentication by sending a timestamp (Pre-auth data) encrypted with the users password-based encryption key (password hash).
3. User account (user@adsecurity.org) requests a Kerberos service ticket (TGT) with PREAUTH data (Kerberos AS-REQ).
4. The Kerberos server (KDC) receives the authentication request, validates the data, and replies with a TGT (Kerberos AS-REP).

Why do you need to update its password?

99.99% of the time, the KRBTGT account’s password has not changed since the AD Domain was set up. But since it’s a domain account, all writable DCs know the account password in order to decrypt Kerberos tickets for validation.

Because of that, the attackers may use the KRBTGT account to persist on the network even if every other account has its password changed. During an incredibly awesome talk (Video) at the Black Hat 2014 security conference in Las Vegas, NV in early August, Skip Duckwall & Benjamin Delpy spoke about a method (using Mimikatz) to generate your own Kerberos tickets (aka the Golden Ticket).

And that’s why Microsoft now recommends that the KRBTGT password change on a regular basis.

How to change the password?

Microsoft posted a KRBTGT account password PowerShell script on TechNet that will change the KRBTGT account password once for a domain, force replication, and monitor change status.

Note that changing the KRBTGT account password in a 2008 (or higher) DFL will not cause replication issues.

There are two KRBTGT Password Change Scenarios:

• Maintenance: Changing the KRBTGT account password once, waiting for replication to complete (and the forest converge), and then changing the password a second time, provides a solid process for ensuring the KRBTGT account is protected and reduces risk (Kerberos and application issues).
• Breach Recovery: Changing the KRBTGT account password twice in rapid succession (before AD replication completes) will invalidate all existing TGTs forcing clients to re-authenticate since the KDC service will be unable to decrypt the existing TGTs. Choosing this path will likely require rebooting application servers (or at least re-starting application services to get them talking Kerberos correctly again).

Resources:

• Kerberos & KRBTGT: Active Directory’s Domain Kerberos Service Account
• Active Directory Accounts
• Reset the krbtgt account password/keys

Asking help from PowerShell is my answer.

There are two places where we can gather this information. The AD contains the bad password attempts and the lockout status while the security event log saves the user account lockout information when it happens.

To get bad password attempts info from AD, use Get-ADUser cmdlet.

Get-ADUser -Filter * -Properties AccountLockoutTime,LastBadPasswordAttemptBadPwdCount,LockedOut

If you want just the info for the past day, pipe the result to Where clause.

Get-ADUser -Filter * -Properties AccountLockoutTime,LastBadPasswordAttemptBadPwdCount,LockedOut | Where {$_.LastBadPasswordAttempt -gt (Get-Date).AddDays(-1)}

To get the account lockout info, use Get-EventLog cmd to find all entries with the event ID 4740. Use -After switch to narrow down the date.

Get-EventLog -LogName "Security" -ComputerName "AD_Server" -After (Get-Date).AddDays(-1) -InstanceID "4740" | Select TimeGenerated, ReplacementString

Depending on the size of the log file, it could take a while to get all the result.

Going through the result, you may find the data shown on the screen is incomplete. That’s because the ReplacementString is a string array that contains the event log data in an XML type of format. Each event type has its own string structure. For 4740 events, 

• ReplacementString[0] stores the name of the computer where the account gets locked out and
• ReplacementString[1] indicates the name of the user account that gets locked out.

So, instead of running the above cmdlet, the following script provides a lot more clear useful info.

#Collect lockout accounts from ADS

$logname = "security"
$dcname = (Get-AdDomain).pdcemulator
$eventID = "4740"
$content = Get-EventLog -LogName $logname -ComputerName $dcname -After (Get-Date).AddDays(-1) -InstanceId $eventID | Select TimeGenerated, ReplacementStrings
$ofs = "`r`n`r`n"
$body = "Fetching event log started on " + (Get-Date) + $ofs

If ($content -eq $null)
{
    $body = $body + "No lock-out accounts happened today" + $ofs
}
Else 
{
    Foreach ($event in $content)
    {
        $source = $content.ReplacementStrings[1]
        $username = $content.ReplacementStrings[0]
        $body = $body + $event.TimeGenerated + ": " + $username + " - " + $source + $ofs
    }
}
$body

Hope it helps.