Photogregor

Damn, hätte schwören können, dass ich das probiert und nicht hinbekommen habe. War wieder ne lange Nacht. Aber ja: Habe mir jetzt mit Get-ExchangeCertificate die Thumbprints anzeigen lassen, dann mit Get-AuthConfig | fl CurrentcertificateThumbPrint das Zertifikat anzeigen lassen, das gerade in Verwendung ist. Anschließend habe ich das doppelte Zertifikat über den EAC gelöscht (nach Prüfung des Thumbprints natürlich). Und alles funktioniert. Hast recht, Norbert. Thanks!

Hi, ich habe im EAC an den Zertifikaten meines Exchange 2013 rumgefummelt und offensichtlich einen Fehler gemacht. Jetzt habe ich plötzlich zwei "Auth"-Zertifikate. Beide sind laut EAC gültig, es gibt keinen erkennbaren Unterschied. Auf der Kommandozeile sehe ich lediglich unterschiedliche Thumbprints (Get-ExchangeCertifcate). Eine Funktionsbeeinträchtigung kann ich zwar nicht erkennen, aber das sieht einfach ziemlich dämlich aus. Hat jemand eine Idee, ob bzw. wie ich eines dieser Zertifikate wieder los werde? Regards Stefano

Hallo allerseits, muss mich entschuldigen, dass ich so lange nicht geantwortet habe - ihr wisst ja, die Arbeit. Aber eure Beiträge haben mich letztlich in die richtige Richtung gepusht, insbesondere der Hinweis von Alith Anar auf DNS. Ist ja meisten DNS, wenn was nicht geht. Zwar habe ich kein reines Split-DNS eingesetzt - wenn ich das richtig verstanden habe, hätte ich dafür den DNS im internen Subnetz konfigurieren müssen und dann in der Firewall für die Abfrage dieses DNS zusätzliche Löcher bohren müssen -, sondern ein nettes Feature meines SoHo-Routers benutzt (Draytek 2860). Dort kann man Einträge hinterlegen, bei denen man für ein bestimmtes Subnetz IP-Adressen mit einem FQDN verbindet - also ein Quasi-DNS. Konkret habe ich also den externen Namen der Mail-Domäne mit der internen IP-Adresse des Servers im .0.0.-Netz verknüpft - und schon funktionierte das. Was Robert schrieb, habe ich nicht so ganz verstanden, denn meines Wissens hat die Unterscheidung zwischen "schnell" und "langsam" in den Anywhere-Optionen mit der Verbindungsgeschwindigkeit bzw. einer 64KBit-Grenze zu tun, nicht mit der Domänenzugehörigkeit. Aber sei's drum - wollte euch noch kurz danken, Stefano

Hallo, vielen Dank für den Input. Zu Euren Fragen: 1. Exchange 2003 auf SBS 2003 2. Alle beteiligten Systeme sind aktuell (Client: Office 2010 / Windows 8.1) 3. das Notebook ist nicht Domänen-Mitglied 4. der DNS ist standardmäßig per SBS-Wizard konfiguriert 5. das Notebook erhält seine IP-Daten über einen zweiten DHCP, der auf der Firewall läuft; die DNS-Adressen des Clients verweisen auf die IP-Adressen des Providers, die externe Adresse wird also intern nicht aufgelöst. Ich hatte, inspieriert von Aliths Frage nach dem DNS, den FQDN mal in die Hosts-Datei eingetragen und auf die interne Server-Adresse im 0er Subnetz zeigen lassen, dann beide HTTP-Optionen deaktiviert (für schnelle und für langsame Verbindung). Das bewirkt dann in der Tat, dass Outlook sofort in das 0er Netz geht und die Verbindung herstellt. Aber diese Einstellungen werden natürlich Probleme machen, wenn das Notebook on the road ist. Das mit dem Hinweis auf das Doppelposting hat sich jetzt ja erledigt, oder? Danke nochmal, LG, Stefano

Hallo Forum, jemand Ahnung von Outlook Anywhere? Habe mich irgendwie verzettelt. Folgendes: Das Chef-Notebook soll im Office und unterwegs Outlook machen können, Anbindung im Office per WLAN. Zum Schutz des verkabelten Office-Netzes (192.168.0.0) habe ich ein WLAN-Subnetz eingerichtet (.1.0) und in der Firewall den BYOD-Geräten den Zugang zum 0er Netz versperrt. Nur das Chef-Notebook erhält Zugriff über WLAN auf die SMB-Ports (wegen Offline-Synchronisation). Was ich aber nicht hinkriege ist, Outlook dazu zu bewegen, im Office-WLAN von HTTP auf TCP umzuschalten und den Mail-Server direkt zu kontaktieren. Stattdessen zeigt das Syslog der Firewall, dass Outlook auch im internen WLAN-Netz den externen FQDN anspricht, also quasi nach draußen geht und wieder zurück kommt. Die Verbindung funktioniert dann, dauert aber rund 1,5 Minuten, bis sie steht. Nur, wenn ich die Option, bei langsamen Netzen über HTTP zu verbinden, ebenfalls deaktiviere, verhält sich Outlook wie gewünscht und Syslog zeigt einen direkten TCP-Zugriff auf den Mail-Server im 0er-Netz an. Also zwei konkrete Fragen: 1. Warum geht Outlook bei einer 100MBit schnellen WLAN-Anbindung über HTTP, obwohl das Häkchen für HTTP nur bei den langsamen Verbindungen gesetzt ist? 2. Warum dauert es 60 - 90 Sekunden, bis die Verbindung zum Exchange steht (DSL-Leitung der Telekom)? Vielleicht hat ja jemand eine Idee, wo mein Denkfehler liegt. :-) Saludos, Stefano

Hi Weingeist, ein interessanter Beitrag. Du meinst: Dazu hätte ich folgende Frage: Inwiefern ist ein Patchmanagement erforderlich - ich lebe seit Jahren wie gesagt bei meinen kleinen / SBS-Netzen ohne - und wieso wäre ein Patchmanagement mit VM, VSS etc. kein Thema mehr? Verstehe hier nicht so ganz den Zusammenhang... Man hat bei der von mir skizzierten 2-VM-Lösung drei Betriebssysteme (inkl. Host), aber mengenmäßig machen die 100 - 200GB an OS-Daten ja nicht soviel aus. Ansonsten ist allerdings das Backup-Thema deutlich komplexer als beim SBS. Bei letzterem habe ich einfach eine Lizenz vom Backup Exec 2010 und sichere Daten und OS auf ein Band und bin für ein Disaster Recovery gerüstet. Meine Recherchen zum "SBS 2012" mit den VMs haben ergeben, dass es da nichts Vergleichbares gibt. Systembedingt, weil man ja die Backup-Software auf dem Host installieren und dann in die VM "hineinschauen" muss. Und man kommt anscheinend nicht ohne ein zusätzliches Plattensubsystem für die Sicherung aus, die also auch noch im Server Platz finden müssten (alte SBS sind ja oft Single-Server mit internem Tape Drive, die in kleinen Büros stehen), weil sich Nutzerdaten und VMs nicht einfach auf ein Tape schreiben lassen. Warum? Wenn beim SBS nur eine Box erforderlich war für DC, Exchange etc. und wenn Hardware-Redundanz in einem kleinen Unternehmen aus Kosten- und Platzgründen nicht geht, dann sollte die 2-VM-Lösung auf Basis des Server 2012 R2 doch auch ausreichen, es sei denn, Hyper-V wäre instabiler als ein alter SBS. Hast du ein Beispiel für eine solches Backupkonzept? Definitiv. Man will das On-Premise-Modell unattraktiv machen. Was meinst du hier mit Dienst? Eine komplette VM? Besten Dank und Gruß, Stefano

Wenn ich 50 Clients hätte, würde ich nicht den SBS einsetzen. Und um die Office-Servicepacks habe ich mich nie kümmern müssen, die hat der Client-Update-Automatismus bei meinen Kunden einfach installiert. Ich strebe für den Kunden und mich kostengünstige, will heißen: wartungsarme Lösungen an. Die Entscheidung, den WSUS links liegen zu lassen, war (neben der, den Servern die üblichen Antiviren-Software-Katastrophen zu ersparen) der Hauptgrund, dass mich meine Kunden zum Meister eines geräuschlosen und sicheren Netzwerkbetriebes gekürt haben. Wozu ein Script installieren, wenn doch keine Ressourcen verbraucht werden? Und wozu überhaupt etwas tun, wo es doch auch ohne jeglichen Eingriff geht? Du hast da etwas falsch verstanden: Es ist zwar schön und durchaus ehrenhaft, ein System beherrschen zu lernen, aber mit Blick auf den Kunden ist das falsch, es ist Frickelei, es kostet Geld und Zeit, es ist l'art pour l'art. Sich die Frage nach dem Verhältnis von Aufwand und Ertrag nicht zu stellen ist das traditionellste und größte Manko in der IT. Wenn sich die Clients alle selbst über das Internet betanken können und der entsprechende Mechanismus so überaus zuverlässig wie bei den MS-Betriebssystemen der letzten Jahre, dann Finger weg von Zusatz-Software, die lediglich ein funktionierendes System durch ein zu verwaltendes System ersetzt. Als WSUS-Nichtbenutzer muss ich nichts anfassen, skripten, verschieben. Ich will das auch nicht. Sonst könnte ich mir ja eine Linux-Maschine hinstellen - da sagen die Leute auch immer "Wenn das nicht funktioniert liegt das nur daran, dass du dies und das und jenes nicht verstanden oder falsch konfiguriert hast". Ich lasse es einfach und meine SBS-Clients sind allesamt und ohne jeglichen Eingriff immer uptodate. Der WSUS macht auch hier und jetzt wieder Ärger, er verstellt den Blick auf Wichtiges, nämlich die Ablösung des SBS durch schlankere Nachfolgesysteme. Die Frage, die auch für euch entscheidend ist, lautet: Was machen wir in der Nach-SBS-Ära?

Ich habe das meinen Kunden einfach erspart. Der WSUS ist halt ressourcenintensiv, man muss dann schon mal die Systempartition von zig Gigabyte befreien. Es ist auch spaßig dem WSUS mal mittels Taskmanager bei der Arbeit zuzuschauen. Meines Erachtens ist es sinnfrei, für Updates den simplen und bombensicheren Client-Automatismus zugunsten einer unergonomischen Verwaltungslösung abzulösen. Das Internet quillt über mit WSUS-Problemen.

Hi CoolBlue, Ja, die Lizenzkosten sind enorm und das Backup/Restore/Disaster Recovery ist auch nicht trivial. Aber MS hatte ja auch geplant, die Unternehmen in die Cloud zu dirigieren und nicht, teure Onpremise-Lizenzen zu kaufen. Nachdem das Cloud-Thema seine Akzeptanz eingebüßt hat müssen jetzt Alternativlösungen her. Kannst du das näher ausführen? Ich wäre ja froh, wenn ich das Cloud-Thema noch verkauft bekäme. Was steht in diesem Modell beim Provider und was beim Kunden? Regards, S. Hi Path, Der Server 2012 hat halt schon ein paar interessante Features und EOL ist halt noch ein paar Jahre später. Außerdem habe ich den SBS 2011, wie gesagt, als Feature-Monster und träge betrachtet. Ich habe keinen Kunden, der Sharepoint benutzt, ich habe keinen Kunden, der den WSUS benutzt (die Clients machen das selbst), aber alles läuft mit und ist ineinander verflochten. Ich bevorzuge schlankere Systeme. Beim 2011 warte ich nach einem Doppelklick auf eines der Verwaltungs-GUIs nicht selten eine Minute, bis es gestartet und bereit ist. Die Cloud sehe ich (bzw. meine Kunden) auch nicht mehr als state of the art, aber die Technik des Servers 2012 doch schon. Ich würde mich ungerne für die nächsten 6 Jahre von neuen Features wie SMB 3 und dem erneuerten Direct Access ausschließen. Auf der anderen Seite hast du aber insofern vielleicht recht, dass, wenn der Zug in die Cloud tatsächlich nicht so läuft, wie MS das plant, vielleicht doch wieder On-Premise-Features auf Basis des Server 2012 entwickelt werden. LG, Stefano

Soll heißen immer und ausschließlich gemäß Standard- bzw. Wizard-Setup, nicht wahr? Da ich meine ersten SBS nie mehr richtig hinbekommen habe, wenn ich mich mal nicht an die Wizards hielt, war das für mich immer Grundgesetz. :-) Der SBS ist ja nicht gerade nebenher administriert und die nicht so hoch integrierte 2012er-Lösung potentiell wartungsärmer. Aber damit habe ich, wie gesagt, noch keine Erfahrung, insbesondere mit der Frage, ob das Zusammenspiel zwischen 1 x Host und 2 x VM den "Komplexitätsgewinn" gegenüber dem SBS nicht wieder aufhebt. @Norbert Du spielst wohl auf die Probleme des Exchange 2013 auf Server 2012 an. Aber der Exchange 2010 wäre doch auch keine schlechte Option für den Server 2012 (R2), oder siehst du das anders? LG, Stefano

Hi Günther, danke für deinen Kommentar. Dass eine einzelne Lizenz quasi drei Installationen abdeckt, habe ich verstanden. Du hast recht: Der Host muss der Server mit der Hyper-V-Rolle installiert sein, nicht als Core. Dazu kommen dann noch zwei VM mit jeweils einem Server 2012 - und all das ist mit einer Lizenz abgedeckt. Ein solches System ist natürlich deutlich teuer als ein SBS, weil man den Exchange separat kaufen muss. Aber dennoch empfand ich den SBS 2011 immer als zu hoch integriert, zu viel Balast mit Sharepoint, WSUS etc. Und der Server 2012 bringt offensichtlich interessante Neuerungen, insbesondere SMB 3. Insofern würde ich den also bevorzugen, allerdings nur dann, wenn sich die oben genannte "SBS-Ersatzkonfiguration" mit den zwei VM sowohl vom Installations- als auch vom Wartungsaufwand rechtfertigen lässt. Danke nochmal, Stefano

Hallo Forum, seitdem der SBS mit der aktuellen Server-Technologie nicht mehr fortgeführt wird, es aber zahlreiche SBS-2003-Installationen gibt, die in 2015 ihr Lebensende erreichen, müssen wir uns nach einer Alternatvie umschauen. Eine davon wäre der SBS 2011, der ja noch überall erhältlich ist. Aber ich fühle mich nicht wohl dabei, eine Technik zu verkaufen, die nicht mehr state of the art ist. Also muss man sich mit dem Server 2012 anfreunden. Eine Möglichkeit ist, einen relativ preiswerten 2012 Essentials aufzusetzen und die Exchange Dienste in die Cloud zu bringen (Hosted Exchange und/oder Office 365). Aber ich finde nur noch wenige Kunden, die heutzutage bereit sind, ihre Daten auszulagern. Also denke ich an die "SBS 2012"-Option: Eine Hyper-V-Core-Installation mit einer VM als DC und einer zweiten VM als Exchange Server. Da das für mich Neuland ist würde mich sehr freuen, wenn diejenigen mit Erfahrung mit dieser Konstruktion kurz ihren Senf zu folgenden Fragen geben könnten: 1. Ist es ratsam für einen alten SBS-Hasen, aber 2012-Novizen (mit ein wenig ESXI-Erfahrung) sich an eine Hyper-V-Core-Installation mit zwei VMs zu wagen oder gibt es zu viele Stolpersteine? 2. Ist diese Hyper-V-Konstruktion genauso verlässlich und stabil wie die alten SBS? Habt Dank für eine Teilhabe an euren Erfahrungen, Stefano

Hallo Forum, neues Problem im Zusammenhang mit dem Thema "Outlook - Anhänge - Winmail.dat": Beteiligt sind ein Versender - Win7 x64 mit OL 2007 - und zwei Empfänger - Win7 x64 mit OL 2003. Alle haben HTML als Mail-Format eingestellt. Der Versender verschickt an beide Empfänger (beide mit Semikolon getrennt im "To:"-Feld, wie üblich) die Datei ABC.XLS, bei dem erstgenannten Empfänger kommt der Anhang an, beim zweitgenannten Empfänger nicht. Der Versender benutzt ein Mail-Konto bei 1&1, die Empfänger sitzen in meiner Firma und senden / empfangen über einen Exchange 2003. Wenn ich im Postfach des ersten Empfängers in den Header der Mail hineinschaue, so ist dort von einem Anhang "ABC.XLS" die Rede - dies ist der Empfänger, der den Anhang erhalten hat. Schaue ich beim zweiten Empfänger in den Header, ist dort von einer Winmail.dat die Rede - es ist jedoch keinerlei Anhang ersichtlich, auch nicht per OWA, auch die Größe der Mail lässt mit ein paar KB nicht darauf schließen, dass der Anhang nur versteckt ist. Hat jemand eine Idee, wo man da ansetzen kann? Vielen Dank für einen Tipp im Voraus und beste Grüße, Stefano

Hallo Günther, danke für die Antwort, gute Idee. Ich habe einen Ordner per Outlook angelegt (angemeldet am Server wieder als Administrator). Wenn ich dann im ESM auf die "Clientberechtigungen" schaue, differieren die leicht: der Administrator ist "Besitzer", Anonym ist "Mitarbeiter", aber Standard ist jetzt "Autor". Und wenn ich dann per OWA auf diesen Ordner zugreife, funktioniert das. Klar ist mir aber immer noch nicht, warum ich als Administrator, Odnerersteller und "Besitzer" per OWA nicht auf den im OP beschriebenen ÖO zugreifen kann!? Ich habe dieses unbestimmte Gefühl, da irgendwas nicht verstanden zu haben... :-) Danke und beste Grüße, Tim

Keine Idee, liebe Forenmitglieder? Was habe ich an dem Berechtigungssystem falsch verstanden? Ihr wisst das doch bestimmt! :) Grüße, Tim