Wordplex

OK, das Problem ist gelöst: auch hier hat das Patch KB3002657 das Chaos verursacht! Patch deinstalliert, DC neu gestartet und alles wieder im Lot!

Hallo, seit einigen Tagen habe ich urplötzlich auf einem einzigen W2008 R2 Terminalserver folgendes Problem: Wenn ich mich von meinem PC (Win7, 32Bit) per RDP (mehrere Versionen) auf einen Terminalserver 2008 als Domänenuser oder als Domänen-Administrator anmelden will, so bekomme ich den Hinweis: "...konnte keine Verbindung hergestellt werden." Im Ereignisprotokoll des TS finde ich den Hinweis: "Fehler beim Anmelden eines Kontos. Antragsteller: Sicherheits-ID: NULL SID Kontoname: - Kontodomäne: - Anmelde-ID: 0x0 Anmeldetyp: 3 Konto, für das die Anmeldung fehlgeschlagen ist: Sicherheits-ID: NULL SID Kontoname: Administrator Kontodomäne: XXXXXX Fehlerinformationen: Fehlerursache: Bei der Anmeldung ist ein Fehler aufgetreten. Status: 0xc000006d Unterstatus:: 0x0 ......" Jetzt das Merkwürdige: - In den Remote-Einstellungen des TS ist der Punkt: "...beliebige Version von RDP..." aktiviert - Der Fehler erscheint bei allen Win7- und Vistarechnern. - Von einem XP-Rechner klappt die Anmeldung problemlos; ebenso von Thin Clients (Igel) - Das Anmelden als lokaler Administrator oder lokaler User klappt von allen Rechnern Nun bin ich ratlos...

Hallo, ich bin auf ein merkwürdiges Phänomen gestoßen und kann es mir einfach nicht erklären: Umgebung: W2008R2, RDP, Remote Drucker werden über IP angesteuert Software: Word 2010, OO 3.4 Fonts: MS Verdana 5.01, 5.02, 5.03 ausprobiert Drucker: div. Kyocera und Brother, alle auf dem Server eingerichtet und via VPN-Tunnel mit den Filialen verbunden. Problem: wenn aus einer RDP-Session heraus ein Dokument gedruckt wird, so erscheint es ganz sauber - es sei denn, man benutzt Verdana Standard oder Bold. Diese beiden Fonts werden partout nicht ausgedruckt; alle anderen schon (auch Verdana kursiv und kursiv/fett). Die MA im LAN, die einen Fat-Client benutzen und die Drucker ebenfalls über den Server ansteuern, haben dieses Problem nicht. Auch wenn ich mich direkt an den 2008 setze und von dort einen Druckauftrag starte, ist alles ok. Dieses Problem konnten wir sogar nachstellen: wir haben extra einen frischen 2008 Server installiert und die Bedingungen bei uns nachgestellt: exakt das gleiche Phänomen. Da uns jetzt langsam die Ideen ausgehen: - neue Ideen? - wird Verdana irgendwie als ureigener W2008-Font interpretiert? Ich würde mich freuen, noch ein paar Hinweise zu bekommen!

Auf einem einzigen W2K3-Server (Standard) habe ich folgendes Problem: Wenn man sich an der Console oder per RDP bzw. als TS-Client anmeldet, erscheint unmittelbar nach Eingabe der Login-Daten ein hellblauer Bildschirm - mit "nix" drauf. Dieser Zustand dauert ca. 10 Minuten, danach erscheinen die Hinweise "Benutzereinstellungen ..." und "Computereinstellungen werden geladen". Ansonsten laufen alle Funktionen ganz sauber. Dazu ein paar Hinweise: - das Problem tauchte vor Jahren plötzlich nach Installation von SP1 auf - SP2 hat keine Besserung gebracht - die Wartezeiten sind user-unabhängig - während der Wartezeit hat der Server keinerlei höhere Auslastungen Und jetzt der Hammer: durch Zufall haben wir mal entdeckt, dass man die Wartezeit ganz locker durch "Strg-Alt-Ende" direkt beenden kann - die Session startet dann sofort. Mich intersssiert ganz einfach, ob jemand dieses Phänomen kennt und evtl. die Ursache dafür herausgefunden hat.

@counterooe, wenn ich das so lese, habe ich den Eindruck, dass da ein paar Lücken sind: - Als "Hotspare" bezeichnet man eine Platte, die sich von Anfang an im System befindet, quasi "leer" mitläuft und im Falle eines Versagens einer anderen Platte automatisch einspringt. Wenn Du vor dem Crash keine Hotspare-Platte im System hattest, kannst Du die neue zwar als Hotspare für einen zukünftigen Crash definieren, aber damit hast Du keineswegs einen Ersatz für die defekte Platte. - Ich kenne Deinen Raidcontroller nicht. Aber die grundsätzliche Vorgehensweise ist die: die defekte Platte aus dem Raidverbund nehmen und die neue Platte dem Verbund zuteilen. Manche Controller beginnen danach automatisch den Rebuild, bei anderen Controllern muss er manuell angestoßen werden. Und bei den ganz billigen muss der Rebuild gar im BIOS angestoßen werden (und der Betrieb fällt für einige Stunden flach). Ob Dein Controller automatisch einen Rebuild macht, wirst Du sehen, wenn Du die neue Platte dem Verbund zugeteilt hast: wenn der Verbund-Status dann nicht auf "Rebuild" steht, dann hast Du irgendwo die Möglichkeit, den Rebuild manuell anzustoßen.

Na, das ist doch mal eine Lösung, wie ich sie liebe - wenn sie denn hinhaut. :cool: Ich probiere das sofort mal aus! –----- Schade, hat leider nicht hingehauen....:nene: Aber dann habe ich denselben Schlüssel unter Office 12 gesetzt - Klasse! Hat geklappt! :jau: Maddes: das ist Nobelpreis-verdächtig! Allerbesten Dank! –------ Nachtrag: Die Änderung in der Registry ist Userabhängig und muss daher für jeden User gemacht werden - so weit, so gut. Merkwürdigerweise klappt es bei einigen (TS-)Usern sehr gut, bei anderen gar nicht - ich kann leider auch überhaupt keine Gesetzmäßigkeiten erkennen, wann es klappt und wann nicht. Gibt es in der Registry irgendwo einen Eintrag, der diesen neuen Key auf alle TS-User überträgt? Und eine zweite Sache ist mir aufgefallen: Excel hat das gleiche Problem, aber hier lässt es sich nicht so einfach aus der Welt schaffen, obwohl die Reg. ähnlich wie bei Word aufgebaut ist. Andererseits brauchen Access und PP nicht getunt zu werden - die haben einen ganz anderen Reg-Aufbau und machen keinerlei Probleme. Hat da noch irgendjemand eine Idee?

Das liegt außerhalb unseres Einflusses: es handelt sich hier um ein Praxisverwaltungsprogramm, das nicht einfach mal durch ein anderes zu ersetzen ist. Und der Hersteller weist darauf hin, dass er mit den permanenten ständigen Gesetzesänderungen im Gesundheitswesen derart ausgelastet ist, dass er mit den sich ebenfalls permanent ändernden Office-Versionen nicht mehr nachkommt..... So schiebt es der eine auf den anderen. Was kann ich als kleiner Ar.... ääähm Admin da noch ausrichten?

Danke für die schnellen Antworten! Ich hatte es schon befürchtet... Ich glaube, dass ich den Weg über einen zweiten TS nehmen werde, weil: weniger (Software) ist mehr!

Hallo, ich habe folgendes Problem: auf einem TS benötigt eine Applikation unbedingt Word und Excel 2000; mit neueren O-Versionen läuft eine bestimmte Applikation nicht (umfangreiche Makros). Eine andere Usergruppe benötigt Office 2007. Beide Versionen konnten auch problemlos auf dem TS installiert und genutzt werden. Das Problem ist nun: als Admin kann ich entweder 2000 oder 2007 als aktives Paket angeben. Die jeweilige andere Gruppe erhält regelmäßig beim Start die bekannten Hinweise "Office nicht richtig installiert", kann danach aber sauber mit dem Paket arbeiten. Als Admin kann ich natürlich die Installation "korrigieren", indem ich die Installationsroutine durchlaufen lasse; aber dann hat die andere Gruppe das Problem der permanenten Hinweise. Hat jemand dafür irgendeine Lösung?

Hallo Wordplex, >>welche Fehlermeldung bekommst du beim Verbindungsversuch ?<< Keine - es erscheint die Anmeldemaske, man kann sich einloggen, die Maske verschwindet und das war's. Der Bildschirm bleibt hellblau. >>Laufen die Server im aministrativen oder Anwendermodus ?<< Sowohl als auch. Hat damit nichts zu tun. >>Wurde der Punkt Systemeigenschaften -> Remote -> Remotedesktop kontrolliert ?<< :confused: Du meinst, ob der Remotezugriff freigegeben ist? :D Da bin ich mir sehr sicher, denn: - der Zugriff via RDC klappt von unserem W2K3-Server auf den Kundenserver sauber - von einer x-beliebigen unserer XP-Arbeitsstation aber nicht - der Zugriff auf rund 50 andere W2K, W2K3 und ältere W2K3-R2 - Server ist alles ok. Nur auf die neuen W2K3-R2 eben nicht...:shock: Fazit: VPN sauber, Verbindungen sauber, aber irgendwelche Versionsänderungen auf den W2K3-Servern...???

Hallo, wie kann man bei W2003 feststellen, welche TS-Version läuft? Unter W2000 wurde als Dienst noch termsrv.exe gestartet, so dass man die Version direkt aus der Datei erkennen konnte. Unter 2003 wird jedoch nur svchost.exe mit der Option "termsvcs" gestartet - die Version ist so nicht direkt erkennbar. Irgendeine Idee? Hintergrund der Frage: irgendetwas muss sich geändert haben, da wir bei allen zuletzt ausgelieferten W2003-Servern über einen VPN-Tunnel keine RDC-Sitzungen mehr aufbauen können (alles andere läuft im Tunnel problemlos).

Auf jeden Server gleich die Enterprise Edition draufzuknallen ist aber auch nicht gerade der Weisheit letzter Schluß.... Eher würde ich sagen: "Selbst die klügste Henne sch... mal ins eigene Nest!" <selbstindenhinterntretend> (oder auch: "Vertan, vertan!" sprach der Hahn und stieg von der Ente...)

Danke für den Tip! Aber bei ca. 100 Clients a) wäre mir das Risiko bei der Umstellung viel zu groß b) habe ich schon gelernt, dass SBS max. 75 Clients handeln kann! :) Trotzdem: Danke für den Tip! P.S.: 2003 SBS R2 billig abzugeben.... :jau:

Besten Dank für Eure schnelle Hilfe! (Kleine Ursache - große Wirkung... ich lass' die Finger in Zukunft vom SBS!) Nochmals allerbesten Dank!

Glauben..? Klar glaube ich Euch - sonst würde ich Euch ja nicht fragen :) ! Nur die Antwort gefällt mir nicht sonderlich :D - ich glaube, Gulp hat Recht: "Da würde ich sagen falsches OS für die Aufgabe herausgesucht ....... " Sch...! Dann also 2003 Standard oder doch besser wieder XP..... Noch eine Abschlussfrage: kann man denn einen 2003 Standard R2 Server als Mitglied in eine bestehende Domän packen?

Sorry - der 2003SBS R2 soll nicht als Domänencontroller, sondern lediglich als Mitglied in einer 2003 Standard-Domäne laufen. Das müsste doch wohl möglich sein, oder?

Hallo, ich habe bei einem Kunden ein etwas merkwürdiges Problem, für das ich i.A. keine Lösung habe: - Kunde hat ein Domäne mit einem 2003 Standard-Server - ein bisheriger PC mit dem Namen "DATEV" hat seinen Geist aufgegeben und wurde durch ein neues Gerät ersetzt - aus verschiedenen Gründen wurde dieses neue Gerät als Server konzipiert und mit 2003 SBS R2 ausgestattet und sollte eigentlich als einfaches Mitglied in die Domäne gesetzt werden. - Gerätename, IP-Adresse etc. sind identisch mit dem der alten Hardware Und nun das Problem: Der neue R2 kann nicht als Mitglied in die Domäne aufgenommen werden: jedes Mal erscheint die Meldung: "Es konnte keine Verbindung mit einem Domänencontroller für die Domäne "XYZ" hergestellt werden. Stellen Sie sicher, dass der Domänenname richtig vergeben wurde...." Was bisher geprüft wurde: - der Domänenname ist (-zigmal) überprüft worden - der Domänencontroller kann sowohl über die IP-Adresse als auch über den Gerätenamen angepingt werden (also vermutlich kein DNS-Problem) - der alte Computername wurde manuell am Domänencontroller aus der Liste der Computer gelöscht; damit dürfte einem Neueintrag nichts im Wege stehen Könnte es damit zusammenhängen, dass R2 ein erweitertes AD hat? Das würde doch eigentlich nur eine Rolle spielen, wenn ich diesen als zweiten Domänencontroller o.ä. laufen lassen wollte; aber als einfaches Domänenmitglied? Es würde mich freuen, wenn mir jemand mit ein paar Ideen helfen könnte...

Hm, Ideen hätte ich genug: - SCSI-Controller tauschen - SCSI-Kabel tauschen - Controller+Kabel+Terminator+Tape in anderen Rechner packen und testen Nach Deiner Schilderung (Laufwerk getauscht) glaube ich nicht, dass es an diesem oder einem Tape liegt. Und SCSI-Fehler melden sich "normalerweise" mit Timeouts. Ich tippe entweder auf eine Inkompatibilität (oder falsche Einstellung!) zwischen Controller und Laufwerk oder ein banales Kabelproblem - aber das kann man nur durch Tausch der einzelnen Komponenten herausbekommen...

Hallo, was erwartest Du? Einen Disassembler, der Dir gleich die Bedeutung eines veränderten Hexcodes anzeigt? Da kannst Du lange warten...:D Aber ich glaube, dass das gar nicht die Frage ist. Interessant ist, ob sich die Datei tatsächlich von der Originaldatei unterscheidet. Und wenn, dann kopiere die Originaldatei zurück, setze ein R-Attribut drauf und warte, bis sie erneut geändert werden soll: dann wird es höchstwahrscheinlich eine Fehlermeldung geben, aus der Du - mit ein bisschen Aufwand - das ändernde Programm herausbekommen kannst; ggf. auch über die Ereignisanzeige.

... noch so'n oller NW-Freak! :D Das darfst Du hier nicht so laut sagen, sonst wirst Du noch ins NW-Forum verbannt! :p

@Loki-123, ok, Du musst ja nun auch nicht unbedingt gleich NCE werden.... Aber Deine Vista-Kiste solltest Du problemlos drankriegen; schlimmstenfalls werde ich Dir schon helfen... @Gulp, das ist korrekt! Aber ich gehe mal davon aus, dass es hier nicht unbedingt um Schnelligkeit, sondern um die Anbindung an sich geht.

Marke "Fred Feuerstein"? Kenne ich nicht - dafür aber die Versionen 2.x, 3.x, 4.x, 5.x Ab V 4.x kannst Du auf dem Server das TCP/IP-Protokoll laden (LOAD TCPIP) und schon sollte es mit Vista zusammen laufen... und zwar ziemlich problemlos.

Hm, einfach und geschmacklos und ziemlich unlogisch - aber es klappt! :) Allerbesten Dank! P.S.: Das passiert mir auch selten: jetzt habe ich eine zwar Lösung, aber keine Erklärung dafür.... P.P.S.: Den "lh" oder "loadhigh" scheint es unter Vista nicht mehr zu geben, trotz standardmäßig geladenem HIMEM.SYS

Wir haben zwei Vista-Testrechner (jeweils mit aktuellen Patches), mit denen wir verschiedene Programme testen. Dabei sind wir auf folgendes gestoßen: Direkt in der DOS-Box (Eingabeaufforderung) ist das Tastatur-Layout deutsch. Wenn nun irgendein DOS-Programm gestartet wird (Edit, Edlin oder div. Applikationen), ändert sich das Tastaturlayout auf englisch. Nach dem Verlassen der Applikation ist wieder das deutsche Layout aktiv. :shock: Hat jemand dafür eine Erklärung oder gar eine Lösung?

Hat denn niemand eine Lösung oder zumindest eine Idee für mein Problem? (Außer den Server neu aufzusetzen....)