top of page

OUR PRECONDITIONS

  • The old network infrastructure, referred to as OldNet:
    Doesn’t support 802.1x.
    Two domains on different VLAN’s with a one way trust, referred to as Enterprise and Educational.
    The two domains have their own network infrastructure, different IP Helpers, DNS, DHCP and so on.

  • The new infrastructure, referred to as NewNet:
    802.1x is required using CISCO ISE and Layer 3 switches.
    Only one fallback net with its own IP range, common for both domains, which also supports WebAuth guest access.
    The two domains still have their own IP range, DHCP, DNS etc. but will use the same PXE-server since PXE boot is taking place on the fallback network.

  • Both the old and the new network infrastructure will be used to deploy Windows 10 x64 and Windows 7 x86.

  • MAB will not be used during OSD, the network team don’t want to spread a special OSD VLAN so clients will get an IP address according to its current location and only certificate-based authentication is allowed.

  • The task sequence needs to support both the new computer and refresh scenario as well as BIOS to UEFI conversion regardless of the currently installed operating system.
    The scripts used for managing 802.1x needs to support Windows 7 and its PowerShell version.

Search
Writer's picturesomeguy100
Apr 6, 20212 min read

The USOal suspect’s new hideout

Updated: Feb 7

Long story short, while trying to update our client base to 1909 we noted that things weren’t going as we wished they were. I noticed that there seemed to be a pending reboot, caused by a driver, which was blocking the FU. Nothing that a reboot won’t fix... Right, not so much. The clients were still getting that error after a reboot no matter what I did. Tried to reset WU by renaming “SoftwareDistribution”, rebuilt the WMI repo and a whole lot of other things but nothing seemed to work, doing a WU scan through the UI (or just wait for a scheduled one) was still giving you that error over and over again.

Logging on to one of those clients remotely revealed a “fix issues”-button in the Windows update UI and clicking it actually fixed it. Getting students to follow instructions and go into that menu and click that button while working from home. No go :P

So what did that button do? I haven’t found the API nor the Dll-calls made, but I did find two folders that I haven’t been paying much attention to. %ProgramData%\USOPrivate and %ProgramData%\USOShared. In order to completely reset Windows update you need to have these folders in mind. If the following procedures doesn’t fix the issue you are facing: How to Clear Windows Update cache and Fix Windows updates (thegeekpage.com) The Windows Update Client Troubleshooting Guide (adamtheautomator.com)

Feel free to try the “Reset-UpdateStore”-script that I made and adapt it for your needs. I only use it as a last resort and I wouldn’t recommend using it in any other way. Doing this research I also found the need to trigger a pending FU (deployed using WU/WUFB) to be installed using a script… And that’s the icing on the cake. I believe that I have found a way of mimic what happens when a user clicks “Update and xxx”

Check it out: Update-AndRestart.ps1



285 views0 comments

Comments

bottom of page