In wenigen Tagen steigt der SysAdminDay (System Administrator Appreciation Day) 2017 in Leipzig. Es gibt noch freie Plätze für die kostenlose Veranstaltung, also meldet euch an:
Wir sehen uns am Freitag!
Schreibe einen Kommentar...Blog von Haiko Hertes zu allen Themen rund um Microsoft, Cloud und Datacenter
In wenigen Tagen steigt der SysAdminDay (System Administrator Appreciation Day) 2017 in Leipzig. Es gibt noch freie Plätze für die kostenlose Veranstaltung, also meldet euch an:
Wir sehen uns am Freitag!
Schreibe einen Kommentar...Heute bin ich über folgendes Problem gestolpert: Bei einem neuen Mitarbeiter enthielt die E-Mail-Adresse im Office 365 einen Unterstrich (“Underscore”) an erster Stelle:
(Zusätzlich wurde nicht die reguläre Domäne sondern eine “@*.onmicrosoft.com” verwendet…)
Die Benutzer werden mittels “Azure AD Connect” vom lokalen Active Directory nach Azure AD synchronisiert und bilden dort die Grundlage für die Office 365 Benutzer. Daher kann man die E-Mail-Adressen auch nicht online ändern, sondern nur on-premise. Im lokalen AD war aber auf den ersten Blick alles in Ordnung:
Nach kurzer Recherche fand ich einen Microsoft KB Artikel, der mich auf die Lösung brachte:
In this scenario, after directory synchronization is run, the special character is replaced by an underscore character. Therefore, the user’s Office 365 email address contains an underscore character instead of the special character.
Dabei wird eine Liste mit “verbotenen” Zeichen aufgeführt (die merkwürdigerweise auch das @-Zeichen enthält…), zu denen auch das Leerzeichen gehört. Bezogen ist das ganze auf die AD-Attribute “mail” und “proxyAddresses”. “Mail” war in Ordnung, aber “proxyAddresses”…
…nicht! Hier war ein Leerzeichen zwischen “SMTP:” und der eigentlichen E-Mailadresse. Nach dem ich dieses entfernt hatte und schnell noch den DirSync mit
Start-ADSyncSyncCycle -PolicyType Delta
angestoßen hatte, war der Benutzer mit seiner korrekten E-Mail-Adresse in Office 365 vorhanden!
1 KommentarWenn man mit Azure AD Sync arbeitet und einen neuen Mitarbeiter im lokalen on-premise Active Directory anlegt, dann kann es einem passieren, dass dieser im Office 365 Portal eine *.onmicrosoft.com E-Mail-Adresse als primäre Mailadresse bekommt, selbst wenn man im AD-Konto die richtige Adresse eingetragen hat:
Das lässt sich über das Office 365 Admin-Portal auch nicht ändern, da der Benutzer eben aus dem lokalen AD synchronisiert wird:
Der Trick besteht darin, im lokalen AD das Attribute “proxyAddresses” zu erweitern (entweder ist es leer oder es enthält bereits einen Eintrag “x500:/o=…”).
Der neue Eintrag muss mit “SMTP:” (Großbuchstaben und den Doppelpunkt nicht vergessen) gefolgt von der gewünschten E-Mail-Adresse (ohne Leerzeichen) bestehen:
Nach der nächsten Synchronisierung sollte es dann auch in Office 365 passen! Viel Spaß damit…
Nachtrag: In meinem Fall existiert kein on-premise Exchange Server! Wenn ihr einen solchen doch habt, dann verändert ihr mit der Änderung des AD-Attributes natürlich auch dort die Mailadresse…
5 CommentsNach einer Migration zu Office 365 kann es sinnvoll bzw. gewünscht sein, alle on-premise Exchange-Server zu deinstallieren. Microsoft selbst beschreibt dies z.B. in der Schritt-für-Schritt-Anleitung für eine Cutover-Migration (Übernahmemigration):
Außerbetriebnahme der lokalen Exchange Server. Nachdem Sie sich vergewissert haben, dass alle E-Mails direkt an die Office 365-Postfächer weitergeleitet werden, und wenn Sie Ihre lokale E-Mail-Organisation nicht mehr benötigen oder nicht planen, eine Lösung für einmaliges Anmelden zu implementieren, können Sie Exchange auf Ihren Servern deinstallieren und Ihre lokale Exchange-Organisation entfernen.
Im Nachsatz dazu heisst es dann interessanterweise:
HINWEIS : Eine Außerbetriebnahme von Exchange kann unerwartete Folgen haben. Vor der Außerbetriebnahme Ihrer lokalen Exchange-Organisation sollten Sie Kontakt mit dem Microsoft-Support aufnehmen.
Ich für meinen Teil wollte in erster Linie den Alten Exchange 2010 loswerden. Vermutlich werde ich später einen neuen Exchange 2016 installieren…
ACHTUNG: Wenn DirSync bzw. Azure AD verwendet werden, dann können AD-Attribute nur on-premise und nicht in Azure geändert werden. Wenn Exchange entfernt wird, können einige Mail-relevante Attribute nicht mehr geändert werden. Einige Attribute könnten zwar über ADSIEdit geändert werden, das wird aber offiziell nicht unterstützt!
Aber reden wir weniger über das WARUM als viel mehr über das WIE…
Wenn man sich nun also entschieden hat, den (letzten) Exchange-Server los zu werden und die Deinstallation gestartet hat, wird man relativ schnell feststellen, dass es nicht ganz so einfach ist! Die Deinstallation stört sich nämlich daran, dass es noch Postfächer gibt:
Nun könnte man natürlich einfach alle Mailboxen löschen (bzw. deaktivieren – löscht man eine Mailbox, löscht man den dahinterstehenden AD Benutzer, also keine gute Idee), aber: Nach dem Deaktivieren der Mailbox hat der entsprechende AD-Benutzer keine E-Mail-Adresse mehr (und er verliert auch auf anderen Attributen die Werte), was durchaus ein Problem für DirSync bzw. eine Synchronisation zu Azure AD sein kann. Was ist nun also der richtige Weg?
Im wesentlichen sind zwei Schritte notwendig:
Die Schwierigkeit dabei besteht darin, dass die E-Mailadresse “zwischengespeichert” werden muss, damit diese dem Mail-Enabled-User zugewiesen werden kann (oder man hat eine Syntax, nach der sich ALLE E-Mail-Adressen bilden lassen, da könnte man das weglassen)
Das Ganze habe ich natürlich mit PowerShell gelöst. Das folgende Skript soll ein Anhalt sein, passt es bitte an eure Gegebenheiten an!
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 | Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010 Import-Module ActiveDirectory $mbxs = Get-Mailbox # This will disable ALL mailboxes! Pay attention... foreach ($mbx in $mbxs) { $adusr = Get-ADUser $mbx.SamAccountName -Properties mail,mailNickname,msExchShadowProxyAddresses,proxyAddresses,UserPrincipalName # Getting Mailboxes mail adress befor disabling it If($adusr.Mail -eq "") { [string]$MailAdress = $mbx.UserPrincipalName } else { [string]$MailAdress = $adusr.Mail } Disable-Mailbox -Id $mbx.Identity -Confirm:$False Enable-MailUser -Id $mbx.Identity -ExternalEmailAddress $MailAdress Set-MailUser -Id $mbx.Identity -EmailAddresses $MailAdress } # Make users MailEnabled users that never had a mailbox $newUsersWithoutMailbox = Get-ADUser -Filter * -SearchBase "OU=Useraccounts,DC=DOMAIN,DC=local" -Properties Mail,UserPrincipalName foreach($user in $newUsersWithoutMailbox) { $FullDistinguishName = “LDAP://” + $user.distinguishedName $AccountEntry = New-Object DirectoryServices.DirectoryEntry $FullDistinguishName $AccountEntry.PutEx(1, “msExchHomeServerName”, $null) $AccountEntry.SetInfo() If($user.Mail -ne "") { [string]$MailAdress = $user.Mail } else { [string]$MailAdress = $user.UserPrincipalName } # Enable-MailUser If((Get-MailUser $user.SamAccountName -ErrorAction SilentlyContinue).RecipientType -ne "MailUser") { Enable-MailUser -Id $user.SamAccountName -ExternalEmailAddress $MailAdress } Set-MailUser -Id $user.SamAccountName -EmailAddresses $MailAdress } |
Nach dem nun keine Mailboxen mehr vorhanden sind, wäre es möglich, dass der Deinstallationsassistent weitere Probleme meldet, u.a. könnten:
vorhanden sein.
Für die Replicas in der Public Folder Database bzw. die Database selbst könnten folgende PowerShell-Aufrufe nützlich sein:
1 2 3 4 5 | Get-PublicFolder -Identity \ -GetChildren | Remove-PublicFolder -Recurse Remove-PublicFolderDatabase -Identity "My Public Folder Database" Get-PublicFolderDatabase | Remove-PublicFolderDatabase –RemoveLastAllowed |
Für das Entfernen der (ggf. letzten) Arbitration Mailbox hilft
1 | Get-Mailbox –Arbitration | Disable-Mailbox –Arbitration –DisableLastArbitrationMailboxAllowed |
Danach sollte es möglich sein, Exchange “normal” zu entfernen:
3 CommentsNur als kurze “Randnotiz”: Wenn man eine Office 365 Subscription hat und seine Benutzerkonten aus einem On-Premise Active Directory nach Azure AD synchronisiert, dann kann man zwar an verschiedenen Stellen Dinge wie Passwort-Reset und andere Self-Service-Angebote aktivieren, diese aber nicht (so ohne Weiteres) benutzen. Der Benutzer bekommt beim Versuch, das Kennwort zu ändern eine Fehlermeldung, in etwa so:
oder so:
Im Wortlaut für die Suche:
“Ihr Konto ist für ein Zurücksetzen des Kennworts nicht aktiviert. Leider hat der Administrator Ihr Konto nicht zum Verwenden dieses Dienstes eingerichtet.”
bzw.
“Sie können Ihr Kennwort hier nicht ändern. Eine Kennwortänderung auf dieser Website wird von Ihrer Organisation nicht gestattet.”
Das Problem dabei ist: Mit dem in Office 365 enthaltenen Azure AD Lizenzen (Entspricht der Lizenzstufe Azure AD Basic) ist das nicht möglich – man bräuchte dazu Azure AD Premium! Und das wiederum wäre nur für dieses eine Feature (wenn man den Rest nicht braucht) in meinen Augen zu teuer…
Zitat aus der Microsoft Doku (https://docs.microsoft.com/en-us/azure/active-directory/active-directory-passwords):
Pricing and availability
Azure AD Password Reset is available in 3 tiers, depending on which subscription you have:
- Azure AD Free – cloud-only administrators can reset their own passwords
- Azure AD Basic or any Paid O365 Subscription – cloud-only users and cloud-only administrators can reset their own passwords
- Azure AD Premium – any user or administrator, including cloud-only, federated, or password synced users, can reset their own passwords (requires password writeback to be enabled)
Heisst also, man kann nur die nicht-synchronisierten Accounts in der kostenlosen Stufe ändern bzw. zurücksetzen lassen.
2 CommentsUnmittelbar vor meiner heutigen Session auf dem Summit hat mit ein Vögelchen gezwitschert, dass die Microsoft Entwickler gerade daran arbeiten, PowerShell DSC in den nächsten Wochen, vermutlich noch im Januar oder Februar 2017, auch in der Deutschen Cloud verfügbar zu machen. Ein Grund mehr, das Ganze mit der bald verfügbaren Free Trial zu testen!
Schreibe einen Kommentar...Wenn man Office 365 Konten hat, die keinem Benutzer fest zugeordnet sind (in meinem Fall für Konferenz-Telefone), dann ist es eher ungünstig, wenn das Kennwort abläuft. Auch bei regulären Benutzern kann es gewünscht sein, dass das Kennwort nicht abläuft.
Wenn der Benutzer aus dem lokalen Active Directory synchronisiert wird, dann kann man diese Option einfach im lokalen AD einstellen. Aber bei einem Benutzer, der nur online existiert geht das nicht. Wie also dort das Ablaufen eines Kennwortes deaktivieren? Natürlich per PowerShell!
Dazu muss erst mit
Connect-MsolService
eine Verbindung mit Azure AD aufgebaut werden. Danach kann dann mit
Set-MsolUser -UserPrincipalName USER@MAIL.DE -PasswordNeverExpires $True
die entsprechende Einstellung vorgenommen werden.
Viel Spaß damit!
Schreibe einen Kommentar...Vor zwei Wochen habe ich nun endlich die E-Mail-Kommunikation meiner Firma auf Office 365 umstellen können. Diese eigentlich gar nicht so aufwändige Projekt war leider durch zu viele kleine Dinge im Alltag zeitlich in die Länge gezogen worden.
Aus den Erfahrungen bei der Migration möchte ich hier ein paar Hürden und Stolpersteine, die mir im Zusammenhang mit Azure AD Connect begegnet sind, erläutern, in der Hoffnung, dass andere diese so umgehen können.
Ich hatte Azure AD Connect bereits aktiviert, bevor ich den Migrationsendpunkt (Migration Endpoint) für die Cutover-Migration angelegt hatte. Danach ließ sich die Option “Übernahmemigration” (Das ist die Cutover-Migration) nicht mehr auswählen, diese war ausgegraut (siehe mein Blogpost vom 12.09.2016)
Erkenntnis: Azure AD Connect erst benutzen, wenn der Migrationsendpunkt angelegt ist. (siehe auch nächster Punkt!) Alternativ kann AD Connect auch wieder abgeschaltet werden: (kann ggf. einige Stunden dauern)
Ich hatte, bevor alle Postfächer durch Cutover-Migration umgezogen waren, schon Azure AD Connect (früher DirSync) auf unseren Systemen installiert und einige Benutzer aus unserem Active Directory zu Azure bzw. Office 365 synchronisiert. Für diese Benutzer konnte ich dann keine Postfächer mehr per CutOver-Migration migrieren, weil dann bemängelt wird, dass es bereits Objekte mit der selben Mailadresse gibt.
Erkenntnis: Azure AD Connect erst benutzen, wenn alle Postfächer migriert sind.
Neben der finalen Mailadresse unserer Public Domain hatten die Exchange-Postfächer (und damit auch die AD Objekte der Benutzer) mehrere Mailadresse, u.a. die der lokalen internen AD Domäne. Diese sind u.a. im Attribut “ProxyAddresses” gespeichert. Die primäre Mailadresse hat dabei ein großgeschriebenes “SMTP:” vorangestellt, alle anderen ein kleingeschriebenes:
Daran aber stört sich anscheinend Azure AD Connect. Darauf deutet auch ein älterer Blog-Artikel bei Microsoft hin. Dort heisst es:
Als Fehler kommt “Das Objekt kann nicht aktualisiert werden, weil die folgenden dem Objekt zugeordneten Attribute Werte aufweisen, die möglicherweise bereits einem anderen Objekt in Ihren lokalen Verzeichnisdiensten zugeordnet sind” – und zwar für jeden User der Domäne.
Also habe ich vorübergehend alle kleingeschriebenen “smtp” durch großgeschriebene ersetzt (ACHTUNG: Das ist nur temporär, in der Zwischenzeit solltet ihr keine Exchange-Konsolen benutzen, da diese damit ein Problem haben, dass es mehrere primäre Adressen gibt! Alternativ könnte man auch alle sekundären Adressen entfernen – das kam für mich aber nicht in Betracht). Dies habe ich natürlich mit PowerShell erledigt:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | Get-ADUser -SearchBase "OU=SOMEOU,DC=MYDOMAIN,DC=local" -Filter * | Get-ADObject -Properties proxyAddresses | ForEach-Object { $ProxyA = $_.proxyAddresses.Replace("smtp","SMTP") ForEach($Adress in $_.proxyAddresses) { if($Adress -like "*@THEDOMAIN.COM") { $ProxyA = $Adress } } $_.ProxyAddresses = $ProxyA Set-ADObject -Instance $_ } |
Selbst nach dem ich dies bei allen Benutzer gemacht hatte kam ausgerechnet für mein eigenes Konto noch immer der selbe Fehler:
Dabei hatte ich meinen Account ebenso behandelt wie alle anderen. Dieses Mal war die Ursache aber eine andere: Es gab noch einen gelöschten O365-Benutzer mit dieser Adresse! Also musst auch noch der gelöschte Benutzer endgültig gelöscht werden. Dies habe ich ebenfalls per PowerShell gelöst:
1 | Get-MsolUser -ReturnDeletedUsers | Remove-MsolUser -RemoveFromRecycleBin –Force |
(Achtung: Das löscht ALLE gelöschten Benutzer endgültig! Will man nur einen einzelnen Benuter löschen geht dies mittels:
1 | Remove-MsolUser -UserPrincipalName Lynn@office365bootcamp.com –RemoveFromRecycleBin |
Danach klappte auch die Synchronisierung des letzten Kontos problemlos…
Die Windows Server User Group Berlin veranstaltet dieses Jahr diverse Azure Bootcamps, u.a. auch in München, und zwar in den Räumen der ppedv AG. Anmeldung und Details zur kostenloses Veranstaltung siehe hier:
https://winsvr.events/event.php?vnr=a-106
Viel Spaß!
Schreibe einen Kommentar...Microsoft bietet einem Blog-Beitrag von Andrew Parson zufolge aktuell für Prüfungen über Prometric kostenlos an. Damit lassen sich 2 Zertifizierungen erreichen:
Für den Microsoft Certified Specialist in Azure muss mindestens eine dieser beiden Prüfungen abgelegt werden:
70-532: Developing Microsoft Azure Solutions
70-533: Implementing Azure Infrastructure Solutions
Um den Microsoft Certified Solutions Associate in Office 365 zu erreichen müssen die beiden folgenden Prüfungen abgelegt werden:
70-346: Managing Office 365 Identities and Requirements
70-347: Enabling Office 365 Services
Die Voucher zum kostenlosen Ablegen der Prüfungen können von hier bezogen werden: http://borntolearn.mslearn.net/goodstuff/p/mcp.aspx
Das Angebot ist nur begrenzt gültig und maximal bis zum 31. Dezember 2014 verfügbar – schnell sein ist also die Devise!
PS: 70-532 ist ein Beta-Examen!
Schreibe einen Kommentar...