06-06-_2016_15-58-06

WSUS Datenbank auf Windows 2012 R2 neu erzeugen

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?

  1. Man benötigt das MS SQL 2012 Management Studio Express, was man unter https://www.microsoft.com/de-de/download/details.aspx?id=29062 herunterladen kann.
  2. Das Programm installiet man und startet es explizit als Administrator!
  3. Man verbindet sich zu \\.\pipe\Microsoft##WID\tsql\query
  4. Dort löscht man dann die WSUS Datebank:

06-06-_2016_15-58-06

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

 

Office öffnet keine Dateien von Netzwerklaufwerken oder Onedrive

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

  • Office Reparatur
  • Office De- und Neu-Installation
  • Installation aller aktueller Windows-Updates
  • Installation aller aktueller Office Updates

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.

 

 

 

Fehlermeldung: Application Manager kann nicht ausgeführt werden.

Seit dem Update auf die Version 5.0.142.5 des Autodesk Application Manager erhalten die Benutzer nach dem Login folgende Fehlermeldung:

22-10-_2015_14-51-04
Fehlermeldung: Application Manager kann nicht ausgeführt werden.

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.

Konfiguration von VPN Verbindungen unter Windows 10

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 $True

Dies entfernt die Nutzung des Standard-Gateway der VPN-Verbindung.

 

 

 

Die VMRC-Konsole hat die Verbindung getrennt…

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….“

27-07-_2015_13-58-38

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:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2089791

Und dort fand ich auch die notwendige Version 5.0.0-1300600. Installiert – und schon gings wieder.

 

 

qvPDF unter Windows 8/8.1 – Fehlermeldung pdftk.exe funktioniert nicht mehr

Auf mehreren Windows 8.1 Systemen hatte ich neulich folgendes Problem:

Beim Erzeugen eines PDFs mit Hilfe von qvPDF bekamen die Anwender folgende Fehlermeldung:

09-04-_2015_12-53-49
pdftk.exe funktioniert nicht mehr

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.

HP Carepack Registration Howto

Möchte man bei HP  ein Carepack registrieren, so hat man verschiedene Hindernisse zu überwinden.

Der Browser

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.

Das Startdatum-Problem

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…

Die Lösung

HP bietet auf der Seite auch die Möglichkeit einer „Massen-Registierung“ an.

28-01-2014 15-09-42

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:

Telefonnummer

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!

Kaufdatum

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.

 

Windows Server 2003 R2 – Schwarze Anmeldung

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:

09-01-2014 20-22-13

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]

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

 

Seriennummer einer HP MSA P2000 auslesen

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:

03-01-2014 14-51-06

Quelle: HP P2000 G3 MSA System CLI Reference Guide

 

 

 

 

Probleme bei der HP Carepack Registrierung

Die Online-Aktivierung eines HP-Carepacks ist leider nicht so einfach wie sie heutzutage sein sollte.

HP bietet diese Funktion leider nur für den Internet Explorer an. Andere Browser (Firefox, Chrome, Opera, Safari etc.) werden nicht unterstützt.  Es wird ausdrücklich gewarnt:

This site supports Internet Explorer browsers only. If you are experiencing problems with this site, complete your registration card and return to HP using the address on the back of the card, or alternatively choose your country and proceed to the next screen, send your details via email by clicking on the „contact us“ button.

Aber selbst wenn man sich mit einem aktuellen IE an die Registrierung macht, wird man spätestens beim letzten Formular feststellen, dass auch das nicht funktioniert.Man kann solange auf den „Senden“-Knopf drücken wie man möchte – es passiert nichts. Auch das Deaktivieren des Pop-Up Blockers oder das Aufnehmen der Website in die Gruppe der „Vertrauenswürdigen-Sites“ behebt das Problem leider nicht.

Die Lösung: Man muss die URL hp.com zu den Websites für die Kompatibilitätsansicht hinzufügen:

03-01-2014 14-22-03

Danach funktioniert das Formular wie erwartet.

@HP: Das ist nicht mehr zeitgemäss!

Quelle: HP Carepack Info-Hotline 069-999915760