Archiv der Kategorie: Microsoft 365

RootCA Updates (Office365 kann nicht aktiviert werden ERROR CODE „0xC004F017“)

Veröffentlicht am von — Keine Kommentare ↓

Weitere Suchwörter: rootca, msrootca, rootca-update, Windows CA-Store Patch, rootcapatch, windowsca, caupdate

Problem

Eine neue Office365-Installation lässt sich nicht aktivieren und es erscheint die folgende Fehlermeldung:

Es gibt ein Problem mit Ihrem Konto. Versuchen Sie es bitte später erneut.

An der Kommandozeile lässt sich die Lizenz im Lizenzaktivierungsdienst aber korrekt anzeigen. Der Fehler an der Kommandozeile für die /act-Aktivierung lautet „ERROR CODE 0xC004F017“

Lösung

Vermutlich ist der Speicher der vertrauenswürdigen Stammzertifizierungsstellen beschädigt, leer oder ein wichtiges Zertifikat fehlt. Das kann durch ein fehlerhaftes Update aus dem Jahr 2013 passiert sein (Windows7/Server2008R2). Die Lösung ist relativ simpel: Zurücksetzen des Windows Zertifikatssspeichers und hinzufügen der passenden Zertifikate. Dazu gibt es auch ein passendes Update. KEINE SORGE, bei dem Update steht „Windows XP“, das läuft aber überall und macht seinen Job …

Office365 (Office 2013 ProPlus Programme) stürzen beim starten ab

Veröffentlicht am von — 2 Kommentare ↓

Problem

Bei einem frisch installierten Windows 7 oder windows 8/8.1 System mit ebenso frisch installiertem Office365 – Office 2013, crashen die Anwendungen Word, Excel, Powerpoint un dPublisher sofort nach dem starten.

Problemsignatur
Problemereignisname:                       BEX
Anwendungsname:                            WINWORD.EXE
Anwendungsversion:                         15.0.4420.1017

die Option „Reparieren“ der Office-Installation löst das Problem nicht.

Lösung

Abby Finereader (gründlich) deinstallieren. Mehrere Versionen der Software haben Schwierigkeiten bei neu installierter Office2013 Software und mit Office2013 SP1 im allgemeinen. Leider wird Finereader wie Malware oft huckepack mit Druckertreibern, neu ausgelieferten PCs und auf ähnlichen Wegen mitgeliefert.

Office365 „winmal.dat“ (TNEF) versand abschalten

Veröffentlicht am von — 2 Kommentare ↓

Problem

Einige Empfänger berichten, das Sie anstelle des gewünschten anhanges eine Datei namens „winmail.dat“ erhalten. Das betrifft vor allem ältere E-Mail-Programme, Apple-Mail und Systeme hinter älteren Firewalls/Mailfiltern.

Lösung

Man kann dem ausgehenden Connector des Office365 Exchange Online Dienstes das versenden des Microsoft TNEF-Formates vollständig abgewöhnen. Man stellt eine Verbindung zur Office365 Powershell her und konfiguriert die Einstellung mit dem Commandlet Set-RemoteDomain.

$Cred = Get-Credential
$shell = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $cred -Authentication Basic –AllowRedirection
Import-PSSession $shell
Set-RemoteDomain Default -TNEFEnabled $false

Mit „Get-RemoteDomain |fl“ lassen sich die aktuellen Einstellungen für den Connector überprüfen. Die folgenden Einstellungen sind für den Parameter TNEFEnabled verfügbar:

  • $true: TNEF wird für alle Nachrichten verwendet
  • $false TNEF wird nie für Nachrichten verwendet
  • $null der Absender gibt die Einstellung vor (Standardeinstellung). Funktioniert TOTAL großartig, denn jeder Mensch weiss ja wie man in Outlook-Kontakten das TNEF-Format konfiguriert. </ironic mode=“off“>

Gezielt lässt sich die Einstellung für bestimmt Domains so setzen:

Set-RemoteDomain foo.bar -TNEFEnabled $false

Office365 Exchange Online POP/IMAP/SMTP Servernamen

Veröffentlicht am von — 2 Kommentare ↓

office365popimapsmtpEigentlich sind die Einstellungen für jeden Postfachnutzer unter „Optionen“ indirekt erreichbar eingetragen, aber seit Wave „blue“ habe ich bisher nur noch diese Einstellungen gesehen. Daher als kurze Notiz die Servernamen

POP3

Servername: outlook.office365.com
Port: 995
Verschlüsselungsmethode: SSL (obligatorisch)

IMAP

Servername: outlook.office365.com
Port: 993
Verschlüsselungsmethode: SSL (obligatorisch)

SMTP

Servername: smtp.office365.com
Port: 587
Verschlüsselungsmethode: TLS (obligatorisch)

Achtung, die Cryptobibliotheken unter Windows Server 2003 unterstützen die geforderte Mindestschlüssellänge und Hash noch noch nicht (2048bit/SHA1). Sowohl Client- als auch Serververbindungen (IIS-SMTP-Relay, ActFax, OutlookExpress …) funktionieren hier nicht. Laut Microsoft wird das auch nicht mehr unterstützt werden.

Scanner senden keine E-Mails über Windows IIS-SMTP-Relay (Logfile: „BDAT“)

Veröffentlicht am von — Keine Kommentare ↓

Problem

windows-iis-smtp-log-BDATEin Flur-Scanner (wir nennen diese Dinger intern gerne „Raumschiff“) versendet „auf einmal“ keine (größeren) Dokumente mehr per E-Mail. Kleine Dokumente funktionieren fehlerfrei – die Meldung am Display des Gerätes dazu lautet „Die Festplatte des Servers ist voll“. Es wird über ein Windows IIS-SMTP-Relay an Office365 gemailt. Der Fehler tritt bei Geräten von Develop (Beispiel ineo+ 220) auf, andere Geräte verschicken mit der Meldung „Message size too big“ überhaupt nichts. Der Server hat selbstverständlich ausreichend Platz.

Lösung

Der Scanner versendet keine größen eingescannten Dokumente mehr, weil die Nachrichtengröße überschritten ist und der Scanner zu dem erweiterten SMTP-Befehl BDAT wechselt. Das funktioniert so nicht richtig, weil die IIS-Metabase zwar die verwendung von BDAT zulässt, die Verbindung aber (ohne Fehlermeldung) beim erreichen der maximalen Nachrichtengröße beendet. Das sieht man sehr schnell und eindrucksvoll in den zugehörigen IIS SMTP LogFiles (\inetpub\LogFiles\SMTPSVC*). Anstell des DATA-Commands folgt da ein auf den ersten blick verwirrender Stapel Binärdaten. Dieser Stapel bricht irgendwann kommentarlos ab.

Zwei Möglichkeiten zur Fehlerbehebung:

  1. Maximal Nachrichtengröße erhöhen (IIS 6.0 Manager > SMTP Virtual Server > Eigenschaften > Nachrichten > „Nachrichtengröße beschränken“ anpassen
  2. In der IIS6 Metabase den SmtpInboundCommandSupportOptions Integer anpassen (/LM/SmtpSvc/<id>/) um das BDAT-Verb zu verbieten.

iis6-smtp-metabase-explorer