Autor: Martin Richter

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.

MSDN/Technet/Answers-Community: Quo vadis? Answers 2.0 steht vor der Tür

Vor nicht mal einem Jahr hat Microsoft die NNTP Foren geschlossen.
MSDN-Foren, Technet-Foren und Microsoft-Answers sind der Weg, den sich Microsoft für die Community vorstellt.

Aber auch bei der gemeinsamen Plattform blieb es nicht lange. Ursprünglich liefen MSDN, Technet und Answers auf der selben Plattform. Dabei blieb es nicht lange. Answers wurde von den MSDN und Technet-Foren getrennt. Die Technik blieb erst einmal fast die selbe. Vor einiger Zeit wurde Answers in einen eigenen Bereich ausgekoppelt. D.h. Microsoft machte aus einem Community Bereich und aus einer Softwarelösung 2.

Nun wird es noch mal ganz anders. Answers 2.0 wird an diesem Wochenende seine Türen auf machen.
Wie immer:  Alles wird besserwerden! Es wird schneller, übersichtlicher, besser für die Fragesteller. Auch das Bewertungssystem wird sich ändern. Es wird keine Medaillen und keine Punkte mehr geben. BTW: Wer ist ernsthaft eigentlich auf so etwas wirklich scharf, oder wer braucht das? 😉
Gut wir werden sehen.

Leider hat dies für die Viel-Poster (z.B. MVPs), die in diesen Foren oft genug einen Löwenanteil an Antworten liefern, einen faden Beigeschmack.
Für die Viel-Poster wurde in den bisherigen Foren MS-NNTP Bridge angeboten und dank Jochen Kalmbach haben wir ein noch besseres Produkt, die Community Forums NNTP Bridge. So, dass man bisher auf einfache Art und Weise die HTML Foren wie gewohnt aus seinem Newsreader lesen und Fragen beantworten.
Auch mit der Trennung vom Answers und MSDN Foren blieb zumindest die NNTP Bridge erhalten.
Damit ist nun in Answers 2.0 Schluss. Die neuen Answer Foren werden keine Unterstützung für eine NNTP-Bridge haben.

Vor einem Jahr hieß es, dass die Community durch das Abschalten der NNTP Foren gestärkt werden sollte. Die dort existierende C++ Community wurde dadurch restlos zerstört. Scheinbar stellt sich jetzt heraus, dass die HTTP Foren in der jetzigen Form doch nicht die Community-Lösung sind, die notwendig ist. Eigentümlich, denn es gab schon damals genug Leute, die dies angezweifelt haben.
Irgendwie kommt mir das alles nicht mehr so durchdacht vor wie es sein könnte, und leider kommt es mir auch so vor, dass diejenigen, die die Community maßgeblich mittragen wieder die sein werden, die die größten Nachteile erfahren werden.

Auch wenn Answers nicht mein Bereich ist bleibt für mich irgendwie ein fader Beigeschmack und die Befürchtung, dass die Answers Foren nur der Anfang waren und das auch die MSDN-Foren bald eine Neugestaltung erfahren könnten und die Bridge auch hier kippen wird.
Für mich als Vielschreiber und Vielleser wäre dies ein echter Rückschritt, wie es schon die Abschaltung der NNTP Foren war, denn mit dem Browser Interface alleine, kann man unmöglich so schnell wie heute, so viele Informationen und Foren sichten.

TFS-2010 Umzug: Probleme mit dem Reporting Services

Beim Umzug meines bisherigen TFS 2010 in seine neue virtuelle Umgebung bin ich streng nach dem folgenden (leider nicht ganz fehlerfreien) Artikel vorgegangen: Move Team Foundation Server from One Hardware Configuration to Another

Ich habe brav die Report-Services Datenbanken wie auch alle anderen Datenbanken zurückgespielt (ReportServer und ReportServerTempDB) und natürlich auch den Verschlüssellungsschlüssel (eine unmögliche Übersetzung) oder besser den Encryption Key vom alten Server übernommen.
Danach habe ich kontrolliert ob die entsprechenden Reports alle wieder verfügbar sind. Aber Pustekuchen.

Beim Öffnen der entsprechenden Site der Reporting-Services erhielt ich im Browser die folgende (mir absolut unverständliche) Fehlermeldung:

Reporting Services-Fehler
Die Funktion Bereitstellung für horizontales Skalieren wird in dieser Edition von Reporting Services nicht unterstützt. (rsOperationNotSupported) Onlinehilfe

Nach etwas Grübeln und vergeblichem googeln bin ich wieder im Reporting Services Configuration Manager gelandet, und siehe da, der letzte Einstellungspunkt lautet: Bereitstellung für horizintales Skalieren.

Nachdem ich diesen Punkt aufgerufen habe war das Problem schnell entdeckt:
In der Liste der hier aufgeführten Server stand sowohl, der neue Server, als auch der alte Servernamen, den ich natürlich bereits vom Netz genommen hatte. Nachdem der Eintrag mit dem alten Namen entfernt war, konnten Reports auf dieser Site zumindest aufgelistet werden.

Leider funktionierte nicht einer der Reports, aber dazu mehr in einem der nächsten Artikel…

TFS-2010 Umzug auf andere Hardware und Dokumentation, die sich irrt

Mein TFS-2010 muss umziehen. Zum Glück ist auch dieser Vorgang in der MSDN ausgiebig beschrieben: 
Move Team Foundation Server from One Hardware Configuration to Another

In der Anleitung steht unter zwei Warnungen, die mich irritierten und die sich eigentlich beide als falsch bzw. teilweise falsch herausstellten:

1. SharePoint

You can choose to change versions or editions of some software, such as SharePoint Products, but not others. Changing versions or editions might complicate the restoration. For optimal results, consider restoring to exactly the same software and then upgrading after the restoration is completed.

Bei der Installation des TFS-2010 habe ich eine Upgradeinstallation gewählt und dabei wurde auch der SharePoint Portal Server 3.0 mit installiert. Mittlerweile lief dort auch schon SharePoint 3.0 SP2.

OK, denke ich. Also SharePoint 3.0 SP2 herunterladen und installieren. Pustekuchen! Bei der Einrichtung und dem hinzufügen der SharePoint Site in den TFS kam es zu mehreren Fehlern. Es hat immer gesagt, dass dieser Name nicht hinzugefügt werden dürfte.

Nach einigem überlegen schwante mir der Unterschied. Ich hatte damals den TFS-2010 in englisch installiert. Jetzt hatte ich die deutsche SharePoint 3.0 SP2 Installation einfach aus Gewohnheit durchgeführt.
Also zurück-marsch-marsch. Die deutsche Version deinstalliert (zwei Snapshots zurück), die englische drauf und siehe da es geht.

Also Achtung: Nach meiner Erfahrung ist der TFS-2010 sehr eigen, wenn es um die Sprachversion des SharePoint Dienstes geht und so einfach kann man also nicht den Dienst wechseln wie man lustig ist. Zumindest nicht die Sprachversion.

BTW: Was sich hier so schnell liest, war eine Fehlersuche von über 2,5 Stunden…

2. SQL Server

Auch hier lesen wie den folgenden Satz:

You must install the same version that you used in the original installation of Team Foundation Server.

Uff! Das kommt gar nicht in die Tüte. Das alte System war ein 32bit System. Der neue virtuelle Server soll komplett in 64bit laufen, inkl. also meinem SQL Server. Auf dem alten Server lief ein SQL 2008 32bit. Der neue Server und das Image, dass ich bereits erzeugt hatte sollte nun SQL 2008 R2 64bit haben.

In diesem Fall habe ich die Warnung ignoriert.
Das erfreuliche Resultat: Keine Probleme ❗

Bis auf Kleinigkeiten beim Einrichten der Dienste und Fehlermeldungen, auf die einen dieses Umstellungsdokument auch nicht hinweist, aber andere Ursachen haben, gab es gar keine Probleme die neue Version zu verwenden und den Sprung von 32bit auf 64bit zu wagen. Also Mut zum Verstoß gegen diesen Hinweis 😉

PS: Ich habe die Umstellung mit entsprechenden Snapshots auf dem virtuellen Server-System abgesichert und konnte somit meine Fehler und Probleme sehr einfach korrigieren und Lösungen austesten, ohne die Neuinstallation zu gefährden.

Und auf einmal ging der Debugger in VS-2010 nicht mehr…

Ich wollte heute morgen einfach ein kleines Testprogramm debuggen. Der Build wurde normale durchgeführt, aber danach ging nichts mehr. VS meldete nurnoch lapidar:

Microsoft Visual Studio is Busy
Microsoft Visual Studio is waiting for an internal Operation to complete. If you regularly encounter this delay during normal usage. please report this problem to Microsoft.

D.h. Visual Studio meldete nur noch, dass es beschäftigt wäre. Nach ein paar überlangen Sekunden/Minuten hatte sich dann zumindest der Bildschirm aufgebaut, wie ich es vom Debugger her gewohnt war.

Im Debug Ausgabefenster konnte ich nur sehen, dass er die Symbole der EXE geladen hat. Mehr nicht.
Also DEVENV.EXE abgeschossen.
Anders Mini-Projekt mit nur einer Consolen Ausgabe, kompiliert, Debuggen… gleiches Problem.
Neustart.
Gleiches Problem.  😯

💡 Ich starte DEVENV.EXE erneut, gehe auf Tools -> Options -> Debugging und sehe den Übeltäter:

Meine Server ziehen um, und ich habe zentral für alle Entwickler einen Symbol-Cache. Nun und dieser Server ist eben nicht mehr da. Also wurde für jede DLL die der Debugger gesucht hat ein Fileshare bemüht der ins Nirwana zeigte.

Wie so oft: Kleine Ursache – Fatale Wirkung!

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.

MVP-Programm: Quo vadis?

Hier ein Link über das MVP Programm, der lesenswert ist:
http://www.riagenic.com/archives/448

Der Artikel ist eine Reaktion auf David Woods Blogpost (http://www.haveyougotwoods.ca/2011/02).
Ich gehe nicht konform mit allem was David über die Produkte schreibt.

Mit dem was beide über das MVP Programm schreiben stimme in großen Teilen überein.
Vielleicht schreibe ich nächsten Tage noch mal etwas dazu… We will see…

virtuelle Funktionen und const sind immer wieder eine Freude… oder wie C++0x einen Fehler verhindert hätte…

Wieder mal hat sich in unserer Software ein kleiner und ganz mieser Fehler eingeschlichen, obwohl der Entwickler „eigentlich“ an alles gedacht hatte.

class A
{
...
    virtual void Doit() const;
...
};

class DerivedA : public A
{
...
    virtual void Doit(); 
...
};

void Foo()
{
...
    A *pA = Something();
...
    pA->Doit();
...
}

Sieht alles gut aus. Leider fehlt das kleine nette Wort const beim Überscheiben der Funktion Doit und daraus folgt, dass DerivedA::Doit niemals aufgerufen wird.

Obwohl wir VC-2010 verwenden, hat der neue C++0x Standard noch keinen Einzug in unseren Köpfen gefunden.
Das kleine Wort override in DerivedA hätte diesen Fehler verhindert.

class DerivedA : public A
{
...
    virtual void Doit() override;
// This line results in:

// error C3668: 'DerivedA::Doit' :
// method with override specifier 'override' did
// not override any base class methods
...
};

Es wird wirklich Zeit, dass C++0x auch wirklich genutzt wird, aber wie alles Neue muss man es sich besonders am Anfang immer wieder bewusst machen, damit es einem direkt zur Angewohnheit wird.
override ist sogar schon in VC-2008 und dem nativen Compiler implementiert. Allerdings wundert es mich, dass hier nicht dann auch gleich das Schlüsselwort new eingeführt wurde.
Aber das man unter dem gleichen Namen wirklich einen neuen Slot in der vtable aufmacht ist wirklich eher selten. Ich persönlich hatte dafür bisher noch keine Verwendung. 

Leider ist C++0x  nicht komplett in der C++ Doku in der MSDN hervorgehoben. Man kann nicht mal erkennen, dass sealed und abstract MS-Extensions sind, und override im Standard verankert ist. Schade…

Damit man sich etwas besser einen halbwegs kompletten Überblick verschaffen kann habe ich hier ein paar Links zusammengestellt.

Siehe auch:

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.

Tipps & Tricks: TFS Administration Tool 2.1

Mit der Benutzerverwaltung im TFS kann man viel unnütze Zeit verbringen.
Jeder kennt das Problem der schon mal mehrere Anwender in einem TFS-Projekt verwalten musste. Durch die Dreiteilung der Rechte muss man:

  • Rechte auf dem TFS verwalten (Team Foundation Roles)
  • Rechte auf dem SharePoint Server verwalten (SharePoint Roles)
  • Rechte auf dem SQL Reporting Server verwalten (Reporting Services Roles)

Wenn also was nicht klappt, weil einem zum Beispiel ein Report nicht angezeigt wird, ist man gleich wieder am grübeln: Wo war das nochmal mit den Reporting Services? Welcher Server, welche Webadresse? Gleiches, wenn man ein Benutzer keinen Zugriff auf die Dokumente in der SharePoint Site hat, die zu einem Projekt angelegt wurde.

Ich fühle mich eigentlich eher als Entwickler, denn als Administrator von einem SharePoint Server oder SQL-Reporting Services Server.

Das Ganze wird um ein vielfaches einfacher durch das TFS Administration Tool 2.1.
Hier kann man auch einfache Art in einem Tool alle Rechte auf einmal einsehen und verwalten. Netterweise wird man in der Listenanzeige sofort durch rote Kästchen auf die Konten aufmerksam gemacht, in denen keine Rechte definiert wurden. In den meisten Fällen ist hier auch schon ein grundsätzliches Problem gefunden.

Das Tool lässt sich auf jedem Client installieren auf dem der Team-Explorer auch installiert wurde.

Link: http://tfsadmin.codeplex.com/