Montag, 9. November 2015

Prinect 2016 - the good, the bad and the ugly

The Good:

  • Das Upgrade von Prinect 2015 auf Prinect 2016 ausgeführt über das Prinect Maintenance Center verläuft einfach, schnell und relativ problemfrei. Das ist ein Riesenschritt nach vorne gegenüber vorigen Versionen.
  • Das Archive-System wird umgestellt von der 'Orrible-Datenbank auf die MS-SQL-Datenbank
  • im Cockpit kann man nun Einträge im Dropdown links und rechts "favorisieren"/pinnen:
  • neue Optionen im Preflight
  • die Signastation hat nun das gleich aussehende Workflow-Band wie Cockpit
  • in der Signastation gibt es schnell-Auswahlfelder mit den zuletzt genutzten Plattenstandbögen, Ausschiessschema usw.

The Bad:

  • Signastation und Cockpit benötigen wesentlich länger zum Starten als mit Prinect 2015
  • im Cockpit konnte man zugewiesene Seiten in einer Seitenliste aus der Seitenliste entfernen, indem man sie wieder mit Drag'n'Drop zurückzog; das geht nicht mehr

The Ugly:

  • Nur noch 5 Aufträge im Ansichts-Menü von Cockpit. Das macht den neuen "Splitview" für breite Monitore nutzlos, weil jeder angeklickte Auftrag einen früheren in der Liste ersetzt. Man bekommt das Gefühl, dass dort ähnlich wie bei Adobe nicht an die Profi-Anwender gedacht wurde, sondern an die Gelegenheits-Anwender. Bei uns sind über den Tag verteilt 10-20 Aufträge geöffnet, zwischen denen man immer hin- und herspringen muss. Das ging früher wesentlich einfach, jetzt ist es eine ewige Suche in der Auftragsliste (mit STRG+f oder manuell):
  • in der Signastation gibt es einen Fehler/Änderung bei der Berechnung der Zwischenschnitte.
    Beispielauftrag:
    Bogengröße 880 mm * 630 mm
    Seitengröße 210 mm * 297 mm
    Kopfbeschnitt max. 6 mm
    16 Seiter 3-Kreuzfalz
    Signastation 2016 Hotfix 1 (und alle Signastation davor) hat den Zwischenschnitt wie folgt berechnet: 12 mm am Fuß, 6+6 mm am Kopf, 12 mm am Fuß und passte somit auf den Millimeter genau auf das Bogenformat mit 630 mm Höhe (12+297+6+6+297+12=630)


    Signastation 2016 Hotfix 2 bis Hotfix 5: 11 mm Fuß, 6+6 mm Kopf, 11 mm Fuß

Samstag, 8. März 2014

Oracle DB Upgrade 2013

Nach den (erwarteten) Fehlschlägen des Upgrades auf Prinect 2013 ging es nun mit der Hilfe des Heidelberg-Supports an die Fehlerursache und -behebung.

Ich muss sagen, ich war sehr positiv überrascht über die Reaktionszeit des Supportmitarbeiters und den Willen zu helfen. Das hatte ich im Jahr zuvor anders erlebt, als es um das Upgrade der Oracle DB ging.

Erst einmal die Fakten, Stand vor dem Upgrade:

  • Oracle-DB 11.2.0.3.0
  • CommonDB 12
  • ArchiveSystem 12
Nun machte ich mich also daran, nach der Anleitung der Oracle-DVD das Upgrade zu starten.
Die CommonDB konnte erfolgreich aktualisiert werden. Das war ja auch einfach, eine Vorgehensweise Marke ComputerBILD: Installer starten, weiter, weiter, ja, ... fertig stellen.

Die Oracle DB dagegen wollte nicht so richtig mit dem OraSPInstaller installiert werden.
Manuelles beenden der ArchiveSystem-Dienste, AnalyzePoint und doppeltes kontrollieren und setzen der Ordner-Berechtigungen, Benutzerrechte, Dienstrechte usw. brachte keine Besserung: Abbruch mit Fehlermeldung während des Upgrades.

Der Tipp des Supportmitarbeiters, noch ein paar weitere unkritische Dienste zu beenden tat nichts am fehlerhaften Ergebnis.

Als nächstes durfte der Supportmitarbeiter selber das Upgrade versuchen (Gott wie ich VM-Snapshots liebe!). Auch dann blieb es erfolglos und brach an der selben Stelle mit demselben Fehler ab. Immerhin bedeutete das, dass ich nichts falsch gemacht habe ;)

Nach dem Einsammeln der Logfiles und einem weiteren (Karnevals-) Wochenende ging es damit weiter, dass ich die Installationsmedien erneut erhielt. Dort bestand die Möglichkeit, dass irgendetwas nicht in Ordnung war mit der Version, die ich zuvor bekommen hatte.
Knapp 6,8 GB später (ich brauche eine Internetanbindung mit mehr Bandbreite!) fiel es mir dann wie Schuppen von den Augen, warum das Upgrade bisher fehl schlug ...

Aber zunächst startete ich einen weiteren Versuch des Upgrades.
Installer lokalisiert auf der DVD, OraSPInstaller gestartet.

Ergebnis:

Nanu? Available version ist gleich Installed version 11.2.0.3.0?
In den Versuchen mit dem ersten Installer stand da doch Available version 11.2.0.4.0?
Noch einmal nachschauen ...


Yep, 11.2.0.4.0. Moment einmal. Common Database 15.0 gegenüber Common Database 12.0?
Das war nun wirklich so, der Installationsordner ist ebenfalls korrekt benannt. Dass mir das vorher nie aufgefallen ist, ist ja schon fast peinlich. Andererseits hat der Supportmitarbeiter dort auch nichts gemerkt ;)

Installationsordner 1. geladene Version:
BLD_15.00.2.01__x64 (man beachte die 15!)

Installationsordner der 2. geladenen, korrekten Version:
BLD_13.00.5.04__x64 (und hier haben wir die 13)

Lange Rede, kurzer Sinn - ich habe die Version der OracleDB-DVD für Prinect 2015 geladen und die CommonDB auf den Stand von Prinect 2015 gebracht. Die Oracle-DB hingegen weigerte sich, von Version 2012 auf 2015 zu kommen. Geplant war ja auch 2013 als Ziel.

Und was lernt man daraus? Wenn man schon den neuen Distributionsweg "Download" nutzt, muss man leider kontrollieren, ob man auch wirklich die richtige Version für alle Komponenten erhalten hat. Was so ein kleiner Versionsunterschied, eine kleine Zahl (15 statt 13) alles an Zeit und Aufwand kosten kann ist schon erstaunlich. Und den ganzen Ärger hätte ich mir sparen können, wäre ich nur etwas aufmerksamer gewesen - oder hätte man mir die korrekte Version zum Download gegeben.

Im Endeffekt muss ich kein OracleDB-Update durchführen, da ich für Prinect 2013 schon die aktuelle Version einsetze. Laut Support ist es auch kein Problem, die CommonDB 2015 mit Prinect 2013 zu nutzen. Empfehlen würde ich diesen Mischmasch nicht, aber damit lebe ich nun erst einmal bis Prinect 2015.

Stand nach dem Upgrade:
  • Oracle-DB 11.2.0.3.0
  • CommonDB 15
  • ArchiveSystem 13

Samstag, 22. Februar 2014

Saphira Verbrauchsmaterialien - Proofpapier

Wir beziehen unser Proofpapier von Saphira.
Oder vielmehr bezogen, denn ...

11. Februar: Proofpapier bestellt, die letzte Rolle in den Drucker eingespannt. Und natürlich muss nun ein Kunde unbedingt Proofs im Format 1:1 haben, 1 Meter lange Lappen in großer Zahl.

17. Februar: nachgefragt, wo denn das Proofpapier bleibt. Normalerweise wird ja innerhalb von 1-2 Tagen geliefert.
Überraschung! Das Proofpapier ist noch nicht einmal unterwegs. Die nette Dame am anderen Ende der Telefonleitung verflüchtigt sich in "es gibt zur Zeit kein Proofpapier mehr". Aha.
Nachbohren ergibt, dass der Lieferant insolvent ist und Heidelberg sich bemüht, Ersatz zu finden.

Schick. Womit wir bei meinem Lieblingsthema wären, der Informationspolitik von Heidelberg. Die Insolvenz und damit der Wegfall des Lieferanten ist schon seit einiger Zeit bekannt bei Heidelberg. Und wieder einmal gab es keine Information an die eigenen Kunden. Natürlich kann es jedem passieren, dass ein Lieferant Insolvenz anmeldet. Aber dann kann man das aktiv an die eigenen Kunden weitergeben, dass diese sich darauf einstellen können. Ein solches aktives Vorgehen schafft Vertrauen.
Schließlich bedeutet das im Falle von Proofpapier mindestens eine Neu-Kalibrierung des Mediums.
Aber genau wie im Fall Prinect Upgrade 2013 gibt es erst Informationen, wenn der Kunde aktiv wird und nachfragt.


Das High-Leid an dieser Geschichte war dann ein Gespräch mit unserem zuständigen Verkäufer/Berater von Saphira: wir hätten schon im Dezember informiert werden sollen über den Proofpapierwechsel, inkl. Besuch eines Spezialisten, der eine Rolle neues Material mitbringt und mit uns die entsprechenden Kalibrierungen anpasst. Da soll aber etwas mit der Ausführung schief gelaufen sein.
Ich kenne den zuständigen Spezialisten, und kann mir nicht vorstellen, dass diese Person uns (freiwillig) so im Dunkeln gelassen hätte. Mindestens eine E-Mail hätte ich bestimmt von dem Spezialisten erhalten.
Außerdem frage ich mich: wenn der Spezialist das "neue" Papier mitgebracht hätte, warum haben wir das nicht geliefert bekommen seit der Bestellung am 11. Februar?

Ein weiteres High-Leid:
Anscheinend sind Telefonrückrufe auch nur ein Mittel, um den Kunden Zeit möglichst einfach abzuspeisen.
17. Februar, 1. Telefongespräch ca. 10:00 Uhr: Rückruf noch heute, wann/ob wir Proofpapier erhalten.
17. Februar, 2. Telefongespräch ca. 15:30 Uhr: nach ein wenig Weiterleitungs-Ping-Pong wird mir mitgeteilt, dass jetzt der Hinweis auf Telefonrückruf an Person X weitergeleitet wurde. (D.h. der versprochene Rückruf vom vorigen Telefongespräch war nur Schall und Rauch?)

Bis heute habe ich keinen Rückruf von Person X erhalten.
Dafür haben wir nun eine neue Bezugsquelle für Proofpapier.

So langsam glaube ich, bei Heidelberg herrscht Informationsfreiheit für Kunden. Die Kunden werden frei von jedweder Information gehalten.

Upgrade auf Prinect 2013

Dieses Wochenende war es dann soweit, nach dem 1. Test am vorigen Wochenende konnte diesmal alles installiert werden.

Aber ich starte einmal noch wesentlich vorher - in grauer Vorzeit sozusagen.
Eines vorweg: ich möchte definitiv keine Heidelberg-Support-Mitarbeiter, mit denen ich Kontakt hatte, irgendetwas vorwerfen. Ich weiß, es ist nicht eure Entscheidung, was die oberste Heeresleitung vorgibt.


Anfang Februar hatte ich die hervorragende Idee, doch einmal nachzufragen, wann das Upgrade auf Prinect 2013 denn verschickt wird. Also zum Telefonhörer (wie altmodisch) gegriffen und in der HD-Niederlassung angerufen.

Überraschung 1: es gibt keinen Versand von Installationsmedien mehr. Aus Kostengründen stellt man entweder die ISO-Images als Download zur Verfügung oder die netten Mitarbeiter der Niederlassung brennen diese auf DVDs und bringen sie vorbei.

Ich habe ja nichts gegen Kosteneinsparungen, aber wäre an dieser Stelle nicht wenigstens eine Information an die Kunden mit Servicevertrag möglich gewesen? Eine E-Mail hätte es ja getan, es muss ja nicht gleich ein Brief mit Porto werden. Zu warten, bis der Kunde sich meldet und nachfragt, halte ich für eine äußerst ungeschickte Strategie.

Ich entschied mich für die Download-Variante. Also angefragt für die Downloadlinks für das Upgrade von Prinect 2012 auf 2013. Zusammen mit unserer Kunden und Dongle-Nummer sollte man ja sehen, was wir so benötigen an Software.

Überraschung 2: E-Mail mit Downloadlinks für

  • Color Toolbox
  • MetaDimension
  • PDF Toolbox
  • PrePress Interface
  • MetaShooter
  • SignaStation
Nunja. Für meinen Geschmack fehlten da ein paar Dinge. MetaShooter haben wir nicht, PrePress Interface ebenfalls nicht. Also heruntergeladen und noch ein paar weitere Teile angefordert, schließlich will man ein vollständiges Upgrade machen:
  • Archive-System
  • CommonDB Oracle
  • PrePress-Manager
  • Dokumentations-DVD
  • ColorProofPro
Im nächsten Anlauf gab es dann diese Softwareteile zum Download. Statt ColorProofPro gab es erneut die MetaDimension-DVD. Nachgefragt: ColorProofPro ist in MetaDimension nun enthalten und kein zusätzliches Paket mehr. Schick.
Nach ein paar Problemen mit dem Download des Archive-Systems habe ich das per FTP-Upload bei uns erhalten. Der Downloadlink von HD funktionierte nie.


Das WE nähert sich, das Test-Upgrade wird ausgeführt. Snapshots von virtuellen Maschinen sind eine geniale Sache.

Als erstes versucht man sich an der Oracle-Datenbank. Bei der hat schließlich noch nie ein Upgrade ohne professionelle Support-Hilfe funktioniert. Und das geht ja erst seit 5 Jahren so ;)

Keine Überraschung 1: trotz genauem befolgen der Anleitung schlägt das Upgrade fehl und hinterlässt eine kaputte Installation. Gut, das hatte ich erwartet - dafür gibt es Snapshots und Backups.
Auch ein paar Experimente bringen keine Besserung. Ein Update mit Sicherheitspatches funktioniert noch, das Upgrade der CommonDB ebenfalls. Aber das Upgrade der Oracle-Installation von 11.0.2.3 auf 11.0.2.4 bricht jedes Mal mit einem Fehler ab und hinterlässt dann eine nicht mehr lauffähige Oracle-DB. Praktischerweise funktioniert die CommonDB und das Archive-System auch mit Oracle-Version 11.0.2.3. Um das kaputte Upgrade auf 11.0.2.4 darf sich dann nächste Woche ein Oracle-Experte kümmern. Ich würde darauf wetten, dass das einmal wieder ein kostenpflichtiger Support-Einsatz wird.
Ich kann es kaum erwarten, die Oracle-DB loszuwerden und durch die MS-SQL-DB zu ersetzen.

Keine Überraschung 2: die Migration von Oracle-DB zu MS-SQL-DB wird (noch) nicht unterstützt.


Nachdem das Upgrade ja schon im Sande verlaufen ist, teste ich das Upgrade der MetaDimension. Läuft einwandfrei ohne Probleme durch. Fein.

Nächster Stop: Upgrade von Prinect PrePress Manager bzw. Integration Manager.
Die Installation läuft kurz an und beschwert sich dann, dass eine CommonDB MS-SQL fehlt.

Überraschung 3: die CommonDB ist umgezogen auf eine MS-SQL-DB, und die ist nicht optional. Das steht sogar in der Installationsanleitung drin, die 40 Seiten stark ist.
Ich zitiere einmal Seite 19:

Voraussetzung: Es ist zwingend erforderlich, dass vor der Installation einer Heidelberg Prinect Workflow Applikation die "Heidelberg Prinect CommonDatabase MS-SQL" installiert worden ist. Sollte dieses nicht der Fall sein, bricht die Installation mit einer Fehlermeldung ab.
Das ist alles, was dazu zu finden ist. Keine weiteren Hinweise außer dem Abbruch des Installers.
Also noch die "Heidelberg Prinect CommonDatabase MS-SQL" angefordert als Download.
Dazu sei mir die Anmerkung erlaubt: es ist bekannt, welche Softwarepakete ein Kunde lizensiert hat und welche er benötigt für ein Upgrade. Die sollte man auch im Komplettpaket zur Verfügung stellen können, und nicht erst mit zweimaligem Nachfordern des Kunden, der noch nicht einmal weiß, dass er seit neuestem Paket X benötigt, was es vorher nicht gab.

Die Support-Mitarbeiter sind da recht schuldlos finde ich, die dürfen das bestimmt zum ersten Mal so machen und haben noch nicht die entsprechende Erfahrung oder Informationen.


Es nähert sich das nächste Wochenende. Upgrade-Versuch, die 2.

Als erstes die CommonDB Oracle aktualisiert. Funktioniert. Den Versuch, die Oracle-DB selbst zu aktualisieren, lasse ich direkt bleiben. Das darf unter der Woche ein Experte machen.

Dann die CommonDB MS-SQL installiert. Die Anleitungen (es gibt derer 2) befolgt.

Keine Überraschung 3: man kann nur die Express-Variante der SQL-DB Version 2012 installieren. Die Vollversion wird in der Installation nicht unterstützt:
At this time two editions are to be supported:
  • Express x64
  • Standard x64 (not yet available)
Auch die Nutzung einer schon vorhandenen Vollversion der MS-SQL-DB auf einem anderen Server ist nicht möglich. Um die Einschränkungen der Express-Version zu umgehen (Backup, Scheduled Tasks ...) wird ein wenig manueller Aufwand betrieben nach der Installation.

Kleiner Tipp: wenn man später das Passwort zum Anmelden an der DB benötigt, das steht etwas versteckt in der ReleaseNotes.html der Installations-DVD.


Die CDB MS-SQL bringt einige neue Abhängigkeiten mit, unter anderem das .Net-Framework 4.
Das war vorher nicht installiert, und der Installer kümmert sich auch darum.

Großer Tipp: danach war Windows direkt dabei, Sicherheitsupdates für das "neue" .Net-Framework zu installieren. Im Hintergrund. Und das mag die Installation des Integration Managers *gar nicht*.
Also vorher einmal Windows seine Updates installieren lassen inkl. Neustart des Systems, bevor man weitere Installation von Heidelberg-Software startet. Das dauert locker eine Stunde, je nach Hardware.


Das Upgrade des Integration Managers, des Archive-Systems und der MetaDimension verlief dann recht ereignislos im Vergleich.

SignaStation-Updates, Cockpit-Updates, Toolbox-Updates, Workflow-Updates, Meta-Updates werden gerade noch heruntergeladen vom Maintenance Center. Das ist nach wie vor toll. Ehrlich.

Ein paar Zahlen:

  • Gesamtgröße der Installations-Medien für das Upgrade: 25,5 GB
  • Gesamtgröße der Updates, die das PMC danach lädt: 5,9 GB
  • Größe des VM-Snapshots während der Installation: 13,2 GB
  • Dauer der Installation ca.: 4h Integration Manager, CDB Oracle/MS, AS, PSS; 30min Meta

Dienstag, 18. Februar 2014

Prinect 2013 - Systemanforderungen

Prinect 2013 ist ja nun aktuell, und es stellte sich die Frage, welche zugrundeliegenden Betriebssysteme man verwenden kann/sollte.

Eine kleine Tabelle der verschiedenen Aussagen der Systemanforderungen bzw. freigegebenen Betriebssysteme für die verschiedenen Komponenten:


Windows XPWindows 7 x64Windows 8Server 2003Server 2008 x64Server 2008 R2Server 2012Server 2012 R2
Prinect CockpitXXXX
Prinect Integration Manager
Dokumentations-DVD
Prinect_Installation_de.pdf
XX
Installations-DVD
Sysinfo_de.pdf
XX
MetaDimension
SPD_MD.pdf
XXXXX
CommonDatabase Oracle
ReleaseNotes.htmlXXX
ReadmeBeforeSetup.pdfXX
CommonDatabase MS-SQL
ReleaseNotes.htmlXXXX
CDB_MSSQL_13.0.pdfX
PMC/Liesmich.RTFXXXXX
Archive System
ReadMe_Prinect_Archive_System.pdf
XXX

Da nun die CommonDatabase MS-SQL Grundvoraussetzung für eine Installation des Prinect Integration Managers ist, bleibt als einziges unterstütztes Betriebssystem Windows Server 2008 x64 (kein R2!).
Oder doch Windows Server 2008 R2, wenn man sich nach anderer Dokumentation richtet?

Sonntag, 15. September 2013

OffTopic: Verschlüsselte und signierte E-Mails mit S/MIME oder GPG

Nicht zuletzt seit den Enthüllungen von Edward Snowden sollte man der nicht von Endpunkt zu Endpunkt verschlüsselten Kommunikation im Internet skeptisch gegenüber stehen.

Gerade im Bereich E-Mail und sensitiver Daten, wie z.B. Adressdaten für ein Mailing.
Daher nehmen wir E-Mails und Daten auch mit S/MIME und/oder GPG verschlüsselt entgegen.

Zusätzlich versenden wir seit einiger Zeit alle unseren E-Mails mit S/MIME signiert. Diese S/MIME-Signatur soll sicherstellen, dass die E-Mail unverändert ihr Ziel erreicht. Sollte die E-Mail inhaltlich verändert sein, so ist die S/MIME-Signatur ungültig. Zusätzlich ermöglicht die Signatur auch die Überprüfung, ob die damit signierte E-Mail auch tatsächlich von uns gesendet wurde.

Außerdem erhält der Rezipient der E-Mail somit auch direkt den Public-Key für eine verschlüsselte Kommunikation mit S/MIME.


Nun gab es darauf verschiedene Reaktionen seitens unserer Kunden:

  • viele haben es gar nicht bemerkt,
  • einige wenige fanden es gut,
  • und von einem Kunden gab es eine geradezu seltsame Reaktion.
Von dieser seltsamen Reaktion wollte ich nun berichten.

Der Kunde fragte, warum seit neuestem unsere E-Mails immer mit eine großen Warnmeldung "Signatur ungültig" bei ihm ankommen. Das wäre sehr irritierend, wir sollen das gefälligst abändern.

Ich versuchte in einem kurzen Telefonat zu erklären, dass die E-Mail inhaltlich verändert worden sein muss, damit eine solche Meldung erscheint. Da wir unsere eigenen E-Mailserver betreiben, kann ich sicher sein, dass unsere E-Mailserver die E-Mail nicht verändern. Ein Blick in die entsprechenden Logfiles zeigt auch, dass wir entsprechende E-Mails direkt beim E-Mailserver des Kunden eingeliefert haben, ohne weitere Zwischenstationen.
Daraufhin habe ich geäußert, dass die E-Mailserver des Kunden die E-Mails inhaltlich manipulieren (sei es das entfernen von Hyperlinks, das hinzufügen von "kein Virus enthalten, Scan erfolgreich"-Meldungen o.ä.). Das war dem Kunden egal, ich solle dafür Sorge tragen, dass dieser Hinweis nicht mehr auftrete.

Ich finde das aus 2 Gründen traurig.
Erstens, dass der Versuch einer sichereren Kommunikation mit solch einer Einstellung begegnet wird.
Und Zweitens: ich würde meiner IT (gut, das bin in dem Fall ich selbst ;) die Hölle heiss machen, warum signierte E-Mails inhaltlich verändert werden, statt diese Veränderung außerhalb des signierten Teils unterzubringen.

Zugegeben, S/MIME und GPG sind nicht gerade einfach und auf Knopfdruck einsetzbar, aber ich finde die Investition an Zeit, um sich damit zu beschäftigen, ist gut angelegt. Und das nicht erst seit ein paar Wochen.

Beschädigter Dongle und LDS im Reparaturmodus

Vor ein paar Tagen hatte ich das Vergnügen, unseren Lizenz-Dongle auszutauschen.

Danach muss man das LDS vorläufig reparieren; damit werden alle zuvor vorhandenen Lizenzen auf den "neuen" Dongle umgeschrieben. Diese vorläufigen Lizenzen sind dann 10 Tage lang nutzbar.
Dauerhaft aktiviert werden die Lizenzen durch einen Aktivierungs-Key, den man von Heidelberg erhält.

So weit, so gut.
Dieser "vorläufig repariert"-Status des LDS soll dafür sorgen, dass man im Notfall nicht einen Totalausfall hat, sondern normal weiter arbeiten kann, bis man entsprechende Hilfe von Heidelberg erhalten hat. Dafür sind die 10 Tage auch recht großzügig bemessen, denn bisher hat Heidelberg auf diese Art von Problemen mit Reaktionszeiten deutlich unter 4 Stunden reagiert.

Das komplette Prinect-System, die MetaDimension und die PDF Toolbox laufen auch einwandfrei mit einem LDS im Reparaturmodus. Man bekommt zwar beim Starten jeweils einen Hinweis auf die noch verfügbare Restzeit, bis man einen gültigen Aktivierungs-Key eingeben muss - aber es funktioniert.

Mit ein paar Ausnahmen ;)

Die Prinect-Engines AutoSheet, AutoPage und Messenger liessen sich partout (auch mit Hilfe von Heidelberg-Technikern) nicht zur Mitarbeit überreden.

Auch die Color Toolbox weigerte sich - hier ein Screenshot des License Managers mit gültigen Lizenzen für die Color Toolbox 12:

Direkt nach dem Start der CT12 bekam ich folgenden Dialog zu sehen:

Feine Sache, danke für die Erinnerungsmeldung. Wenige Sekunden später allerdings ...

Und Tatsache, CT12 läuft im Demo-Modus und ein Arbeiten damit ist nicht möglich.

2 Stunden später traf dann der Aktivierungs-Key ein. Mit nun wieder "vollen" Lizenzen liefen alle Prinect-Engines und die CT wieder einwandfrei, ohne sonst irgendetwas getan zu haben.

Ein LDS im Reparaturmodus ist eine unangenehme Sache. Im Prinzip funktioniert das Sicherheitsnetz ja, man kann weiterarbeiten. Es muss nur noch nachgebessert werden, dass das auch alle Softwarebestandteile genau so sehen. Praktisch alles funktionierte ja, aber während eines Notfalls sind es genau die Bestandteile, die man dann dringend benötigt, die so eine kleine "Macke" aufweisen.

Trotzdem war es eine angenehme Erfahrung, dass selbst im Falle eines Falles der Großteil des Prinect-Systems weiterhin lauffähig bleibt. Noch viel wohler würde man sich allerdings fühlen, wenn man nicht von einem Dongle abhängig ist - im Zweifelsfall ist ein Ersatzdongle zu lange unterwegs. Man kennt ja Murphys Law.