Bei der aktuellen Diskussion über geeignete Schutzmaßnahmen argumentieren viele Admins, dass Sie ja Schattenkopien auf Ihren Fileservern einsetzen.
Warum man Schattenkopien nicht als zuverlässiges Backup einschätzen sollte:
Bei dem Kunden waren die Schattenkopien mit mehr als 40 GB weg….
Ich hatte neulich den Fall, dass die WSUS Datenbank auf einem Windows 2012 R2 Server korrupt war und daher der WSUS Dienst nicht mehr funktionierte.
Die naheliegende Idee, WSUS Server deinstallieren und wieder neu zu installieren brachte kein Erfolg, da die notwendige Datenbank
C:\Windows\WID\Data\SUSDB.mdf
durch die Deinstallation NICHT entfernt wird. D.h. nach der Neuinstallation des WSUS ist man an der gleichen Stelle.
Wenn man jetzt die o.g. Datebank einfach löscht, so bekommt man bei der Neuinstallation Fehlermeldungen.
In dem dazugehörigen Logfile steht dann auch die Ursache:
2016-06-02 11:37:26 Configuring WID database... 2016-06-02 11:37:26 Configuring the database... 2016-06-02 11:37:26 Establishing DB connection... 2016-06-02 11:37:26 Checking to see if database exists... 2016-06-02 11:37:26 Database exists 2016-06-02 11:37:26 Switching database to single user mode... 2016-06-02 11:37:27 System.Data.SqlClient.SqlException (0x80131904): Die physische Datei 'C:\Windows\WID\Data\SUSDB.mdf' kann nicht ge”ffnet werden. Betriebssystemfehler 2: '2(Das System kann die angegebene Datei nicht finden.)'. Die physische Datei 'C:\Windows\WID\Data\SUSDB.mdf' kann nicht ge”ffnet werden. Betriebssystemfehler 2: '2(Das System kann die angegebene Datei nicht finden.)'. Die SUSDB-Datenbank konnte nicht neu gestartet werden. Der vorherige Status wird wiederhergestellt. Fehler bei der ALTER DATABASE-Anweisung. Dateiaktivierungsfehler. Der physische Dateiname 'C:\Windows\WID\Data\SUSDB_log.ldf' ist m”glicherweise falsch. Dateiaktivierungsfehler. Der physische Dateiname 'C:\Windows\WID\Data\SUSDB_log.ldf' ist m”glicherweise falsch. bei Microsoft.UpdateServices.DatabaseAccess.DBConnection.DrainObsoleteConnections(SqlException e) bei Microsoft.UpdateServices.DatabaseAccess.DBConnection.ExecuteCommandNoResult() bei Microsoft.UpdateServices.Administration.ConfigureDB.ConnectToDB() bei Microsoft.UpdateServices.Administration.ConfigureDB.Configure() bei Microsoft.UpdateServices.Administration.ConfigureDB.Run(String instanceName, Action`1 logWriter, Boolean contentLocal) bei Microsoft.UpdateServices.Administration.PostInstall.Run() bei Microsoft.UpdateServices.Administration.PostInstall.Execute(String[] arguments) ClientConnectionId:5c9b6d98-4cbe-47eb-8465-f7fde71f8c4f Fehlernummer (Error Number):5120,Status (State):101,Klasse (Class):16 Schwerwiegender Fehler: Die physische Datei 'C:\Windows\WID\Data\SUSDB.mdf' kann nicht ge”ffnet werden. Betriebssystemfehler 2: '2(Das System kann die angegebene Datei nicht finden.)'. Die physische Datei 'C:\Windows\WID\Data\SUSDB.mdf' kann nicht ge”ffnet werden. Betriebssystemfehler 2: '2(Das System kann die angegebene Datei nicht finden.)'. Die SUSDB-Datenbank konnte nicht neu gestartet werden. Der vorherige Status wird wiederhergestellt. Fehler bei der ALTER DATABASE-Anweisung. Dateiaktivierungsfehler. Der physische Dateiname 'C:\Windows\WID\Data\SUSDB_log.ldf' ist m”glicherweise falsch. Dateiaktivierungsfehler. Der physische Dateiname 'C:\Windows\WID\Data\SUSDB_log.ldf' ist m”glicherweise falsch.
D.h. die eigentliche Konfiguration für den WSUS wurde wieder übernommen und jetzt fehlen natürlich die (gelöschten) Datenbanken.
Wie bekommet man also des WSUS dazu die Datenbank komplett neu zu erstellen?
Wenn der Eintrag für die Datenbank gelöscht ist, startet man die WSUS Installation auf dem Server erneut – und siehe da – er startet die Komplette Konfiguration des WSUS erneut und legt die Datenbank komplett neu und sauber an!
Quellen:
https://en.wikipedia.org/wiki/Windows_Internal_Database
Move or Delete a WSUS 4 Windows Internal Database (WID) on Windows Server 2012
Auf einem Lenovo Thinkpad T450s mit Windows 10 hatte ich neulich folgendes Problem:
Sämtliche Office 2016 Programm konnten keine Dateien mehr öffnen wenn diese auf einem Netzwerk-Laufwerk oder auch OneDrive gespeichert waren. Nach dem Starten des Programms stürzte dieses sofort wieder ab und das Dokument wurde geschlossen.
Kopierte man die Datei jedoch auf die lokale Festplatte des Computers, konnte man diese auch normal öffnen.
Im Ereignisprotokoll stand jeweils:
Ereignis 1000, Application Error Name der fehlerhaften Anwendung: WINWORD.EXE, Version: 16.0.6366.2056, Zeitstempel: 0x568f31f0 Name des fehlerhaften Moduls: ntdll.dll, Version: 10.0.10586.20, Zeitstempel: 0x5654262a Ausnahmecode: 0xc0000005 Fehleroffset: 0x0003ef53 ID des fehlerhaften Prozesses: 0x23b0 Startzeit der fehlerhaften Anwendung: 0x01d15b37ff9e51f1 Pfad der fehlerhaften Anwendung: C:\Program Files (x86)\Microsoft Office\Root\Office16\WINWORD.EXE Pfad des fehlerhaften Moduls: C:\WINDOWS\SYSTEM32\ntdll.dll Berichtskennung: 3de9f46e-c72b-11e5-9ccc-68f728db1328 Vollständiger Name des fehlerhaften Pakets: Anwendungs-ID, die relativ zum fehlerhaften Paket ist:
Folgende Maßnahmen waren ohne Erfolg
Ziel weisend für die Fehlerbehebung war schließlich folgender Microsoft KB Eintrag für Office 2013:
https://support.microsoft.com/de-de/kb/2813143
Und in der Tat war der Schuldige tatsächlich eine ältere Version der Displaylink-Software.
Nach der Deinstallation funktionierte Office 2016 wieder normal.
Seit dem Update auf die Version 5.0.142.5 des Autodesk Application Manager erhalten die Benutzer nach dem Login folgende Fehlermeldung:
Autodesk hat hierzu einen Eintrag in ihrer Knowledgebase mit einer vermeintlichen Lösung: http://knowledge.autodesk.com/de/support/autocad/troubleshooting/caas/sfdcarticles/sfdcarticles/DEU/Error-Unable-to-run-Application-Manager.html
Den Hinweis, man möge doch die Benutzerkontensteuerung doch einfach ausschalten kann aber nicht wirklich deren Ernst sein – oder ? Auch der Hinweis, man möge das Programm doch einfach als Administrator starten hilft einem nicht weiter, wenn die User eben dieses Recht nicht haben.
Das Problem ist nun aber, dass Autodesk dieses Programm beim Login jedes Users starten lässt und somit erhalten die User jedes mal eine schöne Fehlermeldung.
Im Programm selber kann man unter Einstellungen angeben, dass es bei Anmeldung am Computer nicht automatisch gestartet werden soll – aber auch das funktioniert nicht.
Meine Lösung: Ich schmeiße das Programm aus den Autostart.
Hierzu muss der Eintrag ADSKAppManager in der Registry der Rechner im Pfad
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run]
entfernen. Das kann man entweder lokal machen oder per Gruppenrichtlinie.
Danach haben die Benutzer Ruhe und die Admins können das Programm wenn nötig manuell starten.
Richtet man unter Windows 10 eine neue native VPN Verbindung ein – also mit Windows-Bordmitteln sozusagen – dann stellt man schnell fest, dass man nicht mehr an die TCP/IP Einstellungen der Verbindung herankommt.
Dieser “Bug” wird u.a. auf Youtube hier gezeigt: https://www.youtube.com/watch?v=I3fjNpkB-EE
Das ist insofern ärgerlich, weil neue VPN Verbindung immer das Standard-Gateway aktiviert haben. D.h. wählt sich der Benutzer ein, so gehen sofort alle Verbindungen nur noch über diese VPN Verbindung – in der Praxis wird das selten gewünscht.
Möchte man nun eine solche “Split-Tunnel” Konfiguration aber haben, so sind mir zur Zeit nur zwei Möglichkeiten bekannt.
a) Das Editieren der “rasphone.pbk”
oder besser
b) mit Powershell:
Set-VpnConnection -Name "NameVPNVerbindung" -SplitTunneling $TrueDies entfernt die Nutzung des Standard-Gateway der VPN-Verbindung.
Neulich hatte ich bei einem VMWare ESXi 5.0 Server das Problem, dass ich auf keine VM-Konsole mehr zugreifen konnte. Bei jeder VM bekam ich den Fehler “Die VMRC-Konsole hat die Verbindung getrennt….”
Ich wusste aber, dass es mit dieser vSphere Client Installation schon funktioniert hat – und die Installation war auch schon älter.
Die gängigen Hilfmassnahmen die man im Netz findet (Neustart VMWare Dienste, Neuinstallation des Clients) haben nicht geholfen.
Durch Zufall bin ich auf die Lösung gestossen – es lag an der VERSION des vSphere Client. Der ESXi Server selber lotste mich immer zum Download http://vsphereclient.vmware.com/vsphereclient/6/2/3/3/7/3/VMware-viclient-all-5.0.0-623373.exe – aber diese Version “VMware vSphere Client 5.0 Update 1” ist längst veraltet.
Glücklicherweise bietet VMWare eine Übersichtsseite für den Download der jeweils aktuellen Version der Client an:
Und dort fand ich auch die notwendige Version 5.0.0-1300600. Installiert – und schon gings wieder.
Auf mehreren Windows 8.1 Systemen hatte ich neulich folgendes Problem:
Beim Erzeugen eines PDFs mit Hilfe von qvPDF bekamen die Anwender folgende Fehlermeldung:
Wenn man die Fehlermeldung wegegklickt, kam qvPDF ganz normal hoch und man konnte das PDF abspeichern. Die Fehlermeldung war jedoch nervig.
Im Ereignisprotokoll fand ich dann folgenden Eintrag:
Name der fehlerhaften Anwendung: pdftk.exe, Version: 0.0.0.0, Zeitstempel: 0x4cc9eed0 Name des fehlerhaften Moduls: libiconv2.dll, Version: 6.3.9600.17668, Zeitstempel: 0x54c846bb Ausnahmecode: 0xc0000135 Fehleroffset: 0x0009e052 ID des fehlerhaften Prozesses: 0x2f94 Startzeit der fehlerhaften Anwendung: 0x01d072b373403526 Pfad der fehlerhaften Anwendung: C:\Program Files (x86)\qvPDF\pdftk.exe Pfad des fehlerhaften Moduls: libiconv2.dll Berichtskennung: b0f64aae-dea6-11e4-8375-0024d79e0a9c Vollständiger Name des fehlerhaften Pakets: Anwendungs-ID, die relativ zum fehlerhaften Paket ist:
Das interessante daran ist, dass sich auf dem PC das angeblich fehlerhafte Modul libiconv2.dll gar nicht befand!
Diese Datei ist Bestandteil der Library libiconv (http://www.gnu.org/software/libiconv/).
Also habe ich die Library für Windows von http://gnuwin32.sourceforge.net/packages/libiconv.htm heruntergeladen und die Datei libiconv2.dll in das Verzeichnis C:\Program Files (x86)\qvPDF der betroffenen Computer kopiert.
Siehe da – die Fehlermeldung kommt nicht mehr.
Möchte man bei HP ein Carepack registrieren, so hat man verschiedene Hindernisse zu überwinden.
Die HP Seite für die Registrierung funktioniert nur mit dem IE! Kein Firefox oder Chrome – nein IE muss es sein. Zusätzlich muss man noch die “Kompatibilitätsansicht” im IE für die Site hp.com aktivieren – ansonsten funktionieren die Buttons nicht.
Wenn man nun fröhlich sein Carepack registriert, so kann man sich anschliessend wundern. Man wird nicht (mehr) nach dem Kauf-Datum der Hardware gefragt – und das hat Folgen!
Bei einem PC der im Dezember gekauf wurde, startete die Garantiezeit nach der Registrierung des Carepacks bei mir im August! D.h. das Carepack startete 124 Tage zu früh – oder mit anderen Worten: man hat 124 Tage umsonst bezahlt!
Nachdem ich den Carepack-Support von HP angeschrieben habe, hat man das Datum korrigiert – aber ich möchte doch nicht bei jedem Carepack den Support per Email anschreiben…
HP bietet auf der Seite auch die Möglichkeit einer “Massen-Registierung” an.
Hierfür lädt man eine Excel-Vorlage herunter, füllt diese aus, generiert damit eine TXT Datei und lädt diese wieder hoch. Und interessanterweise hat genau diese Excel-Datei ein Pflichtfeld (!) “Product Purchase Date” – Hurra!
Aber leider ist es sooo einfach nun auch wieder nicht. Man muss zwei kleinere Probleme überwinden:
In der Excel Datei gibt es ein Feld “Tele #” welches nicht als “Mandatory” markiert ist. Füllt man dieses Feld aber nicht aus, so wird die Registrierung anschliessend abgelehnt!
Das Pflichtfeld “Product Purchase Date” soll man laut Excel-Datei in dem US-Format “M/DD/YYYY” ausfüllen.
Hier muss man unbedingt darauf achten, dass man das Feldformat auf Text umstellt, sonst korrigiert Excel das Datum wieder in das deutsche dd.mm.yy Format.
Achtet man nicht auf das korrekte Datum und schickt man diese TXT-Datei ein, so antwortet HP mit “Product Purchase date not valid” obwohl man eigentlich alles richtig gemacht hat.
Also muss man in der “RegUpload.txt” das Kaufdatum jeweils wieder manuell korrigieren und in das US Format “MM/DD/YYYY” bringen.
Jetzt kann man die Datei hochladen und sich auf das korrekte Carepack freuen. Dieses bekommt man aber nicht per Email zugeschickt! Das wäre ja zu einfach….
Nachdem man die Antwort von HP erhalten hat, dass die Registrierung erfolgreich durchlief, muss man sich erneut auf der HP Seite für das Carepack einloggen um dann dort die Bestätigung mi dem korrekten Datum zu erhalten.
Die Kontaktperson, die man mit Email-Adresse in der Excel-Datei eingetragen hat, bekommt aber eine Email mit der Bestätigung für das Carepack.
schwarzer Adler auf schwarzem Grund…
Gestern hatte ich bei einem Windows 2003 R2 Server ein interessantes Problem. Bei der Anmeldung am Server, sowohl lokal als auch per RDP, bekam man folgendes Bild:
Wenn man die Login-Daten blind eingetippt hat, kam man ganz normal auf den Desktop. Auch nach einem Neustart des Servers bestand dieses Problem weiterhin.
Eine kurze Google-Recherche brachte mich zu folgendem KB Eintrag
http://support.microsoft.com/kb/906510/de und damit zur Lösung des Problems:
In der Registry des Servers warenunter
[HKEY_USERS\.DEFAULT\Control Panel\Colors] alle Farben auf 0,0,0 gesetzt:
![[HKEY_USERS\.DEFAULT\Control Panel\Colors]](http://blog.kraeg.de/wp-content/uploads/2014/01/09-01-2014-20-22-57.jpg)
MS schreibt, man solle den Registry-Bereich von einem anderen Server exportieren und auf dem betroffenen Server wieder importieren. Das habe ich auch getan und konnte das Problem damit beheben.
Für alle die keinen Zugriff auf die schnelle auf einen anderen Server haben hier der entsprechende Code:
Windows Registry Editor Version 5.00 [HKEY_USERS\.DEFAULT\Control Panel\Colors] "ActiveBorder"="212 208 200" "ActiveTitle"="10 36 106" "AppWorkSpace"="128 128 128" "Background"="102 111 116" "ButtonAlternateFace"="181 181 181" "ButtonDkShadow"="64 64 64" "ButtonFace"="212 208 200" "ButtonHilight"="255 255 255" "ButtonLight"="212 208 200" "ButtonShadow"="128 128 128" "ButtonText"="0 0 0" "GradientActiveTitle"="166 202 240" "GradientInactiveTitle"="192 192 192" "GrayText"="128 128 128" "Hilight"="10 36 106" "HilightText"="255 255 255" "HotTrackingColor"="0 0 128" "InactiveBorder"="212 208 200" "InactiveTitle"="128 128 128" "InactiveTitleText"="212 208 200" "InfoText"="0 0 0" "InfoWindow"="255 255 225" "Menu"="212 208 200" "MenuText"="0 0 0" "Scrollbar"="212 208 200" "TitleText"="255 255 255" "Window"="255 255 255" "WindowFrame"="0 0 0" "WindowText"="0 0 0"
Als zip: Control_Panel_Colors_fix
Problem: Man möchte ein HP MSA 2000 SAN bei HP registrieren und benötigt hierzu die Seriennummer des Geräts.
Dummerweise ist das SAN aber schon eingebaut und/oder man kann den Aufkleber nicht lesen (weil man z.B. nicht vor Ort ist.) Auch blöd: die Seriennummer des Geräts wird nicht in der GUI angezeigt.
Lösung: Man kann die Seriennummer per CLI auslesen. Hierzu loggt man sich per Telnet (z.B. Putty) auf die IP eines der Controller mit dem “manage” Account ein und gibt das Kommando
show enclosure-status
ein. Man erhält eine lange Liste mit den verschiedensten Seriennnummern:
Oben links steht auf der ersten Seite die Seriennummer des Geräts. Sie fängt mit 2S6 an:
Quelle: HP P2000 G3 MSA System CLI Reference Guide