Jim di Griz

"Beim Versuch der Domäne xxxxx beizutreten, trat der folgende Fehler auf: Der angegebene Server kann den angeforderten Vorgang nicht ausführen. Welche eventid hat dieser Fehler im Eventlog des Servers oder clients und welcher errorcode wird hierzu ausgegeben?

ist zwar ein bisschen offtopic aber wenn ich dem angegebenen link folge komme ich auf ein partnermigrationstool. obwohl ich eine live-id habe die bereits einem partneraccount und einer MCP-Nummer zugeordnet ist. die links auf dieser seite erhöhen dann eher die verwirrung als das sie den unwissenden behutsam leiten :p

wo findet man denn den activation code den man zur mcp-id benötigt?

Eventuell mal unsecure updates für DNS-Adressen erlauben für einen Test, mir fällt aufdas der Fehler einmal jeden Monat auftritt, gibt es einen DHCP-Server im Netz mit 30 Tagen lease? der zufällig seit 2 monaten weg ist oder fehler bringt? Ist kerberos in der domäne aktiviert? evtl. mal den Start des Netlogon-Dienstes vom DNS-Start abhängig machen. bezüglich der Fehlermeldung: "Fehlerwert: Ein Socketvorgang konnte nicht ausgeführt werden, da dem System Pufferspeicher fehlte oder eine Warteschlange voll war." diese Fehlermeldung wird bei eventid nicht behandelt zu diesem event, wird allerdings bei anderen Fehlern (USERENV wars meine ich) mehrfach erwähnt, gibt es weitere Fehler im Eventlog?

naja, stimmt doch irgendwie, 4 von den 7 hab ich durch und nach 10 jahren helpdesk/kommunikations/kabeläffchen-dasein kann ich dem helpdesk-teil nur zustimmen: es nagt doch ein wenig ueber die jahre. und gutes geld macht man auch noch

Ist ein neues Protokoll in den Netzwerkeigenschaften der Servernetzwerkkarte installiert worden? Ist unter den Authentifizierungseigenschaften der Netzwerkkarte alles so eingestellt wie bei den Clients (Smartcardauthentifizierung nach iee sonstwas?) Wenn es sehr viele Fehler sind : die eventids mal von unten nach oben auf EventID.Net abarbeiten

JO, schon klar. ich habe hier einen VMWareserver. der Host ist 64 bit, der Rechner hat 6 GB. eine Beispiel-VMWare Maschine ist 64 bit und hat 2 GB. davon laufen drei auf dem Rechner (nur als Beispiel). Der Prozess auf dem Host der die VMWare-Maschine darstellt hat jedoch 32bit Da kommt doch die Frage auf: Was passiert wenn der auf dem Host genutzte Speicher 4GB erreicht? der Prozess in dem die VMWare läuft kann nicht mehr als 4 GB adressieren während die VM selber ueber 4 GB adressieren koennte. Was ich bemerke ist, das es ab 4 GB belegtem Speicher doch schon langsamer wird, vor allem wenn noch andere Speicherintensive Prozesse auf dem Host direkt laufen Anyway: nach dem Starten der VM wird sowieso nur der Speicher auf dem Host belegt den die VM braucht (und nicht der als maximum definierte Bereich) so das es also in einer "mal-ausprobieren-Umgebung" wohl kaum Probleme gibt.

ich glaube 32 bit prozesse auf dem Host koennen nur 4 GB adressieren, wie sich das dann verhaelt wenn Host-Prozesse an diese Grenze kommen weiss ich nicht

die VMWareserver Version 1.0 ist umsonst. unterstuetzt aber z.b. kein usb 2.0, das ist dann in der ws version. leider laufen die vmserver-maschinen zwar intern mit 64 bit, sind aber 32 bit prozesse auf nem 64 bit host, damit max 4 GB. im sommer diesen jahres soll vmware server 2.0 kommen der die angesprochenen punkte aendert. Allerdings aendert sich dann auch die vm-konsole, in der beta von vmwareserver 2.0 ist die eigentlich kaum nutzbar

vermutlich ist im Protokoll http der applikationsfilter nicht mehr angeklickt waere mein tip nachdem ich dasselbe mit rpc hatte

Die Reg-Changes sind vorhanden (BPA hatte ich auch schon mehrfach verwendet, die Settings stimmten seit Installation ), die Networkbindings "sollten" auch stimmen, werd ich aber mal aendern um es auszuprobieren. Vielen dank für den Hint

Der ISA Server ist ISA 2006. Microsoft ISA Server 2006 © 2006 Microsoft Corporation. Version: 5.0.5721.240 Ich bin jetzt mehrere lange Tage dabei ein paar Protokolle zu erstellen/zu testen. Dazu folgendes: das mitgelieferte RPC-Protokoll (all interfaces) hat keine secondary connections definiert. erstelle ich ein RPC-Protokoll mit secondary connections wird mal das eine mal das andere erkannt wenn ich beide verwende. Wenn ich nur zum Testen einen RPC-Server (also einen DC) publishe erkennt ISA ohne Probleme die RPC-UIDs der Server, warum kann er denn dann nicht sauber routen? Aber beide verhalten sich wie das Ventrilo-Protokoll das ich auch noch fertigmachen muss: egal welche Settings ich für secondary connections verwende: ISA 2006 erkennt die secondaries zu 99% als unidentified traffic, auch nach reboot um die bestehenden connections zu resetten. Alle Rechner sind MS-updated bis nichts mehr geht und haben soweit weisse eventlogs. Auf dem ISA ist nur der ISA, keine Fremdsoftware. auf dem "virtuellen PDC" ist auch nichts drauf. DIe CDs zur Installation sind Action Pack-CDs mit gültigen Serials So wie es momentan aussieht bekommt der ISA-Server kein Zertifikat weil er feststellt, das beim Abarbeiten des AD-Zertifikatsrequests keine RPC-Endpoints vorhanden sind, damit schlägt dann die GPO-Verarbeitung fehl. Der ISA-Server bekommt ja auch keine IP-Sec Verbindungsparameter bisher, soweit also erstmal alles zummindest irgendwie stimmig. hm, nachdem die DCs sich prächtig miteinander verstehen werd ich wohl den ISA nochmal neu machen müssen, mal sehen obs hilft..... snipp on By the way: IPsec zwischen den DC ist wie erwähnt nur eine Lösung. Da du ja das Problem mit dem ISA isoliert hast, versuch's doch zu lösen (z.B. aktuellstes SP einspielen welches den veränderten RPC-Call versteht??). snipp off ALLE Maschinen hier sind updated to the max, also alles was ueber MS-Update kommt und ALLE sind installiert von Original-CDs. ich suche schon eine weile zum thema, welcher patch oder hotfix fehlt denn hier? und warum ist sowas essentielles nicht ueber MS-Update erhaeltlich?

Polemik gegen eine Maschine, nicht gegen Personen, wer sich den schuh anziehen will nur zu die einfache Antwort: muss ueber IP-Sec "getunnelt" werden haette mir viel Zeit gespart. Und Polemik ist durchaus angebracht wenn sich die Dinge verhalten wie bei RPC und wenn sich ISA verhaelt wie es sich verhaelt. NUr 2 Anmerkungen: mit SP1 WIndows server 2003 wurde der RPC-Stack geändert, danach war kein "firewallen" von RPC-Verbindungen mehr möglich. Laut meinem BPA zum isa soll ich wegen: "To allow non-strict RPC traffic, expand the Firewall Policy node, right-click the rule Allow Private Subnet Traffic to DCs, click Configure RPC protocol, and clear the Enforce strict RPC compliance check box" würde ich auch gerne tun, leider ist da kein Auswahlfeld (auch nicht nach reboot des ISA und Neuerstellen der Regel.... (weil der Haken schon in den Systemregeln entfernt wurde?) das alles kostet sinnlos zeit und ist keineswegs angenehm, ein wenig fluchen durchaus angebracht. und zum Problem: unter allen Dokumenten war eines dem ich gefolgt bin, Einrichten einer IP-Sec Verbindung um RPC-Regeln auf der Firewall zu umgehen. Notwendig ist hier dann entweder eine CA oder eine Verschlüsselung per Scheinzertifikat die jeder lesen kann. Also aktuell repliziert alles. Das naechste Abenteuer ist aber schon in Sicht, alle Rechner der Domäne bekommen inzwischen zertifikate die ich beglaubigen muss, nur der ISA-Server fragt nicht............

hm, ok, also portqry bringt mir inzwischen von jedem server die am rpc-locator anliegenden eintraege. Im selben Subnetz kommt es zu spontaner replikation. am dynamischen Zuordnen knusper ich noch ein wenig rum, die feste zuordnung einzelner ports funktioniert schon einmal, die empfehlung ueber VPN zu tunneln find ich sehr ernuechternd. ehrlich gesagt so wahnsinnig ungewöhnlich finde ich das ganze Konstrukt (Firewall zwischen Internem Netz und Perimeternetz) nun auch nicht, ich quäl mich mal weiter durch die recht umfangreiche Doku für die ich mich nochmals bedanken möchte. hätte nur noch die Frage ob ich korrekt verstanden habe das sich nur fest vergebne Ports ueber die Firewall erreichen lassen und ob es notwendig ist die Server im ISA zu publishen?

ich weiss nicht ob ich da nem mythos auf den leim gegangen bin. vernünftig monitoren laesst sich das ganze nur wenn von vornherein alles was mit netbios beginnt (session name service und datagram) geblockt wird, da die drei selbst ohne effektiven datenaustausch jedes log zuspammen. ich sehs eher so, das die altlasten eigentlich schon laengst weg sein sollten, komischerweise kann jedoch windows ohne netbios plötzlich nicht mehr richtig. anyway, vielen dank für die hilfe, das mit der fehlenden aktivierung war wirklich gestern das sahnehäubchen.... für so einen Mist zahl ich natürlich gern die lizenzgebühren würg

lol, nein es liegt nicht am verstaendnis... und ja, schoenes monitoring, wie geschrieben lief der joindom auch ueber die isa2004-firewall, mir ist nicht ganz klar warum die replikatiuon dann scheitern sollte oder doch, ich verstehe z.b. nicht, warum rpc-verkehr von dc1 auf dc2 als rpc erkannt wird und analog der regel durchgeroutet wird waehrend der verkehr von dc2 zu dc1 auf port 135 als "unidentifizierter traffic" geblockt wird. mir ist ganz grundsaetzlich nicht klar, warum alle naselang die alten netbios-ports mit den lustigsten verrenkungen benoetigt werden obwohl doch alles im schoenen neuen windows ldap und tcp/ip-basiert ist. ich weiss jedoch imzwischen warum ich nen 2ten dc wollte, der alte ist grad heut mit der meldung ausgefallen das windows die activierung nicht ueberprüfen koenne....nach 1 jahr problemlosem betrieb. und wie schoen, das dann nicht mal mehr ein reparaturlogin moeglich ist (im abgesicherten modus ...lol) interessant war auch, das das tolle porttool mit dem einen dc im anderen subnetz feststellt, das der port 135 gefiltert wird. als beide im selben subnetz waren lief die replikation plötzlich, obwohl der portreporter meldete, das kein rpc-port auf keinem servern offen sei. ohne firewall und virenscanner. aber gut, aktuell habe ich einen halben dc der neu aufgesetzt werden muss dank einer ueberraschend fehlenden aktivierung und der daher noetigen emergency-reparatur und einen 2ten dc der so nuetzlich ist wie ein kropf. was bin ich froh das ich so einen haufen muell nicht produktiv im einsatz habe, danke für die hilfe soweit, neu aufsetzen den dreck ist wirklich um laengen schneller als sich um sowas noch lange gedanken zu machen

ajo, danke für die tools, mit denen ich mich dann in den nexten tagen auseinandersetze. sehr schoenes portlogging bisher, es gibt immer mal wieder verbindungen auf allen möglichen ports zwischen den DCs (auch auf port 135 z.B.) ich setz denn alles mal aufs selbe subnetz und les mich satt an den kruden portbeschreibungen von ms

ja, eventid.net kenne ich. was mir fehlt ist die uebersetzung der offenen ports in ms-firewall-sysntax. da bleibt ja dann eigentlich nur DC-DC alle ports oeffnen und so sieht die firewall gerade auch aus. keine Aenderung am fehler. erklaert doch alles nicht, warum das problem existiert selbst wenn beide DCs sich im selben subnetz befinden und wieso die datei netlogon.dns nicht lesbar ist (obwohl sie beim systemstart jeweils modifiziert wird)

Ich habe einen bestehenden und seit Jahren funktionierenden DC. Aus Gründen der Redundanz gibt es einen neuen 2ten DC in derselben Domäne. Der 2te neue DC ist ein "virtueller" DC auf einem anderen Rechner (Server) in derselben Domäne. Das Netzwerk ist Host-Only (so soll es mal sein) oder eben direkt bridged im physikalischen Netz. Der Fehler wie oben beschrieben tritt nur auf dem neuen DC auf, dieser hat Probleme beim Erkennen der DNS-Settings der Domäne. Diese Probleme existieren nicht auf dem ersten, älteren DC. Kurz: Die Datei netlogon.dns wird nicht in den dns-server des neuen DC integriert (sie wird nicht abgearbeitet). DNS startet zwar auf dem neuen Server und zeigt auch alle eintraege der domäne korrekt an. Leider ist der neue Server dann nicht in der Lage, sich selbst als DC in diesen DNS-Eintraegen wiederzufinden, es ist eher ein logisches Problem als ein Netzproblem (es sei denn die Netlogon.dns datei kann nicht vom ersten älteren DC gelesen werden wenn der neue DC startet). Die Gruppenrichtlinien werden z.B. ohne Probleme korrekt auf beiden DCs angewendet. und der fehler macht mich langsam jeck weil ich seit mehreren Tagen Boardbeitraege wälze die mir zwar sagen wie der fehler aussehen kann aber leider nicht den kleinsten hinweis wie man ihn wieder loswird. Klar ist Neuaufsetzen da kürzer, allerdings hab ich schon ein bisschen ehrgeiz inzwischen rauszufinden was da stört

DNS Problem w2k3 - Seite 3 - Forum Fachinformatiker.de ist exakt mein Stand in dieser Sache: die Datei NETLOGON.DNS kann nicht gelesen werden und es gibt keine NETBT-Eintraege (die Datei existiert und hat vernünftig aussehende Einträge, wurde beim Systemstart geändert) Auch den obigen Beitrag hab ich komplett abgearbeitet, alle Fehlerbilder sind 1 zu 1 wie bei mir. die DCs können sich pingen und gegenseitig auf ihre netzlaufwerke zugreifen. AD-Administrationstools Zugriffe sind problemlos nach allen Seiten möglich. Nur repliziert wird zwischen beiden nicht. Eventid 13508 "the file replication service is having trouble......using the DNS"

Hallo, danke für die Antwort. den triftigen Grund gibt es: Abbilden meiner alten physikalischen Domäne in einer reinen VMWare-Umgebung. Funktionieren bedeutet, das Zugriffe auf Daten ueber username/Passwort funktionieren. Das jedoch domänen so aussehen als seien sie in Ordnung bis es dann doch mal hakt ist ja nichts neues. Warum abreissen? weil ich seit 2 Wochen immer dieselben Artikel zu RPC-Problemen lese ohne das sich an der Situation etwas aendern liesse. Die Firewall ist inzwischen zwischen den 2 DCs völlig offen, keine Aenderung. Auch wenn die beiden DCs im selben Subnetz sind gibt es keine erfolgreiche replikation. und was soll an dem konzept mit dem isa dazwischen so anrüchig sein, ein altes physikalisches Netz das vom neuen virtuellen netz durch eine firewall getrennt ist..... wirklich nichts dolles. joindom funktionierte auch ueber die firewall. und bitte, das ist alles mikrosoft. man sollte erwarten koennen das eine ms-firewall netzverkehr zwischen 2 ms-dcs transportieren kann OHNE das ein doktortitel noetig ist Das problem ist eher einer der vielen wunderbaren reg und dns-eintraege die beim promoten angelegt werden, irgendetwas fehlt. ich les die artikel einfach nochmal, teste alles nochmal, poste mal die errorausgaben so vorhanden, vielen dank soweit

Hallo, ich habe 2 DCs in 2 Subnetzen, dazwischen ist ein ISA 2004. ping usw. funktionieren, joindom ebenfalls. alles wunderbar, leider laesst sich der 2te dc nicht mehr aus der domain entfernen, fehler "1722, der rpc-server ist nicht verfügbar". nachdem ich nun seit 2 wochen irgendwelche hinweise zu diesem fehler suche die anfrage ans forum: was bedeutet diese fehlermeldung? und wie werd ich die wieder los ohne die ganze verdammte domaene abzureissen und neuaufzubauen?

ich spiel an meinem vmware rum, ris-server hab ich bisher nicht im einsatz (obwohl er wirklich ne tolle sache ist). daher nur mal die vermutung: die rechte sind korrekt gesetzt und das ris-image ist auf einem pfad der aus dem netz erreichbar ist?

hm, bei mir ist der (wenn auch selten) kaputt gegangen durch fehlerhafte Hardware (installation läuft durch aber die platte ist defekt z.b.) oder solche dinge wie treiberwechsel, oder auch ausschalten waehrend der rechner intensic irgendwas auf platte auslagert und aehnlichen Kram (mein speicher soll hotswap sein steht drauf :)) ich bin aber nicht zertifiziert und damit nur ein art computerlandwirt. wenn das tcp-ip protokoll jedoch mit einem solchen fehler abstürzt hast du bestimmt mehr als nur ein einziges problem auf dem rechner. ob das neuinstallieren hilft kann man so nicht sagen, aber viel kanns hier nicht mehr schaden.

uebel sieht das aus, wenn der tcp/ip stack schon defekt ist ist wohl ein bisschen mehr im argen. manchmal hilfts tcp-ip als protokoll zu entfernen und neu zu installieren, danach sind aber evtl. ein ganzer haufen systemdienste neu zu installieren wenn mir so ein rechner begegnet würde ich ihn neu aufsetzen und hoffen, das die hardware keinen schaden hat und das die installation durchläuft.