N
NetOpsECC
Guest
Windows Server 2016 domain environment, Windows 10 build 1809 clients running Microsoft Office 2019.
A couple of months ago, our users started reporting that when they open an Office document (Word, PowerPoint, Excel) when they log on to any workstation, they get a message saying the file is locked for editing by another user. If they close the document and re-open it, it works fine. Looking on the file server shows that the file is open by that user.
We managed to replicate the problem with our testing accounts, and after some investigation (eventually resorting to uninstalling Windows updates one at a time until the problem went away) we discovered it was a Windows Update.
I haven't managed to deduce exactly which update causes the problem, but I believe it is one of the Dot Net CU's. Below is the list of updates I have uninstalled (using DISM as I needed a script to do it on 1000 workstations)
Package_for_DotNetRollup~31bf3856ad364e35~amd64~~10.0.1.3034
Package_for_DotNetRollup~31bf3856ad364e35~amd64~~10.0.1.3105
Package_for_KB4480056~31bf3856ad364e35~amd64~~10.0.1.2305
Package_for_KB4486153~31bf3856ad364e35~amd64~~10.0.1.2919
Package_for_RollupFix~31bf3856ad364e35~amd64~~17763.805.1.13
Package_for_RollupFix~31bf3856ad364e35~amd64~~17763.864.1.10
Package_for_RollupFix~31bf3856ad364e35~amd64~~17763.973.1.6
Unfortunately there is no way to find out the KB numbers of these updates without looking at get-packageinfo, but since I have now uninstalled the updates I can't do that.
Has anyone else come across this issue over the last couple of months? These are pretty important security updates but they are causing so many problems for our users we had to remove them in the short term.
More...
A couple of months ago, our users started reporting that when they open an Office document (Word, PowerPoint, Excel) when they log on to any workstation, they get a message saying the file is locked for editing by another user. If they close the document and re-open it, it works fine. Looking on the file server shows that the file is open by that user.
We managed to replicate the problem with our testing accounts, and after some investigation (eventually resorting to uninstalling Windows updates one at a time until the problem went away) we discovered it was a Windows Update.
I haven't managed to deduce exactly which update causes the problem, but I believe it is one of the Dot Net CU's. Below is the list of updates I have uninstalled (using DISM as I needed a script to do it on 1000 workstations)
Package_for_DotNetRollup~31bf3856ad364e35~amd64~~10.0.1.3034
Package_for_DotNetRollup~31bf3856ad364e35~amd64~~10.0.1.3105
Package_for_KB4480056~31bf3856ad364e35~amd64~~10.0.1.2305
Package_for_KB4486153~31bf3856ad364e35~amd64~~10.0.1.2919
Package_for_RollupFix~31bf3856ad364e35~amd64~~17763.805.1.13
Package_for_RollupFix~31bf3856ad364e35~amd64~~17763.864.1.10
Package_for_RollupFix~31bf3856ad364e35~amd64~~17763.973.1.6
Unfortunately there is no way to find out the KB numbers of these updates without looking at get-packageinfo, but since I have now uninstalled the updates I can't do that.
Has anyone else come across this issue over the last couple of months? These are pretty important security updates but they are causing so many problems for our users we had to remove them in the short term.
More...