Microsoft Outlook, sowie auch Microsoft Exchange haben die schlechte Angewohnheit unter bestimmten Umständen anstatt einem regulären Dateianhang eine so genannte TNEF-codierte winmail.dat Datei anzuhängen, in der dann die eigentlichen Dateianhänge, Nachrichten, etc. enthalten sind.

Geht die E-Mail von Outlook zu Outlook, bekommt der Benutzer das im Normalfall niemals mit, für den Empfänger sieht die E-Mail und auch all ihre Dateianhänge ganz normal aus.

Aber wehe, die E-Mail geht an Empfänger anderer E-Mail Clients, wie Lotus Notes, TheBat!, etc. Hier kommt es regelmäßig vor, dass derjenige dann nur eine winmail.dat bekommt, mit der er dann recht wenig anfangen kann.

Ich habe vor kurzem ein nützliches Tool im Internet gefunden, welches genau bei dieser Problematik hilft - den Winmail Opener. Das kostenfreie Programm ermöglicht es, die
winmail.dat zu öffnen, deren Inhalte zu sichten und im Bedarfsfall auch abzuspeichern
(ähnlich wie ein Dateiarchiv).

Winmail Opener: Geöffnete winmail.dat

Das Programm lässt sich auch als Standard-Programm für alle .dat-Erweiterungen einstellen
(sofern man über ausreichende Rechte auf dem Windows-Rechner verfügt):

Winmail Opener: Als Standard einstellen

Dies hat den Vorteil, dass man dann direkt per Doppelklick auf eine solche winmail.dat sofort in dem Program landet und sich die Dateianhänge ansehen und ggf. woanders hin speichern kann.

Mehr zu dem Thema winmail.dat, und wie man es Outlook unter bestimmten Umständen auch ganz austreiben kann, solche Dateien überhaupt zu versenden, unter folgenden externen Blogs:

• How to Prevent Winmail.dat Attachments from Being Sent in Outlook
• Outlook: Winmail-Dat-Problem

Seit Anfang 2010 markiert SpamAssassin jede eingehende Mail fälschlicherweise als SPAM…
Man könnte es fast als immer wiederkehrende “Neujahresgrüße” bezeichnen, wenn es nicht so gravierend wäre und Systeme weltweit betreffen würde. Selbst große E-Mail-Dienstanbieter wie 1&1 und GMX waren davon beeinträchtigt…

Schuld daran ist eine veraltete Standard-Regel in der Datei /usr/share/spamassassin/72_active.cf:

header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006]

Damit wird jede E-Mail ab dem 01.01.2010 als “grob fahrlässig aus der Zukunft” gewertet und als [*****SPAM*****] eingestuft:

pts rule name            description
--- -------------------- ----------------------------------
3.2 FH_DATE_PAST_20XX    The date is grossly in the future.

Das Problem scheint schon seit längerem bekannt zu sein und wurde wohl auch bereits am 21.Jul.2009 korrigiert, wie man hier nachlesen kann.

Nur dass scheinbar vergessen wurde, dass Problembeseitigung nicht das Ende vom Lied ist. Man muss auch sicherzustellen, dass alle bereits auf der Welt laufenden Server diese verbesserte Regel in einer automatisierten Form erhalten können.

Eigentlich existiert eine Automatik dafür, mittels sa-update lassen sich geänderte Regeln abgleichen. Aber die Regel scheint (bisher) leider nicht wichtig genug zu sein, als dass sie in aktualisierter Form in diesen Updates eingeschlossen wird.
 

Daher folgende 2 manuelle Lösungsmöglichkeiten:

1. Man ändere die Regel in der /usr/share/spamassassin/72_active.cf auf:

   header FH_DATE_PAST_20XX Date =~ /20[2-9][0-9]/ [if-unset: 2006]

   Damit hat man den offiziellen Stand eingespielt, welcher das Problem aber eigentlich auch nur wieder verschiebt, nämlich auf den 01.01.2020, denn dann greift die neue Regel wieder. Ich schätze, die Entwickler haben sich wohl gedacht “so können wir das erst mal aufschieben, und wie überlegen uns dann später, wie wir das Problem programmiertechnisch lösen, in dem wir z.B. das tatsächliche Datum mit einbeziehen…”
   Allerdings gibt es bei dieser Lösungsvariante (zumindest zum Zeitpunkt dieses BLOG-Eintrages) noch die Problematik, dass die Regel über sa-update wieder auf den alten Stand zurückgesetzt wird.
2. Oder man ergänze folgenden Zusatzeintrag in der /etc/spamassassin/local.cf Datei:

   score FH_DATE_PAST_20XX 0.0

   Damit wird diese Regel komplett ignoriert, unabhängig davon, wie diese in Zukunft auch aussehen mag.

Man fragt sich, was in der Softwareentwicklung als nächstes kommt. Zuerst die große Panik um Y2k (Jahr 2000), jetzt 2010… Wahrscheinlich weiß nur Murphy wirklich, wo das alles endet

Es hat Spaß gemacht, mit Torsten Borth an einem Schlüsselprojekt rund ums ERP zu arbeiten. Engagiert konstruktives Mitdenken und umsetzen - bei hoher Fachkompetenz zu jeder Zeit.
Kurz: Gerne wieder :-) 

 

Wolfgang Weigelt
Manager I.T., Applications
Tupperware Deutschland GmbH

Projektart: Mitentwicklung eines neuen Client/Server-basierten Anwendungsframeworks & ERP-Systems.

Agentur: runtime Software GmbH, Waiblingen

Technologien: .NET 3.5 SP1, C#, VB .NET, Microsoft Smart Client Software Factory (SCSF), Model/View-Presenter (MVP), MSSQL Server 2005/2008,
ADO .NET Entity Framework, LINQ

Angefangen hat es mit meinem in die Tage gekommen Laptop mit Vista, dieser ist teilweise nach 5-10 Minuten wieder aus den Energiesparmodus aufgewacht. Das ist natürlich beim Transport nicht so gesund, wenn das Gerät in der Tasche angeht. Also war jedes mal vor dem Transport langwieriges Herunterfahren und danach noch langwierigenderes Booten notwendig. Nun hab ich allerdings das gleiche Problem bei meinem neuen Laptop mit Windows 7.

Hier ein paar Tipps wie man das Problem beseitigen kann.

Wonach man zuerst schauen sollte ist die Ereignisanzeige.

Unter dem Punkt Windows-Protokolle/System am besten nach Power-Troubleshooter filtern.

Hier findet man Informationen was den Rechner einschaltet hat.

Ist es ein Gerät kann man die Funktion Das Gerät kann den Computer aus dem Ruhezustand aktivieren im Gerätemanager oder mit Powercfg deaktivieren.

Oft wird allerdings nur RTC oder unbekannt angzeigt.

In diesem Fall können wir und in der Console mit dem Befehl Powercfg helfen.

powercfg -lastwake zeigt Informationen zum letzten Aufwachen an.

powercfg -DEVICEQUERY wake_armed zeigt alle Geräte an die den Computer aus dem Energiesparmodus aufwecken können.

powercfg -DEVICEDISABLEWAKE <Gerätename> entzieht dem Gerät das Recht den Computer aus dem Ruhezustand aufzuwecken.

Hat man die Funktion bei allen Geräten deaktiviert sollte  das Problem in den meisten Fällen behoben sein.

Ist das nicht der Fall gibt es noch die Möglichkeit das Aufwachen per Registry-Eintrag zu deaktivieren.

Unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\238C9FA8-0AAD-41ED-83F4-97BE242C8F20\BD3B718A-0680-4D9D-8AB2-E1D2B4AC806D

und allen Unterordnern gilt es alle Einträge von 1 auf 0 umzustellen.

Dadurch wird die Wake-On-Timer Funktion komplett deaktiviert.

Das bedeutet allerdings auch kein Task mehr in der Aufgabenplanung, wie z.B. die Mediacenter recording Funktion, kann den PC aus dem Energiesparmodus aufwecken.

Allerdings sollte man an dieser Stelle sein System doch mal gründlich nach Trojaner untersuchen, denn es existieren einige die sich diese Funktion zunutze machen um den PC erreichbar zu halten.

Quellen: Microsoft Microsoft Technet

Die Funktion Business Application Monitoring Alerts (BAM Alerts) funktionieren in BizTalk 2009 auch mit dem Microsoft SQL Server 2008. Es wird keine SQL Server 2005 Instanz mehr benötigt. Das ist im offiziellen Installation Guide von Microsoft nachzulesen.

Man braucht dazu folgende Komponenten (in diesem Beispiel für die x64 Plattform):

1. Microsoft SQL Server Native Client
   sqlncli_x64.msi
2. Microsoft SQL Server 2005 Management Objects Collection
   SQLServer2005_XMO_x64.msi
3. Microsoft SQL Server 2005 Notification Services Client Components
   SQLServer2005_NS_x64.msi

Ich habe also diese drei Komponenten nacheinander installiert, was anstandslos funktionierte. Anschließend habe ich den Microsoft SQL Server 2008 aufgesetzt, gefolgt vom SQL Server 2008 Service Pack 1.

Als ich dann schließlich im BizTalk Server 2009 Configuration Wizard die BAM Tools mit aktivierten BAM Alerts konfigurieren wollte, bekam ich am Ende folgende Fehlermeldung:

BizTalk 2009 Configuration Wizard - BAM Tools Failed

Per Doppelklick auf die Zeile BAM Tools Failed zeigte sich folgende Detailfehlerseite:

BizTalk Server 2009 Configuration Wizard - BAM Tools Fehler

Es fehlte also eine DLL: Could not load file or assembly ‘Microsoft.SqlServer.Smo, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91′ or one of its dependencies. The system cannot find the file specified.

Und genau diese DLL, hatte ich kurz zuvor (über Punkt 2 | SQLServer2005_XMO_x64.msi) installiert gehabt. Ich dachte mir dann, ok dann installierst du diese Komponente eben erneut. Aber das ging leider nicht. Das Setup der Komponente versagte den Dienst mit der Meldung, dass die Management Objects Collection bereits in einer neueren Version installiert sei und man die 2005er Version (die der BizTalk Server aber explizit benötigt) daher nicht installieren könne. In der Systemsteuerung / Programme und Funktionen gab es sogar einen Eintrag namens SQL Server 2008 Management Objects Collection, aber selbst eine Deinstallation dieser Komponente half nicht. Die 2005er Version ließ sich nicht installieren.

Auch Versuche anstatt der 2005er Version aus dem Installation Guide (welche sich nicht installieren ließ) die allerneuste Version aus dem SQL Server 2008 Feature Pack (April 2009) zu verwenden schlugen an der selben Stelle im BizTalk Wizard fehl. Der Wizard möchte unbedingt diese eine spezielle Version haben…

Nach einigem Probieren und zurückgehen in frühere Backups/Snapshots habe ich dann schließlich eine Lösung gefunden: Wichtig ist die Installationsreihenfolge.

Man darf nicht zuerst diese 3 Komponenten installieren und anschließend SQL Server 2008 plus SP1. Denn hier kommt es wohl zu dem Problem, dass die Management Objects Collection 2005 im Zuge der 2008er Installation bzw. des SP1 entfernt/aktualisiert wird. Und mit den 2008er Komponenten kann BizTalk nichts anfangen.

Was aber funktioniert:

1. Zuerst SQL Server 2008 installieren
2. Dann das SP1 des SQL Server 2008 installieren
3. Und erst dann die drei 2005er Komponenten nacheinander installieren

Dann läuft auch der BizTalk Server 2009 Configuration Wizard bei der Installation der BAM Tools mit aktivierten Alerts ordnungsgemäß durch

Will man sowohl Microsoft Office SharePoint 2007, als auch BizTalk Server 2009 auf dem gleichen Rechner (und somit IIS betreiben) gibt es hier eine Besonderheit. Das BizTalk Business Application Monitoring (BAM) Portal lässt sich bei der initialen Konfiguration nur einrichten, wenn der IIS ApplicationPool im 32Bit-Modus betrieben wird.

Andererseits funktioniert SharePoint x64 aber nur, wenn der IIS ApplicationPool im 64Bit-Modus läuft.
Was tun?

Es gibt einen Trick:

1. Man stelle vor der Konfiguration über den SharePoint Products and Technologies Configuration Wizard den IIS ApplicationPool auf 32Bit um:
   cscript %SystemDrive%\inetpub\AdminScripts\adsutil.vbs set w3svc/AppPools/Enable32bitAppOnWin64 1
2. Dann läuft der Wizard durch. Wichtig zu beachten ist, dass man nicht in einem Schritt SharePoint Integration und BAM Portal konfiguriert. Denn die SharePoint Site, die man zwingenderweise zur Integration auswählen muss, ist natürlich jetzt solange “nicht erreichbar”, da wir im 32Bit-Modus arbeiten. Also auf keinen Custom Installation, nicht Standard.
3. Und anschließend stelle man es wieder auf 64Bit um. Denn, das BAM Portal wird vom Setup bereits automatisch mit einem separaten ApplicationPool eingerichtet, welcher schon die 32Bit-Eigenschaft hat.
   cscript %SystemDrive%\inetpub\AdminScripts\adsutil.vbs set w3svc/AppPools/Enable32bitAppOnWin64 0
4. Möchte man jetzt noch die SharePoint Integration nutzen, führt man den Wizard erneut aus und konfiguriert dann die noch fehlende Komponente. Jetzt, da der IIS wieder im 64Bit ApplicationPool läuft, lassen sich auch die SharePoint Sites auswählen.

Geht man so vor, hat man einen 64Bit-IIS, der nur für das BAM Portal noch 32Bit nutzt.

Sie haben Microsoft Office SharePoint Server 2007 SP2 x64 neu installiert, den SharePoint Products and Technologies Wizard durchlaufen und es öffnet sich nun der Browser mit der URL der Central Administration. Sie geben Ihren Benutzernamen und das Kennwort ein und es passiert…
…nichts.

Eine mögliche Ursache ist, dass Ihr IIS ApplicationPool im 32Bit-Modus läuft.

Sie können das über die Kommandozeile (Run as Administrator!) über folgenden Befehl überprüfen:

cscript %SystemDrive%\inetpub\AdminScripts\adsutil.vbs get w3svc/AppPools/Enable32bitAppOnWin64

Wenn die Ausgabe hier Enable32bitAppOnWin64: (BOOLEAN) True ist, ist das die Ursache.

Um auf 64Bit-Modus umzustellen nehmen Sie folgendes Kommando:
cscript %SystemDrive%\inetpub\AdminScripts\adsutil.vbs set w3svc/AppPools/Enable32bitAppOnWin64 0

Dann sollte die Central Administration Site wieder angezeigt werden, und Sie können mit Ihrer Konfiguration fortfahren.

Windows Server 2008 R2 unterstützt nur die Installation der allerneuesten Version der Office SharePoint Server 2007 SP2 (Details in diesem Beitrag).

Daher sollte man bei der Installation von Language Packs ebenfalls das neueste Service Pack direkt mit slipstreamen um gleich den neuesten Stand zu installieren.

Hierzu geht man folgendermaßen vor. Man lädt zuerst folgende Dateien herunter (in diesem Beispiel das deutsche Sprachpaket für x64):

1. Windows SharePoint Services 3.0 Language Pack x64
   SharePointLanguagePack.exe
2. Windows SharePoint Services 3.0 Language Pack Service Pack 2 (SP2), 64-Bit Edition
   wssv3lpsp2-kb953338-x64-fullfile-de-de.exe
3. SharePoint Server 2007 Language Pack (x64)
   ServerLanguagePack.img
4. 2007 Microsoft Office Servers Language Pack Service Pack 2 (SP2), 64-Bit Edition
   officeserverlp2007sp2-kb953334-x64-fullfile-de-de.exe

Anschließend werden alle Installationspakete auf dem eigenen Dateisystem entpackt. Das Image ServerLanguagePack.img muss man leider manuell entpacken (z.B. in WinRAR öffnen und in den Ordner to c:\mosslp extrahieren). Danach die restlichen Dateien direkt über die Kommandozeile entpacken:

• SharePointLanguagePack.exe /extract:c:\wsslp
• wssv3lpsp2-kb953338-x64-fullfile-de-de.exe /extract:c:\wsslp\updates
• officeserverlp2007sp2-kb953334-x64-fullfile-de-de.exe /extract:c:\mosslp\updates

Jetzt hat man zwei Slipstreamed Installer, welcher bereits SP2 beinhalten und sich problemlos auch unter Windows Server 2008 R2 installieren lassen.

Abschließend die Sprachpaket-Installer über c:\wsslp\setup.exe und c:\mosslp\setup.exe ausführen.

Man kann das hier gezeigte Verfahren des Slipstreaming aber natürlich auch auf x86 oder anderssprachige Language Packs anwenden. Man lädt dann lediglich die dazu passenden Dateien herunter.

Verwendet man den Dataset-Designer in VisualStudio um typisierte Datasets zu erzeugen, kann es beim Deployen ein böse Überraschung geben, nämlich dann wenn der Datenbankname geändert werden muss.

Der Designer erzeugt teilweise Querys nach vollgender Syntax:

SELECT `ID`,`Name` from `databaseName`.`Customers`;

Wie man sieht ist der Datenbankname mit in der Query integriert.
Ein ändern des Datenbanknamens im ConnectionString hat somit keine Wirkung auf diese Querys.

Es ist möglich die xsd Datei per Hand durchzugehen und den Datenbanknamen zu entfernen, dass muss allerdings nach jeder Änderung am Dataset erneut gemacht werden.

Leider gibt es dafür noch kein Fix dafür von MySQL obwohl der Bug schon lange bekannt ist.

Die Installation wurde aber mit folgender Fehlermeldung verwehrt:

Server 2008 R2: SharePoint 2007 Installationsversuch

Auch der neuste SharePoint 2007 Installer mit integriertem SP1 versagte den Dienst mit der Fehlermeldung This Program is blocked due to compatibility issues. (deutsch: Dieses Programm wurde auf Grund von Kompatibilitätsproblemen gestoppt.) Es stellt sich heraus, dass unter 2008 R2 die Installation nur mit dem neuesten SharePoint 2007 SP2 möglich ist. Microsoft stellt aber bis dato keine ISO mit integriertem SP2 zur Verfügung…

Es gibt aber die Möglichkeit, sich selbst eine solche Installation mit integriertem SP2 zu erstellen.

Die aktuellen Installer haben ein Verzeichnis namens Updates, in welches man Patches und Service Packs kopieren kann. Bei der Installation werden dann sowohl das ursprüngliche Setup, als auch die beigefügten Updates sofort mit installiert (so genanntes Slipstreaming).

Hierzu geht man folgendermaßen vor. Man lädt zuerst folgende Dateien herunter:

1. Microsoft Office SharePoint Server 2007 Trial Version
   OfficeServer.exe (Hier bitte die Version ohne integriertes SP1 herunterzuladen, da wir selbst ein neueres Service Pack integrieren wollen).
   Nicht von “Trial” abschrecken lassen. Es handelt sich 1:1 um die Version, die auch über MSDN oder VolumeLicensing in ISOs verfügbar ist, man muss bei der Installation nur den gültigen Lizenz-Key eintragen und es wird eine Vollversion installiert.
2. Windows SharePoint Services 3.0 Service Pack 2 (SP2)
   wssv3sp2-kb953338-x64-fullfile-en-us.exe
3. The 2007 Microsoft Office Servers Service Pack 2 (SP2)
   officeserver2007sp2-kb953334-x64-fullfile-en-us.exe

Anschließend werden alle Installationspakete auf dem eigenen Dateisystem entpackt.
Hierzu folgende Befehle aus der Kommandozeile ausführen:

• OfficeServer.exe /extract:c:\sp2slipstream
• wssv3sp2-kb953338-x64-fullfile-en-us.exe /extract:c:\sp2slipstream\updates
• officeserver2007sp2-kb953334-x64-fullfile-en-us.exe /extract:c:\sp2slipstream\updates

Als letztes muss noch die Datei c:\SP2Slipstream\Updates\wsssetup.dll manuell gelöscht werden, da eines der Updates bereits die svrsetup.dll mitliefert und nicht beide DLLs im Update-Ordner unterstützt werden.

Jetzt hat man auf c:\SP2Slipstream\setup.exe einen Office SharePoint 2007 SP2 Slipstreamed Installer, welcher sich problemlos auf Windows Server 2008 R2 installieren lässt:

Server 2008 R2: SharePoint 2007 Installation

Ich habe in diesem Falle die x64 Version verwendet, da ich das für den aktuell sinnvollsten Weg halte. Auch nutze ich stets englische Versionen, wenn es um Server geht. Englische Fehlermeldungen sind konkret und verständlich und man findet dazu auch wesentlich mehr Informationen im Internet, als über lokalisierte Fehlermeldungen, die oftmals sogar im Sinn entfremdet sind (Lost In Translation). Mehrsprachigkeit lässt sich im Bedarfsfall meist sowieso nachrüsten (Details in diesem Beitrag), daher spricht nichts mehr gegen einen englischen Kern…

Man kann das hier gezeigte Verfahren des Slipstreaming aber natürlich auch auf x86 oder anderssprachige Installationen anwenden. Man lädt dann lediglich die dazu passenden Dateien herunter (z.B. die SharePoint 2007 Trial x86, etc.)

Noch ein Tipp am Rande: Es empfiehlt sich, am Ende des Setup nicht gleich den SharePoint Products and Technologies Wizard anzustarten (wie standardmäßig vorgeschlagen). Ich kann zu diesem Zeitpunkt nur empfehlen ein Backup bzw. einen Snapshot zu erstellen. Denn hier ist die SharePoint 2007 Installation noch jungfräulich (und es wurde z.B. auch noch keine SQL Server Konfiguration vorgenommen). Wenn es einen Punkt gibt, zu dem man später evtl. nochmal zurück möchte, dann ist es dieser…