Norek

Hi, versuch doch mal von deinem Server aus die MX Einträge auflösen zu lassen. nslookup set type=mx t-online.de Wenn Du hier Einträge angezeigt bekommst, stimmt zumindest schon mal die DNS Abfrage. Somit kannst Du deine Problematik wenigstens eingrenzen.

Tut mir Leid, aber mit Citrix kenne ich mich zu wenig aus um Dir da weiterhelfen zu können.

Terminalserver Lizenzdienst ist ein eigenständiger Dienst und hat nix mit dem Lizenzmanager an sich zu tun. Von daher kann man schon sagen das der Dienst keine Auswirkungen haben sollte.

Hmm, mit einem DR würdest Du das Problem eher nur umschiffen, als es eigentlich zu lösen. Keiner kann Dir garantieren das nach dem DR der Fehler nicht wieder auftritt.

Hi Madnorallen, könntest Du uns bisschen mehr Details mitteilen. Wie sind die beiden Domänen verbunden, sind hier Thrusts eingerichtet die zu einer Migrationsphase dienen? Habt ihr Benutzer migriert mit Hilfe des ADMT oder erstellt ihr die User komplett neu? Wurde Exchange 2003 in irgendwelcher Weise an das Ex5.5 angebunden. Zum Beispiel für Migrationen mit ADC und SRS, damit Ex2003 und 5.5 miteinander arbeiten können, oder sind hier 2 vollkommen unterschiedliche Organisationen installiert, im Falle einer Umbennung oder aus anderen Gründen? Alles in allem, je mehr infos wir haben desto besser können wir Dir vielleicht helfen oder Tips geben. ;)

1. Mit Volume Verträgen habe ich eigentlich Selectverträge gemeint, sry das ich mich hier missverständlich ausgedrückt habe. 2. Das ein Lizenzserver aktiviert sein muss, sollte eigentlich klar sein und muss ich dann nicht extra erwähnen. 3. Dem kann so sein, hab da leider keinen genauen Kenntnisstand. Denke mal hier sollte man sich an MS wenden und dies direkt klären.

jup, ohne RAS Richtlinie in einer Domäne funktioniert das nicht. Ist aber in der RRAS Dokumentation beschrieben. ;)

TS Anwendermodus Lizenzen werden bei Volume Lizenzverträgen mitgegeben, dass heisst man muss den TS nur aktivieren und die Clients können ohne Einschränkung arbeiten. Bei Homeversionen muss diese extra als CAL Paket gekauft werden. So zumindest mein Kenntnisstand.

Mach dich lieber mal auf die Suche nach einem geeigneten Oberadmin der hierfür die Verantwortung trägt. Würde gern mal Mäuschen spielen wenn es bei Euch zu einem Total Ausfall kommen sollte und er dies erklären muss. :p

Hehe, das mit EDS ist mir bekannt. Ist ja mein Arbeitgeber. ;) Grundsätzlich zu den Kosten kann ich nicht viel sagen, da ich nicht die Einzelheiten zur Berechnung des SLA's kenne. Eines kann ich Dir auf jeden Fall mitgeben. Dokus zum Thema Clustering unter W2k gibt es zu Hauf bei MS in der Technet Knowledge Base. Einfach mal Cluster als Stichwort eingeben. ;) Den Vertrag einfach so zu kündigen müsste man abwegen, ob man imstande ist den Cluster grundlegend zu administrieren und nur im schwerwiegendem Störungsfall einen Clusterspezialisten einzukaufen.

Mit reinen SMTP Connectoren. Standort Connectoren setzen voraus das der Gegenpartner innerhalb der Organisation agiert.

omg was müssen meine Augen da lesen. :D

Reine Erfahrungswerte Frieda ;)

Hi Peter, Du solltest Dir eines Bewusst machen. Sollte einmal ein Betriebssystemfehler vorliegen, dann ist mit Platten umtauschen und auf dem anderen Server mal eben hochfahren eben nicht gleich alles wieder in Butter. Dann fällt der Server aus und das für mehrere Stunden wenn nicht Tage, falls kein entsprechendes Know how vorhanden ist. Dann seid Ihr mit Fehleranalyse und Behebung beschäftigt und die Datenbank steht. Bei einem Cluster, wird der Failover iniziiert und am fehlerhaft laufendem Knoten kann gearbeitet werden, während der SQL weiterhin zur Verfügung steht.

Geht zum derzeitigen Standpunkt noch nicht, da Exchange mit ESE arbeitet und dies acuh als Voraussetzung setzt. Wartet auf Kodiak, dann werden seine Wünsche wahr und auch von MS supportet.

Für solche Fälle gibt es Virenerkennungsprogramme für Exchange. Trend Micro Symantec Sybari NAI Groupshield und und und.... Wer heutzutage auf solche Tools verzichtet um Anschaffungskosten oder etweiige Lizenzkosten zu sparen, hat das sogenannte Trojanische Pferd gleich selbst reingelassen.

Die Frage die sich mir hierbei stellt, was ist für Euch sinnvoller im Falle einer Störung und unter welchem SLA Aspekt betrachtet ihr den SQL Server? Folgendes Szenario. 1) Du hast 2 identische Systeme. SQL fällt aus, sagen wir mal an einem Feiertag "es sind meist die Feiertage, sonst würde es ja kein Spass machen ^^ ). Ein Administrator fährt raus und baut von Server A die festplatten in den Server B. 2) Du hast einen Cluster. Node 1 fällt aufgrund einer Störung aus (Festplattendefekt genau auf dem Volume wo die Datenbank gehostet wird). Da ihr aber für dieses Szenario vorgesorgt habt, sind die Volumes auf Hot Spare Platten im SAN oder kleineren Plattensystemen eingebaut. Die Platte fällt aus, aber der Server kann weiter laufen und steht weiterhin zur Verfügung. Dann eines schönen Feiertags mal wieder, wie sollte es auch anders sein, fällt der Dienst auf Node 1 aus. Der Clusterservice erkennt dies, führt einen Failover durch und Node 2 übernimmt binnen weniger Minuten den SQL Dienst. Dies alles ohne Administrativen Aufwand. Der fehlerhafte Dienst kann am folgenden Arbeitstag auf Node 1 erörtert werden, ohne das die Benutzer etwas davon merken. Nun entscheide selbst was wichtiger ist. Verfügbarkeit und automatisierte ausgrenzender Ausfälle über einen längeren Zeitraum, oder ein Techniker der sich ständig auf Abruf bei Störfällen einstellt. ;) is it your Choice.

Sobald Du deine Testumgebung implementiert und Lauffähig hast, kannst Du uns ja informieren wie es gelaufen ist. Gibt vielleicht einigen anderen hier nützliche Hinweise wie sie später mit eventuell der gleichen Voraussetzung schneller und sicherer umgehen können. ;)

Ist dein Windows 2003 Server schon DC oder noch Memberserver? Wenn ja kannst Du dich erstmal als lokaler Admin anmelden, was unter DCs ja nicht mehr möglich ist, da ein DC keine lokale Usergruppen mehr verwaltet, sondern nur noch mit Active Directory arbeitet. Sobald Du dich anmelden kannst, würde ich Dir die KB bei MS mal vorschlagen und dort nach deinen Event IDs suchst die dir die Fehlermeldungen anzeigen. Eventuell findest Du dort eine Lösung. In erster Linie solltest Du aber erstmal die Einstellungen zur Zeit und zur Zone, sowie der S/W Umstellung angleichen, denn Grundsätzlich gilt wenn ein System im AD weiter wie 30 Minuten Unterschied zur Umgebung aufweist wird er nicht mehr vom DC authentifiziert und die Anmeldung schlägt fehl.

Mit Einführung von Windows 2003 wurden zu den Device CAls nun auch User CALs eingeführt, die sich in der Handhabung zum Clientumfeld anpassen lassen. Das heisst nichts anderes als das Du für deine Benutzer an diesen dementsprechend gebundene CALs kaufen kannst und sie damit ganz gleich von welchem Device (Notebook, Public Station, Mobile Access) zugreifen ausreichend lizensiert sind. Oben genannte Lizenzen benötigen noch die standard CAls für das Client Betriebssystem.

wenn beide Server inerhalb des ADs und der gleichen Organistation agieren, kann man das per manueller Aktion über AD Users und Computers machen, oder per Script automatisieren. Exmerge ist hierfür nicht nötig.

Hi, ich würde hier zu einer gemischten Lösung empfehlen. Den Smarthost mit GFI ausstatten und den eigentlichen Exchange mit einem anderen Virenerkennungsprogramm. Sei es Trend Micro Scanmail oder McAfee Groupshield oder auch Symantec. Der Vorteil der hieraus ensteht, sind 2 verschiedene Erkennungstools die eventuell den einen der hier weniger schnell war auszuhelfen. Doppelter Schutz mit einer besseren Erkennungsrate die sich aus zwei unterschiedlichen Tools ergibt.

Hi roide, wenn ich das richtig verstehe, stehen Dir zu diesem Projekt 2 Server zur Verfügung. Also einmal der W2k - Ex2k und der neue zukünftige W2003 - Ex2003. In diesem Fall könntest Du den W2003 vollkommen unproblematisch in die bestehende Windows 2000 AD Struktur integrieren, hiernach den Ex2003 in die Organisation installieren und dann per Script, sämtliche Postfächer moven lassen. Danach kannst Du in aller Ruhe die Vorbereitungen treffen den bestehenden W2k Rechner aus der Domäne zu entfernen.

Kleine Abhilfe, installier schnell nen single Server und downloade Dir solange eine 30 Tage Trial von GFI/Virescan for SMTP. Richte ihn während der Übergangsphase als Smarthost Gateway ein, dass verschafft Dir etwas Luft bis euer SBS samt GS umgestellt ist.

GS 5.2 bietet kein Transport Scan an. Sind aber noch in Tests. Da demnächst unsere Cluster auch auf Viruscan 7.1 Enterprise umstellen werden, werde ich den GS gleich mit einspielen.