Jump to content

nn23

Members
  • Gesamte Inhalte

    49
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von nn23

  1. Ok, habs gefunden xD Es scheint der Sophos Web Filter zu sein, welcher die Kommunikation stört. Dienst aus -> geht scheinbar
  2. Hi ich habe hier 2 Systeme (Win10 + Srv22), die per IPSec über Port 80 kommunizieren sollen (normale Windows Domäne, viele Konfigurationen, ansich nix besonderes). IPSec ist konfiguriert, Windows Firewall Port 80 für bestimmte Benutzer am Server frei (Wenn die Verbindung sicher ist). Das läuft aber nur teilweise. Vom Client aus: telnet Server:80 -> funktioniert einwandfrei Browser http://server -> funktioniert nicht In der Firewall unter Sicherheitszuordnungen/Hautpmodus sehe ich auch das Problem: Beim Telnet ist die Authentifizierung OK (1. Computername, 2. Benutzername). Beim Browserzugriff ist die 2. Authentifizierung nicht ok. Da steht ebenfalls der Computername (anstelle des Benutzernamens). Also erste Auth: Domain\Computerkonto$ / 2. Auth Domain\Computerkonto$ Der Browser identifiziert sich als "System", welches logischerweise nicht berechtigt ist -> Zugriff verwehrt. Der Prozess am Client läuft lt. ProcessExplorer aber im Benutzerontext. Verschiedene Browser verhalten sich gleich (FF, Edge, IE). Nehme ich den Haken bei "Nur für bestimmte Remotebenutzer" raus, funktioniert es sofort. Es ist scheinbar wirklich die Auth, die falsch vom Client, bzw. speziell vom Browser gesendet wird. Weil telnet funktionuckelt wunderbar. Was ist das?
  3. Hi IIS Manager, Sites öffnen, Deine Site anklicken. Dann im rechten Fenster "Autorisierungsregeln". Manchmal muss man den IIS Manager nach Installation neu öffnen. Der Punkt sollte aber da sein.
  4. ServerManager, IIS Rolle, URL Authorisierung. Dann im IIS manager die Site auswählen, Authorisierung rechts, und bei Rolle "Gruppe@Domain", also "IIS_MeineSeite@domände.fqdn.de" eintragen.
  5. Hallo zusammen, habe hier ein Problem zu dem ich einfach keine Lösung finde... Kurz gesagt authentifiziert sich der Windows 10 Client unterschiedlich,je nachdem welches Programm ich nutze um auf einen Zielport (IIS) am Server zuzugreifen. Wir wollen Ports auf Basis von AD-Gruppen freigeben. Spieler sind 2 Hyper-V VMs, ein Server 2016, ein Win10 1809 / alles voll gepatcht. - Defender Firewall - IPSec aktiviert - "Computer und Benutzer (Kerberos5)" - Firewall Regel "Port 80 erlauben, wenn Verbindung sicher und Benutzername=kennung666" - Client ebenso konfiguriert. Dann am Win10 Client als kennung666 angemeldet und ein Telnet auf Server:80 => Funktioniert Als nächstes den Browser aufgerufen, http://Server:80 => Funktioniert nicht? Der Zugriff via Browser auf Server:80 funktioniert nicht, während Telnet Server:80 problemlos funktioniert. Prüfe ich in der Firewall/Überwachung/Sicherheitszuordnung die Verbindung sehe ich folgendes: Stelle ich die Verbindung via Telnet her, authentifiziert sich zuerst der Computer (Remote-ID für erste Auth), danach der Benutzer (Remote-ID für 2. Auth) => Alles gut Stelle ich die Verbindung via Browser her, authentifiziert sich zuerst der Computer (Remote-ID für erste Auth), danach wieder der Computer (Remote-ID für 2. Auth) => Nix gut Die Kerberos Authentifizierungs ID ändert sich, je nach dem welches Programm ich zum Verbindungsaufbau nutze. Siehe hier: Getestet mit IE, Edge, Firefox und Chrome. Überall das Gleiche. Habe schon alle GPOs entfernt, PCs neu gestartet, Updates installiert, verschiedene Optionen getestet, kein Proxy, alles mehrfach neu konfiguriert. Prinzipiell funktioniert es ja. Nehme ich den Telnet klappt es als berechtigter User, und klappt nicht bei nicht berechtigten Usern. Ansich alles gut! Stehe da gerade echt vor nem Rätsel... Jemand ne Idee was Das sein kann? Danke+Gruß Alex
  6. 2008 kann ich leider nicht testen, da ein Treiberkonflikt die Netzwerkverbindung unterbricht :/ Aber wieso geht es in eine Richtung, und nicht in die andere?
  7. Hi, habe ich auch probiert, von auto über disabled bis hin zu experimental. Hat leider keinen Effekt. Ich werde jetzt mal 2008 installieren und testen wie es da aussieht. Gibt es vielleicht eine Beschreibung im Netz, welche den Mechanismus erklärt wie Dateien über das Netz kopiert werden? Wieso schreibt Windows die Daten wenn sie vom W7 gesendet werden zuerst in den Ram und dann auf HDD; und wieso tut er das nicht wenn ich die Datei vom 2003er hole? Denn da bleibt der Ram leer. Gruß Alex
  8. Hi, ja, AHCI ist aktiviert. Ich habe das fanze auch schon mit einer neueren Platte (1,5 TB Samsung Ecogreen) probiert, gleiches Ergebnis. Dass das Teil insgesamt keine Perfomrancegranate wird ist mir klar. Aber wenn ich die Operation vom 2003er aus anstosse funktioniert ja alles ohne Probleme... Ich will ja keine 100 MB/s haben, aber ist mir schon ein bisschen zu langsam wenn der da mit 8 MB/s in einem Gigabitnetzwerk rumeiert ;)
  9. Hallo, sorry für den Titel, aber mir fällt keine bessere Formulierung ein. Ich weiß nicht mehr weiter... Ich möchte eine große Datei (mehrere GB) übers Netz kopieren. Folgende Situation: W7 Client <-> Gigabit Switch <-> 2003 Server - Ich melde mich an dem W7 PC an - Mappe das Laufwerk des Servers - schiebe eine Datei vom W7 ( C: ) auf den Server (\\server\freigabe) Das hat folgendes Verhalten zur Folge: Der Kopiervorgang fängt mit ~60 MB/s an. Auf dem Server steigt die Ramnutzung an, und in dem Moment wo der Ram die 1,1 GB Marke erreicht, bricht die Übertragungsrate auf ~6 MB/s ein, gleichzeitig sinkt die Ram Auslastung langsam. Ist diese wieder bei ~300 MB angekommen steigt die Übertragungsrate wieder auf 60 MB/s und der Ram füllt sich wieder. Dieses Spielchen wiederholt sich, bis die Datei komplett kopiert wurde. --- Cut --- - Ich melde mich an dem 2003er an - Mappe das Laufwerk des Clients - hole eine Datei vom W7 (\\W7-PC\Freigabe\Datei) auf den Server ( C: ) Es ist die gleiche Datei, die selbe Quelle und das gleiche Ziel. Einziger Unterschied ist, dass der 2003er - und nicht der Win7 PC den Kopiervorgang initialisiert. Die Datei wird konstant mit 50 MB/s übertragen, der Ram wird kein bisschen gefüllt, es geht wesentlich schneller! Auch der ProcessExplorer zeigt ein viel homogeneres Bild. Wie gesagt, gleiche Datei, gleiche Quelle gleiches Ziel. Was ist das und wie kann ich das abstellen? Ich möchte mich nicht jedes mal auf den Server aufschalten um eine Datei zu kopieren... Bisher probiert: - W7 sowie 2003 komplett gepatcht - verschieden kopiertools (Killcopy, Teracopy, Explorer) - LargeFileCache = 0 - UtilizeNtCaching = 0 - TcpDelAckTicks = 0 - Viele Netzwerkeinstellungen wie MTU, TCPWindowSize, etc. - EnableSecuritySignature = 0 Ich schließe eigentlich auf ein Softwareproblem, da es ja in eine Richtung funktioniert. Es muss imo ein Mechanismus in Windows sein, Push-Modus vs. Get-Modus oder so... Leider finde ich bei google nichts was mir weiter hilft. Ich hoffe auf einen Tip, wo ich weiter suchen kann, mir gehen die Ideen aus :( Danke schonmal fürs lesen :) Wenn ich irgendwelche wichtigen Infos vergessen habe liefer ich die natürlich nach ;) 2003er Asus ITX220 2 GB Ram 80er Sata Platte W7 PC Gigabyte 965p DS3 Q9300 Samsung HDD
  10. Ok, wenn wir NAT auf dem dezentralen Server für die Internet, sowie VPN Verbindung aktivieren geht es. Aber halt nur in eine Richtung! Was wäre, wenn ich eine VPN-Verbindung zusätzlich in die andere Richtung aufbaue? Also vom zentralen zum dezentralen Server, denn dann kann ich ihm doch Routinginformationen geben (alles an 192.168.10.0 über VPN-Verbindung)?
  11. Ok, Das läuft jetzt. Wir haben den Server zurückgesetzt und neu konfiguriert. Keine Ahnung was das war. Aber ich habe noch eine Frage: Also: Wir haben am zentralen Standort den Server stehen. dieser nimmt vpn Verbindungen entgegen. Hat eine interne Schnittstelle 192.168.1.1 und eine am Internet. An einem anderen Standort haben wir einen Server stehen. Dieser hat auch 2 Netzwerkschnittstellen: 1 Internet 192.168.2.1 und eine interne 192.168.10.1 RRAS konfiguriert, und eine Wählverbindung erstellt. Der Server wählt sich über die Internet-Schnittstelle am VPN Server ein (die Wählverbindung bekommt dann die 192.168.1.10). Verbindung steht, Statische Route auf dem dezentralen Server DST 192.168.1.0 SM: 255.255.255.0 Schnittstelle: Remoterouter von dem Server kann ich auch auf den zentralen Server zugreifen und umgekehrt. Ich komme aber weder zum, noch aus dem 192.168.10er Netz am 2. Standort. Die Clients in dem Netz müssen sich aber am zentralen Server melden können. Mir scheint es so, als ob der zentrale Server nicht weiss wohin mit den Paketen. Ich habe versucht eine Route einzutragen (nach 192.168.10.0). Dort muss ich dann ja auch eine Schnittstelle auswählen. Da kann ich aber nur die interne, und die Internet-Schnittstelle nehmen. nicht aber die VPN-Verbindung des Server der sich einwählt. Hier hab ich versucht das ganze nochmal darzustellen: Ping von zentraler Server nach dezentraler Server OK Ping von dezentraler Server nach zentraler Server OK Ping von zentraler nach XP Client und zurück geht nicht. Hat jemand eine Idee? Danke!
  12. Hallo, ich habe hier ein sehr komisches Problem: Kurz zur Struktur: ein zentraler Server (SRV1) (DC+VNP Server per Routing und RAS) 2 Netzwerkkarten, eine mit Internetanbindung, eine intern (LAN1). 1 Server an einem anderem Standort (SRV2) (Routing & RAS) 2 Netzwerkkarten, eine am Internet, eine in einem separaten Netz(LAN2). Beide W2k8 Standard Alle NICs haben feste IPs SRV2 soll als eine VPN Verbindung zu SRV1 aufbauen, und als Router zwischen LAN1 und LAN2 fungieren. Also auf SRV2 Routing und RAS installiert, Sichere Verbindung zwischen 2Netzen herstellen, eine VPN Wählverbindung einrichten, Route zu LAN1 hinzufügen -> fertig. Soweit funktioniert es auch erstmal. SRV1 ist der VPN-Server SRV2 wählt sich bei SRV1 per VPN ein, bekommt seine IP-Adresse, und die Verbindung steht. Jetzt starte ich SRV2 neu. Er fährt hoch, der RR Dienst startet, die VPN-Wählverbindung wählt sich bei SRV1 ein. Auf SRV1 seh ich auch den VPN Client. Ich kann von SRV2 auf die interne Adresse des SRV1 pingen. Wenn ich aber z. B. im Windows Explorer versuche auf eine Freigabe auf SRV1 zuzugreifen bekomme ich die Meldung dass der Netzwerkpfad nicht gefunden wurde. Domänenaufnahme z. B. klapppt dann auch nicht -> gleiche Meldung. Jetzt kommts: Ich - beende den Routing und RAS Dienst - deaktiviere einmal alle Netzwerkverbindungen, - aktiviere die Netzwerkverbindungen - starte den Routing und RAS Dienst => RR Dienst startet => die VPN-Wählverbindung wählt sich bei SRV1 ein => Auf SRV1 seh ich auch den VPN Client. Jetzt kann ich stabil und ohne Probleme auf das Netzwerkshare zugreifen oO Das ganze ist reproduzierbar, also nach jedem Windows Neustart muss ich Dienst und Netzwerkverbindung de- und wieder aktivieren, sonst ist keine Verbindung möglich (bis auf den Ping). Da der Netzwerkverkehr ansich nach Dienst-neustart funktioniert denke ich, dass R&R ansich funktioniert. Was passiert beim Dienst- und Netzwerkverbindungs-Neustart was das Verhalten beeiflussen kann? Firewall testweise deaktiviert, daran liegts nicht. Verschiedene Netzwerkkarten probiert, gleiches Problem. Server schon neu installiert, also mit einem blanken System getestet Bin da atm etwas Ratlos. Hat jemand schonmal etwas ähnliches erlebt? Danke und Gruß nn23
  13. Hi olc, "Automated Site Coverage" haben wir per GPO für die DCs, welche das übernehmen sollen, aktiviert: http://666kb.com/i/b34ct1ulbi73ua1jq.jpg Ins DNS tragen sich die DCs auch ein: DNS: DOMAIN\_Sites http://666kb.com/i/b34cp82af72yb61jq.jpg Danke dir Alex €: Danke dir smartino für den Tipp, mittlerweile habe ich herausbekommen, dass es daran liegt, wie der DFS-Dienst dem Client die Verfügbaren Orte des Sysvol liefert.
  14. Hallo olc, Standardmäßig ist ja die "Default Target Selection" aktiviert. Da tritt das Problem auf, egal ob der Haken aktiviert oder deaktiviert ist (werden ja keine Kosten berechnet). Ich habe jetzt per Reg Key "Least Expensive Target Selection (Site-costing)" aktiviert. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs\Parameters\SiteCostedReferrals=1 Der Client bekommt jetzt (bei deaktiviertem "Bridge All Site Links") immer als erstes die 3 zentralen DCs als Referral. Danach die DCs in den Außenstandorten. Was ich noch nicht verstehe: Standardmäßig ist ja "Default Target Selection aktiviert". Distributed File System: Frequently Asked Questions Link or root targets in the same site as that of the client. Ich verstehe das so, das der Client guckt, welche Server in seiner Site liegen und diese ungeordnet an den Client schickt. So, nun ist die Site ohne DC. Wie kann ich zwei Sites einen DC zuordnen? "Automated Site Coverage" tuts ja anscheinend nicht? Danke und mfg Alex
  15. _________________________________________________ C:\>dfsutil /PKTINFO Microsoft(R) Windows(TM) Dfs Utility Version 4.2 Copyright (C) Microsoft Corporation 1991-2005. All Rights Reserved. --mup.sys-- 1 entries... Entry: \sgremote.stg\sysvol ShortEntry: \sgremote.stg\sysvol Expires in 0 seconds UseCount: 0 Type:0x1 ( DFS ) 0:[\swdepot53.sgremote.stg\sysvol] State:0x21 ( ) 1:[\swdepot31.sgremote.stg\sysvol] State:0x21 ( ) 2:[\swdepot30.sgremote.stg\sysvol] State:0x21 ( ) 3:[\sg-dc-02.sgremote.stg\sysvol] State:0x31 ( ACTIVE ) 4:[\swdepot50.sgremote.stg\sysvol] State:0x21 ( ) 5:[\swdepot28.sgremote.stg\sysvol] State:0x21 ( ) 6:[\swdepot58.sgremote.stg\sysvol] State:0x21 ( ) 7:[\swdepot61.sgremote.stg\sysvol] State:0x21 ( ) 8:[\swdepot100.sgremote.stg\sysvol] State:0x21 ( ) 9:[\sg-dc-01.sgremote.stg\sysvol] State:0x21 ( ) 10:[\swdepot33.sgremote.stg\sysvol] State:0x21 ( ) 11:[\swdepot140.sgremote.stg\sysvol] State:0x21 ( ) 12:[\swdepot98.sgremote.stg\sysvol] State:0x21 ( ) 13:[\swdepot59.sgremote.stg\sysvol] State:0x21 ( ) 14:[\swdepot26.sgremote.stg\sysvol] State:0x21 ( ) 15:[\swdepot25.sgremote.stg\sysvol] State:0x21 ( ) 16:[\swdepot51.sgremote.stg\sysvol] State:0x21 ( ) 17:[\swdepot23.sgremote.stg\sysvol] State:0x21 ( ) 18:[\swdepot32.sgremote.stg\sysvol] State:0x21 ( ) 19:[\swdepot27.sgremote.stg\sysvol] State:0x21 ( ) 20:[\swdepot120.sgremote.stg\sysvol] State:0x21 ( ) 21:[\swdepot20.sgremote.stg\sysvol] State:0x21 ( ) 22:[\sg-dc-03.sgremote.stg\sysvol] State:0x21 ( ) 23:[\swdepot52.sgremote.stg\sysvol] State:0x21 ( ) 24:[\swdepot54.sgremote.stg\sysvol] State:0x21 ( ) 25:[\swdepot21.sgremote.stg\sysvol] State:0x21 ( ) DfsUtil command completed successfully. _________________________________________ – Referrals Referral Version: 3 Size: 34 Server Type: Don't know (0) Flags: 0x0000 .... .... .... ...0 = Strip: Do NOT strip off any characters Proximity: 900 TTL: 0 Path Offset: 884 Alt Path Offset: 926 Node Offset: 968 Path: \sgremote.stg\sysvol Alt Path: \sgremote.stg\sysvol Node: \swdepot51.sgremote.stg\sysvol Unknown Data: 00000000000000000000000000000000 Referral Version: 3 Size: 34 Server Type: Don't know (0) Flags: 0x0000 .... .... .... ...0 = Strip: Do NOT strip off any characters Proximity: 900 TTL: 0 Path Offset: 850 Alt Path Offset: 892 Node Offset: 996 Path: \sgremote.stg\sysvol Alt Path: \sgremote.stg\sysvol Node: \swdepot27.sgremote.stg\sysvol Unknown Data: 00000000000000000000000000000000 Referral Version: 3 Size: 34 Server Type: Don't know (0) Flags: 0x0000 .... .... .... ...0 = Strip: Do NOT strip off any characters Proximity: 900 TTL: 0 Path Offset: 816 Alt Path Offset: 858 Node Offset: 1024 Path: \sgremote.stg\sysvol Alt Path: \sgremote.stg\sysvol Node: \swdepot52.sgremote.stg\sysvol Unknown Data: 00000000000000000000000000000000 Referral Version: 3 Size: 34 Server Type: Don't know (0) Flags: 0x0000 .... .... .... ...0 = Strip: Do NOT strip off any characters usw... Text ist zu lang mit 14000 Zeichen^^
  16. Ok, ich hab den Schuldigen gefunden: Die Authentifizierung gelingt ohne Probleme, der Client findet seine Site, den richtigen DC, authentifiziert sich und alles ist OK. jetzt gehts los: Dann versucht der Client per SMB seine GPOs zu ziehen, und bekommt vom DC eine Liste der DFS_REFERRALs: Path: \sgremote.stg\sysvol Alt Path: \sgremote.stg\sysvol Node: \swdepot51.sgremote.stg\sysvol Path: \sgremote.stg\sysvol Alt Path: \sgremote.stg\sysvol Node: \swdepot27.sgremote.stg\sysvol und viele mehr Also alle DCs, zufällig ausgewählt in nicht sortierter Reihenfolge. Diese arbeitet der Client natürlich von oben nach unten ab. Kann den 1. nicht erreichen, 45 Sek. Timeout, Kann den 2. nicht erreichen, 45 Sek. Timeout, usw. bis er einen bekommt den er erreichen kann. Beim googlen bin ich auf folgenden Thread gestoßen: SYSVOL - Clients connecting across WAN for SYSVOL data - Active Directory sowie auf folgenden kb-Artikel: "You may receive DFS referrals that contain a list of random DFS targets, random SYSVOL or NETLOGON referrals, or experience slow performance when you access a shared folder in a DFS namespace on a Windows Server 2003-based computer" You may receive DFS referrals that contain a list of random DFS targets, random SYSVOL or NETLOGON referrals, or experience slow performance when you access a shared folder in a DFS namespace on a Windows Server 2003-based computer "RESOLUTION: To resolve this problem, obtain the latest service pack for Windows Server 2003." Problem dabei ist nur, wir haben SP2 überall installiert :/ 32 Bit, Windows Server 2003 Standard Edition Interessant ist dieser Abschnitt im KB-Artikel: Note: Domain controllers generate site-costed SYSVOL and NETLOGON referrals only if the SiteCostedReferrals registry entry is added to the registry on all domain controllers, and the DFS service is restarted. <Der key ist nicht gesetzt!> When the SiteCostedReferrals registry entry is not added, SYSVOL or NETLOGON referrals contains two sets of targets. <Trifft bei uns zu!> The first set contains all the targets in the same site as the client. <Woher weiss der DC welche DCs in der Site sind? AD_Sites&Services oder DNS?> The second set contains all remaining targets. <Das ist imo das, was der Client vom DC bekommt. Eine Liste mit allen Referrals=alle DCs der Domäne> The SiteCostedReferrals registry entry is located in the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs\Parameters <Der key ist nicht gesetzt!> Also wenn ich das richtig verstehe macht der DFS Dienst eine Liste mit allen Referrals, weil er in der Site des Clients keine DCs findet. Ich werden den Key morgen mal setzen und schauen was passiert. Gibt es da Erfahrungswerte zu? Unten einmal ein dfsutil /PKTINFO am Client, sowie das gesniffte Paket vom DC zum Client mit den DFS_Referrals.
  17. Ja, danke. Werd mich da mal durchwühlen. Wenn ich mehr weiss melde ich mich wieder ;)
  18. Hehe, habe ich jetzt auch gemacht, nur wurmt mich das! Ich will wissen was da genau passiert und woran es liegt ;) Danke euch!
  19. Hallo Sunny, das hatten wir bereits getestet, bringt keine Verbesserung. - Software Installation haben wir nicht - Scripts werden keine ausgeführt - Folder Redirection nutzen wir an Standorten nicht Für die Benutzerconfig gibt es ja den UserEnvDebug Lvl, nur leider habe ich nichts derartiges für die Computer GPOs gefunden :/
  20. Jo, danke Suuny61. Aber den Link kannte ich schon. Diese Einstellung ändert also die Verarbeitung von Prozessen von asynchron nach synchron, richtig? D. h. ein Prozess beim PC Start hängt, bzw. braucht sehr sehr lange. Damit sind wir wieder am Anfang, wie bekomme ich raus, was beim Anmelden so lange dauert? ;)
  21. Ok, ich konnte das nochmal ein bisschen eingrenzen, sobald ich die Einstellung "Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten" per GPO zuweise, habe ich lange Anmeldezeiten. Lasse ich diese Einstellung nicht konfiguriert geht alles schnell wie es sollte... Hat jmd. einen Link, was genau bei dieser Einstellung passiert? Danke
  22. Hi twiki, der Paketverlust zu dem einen Server ist OK. Ist von Arcor, den können wir generell nicht anpingen. Ich denke der Fehler war schon immer da, und je mehr DCs ins Netz kamen, desto länger wurden die Anmeldezeiten. Sicher kann ich das natürlich nicht sagen! Ja, es werden Netzlaufwerke gemappt, aber daran liegt es nich. Die werden erst nach der Anmeldung per Benutzer-GPO gemappt. Es dauert aber schon vor dem "Strg+Alt+Entf" so lange. DNS Fehler haben wir keine im Eventlog. Das Netzwerk ansich funktioniert einwandfrei (DNS/DHCP/Routing/WINS).
  23. Hi Sunny61 , danke für den Tipp mit Bits, werd ich mir bei Gelegenheit mal anschauen :) Mit den Anmeldezeiten hängt das, wie du sagst, nicht zusammen, das muss was anderes sein.
  24. Hallo twiki, das Netzwerk hat keinerlei Aussetzer, Paketverlust von 0% bei tausenden Paketen. Ping liegt bei ~10-20 ms. Pathping mach ich sofort mal, sek. €: Routenverfolgung zu sg-dc-01.sgremote.stg [192.168.10.217] über maximal 30 Abschnitte: 0 pc-11-152.sgremote.stg [192.168.22.15] 1 router-arcor-22.sgremote.stg [192.168.22.1] 2 localhost [10.8.224.21] 3 localhost [10.8.224.106] 4 sg-fw-extlan.sgremote.stg [192.168.210.253] 5 sg-dc-01.sgremote.stg [192.168.10.217] Berechnung der Statistiken dauert ca. 125 Sekunden... Quelle zum Abs. Knoten/Verbindung Abs. Zeit Verl./Ges.= % Verl./Ges.= % Adresse 0 pc-11-152.sgremote.stg [192.168.22.15] 0/ 100 = 0% | 1 1ms 0/ 100 = 0% 0/ 100 = 0% router-arcor-22.sgremote.stg [192.168.22.1] 0/ 100 = 0% | 2 9ms 0/ 100 = 0% 0/ 100 = 0% localhost [10.8.224.21] 0/ 100 = 0% | 3 --- 100/ 100 =100% 100/ 100 =100% localhost [10.8.224.106] 0/ 100 = 0% | 4 12ms 0/ 100 = 0% 0/ 100 = 0% sg-fw-extlan.sgremote.stg [192.168.210.253] 0/ 100 = 0% | 5 13ms 0/ 100 = 0% 0/ 100 = 0% sg-dc-01.sgremote.stg [192.168.10.217] Ablaufverfolgung beendet.
  25. Hi Sunny61, ist ein Relikt aus "alten Zeiten", haben wir aber im Endeffekt so gelöst wie du schreibst. An jedem Standort steht ein Wsus-Server. Nun wollten wir nicht 80 GPOs bauen und haben mit Variablen herumgespielt, u. a. solchen Dingen wie %susserver% usw. Hat aber alles nicht funktioniert... ;) Der Dienst ist von unserer Softwareverteilung, und liest DHCP-Werte aus, und schreibt sie in eine BetriebssystemVariable, mehr macht der an dieser Stelle nicht.
×
×
  • Neu erstellen...