[German]Since Microsoft released its cumulative (security) updates for Windows on September 13, 2022, copying or moving files via Group Policy (GPO) no longer works. I had addressed this here on the blog. Now a blog reader has provided me with some more hints as well as a PowerShell script to evaluate the paths that are affected. Therefore a supplement. Addendum: In addition, Microsoft has confirmed the problem.
Advertising
The Windows GPO problem
DThe cumulative (security) updates for Windows close various vulnerabilities and fix bugs. Shortly after the blog post Patchday: Windows 10 updates (September 13, 2022) was published, the first users came forward to report problems related to the creation of shortcut files:
After September updates, creating two shortcuts on users' desktops via GPO within the domain no longer works reliably. Computer policies as well as user policies (GPO) no longer copy files, one user wrote. Or the copied files are empty.
I had addressed this in the blog post Windows 10 Update KB5017308 causes issues when creating/copying files via GPO for Windows 10 and the update KB5017308 (available for Windows 10 Enterprise/Education 20H2 as well as for Windows 10 version 21H1-21H2). But the issue affects all Windows 10/11 clients as well as Windows Server 2019 – 2022 (and I mean Windows Server 2012 R2 as well).
Strange error message
Users who followed up reported finding an error code 0x800703ee in the Event Viewer application log.
The computer "" setting item in the group policy object "******** {97B70815-2B31-4A40-BB56-A27E6DAC6485}" was not applied due to an error. Error code: "0x800703ee The volume of a file has been externally modified so that the open file is no longer valid." This error was suppressed.
Error code 0x800703ee stands for ERROR_FILE_INVALID – somehow access to the files is probably lost.
Partial workarounds usable
In the blog post I had given a partial workaround – blog reader Sven describes it this way in this comment:
Advertising
After some searching it was clear, we copy the config files to the users new on the clients. But these files were copied with 0 KB after the update.
After unchecking that the files should be copied in the user context (user policy option) the copying via GPO worked again.
However, this does not help in all cases and application scenarios. One reader wrote in the English blog:
In my case I switched from user context to "machine context ":
–> Additionally I have to add read access for the ad-group "domain-computers" to the sourcefolder "\\server\share\" for the "machine context".
Read access for the ad-group (with users) was not working in the machine-context.
Another workaround was mentioned by a reader on the blog (here and here): Simply dispense with wildcards in file operations. However, this approach cannot be used in many scenarios. Ein weiterer Workaround wurde von einem Leser im englischsprachigen Blog erwähnt (): Einfach auf Wildcards bei Dateioperationen verzichten. Dieser Ansatz lässt sich aber in vielen Szenarien nicht verwenden.
New findings
German blog reader Markus K. took another look at the situation and sent me the following information by e-mail.
Hello,
I have looked into this at our end and can say the following:We copy a file in user context to the desktop, which is redirected to a share.
So far so good. Now the following screenshots:
Click to zoom
But the share does not know "System" – and in the user context means that the stuff should be done as "User"! So no wonder why that broke.
Whether it's good that now "in user context" is copied as "system"…. I don't know.
I can also report that a file copy action goes quite well if you write e.g. a file to Appdata\Local, also with "run in user context".
Markus wrote in his mail: To places where "System" is allowed to write, the copying will work. If you have to copy something somewhere where System has no rights, it gets more exciting. Then the file operation might fail.
A script for testing
Markus sent me a few lines of PowerShell script that can be used to quickly identify potentially affected group policies (GPOs).
$gpos = Get-GPO -All -Domain Your-Domain
$gpos | %{[string]$srep = Get-GPOReport $_.DisplayName -ReportType Xml -Domain DEINEDOMÄNE; if($($srep -match 'FilesSettings') -and $($srep -match 'userContext="1"')){[xml]$xrep = $srep; $xrep.DocumentElement.Name; $xrep.DocumentElement.Name | Out-File path-to-log.log -Append -Force }}Maybe this will help some desperate admins. Thanks to Markus for the hints.
Microsoft confirms the GPO problem
As of September 22, 2022, Microsoft has confirmed the problem on the Windows Release Healt Status page in the post Copyying files/shortcuts using Group Policy Preferences might not work as expected (thanks to riedenthied for the tip). All Windows versions are affected:
- Client: Windows 11, version 22H2; Windows 11, version 21H2; Windows 10, version 21H2; Windows 10, version 21H1; Windows 10, version 20H2; Windows 10 Enterprise LTSC 2019; Windows 10 Enterprise LTSC 2016; Windows 10 Enterprise 2015 LTSB; Windows 8.1.
- Server: Windows Server 2022; Windows Server 2019; Windows Server 2016; Windows Server 2012 R2; Windows Server 2012; Windows Server 2008 R2 SP1; Windows Server 2008 SP2.
after installing the September 13, 2022 security updates. Microsoft states in this regard:
After installing KB5017315 (or the update that matches the Windows version), file copies with Group Policy settings may fail or create empty shortcuts or files with 0 (zero) bytes.
Known affected Group Policy objects refer to files and shortcuts in User Configuration -> Settings -> Windows Settings in Group Policy Editor..
Microsoft is working on a fix and plans to roll it out in one of the next versions of updates. As a workaround for this issue, Microsoft suggests the following:
- Disable the "Run in the security context of the logged on user (user policy option)" option. Note: For items that use a wildcard (*), this may not resolve the issue.
- In the affected group policy, change "Action" from "Replace" to "Update".
- If a wildcard (*) is used in the location or destination, deleting the trailing "\" (backslash, without quotes) from the destination may allow the copy operation to succeed.
In an email to me, a blog reader raised the question of whether the WSUS snafu, which I addressed in the blog post WSUS chaos: Preview updates for Windows and Net withdrawn as superseded on 9/21/2022, had anything to do with the GPO problem. Because in the Microsoft Answers forum a user wrote:
Everyone with this issue should try latest Preview Update KB5017380 which probably addresses an issue that affects Group Policy Objects.
User JSB_116 added:
We have an open Microsoft case, and we just got a message from Microsoft that installing Preview Update KB5017380 solve the problem. Can anyone confirm that.
No idea if this is true – a user named DomLu confirms it:
Yes it resolved our apparent issues with Group Policy Preferences- File actions… we'll see what else is broken soon lol.
On the other hand, Rene-Comedian negates this very insight in MS Answers, writing:
I have installed kb5017308 und yesterday kb5017380, and still I can redproduce the problems with deploy files via gpp, if the "in user context"-box is checked.
In other words: Microsoft probably tried to patch something, but didn't really get it right. Let's see if there is a solution until the October 2022 patchday.
Similar articles:
Microsoft Security Update Summary (September 13, 2022)
Patchday: Windows 10-Updates (September 13, 2022)
Patchday: Windows 11/Server 2022-Updates (September 13, 2022)
Advertising
Hi ,
I try the Script from Markus but i can not create an output File .
Hope you can help me .
Guess some output path or domain name is wrong. Better post our question at the German blog post and describe the error you are receiving.
That possibly means you have no impacted GPO or you are not running with admin id (which match the if condition) . You can do a simple test by replacing if condition from "match" to "notmatch" and see if you get an output file. Also remember to change domainname and give path to log file something like c:\temp\output.log.
When you said that a possible workaround is to "Disable the "Run in the security context of the logged on user (user policy option)" option."
Don't you mean to ENABLE the "Run in the security context of the logged on user (user policy option)" option?
It seems that if the problem is that the normal account used for processing group policy file copies is SYSTEM, then you'd want to change the user account away from that default setting by ENABLING the "use the security context of the logged in user." I tested this workaround and it worked for me.