Archiv des Autors: weed

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

Veröffentlicht am von — Keine Kommentare ↓

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 Update „Warning 1327.Invalid Drive D:\“

Veröffentlicht am von — 1 Kommentar ↓

Normalerweise sind Veeam Backup&Replication Updates dank der extensiven Q&A-Kultur von Veeam äußerst stressfrei und unter Berücksichtung der neuen Features/Funktionen schnell erledigt. Es gibt aber ein Problem im Setup der aktuellen Versionen (hier: Update 4a) wenn der „Veeam Backup Catalog“ irgendwann einmal verschoben wurde. Das Update-Setup

Warning 1327.Invalid Drive: D:\

Lösung

Der VBRCatalog wurde offensichtlich irgendwann einmal verschoben. Das Setup liesst bei der Installation einmal den Pfad aus der Windows-Freigabe aus, wenn die Installation lokal ist, und versucht diesen veralteten Pfad dann erfolglos zu nutzen.

  1. In der Computerverwaltung unter den Freigaben die Freigabe „VBRCatalog“ prüfen und den Pfad korrigieren (auf die Berechtigungen achten!)
  2. In der Registry diesen Pfad ebenfalls korrigieren: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup Catalog (Zeichenfolge: „CatalogPath“ auf den richtigen Pfad ändern, zum Beispel „C:\VBRCatalog“)

Danach das Setup neu starten und schon läuft es wie gewohnt stressfrei durch.

LANCOM Router und WLCs SYSLOG leeren/löschen

Veröffentlicht am von — Keine Kommentare ↓

Dies ist wieder ein Fall von „Notiz an mich selbst“. Nachdem ich das jetzt 1290843950 mal gegoogelt habe, die die Abkürzung zu „Syslos Protokoll eines Lancom-Router, Accesspoints oder Switches leeren“ 😉 An der SSH oder Telnet-Shell hilft:

do Status/TCP-IP/Syslog/Delete-Values

Syslog-Einträge werden beim LANCOM im RAM und im Flash-Speicher (bootpersistentes Backup) abgelegt. Der Befehl löscht beides, einzeln ist das (meines Wissens nach) nich möglich.

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

Veröffentlicht am von — 1 Kommentar ↓

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)

Veröffentlicht am von — 3 Kommentare ↓

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.