Two different clients, neither storing credentials in credential manager. Login required everytime.

That's the fix we could use now on impacted boxes yes, but it won't be indefinate. Heck next month's rollup might fix it... it's hard to say.

But yes, this does seem to be a 2004 bug... interesting that it doesn't impact all installs.
 
That's the fix we could use now on impacted boxes yes, but it won't be indefinate. Heck next month's rollup might fix it... it's hard to say.

But yes, this does seem to be a 2004 bug... interesting that it doesn't impact all installs.

TYPICAL MICRO$HAFT
 
I brought it back forward to 1909 and have used step 4 in this article to defer feature updates for 365 days and quality updates for 30 days. This will be interesting to watch. So far no issues since removing 2004 version.

 
I brought it back forward to 1909 and have used step 4 in this article to defer feature updates for 365 days and quality updates for 30 days. This will be interesting to watch. So far no issues since removing 2004 version.


So you ended up using the Local Group Policy editor to keep it on 1909?
 
One of the stations with the issue is still capable of rolling back ... doing that now.

The main station I've been working on now has a clean 2004 install so I guess I'll need to go back out and bring a 1909 ISO.
 
Here's a policy registry file you can use if you've got pro:
Code:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"DeferFeatureUpdates"=dword:00000001
"BranchReadinessLevel"=dword:00000020
"DeferFeatureUpdatesPeriodInDays"=dword:00000016D
"PauseFeatureUpdatesStartTime"=""
"ElevateNonAdmins"=dword:00000000
"AcceptTrustedPublisherCerts"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"IncludeRecommendedUpdates"=dword:00000000
"AUPowerManagement"=dword:00000001
"NoAutoRebootWithLoggedOnUsers"=dword:00000000
"NoAUShutdownOption"=dword:00000000
"AutoInstallMinorUpdates"=dword:00000001
"DetectionFrequencyEnabled"=dword:00000001
"DetectionFrequency"=dword:00000016
"RebootRelaunchTimeoutEnabled"=dword:00000001
"RebootRelaunchTimeout"=dword:0000003c
"RescheduleWaitTimeEnabled"=dword:00000001
"RescheduleWaitTime"=dword:0000001e
"UseWUServer"=dword:00000000
"NoAutoUpdate"=dword:00000000
"AUOptions"=dword:00000004
"ScheduledInstallDay"=dword:00000002
"ScheduledInstallTime"=dword:00000002
"ScheduledInstallEveryWeek"=dword:00000001
"AllowMUUpdateService"=dword:00000001
"NoAUAsDefaultShutdownOption"=dword:00000000
"EnableFeaturedSoftware"=dword:00000000
"RebootWarningTimeoutEnabled"=dword:00000000
"AutomaticMaintenanceEnabled"=dword:00000001
"AlwaysAutoRebootAtScheduledTime"=dword:00000000

Each of these lines does stuff, but the one you care mostly about is this one:

"DeferFeatureUpdatesPeriodInDays"=dword:00000016D

16D is 365 days. So 1909 won't update until 11/11/2020. Which only buys you a month... you might have to increase it.
 
So you ended up using the Local Group Policy editor to keep it on 1909?
No in step 4 it mentions:
Start > Settings > Update & Security. Click the link marked Advanced options. Under Choose when updates are installed, use the drop-down boxes to defer feature updates for 365 days and quality updates for 15 days.
I set the quality updates for 30 days
 
First rollback went all the way back to 1903 ... I'll push it up to 1909.
Interesting. That's exactly what mine went back to 1903. I know it's a risk but I wonder if after going back to 1909 what would happen if I then installed 2004.
Do I take the risk? I'll have to mull that over.
 
That is a fascinating theory... all of my units were 1909 before going to 2004.

But if an upgrade fault was in play wouldn't that mean the fresh install was immune?
 
That is a fascinating theory... all of my units were 1909 before going to 2004.

But if an upgrade fault was in play wouldn't that mean the fresh install was immune?
True. I'm going to watch the machine tonight and tomorrow morning. Then I'm thinking of handing the machine back tomorrow & then if it's ok getting it back in a couple of weeks and pushing it back to 2004 again just to see what happens.
 
I don't know how many of these computers went from 1903 to 2004 or how many made it to 1909 but I can confirm with certainty that a fresh 2004 install does not fix the issue.

*On some computers
 
Code:
Get-ScheduledTask | foreach { If (([xml](Export-ScheduledTask -TaskName $_.TaskName -TaskPath $_.TaskPath)).GetElementsByTagName(“LogonType”).’#text’ -eq “S4U”) { $_.TaskName } }

The above link says running that will highlight an HP service that causes this?

Which implies other things could do it too...

I have an HP printer but do not have results from the above... I also don't have the problem... so there's that.
 
I have two customers now with this issue. I'm logged into one of them now, and she doesn't have anything HP on her system. Running the Powershell command returns a task created by Carbonite.
I know the other customer has an HP printer as well as Carbonite, but I didn't get a chance to run the command on that system yet.
Not sure I want to disable Carbonite for this, or start to convince her to move to a different product if we don't know for sure this is the issue.
 
Both systems are the only two systems in this office that have HP Printers installed on them.

Ran the PowerShell command on one which returned:

HPCustParticipation HP ColorLaserjet MFP M278-M281

Ran PowerShell command on the second one which returned:

HPCustParticipation HP ColorLaserjet MFP M278-M281

I looked up the task and it is set to:

Run at 4:30pm on 10/9/2020 - After triggered, repeat everyone 1 hour indefinitely.

Makes sense, sort of, since she is required to login all day long to various services, but it may also go a period of time without having to login, I do not have exact numbers on that period.



They both have the same printer. One has been downgraded to 1903 and I'm bumping it up to 1909. I will leave the other one that is actively experiencing the issue on 2004 and have the user test.
 
Reporting back ... the user running 2004 who WAS actively experiencing the issue is no longer experiencing the issue and has not for 2 hours. Will continue to monitor.
 
Third client who is completely different from the first two, just a single laptop, not at all associated with the first company but also experiencing the same issue also had the Task enabled:

HPCustParticipation HP Officejet 4650

Deleted the task and with have him monitor.
 
I delivered the laptop back this morning with it running 1909. They have a second laptop they are going to get me the first of the week. I'm going to try the Task schedule trick on that one.
Being able to work together on a problem like this is what makes this a great community.
 
Back
Top