docmartin

naja, wenn M$ das so vorsieht... - warum dann allerdings so eine ***ische Fehlermeldung statt "Sie können den Bereich nicht verkleinern" oder ähnlich kommt, weiß man wohl auch nur in Redmond. Ich werde für die restliche Serverlaufzeit meine Hintenrum-Lösung lassen - never touch.... Danke! Docmartin

Nachtrag: ich habe erst einmal eine Hintenrum-Lösung genommen und einen größeren Adreßbereich ausgeschlossen (das ging!) - somit ist mir bis zum neuen Server erstmal geholfen. Interessieren tät's mich aber trotzdem... Gruß Docmartin

Hallo, ich habe ein Problem mit der Verkleinerung des DHCP-Adreßbereichs bei einem Windows NT-Server einer Schule. Bislang vergibt der DHCP-Server Adressen im Bereich 192.168.0.20-192.168.0.190, Subnet Mask 255.255.255.0, kein Ausschlußbereich. Der DHCP-Server versorgt zudem noch eine 2. Netzwerkkarte mit dem Adreßbereich 192.168.1.20-100. Da nun künftig wg. besserer Kontrolle der angesurften Internetseiten die Schülerrechner auf feste IPs umgestellt werden sollen, muß der DHCP-Adreßbereich verkleinert werden. Die Schaltfläche "Bereich ändern" läßt sich noch anklicken, der Klick auf OK gibt jedoch folgende Fehlermeldung: "DHCP-Manager: Der Bereich ist weniger erweitert als die angegebene rückwärtige Erweiterung. Erweitern Sie den Bereich um Einheiten von 32 Adressen." Die Änderung wird nicht durchgeführt. Testweise habe ich eine Endadresse gewählt, die um ein Mehrfaches von 32 oberhalb der Anfangsadresse 20 liegt - selber Effekt. In der MS-Knowledgebase habe ich noch nichts Aussagekräftiges gefunden. Hat jemand eine Idee? (Notfalls muß noch einige Monate alles beim Alten bleiben, dann kommt ohnehin ein neuer Server 2003). Gruß Docmartin

Hallo, bei einem Kunden habe ich folgende Situation: Netzwerksegment mit 1 Linux-Server als DC, PC 1 mit XP prof. SP 2, PC 2 mit NT SP 6, PC3 mit NT SP 6, PC 4 mit Win98. Alle bekommen ihre IPs über DHCP vom Server. Die PCs 1-3 sind nicht in der Domäne, d.h. die Anmeldung erfolgt lokal. PC 2 greift auf den Drucker von PC 1 sowie über ein manuell verbundenes Netzlaufwerk auf eine Dateifreigabe von PC 1 zu, PC1 kann umgekehrt auf dem Drucker von PC 2 drucken . Dies klappt insgesamt auch gut, nur gibt es seit einiger Zeit vereinzelt folgendes Problem: Wird PC1 erst nach PC2 hochgefahren (wobei auf PC2 natürlich Fehlermeldungen beim verbinden des Netzlaufwerkes kommen), kann ich mich an PC 1 als Administrator problemlos anmelden; bei Anmeldung als der normale Benutzer kommt die Anmeldemelodie und das Hintergrundbild erscheint, danach passiert nichts mehr (NumLock und Maus reagieren noch). Ist nach dem (notwendigen) Reset das Netzwerkkabel abgezogen, klappt das Hochlaufen ganz normal. Außerdem hatte ich bei der gleichen Konstellation dann auch einmal das Phänomen, daß bei Abmeldung des normalen Benutzers auf PC1 die Prozedur lief bis "Netzwerkverbindungen werden getrennt", dann passierte ebenfalls nichts mehr. Es waren zu diesem Zeitpunkt auf PC 2 keine Dateien geöffnet, die auf PC1 liegen - und dann sollte eigentlich eine Fehlermeldung kommen, daß ein anderer Benutzer noch Dateien offen hat. Wird PC1 vor PC 2 hochgefahren, gibt es überhaupt keine Probleme. Es ist nur das normale Arbeitsbenutzerkonto betroffen und nicht der Administrator. In Verdacht habe ich den Netzwerkdrucker, der nur für den Arbeitsbenutzer eingerichtet ist und das einzige ist, was PC 1 auf PC 2 nutzt - muß ich in einer ruhigen Minute mal testen. Hat jemand sonst noch eine Idee? Gruß Docmartin P.S. Die Ereignisanzeige von PC 1 spuckt nichts Verdächtiges aus.

Hallo allerseits, statt weiter vergeblich zu suchen, habe ich einen Nachmittag für die brutalstmögliche Fehlerbehebung geopfert: format c:. Nach kompletter Neueinrichtung läuft die Kiste wieder normal. Gruß Docmartin

Hallo, ist das Problem so exotisch, daß der geballte Sachverstand hier keine Idee hat?? Dann muß ich die Kiste wohl doch plätten :-( Gruß Docmartin

Hallo allerseits, bei einem Kunden besteht auf einem PC mit XP SP2 folgendes Problem: Nach Öffnen des Arbeitsplatzes dauert es lange, bis Laufwerke angezeigt werden, dabei wedelt ständig die Taschenlampe. Dies unabhängig davon, ob als lokaler Admin (ohne netzlaufwerke) oder Domänenbenutzer (mit Netzlaufwerken) angemeldet. Dies passiert bei jedem Start des Arbeitsplatzes. Im IE dauert es ewig, bis Seiten angezeigt werden. Zugriffe im Netzwerk sind langsam. Gleichzeitig erscheint im Systemprotokoll dann mehrfach folgender Eintrag: Ereignistyp: Fehler Ereignisquelle: DCOM Ereigniskategorie: Keine Ereigniskennung: 10010 Datum: 08.12.2005 Zeit: 14:00:33 Benutzer: KN_Ilsede\buecherei Computer: PCL Beschreibung: Der Server "{A1F4E726-8CF1-11D1-BF92-006008ED811}" konnte innerhalb des angegebenen Zeitabschnitts mit DCOM nicht regstriert werden. Gehe ich auf Verknüpfungen, die direkt auf Ordner oder Netzlaufwerke weisen, wird der Inhalt normal schnell angezeigt - als ob der Explorer erst mit sich zu Rate gehen muß, was er für Laufwerke anzuzeigen hat. Googeln, http://www.eventid.net und regedit ergaben, daß hinter dieser ID der WIA Device Manager (WIADevMgr) steckt. Es gibt keine Protokolleinträge, daß Dienste nicht starten würden, Hoch- und runterfahren ist normal schnell. Deaktivieren des VS (McAfee 8.0i) beschleunigt nichts. Der ergoogelte Tip, Geräte abzuhängen und zu deinstallieren (speziell USB) brachte nichts. Vor einiger Zeit soll es auf der Kiste das Problem gegeben haben, daß der WMI-Dienst nicht startete, was seit Installation von SP 2 behoben ist - die Lahmars***igkeit war wohl vorher schon da. Was macht dieser WIA Device Manager, kann ich den ggf. abschalten , wenn ja wie (unter Dienste finde ich ihn nicht)? Wäre schön, wenn jemand eine Lösung außer "Neu aufsetzen" wüßte! Gruß Docmartin Nachtrag: Wenn der Arbeitsplatz dann seine Laufwerke beisammen hat, sind sie einfach alphabetisch untereinander aufgelistet und nicht wie sonst in Kategorien (Festplatten, Geräte mit Wechselmedien, Netzlaufwerke) unterteilt.

Hallo, googeln ergab, daß anscheinend der Zeritfikatsserver (CertSrv) laufen muß, damit diese Fehlermeldung beim NT-BAckup nicht auftaucht. Jetzt einfach noch die Fragen: Ist die DCOM-Fehlermeldung nur lästig - ntbackup läuft ja eigentlich trotzdem - oder steckt da ein echtes Problem dahinter? Sind bei Inbetriebnahme vom Zertifikatsserver irgendwelche Probleme oder negativen Auswirkungen zu erwarten? Ich möchte nämlich ungern - schon gar nicht als Vertretung - an einem ansonsten funktionierenden System (das als DC, Datei- und Exchangeserver läuft) herumdrehen - den Zertifikatsserver vermißt bislang keiner. Gruß Docmartin

Hallo, nachdem der Drucker auch ohne Freigabe und nach Neueinrichtung partout nicht an diesem Rechner drucken wollte (Lehrerrechner mit anscheinend einigen ALtlasten), habe ich die ganze Sache so umgestrickt, daß der Drucker nun an einem anderen PC hängt, mit neuen Benutzerprofilen klappt es nun auch mit der Netzwerkdruckerei für alle. Problem also nicht beseitigt, aber umgangen. Danke und Gruß Docmartin

Hallo Günther, ich habe im Editor mir diese Datei einmal angesehen, ohne sie aber wieder zu speichern. Zur Sicherheit habe ich deinen Vorschlag befolgt, mal sehen, was heute abend passiert. Gestern abend lief die Sicherung etwas besser, er hat nicht das gesamte Laufwerk d:\ nicht öffnen können, sondern nur eine bestimmte Datei, s.u. WARNUNG: Teile von d:\DATEN\xxxxx.xxx können nicht gelesen werden. Die gesicherten Daten sind beschädigt oder unvollständig. Die Datei kann nicht ordnungsgemäß wiederhergestellt werden. Sie haben keinen Zugriff auf Teile des Verzeichnisses D:\DATEN\xxxx. Sie besitzen möglicherweise nicht die Berechtigung, die Datei zu öffnen oder das Verzeichnis fehlt oder ist beschädigt. Wenden Sie sich an den Besitzer oder Administrator. Ich habe den Verdacht, daß mit dem Problem auch folgender Eintrag im Systemprotokoll zu tun hat: Ereignistyp: Fehler Ereignisquelle: VolSnap Ereigniskategorie: Keine Ereigniskennung: 25 Datum: 22.11.2005 Zeit: 20:44:54 Benutzer: Nicht zutreffend Computer: SERVER1 Beschreibung: Die Schattenkopien von Volume "D:" wurden gelöscht, weil der Schattenkopiespeicher nicht rechtzeitig vergrößert wurde. Sie sollten die E/A-Last auf dem System verringern oder ein Schattenkopie-Speichervolume, von dem keine Schattenkopie erstellt wird, auswählen. Zeitlich passierte dies nämlich während der Sicherung von Laufwerk d: Gruß Docmartin

Hallo, unser SBS (DC und Exchange-Server) soll von Mo-Fr jeden Abend per ntbackup (konfiguriert über den Sicherungsassistenten) eine interne Sicherung seiner Laufwerke (c:, d:) und seines Systemstatus in einen Sicherungsordner d:\sicherung\backup files erstellen, wobei jeden Tag eine neue .bkf-Datei erstellt wird und Montags wieder von vorne begonnen wird. Einige Ordner, u.a. natürlich d:\sicherung, sind von der Sicherung ausgeschlossen. Das SmallBusinessBAckupSkript.bks sieht so aus: SystemState C:\ D:\ C:\ClientApps\ /Exclude C:\TEMP\ /Exclude C:\VxPushRA\ /Exclude D:\DATEN\xxxx /Exclude D:\Profile\ /Exclude D:\sicherung\ /Exclude D:\sicherung\Backup Files\ /Exclude D:\Teminalserver\ /Exclude JET SERVER1\Microsoft Information Store\Erste Speichergruppe\ Bis auf die Sicherung von d: funktioniert das Ganze auch, bei Laufwerk d: werden jedoch einzelne Ordner, häufiger aber sogar das ganze Laufwerk übersprungen mit der Begründung im Sicherungslog (vgl. Anlage): Warnung: "D:\" kann nicht geöffnet werden und wird übersprungen. Ursache: Das System kann den angegebenen Pfad nicht finden. wobei es bei "normalen" Zugriffen auf das Datenlaufwerk d: keinerlei Probleme gibt. Die Ereignisanzeigt vermeldet demzufolge: Ereignistyp: Fehler Ereignisquelle: NTBackup Ereigniskategorie: Keine Ereigniskennung: 8019 Datum: 15.11.2005 Zeit: 20:55:59 Benutzer: Nicht zutreffend Computer: SERVER1 Beschreibung: Vorgang beenden: Es wurden Warnungen oder Fehler gefunden. Weitere Informationen finden Sie im Sicherungsbericht. Was kann da los sein? Auf einen passenden Google- oder Forumseintrag bin ich noch nicht gestoßen. Gruß Docmartin P.S. Das Problem ist nicht ganz dramatisch, da die Arbeitsdaten von d: zusätzlich einige Stunden später - wie die Daten von allen Servern - übers Netz auf ein Band gesichert wird. Der Streamer hängt nicht am betroffenen Server. BAckup Server1.txt

Drucker ist an einem der PCs per LPT 1 angeschlossen und wurde als lokaler Admin installiert und freigegeben. Auf zwei weiteren PCs ist er ebenfalls installiert, und zwar ebenfalls als lokaler Drucker, dem LPT1 per net use-Befehl zugewiesen wird. Grund: es werden serverbasierte Benutzerprofile verwendet, und der vorherige Versuch, ihn auf den beiden anderen PCs einfach als Netzwerkdrucker einzurichten und per Batch-Datei (mit rundll32 printui.dll ...) im Autostart-Ordner allen Benutzern als Standarddrucker zuzuweisen, klappte nur halb: Der Drucker war zwar vorhanden, aber die Zuordnung als Standarddrucker bei den einzelnen Benutzern klappte nach dem Zufallsprinzip. Auf allen 3 PCs ist ein weiterer Drucker an einem Printserver installiert, der problemlos läuft. Gruß Docmartin

Hallo Kohn, sc \\server1 queryex certsvc ergibt: Service_Name : certsvc Type : 10 Win32_Own_Process state: 1 stopped (Not_Stoppable, Not_PAusable, ignores_Shutdown Win32_Exit_Code: 1077 (0x435) Service_Exit_Code: 0 (0x0) Checkpoint: 0x0 Wait_Hint: 0x0 PID : 0 Flags : Ich gebe zu, daß mir das ziemlich wenig sagt. Die Einträge im Ereignisprotokoll lassen sich über die gesamte Laufzeit des Systemprotokolls zurückverfolgen, wobei ein zwischenzeitlicher Serverneustart nichts änderte. Gruß Martin

Hallo, ich habe bei einem Kunden mit einem Kyocera FS 600 an einem PC mit Win 2000 professional SP 4 - angeschlossen an LPT1 - ein etwas dubioses Problem: - Bin ich mit einem lokalen Benutzerkonto angemeldet, druckt er problemlos. - Bin ich mit einem Domänenbenutzerkonto angemeldet (egal ob einfacher Benutzer oder Admin), erscheint in der Taskleiste das Druckersymbol, in den Spoolerfenster des Druckers heißt es wechselnd in der 1. Zeile Lokale Druckerdatendatei ...wird gedruckt ...wird gelöscht, zusätzlich taucht immer wieder eine 2. Zeile auf Lokale Druckerdatendatei ...in Warteschlange, mit selber Größe und Uhrzeit. Erst nach Abmeldung des Benutzers kommen sämtliche Druckaufträge gesammelt aus dem Drucker. Ändere ich die Druckereinstellungen derart, daß nicht über den Spooler, sondern direkt gedruckt wird, kommt eine Fehlermeldung "Fehler beim Schreiben auf LPT1", Optionen Wiederholen/Abbrechen. - Der Drucker ist freigegeben, Drucken übers Netz klappt. Die Spoolereinstellungen sind auf den Standardwerten, d.h. Drucken über Spooler - Drucken sofort beginnen. Ändern in Drucken, wenn letzte Seite gespoolt wurde, bringt nichts. Es scheint also, daß während ein Domänenbenutzer angemeldet ist, der Spooler seine Druckaufträge nicht los wird bzw. der Port LPT1 blockiert ist. Neuinstallation des Druckers half nicht, egal ob als lokaler Administrator oder Domänenadmin. Hat jemand eine Idee, was da klemmt?

Hallo, ich finde im Systemprotokoll unseres Server 2003 SBS täglich ab 20.00 (Start von ntbackup) mehrfach über den Zeitraum von ca. einer Stunde diese gleichlautenden Einträge: Ereignistyp: Fehler Ereignisquelle: DCOM Ereigniskategorie: Keine Ereigniskennung: 10002 Datum: 15.11.2005 Zeit: 20:52:37 Benutzer: AB-PEINE\SBS Backup User Computer: SERVER1 Beschreibung: Zugriff verweigert beim Versuch, einen DCOM-Server zu starten. Server: {D99E6E73-FC88-11D0-B498-00A0C90312F3} Benutzer: SBS Backup User/AB-PEINE, SID=S-1-5-21-3465625181-1415543005-1699559974-1126. Googeln half hier nicht richtig weiter, da die dortigen Meldungen i.d.R. andere Dienste/Benutzer betreffen. Ich habe auch ausprobiert Start-Ausführen dcomcnfg.exe - Arbeitsplatz - DCOM-Konfiguration. Dort ist aber ntbackup nicht gelistet, einziger "Verdächtiger" wäre sonst noch der Dienst für die Volumenschattenkopien. Kann jemand aus dem Logeintrag entnehmen, welchem Dienst der Zugriff verweigert wird, damit ich diesen Eigenschaften-Startberechtigungen anpasssen kann? HAben die Fehlermeldungen überhaupt eine schwerwiegende Bedeutung? Interessanterweise läuft ntbackup trotzdem. Gruß Docmartin

Hallo, ich habe ein etwas kurioses Problem auf einem Rechner mit Win XP prof. SP2 und Word 97. Das Ganze ist einer Domäne mit einem Server 2003 SBS als DC und Dateiserver. - Öffne ich als Benutzer xxx im Explorer eine Datei aus einem Netzlaufwerk mit Leerzeichen im Dateinamen per Doppelklick, meldet Word "<Pfad\Datei> wird von xxx benutzt. Möchten Sie eine Kopie erstellen?" Nach "Abbrechen" kann mit der Datei normal gearbeitet werden. Schließe ich die Datei, ohne auch Word zu beenden, und öffne sie erneut im Explorer, bleibt die Fehlermeldung aus. - Kopiere ich dieselbe Datei auf ein lokales Laufwerk und öffne sie dort per Explorer, meldet Word stattdessen "Soll <Datei> wiederhergestellt werden?" Egal ob Ja oder Nein, es kann die Datei bearbeitet werden. - Lege ich im Netzlaufwerk ein neues Word-Dokument ohne Leerzeichen im Namen an, klappt das Öffnen ohne Probleme. - Öffne ich die Dateien aus Word heraus (Datei-Öffnen), gibt es ebenfalls keine Probleme, egal ob mit oder ohne Leerzeichen im Pfad. Den Tip, die Registry-Schlüssel HKEY_LOCAL_MACHINE\Software\Classes\Word.Document.8\Shell\Open\Command und HKEY_CLASSES_ROOT\Word.Document.8\Shell\Open\Command "...sollte der Wert auf der rechten Seite des Registry-Editors den kompletten Pfad zur Winword.exe zeigen und den Parameter "/e" haben (Bsp. C:\Office\winword.exe /e). Lautet der Parameter "%1", tritt das beschriebene Verhalten auf." zu untersuchen und zu ändern, habe ich probiert, ändert aber leider nichts am Verhalten von Word. Diese Fehler sind zwar nur lästig, da die Dokumente ja zugänglich sind, aber der Mitarbeiter möchte natürlich schon normal arbeiten können. Hat jemand eine Idee? Danke

Hallo Leonex, Neustart ändert leider nichts. Ich werde das M$-Tool aber einmal ausprobieren. Gruß Docmartin

Hallo allerseits, ich habe bei einem Kunden in einer Domäne auf 2 Win2k-Rechnern Probleme mit der lokalen Kopie des Benutzerprofils: Domänencontroller ist ein Linux-Server (Samba-Version 2.2.8), der auch DHCP und DNS-Server ist. Die Benutzer haben servergespeicherte Profile. Die Domäne heißt "samba" Das "default user"-Profil wurde auf den beiden PCs derart modifiziert, als das Profil eines lokalen Beispielbenutzers über Systemsteuerung-System-Benutzerprofile in default user kopiert wurde (damit jeder, der sich neu an dem PC anmeldet, ein passendes Profil bekommt). Es gibt keine gleichlautenden Benutzer lokal und in der Domäne. Aufnahme in Domäne, Anmeldung, Anmeldeskript etc. klappen tadellos. Einziger Fehler ist, daß Windows bei jeder Anmeldung eines Benutzers für diesen einen neuen lokalen Profilordner anlegt statt den vorhandenen wieder zu verwenden. Für Benutzer Meier sieht das so aus, daß unter Dokumente und Einstellungen die Ordner meier, meier.samba, meier.samba.000, meier.samba.001 etc. stehen, bei jeder Anmeldung von Meier kommt ein meier.samba.xxx dazu und müllt mir die Platte zu. Fehlermeldungen gibt es bei der ganzen Prozedur keine. Der Versuch, diese Profilordner als lokaler Administrator zu löschen, scheitert daran, daß einzelne Dateien angeblich in Benutzung sind (einmal der Link zu Outlook Express in der Schnellstartleiste, einmal eine Vorlagendatei). Auch ein Registry-Patch, der den lokalen Profilordner nach der Abmeldung löscht, bleibt wirkungslos. Die übrigen Win 2k-PCs in der Domäne haben das Problem nicht. Any idea? Gruß Docmartin

Hallo, neu aufgesetzt wurde nur einer der Server. Der andere war vorher aber nur Mitgliedsserver und wurde nach der Neueinrichtung von Server 1 neu in die Domäne aufgenommen und dann zum 2. DC heraufgestuft. Zur Verteilung der Masterrollen: Der neu aufgesetzte Server 1 hat lt. Management-Konsole die Masterrollen inne (ob der 2. DC der gleichen Meinung ist, habe ich noch nicht getestet). Auf Server 1 lassen sich die Einträge allerdings nicht editieren. Gruß Docmartin

Nachtrag zu diesem Problem: Ich kann auch keine Domänenbenutzer in lokale Gruppen auf den Arbeitsstationen hinzufügen, obwohl ich als Domänenadmin angemeldet bin und die Benutzer alle sehe, Beim Hinzufügen kommt dann aber Fehlermeldung: Die angegebene Domäne ist nicht vorhanden oder es kann keine Verbindung hergestellt werden. Ich muß eine Anwendung installieren, die nur unter dem Installationsbenutzernamen richtig läuft, und der muß für die Inst. lokal Adminrechte haben.... HASS!!

Hallo Liste, ich habe ein kurioses Problem mit 2 Win2000DCs: Situation: 1. W2000-Server nach Crash neu als Domänencontroller aufgesetzt. 2. W2000-Server (bislang Mitgliedsserver) nach dieser Installation wieder in die Domäne augenommen und als 2. DC eingerichtet (ging problemlos) Auf beiden läuft ein DNS-Server, nach Augenschein sind die DNS-Einträge auch in Ordnung. Auf dem 1. DC ist eine DNS-Weiterleitung auf einen Linux-server eingerichtet. Benutzereinrichtung ging ohne Probleme, die Leute können sich auf Arbeitsstationen problemlos anmelden und bekommen ihre Laufwerke zugewiesen. Wo es klemmt: Wenn am DC (egal welcher) die Gruppenrichtlinien aufgerufen werden sollen, kommt Fehlermeldung: Der Domänencontroller für Gruppenrichtlinienvorgänge ist nicht verfügbar, Brechen Sie den Vorgang ab oder wählen sie einen anderen DC. Zur Auswahl werden angeboten: -Domänencontroller mit dem Betriebsmastertoken für die PCD-Emulation -Von den Active Directory Snap-Ins verwendeter DC -Verfügbarer DC Bei Auswahl von einem der beiden letzteren lassen sich die Gruppenrichtlinien auch bearbeiten. funktionieren tun sie allerdings nur teilweise (Einstellung Benutzerrechte ja, Softwareverteilung nein). Beide DCs sind im AD als DCs vorhanden. Auf dem 2. Server taucht im Systemprotokoll regelmäßig die Fehlermeldung auf: Netlogon ID 5719 Für die Domäne RGP ist kei Windows NT- oder Win 2000-DC verfügbar. Folgender Fehler ist aufgetreten: Das verwendete Konto ist ein Arbeitsstationskonto. Verwenden Sie ihr normales oder ein lokales Benutzerkonto, um auf diesen Server zuzugreifen. Angemeldet bin ich als Domänenadministrator, was auch ohne Probleme geht. Kann mir jemand helfen, wo ich ansetzen muß? Gruß Docmartin

Hallo Perin, Danke für die Tipps, Einstellungen habe ich kontrolliert, DNS auf dem Fileserver deinstalliert, neugestartet, trotzdem mault dcpromo noch mit "Zugriff verweigert" herum. Gruß Martin

Hallo, ich stecke im Zusammenhang mit der Einbindung eines zweiten Servers als Domänencontroller in den Tiefen der DNS-Konfiguration des ersten DC fest. System: Bislang ein Domänencontroller, W2k SP3, feste IP. DNS AD integriert. Unter TCP-IP-Einstellungen als DNS-Server die eigene IP des DC eingetragen. Domänen- und DNS-Name übereinstimmend rgp.local Zusätzlich DNS-Weiterleitung auf einen Linux-Kommunikationsserver eingerichtet, der den Internetzugang managt. Forward-lookupzone rgp.local hat die 4 Unterordner _msdcs, _sites, _tcp, _udp; dynamische Aktualisierung erlaubt. Server und Clients sind als Host eingetragen, der DC zudem mit SOA- und NS-Eintrag (identisch mit übergeordnetem Ordner...). Reverse-Lokupzone 192.168.0.x Subnet ist eingerichtet, dynamische Aktualisierung erlaubt. Dort sind Server und Clients (automatisch) eingetragen mit <IP-Adresse> - Zeiger - <name>.rgp.local. Der DC hat wiederum zusätzlich mit SOA- und NS-Eintrag. Aufruf von nslookup ergibt (auf dem DC und den Clients): Standardserver w2000dc.RGP.local, Adress 192.168.0.2, also soweit o.k. Aufruf von nslookup <name> oder nslookup <IP-Adresse> ergibt aber als Antwort "nslookup wurde von <name> bzw. <IP-Adresse> nicht gefunden: Non-existant domain" Was klemmt da noch? Die Anmeldung der Clients (W2k) inkl. Anwendung von Gruppenrichtlinien und Softwareverteilung klappt einwandfrei. Aber wahrscheinlich hängt es an diesen DNS-Einstellungen, daß es scheitert, den zweiten Server (W2k-SP3, bislang reiner Fileserver) als 2. DC einzubinden. Dieser ist gleichzeitig als sekundärer DNS-Server eingerichtet, wobei er sich ohne Murren die Informationen vom primären DNS-Server geholt hat. Der "Assistent zum Installieren von Active Directory" meldet trotz Angabe eines Domain-Adminkontos "Zugriff verweigert" - der Domain-Admin (und gleichzeitg Organisationadmin) sollte doch eigentlich berechtigt sein, einen zusätzlichen DC zu erstellen ?? Ratlose Grüße Docmartin

Hallo, der Tip mit nsllokup war gut, denn bei den DNS-Einstellungen scheint der Hase im Pfeffer zu liegen (da fehlt mir noch das entscheidende Know How). nslookup localhost ergibt : Der Servername f. 192.168.0.2 (die IP des vorhandenen DCs) konnte nicht gefunden werden: Non-existent domain. Die Standard-Server sind nicht verfügbar. Standard-Server: UnKnown Address: 192.168.0.2 nslookup w2000dc.rgp.local (der vorhandene DC) ergibt: Server: w2000dc.rgp.local Adress 192.168.0.2 nslookup wurde von w2000dc.rgp.local nicht gefunden: Non-existent domain. Bisherige DNS-Einstellung auf dem DC: forward-Lookupzone rgp.local, Typ AD-integriert. Keine reverse-lookup-Zone. Auf dem geplanten 2. DC: forward-lookup-Zone rgp.local, Typ sekundär. Keine reverse-lookup-Zone. Auf dem DC ist zusätzlich noch eine DNS-Weiterleitung auf einen Linux-Kommunikationsserver im selben Netz eingerichtet, der den Internetzugang der Clients besorgt. Ich nehme an, die fehlenden Reverse-Lookup-Zonen sind das/ein Problem?

Hallo, ich stehe vor dem Problem, daß ich einen zusätzlichen W2k-Server nicht als zusätzlichen DC in eine bestehende Domäne eingebunden kriege. Es existiert im Netz bislang ein W2K-DC, gleichzeitig primärer DNS-Server mit fester IP, der neue Server hat ebenfalls eine feste IP. Außerdem werkelt ein Linux-Server mit fester IP für den Internetzugang und als DHCP-Server für die Clients. Der "Assistent zum Installieren von Active Directory" meldet trotz Angabe des Domain-Adminkontos "Zugriff verweigert" - der Domain-Admin sollte doch eigentlich berechtigt sein, einen zusätzlichen DC zu erstellen ?? Als Ergebnis wird der Server nur als einfacher Mitgliedsserver in die Domäne aufgenommen, die Ereignisanzeige (Systemprotokoll) meldet die Fehler-IDs 5788 und 5789. Die englische KB schlägt zu diesen IDs vor, einerseits die DNS-Suffix zu checken, ob diese identisch mit dem Domänennamen ist (ist sie) und in den Gruppenrichtlinien für den vorhandenen DC zu prüfen, ob der Domänenadmin das Recht zum Zugriff auf den DC übers Netz hat (hat er auch). Laut deutscher KB (soll bei den Gruppenrichtlinien für den DC unter Computerkonfiguration-->Windows-Einstellungen-->Sicherheitsrichlinien-->Lokale Richtlinien-->Benutzerrechte das Admin-Konto unter "Computer und Benutzerkennungen, denen für Delegierungszwecke vertraut werden soll" hinzugefügt werden - nur ist dieser Eintrag auf dem DC gar nicht vorhanden!?! Any idea? Trotz allem frohe Weihnachten und ein störungsarmes 2004 Martin