schroeder750

Sorry, habe gerade das Blog angesehen, steht alles drin, hatte gerade meine Antwort oben schon editiert... :D Grüsse schroeder750

Harr harr, da hast Du natürlich auch wieder Recht... ;) Habe hier in meiner Testumgebung einen Enterprise laufen und gar nicht mehr daran gedacht, daß ich beim Standard ja diesen Fall der multiplen DBs gar nicht haben werde... Übrigens die Datenbankgröße beim Enterprise geht laut Editionenvergleich von MS sogar bis 16 Terabyte... O.K. damit hat sich Teil 1 meiner Frage in Luft aufgelöst... Danke Dir !!! :p Und den Rest werde ich mir über den Link ansehen. Auch hierfür nochmal danke !!! Grüsse schroeder750

Hy Flare, schau mal hier: http://www.mcseboard.de/showthread.php?t=75643 Da steht die Antwort, wo man es einstellt, aber leider habe ich dazu direkt wieder neue Fragen... :D Sorry, daß ich jetzt hier die beiden Threads miteinander verschraube, ich hätte es eigentlich auch hier posten können... Grüsse schroeder750

Klingt auf jeden Fall besser, als den ganzen Tag mit einem Account zu arbeiten, der mit einer falschen Tat einiges verursachen kann... :D Die meisten Arbeiten fallen doch eh an den Servern an, oder ? Meine Kunden arbeiten meistens mit Ihrem Standarduser an den Workstations angemeldet und gehen, wenn es etwas zu administrieren gibt, via Remote Desktop auf die Server, wo dann ja wieder neu angemeldet werden muss (dann aber als Admin). So ergibt sich eine gewisse "Hemmschwelle". Wenn man via RDP auf dem Server arbeitet, ist das vom "Standardgeschäft" auf den Clients getrennt... Wenn man natürlich mit lokal auf den Clients laufenden Managementkonsolen arbeitet, ist Dein Vorschlag absolut sinnvoll. Kommt immer auf die Strukturen an. Hier kann man auch über Dinge nachdenken wie eingeschränkte, eigens für die Administration bestimmter Dinge eingerichteten Managementkonsolen oder Delegationen... Grüsse Schroeder750

Hallo zusammen, wenn beim Exchange 2003 das SP2 installiert wurde, kann man ja nun auch bei der Standard-Edition die Datenbankgrenze auf 75 GB erhöhen. Hierzu muss ja beispielsweise folgender key in der Registry gesetzt werden: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<SERVER NAME>\Private-<GUID der Datenbank>\Database Size Limit in GB: DWORD = 0-xxxx Das wollte ich eben mal testen und stieß auf folgendes Problem: Wenn man mehr als eine Datenbank hat, tauchen in der registry natürlich mehrere Einträge mit "Private-<GUID der Datenbank>" auf. Wie finde ich heraus, welche GUID welcher Datenbank zugeordnet ist ? Kann ja durchaus sein, daß eine DB begrenzt bleiben soll, während die andere aufgemacht werden soll ... Trage ich als neuen Wert wortwörtlich "Database Size Limit in GB" ein ? mit Leerzeichen und dem Zusatz "in GB" ? Kommt mir ein wenig merkwürdig vor... Wäre froh über kleine Infos... Danke Euch !!! Grüsse schroeder750

Brauchst Du auch nicht. Du hast optimale Vorraussetzungen, wenn Du ganz in Ruhe beide parallel aufbauen kannst, weil Du neue Hardware hast... Den Ex2K3 in die gleiche Organisation bringen wie den Ex2K, Replikation der öffentlichen Ordner einrichten (versteckte Systemordner nicht vergessen) und danach ganz in Ruhe (auch im laufenden Tagesbetrieb) die Postfächer vom alten auf den neuen Exchangeserver verschieben. Die Einträge im Outlook werden dann automatisch angepasst. Im argsten Fall werden die User, die Du gerade verschiebst, kurz aus dem Outlook rausgekickt, wenn Sie zu diesem Zeitpunkt angemeldet sind. Vielleicht vorher ne kurze Mail rumschicken, daß die User einmal kurz mit einer minimalen Unterbrechung rechnen müssen, wenn Du die Postfächer tagsüber verschiebst... Mich würde etwas anderes noch interessieren: Ihr habt momentan eine W2K AD-Domäne im Einsatz, bei der das Schema schon durch den Exchange 2K erweitert wurde, richtig ? Planst Du auch, das AD auf 2003 zu bringen? Wenn das Schema unter W2K von einem Exchange 2K erweitert wurde, entstehen Probleme beim Update des Schemas auf W2K3-AD. Ganz einfach, weil das Schemaupdate des W2K3-Servers Attribute vorfindet, mit denen es nichts anfangen kann. Man muss in diesem Fall das bereits durch den Exchange 2K "aufgebohrte" Schema vorbereiten. Der KB-Artikel dazu ist folgender: http://support.microsoft.com/defaul...kb;en-us;314649 Falls Du beim 2000er AD bleibst, vergiss es einfach, passt dann schon... :D Grüsse schroeder750

Moin moin Outlook-Version ? Ich habe mir das hier mal bei einem Outlook XP angesehen und würde folgendes vorschlagen: Oulook starten => Extras => EMail-Konten => Vorhandenes Konto anzeigen lassen => Ändern => Weitere Einstellungen => Klappkarte "Allgemeines" => Hier unten auf "Verbindung manuell prüfen" klicken und "Verbindungstyp bei jedem Start auswählen" anhaken. Dann müsste theoretisch bei jedem Start vom Outlook abgefragt weren, ob offline oder mit Netzwerkverbindung gearbeitet werden soll. Unabhängig davon, ob der Rechner selber bereits im Netz hängt... Gruss Schroeder750

Was genau bekommst Du denn angezeigt, wenn Du es eingibst ? "Diese Seite konnte nicht geöffnet werden" oder ähnliches ? Hast Du es schonmal direkt auf dem Exchange-Server als Administrator angemeldet versucht über http://localhost/exchange/meier... Gleicher Fehler ? Kommt dann überhaupt nicht die Anmeldemaske ? Grüsse schroeder750

Sorry, wenn ich vielleicht etwas dämlich nachfrage: wenn der Benutzer z.b "meier" heißt, gibst Du dann "servername/exchange/username-meier" oder "servername/exchange/meier" ein ? Im letzteren Fall müsste es eigentlich funktionieren... Frage mag vielleicht echt flach sein, aber evtl. hast Du da falsche Infos zur Nomenklatur bekommen... Grüsse schroeder750

ähm... wenn ich Workstation sage, meine ich damit natürlich die Hardware als temporären, billigen Serverersatz mit installiertem NT4 Server-Betriebssystem, kein NT4-Workstation-Betriebssystem, nicht, daß wir uns da missverstehen... :D Bitte Service Pack 6a fürs NT4 nicht vergessen... Im Normalfall dauert der Vorgang des Hochstufens wenige Sekunden bis eine Minute. Währenddessen werden die Logondienste kurz angehalten, in dem Moment kann sich also an den beteiligten Servern niemand anmelden... wenige Sekunden lang. Das wird niemand merken. Ganz davon ab, werden die meisten Logonvorgänge im Normalfall sowieso von den BDCs abgefackelt, davon hast Du ja noch einen in der NT4-Domäne, oder ? Ich sehe da also keine Probleme... Grüsse schroeder750

... was ja auch wieder sinnlos war, sorry... Du hast ja bereits 10 Lizenzen bei "Pro Server" drinstehen... wer lesen kann ist eindeutig im Vorteil. mannomann, bei den Donald Duck-Comics schaue ich mir die Bilder doch auch immer genauer an :p Ich sag Dir was: unser Problem liegt woanders... an den Lizenzen brauchen wir meiner Meinung nach nicht mehr rumzudrehen... Ich schlage die BDC-Geschichte vor ... Grüsse schroeder750

O.K. da muss ich die Sache etwas relativieren... irgendwie haben wir da ein wenig aneinander vorbei geredet. Wenn ich beim W2K3 Server über Start=> Programme=> Verwaltung=> Lizenzierung gehe, bekomme ich natürlich ein ähnliches Bild. Hier taucht bei mir natürlich auch der Eintrag "Microsoft Back Office" mit lauter Nullen auf... Das ist also normal... vergiss mein Geunke :D Ich bin bisher immer folgenden Weg gegangen: Start=> Einstellungen => Systemsteuerung=> Lizenzierung. Und dort tauchen nur die besagten Windows Server und Exchange Server 2003 auf... Geh doch bitte mal an diese Stelle und spiele hier mit den Parametern für den Windows Server rum. Hier würde ich mal testen, "Pro Server" anzugeben und eine höhere Anzahl an Lizenzen einzutragen. z.B. 999 oder ähnliches. Soll jetzt keine Aufforderung zur Falschlizenzierung sein !!! Soll zu Testzwecken dienen. Analog schaust Du Dir die Geschichte unter NT4 mal an. Sollte uns dies nicht zu einem Erfolg bringen, bin ich echt drauf und dran Dir die Geschichte mit dem neuen BDC / PDC ans Herz zu legen... so kommen wir der Geschichte wohl eher bei... Ist ja auch kein Akt. Workstation geschnappt, NT4 BDC drauf, hochstufen zum PDC, der jetzige PDC wird dabei automatisch runtergestuft, erneutes Testen des Trusts. Dauer insgesamt vielleicht 1,5 Stunden ... dann bist Du schlauer ... Grüsse schroeder750

Oha... danke für die Info !! Und wie findet man heraus, ob es ein solcher NT BOSBS-Server ist ? Könnten wir das Problem dann umgehen, indem wir evtl. die Geschichte mit dem BDC, Hochstufen zum PDC usw. durchführen, wie oben beschrieben ? Oder versemmeln wir damit die Domäne ? Grüsse schroeder750

... "Pullmail" ist auch ein nettes Tool, mit dem man sich auf Kommandozeile und dann über den Scheduler was zurechtstricken kann... soweit ich mich erinnere kostenlos (Freeware). Schau z.B. mal hier: http://faq.netzprisma.de/?id=212001 Der Exchange kann zwar POP3-Server spielen, ist aber, soweit ich weiß, standardmäßig nicht drauf gedrillt, POP3-Client zu spielen. Und genau das ist er ja, wenn er die Mails von einem anderen POP-Server abholen soll... Ich nehme in solchen Fällen auch Zusatztools wie das oben erwähnte Pullmail. Grüsse schroeder750

Hy Christoph, danke Dir für die Info, nur bringt dieser Artikel leider keine Lösung mit sich, wenn ich das richtig sehe, oder ? Hast Du noch einen Ansatz ? - So langsam gehen mir auch die Ideen aus dem Nähkästchen aus... @jimmypop: Hast Du mal den Lizenzprotokollierdienst beendet ? - Schmaler Grashalm, ich weiß, ich möchte nur wissen, was dann passiert ... Shiet, ich habe auch echt keinen Ansatz mehr, da ich ja wie schon gesagt, diesen Fehler nicht mal mit Gewalt nachstellen kann ... Da der W2K3-Server sauber neu aufgesetzt wurde, denke ich, daß da irgendwo in der alten NT4-Domäne der Hund begraben ist ... Vielleicht mal den Trust kappen, eine Workstation schnappen, diese sauber als NT4 BDC ins alte Netz bringen, hochstufen zum PDC und erneuter Test ? Vielleicht hat der alte PDC aus irgend einem Grunde einen Schuss ... Versuch wäre es vielleicht wert ... Grüsse schroeder750

Moin, etwas spät die Antwort, aber hierzu: nochmal ein kleiner Tip am Rande: Ist manchmal nach einem Domänenwechsel recht chaotisch, herauszufinden, in welchem Profil ich denn nun gerade arbeite...je nach Vorarbeiten entstehen da ruckzuck mal mehrere Profile mit irgendwelchen lustigen Endungen... Mach nach der Anmeldung mit dem User, um den es geht, einfach eine DOS-Box auf und gib den Befehl: "set" ein. Dann wird ziemlich weit unten unter "USERPROFILE" angezeigt, mit welchem Profil Du gerade arbeitest. Und da müssen dann die Daten aus dem alten Profil reinkopiert werden... Wie gesagt, nur noch mal als Info zum Abrunden, freut mich, daß inzwischen wieder alles funktioniert :p Grüsse schroeder750

Moin moin, ... ist normal, da die Clients mit den Servern in bestimmten Zeitabständen eine neue SID verhandeln. Das gleiche Problem tritt auf, wenn man einen Client von einem älteren GhostImage wieder herstellt. Dann passt die SID des Computerkontos nicht mehr zur aktuellen am Server. Du hast es hier halt umgekehrt gemacht, die Domäne wurde neu erstellt und der Client war halt noch da ... Den Client neu in die Domäne zu bringen war genau das richtige... Edit: Wenn Du die Domäne neu erstellt hast (und das tust Du ja mit Neuinstallation des SBS), waren doch auch die ganzen Computerkonten gekillt, oder ? Dann müssen doch eh die WS neu in die neue Domäne gebracht werden ... oder wie hast Du das geregelt ? ... ich denke, wenn Du einfach nur die Daten aus dem alten Profil in das neue (.scin) kopiert hättest und es dabei belassen hättest, würden die Probleme nicht auftauchen. Das alte Profil war ja auf einen Benutzer aus der "alten" Domäne berechtigt. Du hast es jetzt einem neuen Benutzer (aus der neuen Domäne) untergejubelt... ich würde hier wirklich nur die Nutzdaten rüberkopieren, nicht die ganzen Profile ersetzen... Ich würde einfach mal a) die Daten aus dem Profil zur Seite kopieren b) die Profile löschen c) den Benutzer neu anmelden (neues Profil erzeugen lassen) d) die Daten in dieses neue Profil kopieren dann dürfte es eigentlich funktionieren... Grüsse schroeder750

... Du schreibst übrigens auch "servergespeicherte Profile"... der Administrator auch ? Mal ne Anmeldung versucht mit einem Benutzer, der kein servergespeichertes Profil hat ? Vielleicht liegt da momentan der Hase im Pfeffer ... ... nur mal so als erste Ansätze... Grüsse schroeder750

... und wenn Du den Dienst, den Du in Verdacht hast (Virenscanner) mal auf "deaktiviert" setzt und den Server neu startest ? Auf diese Art und Weise könntest Du zumindest mal rausfinden, ob und welcher Dienst Dir in die Suppe spukt... Kommst Du denn rein, wenn Du den Server abgesichert hochfährst ? Grüsse schroeder750

Ist die Domäne denn im native mode ? Als kleines Mittel zur Fehlersuche: Verleg doch mal den PDC-Emulator auf den anderen DC, ist schnell passiert und kann fix wieder rückgängig gemacht werden. Wenn die Rechner beim Anmelden dem PDC-Emulator folgen, weisst Du schon mal grob in welche Richtung das geht... Grüsse schroeder750

Recht so, je ein Bierchen für jede fsmo-Rolle und das letzte dann für die erfolgreiche Verlegung des Globalen Katalogs. Das macht Sinn :D :D :D Ähhmmm... vorsichtig, das sind 5 Rollen. Drei (die, die jeweils in einer Domain verfügbar sind) kann man an EINER Stelle ändern, die beiden weiteren (Schemamaster und Domain Naming Master, die forestweit nur einmal vorhanden sind) werden nochmal separat an anderen Stellen geändert. Für den Schemamaster musste Dir erst noch das Snap-In fürs AD-Schema freischießen (Regsvr32.exe %SystemRoot%\System32\schmmgmt.dll). Und genau deswegen mache ich das immer mit dem ntdsutil. Is mir echt zu nervig, mich wild durch die mmc zu klicken, irgendwelche Fokusse richtig zu setzen und dann nach einer Ewigkeit alles verlegt zu haben. Beim ntdsutil sind das 5 Befehle, die ich der Reihe nach absetze und dann hat sich der Fisch ... Na, denn mal viel Erfog !! Und die Bierchen erst nachher trinken, sonst verlegst Du die fsmo-Rollen womöglich noch auf einen Win98 PC und den Globalen Katalog auf den SAN-Controller... :D :D Grüsse schroeder750

... ach ja, was ist mit DNS, DHCP und WINS ? nich vergessen, gelle ? :D Grüsse schroeder750

Die Methode mit dem ntdsutil ist meiner Meinung nach keinesfalls rabiat. Ist doch eigentlich (jedenfalls für mich) die Standardmethode um die Rollen zu verschieben. Klar, es funktioniert auch über die Managementkonsole, diese Methode fährt mir jedoch voll vor die Wand, wenn der erste DC, der die fsmo-Rollen gehalten hat, abgeraucht ist und nicht mehr verfügbar ist. Dann is über die Managementkonsole nix mehr mit Rollen verschieben. Im Desasterfall immer gut zu wissen... Die Managementkonsole macht das, was ich via ntdsutil mit dem "transfer"-Befehl mache. Wenn der fsmo-Rollenhalter jedoch nicht mehr erreichbar ist, kann ich es im ntdsutil mit dem "seize"-Befehl erzwingen...das macht die mmc nicht. Ich würde auf jeden Fall vorher die fsmo-Rollen sauber auf den neuen DC verschieben und den Erfolg mit "netdom query fsmo" überprüfen. Dann, wie schon erwähnt den global catalog auf den neuen DC, vom alten den GC entfernen und sauber mit dcpromo aus dem AD nehmen. Ist wichtig, weil sonst Replikationsleichen im AD zurückbleiben. Wenn Du die genauen Befehle zum Verschieben der fsmo-Rollen mit ntdsutil brauchst, mach kurz Meldung, O.K ? :D Grüsse schroeder750

... kleine Anmerkung noch von mir: Das mit dem Anmelden am DC mit globalem Katalog funktioniert nach meinen Informationen nur, wenn a) die Domäne im native mode ist und b) die Clients größer W2K sind, oder ? Ansonsten müssten trotzdem alle nach dem ersten DC schreien, weil der ja den PDC-Emulator hält... Korrigiert mich bitte, wenn ich mich irre... ;) Grüsse schroeder750

Mal noch ne ganz dumme Frage: Der W2K3-Server ist doch kein SBS, oder ? Grüsse schroeder750