Outlook 2013 / Signaturbild wird nicht mitgeschickt (broken icon)

Den ersten tolle FeatureBug im Office 2013 Paket habe ich nun auch gefunden… leider!

microsoft-office-2013-logo

Die letzten beiden Tage war ich beschäftigt mit Rollout Tests für Blackberry10 und Office 2013… 
Das Ergebnis lässt sich schnell zusammenfassen: „Katastrophe!“

Hier möchte ich aber nur auf die Probleme mit Office 2013 eingehen.
Wenn ich mich vom Blackberry Schreck erholt habe, schreibe ich vielleicht auch da noch etwas zu.

 

Je nach Umgebung muss man sich im Vorfeld des Office2013 Rollout ein wenig Gedanken machen, welche Version man einsetzten möchte. 
Im Grunde kann man sagen, dass wenn man viele Third Party Addin’s (CTI oder ähnliches) benutzt sollte man unbedingt auf die 32Bit Variante zurückgreifen… so unter uns gesagt: „Der Sinn einer 64Bit Office Anwendung hat sich mir noch nicht ganz erschlossen. Bei einer Software wie Adobe Photoshop mag das ja Sinn machen, aber bei Office?!“

Ich möchte nun aber nicht auf die diversen Probleme mit Third Party Addin’s und Änderungen am Design von Office2013 eingehen, sondern, wie die Überschrift schon sagt auf das Problem, welches ich durch Zufall gefunden habe.

Signaturbilder werden nicht mitgeschickt und der Empfänger sieht nur ein „broken icon“

 Wenn man die HTML Signatur so wie wir in einer externen Anwendung erzeugt hat und die erzeugten Signaturen (html, txt und rtf) anschließend in den Signaturordner von Office verschiebt gibt es ab Office 2013 das Problem, dass der Empfänger nur ein „broken icon“ zu sehen bekommt, sofern man ein Bild in die Signatur einbindet. Man darf sich nicht davon täuschen lassen, dass die E-Mail die man erzeugt korrekt aussieht!

Die wie oben beschrieben erzeugten Signaturen nutzen wir schon seit Office 2003 und das sehr erfolgreich! Es gab noch nie Probleme damit… bis Office 2013.
Denn Microsoft hat mal wieder ein tolles Feature implementiert, über das sich freuen und zugleich streiten lässt.

In Outlook 2013 wurde eine Änderung der Standardeinstellungen für den Umgang mit verknüpften Bildern eingearbeitet. In früheren Versionen von Outlook, wurden die verknüpften Bilder beim Senden einer E-Mail direkt eingebettet. In Outlook 2013 werden die verknüpfte Bilder NUR verlinkt!

Bei den HTML Signaturen ist es aber so, dass diese die Bilddatei nicht beinhalten, sondern werden im HTML Code auf eine lokale Datei referenziert (verlinkt). Durch die Änderung in Office2013 wird also das Bild nicht mehr „embedded“ sondern nur noch verlinkt. Da der Empfänger das Bild aber gar nicht hat wird ein „broken icon“ angezeigt.

Dieses Problem tritt aber nur dann auf, wenn man die Signaturen mit einem externen Programm erzeugt. Nutzt man den Signatureditor im Outlook tritt das Problem nicht auf.

Registry EditorDie Lösung ist mal wieder ein reg-Eintrag…

Durch einen Registry Key kann man es schaffen, dass der altbekannte Zustand (Die Bilder werden immer eingebettet) aus Outlook 2010 wieder hergestellt wird. Dazu musst folgender Key Angelegt werden:

HKEY_CURRENT_USERSoftwareMicrosoftOffice15.0OutlookOptionsMail

Werttyp: REG_DWORD
Wertname: Send Pictures With Document
Wert: 1

Hinweis: Achtet darauf, dass der Wertname inkl. der Leerstellen geschrieben wird!

Eine weitere Lösung möchte ich nur andeuten… Es wäre auch möglich, das Signaturbild den Empfängern zur Verfügung zu stellen, indem man dies zum Beispiel online auf einem WebServer ablegt und in der Signatur dies dann verlinkt. Der Nachteil liegt aber ganz klar auf der Hand, da das Bild erst durch aktives Nachladen des Empfängers angezeigt wird.

Windows Server 2008 R2 mit x86 Druckertreibern

Es war mal wieder an der Zeit, dass ein aktueller PrintServer her musste. Da mittlerweile fast alles auf 64Bit umgestellt ist, lag die Lösung nahe einen Windows Server 2008 R2 zu nehmen und für die wenigen Clients, die noch ein 32Bit Betriebssystem haben die Treiber mit zu installieren. Bei HP Druckern war das alles kein Problem. Auf dem PrintServer schlummern nur die HP Universaltreiber PCL6 32 & 64Bit. Die Clients laufen ohne Fehler und alles ist schön performant.

Totaler Murks allerdings, wenn man keine HP Druckertreiber installieren möchte. So z.B. knallt der Kyocera Universal 32&64 Bit Treiber immer auf den Hammer mit der Meldung doch bitte das Geeignete Windows Medium einzulegen.
Tja, da Windows Server 2008 R2 aber keine 32 Bit Version hat, wird es etwas schwieriger…

Abhilfe schafft leider nur eins. Man muss ne Windows 7 32 Bit Installation irgendwo haben…

Workaround:

  1. Man gehe auf dem PrintServer zu „Start/Geräte und Drucker“
  2. Rechtsklick auf den dummen Drucker, welcher die 32Bit Installation verweigert und „Druckereigenschaften“ auswählen
  3. Anschließend auf den Reiter „Freigabe“ klicken und unten rechts auf „Zusätzliche Treiber“
  4. Nun setzt bei dem neuen Fenster den Haken bei x86
  5. Anschließend öffnet sich das allen bekannte Fenster „Treiber hinzufügen“. Sucht nach der ini für den 32Bit Treiber und wählt diese aus.
  6. Nun sollte folgende Fehlermeldung auftreten:
    Problem mit der ntprint für x86 (32bit) Treiber
  7. Nun sollte man mal nach der ntprint_ Datei suchen, die man aber dank der 64bit Architektur des Win2008 R2 Servers nicht findet 🙂
  8. Abhilfe schafft ein Win7 Client mit 32bit Architektur. Geht auf dem Win7 Client in de Ordner „C:WindowsSystem32DriverStoreFileRepository“
  9. Kopiert den kompletten Ordner „ntprint.inf_x86_neutral_XXXXXXXXXXXXX“ auf eine Partition die der Printserver erreichen kann.
  10. Bei Punkt 7 in dieser Liste navigiert zu dem kopierten Verzeichnis.

Das sollte es gewesen sein!

 

Langsames abarbeiten von Druckaufträgen bei zu viel protokollierten Einträgen

Manchmal kommt es vor, dass man sich das Druckerprotokoll doch ein wenig anschauen muss, um zum Beispiel herauszufinden, was denn überhaupt gedruckt wird und was eventuell Probleme bereitet…

 

Dafür ist es immer recht sinnvoll, in den Drucker- Eigenschaften des betroffenen Druckers unter dem TAB Erweitert den Haken bei „Druckaufträge nach dem Drucken nicht löschen“ zu setzten.

 

 

Vergisst man das aber wieder auszustellen, kann es schon einmal vorkommen, dass nach 1-2 Tagen das Protokoll bei ein paar Hundert oder Tausend Einträgen steht. Das Problem an der ganzen Geschichte ist, sobald das Protokoll etwas voller ist, können die neu ankommenden Druckaufträge nicht mehr so schnell verarbeitet werden.

Löscht man das Protokoll, gehen die Druckaufträge wieder schneller durch… ein schöner Bug, welcher einen doch recht gut nach der Ursache suchen lässt 🙂

MSSQL 2005 Bug beim Umbenennen eines Users oder Logins

Wenn man versehentlicher Weise mal einen User im Active Directory angelegt hat, wo der Name und der Anmeldename nicht ganz stimmt aber zudem schon alles in den restlichen Bereichen, wie CTI, Exchange, MS SQL usw. angelegt hat, dann „Prost Mahlzeit“ beim Umbenennen. Normalerweise gehe ich dann immer so vor, dass ich den User komplett überall herauslösche (AD, MSSQL, Exchange usw.) und anschließend einen neuen User erstelle… Warum ich das in diesem Fall nicht gemacht habe kann ich leider auch nicht mehr sagen… ich werde in Zukunft aber bei der sicheren LÖSCH-Variante bleiben :-).

Nun gut… nachdem ich also den User komplett umbenannt hatte und auch der Meinung war alle Stellen erwischt zu haben, stellte sich heraus, dass es beim Login in Microsoft Dynamics NAV (Basis ist ein SQL-Server 2005 SP2) Probleme gab. Der Login war immer noch der alte Benutzername, obwohl dieser im Management Studio schon aktualisiert wurde.

Ewiges Umbenennen und neu anlegen half nicht. Angezeigt wurde er mir bei der Suche im AD über den SQL richtig, klickt man aber auf OK, legte er den SQL-Login immer mit dem falschen Anmeldenamen an… Meine Herren!
Wie sich herausstellte, ist das ein Bug in der 2005er Version des Microsoft SQL Servers. 

 

Ab SQL Server 2005 SP2 gibt es einen Workaround:

Problembeschreibung:

The problem will be when trying to access/manipulate metadata since SQL Server will use the metadata (MD) copy of the NetBIOS name (i.e. the old name) and we won’t be able to identify the new name.

The root cause for this problem is the fact that SQL Server keeps a copy of the Windows NetBIOS user name in MD and we use this MD copy whenever a name-based operation on the user is made instead

of relying exclusively on the SID. 

This is a well known limitation of SQL Server and it has been there since Windows authentication was introduced (SQL Server 7 if I do remember). In SQL Server 2005 SP2 we introduced a mechanism that

allows you to rename the login and user to match the updated Windows name:

 

ALTER LOGIN [Old_Windows_name] WITH NAME = [New_Windows_name]
ALTER USER [Old_Windows_name] WITH NAME = [New_Windows_name]

 

As long as the SID in MD for [Old_Windows_name] matches the SID for [New_Windows_name], this operation should succeed and properly rename the principal login/user name in MD. For more information please refer to BOL:

http://msdn.microsoft.com/en-us/library/ms189828.aspx
http://msdn.microsoft.com/en-us/library/ms176060.aspx

 

Nachdem ich die oben beschriebenen Schritte vollzogen hatte, funktionierte der Login mit dem umbenannten User wunderbar…

Zwei Stunden später stand der User mit dem alten Loginnamen wieder in der SQL… WTH!
Ich glaube dies ist aber dem NAV zuzurechnen, da dieser auch komischerweise seine Logins mit dem SQL synchronisiert und dort scheinbar immer noch bei der alten SID den alten Loginnamen stehen hatte…

Fazit: An einem ruhigen Abend erst mal die Löschvariante vollzogen und nach 1,5 Stunden war der User komplett neu und sauber angelegt … in allen Applikationen.