Jump to content

sunday

Members
  • Gesamte Inhalte

    21
  • Registriert seit

  • Letzter Besuch

Profile Fields

  • Member Title
    Newbie

Fortschritt von sunday

Contributor

Contributor (5/14)

  • Erste Antwort
  • Engagiert
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei

Neueste Abzeichen

10

Reputation in der Community

  1. Prolem hat sich erledigt. Fehler lag darin, dass in der Transportkonfiguration im Exchange Server die maximale E-Mail-Größe auf unlimitiert (unlimited) eingestellt war. Damit kann OWA wohl seit Exchange 2007 SP1 nicht mehr umgehen. Den Wert hab ich über die Powershell mittels set-transportconfig -maxsendsize 100MB angepasst. Anschliessend noch den Server neu gebootetd und es lief alles. Ausführlichere Anleitung unter http://www.danrei.de/dateianhaenge-groesser-als-5-mb-koennen-mit-owa-nicht-verschickt-werden/
  2. Hallo zusammen. Folgendes Problem: Wenn ein Client per IE (oder Firefox) auf OWA zugreift, ist der Mailanhang für den Versand auf eine Größe von 5MB limitiert. Die Datei web.conf unter %ExchangeInstallPath%ClientAccess\Owa habe ich bereits nach der Anleitung unter http://technet.microsoft.com/de-de/library/hh529949%28v=exchg.150%29.aspx für eine Größe von 50MB angepasst Der Server läuft als Postfach und Clientzugriffsserver. Müssen weitere Anpassung vorgenommen werden? Wenn ja, welche? Wäre für Hilfe dankbar.
  3. Danke, werde es mir mal anschauen. Aber warum kommt der Fehler nur, wenn man Outlook auf dem Server startet und nicht auch bei den Clients? Und warum ist der Zugriff auf das Benutzerpostfach trotz Fehler möglich, aber nicht auf freigegebene Postfächer und Kalender anderer Benutzer? Was aber bei den Clients funktioniert? Das ist der Punkt, den ich nicht verstehe. Vom Server und den Clients wird ja das gleiche Zertifikat benutzt.
  4. Tja, ich weiss nur nicht, wo. Das Zertifikat funktioniert ja von nem Client aus, nur eben nicht am Terminalserver. Auch bei lokaler Anmeldung am Terminalserver kommt dieser Fehler. Edit: Muss mich korrigieren, was den Zertifikatsfehler bei OWA angeht. Wenn ich über https://ipdadresse/owa versuche, auf OWA zu zugreifen, kommt der Zertifikatsfelher. Bei Zugriff über https://servername.domaine.local werde ich direkt mit dem Anmeldefenster von OWA verbunden ohne Zertifikatswarnungen. So weit ist doch dann mit dem Zertifikat alles in Ordnung?
  5. Nur ne Warnung vom IE: Das Sicherheitszertifikat dieser Website wurde für eine andere Adresse der Website ausgestellt. Die Sicherheitszertifikatprobleme deuten eventuell auf den Versuch hin, Sie auszutricksen bzw. Daten die Sie an den Server gesendet haben abzufangen. Es wird empfohlen, dass Sie die Webseite schließen und nicht zu dieser Website wechseln. Klicken Sie hier, um die Webseite zu schließen Laden der Webseite fortsetzen Wenn ich dann das Laden fortsetze, komme ich zum Anmeldebildschirm und kann mich auch anmelden.
  6. Hallo zusammen. Nach dem das Forum schon häufig die Lösungsquelle für mich war, stehe ich nun vor einem größeren Problem: Umgebung: Server 2008R2 als DC Server 2012 als RDS Exchange 2013 auf Server 2012, genutzt wird das selbst erzeugte Standardzertifikat vom Exchange Office 2010 Alles mit aktuellen Updates bis zum heutigen Tage. Exchange funktioniert ohne Probleme, so wohl über OWA von intern und extern als auch bei lokaler Anmeldung. Outlook 2010 bringt keine Zertifikatswarnung bei der lokalen Anmeldung am Client. Wenn ich mich aber als User auf dem RDS 2012 einlogge, kommt so wohl bei lokaler Anmeldung als auch über Remote Desktop beim Starten von Outlook 2010 folgender Fehler: ****************************************************************************************** Es liegt ein Problem mit dem Sicherheitszertifikat des Proxyservers vor. Der Name des Sicherheitszertifikats ist ungültig oder entspricht nicht dem Namen der Zielwebsite 'host.domäne.local'. Von Outlook kann keine Verbindung mit dem Proxyserver hergestellt werden (Fehlercode: 0). ******************************************************************************************* (Meldet sich der User lokal an seinem Win7 Client an, verbindet Outlook sich ohne Probleme) Wenn ich die Fehlermeldung mit OK bestätige, kann ich Mails senden und empfangen. Beim Wechsel zum Kalender fragt Outlook dann aber nach Benutzername und Passwort. Den Domänenbenutzer und das Passwort akzeptiert Outlook nicht. Nach Klick auf Abrrechen kann ich jedoch ohne Probleme aud den eigenen Kalender zugreifen. Lediglich der Zugriff auf freigegebene Kalender anderer Nutzer funktioniert nicht. Als Administrator erhalte ich diesen Fehler nicht. Das Exchangezertifikat wurde über die Gruppenrichtlinie an die Computer in der Domäne verteilt; es ist auch beim RDS Server im Speicher "Vertrauenswürdige Stammzertifizierungsstellen" hinterlegt. Die Verbindungseinstellungen, die Outllok sich auf dem RDS per Autodiscover zieht, sind mit denen auf dem Client PC identisch. Ich hoffe, jemand kann weiterhelfen.
  7. Hallo zusammen. Nach dem das Forum schon häufig die Lösungsquelle für mich war, stehe ich nun vor einem größeren Problem: Umgebung: Server 2008R2 als DC Server 2012 als RDS Exchange 2013 auf Server 2012, genutzt wird das selbst erzeugte Standardzertifikat vom Exchange Office 2010 Alles mit aktuellen Updates bis zum heutigen Tage. Exchange funktioniert ohne Probleme, so wohl über OWA als auch bei lokaler Anmeldung. Wenn ich mich aber als User auf dem RDS 2012 einlogge, kommt so wohl bei lokaler Anmeldung als auch über Remote Desktop beim Starten von Outlook 2010 folgender Fehler: ****************************************************************************************** Es liegt ein Problem mit dem Sicherheitszertifikat des Proxyservers vor. Der Name des Sicherheitszertifikats ist ungültig oder entspricht nicht dem Namen der Zielwebsite 'xxx.zzz.local'. Von Outlook kann keine Verbindung mit dem Proxyserver hergestellt werden (Fehlercode: 0). ******************************************************************************************* (Meldet sich der User lokal an seinem Win7 Client an, verbindet Outlook sich ohne Probleme) Wenn ich die Fehlermeldung mit OK bestätige, kann ich Mails senden und empfangen. Beim Wechsel zum Kalender fragt Outlook dann aber nach Benutzername und Passwort. Den Domänenbenutzer und das Passwort akzeptiert Outlook nicht. Als Administrator erhalte ich diesen Fehler nicht. Das Exchangezertifikat wurde über die Gruppenrichtlinie an die Computer in der Domäne verteilt; es ist auch beim RDS Server im Speicher "Vertrauenswürdige Stammzertifizierungsstellen" hinterlegt. Die Verbindungseinstellungen, die Outllok sich auf dem RDS per Autodiscover zieht, sind mit denen auf dem Client PC identisch. Ich hoffe, jemand kann weiterhelfen.
  8. Werde das mal weitergeben. Bis jetzt hat sich der kerl leider nicht mehr gemeldet.
  9. Dann würde ich hier nicht fragen, wo das Problem liegen könnte. Nochmals: der Dienst automatische Konfiguration (verkabelt) ist gestartet und startet ohne Fehlermeldung.
  10. Der Dienst wurde gestartet. Schrieb ich aber auch am Anfang.
  11. War leider nicht die Lösung. Gibt´s weitere Lösungsvorschläge?
  12. Danke für den Lösungsansatz. Das werde ich mal überprüfen, auch wenn ich mir fast sicher bin, dass der Student MS Essentials auf dem Rechner hatte.
  13. Hallo zusammen. Folgende Situation: Client Windows 7 Ultimate soll sich per 802.1x am LAN authentifizieren. Jedoch fehlt unter den Eigenschaften der LAN Verbindung die Registerkarte "Authentifizierung". Der PC ist als Arbeitsgruppen PC eingerichtet, keine Domäne. System ist aktuell, was Updates angeht. Folgendes ist überprüft und eingerichtet: - Dienst "Automatische Konfiguration (verkabelt)" steht auf automatisch und ist gestartet - Dienst "extensible authentication protocol" ist auf manuell und ebenfalls gestartet Wo kann der Fehler noch liegen? (Dass es sich bei dem Besitzer des Laptops um einen türkischen Gaststudenten handelt mit fehlenden Deutsch- und schlechten Englischkenntnissen und das System in türkisch ist, erleichtert die Sache nicht gerade) Ich danke euch schon mal für eure Mühe.
  14. Hat wirklich niemand einen Tipp für mich ???
  15. Hallo zusammen. Folgende Situation: DC = W2k3 64Bit Terminalserver = W2k3 64 Bit DC und TS an Standort A Client an Standord B über VPN an A angebunden.(über DSL) An Standord B befinden sich 2 Netzwerkdrucker, die in der Terminalsession genutzt werden sollen. Nach langen hin und her werden die Drucker in der Terminalsession gemappt. Habe die Drucker, da sie als Netzwerkdrucker nicht gemappt wurden, freigegeben, mit den Anschlüssen LPT2 bzw. 3 nochmals installiert und die lpt Anschlüsse per net use dauerhaft umgeleitet auf den Freigabenamen. Die Clients melden sich per Remotedesktop an. Auf den Clients ist der Universal PCL5 Treiber von HP installiert (es handelt sich um den Laserjet 1522nf und den Colorlaserjet P4014n). Auf dem TS ist der Treiber sowohl in der 32 als auch in der 64 Bit Variante installiert; es handelt sich ebenfalls den PCL5 Universaltreiber. Beim anmelden per Remotedesktop dauert es 3-4 Minuten, bis beide Drucker gemappt sind. Das wäre noch zu ertragen. Wenn jedoch ein Druckauftrag abgeschickt wird, kommt beim Client nichts an. Erst beim trennen der VPN Verbindung erfolgt der Ausdruck. Unter der Druckerverwaltung auf dem Terminalserver erscheint der Druckauftrag jedoch nur für 2-3 Sekunden in der Druckerwarteschlange. Hat irgendjemand ne Idee, woran das liegen könnte ? Habe bis jetzt kaum Erfahrung in der Administration von TS. Bin für jeden Tipp sehr dankbar.
×
×
  • Neu erstellen...