dmetzger

Zeit für einen externen Dienstleister, der die Sache vor Ort analysieren und lösen kann? Du steckst sonst vielleicht zu viel Zeit in dieses Problem, und Deine Zeit kostet ebenfalls.

Priorität und Gewichtung sind für standortinterne Zwecke in grösseren Umgebungen. http://technet.microsoft.com/en-us/library/cc957291.aspx

Nein. Du willst ja, dass sich die Nutzer am RODC-Standort am lokalen RODC anmelden und nicht an einem anderen Standort.

Hier gibt es ein Papier zu diesem Thema: White Paper: Exchange 2007 Autodiscover Service

Erstelle diese Zone von Hand auf dem Problem-DC und starte den Netlogon-Dienst auf dem Problem-DC neu. Hilft das?

Du darfst trotzdem nur die Anzahl CALs nutzen, die Du nachweislich gekauft hast.

Mir ist weiter nicht klar, was Ihr genau erreichen wollt und was Ihr tut (beabsichtigt oder irrtümlich). Die Fehlermeldungen sagen jedoch klar aus, dass der Schema- und Domänennamen-Master nicht erreicht werden konnten, aber müssten. Das Problem hier ist, dass ich keine Idee von Eurer Topologie habe und insgesamt viel zu wenig Information, um Deine Fragen strukturiert und nicht zufällig beantworten zu können. z.B. ist unklar, ob alle DNS-Zonen der Gesamtstruktur zentral in der Stammdomäne gehostet werden oder verteilt, wie die administrativen Delegationen eingerichtet sind, welchen OS-Stand die DCs haben, Funktionsebenen etc. etc.

Herzliche Gratulation. Bleib am Thema PKI dran. Es wird in naher Zukunft an Wichtigkeit gewinnen, da verschiedene schon vorhandene oder noch kommende Funktionen von Zertifikaten und Zertifikatsketten abhängen resp. abhängen werden (DirectAccess, Verbunddienste etc.)

Falls es auch Englisch sein darf, gibt es weitere Lektüre hier: The Official SBS Blog - Site Home - TechNet Blogs THE OFFICIAL BLOG OF THE SBS "DIVA" Im SBS 2008 gibt es zudem eine brauchbare eingebaute Hilfe mit reichlich Information.

Immer wieder: Nein. http://www.mcseboard.de/windows-forum-lan-wan-32/sbs-2003-memberserver-109406.html Nebst den technischen gelten die lizenzrechtlichen Bedingungen.

Wenn Du Zertifizierungen schaffen willst, musst Du unter anderem wissen, welche Funktionen und Möglichkeiten bestimmte Produkte enthalten und welche nicht. Das gehört zu den Grundlagen. Du solltest ebenfalls in der Lage sein, weitergehende Informationen eigenständig zu recherchieren. Sonst bleibst Du "alle anderen". Dass Virtual PC ausschliesslich x86-Systeme virtualisieren kann, ist hinlänglich bekannt und dokumentiert. Ein angehender MCSE oder MCITP muss dies wissen. Windows Server 2008 R2 bietet wie Windows 7 Enterprise die Option, direkt als VHD-Abbild zu starten. Hier bietet sich für Dich die Möglichkeit, Dein neu gekauftes x64-Notebook mit Dual Boot zu nutzen, indem Du das install.wim des W2K8R2-Installmediums in ein VHD konvertierst (Google -> "wim2vhd") und als zweite Startoption einbindest. Weitergehend kannst Du dann in diesem VHD-W2K8R2 die Rolle Hyper-V installieren und damit virtuelle Gäste erstellen und verwalten. Somit hast Du dank MS ein fertiges Virtualisierungssystem, das sowohl x86- wie x64-Gäste beherbergen kann. Während Du alles dies baust und konfigurierst, lernst Du automatisch viele Funktionen und Verfahren kennen, die Du für eine Zertifizierung auf Windows 7 und/oder Windows Server 2008 R2 kennen musst. Dazu gehören VHDs, imagex, bcdedit, Hyper-V, etc. etc.

Wie wärs mit Windows Deployment Services (WDS)? Als Dienstleister sind wir auf die Idee gekommen, unsere Notebooks (als zusätzliche VHD-Startoption neben Windows 7 Enterprise) mit Windows Server 2008 R2 und WDS aufzusetzen, um vor Ort netzwerkbasierte Installationen von Servern durchzuführen. Wir benötigen nur die Basis-Abbilder der Installationsmedien von W2K8 und W2K8R2 Standard/Enterprise (install.wim), die wir als Installationsabbilder importiert haben, dazu die boot.wim von W2K8R2. Wir kommen zum Kunden, hängen unser Notebook ins Servernetz und installieren die Abbilder per PXE Boot. Lizenztechnisch kein Problem, da in der Regel mit KMS gearbeitet wird (oder per slmgr ein MAK-Schlüssel installiert werden kann). Die HP-Treiber etc. installieren wir anschliessend. Der grosse Vorteil ist, dass uns völlig egal sein kann, ob die Server optische Laufwerke haben, und Mehrfach-Installationen weit schneller erledigt sind.

Genau, immer zur angefangenen vollen Stunde. Welche Einstellungen findest Du im Reiter "DNS" der Bereichs-Eigenschaften auf dem DHCP-Server vor?

Sind dynamische Updates für die Zone zugelassen?

Für mich genügen Deine Fehler- und Umgebungs-Informationen für eine Ferndiagnose nicht. Möglicherweise meldet sich deshalb keiner. Alles was mir auf die Schnelle einfällt: Haben diese Kunden denn Reverse-DNS-Einträge, gehen alle über Smarthost, gehen alle über den gleichen Smarthost?

Mmmh, hier riecht es gut! *Licht an* Geht denn schon die Grippe um? Wünsche Euch allen einen gesunden Tag, und dass Euch nicht die Bazillen erwischen.

Ok, habe zuerst über die Frage nachgedacht, verstehe jetzt aber Deinen Punkt. Der Begriff Offline Root CA fehlt, und das ist mein Versehen. Ich gehe ganz selbstverständlich von einer Standalone Offline Root CA aus, die eben offline in Tresor lagert und während ihrer ganzen Lebensdauer nie mit dem Netzwerk in Verbindung kommt (-> telefonische OS-Aktivierung). Zertifikatsanforderungen der online Issuing CAs sowie ausgestellte Zertifikate für die Issuing CAs werden ebenso wie die CRLs der Root CA per USB-Datenträger transportiert. Sobald alles konfiguriert, die Issuing CAs signiert und die CRL publiziert sind, schalte ich die Root CA ab und lagere sie, wo immer es sicher ist. Würde die Root CA so konfiguriert, dass sie alle 7 Tage eine CRL publizieren soll (Konfiguration enthalten in den Erweiterungen der Zertifikate für die Issuing CAs), müsste ich die Root CA alle 7 Tage in Betrieb nehmen, eine neue CRL ausstellen und diese publizieren. Das macht wenig Sinn, da sie ja eben nur die Zertifikate für die Issuing CAs ausgestellt hat. Wird ein solches Zertifikat komprimittiert, kann ich noch immer die offline Root CA umgehend in Betrieb nehmen, ein neues Zertifikat für die Issuing CA ausstellen, das alte Zertifikat sperren, eine neue CRL publizieren und die offline Root CA wieder herunterfahren. Konfiguriere ich dagegen für die Offline Root CA ein CRL-Publikationsintervall von 6 oder 12 Monaten, senke ich den administrativen Aufwand ohne Sicherheitseinschränkung. Die für die online Issuing CAs ausgestellten Zertifikate der offline Root CA werden voraussichtlich nicht im Wochenrhythmus komprimittiert. Selbstverständlich ist das CRL-Publikationsintervall für Zertifikate, die die Issuing CAs ausstellen, erheblich kürzer. Üblich sind 1 Woche für vollständige CRLs und 1 Tag für Delta-CRLs.

Variante 2 genügt. Im schlimmsten Fall, wenn alle 3 Kopien irgendwann kaputt sind, könnte man zu einer neuen Root CA migrieren, die die Issuing CAs signiert. Aber das wird kaum passieren. Wichtig: Wenn eine Kopie in Betrieb genommen wird, weil das Stammzertifikat erneuert oder eine neue CRL publiziert werden muss (CRL-Publikationsabstände nicht zu kurz halten, 6 Monate oder 1 Jahr genügt - es werden ja nur Zertifikate für die Issuing CAs sowie das Stammzertifikat ausgestellt), müssen alle 3 Kopien anschliessend ersetzt werden. Standard für beide, so lange Du nicht Zertifikate gesamtstrukturübergreifend ausstellen willst. Ab W2K8R2 ist das Bearbeiten von Zertifikatsvorlagen auch mit der Standard-Edition möglich.

Kommt darauf an, im Grundsatz ja. Falls Euer Geschäft die Ausstellung von 1000en Zertifikaten pro Minute ist, dann lieber als Gerät. Im üblichen Mittelstands-Umfeld (automatisch verteilte Zertifikate für Computer und Benutzer, vielleicht NAP etc.) genügt eine virtuelle Issuing CA absolut. Du könntest sonst zwecks Lastverteilung später auch eine zweite konfigurieren. Die Root CA als Standalone/Nicht-AD-intergriert bietet sich als VM geradezu an, weil sie einfacher im Tresor zu lagern ist.

Genau.

Da spricht die Angst, dass das eigene Unvermögen schmerzhaft zu Tage tritt. Wirklich kompetente Interne haben externe Dienstleister nie zu fürchten. Aber es ist sicher einfacher, den Überbringer der schlechten Nachricht zu hängen. Nun hast Du die Frage beantwortet, weshalb kein externer Dienstleister hinzugezogen werden soll. Der hätte Eure Fehler schonungslos aufgedeckt, und das wollt Ihr dem Chef lieber nicht zumuten.

Alles Geniale ist einfach.

@Pat: Ich gehe davon aus, dass Du weisst wovon Du sprichst. Kein Zweifel, ist im Forum klar ersichtlich. Es ist eher ein "wording"-Problem. Snapshot ist nicht gleich Snapshot. Der Hyper-V-Snapshot ist was ganz anderes als der Snapshot mittels ntdsutil, aber beide heissen Snapshot. Generelle Aussagen können für weniger erfahrene Kollegen deshalb manchmal verwirrend sein, darum ist die nachgeschobene Präzisierung nicht im Sinn einer Belehrung. Ich denke meistens daran, dass solche Beiträge auch noch in Jahren aufgerufen werden und bemühe mich darum meistens - aber auch nicht immer - um exakte Aussagen inklusive Primärquelle, wenn vorhanden.

In diesem Fall würde ich u.a. die generischen SRV-Einträge prüfen. Vielleicht hat jemand sie manipuliert, oder sie wurden nicht korrekt geschrieben. Firewalls zwischen den Standorten rücken ebenfalls oft in den Fokus der Fehlerprüfung. Wireshark ist hilfreich.

Doch. Aber nur weisungsbefugt und mit völlig freier Hand. Anschliessend würde ich das Gespräch mit dem Chef suchen, um über seine Leute zu sprechen. Stimmt er einer Kompetenzprüfung seines IT-Personal mittels einfachem Qualifikationsinterview zu, erledigt sich die Sache von selbst. Es sei denn, er will es einfach möglichst billig haben. Man bekommt, wofür man bezahlt.