Jump to content

Domo

Members
  • Content Count

    141
  • Joined

  • Last visited

Everything posted by Domo

  1. Hallo Dukel, Danke für deine Rückmeldung. Die beiden Links habe ich bereits durchgelesen. Grundsätzlich habe ich mich eigentlich für intern.domain.com entschieden. Ich frage mich aber ob dazu noch irgendwelche weitere Konfigurationen (DNS Delegierungen, etc.) notwendig sind. Dazu habe ich leider im Internet bisher noch nichts eindeutiges gefunden und kenne leider auch niemanden der mir hier was nützliches sagen könnte :) Ich möchte nur verhindern dass ich am Ende in meiner brandneuen Umgebung schon Probleme bekomme. Kannst du mir zur Konfiguration evtl. noch etwas detaillierte Hinw
  2. Hallo zusammen, Dann erstell ich noch einen eigenen Thread, sorry ;) Ich bin gerade dabei eine neu AD Struktur aufzubauen. In meiner Ausbildung wurde mir gesagt ich müsse ".local" verwenden, das ist aber wohl heute nicht mehr aktuell. Ich habe mich nun etwas in das Thema eingelesen und würde mich für eine subdomain ala intern.domain.com o.Ä. entscheiden. Muss ich dazu noch irgendwelche weitere Konfigurationen vornehmen als bei der Verwendung von domain.local? Ich hätte jetzt einfach die Subdomain angegeben und als NETBIOS domain.com. Da ich ja onehin nur einen Standort verwende ist ein
  3. Hallo zusammen, Ich hoffe es ist ok wenn ich für mein Anliegen diesen Thread hier benutze :) Ich bin gerade dabei eine neu AD Struktur aufzubauen. Dabei bin ich auf diesen Thread hier gestossen. In meiner Ausbildung wurde mir gesagt ich müsse ".local" verwenden, das ist aber wohl heute nicht mehr aktuell. Ich habe mich nun etwas in das Thema eingelesen und würde mich für eine subdomain ala intern.domain.com o.Ä. entscheiden. Muss ich dazu noch irgendwelche weitere Konfigurationen vornehmen als bei der Verwendung von domain.local? Ich hätte jetzt einfach die Subdomain angegeben und als
  4. Hallo zusammen, Wir verwenden bei einem Kunden servergespeicherte Profile (Server 2012 R2 in Verbindung mit Windows 7 Profile). Ein User erhält seit einer Woche beim Herunterfahren die Meldung, dass einige Dateien (Eine oder mehrere?) nicht synchronisiert wurden. Wenn ich aber testweise files erstelle und wieder lösche funktioniert die Synchronisierung einwandfrei. Zudem stimmt auch die Dateimenge der synchronisierte Elemente überein. Ich habe daraufhin das Profil in ein lokales umgewandelt und den Synchronisierungszielordner neu erstellt. Danach habe ich das Profil wieder in ein serve
  5. Hallo zusammen, Ich habe hier einen von Exchange 2007 migrierten 2013er Exchange mit CU9 installiert. Als Clients werden Outlook 2010 verwendet. Grundsätzlich funktoniert alles einwandfrei (Autodiscover, Mailfluss, etc.). Wenn ich aber bei geöffnetem Outlook aus einem Programm heraus ein Email senden möchte (z.B. Word 2010 -> Speichern und senden), plopt das Anmeldefenster auf. Nach Eingabe des Logins kann das Mail problemlos gesendet werden. Sobald ich aber Outlook neustarte muss ich aus einem Drittprogramm heraus wieder die Logindaten eingeben. Mache ich das ganze bei geschlossenem Ou
  6. Hallo, Dank für die Inputs. Wir verwenden bisher bei all unseren Umgebungen user@domain.local als UPN, Probleme hatten wir bisher damit noch nie... Das werden wir wohl überdenken müssen - Danke! Ich finde es einfach seltsam, dass bei neu erstellten Usern der komplette Autodiscover (trotz domain.local UPN) reibungslos läuft. Lediglich bei bereits vorhandenen Usern versucht Outlook sich krampfhaft mit der Email Adresse anzumelden. Wenn es am falsch konfigurierten UPN liegen würde, müsste es doch auch mit neuen Konten nicht funktionieren oder? LG Claudio
  7. Guten Morgen, Ja, Autodiscover war (peinlicherweise) auch zuerst falsch konfiguriert. :rolleyes: Als UPN wird aktuell die .local Adresse verwendet. Der Administrator, sowie alle anderen neu erstellten User, haben ebenfalls die Netzdomain als Anmeldeadresse. Bei diesen Konten klappt der interne Autodiscover einwandfrei. Aktuell habe ich aber das Gefühl, es ist eher ein "PC Problem" als ein Exchange Problem. Auf dem Terminalserver klappt der Autodiscover auch intern bei den meisten Usern. Auf zwei Computern versucht Outlook sich beim Autodiscover nach wie vor mit der Mailadresse anzumeld
  8. Guten Morgen, Ich gehöre nun wohl auch zu den Leuten die das können :-) Konnte am Wochenende erfolgreich updaten. Das Phänomen ist lustigerweise immer noch dasselbe. Verwende ich einen User den ich neu erstellt habe, funktioniert der interne Autodiscover korrekt. Verwende ich einen User den es vorgängig im Active Directory schon gab, versucht Outlook sich mit der Email Adresse anzumelden. Ich habe nun mal alle Active Directory Attribute überprüft und verglichen, konnte aber keine Differenz feststellen... Hättest du mir evtl. noch eine weitere Idee? Lg Claudio
  9. Hallo zusammen, Ich hoffe der nachfolgende Beitrag ist im richtigen Forum, falls nicht bitte ich um Entschuldigung :) Wir haben bei einem Kunden SBS2011 im Einsatz. In den Outlook Clients wird in der Signatur ein Bild eingefügt. Dieses Bild wurde nun abgeändert (kleineres Format, andere Farben, etc.). Das ganze funktioniert auch wunderbar. Nach einigen Neustarts wird aber die alte Signatur wieder angewendet, bzw. deren Format. Das neue Bild ist dann nach wie vor eingebunden, allerdings auf das Format zusammengedrückt was das alte Bild hatte. Ich habe bereits den Signatures Ordner g
  10. Hallo Norbert, Hm okay, das werde ich wohl mal an die Hand nehmen. Kann ich CU9 bedenkenlos während eines Wartungsfenster installieren? Ich habe bisher erst einmal CU6 installiert, danach traten aber einige Probleme auf (Outlook Profile defekt, Mailflow nicht mehr vorhanden, etc.) Danke nochmals für deine Hilfe :-) LG Claudio
  11. Guten Abend, Zuerst noch kurz zum Autodiscover (intern): Ich hab mich wohl zu früh gefreut. Mit dem Administrator funktioniert das Einrichten automatisch ohne Murren. Sobald ich aber einen User einrichte (natürlich mit dem Profil des Users angemeldet) ploppt wieder die Loginbox auf und Outlook versucht sich mit user@domain.ch anstatt user@domain.local anzumelden. Vielleicht kurz zur Info: Die User existieren im AD schon länger, bisher war aber kein Exchange Server vorhanden. Kann es sein, dass dem Exchange Server der Link ins AD fehlt um die User abzufragen? Grundsätzlich erkennt aber der
  12. Guten Abend Norbert, Ich glaube fast ich habe mich bei der Eingabe des SCP vertippt. Ich habe ihn direkt mal neu gesetzt und jetzt scheint die Autoconfig zu greifen. Hättest du mir netterweise trotzdem noch einen Tipp zu meiner Frage betr. Authentifizierung? :-) Ansonsten warte ich einfach bis September :p LG Claudio
  13. Nochmals danke für die Rückmeldung :-) Im Zertifikate ist autodiscover, remote sowie der Servername selber eingetragen. Das Zertifikat wird auch entsprechend gezogen, sprich ich habe keine Zertifikatswarnmeldung. Zugegriffen wird von extern über den Remote Eintrag. Ist der folgende Gedankengang richtig: In AD integrierte Outlook Clients fragen übers AD den SCP (autodiscover.domain.ch) ab. Danach wird über DNS intern auf den Exchange Server geleitet. Dort versucht sich der Client am Exchange Server anzumelden. Mir ist aufgefallen dass jeweils bei der Passworteingabe die Emai
  14. Hallo Norbert, Danke für deine Rückmeldung. Als SCP habe ich per Powershell "autodiscover.domain.ch/Autodiscover/Autodiscover.xml" eingetragen. Autodiscover.domain.ch zeigt dann im internen DNS auf den Exchange Server. Ist das nicht korrekt so? Grüsse, Claudio
  15. Hallo zusammen, Ich habe hier einen Server 2012 R2 mit installiertem Exchange Server 2013. Konfiguriert habe ich ihn unter anderem mithilfe dieses Artikels: https://technet.microsoft.com/de-de/library/jj218640%28v=exchg.150%29.aspx Grundsätzlich funktioniert der Server wunderbar. Ich habe aber noch zwei kleine Eigenheiten entdeckt, die mir keine Ruhe lassen. Nummer 1: Wenn ich interne Outlook Clients per Autodiscover verbinden lasse muss ich trotzdem den Benutzer und das Passwort eingeben. Per default versucht Outlook sich mit der Mail Adresse anzumelden was logischerweise nicht k
  16. Hallo nochmals, Ich habe für mein Trend Micro Problem die Lösung gefunden und wollt sie mit euch teilen. Vielleicht hat ja jemand mal das gleiche Problem :) Um dieses Problem zu beheben, muss der Prozess mmc.exe in den globalen Einstellungen von Trend Micro ausgeschlossen werden. (Zu finden im Webinterface unter Voreinstellungen -> Allgemeine Einstellungen -> Desktop/Server -> Web Reputation und URL Filter -> Prozess Ausnahmeliste) Danach Agent updaten und die Konsole kann problemlos verwendet werden :) Herzlichen Dank nochmal für die HIlfe Norbert! LG Claudio
  17. Hello, Ja, der Kunde hat eine Firewall. Dort ist aber HTTPS zugelassen und NAT entsprechend konfiguriert.
  18. Die Postfächer liegen eigentlich bereits auf dem Exchange 2013. Der "Vorgänger" Server ist ein Exchange 2007 (SBS 2008). Intern scheint es zu klappen, ich kann es leider nur mit dem Administrator Postfach testen. Dort ist unter Outlook 2010 alles richtig eingestellt und bleibt auch so. Ich habe nun als nächster Schritt mal die Einbindung meines externen Outlook 2013 Clients über Outlook Anywhere getestet. Verbindung, etc. funktioniert alles. Jedoch stellt es mir in den Einstellung immer wieder auf "anonyme anmeldung" um. Dadurch ploppt konstant immer wieder das Anmeldefenster auf.
  19. Hallo, Die remote domain zeigt bereits auf den neuen Server. Ich habe den Eintrag mittels Set-ClientAccessServer nun geändert. Profile kann ich nach wie vor einrichten, Glück gehabt :) Ich habe aber nach wie vor das Phänomen, das öfters beim Anmelden die Anmeldebox aufploppt und hartnäckig wiederkehrt. Mir ist aufgefallen das dann jeweils die Eiinstellung im Outlook Profil unter "Sicherheit / Netzwerksicherheit bei der Anmeldung" auf Anonym konfiguriert ist. Stelle ich dann auf "aushandeln" funktioniert die Anmeldung. Die Einstellung wird aber öfters zurückgesetzt... hättest du mir
  20. Also müsste ich mittels Set-ClientAccessServer für den Exchange 2013 ebenfalls die Remote Domain setzen, korrekt?
  21. Guten Morgen, Ich habe soeben die Zone als domain.com erstellt und die entsprechenden Einträge vorgenommen. Ist mir persönlich lieber wenn ich alles so direkt in einer Zone verwalten kann. Zudem habe ich auch die internen Einträge auf remote.domain.com umgestellt. Rufe ich ClientAccessServer auf, erhalte ich vom bestehenden SBS eine remote.domain.com Zone, vom neuen Exchange erhalte ich aber den lokalen Namen, also ex2013.domain.local/autodiscover... etc. Ist das schlimm, der Name müsste ja auch so aufgelöst werden können oder? Ich habe mal kurz bei unseren bestehenden, fun
  22. Wenn ich das Template öffne sehe ich nichts was annähernd nach "Reg_SZ" oder "Reg_Expand" aussieht. Die GPO wird aber umgesetzt, beim Testuser ist in der Registry unter HKEY_CU\Software\Policies\Microsoft\Office\14.0\Outlook der Wert forcepstpath als REG_EXPAND_SZ hinterlegt mit dem entsprechend Pfad. Im Outlook wird es aber nicht umgesetzt. Aber mal etwas ganz grundsätzliches: Wie würdest du mir empfehlen vorzugehen, wenn ich eine Outlook Archivierung auf einen anderen Pfad legen möchte, unter Einbezug des %username%? Grüsse Claudio
  23. Hups, natürlich :) Der Hinweis lautet: "Erweitere die Edittext Anweisung um ExpandableText, damit es kein REG_SZ wird, sondern ein REG_EXPAND_SZ, daß auch die Variablen "expandieren" kann." Ich denke aber das ganze ist ziemlich veraltet, ist aus einem EIntrag von 2005.
  24. Hallo zusammen, Ich hätte doch noch eine kleine Frage. Ich möchte nun per GPO die Outlook Archivierung einschalten und das PST unter E:\OutlookArchive\Username\User.pst ablegen. Es ist also für jeden User ein Verzeichnis vorhanden und darin wird das PST abgelegt. Outlook meldet jedoch bei Verwendung von E:\OutlookArchive\%username%\user.pst "ungültiger Dateipfad". Irgendwie kann die Variable nicht aufgelöst werden. Im Internet habe ich eine Hinweis zur Veränderung des ADM Files gefunden. Da ich das aber noch nie gemacht habe möchte ich zuerst hier nochmals nachfragen :) Wie muss ich d
  25. Okay danke! Aber nur nochmals fürs Verständis (Tut mir leid wenn ich mit dummen Fragen nerve :( ) Ich erstelle intern Einträge die per remote.domain.com und autodiscover.com auf den internen Exchange Server verweisen. Zudem stelle ich auch die internen Einträge von OA auf remote.domain.com um. Somit können Outlook Clients intern autodiscover einrichten und verbinden sich per remote.domain.com Eintrag. Das Zertifikat wurde ausgestellt für remote und autodiscover, das sollte also klappen. Korrekt? :)
×
×
  • Create New...