Ich stand vor der Einführung von Microsoft Dynamics 365 bei einem Kunden. Generell stellt sich die Frage, ob Dynamics hierbei für die Nutzerauthentifizierung an das Active Directory des Kunden angeschlossen werden sollte oder eine eigenständige, nicht synchronisierte Nutzerdatenbank verwenden sollte.
Beides ist möglich – für die Nutzung des heimischen ADs ist jedoch eine Synchronisierung via Azure erforderlich. Diese Synchronisation aufzusetzen ist zu Beginn etwas fordernder. Das Ergebnis lohnt sich natürlich, da ich dann nur noch einen einzigen Administrationspunkt, nämlich das AD habe. Microsoft selbst rät bei unter 50 Nutzern nicht dazu, da der Aufwand hierfür wohl relativ groß sei.
In meinem Fall waren maximal 15 Nutzer geplant, daher entschied ich mich dazu, die Nutzer manuell anzulegen und die Dynamics-Nutzer also seperat zu administrieren. Natürlich will ich dennoch nicht alle Daten per Hand eintippen, sondern möglichst fehlerfrei 1:1 übernehmen. Bequemerweise bietet Microsoft eine Tabellenvorlage an, mit der Nutzerdaten auf einen Rutsch importiert werden können. Nun müssen nur noch die Daten in die Tabelle. Dazu bietet sich die Arbeit mit Powershell an.
Schritt 1: Export der Nutzer aus dem AD
Dazu reicht es, einfach mit einem bestimmten Kriterium zu suchen. Beispielsweise kann ich mir alle Nutzer ausgeben lassen, die in der AD Gruppe „CRM Nutzer“ Mitglied sind. Dazu muss ich den vollen Pfad zur Gruppe angeben. Die Treffer lassen wir gleich mit den benötigten Spalten ausgeben. Für die Vorabkontrolle bietet sich die Ausgabe in eine Tabelle „grid“ an:
Get-ADGroupMember "CN=CRM Nutzer,OU=Groups,OU=MeineFirma,DC=meinedomain,DC=com" | Get-ADUser -Property * | Select eMailAddress, GivenName, Surname, DisplayName, Title, Department, telephoneNumber, otherTelephone, MobilePhone, Fax, StreetAddress, City, State, PostalCode, Country | Out-GridView
Arbeite ich nicht mit Gruppen, kann ich auch nach anderen Kriterien, wie zb. Feldern des Nutzers suchen, hier den Firmennamen:
Get-ADUser -Filter {company -like "Meine Superfirma GmbH"} | Get-ADUser -Property * | Select eMailAddress, GivenName, Surname, DisplayName, Title, Department, telephoneNumber, otherTelephone, MobilePhone, Fax, StreetAddress, City, State, PostalCode, Country | Out-GridView
So lassen sich bequem die Treffer kontrollieren. Die einzelnen Spalten kann ich nach Belieben in Ihrer Reihenfolge ändern.
Leider ist Microsoft nicht sehr konsequent, was die Verwendung der Felder angeht. So habe ich in Office 365 andere Felderbezeichnungen als im Active Directory (Level 2008). Ich habe mich daher für folgende Zuordnung entschieden:
AD Feld | Office 365 Feld |
eMailAddress | User Name |
GivenName | First Name |
Surname | Last Name |
DisplayName | Display Name |
Title | Job Title |
Department | Department |
telephoneNumber | Office Number |
otherTelephone | Office Phone |
MobilePhone | Mobile Phone |
Fax | Fax |
StreetAddress | Address |
City | City |
State | State or Province |
PostalCode | ZIP or Postal Code |
Country | Country or Region |
Die Zuordnung bleibt aber jedem selbst überlassen. Was der Unterscheid zwischen Office Number und Office Phone sein soll, habe ich beispielsweise nicht herausfinden können. Es ist nur darauf zu achten, Office365 als Nutzernamen gerne die E-Mailadresse möchte – das ist zumindest für das korrekte Tracking von Mails erforderlich. Leider gibt es kein Extra Mailadressen-Feld, sondern dies ist gleichzeitig auch das Anmeldename-Feld. Daher empfehle ich, als Username in Office 365 einfach die Mailadresse zu verwenden, sofern diese die Unternehmens-Domain enthält.
Wer andere Felder sucht, der findet hier eine ganz hübsche Übersicht.
Bin ich zufrieden mit den Ergebnissen, ändere ich den letzten Parameter zur Ausgabe in eine CSV-Datei:
Get-ADUser -Filter {company -like "Meine Superfirma GmbH"} | Get-ADUser -Property * | Select eMailAddress, GivenName, Surname, DisplayName, Title, Department, telephoneNumber, otherTelephone, MobilePhone, Fax, StreetAddress, City, State, PostalCode, Country | Export-Csv 'C:\export\crm-users.csv' -NoType
Schritt 2: Import der Daten nach Microsoft Dynamics 365
Der Import der Nutzer erfolgt zunächst über das Office 365 Admin Center.
Dort auf „More“ -> „Import multiple users“:
Nun wird der Download einer Download einer Beispiel-CSV-Datei angeboten. Dies ist ratsam, um zu kontrollieren, welche Felder in welcher Reihenfolge erwartet werden, denn Microsoft könnte etwas geändert haben. In jedem Fall müssen alle 15 Spalten übergeben werden.
Nun einfach die exportierte CSV-Datei einlesen und auf „Verify“ klicken. Falls Probleme erkannt werden, wird eine log-Datei mit Details dazu ausgegeben. Microsoft rechnet übrigens die Überschrifts-Reihe nicht mit. Reihe 1 ist also die erste Datenreihe unter der Überschrift.
Wichtig: Möchte man einen erneuten Import testen, muss die Maske erst geschlossen werden und der Importprozess erneut gestartet werden!
Bugfixing
Mir sprang beim Import gerne der folgende Fehler entgegen:
[{"Row number":7,"Errors":["Invalid domain name used in username. "]}
Dieser Fehler tritt üblicherweise dann auf, wenn die Domain im Nutzernamen nicht übereinstimmt mit den in Office 365 administrierten Mailadressen. (Siehe Manual)
Einzelne Fehler können ggf. auch per Hand mit einem Editor direkt in der Datei behoben werden. Für größere Bearbeitungen, die Datei in Excel einlesen, bearbeiten und wieder exportieren. Achtung: Excel zerhaut einem gerne die Formate. Ich rate daher dazu, lieber eine saubere Ausgabe in Powershell zu erzeugen und diese notfalls minimalistisch im Editor nachzukorrigieren.
Sind alle Fehler behoben, können die Daten anschließend importiert werden!
Schritt 3: Nutzer zuweisen
Die nun importieren Nutzer haben erstmal keinerlei Produkte – benötigen auch keine Lizenzen. Nun muss also eine Lizenz zugewiesen werden.
Dazu in der aktiven Nutzermaske alle gewünschten Nutzer markieren, dann rechts in „Bulk actions“ auf „edit product licences“:
Über „Add to existing product licence“ kann eine freie Lizenz zugewiesen werden. Wichtig: Es müssen Lizenzen frei sein, bevor diese zugewiesen werden können.
Nun die gewünschten Untermodule ggf. abwählen – Auswirkungen auf die Kosten hat es jedoch nicht 😉
Abschließend empfehle ich noch, das Passwort für die frisch importierten Nutzer zu resetten. Das gilt nur für Office 365 – nicht für das AD. Und dann sind die Nutzer startklar!
Fertig! Oder?
Nein! Denn nun darf der Nutzer zwar die Lizenz benutzen, dadurch hat er aber nicht automatisch Zugriff auf die eigene Dynamics-Instanz. Das Dynamics 365 hat seine eigene Rechteverwaltung.
Dazu in die Dynamics 365 Instanz wechseln, dann unter „Einstellungen -> Sicherheit -> Benutzer wechseln. Dort sollten die importierten Nutzer nun auftauchen – das kann einige Minuten dauern.
Dann alle gewünschten Nutzer einer Funktion markieren und oben im Menü auf „Rollen verwalten“ drücken.
Über das auftauchende Menü kann nun eine Rolle zugewiesen werden, z.b. „Vertriebsmitarbeiter“. Die Rollen sind vordefiniert, können aber auch noch manuell nachjustiert werden.
Und das wars dann auch endlich!
Schreibe einen Kommentar