NilsK

Moin, warum hängen die Server am internen Switch einer Fritzbox? Der ist nur für Heimumgebungen gedacht, ganz bestimmt nicht für Server. Eine höhere Geschwindigkeit erzielt ein NIC-Team nur, wenn mehrere parallele Datenströme vorliegen. iSCSI bindet man nicht über ein Team an. iSCSI ist Storage-Anbindung, die ist empfindlich. Wenn du daran was änderst, stell zuerst sicher, dass keine Daten zwischen Storage und Server laufen (Server herunterfahren), sonst riskierst du Datenverluste. Und auch wenn es ein kleines Netzwerk ist: Da sollte man mal die Struktur überarbeiten. Gruß, Nils

Moin, dazu kann man nichts Seriöses sagen, ohne die Infrastruktur zu kennen. "iSCSI" etwa taucht bei dir nur in einem Nebensatz auf. Generell: Wenn du Änderungen dieser Art vornehmen willst, solltest du das in einer Downtime und mit Planung machen, gerade wenn Spezialitäten wie iSCSI im Spiel sind. Einen DC bindet man eher nicht über ein Team an, sondern sorgt für Redundanz auf der Applikationsebene (= mehrere DCs) Exchange würde man sich auch noch mal separat ansehen Zu klären wäre, was mit dem Teaming denn überhaupt erreicht werden soll. Gruß, Nils

Moin, eine einfache Installation von OTRS dürfte das leisten. Wenn man will, kann man das auch unter Windows einsetzen. Linux wäre hier aber vorzuziehen. Falls die Anforderungen dann mal steigen, ist man mit OTRS immer noch richtig bedient. Gruß, Nils

Moin, macht ja nix. Ich weise vor allem deshalb darauf hin, damit der TO nach den richtigen Begriffen suchen kann bzw. weiß, welche Begriffe evtl. unpassende Ergebnisse bringen. Gruß, Nils

Moin, äh ... ich verstehe noch nicht so ganz, wo das hinsoll. Ein Standard-Gateway hat ein Rechner normalerweise nur einmal, denn es gibt ja an, wohin Traffic geroutet werden soll, der keine dedizierte Route hat. Warum gibt es in der aktuellen Konfiguration überhaupt zwei Standard-Gateways? Normalerweise warnt Windows bei sowas doch. Wenn es dedizierte Routen geben soll, ist das gerade kein Fall für ein Standard-Gateway, sondern für die Routingtabelle. Also am besten noch mal beschreiben, was genau das Ziel ist. Und am besten auch, wieso der Rechner so konfiguriert ist wie oben beschrieben. Gruß, Nils

Moin, und nur zur Ergänzung: Das ist keine Migration, sondern eine Aktualisierung. Gruß, Nils

Moin, sorry, aber meine Kollegen kann ich hier nicht einbinden. Dazu bräuchte ich einen kaufmännischen Auftrag. Gruß, Nils

Moin, da Invoke-Command per PSRemoting ein Kommando auf dem entfernten Server ausführt, muss die Funktion dort erreichbar sein. Du musst sie also auf dem entfernten Server oder auf einem Dateiserver ablegen und dann mit ihrem Pfad aufrufen, damit sie verfügbar wird. Gruß, Nils

Moin, naja, dass die neuen Funktionen fehlen, ist ja logisch. Woher sollen die alten RSAT die auch kennen? Ich hätte jetzt sogar vermutet, dass man damit gar nicht rankommt. In der Vergangenheit war es auch meist so, dass nur genau eine OS-/RSAT-Kombination wirklich funktionierte. Gruß, Nils

Moin, ja, das kann sein. Ich habe es jetzt nicht überprüft, würde aber davon ausgehen. Es hat sich am API einiges geändert, das die RSAT für Windows 8.1 sicher nicht können. Manche Dinge sollten per PowerShell gehen, aber auch da wäre ich vorsichtig, weil sich da auch einiges getan hat. Gruß, Nils

Moin, ich denke, die Boardregeln sind da eindeutig. Dieser Thread sollte geschlossen werden. Gruß, Nils

Moin, vor allem ist wichtig, dass die Clients zwei DNS-Server haben ... ... und falls der erste DC zufällig auch noch der einzige DHCP-Server ist und es eine kurze Lease-Dauer gibt, dann führt das auch zu dem beschriebenen Problem. Hatte ich vor ein paar Wochen gerade bei einem Kunden. Gruß, Nils

Moin, welches OS? Gruß, Nils

Moin, bei der Namensauflösung ist das normal, dort greift Round Robin. Der DC-Locator-Prozess, der die tatsächliche Anmeldung steuert, führt danach noch weitere Schritte durch, um den (laut AD-Konfig) "tatsächlich" günstigsten DC herauszufinden. Das muss dann nicht der sein, den DNS als ersten zurückgegeben hat - den fragt der Client nur nach den SRV-Records, was kein nennenswerter Traffic ist. Du kannst im DNS noch das Subnet-Mask-Ordering einschalten, wobei das aber, wenn ich nicht irre, nur auf das letzte Oktett der IP-Adresse schaut. Details kann man irgendwo nachlesen, hab ich grad nicht zur Hand. Gruß, Nils

Moin, sofern du vorher keinen anderen User eingerichtet hattest: Schlechte Karten. Da wir das Einbrechen in Systeme hier nicht supporten, werden wir dir dann nicht helfen können. Gruß, Nils

Moin, ja, wie jetzt? Soll dein eigenes Setup interaktiv laufen, oder soll das einmal vorgegeben sein? Ein Repackaging einer Software ist nicht immer möglich, und wenn, dann kann es sehr aufwändig sein. Auch MSI-Generatoren können da nicht zaubern, zumal die meisten gar nicht auf das Repackaging orientiert sind, sondern sich eigentlich an den Entwickler der Software wenden, der eine Installationsroutine bauen will. Hast du denn schon mal geprüft, ob deine Software auch Silent-Schalter zur Automatisierung hat? Gruß, Nils

Moin, behalte dabei im Blick, dass die "erste" Migration in deinem Szenario erst vollständig abgeschlossen sein muss, bevor die "zweite" beginnt. Da Quell- und Zieldomäne gleiche NetBIOS-Namen haben, kann die Transfer-Domäne nicht zu beiden gleichzeitig einen Trust haben. Das bedeutet, dass mit hoher Wahrscheinlichkeit auch die Transferdomäne zeitweise produktiv genutzt werden muss. Das wiederum bedeutet, dass nicht nur User dorthin migriert werden müssen, sondern auch Ressourcen. Nicht ohne. Wenn ihr aber FIM zur Steuerung nutzt, lässt sich evtl. ein Verfahren entwickeln, das ohne eine Domänen-Migration auskommt. Das erfordert natürlich einiges an Analyse und Design. Gruß, Nils

Moin, und wie weit ist diese neue Domäne? Vielleicht wäre es sinnvoller, die einzureißen und mit einem eindeutigen NetBIOS-Namen neu zu installieren. Selbst wenn das zwei Tage oder so dauern würde, wäre das vermutlich erheblich weniger Aufwand als eine doppelte Migration. Gruß, Nils

Moin, du kannst mit ADMT auch zweimal migrieren, dann haben die User hinterher zwei SID-History-Einträge. Ob das sinnvoll ist, steht auf einem anderen Blatt. Was ist denn der Grund für die Migration? Nur das Suffix .local? Dann würde ich das, ehrlich gesagt, bleiben lassen. Der Aufwand einer Migration ist groß bis sehr groß, das steht in keinen sinnvollen Verhältnis. Gruß, Nils

Moin, die Fragen sind alle völlig berechtigt. Ich teile die Ansicht. Angesichts der Ausgangsfrage ("kostenlos") und der sonstigen Aussagen des TO wage ich aber zu bezweifeln, dass er versteht, was wir meinen. Wenn man für das Backup seiner Produktionssysteme kein Geld ausgeben will, dann kann die Produktion ja nicht wichtig sein. Ansonsten: Bevor ich irgendwas Externes "Kostenloses" nehme, würde ich mit Windows Server Backup arbeiten. Insgesamt sehe ich das aber eher als Übergangslösung an, bis etwas beschafft ist, mit dem man ein ernsthaftes Recovery-Konzept umsetzen kann. Gruß, Nils

Moin, könntest du auch, ist aber viel mehr Aufwand. Gruß, Nils

Moin, guck mal in dem verlinkten Artikel recht weit am Anfang ... Gruß, Nils

Moin, $em aktualisiert sich nicht, weil es nur den Rückgabewert des Cmdlets New-MailboxExportRequest enthält. Das Cmdlet erzeugt einen neuen Request, mehr nicht. Also gibt es auch nur einen Rückgabewert. Dass du den Status periodisch abfragen musst, liegt in der Natur der Sache. Stell dir eine große Umgebung vor, in der du zahlreiche Requests hast. Wenn Exchange von sich aus überall, wo jemand lauscht, den Status aktualisieren müsste, hätte es ganz schön zu tun. Gruß, Nils

Moin, nutzt der Client, von dem aus du pingst, denselben DNS-Server? Hat er dasselbe DNS-Suchsuffix? Hast du den DNS-Clientcache gelöscht (ipconfig /flushdns)? VMware emphiehlt, auch einen Reverse Pointer im DNS einzutragen. Hast du das getan? Nutzt der vCenter denselben DNS-Server? Nutzt der ESXi denselben DNS-Server? Wenn du den Host per IP-Adresse ins vCenter aufnimmst, geht es dann? Falls nicht, ist DNS nicht das Problem. Hast du die anderen Vorschläge aus dem VMware-KB-Artikel schon durch? Gruß, Nils

Moin, das "Neu laden" bedeutet nichts weiter, als dass der DNS-Server seine Datenbank neu lädt. Das ist manchmal nötig, wenn es Replikationsverzögerungen gibt oder so. Nachteilig wird sich das nicht auswirken. Es wird allerdings an deinem Problem auch nichts ändern. Was ist denn genau der Stand? Du hast einen Host-Eintrag (A) für deinen ESXi gemacht, in dem der Name der IP-Adresse zugeordnet wird? Wenn du dann von einem Client aus diesen Namen anpingst, passiert was? Nutzt dein vCenter-Server den betreffenden DNS-Server? Geh mal dies hier durch, dann sehen wir weiter: [Was muss ich beim DNS für Active Directory beachten? (Reloaded) | faq-o-matic.net] http://www.faq-o-matic.net/2007/01/09/was-muss-ich-beim-dns-fuer-active-directory-beachten-reloaded/ Gruß, Nils