himbidas

lies mal devicewatch (mit Demodownload) oder die Herstellerseite himbidas

Radius, Enterprice & Co. sind doch ziemlich "aufwendig" / "teuer". Wenn es darum geht, "nur" das Arbeitsnetz zu schützen, muss man da mit Kanonen auf Spatzen schießen? Wieviel Clients hat denn das Arbeitsnetz? Wenn die Anzahl nicht allzu groß ist, oder man den Aufwand nicht scheut, könnte man doch jedem Client im Arbeitsnetz eine DHCP-Reservierung per MAC verpassen. Weiterhin wird kein DHCP-Adressbereich zum Leasen definiert. Dann dürfte doch ein "fremder" Client vom DHCP keine IP zugewiesen bekommen, oder? (Macht die DHCP-Verwendung zwar ziemlich sinnlos, außer dass man die IP's von zentraler Stelle aus administriert, ohne jeden Client vor Ort oder Remote anfassen zu müssen.) Weiterhin habe ich in der Hilfe zum DHCP-Server mal ein bissel gelesen (ähnliches Problem bei mir) und etwas vom definieren eigener Geräteklassen per netsh gelesen. Wenn sich die Arbeitsclients irgendwie hardwaremäßig gegen die Kunden-Test-Clients abheben würden, könnte man da nicht irgendsoeine Klasse definieren und der per DHCP die notwendigen Parameter verpassen? Habe das mit der netsh-Klassendefinition aber noch nicht so richtig durchgearbeitet und begriffen. Nur mal so als Denkanstoß ;) himbidas

sorry sorry, ich bin doch die absolute Pappnase. Na klar, so wie IThome das darstellt, klappt es auch. Das Problem der Erstellung/Änderung von Daten im Baseordner hab ich mal schlicht übersehen. Ich mappe die HOME's mit subst über die versteckte Freigabe. Natürlich könnte ein findiger User trotzdem die Freigabe "erraten". Und dann würde ich ziemlich dumm dastehen. Okay, er könnte neue Daten im BASE erstellen. Durch das ABE würde er sie aber danach nicht mehr sehen (hab's getestet). Ich würde mich nur wundern, wo die herkommen, tzz tzz #2 - jetzt stehen in der Freigabeberechtigung nur noch die Auth.User mit Vollzugriff. Reicht ja völlig aus. Der Admin ist ja auch authentifizierter User :rolleyes: Jeder als Konto zu benutzen, erzeugt immer schweres Bauchgrummeln bei mir. Jeder ist eben jeder, auch Unbekannt, Anonym, nicht gewollt, Geräte/Computer usw. Ist mir schon sicherer, wenn in meiner Domäne auch nur authentifizierte User etwas dürfen (oder nicht). Das mit dem "Nicht-funktionierenden" Quota hat sich auch erledigt. Habe das Problem hausgemacht. Zu Testzwecken habe ich dem User als Admin einfach einen Schwung Daten in sein HOME kopiert und mich gewundert, dass das Kontingent für den User nicht berechnet wurde. Irgendwie war mir doch entfallen, dass der Admin weiterhin Besitzer der kopierten Daten ist. Hatte irrtümlich angenommen, dass der User automatisch Besitzer davon wird. Die Ausführungen von IThome haben mich aber wenigstens darauf gebracht, dieses Verhalten beim Reinkopieren zukünftig zu beachten. also, mein Problem soweit gelöst. Manchmal wird man doch total betriebsblind und sieht den Wald vor lauter Bäumen nicht. cu himbidas

Hi, Stop F4-geplagte bei mir war eine defekte, sprich weder lösch- noch umbenennbare Datei die Ursache. Handelte sich um btwusb.inf im INF-Verzeichnis (oder system32?). Kam nach langem googeln und probieren mit Lüfter säubern, RAM checken und tauschen, Graka tauschen, Rep-Installation usw. darauf. Irgendwann stellte ich fest, dass einige Dateien bei der Rep-Inst nicht "überkopiert" werden konnten. Viele besaßen einen Schreibschutz. also ab nach DOS -> attrib -r * /s /d. Dabei wurde die besagte Datei angemoosert. Nach mehrmaligem chkdsk /f <lw:> bzw. chkdsk /f btwusb.inf hat XP das Teil gekillt. Ist eine INF des WIDDCOMM-Bluetooth-Treibers. Wahrscheinlich wollte der Kunde den vorhandenen Treiber des Herstellers austauschen und irgendwas ging da schief. Tlw. findet man unter Google Hinweise darauf, dass Avira-Antivir beim Upgrade auf die Rootkit-Erkennung Treiber abschiesst. Ziel sollte es also sein, die benötigten Systemtreiber (Stop 0x000000f4 (0x00000003,... 3=Prozeß), auf welche XP nicht zugreifen kann zu finden und zu reparieren. Da in diesem Fall die Datei zwar da war, aber "defekt" im Dateisystem hing, brachte Deinstall/Install des Treibers nix. Ich musste die echt physisch killen und danach von einem anderen System raufkopieren. Auch BIOS-Deaktivierung des Bluetooth-Gerätes brachte nix. XP wollte die INF-Datei beim Start immer wieder "anfassen", konnte aber nicht und schmierte ab. Unter Umständen könnte es auch eine andere Gerätedatei sein. XP prüft z.B. die Dateien im dllcache gegen die im INF- bzw. System32-Verzeichnis vorhandenen ab (um Manipulationen o.ä. zu verhindern). Ist da eine defekt, knallt 0xF4 rein. Mal ab %systemroot% (i.d.R. WINDOWS) in der DOS-Box mit attrib +a * /s /d und danach das ganze mit -a probieren, ob man allen Objekten unterhalb von Windows das Archiv-Attribut verpassen und wieder entziehen kann. Sollte das nicht gehen, liegt u.U. ein Dateifehler vor, welcher bereinigt werden muss. RAM-, Graka-Tausch, Lüfter reinigen, Reparatur-Inst usw. hat nix gebracht. Nachdem ich die INF-Datei sauber gekillt und ersetzt hatte, blieb der Stop-Fehler jedenfalls aus und das System läuft wieder stabil. vielleicht hilft's himbidas

...oder such mal hier im Board nach "poweroff.exe" . Geniales Tool, mit dem man viel, auch zeitgesteuert, anstellen kann. Müsste hier zu finden sein. Mal ziemlich weit runter auf der Seite. himbidas

Hallo Forum nach langer Abstinenz wieder mal was von mir. (Was soll ich machen? Mein System läuft und läuft und läuft...) Da ich aber jetzt vor dem selben bzw. ähnlichen Problem stehe, hänge ich mich mal mit in den Thread. Der erste Linke bringt ja nicht wirklich viel, sorry... Der Microsoft-Link ist da schon aufschlussreicher. Wenn bzgl. Kontingentierung im R2 jetzt auch Ordner behandelt werden können, ist da zwar chic, macht die Sache aber nicht unbedingt einfacher.:suspect: Bevor ich mich wieder verquatsche, kurz mein System W2k3-SP2 Domäne über mehrere WAN-Subnetze. Als Clients (noch) NT4SP6a, XP-SP1, XP-SP2. In jedem Subnetz steht mind. ein Server (server1 bis -9). Einige als DC (mit ADS-Funktion), andere "bloß" Memberserver. Die Subnetzserver sollen für die jeweiligen Bereiche gleichfalls als Dateiserver für die HOME-Laufwerke, sprich Basisordner, der User genutzt werden. Da noch nicht R2, wurde jeweils eine Partition für die HOME's abgezwackt. Diese Laufwerke, nennen wir sie mal H: (lokal auf den Servern), wurden per Kontingentverwaltung mit Quota belegt. Auf H: wurde der (lokale) Order HOME angelegt. Lokale Sicherheit: Administratoren - Vollzugriff - volle Vererbung authentifizierte Benutzer - Vollzugriff - nur dieser Ordner SYSTEM - Vollzugriff - volle Vererbung Der (lokale) Ordner wurde freigegeben als home$. Freigaberechte: Administratoren - Vollzugriff authentifizierte Benutzer - Vollzugriff. Zusätzlich wurde auf den Servern ABEUI im "Individualmodus" installiert. (Access Based Enumeration). Die freigegebenen Ordner home$ wurde mit ABE belegt. Im ADS (Benutzer- und Computer-MMC) wurde für die User die Basisordner angegeben. --> \\server[1-9]\home$\%username% Nach Übernehmen der Angaben erzeugt das System sofort im o.g. lokalen Ordner HOME die jeweiligens User-Basisordner. (Im Gegensatz dazu werden ja die definierten Profilordner erst mit ErstLogin des Users generiert.) Das klappt soweit auch alles prima. Administratoren und Userxyz - Vollzugriff Nur die Kontingentberechnung haut nicht hin. Ursache: Die angelegten Basisordner bekommen als Besitzer immer den User verpasst, der das ADS-MMC benutzt (i.d.R. Administrator). Der eingerichtete User wird nicht, wie im o.g. Link beschrieben, automatisch Besitzer seines Basisordners. Dadurch knallt Quota weg, da das nur über den Besitzer geregelt werden kann. Auch das nachträgliche setzen des Besitzers im Anmeldescript mit xcacls \\server[1-9]\home$\%username% /T /E /G %username%:O funktioniert nicht. Nach einigen Versuchen brachte xcacls zwar keine Fehler mehr (Rechteprobleme, deswegen auch die o.g. Rechte). Aber der jeweilige User wird nicht Besitzer seines Basisordners. Ein bissel ausführlich, aber vielleicht kann ja Inino noch was daraus "lernen". :confused: Nur, wo steckt jetzt mein Fehler?? Wie bekomme ich den Besitz der Basisordner auf die User gebogen? Stimmt was an den lokalen und Freigaberechten nicht? Habe da mehreres ausprobiert und am Ende so belassen wie oben beschrieben. thx, himbidas

@thorgood yepp, das ist genau das, was ich gesucht habe, klein und fein und kann vom Normal-User ausgeführt werden. thx @blub Das mit dem WMIC-Befehl scheint in meiner Umgebung nicht für Normal-User zu funzen. Es kommt immer beschriebene Fehlermeldung. Wobei ich sagen muss, dass ich das nur mit der Befehlszeilenversion WMIC probiert habe. Als admin wird da bei Erstaufruf von WMIC auch irgendwas "installiert". Jedenfalls lassen die Ausgaben darauf schliessen. WMI, geschweige denn eine Reiterkarte "Sicherheit" habe ich dazu nicht gesehen. Letztendlich habe ich das Problem bereits versucht über einen anderen Weg zu klären. @all Damit ihr nicht im Trüben stochert, will ich wenigstens erzählen, wozu dieser Aufwand eigentlich nützlich sein soll. Also, wir haben in unserer lokalen Damäne sowohl NT- als auch XP-Clients mit unterschiedlichen Desktopauflösungen am laufen. Während der Anmeldung laufen mehrere Scripte ab (Umgebung setzen, Laufwerke verbinden, bestimmte Anwendungen einbinden, Startmenü aufbereiten usw.). Für den User sieht das immer alles ein bissel trist aus, so in der DOS-Box. Ich wollte also ein bisschen was "grafischen" einbringen. Vielleicht so in der der Art wie Linux/KDE (nicht schimpfen, dass ich mir an einem Nicht-Windows-OS ein Beispiel nehme ;) ). Also sollte zu Beginn jedes Scriptes der Bildschirm mit einer Vollbildgrafik überlagert werden, der das ggw. Vorgehen grafisch darstellt. Auf Grund der verschiedenen Auflösung brauche ich da auch verschiedene Grafiken. Soll ja professionell aussehen (nix Zoom und pixelig). Dazu muss ich natürlich immer die aktuelle Auflösung auslesen. Hatte schon an HTA gedacht. Das scheint aber nicht zu gehen. Läuft bereits eine aus einem Script gestartete HTA, lässt sich aus dem nächsten Scripts keine zweite HTA starten und dabei die erste beenden. Jedenfalls bin ich bei meinen weiteren Recherchen über ein feines kleines Bildanzeigeprogramm aus der DOS-Box, namens LxPic gestoßen. (auf der Website nach LxPic suchen). Dem scheint es egal zu sein, wie die Auflösung ist. Nimmt default immer die beste Auflösung. Hab's aber noch nicht abschliessend getestet. Finde das Programm aber sehr interessant. Besonders unter dem Aspekt, dass man wohl in der Lage ist, aus der DOS-Box eine Grafik auf dem Screen darzustellen. Dazu findet man recht wenig im Netz. Falls also jemand ein ähnliches Problem hat, mal mit LxPic experimentieren. Auch die Tools, auf die thorgood verweist, sehen sehr nützlich aus. also, nochmal vielen Dank. ich denke, jetzt komme ich schon einen grossen Schritt weiter Himbidas

hhmm, wäre eine Möglichkeit... ...wenn wmic nicht nur für Administratoren wäre ;). Normale Benutzer haben darauf keinen Zugriff. MOF-Datei(en) konnte(n) nicht registriert werden. Nur Mitglieder der Administratorgruppe können WMIC.EXE verwenden. Ursache:Win32-Fehler: Zugriff verweigert Und selbst als Admin liefert mir das auch nicht die notwendigen Werte. Weder die beiden ...Resolution-Werte, noch VideoModeDescription sind mit Werten hinterlegt. ...tja, so also nicht, danke :(

Hallo Gemeinde, seit langem wieder mal eine Frage von mir. Umgebung: W2k3-Domäne -> ADS- & Memberserver Clients -> XP-Prof & NT 4.0 (jaaa, die werden noch benötigt ;) ) Anmeldung per cmd-Scripts aus dem NETLOGON. Während der ablaufenden Anmeldung muss ich ermitteln, mit welcher Desktopauflösung der Benutzer arbeitet. Habe unzählige Versuche per Google, Forumssuche & Co. hinter mir. Nix, nada, njente. Ich finde nix, wie man das bewerkstelligen kann. Tools wie bginfo usw. können ja viel auslesen, aber eben nicht die Auflösung. In der Registry (weder XP noch NT) finde ich auch keinen verläßlichen Wert (z.B. xRes, Resolution, Widht, Height usw.). Unter HKCU\Control Panel\Desktop\ ff. finde ich alle möglichen Werte, nur eben nicht die Auflösung. #1. Kennt jemand ein Tool, dass das in der DOS-Box, also eigentlich während der Anmeldung im Batch kann? Am besten mit Übernahme in eine Variable (bekomme ich schon hin, wenn das Teil nur was ausspuckt) #2. Gibt es in der Registry einen Key, der mich bzgl. Auflösung schlauer macht? (Adobe scheint bisher das einzige Programm zu sein, dass einen xRes- und yRes-Key setzt. Setzt aber Adobe vorraus, was nicht immer gegeben ist.) Hoffe, es kann jemand helfen mfg himbidas

du musst, wenn mehrere Domänen verfügbar, die richtige Domäne auswählen. Dann rubelt das Teil ein wenig und schreibt dann in der Menüzeile "Tell Me Where -- PDC Is \\<dc deine domäne>". Ich weiss aber jetzt nicht, ob dazu vielleicht Adminrechte notwendig sind Thomas

yo, genau das ist das Teil. Fixe Leutz hier :) Thomas

hi, ich tipper in meinem Outlook2000 immer den Anfang einer Adresse in das An-feld und drücke dann STRG+K. Danach wird die Adresse entweder vollständig aufgelöst, wenn sie unikat ist oder ich erhalte eine Vorschlagsliste mit Adressen, die der bisherigen Eingabe entsprechen. Die Liste scheint alles was stimmig wäre aus dem globalen Adressbuch, als auch aus privaten Kontakten aufzulisten. Thomas

halloooo es ist ein NT-Domäne, da isse nix Computerverwaltung... im Ernst, da gibt's ein kleines Tool von http://www.securewave.com namens tmw.exe (tell me where). Leider scheint das auf dieser Seite nicht mehr zu existieren. Auch die im Google aufgefundenen Links zu Downloadseiten dieser Firma gehen ins Fehler-404-Nirwana. Das Tool ist nur 228 kB groß, braucht auch keine Installation. Nur leider ist das Ding nirgends zu finden. Da es für einen Upload leider zu groß ist, müsstest du mich mal anmailen. Dann könnte ich es dir schicken. Thomas

Lösungsweg: 1.) die betreffende setup.exe, die die nicht will, mit rechts anklicken → Eigenschaften → Reiterkarte Version → Versionsnummer merken (z.B. Dateiversion: 6,31,100,1190) 2.) nach http://www.installshield.com gehen, und dort das ikernelupdate für die entsprechende Version laden 3.) InstallShield (V 6.x) liegt i.d.R. unter c:\programme\gemeinsame dateien\installshield\engine\6\intel 32 Die absolut notwendigen Dateien sind: corecomp.ini ctor.dll iKernel.exe iuser.dll objectps.dll Kontrollieren und merken → Verzeichnis ab engine löschen. engine/6/intel 32 verschwindet also jetzt. 4.) Das heruntergeladene ikernelupdate installieren. I.d.R. kommt auch hier wieder die Meldung "Klasse nicht registriert". Keine Panik, Kontrolle unter (s.o.) ....\installshield sollte zeigen, dass die Ordner engine\6\intel 32 wieder angelegt wurden. In ihm sollten sich die Dateien von 3.) befinden → kontrollieren und merken. 5.) U.U. könnte jetzt das Installieren der betreffenden Anwendung funktionieren. Um allen Fehlern aus dem Weg zu gehen, noch folgendes ausführen... 6.) Nach c:\programme\gemeinsame dateien\installshield wechseln. Hier existiert u.U. ein Ordner iscript. Reinwechseln, darin sollte sich die Datei iscript.dll befinden. Wie 1.) Rechtsklick → Eigenschaften → Version. Die Versionsnummer sollte die selbe, wie das installierte InstallShield (V 6.x) sein. Meine hatte z.B. die 9.01.429, ist also zu hoch. Hier am besten von der funktionierenden Maschine die DLL-Datei drüberkopieren (nach Versionskontrolle natürlich). 7.) Jetzt kommt der wahrscheinlich nervigste Teil. In der Registry muss überprüft werden, ob die installierten InstallShield-Dateien gültig und vorhanden sind. 8.) Mit Adminrechten die Registry mit regedit.exe oder regedt32.exe (je nach verwendeten OS) öffnen. Wir brauchen auf jeden Fall einen Registry-Editor, der suchen kann! 9.) An den Anfang der Registry stellen (Arbeitsplatz) → STRG + F drücken -> Suchen nach: engine\6 → Suchoptionen: Schlüssel, Werte, Daten → ganze Zeichenfolge vergleichen nicht aktivieren → und los geht's mit suchen. (Weitersuchen, nach 10., mit F3 ) 10.) Unter HKEY_CLASSES_ROOT\CLSID sollte es jetzt einige Treffer geben, die als Wert den Pfad von 3.) mit einer Datei aus 3.) bzw. 4.) besitzt. Jeder gefundene Wert sollte auf eine Datei zeigen, die es effektiv im Verzeichnis gibt. Wird hier eine Datei angezeigt, die es im o.g. Verzeichnis nicht gibt, kann der komplette Schlüssel (linke Seite mit {} ) gelöscht werden. Wer ganz sicher gehen will, kann den Cursor auf den betreffenden Schlüssel stellen und diesen zur Sicherheit exportieren. Dann kann man ihn bei Bedarf wieder laden. 11.) Das ganze Prozedere mit F3 so oft wiederholen, bis alle engine\6-Pfade kontrolliert und korrigiert sind und am Ende eine "Registrierung durchsucht" kommt. 12.) Nach HKEY_LOKAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls wechseln. Dieser Schlüsselbereich sollte bei 9.)-11.) bereits schonmal besucht worden sein. Hier wurden bei mir z.B. zwei Werte gefunden, die auf die Dateien ilog.dll und knlwrap.exe im InstallShield-Verzeichnis verwiesen, welche nicht vorhanden waren! Diese Schlüssel sollten bereits bei 10.) gefunden und gelöscht worden sein. 13.) In diesem Registryzweig (12.) die Werte für die Dateien aus 3.)/4.) kontrollieren. Bei mir waren hier HEX 0x00000008 eingetragen. Auf der funktionierenden Maschine hatten diese aber den HEX-Wert 0x00000003 ! Jeden Eintrag also doppelklicken und als Wert 3 eingeben. 14.) registry verlassen, Kiste neu starten, Installation versuchen. Hat bei mir funktioniert. Ist zwar etwas länger geworden, aber es ging nicht kürzer. Große Fehler bedürfen langwieriger Lösungen ;) Wenn's geholfen hat, mal posten. Thomas

Hi Forum mich hat diese Meldung auch desöfteren heimgesucht. Nach vielem googeln und Foren-lesen bin ich auf einen möglichen Lösungsweg gestossen. Da dieses Problem weit verbreitet zu sein scheint, hier mal meine Tipps. System: NT4 Sp6a, InstallShield V 6.31. Das OS scheint nicht primär interessant zu sein, da der Fehler unter ME, NT, W2K oder XP auftritt. (Hilfreich wäre eine 2. Maschine gleichen OS, auf der der Fehler nicht auftritt.) a) als erstes muss hier klar gesagt werden, dass der Fehler nix mit dem MSI-Installer zu tun hat! Dieser bearbeitet msi-Pakete. Der Fehler, der hier auftritt, bezieht sich auf die Verwendung von z.B. setup.exe, install.exe o.ä. Dabei jeweils bei Installation und/oder Deinstallation des betreffenden Produktes. b) Viele schreiben in Foren, dass sich Anwendung XY nicht de-/installieren läßt. Es liegt definitiv nicht an der Anwendung, bzw. dem Setup der Anwendung. Die fehlerhafte Komponente ist der InstallShield. c) InstallShield gibt es in mehreren Versionsständen. Die gängigste scheint die 6.31 zu sein. Es muss also sichergestellt werden, dass alle benötigten DLL's die selbe Version besitzen. Ende Teil 1