February 02/2021 Windows Updates Deinstall Adobe Flash on Server and Clients W10 – Attention VMware vCenter/ESX Admins

February 02/2021 Windows Updates Deinstall Adobe Flash on Server and Clients W10 – Attention VMware vCenter/ESX Admins

Mit den Februar 2021 Windows Updates wird Adobe Flash (MS) de-installiert. Von Hand installierte Adobe Flash Binary bleiben auf den Systemen. Bei Teils Kunden brauchen wir ja noch FLASH fuer den Web Zugriff auf vCenter/ESX.

 

Wenn man nicht via HTML5 auf das VMware vCenter drauf kann dann einfach nochmals eine letzte Adobe Flash Version manuell installieren. (https://get.adobe.com/de/flashplayer/about/)

 

Zugriff vCenter 6.5:

https://blogs.vmware.com/vsphere/2016/12/new-vcenter-management-clients-vsphere-6-5.html

 

Vmware Produkte welche noch Flash brauchen:

https://www.virtuallyghetto.com/2020/10/adobe-flash-is-going-away-is-your-vmware-environment-and-it-organization-ready-for-it.html

 

 

 

 

Exchange 2016, Outlook 2016, Connection Status ERROR* Fehler*

Problem: Exchange 2016, Outlook 2016, Connection Status ERROR* Fehler*

Solution: Install Outlook 2016 Patch KB3115101

 

 

Leider läuft man in die Falle immer wieder rein. Man sucht an allen Enden und Cipher oder Kerberos rum und am Schluss ist es ein simpler MS KB patch. Wohl im OnPremise WSUS integriert aber aus Zeitgründen auf Test Clients nicht installiert ;-)

 

Loesung: Outlook 2016 KB3115101

 

https://www.microsoft.com/de-DE/download/details.aspx?id=52017

 

 

"Suppose that Outlook 2016 is on an Exchange server on an intranet with MAPI over HTTP transport protocol. If you use the Connection Status dialog box, the Authn Error * column shows * but no login*."

 

 

Fehler:

 

 

 

Obwohl dies geht und bei Authentication "Negotiate/Aushandeln" steht:

 

Exchange 2016 settings together with 2010 co. exist:

Nach der Installation des Patches sieht es dann so aus:

 

Error: “Exchange OWA HTTP500 Internal Server Error” after OWA Logon

 

Error: "Exchange OWA HTTP500 Internal Server Error" after OWA logon

You see the Logon Screen from Exchange OWA. You Logon with valid Credentials. After Logon you receive a Website error:

Solution/Reason/Source: Service "Microsoft Exchange Forms-Based-Authentication Service is not started or crashed.

 

This was hard to find since behind a KEMP and during a 2010-2016 Migration. But indeed very simple. The Service "Microsoft Exchange Forms-Based-Authentication Service" was not started on one CAS behind the KEMP Load Balancer. Depending on the complexity of your KEMP checks the NLB fails over to the other CAS or not.

When you search for Routes, Cipher and everything you seem to forget simple things like services.

We found a lot of blogs which mentioned that this was solved and related to the fact the VM running the CAS having too low RAM memory. Either check all Services after Reboot with Scripts or give more RAM. ;-)

 

 

If this does not solve it please also see:

Exchange 2013 Troubleshooting: Error 500 when login ECP and OWA - TechNet Articles - United States (English) - TechNet Wiki (microsoft.com)

https://social.technet.microsoft.com/wiki/contents/articles/34020.exchange-2013-troubleshooting-error-500-when-login-ecp-and-owa.aspx

Recycle APP Pool in IIS

OR

  1. Go to the RUN window and type "ADSIEDIT.msc"
  2. After opening ADSIEDIT, go to the Action navigation. Connect to and then navigate to
    1. "Select a Well known Naming Context"
  3. Select Configuration and select OK.
  4. Go to CN=Configuration then CN=Services then CN=Microsoft Exchange then CN=Your DOMAIN Name and navigate to CN-Client Access
  5. Right-click CN=Client Accessand click Properties. Scroll down to look for values:
    1. msExchCanaryData0
    2. msExchCanaryData1
    3. msExchCanaryData2
    4. msExchCanaryData3
  6. Take a backup to be safe and clear all these values to<not set>. If Values are already set to <not set> then try to do Solution 1.
  7. Open IIS Manager on your CAS server, go to "Application Pools", right-click MSExchangeOWAAppPool and click Recycle.

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.

Solution:

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"/>

</Program></Programs>

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

Source:

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:

http://www.butsch.ch/category/WSUS.aspx

 

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