[POST MORTEM] WOL.NET

Während ein Großteil unserer Entwicklungsprojekte auf den Bühnen unserer Kunden stattfinden, gab es in der Vergangenheit auch die eine oder andere Software, die wir in Eigenregie entwickelt und zeitweise auch vertrieben haben. Das wohl bekannteste Produkt ist dabei das später in RPM umgetaufte WOL.NET. Dieser Artikel schaut ein wenig hinter die Kulissen: Was lief gut, was lief nicht so gut, über was für Kuriositäten sind wir bei der Entwicklung gestolpert. Ein klassisches Post Mortem also.

Viel Spaß beim Lesen!

Softwareverteilung als Auslöser für eine Eigenentwicklung

Bereits vor über zwölf Jahren hatten einige unserer Kunden das Bedürfnis, ihre Softwareverteilung möglichst zentral zu verwalten. Auf dem Markt existierten (und existieren noch immer) die unterschiedlichsten Produkte verschiedenster Hersteller, die das ermöglichen. Um ein prominentes Beispiel zu nennen: Microsoft bot damals bereits mit dem Systems Management Server (SMS) in der Version 2003 ein solches Produkt an. Inventarisierung von Soft- und Hardware war damit möglich, ebenso aber auch das Verteilen von Software; zentral gesteuert. Später wurde daraus übrigens SCCM (Systems Center Configuration Manager) in der Version 2007.

Was allerdings ab Start fehlte, war die Möglichkeit, Rechner gezielt für eine Software-Verteilung remote einzuschalten oder im Anschluss auch wieder herunterzufahren. Kurzum: Bis ein Programmpaket auf teilweise hunderte Systeme verteilt war,… das konnte dauern. Tage. Wenn nicht gar Wochen. Es kam halt darauf an, wann jemand seinen PC anschaltete.

Auf Basis einer Kundenidee zu diesem Problem entstand dann 2004 die Software WOL.NET. WOL  stand dabei für Wake on LAN und beschrieb somit die Technologie, die für das ferngesteuerte Aufwecken der Clients zum Einsatz kommen sollte. .NET wiederum trug damals nahezu jedes Programm im Namen, was auf die .NET Plattform von Microsoft setzte. 

Als Web-Anwendung konzipiert, war es die Aufgabe von WOL.NET, ausschließlich lesend auf die Datenbasis vom SMS 2003 Server zuzugreifen und die Hierarchie der darin registrierten Clients darzustellen. Administratoren konnten sodann einzelne Clients, sowie ganze Sammlungen selektieren und dann einen Job erstellen, der die Clients sowohl aufwecken wie auch herunterfahren konnte. Letzteres erledige ein entsprechender Aufruf der shutdown.exe. Das Gute an diesem Konzept: Wir waren unabhängig vom eigentlichen SMS Workflow und der tatsächlichen Softwareverteilung. Sprich: Rauf- und Runterfahren gingen auch komplett autark und konnten somit auch für alle andere Zwecke genutzt werden, für die ein Rechner so eingeschaltet sein sollte (Virenscans, etc.).

Die ersten Probleme

Direkt ab Start trafen uns dann allerdings zwei Probleme:

  1. In 2004 waren wir noch nicht bereit, Lizenzen von Drittherstellern wie bspw. Infragistics, Telerik, Component One und wie sie alle heißen auszugeben. Warum das eine schlechte Entscheidung war, kann man hier nachlesen.
  2. Magic Packets wie sie für Wake on LAN benötigt werden, müssen gebroadcastet werden.

Was bedeutete das für uns?

Nun, während unsere Testumgebung aus einer handvoll PCs bestand, verfügte unser erster ernstzunehmender Kunde für das Produkt über ca. 2.000 Systeme. In SMS waren sie auf eine Art strukturiert, so dass sie durch die Kategorisierung (Windows Clients, Windows XP Clients, Clients für die Verteilung von Adobe Photoshop,…) teils mehrfach in der Hierarchie auftraten. Daraus ergab sich für WOL.NET also ein Baum mit tausenden von Knoten. Im Web. Und wir wussten noch nicht, wie Load on Demand funktioniert. Es gab nicht einmal ein TreeView Control unter ASP.NET, geschweige denn einen Drittanbieter für so etwas (zumindest keinen mit einer kostenfreien Lösung).

Was es indes gab, war ein ASP.NET TreeView Control bei Microsoft Research (2006 wurde es übrigens regulär als CSS Control Adapter Toolkit veröffentlicht). Das befand sich in einer Art Beta-Stadium und beherrschte etwas Großartiges: Es war CSS Friendly. Das bedeutet, es war möglich, ASP.NET dazu zu bringen, das Control auf eine beliebige Art so zu rendern, dass etwas dabei herauskommt, was sich einfach mittels CSS optisch gestalten lässt. In diesem Fall: Eine Unordered List aus der geschickte CSS-Definitionen optisch einen hierarchischen Baum zauberten. Und nicht nur das: Es wurde direkt JavaScript-Code mitgeliefert, der den Baum interaktiv werden ließ: Einklappen, Aufklappen, einzelne Zweige selektieren und – und das war das besondere Highlight – während es zwar keine TriState Checkboxen gab, konnte der Code immerhin rückwärts die übergeordnete CheckBox deselektieren, sobald in der Hierarchie darunter auch nur ein Häkchen entfernt wurde. Sehr cool.

Das einzige Problem: Beim Aufruf der Webanwendung wurden alle Daten des Baumes in einem Rutsch komplett an den Browser übertragen. In unserem Testlab war das aufgrund der geringen Menge an Clients kein Problem. Beim Kunden knallte es. Natürlich. Unsere Lösung war zweigleisig: Zum einen erhöhten wir den TimeOut auf 2 Stunden. Im Nachhinein betrachtet klingt das aberwitzig, aber der Kunde ließ sich darauf ein. Da wurde dann eben WOL.NET geöffnet, in die Mittagspause gegangen und danach der Job konfiguriert. Das gehörte zur täglichen Routine. Zum anderen ergänzten wir die Möglichkeit, mittels konfigurierbarer Optionen einen beliebigen Knoten in der SMS Hierarchie als Stammknoten für WOL.NET zu definieren. Im Kern ging es hier nun einmal um Softwareverteilung und dafür wurden vom Kunden jedes Mal sog. Collections in SMS angelegt. Sobald diese in WOL.NET als Stammknoten eingestellt waren, wurden auch nur diese – und natürlich die Clients darunter – auf der Hauptseite angezeigt und alles war gut.

Darüber hinaus arbeiteten wir an einer ganzheitlichen Lösung des Problems. Und die kam später in Form einer Infragistics-Lizenz (sic!). Von Infragistics wurde uns ein TreeView Control geboten, das alle Funktionen enthielt, die wir brauchten. Inklusive Load on Demand. Das kam einer Erleuchtung gleich! Lediglich die Anpassungen an unseren Stored-Procedures war nicht so einfach wie gedacht, da diese nun nicht mehr direkt hierarchische Daten in einer zweidimensionalen Tabelle liefern mussten, sondern komplett umgeschrieben, um Knoten nach Bedarf zu laden, sowie Informationen darüber, wie viele Knoten sich jeweils darunter befinden zu liefern.

Das Problem mit den Magic Packets war da schon komplexer. Vereinfacht gesagt ist die Sache die: Ein Magic Packet ist ein ursprünglich von AMD definiertes Netzwerkpaket, dessen Aufbau festgelegt ist und i.d.R. die MAC Adresse des aufzuweckenden Clients beinhaltet nebst einem Identifier, der es als Magic Paket erkennbar macht. Warum nun also eine MAC Adresse? Ganz einfach: Solange ein Client offline ist, verfügt er schlicht über keine IP Adresse. Was er aber haben kann, ist eine Netzwerkkarte, die rudimentär mit Strom versorgt wird und am Kabel lauscht. Dazu müssen Netzwerkkarte und Mainboard Wake on LAN unterstützen und zusätzlich entsprechende Einstellungen im BIOS und dem Betriebssystem gemacht werden. Das einmal vorausgesetzt kann also ein Magic Packet auf die Reise geschickt werden und sobald die mit der entsprechenden MAC Adresse versehene Netzwerkkarte dieses Paket vorbeiflitzen sieht, fährt es den Rechner, in dem sie steckt, einfach hoch. Da das aber nicht zielgerichtet sein kann – es gibt ja keine IP-Adresse – muss das Paket in das gesamte Netzwerk gebroadcastet werden. Und das stellte sich als Problem heraus, sofern Subnetze zum Einsatz kamen. Das war nahezu immer der Fall. er sich hier für Details interessiert, der liest am besten Mal Artikel über Networking Layer und das ISO OSI Modell.

Gelöst werden kann das Problem entweder, in dem die Router zwischen Subnetzen für sog. Directed Broadcasting konfiguriert werden, oder indem man in jedem Subnetz einen eigenständigen Service installiert, der nur für sein eigenen Netz verantwortlich ist. Wir unterstützen seit jeher beides und waren damit der Konkurrenz und auch Microsoft selbst voraus. Unser WOL.NET ließ dabei auch einen hybriden Modus zu, in dem einzelne Dienste für mehrere Subnetze verantwortlich waren und diese per Directed Broadcast erreichen konnten, sowie Dienste, die nur für jeweils ein Subnetz verantwortlich waren. Dieses Szenario ergab immer dann Sinn, wenn ein Unternehmen bspw. über mehrere Standorte verfügte und an einigen Directed Broadcast erlaubt war, an anderen aber nicht. Wenn es nach uns gegangen wäre, hätten wir immer empfohlen, Directed Broadcast zu erlauben. Allerdings hat es vor einigen Jahren Angriffe auf Unternehmen gegeben, die über diese Technologie ermöglicht wurden (Stichwort: Smurf Attack). Obwohl man bereits damals die Quelle für solche Broadcasts und auch die erlaubten Ports konfigurieren konnte, hielt das viele Systemadministratoren nicht davon ab, aus Sicherheitsgründen weiterhin auf Directed Broadcasts zu verzichten. Immerhin hatten wir selbst in dem Fall eine Lösung parat.

Installation

Während unsere ersten Kunden für WOL.NET sich schon fast durch langjährige, beinahe freundschaftliche Beziehungen charakterisieren ließen, kamen bald schon Interessenten hinzu, die uns in dem Kontext ausschließlich als Hersteller einer Software wahrnahmen. Als Beratungsunternehmen waren wir es gewohnt, unser KnowHow an den Kunden weiterzugeben, was im Fall von WOL.NET auch bedeuten konnte, dass der Windows NT Service und die ASP.NET Webanwendung nebst SQL-Datenbank manuell angelegt und eingerichtet wurden. Die Schritte wurden wie in regulären Projekten auch protokolliert, dokumentiert und an den Kunden übergeben. Das Resultat: Maximale Flexibilität und auch Unabhängigkeit. Kunden aber, die annahmen, wir wären ein Softwarehersteller, erwarteten eine Boxed-Lösung inkl. MSI-Setup.EnergyMonitor

Zu dem Zeitpunkt war die Featureliste von WOL.NET bereits spürbar angewachsen. Es gab neben dem Hauptprodukt auch eine Integrationskomponente für SMS 2003 und später auch SCCM 2007, sowie einen Energymonitor, der visuell aufzubereiten versuchte, wie es um den Energieverbrauch der Systeme steht und wie er sich vor allem durch die Nutzung der Shutdown-Funktion optimieren ließ. Es kam ein SelfService Portal hinzu, über das Mitarbeiter von Zuhause aus in der Lage waren, ihren Arbeitsplatz-PC einzuschalten, um sich damit bspw. Remote zu verbinden und noch ein paar weitere Kleinigkeiten mehr. Die Installation gestaltete sich daher beliebig komplex – und alles was wir hatten, war InstallShield. Dieses Produkt hat eine sehr bunte Vergangenheit und mehrere Aufkäufe hinter sich. Inzwischen gehört es glaube ich Flexera. Das Setup für WOL.NET musste Webseiten im IIS einrichten und konfigurieren, Dienste installieren, Service-Konten erstellen und Berechtigungen zuweisen, Datenbank-Schemata einrichten und von Version zu Version migrieren, Updates ermöglichen und vieles mehr. Da InstallShield bspw. zwar Standard-Dialoge mit sich bringt, um Benutzerkonten im AD anzulegen (das aber pro Setup auf EIN Konto beschränkt) begann hier eine Odysee, die u.a. auch in der Entwicklung C++ basierter Custom Actions mündete für die Prüfung eingegebener Kennwörter oder das Zuweisen von Berechtigungen. Bis das Setup vollständig funktionierte, ist sehr viel Zeit ins Land gegangen, aber das Ergebnis konnte sich sehen lassen.

Mehr Verkäufe konnten wir dadurch allerdings nicht verzeichnen. Eine schöne Anleitung und vielleicht das ein oder andere Powershell-Script hätten es vermutlich auch getan.

Verified for Windows

Als langjähriges Mitglied im Microsoft Partner Network sind wir stolz darauf, dass wir bereits seit über zehn Jahren in der einen oder anderen Weise Goldpartner sind. Zunächst ganz allgemein, später in immer mindestens einer Kompetenz (nachdem Microsoft ich glaube 2010 das Modell geändert hat). Darunter fiel auch die sog. ISV Kompetenz (Independent Software Vendor). Der Vorteil, eine solche Kompetenz inne zu haben, liegt darin, zum einen damit werben zu können: Ein schickes Logo gibt es nämlich gratis dazu. Zum anderen verteilt Microsoft damit auch kostenlose Softwarelizenzen, die bspw. für Entwicklungs-, Test- und Demonstrationszwecke eingesetzt werden können. Zwei gute Gründe für uns also, die ISV Kompetenz zu erwerben. Dem vorgeschaltet war allerdings, dass man als ISV mindestens ein Softwareprodukt von einem unabhängigen Institut testen lassen musste. Für WOL.NET aber genügte es nicht, das Setup durchlaufen zu lassen und dann ein wenig in der Software herumzuklicken. Nein, man benötigte einen Domaincontroller, einen SQL Server, ein installiertes und voll funktionsfähig konfiguriertes SMS 2003 nebst mindestens einem physischen Client, den man auch aufwecken kann und der in SMS bekannt sein musste. Im ersten Durchlauf mit der Firma Veritest haben wir also ein Notebook aufgesetzt und alles vorinstalliert und konfiguriert, was ging, eine hübsche CD mit WOL.NET drauf dazugepackt und um einen Testleitfaden ergänzt. Das ganze Paket ging dann auf die Reise nach England und wiedergesehen haben wir es nie wieder.

CD CoverNach einigen Nachfragen konnte Veritest immerhin bestätigen, dass WOL.NET tat, was wir behaupteten und verpassten dem Produkt das Label “Verified for Windows”. Wir wurden daraufhin ISV und freuten uns. Später wurde aus WOL.NET RPM (Remote Power Management) und der Prozess mit Veritest gestaltete sich plötzlich viel einfacher:

Auf einmal mussten die Binaries gar nicht mehr digital signiert sein. Wir brauchten gar keinen Account auf winqual.microsoft.com mehr und das dazu notwendige teure Zertifikat von Verisign war ebenfalls unnötig. Auch das Setup musste nicht signiert sein. Das Label “Verified for” benötigt das alles nicht, ob wir das nicht gewusst hätten? “Tested for…” setzt Zertifikate voraus. Spannend. Und darüber hinaus gibt es eine Testsuite, die wir herunterladen könnten, um die Software selbst zu testen. Die Ergebnisse werden verschlüsselt an Veritest übertragen und die würden sie daraufhin über ihre eigene Suite bestätigen. Wir bräuchten gar keine Hardware schicken, das ginge auch so.

Wir fragten also: Was ist eigentlich aus dem letzten Notebook geworden, das wir euch geschickt haben? Und Veritest so: “Ach das… das liegt hier noch rum… wollt ihr es wiederhaben?”. Auf die Erkenntnis hin, was für Mühen und Aufwand die Retour produziert hätten, haben wir die freundlichen Kollegen von Veritest gebeten, das Gerät zu entsorgen.

Marketing

Ungefähr zu der Zeit sollte für die Einführung von Windows 7 eine virtuelle Konferenz stattfinden. Ebenfalls gab es eine Website von Microsoft die für speziell für das OS kompatible Anwendungen bekannter ISVs warb. Auch wurden hier die ersten Marketplaces beim Redmonder Konzern geboren und überall waren wir dabei. Unser Unternehmen wurde auf allen Plattformen präsentiert, wir wurden in den Lösungskatalog aufgenommen und standen in der Liste für Windows 7 kompatible Anwendungen. Gebracht hat all das leider nichts. In all den Jahren gab es genau eine Anfrage zu RPM 2009, die über Microsoft Pinpoint ihren Weg zu uns fand. Der Admin einer kleinen IT Schmiede war geschockt, als wir ihm unser Preismodell erklärten und meinte, er hätte Skripte, die das gleiche täten für lau. Für seine Umgebung mag das sogar stimmen.

RPM_2009_BoxShotAuch haben wir dem Kind einen professionellen Anstrich gegeben. RPM erhielt einen Box Shot, der Lust auf mehr machen sollte. Dass das für ein Produkt dieser Kategorie kein wirklich ausschlaggebender Faktor ist, sei einmal dahingestellt. Zusammen mit dem Installationssystem stellt es im Nachhinein vermutlich den Teil des Aufwandes dar, auf den wir getrost hätten verzichten können. Im Vergleich zum MSI war der zeitliche Aufwand für den Box Shot immerhin sehr gering und das Ergebnis sah nett aus. Ich frage mich bis heute, warum wir die Grafik nicht in den Installer eingebaut haben…

Funktionsvielfalt

Viele Funktionen sind auf besonderen Kundenwunsch entstanden. Da wir aber nie mandantenabhängig entwickelt haben, waren Funktionen, die durch einen Kunden in das Produkt Einzug hielten, fortan auch für alle weiteren Kunden verfügbar. Während das zunächst einmal nach etwas Gutem für die Kunden klingt, hat es uns persönlich vor eine immense Herausforderung gestellt: Die Funktionen genügten zumeist den exakten Anforderungen des ursprünglichen Auftraggebers und funktionierte super in dessen Infrastruktur. Das bedeutete aber nicht zwangsläufig, dass sie auch überall anders funktionierten. Wir mussten schnell lernen, dass insbesondere im Bereich der Infrastrukturen kein Ei dem anderen gleicht. Ein Kunde benötigte bspw. ein Kommandozeilentool (heute würde man CLI sagen für Commandline Interface), über das sich ein Client direkt aufwecken lässt. Während wir zwar seit Anbeginn von WOL.NET so ein Tool hatten (ursprünglich, um die Funktionalität zu testen), war nun aber die Anforderung, auch die Ausnahmelisten von RPM zu nutzen und das Logging noch dazu. Sprich: Das Tool durfte den Befehl nicht selbst absetzen, sondern musste einen Job in der RPM Datenbank hinterlegen, ganz genau so wie es auch die Webanwendung täte. Das hat sehr gut funktioniert, hatten wir doch die gesamte Geschäftslogik in Bibliotheken verkapselt und mussten sie nun nur einfach in einem Konsolenprojekt orchestrieren. Leider hatten wir die Rechnung nicht mit den Sicherheitsfanatikern anderer IT-Abteilungen gemacht: Was beim Auftraggeber wunderbar funktionierte, scheiterte bei anderen Kunden daran, dass die direkte Verbindung zum SQL Server von SCCM 2007 nicht von den Admin-Maschinen aus erlaubt war, sondern nur vom SCCM Server aus. Unser Kommandozeilentool funktionierte also nur von einer Konsolen-Session direkt auf dem SCCM Server.

Wartung und das schleichende Ende

Ganz genau so wie Hersteller anderer Softwareprodukte boten wir unseren Kunden natürlich auch Wartungsverträge an. Dabei stellte sich aber verhältnismäßig schnell heraus, dass hier die Rechnung nicht aufging: Der Betrag, den die Kunden per anno dafür zahlten, wurde durch den Aufwand, der durch Anfragen entstand, bei Weitem überstiegen (wann man unsere regulären Tagessätze als Berater in Projekten als Maßstab nimmt). Hinzu kam allerdings ein viel gravierenderes Problem: Als Unternehmensberatung war und ist unser zentrales Anliegen, unsere Mitarbeiter in Projekte zu bringen. Es konnte also selten sichergestellt werden, dass jemand mit WOL.NET / RPM Entwicklungskompetenz verfügbar war, wenn er oder sie gebraucht wurde. Das hat dazu geführt, dass die Arbeit an der Software nach und nach eingestellt wurde und im Laufe der Zeit auch unser Vertrieb in dieser Hinsicht das Engagement einstellte. Heute gibt es nur noch zwei Kunden, die das Produkt einsetzen – soweit wir es sagen können. Die letzten Funktionen, die dabei durch uns ergänzt wurden betrafen die Kompatibilität zu SCCM 2012, sowie die Einführung einer Unterstützung für intels Active Management Technology (AMT), mit der sich inzwischen sogar gezielt Clients aufwecken und herunterfahren lassen – ganz ohne Magic Packet und die damit verbundenen Herausforderungen. Auf der Strecke geblieben sind dabei das Installationssystem – nachdem sich unsere alte InstallShield 2009 Lizenz mangels Herstellerseite nicht mehr reaktivieren lässt und das eine oder andere Feature, das nicht benötigt und von uns daher vorsorglich aus dem Paket entfernt wurde. Dafür hat das Kind einen neuen Namen: RPM Core. So heißt es übrigens auch bei uns in der Quellcodeverwaltung – wie praktisch.

Fazit

Was als ambitioniertes Projekt begann, entwickelte sich rasant zu dem umfangreichsten Stück Software, dass die TOP TECHNOLOGIES innerhalb von über zehn Jahren hat entstehen lassen. Fast alle Mitarbeiter mit Fokus auf Softwareentwicklung durften ihre Kompetenz mit einbringen und auch der eine oder andere Auszubildende hat sich seine Hörner daran abstoßen können. Wir haben viel über die Entwicklung von Enterprise-fähigen Produkten gelernt, über komplexe IT Infrastrukturen, die Zusammenarbeit mit Agenturen, die Handbücher übersetzen – und über das Erstellen von Produkthandbüchern im Allgemeinen, über den Entwurf und die Umsetzung komplexer Installationsszenarien und worauf man beim Logging achten sollte – und was man lieber bleiben lässt (viel ist nicht immer gut –> gut ist gut.)

Trotz allem: Wir sind kein Produktentwicklungshaus und haben einige Jahre gebraucht, um zu verstehen, dass unser Geschäftsmodell nicht kompatibel zur Entwicklung eines Produktes wie RPM ist. Ich bin stolz auf unsere Geschäftsführung, die in WOL.NET von Anfang an ein großes Potential erkannte und das Risiko einging, es über die Jahre hinweg auch als Investition zu betrachten. Sie standen jederzeit mit Rat und Tat hinter dem Produkt und waren zugleich Mentoren für uns Entwickler wie auch Ideengeber für sinnvolle Funktionen! Es war eine schöne Zeit, in der wir alle viel gelernt haben, die nun aber zu Ende geht. Vermissen werde ich sie dennoch nicht, da sich auch mein eigenes Aufgabenfeld verändert hat und inzwischen keiner meiner Mitarbeiter mehr aktiv an dem Projekt arbeitet. Dennoch war gerade die sehr intensive Zusammenarbeit mit Kollegen an unserem eigenen Produkt auch eine spannende Zeit für die ich dankbar bin!

Comments are closed

Über die Autoren

Christian Jacob ist Leiter des Geschäftsbereiches Softwarearchitektur und -entwicklung und zieht als Trainer im Kontext der .NET Entwicklung sowie ALM-Themen Projekte auf links.

Marcus Jacob fokussiert sich auf die Entwicklung von Office-Addins sowie Windows Phone Apps und gilt bei uns als der Bezwinger von Windows Installer Xml.

Martin Kratsch engagiert sich für das Thema Projektmanagement mit dem Team Foundation Server und bringt mit seinen Java- und iOS-Kenntnissen Farbe in unser ansonsten von .NET geprägtes Team.

Aktuelle Kommentare

Comment RSS