Jump to content

bgeltenpoth

Members
  • Gesamte Inhalte

    23
  • Registriert seit

  • Letzter Besuch

Über bgeltenpoth

  • Geburtstag 28.05.1964

Profile Fields

  • Member Title
    Newbie

Letzte Besucher des Profils

Der "Letzte Profil-Besucher"-Block ist deaktiviert und wird anderen Benutzern nicht angezeit.

Fortschritt von bgeltenpoth

Contributor

Contributor (5/14)

  • Erste Antwort
  • Engagiert
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei

Neueste Abzeichen

10

Reputation in der Community

  1. Ja, das befürchten wir auch ...., aber erstmal Danke für Deine bestätigung... Grins... ich weiss, es sind nur 10 Seiten...das spielt bei uns allerdings keine Rolle...(den Anwendungsfall wollte ich jetzt aber nicht auch noch erklären)... Aber danke für den Input..
  2. Hallo, vielen Dank für die Antworten... @NilsK Ich stimme dir natürlich zu, dass die Wahrscheinlichkeit, dass das RZ down ist aber die Standortkopplung noch funktioniert ziemlich gering sein wird. Wir hatten das auch schon intern diskutiert. (Leider war das neulich genau der Fall ) @cj_berlin Die Standortkopplung ist schon akzeptabel leistungsfähig. Der Zugriff auf die "normale" Shares ist wirklich ok. Nur bei DFS ist es fast nicht brauchbar wenn die lokalen DFS Server nicht erreichbar sind Das DFS ist AD Integrated und die Namespace Server sind unser 2 VMs an jedem Standort. Diese stellen dann auch die lokalen Shares zur Verfügung die über DFS-R repliziert werden. soweit alles gut... Wenn auf einer Site die DFS Nameserver wegfallen scheinen die lokalen Clients aber keinen Targetfailover auf die verbleibenden (entfernten) Nameserver oder die Shares selber hinzubekommen... wie es hier beschrieben ist: https://learn.microsoft.com/de-de/windows/win32/dfs/dfs-server-target-prioritization (Wobei ich nicht verstanden habe, wie ich diese Priosierung Steuern kann)
  3. Hallo, wir planen bei uns DFS einzusetzen um bestimmte Dateien an 2 Standorten synchron zuhalten. Dazu haben wir in einer Testumgebung DFS und DSF-R aufegesetzt. Wir betreiben 2 AD Sites an 2 unterschiedlichen Standorten. Die beiden Sites sind durch eine leistungsfähige Standortkopplung verbunden. Die DFS Server sind VM's (jeweils 2 pro Site) die jeweils in einem Rechenzentrum am jeweiligen Standort gehostet sind. Die Domain Controller sind auch über die Standorte verteilt. Wir haben also einen DFS Namespace eingerichtet und mehrere Shares die über Standort Kopplung synchronisiert sind. Alles das klappt soweit wunderbar. Clients an beiden Standorten können problemlos auf die DFS Shares zugreifen... Jetzt haben wir getestet, was denn passiert, wenn ein Rechenzentrum stirbt... Das haben wir simuliert in dem wir die beiden VMs einer Site heruntergefahren haben. Am "defekten" Standort konnten die Clients nicht mehr auf die DFS Share zugreifen, am andern Standort ging das problemlos. Unsere Erwartung war aber, das auch die lokalen Clients nach kurzer Zeit vielleicht auf das entfernte Target "umschalten" würden, das wird in den Share Eigenschaften ja auch so angezeigt. Irgendwas funktionierte auch, aber für einen Betrieb war das nicht brauchbar. (Zu träge, bis garnicht funktionierend) Wir haben auch mit den Cache Zeiträumen gespielt aber nur mit extrem kleinen Werten Erfolg gehabt... Im Prinzip geht es ja um einen hochverfügbaren, replizierten Fileservice... Im echten Leben sind die beiden VMs sogar Nodes eines Failover Clusters, jeder Node läuft auf einem dedizierten ESX Hosts...was gegen Hostausfall absichert. Gegen den RZ Ausfall hilft dass dann leider auch nicht wie wir feststellen mussten. Hat das schonmal jemand so oder ähnlich realisiert oder gibt es da bei uns Denkfehler... Die MS Doku zu DFS ist ...ach was ...MS Doku halt...was soll ich noch mehr sagen... Liebe Grüsse
  4. Wir haben bisher immer alles Retail oder OEM gehabt (Windows 2008R2 / 2012 R2). Die neuen Lizenzen (Windows 2019) sind bzw. werden alles Volumenlizenzen mit KMS Keys Aber echt...vielen, vielen Dank....das hilft mir schon total weiter....
  5. Hallo, Ich fremdel immer noch mit KMS Server und der Lizensierung bzw. Aktivierung... Wir stehen gerade vor einer Erneuerung unserer IT Landschaft. Derzeit haben wir ein Hyper V Cluster, einen phys. Domain Controller und einem Backup Server alles unter Win2008R2 , ausser der DC ist aber 2012R2. Das Hyper V Cluster hat Datacenter Editions. Alles lizensiert mit Retail oder OEM Lizenzen. In Zukunft wollen wir ein vSphere Cluster betreiben mit neuen Domain und Backup Server unter Windows 2019. Für die vSphere Maschinen haben wir entsprechende Win 2019 Datacenter Lizenzen gekauft (angepaßt an die Core Anzahl) und dafür KMS Keys erhalten. Win2019 Standard Lizenzen mit KMS Keys sind ebenfalls bestellt. Domain Controller und Backup Server werden aber erst nach dem Cluster erneuert. In dem Cluster soll dann eine Anzahl von Windows VM's laufen (zusätzlich noch einige Linux Maschinen, was man halt so braucht...) Zur Vorbereitung habe ich auf dem DC nun einen KMS Server installiert. Bei der Installation werde ich nach einem Aktivierungskey gefragt. Da laufe ich schon vor die erste Wand... Was für einen Key brauche ich denn an der Stelle? Einen speziellen KMS Server Installationskey? Einen unserer neu gekauften Windows 2019 Datacenter Keys? Für jede Betriebssystem Spielart (Standard, Datacenter) einen eigenen Key? Einen KMS Client Key für Windows 2012R2 , weil der Server ja 2012R2 ist...? Dann habe ich noch eine Frage generell zum Zusammenspiel mit vSphere...Wie läuft hier die Aktivierung? Ich installiere die VM mit dem generischen KMS Client Key. Zählt dann die VM auch für den KMS Aktivierungsthreshold (5 Server)? Bei Hyper-V ist es ja mit den AVMA Keys ganz einfach, geht das mit den generischen KMS Server Keys genauso (einfach) wenn ein KMS Server korrekt eingerichtet ist?
  6. Ja, erst ab 5 Servern überschreitest du den Aktivierungsthreshold: "...KMS-Hosts zählen die Anzahl der neuesten Verbindungen. Wenn ein Client oder Server den KMS-Host kontaktiert, zählt der Host die Computer-ID als weiteren Computer und gibt dann die aktuelle Anzahl als Antwort zurück. Der Client oder Server wird aktiviert, wenn die Anzahl hoch genug ist. Clients werden aktiviert, wenn die Anzahl höher als 25 ist. Server und Volumenlizenzversionen von Microsoft Office-Produkten werden aktiviert, wenn die Anzahl fünf oder mehr ist. ..."
  7. Cool, danke.... zumindest die Option über die Kommandozeile gibt es ...
  8. Hallo, ich teste gerade unter Windows 2012 R2 Windows Server Backup. Backups erstellen, lokal und über Netzwerk geht natürlich problemlos, auch das Wiederherstellen des SystemStates über Netzwerk funktioniert gut. Ich würde aber das Feature auch gerne als Ersatz für 3rd Party Imageing Lösung (z.B. Acronis) einsetzen. Dafür bietet Windows Server Backup ja auch die Bare Metal Option. Beim Restore muss über die Windows DVD gebootet werden, und dann die Recovery Option benutzt werden. Hier kann ich zwar den UNC Pfad angeben, aber die Verbindung schälgt fehl weil in diesem Netz kein DHCP verfügbar ist. Ich finde aber keine Möglichkeit Netzwerk Parameter einzustellen. Bin ich dann damit raus? Hat da jemand Erfahrungen mit? Sagt doch mal Bescheid... Liebe Grüsse Benedikt
  9. Hallo zusammen, bei uns ist die Entscheidung gefallen unser bisheriges ClassC Netz in ein ClassB Netz zu ändern. Grundsätzlich haben wir nur eine Single Site mit 2 DC's (einer davon virtualisiert). Kern der ganzen Infrastruktur ist ein 3 Knoten MSCS Cluster, das über Hyper-V alle benötigten Services zur Verfügung stellt. Um das Cluster geht es denn nun auch. Ich muss ja auch hier die IP Adressen ändern. Vor allem die des Clusters selber. Hier gibt es nun ja leider das Henne/Ei Problem, entweder ich ändere zuerst die IP Adresse des Clusters, oder die der Knoten selber. In allen Fällen fällt das Cluster auf die Nase. Meine Idee ist bisher folgende: 1. Alle Cluster Resourcen stoppen (Damit ist auch der virtuelle DC Offline) 2. Cluster Service auf allen 3 Knoten stoppen 3. IP Adresse des Hardware DC's ändern und neustarten (vorher in der DNS eine neue Reverse Lookup Zone erstellen) damit stehen die Domain Dienste im neuen Netz zur Verfügung 4. IP Adressen der Cluster Knoten anpassen 5. Mit Regedit in der Registry die Cluster IP Adresse suchen und anpassen 6. Clusterknoten neu starten Anschliessend müsste das Cluster mit der neuen IP Adresse neu starten. Da noch alle Resourcen offline sind fährt erstmal nix weiter hoch. Dann kann ich gemütlich allen Resourcen neue IP Adressen geben und die nach und nach starten. Soweit mein Plan..... Frage: Ist das machbar oder habe ich was übersehen.....? Um Kommentare wäre ich dankbar..... Liebe Grüsse Benedikt
  10. Hallo zusammen, zumindest mein Problem hat sich geklärt: Also, zeitgleich mit dem ISA Server wurde auch unser DHCP Server neu gestartet (Was ich bis gerade noch nicht wusste). Der ISA Server hat darauf hin keinen Address Pool reservieren können und hat den Clients fröhlich APIPA Adressen zugewiesen. Lustigerweise scheint das bei den XP und Win2003 Rechner im Domain Netz egal zu sein. Nur die Win7 Rechner scheinen das (berechtigter Weise) für ein Problem zu halten. OK, den Remote Access Service auf dem ISA Server durchgestartet und schon werden die richtigen IP Adressen an die Clients weitergegeben. Schon klappt es auch per RDP wieder mit dem Windows 7 Rechner. Also nochmal: Hatte nix mit RDP zu tun.... LG Benedikt
  11. Hi il_principe, danke für den Input. Ich versuche das gerade mal nach zu vollziehen, kann aber nirgendwo die Möglickeit diese Option finden. Also ich starte die Firewall Eigenschaften in der Systemsteuerung und hangel mich dann auf die erweiterten Einstellungen weiter. Unter "eingehende Regeln" suche ich dann "Remote Desktop (TCP eingehend)". Unter "Bereich" (am ehesten würde ich hier noch was erwarten) sind aber sowohl die lokalen als auch die Remote Addressen auf "beliebige Adresse" eingestellt. Andererseits tritt der Effekt ja auch auf wenn die Firewall komplett deaktiviert ist. (Aber der Bill macht ja schonmal was er will:-) Wir forschen weiter.... Benedikt
  12. Hallo zusammen, ich verzweifel da gerade an einem Problem. Eine Kollegin will von zuHause aus per VPN auf einen Win7 64 Bit Rechner im Office per RDP zugreifen. Grundsätzlich hat das auch schon schön funktioniert. Ab heute Mittag aber nicht mehr. Das ganze ist sehr rmerkwürdig: Der Rechner der Kollegin ist ein XP Laptop bei ihr zu Hause. Sie baut eine L2TP Verbindung zu unserer Firewall ( MS ISA Server) auf und ist dann mit dem Intranet verbunden. Sie kann auf alle Resourcen zugreifen ausser auf diesen Win7 Rechner. Beim Verbindungsversuch auf den Rechner erhält sie einen Timeout. Jetzt wird es noch ****er: Innerhalb des Intranets kann auf den Rechner per RDP zugegriffen werden. Der Workaround ist im Augenblick: VPN Verbindung auf einen XP Client aufmachen, und dort lokal per RDP weiter auf den Win7 Host. (Wie **** ist das denn?) Da ich heute auch im Homeoffice arbeite konnte ich das Verhalten auch von meinem Rechner nachvollziehen (auch bei mir noch: XP Laptop) Offensichtlich akzeptiert der Win7 Rechner keine ankommenden Verbindungen, weder RDP noch sonst was, wenn sie nicht aus dem lokalen Netz kommen. An dem Rechner selber habe ich natürlich die Möglichkeit, ganz normal ins Internet zu gehen, ausgehender Traffic funktioniert also. Den Windows Firewall Dienst habe ich auch schon mal abgeschaltet, alles ohne Erfolg. Habe ich da ein Sicherheitsmerkmal noch nicht verstanden? Das ganze konnten wir auch mit einem weiteren Win7 Rechner validieren,. Dieser zeigt grundsätzlich den gleichen Effekt (RDP im LAN geht, über VPN nicht) Es handelt sich auch nicht um ein DNS Problem, da die Namensauflöung funktioniert und wir auch versucht haben uns über die IP Adresse zu verbinden. Dieses Problem tritt auf seit heute Mittag der ISA Server nach Windows Updates neu gestartet wurde. Aber wie gesagt, grundsätzlich arbeitet die Firewall korrekt (ausser eben für die Win7 Rechner) Hat das schon mal jemand gehabt? Gibt es da bekannte Probleme? Jeder Input ist willkommen..... LG Benedikt
  13. Hallo zusammen, wir müssen für einen Kunden ein komplexes Softwaresystem installieren. Dieses System besteht aus mehreren Application Servern, Clustern mit MSSQL und Workstations. Die Server und Workstation müssen in die vom Kunden beigestellte AD Domäne installiert werden. Die Software kann auch nicht ohne Domänen Integration installiert werden. Aus Kostengründen soll die Installation natürlich hier bei uns im Werk passieren, während die Domäne natürlich vor Ort im Einsatz ist. Tja...hier liegt der Hase im Pfeffer...geht das überhaupt einigermassen? Die DC's sind beim Kunden bereits im produktiven Betrieb und können nicht zu uns kommen. Die erste Idee war, einen Rechner Onsite als DC zu installieren und die benötigten FSMO Roles (Global Catalog, RID Master, PDC Emulator ... nochwas?) darauf zu geben. Dieser DC würde dann zu uns kommen und wir würden dann installieren. Was würde dann aber die Domäne bei Kunden machen. Würde das funktionieren (mal angenommen der Kunde würd in der Zeit keine Rechner in die Domäne hängen wollen)? Würden sich die DC's bei der Onsite Inbetriebnahme wieder synchronisieren und die neuen Objekte übernehmen? Die 2te Idee wäre dann eine eigene Site aufzumachen und z.B. nur per SMTP zu synchronisiren. Da müsste man dann allerdings durch mehrere Firewalls durch (inkl. NAT router), und ich bräuchte auch eine eigen IP Range (die ich hinterher wieder umstellen müsste, auch nicht schön.... Fragen: Hat sowas schon mal jemand gemacht? Gibt es bessere Ansätze? Vielen Dank schon mal im voraus... Liebe Grüsse Benedikt
  14. Hallo daim, danke für die Antworten. Ich versuche also zu präzisieren: Es existiert in der zentrale eine Gesamtstruktur mit einer Domäne mit Win 2003 DC's Gesamtstruktur Funktionsmodus: Win 2003 Nun ich hatte es so verstanden, dass zumindest die Computer accounts nach einiger Zeit ablaufen wenn die Rechner keine Verbindung mit der Domäne haben. Falsch gedacht?? Jedes Mobile System enthält so oder so einen Server (derzeit) unter Win2000, auch wenn da nur noch ein weiterer Rechner dran hängt. Das ist leider duch die Applikation so vorgegeben. Den könnte man dann für das mobile System zu einem DC machen. Frage: Wenn ich lediglich die Mobilen Systeme zu Membern der zentralen Domäne mache, können sich dann unterwegs auch Dienste mit Domänen accounts problemlos anmelden? (Warum eigentlich nicht??(laut gedacht)) Ich meinte natürlich Traffic zwischen den zentralem DC und mobilen DC der Sub Domain wenn ich die mobilen Systeme als Sub Domänen der Zantrale betreibe. Ich glaub da muss ich nochmal über die wirklichen Anforderungen Grübeln. Vielen dank erstmal
  15. hallo zusammen, ich brüte gerade an einem Problem und mir will nicht das große Licht aufgehen. Also: Wir haben einen Kunden mit einer zentralen ADS an dem ein Haufen Rechner laufen. Gleicher Kunde hat mehrer Systeme (meist bestehend aus 2-3 Rechnern) unter Win2K laufen, die Mobil sind und teilweise monatelang unterwegs sind, ohne Netzverbindung zum zentralen System. Diese Systeme wurden deshalb nicht in die ADS integriert sondern laufen als Workgroups. Auf den einzelnen Rechnern sind einige Funktionsaccounts eingerichtet, die identisch zu Accounts in der ADS sind. Damit konnte dann ein manueller Datenaustausch (meist reiner Fileaustausch) zwischen Arbeitsgruppen Rechnern untereinander und ADS Rechnern durchgeführt werden. So, aber alles wird halt anders. Neue Softwarekomponenten benötigen (Web-)Dienste die auf andere Systemen (Arbeitsgruppen Rechnern und / oder ADS Rechnern) zugreifen und da komme ich leider mit der Arbeitsgruppen Lösung nicht weiter (oder doch???). Es wird also geplant, dann auch die Mobilen Systeme mit ADS auszustatten. Also jedes Mobile System erhält mindestens einen DC. Nun meine Frage an die Fachleute: Wie kann ich denn die ADS an der Stelle sinnvoll aufbauen. Alle ADS Domänen in den Tree der Zentrale hängen? Was passiert dann wenn monatelang kein Netzwerk Traffic möglich ist? Unabhängige Trees / forest für alle Mobilen Systeme? Wie kann ich dann Trusts zwischen den Systemen aufbauen wenn ich das brauche? Frage: Hat jemand sowas schonmal machen müssen???? Jede Hilfe ist willkommen... Viele Grüsse
×
×
  • Neu erstellen...