gelöscht
-
Gesamte Inhalte
808 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von gelöscht
-
-
Ja, Set-User z.B. https://docs.microsoft.com/en-us/powershell/module/exchange/users-and-groups/set-user?view=exchange-ps
Ist fast genauso easy wie eine neue Recipientpolicy.
Oder per AD PowerShell:
foreach ($user in (Get-ADUser -Filter { sAMAccountName -like '*' } -Properties displayName -SearchBase "ou=Externe,dc=yourCompany,dc=com")) { $user.displayName += " (Extern)"; Set-ADUser -Instance $user }
ASR
-
vor 1 Stunde schrieb Nobbyaushb:
Eben
Nein?
Wenn ich es mit New-ExchangeCertificate erzeuge ist es auch nicht "selfsigned", dann macht es das CommandLet.
Der Unterschied zu einem Third-Party CA Signed ist die Vertrauenswürdigkeit. Alles was ich selbst mache, sei es eine CA installieren, mit dem CMDLet, OpenSSL ist grundsätzlich nicht vertraueneswürdig, eben selbst gebastelt.
Supported sind grundsätzlich alle Typen von Zertifikaten die dem hier entsprechen: https://docs.microsoft.com/en-us/Exchange/architecture/client-access/certificates?view=exchserver-2019
Das schließt explizit "Self-Signed", wie immer man das definieren möchte mit ein.
ASR
-
vor einer Stunde schrieb Nobbyaushb:
Self-Signed Zertifikate sind nicht supportet.
Unsinn. Natürlich kann ein x509 Zertifikat von einer eigenen CA, openSSL usw. grundsätzlich verwendet werden. Das ist auch der Default Zustand nach der Installation von Exchange seit 2007. Weiterhin wird in dem Screenshot der CN angemeckert.
Zum Problem. Wenn Du das Problem reproduzierst. Was steht dazu im IISlog der Server? 400, 401,500?
Kannst Du ein Fiddler Trace (mit SSL decryption) für einen der betroffenen User machen? Evtl. findest Du sowas wie: “HTTP Error 400. The size of the request headers is too long”
Funktioniert Autodiscover für diesen User? Auch davon ein Fiddler Trace?
Hast Du Layer4 oder Layer7 am LoadBalancer? SSL Bridging?
ASR
-
vor 2 Stunden schrieb NilsK:
nur mal so als Zwischenruf: Es kann durchaus sein, dass man im Zuge des Designs feststellt, dass Exchange nicht das richtige System dafür ist.
Auch nur mal: per Default kann auch jeder authentifizierte User all diese Attribute per LDAP auslesen, auch "externe". Was immer ihr da für geheime Daten habt, vielleicht habt grundsätzlich einen falschen Ansatz mit den "Externen".
ASR
-
vor 15 Minuten schrieb Bubblegum:
Bestehende Mail Adressen bleiben vorhanden und neue Adressen sollen dann vorname.nachnme.extern@blabla.com heißen.
Ja, mach einfach eine neue RecipientPolicy für die Mailboxen die das bekommen sollen. Die haben bestimmt ein "extern" Attribut das Du verwenden kannst, dann bist Du in 20sec. fertig.
ASR
-
Exchange 2016 CU11 ist jetzt verfügbar: https://www.microsoft.com/en-us/download/details.aspx?id=57388
Daneben ist das Testing für .Net 4.7.2 abgeschlossen und jetzt für 2013 CU21 und 2016 CU11 supported.
ASR
-
Hallo
1. Ja, verwende am Besten den "suspendwhenreadytocomplete" Parameter.
2. Kommt auf "kurz" an. Bei einer Unterbrechung werden "Retries" versucht. Erst nach längerer Unterbrechung wird der Move-Request auf "failed" gehen.
ASR
-
Was genau hat die Frage mit Exchange Server zu tun? Das ist eine reine Client/Outlook Sache.
ASR
-
Gerade eben schrieb NorbertFe:
Weil der vermutlich für die andere Domäne (extern) konfiguriert ist und deswegen ein Problem mit der internen Domäne hat.
Verstehe ich nicht. Im SCP ist eine URL hinterlegt, diese (interne URL) sollte auf den Exchange oder den LoadBalancer zeigen. Diese hat nichts mit der SMTP Domäne zu tun.
ASR
-
vor 42 Minuten schrieb Philzip:
Ich glaube, ich habe des Rätsels Lösung gefunden. Für die interne Domain (.local) war im DNS kein SRV Record für's Autodiscover gesetzt. Dies habe ich nun nachgeholt und bei einem Test-User, der vorher keinen Zugriff hatte, habe ich nun Zugriff.
Dann wäre die Frage: warum funktioniert der SCP Autodiscover nicht (zuverlässig)? Das würde ich überprüfen, vielleicht per GPO für mache deaktiviert?
ASR
-
Du gibst die E-Mail Adresse der PF Mailbox in die Outlook Autodiscover Test Dialog Box ein und kopierst dann den XML Output.
ASR
-
vor einer Stunde schrieb Philzip:
Update: Nach 10 Minuten ließ sich Outlook mit dem Testuser wieder starten - nur dass nun der Public Folder Zugriff fehlt, der vorher mit diesem User normal funktioniert hat.
ok, Du solltest mal den TCP KeepAlive Timeout auf dem Server checken und ggf. korrigieren. Das ist aber ein anderes Thema.
Was ist mit dem Autodiscover Test für die PF Mailbox? Klappt das und kommen die richtigen Einstellungen zurück?
Hast Du hier noch was eingetragen:
Get-MailboxDatabase <2016DB> | fl PublicFolderDatabase
ASR
-
vor einer Stunde schrieb NorbertFe:
Ist das ein single Server (Exchange)? Ich würde mal exemplarisch statt Mapi/http für einen betroffenen User auf Outlook Anywhere konfigurieren. Das geht ja mittels set-casmailbox in Exchange 2016 (Set-CASMailbox -MapiHttpEnabled:$False) und mal beobachten, ob das zu Änderungen führt.
Das nützt leider gar nichts: für die PublicFolder Mailboxen wird jeweils ein separater Autodiscover durchgeführt, und für diese Mailboxen auch weiterhin MAPI/HTTP verwendet. Wenn dann müsste man für die PF Mailboxen MAPI deaktivieren.
@Philzip Haben manche Mailboxen die ein/kein Problem haben einen Eintrag im Property: DefaultPublicFolderMailbox ? Das siehst Du mit
Get-Mailbox <user> | FL DefaultPublicFolderMailbox
Kannst Du mal mit Outlook einen Autodiscover Test für die PF Mailbox machen, z.B. pfmailbox@zensiert.local
ASR
-
-
vor 52 Minuten schrieb Starscream:
das betrifft nur migrierte Postfächer. Die neuen verbinden sich sofort.
Die neuen was? Profile oder Postfächer.
In 2016 darf/kann/soll Outlook selbst gar keine Verbindung zu einem DC/GC aufbauen, das muss immer über Exchange und den dortigen NSPI Proxy gehen. Das war in Exchange 2010 auch schon so (Addressbookservice), funktionierte bei RPC/TCP Verbindungen auch noch mit Verbindung direkt zum DC/GC.
Sind HKEY_CURRENT_USER\Software\Microsoft\Exchange\Exchange Provider hier noch andere Keys drin? z.b. "Closest GC"?
Ziemlich sicher ist dort in allen Outlook Profilen, bei denen es Probleme gibt, eine nicht supportete Einstellung (RegKey/GPO) drin.
ASR
-
Sieht auf den ersten Blick nach Backscatter aus.
Habt Ihr keinen Recipient Filter auf oder vor Exchange?
ASR
-
vor 9 Stunden schrieb pollito:
Nun, wenn es so ist, warum entfernt er unsere X-Zeilen im Header bei den an uns selbst verschickten E-Mails? Eigentlich sieht der Header komplett anders aus – das finde ich nicht wirklich nett…
Header Firewall?!? Gibt es in Exchange schon lange/immer. Die Mails sind ja auch nicht als Intra-Org zu betrachten, kommen ja vom ERP.
Was schreibt ihr denn da tolles rein?
ASR
-
Am 10/3/2018 um 08:37 schrieb meney:
Gibt es allenfalls eine andere Variante für mein Vorhaben? Oder hat jemand eine Idee diese Problem zu lösen?
Grüezi,
mal davon abgesehen dass ich nicht verstehe was das bringen soll, kannst Du das probieren:
Stelle aber besser die Retention Time für "gelöschte Elemente" auf einen längeren Zeitraum, z.B. zwei Jahre. Dann kann der User das sogar selbst wiederherstellen.
ASR
-
vor 6 Minuten schrieb mwiederkehr:
Frage: Wo kann ich nachschauen, aufgrund welchen Kriteriums der Exchange auf die Idee kommt, eine Mail abzulehnen? Vielen Dank!
Mal ins Eventlog geschaut: https://docs.microsoft.com/en-us/Exchange/mail-flow/back-pressure?view=exchserver-2019
ASR
-
Am 9/26/2018 um 14:06 schrieb IxxZett:
Die URL habe ich natürlich angepasst. Mit einem Office365 SharePoint klappt das nicht?
VG Matthias.
Doch klar funktioniert das. Warum liest Du nicht einfach die Guidance dazu? z.B.
https://docs.microsoft.com/en-us/exchange/hybrid-deployment/set-up-document-collaboration
ASR
-
OWA im Browser. Mit Thunderbird kannst Du nur 10% der Funktionalität nutzen.
ASR
-
Per:
Set-OwaMailboxPolicy Default –InternalSPMySiteHostURL <https://my.sharepoint.com> -ExternalSPMySiteHostURL <https://my.sharepoint.com>
ASR
-
vor 32 Minuten schrieb Vinc211:
OK, also eher ein Bug der grade verhindert dass es so funktioniert wie es sollte.
Nein, kein Bug. Ich bin auch nicht sicher ob das funktionieren sollte...
ASR
-
vor 13 Stunden schrieb NorbertFe:
Ja aber dafür mußt du ein Kennwort eingeben und es sogar lokal speichern. ;)
Ja.
Die Speicherung im Windows Credential Store funktioniert in Kombination mit diversen Outlook Versionen auch nicht immer zuverlässig. Da kann es trotzdem zu Passwort Prompts kommen. Send-As + Full Access ist wahrscheinlich besser. Was spricht dagegen?
ASR
Fehler beim setzen der Abwesenheitsnotiz in Outlook - Server zurzeit nicht verfügbar
in MS Exchange Forum
Geschrieben
Alles richtig, aber vollkommen irrelevant: es wurde behauptet dass ein Selfsigned Certificate für Exchange "nicht supported" wäre. Das ist und bleibt falsch.
Und ob jetzt das root Certificate meiner CA "selfsigned" ist oder eben das, das auf dem Exchange Server verwendet wird, ändert nichts an den Herausforderungen die es damit gibt.
Damit zurück zum Thema dem dieser Exkurs nicht hilft.
ASR