Microsoft hat meine Session zu PowerShell DSC (Arbeitstitel “Windows PowerShell 5.0 DSC: The not too deep dive”) ausgewählt, somit werde ich also auf dem Microsoft Technical Summit 2016 in Darmstadt als Speaker dabei sein – das zweite Jahr in Folge also. Ich freu mich drauf!
Die genaue Agenda steht noch nicht fest, aber alle Speaker und Sessions könnt ihr hier schon sehen:
https://www.microsoft.com/germany/technical-summit/agenda.aspx
Schreibe einen Kommentar...Die “Übernahmemigration” (Englisch: Cutover-Migration) ist eine nette Option, um alle Postfächer eines Exchange-Servers in einem Rutsch nach Office 365 zu migrieren. Allerdings gibt es ein paar Dinge zu beachten. Und manches erfährt man nur durch Ausprobieren, auch das möchte ich euch hier nicht vorenthalten…
Allgemein hin liest man immer wieder, das man mit der Cutover-Migration nur ALLE Postfächer auf einmal (bzw. nacheinander, aber in einem Rutsch) migrieren kann. Das ist so nicht ganz richtig… Insbesondere für Tests vor der eigenen Migration ist es sinnvoll, nur ein paar wenige (Test)Postfächer zu migrieren. Jedoch hat man bei dem Assistenten keine Möglichkeit zur Auswahl. Der Trick ist, die Postfächer vor Office 365 zu “verstecken”. Office 365 liest nämlich einfach nur die Global Address List (GAL, Globales Adressbuch) aus. Wenn dort nun nur die Postfächer drin stehen, die migriert werden sollen, dann wird der Rest einfach ignoriert.
Um jetzt ein Postfach aus der GAL zu entfernen, gibt es zwei Wege:
1 2 | Get-Mailbox | Set-Mailbox -HiddenFromAddressListsEnabled $true Get-DistributionGroup | Set-DistributionGroup -HiddenFromAddressListsEnabled $true |
Mit der PowerShell-Variante werden ALLE Postfächer und Verteiler aus dem Adressbuch entfernt. Danach können die gewünschten Postfächer wieder händisch hinzugefügt werden. Nach der (Test)Migration sollte man dann nicht vergessen, die Postfächer wieder im Adressbuch sichtbar zu machen:
1 2 | Get-Mailbox | Set-Mailbox -HiddenFromAddressListsEnabled $false Get-DistributionGroup | Set-DistributionGroup -HiddenFromAddressListsEnabled $false |
Auf dem Bild ist zu sehen, dass nur 2 (von insgesamt deutlich mehr) Postfächern synchronisiert wurden!
Wichtig ist noch, dass Benutzer, die bereits in Office 365 von Hand angelegt wurden (! – wichtig, das geht nicht bei synchronisierten Benutzern – !), nicht gelöscht werden müssen! Die Cutover-Migration kann diese einfach mit dem passenden Postfach vom Exchange-Server verbinden und auffüllen. Wichtig ist dazu nur, dass der O365-Account als primäre Mailadresse die selber hat wie auf dem Exchange-Server und eben noch keine AD-Attribute synchronisiert wurden.
Schreibe einen Kommentar...Nachdem ich meinen Webcast-Kurs zur PowerShell Pipeline in den letzten Tagen (oder eher Nächten…) fertiggestellt habe, ist dieser nun seit heute auf Channel9 online.
In den nächsten Tagen wird der Kurs dann auch in der Microsoft Virtual Academy (MVA) zu finden sein.
Der Link zur Channel9 Serie:
https://channel9.msdn.com/Series/Fortgeschrittene-PowerShell-Techniken
Was für uns MVPs schon etwas länger bekannt war, wurde heute durch Microsoft offiziell bekannt gegeben (und daher darf ich nun auch darüber schreiben):
Die Windows PowerShell ist seit heute OpenSource! Das Projekt ist auf GitHub zu finden:
https://github.com/powershell/powershell
Außerdem gibt es eine erste Alpha-Version der PowerShell für Linux und MacOS!
(Ubuntu 14.04 / 16.04, CentOS 7.1 und MacOS X 10.11)
Weitere Infos auf dem offiziellen Microsoft PowerShell Team Blog:
https://blogs.msdn.microsoft.com/powershell/2016/08/18/powershell-on-linux-and-open-source-2/
Schreibe einen Kommentar...Im folgenden möchte ich euch einige Code-Schnipsel für die PowerShell zur Verfügung stellen, die das Arbeiten mit Office 365 bzw. einem Exchange Server mittels PowerShell erleichtern sollen. Dabei ist immer kurz angegeben, was der Code macht.
Der Artikel wird regelmäßig ergänzt und erweitert.
1 2 3 4 | Import-Module "PFAD-ZUR-EXCHANGE-PSM-DATEI.psm1" $credential = Get-Credential -UserName "USER@DOMÄNE.DE" -Message "Bitte das Passwort für O365 eingeben!" $ExchangeSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $credential -Authentication Basic -AllowRedirection Import-PSSession $ExchangeSession -AllowClobber >> $null |
1 | Get-DistributionGroup |
1 2 3 4 | $Mailbox = Get-Mailbox "Haiko Hertes" $DN=$Mailbox.DistinguishedName $Filter = "Members -like ""$DN&""" Get-DistributionGroup -ResultSize Unlimited -Filter $Filter |
1 2 3 4 | $Mailbox = Get-MailContact "*KONTAKTNAME*" $DN=$Mailbox.DistinguishedName $Filter = "Members -like ""$DN""" Get-DistributionGroup -ResultSize Unlimited -Filter $Filter |
Wie das Configuration Manager Team auf seinem TechNet-Blog berichtet, steht seit heute das Update 1606 für den SCCM bereit.
Einige der Neuerungen:
Eine komplette Auflistung der Änderungen und Neuerungen ist hier zu finden:
http://technet.microsoft.com/en-US/library/mt752488.aspx
Das Update wird automatisch, aber erst nach und nach verteilt. Wer zu den Ersten gehören möchte, die es bekommen, kann dieses PowerShell-Skript nutzen:
https://gallery.technet.microsoft.com/ConfigMgr-1606-Enable-043a8c50
Viel Spaß damit!
Schreibe einen Kommentar...Da ich diese Woche unterwegs war kommt es etwas “verspätet”: Microsoft hat das Releasedate für Windows Server 2016 und System Center 2016 bekannt gegeben. Das Microsoft Windows Server Team schreibt auf seinem Blog:
We are excited to announce the official launch of Windows Server 2016 will be at the Ignite conference this Fall.
Die Ignite-Konferenz (quasi der Nachfolger der TechEd) findet Ende September (26.-30.09.) in Atlanta statt. Zeitgleich wird also der Release stattfinden – wir dürfen uns also freuen!
Gleichzeitig schreibt das MS Team, dass die aktuelle Technical Preview 5 gleichzeitig die letzte ist und diese auch bereits feature-complete ist, also alle künftigen Funktionen enthält.
Der Download der TP5 kann hier erfolgen:
https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview
Schreibe einen Kommentar...Eine interessante Frage eines Kollegen brachte mich dazu, heute Folgendem auf den Grund zu gehen: Outlook speichert E-Mail-Adressen, die man in der Vergangenheit benutzt hat, um Mails zu senden, automatisch ab und stellt diese beim Eingeben von Empfänger-Adressen als Autovervollständigung zur Verfügung:
Die Frage war nun, ob man diese Adressen irgendwie als normalen Kontakt benutzen kann.
Und ja, man kann! Die Adressen werden in einer (oder bei mehreren Postfächern) mehreren Dateien im Pfad C:\Users\BENUTZER\AppData\Local\Microsoft\Outlook\RoamCache gespeichert:
Das Tool NK2Edit kann nun diese Einträge lesen und Exportieren:
Es ist für den privaten Einsatz kostenlos, für den kommerziellen Einsatz kann es 14 Tage als Testversion genutzt werden, danach muss eine Lizenz erworben werden.
Das Tool ist hier zu finden:
http://www.nirsoft.net/utils/export_nk2_autocomplete_outlook_contacts.html
2 CommentsAuf einem produktiven Exchange 2010 SP3 mit aktuellem Patchstand begegnete mir heute folgendes Problem: Der Mailserver war weder über Outlook noch über OWA erreichbar und wenn man sich per RDP angemeldet hat, dann war nahezu nichts möglich, jede Aktion führte zu einem sich ewig drehenden Sanduhr-Symbol. Keines der Systemsteuerungswerkzeuge oder auch nur die Netzwerkwerk-Adapter-Verwaltung ließen sich öffnen.
Um zunächst erst mal mit dem Server arbeiten zu können, hatte ich ihn im abgesicherten Modus gestartet. Da hier aber auch sehr viele Werkzeuge nicht funktionieren, habe ich alle Exchange-Dienste deaktiviert und die Maschine neugestartet. Jetzt konnte man erst mal wieder arbeiten und mit der Fehlersuche beginnen.
Zunächst hatte ich mit ESEUTIL die Datenbank-Files geprüft, hier war aber alles in Ordnung. Netzwerk, DNS und co. sowieso, DC war auch erreichbar, auch Kerberos-Auflösungen waren kein Problem. Da ich am Vorabend das aktuellste Update Rollup 14 eingespielt hatte, hatte ich dieses im Verdacht und hab es wieder deinstalliert – ohne Erfolg. Der Server reagierte wieder so wie vorher.
Im Eventlog war mir vor allem dieser Fehler aufgefallen:
(Quelle: MSExchange ADAccess | Ereignis-ID: 2114 | Aufgabenkategorie Topologie)
Außerdem noch dieser Fehler:
(Quelle: MSExchange ADAccess | Ereignis-ID: 2102 | Aufgabenkategorie Topologie)
Dort heisst es: “Keine Antwort von allen verwendeten Domänencontrollerservern”. Dies war merkwürdig, weil sämtliche Arten der von mir getesteten Kommunikation mit dem DC funktionierten tadellos, zur Sicherheit hatte ich noch ein dcdiag gegen den DC laufen lassen – ohne Auffälligkeiten. Zur Sicherheit hatte ich noch das Computerkonto sowie den Secure Channel zurückgesetzt die Mitgliedschaft des Computerkontos in den notwendigen Exchange-Gruppen im AD geprüft.
Symptomatisch war, dass sich der Dienst “Microsoft Exchange Active Directory-Topologie” und auch “Microsoft Exchange-Diensthost” relativ problemlos (wenn auch nur mit längerer Wartezeit) starten ließen, aber die “Microsoft Exchange-Systemaufsicht” ließ sich nicht starten!
Nach etwas Suche im Internet fand ich diverse Hinweise. Der erwarte war das Thema IPv6 – tatsächlich hatte mein Vorgänger dies am Exchange Server abgeschaltet. Also das Häckchen wieder rein:
Leider brachte dies – auch nach einem Neustart nichts.
Ein weiterer Hinweis der sich fand, schien mir etwas abwegig, aber da ich kurz vor dem Restore des gesamten Servers stand, habe ich es drauf ankommen lassen und das Computerkonto des Exchange-Servers in die Gruppe der Domänen-Admins aufgenommen. Und tatsächlich, nach einem Neustart des Servers kamen alle Dienste hoch. Damit war mein Kernproblem zwar gelöst, aber ich war mir sicher, die eigentliche Ursache nicht gefunden zu haben, denn es ist IMHO keine Bedingung für Exchange, dass der Server DomAdmin ist. Nach längeren Recherchen fand ich dann den “Übeltäter”:
Eine GPO hatte die Berechtigung für “Manage auditing and security log” (“Verwalten von Überwachungs- und Sicherheitsprotokollen”) auf einen zu kleinen Benutzerkreis festgelegt.
Laut diesem Artikel muss hier auch die Gruppe der Exchange-Server mit eingetragen werden – und zwar für die GPO die auf die DCs zielt!
Das war also das recht kleine Problem mit riesiger Auswirkung!
Jeden Tag fiebere ich nun der endgültigen Umstellung auf Office 365 entgegen – dann gehören derartige Probleme wohl der Vergangenheit an.
Schreibe einen Kommentar...Nur als kurze Info:
Der Termin sowie der Ort für den kommenden Microsoft Technical Summit stehen fest – es geht wieder nach Darmstadt, und zwar vom 6. bis 8. Dezember!
Weitere Details siehe hier: https://www.microsoft.com/germany/technical-summit/default.aspx – dort müsste demnächst auch die Agenda veröffentlicht werden.
Schreibe einen Kommentar...
Zum Ändern Ihrer Datenschutzeinstellung, z.B. Erteilung oder Widerruf von Einwilligungen, klicken Sie hier:
Einstellungen
