Stichwort Pushmail. Toll, wenn Kollegen mit 1-2-3 Klicks ihr Smartphone um das Firmen-E-Mail-Konto ergänzt haben und diese dann ruck-zuck via Pushmail darauf landen. Nicht so toll ist, wenn man das mit jedem x-beliebigen Gerät machen kann – der Benutzer benötigt im Zweifelsfall nur den Benutzernamen und das Passwort in der Windows-Domäne. Gut – an der Authentifizierung ändern wir in diesem Artikel nichts, aber zumindest schränken wir die Endgeräte ein, mit denen sich Benutzer verbinden dürfen.
Ähnlich wie man in WLANs die Endgeräte festlegen kann, die sich verbinden dürfen, indem man einen MAC-Adressenfilter konfiguriert, funktioniert das auch bei ActiveSync.
Zunächst sollte man generell nur den Benutzern in den Eigenschaften des AD-Objekts die Funktion aktivieren, die auch Pushmail/ActiveSync einsetzen dürfen:
Dann kann man mittels EMS-Befehle die Smartphones anhand deren DeviceID beschränken. Im Standard ist das entsprechende Feld nämlich leer und bedeutet, dass beliebige Smartphones erlaubt sind.
Um herauszufinden, welches Smartphone der Benutzer registriert hat, verwendet man das CmdLet
Get-ActiveSyncDeviceStatistics -Mailbox:”Name@domaene.tld” | fl DeviceID
Im Anschluss beschränkt man die erlaubten Smartphones:
Set-CASMailbox -Identity: “Name, Vorname” -ActiveSyncAllowedDeviceIDs: “<DeviceID_1>”,”<DeviceID_2>”
Siehe http://technet.microsoft.com/de-de/library/aa998933.aspx.
Wer das Thema Absicherung weiter beleuchten möchte, sollte sich zudem noch die Themen Zertifikate und ActiveSync-Postfachrichtlinien anschauen.
Share your thoughts
Es kommt ja mal vor, dass Kollegen das Unternehmen verlassen.
Nun gibt es ganz sicher eine Checkliste zur Deaktivierung des User-Accounts im Netz.
Bezüglich des E-Mail-Accounts unter Exchange könnte dann nachfolgendes interessant sein.
Ist die Unternehmensrichtlinie dahingehend gestrickt, dass keine privaten Mails zugelassen sind, muss das Mail-Postfach langzeitarchiviert werden (andernfalls vielleicht auch, wenn der Mitarbeiter vorher seine privaten Mails herausgefiltert hat). Eine einfache Möglichkeit unter Exchange 2010, ohne dass der Admin gleich auf den Postfachinhalt zugreifen muss, sind folgende EMS-Befehle:
Exportieren des Postfachs in ein .pst-File auf eine Freigabe eines Servers:
New-MailboxExportRequest -Mailbox “Nachname, Vorname” -FilePath “\\Server\BackupDB\Name_Backup.pst”
Da der Export serverbasiert läuft, kontrolliert man anschließend, ob er vollständig durchgelaufen ist:
Get-MailboxExportRequestStatistics -Identity Name\MailboxExport
Ist alles ok, kann der Job gelöscht werden:
Get-MailboxExportRequest | Remove-MailboxExportRequest
Weitere Impressionen unter http://technet.microsoft.com/de-de/library/ee633455.aspx.
Share your thoughts
Am Wochenende waren die Exchange-Server dran, auf das SP2 aktualisiert zu werden.
2-3 Stolpersteine sind mir dabei in den Weg gekommen, die ich hier noch einmal zusammenfasse.
Ein Überblick über die wesentlichen Neuerungen – z.B. hier oder eben hier. Interessant ist z.B. oma (outlook mobile access) – gut für Smartphones mit kleinem Display und geringerer Bandbreite.
Zur Vorbereitung des Updates natürlich vorab ein ausführlicher Blick auf die Requirements, die Sicherstellung eines aktuellen Backups und schonmal der Start des Download des Pakets. Sind immerhin über 500 MB.
Zur Installation sollte man am Exchange-Server als Schema-Admin angemeldet sein, da wieder einmal das AD-Schema erweitert wird. Weiterhin ist es ratsam, vor Beginn der Installation alle tangierenden Dienste zu prüfen. Backup-Agent oder Virenscanner für Exchange zum Beispiel müssen vor Start des Setups beendet werden. Gern sind auch Drittanbieter-Tools für Gruppenkalender oder andere Collaborations-Programme involviert. Diese sollten zumindest für anschließende Funktionstests auf dem Zettel bleiben. 
Ist alles angerichtet, kann das Upgrade über die setup.exe aus dem entpackten Downloadfile starten.
Read the rest of this entry »
Share your thoughts
Man stelle sich folgendes vor:
Er kennt noch kein Internet. Zumindest kann er sich nicht viel darunter vorstellen, außer dass sich die Großen öfter darüber unterhalten und dass man dort tolle Fußball-Videos anschauen kann. Ansonsten gibt es kaum Berührungspunkte, vielleicht einige flüchtige Besuche auf der Maus-Seite. Sein Vater sorgte bislang dafür, dass es noch keine verwertbaren Spuren über ihn gibt. Er wachte darüber, Tag und Nacht. Doch auch ein Vater macht Fehler. Nicht umkehrbare Fehler, die das Leben seiner Kinder für immer beeinflussen könnten. Er wollte seine Kinder am öffentlichen Leben teilhaben lassen. Sportverein, ein bißchen Fußball spielen oder Kinderturnen, wie schön. Doch dann das! Treffer bei einer routinemäßigen Kontrolle in der Ergebnisliste des Datenkraken! Eindeutig zurückzuführen auf…SEINEN SOHN!! Nicht wieder auslöschbar, für lange Zeit konserviert in den netzartigen, weltweiten Strukturen des Internets…DAS ist der Anfang vom Ende (oder DAS oder DAS)!
Oder anders formuliert: Es reicht heutzutage aus, sein Kind in die Schule zu geben, an Festen teilnehmen zu lassen, Sportverein, Schwimmkurs, usw. Schon kann man davon ausgehen, dass der Name des Kindes in diesem Zusammenhang im Internet verewigt ist, auch wenn man zunächst keine Verbindung mit dem Web vermuten würde. Der Schein trügt. Nun beginnt die Geschichte des jungen Menschen ein zweites Mal, virtuell. Erste Spuren liegen aus…der Vater weiß, was zu tun ist.
…Und – ja, ich habe heute Abend ein wenig zuviel Cola-Dramatik getrunken.
1 Comment
Weil ich ein wenig danach gesucht habe.
Serverfarm: XenApp 6.
Beim Discovery der Nicht-lokalen XenApp-Server erscheinen Fehler mit der EventID 10016 im Eventlog, wenn man kein Administrator ist, etwa
“Durch die Berechtigungseinstellungen (Computerstandard) wird der SID (…..) für Benutzer Domain\Name von Adresse 1.2.3.4 keine Berechtigung zum Aktivierung (Remote) für die COM-Serveranwendung mit CLSID {D66B68BD-9B5B-41CB-B692-A4D44DA3DC20} und APPID {7BB98CBB-42E7-402B-994B-C21141D252DB} gewährt. Die Sicherheitsberechtigung kann mit dem Verwaltungsprogramm für Komponentendienste geändert werden.”
Folgendermaßen kann der Fehler jeweils auf allen XenApp-Servern lokal beseitigt werden:
- Starten der Verwaltung der Komponentendienste -> Komponentendienste -> Computer -> Arbeitsplatz -> DCOM-Konfiguration -> MFCOM -> Rechtsklick / Eigenschaften -> Sicherheit -> Start- und Aktivierungsberechtigungen auf „anpassen“ setzen -> bearbeiten -> hinzufügen der lokalen Windows-Gruppe „Distributed Com-Benutzer“ -> Vergeben aller 4 Rechte (Lokaler Start, Remotestart, Lokale Aktivierung, Remoteaktivierung). Schließen mit OK.
- Hinzufügen der gewünschten Gruppe oder einzelner Benutzer in die lokale Berechtigungsgruppe „Distributed COM-Benutzer“
- Neustart des Dienstes „Citrix MFCOM-Dienst“.
- Fertig.
Share your thoughts
Hab heute mal ein paar Updates gemacht. Muss ja auch mal sein.
mySQL-DB unter 5 neu erstellt, dann den ganzen Wp-Kram aus dem letzten Backup mit Zeichenkodierung latin-1 importiert und schließlich auf WP 3.2 aktualisiert.
Share your thoughts