Exchange Lizenzierung: standrad/enterprise CALs

Posted on 05.01.2017 by in Exchange

Ausgangslage:

Die Lizenzprüfung steht ins Haus und es muss herausgefunden werden wie viele Lizenzen benötigt werden.
Die Exchange Server sind grundlegend entweder mit einer Standard oder einer Enterprise Lizenz versehen.
Sobald mehr als 5 aktive MailboxDatenbanken vorhanden sind wird eine Enterprise Lizenz benötigt.

Diese Tatsache ist aber bei den meisten bekannt und wäre ja auch noch kein Beitrag wert.

Client Access License:
Viele haben schon davon gehört, dass es für Server Benutzer bzw Geräte Zugriffslizenzen gibt. Ja solche gibt es auch für Exchange 🙂
Hierbei wird zwischen Standard und Enterprise unterschieden.

Der folgende Befehl liefert die Lizenzen die in der Organisation verwendet werden. Die Spalte LicenseName wird dann entsprechend in dem nächsten Befehl erneut verwendet.

Auflistung der Standard CAL Users:

Auflistung der Enterprise CAL Users:

Seit Exchange 2016 erscheint nun seit neuem die Warnmeldung, dass der Befehl Get-ActiveSyncMailboxPolicy depricated ist und Get-MobileDeviceMailboxPolicy verwenden sollte. Dies wird denke ich in einem späteren CU (spätestens bevor der Befehl entfernt wird) angepasst werden.

Die beiden Befehle können dann natürlich an das Measure-Object gesendet werden um nicht von Hand zu zählen:

Zur Vollständigkeit des Artikels gibt es hier die Liste von Microsoft, welche Features in der Standard bzw. Enterprise CAL enthalten sind.
https://products.office.com/en/exchange/microsoft-exchange-server-licensing-licensing-overview

SPLA / SAL:
Die SPLA (Microsoft Services Provider License Agreement) Lizenzierungsmethode bzw. für Exchange die SAL (Subscriber Access License) steht ebenfalls zur Verfügung, jedoch nur für Microsoft Partner, also für Firmen die Mitglied des MPN (Microsoft Partner Network) sind sowie entsprechende Hosting, Outsourcing Lösungen anbieten können. Grundlegend werden dabei nicht mehr die eingesetzten Server Lizenziert sondern für jeden Benutzer eine entsprechende SAL verwendet.

Microsoft stellt dabei den folgenden Guid zur Verfügung.
http://download.microsoft.com/download/8/9/A/89A3F8B9-94DE-4956-A56E-F6D2B215D0E6/Services_Provider_License_Agreement_Program_Guide.pdf

Mail Stuck in Queue LastError: 451 4.4.0 SMTPSEND.SuspiciousRemoteServerError; remote server disconnected abruptly; retry will bedelayed

Prolog:

Bei diesem Kundensystem handelt es sich um eine Exchange 2013 Umgebung mit mehreren MultiRole Servern in einer DAG.
Es gibt einen Send Connector zu einer MTA Infrastruktur mit mehreren MTAs. Dabei wird die VIP der MTA Infrastruktur angesprochen.

Ausgangslage:

Bei der Umgebung  stellten wir fest, dass vermehrt E-Mails mit dem folgenden SMTP Error in den Queues stecken bleiben.

Es bleiben bei allen Servern Mails in der SmartHost Queue stecken – das Problem scheint also durch den Smarthost verursacht zu werden.

Die meisten E-Mails werden jedoch erfolgreich verarbeitet (von und zu der MTA Infrastruktur).

 

 Überprüfung:

Mit folgendem Befehl habe ich mir die relevanten Informationen der E-Mails aus den Queues ausgelesen.

Ich habe die Mails ebenfalls zur weiteren Analyse aus der Queue exportiert (Betrachtung eines Mails via Outlook kann durchaus einiges vereinfachen – Headerinformationen des Mails, Auflistung Empfänger etc.)

Ausser der grossen Empfängeranzahl (bis zu 150 Empfänger) konnte ich jedoch keine ungewöhnlichen Informationen im E-Mail identifizieren.

Somit prüfte ich die erlaubten Limiten

Kann also nicht das Problem sein.

Für diejenigen die sagen, es gibt doch noch eine Stelle um die MaxRecipients einzuschränken. Genau, nur wurde das Message bereits angenommen durch den Receive Connector – so dass dieses Limit nicht zutreffen kann. Geprüft werden könnte das Limit mit folgendem Befehl, für diejenigen die es dennoch lieber geprüft haben (Ich hab die ReceiveConnector in dem Befehl nicht gefiltert – sry, zu lacy – welcher ReceiveConnector zur Anwendung kommt, könnte aus dem Get-Message Befehl ausgelesen werden – Attribut: MessageSourceName).

 

Der Verdacht scheint sich zu bestätigen, dass das Problem auf dem SmartHost zu suchen ist.
Die Abklärungen mit den Kollegen beim SmartHost ergibt schlussendlich folgendes Bild.

Der TCP Trace zeigt, dass der Exchange Server versucht das Mail beim MTA zu deponieren, entsprechende SMTP Kommunikation ist ersichtlich.

Auf den ersten Blick konnte man auch aus dem TCP Trace nicht schlauer werden. Wir bemerkten aber, dass jeweils nach dem 100sten Empfänger die Verbindung getrennt wurde. Dies löste Verwunderung aus, da nach unserem Wissensstand keine Filterregeln oder ähnliches zwischen der Verbindung aktiv sein sollte.

 

Lösung:

Wir mussten leider feststellen, dass unser Wissensstand nicht korrekt war. Der Kunde hat vor wenigen Tagen eine neue Cisco ASA erhalten welche per Standard das ESMTP Inspection aktiv hat.

Quelle Cisco

Wie aus dem Referenzartikel zu entnehmen:

Als wir das ESMTP Inspection auf der ASA deaktiviert haben konnten die Mails erfolgreich durch den Exchange abgearbeitet werden.

 

Server 2016 Preview 3

Posted on 20.08.2015 by in PowerShell

Gestern wurde die Server 2016 Preview 3 veröffentlicht.
Ich hatte bis jetzt noch keine Zeit die Preview 1 oder 2 genauer anzuschauen. Genau so wenig wie die schon länger veröffentlichte Exchange 2016 Preview.
Hier gibt es noch den TechNet-Artikel zur TP3

Ich wollte mir darum ein neues Lab mit Server 2016 TP3 und Exchange 2016 TP1 aufbauen.
Ich verwende dazu meinen Windows 10 Client mit der eingebauten Hyper-V Funktion.

Installation ADDS

Natürlich muss zuerst das OS Installiert werden – da ich jedoch strikt auf PowerShell-Befehle beharren möchte, lasse ich die Screenshots der Installation weg.
Ich kann euch nur so viel sagen. Ich konnte mit der TP3 Core Version kein ADDS Installieren.

Egal wie ich es versuchte, ich endete jeweils mit dem Resultat:

Fehler

//Eventlog, logs etc. ergab keine Hilfe, die Prerequisite Tests waren zu diesem Zeitpunkt bereits erfolgreich. Eine neue NIC etc. konnte ebenfalls nichts daran ändern.

Aus diesem Grund habe ich dann noch mit den Desktop Experiences installiert, die Konfiguration dennoch ausschliesslich mit PowerShell vorgenommen.
Folglich also die Installation eines komplett neuen ADDS Servers für mein Lab.

Hostname

Es kann natürlich auch die Variante mit WMI verwendet werden

IP Adresse

Sofern ihr nicht mehrere aktive NICs habt sollte hier nur ein Interface mit dem Namen „Ethernet“ erscheinen. Entweder ihr arbeitet mit dem InterfaceAlias (also Ethernet) oder mit der ifIndex also dem InterfaceIndex. Mein InterfaceIndex war 3.

Ihr könnt natürlich noch weitere Angaben machen, wie DefaultGateway oder AddressFamily (IPv4). Ich habe in erster Linie darauf verzichtet.

DNS Server

Ich hab mir die Mühe geschenkt, einen DNS Server anzugeben mit $null wollte ich jedoch explizit die vorhandenen DNS Server die ich via DHCP erhalten habe, entfernen.

Windows-Features

Diese werden benötigt damit die entsprechenden Befehle zur Verfügung stehen, ähnlich dem dcpromo.

Reboot

DcPromo oder wie man das Promoten eines Servers zu einem DomänenController nun nennen möchte

Wer einen schönen Screenshot nach der Installation machen möchte oder warum auch immer kann natürlich noch weitere Switch-Parameter angeben z.B. -NoRebootOnCompletion oder die Pfade für EDB etc.

Setup1

Setup2

ADDS_DE

Die Domäne steht nun erstmals, kleine Konfigurationen kommen dann noch.
Als nächstes kommt aber der Exchange 2016

Exchange: Sperren der „Microsoft Outlook“ Mobile App

Prolog:

 

Ausgangslage:

Wer den oberen acompli Link bereits angeschaut hat stiesst auf folgende Aussage:

What information do we collect and why?
Account Information. If you decide to sign up to use the service, you will need to create an account. That requires that you provide the email address(es) that you want to access with our service. Some email accounts (ones that use Microsoft Exchange, for example) also require that you provide your email login credentials, including your username, password, server URL, and server domain.

Dies wird auch vom Microsoft Supportern besätigt:
http://blogs.office.com/2015/01/29/deeper-look-outlook-ios-android/ in den Kommentaren;

Fragen von: larrycl:

In the linked blog post, it said the new Outlook app is based on the Acompli code base.
Acompli had a design issue whereby your usernames & passwords were stored on Acompli’s servers, and all your email was downloaded and cached by Acompli. This, IMHO, made Acompli a non-starter for business use, as it violated most corporate security policies.

Does the new Outlook app remove this “feature”, or will all your email still be routed through acompli/microsoft’s servers?

Antwort von Microsoft Support (Jon Orton – MSFT):

@larrycl – Yes, that architecture remains in place with the new app. It uses cloud components to improve app performance and enable some features, such as predictive search, recent attachments, and large attachment handling.

 

Lösung:

 

Überprüfung:

Wenn die Richtlinie korrekt angewendet wird, sollte die Mailbox beim versuch folgendes E-Mail erhalten:

EASPolicy

 

 

Zusatz Info:

Benutzer die bereits das App verwenden, erhalten danach ständig die Aufforderung zur Anmeldung, die leider nicht als Fehlerhaft zurückgewiesen wird (erst bei der nächsten Aktion erneut auftaucht)
Der verdacht, dass zu diesem Zeitpunkt die Benutzerdaten bereits an die Server von acompli gesendet wurden ist jedoch gross. – Diese Lösung ist nicht mit einer MDM Lösung zu vergleichen. Ebenfalls besteht die möglichkeit, dass Personen mit der vorgänger Acompli App arbeiten. Leider konnte ich diese nicht zu 100% Identifizieren. Einzig auffälliger Eintrag konnte ich mit folgender Kombination ausfindig machen:

Ich habe dafür folgende Abfrage verwendet:

 

Damit die bestehenden Personen angesprochen werden können, kann mit folgenden Befehlen eine Liste mit E-Mail Adressen generiert werden.

Okay, Exchange 2007 ist hier etwas umständlich, da leider keine Liste mit Mailadressen zurück kommt – da es in meiner Exchange 2007 Umgebung zu wenig treffer gab, hab ich dann auch nicht mehr weiter geamcht.
Ebenfalls hatte ich keine Benutzer die mehrere ActiveSync Verknüpfungen mit dem App aufweisten (z.B: zweites Device), somit habe ich auf eine überprüfung nach Verdoppelung verzichtet.

 

Aufweichung – AllowDeviceIDs:

Es kann natürlich auch pro Mailbox die Freischaltung gemacht werden, wir kennen ja unsere Benutzer und eine wichtige Person möchte nicht auf das App verzichten. Hiermit lässt sich auch mit dem Block via ActiveSyncDeviceAccessRule das App pro Mailbox freischalten:

 

Aufweichung – Quarantäne:

Es kann natürlich auch anstelle des Block auch der Quarantäne-Modus verwendet werden. Dieser wird wie folgt eingestellt.

In diesem Modus kommt das ECP für die Freischaltung der Devices zum Einsatz.
Der Administrator muss somit die Anfragen der Benutzer entsprechend freischalten.
Hierfür lässt sich mit folgendem Befehl eine administrative Mailadresse erfassen, die eine jeweils ein E-Mail erhält sobald ein Device freigeschaltet werden muss.

 

Ansicht ECP – Admin:
Quarantined_ECP

 

Mailbenachrichtigung – Benutzer:
Quarantined_Mail

Ansicht ECP – Benutzer (Detail):

Quarantined_ECP_user
Status ist bereits Ok, im Detail ist jedoch der Quarantäne-Status erkennbar.

 

Löschen der App:

Hat man erst einmal ein Postfach mit der App synchronisiert, so wurden die Daten an die Cloud-Server übetragen. Diese bleiben dort auch nach einem löschen für eine gewisse Zeit erhalten (z.B.: Wenn von Device 1 zu Device 2 gewechselt wird, muss nicht mehr die komplette Mailbox in die Cloud übertragen werden.). Damit diese Daten ebenfalls entfernt werden sollte vor der deinstallation des Apps in den Kontoeinstellungen das Konto inkl. der Remote Daten entfernt werden.


App_Remove
Die Daten auf dem Mailsystem werden dabei nicht gelöscht.

Lync-Kontakte Ordner (mehrfach Kontakte, Duplikate)

Ausgangslage:

Der Lync Client erstellt x-Fache doppelte Kontakte unter dem Kontakte Ordner Lync-Kontakte.

Diese können via Outlook oder OWA nicht gelöscht werden.

 

Ursache:

Korrupter Eintrag in der Lync Buddy-Liste

Korrupter Lync 2013 Client Version (vor SP1).

 

Workaround:

Löschen des Korrupten Lync Buddy-List-Eintrag

Löschen der Lync-Kontakte via MFCMAPI oder via OWA Light.

Ich persönlich hab immer auf MFCMAPI zurück gegriffen, da im Internet auch Kommentare zu finden sind, die eine negative Erfahrung via OWA Light gemacht haben.

 

Hilfe:

 

Weitere Informationen:

http://support2.microsoft.com/default.aspx?kbid=2916650

Lync wird zu Skype

Posted on 11.11.2014 by in Lync

„[…] The next version of Lync, available in the first half of 2015, will debut as Skype for Business.[…]“

Quelle:
http://www.theverge.com/2014/11/11/7192929/skype-for-business-lync-replacement

Es wird also spannend an der Lync Front.
Meine ersten Gedanken gehen in die Richtung; Lync / Skype Client.. Ist im nächsten Office dann ein Skype Client enthalten.. Oder was wenn eine Firma keine Federation zu Microsoft bzw zu Skype haben möchte?

Exchange 2010 – MailboxDatabase – ContentIndex State Failed

Posted on 11.11.2014 by in Exchange 2010

Prolog:
Immer ärger mit dem ContentIndex.
Bei diesem Kundensystem handelt es sich um einen MultiRole Exchange 2010 SP3 mit CU6.
Es ist somit keine Replication von einem DAG Node möglich, da es keine weiteren Kopien der Datenbank gibt.

Ausgangslage:
SCOM meldet folgende Fehlermeldung:

 

Überprüfung:
Als erstes habe ich die SCOM Meldung überprüft, für mich jeweils am einfachsten mit Powershell.

 

Weitere Überprüfungen:
1.

Weitere Informationen zu der Troubleshoot-CI.ps1 gibt es unter (http://blogs.technet.com/b/exchange/archive/2011/01/18/3411844.aspx)

 

2.

 

Lösung:
Wie bereits erwähnt handelt es sich hierbei um einen MultiRole Exchange. Es ist zudem der einzige Exchange in der Organisation, womit auch klar ist, dass es keine weiteren Kopien der Datenbank gibt. Update-MailboxDatabaseCopy  -Identity MDB001\Server1 -SourceServer Server2 -CatalogOnly fällt somit leider weg.

Ich konnte bereits mehrfach eine „Quick and Dirty“ Workaround-Lösung anwenden um den ContentIndex State wieder auf Healthy zu bringen.

Natürlich auch mit klassischem Stop-Service && Start-Service oder net stop && net start zu lösen.

Es kann jedoch sein, dass beim Stoppen folgende Fehlermeldung präsentiert wird

The request failed or the service did not respond in a timely fashion. Consult the event log or other applicable error logs for details.

Um hier ebenfalls abhilfe zu schaffen, kann die entsprechende Microsoft.Exchange.Search.ExSearch.exe via Taksmanager beendet werden, wodurch der Service anschliessend neustartet.

Hello world! 1.0

Posted on 28.10.2014 by in Off-Topic

Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!

Ich werde in diesem Blog mein Wissen, meine gesammelten Erfahrungen und (Problem)-Lösungen festhalten. Es ist damit zu rechnen, dass die Themen stark durch Exchange und Lync geprägt sein werden. Generelle Lösungen im Windows Bereich können aber ebenfalls vorkommen 🙂