Jump to content

slemke

Members
  • Gesamte Inhalte

    38
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von slemke

  1. Hallo Norbert,

    vielen Dank für deine Antworten.
     

     

    Was genau bedeutet das? Mit welcher Zielstellung? Mit welchem Schwerpunkt?

    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.
     

     

    Bin "zu faul" zum Suchen, aber ich würde behaupten, dass das Thema Reverse Proxy mit oder ohne Prä-Authentifizierung und mit oder ohne Reverse Proxy gerade im Rahmen der Abkündigung des MS TMG häufiger hier aufploppte. Vielleicht liegts ja an deiner Suche.

    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 ;-)
     

     

    Wenn du ECP nicht aufmachst, kann man im OWA aber keine Einstellungen vornehmen.

    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?

     

     

    - Szenario1 -

    Zu Port 80 hatte ich ja schon was geschrieben. Ansonsten wieso ist Sicherheit gering? Wieso Organisationsgröße <5?

    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.
     

     

    - Szenario 2: -
    Versteh ich nicht, bzw. das was ich verstehe ist, dass du damit ein von MS unsupportetes Szenario herstellen würdest. Es gibt ein klares Supporstatement: Keine Firewalls zwischen Exchange und DC! Wieso <10 Nutzer? Wieso ist jetzt die Sicherheit höher als bei Szenario 1?

    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.
     

     

    - Szenario 3 -

    Ich interpretiere das mal als Firewall mit Reverse Proxy Komponente. Du bist dir nicht sicher, ob die Sicherheit hoch ist?

    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“?

     

     

    - Szenario 4 -
    Was meinst du mit feingranulare Konfigurationsmöglichkeiten? Gäbe es die bei Szenario 3 nicht?

    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

     

  2. 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

  3. 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

     

  4. 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

  5. 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

  6. 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

  7. 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

  8. Hallo,

     

    Trage mal bei DC1 mal den DNS von DC2 als 1. DNS-Server ein. Seinen eigenen DNS als 2. Position.

     

    erledigt (hatte ich vergessen, wollte ich sowieso machen :-))

     

    Wird für DNS eine Anwendungspartition verwendet ?

     

    Kannst du mir auf die Sprünge helfen ?

     

    Prüfe, ob die richtig repliziert wird:

     

    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.
    
    

     

    Sind in den Netzwerkeinstellungen bei DC2 irgendwelche IPV6-Sachen deaktiviert oder Bindungen entfernt worden ?

     

    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

  9. 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

  10. 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

  11. 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

  12. 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

  13. Hallo !

     

    Es ist empfohlen die Überkreuzeinstellung zu wählen. Jeweils der andere DC sollte als primärer DNS- und der DC selbst als zweiter DNS-Server konfiguriert werden.

     

    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!

     

    Ja, es funktioniert auch wenn der DC selbst als primärer DNS-Server steht. ....im Eventlog erscheinen hässliche Fehlermeldung, die dann aber auch automatisch wieder verschwinden.

     

    Das wollte ich ganz gerne vermeiden :-)

     

    127.0.0.1 - Würdest du die Loopback-Adresse eintragen, hättest du den Vorteil das wenn sich "mal" die IP-Adresse des DCs ändert, du die DNS-Server IP nicht ändern müsstest.

     

    Werde ich nicht machen, eine IP vom Server ändert man ja i.d.R. nicht "mal" so.

     

    In dem Eventlogeintrag steht doch auch in der Beschreibung was man unternehmen könnte, um dem Problem auf die Schliche zu kommen.

    ....

     

    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.

     

    Du hast den Server wieder mit DCPROMO heruntergestuft?

     

    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

  14. 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

  15. Auf Tapes zu sichern ist eine gute Wahl, dafür brauchst du aber eine eigene Kiste (wenn du nicht basteln willst) - das ist sowieso eine gute Idee, da ein physikalischer DC viele Vorteile hat. Dort kannst du aber ruhig eine kleine 1 CPU Maschine nehmen, mit X34xx Xeons.

     

    Zum Virtualisierungsserver:

     

    Stelle Applikationssupport sicher - gerade kleinere ERP-Lösungen sind zum teil ziemlich ... suboptimal programmiert und evtl. in virtualisierten Umgebungen nicht support.

     

    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).

     

    Von der Hardware her dürften die aktuellen 5500er Xeons das richtige sein. Mit E5530 aufwärts liegst du richtig. Wenn die X5550 noch im Budget liegen, nimm diese. Beachte die Memory-Konfiguration, du musst bei einer 2 CPU Maschine immer mit Sechserpaaren arbeiten, also z.B. 6x4GB oder 12x4GB. Andere Konfigurationen geben suboptimale Performance.

     

    Ah-ha - das mit der 6er Bestückung wusste ich nicht - sehr gut.

     

    Mehr als 12 Module senken die RAM-Geschwindigkeit, was auch wieder Nachteile hat. Beachte die Config Guides deines Serverherstellers, HP bietet z.T. auch unbuffered RAM an, was günstiger ist aber die Kapazität einschränkt.

     

    Da sind auf alle Fälle RDIMMs vorgesehen...

     

    Bei den Bandlaufwerken gibts nur eine Wahl: LTO4.

     

    Die nächste Frage ist wie du den Storage lösen willst. Ein Entry-Level SAS attached SAN (IBM's DS3200, HP hat sicher ähnliches) dürfte langfristig die richtige Wahl sein. Falls das nicht möglich ist, nimm den besten RAID-Controller den du für den Server kriegst - BBWC and all.

     

    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

  16. Hallo,

     

    ich sag's ja ungern, aber es wäre schon nicht schlecht, vorher die Anforderungen zu klären. Ein Projekt ohne definiertes Ziel kann nur scheitern.

     

    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 ;)

     

    Virtualisierung produktionskritischer Server würde ich ohne SAN heute nicht machen, auch wenn im ersten Schritt evtl. kein Cluster im Spiel ist. Wenn du später mal clustern willst/musst, kommst du ohnehin nicht dran vorbei.

     

    Klare Aussage -) Aber natürlich absolut vernüftig, man kann später erweitern.

     

    lg

    Sebastian

  17. Wow,

     

    ich bin dabei die erste Antwort zu schreiben, da laufen schon zwei weitere ein - Respekt :cool:

     

    also grundätzlich bin ich ein Fan von Virtualisierung, weil du einen enormen Vorteil hast. Du kannst die virtuellen Maschinen wunderbar zwischen verschiedenen physischen Maschinen umziehen (sofern vorhanden).

     

    Es soll zwar ersteinmal kein Failover geben, aber für die spätere Skalierbarkeit finde ich das Verschieben der VMs auch sehr attraktiv.

     

    Ich selbst tendiere definitiv zu aktuellen Xeons. Ich würde das Größte kaufen, was sich noch gerade so rechnet.

     

    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....

     

    Wenn du gerade beim RAM Sizing auf genügend Reserven achtest, solltest du nicht in diese Falle laufen. Und ansonsten schiebst du während der Testphase einfach noch was nach.

     

    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.

     

    Ich würde den definitiv als eigenständige Maschine betreiben. Also wenn der DC noch DNS und DHCP macht isses auch nicht so sonderlich schlimm :) Du solltest aber einen 2. DC auf einer 2. physischen Maschine vorhalten.

     

    Wenn es Virtualisierung wird, wird es so werden - den Tip hab ich "mitgenommen" - DANKE! (auch an Norbert :-)

     

    Der macht seit 2008 keine Probleme mehr, wenn er Virtuell läuft. Hab da einige, die virtuell betrieben werden.

     

    Prima !

     

     

    Was willst du denn überhaupt alles mit einem AV beglücken?

     

    Hmm - macht es Sinn, etwas nicht zu beglücken ? Der SQL-Server kann vielleicht raus ? Aber sonst sollte doch alles "gedeckelt" werden, oder ?

     

    Wie Norbert schon erwähnt hat, hast du in VMs die Limitierung mit SCSI. Aber iSCSI funktioniert fürs Backup wunderbar. Seit einiger Zeit teste ich auch den DPM. Bin damit sehr zufrieden.

     

    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....

     

    Als kleine Sizing-Hilfe hier mal eine produktive Konfiguration von mir: Dual Xeon 5560 mit 24 GB RAM. 5 + 1 x 300 GB SAS. Darauf laufen 4 virtuelle Maschinen DC, Exchange, SQL 2008, Backup/SharePoint (und ein wenig kleinkram). Angebunden werden 80 User.

    Die Kiste langweilt sich die meiste Zeit ...

     

    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

  18. 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)

     

    Auf jeden Fall eine aktuelle. ;)

     

    Ich habe mich an den CPUs gehalten, die in den HP Proliants drin sind....

     

    Wozu gibt es eigentlich Evaluierungs- und Pilotphasen?

     

    Es ging mir auch nicht dadrum, das zu eleminieren, sondern ersteinmal die grundsätzliche Machbarkeit, bzw. den Sinn oder Unsinn abzuklären....

     

    Einen DC würde ich persönlich physisch laufen lassen, und den zweiten dann virtuell. (physisch dann aber nicht auf dem VM Host, sondern auf einer dedizierten Hardware).

     

    Das ist keine schlechte Idee, zumal der "alte" Server noch zur Verfügung steht; der könnte das übernehmen.

     

    Das hängt vor allem von deinem Backupkonzept und deinem Backupmedium ab. In einer VM kannst du bspw. wahrscheinlich nur mit ISCSI Tapes arbeiten, denn SCSI Tapes gibts da nicht. ;)

    Ein Grund mehr für einen Hardware DC, der dann ein beliebiges Backupmedium direkt ansteuern kann.

     

    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

  19. 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

×
×
  • Neu erstellen...