Montag, 16. September 2013

Lancom Access Points AP verlieren nach einem Jahr den Zugriff / Zugang / Kontakt zum WLAN Controller WLC (VPN, SCEP, CA, Zertifikat) Problem verliert Probleme

Als Lancom Gold Partner (Solution Partner) haben wir bei einigen Kunden festgestellt, dass in einem WLC-Umfeld (allerdings sehr selten) die Access Points nach genau einem Jahr Laufzeit keine Verbindung mehr zum WLC-Controller (egal ob als eigener WLAN-Controller oder als WLC-Option) aufbauen können. Die Access Points können mit LANconfig gefunden werden, holen sich aber die WLAN-Konfiguration nicht und sind über WLAN nicht ansprechbar. Das betrifft dann alle im Einsatz befindlichen Access Points.

Wenn ein Trace (auf dem WLC) mit LANconfig durchgeführt wird, gibt es Meldungen wie:

[SCEP-Client] 2013/09/15 12:32:47,484  Devicetime: 2013/09/15 12:32:47,197
SCEP-Client info: SCEPclient-Interface: isCertificateAvailable: SCEP-Client is initialised[SCEP-Client] 2013/09/15 12:32:47,484 Devicetime: 2013/09/15 12:32:47,197
SCEP-Client info: SCEPclient-Interface: isCertificateAvailable: status of device certificate is SCEP_ENROLL_REJECTED_BADREQ
[CAPWAP-CTRL] 2013/09/15 12:32:47,484 Devicetime: 2013/09/15 12:32:47,197
CEP-Client: certificate id 0 CA id 0 Request error

Schuld ist ein bisher noch nicht von Lancom diagnostizierter Fehler, der wie folgt behoben werden kann. Bitte beachten Sie, dass alle Angaben ohne Gewähr sind. Gerne helfen wir Ihnen weiter, wenn Sie uns direkt kontaktieren.

Wichtige Hinweise vorab:
  • Sichern Sie Ihre bestehende Konfiguration per LANconfig.
  • Beachten Sie, dass durch das Zurücksetzten des Zertifikat-Baumes alle vorhanden Zertifikate aus dem WLC gelöscht werden.
  • Sollten Sie Zertifikats basierende VPN-Verbindungen nutzen, führen Sie dieses HowTo nicht durch.
  • Das neue Generieren der Zertifikate durch den WLC kann einige Zeit in Anspruch nehmen. für diese Zeit besteht keine Möglichkeit sich mit dem WLAN zu verbinden.
  • Aktivieren Sie z.B. unter LANconfig die Annahme neuer APs, sowie die Vergabe des Standard-Profils (alternativ manuelle Zuweisung von Profilen per LANmonitor)
  • Schließen Sie vor dem Beginn das Offline-Konfigurationstool LANconfig.
  • Bitte öffnen Sie das Offline-Konfigurationstool LANconfig erst wieder, wenn alle Access-Points erkannt worden sind (kann im LANmonitor geprüft werden).
  • Geben Sie die Befehle in der Eingabekonsole (PUTTY, Telnet,..) genau in der gegebenen Reihenfolge ein, da ansonsten die gesamte Konfiguration gelöscht werden kann.

1) Webconfig
  • Verbinden Sie sich (auch über WAN möglich) über die Weboberfläche auf den Lancom-Router.
  • Navigieren Sie in den Verzeichnisbaum durch zu LCOS-Menübaum->Status->Dateisystem->Inhalt
  • Löschen Sie alle "scep*"-Dateien sowie die "Controller_pkcs12_int"-Datei

2) Putty, Telnet, etc.
Nun verbinden Sie sich mit Putty auf den WLC (Anmeldung mit dem Benutzer "root" und dem Lancom-Kennwort) und geben die nachfolgenden Befehle in dieser Reihenfolge ein:
  • cd Setup/Certificates/ (wechselt in das Verzeichnis)
  • default-r (setzt alle Einstellungen zurück auf DEFAULT)
  • do /Setup/Certificates/SCEP-Client/reinit (Reinitialisieren des SCEP-Clients)
  • do /Setup/Certificates/SCEP-CA/reinit (Reinitialisieren der SCEP-CA)
  • do /Setup/Certificates/CRLs/refresh-crl-now (Reinitialisieren der CRLs)

3) Kontrolle
Nun müssen Sie ein paar Minuten warten und können beobachten, wie die Access Points sich wieder die Konfiguration vom WLC holen und betriebsbereit werden. Der Router / WLC muss nicht neu gestartet werden.

Viel Spaß mit dem WLAN und Ihrem Kunden!

Donnerstag, 8. November 2012

Fehlermeldung beim Öffnen von Links aus Outlook - Vorgang wegen Beschränkungen abgebrochen- Google Chrome

Immer häufiger gibt es die Rückmeldung von Kunden, dass diese beim Öffnen von Links in einer E-Mail die Fehlermeldung
"Dieser Vorgang wurde wegen Beschränkungen auf diesem Computer abgebrochen. Bitte wenden Sie sich an Ihren Systemadministrator."
erhalten. Als zuständiger Systemadministrator gibt es dann einen Anruf bei uns :-)

Beim ersten Mal war etwas Recherche notwendig, bis ich dem Problem auf die Schliche gekommen bin: Google Chrome ist Schuld! Alle Anwender hatten in der Vergangenheit bewußt oder unbewußt Google Chrome auf dem Rechner installiert (und teilweise wieder deinstalliert). Chrome setzt sich als Standard Webbrowser ein und ändert die Zuordnungen von Links. Nach einer Deinstallation (aber auch bei manueller Änderung des Standard Browsers) werden Systemzuordnungen nicht mehr korrekt zurück gesetzt, so dass es u.a. die o.g. Fehlermeldung gibt.

Folgendes ist zu tun (Es wird keine Haftung für die folgenden Angaben übernommen):
  • Start -> Ausführen -> Regedit
  • Schlüssel HKEY_CLASSES_ROOT öffnen
Nachfolgende Schlüssel suchen und dort jeweils den Wert für "(Standard)" abändern:
  • .htm -> "(Standard)" auf "htmlfile" setzen
  • .html -> "(Standard)" auf "htmfile" setzen
  • .mdbhtml -> "(Standard)" auf "accesshtmlfile" setzen
  • .mht -> "(Standard)" auf "mhtmlfile" setzen
  • .mhtml -> "(Standard)" auf "mhtmlfile" setzen
  • .shtm -> "(Standard)" auf "htmlfile" setzen
  • .shtml -> "(Standard)" auf "htmlfile" setzen
  • .stm -> "(Standard)" auf "htmlfile" setzen
  • .htm -> "(Standard)" auf "htmlfile" setzen
  • .html -> "(Standard)" auf "htmfile" setzen
  • . mdbhtml -> "(Standard)" auf "accesshtmlfile" setzen
  • .mht -> "(Standard)" auf "mhtmlfile" setzen
  • .mhtml -> "(Standard)" auf "mhtmlfile" setzen
  • .shtm -> "(Standard)" auf "htmlfile" setzen
  • .shtml -> "(Standard)" auf "htmlfile" setzen
  • .stm -> "(Standard)" auf "htmlfile" setzen

Anbei ein Auszug aus einer Regdatei, die die betreffenden Einträge korrigiert. Einfach den Text als .reg-Datei abspeichern und per Doppelklick starten:

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.htm]
@="htmlfile"
[HKEY_CLASSES_ROOT\.html]
@="htmlfile"
[HKEY_CLASSES_ROOT\.mdbhtml]
@="accesshtmlfile"
[HKEY_CLASSES_ROOT\.mht]
@="mhtmlfile"
[HKEY_CLASSES_ROOT\.mhtml]
@="mhtmlfile"
[HKEY_CLASSES_ROOT\.shtm]
@="shtmfile"
[HKEY_CLASSES_ROOT\.shtml]
@="shtmlfile"
[HKEY_CLASSES_ROOT\.stm]
@="stmfile"

Donnerstag, 19. Juli 2012

Exchange 2007 SSL Zertifikat abgelaufen - Anleitung zum Verlängern des ausgelaufenen Zertifikats SBS2008

Hinweise
  • Der SBS2008 verhält sich anders. Bitte am Endes des Artikels die Besonderheiten lesen!
  • Die Anleitung ist mit Vorsicht zu genießen und Bedarf einer Überarbeitung. Bitte lesen Sie die Kommentare der Benutzer durch.


Jeder Jahr wieder (das selbst erstellte Zertifikat lässt sich nur um ein Jahr verlängern) kommt unverhofft die Fehlermeldung, dass das Exchange-Server Zertifikat ausgelaufen ist.

Über die Exchange Verwaltungskonsole lässt es sich jedoch problemlos verlängern.

Zunächst gilt es festzustellen, welches Zertifikat ausgelaufen ist:
get-exchangecertificate | fl thu*,notafter,services,certificatedomains
Dieser Befehl gibt komfortabel den Thumbprint, die dazugehörigen Dienste, den Domainnamen und das Datum aus, von den bisher selbst erstellen Zertifikaten.

Wenn man das betreffende Zertifikat gefunden hat, wird es wie folgt verlängert und aktiviert:
get-exchangecertificate -thumbprint "xxx" | new-exchangecertificate
Die folgende Meldung zum Überschreiben des Zertifikats muss mit "J(a)" bestätigt werden. Mit dem o.g. Befehl kann nun nachvollzogen werden, dass ein neues Zertifikat (mit neuem Thumbprint) erzeugt wurde:
get-exchangecertificate | fl thu*,notafter,services,certificatedomains
Es ist darauf zu achten, dass das Zertifikat wieder an die gleichen Dienste (Services) gebunden wird, meist fehlt der IIS-Dienst! Das Hinzufügen des Dienstes zum neuen Zertifikat erfolgt mit:
enable-exchangecertificate -thumbprint "yyy" -services IIS

Nicht vergessen, alles hinterher zu überprüfen:
get-exchangecertificate | fl thu*,notafter,services,certificatedomains


Anleitung für den SBS2008:
Nachdem wie oben ein Zertifikat erstellt wurde, muss das Zertifikat noch aktiviert werden:
- Starten der "Windows SBS Console" -> Freigegebene Ordner und Websites -> Websites
- "Outlook Web Access" -> Eigenschaften der Website anzeigen -> Erweiterte Einstellungen -> IIS Manager
- Servername aufklappen -> Sites
- Rechtsklick auf "SBS Web Applications" -> Bindungen -> HTTPS auswählen -> Bearbeiten -> neues Zertifikat auswählen

Mittwoch, 11. Juli 2012

Outlook / Exchange erzeugt E-Mail mit winmail.dat Anhang auf Mac Client

Da es immer mehr Mac User gibt, tritt bei meinen Kunden gehäuft folgendes Problem aus.

Über Outlook 2007 / 2010 wird eine E-Mail geschrieben und mit einem Anhang versehen (Bild, Office Dokument wie Word, Excel oder PDF). Im Hintergrund arbeitet Exchange 2007 bzw. 2010. Auf dem Mac (über iMail) kommen jedoch die Anhänge nicht an, sondern nur ein Anhang "winmail.dat".

Das Problem ist, dass Microsoft Exchange standardmäßig versucht, das Microsoft eigene E-Mail Format Richt-Text-Format zum Senden von E-Mails zu verwenden. Das Verhalten kann teilweise über Outlook gesteuert werden, jedoch vom Server überschrieben werden.

Abhilfe schafft folgendes (Exchange 2010):
  • Exchange-Verwaltungskonsole -> Organisationskonfiguration -> Hub-Transport -> Remotedomänen
  • Eigenschaften des Default-Eintrages (bzw. weiteren) -> Registerkarte "Nachrichtenformat" -> Exchange-Rich-Text-Format: "Nie verwenden" markieren und mit "OK" bestätigen
Danke für den Tipp an OliverDE aus dem MS Technet: http://social.technet.microsoft.com/Forums/de-DE/office_generalde/thread/1721a231-771e-4756-9c42-1c475747e02b/

Freitag, 6. April 2012

Apple Mail App und Exchange 2007 / 2010 Größenbeschränkung beim Versenden großer Mails / Anhang

Mac Mail.app verwendet Microsoft Exchange Web Services zum Versenden von E-Mails über einen Exchange Server. Die Standardeinstellungen für die maximale E-Mail Größe auf dem Exchange Server liegt hier bei knapp 13MB.

Häufig wird diese Größenbeschränkung nicht wahrgenommen, da Outlook oder Outlook Web Access (OWA) über andere Schnittstellen die Verbindung zum Exchange Server aufbauen und der Wert nicht über die PowerShell oder GUI geändert werden kann.

Um den Maximalwert zu erhöhen sind die folgenden Schritte notwendig. Bitte beachten Sie, dass durch Erhöhen der Werte der Exchange-Server stark belastet wird und folgende Probleme auftreten können:
- Speicherdatenbanken vom Exchange können instabil werden
- die Zahl der Transaktionsprotokolle wird stark erhöht
- die CPU-Auslastung kann sich verdoppeln und auf bis zu 100 Prozent ansteigen
- falls Outlook auf dem gleichen Rechner läuft und es RPC-Fehler gibt, muss der Information Store neu gestartet werden

Gehen Sie also vorsichtig mit der Erhöhung um!

Sie müssen in der Datei "web.config" den Wert "MaxRequestLength" von "13280" auf einen beliebigen Wert (max. 50000) erhöhen. Die Zahl ist in KB anzugeben.

Die Datei ist im EWS Virtual Directory zu finden:
- "Microsoft\Exchange Server\ClientAccess\exchweb\EWS"


Weitere Infos:
- Microsoft KB935848