massaraksch

Hi, evtl. könnte auch helfen, über GPO den Wert "ExcludeLastKnownGoodUrl" zu setzen. Beschrieben u.a. hier: https://support.microsoft.com/en-us/help/3073002/after-migration-to-office-365--outlook-doesn-t-connect-or-web-services

Hi, ...was sehr wahrscheinlich auch die Ursache des Fehlers ist. Könnte man prüfen, indem man den ActiveSync-Zugriff des betroffenen Users für eine Weile unterbindet und das Verhalten beobachtet. Hatte auch mal einen ähnlichen Effekt, daß fast alle Mails sofort nach Eintreffen aus dem Posteingang "verschwanden" (wie sich herausstellte, in einen neu erstellten Ordner "Junk" verschoben wurden). Ursache war die amoklaufende Spam-Funktion eines Samsung-Androiden.

Hi, könnte sein, weil der Host mail.domain.local noch auflösbar/erreichbar ist. Wäre er das nicht, müsste sich Outlook per Autodiscover neu konfigurieren.

Hi, ich würde trotzdem auf Exclaimer tippen, denn genau diesen Text (wörtlich) würde dieser laut Manual im Standardfall einfügen. Vielleicht ist irgendwas mit deinen Exclaimer-Regeln falsch... http://docs.exclaimer.com/Signature-Manager-Exchange-Edition-User-Manual_DE.pdf (Seite 77ff) Also... RTFM ;) PS: Ich nutze und kenne Exclaimer selbst nicht, habe nur mal schnell das Manual gecheckt. PPS: Prüfe die "Bedingungen". Nicht das der Exclaimer doch auf "Alle Nachrichten" (ohne Einschränkung) wirkt.

Hi nochmal, Get-OfflineAddressBook | select * Was steht bei "Server" drin? Wenn da kein Postfachserver drinsteht (sondern vielleicht ein "reiner" CAS, oder ein gar nicht mehr vorhandener?), dann Return zu: http://www.mcseboard.de/topic/212064-oabs-lassen-sich-nicht-aktualisieren/?p=1346889

Hi, vielleicht das? "Verschieben des Offlineadressbuch-Generierungsprozesses auf einen anderen Server" https://technet.microsoft.com/de-de/library/bb125184(v=exchg.141).aspx

Hi, evtl. ist der Grund dieses Outlook-Verhalten: http://www.mcseboard.de/topic/210718-autoarchivierung-generell-probleme-mit-pst/?p=1335215

Hi, zum Ursprung: $targetdb = (get-mailboxdatabase -status | sort DatabaseSize -desc | select -Last 1).Name In $targetdb hast du dann den Namen der kleinsten Datenbank. Will man die mit dem meisten freien Platz: $targetdb = (get-mailboxdatabase -status | sort AvailableNewMailboxSpace | select -Last 1).Name

Hi, das ist halt der Urknall der Microsoft-IT, der Zeitpunkt Null :) Powershell: [DateTime]::FromFileTime(0)

Hi, immer schrittweise vorgehen: Teste die Befehle einzeln in der Shell... Bringen die dir keine Fehler? Also: [datetime]$heute = 25.02.2018 23:23:23 Was passiert? Get-ADUser -properties passwordlastset,samaccountname Was passiert? Tipps: Ich würde so machen: $heute = get-date(25.02.2018 23:23:23) Und bei get-aduser fehlt dir der Filter: get-aduser -filter * ... PS: Wieso ist heute eigentlich der 25.02.2018... Hab ich etwa Winterschlaf gehalten? :cool:

Hi, schau mal, ob in der Eigenschaft "AuditDelegate" des zu überwachenden Postfachs die Aktion "FolderBind" konfiguriert ist: (AuditDelegate deshalb, weil ein Admin mit Vollzugriff als "Delegate" gilt) get-mailbox POSTFACH | select name,audit* Wenn nicht, dann hinzufügen. Geht mit set-mailbox POSTFACH -auditdelegate ... (Hint: nicht nur den Wert FolderBind eintragen, sondern addieren) In der Doku steht zwar, das wäre für Delegate standardmäßig aktiviert, ist aber wohl doch nicht (immer) so. https://technet.microsoft.com/en-us/library/ff459237(v=exchg.141).aspx

Hi, den Mailweg könnte man ja prinzipiell auch in den Header-Zeilen (einer ordentlich empfangenen Mail) nachvollziehen. Und dann die entsprechenden Systeme anschauen/prüfen. PS: Bei einer Regel im Outlook müßte die Mail auf jeden Fall im Messagetracking-Log des Exchange auftauchen.

Hi, ich denke, der fehlende Parameter -Force ist der Grund beim Delete-Item... Im Beispiel von Board Veteran steht's drin. Bei der DeleteFolder-Methode des Scripting.FileSystemObject erreichst du das mit dem zweiten Parameter "$true". Also funktioniert's damit im Gegensatz zu deinem Remove-Item.

Tut mir leid, aber muß darauf beharren: Mindestens seit Powershell 2.0 :cool: Begründung: 1. Ich hab's live vor mir. 2. https://technet.microsoft.com/en-us/library/ff714569.aspx

Nur so nebenbei... Get-Counter gibts schon seit mindestens PS 2.0, also eigentlich seit der Powershell-Steinzeit ;) PS: Für Exchange z.b. einfach mal ein Get-Counter -ListSet *exchange* machen... Oder für alles: Get-Counter -ListSet * | Out-File CounterList.txt

gci | select name,creationtime oder gci -file | select name,creationtime

Hi, Copy&Waste? Will sagen, vielleicht den Befehl irgendwoher kopiert und dabei zwischen netsh und interface einen (unsichtbaren) Zeilenumbruch erwischt?

Hatte ich ja auch vorgeschlagen ;)

Interessanter Link. Danke. Gut zu wissen, wenn man einen Postfix mit dynamischer Adressprüfung davor hat...

Siehe oben - "Nachtrag"

Hi, weil EWS nun mal kein ActiveSync ist. Eben ein anderes Protokoll und hat mit ActiveSync nichts zu tun. Nachtrag - Steuerung EWS-Zugriff: https://msdn.microsoft.com/de-de/library/office/dn467892(v=exchg.150).aspx

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.