Evgenij Smirnov – IT Pro aus Berlin …because IT matters :)

Am 01.09.2018 steigt wieder die CIM Lingen. Dismal bin ich auch dabei, mit einem Vortrag zu „Running Scripts in the Enterprise“ 🙂

… erscheint Anfang April 2019: vorbestellbar auf Amazon

Ab sofort wird mein Blog von netCUP gehostet.

Ich habe ja schon des öfteren über Eigenarten von Sammlungen aller Art in PowerShell berichtet. Heute ein Beispiel aus der Active Directory-Administration.

Nehmen wir einfach mal an, wir haben ein mehrwertiges Attribut und wollen zu diesem einen zusätzlichen Wert hinzufügen. Für diese Beispiel nehme ich msExchExtensionCustomAttribute1, da kann man nichts kaputt machen.

Set-ADUser john.doe -Replace @{msExchExtensionCustomAttribute1=@("A","B","C")}
$user = Get-ADUser john.doe -Properties msExchExtensionCustomAttribute1
$a1 = $user.msExchExtensionCustomAttribute1
Write-Host "Unser Attribut msExchExtensionCustomAttribute1:"
$a1.GetType()
$a1

Nun wollen wir zu $a1 ein viertes Element hinzufügen. IntelliSense in ISE bietet folgendes an:

Auch wenn’s bei nativen PowerShell-Arrays nicht funktioniert, ist Add doch vielversprechend. Probieren wir’s aus:

$a1.Add("D")
Write-Host "`r`nNach dem Add:"
$a1.GetType()
$a1

liefert

Sieht doch super aus, richtig? Der Typ ist derselbe, alle vier Elemente sind wie erwartet da. Nun bleibt also die neue Sammlung zurück in das Attribut zu schreiben und das Ergebnis zu überprüfen:

Set-ADUser john.doe -Replace @{msExchExtensionCustomAttribute1=$a1}
Get-ADUser john.doe -Properties msExchExtensionCustomAttribute1

Doch das Ergebnis ist leider nicht ganz das, was wir erwartet haben:

Das soeben beschriebene Attribut ist leer. Hmmm.

Machen wir das gleiche Spiel und nehmen statt der Methode .Add das PowerShell-eigene Anfügen:

$a1 += "D"

so ist das Ergebnis wie erwartet:

Der alles entscheidende Unterschied ist anscheinend, dass die Operation += die ADPropertyValueCollection in ein System.Array konvertiert. Und dieses wird offenbar von Set-ADUser korrekt interpretiert, sein nativer Datentyp hingegen nicht!

Happy updating!

Ein getrenntes Postfach in Exchange wiederverbinden ist bei den modernen Versionen bekanntlich keine Hexerei und geht sogar an der GUI – einfach in der Postfachverwaltung auf drei Punkte klicken, „Postfach verbinden“ auswählen und auf das entsprechende Symbol klicken:

Hatte der Benutzer vor dem Deaktivieren jedoch ein In-Situ-Archiv, so stellt man schnell fest, dass dieses nun weg ist:

Schaut man ins Active Directory, so stellt man fest: das Archiv ist nicht „vergessen“:

Bei der Lektüre der Online-Hilfe zu Connect-Mailbox fällt dann schnell auf, dass -Archive ein valider Parameter des Cmdlets ist. Man könnte also erwarten, dass bei Verwendung dieses Parameters anhand der Infos aus dem AD auch die Archivmailbox wiederverbunden wird – doch erst einmal wird diese Erwartung enttäuscht:

Schaut man in der Hilfe weiter, so fällt noch etwas auf: In dem Parameter Set, wo -Archive drin vorkommt – und nur in diesem – findet sich noch der Switch -AllowLegacyDNMismatch, welcher als „reserved for internal Microsoft use“ kategorisiert ist. Hmmm. Schauen wir mal:

OK, schon mal kein Mismatch. Trotzdem probieren?

Achso… er will eine Mailbox haben, so richtig mit Version und so? Das kriegen wir doch hin:

…und siehe da:

Happy reconnecting!

Das 2. Quartalsmeeting 2018 der Exchange User Group Berlin steht fest. Es findet bei der JAEMACOM am 31.05.2018 um 18 Uhr statt. Alle Details und Anmeldung über Meetup: https://www.meetup.com/de-DE/EXUSG-DE/events/250512828/

Es gibt noch freie Plätze 🙂

Das nächste Treffen (Q2/2018) der WSUG-B findet am Donnerstag, dem 24.05.2018 bei der COMPAREX AG in Berlin-Adlershof. Details und Anmeldung über Meetup.com: https://www.meetup.com/de-DE/Windows-Server-User-Group-Berlin/events/250092212/

Haben wir uns das nicht alle schon mal gewünscht – eine ordneltiche Hilfe zu den zahlreichen Kommandozeilen-Befehlen? Jetzt, wo man schon dachte, nun ist PowerShell da und es kommt keine CMD-Doku mehr, hat Microsoft sich einen Ruck gegeben und die folgende coole PDF rausgebracht: https://www.microsoft.com/en-us/download/details.aspx?id=56846

Happy commandlining!

Gerade das folgende Announcement des Exchange Teams gelesen: https://blogs.technet.microsoft.com/exchange/2018/04/20/changes-coming-to-the-smtp-authenticated-submission-client-protocol/ . Man beachte den ersten Punkt:

Sent email will now be stored in the Sent Items folder of the mailbox.

Manche Dinge kommen halt 20 Jahre zu spät, aber Hauptsache, sie kommen überhaupt 🙂 Jetzt bleibt natürlich die große Frage:

• Werden wir diesen Change auch in Exchange 2019 sehen?
• Falls ja: Werden wir ihn auch in Exchange 2016 sehen?
• …und wird man das auch pro Mailbox abschalten können, zumindest on premises?

Man kann ja Träume haben…

Leute, die viel SMTP mit Exchange Online verwenden, sollten ihre Versandstrategie allerdings auf den Prüfstand stellen, denn der Preis für den erste Punkt ist natürlich der zweite Punkt:

Only three concurrent connections to our service per mailbox will be allowed. Additional connections will be rejected with the error: 4.3.2 STOREDRV.ClientSubmit; sender thread limit exceeded.

Happy sending!

Nach Ansicht eines deutschen Software-Herstellers ist der wahre Bösewicht aber SMB2. Die folgende Warnmeldung ist kein Scherz:

Die haben sogar einen extra Menüpunkt, der SMB2 auf dem Server abschaltet (wenn man das Programm dort startet). Gut, der Hotline-Mitarbeiter sagte zum Server auch „Hauptrechner“ 😉