Archiv der Kategorie: Office 365

Office 365 – nicht alle Benutzer synchronisieren

Standardmässig werden von DirSync alle Benutzer synchronisiert. Diese Benutzer können dann für das Abrufen der Mails von Office 365 das Passwort benutzen, das sie auch für die Anmeldung innerhalb des Netzwerks benutzen. Bevor das Passwort abläuft, werden sie am Computer aufgefordert, dieses zu ändern.

Wir haben aber Mailaccounts für Schulratsmitglieder, Sekretariatsmitarbeiter/-innen und andere, die nie an einem Computer innerhalb des Schulnetzwerks arbeiten. Damit diese eine Mailadresse erhalten, mussten wir einen Benutzeraccount im AD anlegen. Das Passwort konnten sie von extern über Outlook Web Access (OWA) zurücksetzen, auch nachdem dieses abgelaufen war. Für diese Benutzer erstellt man besser nur in Office 365 einen Account und löscht den lokalen nach der Migration des Postfachs.

Um in DirSync die OU’s herauszufiltern, die man nicht synchronisiert haben möchte, kann man im “Synchronization Service Manager” “Management Agents” und dann den “Active Directory Connector” auswählen und dann auf “Properties” klicken. In dem sich öffnenden Fenster wählt man “Configure Directory Partitions” und dann “Containers…”

Man muss sich dann mit Benutzernamen und Passwort mit Administratorberechtigungen für das lokale AD anmelden. Den voreingestellten Benutzernamen kann man einfach überschreiben.

Hier kann man nun alle Häklein ausser bei den gewünschten OU’s entfernen.

Nachdem sollte man einen “Full Import Full Sync” ausführen. Die Accounts in den nicht mehr synchronisierten OU’s werden dabei in Office 365 gelöscht. Diese können nun manuell als nicht synchronisierte “cloud only” Accounts in Office 365 angelegt werden.

Man kann übrigens solche nicht synchronisierte Accounts ganz normal über einen Migration-Batch in die Cloud migrieren. Nur die Mailadresse muss stimmen, die Accounts müssen lokal und in Office365 nicht einmal das gleiche Passwort besitzen.

zurück zu Teil 5: Benutzer migrieren

zurück zur Übersicht

Office 365 – Outlook Profil anpassen

Kommentar verfassen

Bei der Installation von Office auf Computern kann man die einzelnen Komponenten mit dem “Office Customization Tool” (OCT) anpassen. Damit die Benutzer kein eigenes Profil für Outlook erstellen müssen, habe darüber ein Profil verteilt, das den lokalen Exchangeserver als Server eingetragen hat.

Für Benutzer, die Outlook noch nie geöffnet haben, wird beim ersten Öffnen von Outlook ein Profil erstellt. Wenn nun solche Benutzer nach Office 365 migriert werden, erstellt Outlook automatisch die neuen Einträge wie in diesem Artikel ganz unten beschrieben.

Wenn nun aber ein Benutzer bereits nach Office 365 migriert ist, bevor er das erste Mal Outlook geöffnet hat, wird beim ersten Start versucht, die Verbindung mit dem lokalen Exchangeserver, der über das Office-Anpassungstool (OCT) eingetragen wurde, herzustellen. Das geht aber nicht und Outlook lässt sich dann nicht öffnen.

Um diesen Fall aufzufangen, kann man mit dem OCT eine MSP-Datei erstellen, die sich verteilen lässt. Da bei der Installation von Office damals OCT benutzt wurde, kann man einfach die Installationsdateien z.B. auf eine virtuelle Maschine kopieren und “setup.exe /admin” ausführen.

Wenn man nun unter “Outlook-Profil” –> “Vorhandenes Profil verwenden:” auswählt, wird nichts an bereits eingerichteten Profilen geändert, aber bei der Neuerstellung von einem Profil kommt die Abfrage und es wird nicht mehr versucht, mit dem voreingestellten lokalen Exchangeserver Kontakt aufzunehmen.

Ich ändere gerade auch noch die Einstellung für den Cachemodus (aus anderen Gründen).

Über “Datei” –> “Speichern” kann man die Einstellungen als MSP-Datei speichern und diese z.B. mit SCCM verteilen. Das Programm könnte z.B. lauten:

msiexec /p Office365.msp /qn

Wenn sich nun ein Benutzer zum ersten Mal anmeldet, kommt wie gewünscht der Start-Assistent.

Da kann man sich durchklicken, bis zur Anmeldung. Hier muss man als Benutzernamen die vollständige Mailadresse und das Passwort eingeben.

Wenn das Postfach bereits eingerichtet ist, der Benutzer also Outlook schon einmal geöffnet hat, ändert sich nichts, man muss den Assistenten nicht durchklicken.

zurück zu Teil 5 „Benutzer migrieren“

zurück zur Übersicht

Office 365 – Teil 5: Benutzer migrieren

Kommentar verfassen

Es gibt verschiedene Wege, die Benutzer auf Office 365 zu migrieren. Mit dem Exchange 2013 Server Deployment Assistant kann man herausfinden, welche Migration für die eigene Umgebung in Frage kommt.

In meinem Fall mit mehr als 1’000 Accounts und einem Exchange 2007 Server wählt man die sogenannte “Staged Exchange Migration”.

Die “Staged Exchange Migration” kann sich über mehrere Wochen oder sogar Monate hinziehen. Wichtig ist, dass bis zum Abschluss der Migration die öffentlichen DNS-Einträge (Autodiscover- und MX-Einträge) auf den lokalen Exchange Server zeigen. Dies bedeutet zwar, dass im Office 365 Admin Center die Domänen ein rotes Kreuz haben, was aber während der Migration richtig ist.

Der lokale Exchangeserver leitet nämlich die an ihn gerichteten Mails der bereits migrierten Benutzer an Office 365 weiter. Erst wenn alle Benutzer migriert sind, kann man die DNS Einträge auf Office 365 umstellen, damit die Mails direkt dorthin geroutet werden.

Wenn alles vorbereitet ist, kann man gemäss diesem Technet Artikel eine CSV-Datei für die Migration bereitstellen. Da das Passwort über DirSync mit dem Active Directory synchronisiert wird, benötigt man nur die Spalte “EmailAddress”. In einer CSV-Datei dürfen maximal 1’000 User vorkommen.

Diese CSV-Datei kann man nun im “Exchange Admin Center” vom Office 365 Portal”“ unter “Empfänger” –> “Migration” hinzufügen.

Beim Migrationstyp wählt man aus den oben erwähnten Gründen “Mehrstufige Migration”, also eine “staged migration”.

Im nächsten Fenster wählt man die vorher erstellte CSV-Datei aus.

Als nächstes muss man die Angaben zum Server angeben.

Nun muss man dem Migrationsbatch noch einen Namen vergeben.

Wenn man möchte, dass man per Mail über die erfolgreiche Abarbeitung des Batches informiert wird, kann man eine Mailadresse eintragen.

Nachdem der Migrationsbatch durchgelaufen ist, haben die migrierten Benutzer zwei Postfächer, eines auf dem lokalen Exchangeserver und eines in Office 365. Mails werden wegen den noch nicht umgestellten DNS Einträgen weiterhin an den lokalen Exchangeserver geliefert, welcher nun die Mails an Office 365 weiterleitet. Dies wird erreicht, indem im Active Directory die Adresse von Office 365 bei targetAddress eingetragen wird. Man kann dies mit dem ADSI-Editor überprüfen.

Ein Problem bleibt nun aber das bestehende Postfach auf dem lokalen Exchangeserver. So verbindet sich z.B. Outlook über den Autodiscover-Eintrag weiterhin mit dem lokalen Exchangeserver. Dieses und weitere Probleme kann man beheben, indem man das Benutzerpostfach auf dem lokalen Exchangeserver zu einem “mail-enabled user” abändert. Microsoft stellt dafür eine Anleitung und Powershellskripts zur Verfügung.

Als erstes lädt man die beiden Powershellskripts in einen Ordner, kopiert die CSV-Datei mit den migrierten Benutzern dazu und ändert den Namen auf migration.csv.

Nun kann man in der Exchange Management Shell das erste Skript .\ExportO365UserInfo.ps1 ausführen lassen.

Für die Verbindung mit Office 365 muss man sich mit Benutzernamen und Passwort für Office 365 anmelden.

Wenn das Skript erfolgreich durchgelaufen ist, wird eine neue Datei cloud.csv erstellt.

Mit .\Exchange2007MBtoMEU.ps1 <FQDN von einem Domänencontroller> kann man nun die Umwandlung auslösen.

Wenn alles erfolgreich gelaufen ist, haben die Accounts kein Postfach mehr in Exchange, sondern sind nur noch als E-Mail-Kontakt mit der externen Mailadresse von Office 365 aufgeführt.

Im Office 365 Portal kann man nun unter “Benutzer” –> “Aktive Benutzer” die migrierten Benutzer auswählen.

Tipp: Ich habe mir eine neue Ansicht erstellt, die die Benutzer mit einem Postfach, aber ohne Lizenz anzeigt. Dies sind dann gerade die noch zu ändernden Benutzer.

Diese kann man nun alle auswählen und bearbeiten. So kann man für alle migrierten Benutzer die Standarddomäne auswählen, den Benutzerstandort auf Schweiz setzen und eine Lizenz zuweisen.

Wenn alles korrekt funktioniert hat, kann man den Batch im Exchange Admin Center unter “Empfänger” –> “Migration” beenden und löschen

Die migrierten Benutzer können sich nun auf verschiedenen Wegen anmelden. An Outlook Web App kann man sich über https://outlook.office365.com und am Portal über https://portal.office365.com anmelden.

Bei der ersten Anmeldung muss man noch Sprache und Zeitzone auswählen.

Über Active Sync kann man wie gewohnt ein neues Exchange Konto hinzufügen und die persönlichen Daten eintragen. Bei mir genügten die Mailadresse und das Passwort nicht. Es wurde auch der Benutzername (gleich wie Mailadresse) und der Server (outlook.office365.com) abgefragt. Ich gehe davon aus, dass dies nicht mehr nötig ist, wenn nach der vollständigen Migration die DNS Einträge angepasst sind.

Bei einem bereits eingerichteten Outlook Profil muss man die neue Verbindung herstellen. Beim Starten von Outlook erscheint ein Anmeldefenster. Beim Benutzernamen wird die intern verwendete Domäne vorgeschlagen, welche auf die korrekte öffentliche Mailadresse geändert werden muss.

Am Schluss kommt eine Meldung, dass Outlook nun neu gestartet werden muss.

Danach startet Outlook korrekt mit der neuen Verbindung zu Office 365.

Über diese Änderungen sollte man die Benutzer mit einer Anleitung informieren.

Alternativ könnte man mit dem “Office Customization Tool” eine angepasste MSP-Datei erstellen, die sich dann verteilen lässt. Wegen einem Problem mit Benutzern, die Outlook noch nie geöffnet haben, musste ich so eine angepasste MSP-Datei verteilen. Weitere Informationen findet man in diesem Beitrag.

Es bleiben ein paar weitere “Real-World” Probleme.

Public Folders
Microsoft bietet zwar Skripts zum Migrieren der öffentlichen Ordner, aber solange diese Skripts nicht ausgeführt wurden, können die migrierten Benutzer nicht auf die öffentlichen Ordner zugreifen und nachdem sie ausgeführt wurden, können die noch nicht migrierten Benutzer nicht mehr auf sie zugreifen…

Passwort ändern
Bisher konnten Benutzer, die nicht an einem Computer in unserem Netzwerk arbeiten (z.b. Schulräte), ihr Passwort von extern über Outlook Web Access (OWA) zurücksetzen, auch nachdem es abgelaufen ist. Da DirSync aber die lokalen Passwörter nach Office 365 synchronisiert, können die Passwörter nur noch von intern geändert werden. Der beste Weg wird wohl sein, nicht das ganze AD zu synchronisieren und für diese Benutzer nicht synchronisierte “cloud-only” Accounts anzulegen.

zurück zur Übersicht

Office 365 – Teil 4: Benutzer synchronisieren

Kommentar verfassen

Wie im 1. Teil beschrieben, favorisiere ich das Modell, bei dem die Passwörter von Office 365 mit den Passwörtern im lokalen Active Directory synchronisiert werden.

Um die Synchronisierung einzurichten, kann man “Benutzer und Gruppen” und dann “Aktive Benutzer” auswählen. Rechts wird nun “Active Directory Synchronisierung” angezeigt. Hier wählt man “Einrichten”.

Nun kann man unter Punkt 3 die Active Directory Synchronisierung aktivieren.

Unter Punkt 4 lässt sich nun das DirSync Tool herunterladen.

Um DirSync zu installieren, muss das .Net Framework 3.5 SP1 und 4.0 installiert sein.

Das .Net Framework 3.5 kann man über den Servermanager als Feature installieren. Unter Windows 2012 R2 ist das .Net Framework 4.5 bereits installiert. Die Version 4.0 muss also nicht installiert werden, da 4.5 die Version 4.0 bereits enthält.

Vor der Installation wird noch bemängelt, dass Powershell 2.0 benötig werde (obwohl $PSVersionTable ausgibt, dass Version 4 installiert sei).

Dies ist aber ein Fehler bei der Abfrage von Powershell. Man kann dies umgehen, indem man die Einstellungen fürs Zahlenformat auf Englisch stellt und sich ab- und wieder anmeldet. Dieses Verhalten wird bei der nächsten Version von DirSync behoben sein.

Danach funktioniert die Installation.

Wenn man das Häklein stehen lässt, startet direkt der Konfigurations-Assistent.

Auf der nächsten Seite kann man die Benutzerdaten für die Verbindung mit Office 365 eingeben.

Auf dieser Seite muss man die Anmeldeinformationen eines Kontos angeben, das Admin-Berechtigungen auf das lokale Active Directory hat.

Hier könnte man die “Hybride Bereitstellung aktivieren”. Da ich aber plane, den Exchangeserver bei uns ganz mit Office 365 zu ersetzen, lasse ich das Häklein weg. Ausserdem bin ich nicht sicher, ob das überhaupt gehen würde. Wir haben noch einen Exchange 2007 Server im Einsatz, ich meine aber gelesen zu haben, dass Exchange 2010 Mindestvoraussetzung sei.

Im nächsten Fenster sollte man “Kennwortsynchronisierung aktivieren” auswählen. Ziel ist es ja, dass für Office 365 das gleiche Kennwort wie für die Computeranmeldung im lokalen Netzwerk verwendet werden kann.

Nun kann man die Verzeichnisse synchronisieren.

Vor dem Abschluss des Konfigurations-Assistenten wird noch ein Link angezeigt, mit dem man überprüfen kann, ob die Verzeichnissynchronisierung korrekt durchgeführt wird.

Nach der Synchronisation findet man die Accounts im Portal.

Um die Synchronisierung zu überprüfen, kann man den “Synchronization Service Manager” verwenden. Dieser befindet sich unter C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell als Programm miisclient. Ich habe gleich eine Verknüpfung auf dem Desktop angelegt.

Hier lassen sich dann die Änderungen verfolgen. Durch einen Klick auf Updates, kann man einzelne Updates überprüfen.

Grundlage für diesen Beitrag war dieser Blog. Vielen Dank dafür.

Um einen manuellen Sync durchzuführen (z.B. weil man nicht so lange warten möchte), kann man das DirSync Modul in Powershell importieren und dann das Start-OnlineCoexistenceSync Cmdlet ausführen.

Import-Module DirSync
Start-OnlineCoexistenceSync

zurück zur Übersicht

Office 365–Teil 3: Plan Education A2

Kommentar verfassen

In Teil 2 habe ich beschrieben, wie man überprüfen lassen kann, ob man für Academic Preise berechtigt ist.

Ein paar Tage später muss man ein englisches Mail beantworten. Die Fragen beziehen sich nicht wirklich auf das schweizerische Schulsystem, aber irgendwie versteht man dann doch was gemeint sein könnte.

Wiederum ein paar Tage später erhielt ich dann den Bescheid, dass der Antrag genehmigt wurde und wir als “qualifizierte universitäre Einrichtung” Lizenzen erwerben können.

Im Office 365 Admin Center unter Kaufdienste werden dann die möglichen buchbaren Pläne angezeigt. Bei den beiden freigeschalteten Testversionen steht im Gegensatz zu den anderen Plänen kein Preis, sondern nur “Jetzt kaufen”.

Der Plan A3, den man 30 Tage kostenlos testen kann, ist aber kostenpflichtig. Wir würden alleine für die Schüler/-innen über 50’000.- Fr. pro Jahr dafür bezahlen. Hier findet man den Vergleich der verschiedenen Versionen.

Der richtige Plan ist also in unserem Fall A2 für 0.- Fr.

So habe ich mir mit wenigen Klicks 1’700 Office 365 Lizenzen für 0.- Fr. bestellt. Microsoft reserviert uns also 85 Terabyte Postfachspeicher und ab Juli 1,7 Petabyte Speicherplatz auf Onedrive…
Irgendwie andere Dimensionen als sie bei uns im Keller vorhanden sind.

zurück zur Übersicht

Office 365 – Teil 2: Testversion in Education-Version umwandeln

2 Antworten

Nachdem man sich für eine 30-tägige Testversion registriert hat (vgl. Teil 1), kann man sich unter https://portal.office.com anmelden.

Als erstes bekommt man die Meldung:

Um für Academic-Preise berechtigt zu sein, müssen Sie nachweisen, dass Sie der Besitzer einer qualifizierten Domäne sind.

Wenn man auf “Domäne überprüfen” klickt, muss man über einen DNS Eintrag bestätigen, dass einem die Domäne gehört.

Gemäss der Anleitung erstellt man einen TXT Eintrag für die Domäne. Durch einen Klick ganz unten wird der Eintrag überprüft.

Der Besitz wird sofort bestätigt. Ob man für die Education Preise berechtigt ist, wird scheinbar manuell überprüft. Es gibt einen Hinweis, dass man über Mail benachrichtigt wird, wenn alles klappt.

zurück zur Übersicht

Office 365 – Teil 1: Grundsätzliche Überlegungen

4 Antworten

Im Zuge unserer Serverumstellung müsste ich eigentlich auch unseren alten Exchangeserver auf einen neuen migrieren. Aber Microsoft hat da ein vielversprechendes Angebot, das ich vorher überprüfen möchte.

Schulen bekommen den “Office 365 Education A2” Plan kostenlos. Dieser Plan beinhaltet neben Office Online auch einen Exchange-, Sharepoint- und Lyncserver von Microsoft in der Cloud. Dies hat diverse Vorteile. So muss man den Exchangeserver nicht bei sich installieren, verwalten und immer mal wieder updaten. Aber auch die Speicherdimensionen ändern sich. Microsoft bietet 50 GB pro Postfach. Wenn man das bei sich (sogenannt on-premise) anbieten möchte, investiert man viel in Hardware, hat Probleme mit Datenbankgrössen, Backup oder einer Wiederherstellung im schlimmsten Fall eines Ausfalls (sogenanntes Desaster Recovery).

Ursprünglich wollte ich Office 365 trotzdem nicht einsetzen, weil die Vereinigung der Schweizer Datenschützer vom Einsatz von Cloudlösungen wie Office 365 abgeraten haben. Microsoft ist der einzige mir bekannte internationale Cloudanbieter, der den Forderungen nachgekommen ist und erfüllt neu die Forderungen der Datenschützer. Nun steht dem Einsatz von Office 365 in Schulen aus rechtlicher/datenschutztechnischer Sicht nichts mehr im Wege.

Um erste Erfahrungen zu sammeln, kann man sich für eine 30-tägige Testversion registrieren.

Welches Modell
Grundsätzlich gibt es 3 Möglichkeiten, wie man Office 365 einsetzt. Diese sind unter http://blogs.office.com/2014/05/13/choosing-a-sign-in-model-for-office-365/ genauer beschrieben. Nach einem ersten Durchsehen favorisiere ich das mittlere Modell, bei dem die Passwörter über “Directory Sync” mit dem lokalen Active Directory synchronisiert werden. Aber mal schauen, was die weiteren Abklärungen und Tests ergeben.