Kategorie: Software

Diverses über andere (fertige) Programme

Probleme nach Upgrade auf Microsoft SQL Server 2008 R2

Ein Kollege von mir hat ein Upgrade von seinen Microsoft SQL Server 2008 auf einen Microsoft SQL Server 2008 R2 durchgeführt.

Soweit ist alles gut abgelaufen, der SQL Server läuft. Einzig die Reporting Services ließen sich nicht mehr starten. Die Reporting Services liefen allerdings zuvor ohne Probleme.

Eine Reparaturinstallation sowie Entfernen und erneutes Hinzufügen des Dienstes wurden ohne jedweden Erfolg durchgeführt.

Nach dem fehlgeschlagenem Start des Dienst fanden sich nur die drei folgenden Einträge im Event-Log:

Protokollname: Application
Quelle:        SQL Server Reporting Services (MSSQLSERVER)
Datum:         26.05.2011 14:56:09
Ereignis-ID:   0
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      xyz
Beschreibung:
Der Dienst kann nicht gestartet werden. System.Exception: Default appdomain failed to initialize.
bei Microsoft.ReportingServices.Library.ServiceAppDomainController.Start()
bei Microsoft.ReportingServices.Library.ReportService.OnStart(String[] args)
bei System.ServiceProcess.ServiceBase.ServiceQueuedMainCallback(Object state)
Protokollname: Application
Quelle:        Report Server Windows Service (MSSQLSERVER)
Datum:         26.05.2011 14:56:09
Ereignis-ID:   140
Aufgabenkategorie:Starten/Herunterfahren
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      xyz
Beschreibung:
Fehler beim Initialisieren der DefaultDomain-Anwendungsdomäne. Fehler: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt..

Protokollname: Application
Quelle:        Report Server Windows Service (MSSQLSERVER)
Datum:         26.05.2011 14:56:09
Ereignis-ID:   113
Aufgabenkategorie:Protokollierung
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      xyz
Beschreibung:
Der Berichtsserver kann den Leistungsindikator 'Report Requests' nicht erstellen.

Der letzte Eintrag mit der Meldung „Der Berichtsserver kann den Leistungsindikator ‚Report Requests‘ nicht erstellen.“, in Verbindung mit der Meldung „System.Exception: Default appdomain failed to initialize.“ . Hat mich letzten Endes auf die Spur gebracht.

Die Lösung ist hier zu finden: http://support.microsoft.com/kb/956155/en-us

Offensichtlich wurde bei der Deinstallation des 2008er SQL-Servers mehr entfernt als gut war und der hier vorgeschlagene Weg einer Reparaturinstallation war leider nicht erfolgreich.
Ich habe die 4 Schlüssel die fehlten einfach manuell eingefügt und der Dienst konnte danach sofort wieder gestartet werden.

Wenn man mal doch Hardware in einem auf Hyper-V gehosteten Server benötigt…

Virtuelle Server sind was tolles. Aber leider lässt sich doch nicht alles virtuell abbilden, denn manche Software braucht die Verbindung zur Hardware. Und hier hat Hyper-V doch eine klare Einschränkung. Man kann kann nicht einfach ein USB Device an dem Hyper-V Host anschließen und in einer virtuellen Maschine benutzen, wie das VMWare Workstation perfekt beherrscht..

In meinem Fall waren es folgende Devices, die ich in meinen virtuellen Maschinen benötigte:

  • Unseren Master-Dongle für die Dongleerzeugung (WiBu)
  • Ein USB-Modem für unseren Fax-Eingang
  • Ein USB-Seriell Adapter an der eine TK-Anlage angeschlossen ist und gesteuert wird
  • Ein weitere USB-Port nochmal für eine weitere TK-Anlage
  • Manchmal für den direkten Anschluß einer USB Festplatte/Sticks

Ich habe mir einige Lösungen angesehen, die alle die USB-Devices über das Netzwerk sharen. Manche sind spezielle USB-Hubs mit Netzwerkanschluss, andere reine Software Lösungen.

Im Einsatz ist nun USB over Ethernet von KernelPro als reine Softwarelösung gekommen.
Bei dieser Lösung wird auf dem Hyper-V Host nur die Server Komponente installiert. Am Host schließt man nun die gewünschten USB Geräte an, ohne deren Treiber zu installieren. Man wählt in der Server Software nun die USB Geräte aus, die über das Netzwerk an interne Server weitergereicht werden.
Auf dem internen virtuellen Server, wird nun die Client-Software installiert. Dort kann mannun die USB Geräte auswählen, die der Server zur Verfügung stellt und die man in der virtuellen Maschine benötigt. Entsprechende Portfreigaben in der Firewall sind natürlich zu beachten. Auf dem virtuellen Client werden nun wie gewohnt die USB-Treiber installiert.
USB over Ethernet läuft als Dienst sowohl als Client wie auch als Server. Man muss sich um nichts mehr kümmern, alle angeschlossenen Geräte werden auch bei entsprechenden Serverneustarts einfach durchgereicht wenn die Dienste wieder starten.

Die Oberfläche des Tools ist einfach und verständlich ohne Schnickschnack wie man sich das für ein Server-Tool wünscht, dazu ist der Speicherverbrauch und die Prozessorlast niedrig. Die Software läuft seit 2 1/2 Monaten unauffällig und stabil, wie es sein soll.

Workaround für Patchday Bug vom 12.04.2011: Wenn unter Windows 2000 der Einsprungpunkt FindActCtxSectionStringA nicht gefunden wird

Hintergrund siehe hier:
BUG: Schwarzer Patchday für Windows 2000 – MFC 8.0 (VC-2005) und MFC 9.0 (VC-2008) DLLs sind nicht mehr lauffähig nach Installation von KB2467174 bzw. KB2467175
BUG: Schwarzer Patchday für Windows 2000 2.- MFC 8.0 (VC-2005) und MFC 9.0 (VC-2008) Static Libraries erzeugen auch inkompatiblen Code für Windows 2000 durch KB2465367 bzw. KB2465361

Unter Windows 2000 kann man wie folgt vorgehen und das Problem beheben:

  1. Am Besten macht man das nachdem man das System neu gestartet hat und noch keine Anwendung gestartet hat.
  2. Alle betreffenden Hotfixe entfernen (für Runtime-2005 KB2467175, Runtime-2008 KB2467174, für VS-2007 SP1: KB2465367, VS-2008 SP1: KB2465361).
    Die betroffenen C/C++ Runtimes des Visual Studio, die deinstalliert werden müssen, haben die folgenden Versionsnummern
    – VC-2005 8.0.50727.5592 (KB2467175)
    – VC-2008 9.0.30729.5570 (KB2467174)
    Um VS-2005/2008 wiederherzustellen ist zwingend eine Deinstallation des Patches nötig.
    Die Dateien für das Visual Studio sollten dann wieder denen des letzten Fix aus 2005/2008 entsprechen.
  3. Eigentlich sollte die Deinstallation des Patches genügen.
    Sofern es sich nur um ein Problem mit den Runtimes handelt und sich das Problem nicht behoben hat kann man mit den nächsten Schritten weiter machen und versuchen die alten Dateien wieder herzustellen.
    (    Man kann diese Schritte auch ohne Deinstallation durchführen)
  4. Für VS-2008: Die Dateien für aus dem letzten Sicherheitsupdate müssten in dem folgenden Verzeichnis unter C:\WinNT\winsxs\ liegen:
    a. x86_microsoft.vc90.mfc_1fc8b3b9a1e18e3b_9.0.30729.4974_…
    b. x86_microsoft.vc90.mfc_1fc8b3b9a1e18e3b_9.0.30729.4148_…
    c. x86_microsoft.vc90.mfc_1fc8b3b9a1e18e3b_9.0.30729.1_…
    Man wählt das Verzeichnis, dass man zuerst findet.
  5. Für VS-2005: Die Dateien für aus dem letzten Sicherheitsupdate müssten in dem folgenden Verzeichnis unter C:\WinNT\winsxs\ liegen:
    a. x86_microsoft.vc80.mfc_1fc8b3b9a1e18e3b_8.0.50727.4053_…
    b. x86_microsoft.vc80.mfc_1fc8b3b9a1e18e3b_8.0.50727.4027_…
    c. x86_microsoft.vc80.mfc_1fc8b3b9a1e18e3b_8.0.50727.1833_…
    d. x86_microsoft.vc80.mfc_1fc8b3b9a1e18e3b_8.0.50727.762_…
    Man wählt das Verzeichnis, dass man zuerst findet.
  6. Alle Dateien aus diesen gefundenen Verzeichnissen in das C:\WinNT\System32 Verzeichnis kopieren.

Hope that helps ❗

PS: Ich habe den Artikel mehrfach überarbeitet während er bereits veröffentlicht war und immer neue Infos eingebaut bzw. die Vorgehensweise besser erklärt.

Massive Probleme mit ADO auf Windows 7 SP1

Windows 7 SP1 scheint einige Probleme in Bezug auf ADO zu haben. So jedenfalls hat dies Mike Ryan gemeldet.
Hier die beiden Threads in den MSDN Foren, die von den Problemen berichten:

  1. Massive Thread-Handle Leaks bei asnychronen Operationen:
    ADO, adAsyncExecute and Windows 7 SP1 handles leaking
    http://social.msdn.microsoft.com/Forums/en/sqldataaccess/thread/68e23681-f6b5-4ed5-b963-e63e34eeac2f
    Dieser Bug wurde bereits von Microsoft bestätigt.
    Wer einen Fix braucht muss sich an den Microsoft Support wenden.
  2. Das zweite Problem betrifft die COM Registrierung für Applikationen, die auf Windows 7 SP1 Maschinen gebaut werden.
    Breaking change in MDAC ADODB COM components in Windows 7 Service Pack 1
    http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/3a4ce946-effa-4f77-98a6-34f11c6b5a13
    Siehe auch:
    http://blogs.technet.com/b/asiasupp/archive/2011/03/14/changes-in-mdac-adodb-com-components-in-windows-7-service-pack-1.aspx

PS: Ich bin ziemlich froh, dass ich direkt auf OLD-DB arbeite… 😉

Nach Installation von Windows 7 SP1 wird immer wieder die Installation für den USB Treiber der Microsoft IntelliType Tastatur durchgeführt

Ich hatte nach der Installation von Windows 7 auf einem meiner Rechner ein eigentümliches Problem:

Auf diesem Rechner wie auf auf zwei anderen meiner Rechner benutze ich eine Microsoft Keyboard-Maus Kombination. Entsprechend ist auf den Rechnern auch Microsoft IntelliType und IntelliPoint installiert.

Alles lief beim Update von Windows 7 glatt. Aber nach dem Neustart des Systems bekam ich einen UAC Prompt und es wurde gemeldet, dass ein neuer USB Treiber für die Microsoft Tastatur installiert werden müsste. Also OK.

Aber beim nächsten Neustart wieder die gleiche Meldung, ein detailierter Blick auf den Treiber der angefordert wurde ergab folgende Info:

rundll32.exe C:\Windows\system32\newdev.dll,pDiDeviceInstallAction \\.\pipe\PNP_Device_Install_Pipe_1.{541e93b9-2da1-4d96-91e1-68472a06f5a9} „usb\vid_045e&pid_00e3&mi_00\7&13cc06b7&0&0000“

Neuinstallation/Reparaturinstalltion der IntelliType Software nützte nichts.

Erst als ich die Software komplett entfert hatte und dann eine Neuinstalltion durchgeführt habe verschwand diese lästige Meldung.

Nach der Installation des SP1 von Wndows 7 / Windows Server 2008 R2 lässt sich wieder einiges an Speichplatz freigeben

Auch durch die Installation des SP1 für Windows 7 und Windows Server 2008 R2 kann man durch das Aufrufen der Datenträger Bereinigung 0,8GB bis 2,5GB an Speicher freigeben.

Entfernen der SP1 Backupdateien für Window 7

Dazu startet man einfach die Datenträgerbereinigung (CLEANMGR.EXE) als Administrator. Oder man startet die Datenträgerbereinigung normal und klickt dann auf den Schalter Systemdateien bereinigen. Nur wenn man das Programm als Admin startet erhält man auch Zugriff auf die Backupdateien des SP1.
Bei mir wurden hier zwischen 0,5GB und 0,8GB freigegeben.

Entfernen der SP1 Backupdateien für Windows Server 2008 R2

Das Löschen der Backup Dateien des SP1 für einen Windows Server 2008 R2 ist hier beschrieben:
http://technet.microsoft.com/en-us/library/ff817650(WS.10).aspx (ziemlich weit unten unter To remove service pack backup files).

Der Befehl zum Entfernen der Backupdateien für ein durchgeführtes Online-Update lautet entsprechend:
DISM.exe /online /Cleanup-Image /spsuperseded

bzw. bei Verwendung eines Offline-Images:
DISM.exe /Image:<path_to_offline_image> /Cleanup-Image /spsuperseded

Auf meinen Servern konnte ich durch diese Operation im Schnitt ca. 2,4GB freigeben.

Nachtrag (09.03.2011):
Es sollte klar sein, dass man die Installation des SP1 nach Löschen der Backup-Dateien nicht mehr rückgängig machen kann.

Lahme Sage Office Line 4 – 2010

Seit Wochen klagten unsere Damen vom Vertrieb, dass Ihre Warenwirtschaft (Sage Office Line 4 – 2010)extrem langsam startet. Bis zu einer Minute wird für den Start benötigt. An unseren Rechner (Alles Quadcores mit Minimum 3GB und Vista) kann es nicht liegen.
Ich habe mich mit dem ProcessMonitor auf die Suche gemacht konnte aber eigentlich nichts auffälliges feststellen.

Dann bin ich auf die Idee gekommen mal unsere Antiviren Software (Symantec Endpoint Protection) auszuschalten. WOW… Die OfficeLine startet in nicht weniger als 3 Sekunden ❗

Jetzt habe ich einfach die beiden Dateien „C:\Program Files\Sage\Office Line\4.2\Abf\OLABF_001.ADE“ und „C:\Program Files\Sage\Office Line\4.2\Rewe\OLREWE_001.ADE„, der Warenwirtschaft bzw. des Rechnungswesen durch eine extra Regel in der Endpoint Protection ausgenommen und siehe da alles gut.

Die Endpoint Protection kenne ich sonst nicht so als Systembremse, aber wie man sieht lohnt sich manchmal ein kritischer Blick auf das eigene AV System.

Auch bei haben nun die virtuellen Zeiten angefangen…

Unsere Firmeninfrastruktur ist bisher auf 3 Server verteilt. Die Server selbst sind noch so richtige Siemens Hardware, oder vielleicht sollte man sagen Heavyware. Wenn die einem auf den Fuß fallen, dann schade um den Fuß ;-):

  • Ein Siemens Primergy E200 Tower mit 2x 1Ghz PIII Prozessor (2 Kerne), 2GB RAM, mit RAID5 SCSI Subssystem.
    Mit SBS-2003 (32bit). In Betrieb seit 2004 ❗
  • Ein Siemens Primergy TX200 Rack-Server mit 2×2.4 Ghz Xeon-HT Prozessor (2 Kerne, 4 Threads), 3GB RAM, mit RAID5 SCSI Subssystem
    Mit Windows Server 2008 (32bit). In Betrieb seit 2007.
  • Ein Siemens Primergy TX200 Rack-Server mit 1×2.4 Ghz Xeon-HT Prozessor (1 Kern, 2 Theeads), 3GB RAM, mit RAID5 SCSI Subssystem
    Mit Windows Server 2003 R2 (32bit). In Betrieb seit 2007.

Im Winter kann man die drei auch locker als Heizung missbrauchen. Im Sommer muss eine Klimanlage den Serverraum auf maximal 23 Grad halten.

Die drei werden nun durch virtualisierte Server ersetzt. Der neue Host ist ein Dell T310, mit einem Xeon X3470 Prozessor 2,93GHz (4, Kerne, 8 Threads), dazu 24GB RAM und ein RAID5-SATA Subsystem.

Das Host und die Guest Systems sind einheitlich Windows Server 2008 R2 mit 64bit. Das Ganze läuft auf Hyper-V.
Umziehen bzw. ersetzt werden müssen nun Exchange, 3 SQL-Server, TFS-2010, ein Sharepoint Server, Sage-Office-Line, ein zusätzlicher Mailserver, ein Antivirensystem, ein File- und Druckerserver, der PDC und ein ganzer Haufen anderer kleiner andere Dienste.

… und da stecke ich nun mitten drin, bzw. bin schon ziemlich weit durch.

C:\WINDOWS\TEMP und die Tücken von Programme der Kategorie „es war einmal“

Es waren einmal die Zeiten in denen man in C:\WINDOWS\TEMP einfach mal eine Datei anlegen konnte und jeder darauf zugreifen konnte.
Seit Windows Vista hat sich ja einiges getan was Sicherheit betrifft, besonders auch die Rechtevergabe auf Dateien, die im C:\Windows\Temp Ordner angelegt werden.

Ein Programm  im Rentenalter (es ist gerade mal so um die 16 Jahre alt 😉 geschätzt) erzeugte in C:\WINDOWS\TEMP eine Datei, mit der bestimmte Zugriffe abgesichert wurden. Darunter auch wenn mehrere Instanzen des Programms auf einem Rechner liefen. Das funktionierte prima. Die Datei wurde unter einem festen Namen angelegt und nicht entfernt, nachdem das Programm beendet wurde.

Seit Vista gibt es aber nun ein kleines Problem.:
Seit Windows Vista darf in C:\WINDOWS\TEMP immer noch jeder User Dateien erzeugen. Auf diese Dateien hat er auch vollen Zugriff. Aber auf diese Dateien hat kein anderer Nutzer mehr Zugriff… 😮 … und selbst ein Admin muss erst hier erst den Besitz übernehmen, wenn er die Datei nicht erzeugt hat.

Und nun hat diese kleine alte Programm den folgenden Effekt:

  • Benutzer A meldet sich an.
  • Benutzer A startet das Programm Er arbeitet damit und die temporäre Datei wird in C:\WINDOWS\TEMP angelegt.
  • Benutzer A meldet sich ab und beendet das Programm.
  • Benutzer B meldet sich an.
  • Benutzer B startet das Programm und … bekommt eine Fehlermeldung mit einem „Access denied!“.

Mit den neuen Rechten, die auf dem C:\WINDOWS\TEMP Verzeichnis liegen, kann der zweite Benutzer auf diese Datei nicht mehr zugreifen auf die eben nur der Erzeuger Zugriff hat, und der ist eben Benutzer A.

PS: Es Frage mich keiner warum C:\WINDOWS\TEMP aus GetWindowsDir und angehängtem Text TEMP zusammengesetzt wurde. Vermutlich um zu umgehen, dass ein privates temporäres Verzeichnis benutzt wird. Tja und CSIDL_APPDATA war dem damaligen Entwickler (evtl. noch unter Windows 3.1) nicht bekannt.

So lange wollte eigentlich nicht warten…

Wie gut das manche Anzeigen einfach nicht stimmen:

In einer Teamviewer Session bekam ich beim übertragen der Datei, den Hinweis, dass es ca. 357.020 Jahre dauern wird bis die Datei übertragen ist 😮
Das Ganze obwohl der Fortschrittsbalken zügig voran geschritten ist. Das Ganze hatte wirklich nur 25 Sekunden gedauert und ich musste mich sputen das Bild einzufangen.

Berechnungen über die Dauer von Operationen führen immer wieder zu erstaunlichen Ergebnissen in unserer Branche…