[German]Sort September 2022 patchday recap. It looks like the cumulative (security) update KB5017308 released on September 13, 2022 for Windows 10 comes with collateral damage. I have received several reports from readers that following the update installation, creating or copying files via GPO or creating GPO settings files no longer works.
Advertising
Windows 10 Update KB5017308
Cumulative update KB5017308 is available for Windows 10 Enterprise/Education 20H2 as well as Windows 10 version 21H1-21H2, and is supposed to fix various things. I had informed about it in the blog post Patchday: Windows 10-Updates (September 13, 2022) and also mentioned issues with daylight saving time (see Windows 10/ 11: Possible daylight saving time changeover issues [in Chile and worldwide]). Microsoft is holding back on details of what the update fixes. The list of improvements can be found in the blog post Windows 10 Preview Update KB5016688 (August 26, 2022).
GPO related file operation issues reported
Shortly after the publication of the blog post Patchday: Windows 10-Updates (September 13, 2022), the first users came forward reporting issues in connection with the creation of shortcut files. In the meantime, I have received further reports.
Shortcuts on desktop via GPO broken
German blog reader Aike has reported issues in this German comment and describes there the following misbehavior under Windows 10 21H2 now with current build 19044.2006, i.e. after installing update KB5017308.
After September updates, creating two shortcuts on the users desktop via GPO within the domain no longer works reliably.
After a GPUPDATE /force on the client, one of the two shortcuts created by the GPO disappears. After another manual call of GPUPDATE /force it is available again and disappears again independently (after the default GPUPDATE interval). This game can be played on as an endless loop.
Set in the policy: User Configuration/Settings/Windows Settings/Links.
"Link to a web application A" and "Link to a web application B" – action "Replace". Within each object target type: URL location: desktop – otherwise no parameters. Options common to both objects: Run in the security context of the logged in user (user policy option) & Remove item when no longer applied.
It worked wonderfully for years – Now this behavior.
German blog reader Markus also confirms (in the same comment thread) that computer and user policies (GPOs) are no longer copying files. Windows 10 clients are affected as well as Server 2022/2019 – here is the translated text:
we have the problem too. Computer policies as well as user policies (Gpo) do not copy files anymore (Win10 Client as well as Server 2022/2019) – unfortunately, Sven's workaround did not help in our case.
Message in the 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…Update uninstalled – everything works again
More reports via mail and facebook
German blog reader Sebastian G. contacted me by mail today and pointed me to the a reddit.com thread, which discusses problems with copying files after installing the KB501730 update. A post there states:
Advertising
Our patch manager accidentally pushed the update to live production instantly, yay!
Issues encountered Win10 21H2 KB5017308:
gpo file copy seems to not work properly (shortcuts lose their icon and batch file is blank)
can no longer deploy programs from lansweeper
There is also a 2nd reddit.com thread about that issue. On Facebook, blog reader Simon A. also brought up the problem (see screenshot) to me in a closes administrator group, and pointed to a mention on Geek at Works:
Windows Update KB5017308 breaks GPO preferences file creation
Anyone observing the same issue? All files created with GPO preferences in replace mode are having 0 kb. Doesn't matter if these are newly created links or files copied to a machine with GPO preferences.
Again, it is reported that uninstalling the update solves the problem. The short article links to this Microsoft Answers forum thread, which also states that shortcut files cannot be created via GPO.
Addendum: I got reports from German blog readers, that the issue occurs also on Windows 11, Windows Server 2016 and Windows Server 2022. Using GPO to copy files in user context fails.
A possible workaround
Several users report that if copying the files via GPO is not done in the user context, it works again. German blog reader Sven wrote a workaround he was using within this German comment (I've translated it):
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.
Also on Microsoft Answers you can find the following note from Adam Postgate in this forum post:
Yes we had this today too – try un-checking "run in user security context" on any gpo
I assumed it was needed for %userprofile% variable to work, but it isn't
It's definitely worth a try – although there are user reports that it didn't work and the problems persist. Thanks to all users for the feedback – I have reported the bug to Microsoft via MS Answers and on Twitter. I know also, that some business users has opened a support ticket.
Addendum: More details are covered at the article Windows GPO bug (copy/move) caused by Sept. 2022 update confirmed by Microsoft. Microsoft has also confirmed the bug, as shown in this article.
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)
Windows 7/Server 2008R2; Windows 8.1/Server 2012R2: Updates (September 13, 2022)
Advertising
Hi,
I confirm the problems with copying files via gpo (GPP)
In my case:In the machine context if you replace a file one to one it is ok
\\server\share\text.txt –> C:\folder\text.txt
Instead I use wildcard is not work:
\\server\share\*.* –> C:\folder\
Hi,
I also confirm the problems with copying files via gpo (GPP)
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
I wracked my brain trying to understand why the user could copy the file, but the GPO in the user security context could not. Switched GPO over to logon robocopy batch script before I found this article. Unchecking the "Run in User security context" fixes the issue in our testing.
I've the same trouble. I've temporary fixed it by creating a gpup.cmd script in Domain netlogon with only "gpupdate" in it. Not changing anything else
If you have redirected desktops/start menus that are redirected to a network folder then removing "Run in User Security context" prevents the shortcuts from being created in the redirected folders. Setting the shortcut to "Update" rather than "Replace" fixes it.
The Office 365 App Policies wich are also run in User Context seem to be affected as well. https://config.office.com/officeSettings/officePolicies
I just unistalled the KB5017308 and they now work fine again.
So, does the KB5017380, which has superseded this solve the issue?
no, in a machine context same issue.
Thanks Nick!
In our case, this was only affecting 11 files over 3 GPOs. So implementing the workaround of unchecking user context has worked for us. I also had to implement the heavy hand of changing the mode to replace so that the 0-byte files get overwritten.
I am holding the patch deployment for another day, but if no other issues arise, we will roll with it over the weekend.
We have had this deployed to our test group for a week now and have not had any complaints, which is surprising. This should have been breaking several applications as we were using this to configure licensing. I suppose it only hits fresh logins so that might be why we had no feedback about it.
We have the same behaviour on our Servers 2016 since KB5017305.
Unchecking "Run in User Security context" will fix the issue for all Clients/Servers which have KB5017305/KB5017308 installed.
We have the same behaviour on our Servers, Workstatins, etc….. Resolution for us is: Do not use WILDCARDS. Copy only single file in GPO, after that, all working.
Of course this works as long as you have a few files
but if the files are different and they keep changing, the method used via gpo no longer works. Strange that nowhere has microsoft ever taken a position, even saying that this is a permanent change and can no longer be used in the future. In any case, a warning is generated in the event log with an error, so I am hoping for an official statement on the matter.
Have any of you opened a case at MS?
Our symptom was with a custom font being deployed by GP:
Computer Context > Single File/Filename > Replace > (from)Netlogon (t0)Windows\Fonts = Caused font file to become empty. After next policy refresh the font would return.
The symptom appeared as a bad font in an automatically generated report, after we discovered it was the font file missing, we began re-installing it immediately as a workaround, so the policy refresh alternately breaking/fixing the issue was not immediately evident. After flushing the font cache unsuccessfully we found articles mentioning the GPO bug; empty files, etc. Switched GPO from replace – which re-writes the file every time to update which leaves the file alone if it hasn't been changed and the symptom went away. Other files pushed out by GPO invoked the …volume of a file has been externally modified… error. I would say that moving from replace to update was the key fix in our case.
As I wrote within the article: I've reported the issue to Microsoft and I know from German users, that multiple administrators opened a support case.
The issue has now been confirmed – see Windows Release Health Status
MS answered with Workarounds:
- Uncheck the "Run in logged-on user's security context (user policy option)". Note: This might not mitigate the issue for items using a wildcard (*).
- Within 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 might allow the copy to be successful.
Workaround 2+3 solved Problem for us.
https://learn.microsoft.com/en-us/windows/release-health/status-windows-10-1809-and-windows-server-2019#2910msgdesc
Great, thanks
N.
I can't even change the action from "Replace" to "Update" in our shortcuts – it's greyed out. I can change from "Update" to any other action without problems though…
How can I change it from Replace to Update? :(
Unchecking "Run in User Security context" will not fix the issue when destination is user homeshare on the servers.
kb5017308 broke all applications preferences in %AppData% (Roaming)
We end up uninstalling kb5017308 on workstations.