W10 Update Deployment Silent, certain not used old DLL in OEM Install paths BLOCKS update c:\drivers or c:\SWSETUP


Microsoft W10 Update to 1909 failed because the pre Check found the certain DLL somewhere under the c:\drivers or C:\SWSETUP olders. (APP/Software or driver was not installed, Update block by JUST finding the Certain DLL somewhere on certain paths used by certain Producer/OEM.

Often used paths for drivers and where W10 Update tried to find add. Info about a system and what was installed (Beside Software, Registry and Windows-Installer Cache/DB).

  • HP > C:\SWSETUP\
  • DELL > c:\DRIVERS\
  • Our deployment solution > c:\DRIVERS\

We just had a case where we update W10 1709 to 1909 through a Deployment solution. Updates of HP Laptop failed.

If we installed the Update manual we did see that the "Infineon TPM Professional Package" was blocking. But the software was not installed.


Reason for W10 Update failing:

At that customer we use c:\drivers\ for our deployment structure on HP (Like Dell does > By the way don't use c:\drivers for your own packages/batch on DELL systems it will break some DELL batches).

Under that structure we have a library of certain most used HP Service Packs. There was one which included an Infineon TPM driver. Just by searching through those files

Microsoft thinks the drivers IS installed a Blocks the update. The driver was not installed on the system.


Just delete those Directory and files if you don't reference them and they are not used MSI-Source files on the system you handle the update. On HP systems you can even rename the folder like from C:\SWSETUP\ to C:\_SWSETUP\ and it will work.

Where we found that info:

We silent deploy the 1909 there will following command line which gives us detailed Debug Log Info:

c:\drivers\setup\CUSTOMER_W10_1909\setup.exe /auto upgrade /copylogs \\SERVER\w10_1909$\CLIENTS_DEBUG\%computername% /DiagnosticPrompt enable /Priority Normal /postoobe c:\drivers\setup\CUSTOMER_W10_1909\CUSTOMER_W10_ENDE_OK.cmd /postrollback c:\drivers\setup\CUSTOMER_W10_1909\CUSTOMER_W10_ROLLBACK.cmd /Quiet /ShowOOBE none /telemetry disable /compat IgnoreWarning /DynamicUpdate disable /migratedrivers all

In these Logfiles then you will find the reason why he did not upgrade. You will also see why if you skip the OPTIONS: /Quiet /ShowOOBE none

search over all log files for "StatusDetail="UpgradeBlock"

It will be found in the logfile Compatdata*.xml

Here is the info regarding the Block within the XML File:

<Program IconId="ifxspmgt.exe_f069054697b0a0ae" Id="0006c5c9b5d907dd9c81f4d74bb61beb7e3900000904" Name="Infineon TPM Professional Package">

<CompatibilityInfo BlockingType="Hard" StatusDetail="UpgradeBlock"/>

<Action Name="ManualUninstall" ResolveState="NotRun" DisplayStyle="Text"/>


The where the files that Windows 10 Update found BUT where not installed on the system.

Just delete the files if unused and the update will do it what it should.



2020 WSUS-Server content Drive suddenly no space over 300GB *.ESD Upgrade files

Windows Update Server filling since a few months over the 350GB max. Value you know from WSUS-Server which runs over years

  • You checked the internal WSUS GUI Command to clean (That does not free space often…)
  • You cleaned the WSUS maybe even if free or commercial scripts like Adamj Clean-WSUS
  • Still you don't get under 350GB for the WSUS content drive
  • You are at a point where the SQL Cleanup stales, Your SQL Management Studio crash
  • You would have to use sqlcmd.exe to clean the WSUS because no space left


The Source is mostly ESD Windows Distribution Files (*.ESD) or updating from Windows 10 to other W10 versions. These exploded that last few months. Maybe you did one update like a 1903 to 1909 and now you have the full range coming in. This is around 120 to 160GB on Data.

This add. to the 350GB you normally have with running a certain range of products from like 2010-2016 office and W7/W10.

Quick and Dirty Workaround:

When you can't approve new updates and they are urgent and you can't expand the Disk temporary because it's a VM or the storage team refuses to do so (Because they like to save money for the customer [Who understands why?])

  1. Make sure nobody in your SBS or Enterprise does need those updates
  2. Just delete them from the \WSUSCONTENT\ drive recursive with del *.esd /s
  3. Find the person who turned the category on without thinking in advance ;-)
  4. Cancel the Download in the WSUS-GUI and also DENY them if there still NON APPROVED

Check other WSUS category from us:



Afterwards choose "cancel download" and "DENY" them.




Exchange 2010 SP3 RU28/29/30 ended prematurely (Management Framework 3.0 on Server)

Server 2008R2, Exchange 2010 SP3, ROLLUP 27 installed, 2x DAG Mailbox Server (Netapp Snap Manager for Exchange 7.2.1), CAS-Servers all went fine to Upgrade to RU30


This KB is all about a built in Exchange 2010 Powershell Script from Microsoft where they complain or wonder about Powershell from Microsoft. A finally statement has following comment:

"Curious PS behavior: It appears that 'return' trumps 'throw', so don't return..."


What we try to do:

We install RU28/29 or 30 on Exchange 2010 SP3 with some "World famous" Netapp Software for Exchange Backup SnapManager or some Netapp Partner tool.

Because it's "Freaky" the Netapp people install Microsoft Management Framework 3.0 or 4.0. So they have a little plug-in somewhere or can freak around with Power shell to show off their skills to other people. Because their football field size compatibility matrix shows they have to upgrade they update.

So the real problem is the Management Framework 3.0 or 4.0 installed by some Netapp Software or a partner plugin from a Netapp company.


This is what happens:

Regular approved setup, elevated, services no needed Stopped, Execution Policy Unsigned.


Setup Wizard for Update Rollup for Exchange Server 2010 Service Pack 3 ended prematurely because of an error. Your system has not been modified. To install this program at a later time, please run the installation again.


Event 1023, Msiinstaller, Application, Update Rollup


As always you did check:

  • The account you update is not some lockdown crap admin.s admin.c User which has no Schema, ADS-permission
  • Set-executionpolicy unrestricted
  • Disabled Cert Revocation Check in IE/EDGE > Options
  • Make a cmd.exe on Desktop run that ELEVATED (Run as Administartor)
  • Shortly disable AV even if it's Mcafee ENS ;-)

But that was not the error here….


Try to re-run it with debug option so you see more:

D:\edv\RU30\Exchange2010-KB4536989-x64-en.msp /lvx D:\edv\RU30\RU30_InstallationLogFile.log

Also check everything under C:\ExchangeSetupLogs\*.log


Logfile Debug:

MSI (c) (C4:C8) [21:28:16:082]: Product: Microsoft Exchange Server - Update 'Update Rollup 30 for Exchange Server 2010 Service Pack 3 (KB4536989) 14.3.496.0' could not be installed. Error code 1603. Additional information is available in the log file D:\edv\Exchange_2010_SP3_ROLLUP_30\RU30_InstallationLogFile.log.


MSI (c) (C4:C8) [21:28:16:082]: Windows Installer installed an update. Product Name: Microsoft Exchange Server. Product Version: Product Language: 1033. Manufacturer: Microsoft Corporation. Update Name: Update Rollup 30 for Exchange Server 2010 Service Pack 3 (KB4536989) 14.3.496.0. Installation success or error status: 1603.

MSI (c) (C4:C8) [21:28:16:113]: MainEngineThread is returning 1603


Remark Butsch:


Return MSI error normal helps if the MSI just copied a few files and registry keys. If the MSI starts one hundred powershells and it fails the error means almost nothing. That's like you trigger a start.cmd which calls a start.bat and that calls a start.vbs and somewhere you should capture an %errorlevel%

Lets search for [ERROR] in all Exchange logs > As example under c:\exchangesetuplogs\*.log

Check the logfile C:\ExchangeSetupLogs\ServiceControl.log for [ERROR]


[20:18:24] [Error] System.Management.Automation.ParseException: At D:\Program Files\Microsoft\Exchange Server\V14\Scripts\ManageScheduledTask.ps1:462 char:5

+ return $success


Solution 1:

Microsoft recommends to UNINSTALL Management Framework 3.0 or 4.0 > Install the Rollup > RE-Install Management Framework 3.0 or 4.0 and pray.

Solution 2:

Just give the Service Pack RU (The Powershell) what it wants. A return value $success. ;-) As you can guess not official supported says the guy who wrote the comments in the PS code? It's really in the beginning when the Rollup checks Services, Checks that Powershell runs etc.

Backup the file then Modify file ManageScheduledTask.ps1 from "D:\Program Files\Microsoft\Exchange Server\V14\Scripts" Line 462.

Change line 462 from "Return $success" To "# Return $success"

Just put the # and a space in front of it (Exclude)

OR this worked too….

Change line: "Return $success" to "Write-Output $success"


The comments speaks for their self in this Microsoft Script. Microsoft about Microsoft ;-)

09/2020 Patchday, KB4577015, breaks MMC (wsecedit.dll ) console for local security and GPO SRV 2016


ERROR: wsecedit.dll, MMC, Local Security Policy, Security Options > "MMC has detected and error in a snap-in"

Update 2020-09 Cumulative Update (KB4577015) bug mit GPO/MMC.

"Next steps: We are working on a resolution and will provide an update in an upcoming release."

Macht ein bug bei Server 2016 z.B. MMC-Konsole. Ich würde daher DC oder IT-MANAGEMENT Server 28.09.2020 nicht weiter patchen.

DC GPO nicht mehr verwaltbar auf SRV 2016 direkt selber.






  1. RSAT Tools auf W10 installieren und von dort managen
  2. Unschöner fix unten:


reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SecEdit\Reg Values\MACHINE/Software/Microsoft/Windows/CurrentVersion/Policies/System/DontDisplayLockedUserId"





How to turn off Autodiscover Warning in Outlook 2010, 2013, 2016, 2019

How to turn off Autodiscover Warning in Outlook 2010/2013/2016/2019 (Exchange 2010/2013/2016)

Warnung: Das Konto wurde fuer die Einstellung auf die Website umgeleitet


A little bit more explained than in the Microsoft KB and with a check THAT if you ONLY set the Registry key if the OFFICE Version is installed. During Migrations you could otherwise run into trouble if this key re-applies just the time you migrate to next office version.

This after you done Split DNS and integrated Autodiscover like you should.



We have:

Autodiscover.butsch.ch    (Exchange Server Autodiscover DNS entries)

mail.butsch.ch (Exchange Server)

This is what we don't want:

Make a new GPO policy.

Erstellen neue GPO:


Registry Keys:

"Software\Microsoft\Office\14.0\Outlook\AutoDiscover\RedirectServers" (Office 2010)

"Software\Microsoft\Office\15.0\Outlook\AutoDiscover\RedirectServers" (Office 2013)

"Software\Microsoft\Office\16.0\Outlook\AutoDiscover\RedirectServers" (Office 2016)

Office 97 - 7.0

Office 98 - 8.0

Office 2000 - 9.0

Office XP - 10.0

Office 2003 - 11.0

Office 2007 - 12.0

Office 2010 - 14.0 (sic!)

Office 2013 - 15.0

Office 2016 - 16.0

Office 2019 - 16.0 (sic!)