olc

Hi Naison, sobald ein Client eine CRL heruntergeladen hat, ruft er die nächste CRL erst herunter, wenn der Gültigkeitszeitszeitraum der aktuellen CRL abgelaufen ist. Bei Dir wird die Delta CRL alle 12 Stunden ausgestellt, d.h. alle 12 Stunden wird diese auch abgerufen werden, minus die "Overlap Period", die Du definiert hast. Ab Vista gibt es die (supportete) Möglichkeit, diesen sogenannten CRL-Cache auch vorher zu leeren, um somit den erneuten Abruf der CRLs zu initiieren. Aber einmal anders gefragt: Worum geht es Dir genau - wurden Zertifikate zurückgezogen, die nicht korrekt in der (Delta) CRL auftauchen? Viele Grüße olc

Hi André, schau auch einmal hier hinein: PowerShell 1.1 Deinstallation Powershell V1.0 / Installation Powershell V2.0 - PowerShellPraxis.de Viele Grüße olc

Hi, einmal anders gefragt: Gibt es einen konkreten Hintergrund, warum Du die Priorität verändern möchtest? Funktioniert etwas nicht korrekt? Warum kein CMD / Batch Aufruf? Viele Grüße olc

Hi Naison, welchen CRL und Delta CRL Veröffentlichungsintervall hast Du denn gewählt? Die Clients ziehen die CRL bzw. Delta CRL erst, wenn der nächste Zeitpunkt erreicht ist. Den nächsten Veröffentlichungszeitpunkt solltest Du zum Beispiel in einer per GUI geöffneten CRL sehen. Über welches Client OS sprechen wir? Welche Optionen hast Du in der entsprechenden GPO gewählt (Benutzer + Computer Einstellungen)? Viele Grüße olc

Hallo Maik, ok, dann versuche das alte Profil "über" das neue Profil des Administrators zurückzusichern. Vorher natürlich das neue Profil sichern, nur für den Fall der Fälle. Viele Grüße olc

Hi, zu Punkt 1: Ja, die Daten fließen verschlüsselt in das Backup. Das ist der Sinn von Dateiverschlüsselun. ;) zu Punkt 2: Ich möchte noch einmal anmerken, daß das konkrete Problem rein gar nichts mit der installierten oder deinstallierten CA zu tun hat. Es geht um schon vorhandene Zertifikate, nicht um neu auszustellende oder abgelaufene Zertifikate. Handelt es sich bei dem "neuen" Administrator um den selben Administrator der alten SBS Domäne (also wurde das Upgrade in der selben SBS Domäne durchgeführt) oder ist es ein neuer Forest? In ersterem Fall könntest Du mit der Rücksicherung des Profils zum Administrator Glück haben (gleiches Kennwort benötigt wie vor der Migration). D.h. Du überschreibst das aktuelle Profil mit dem alten Profil inkl. aller untergeordneter Daten. In letzterem Fall denke ich, daß es mit der Rücksicherung des Profils nicht so einfach klappen würde, da sich die SID des Benutzers unterscheidet. In diesem Fall gibt es darauf spezialisierte Datenretter, die bei vorhandenem Profil des Administrators und bekanntem Kennwort die Schlüssel des DRA aus dem Profil extrahieren können und damit den privaten Schlüssel wieder verfügbar machen können. Viele Grüße olc

Hi, ok, d.h. Du kannst die certsrv Seite doch abrufen, bekommst aber nach dem Import des Zertifikats einen Fehler. Es wäre gut gewesen, wenn Du das vorher auch so dargestellt hättest. Wie gesagt, nur mit sinnvollen Beschreibungen kann man Dir auch helfen. Anhand Deiner nur sehr allgemeinen Beschreibungen vermute ich, daß Du keine Enterprise CA einrichtest, sondern eine Stand-Alone CA. Ist das korrekt? Möchtest Du "nur" ein SSL Zertifikat für den IIS haben? Falls ja, dann mußt Du dafür nicht unbedingt eine CA installieren, es reicht dann auch ein einzelnes, selbsigniertes Zertifikat, siehe auch http://www.serverhowto.de/Selbstsigniertes-Zertifikat-fuer-den-IIS-6-0-erzeugen-und-installieren.267.0.html Poste die Anhänge bitte auf einem externen Server, der Speicherplatz hier ist wie immer begrenzt. Den Text des Eventlogs kannst Du hier auch als "CODE" posten, ein Screenshot macht sich da nicht so gut. Dafür gibt es den "Kopieren" Schalter im Menü des geöffneten Events. Viele Grüße olc

Hi, wie gesagt, eine CA gehört im Normalfall nicht auf eine andere Serverrolle. Wenn die alte CA eine Enterprise CA war, dann mußt Du noch weiterführende Aufgaben durchführen, um die alte CA sauber zu entfernen: How to decommission a Windows enterprise certification authority and how to remove all related objects from Windows Server 2003 and from Windows Server 2000 Viele Grüße olc

Hi, auf keinem der beiden Server. Eine CA ist eine CA ist eine CA. ;) Soll heißen: Wenn Du eine andere Maschine zur Verfügung hast, dann solltest Du keinen der beiden Server nehmen. Viele Grüße olc

Hallo, vielleicht kannst Du ja noch einmal etwas genau das Problem beschreiben, so etwa die genaue Fehlermeldung bei einem Zugriff. How to ask a question Viele Grüße olc

Moin, interessant, wußte nicht, daß die Session "0" ab 2008 nur noch Diensten vorbehalten ist. Vielen Dank für den Link. Wie oben angesprochen sehe ich jedoch den zweiten Punkt immer noch für eine interaktive Installation sprechen. Das mag in einer Vielzahl von Konstellationen nicht unbedingt notwendig sein, ist jedoch auch sicher nicht verkehrt. Oder ich bin einfach zu "altbacken". ;) Viele Grüße olc

Hi, schau auch einmal hier hinein: https://www.mcseboard.de/windows-forum-lan-wan-32/smb-transfer-stoppt-1-minute-160231.html Viele Grüße olc

Hi, das Problem hat nichts mit der PKI als solches zu tun. Die Dateien wurden mit einem bestimmten File Encryption Key (FEK) gesichert und die nun fehlenden Zertifikate zum Entschlüsseln dieses FEK stehen nun nicht mehr zur Verfügung. Denn diese liegen / lagen auf dem 2003er SBS. Ich hatte eigentlich im Hinterkopf, daß das File Server Migration Tool darauf hinweist, aber da kann ich mich auch irren. Habt Ihr den alten DRA bzw. dessen Zertifikat + privaten Schlüssel vielleicht gesichert? Hier noch einige EFS Recovery Basics: Windows Server How-To Guides: EFS Recovery – oder: Vorsorge ist alles - ServerHowTo.de Viele Grüße olc

Hi Iceteebee und willkommen an Board, :) grundsätzlich sollten die meisten Installationen auch über RDP problemlos laufen. Am besten mit dem "/admin" Schalter in der Session 0, damit Du alle Meldungen siehst, die Du auch interaktiv sehen würdest. Nichtsdestotrotz würde ich persönlich die Installation nicht per RDP machen, wenn es sich vermeiden läßt. Erstens weil man sicherstellen muß, wirklich immer in der Session "0" zu sein, um alle Meldungen zu sehen, siehe dazu auch: Using Remote Desktop for Administration for remote server administration: Terminal Services Client (Remote Desktop) ganz unten. Bei administrativen Remote Desktop Sessions kommst Du mit dem /admin Schalter bzw. früher /console dort hinein, bei Terminal Servern ist das zumindest über normale TS Sessions nicht so einfach möglich. Dort mußt Du dann auch die administrativen RDP Sessions nutzen. Zweitens stehen ganz praktische Erwägungen im Vordergrund, so etwa daß diverse Installationen die Netzwerkverbindung unterbrechen können oder aber normale Netzwerkverbindungsabbrüche. Das kann dann durchaus Einfluß auf die Installation bzw. deren Überwachung haben. Ich habe auch einmal Probleme gesehen, die durch die Installation eines Service Packs für Windows Server 2003 in einer RDP Session zustande kamen. Leider bekomme ich den Hintergrund davon gerade nicht mehr zusammen; wenn es mir doch noch einfallen sollte, dann melde ich mich. ;) Viele Grüße olc

Hi, EFS verschlüsselt Daten auf Netzlaufwerken "neu", d.h. diese werden beim Transport vom CLient zum Server entschlüsselt übertragen und auf dem Server neu verschlüsselt. Hierzu wird auf dem Server für jeden Benutzer ein eigenes Verzeichnis angelegt, in dem das Schlüsselmaterial liegt. Dieses Schlüsselmaterial ist bei der Migration nicht übernommen worden, daher können die Daten nicht entschlüsselt werden. The Encrypting File System Habt Ihr das Zertifikat des Data Recovery Agents vor der Migration gesichert (erster Administrato der Domäne, liegtim Profil des Administrators)? Falls ja, könntet Ihr die Daten damit entschlüsseln. Wie genau wurden die EFS Daten auf den neuen Server übertragen? Migrieren von EFS-Dateien und -Zertifikaten Viele Grüße olc

Hi, versuche es einmal mit dem Schalter /RU "" Damit sollte der Task im SYSTEM Kontext laufen. Viele Grüße olc

Hi, so wie ich es verstanden habe geht es um den Neuverkauf von Office Versionen, die von diesem Patent / dieser Technik betroffen sind. D.h. schon verkaufte Versionen sind nach derzeitigem Kenntnisstand nicht von irgendwelchen Problemen betroffen. Da MS schon vor einiger Zeit angekündig hat, daß es bei einem entsprechenden Urteil a) neue Office 2007 Versionen zu verkaufen, die nicht von dem Patent / Urteil betroffen sind und b) bald Office 2010 ansteht, welches von dem Patent nicht betroffen ist, verstehe ich ganz ehrlich gesagt die Panikmache in diesem Thread nicht. Viel interessanter ist die Frage, inwieweit das Patent nicht nur die konkrete Word Implementierung betrifft, sondern vielmehr alle XML-basierten Austauschformate für Dokumente, die den Inhalt von Strukturelementen getrennt bearbeiten läßt (wie es eben bei XML-Daten üblich ist). Dann sind nämlich generell Formate wie MS DOCX oder aber auch das ODF Format betroffen. Darüber könnte man sich meiner Meinung nach Sorgen machen. Aber so ist das eben mit dem Patentwesen: Die Geister, die ich rief... Viele Grüße olc

Hi, die Lösungen findest Du in den ersten Antworten. Du mußt sie nur noch verstehen. ;) Viele Grüße olc

Hallo, es sind einige Schritte erforderlich, um eine CA außer Betrieb zu nehmen. Neben dem Technet Artikel gibt es hier auch noch einige Hinweise: How to decommission a Windows enterprise certification authority and how to remove all related objects from Windows Server 2003 and from Windows Server 2000 Die aufgeführten Schritte gelten auch für 2008 / 2008 R2. Viele Grüße olc

Hallo, ich wüde vermuten, daß die SYSVOL Objekte shlichtweg unsauber gelöscht wurden und die AD Objekte der GPOs weiterhin existieren. Daher die Fehlermeldungen. Das bedeutet übrigens, daß die Clients KEINE neuen GPOs bzw. neuen GPO Einstellungen bekommen haben, seitdem dieser Zustand so existiert. Nur die vor dem Fehler vorhandenen GPOs werden beibehalten. Es wäre also höchste Zeit zum Beheben des Problems... Du mußt also die Policies im AD suchen, die keinen SYSVOL Teil mehr haben, um diese dann etweder korrekt wiederherzustellen oder aber ie AD Teile zu löschen bzw. zumindest die Verlinkungen zu entfernen. Recht schnell läßt sich das herausfinden mit "GPOTOOL.EXE" aus demn 2003er Resource Kit Tools. Das hat übrigens wahrscheinlich nic´hts mit dem /PUREMUPCACHE zu tun, vielleicht macht es also Sinn, den Thread zu teilen. Die ganze AD-Verwaltung sieht mir persönlich etwas schlech verwltet aus - vielleicht sollte man hier ansetzen und das Thema einmal grundsätzlich ändern... Viele Grüße olc

Hi, bitte beschreib noch einmal etwas genauer, was das Problem ist. Aus der Beschreibung wird man nicht schlau in Bezug auf die Frage, wie Ihr genau die Zertifikatdienste neu eingerichtet habt, was mit der alten Installation passiert ist und welche Zertifikate nun scheinbar weiter "verteilt" werden bzw. was "verteilt werden" überhaupt heißt. Ich denke, danach wird man Dir besser helfen können. :) How to ask a question Viele Grüße olc

Hi, Du weißt, daß da noch weiterführende Aufgaben zu erledigen sind? Das reine Umbenennen reicht nicht aus. Performing the Upgrade or Migration Viele Grüße olc

Hi Chris, nein, von 2003 auf 2008 kannst Du den Namen nicht ändern. Du könntest aber von 2003 uf 2008 wechseln und dann die CA umbenennen. Viele Grüße olc

Hi, solange sie eine gültige CRL oder Delta CRL haben, bekommen sie keine Probleme. Sollte jedoch der Ablauf der CRLs genau in den Migrationszeitraum fallen, dann wird das problematisch, da dann kein CDP erreichbar ist. Ich würde Dir empfehlen das Vorgehen im "Trockenen" zu üben (in einer abgeschotteten VM zum Beispiel) und erst dann durchzuführen, wenn Du damit vertraut bist. Generell ist das im Normalfall weniger problematisch, aber Fehler sind ja wie immer nicht auszuschließen. Wenn alles gut vorbereitet ist, dann ist das im Normalfall eine Sache von 20 Minuten - und in diesen 20 Minuten sollte es im Normalfall zu keinen größeren Problemen kommen. Viele Grüße olc

Hi, eine CA auf einem DC zu installieren sollte man wenn möglich immer vermeiden - ich würde fast soweit gehen und sagen, daß das ein "no go" ist. Du nimmst also am besten einen neuen Server und migrierst dann die CA: How to move a certification authority to another server Viele Grüße olc