Shao-Lee

Hi - das Vorhalten von DC's an den Außenstellen kommt bereits aus Kostengründen nicht in Frage. Dies war auch der Grund, weshalb wir draußen keine eigenen Netzstrukturen aufbauen wollten, sondern uns für den Weg einer "flächendeckenden Integration" entschieden haben. Nächste Woche weiss ich, ob die Maßnahme auch "flächendeckend" greift. Bis jetzt konnte ich es nur sporadisch an 2 Clients testen. Herzlichen Dank nochmals an Alle für Euer Feedback :D Und ja: MS ist cool - schafft es aber immer wieder, dass der Admin anfängt, an sich selbst zu zweifeln ;) In diesem Sinne wünsche ich Euch weiterhin auch viel Erfolg ! Machts gut, Tapio aka Shao-Lee

Hi ! Die Außenstellen sind alle in separaten Subnetzen untergebracht; Router und DSL-Modem übernehmen den Verbindungsaufbau, ect. :-)

YUHUU - ich denke, so langsam kommen wir dem Problem auf die Spur ! Status-Update: Ich habe jetzt einmal die beiden Gruppenrichtlinien "Erkennung von langsamen Verbindungen" aktiviert. Ergebnis => 2 User haben nach erneuter Anmeldung die IE-Settings übertragen bekommen ! Was ich auch noch getestet habe, ist, dass die fehlenden IE-Settings nach der Eingabe von => secedit /refreshpolicy user_policy an den Client ebenfalls erfolgreich übergeben wurden; und zwar im laufenden Betrieb. Lösungsansatz: Die aktualisierten GPO's lasse ich jetzt erstmal so laufen; weitere Anbindungen erfolgen. Frage: Spricht etwas dagegen, dass ich diesen Befehl in mein Logon-Script mit aufnehme, dass jeder User beim Systemstart automatisch ausführt ? Somit wäre ja gewährleistet, dass die User nach jeder Anmeldung mit den aktuellen Richtlinien verbunden sind. Außerdem könnte ich hierdurch Probleme durch mögliche fehlerhafte Übertragungen vorbeugen. Der Client zieht sich dann halt 2x den Richtliniensatz. 1x über die Windowsanmeldung; 2x über das Script. Ist das ein Problem ? Zu unserer VPN-Verbindung: Wir nutzen Standard-DSL-Anschlüsse (1000er bzw. 2000er) incl. erhöhtem Upload. Unsere Zentrale ist mit einer 2000er sync. Leitung ausgestattet. Ping-Zeiten sind zwar langsam, aber akzeptabel.

Status-Update: Wenn ich den externen Client bei mir ins interne Netzwerk hänge und sich der besagte Benutzer anmeldet, werden die Gruppenrichtlinien korrekt übertragen. Transportiere ich nun anschließend den Client in die Außenstelle und meldet sich der Benutzer dort erneut an, sind die fehlenden Settings enthalten. Dies hängt damit zusammen, dass sich die GPO in das lokale Benutzerprofil des Clients schreiben und nach einer erneuten Anmeldung von dort gelesen werden. Fragen: 1.) Werden Gruppenrichtlinien bei geringer Bandbreite "beschnitten" oder erst garnicht übertragen ? Gibt es ein Setting für eine mögliche Bandbreitenregelung unter Windows bzw. für die GPO's ? Ich habe sowas ähnliches in den GPO's für die Videoübertragung gefunden. 2.) Gibt es die Möglichkeit, die Übertragung der GPO's an die Clients "zu erzwingen" ? Die "Loopbackverarbeitung" gilt - wenn ich das richtig verstanden habe - lediglich für die Terminalserverlösungen. Ich werde folgendes Testen: a.) Neue GPO nur für die Außenstellen, um zu testen, ob da überhaupt was übertragen wird b.) Replikation der Richtliniensätze auf unseren DC's checken (auf jedem DC das AD aufrufen und Gruppenrichtlinien auf vollständigkeit überprüfen - ist das korrekt ?) Grüssle, Shao

- Betrifft das Problem alle Benutzer am Remotestandort oder nur einzelne? Betrifft alle 10 Clients - Das GPO auf dem DC02 ist identisch wie das auf DC01 (Versionsnummer, Dateien, etc.)? Das GPO ist in unsere Domänenstruktur (AD) eingetragen und wird an alle DC's repliziert. Ich schaue mir das aber nochmals ganz dediziert an. Versionsnummer ? Muss ich prüfen. Wo sehe ich die ? - Läuft auf den Clients besondere Software, z.B. eine Novell-Client? Nein, lediglich: - Windows 2000 SP4 - Office 2000 - IE v6 - Telnet-Anwendungen - Hänge doch mal bitte die in eine Textdatei umgeleitete Ausgabe von gpresult /v hier an deinen nächsten Beitrag an. Bin nachher nochmals draußen und organisiere das. Von den Servern auch ? Machts gut, Tapio aka Shao-Lee

Hallo Grizzly - kein Problem, ich fasse Deine Fragen kurz zusammen :D Vielleicht ergibt sich hieraus auch ein neuer Lösungsansatz - wünschen würde ich mir es zumindest Die Proxy-Settings und IE-StartseiteEinstellungen befinden sich in der GPO "GPO Domain Standort"? - Im AD gibt es als übergeordnetes Objekt die Domäne mit Bezeichnung "Rathaus.Standort.de" -> Dort ist die "Default Domain Policy" <= Die haben wir unberührt gelassen. - Unter der Domain (neben Builtin, Computers, Domain Controllers, ...) haben wir ein neues OU erfasst: "Rathaus". -> Dort ist die Gruppenrichtlinie "GPO Rathaus Standort" eingetragen <= mit den speziellen Settings Unter dieser OU haben wir dann alle weiteren Abteilungen / Benutzer strukturiert angelegt. In dieser GPO gibt es noch weitere Einstellungen? Geregelt sind: - Internet Explorer Wartung: -> Verbindung => Proxy-Einstellungen (Unsere Proxy-Settings mit den Ausnahmen) -> URL's => Wichtige URL's (mit der Startseite) - Administrative Vorlagen: -> Internet Explorer => Änderung der Proxyeinstellungen deaktivieren => Aktiviert Diese weiteren Einstellungen werden aber übernommen? Am externen Client sind die Proxy-Settings (wie in der GPO eingestellt) deaktivert. Aber: -> Die Startseite wird nicht übergeben (Microsoft-Standardseite kommt) -> Die Proxy-Settings sind alle leer (aber Einstellungen sind deaktivert !) Ein DNS-Problem dürfte ausscheiden, sonst gäbe es gar nix an GPOs. Warum funktioniert bei den hausinternen Clients die GPO vollständig; ... Nehme ich den Client von der Außenstelle zu mir ins Rathausnetz (vergebe ihm also eine interne IP und melde mich als Domäne-User an) werden die GPO-Einstellungen vollständig übertragen). - Die Proxyeinstellung wurde unter Benutzerkonfiguration\Windows-Einstellungen\Internet Explorer-Wartung\Verbindung\Proxyeinstellungen vorgenommen? Genau => allerdings nicht in der obersten Default Domain Policy, sondern eine "OU" unterhalb, jedoch AD-Strukturenübergreifend (siehe oben). -Es wird nicht noch an anderer Stelle was mit den Proxy-Settings herumgemacht, Stichwort Firewall-Client vom ISA, Autodetect Proxy o.ä? Gute Frage; expliziet definiert ist auf jeden Fall nichts. Der ISA hat lediglich bei uns die Aufgabe, Internetanfragen anzunehmen, sie ans Web weiterzuleiten und wieder dem Client zuzuschicken. Firewalling ist nicht aktiviert; Unter "Interne Netzwerke" habe ich die komplett neue IP-Range xxx.xxx.124.0-255 freigeschaltet. Müsste ich die Einzelnen Netzwerksegmente dort eintragen ? (Jeder Standort hat aus diesem Netz ein eigenes Segment erhalten). Wenn etwas mit dem ISA-Server falsch liefe, müsste doch eine Fehlermeldung kommen wie: - Proxy nicht gefunden; - Zugriff verweigert... Aber der Proxy selbst in den IE eintragen ist ja erstmal unabhängig vom ISA, oder ? - Die Startseite wird auch nicht übergeben, oder nur ein einziges mal? Nein, diese wird erst garnicht eingetragen :-( - Die Startseite kann geändert werden? Ja; ist bei unseren hausinternen Clients aber genauso. - Welche anderen PolicySettings sind in dieser Policy drin? => Administrative Vorlagen => Proxy Settings deaktivieren (ist aktiviert) - Sind für den IE weitere Einstellungen in dieser Richtlinie unter Benutzer oder auch Computer drin? Nein.

Kleine Aktualisierung: Ich habe mir die USERENV.LOG angeschaut - diese geben aber auch keine Hinweise auf mein besagtes Problem. Es sei noch erwähnt, dass die LOG-Dateien älteren Datums sind (Juni / unbedeutend jünger oder älter); aber ich mit dem Problem ganz aktuell seit knapp einer 1,5 Woche kämpfe. Ich steh' jetzt ehrlich gesagt mit dem Rücken an der Wand & zweifle an mir selbst. Wenn jemand noch eine Idee hat, hätte ich die herzliche Bitte, diese hier hineinzuposten. Ich gehe Ende dieser Woche mit einem externen Techniker das Problem nach dem "4-Augen-Prinzip" nochmals an. Ich vermute weiterhin, dass ein DNS-Problem dahinter steckt; weil der übrige Netzwerkverkehr zu den VPN-Clients arbeitet einwandfrei. Für weitere Tipps wäre ich auf jeden Fall immer noch sehr sehr dankbar. :(

- und genau dass ist irgendwie das unlogische an der ganzen Geschichten :nene: Die Benutzeranmeldung erkennt, dass es da wohl eine Einstellung gibt (nämlich die Settings für unseren Proxy), übernimmt (oder übergibt) diese Einstellungen aber nicht in die Anwendung. Ich werde auf jeden Fall einmal die "Userenv.log" eines Clients hier posten. Die Log's vom Server geben nicht sehr viel Auskunft / Habe aber auch - um's offen zu sagen - Verständnisschwierigkeiten. Tatsache ist, dass diese Log's kein aktuelles Datum besitzen, die in irgendeiner Form mit diesem Fehler in Verbindung gebracht werden könnten. An der Ursachenforschung sitze ich jetzt schon seit Anfang letzter Woche und die Logs sind z.T. älter.

Hi - das ist korrekt. Die Außenstellen liegen in verschiedenen OU's. Aber dass ist nicht weiter schlimm, da ich keine verschiedenen GPO's für die jeweiligen OU's verwende. Ganz konkret sieht das bei uns in der AD so aus: AD Benutzer- und Computer: _+ Domäne.Standort.de ("Default Domain Policy" => blieben weitestgehen unberücksichtigt) ___+ Domänename ("GPO Unser Standort" => hier wurden sämtliche Einträge vorgenommen) _____+ Interne Standorte __________+ Abteilungen _____+ Externe Standorte __________+ Abteilungen _____+ Clients Die einzigsten Gruppenrichtlinien, die sihc überlagern, ist die "Default Main Policy" und die "GPO Unser Standort"-Policy. Weitere Richtlinien haben wir der Übersicht wegen nicht eingebaut.

Habe ich gerade geprüft - leider Fehlanzeige. Also der DC läuft ohne Probleme; auch keine aktuellen Warnings oder Fehler-Meldungen. Was mir bei dieser Gelegenheit aufgefallen ist: Ich habe ja jetzt 2 DNS-Reverse-Lookupzonen. ___.___.123.x Subnet ....und die: ___.___-124.x Subnet Bei der .123 stehen alle Clients des lokalen Netzwerkes drinnen. In der .124 müssten ja theoretisch dann die VPN-Clients enthalten sein. Dort stehen aber lediglich die beiden Nameserver und der "Autoritätsursursprung". Sorry, kenne mich mit DNS zu wenig aus, als dass ich einschätzen könnte, ob hieraus ggf. ein Fehler resultiert. Also in der Ereignisanzeige "DNS Server ist der letzte Eintrag vom 19.5.: DNS erfolgreich gestartet". Seit dem läuft der Server eigentlich problemlos durch. Mal eine ganz grundsätzlcihe Frage in die Runde: Am IE kann es ja theoretisch nicht liegen - oder ? 1.) ist die extern installierten Versionen identisch mit den internen 2.) funktioniert die GPO bei lokaler interner Netzanmeldung auch auf den draußen stehenden Clients Die Gruppenrichtlinie "überträgt" ja "irgendwas" an den Client, sonst würden ja die Sicherheitsricht- linien im IE nicht greifen (Proxy-Einstellungen sind ausgegraut -> für User deaktiviert). Das GPO schreibt nur leider nichts in die fehlenden Einstellungen hinein (überschreiben der lokalen Settings). Es gibt meines Erachtens 2 Ansätze: a.) Irgendwas ist nicht sauber integriert zwischen dem neuen Netzsegment und meiner internen Domäne b.) Das Routing "verschluckt" irgendwelche Informationen (ggf. Nachkonfiguration unserer VPN-Policies) An den Clients kann es nicht liegen - die gleichen sich installationstechnisch wie ein Ei dem Anderen.

O.k. - Danke :D Was mir beim Vergleich der lokalen gpresults zu den externen gpresults aufgefallen ist, dass wir uns intern an "dc1.domäne.standort123.de" anmelden; der externe Client an dc2.domäne.standort123.de". Anonsten erkenne ich nichts ungewöhnliches: Microsoft Windows 2000 [Version 5.00.2195] © Copyright 1985-2000 Microsoft Corp. U:\>gpresult Microsoft ® Windows ® 2000 Operating System Group Policy Result tool Copyright © Microsoft Corp. 1981-1999 Created on Montag, 21. August 2006 at 11:54:52 Operating System Information: Operating System Type: Professional Operating System Version: 5.0.2195.Service Pack 4 Terminal Server Mode: Not supported ############################################################### User Group Policy results for: CN=Vorname Nachname,OU=OV Standort,OU=_Au▀enstellen,OU=Rathaus,DC=Domain,D C=domain,DC=de Domain Name: Domain Domain Type: Windows 2000 Site Name: Standort-RathausNetz Roaming profile: (None) Local profile: C:\Dokumente und Einstellungen\nachname_v The user is a member of the following security groups: Domain\Domõnen-Benutzer \Jeder VORDEFINIERT\Administratoren VORDEFINIERT\Benutzer NT-AUTORIT─T\INTERAKTIV NT-AUTORIT─T\Authentifizierte Benutzer \LOKAL Domain\Aussenstelle ABC ############################################################### Last time Group Policy was applied: Montag, 21. August 2006 at 11:12:37 Group Policy was applied from: DC2.Domain.standort.de =============================================================== The user received "Registry" settings from these GPOs: GPO Domain Standort ############################################################### Computer Group Policy results for: CN=OV-ECK-02,CN=Computers,DC=Rathaus,DC=standort,DC=de Domain Name: Domain Domain Type: Windows 2000 Site Name: Standort-RathausNetz The computer is a member of the following security groups: VORDEFINIERT\Administratoren \Jeder VORDEFINIERT\Benutzer NT-AUTORIT─T\NETZWERK NT-AUTORIT─T\Authentifizierte Benutzer domain\Client-123$ domain\Domõnencomputer ############################################################### Last time Group Policy was applied: Montag, 21. August 2006 at 10:11:41 Group Policy was applied from: DC2.domain.standort.de =============================================================== The computer received "Registry" settings from these GPOs: Richtlinien der lokalen Gruppe Default Domain Policy =============================================================== The computer received "Security" settings from these GPOs: Richtlinien der lokalen Gruppe Default Domain Policy =============================================================== The computer received "EFS recovery" settings from these GPOs: Richtlinien der lokalen Gruppe Default Domain Policy

Danke - bin schon einfrig am lesen - aber :-) Knackpunkt ist, dass ich auf den Gruppenrichtlinienergebnis-Satz nicht draufkomme, da wir hier Windows 2000 im Einsatz haben :( Und in der Ereignisanzeige gibt's auch keine spannenden Einträge :-/

Hallo zusammen - ich sitze jetzt schon eine ganze Weile an unseren neuen VPN-Clients, und bis auf einen etwas irreführenden Problempunkt klappt alles bestens: Problem: Meine Clients melden sich an der Domäne an, bekommen Netzlaufwerke ect. übergeben. Lediglich die Einstellungen zur Startseite und der Proxy-Configuration schlägt fehl Interessanterweise "graut" er die Proxy-Einstellungen aus; aber die ganzen Informationen werden dem IE nicht übergeben. Systemumgebung: Wir haben hier eine Win2k-Umgebung. "Im Haus" hängen die Clients in einem eigenständigen Netzsegment: xxx.xxx.123.1-254; Hier hängen auch unsere Domänecontroller; der ISA-Server 2004 (Proxy). Integriere ich hier im Haus einen Client in die Domäne & meldet sich der User an, werden ihm die Netzlaufwerke per Script und die IE-Umgebung per Gruppenrichtlinie übergeben. Als DNS-Server (Clients) sind unsere Domänecontroler eingetragen. Seit kurzem haben wir unsere Außenstellen per VPN angebunden. Sprich: die Clients hängen in jeweils unabhängigen Netzsegmenten (xxx.xxx.124.0-15;16-31; ect.). Eine Firewall & ein Router übernehmen das Routing; In meiner Domänestruktur habe ich folgende Anpassungen für die Netzerweiterung vorgenommen: - DNS-Server: Neue Reverse-Lookup-Zone - im ISA-Server: "Internes Netz" mit der neuen Adressierung ergänzt Die IP-Config der Clients sieht folgendermaßen aus: IP:xxx.xxx.124.2 : 255.255.255.240 GW: xxx.xxx.124.1 DNS: xxx.xxx.123.2 DNS: xxx.xxx.123.3 Meldet ich sich der User nun lokal in der Außenstelle an unserer Domäne an, werden sämtliche Datenströme an unsere interne Domäne verschlüsselt weitergereicht (und umgekehrt). -> Der User kann seine Dokumente (Mapping auf unserem Server) aufrufen -> Der User kann seine gewohnte Outlook-Umgebung aufrufen (Exchange => IMAP) -> Nslookup funktioniert einwandfrei; die Namen zu uns ins LAN werden alle korrekt aufgelöst Trage ich mit Administratorenrechte die Proxy-Einstellungen von Hand in den IE ein, kann ich auch surfen ! Versucht aber der User, die Internetumgebung aufzurufen, wird der Bereich zwar "ausgegraut", aber die Proxy-Einstellungen fehlen (leere Felder). Also die Gruppenrichtlinien greifen ja; - aber warum nur werden die Einstellungne nicht eingetragen ? -> Habe auch einmal die Sicherheitseinstellungen des IE ganz nach unten geschraubt; ohne Erfolg. Was hat ein Problem ? Die Gruppenrichtlinie ? Oder der IE ? IE-Version: 6.0.2800.1106 Für jede Idee, wo ich meine Suche noch ansetzen könnte, wäre ich sehr, sehr dankbar. Komme jetzt leider nicht mehr weiter :-( Viele Grüsse, Tapio aka Shao-Lee

Hallo zusammen, wir haben hier in unserer Windows 2000 - Domäne (Win2k Server & Clients) eine Gruppenrichtlinie definiert, in welcher den Clients die Proxy-Einstellungen sowie die Startseite (auf unser lokal liegendes Intranet) übergeben werden. Das hat bis jetzt auch wunderbar geklappt :D .... bis Gestern :( Ich habe neue Clients ins Netzwerk einbinden müssen (auch Win2k) und die Domänenanbindung vollzogen. Da ich auf der Microsoft-Seite keinen vollständigen IE-6 SP 1 finden konnte, habe ich von einem Dritt-Hersteller ein vollständige IE6 SP1 - Installationsverzeichnis genommen und damit unsere Clients installiert (Internet Explorer). ...war wohl im Nachhinein ein Fehler. Jetzt haben die neuen Clients den aktuellen IE zwar drauf (mit SP1) ... aber die Gruppenrichtlinien versagen buchstäblich. Die Internetstartseite wird nicht aktualisiert und interessanterweise auch nicht die Proxy-Einstellungen. Wenn ich die Einstellungen "händisch" ändere, bleiben die Einstellungen erhalten. Interessanterweise habe ich aber wieder das gleiche Problem, wenn sich ein anderer Benutzer an dem neuen Client anmeldet. Was ist da falschgelaufen ? Oder gibt es einen "Mechanismus", mit dem ich die Verwendung der Gruppenrichtlinien "erzwingen" kann ? Danke & Gruss, Shao

JUHUUUU - DAS WAR'S !!!! Hallo Squire ! .net-Framework 2.0 ist auf unserer Maschine installiert ! Problemlösung: Ich habe in dem "Microsoft.net"-Ordner den "Netzwerkdienst" hinzugefügt (war nicht enthalten ) - dann ging's :D Herzlichen Dank, Squire ! Ich wäre selbst nie auf diese Lösung gekommen. Auch im Internet hatte ich keine Anhaltspunkte für solch eine Lösung entdecken können. Vielen, vielen Dank *tief-verbeug* Ich werde das Intranet jetzt ersteinmal auf Herz und Nieren prüfen. Aber auf jeden Fall lassen sich schonmal die Konfigurationsseiten wieder aufrufen :D Weiterhin viel Erfolg wünsche ich Dir, Tapio

Hallo zusammen ! Hat keiner eine Idee ? :( Habe mich heute nochmals 2 Stunden mit dem Zielsystem auseinandergesetzt; aber ich komme einfach nicht weiter. Ich habe paralell einmal eine neue Webseite auf unserem System erstellt (Website auf höchster Ebene); das Ergebnis ist aber identisch: Die Seite kann nicht angezeigt werden, da permanent eine Auth. verlangt wird. Auch die "Help" aus der oberen Navigationsleiste bringt die besagte Fehlermeldung (Authentifizierung => Laufzeitfehler). Interessanterweise arbeitet aber die Zentraladministration einwandfrei Ich vermute, dass ggf. ein Problem mit den Parametern der Seite selbst (also in den IIS-Services) ggf. Probleme bereitet (Zentraladministration ist als separate Seite aufgeführt). Aber die Settings habe ich bereits geprüft / da ist auch nichts auffallendes eingetragen; eigentlich so, wie auf unserem "Quellsystem". Kann es ein Problem darstellen, dass das Quell-System das englische Windows installiert hatte und ich die Intranetseite auf ein Deutsches Windows rübergesichert (bzw. die Webserverdateien rüberkopiert) habe ? Bis dann, Shao

Hilfe - Habe hier aktuell ein Problem, das nach dem Umzug unserern Intranet-Webseite aufgetreten ist "Serverfehler in der Anwendung '/_layouts'. -------------------------------------------------------------------------------- Laufzeitfehler Beschreibung: Auf dem Server ist ein Anwendungsfehler aufgetreten. Die aktuellen benutzerdefinierten Fehlereinstellungen für diese Anwendung lassen das Anzeigen der Details nicht zu. " Hier ist Sharepoint Services mit Servicepack auf Win2k3 SP1 am laufen. Ich habe unsere Intranetseite auf einen neuen Server umgezogen. Den Umzug habe ich mit "stsadm" vollständig durchführen können. Die Datenbank kann auch fehlerfrei angesprochen werden. Lediglich startete zu Beginn die "localhost/default.aspx" nicht :-( Fehler: Die Seite erwartete eine Authentifizierung / und egal, mit welchem Benutzer ich mich angemeldet habe, die Auth. schlug fehl. Ergebnis: Fehlermeldung mit einem "Laufzeitfehler" mit Hinweis auf die Anwendung "_layouts" ?! ...dann ich festgestellt , dass Strukturen im Template-Verzeichnis nicht vorhanden sind (wo div. Grafiken direkt abgelegt wurden (Webserververzeichnis) / auf der Ursprungs-Maschine waren die Folders aber da). Nachdem ich den "../60/Template"-Folder von Hand vom alten Server auf den neuen Intranetserver rüberkopierte, startete zwar glücklicherweise die Intranet-Webseite wieder(und die Datenbankinhalte lassen sich auch problemlos aufrufen), nur erscheint der besagte Laufzeitfehler und die zwingende Anmeldung immer dann, sobald ich "Documents and Lists" - "Create" - "Site Settings" - "Help" oben in der Navigationsleiste auswählen will. Was stimmt da nicht ?! Die zwingende Anmeldeaufforderung "riecht" nach einem Berechtigungsproblem. Auch in den Sharepoint-Service-Eigenschaften sind sämtliche Berechtigungen eingeschaltet. In den "Managed Pathes" ist auch nichts spezielles eingestellt. Die "Sharepoint Zentraladministration" lässt sich auch problemlos aufrufen. Wer hat einen kleinen Tipp für mich ? Vielen Dank im Vorraus, Tapio aka Shao-Lee

Hallo zusammen :-) Vor mir liegt diese Woche eine Aufgabe, die eigentlich simple sein sollte. Trotzdem liegt ja bekanntlich "der Teufel im Detail". Aufgabenstellung: Hier läuft eine homogene Windows2003-Domäne, bestehend aus insgesamt 3 DC's mit unterschiedlich verteilten Netzwerkdiensten . Das AD wird auf alle 3 DC's verteilt; ähnlich umserem aufgesetzten DFS. Nun geht es darum, einen DC aus dieser Domäne vollständig und endgültig zu entfernen. Auf diesem DC laufen: DNS, DHCP und der Sharepoint-Service. Als ich mal die Rollen gecheckt habe, wurde mir der herauszunehmende DC als Primärer DC angegeben. Ist ja aber in einer reinen Win2k3-Server-Umgebung eher unerhelblich. Rein theoretisch müsste ich ja jetzt nur hergehen, und die Dienste DHCP & DNS auf einem anderen DC installieren; ggf nachkonfigurieren. Von der Sharepoint-Database mache ich eine Sicherung und übernehme diese auf den alternativen Server & passe die Gruppenrichtlinien an, damit die User wieder auf's Intranet kommen. Wenn dann diese 3 Services auf den anderen Server portiert wurden, - deinstalliere ich die Dienste auf dem herauszunehmenden System, - entferne den DC aus der Domäne (als Mitglied -> in Arbeitsgruppe) - ausschalten & fertig. Sollte eigentlich reichen, oder ? Viele Grüsse, 'Tapio aka Shao-Lee

Hi :-) Ja - Genau - das iPrint-Tool hört sich richtig interessant an; ich hatte dass auch bei meiner Recherche entdeckt. Dummerweise steht es nur Novell zur Verfügung - und da wir eine homogene Windows-Umgebung haben :D , ist dieses nette Tool leider unbrauchbar für uns :( Ich suche auf jeden Fall mal weiter :D Grüssle, Shao-Lee

@carlito: Vermutlich hast Du recht und es wäre wirklcih der einfachere Weg über "User-Schulungen". Problem ist halt auch, dass die Benutzer bei entsprechender Vorgehensweise über "Neuer Drucker" sämtliche Drucker angezeigt bekommen, die es bei uns im Unternehmen gibt. Dass ist dann häuft "zu viel Information" und sie rufen mich dann wieder an :( Dann lieber doch der Weg über eine "direkte Verbindung" mit dem Printserver, auf dem sie sich dann ihren zentralen Wunschdrucker aussuchen und verbinden können. Solch eine Intranetseite mit Druckerverbindung per Knopfdruck wäre halt schon mal was gewesen :D @Josh16: Ganz genau sowas wäre dann mit der "Internetdrucker"-Option möglich. man bindet die Informationen auf seiner Intranetseite ein und die User haben einen direkten Bereich für ihre Druckerumgebung. Alternativ wäre ja eine Script-Lösung interessant... da habe ich auch mal in die Richtung recherchiert... Problem ist halt: Die User haben keine lokalen Administratorenrechte ;) Es müssen doch brauchbare Lösungen am Markt sein - ... Wie löst ihr anderen dieses Problem ? Grüssle & Danke für's bisherige Feedback ! Tapio aka Shao-Lee

Hallo Carlito, ja, die Drucker sind auch allesamt im AD veröffentlicht. Aber das Problem ist hat, dass die User sich nicth so gut auskennen hinsichtlich Drucker- installation => Neuer Drucker => Suche im Rathaus-Verzeichnis :( Alternative zum "Internetdrucken" wäre natürlich auch eine kleine Beschreibung mit direktem Link zum Printserver (an dem dann nur die Drucker als Freigaben erscheinen) für "Rechte Maustaste -> Verbinden". Hinsichtlich meinen oben angesprochenen Problempunkten habe ich nochmals fleissig recherchiert und herumkonfiguriert. Also grundsätzlich scheint alles "sauber" zu sein. Ich habe fast die Vermutung, dass auf Grund des SharePoint-Services (der ebenfalls auf diesem besagten Intranet-Server läuft) den Aufruf der Standardwebsites unterbindet. Auf jeden Fall komme ich jetzt definitiv bei diesem Problem nicht weiter. Egal welche Adressierungen ich nehme; auch Konfiguration der "Verbindungen" incl. Ausnahmeregelungen beim Browsen von lokalen Adresen; ich bekomme immer die Fehlermeldung, dass die Seite nicht existiert. ... wenn wenigstens ein Problem mit der Berechtigung bestehen würde... aber ich finde sie weder vom localhost aus, noch von irgendeinem Client. Schade :( Grüssle, Shao

Hallo zusammen :-) Ich habe mich da jetzt einmal drangewagt und soweit alles durchkonfiguriert. Die Dienste und PlugIns sind soweit alle installiert und konfiguriert. Lediglich bei den Sicherheitseinstellungne für die "Printers" habe ich die anonyme Anmeldung deaktiviert und setze lediglich die Windowsintegrierte Anmeldung ein. Im IIS-SnapIn (Server-Verwaltung) zeigt er mir die Netzwerkdrucker auch an (Als Verzeichnis). Wenn ich allerdings die Druker mit der rechten Maustaste anwähle, erscheint rechts eine Fehlermeldung: "Verzeichnis nicht gefunden". Wo ich noch hänge: Unsere Intranetseite über Sharepoint-Services lässt sich über "http://servername/" problemlos anzeigen. Aber: Verzweige ich aber auf den benötigten Unterpfad (der mir ja eigentlich vom System nach der Aktivierung der Internetdruckdienste zur Verfügung gestellt werden sollte) "http://Servername/Printers/" bekomme ich eine 404-Fehlermeldung: "Seite nicht gefunden". Also irgendwie doch nicht so einfach, wie gehofft. Vielleitch hat jemand von Euch einen Tipp, wo ich ansetzen kann ? Ich vermute mal stark, dass es mit einer IIS-Einstellung zusammenhängt. Die Drucker selbst sind standardmässig installiert (mit IP-Adressen; Druckertreibern) und auch freigegeben. Ich bleibe da auch am Ball und recherchiere einfrig im Internet. Viele Grüsse, Tapio aka Shao-Lee

Hallo Kai, also - nach Deaktivierung des Dienstes bekomme ich folgende Fehlermeldung: "Sichern- \\SRVEXCH\Microsoft Information Store\Erste Speichergruppe Anschluß nicht möglich an \\SRVEXCH\Microsoft Site Replication Service\SRS Storage V-79-57344-33932 - Verbinden mit einer Ressource nicht möglich. Stellen Sie sicher, daß alle ausgewählten Ressourcen vorhanden und online sind, und versuchen Sie es erneut." Die Fehlermeldung leuchtet mir im Grunde ein / Offensichtlich versucht Veritas, den SRS Storage auf jeden Fall anzusprechen und mitzusichern. Möglichkeiten: a.) Ich nehme den "SRS Storage" aus dem Sicherungsjob heraus. - Geht irgendwie nicht // Auch wenn ich sämtliche Auswahlen deaktiviere, erkennt Backup Exec offensichtlich das Vorhandensein dieses Dienstes und nimmt ihn automatisch in den Backup-Job mit auf :( Wenn ich alle Auswahlen deaktiviere, erscheint nur noch "SRS-Storage" in meinem Backup-Job :suspect: b.) Ich deinstalliere die komplette Komponete aus Exchange. Gesagt getan => Software => Microsoft Exchange aufgerufen => Komponenten ändern; Pech: SRS-Storage kann man nicht deinstallieren; ...wird irgendwie auch garnicht als einzelne Exchange-Komponente angezeigt. Auch hier: Fehlanzeige. Ich meine, solch eine Umgebung für Exchange ist ja eigentlich typisch... c.) Letzte Idee, die ich noch habe; ich gehe "2 Schritte zurück" und schaue, dass ich den Dienst sauber hochgefahren und korrekt durch Backup-Exec angesprochen bekomme. > Anmeldung als Administrator; ...offensichtlich gibt es ja mit "LocalSystem" Probleme. ...werde ich für die Sicherung heute Nacht einmal durchkonfigurieren. Für weitere Ideen bin ich dankbar :-) ...es muss doch möglich sein, dass ich Backup-Exec so konfiguriert bekomme, dass ich keine Fehlermeldung nach jedem Backup-Job ausgeworfen bekomme. Wie sieht dass denn aus, wenn mein Boss in meinem Urlaub da mal was Rücksichern will... :eek: Grüssle, Tapio aka Shao-Lee

Also unser Virenschutz (McAfee ePo mit McAfee Groupshield) ist eigentlich so konfiguriert, dass der Administrator über Aktionen informiert wird. Aber es würde auf jeden Fall Sinn machen, dass der Fehler mit dem Virenschutz zusammenhängt. Dass der Fehler mit unserem RAID-System zusammenhängt will ich erstmal nicht hoffen :( Wir hatten auch unsere Festplatten im RAID-System erst zum Jahreswechsel komplett gegen Neue ausgetauscht. Bevor ich jetzt an die Korrekturarbeiten gehe (mit Ex-Merge) werde ich erst einmal Ursachenforschung betreiben und einen entsprechenden Spezialisten zur Seite nehmen. Danke Euch nochmals herzlich für Euer bisheriges Feedback - dass war der Input, den ich gebraucht habe. Ich halte Euch auf dem Laufenden ! Machts gut, Tapio aka Shao-Lee

Guten Morgen Kai :D Im Exchange System-Manager ist unter Extras -> Standortreplikationsdienste kein Eintrag vorhanden. Wollte ich einen Standortreplikationisdienst hinzufügen, gibt mir Exchange ein Fehlgeschlagen aus, mit der Information: "Der Active Directory Connector-Dienst muss in der Domäne installiert sein, bevor der Dienst Standortreplikation hinzugefügt werden kann." :cool: Ein AD-Connector ist nicht eingerichtetn (hab's gerade einmal geprüft). O.k. - ich fahr den Dienst jetzt erstmal für die Sicherung heute Nacht permanent runter :D Danke Dir - LG, Tapio