Beiträge von MTheis

Zitat

RobertW schrieb:
ja, hat er doch geschrieben: "Exchange....als lokale Ausnahme definiert haben."

Hallo Robert,

laut MS wird die Option "Proxyserver für lokale Adressen umgehen" beim WINHTTP Proxy Dienst mit der Ausnahme <local> definiert. Diese Ausnahme ist auch definitv gesetzt gewesen. Also müsste ich zur Sicherheit dann noch zusätzlich den FQDN des CAS Servers reinsetzen, richtig?

Zitat

NorbertFe schrieb:
Ich kenne solche "Blinkereffekte" beim OOF immer mit involvierten Proxyservern, die die interne Seite der Webservices nicht als lokale Ausnahme definiert haben.

Bye
Norbert

Hallo Norbert,

danke für den Hinweis. Wir stellen gerade von Proxy auf Firewall based Routing um. Besagte Maschine hatte noch unter netsh winhttp show proxy den alten Proxy drin (der auch noch aktiv ist). Nach dem Löschen netsh winhttp reset proxy lief es einwandfrei. Ich werde die Änderung gleich forciert per Softwareverteilung gauf der Domäne durchdrücken. Ich hoffe das es das Problem war.

Gibt es eine Lösung für Konstellationen die den WINHTTP Proxy benötigen?

Gruß, M. Theis

Eigentlich führe ich ja keine Selbstgespräche, aber gibt schon wieder neue Erkenntnisse. Eine meiner Testmaschinen, die gestern den Fehler definitiv nicht hatte, hat ihn jetzt auch :confused:

Und siehe da, das Autodiscover Log sieht auf einmal ganz anders aus:

Ich habe ganz viele Guessmart POP und IMAP Versuche drin stehen (obwohl beide Dienste weder konfiguriert nich aktiviert sind). Beim gestrigen Test waren es nur jeweils ein Versuch. Bei Guessmart SMTP sieht es folgendermaßen aus (anonymisiert):

Hinweis:

Unsere interne Domain heißt genau wie die externe domain.tld
Mailserver ist intern wie extern mail.domain.tld
Sämtliche Zertifikate sind gültig
Outlook konnte ganz normal gestartet werden, ohne Fehlermeldung der Zugriff auf das Postfach funktioniert einwandfrei

Guessmart SMTP: server smtp.domain.tld, port 25, initializing
Guessmart SMTP: server domain.tld, port 587, initializing
Guessmart SMTP: server domain.tld, port=587, ssl=yes, tls=no, spa=no, starting
Guessmart SMTP: server smtp.domain.tld, port=25, ssl=yes, tls=no, spa=no, starting
Guessmart SMTP: server domain.tld, port 25, initializing
Guessmart SMTP: server mail.domain.tld, port 25, initializing
Guessmart SMTP: server smtp.domain.tld, port 587, initializing
Guessmart SMTP: server domain.tld, port=25, ssl=yes, tls=no, spa=no, starting
Guessmart SMTP: server mail.domain.tld, port=25, ssl=yes, tls=no, spa=no, starting
Guessmart SMTP: server mail.domain.tld, port 587, initializing
Guessmart SMTP: server smtp.domain.tld, port=587, ssl=yes, tls=no, spa=no, starting
Guessmart SMTP: server mail.domain.tld, port=587, ssl=yes, tls=no, spa=no, starting
Guessmart SMTP: server smtp.domain.tld, port=587, ssl=yes, tls=no, spa=no, FAILED (0x800CCC0D)
Guessmart SMTP: server smtp.domain.tld, port=25, ssl=yes, tls=no, spa=no, FAILED (0x800CCC0D)
Guessmart SMTP: server mail.domain.tld, port=587, ssl=yes, tls=no, spa=no, FAILED (0x800CCC1A)
Guessmart SMTP: server mail.domain.tld, port=25, ssl=yes, tls=no, spa=no, FAILED (0x800CCC1A)
Guessmart SMTP: server mail.domain.tld, port=587, ssl=no, tls=yes, spa=no, starting
Guessmart SMTP: server mail.domain.tld, port=25, ssl=no, tls=yes, spa=no, starting
Guessmart SMTP: server mail.domain.tld, port=25, ssl=no, tls=yes, spa=no, FAILED (0x800CCC1A)
Guessmart SMTP: server mail.domain.tld, port=25, ssl=no, tls=no, spa=yes, starting
Guessmart SMTP: server mail.domain.tld, port=587, ssl=no, tls=yes, spa=no, FAILED (0x800CCC1A)
Guessmart SMTP: server mail.domain.tld, port587, ssl=no, tls=no, spa=yes, starting
Guessmart SMTP: server mail.domain.tld, port=25, ssl=no, tls=no, spa=yes, succeeded (0x00000000)
Guessmart SMTP: server mail.domain.tld, port=587, ssl=no, tls=no, spa=yes, succeeded (0x00000000)
GetLastError=12002; httpStatus=0.
AutoDiscover internet timeout against URL https://mail.domain.tld/autodiscover/autodiscover.xml
GetLastError=12002; httpStatus=0.
AutoDiscover internet timeout against URL https://mail.domain.tld/autodiscover/autodiscover.xml
Autodiscover to https://mail.domain.tld/autodiscover/autodiscover.xml FAILED (0x800C8203)
Autodiscover to https://domain.tld/autodiscover/autodiscover.xml starting
GetLastError=12029; httpStatus=200.
Autodiscover to https://domain.tld/autodiscover/autodiscover.xml FAILED (0x800C8203)
Autodiscover to https://autodiscover.domain.tl…discover/autodiscover.xml starting
GetLastError=12002; httpStatus=0.
AutoDiscover internet timeout against URL https://autodiscover.domain.tl…discover/autodiscover.xml
GetLastError=12002; httpStatus=0.
AutoDiscover internet timeout against URL https://autodiscover.domain.tl…discover/autodiscover.xml
Local autodiscover for domain.tld starting
Local autodiscover for domain.tld FAILED (0x8004010F)
Redirect check to http://autodiscover.domain.tld/autodiscover/autodiscover.xml starting
Redirect check to http://autodiscover.domain.tld/autodiscover/autodiscover.xml FAILED (0x8004005)
Srv Record lookup for domain.tld starting
Srv Record lookup for domain.tld FAILED (0x8004010F)

Rufe ich die https://autodiscover.domain.tl…discover/autodiscover.xml direkt auf, erhalte ich eine htaccess Abfrage. Logge ich mich dort mit den Domaincredentials de Benutzers ein erscheint folgende XML Ausgabe:

<Autodiscover><Response><Error Time="09:55:16.9654508" Id="1306505312"><ErrorCode>600</ErrorCode><Message>Ungültige Anforderung</Message><DebugData/></Error></Response></Autodiscover>

E-Mail-Autokonfiguration mit einem anderen Benutzerkonto funktioniert auch nicht
E-Mail-Autokonfiguration von einem gleich installierten PC funktioniert
nslookup auf autodiscover.domain.tld gibt die richtige interne IP zurück
abmelden und neu anmelden bringt keinen Erfolg
Neustart des PCs hat in diesem Fall auch nicht geholfen

Verzweifelt

M. Theis

Hier noch einige anonymisierten Ergebnisse vom Outlook 2007 Autodiscover-Test:

Auth Package: Unspecified

Protocol: Exchnage HTTP
SSL: Yes
Mutual Authentication: Yes
Auth Package: Basic

keine weiteren Auffälligkeiten.

Im Protokoll ist dann noch zu finden:

Autodiscover to ....xml starting
GetLastError=0; httpStatus=200.
Autodiscover to ....xml succeeded (0x00000000)

Das ist jetzt alleridngs von einem Client wo es funktioniert. Leide rkann ich auf keiner meiner Testmaschinen im Moment den Fehler nachstellen um ihn näher zu analysieren. Und bei den betroffeen Usern kann ich die Maschinen auch nicht ewig blockieren.

Hallo zusammen,

unsere Mailingumgebung besteht aus 2 Exchange 2010 SP2 URP6 Servern (1x CAS/HUB und 1x Mailbox). Als Clients nutzen Wir Outlook 2007 SP3 unter Windows Vista. Sowohl Server als auch Clients sind mit sämtlichen Updates vom Junipatchday versorgt.

Klingt erstmal alles gut. In Niedersachsen haben die Sommerferien begonnen und somit der Ansturm auf den Abwesenheitsagenten. Der Abwesenheitsagent funktioniert auch. Bei User A,B,C, bei D,E,F nicht, dann wieder ja, dann wieder nein usw. Ich bekomme völlig sporadische Meldungen darüber, dass der Abwesenheits-Agent nicht funktioniert.

Zitat

"Ihre Abwesenheitseinstellungen können nicht angezeigt werden, da der Server zurzeit nicht verfügbar ist. Versuchen Sie es später erneut"

Dieser Fehler ist bei MS hier beschrieben. Dort besagter Hotfix von 2009 lässt sich unter Outlook 2007 SP3 nicht einspielen (angeblich falsche Version). Der Registryeintrag alleine reicht auch nicht aus. Bei einigen Usern half ein Neustart, bei anderen nicht.

Die anderen schalten das jetzt über OWA, sind aber natürlich sehr unzufrieden. Genau wie ich auch

Hinweis:
In den letzten Tagen haben unsere Azubis die Plätze gewechselt und somit neue Profile an PCs bekommen. Dort hakte es auch bei der automatischen Konfiguration des Outlook Clients. Namensauflösung usw. lief aber. Hängt das evtl. zusammen? Ansonsten wurde an der gesamten Outlook/Exchangekonfiguration bis auf hal das Einspielen der Windows Updates nichts verändert.

Ich hoffe einer von euch kann mir dir Augen öffnen, bin hier echt am Verzweifeln.

Gruß, MTheis

Zitat

RobertW schrieb:
Moin,

RMT -> rechte Maustaste....

OMG .. don´t post before coffee

Zitat

Hast Du denn eine Quarantäne konfiguriert? Wenn nicht, darf normalerweise jedes Gerät sich anmelden.

Ja Quarantäne ist als Standard gesetzt.

Wenn das Gerät im ECP gelöscht wird, erscheint es weder über die Abfrage in der PS noch unter "Mobiltelefon verwalten". Synct das Gerät jetzt erneut erhält es jedoch automatisch wieder den Status erlaubt, obwohl der Exchangeserver es nicht kennen dürfte, da es ja nicht unter ActiveSyncAllowedDeviceIDs geführt wird. :-?

Zitat

NobbyausHB schrieb:
Hallo,

Nein.
Send as, send on behalf sind zwei paar Schuhe.

Entweder, oder..

Alles anzeigen

Das ist richtig! Aber wie in dem von mir verlinkten Artikel beschrieben, ist es bei Microsoft wanted by Design, dass wenn z.B. einer Vollzugriff auf eine andere Maildatenbank hat und er gleichzeitig das Recht "Senden im Auftrag von" bekommt, der Exchangeserver automatisch ein Senden als daraus macht. Und dadurch wiederum die Regel für die Mails "Gesendet im Auftrag von..." scheinbar nicht greift.

Zitat

RobertW schrieb:
Moin,

mach aus 14.0 eine 12.0, dann funktioniert der Key auch unter Outlook 2007. Oder mach daraus 11.0 draus für Outlook 2003.

Und alles, was Du als Regkey hast, kannst Du auch in eine GPO packen. Die sind am Ende nichts anderes, das zentrale Verteilung von Regkeys.

Funktioniert leider nicht. Das bewirkt sogar, dass die Nachricht weder bei mir, noch bei der anderen Mailbox unter SentItems landet (Rechte sind vorhanden mit Stufe 6 auf den jeweiligen Ordner). Hängt das mit dieser SendAs / SendOnBehalfAs Geschichte zusammen?

Die Benutzer haben Vollzugriff auf Funktiosndatenbanken wie z.B. Einkauf@ und das Recht Senden im Auftrag von (was ja damit zu senden als wird)

Zitat

NorbertFe schrieb:

Zumindest das ist inzwischen per GPO konfigurierbar.

Bye
Norbert

Hallo Norbert,

auch unter Outlook 2007? Unsere Outlook 2007 ADMX Dateien sind aus 2009 (Stand: SP2). AFAIK gab es zu Outlook 2007 SP3 keine neuen ADMX Dateien. Und in unseren kann ich dazu leider nichts finden.

Oder meinst du KB2181579? Der ist ja leider erst für Outlook 2010.

Bisher denken wir über den Workaround mit KB2632409 nach. Nicht schön, aber zur Not. Allerdings lief das bei uns noch nicht sabuer. Wollen das jetzt noch einmal mit URP6 testen.

Hallo zusammen,

wir setzen Exchange 2010 SP2 ein und haben das Problem, dass ActiveSync Devices (Smartphones) die über das ECP gelöscht (nicht gewiped) wurden sich wieder ohne Bestätigung am Exchangeserver anmelden können, sofenr sie vor dem Löschvorgang das Recht hatten.

Wenn ich also Bei "Benutzer A" vor dem Löschen schaue, steht bei ihm unter ActiveSyncAllowedDeviceIDs die ID seines Smartphones. Nun wird das Gerät über das ECP gelöscht. Das Gerät erscheint auch nicht mehr unter ActiveSyncAllowedDeviceIDs. Triggert der Benutzer nun mit seinem Smartphone einen Sync, kommt das Gerät (welches der Exchangeserver ja nun nicht mehr kennen dürfte) automatisch wieder in den Zustand erlaubt, obwohl die Hausrichtlinie sagt, das es erst genehmigt werden muss.

Lösche ich hingegen das Smartphone mittels Powershell:

Set-CASMailbox "Benutzer A" -ActiveSyncAllowedDeviceIDs $null

fragt er anschließend wieder um Erlaubnis.

Wo ist bei beiden Varianten der Unterschied? Und vor allem: Wo cached oder speichert Exchange 2010 die Info, dass das Gerät schon einmal erlaubt war, wenn ich das in dem Feld ActiveSyncAllowedDeviceIDs nach dem Löschen durch das ECP nicht mehr sehen kann?

RobertW schrieb in einem anderen Beitrag etwas von:

Zitat

EMC:
Empfängerkonfiguration -> Postfach -> Postfach auswählen -> RMT -> Mobiltelefon verwalten...

Leider kann ich den Part RMT bei uns nicht finden. Fehlt mir ein Plugin? Die EMC wird direkt auf dem Exchangeserver ausgeführt.