Martin's Blog

Immer wieder mal lese ich von Problemen bei der Installation oder mit Installationen von VS-2010. Ich hatte den Fall noch nie, aber es gibt scheinbar immer wieder Installationen in denen der Wurm drin ist.

VS-2010 installiert eine Unmenge an Komponenten und Programmteilen. Die meisten können einfach deinstalliert/gelöscht werden. Aber es bleiben immer noch ein Haufen DLLs/ActiveX Controls und Registry Einträge und Verweise auf Verzeichnisse. Und leider gibt es für die Visual Studio 2010 keinen richtigen Uninstaller, der auch alle Artefakte löscht und deshalb kann ich gleich zu Anfang sagen, dass man außer der Deinstallation wirklich wenig tun kann.
Eine Reparaturinstallation sollte man aber bei einer bestehenden Installation in jedem Fall einmal, bevor man zu härteren Maßnahmen greift. Die wirkt oft schon Wunder.

Im Netz gibt es das folgende Utility: Visual Studio 2010 Uninstall Utility:
http://archive.msdn.microsoft.com/vs2010uninstall
Das Tool hat drei Operationsweisen die man in dem obigen Link erklärt findet.
Das Tool funktioniert eigentlich ohne Probleme aber benutzt auch nur auf dem MSI Uninstall Prozess auf, und dabei berücksichtigt es nicht einmal Servicepacks. Sollte man also das SP1 von Visual Studio 2010 installiert haben, dann muss man dieses vorher selber entfernen.

Das dieses Tool macht aber auch nur die Arbeit halb. Das erkennt man mit einem schnellen Blick in Registry. Der Ast HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\10.0 wird durch die Deinstallation nicht entfernt und man muß in diesem Fall manuell Hand anlegen.

Wenn man also persistente Probleme mit der VS-2010 Installation hat, die man nicht über die Setup-Logs oder mit Tipps aus den Foren lösen kann, dann bleibt nach meiner Meinung nur der harte Weg den Rechner neu aufzusetzen. Bisher bin ich davon verschont geblieben und meine Installation haben immer von Rechnerwechsel zu Rechnerwechsel gehalten.

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.

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.

Bei dem Management Studio für die 2005 EE war noch alles ganz einfach. Man schmeißt einfach den Installer an. Man klickt ein paar mal weiter und das war es auch schon. Nachdem ich VS-2010 installiert hatte wollte ich nun auch das passende Management Studio für die 2008 EE installieren. Also:

• Download gemacht 
• Setup gestartet
• und was nun?

Das Setup und das was ich hier alles einstellen kann ist alles andere als intuitiv.

Ich mache es kurz. Man kann sich das ganze durch-die-Dialoge-hangeln sparen.
Man startet einfach die Installation mit dem folgenden Befehl von einer Befehlszeile:

SQLManagementStudio_x86_xxx.exe /q /FEATURES= SSMS /ACTION=Install

Statt xxx gebe man bitte einfach in DEU oder ENU an, je nachdem was man für eine Sprache hat.

Gefunden habe ich das hier auf diesem Link, hier finden sich auch weitere Anweisungen wie man sich durch die Dialoge quälen muss:
http://blogs.msdn.com/billramo/archive/2009/02/20/sql-server-2008-management-studio-express-released-to-the-web.aspx

Das Management Studio Express findet sich hier zum Download:
http://www.microsoft.com/downloads/details.aspx?familyid=08E52AC2-1D62-45F6-9A4A-4B76A8564A2B&displaylang=de

In den Express Editionen für Visual Studio 2005 und 2008 war es nur nötig die Versionen zu registrieren, die mit dem Online Installer installiert wurden. Die Installationen die mit dem ISO-Image durchgeführt wurden dies nicht nötig.

Das hat sich mit den VS-2010 Express Editions (VS-EE) geändert. Es spielt keine Rolle ob es sich hier um die EE von C#, C++, VB oder eine der anderen verfügbaren Versionen handelt.
Alle diese Versionen müssen registriert werden. Die Laufzeit ohne Registrierung beträgt 30 Tage.

Ich rate dringend dazu, sofort nach der Installation auch die Registrierung durchzuführen. Und wenn es nicht klappt am nächsten Tag gleich wieder zu versuchen. Die Seite funktioniert leider oft genug nicht. So klagen zumindest nicht wenige Benutzer in den Foren.

Infos zur Registrierung hier:
http://www.microsoft.com/germany/express/registration/default.aspx

Download Link für alle Express Editionen (inkl. ISO-Image) hier:
http://www.microsoft.com/germany/express/download/default.aspx

Nachtrag:
Die FAQ ist ziemlich ungenau. Das jedes Produkt einen eigenen Schlüssel braucht habe ich ausprobiert. Aber man benötigt nur einmal eine Nummer für die Registrierung von VC#-2010 EE oder VC++-2010 EE
Man kann ohne weiteres diese Registrierungsnummer auf mehreren Rechnern für mehrere Installationen benutzen (probiert auf Windows XP und Windows 7 Starter). Zumindest bei mir hat das geklappt. Es ist scheint nicht notwendig zu sein jede Version separat auf jedem neuen Rechner wieder zu registrieren

Ein Sch<zensiert>…</zensiert>tag.

Heute morgen komme ich in die Firma und schalte meinen Fujitsu-Siemens Quad-Core Desktop ein. Dann gehe ich in die Büroküche und setze Wasser für meinen Tee auf. Wenn ich damit fertig bin, erwartet mich normalerweise der Anmeldebildschirm von Windows.
Heute Nix. Schwarzer Bildschirm.

Um es kurz zu machen: Die Seagate Baracuda hat Ihren Geist aufgegeben. Nicht mal 1 Jahr hat sie es gemacht. Am 18.12.2008 wurde der Rechner gekauft, am 10.12.2009 Platte kaputt!
Da ich noch eine absolut baugleiche Festplatte in dem Desktop meines Kollegen hatte, habe ich sogar versucht die Elektronik alleine zu tauschen. Hätte ja sein können, dass nur nur die einen Hau hat. Nix!

Zum Glück habe ich Alles, was die Entwicklung betrifft in meinem TFS. Und von meinen aktuellen wichtigen, Arbeitsverzeichnissen ein Backup mit Acronis, das mal gerade 3 Arbeitstage zurück liegt. Ausgecheckt waren drei Dateien.
Nur mit dem Vollimage meines Rechners habe ich in der letzten Zeit geschlampt. Das liegt leider fast 2 Monate zurück und war direkt vor meinem Update von Vista auf Windows 7.
Das nächste volle Backup hatte ich jetzt fest für das Wochenende geplant. Leider zählt die Absicht nicht!

Verloren habe ich einige interessante Testprogramme, die ich nicht im TFS und auf keinem Backup, Stick oder SD-Karte hatte und einige Downloads die ich in den letzten Wochen gemacht hatte und die noch zu archivieren waren. Und natürlich die Zeit um den Rechner wieder mit allen wichtigen Werkzeugen auszustatten.
Ärgerlich…

Was lernt man daraus: Mit Backups darf man nicht warten
Das ist in 30 Jahren der erste Crash, der mich ärgert.  Sonst mache ich in der Firma und auf meinem privaten PC mit Acronis Trueimage grundsätzlich zum Wochenende hin ein Backup (1 Vollbackup dann 4 Wochen inkrementell).

Ich habe einen Server auf dem mein TFS läuft. D.h. es ist eine Ein-Server Installation. SQL-Server, TFS und SharePoint liegen alle auf einem Windows 2003 R2.

In der letzten Zeit hatte ich schon das Gefühl, dass der erste Kontakt zum TFS ziemlich langsam war, bzw. auch das erste Speichern eines Tasks, oder Bugs.

Vor einigen Tagen dann bekam ich eine Meldung, dass kein Backup mehr durchgeführt wurde.
Eine Analyse ergab, dass auf dem TFS mit einem 100GB Raid5 Laufwerk nur noch 200MB frei waren. Eine Suche ergab, dass sich im Verzeichnis C:\Programme\Gemeinsame Dateien\Microsoft Shared\Web Server Extensions\12\LOGS\ weit über 22GB an Daten angesammelt hatten.

Eine weitere Analyse ergab, dass alle 15 Sekunden ca. 4000 Zeilen mit dem folgenden Text erzeugt wurden.

Alle 15 Sekunden ca. 4000 Einträge

11/02/2009 11:59:14.87  OWSTIMER.EXE (0x0F30)                    0x049C Windows SharePoint Services    Timer                          5uuf Monitorable Die vorhergehende Instanz des Timerauftrags ‘Config Refresh’, ID {0CA4803D-1621-49F4-BEFC-1BA2B441AC28} für den Dienst ‘{8B6CADF9-8ECE-409C-8D32-E336A5564C04}’ wird noch ausgeführt. Die aktuelle Instanz wird deshalb übersprungen. Sie sollten eine Vergrößerung des Intervalls zwischen den Aufträgen in Erwägung ziehen.

Einiges suchen im Internet ergab, dass ich nicht alleine an diesem Problem leide. Es gibt sogar einen KB Artikel dazu: http://support.microsoft.com/kb/941789/en-us/

Letzten Endes kann man die Warnungen unterdrücken, indem man den Logging Level verändert. Das geht einmal wie beschrieben über die SharePoint 3.0 Central Administration. Aber weitaus einfacher geht es auch über die Befehlszeilentools.

stsadm -o setlogginglevel -category timer -tracelevel unexpected 

Das ganze kostet aber immer noch einiges an Performance, denn dies unterdrückt nur die Protokollierung des Problems. Ein Refresh des Caches ist aber wirklich nicht alle 15 Sekunden notwendig, wie es die Standardeinstellungen vorsehen. Den Prozess alle 5 Minuten laufen zu lassen langt auch.
Das erreichen wir durch:

stsadm -o setproperty -propertyname job-config-refresh -propertyvalue "Every 5 minutes between 0 and 59"

Die entsprechende Doku dazu findet sich hier:
http://technet.microsoft.com/en-us/library/cc424971.aspx
http://technet.microsoft.com/en-us/library/cc261740.aspx

Die Standardwerte kann man wieder setzen durch die Befehle:

stsadm -o setlogginglevel -default -category timer
stsadm -o setproperty -propertyname job-config-refresh -propertyvalue "Every 15 seconds"

Ich hatte zu dem Problem auch den Microsoft Support bemüht, allerdings erfuhr ich hier auch nicht mehr, als ich selbst schon ermittelt hatte. Allerdings wurde mir angedeutet, dass es zu diesem Problem auch einen “noch” inoffiziellen Fix gibt. Mal sehen ob sich hier mal noch etwas tut.

Mein fix behebt zumindest das Problem mit den extrem vielen Log-Datei Daten- Und auch die Performance des TFS ist wieder etwas besser geworden, nachdem der entsprechende Timer Job nur noch alle 5 Minuten läuft.

Weitere Links zu OWSTIMER und den Timer Jobs des Sharepoint 3.0

• SSP and OWSTIMER Service – Hob Description Used for Synchronisation
  http://blogs.msdn.com/gregmcb/archive/2008/03/05/ssp-and-owstimer-service-job-descriptions-used-for-synchronization.aspx
• SharePoint Timer Job Reference
  http://technet.microsoft.com/en-us/library/cc678870.aspx
• Best Practices: SharePoint Timer Jobs
  http://www.alexbruett.net/?p=69

Nachdem ich vor einigen Tagen ein Update auf meinen Vista Rechner auf Windows 7  durchgeführt habe, sind mir zwei versteckte Ordner im Rootverzeichnis auf meiner Festplatte aufgefallen, die nicht klein sind.

Durch eingeschränkte Rechte hat man normalerweise keinen Zugriff, aber wenn man eine elevated Session mit dem Explorer startet kann man herausbekommen was sie beinhalten:

$WINDOWS.~Q    2200 MB (2.364.075.683 Bytes)
$INPLACE.~TR    471 MB (  494.284.806 Bytes)

Die Dateien in diesem Ordner schienen auf den ersten Blick irgendwas mit dem Update zu tun zu haben.

• Der erste Schritt: Mal in der Systemsteuerung nachsehen ob man dort etwas deinstallieren kann. Nada.
• Zweiter Blick: Starten der Datenrägerbereinigung. Auch nichts auffälliges.
• Dritter Versuch: Starten der Datenträgerbereinigung als Administrator. Bingo

Siehe da:

Zwei Dateigruppen finden sich:
Beim Window-Upgrade verworfene Dateien – und -
Protokolldateien für Windows-Upgrades

Anhaken und Schwupps sind 3GB mehr Plattenplatz da…

Ich habe vor einiger Zeit in dem Artikel Probleme bei Installation des Sicherheitsupdates KB947319, Fehler Code A95 von meinen Ärger mit dem Windows Update berichtet.

Ich war extrem überrascht welche Aufmerksamkeit dieser Artikel erregte. Das ging so weit, dass ich weitere Kommentare blocken musste und in meinem überfüllten Email-Postfach zu einem Standardtext greifen musste für Leute, die nach der Case Id fragten.

Endlich ist ein offizieller Fix für den KB947319 verfügbar

http://www.microsoft.com/downloads/details.aspx?displaylang=de&FamilyID=95c94c9a-6aca-42fb-9679-3234f06c72f7

Am 11.08.2009 wurde das KB947319 Sicherheitsupdate für Office 2003 Web Components und Office XP Web Components in Office 2003  herausgegeben.
Dieses Updates lies sich bei mir auf einigen meiner Rechner (alle Vista) nicht installieren. Ich erhielt immer die Fehlermeldung A95.

Im Updateverlauf steht folgendes:

Sicherheitsupdate für Microsoft Office Web Components (KB947319)
Installationsdatum: ‎13.‎08.‎2009 10:29
Installationsstatus: Fehlgeschlagen
Fehlerdetails: Code A95

Ich habe danach versucht den Hotfix direkt herunter zu laden und die office2003-KB947319-FullFile-DEU.exe auszuführen. In diesem Fall erhielt ich die Fehlermeldungen:

Fehler 2709: Ein internen Fehler ist aufgetreten.
(Global_PIA_OWC11 )

und

Sicherheitsupdate für Office Web Components 2003 (KB947319)
Das Update konnte nicht angewendet werden.

Das eigentümliche ist allerdings, dass Office 2003 auf diesen Rechner selbst nicht installiert ist.
Da dieses Problem konsequent auf einer einer ganzen Reihe von Rechner auftrat habe ich den MS-Support bemüht. Jetzt nach einigen Tagen sieht es so aus, dass das ganze an einer Installation der MS-Access 2003 Runtime liegt.
Auch die MS-Access 2003 Runtime wurde als Ziel für diesen Patch eingetragen obwohl diese gar nicht betroffen ist.
Ich zitiere einfach mal den MS-Support:

Das Update KB947319 besteht aus 2 MSPs, OWC10.MSP und OWC11.MSP. Beide haben unter anderem die Access Runtime 2003 als Target eingetragen. Allerdings hat die Access Runtime 2003 gar keine OWC11, sondern nur die OWC10, insofern scheitert OWC11.MSP mit der Fehlermeldung:
Error 2709. An internal error has occurred. (Global_PIA_OWC11 )

Error 2709 heisst: “The specified Component name (‘[2]‘) not found in Component table” was ja auch der Tatsache entspricht, denn die Komponente OWC11 ist ja tatsächlich nicht in Access Runtime 2003 enthalten.

Das Problem in diesem Fall ist, dass die Access Runtime 2003 in OWC11.MSP überhaupt als Target eingetragen ist. Das bedeutet für Sie zunächst einmal, dass trotz des Problems bei der Installation des Fehler im Moment kein  Sicherheitsrisiko besteht, durch den Umstand, dass OWC11.MSP in der Access Runtime 2003 nicht installiert werden kann, da es keine OWC11 gibt, die man updaten könnte.

Es geht momentan noch darum, dass KB947319 von der Patch Detection weiterhin als applicable angezeigt wird, solange der Patch für die OWC11.MSP bezüglich der Access Runtime 2003 einen Fehler zurückliefert.

Wir sind aktuell dabei, einen Regression Hotfix für diesen Patch zu beantragen.

Aktuell habe ich dieses Sicherheitsupdate ausgeblendet. Bis die Regression durch ist.

Nachtrag 07.09.2009:
Ich bitte davon abzusehen weiter nach Informationen bei mir persönlich nachzufragen. Ich werde über die Veröffentlichung eines öffentlichen Fixes zu gegebener Zeit berichten.
Man kann sich ohne Probleme selbst an den Microsoft Support wenden und seine Probleme bzgl. des KB947319 schildern. Die Probleme sind hinlänglich bekannt und sofern die Indikatoren übereinstimmen sollte man auch einen provesorischen Fix vom Microsoft Support erhalten können.

Mit Datum vom 07.09.2009 sperre ich weitere Kommentare.

Nachtrag 26.10.2009
Endgültiger Fix für die Probleme bei Installation des Sicherheitsupdates KB947319, Fehler Code A95