Jump to content

Darksun777

Members
  • Gesamte Inhalte

    416
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von Darksun777

  1. Danke vielmals, das war genau die Information die ich gebraucht habe ! :)

     

    Und ja, ich habe mir Mühe gemacht, aber ich habe wohl den Wald vor lauter Bäumen nicht gesehen .. *stärkere Brille kaufen muss*..

     

    Ich poste prinzipiell erst wenn ich selbst nicht mehr weiterkomme und nachdem ich die Suchfunktion etc. benutzt habe.

    Sorry wenn die Lösung so offensichtlich war, aber ich habs einfach nicht gesehen.

  2. Hallo,

     

    wir haben ein riesen Problem in unserer Firma nach der Installation von SP2...

     

    Beim Anmelden an der Domäne verabschiedet sich WinXP (nur mit SP2) sporadisch mit einem Bluescreen.

    Im Bluescreen selbst werden dann immer unterschiedliche Fehlerursachen angegeben, mal ist es ein PAGE_FAULT, mal irgendein Treiber.

    Das Problem besteht an ALLEN WinXP Rechnern mit SP2.

     

    Der Bluescreen kommt immer an derselben Stelle, und zwar dann, wenn das Privat-Laufwerk (P:) gemappt werden soll.

     

    Hier mal unser Logonscript:

     

    -------------------------------------------------------------------------

     

    :winnt

     

    net use * /delete /yes

     

    net use n: \\192.168.0.1\daten /persistent:no

     

    net use m: \\192.168.15.1\daten_ma /persistent:no

     

    if exist \\192.168.0.1\privat\privat\%username% net use p: \\192.168.0.1\privat\privat\%username% /persistent:no

     

    if exist \\192.168.15.1\privatma\privat\%username% net use p: \\192.168.15.1\privatma\privat\%username% /persistent:no

     

    net time %logonserver% /SET /YES

    exit

     

    ---------------------------------------------------------------------------

     

    Ich habe mit Hilfe von Pause-Befehlen festgestellt, das es immer nur beim P-Laufwerk passiert. Und zwar dann, wenn das P-Laufwerk einem anderen Benutzernamen als zuvor zugeordnet werden soll, z.b.

     

    - Benutzer ABC meldet sich an, P-Laufwerk wird auf ABC gemappt

     

    - Benutzer CDE meldet sich,P-Laufwerk soll auf CDE gemappt werden --> Bluescreen

     

    In der DOS-Box steht dann auch manchmal die Fehlermeldung

     

    "Ein aktiver Prozess greift auf das Laufwerk zu"

     

    Das kommt IMHO daher, das der aktuelle Pfad komischweise immer auf P: steht.

    Wenn ich im Windows z.B. eine DOS-Box öffne, bin ich immer auf P: und nicht auf C:, das habe ich noch nicht ändern können (?)

     

    Das ganze hört sich sicher ziemlich komplex an, ich hoffe ich konnte es verständlich erklären .. und hoffe jemand kann mir helfen, da ich echt nicht mehr weiter weiss.

     

    :confused:

     

    Greetz

  3. So, ich hab des Rätsels Lösung falls es jemanden intressiert:

     

    Der Task wurde zwar ausgeführt, aber das kopieren des Logfiles auf ein Netzlaufwerk hat nicht funktioniert.

     

    In der batch stand drin:

     

    copy robolog.txt o:\it\backuplogs

     

    o: ist ein Netzlaufwerk

     

    So funzt es nicht, aber nach dem ich es geändert habe in

     

    copy robolog.txt \\server\freigabe\backuplogs

     

    funktionierte es !

     

    Keine Ahnung warum es mit dem Laufwerksbuchstaben nicht klappt wenn keiner am Server angemeldet ist...

  4. Hi all,

     

    ich hab da ein Problem mit einem Win2003-Server.

     

    Ich habe einen Task geplant (ausführen einer Batch Datei) ..

    Als Konto habe ich das Domänen-Admin-Konto angegeben.

    Soweit ist alles ok, wenn ich den task manuell anstosse wird er korrekt ausgeführt.

     

    Nur wenn ich mich vom Server abgemeldet habe, wird der Task nicht mehr zur geplanten Zeit ausgeführt!

    Das komische ist aber, in dem Fenster der geplanten Tasks steht dann drin das der Task zur geplanten Uhrzeit ausgeführt wurde .. das stimmt aber nicht, das sehe ich z.B. daran das kein Logfile erstellt wurde.

     

    Weiss jemand an was das liegen kann ?

     

    Bin dankbar für jede hilfe, ich weiss nicht mehr weiter .. hab den Task schon x-mal neu erstellt, aber es hilft nix..

  5. HiHo,

     

    wir haben hier 2 Standorte mit jeweils einem DC, verbunden über eine 2MBIT-Leitung.

     

    Wir möchten nun die Daten auf den jeweiligen Servern redundant zur Verfügung stellen, d.h. das wenn mal die WAN-Leitung ausfällt die Benutzer trotzdem noch an die Daten rankommen.

     

    Auf Server1 wären es z.B. über 60Gig an Daten welche zu replizieren wären ..

     

    Zu was würdet ihr eher raten, zu DFS oder zu einer Batch-Lösung (robocopy oder ähnliches) ?

     

    Danke für jeden Tip...

  6. Richtig, du kannst keine Veränderungen mehr vornehmen was die einzelnen Rollen betrifft (Schema etc.) wenn der Server, welcher die Rollen hat, nicht online ist.

     

    Such einfach mal nach den FSMO Rollen und Du wirst bestimmt fündig.

     

    Edit: Objekte im AD kannst Du solange weiterhin anlegen, bis der 2.DC keine freien RID´s mehr hat. Dann würde er normalerweise beim RID-Master eine Anfrage stellen um neue zu erhalten.

    Ist der RID-Master aber nicht erreichbar kannst Du dann auch keine Objekte mehr erstellen.

     

    Du musst also im Falle eines Falles so schnell wie möglich die Rollen einem anderen Server zuordnen, falls keine Aussicht auf Wiederherstellung des 1.DC besteht.

  7. Hallo,

     

    also net use funktioniert definitiv mit W2k3.

     

    IMHO ist folgende Gruppenrichtlinien-Einstellung das Problem:

     

    Default Domain Controller Policy --> Computerkonfiguration --> Windows-Einstellungen --> Sicherheitseinstellungen --> Lokale Richtlinien --> Sicherheitsoptionen -->

     

    "Microsoft Netzwerk(Server): Kommunikation digital signieren (immer)"

     

    Diese Einstellung solltest Du mal auf "deaktiviert" stellen, danach sollte es imho funzen.

     

    Greetz

  8. Hallo,

     

    ".local" sollte man nicht mehr für einen Domänennamen verwenden, da irgendwann in ferner Zukunft dieser Name irgendwas mit Multicast zu tun haben wird.

     

    Hab ich neulich in einem Artikel im Netz gelesen.

     

    Greetz

     

    EDIT: Hier der Text und die URL

     

     [url]http://www.layerdrei.de/tips.htm[/url] 

     

    ------------------------- SNIP ---------------------------------------------

     

    [04.08.04] Multicast DNS oder warum .local keine gute Wahl für eine AD-Domäne ist

     

    Viele Firmen haben Ihre DNS-Domains mit einer Top-Level Domain versehen, die im Internet nicht definiert ist, nämlich .local.

    Wie sich jetzt heraus stellt, ist dies keine gute Idee gewesen, denn es gibt zur Zeit einen Entwurf für Multicast DNS, der, sollte er offiziell gültig werden, die Endung .local unbrauchbar macht. Der Sinn von Multicast DNS soll es sein, innerhalb eines lokalen Netzwerkes die Namensauflösung ohne einen dedizierten DNS-Server durchzuführen.

    Beim Multicast DNS wird kein DNS-Server mehr benötigt.

    Ein Client, der Multicast DNS benutzt, versucht, jeden Namen, der mit der Endung .local endet, über einen IP-Multicast auf die Adresse 224.0.0.251 aufzulösen. Das bedeutet innerhalb einer Windows Domäne aber, daß kein Computername mit der Endung .local mehr über den DNS-Server aufgelöst wird.

     

    Bisher unterstützt Microsoft Multicast DNS nicht.

     

    Daher ist dieses Feature in naher Zukunft nur bei Nicht-Micosoft Clients kritisch, die auf die Windows-Domäne zugrifen sollen.

    Hier kann man eventuell auf Workarounds zurück greifen, wie eine zweite Zone, in der alle Clients ein zweites mal aufgelistet sind. Trotz allem sollte man in Zukunft aus Sicherheitsgründen keine Domänen mehr mit der Endung .local ausstatten.

     

    Am Besten nimmt man als Domänennamen einen offiziellen Internet-Namen, den man selbst registriert hat, oder eine Subdomäne zu seiner offiziellen Domäne.

    Auch deutsche, nicht vergebene Top-Level-Domain Namen sind auf längere Frist vermutlich sicher. :-)

     

    ---------------------- SNAP ---------------------------------------

  9. Original geschrieben von Dr.Melzer

    Win 9.x Systeme konnen nicht in eine Domäne eingebunden werden.

     

    Also der Aussage kann ich so nicht zustimmen. Es ist so, das Win9x Clients kein Computerkonto in der Domäne haben und es wirken auch keinerlei Gruppenrichtlinien.

     

    Aber an die Domäne anschliessen kannst Du die Win9x Clients sehr wohl, ich hab die genauen Einstellungen jetzt nicht im Kopf, aber so ungefähr sollte es gehen:

     

    DNS-Server eintragen

    WINS-Server eintragen

    irgendwo in den Eigenschaften der Netzwerkverbindung gibt es einen Punkt wo du den Domänennamen eintragen musst ("An Windows NT Domäne anmelden" oder so ähnlich).

     

    Wichtig, hier nur den namen VOR dem punkt eintragen, die endung weglassen.

     

    z.B: Deine Domäne heist abc.local, dann nur ABC eintragen.

     

    So hat es bei uns gefunzt, man kann sich an der Domäne anmelden.

     

    Was dann funktioniert sind Logonscripts und Zugriffsberechtigungen, mehr nicht.

     

    Hoffe Dir etwas geholfen zu haben.

  10. Original geschrieben von Dr.Verpeilung

    aaah! perfekt! genauso hatte ich mir das vorgestellt. und die clients verwenden den exchange dann wiederum zum abholen der e-mails und auch zum versenden??? also die ausgehende mail geht erst an den exchange der sie dann an schlund & partner weiterleitet oder wie???

     

     

    gibts auch ne anständige viren und spamlösung für exchange???

     

     

    Ja,das versenden/empfangen von Mails löpt dann über den Exchange.

     

    Als Virenlösung kann ich Dir z.B. die Enterprise-Version von Trend Micro empfehlen,die haben wir auch im Einsatz. Hat ne super Scan-Engine und die Updatezyklen sind auch in Ordnung.

×
×
  • Neu erstellen...