slemke

Hallo, danke für die beiden Links - habe ich mir gerade durchgelesen. Werde in meinem Lab-Setup mich mal weiter in Richtung ADFS / WAP einarbeiten. Schönen Abend, Sebastian

Hallo Norbert, vielen Dank für deine Antworten. Ich arbeite tatsächlich selber im IT-Bereich. Das letzte Mal, dass ich was mit Exchange gemacht habe, war im SBS2003, also schon eine ganze Weile her. Intention ist, das Produkt kennen zu lernen, vielleicht auch mal eine Schulung zu besuchen. Im ersten Schritt habe ich mir den Exchange aus dem Action-Pack geschnappt und los gelegt. Ich glaube auch, ich habe mich ganz gut durchgearbeitet. Jetzt bin ich an einer Stelle, wo ich einfach nicht weiter gekommen bin. Du bist schon bei dem Reverse Proxy, mir fehlte quasi erst einmal ein Überblick, was überhaupt möglich ist – idealerweise mit Vor- und Nachteilen. Deswegen habe ich einfach meine Ideen mal runter geschrieben - und anscheinend auch einiges falsches mit rein geschrieben ;-) Vielleicht etwas unglücklich von mir ausgedrückt. Was ich bisher gemacht habe: Ich habe im Standard-Hosting für das ECP AdminEnabled auf $False gesetzt. Danach habe ich dem Exchange Server eine weitere IP gegeben, auf der ich ebenfalls ECP & OWA eingerichtet habe. Diese IP ist nur intern erreichbar. Somit sollte man extern im OWA Einstellungen vornehmen können, Administrative aber nur intern über die zweite IP, korrekt? Wie gesagt, war ein Gefühl. Jetzt ist natürlich ohne konkretes Umfeld die „Sicherheitsanforderung“ schwer zu greifen. Deswegen mal die umgekehrte Frage: Wie „unsicher“ ist das, wie groß ist die Angriffsfläche hier? Ich meine über Sicherheitsverwundbarkeiten. Schwache Passwörter lassen wir mal außen vor, eine entsprechende Richtlinie war ja sowieso Vorgabe. Ok, klare Aussage – ich wusste schlichtweg nicht, dass das so nicht supported ist (DC / Firewall / Exchange) [Outing off]. Idee war, dass wenn wirklich jemand auf dem Exchange „einbricht“ zunächst einmal noch eine Firewall den DC schützt (deswegen höhere Sicherheit). Benutzerzahl scheint ja unfug gewesen zu sein. Kurzum: Vergessen wir dieses Szenario, unsupported, fällt raus. Ich habe mich hier tatsächlich ein wenig an der Fortigate orientiert und die wäre hier wohl nicht mit der vollen Funktionalität des WAP-Servers vergleichbar. Man hat hier zwar Loadbalancing und SSL Offloading konfigurieren, aber nicht einzelne Unterverzeichnisse für den Reverse Proxy - nur den kompletten Host. (Alternativ könnte man natürlich eine IPS-Signatur schreiben, die den Zugriff blockt, aber das wäre ein wenig von hinten durch die Brust in die Augen). Dafür hat Fortinet zusätzliche Produkte. Zur Sicherheit: Ich habe das Fragezeichen geschrieben, eben weil das so individuell ist. Vielleicht ist es besser zu schreiben „höher als reines Port Mapping“? Siehe auch Antwort zu Szenario 3 – Mit dem WAP müsste man hier differenziertere Möglichkeiten haben, wenn ich alles richtig verstanden habe. - Szenario 5 - Aufbau eines komplett eigenständigen Domänencontrollers mit Exchange, der dann mit einem der vorherigen Szenarien nach außen geöffnet wird. Du meinst jetzt eine eigene AD-Infrastruktur für Exchange? Wieso ist da die Sicherheit höher? Welche und warum? Gedanke war: Was passiert, wenn auf dem Exchange „eingebrochen“ wird, und jemand in den Besitz von Benutzerdaten kommt. Dann hat er auch Zugriff auf weitere Netzwerkressourcen. Wenn man ein eigenes AD & Exchange hat und die Passwörter anders sind (und womöglich diese Kombination aus DC&Exchange in einem anderen Netzsegment steht), hat sich ein Unbefugter nicht Zugriff auf weitere Ressourcen (z.B. Dateien). Mann kann es auch kompliziert machen ;-) Oder bin ich jetzt völlig paranoid ?! ;-) - Zwei Faktor - Wäre aber ggf. interessant. Nur nicht jede Version von Exchange und jeder Client kann damit umgehen. Danke für den Hinweis! Liege ich mit der Einschätzung der Organisationsgrößen in etwa richtig? Hmm... eher nein. Da habe ich wohl ziemlich daneben gelegen. Gibt es trotzdem Erfahrungswerte? Wird zum Beispiel auch Szenario 1 bei Installationen mit (zum Beispiel) mehr als 70 Usern gemacht? Oder eher nicht? Ich versuche, ein Gefühl dafür zu bekommen. Umgekehrt gefragt: Gibt es Szenarien, die sich bei einer gewissen Organisationsgröße per se verbieten? 2. Wird der WAP-Server zu einem Mitglied der Domäne? Oder steht der außerhalb und fragt „in die Domäne rein“? (Hier wird ja auch der ADFS Proxy mit dem WAP mitinstalliert) Was sagt denn die MS dazu? Ich denke du liest soviel. https://technet.microsoft.com/en-us/library/dn383660.aspx Entweder stehe ich kräftig auf dem Schlauch oder wir reden aneinander vorbei ;-) ? Ich meinte das so: Der ADFS Server steht in der Domäne. Ich installiere einen weiteren Server außerhalb der Domäne, der WAP und den ADFS Proxy installiert hat. Geht das so? Dieser Artikel ließ mich das vermuten: http://www.msxfaq.de/internet/wap.htm Danke, Sebastian

Hallo zusammen, man ruhig mit den jungen Pferden..;-) Es ist so wie oben geschrieben, ich habe nichts im Forum gefunden und „nur“ meine Gedanken zusammengefasst. Auch von einem „Bepreisungsmodell“ für den Vertrieb kann nicht die Rede sein, das war überhaupt nicht die Intention. Die Idee war einfach nur, Ansatzpunkte für die sichere Integration zu diskutieren, nicht mehr und nicht weniger. Das ist offensichtlich so nicht rüber gekommen. Ich habe bei meinen Recherchen nicht viel gefunden, auch hier im Board nicht. Es wäre doch prima, wenn man so auch Newbies Ideen an die Hand geben könnte, wie eine Integration aussehen **kann**. Klar, gibt es auch Beratungsfirmen, keine Frage – aber irgendwie muss man sich doch auch in ein Thema einarbeiten. Auch dass das ganze immer sehr individuell ist, ist mir klar. Hier gibt es aber nur mein Lab-Setup. Gute Güte ;-) Was´n los – war doch nur eine normale Frage…. @NorbertFe: Vielen Dank für den Input – du hast natürlich Recht, Port 80 gehört raus. Ich hatte mit einem weiteren Web-Root „rumgespielt“, der dann einen https-Redirect nach https://www.example.com/ecp macht. Der MS-Artikel https://support.microsoft.com/de-de/kb/975341 ist bekannt, ich habe nur eine Möglichkeit getestet, das auch ohne Änderungen an den Standard-Hostings zu machen. Was die Sicherheitseinschätzung angeht – die wollte ich eigentlich zur Diskussion stellen, das war eine rein subjektive Einschätzung. @DocData: Wie gesagt, ist nicht so, hat mit Vertrieb nichts zu tun. Abgesehen davon, dass ich dir völlig zustimme und man das ganz sicher nicht pauschal bepreisen kann – selbst wenn man das versuchen würde, ab Szenario 4 wird das absolut unmöglich. Außerdem wäre das doch sowieso wiedersinnig. Der Vertrieb wird die Szenarien (wahrscheinlich) nicht aufbauen können, die Technik wird dem Vertrieb von vornherein genau das sagen, was du geschrieben hast!? @magheinz: Sicherheitslevel: Bin ich bei dir, wie gesagt, Intention war, genau das zu diskutieren – wenn das anders angekommen ist, tut´s mir leid. Das mit den Magnettafeln verstehe ich leider nicht, habe dir eine PM geschrieben. Mit den RFCs hast du sicherlich Recht, die Beispiel Domain ist schlecht gewählt. [Edit: Die Beispiel-Domain war ganz schlecht gewählt, ich habe nichts mit der o.g. Domain zu tun, Sorry - das zur Richtigstellung] Ich find´s eigentlich ein wenig schade und verstehe die Reaktionen auch nicht so ganz. Sebastian

Hallo zusammen, ich bin gerade dabei, mich intensiv mit Exchange 2016 zu beschäftigen. Bis jetzt läuft das ganze prima und ich würde gerne ein paar Szenarien zum Öffnen des Exchange Servers nach außen diskutieren. Ich habe auch schon die Forumssuche bemüht und insgesamt 3 Jahre zurück gegangen, aber eine Diskussion über die verschiedenen Möglichkeiten mit Vor- und Nachteilen habe ich nicht gefunden. Stand der Dinge: Domänen-Controller: W2K8R2 Exchange-Server: W2K12R2 mit Exchange 2016 im gleichen Netz Exchange ist unter exchange.organisation.de erreichbar, Split-DNS ist eingerichtet, SSL-SAN Zertifikat ist vorhanden & eingerichtet, Autodiscovery funktioniert, nur intern erreichbar. Die Firma besitzt einen Internetzugang, der über einen Standard-NAT-Router zugänglich gemacht wird sowie eine feste IP-Adresse. Ich habe viel im Internet gelesen und diverse Möglichkeiten gefunden, um den Exchange nach außen zu öffnen. In diesem Fall soll das heißen – „Full-Pull“ – also mit Outlook Anywhere, OWA, mobile Devices. Nur die ECP soll nicht geöffnet werden. Office 365 und/oder Hybrid soll an dieser Stelle unberücksichtigt bleiben. Besonders interessant ist das Verhältnis von Sicherheit / Aufwand / Organisationsgröße – klar ist das immer individuell, aber vielleicht bekommen wir ja einen groben Ansatzpunkt zusammen. Darüber hinaus ist zu sagen, dass das ganze bis jetzt ÜBERLEGUNGEN sind, die kleinen Lösungen habe ich getestet, die großen noch nicht. Die Einschätzungen, Vor- und Nachteile würde ich gerne mal zur Diskussion stellen. Ich versuche mich mal – Ausgangsszenario ist immer der oben beschriebene IST-Stand: Szenario 1: Es wird ein Port-Mapping für Port 80 & 443 auf dem Router mit Ziel Exchange-Server angelegt. Vernünftige Passwort- und Kontosperrrichtlinie. Vorteil: Sehr geringer Aufwand Organisationsgröße: < 5 Benutzer Sicherheit: gering Szenario 2: Es wird ein Port-Mapping für Port 80 & 443 auf dem Router mit Ziel Exchange-Server angelegt. Zusätzlich wird der Exchange Server in ein anderes Netzsegment gestellt; die beiden Netzsegemente werden mittels einer Firewall verbunden, die nur die notwendigen Ports durchlässt. Vernünftige Passwort- und Kontosperrrichtlinie. Vorteil: Geringer Aufwand, höhere Sicherheit als Szenario 1 Nachteil: Organisationsgröße: < 10 Benutzer Sicherheit: mittel (?) Szenario 3: Wie Szenario 1 oder 2 – jedoch wird der Standard-Router durch einen Firewall-Router ersetzt, der auch ein Intrusion-Prevention/-Detection System besitzt (z.B. Fortigate). Hier muss natürlich so etwas wie ein Loadbalancer und/oder SSL-Offloading konfiguriert werden, damit die Firewall die SSL-Pakete aufmachen, scannen und wieder verschlüsseln kann. Vorteil: Firewall kann weitere Dienste bereitstellen (z.B. AV-Gateway) Nachteil: Einarbeitungszeit / Schulungen / Kosten Firewall Organisationsgröße: 10-40 Benutzer Sicherheit: hoch (?) Szenario 4: Aufbau eines Web-Application Proxy-Servers (Bestandteil von W2K12R2), der in einem getrennten Netzwerk steht. Dieser greift durch eine Firewall auf einen (ebenfalls aufzubauenden) ADFS Server sowie auf den Exchange Server zu. DC, Exchange und ADFS Server stehen im internen, vertrauenswürdigen Netz. Vorteil: Weitere Dienste können über ADFS Dienste mit Single Sign-On bedient werden, über den Reverse Proxy des WAP können weitere interne Websites veröffentlicht werden, fein-granulare Konfigurationsmöglichkeiten Nachteil: hoher Implementierungsaufwand Sicherheit: hoch (?) Organisationsgröße: > 40 Benutzer Szenario 5: Aufbau eines komplett eigenständigen Domänencontrollers mit Exchange, der dann mit einem der vorherigen Szenarien nach außen geöffnet wird. Vorteil: Völlige Trennung der Mail & AD Dienste Nachteil: Erhöhter Aufwand in Administration und Einrichtung bei Benutzern Sicherheit: sehr hoch Szenario 6: Hinzufügen von zwei-Faktor Authentifizierungen (das führt hier jetzt vielleicht etwas weit). Wie würdet Ihr die Vor- und Nachteile der Szenarien einschätzen? Liege ich mit der Einschätzung der Organisationsgrößen in etwa richtig? Wie gesagt – auch mir ist klar, dass das sehr individuell ist und das Ganze nur eine grobe Richtschnur sein kann. Zuletzt hätte ich noch zwei Fragen, insbesondere zum vierten Szenario: 1. Outlook Anywhere kann nur als „Passthrough“ auf dem WAP konfiguriert werden (wenn ich mir das richtig angelesen habe) – die Meinungen im Internet sind so, dass das nicht allzu viel bringt, der WAP reicht einfach nur durch. Wäre da nicht Szenario 3 sinnvoller? 2. Wird der WAP-Server zu einem Mitglied der Domäne? Oder steht der ausserhalb und fragt „in die Domäne rein“? (Hier wird ja auch der ADFS Proxy mit dem WAP mitinstalliert) Schönen Sonntag noch, Sebastian

Hallo zusammen, so letztes Update - ich hab´s mir doch noch zu Ende angeschaut :D Problem waren die ACLs im FreeNAS (wie gesagt, FreeBSD mit ZFS). Man muss in der entsprechenden Freigabe mittels "setfacl" die Berechtigungen auf Dateien und Verzeichnisse passend setzen. Hier haben ArcServe wohl vor allem die "Spezialberechtigungen" wie "Ordner auflisten" gefehlt; die Linux-Standard Berechtigungen (r/w/x) werden durch die ACLs mit ZFS deutlich erweitert, vergleichbar mit den Berechtigungen eines Windows-Servers. Das kuriose daran ist, dass es keinerlei Fehlermeldungen bzgl. der Berechtigungen geben hat. Wie dem auch sei - ich hoffe, es hilft vielleicht dem ein oder anderen hier im Forum - auch wenn es inzwischen gar kein Windows-Server Problem mehr ist (wie Anfangs vermutet). @djmaker: Du hast gar nicht so schlecht gelegen mit deiner Vermutung, mit einer Windows-Freigabe wäre das wahrscheinlich nicht passiert..... Grüße, Sebastian

Hallo, der Grund lag / liegt auf dem NAS. Es wird FreeNas mit CIFS (Samba) und als Dateisystem ZFS verwendet. Sobald vfs objects = zfsacl für die Sambafreigabe gesetzt ist, werden die vorhandenen Backup-Files nicht gelöscht (die HEADER-Datei von ArcServe aber neu erzeugt). Das muss mit den ACLs vom ZFS Dateisystem zu tun haben - ich habe versucht, mir das weiter anzuschauen, aber es ist langsam spät ;-) Ich habe jetzt in der Samba-Konfiguration von FreeNAS einfach vfs objects = angeben, damit ist das Modul deaktivert und es funktioniert erst einmal alles wie es soll. Vielleicht kennt sich ja jemand mit ZFS unter FreeBSD (=FreeNAS) aus und kann noch einen Tip geben ? Auf alle Fälle war der erste Beitrag der "Schubs" in die richtige Richtung, Danke ! Sebastian

Hallo, kleines Update - die Spur ist richtig. Auf einem anderen NAS, bzw. lokal passiert es nicht, nur eben auf _diesem_ NAS / Samba Share (ist ein FreeNAS 8). Ich forsche mal weiter (vielleicht hat auch jemand noch eine Idee?).... Grüße, Sebastian

Hallo, da gehe ich mal von aus - aus dem Datenträgerverwaltungshandbuch: Grüße, Sebastian

Hallo zusammen, folgendes Setup: Windows 2003 SBS ArcServe r15 SP1 Sicherung auf NAS per Samba Ich mache eine tägliche Rotationssicherung an 5 Tagen, Montag vollständig, alle anderen Tage Änderunggsicherungen. Alle Tage im Modus "Überschreiben". Des Weiteren habe ich fünf Verzeichnisse auf dem Samba Share, die als Dateisystemgerät alle in einer Gruppe zusammengefasst sind und auch einem Datenträgerbestand zugeordnet sind. Grundsätzlich funktioniert das auch, aber die fünf Verzeichnisse auf dem Share werden immer grösser, d.h. dass immer mehr S00000xxx.CTF Dateien entstehen, aber "alte" nie gelöscht werden. Auch nach dem Formatieren der Bänder sind die Dateien immer noch vorhanden. Kann sich da jemand einen Reim drauf machen ? Grüße, Sebastian Lemke

Hallo zusammen, nachdem wir zu zweit das System einmal komplett durchgesehen haben haben wir uns jetzt ersteinmal entschlossen, den Virenscanner (Etrust) auf dem DC2 zu entfernen (nicht hauen, kommt natürlich sofort wieder drauf nach neuen Erkentnissen) sowie die LAN Verbindung fest auf 1 GBit zu stellen; vorher hat es beim Start des Servers (merkwürdigerweise) immer einen Moment gedauert, bis er erkannt hat, dass er eine Internetverbindung hat (obwohl auch der Switch ein Procurve ist). Ich werde weiter berichten. Schönes WE, Sebastian

Hallo, erledigt (hatte ich vergessen, wollte ich sowieso machen :-)) Kannst du mir auf die Sprünge helfen ? Ich vermute mit repadmin ? DC1: repadmin running command /showrepl against server localhost Default-First-Site\dc1 DC Options: IS_GC Site Options: (none) DC object GUID: af44a2bd-af79-46c5-89cc-ed4f6c169b9d DC invocationID: af44a2bd-af79-46c5-89cc-ed4f6c169b9d ==== INBOUND NEIGHBORS ====================================== DC=domaene,DC=local Default-First-Site\dc2 via RPC DC object GUID: 1a049303-0b27-406e-9caf-5098ea2223dc Last attempt @ 2010-08-19 12:41:46 was successful. CN=Configuration,DC=domaene,DC=local Default-First-Site\dc2 via RPC DC object GUID: 1a049303-0b27-406e-9caf-5098ea2223dc Last attempt @ 2010-08-19 11:56:41 was successful. CN=Schema,CN=Configuration,DC=domaene,DC=local Default-First-Site\dc2 via RPC DC object GUID: 1a049303-0b27-406e-9caf-5098ea2223dc Last attempt @ 2010-08-19 11:56:41 was successful. DC=DomainDnsZones,DC=domaene,DC=local Default-First-Site\dc2 via RPC DC object GUID: 1a049303-0b27-406e-9caf-5098ea2223dc Last attempt @ 2010-08-19 12:41:32 was successful. DC=ForestDnsZones,DC=domaene,DC=local Default-First-Site\dc2 via RPC DC object GUID: 1a049303-0b27-406e-9caf-5098ea2223dc Last attempt @ 2010-08-19 11:56:41 was successful. DC2: Repadmin: Befehl "/showrepl" wird für den vollständigen DC "localhost" ausgeführt Default-First-Site\dc2 DSA-Optionen: IS_GC Standortoptionen: (none) DSA-Objekt-GUID: 1a049303-0b27-406e-9caf-5098ea2223dc DSA-Aufrufkennung: 74131738-881c-4b17-adc6-a4bb3fd420b6 ==== EINGEHENDE NACHBARN===================================== DC=domaene,DC=local Default-First-Site\dc1 über RPC DSA-Objekt-GUID: af44a2bd-af79-46c5-89cc-ed4f6c169b9d Letzter Versuch am 2010-08-19 12:41:27 war erfolgreich. CN=Configuration,DC=domaene,DC=local Default-First-Site\dc1 über RPC DSA-Objekt-GUID: af44a2bd-af79-46c5-89cc-ed4f6c169b9d Letzter Versuch am 2010-08-19 11:59:54 war erfolgreich. CN=Schema,CN=Configuration,DC=domaene,DC=local Default-First-Site\dc1 über RPC DSA-Objekt-GUID: af44a2bd-af79-46c5-89cc-ed4f6c169b9d Letzter Versuch am 2010-08-19 11:59:54 war erfolgreich. DC=DomainDnsZones,DC=domaene,DC=local Default-First-Site\dc1 über RPC DSA-Objekt-GUID: af44a2bd-af79-46c5-89cc-ed4f6c169b9d Letzter Versuch am 2010-08-19 12:41:32 war erfolgreich. DC=ForestDnsZones,DC=domaene,DC=local Default-First-Site\dc1 über RPC DSA-Objekt-GUID: af44a2bd-af79-46c5-89cc-ed4f6c169b9d Letzter Versuch am 2010-08-19 11:59:54 war erfolgreich. Nein, keine Bindungen entfernt und sowohl die IP als auch DNS steht auf automatisch beziehen. Bei DNS stand mal ::1 - dann gabs aber beim nslookup Probleme; den Tip mit automatisch Beziehen habe ich hier im Forum gefunden. lg Sebastian

Hallo, bin hier echt am verzweifeln :-) DC1: Windows-IP-Konfiguration Hostname . . . . . . . . . . . . : dc1 Primäres DNS-Suffix . . . . . . . : domaene.local Knotentyp . . . . . . . . . . . . : Hybrid IP-Routing aktiviert . . . . . . : Nein WINS-Proxy aktiviert . . . . . . : Nein DNS-Suffixsuchliste . . . . . . . : domaene.local Ethernet-Adapter LAN-Verbindung 2: Verbindungsspezifisches DNS-Suffix: Beschreibung . . . . . . . . . . : HP NC7761 Gigabit Server Adapter Physikalische Adresse . . . . . . : 00-12-79-91-5F-37 DHCP aktiviert . . . . . . . . . : Nein IP-Adresse. . . . . . . . . . . . : 192.168.1.10 Subnetzmaske . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : 192.168.1.1 DNS-Server . . . . . . . . . . . : 192.168.1.10 Primärer WINS-Server . . . . . . : 192.168.1.11 DC2: Windows-IP-Konfiguration Hostname . . . . . . . . . . . . : dc2 Primäres DNS-Suffix . . . . . . . : domaene.local Knotentyp . . . . . . . . . . . . : Hybrid IP-Routing aktiviert . . . . . . : Nein WINS-Proxy aktiviert . . . . . . : Nein DNS-Suffixsuchliste . . . . . . . : domaene.local Ethernet-Adapter LAN-Verbindung 1: Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : HP NC375i Integrated Quad Port Multifunction Gigabit Server Adapter #2 Physikalische Adresse . . . . . . : D8-D3-85-D8-FB-C0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Verbindungslokale IPv6-Adresse . : fe80::f8a0:57e7:8fe1:5ce1%13(Bevorzugt) IPv4-Adresse . . . . . . . . . . : 192.168.1.11(Bevorzugt) Subnetzmaske . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : 192.168.1.1 DHCPv6-IAID . . . . . . . . . . . : 316199813 DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-13-E4-54-54-D8-D3-85-D8-FB-C3 DNS-Server . . . . . . . . . . . : 192.168.1.10 192.168.1.11 Primärer WINS-Server. . . . . . . : 192.168.1.11 NetBIOS über TCP/IP . . . . . . . : Aktiviert Tunneladapter isatap.{A7A63E27-2BA2-49D5-88AB-1D2E5AEFF471}: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Tunneladapter Teredo Tunneling Pseudo-Interface: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Teredo Tunneling Pseudo-Interface Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja lg Sebastian

Hallo zusammen, folgendes Setup: DC1 – w2k3 DC2 – w2k8r2 Die DNS-Zonen sind AD-integriert, der DC2 hat die FSMO Rollen inne. Des weiteren läuft auf DC2 ein WINS Server, alle Clients wie auch die beiden Server haben diesen auch unter WINS in den TCP/IP v4 Eigenschaften eingetragen. Problem ist nun, daß ich nach einigen Stunden von DC2 aus nicht mehr auf DC1 mit \\DC1 zugreifen kann (Fehler 0x80070035, Netzwerkpfad nicht gefunden). Wenn ich statt \\DC1 \\DC1.domaene.local verwende geht´s :confused:. Ein "nbtstat -a DC1" ausgeführt auf DC2 gibt die korrekten Ergebnisse. Wenn ich von DC2 aus einen anderen PC im Netz aufrufe geht das auch. Wenn ich von DC1 aus \\DC2 macht geht es ebenfalls. Im Eventlog sind auf beiden Servern keine Auffäligkeiten; auch Netdiag und dcdiag sind "ohne Befund". Nslookup der Server funktioniert auf beiden Servern einwandfrei. Nach einem Neustart von DC2 gehts ersteinmal wieder. UPDATE von DC2 aus: Ein net view \\DC1 geht nicht ein net view \\<IP> geht Müsste also in der Netbios-Namensauflösung liegen ??? Hat jemand eine Idee ? lg Sebastian

Hallo zusammen, kurzes Update: Im zweiten Anlauf hat alles so geklappt wie es sollte; nach Dcpromo und vor dem Neustart habe ich den DNS-Server Ipv6 - wie beschrieben - auf automatisch beziehen gestellt. Nach dem Neustart gab es absolut keine Probleme :-) Vielen Dank an alle! Sebastian

Hallo, ich muss mich nochmal zurückmelden :-) Ich habe das ganze jetzt mit meiner VM nachgestellt. Ausgangssituation: DC 1 - 192.168.1.10 - GC / FSMO / DNS / DHCP 1. Ich habe den 2k8r2 auf dem zweiten Rechner (VM) installiert, IP 192.168.1.11, DNS auf 192.168.1.10. Nslookup auf DC1 ohne Probleme. 2. Danach habe ich den zweiten Rechner zunächst als normales Mitglied in die Domäne gehoben. Nach Neustart kein Problem mit Nslookup. 3. Mit DCPromo den zweiten PC zum DC gemacht. Nach Neustart sind die DNS-Einstellungen (automatisch) wie folgt: primärer DNS: 192.168.1.10, sekundärer: 127.0.0.1 Problem ist an dieser Stelle, daß ein nslookup auf DC2 ausgeführt folgendes ergibt: C:\Users\Administrator.domaene>nslookup dc1.domaene.local DNS request timed out. timeout was 2 seconds. Server: UnKnown Address: ::1 Name: dc1.domaene.local Address: 192.168.1.10 Den gleichen Befehl auf DC1 ausgeührt liefert korrekte Ergebnisse. Könnte das der Ursprung der Probleme sein, bzw. warum funktioniert der Lookup auf DC1 von DC2 aus nicht ? Nachtrag: Die PTR Einträge in der Reverse-Lookupzone sind für DC1 und DC2 enthalten. Nachtrag2: Ein Ping auf DC2 ausgeführt auf DC2 ergibt folgendes: C:\Users\Administrator.domaene>ping dc2.domaene.local Ping wird ausgeführt für dc2.domaene.local [fe80::8c70:96cf:47ae:8f4e%11] mit 32 Bytes Daten: Antwort von fe80::8c70:96cf:47ae:8f4e%11: Zeit<1ms Antwort von fe80::8c70:96cf:47ae:8f4e%11: Zeit<1ms Antwort von fe80::8c70:96cf:47ae:8f4e%11: Zeit<1ms Könnte das Problem doch mit IPv6 zusammenhängen ? Nachtrag 3: Ich habs gefunden... http://www.mcseboard.de/post8-959628.html Sorry - für das unnötige Posting; aber vielleicht hilfts ja mal jemand anderen :-) lg Sebastian

Hallo ! Ich hab´s mir gedacht, war mir aber nicht sicher; im Blog habe ich schon vieles gelesen, aber diesen Artikel habe ich nicht gesehen; danke! Das wollte ich ganz gerne vermeiden :-) Werde ich nicht machen, eine IP vom Server ändert man ja i.d.R. nicht "mal" so. Ich habe auch angefangen, das ganze abzuarbeiten, habe ich aber etwas im Kreis gedreht - lag vielleicht auch dadran, daß es schon sehr spät war (eine vorherige Installation hatte sich auch schon verzögert), so daß ich beschlossen habe, ersteinmal wieder einen sicheren Betrieb herzustellen. Ich wollte das Szenario heute einmal in zwei VMs nachstellen - ich habe vom DC1 ein VM-Image gezogen. Netzwerkkonnektivität ist es nicht, das passt alles; ist nur ein kleiner Switch zwischen und die Server sind im gleichen Rack. Treiber ist auch alles fein. Sollte man grundsätzlich IPv6 auf dem 2k8r2 abschalten / nicht an das Interface binden ? Wir brauchen´s im Moment sowieso nicht. Ja, und nach Neustart auch sauber aus dem AD als "normales" Mitglied entfernt und als letztes das PC-Konto aus "Computers" gelöscht. Danke Sebastian

Hallo zusammen, ich habe eine grundsätzliche Frage – folgendes Setup: DC1 – w2k3 DC2 – w2k8r2 Die DNS-Zonen sind AD-integriert, der DC2 hat die FSMO Rollen inne. Die erste Frage - Wie müssen / sollten die DNS-Einstellungen in den Netzwerkkarteneinstellungen der DCs stehen ? Sollte es im „Prinzip“ nicht egal sein, ob ich die Server untereinander „kreuze“, 127.0.0.1 oder die eigene Ethernet-Adresse angebe ? Ich hatte gestern genau diese Situation, nachdem ich DC2 mittels DCPromo in die Domäne gehoben und er auch die FSMO Rollen übernommen hat. Allerdings gab es massive Probleme, deren Ursache ich im DNS vermute – unter anderem wurde im Eventlog protokolliert, dass „kein Domänencontroller gefunden“ werden konnte und DC2 Inhaber der FSMO Rollen ist, aber mindestens eine Rolle ungültig sei. Als „Ausgangsmeldung“ habe ich EventID 2087 ausmachen können, bzw. vermutet; in dem unter anderem der „failed DNS Host Name“ angegeben wird, der als GUID (z.B. Failing DNS host name: b0069e56-b19c-438a-8a1f-64866374dd6e._msdcs.domaene.local) angegeben wird. Allerdings hat ein nslookup auf beiden Server sowohl auf die dc1.domaene.local, dc2.domaene.local als auch auf b0069e56-b19c-438a-8a1f-64866374dd6e._msdcs.domaene.local korrekte Werte geliefert! Kann es sein, dass bei DCPromo bzw. der anschließenden Replikation etwas schief gegangen ist ? Letzten Endes konnte ich die FSMO Rollen zurück übertragen und DC2 wieder entfernen; DC1 läuft im Moment ohne Probleme. Lg Sebastian

Ich war heute etwas überrascht - eine Software kommt zwar mit Virtualisierung klar, aber nicht wirklich mit 64bit. Also ein 32bit Gast... Naja... Kein Beinbruch, aber gewundert hat´s mich schon.... Deckt sich ja mit deiner Aussage. Und dabei sind keine Gerätetreiber oder Dienste im Spiel (dann hätte ich das vielleicht noch verstehen können). Ah-ha - das mit der 6er Bestückung wusste ich nicht - sehr gut. Da sind auf alle Fälle RDIMMs vorgesehen... Ich denke, dass es wohl auf ein Raid hinauslaufen wird - ein SAN wird wohl ausserhalb des Budgets sein (steht noch nicht genau fest). Cache und BBWC sind fest eingeplant ;-) Vielen Dank für die Rahmenbedingungen - Super Infos !!! lg Sebastian

Hallo, naja, ganz so ist es ja nicht :cool: Es steht ein neuer Server an - und wir befinden uns gerade genau in der Phase, zu überlegen, ob Virtualisierung gewünscht ist oder nicht, Vor- und Nachteile und natürlich auch den Budgetrahmen zu beleuchten. Die Gespräche mit den Softwareherstellern laufen auch noch. Also erst einmal Informationen sammeln, was in diesem Umfeld überhaupt möglich ist, um dann eine sinnvolle Entscheidung zu treffen. Ziele kann man viele Stecken, ob´s bezahlbar ist, ist dann was anderes :) Die Frage ist halt, wie viel "Schmerz" (=Ausfallszeit) zu ertragbar ist, wenn es zum Worst-Case kommt. Kam vielleicht etwas anders rüber ;) Klare Aussage -) Aber natürlich absolut vernüftig, man kann später erweitern. lg Sebastian

Hi, im einfachsten Fall 2x W2k8 R2 EE - wenn man mit insgesamt 4 VMs hinkommt, oder ? lg Sebastian

Wow, ich bin dabei die erste Antwort zu schreiben, da laufen schon zwei weitere ein - Respekt :cool: Es soll zwar ersteinmal kein Failover geben, aber für die spätere Skalierbarkeit finde ich das Verschieben der VMs auch sehr attraktiv. Ok, klare Ansage ;-) Wenn ich mir den Preisunterschied der Maschinen ansehe, wäre eigentlich der größte (X5550) als 2 Prozessormaschine am sinnvollsten. Wenn die Kiste erstmal produktiv ist, ändert man so schnell sowieso nichts mehr.... Wie ich schon schrieb, ich dachte an ~36 GB; da sollten Reserven sein. Aber sehr schön, dass ich jetzt ein Feedback zum virtualisieren vom TS hab. Wenn es Virtualisierung wird, wird es so werden - den Tip hab ich "mitgenommen" - DANKE! (auch an Norbert :-) Prima ! Hmm - macht es Sinn, etwas nicht zu beglücken ? Der SQL-Server kann vielleicht raus ? Aber sonst sollte doch alles "gedeckelt" werden, oder ? Hört sich nicht schlecht an; seitdem CA mir am Telefon gesagt hat, dass man auf einem 64bit Betriebssystem keinen Protokoll _ausdruck_ erstellen kann (der Agent dafür ist 32 bit, der Druckertreiber 64 bit) und das Microsoft davon in Kenntniss gesetzt sei, bin ich von ArcServe eh nicht mehr so begeistert.... Aber kein TS, oder ? Der Backup-Server läuft also auch in der VM ? Bringt das DPM die "Agents" mit, um die anderen VMs mitzusichern (extra Lizenz?). lg Sebastian

Hallo, OK, die C-States sind eine Option; über das Hotfix habe ich gelesen, dass es zum Teil gar keine Wirkung zeigen soll (Bugreport: Nehalem plus Hyper-V ergibt Bluescreen - Seite 2 von 5 - Analysen - Security - ZDNet.de) Ich habe mich an den CPUs gehalten, die in den HP Proliants drin sind.... Es ging mir auch nicht dadrum, das zu eleminieren, sondern ersteinmal die grundsätzliche Machbarkeit, bzw. den Sinn oder Unsinn abzuklären.... Das ist keine schlechte Idee, zumal der "alte" Server noch zur Verfügung steht; der könnte das übernehmen. Das mit den SCSI-Tapes ist ein wertvoller Hinweis, vielen Dank. Was das eigentliche Konzept angeht, bin ich im Moment noch recht offen; klar ist nur, dass auf Band gesichert werden soll - wahrscheinlich ein SAS-Laufwerk (Ultrium). Haben evt. noch andere Leute Infos / Ideen zu dem Thema ? Besonders bei dem Terminalserver und die übrigen Fragen würde ich mich über Erfahrungen freuen. lg Sebastian

Hallo zusammen, ich stehe vor der Frage ob ich mittels Server 2008 R2 EE Hyper-V virtualisieren soll oder nicht. Ich habe den Vormittag damit verbracht, sowohl hier im Board zu lesen als auch im Internet zu googlen, bin mir aber nicht sicher. Zunächst einmal zur vorhandenen Hardware (und den auftretenden Problemen): HP ML350 G4 2x Dual Core Xeon 3 GHz 4 GB Ram Raid 5 mit 3 SCSI Platten, 10k rpm W2k3 32 bit (deswegen nur 3,5 GB Ram nutzbar) SQL Server 2008 servergespeicherte Profile Der Server ist sowohl als DC als auch aus TS konfiguriert. Zusätzlich läuft auch der SQL-Server dadrauf. Es verbinden sich circa 20-25 Leute, zum Teil doppelt und öffnen insgesamt circa 30 Sitzungen. Mit dem SQL-Server sowie einer weiteren, dateibasierten Datenbank, wird es jetzt knapp mit der Serverperformance. Bei den Sitzungen denke ich, dass die nächsten 2-3 Jahre circa nochmal 20-30% dazu kommen werden (plus 30 % Reserve würde ich sagen). Bei der Planung eines neuen Server stellte sich nun die Frage, ob Virtualisierung oder nicht. Idee wäre, einen Terminalserver, evt. den SQL-Server und vielleicht auch einen Exchange (ist noch nicht klar, ob das eingesetzt werden soll) jeweils einzeln laufen zu lassen. Geplante Hardware: 2x QuadCore Intel Xeon E5520, E5530 oder X5550 ~32 GB RAM (vielleicht auch etwas weniger ?) Raid 5 mit 7+1 Hotspare 15k rpm (vielleicht auch etwas weniger ?) evt. später ein Failover, im Moment aber nicht. Wie "eventuell" das ist und ob das wirklich kommen wird, weiss ich beim besten Willen nicht. Jetzt mein "Sack" Fragen :-) 1. Die wichtigste - es gibt ja den "Nehalem Bug" - auf der einen Seite wird "SLAT" / "EPT", was wohl eine deutliche Performance-Steigerung bringt, nur auf Nehalem Prozessoren verfügbar, auf der anderen Seite kann es Blue-Screens geben. Was denn nu ? Ich meine, das ist doof :-) Ich will ja schon die bestmögliche Performance haben (und nicht das zweitbeste Steak :D), aber ich will mich auch nicht mit Blue-Screens "rumärgern". Das geht auch nicht, die Kiste muss gut laufen :-) 2. Welche CPU würdet Ihr empfehlen ? Wahrscheinlich in erster Linie eine Preisfrage, oder? 3. Macht es in dem Umfeld Sinn, einen TS zu virtualisieren ? Ich möchte ungerne am ersten Tag des Live-Betriebs einen Anruf haben und "es ist zu langsam" oder "das ist ja gar nicht schneller". Einen TS auf dem "Host" zu betreiben macht wohl gar keinen Sinn, oder? Wäre es vielleicht sinnvoller, zwei Server zu nehmen ? Einen der alles virtualisiert und einen der nur TS macht ? Wenn der TS Server dann aber kaputt geht, kann man nicht mal eben schnell ein Image zurücksichern und weiter gehts - dann macht man sich ja Virtualisierungs-Vorteile kaputt :confused:. 4. Wo sollte der DC laufen ? Eigene VM oder irgendwo "mit" drauf ? 5. Wie sind die Erfahrungen mit dem SQL-Server ? Das sollte doch eigentlich kein Problem sein, oder ? 5. Virenscanner - derzeit CA im Einsatz (ITM Thread Management) - habe auch schon gesehen, dass man unbedingt einige Exclusions machen muss. Gibt es damit bereits Erfahrungen ? 6. Datensicherung - wo hängt man die am besten auf, bzw. wie läuft das grundsätzlich ? Favourit wäre ArcServe. In einer VM und dann die anderen VMs sichern ? In der VM, in der auch der DC liegt ? Auf dem Host ? Werden die VMs als "VM-Image" gesichert, oder wird innerhalb der VM ein Agent installiert, der quasi "normal" einen Server sichert? Wow - da kommt schon einiges zusammen :-) Danke erstmal ;-) mfg Sebastian

Guten Morgen, Netzteiltausch hat auch nichts gebracht, Stromtaster ist in Ordnung. Werde jetzt nochmal probieren, eine andere GraKa einzubauen und werde dann berichten ! Grüße, Sebastian

Hallo, leider steht ein Austausch derzeit nicht zur Debatte; die Software, die dadrauf läuft ist noch nicht für w2k3 / w2k8 freigegeben :-( Hat noch jemand eine Idee / kann sich jemand den Minidump mal ansehen ? Grüße, Sebastian