=BT=Viper

Ich darf vermelden das es nach den ersten 161 Updates dann funktioniert hat ;)

Die Targeteditionen passen natürlich und laut zig Artikeln im Netz muss es gehen. In einem Artikel ging es einem wie mir und einen Tag später hat es dann funktioniert. ​Na mal schaun was nach dem 171 Updates passiert...

Ich versuche mit DISM /online /Set-Edition:ServerStandard /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /AcceptEula eine Testversion in eine Vollversion zu wandeln, bekomme aber immer folgende Meldung: Tool zur Imageverwaltung für die Bereitstellung Version: 6.3.9600.17031 Abbildversion: 6.3.9600.17031 Fehler: 87 Fehler: Es wurde versucht, ein Windows-Onlinebetriebssystem ohne Angabe eines gültigen Product Key zu aktualisieren. Führen Sie den Befehl erneut aus, und geben Sie einen gültigen Product Key an. Der Key ist ein OEM Key und vertippt hab ich mich natürlich auch nicht. Auch der KMS Key will nicht. Der Server läuft auf einem Hyper-V und wurde von der MS-Test ISO installiert und ist quasi jungfräulich. Ich lass jetzt mal alle Updates laufen. Vielleicht bringt das was. Hat sonst noch jemand eine Idee???

Zur Info, so hats funktioniert: Get-ADGroupMember [GRUPPE] -Recursive | Select -ExpandProperty objectGUID | %{Add-MailboxFolderPermission -Identity "$_ :\Kalender" -User [SMTP der Sicherheitsgruppe] -AccessRights Reviewer}

Das hatte ich natürlich zuerst versucht. Aber dann bringt er die selbe Meldung wie zuletzt.

In dem Fall bekomme ich dann Die Argumenttransformation für den Parameter "Identity" kann nicht verarbeitet werden. Der Wert "System.Collections.ArrayList" vom Typ "System.Collections.ArrayList" kann nicht in den Typ "Microsoft.Exchange.Configuration.Tasks.MailboxFolderIdParameter" konvertiert werden. + CategoryInfo : InvalidData: (:) [Add-MailboxFolderPermission], ParameterBindin...mationException + FullyQualifiedErrorId : ParameterArgumentTransformationError,Add-MailboxFolderPermission + PSComputerName : exchange01.domäne.local

Also wenn ich den Befehl so eingebe: Get-ADGroupMember [GRUPPE] -Recursive | %{Add-MailboxFolderPermission -Identity "$_.GUID:\Kalender" -User Kalenderberechtigung@domäne.com -AccessRights Reviewer} Meckert die PS: Das angegebene Postfach "Domäne.local.GUID/Wedo-User/NAME" ist nicht vorhanden. + CategoryInfo : NotSpecified: (:) [Add-MailboxFolderPermission], ManagementObjectNotFoundException + FullyQualifiedErrorId : [Server=EXCHANGE01,RequestId=220cc254-e962-4359-8268-d62b91a0df1e,TimeStamp=11.01.2016 0 8:52:05] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] 7DE28E8F,Microsoft.Exchange.Management.StoreTa sks.AddMailboxFolderPermission + PSComputerName : exchange01.domäne.local Hat da jemand eine Idee? Mein Problem ist das statt der GUID, folgendes kommt: Domäne.local.GUID/Wedo-User/NAME

Also wenn ich das richtig verstanden habe sollte das dann so aussehen? Get-ADGroupMember Kalenderberechtigung -Recursive | %{ Add-MailboxFolderPermission -Identity $_.GUID:\Kalender -User Kalenderberechtigung@domäne.com -AccessRights Reviewer} Mit der GUID sollte es ja gehen, ist ja eindeutig.

Wobei ich da noch eine Hürde sehe. In der Gruppe die ausgelesen wird, sind weitere Gruppen enthalten.

Na die Namen sind unterschiedlich und folgen auch keinem System. Bei ein paar neueren Usern würde es passen.

Das ist leider nicht der Fall :(

Ja, so in der Art hab ich mir das auch vorgestellt. Aber bin nicht so der Powershel/VBScript Profi... :/

Wie man Berechtigungen einer Gruppe zuweist ist klar. Add-MailboxFolderPermission -Identity <mein benutzer>:\Kalender -User <AD-Sicherheitsgruppe> -AccessRights <Berechtigungsrolle> ​Aber geht es auch das alle User einer Gruppe Zugriff auf die Kalender einer anderen Gruppe haben? Ich will ungern den Befehl für jeden User einzeln ausführen. Kann man da für <mein benutzer> eine Abfrage aller Mitglieder einer Gruppe hinzufügen?

Folgendes Verhalten ist mir jetzt bei mehreren Installationen aufgefallen: Über die OWA wird ein weiteres Postfach geöffnet (oben links unter Administrator -> "Weiteres Postfach öffnen"). Das Postfach wird in einem neuen Tab geöffnet und wird auch korrekt angezeigt. Öffne ich nun Outlook (egal welche Version) werden alle jemals so geöffneten Postfächer angezeigt und können auch nicht geschlossen werden. Dann kommt die Meldung das man es über die Kontenkonfiguration machen soll. Dort sind diese Postfächer aber nicht hinterlegt (Register "Erweitert") und kann somit auch nicht entfernt werden. Kennt jemand diesen Effekt und hat evtl. eine Lösung dafür? Im Web konnte ich bisher nichts dazu finden. Edit: OK, dass Verhalten besteht wohl seit Exch2010. Über einen Threat hier im Board bin ich auf folgendes gestoßen. http://www.andrewparisio.com/2010/12/exchange-2010-sp1-removing.html Ist das noch immer der einzige Weg die Postfächer zu entfernen?

Ah ich verstehe, danke für die Info!

Klar, die lokalen und kurzen Namen sind mittlerweile überflüssig seit ich es mit Split-DNS richtig gemacht habe. autodiscover.example.com und hostname.example.com wären die Namen die ich rein packen würde. (Lync und UM werden nicht genutzt) Die einzige Überlegung wäre die autodiscover.example.com auf hostname.example.com zu ändern. Aber ich vermute mal das ist keine gute Idee.

Momentan nutze ich noch ein selbst signiertes Zertifikat für den Exchange. Dank Split-DNS usw. funktioniert das ja auch super, bis auf den Schönheitsfehler das dem Zertifikat natürlich erstmal nicht vertraut wird. Das soll sich jetzt mit einem gekauften Zertifikat ändern. Jedoch stellt sich jetzt für mich die Frage der "Alternativen Antragstellernamen". Bei meinem eigenen Zertifikat hab ich da einfach alles rein gepackt. Exchange.domäne.de servername.domäne.local servername Domäne.de Domäne.local autodiscover.domäne.de autodiscover.domäne.local Nach meinem Verständnis sollte es ja reichen exchange.domäne.de und autodiscover.domäne.de enthalten zu haben. Oder doch nur Exchange.domäne.de und die URL für das Autodiscover darauf ändern? Ein Zertifikat mit mehreren Adressen kostet ja gleich um einiges mehr. Wie handhabt ihr das?

Es gibt noch einen Weg das zu realisieren. Man legt einfach eine Weiterleitungsregel im Nachrichtenfluss an.

Ja, das CU3 nicht gerade neu ist war mir dann auch aufgefallen. Ich ging eigentlich davon​ aus das man die CUs nicht benötigt wenn man die normalen Updates fährt.

OK, danke... Hatte gehofft es sei mit CU9 behoben, aber leider Fehlanzeige.

Naja... in Exch 2013 eigentlich schon...so irgend wie. ;) Die Weiterleitung tut ja, nur als Kopie nicht. Ich vermute mal das es ein Fehler im Frontend ist. Denn die Beschreibung in der Sprechblase stimmt auch nicht.

Dann fragt man sich wieder warum die Funktion da ist.

Es handelt sich um einen Exchange 2013 mit CU9. Wenn man bei einem E-Mail aktivierten Ordner die Weiterleitung aktiviert und den Haken "Nachricht an die Weiterleitungsadresse und an das Postfach übermitteln." aktiviert, dann werden die Mails zwar weitergeleitet, liegen jedoch nicht wie erwartet zusätzlich im ÖO. Kennt jemand das Problem, bzw. hat eine Lösung dafür? Danke!

Es gibt wohl mittlerweile einen Best Practices Analyzer für EXCH13. Jedoch finde ich den in meiner ECP nicht. Der Exchange hat die Build 775.38 und das CU3 installiert.

Ich hab alles nochmal zurück gerollt und es nach folgender Anleitung gemacht. Damit hat es dann funktioniert. Teil1: http://www.johnlose.de/wp-content/uploads/2013/09/Migrating-Public-Folders-to-Exchange-2013-Part-1-Migration-Deployment-Exchange-2013-Articles-Articles-Tutorials-MSExchange.org_.pdf Teil 2: http://www.johnlose.de/wp-content/uploads/2013/09/Migrating-Public-Folders-to-Exchange-2013-Part-2-Migration-Deployment-Exchange-2013-Articles-Articles-Tutorials-MSExchange.org_.pdf