wean

vielen dank doc :-)

sorry - habs jetzt erst 290835089235 mal im forum gefunden :-)

hi, es ist ja möglich sich mit einer windows xp pro lizenz windows 2000 pro aufzuspielen. gilt das auch, wenn ich einen rechner mit einer windows-xp-pro OEM version erwerbe? kann ich dann auch einfach windows 2000 pro installieren? danke wean

Allerdings werden auch einige Richtlinien erfolgreich angewandt, wie optimierung am DNS-Cache, XP-Firewall.... Bei den Software-Ínstallationen gibt gpresult folgendes zurück:

oh mein gott, habe nach einer Testzeit bei uns SP2 installiert. Nun verhält es sich so, dass trotz gleicher OU, wie die Testrechner bei einigen sich MicrosoftOffice deinstalliert und Startscripts nicht mehr ausgeführt werden... Office wird über ein GPO verteilt und deinstalliert, "wenn ausserhalb des Verwaltungsbereichs". Die Startscripts funzen nicht, da hiervon Admin-Rights notwendig sind, welche wiederrum über ein GPO zugewiesen werden. Was kann denn das sein? Das kuriose allerdings ist, dass es bei einigen XP-Maschinen funktioniert, trotz gleicher OU (?) Fällt jemand was ein?

Bei dem Import der Richtlinien (nach dem Umbenennen) auf dem 2000erDC erhalte ich: ??? Warum klappts bei euch und die Beschreibung passt bei euch rein?

Ein schönes Eck, in das wir uns hier geredet haben :-)

D.h ich brauch mich gar nicht erst damit zufrieden geben die angezeigten verwendeten CAL's im Lizenzmanager lizenziert zu haben.....? Auwei.....ich denke, ich bin jetzt besser still

Stimmt, Du müsstest ohnehin die 1100 Clients zur Verwendung des SUS-Servers konfigurieren.....Nach Abschluss der Lan-Party wieder auf default zurückstellen. Sonst geht nach dem ersten Tag einer Heim und sein PC versucht dann zu Hause weiterhin auf den Lan-Party-SUS zuzugreifen um Updates zu beziehen.... Oder Du erwähnst explizit dass vor Antritt der LAN alle Rechner den neuesten Patchlevel aufweisen müssten, da für evtl Schäden...bla bla....kann aus..... Gründen....keine Haftung übernommen werden Das rechtliche gehört aber hier nicht hin, darüberhinaus kenn ich mich da auch nicht aus :-) Gruss Andy

Und wo im DNS, DHCP, NAT, IGMP, Protokoll liegt dann der Unterschied, ob die Anfrage von einem Windows-Host oder durch ein anderes Netzwerk-Peripherie Gerät kommt? Doc, das ist so - wirklich :-) Es können sich sogar Netzwerkkomponenten im DNS registrieren ohne eine CAL zu benötigen. Wo aber evtl der Haken liegt: Dass er den Zugriff dem Admin-Konto etc. dazuzählt........... Muss ich mal ausprobieren @Doc, nix gegen Polo ;)

.......von wegen ganz banal..... echt heftig blub.....*boar* Danke!!

wenn Du dann den Button "Durchsuchen" klickst - Welchen Pfad öffnet er denn standardmässig?

In der Praxis habe ich aber auch die Erfahrung gemacht, dass die CAL's nur von authentifizierten Sitzungen gezählt werden. Wenn beispielsweise alle unsere IP-Phones eine CAL benötigen würden, weil sie vom DHCP oder RRAS nagten, dann kämen wir ja mächtig ins schleudern. Auch setzen wir beim Kunden Produkte ein, die auf dem IIS basieren (WebFrontends für CallCenter-Statistiken). Auch hier werden keine CAL's abgezogen.......gaaaaaaaaaanz ehrlich Doc btw: SUS habe ich für "anonymen" Clients noch nicht zu Laufen bekommen.......... (SUS ist auf 2kDomain MemberServer installiert)

Doc, steinige mich jetzt bitte nicht, aber ist es nicht so, dass diese TS-CAL nur von "Windows < 5.0" und alles "Nicht Windows" aus benötigt wird? @andpfl nein :-) TS-CAL's kommen nur dann ins Gerede, wenn Du einen TerminalServer besitzt. Das ist eine ähnliche Art wie z.B pcAnywhere - mit dem Unterschied, dass mehrere Benutzer gleichzeitig auf dem Server arbeiten können, ohne sich gegenseitig zu stören ;)

Das Problem existiert noch bis heute. wir haben unsere User angewiesen auf die direkten Freigaben zuzugreifen, wie sie eben im dfs eingetragen sind: \\server\freigabe$ Damit kommen sie eigentlich gut zurecht. Für DAU's hab ich nen Terminal-Server aufgesetzt. Das hat wirklich eine Menge Vorteile.... hat sich bei uns am meisten bewährt Andy

Diese Unix-Tools gibbed auch unter ****** :) LINK Die Ausgabe sieht dann so aus: Demnach ist folgendes Script zu verwenden ohne Zeilenumbrüche

Mit Linux lässt sich die dns.log entsprechend auswerten: Inhalt von dnsgrep: ....wäre der Inhalt von 192.168.10.x ....wäre der Inhalt von 192.168.10.10 Die Auswertung sieht dann folgendermaßen aus:

huhu, kennt jemand von euch ein tool um die dns.log unter w2k auszuwerten? ich muss statistiken erstellen, was für anfragen die clients an den dns-server schicken - vorallem wie oft. nun enthält das logfile z.B hier stehen zwar die anfragen schon relativ nett drin, aber nicht so wie ich sie eben gebrauchen könnte. ich bräuchte: 100x google.de 21x microsoft.de ......usw hat jemand zufällig einen tip?

a)

ich bekomm's einfach nicht hin ------------------------------------------------------------------ Kurzform: ------------------------------------------------------------------ 1. Windows 2000 RRAS Server SP4 mit 2. Netzwerkkarten und 2 Subnetzen (Intern und Extern) Wählt man sich per Modem ein erhält man eine IP-Adresse aus dem Subnetz Intern. Gelangt in das vollständige Subnetz von "Intern", aber nicht auf das Subnetz "Extern" ------------------------------------------------------------------ Detaillierte Version: ------------------------------------------------------------------ Unser RRAS-Server hat zwei Netzwerkkarten. Eine externe und eine interne. Über die Externe Netzwerkkarte sind entfernte Standorte und einige einzelne Benutzer über VPN mit der Firma verbunden (rot). Die über VPN verbunden Benutzer und Router erhalten ganz normal eine IP-Adresse aus dem Bereich "intern". Mit diesen IP-Adressen werden Routen zu den jeweiligen Subnetzen generiert. Somit ist es möglich, dass auch die entfernten Standorte sich auch untereinander verständigen können. (die roten untereinander..... ;) ) Wählt sich aber ein Benutzer über Modem ein, erhält dieser auch eine IP aus dem Bereich "intern". Kann auch die entfernten Standorte pingen. ABER ER KANN NICHT AUF DAS SUBNETZ "EXTERN" ZUGREIFEN ??! ?!?=)!?= )!? Ausserdem verfügt unser RRAS Server über Schnittstellen für "Wählen bei Bedarf" zu Kunden. Diese Schnittstellen werden "genatted" und nicht "geroutet". "Wählt" man sich über VPN ein, gelangt man zwar zu den Remote-Standorten und in das Subnetz "Intern", jedoch nicht auf die vorgesehenen Routen über "Wählen bei Bedarf" über NAT. Hockt man in der Firma rum, geht alles einwandfrei - mhmmm, warum nur??? Ich glaube ja langsam dass M$ hier ein Problem hat. merci :p

mit dem tool gpresult lässt sich sehr schnell ermitteln, ob und welche gruppenrichtlinien konfiguriert sind. wegen der einheitlichen darstellung..... gibt es innerhalb des benutzerprofiles der betroffenen benutzers zufällig eine ntuser.man? Wenn ja, dann bennen die 'mal kurzer hand um in ntuser.dat Wenn nein - bleiben andere Einstellungen denn erhalten? Hintergrundbild....Desktopfarben etc? Ich würde diese Detail-Ansicht Geschichte über einen Registry-Schlüssel lösen, den ich über ein vb-script verteilen würde. allerdings konnte ich nicht genau ausfindig machen, welcher key dafür verantwortlich ist. mittels eines registry monitors habe ich folgende "bereiche" gefunden (zugegeben etwas unwage, aber bestimmt die richtige richtung) HKLM\Software\Microsoft\Windows\CurrentVersion\ExtShellViews

Ich bügel morgen Sp3 drauf und berichte dann, ob es was gebracht hat :)

huhu, irgendwie hat es der kunde geschafft über den Administrator-Account des Exchange-Servers, seinem Benutzeraccount als einzigsten Berechtigungseintrag "lesen" in einen öffentlichen Ordner zu schreiben. Somit hat niemand mehr das Recht "schreiben" auf das Ding. Gelöscht werden kann er auch nicht und die Besitzübernahme bleibt für jeden grau hinterlegt :( So etwas schon mal gehabt? :-) Über den Systemmanager komm ich leider nicht dran, lediglich über IFS (M:\) Beim Systemmanager erhalte ich immer die berühmt/berüchtigte Meldung 80004005 :( Bin für jeden Tip dankbar