Windows 10 1809 Websuche im Startmenü abschalten

Diese blöde unnütze Websuche im Windows 10 Startmenü ist deutlich häufiger lästig als hilfreich. Natürlich gibt es keine Möglichkeit, diese in der Systemsteuerung auszuschalten.

So gehts:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Search]
"BingSearchEnabled"=dword:00000000

Microsoft OneDrive Explorer-Fenster öffnet sich ständig von selbst

Problem

Ein Anweder klagt, es würde sich sporadisch und vor allem ohne Zutun ein Explorer-Fenster öffnen, das den Inhalt der Microsoft OneDrive (for Business) zeigt.

Lösung

Der Nutzer hat recht, es gibt tatsächlich einen Geist der das Fenster „von selbst“ öffnet. Und zwar aus der Zeit vor dem Windows 10 Update; war auf dem PC vorher schon OneDrive installiert, entfernt das Upgrade zwar die alte OneDrive-Installation, nicht aber den Update-Task dazu.

In der Aufgabenplanung nach „Microsoft OneDrive Auto Update Task“ suchen. Wenn dieser im Format „Microsoft OneDrive Auto Update Task-S-x-x-xx-xxxxxxxxxx-xxxxxxxxx-xxxxxxxxxxx-xxxx“ angelegt ist und auf „%localappdata%\Microsoft\OneDrive\OneDrive.exe /autoupdate“ zeigt, ist dieser veraltet und löst das Fenster aus.

Diesen Task einfach deaktivieren, schon ist Ruhe.

Die „richtigen“ geplanten Aufgaben heissen „OneDrive Standalone Update Task“ und zeigen auf den Installer in „%localappdata%\OneDrive\17.3.6517.0809\OneDriveStandaloneUpdater.exe“.

Veeam „Unable to update SQL backupset for instance SQLEXPRESS : Code = 0x80040e09 Code meaning = IDispatch error #3081“

Veeam Backup&Replication beendet seit dem Update 3a alle Backup-Jobs die Windows Server mit einem installierten SQL-Server Express Edition beinhalten mit einem gelben „Warning“ Hinweis. Das passiert auch bei SQL-Servern, deren Application-Aware Benutzer zu wenig Berechtigungen auf den Datenbanken besitzt. Die Maschine an sich wird aber gesichert.

Die Warnung lautet

Unable to update SQL backupset for instance SQLEXPRESS : Code = 0x80040e09
Code meaning = IDispatch error #3081 Source = Microsoft OLE DB Provider for SQL Server
Description = The UPDATE permission was denied on the object 'backupset', database 'msdb', schema 'dbo'.

Das passiert, weil der Benutzer der von Veeam für das Application-Aware Processing genutzt wird, standartmäßig zu wenig Berechtigungen in einer SQL Express Edition (EE) Datenbanken besitzt um die Transaktionsprotokolle zu markieren. Der Fehler tritt erst seit Update 3a auf, weil Veeam dort das Verhalten des Agenten geändert (=korrigiert) hat.

Lösung

Die Berechtigungen in der Datenbank müssen nur schnell angepasst werden. Das geht am einfachsten mit dem SQL Management Studio. Standartmäßig steht eine SQL-Express Instanz alledings nur auf dem lokalen Host zu Verfügung, weswegen man das SSMS entweder auf dem betrroffenen Server installieren muss, oder die SQL-Instanz über das Netzwerk erreichbar macht.

Welche Application-Aware Processoin Credentials werden verwendet?

Das kann man direkt im Job nachschlagen, unter Guest Processing > Guest OS Credentials.

Dann …

  • SSMS „Als Administrator“ starten und mit localhost\sqlexpress verbinden
  • Falls noch nicht geschehen, unter Sicherheit > Anmeldungen den betreffenden Benutzer hinzufügen.
  • Dann dem Benutzer links unter „Serverrollen“ die Rolle „sysadmin“ zuweisen.

Powershell Scripts starten in der Aufgabenplanung nicht (Ergebnis 0x1)

Problem

Im Taskplaner (Aufgabenplanung) angelegte Powershell-Scripte (*.ps1) starten trotz „richtigem“ Aufruf (%System32%\WindowsPowerShell\v1.0\powershell.exe …) nicht und geben das Ergebis 0x1 zurück

Lösung

Meistens ist die ExecutionPolicy schuld. Mal ist es der 32bit-Powershell-Interpreter, dann wieder 64bit. Die Aufgabenplanung startet per Default x64, aber beide Interpreter haben eigene Policys. Es kann auch eine lokale- oder nichtlokale Profileinstellung sein oder Policy-Changes nach einem Update Es gibt viele Ursachen. Es hat sich daher bewährt, die Policy pro Script zu umgehen:

powershell.exe -NoProfile -NoLogo -NonInteractive -ExecutionPolicy Bypass -File \\<SERVER>\<FREIGABE>\<SCRIPT>.ps1

-NoProfile Stell sicher, das das Script ohne ein lokales Profil ausgeführt wird und somit immer „kollisionsfrei“ bleibt. Außerdem vermeidet man so den langsamen Overhead sämtlichen Profilcodes/aliases/Snipplets/Imports.
-NoLogo Lässt das Startlogo weg. Hilfreich wenn man den vollständigen Output umleitet. Und total gut fürs Admin-Gefühl.
-NonInteractive Umgeht Wartezeiten für Benutzereingaben, indem es letztere weglässt; genauer: durch ein ‚exit 100‘ ersetzt. Das Script hängt also nicht mehr bei Prompts, sondern beendt siche selbst mit dem Fehler 0x100.
-ExecutionPolicy Bypass Umgehen die lokale Executionpolicy. ‚unrestricted‘ ist natürlich ebenfalls möglich. Wir empfehlen aber ‚Bypass‘, weil das Probleme mit globalen Konfigurationsänderungen der Policys (jetzt und in Zukunft) umgeht.

Swyx Server Line Manager kollidiert mit Windows DNS Server Ports

Problem

Auf einem Swyx Server werden nach einem Reboot oder Dienstneustart des SwyxLinkManager die angelegten SIP-Trunks nicht mehr korrekt (oder nicht mehr alle) angemeldet. Manchmal funktioniert die Bereitstellung der Trunks auch scheinbar fehlerfrei, aber es kann nur in eine „Richtung“ telefoniert werden. Beispielsweise ist eine eingehende Rufsignalisierung kein Problem, die ausgehende funktioniert aber nicht. Dieses Verhalten scheint nicht reproduzierbar, sondern stellt sich „mal so mal so“ dar. Das passiert hauptsächlich auf Maschinen mit Windows DNS-Server.

Lösung

Der „SwyxLinkmanger“ benötigt für die einwandfreie Funktion folgende (UDP-)Ports:

SwyxServer 51000-51499
LinkManager55000-56000

Verbindungen unterteilen sich dabei in „Callcontrol“ (für den Verbindungsauf- und Verbindungsabbau) sowie die „Payload-“ oder „Datenphase“ in der der eigentlich Versand der Datenpakete mit Audio- oder Faxinhalten stattfindet.

Audiodaten werden immer per UDP Protokoll übertragen. Faxdaten hingegen können per UDP (überwiegend) oder TCP übertragen werden. Die Voreinstellung ist, zumindest bis SwyxWare v4.10, UDP. Sowohl die Quell- als auch die UDP/TCP-Zielports kommen aus den oben aufgeführten Bereichen.

Diese werden nun gerne beim starten des Windows DNS Dienstes belegt; dieser belegt eine ganze Menge an listener-Sockets im guten Glauben an viel DNS-Traffic. Man kann (und sollte) diese Ports einfach im DNS Server blockieren, dann entstehen keine Konflikte und die Telefonie funktioniert auch nach einen Reboot.

c:\> dnscmd /Config /SocketPoolExcludedPortRanges 51000-51490 55000-56000
c:\> sc stop dns & timeout 3 & sc start dns

Windows Server 2012/2012R2 RDS und/oder Windows 8/8.1/10 hängen bei „abmelden“ ewig fest

Problem

Wir sehen öfter den Fehler, das ein Windows Server 2012 RDS Session Host beim abmelden hängenbleibt. Das auch gerne ausdauernd lange. Dieses Verhalten lässt sich reproduzieren, wenn das Kennwort des angemeldeten Benutzers geändert wird.

Lösung

Das liegt (meist) an dem fehlenden Fix KB3132080, der diesen Effekt zwar behebt, aber andere Probleme mitbringt.

Es geht für den schnellen Admin aber auch manuell und flott, wenn man einfach die hängenden RDP-Sessions manuell beendet.

CMD-Session auf dem betroffenen Host öffnen:
C:\> psexec \\<MEINSERVER> cmd

offene RDP-Sessions auflisten:
C:\Windows> query session

offene RDP- Session beenden
logoff <ID>

IIS mit PHP Berechtigungsfehler beim Upload von Dateien

Unter Windows mit einem IIS und PHP habe ich soeben STUNDEN damit zugebracht, herauszufinden warum meine hochgeladenen Bilder (und Dateien) nicht die erforderlichen Berechtigungen für eine korrekte Anzeige aus dem Upload-Ordner erben. „Serverfehler 500“ sagt der IIS dazu ja auch nur und Bilder werden nicht angezeigt.

Das Problem tritt nur auf, wenn man PHP zum Hochladen nutzt. .NET hat das Problem generell nicht.

PHP legt hochgeladene Dateien nämlich in einem temporären Verzeichnis ab (Default: %windir%\Temp) und VERSCHIEBT diese danach ins Zielverzeichnis. Wenn eine Datei in dem temporären Upload-Verzeichnis angekommen ist, erbt sie (korrekterweise) erst einmal die NTFS-Berechtigungen dieses Verzeichnisses. Verschieben der Datei auf dem selben Laufwerk erhält dann aber die Berechtigungen dieser Datei und diese erbt die Berechtigungen des Ziel-Webverzeichnisses nicht. Verschiebt man über Volumengrenzen hinweg, tritt dieser Fehler nicht auf: Neue Dateien erben dort die NTFS-Berechtigungen des Zielordners. Das ist so, weil verschiebeoperationen eines Volumes nur den Pointer einer Datei ändern, die anhängenden ACLs und Metadaten aber nicht.

Lösung

Der einfachste Weg dieses Problem zu beheben besteht darin, die Berechtigungen der Ziel-Webverzeichnisses auf das temporäre Upload-Verzeichnis zu übertragen, bzw. die ACLs zu ergänzen. Einfach die Berechtigungen des Webverzeichnisses zum TEMP-Verzeichnis hinzufügen.

  1. Das temporäre Upload-Verzeichnisses in der php.ini-Datei in dem Parameter „upload_tmp_dir“ festgelegt. Ist kein Eintrag festgelegt, verwendet PHP %TEMP%
  2. In diesem Ordner alle Berechtigungen des Ziel-Webordners hinzufügen.