Jump to content

Gulp

Expert Member
  • Gesamte Inhalte

    4.465
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von Gulp

  1. Da gibts nen einfachen Trick: Druckwarteschlange in den Diensten beenden und anschliessend Treiber deinstallieren, Druckwarteschlange neu starten, fertig. Grüsse Gulp
  2. Stimmt die Rechner SID bleibt gleich, ist ja auch eine lokale SID, die im ADS keine Rolle spielt. Wohl aber in der Kommunikation von Client zu Client (auch das solls in Domänen ja geben) ... Hier ein Auszug aus http://www.sysinternals.com/Utilities/NewSid.html (den Edgar abe sicher schon kennt ;) ): The SID Duplication Problem The problem with cloning is that it is only supported by Microsoft in a very limited sense. Microsoft has stated that cloning systems is only supported if it is done before the GUI portion of Windows Setup has been reached. When the install reaches this point the computer is assigned a name and a unique computer SID. If a system is cloned after this step the cloned machines will all have identical computer SIDs. Note that just changing the computer name or adding the computer to a different domain does not change the computer SID. Changing the name or domain only changes the domain SID if the computer was previously associated with a domain. To understand the problem that cloning can cause, it is first necessary to understand how individual local accounts on a computer are assigned SIDs. The SIDs of local accounts consist of the computer's SID and an appended RID (Relative Identifier). The RID starts at a fixed value, and is increased by one for each account created. This means that the second account on one computer, for example, will be given the same RID as the second account on a clone. The result is that both accounts have the same SID. Duplicate SIDs aren't an issue in a Domain-based environment since domain accounts have SID's based on the Domain SID. But, according to Microsoft Knowledge Base article Q162001, "Do Not Disk Duplicate Installed Versions of Windows NT", in a Workgroup environment security is based on local account SIDs. Thus, if two computers have users with the same SID, the Workgroup will not be able to distinguish between the users. All resources, including files and Registry keys, that one user has access to, the other will as well. Another instance where duplicate SIDs can cause problems is where there is removable media formated with NTFS, and local account security attributes are applied to files and directories. If such a media is moved to a different computer that has the same SID, then local accounts that otherwise would not be able to access the files might be able to if their account IDs happened to match those in the security attributes. This is not be possible if computers have different SIDs. Wenn ich mich recht entsinne wird die SID des Computerkontos in einer Domäne aber mit Hilfe der lokalen Computer SID generiert, wobei zwar nicht die komplette lokale SID herhalten muss, schliesslich muss ja auch zumindest ein Teil der Domänen-SID im Computerkonto hinterlegt sein, damit man den Rechner als Teil der Domäne identifizieren kann. Ich muss gleich mal gucken ob es zwischen der SID eines Computerkontos in einer Domäne und der lokalen Computer-SID Gemeinsamkeiten gibt. Grüsse Gulp
  3. Hmm... sowas hab ich auch schon mal probiert und dann ne dicke Fehlermeldung bekommen. Ausserdem wage ich zu bezweifeln, dass dies in einer Produktiv-Umgebung zB mit GPO's, differenzierter File-Security und Netz-Security, Datenbanken und Drittanbietersoftware wirklich reibungslos funzt. Naja, ich lass mir gerne auch das Gegenteil beweisen. Grüsse Gulp
  4. Gulp

    Letzter macht das Licht aus

    Moin, moin ... ... ein neuer Tag beginnt. Kaffee ist schon mal anwesend, so wie ich. Heiss is der Kaffee auch. Schmecken tut er nicht wirklich, wer hat das gebraut, der Azubi oder was? Hier liegen noch ein paar Kitkat Riegel neben dem Linux Server *indieRundewerf* .... Am Dienstag wird ein ein Server zum neuen DC hochgestuft *freu* und dann kann ich endlich die alte Samba Domäne wegwerfen. Wird zwar noch einen Rattenschwanz an Clientanpassungen nach sich ziehen, aber da kann ich wieder ein paar User gängeln *diabolischgrins*. Möge es noch viele Dienstage wie diesen geben! :D Grüsse Gulp
  5. Ging mir auch schon so und das lief auch so cirka 1 Jahr problemlos. Dann gings aber los mit Problemen, Rechner konnten nicht mehr in die Domäne, Anmeldeprobleme, Synchronisationsprobleme mit Profilen, Zugriffsprobleme auf Freigaben und und und ... Das Ganze war eine NT 4 Domäne mit NT 4 Clients und wurde ständig mit Rechnern erweitert. Komischerweise waren diese Phänomene weg, als ich dann mit NewSID alle Kisten mit neuen SID's versorgt hatte. Bei W2K/W2K3 kriegen durch die Verwendung des ADS aber auch mehr Objekte SID's, als bei NT (weils auch mehr Objekte gibt), daher spielt die SID auch eine wichtigere Rolle. Trotzdem fallen die Probleme oft 'nur' in speziellen Fällen und Konstellationen auf. Grüsse Gulp
  6. Das bekommt man doch ganz einfach mit dem Process Explorer von sysinternals raus. Ausserdem lässt sich damit gezielt nach dem geöffneten Handle suchen und dieses Handle kann auch damit geschlossen werden. Danach ist ein löschen der Datei problemlos möglich. Und das in der Regel ohne Neustart ..... Grüsse Gulp
  7. Der Rechnername spielt da eine eher untergeordnete Rolle. Jedes Objekt im ADS (so auch Computerkonten) hat eine eindeutige SID (Security Identifier), die sich auch zwischen Domänen unterscheidet. Da sich die Kombination von Computer SID und Domänen SID von Client A und Client B unterscheiden wird schon beim lokalen Authentifizierungsversuch gemerkt, dass hier was nicht stimmt und da ruft der Client den DC zur Hilfe, vereinfacht ausgedrückt. Grüsse Gulp
  8. Is ganz einfach .... (jedenfalls eigentlich) Das ist der Ausgangspunkt: Du hast eine Domäne A mit DC und mehreren Clients. Genauso eine Konstellation B. Client aus Domäne A soll auf Client aus Domäne B zugreifen. Ganz vereinfacht gesagt: Der Client aus Domäne A versucht mit seinem Computerkonto (in Domäne A ja vorhanden) auf Client aus Domäne B zuzugreifen. Da der Client keine Computerkonten verwaltet, fragt der seinen DC B, der guckt nach, ob er Domäne A kennt bzw ob er Domäne A vertraut. Kennt/vertraut der DC B der Domäne A nicht lehnt er den Zugriff ab. Sonst könnte ja jeder auf beliebige Clients zugreifen. Alternativ ist eine Verbindung auf lokaler Basis der Clients nicht ganz unmöglich, dazu muss man nur einen entsprechenden lokalen User des Clients verwenden. Leider muss man nach jedem Neustart die Session erneuern, also entweder neu verbinden oder das entsprechende Passwort eintippeln. Eine Vertrauensstellung hast Du ja jetzt, die erübrigt das oben genannte. Gruss Gulp
  9. Ich weiss zwar nicht was Du bei Windows 98 mit 'ipconfig /all' erreichen willst, ich kann Dir aber sagen, was Du erreichen wirst. Eine Fehlermeldung .... Bei Windows 98 geht wohl nur 'winipcfg' .... (liefert aber auch die gewünschte Info). Grüsse Gulp
  10. Sicher funkt der DC dazwischen, ist ja auch logisch, denn die Clients sind Teil der Domäne. Egal, ob Du per Name oder IP des Clients auf Ressourcen (in Deinem Fall die DB) zugreifen möchtest. Zunächst wird der Client versuchen den Zugriff zu authentisieren und genau da kommt der DC ins Spiel, da der Client Mitglied in der Domäne ist. Du solltest die Vertrauensstellung der beiden DC's mal prüfen und gegebenfalls erneuern, dann dürfte das wieder funktionieren. Grüsse Gulp
  11. Gulp

    Letzter macht das Licht aus

    Mahlzeit .... würde am liebsten auch zu Tisch ... wenn ich denn hier weg könnte ... also fällt mal wieder Mittag aus. Manno, das hasse ich ja. :( :suspect: Also, wieder mit Kaffee und Zigaretten den Hunger betäuben .... Hmm, ich glaube am Freitag stell ich mal ein bisschen was im Netzwerk um, damit hier ein bisschen Bewegung in den Laden kommt. Neuer Server wär ja nicht schlecht ... und macht Spass.
  12. Brauchst Du einen geeigneten Switch mit Portbasierter Security (CISCO hat sowas im Programm) für, meines wissens kann man beim Server keine MAC Adressen vom Zugriff auf eine Domäne abhalten (ausser über den Umweg der DHCP Vergabe für mehrere Subnetze, die nicht miteinander kommunizieren können). Grüsse Gulp
  13. Gulp

    Letzter macht das Licht aus

    Moin .... ... ich glaub ich werd erst jetzt so richtig wach, obwohl ich schon fast 2 Stunden auf der Arbeit bin. Irgendwie scheint auch der Kaffee nich mehr zu wirken ..... * indieRundewink * Gulp
  14. Office 2003 bietet mit dem "Microsoft Office 2003 Assistent zum Speichern eigener Einstellungen" die Möglichkeit alle Konteninformationen von einem PC auf einen anderen zu Übertragen. (zu finden unter Start --> Programme --> Microsoft Office --> Microsoft Office Tools) Damit gelingt recht einfach ein "Umzug" von Outlook. Grüsse Gulp
  15. Gulp

    Letzter macht das Licht aus

    Mittagspause? Wat'n dat? ** nocheinKaffeehol **
  16. Da gibt's mehrere Möglichkeiten, schau Dir mal folgende Links an: TrendMicro KB 23776 TrendMicro KB 22633 TrendMicro KB 16122 Den letzten Hinweis (mit der ipxfer.exe) habe ich bei solchen Update Problemen schon öfter erfolgreich eingesetzt. Dies geht am Einfachsten über ein temporäres Logon-Script (je nach Client Anzahl ein paar Tage bis ein paar Wochen), welches je nach Anzahl der Clients und deren Anmeldeverhalten, ein paar Tage oder eben ein paar Wochen verwendet wird. Es spielt dabei keine Rolle, wie oft Clients diesen Befehl ausführen. Grüsse Gulp
  17. Dr. Melzer hat recht, das wird nicht gehen. Erstens wegen mangelnder Treiber-/TWAIN Unterstützung auf dem 2003 Server und ausserdem wirst Du den ohne entsprechende Software nicht freigeben können. Lediglich die gescannten Bilder wirst Du von einem XP/2k/NT/ME/9x Client auf eine zentrale Freigabe des 2003 Servers schaufeln können. Dafür gibt es, wie Dr. Melzer dies schon treffend bemerkte, spezielle angepasste Scanner (HP Digital Sender, etc) Grüsse Gulp
  18. Gulp

    Letzter macht das Licht aus

    ... der Gulp arbeitet noch ....
  19. Das müsste von den jeweiligen Setups unterstützt werden, aber keine Ahnung, ob das auch tatsächlich vorgesehen ist. Bei Novell ist es zumindest wahrscheinlich. Zumindest für diverse Novell Client Versionen gibts ein paar brauchbare Anleitungen in der Novell Knowledgebase für diverse Silent Installationen/Deinstallationen. Wird aber wohl darauf hinauslaufen, dass Du einige Parameter mitgeben musst. Je nach verwendeter Technik eine ini oder so, da der Client wissen will was alles (nur TCP/IP oder TCP/IP und IPX/SPX oder nur IPX/SPX, IPX Rahmentyp, bevorzugter Server, Bindery oder NDS, SingleSignOn und so weiter) installiert werden soll. Möglicherweise hilft auch ein Ausführen der jeweiligen setup.exe mit dem Parameter -? oder /?, meistens schmeissen die EXE dann ein paar Setup Parameter aus. Grüsse Gulp
  20. Bei mir funzt das wunderbar ... egal mit welcher Dateiart. Schau mal nach was das überhaupt für eine Datei ist, vielleicht ist's auch nur eine Verknüpfung auf die Notes.exe (kann mir nämlich nicht vorstellen, dass die EXE für Notes auf'm Desktop liegt.). Also dann del /S /Q "C:\Dokumente und Einstellungen\All Users\Desktop\notes.lnk" Grüsse Gulp
  21. Rmdir heisst RemoveDirectory .... Notes.ini ist kein Directory (also Ordner), sondern ein File (also Datei), ebenso die notes.exe. Da hilft der Befehl delete (del), ausserdem setzt man Pfade mit enthaltenen Leerzeichen in Anführungszeichen: "C:\Dokumente und Einstellungen\All Users\Desktop\notes.exe" Hoffe das bringt Dich weiter ... Grüsse Gulp
  22. ich bin ganz zufrieden mit http://www.flashpeak.com/sbrowser/
  23. Geht über GPO's, allerdings erst ab Windows XP/2003, Stichwort "Computerkonfiguration --> Administrative Vorlagen --> System --> Remoteunterstützung" und auch im MMC Snap-In Terminaldienstkonfiguration: Verbindungen --> Rechtsklick auf RDP-Tcp --> Eigenschaften --> Remoteüberwachung Im englischen Server Terminal Services Configuration MMC: Connections -->Rechtsclick auf RDP-Tcp --> Properties --> RemoteControl Hier kann auch eingestellt werden, ob der User sein Einverständnis abgeben muss/kann. Leider funktioniert das nicht in beide Richtungen, also dass der User eingreifen kann, wenn der RDP Client die Kontrolle hat. Entweder hat der User oder der RDP Client die Kontrolle über die Maschine. VNC also nicht "wegwerfen" *grins* Grüsse Gulp
  24. Du meldest Dich direkt an der Konsole an. Die Konsolensession ist die lokale Anmeldesession, quasi exakt das was Du siehst, direkt am Monitor und der Tastatur des Servers Deine Anmeldedaten eintippst. Ist ein anderer User am Server angemeldet, wird bei der Standardkonfiguration der GPO's dieser gesperrt/abgemeldet je nachdem Du Dich mit dem gleichen oder einem anderen Benutzer anmeldest. Dies kann man allerdings auch so konfigurieren, dass der angemeldete User sieht was Du am Server machst oder Du siehst was er macht. Ist niemand am Server angemeldet, wird der Bildschirm mit den Anmeldedaten des RDP Clients gesperrt. Grüsse Gulp ** edit ** .... uups Christoph war schneller! ** /edit **
  25. Was heisst der normale Desktop, die Option -console bewirkt die Verbindung mit der Console Session, also genau das was Du siehst, wenn Du Dich direkt am Server anmelden würdest. Dies ist nicht zu verwechseln mit einer Terminal-Session. Grüsse Gulp
×
×
  • Neu erstellen...