dmetzger

Warum nicht gleich den Hersteller fragen, ggf. per Google?: Exchange Server 2010 Licensing

Wie GuentherH und NorbertFe bereits erwähnt haben, lautet die Standard-URL für Exchange 2010 Outlook Web App https:/<URL>/owa. Das funktioniert anscheindend einwandfrei. Wo also ist das Problem?

Ein mir immer wieder nützliches Werkzeug in solchen Fällen: Process Monitor

Soll heissen: "Ausführen als" führt eine Anwendung im Kontext des "Ausführen als"-Benutzers aus. Du kannst den Task Manager starten und Dir die Prozesse aller Benutzer zeigen lassen (administrative Anmeldeinformationen erforderlich). Dann startest Du irgendeine Anwendung mit "Ausführen als" im Kontext eines anderen Benutzers und prüfst, was bei diesem Prozess im Task Manager unter "Benutzername" gezeigt wird. Und da Du beim Task Manager administrativen Anmeldeinformationen hinterlegt hast, kannst Du gleichzeitig prüfen, was bei diesem Prozess nun unter "Benutzername" erscheint.

Ist der FQDN für den internen ZUgriff auf SharePoint im IE unter der Intranet-Zone eingetragen (ggf. per GPO)? Zusätzlich sollte auch der nachstehend erwähnte Registry-Eintrag helfen. In unseren SharePoint 2010-Installationen ist dies der Fall. You are prompted to enter your credentials when you access an FQDN site from a computer that is running Windows Vista or Windows 7 and has no proxy configured

Das wollte ich wissen. "Natürlich" ist relativ, denn diesen Fall hatte ich auch schon. ;) "RPC server unavailable" kann viele Ursachen haben. Möglicherweise wärst Du mit einem Dienstleister gut bedient, der die Möglichkeit der Fehlersuche vor Ort hat.

Hast Du beim Erstellen der Deleierung unter "Delegierte Domäne" die Subdomäne als "srl" oder als "srl.firma.global" (vollqualifizierter Domänenname "srl.firma.global.firma.global") eingetragen?

Und wenn es im überschaubaren Umfeld trotzdem eilig gehen soll, weil z.B. ein Kunde darauf drängt: - SP1-Paket herunterladen und mit der Option /x:<Pfad> in eine Freigabe extrahieren; - per Batchdatei (GPO -> Computerkonfiguration -> Richtlinien -> Windows-Einstellungen -> Skripts -> Starten) verteilen: "<Pfad>spinstall.exe /quiet /nodialog /forcerestart"

Du hast tatsächlich eingehend Port 53 für DNS-Abfragen auf der Firewall geöffnet und leitest diese Anfragen an einen Domänencontroller im internen Netzwerk (sprich Deinen SBS) weiter? :shock:

Du verstehst IP-Adressierung im Netzwerk so weit grundsätzlich nicht. Das geht aus dem bisherigen Schriftwechsel hervor. Auf die Gefahr hin, das zu wiederholen, was Dir erfahrene Netzwerker bereits mitgeteilt haben: - Du benötigst einen internen DHCP-Server, der den Clients dynamisch die 4 Basisinformationen liefert: IP-Adresse, Subnetzmaske, Standard-Gateway, DNS-Server (primär, da kein sekundärer vorhanden); - In Fremdnetzwerken erhalten Deine Clients ihre dynamische IP-Konfiguration von einem lokalen DHCP-Server, der von einem dafür zuständigen Netzwerkadministrator eingerichtet wurde. Dass es bei Deinen Desktops funktioniert liegt daran, dass diese ausschliesslich den ersten DNS-Server in ihrer Liste abfragen, so lange dieser verfügbar ist. Nimm doch mal einen unter den Arm und transportiere ihn in ein Fremdnetzwerk. Möglicherweise kommst Du spätestens dann auf die Idee, dass ein fest eingetragenere, domänenexterner DNS-Server keine gute Sache ist. Deine Konfiguration mit internem/externen DNS-Server sehen wir bei Kunden anderer IT-Dienstleister oft dann, wenn wir im Auftrag dieser anderen Dienstleister unerklärliche Probleme mit der Namensauflösung zu lösen haben. Wir nennen das intern einen "Anfängerfehler".

Du verwechselst womöglich "Domäne" und "Host". Wahrscheinlich habt Ihr beim Registrar die Domäne "firma.net" eingetragen, und in der externen DNS-Zone "firma.net" befindet sich ein Host-Eintrag "www", der auf die IP-Adresse Eurer externen Website verweist. Und was Dein ursprüngliches Problem angeht, kann Grundlagenwissen nicht schaden: MSXFAQ.DE - DNS

Wieso virtualisierst Du den Server nicht einfach auf neuer Hardware unter W2K8R2 Hyper-V?

Ich meine, das Problem liegt am sekundären DNS-Eintrag, der auf einen domänenexternen DNS-Server verweist. Das ist sogar äusserst unlogisch. Der interne DHCP-Server ist für die IP-Konfiguration zuständig. Wenn Ihr intern nur einen DNS-Server habt, wird logischerweise auch nur dieser als primärer DNS-Server zugewiesen, es gibt dann keinen sekundären.

Warum? Je öfter Du den Server neu einrichtest, desto schneller und kompetenter geht das. Du willst ja das Produkt kennenlernen, ehe Du zum Examen fährst.

Es kann an der Verbindung zum Server liegen. Das erklärt auch die langsamen Hochfahrzeiten und die fehlenden Netzlaufwerke. Allerdings scheint es kein Problem zu sein, per RDP auf den SBS zuzugreifen. Kannst Du Dich am SBS selbst lokal anmelden und auf die Clients/Internet etc. zugreifen? Hast Du die Verbindungskomponenten zwischen Clients und Server bereits geprüft? Was sagen die Ereignisanzeigen auf dem SBS? Kannst Du Exchange OWA von Clients aus aufrufen?

@Ute: Willkommen im Board. Wir haben hier Regeln, die jeder neu Ankommende lesen sollte: http://www.mcseboard.de/rules.php#nr7 Die Überführung physischer Server in virtuelle funktioniert in der Regel zuverlässig. Eine weitere Möglichkeit ist der kostenlose VMware Converter, wobei die erzeugten vmdk-Dateien anschliessend mit vmdk2vhd.exe für den Einsatz in Hyper-V-Umgebungen konvertiert werden: VMDK(VMWare) to VHD Converter Etwas aufwändiger und man sollte in der erzeugten VM dann auch nicht vergessen, den Converter zu deinstallieren, aber nach meiner Erfahrung absolut fehlerfrei und verlässlich.

Mit dieser Feststellung bin ich bei Dir. Deshalb meine frühere Frage. Das "firma.de" ist ein Platzhalter, genau wie Dein "name.name". Gemäss Deinen Angaben soll in Deiner internen DNS-Zone "serv03.serv04.name.name" ein Host-Eintrag "serv03" existieren. (Ich beziehe mich jetzt auf "name.name", damit Dich "firma.de" nicht weiter verwirrt :rolleyes:) Ist das der Fall?

Und ebenfalls leider hast Du zu erwähnen vergessen, wie gross Deine Datenbank ist.

Anhang*B: Überprüfen der wichtigsten DirectAccess-Konzepte The Cable Guy - May 2010 Das reflektiert sich auch hier: Test Lab Guide: Demonstrate DirectAccess Test Lab Guide: Base Configuration An jedem DirectAccess-Seminar und -Workshop, den ich bisher besuchte, wurden die Teilnehmer explizit darauf hingewiesen, nach dem Muster "sub.firma.de" vorzugehen. Wir berücksichtigen dies heute durchgehend, wenn wir neue AD-Gesamtstrukturen entwerfen oder Kunden aus bestehenden in neue Gesamtstrukturen migrieren.

Willkommen im Board Wir bieten eine ausgezeichnete Suchfunktion an. Gemäss Boardregeln ist diese zu nutzen, bevor eine Frage gestellt wird. Deine Frage wurde mehrfach ausgiebig diskutiert, z.B. http://www.mcseboard.de/windows-server-forum-78/ad-domaenenname-auswahl-174452.html

Die beiden Antwortdateien hier funktionieren inkl. Gebietsschema und helfen Dir ggf. bei einem Quervergleich: http://www.mcseboard.de/windows-server-forum-78/vollautomatische-installation-wds-funktioniert-173169.html#post1066088

Und das gibt es ebenfalls: The "Desktop Wallpaper" Group Policy setting is not applied in Windows 7 or in Windows Server 2008 R2

Ok, dann ist mir der Ablauf nun ebenfalls weitgehend klar. Du hast alle Optionen inklusive "Items from Dumpster" in der RSG also bereits durchgespielt?

Es macht sicher schon einmal Sinn, die beiden DB-Anwendungen und deren Last vom SBS zu trennen. Das hast Du bereits selbst festgestellt. Ihr könntet Euch einen Markenserver leisten, der Platz für mehr Platten bietet. Dies würde Dir erlauben, getrennte RAID 1 oder 10-Verbünde für die einzelnen VMs einzurichten. Falls das vom Budget her nicht drinliegt, kannst Du auch darüber nachdenken, auf die Virtualisierung zu verzichten und den zweiten Server dezidiert für die beiden DB-Anwendungen zu verwenden.

Trenne die Strukturen von Laufwerken für einzelne Nutzer (individuelle Homes) von den Strukturen für gemeinsame Zugriffe (Public). In dem von Dir genannten "Konzept" soll das Organigramm der Firma abgebildet werden, was zu den wahrscheinlich erkannten Problemen mit über- und untergeordneten Berechtigungen führt. Weiter solltest Du mit DFS-Namensräumen an Stelle von UNC-Pfaden arbeiten, z.B. "\\domäne\homes" und "\\domäne\public". Du wirst sonst bei der nächsten Migration der Daten unnötig viel Arbeit haben. Ebenfalls sollten Berechtigungen in der Struktur für gemeinsame Laufwerke (Public) für Gruppen statt einzelne Nutzer gesetzt werden. Du darfst sonst bei Mitarbeiterwechseln viel Arbeit in die Änderung individuell gesetzter Berechtigungen stecken. HINWEIS: Mir ist bewusst, dass der TO seinen Beitrag bereits 2007 erstellt und nie eine Antwort erhalten hat. Nun ist der Thread erneut auf dem Radar erschienen, und ich fands interessant, hier kurz eine Lösung zu skizzieren, die vielleicht dem einen oder anderen Forumsteilnehmer mit dem gleichen Problem helfen kann. :);)