massaraksch

Hi,
 
grundsätzlich ist SendAs natürlich auch bei Hybrid möglich. Man muß die Online-User/Gruppe einfach mit SendAs auf das Online-Objekt (Mailuser) der OnPrem-Mailbox berechtigen. Also mit:
 
Add-RecipientPermission -Identity OnPremMailbox -Trustee USER/GROUP -AccessRights SendAs
 
Voraussetzung ist, daß alle Objekte synchronisiert (also OnPrem und Online als Mailobjekte vorhanden) sind.
 
Kurz gesagt: Das SendAs-Recht muß in der Umgebung gesetzt werden, wo sich der User befindet, der senden will (oder halt in beiden Umgebungen).
 
PS: Das "ACLableSyncedObjectEnabled" hat damit eigentlich nichts zu tun. Und du mußt auch nichts hin-und-her-migrieren.
 

Hi,
 

Das heißt also, in der Autodiscover.xml, die Outlook über den Dialog "E-Mail-Autokonfiguration testen..." (Strg-Rechtsklick auf Outlook-Symbol im Systray) erhält, steht die korrekte SMTP-Adresse der PublicFolderMailbox drin? Und diese SMTP-Adresse hat eure über Autodiscover auflösbare Maildomain, z.B. wie PublicMailbox1@contoso.com?
 

Der Registryzweig ...\16.0\... gilt für alle Versionen ab Office 2016 (Office 2016, Office 2019, Office 2021, Office 365)
 
Click-to-Run oder nicht ist dabei Wurst.
 
PS: Und HKEY_LOCAL_MACHINE hat damit auch nix zu tun.
 
PPS: Wenn es einen Reg-Schlüssel und/oder Wert nicht gibt, dann muß man ihn einfach erstellen.

Hi,
 
evtl. sind die auf den Client heruntergeladenen Dateien des Offline Adressbuchs (OAB) kaputt/nicht aktuell.
 
Könnte man mal weglöschen:
"%userprofile%\AppData\Local\Microsoft\Outlook\Offline Address Books\xxxxxxxxxxxxx"
 
Aktualität sollt man am Änderungsdatum der Dateien in dem/den Unterverzeichniss(en) erkennen.
 
Die OAB-Dateien werden nach Outlook-Neustart "irgendwann" wieder heruntergeladen (oder man schubst das über "Senden/Empfangen -> Senden-Empfangen-Gruppen - Adressbuch herunterladen" manuell an.
 
Könnte auch sein, daß das OAB auf den Exchange selbst kaputt/nicht aktuell ist.
Kann man auch manuell updaten lassen (Exchange Management Shell):
Get-OfflineAddressBook | Update-OfflineAddressBook
 

Hi,
 
mittels "Search-AdminAuditLog" sollte man das meiste finden. Allerdings nicht direkt die vollständige Shell-Befehlszeile, aber zumindest das Exchange-Cmdlet an sich und die verwendeten Parameter.
 
Beispiel (zeigt die Aktionen der letzten 15 Minuten in einem GridView Fenster):
 
Search-AdminAuditLog -StartDate (get-date).AddMinutes(-15) | Out-GridView  
Das hilft vielleicht weiter.

Hi,
 
mit ThrottlingPolicies hat das nichts zu tun.
 
Ist sicher das alte Thema der "MaxObjsPerMapiSession" in den Reg-Einstellungen für den Store-Dienst (MSExchangeIS).
 
Managed Store Limits in Exchange 2016 and Exchange 2019 | Microsoft Learn
 
Müsste in diesem Fall der Wert für "objtMessage" (Default 250) sein.
 
PS:
Nicht gleich wahnsinnig hoch setzen, evtl. mit 500 anfangen und schauen, ob die Meldung weg ist. Leider muss nach Anderung der MSExchangeIS neu gestartet werden, also evtl. kurze Unterbrechung für Clients.
 

Hi,
 
mach mal
Get-MailboxFolderPermission -Identity $element':\Kalender' oder Get-MailboxFolderPermission -Identity $element":\Kalender" Sollte beides gehen.

Hi nochmal,
 
hab mal etwas "gespielt"... In der Tat könntest du ein anderes Attribut dafür "mißbrauchen".
 
"Position" (AD-Attribut: title) ist für Gruppen nicht verfügbar. Aber Abteilung (AD-Attribut: department) ist ein legitimes Gruppenattribut.
 
Das Setzen des Attributs "department" geht in der AD-Benutzerverwaltung nur indirekt, über die Registerkarte "Attribute Editor" (vorher über View - Advanced Features aktivieren). Wäre natürlich etwas mühsam.
 
In der Shell mit Set-ADGroup. Beispiel:
 
Set-ADGroup EU-AT-V-S -Replace @{department='AT Salesteam Vienna'}
 
Hinweis: Attribut löschen mit Set-ADGroup EU-AT-V-S -Clear department
 
Falls es viele sind, könnte man das halt etwas scripten und über eine CSV-Liste und foreach in die Gruppen "reinblasen". Ist mir jetzt zu viel... Da hilft sicher das Scripting-Forum 
 
Dann wird deine Beschreibung bei Gruppen in der GAL in der Spalte "Abteilung" angezeigt.
 
Im Offline Adressbuch dauert das natürlich wie üblich ca. 1 Tag (falls man das nicht manuell forciert).
 
PS: Die im Outlook angezeigten Spalten kannst du IMHO nicht ändern.

Hi,
 
siehe: Attributes synchronized by Azure AD Connect | Microsoft Docs
 
msExchExtensionCustomAttribute1..5 -> This attribute is currently not consumed by Exchange Online
 
Scheint also nicht supportet in EXO.

Hi,
 
das könnten Kontakteinträge aus einem versteckten Ordner "Recipient Cache" im Postfach sein (ich glaube, existiert seit Ex2013). Dieser ist allerdings nur sichtbar/bearbeitbar mit speziellen Tools (z.B. MFCMapi).
 
Ob diese Einträge evtl. über "Optionen - E-Mail - Autovervollständigen-Liste leeren" entfernbar sind weiß ich jetzt nicht (der Adresscache der Autovervollständigung ist ja eigentlich eine andere Sache).
 
Pfad über MFCMapi:
Root\IPM_SUBTREE\Kontakte (bzw. Contacts)\Recipient Cache
 

Hi,
 
bei dir geht es laufend durcheinander, was den Aufbau deiner CSV und des Befehls betrifft. Nur die Bezeichnungen (Felder) der CSV können im Befehl verwendet werden und keine anderen... Also bring Ordnung rein.
 
Beispiel:
Du kannst nicht $_.ExternalEmailAddress verwenden, wenn in der CSV das Feld "WindowsEmailAddress" heißt.
 
Falls deine CSV wie zuletzt von dir beschrieben aussieht... also folgende kommagetrennte Angaben:
 
Displayname,WindowsEmailAddress,Company
 
Dann kann dein Befehl auch nur so aussehen:
 
Import-Csv .\test.csv | % { New-MailContact -Name $_.DisplayName -ExternalEmailAddress $_.WindowsEmailAddress -OrganizationalUnit "domain.local/OU/..." -whatif }
 
Hinweise:
Die Parameter -Name sowie -ExternalEmailAddress sind erforderlich (mandatory), alle anderen optional.
Name wird automatisch auch Displayname, wenn Displayname nicht extra angegeben wird.
Der Parameter "-whatif" dient zum Testen, damit man nicht gleich live Tausende evtl. falscher Objekte erzeugt). Nach Test/Prüfung dann einfach weglassen.
Ach ja, -Company kann man mit New-MailContact nicht setzen, sondern nur mit Set-Contact.
 
Nachtrag: Aus alter Faulheit habe ich % für ForEach genommen.

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,
 
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,
 
 
Klar funktioniert das ;)
 
 
Das ist hier normal.
Besagte Meldung kommt dann, wenn man in der Shell eine DynGruppe mit Angabe des Parameters "-RecipientFilter" erzeugt. Das ist dann ein sog. "Custom"-Filter, der nicht vom AdminCenter verarbeitet wird.
Deine DynGruppe müßte einen "Precanned"-Filter haben.
 
Guggst du:
 
Get-DynamicDistributionGroup Testgruppe | select name,reci*
 
-> RecipientFilterType  : Precanned
 
 
Eigentlich so:
$var = Get-DynamicDistributionGroup Testgruppe Get-Recipient -RecipientPreviewFilter $var.RecipientFilter -OrganizationalUnit $var.RecipientContainer  
Kein Problem.

Hi,
 
bei Problemen einfach mal den Befehl direkt im CLI testen...
E:\>for /f %i in ('TASKLIST /NH | FIND /C ".exe"') do Set AnzahlTasks=%i "|" kann syntaktisch an dieser Stelle nicht verarbeitet werden. Aha?
E:\>for /f %i in ('TASKLIST /NH ^| FIND /C ".exe"') do Set AnzahlTasks=%i E:\>Set AnzahlTasks=76 E:\>echo %AnzahlTasks% 76 Voila! Das Pipe-Zeichen "escapen" mit ^
 
(nicht wundern... in der Batch natürlich wieder doppelte % nutzen)

Hi,
 
RemainingTrialPeriod: 00:00:00
 
klingt doch erstmal gut.
 
Und die Anzeige des Serverstatus im Manager kann veraltet sein (das ist keine Echtzeitanzeige).
Mal mit "Organisationsstatusdaten erfassen" aktualisiert?

Nachtrag: Beim Org-Status im Manager müsste auch ganz unten stehen
 
"Letztes Update: IRGENWANN. Klicken Sie hier, um auf die aktuellsten Daten zuzugreifen."

Hi,
 
Abwesenheitsregel konfiguriert? Siehe Pig...
 
(dummerweise tauchen diese nicht im normalen Regel-Assi auf, auch nicht mit Get-InboxRule)

Hi,
 
evtl. hilft "Update-StoreMailboxState":
 
https://technet.microsoft.com/en-us/library/jj860462%28v=exchg.150%29.aspx
 
Schlecht allerdings, wenn die 14 Tage schon vergangen sind... Restore.

Hallo,
 
 
Das ist korrekt. Transportregeln verhalten sich da ähnlich (unschön) wie die Client-Regeln (OWA/Outlook) und werten nicht die eigentliche SMTP-Adresse aus sondern holen sich vom Empfänger die primäre Adresse und vergleichen damit.
 
Man könnte aber in einer Transportregel den Mailheader (To, bei Bedarf auch Cc) auswerten.
 
Für eine OWA-Client-Regel hatte ich das mal da beschrieben:
http://www.msxforum.de/community/index.php/Thread/15293-OWA-Regeln-und-Namensaufl%C3%B6sung/?postID=86821#post86821
 
Bei einer Transportregel muß der auszuwertende Header konkret angegeben werden, also z.B.:
 
HeaderMatchesMessageHeader: To
HeaderMatchesPatterns: {dein Kriterium}
 
Wenn du die Transportregel nur auf externe Absender einschränkst (FromScope: NotInOrganization), dann bräuchtest du eigentlich auch kein weiteres Kriterium (also dieses ExceptIfFromAddressMatchesPatterns).
 
Gesundes neues Jahr noch...