massaraksch

Eigentlich müßte MS ja auch nichts "verbessern". Sie sollten einfach nur gewohnte Features nicht "verschlechtern". Der Recipient Filter funktionierte schließlich bis Ex2010 noch korrekt auch bei mehreren Empfängern. Naja, "Produktpolitik"...

Hi, grob gesagt so,,, (Beispiel Ex2010) Migration starten (hier Exchange Management Shell): New-MoveRequest -Identity MAILBOX -TargetDatabase DBNAME -SuspendWhenReadyToComplete (oder halt Get-Mailbox mit geeignetem Filter und dann per Pipe zu New-MoveRequest übergeben) Die Daten werden migriert und dann wird angehalten. Der User arbeitet noch mit dem alten Postfach und "merkt nix" davon. Der MoveRequest bekommt irgendwann den Status "AutoSuspended". Dann nach Lust und Laune: Get-MoveRequest -MoveStatus AutoSuspended | Resume-MoveRequest Dies ermittelt beispielsweise alle automatisch angehaltenen Requests und schließt sie ab (konkret: Synchronisiert die zwischenzeitlich aufgelaufenen Änderungen vom alten in das neue Postfach, schaltet auf das neue Postfach um und entfernt das alte). Nicht zu lange damit warten, da sonst die Synchronisierungs-Differenz immer größer wird und der Abschluß entsprechend länger dauert. Am besten nachts ausführen (der schläfrige Admin macht das per geplantem Task). So kann man das über ein paar Tage oder wie auch immer laufen lassen. Aber immer dran denken, daß man das Sizing auf dem Zielserver im Auge behält. Jeder MoveRequest erzeugt zusätzlich Transaktionsprotokolle in der Größe der migrierten Postfächer -> Korrektes Backup beachten! Probier das einfach mit zwei-drei Testmailboxen aus um ein Gefühl für die Zeiten zu bekommen. In der Exchange-Verwaltungskonsole von Ex2010 lautet der Punkt bei der lokalen Versch.-anforderung "Diese Verschiebung anhalten, wenn sie bereit ist für den Abschluß". Bei Ex2013/16 wird es das sicher auch geben (hab ich gerade nicht vor mir). Ob man das nun manuell mit Mausschubserei macht oder per Script (natürlich testen... der Befehlsparameter "-Whatif" ist auch immer mein Freund) ist natürlich Geschmackssache.

Hi, dann ist wohl das Attribut "msExchDelegateListLink" beim Entfernen des Vollzugriffs nicht ordentlich geleert worden (was normalerweise der Exchange macht). Dieses sorgt über Autodiscover für die automatische Einbindung des Postfachs. Entweder in der AD-Benutzerverwaltung dieses Attribut anschauen (leeren). Oder mit Shell nachschauen: Get-ADUser "SharedMailbox" -Properties msExchDelegateListLink | select -ExpandProperty msExchDelegateListLink PS: Das ist jetzt für OnPremise, wie das bei O365 ist, weiß ich nicht genau, Get-MsolUser oder so ist ja wohl etwas anders...

@BOfH_666 Bin ich eigentlich auch ;) Habe aber trotzdem noch ein paar Exchange 2010 hier rumlungern... Und da läuft halt noch v2.

PS C:\Users\DAU\Documents> Get-Help Get-Help -ShowWindow Get-Help : Es wurde kein Parameter gefunden, der dem Parameternamen "ShowWindow" entspricht. Doofe Powershell v2 :mad: Ja, ab 3 geht's...

Naja, und grundsätzlich hilft ja erstmal immer RTFM ;) help Get-Adobject -detailed respektive: man Get-Adobject -det :eek: PS: Ich hab mir help statt get-help angewöhnt, da help (oder "man") seitenweise ausgibt.

Hi, get-member ist eigentlich genau das. Damit bekommst du alle Methoden und Properties eines übergebenen Objekts. z.B. Get-Item C:\Windows\explorer.exe | Get-Member Ah, da gibt es z.B. VersionInfo... Interessant, was bringt das wohl? Get-Item C:\Windows\explorer.exe | select -ExpandProperty VersionInfo | select * Hm, dann geht sicher auch sowas... (Get-Item C:\Windows\explorer.exe | select -ExpandProperty VersionInfo).FileVersion

Hi, welche Logs sind es denn überhaupt? (wenn es nicht die DB-Transaktionsprotokolle sind, denn DIE will man nicht löschen)

Hi, MS sagt zum Parameter "MaintenanceSchedule" (ich glaube seit Ex2013?): "This parameter has been deprecated and is no longer used." IMHO gilt standardmäßig eine 24*7 Maintenance bei Ex2013/16. Ich habe die Erfahrung gemacht (zwar bei Ex2010, aber wahrscheinlich übertragbar auf Ex2016), daß B-Tree-Fehler nur durch eine Offline-Defragmentierung behebbar sind. Wegen der notwendigen Downtime der Datenbank ist das (natürlich abhängig von der Größe) meist keine Option. Eher also die Postfächer in eine andere (neue) DB verschieben und die alte wegwerfen (oder defragmentieren wenn sie leer ist und dann die Postfächer wieder zurück). Wie man es halt lieber hätte...

Hi, da warten keine "Prozesse" auf Abarbeitung, sondern Lese/Schreibanforderungen. Und errechnete Durchschnittswerte (pro Zeiteinheit) können nun mal auch gebrochene Zahlen sein. Hier ein Dokument mit einigen Erläuterungen zur Datenträgerleistungsüberwachung: https://technet.microsoft.com/de-de/library/aa997558(v=exchg.65).aspx

Hi, Nein, eigentlich nicht. Du meldest dich mit den Anmeldedaten des "Sekundärkontos" an den zusätzlichen Konten des zweiten Servers an. (natürlich unter der Voraussetzung, daß dein "Sekundärkonto" Vollzugriff auf die betreffenden Postfächer hat)

Hi, Hm, naja... Die Fragestellung löst es nicht ;)

Hi, ich würde die "Frage-Logik" umkehren... Welche Gruppenmitglieder sind in der OU (und Sub-OUs)? Get-ADGroupMember Sicherheitsgruppe | where { $_.ObjectClass -eq "user" } | Get-ADUser -Properties CanonicalName | where { $_.CanonicalName -like "domain.com/OU_Name/*" } (where { $_.ObjectClass -eq "user" } filtert eventuelle "Gruppen in der Gruppe" raus) Oder die in der Gruppe enthaltenen Gruppen recursiv mit abfragen: Get-ADGroupMember Sicherheitsgruppe -Recursive | Get-ADUser -Properties CanonicalName | where { $_.CanonicalName -like "domain.com/OU_Name/*" }

Hi, Also auf dem "alten" Server? (dann kann's ja nicht mit dem fehlenden Single Instance Storage zu tun haben, wenn dann würde die DB auf dem neuen Server größer) Und: Was meinst du eigentlich mit "exportieren Postfach"? Was tust du da... etwa in PST exportieren/importieren? Migration heißt doch, man verschiebt (direkt per Move-Requests).

Hi, kleines "Durcheinander"... Get-Recipient "Name öffentlicher Ordner" funktioniert nur für Ordner, die MailEnabled sind. Sagt ja schon der Befehl selbst: Get-Recipient. Und ein Ordner ist nur ein "Recipient", wenn er MailEnabled ist. Get-PublicFolder "Name öffentlicher Ordner" funktioniert nicht recursiv, d.h. man muß selbst den Pfad angeben (das ist ähnlich wie im Dateisystem): Get-PublicFolder "\Ordner\Unterordner\Noch ein Unterordner" Und das ist IMHO unabhängig von der Version. Und nein: Get-PublicFolder "Name öffentlicher Ordner" -Recurse nützt da wohl auch nichts. Eventuell aber so: Get-PublicFolder -Recurse | where { $_.Name -eq "Name öffentlicher Ordner" } Kann aber dauern bei großer Struktur.

Hi, was willst du erreichen? Einfach den gleichen Befehl nochmal ausführen/vorher editieren? Cursortaste Hoch - Enter bzw. vorher editieren (oder mehrmals Hoch um durch die History zu gehen, oder F7 für die History-Liste) Oder willst du den Befehl einfacher (also ohne Prompt und Umbruch) in einen Editor kopieren? -> das geht mit Windows 10 mit den erweiterten Bearbeitungsfunktionen der Shell (siehe Eigenschaften), dann funktionieren die üblichen Tastenkombination zum Markieren/Kopieren/Einfügen, wie z.B SHIFT + Links/Rechts, STRG + A, STRG + C, STRG + V

Hi, gestern wurden Updates veröffentlicht, die folgende Outlook-Probleme (durch die Juni-Patches verursacht) beheben sollen: https://support.office.com/de-de/article/Bekannte-Probleme-mit-Outlook-in-den-Sicherheitsupdates-von-Juni-2017-3f6dbffd-8505-492d-b19f-b3b89369ed9b?ui=de-DE&rs=de-DE&ad=DE&fromAR=1 Siehe Problem Nr. 5 Also Windows-Updates machen... PS: Die Probleme mit der Windows-Suchindexierung sind leicht an der Event ID 36 im Anwendungsprotokoll nachvollziehbar.

Hi, bei einer geschickteren Vorgehensweise übernimmt Exchange solche Änderungen nach meiner Erfahrung sofort: - Dialogfelder Eigenschaften-Mailadressen Mailobjekt A und B gleichzeitig geöffnet - Adresse bei A entfernen -> Übernehmen - Adresse bei B hinzufügen -> Übernehmen Fertig in Sekunden. Wäre auch furchtbar, wenn da eine Unterbrechung von Stunden wäre. Du bist wohl "ungeschickt" vorgegangen, indem du das Postfach einfach gelöscht hast (ohne die Adresse vorher zu entfernen). Evtl. beschleunigt ein Get-GlobalAddressList | Update-GlobalAddressList die Sache. Nachtrag: Sag bloß nicht, daß du POP-Abruf machst... Dann kriegste im Forum gleich Haue ;)

Hi, evtl. das altbekannte Problem: Outlook archiviert Mails standardmäßig nicht nach der Zeiteigenschaft "Erhalten", sondern nach "Geändert". Die Geändert-Eigenschaft wird z.B. aktualisiert, wenn eine Mail in einen anderen Ordner verschoben wird. Laß dir einfach mal die Spalte "Geändert" im Outlook anzeigen... Änderung dieses Verhaltens: HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\xx.0\outlook\preferences ArchiveIgnoreLastModifiedTime = 1 (REG_DWORD) Ist per GPO konfigurierbar, siehe Pig...

Hi, ich weiß jetzt nicht genau, ob es für die externe Buchungsautomatik reicht, die folgende Option zu setzen: Set-CalendarProcessing Raumpostfach -ProcessExternalMeetingMessages $true Für Frei/Gebucht-Anzeige braucht man dann eher Calendar Sharing (Federation Trust). PS: Irgendwo hab ich mal gelesen, daß man für die externe Buchungsautomatik auch noch für jeden "Fremden" einen externen Kontakt anlegen soll/muß. Kannst ja erstmal ohne probieren...

Hi, Bloß nicht! Niemals diese elendigen PST-Files... Machen nichts als Probleme!

Hi, evtl. mal die Queues auf "gestrandete" (defekte/große) Messages untersuchen... Get-TransportServer | Get-Queue | ? { $_.MessageCount } | Get-Message Mehrmals ausführen und schauen, ob da Mails drin sind, die über einen längeren Zeitraum nicht "verschwinden" (also nicht übertragen werden). Die Eigenschaften der Mails anzeigen: Get-TransportServer | Get-Queue | ? { $_.MessageCount } | Get-Message -IncludeRecipientInfo | fl Da steht dann auch Size drin und LastError usw.

Hi, wir hatten das mal mit einem verbuggten "Microsoft CRM Desktop Client". Da hat das Outlook Add-On bei manchen Usern auch 250 MB pro Stunde "LogBytes" produziert. Das läpperte sich zusammen... Ist aber schon paar Jahre her, gab damals ein CRM-Update. Das hat man aber "schön" im ExMon sehen können, wenn man z.b. mal das Update Interval auf 5 oder 10 min. stellte.

Hi, du wirfst immer zwei Sachen durcheinander: Datenbank und Transaktionslogs. Die DB ist EINE Datei, Translogs sind viele (1 MB Dateien). Auch wenn du viele Transaktionslogs hast (weil dein Backup nicht korrekt läuft) wächst die DB nicht notwendigerweise ebenso an.

Hi, aus deinem Link: PS: Evtl. auch noch "msExchESEParamCacheSizeMin" beachten. Habe diese Werte aber noch nicht selbst mit 2013 getestet.