Set Up Group Policy on Windows Server 2025: Drive Maps, Printers

When a new hire logs on and calls to ask where the shared drive is, the fix shouldn’t be a visit to their desk. A small office needs three things from Group Policy on day one. Everyone gets the same S: drive, Finance alone gets F:, and the office printer turns up on its own. This is the Group Policy Windows Server 2025 setup we keep for that job, built with the console already on the domain controller.

Original content from computingforgeeks.com - post 180443

You’ll build an ADMX central store from Microsoft’s current templates, link GPOs to an OU, map drives with Group Policy Preferences and item-level targeting, and deploy a shared printer. Each change is proved on the client with gpupdate and gpresult, and the failures we hit get their own section. We tested every step in October 2026 on a Windows Server 2025 domain controller with a Windows 11 24H2 workstation joined to it.

Understanding how a GPO reaches the PC

A Group Policy Object does nothing until it is linked to a site, the domain or an organizational unit, and it only reaches the users and computers that sit under that link. Windows processes the links in a fixed order, so you can predict which setting wins before you open a single console:

1. Local policy on the machine itself
2. GPOs linked to the Active Directory site
3. GPOs linked to the domain
4. GPOs linked to each OU, parent first, then the child OU that holds the object

That order is why admins call it LSDOU. The rule that follows is simple: the last GPO to write a setting wins, so a GPO on the user’s own OU beats one on the domain unless the domain link is enforced. Each GPO also has two halves. The Computer Configuration half applies at startup and to the machine account, while the User Configuration half applies at logon and only to user accounts in the linked OU. Put a user setting in a GPO linked to an OU that holds only computers and it never applies, which is the most common “GPO not working” ticket we see.

Drive maps and printers live under Preferences, not Policies, and the difference matters for day two. A policy setting is enforced: the user can’t change it, and Windows removes it when the GPO stops applying. A preference is written into the user’s normal settings, refreshed on every background cycle by default, and left behind when the GPO goes away unless you tell it otherwise. Background refresh runs every 90 minutes plus a random offset of up to 30, so a change you make now reaches logged-on users within two hours, or right away with gpupdate /force.

Preparing the domain controller and the workstation

Everything below runs from an elevated PowerShell window on the domain controller unless a step says otherwise. If you don’t have a domain yet, our Active Directory Domain Services install gets you there first. This is what the lab looked like, and it’s the minimum you need to follow along.

• DC01, a Windows Server 2025 domain controller at 10.0.1.10 for the domain office.lan
• WS01, a Windows 11 Pro or Enterprise PC (Home can’t join a domain)
• A domain admin account for the console work
• Internet access on the DC for one download, or the ADMX installer copied over

The Group Policy Management Console comes with the AD DS role tools, but it’s a separate feature, so install it explicitly. The command is harmless when the feature is already there.

Install-WindowsFeature GPMC -IncludeManagementTools

GPOs need somewhere to land, so create two OUs: one for staff accounts and one for workstations. Keeping users and computers apart is what lets you link a user-side GPO to Staff without it touching servers. The Finance group drives the item-level targeting later, and the two test users let you see the difference between a member and a non-member. The password must meet the domain’s complexity policy, or New-ADUser can’t set it and leaves the accounts disabled:

$pw = Read-Host -AsSecureString 'Password for the test users'
New-ADOrganizationalUnit -Name 'Staff' -Path 'DC=office,DC=lan'
New-ADOrganizationalUnit -Name 'Workstations' -Path 'DC=office,DC=lan'
New-ADGroup -Name 'Finance' -GroupScope Global -GroupCategory Security -Path 'OU=Staff,DC=office,DC=lan'
New-ADUser -Name 'Amina Otieno' -SamAccountName amina -UserPrincipalName [email protected] -Path 'OU=Staff,DC=office,DC=lan' -AccountPassword $pw -Enabled $true
New-ADUser -Name 'Brian Kamau' -SamAccountName brian -UserPrincipalName [email protected] -Path 'OU=Staff,DC=office,DC=lan' -AccountPassword $pw -Enabled $true
Add-ADGroupMember -Identity 'Finance' -Members amina

The drive maps need real shares behind them. Share permissions here are only as wide as each team needs: everyone can change files on Shared, only Finance on Finance. A drive map can’t grant access the share doesn’t allow, so a user outside Finance who somehow got F: would still see “Access is denied”:

New-Item -ItemType Directory -Force C:\Shares\Shared, C:\Shares\Finance
New-SmbShare -Name Shared -Path C:\Shares\Shared -ChangeAccess 'OFFICE\Domain Users' -FullAccess 'OFFICE\Domain Admins'
New-SmbShare -Name Finance -Path C:\Shares\Finance -ChangeAccess 'OFFICE\Finance' -FullAccess 'OFFICE\Domain Admins'
icacls C:\Shares\Shared /grant 'OFFICE\Domain Users:(OI)(CI)M'
icacls C:\Shares\Finance /grant 'OFFICE\Finance:(OI)(CI)M'

On WS01, in an elevated PowerShell window as a local administrator, point DNS at the domain controller and join the PC straight into the Workstations OU. Joining into the right OU saves you the step everyone forgets, moving the computer out of the default Computers container, which no GPO can link to.

$if = (Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object -First 1).Name
Set-DnsClientServerAddress -InterfaceAlias $if -ServerAddresses 10.0.1.10
Add-Computer -DomainName office.lan -NewName WS01 -OUPath 'OU=Workstations,DC=office,DC=lan' -Credential (Get-Credential OFFICE\Administrator) -Restart

After the restart, sign in to WS01 as OFFICE\amina once so her profile exists. Before any GPO has settings, her gpresult /r /scope user lists nothing under Applied Group Policy Objects, which is the baseline to compare against.

Building the ADMX central store

Without a central store, the Group Policy editor reads administrative templates from whichever machine you happen to open it on. Two admins on two servers then see different settings for the same GPO, and a setting defined in a newer template shows up as “Extra Registry Settings” in the GPMC settings report on the older one. Open any GPO in the editor and expand User Configuration > Policies: on a fresh Server 2025 DC the node reads “Policy definitions (ADMX files) retrieved from the local computer.”

The fix is a PolicyDefinitions folder in SYSVOL, which replicates to every DC. Fill it from Microsoft’s latest template package rather than from the server’s own folder: Server 2025 ships 222 ADMX files, while the Windows 11 2025 Update (25H2) templates carry 232, including settings your 24H2 and 25H2 clients understand. Download and install the package on the DC:

$msi = "$env:TEMP\admx-25h2.msi"
Invoke-WebRequest -Uri 'https://download.microsoft.com/download/f35d3000-b6c9-4ca6-bedc-5e4ec15a6b7a/Administrative%20Templates%20(admx)%20for%20Windows%2011%20Sep%202025%20Update.msi' -OutFile $msi -UseBasicParsing
Start-Process msiexec.exe -ArgumentList "/i `"$msi`" /qn /norestart" -Wait
Get-ChildItem 'C:\Program Files (x86)\Microsoft Group Policy'

The installer only unpacks files; it doesn’t touch SYSVOL. It creates one folder per release, which is the path the copy step needs.

Name
----
Windows 11 Sep 2025 Update (25H2)

Copy the ADMX files and the en-US language files into the central store. The package also carries 21 other language folders; copy only the ones your admins use, because every ADML file you add is one more file SYSVOL replicates. Robocopy creates the PolicyDefinitions folder for you:

$src = 'C:\Program Files (x86)\Microsoft Group Policy\Windows 11 Sep 2025 Update (25H2)\PolicyDefinitions'
$store = '\\office.lan\SYSVOL\office.lan\Policies\PolicyDefinitions'
robocopy $src $store *.admx /NFL /NDL /NJH /R:1 /W:1
robocopy "$src\en-US" "$store\en-US" *.adml /NFL /NDL /NJH /R:1 /W:1

Each run ends with a summary. Copied should equal Total and FAILED should be 0; on our DC the ADMX pass moved 232 files (4.01 MB) and the ADML pass another 232 (3.18 MB):

               Total    Copied   Skipped  Mismatch    FAILED    Extras
    Dirs :         1         1         0         0         0         0
   Files :       232       232         0         0         0         0
   Bytes :    4.01 m    4.01 m         0         0         0         0
   Times :   0:00:21   0:00:21                       0:00:00   0:00:00

Close and reopen the editor. The same node now says the definitions come from the central store, and every admin who opens a GPO from any machine in the domain sees the same 232 templates.

The first open after the copy is slow, because the editor parses every template over the SYSVOL share; on our 4-vCPU DC it took close to a minute before the node expanded. When the next Windows release ships new templates, Microsoft’s advice is to build the new set in a folder such as PolicyDefinitions-26H2, rename the live folder out of the way, and rename the new one in. That gives you a one-rename rollback if a template breaks the editor.

Creating and linking GPOs in the Group Policy Management Console

Keep one GPO per job. A “Staff Drive Maps” GPO and a “Staff Printers” GPO can be disabled, filtered or rolled back on their own, while one “Staff Settings” GPO that does everything turns every change into a risk to everything else. In the console you’d right-click the Staff OU, pick Create a GPO in this domain, and Link it here, and name it. The PowerShell equivalent does both steps and is easier to repeat:

New-GPO -Name 'Staff Drive Maps' -Comment 'S: for everyone, F: for Finance'
New-GPLink -Name 'Staff Drive Maps' -Target 'OU=Staff,DC=office,DC=lan' -LinkEnabled Yes
New-GPO -Name 'Staff Printers'
New-GPLink -Name 'Staff Printers' -Target 'OU=Staff,DC=office,DC=lan'

Each New-GPO returns the GPO’s ID, which is also its folder name under SYSVOL, and New-GPLink confirms the target and the link order.

DisplayName : Staff Drive Maps
Id          : b019c11a-8495-4b26-aa32-f4ebf843fd27
GpoStatus   : AllSettingsEnabled

GpoId       : b019c11a-8495-4b26-aa32-f4ebf843fd27
DisplayName : Staff Drive Maps
Enabled     : True
Enforced    : False
Target      : OU=Staff,DC=office,DC=lan
Order       : 1

Check what the OU inherits before you add settings, because a GPO on the domain that sets the same thing will be overridden by yours, and you want to know that now rather than when a user calls:

Get-GPInheritance -Target 'OU=Staff,DC=office,DC=lan'

InheritedGpoLinks lists the effective order, the OU’s own links first and the Default Domain Policy last, which is LSDOU read from the winning end.

Name                  : staff
ContainerType         : OU
Path                  : ou=staff,dc=office,dc=lan
GpoInheritanceBlocked : No
GpoLinks              : {Staff Drive Maps, Staff Printers}
InheritedGpoLinks     : {Staff Drive Maps, Staff Printers, Default Domain Policy}

The Group Policy Management Console shows the same thing when you select the Staff OU: both GPOs on the Linked Group Policy Objects tab, link order 1 and 2, neither enforced. Link order matters only when two GPOs on the same OU set the same thing, and then link order 1 wins.

One thing surprised us here. With both GPOs linked but still empty, amina’s gpresult on WS01 still showed “N/A” under Applied Group Policy Objects. A GPO with nothing in its User Configuration half is skipped for users entirely, so an empty GPO missing from the report is normal, not a broken link.

Mapping drives with Group Policy Preferences

Drive maps are a user setting, so they go in the User Configuration half of the GPO linked to the Staff OU. Right-click Staff Drive Maps in the console and choose Edit, then go to User Configuration > Preferences > Windows Settings > Drive Maps, right-click Drive Maps and pick New > Mapped Drive. The S: drive every staff member gets takes four values:

1. Action: Replace
2. Location: \\dc01.office.lan\Shared
3. Reconnect ticked, Label as: Shared
4. Drive Letter: Use, S

The Action field is where most drive-map tickets start, and the choice isn’t obvious from the names. This is how each one behaves on the client:

Action	What the client does	Use it when
Create	Creates a new mapping for the user	A one-off drive you don’t need to police afterwards
Replace	Deletes the mapping and recreates it on every refresh, creating it if missing	The path must always be right, even after a user remaps the letter
Update	Changes only the fields set in the item, creating the drive if missing	You want to keep a user’s own label or credentials
Delete	Removes the mapping	Retiring an old share

We use Replace for shared drives because it heals itself: if someone maps S: to a USB share at home, the next refresh puts it back. Update is the gentler choice when users keep their own label or credentials on a drive, because it leaves every field you didn’t set alone. Use the FQDN in the path, not the short name: a PC whose DNS suffix list doesn’t include office.lan, a VPN laptop for example, can still resolve dc01.office.lan but not plain dc01.

Giving only Finance the F: drive with item-level targeting

You could create a second GPO and filter it to the Finance group, but item-level targeting keeps both drives in one place and avoids the security-filtering trap covered in the troubleshooting section. Create a second mapped drive the same way, with Replace, \\dc01.office.lan\Finance, label Finance and letter F. Then open its Common tab:

1. 1Remove this item when it is no longer applied
2. 2Item-level targeting
3. 3Targeting...

1. Tick Remove this item when it is no longer applied
2. Tick Item-level targeting
3. Click Targeting…

The first box is the one people skip, and it’s the one that matters when someone changes teams. Without it, a user who leaves Finance keeps F: mapped forever, because a preference that stops applying is simply left in place. Notice that ticking it greys out “Apply once and do not reapply”; the two options contradict each other. In the Targeting Editor, choose New Item > Security Group, click the … button, type Finance and press Enter so the editor resolves the name to a SID:

Leave “User in group” selected, since the drive follows the person and not the PC. Click OK on both dialogs. The editor writes both items to one XML file in the GPO’s SYSVOL folder, and reading it is the quickest way to confirm what you clicked actually saved.

Get-Content 'C:\Windows\SYSVOL\domain\Policies\{B019C11A-8495-4B26-AA32-F4EBF843FD27}\User\Preferences\Drives\Drives.xml'

Look for action="R" on both drives, removePolicy="1" on F:, and a FilterGroup element carrying the Finance SID:

<Drives clsid="{8FDDCC1A-0C3C-43cd-A6B4-71A6DF20DA8C}"><Drive clsid="{935D1B74-9CB8-4e3c-9914-7DD559B7A417}" name="S:" status="S:" image="1" changed="2026-10-30 08:41:52" uid="{66C26E65-5E60-4344-8F3F-1D48B60D1202}"><Properties action="R" thisDrive="NOCHANGE" allDrives="NOCHANGE" userName="" path="\\dc01.office.lan\Shared" label="Shared" persistent="1" useLetter="1" letter="S"/></Drive>
	<Drive clsid="{935D1B74-9CB8-4e3c-9914-7DD559B7A417}" name="F:" status="F:" image="1" removePolicy="1" bypassErrors="1" changed="2026-10-30 08:46:26" uid="{D70898AA-082D-48BC-843A-4683672A1B8F}"><Properties action="R" thisDrive="NOCHANGE" allDrives="NOCHANGE" userName="" path="\\dc01.office.lan\Finance" label="Finance" persistent="1" useLetter="1" letter="F"/><Filters><FilterGroup bool="AND" not="0" name="OFFICE\Finance" sid="S-1-5-21-3778530057-3768371804-1503282553-1102" userContext="1" primaryGroup="0" localGroup="0"/></Filters></Drive>
</Drives>

Your GPO ID and SID will differ; take the ID from the New-GPO output. If the file is missing after you clicked OK, the editor didn’t save. On our first attempt the dialog froze with “Not Responding” while the DC was busy with Defender scans and servicing. It closed minutes later with nothing written. Recreating the item once the server was idle saved it on the first click.

Deploying a shared printer with Group Policy

Printer deployment by GPO is two pieces: a printer shared from a server, and a preference item that connects users to that share. The share is where the driver decision gets made, and it decides whether standard users can connect at all. Since Microsoft’s PrintNightmare fixes (KB5005652), Point and Print only lets administrators install a driver from a print server. A driver that already ships with Windows, such as the PCL6 class driver, sidesteps that because there’s nothing to download.

Share the office printer from DC01 with that class driver. Sharing printers from a DC is a lab shortcut: Microsoft’s guidance keeps the Print Spooler on domain controllers only for print pruning, so in production put the queue on a member server with the Print Server role. The Group Policy side is identical:

Add-PrinterDriver -Name 'Microsoft PCL6 Class Driver'
Add-PrinterPort -Name 'IP_10.0.1.60' -PrinterHostAddress '10.0.1.60'
Add-Printer -Name 'Office-Printer' -DriverName 'Microsoft PCL6 Class Driver' -PortName 'IP_10.0.1.60' -Shared -ShareName 'Office-Printer' -Location 'Front office'
Get-Printer -Name 'Office-Printer' | Format-List Name,ShareName,Shared,DriverName,PortName

Change 10.0.1.60 to your printer’s IP address. Shared must read True before any GPO can point at it.

Name       : Office-Printer
ShareName  : Office-Printer
Shared     : True
DriverName : Microsoft PCL6 Class Driver
PortName   : IP_10.0.1.60

Now edit the Staff Printers GPO and go to User Configuration > Preferences > Control Panel Settings > Printers. Right-click Printers and choose New > Shared Printer:

Fill in three fields: Action set to Update, Share path \\dc01.office.lan\Office-Printer, and Set this printer as the default printer ticked. Update is the right action here, unlike the drive maps. Replace would delete and re-add the printer connection on every refresh, while Update only adds it when it’s missing. The default-printer box overrides whatever the user picked, so leave it off if people choose their own default. The “…only if a local printer is not present” option under it is the middle ground for laptops that also print at home.

Checking the result with gpupdate and gpresult

Users pick up the new GPOs at their next logon or background refresh. To see the result now, run these on WS01 in the user’s own session. Don’t use “Run as administrator” with an admin account for this, because gpresult then reports that admin’s policy, not the user’s:

gpupdate /force
net use
gpresult /r /scope user

For amina, a Finance member, both drives map and both GPOs show as applied. The group list at the bottom of the gpresult report is the one to read when targeting misbehaves, because item-level targeting checks the user’s logon token and nothing else. This excerpt is trimmed to the lines that matter:

Updating policy...

Computer Policy update has completed successfully.
User Policy update has completed successfully.

Status       Local     Remote                    Network
-------------------------------------------------------------------------------
OK           F:        \\dc01.office.lan\Finance Microsoft Windows Network
OK           S:        \\dc01.office.lan\Shared  Microsoft Windows Network
The command completed successfully.

USER SETTINGS
--------------
    CN=Amina Otieno,OU=Staff,DC=office,DC=lan
    Last time Group Policy was applied: 10/30/2026 at 12:03:53 PM
    Group Policy was applied from:      DC01.office.lan

    Applied Group Policy Objects
    -----------------------------
        Staff Drive Maps
        Staff Printers

    The user is a part of the following security groups
    ---------------------------------------------------
        Domain Users
        Everyone
        BUILTIN\Users
        NT AUTHORITY\INTERACTIVE
        CONSOLE LOGON
        NT AUTHORITY\Authenticated Users
        This Organization
        LOCAL
        Finance

Printer connections from Group Policy Preferences are per user, so the quickest check that works from any prompt is the user’s registry.

reg query HKCU\Printers\Connections

The connection shows up as a key named after the server and share, with the backslashes turned into commas.

HKEY_CURRENT_USER\Printers\Connections\,,dc01.office.lan,Office-Printer

On WS01 the PCL6 class driver appeared in Get-PrinterDriver right after that refresh, with no Point and Print warnings in the Application log, which confirms the in-box driver route works for a standard user. If you share a printer with a vendor driver instead, expect the connection to fail for non-admins until you pre-install the driver on the clients.

The F: drive was the last thing to prove. We removed amina from Finance on the DC and had her log off and back on, because group membership only changes in a fresh logon token. After that logon, net use listed S: alone, and the group list in gpresult no longer showed Finance. That’s the “Remove this item when it is no longer applied” box doing its job: the drive went away with the membership, with nobody touching the PC.

Fixing a GPO that doesn’t apply

Most “the GPO isn’t working” cases come down to scope, filtering or name resolution, and gpresult tells you which before you change anything. These are the failures we reproduced on the lab pair, with the exact text each one produced.

Filtering: Not Applied (Unknown Reason)

This is the security filtering trap, and it’s the one that catches people who scope a GPO “properly”. In the console you select the GPO, and on the Scope tab you remove Authenticated Users from Security Filtering and add only the user or group who should get it. It looks right, but since the MS16-072 update Windows reads user GPOs with the computer’s account, and the computer now has no right to read the GPO at all. We set Staff Drive Maps up that way, with only amina allowed to apply it, and her next refresh dropped it:

Two details make this one hard to spot. The System log logged no error, only event 1503 saying user settings “were processed successfully” with 1 GPO instead of 2. And S: stayed mapped, because a Replace item without the Remove option is left behind when its GPO stops applying, so the user notices nothing until you change the path. Give Domain Computers read access and leave amina’s Apply permission alone:

Set-GPPermission -Name 'Staff Drive Maps' -TargetName 'Domain Computers' -TargetType Group -PermissionLevel GpoRead

In the console the same fix is the Delegation tab, Add, Domain Computers, Read. The next gpupdate /force as amina listed Staff Drive Maps under Applied again. Item-level targeting, as used for F:, avoids the problem entirely, because the GPO stays readable by everyone and the filter is evaluated per item on the client.

Set-GPPermission: Object reference not set to an instance of an object

We hit this while scripting the scenario above. Set-GPPermission -TargetName 'Authenticated Users' -PermissionLevel None failed with a NullReferenceException on Server 2025, with and without -Replace, and left the permissions unchanged. Adding a permission with the same cmdlet worked every time. If you need to remove a trustee from a script, the GPMC COM object the console itself uses does it:

$gpm = New-Object -ComObject GPMgmt.GPM
$c = $gpm.GetConstants()
$dom = $gpm.GetDomain('office.lan', '', $c.UseAnyDC)
$gpo = $dom.GetGPO('{B019C11A-8495-4B26-AA32-F4EBF843FD27}')
$sec = $gpo.GetSecurityInfo()
$sec.RemoveTrustee('S-1-5-11')
$gpo.SetSecurityInfo($sec)

S-1-5-11 is the well-known SID for Authenticated Users. Run Get-GPPermission -Name 'Staff Drive Maps' -All afterwards to confirm the trustee is gone, and remember the read permission for Domain Computers from the previous fix.

Windows could not resolve the computer name (event 1055)

A domain PC that uses a public resolver instead of the domain controller can’t find the domain at all. We pointed WS01’s DNS at 1.1.1.1 and ran a computer refresh:

gpupdate /target:computer /force

It failed at once, and the System log recorded the same text as error 1055.

Computer policy could not be updated successfully. The following errors were encountered:

The processing of Group Policy failed. Windows could not resolve the computer name. This could be caused by one of more of the following:

a) Name Resolution failure on the current domain controller.

b) Active Directory Replication Latency (an account created on another domain controller has not replicated to the current domain controller).

The message blames the DC, but the cause was the client’s DNS setting. Point the adapter back at the DC (Set-DnsClientServerAddress as in the join step) and check the secure channel with nltest /sc_query:office.lan; ours returned NERR_Success and the next refresh completed. On a network where DHCP hands out a public resolver, fix the DHCP option, or every laptop that renews its lease breaks again. Microsoft’s Group Policy troubleshooting guide covers events 1058 and 1030, the SYSVOL-read and settings-retrieval failures; we didn’t reproduce either on this pair, but they share the same first check, name resolution to the DC.

Keeping Group Policy healthy after day one

A GPO is a production change like any other, and the console has no undo. Back up every GPO before you edit one. The command below writes to the DC’s own disk, so copy the folder to another host afterwards, or give -Path a UNC share on a file server.

New-Item -ItemType Directory -Force C:\GPOBackups
Backup-GPO -All -Path C:\GPOBackups

Each GPO gets its own folder named after a new backup ID. That’s the Id column in the output, and it isn’t the GPO’s own ID, which trips people up when they go looking for a GPO’s folder:

DisplayName                       Id                                   BackupDirectory
-----------                       --                                   ---------------
Staff Printers                    cf40ccc3-8fe2-41d6-a20b-0e0ff8522540 C:\GPOBackups
Default Domain Policy             b1ac5e53-a25c-47a8-b09b-f954ca1f8f79 C:\GPOBackups
Default Domain Controllers Policy f62dffd7-c51c-4369-8d7e-3b45978b4d77 C:\GPOBackups
Staff Drive Maps                  1b27de2f-7b77-4be2-859e-3d8f0f2761f2 C:\GPOBackups

Beyond backups, refresh the central store when a new Windows release ships its templates, using the versioned folder swap, and give Domain Computers read on any security-filtered GPO the day you create it. Put a comment on every GPO saying what it does and who asked for it, because in two years nobody will remember why “Staff Printers 2” exists.

The one log to watch is the Group Policy provider in the System log on the client. A healthy refresh logs 1500 and 1501 for the computer and user when nothing changed, or 1502 and 1503 with a count of GPOs applied when something did, so a count that drops without anyone changing scope is your early warning for the filtering problem above:

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-GroupPolicy'; StartTime=(Get-Date).AddHours(-2)} | Select-Object -First 5 TimeCreated, Id, LevelDisplayName, Message | Format-List

If the same machines also take their Windows updates from your own server, the WSUS guide uses a GPO linked the same way to point clients at it, and our Windows Server administration books list covers Group Policy design in more depth than one lab can. For a fresh lab of your own, start from a Windows Server template on Proxmox and the Windows Server 2025 install walkthrough.