Rotwilderer

Nachdem ich das angeforderte Zertifikat von der root CA expoortiert und bei der ausstellenden CA von Hand installiert habe, hat es funktioniert. Wundert mich nur, dass das nirgends so beschrieben ist.

Hallo zusammen, ich habe eine Root CA und eine Ausstellenden Zertfizierungsstelle, beide laufen unter Windows 2008 R2. Da das Zertifikat der ausstellenden CA bald abläuft, will ich dieses erneuern. Ein entsprechende Anforderung habe ich and die Root CA nach dieser Anleitung gestellt: https://technet.microsoft.com/de-de/library/cc962077.aspx An der root CA kommt die Anforderung auch an und ich kann das Zertifikat ausstellen, allerdings erhält die anfordernde CA das neue Zertifikat nicht. Ich habe die Anforderung auch mal offline mit einer req-Datei gestellt - gleiches Ergebnis. Der Zertifikatsdienst wurde auch vorher beendet, Server habe ich auch mal neu gestartet. Muss ich das ausgestellte Zertifikat noch irgendwie manuelle importieren oder was hab ich sonst falsch gemacht?

Hallo zusammen, seit ein paar Tagen erhalte ich auf einem unserer RODC Server folgende Fehlermeldungen: Protokollname: Directory Service Quelle: Microsoft-Windows-ActiveDirectory_DomainService Datum: 17.08.2016 16:38:54 Ereignis-ID: 2904 Aufgabenkategorie:Konsistenzprüfung Ebene: Fehler Schlüsselwörter:Klassisch Benutzer: ANONYMOUS-ANMELDUNG Computer: Server.domäne.local Beschreibung: Dieses Ereignis dokumentiert zusätzliche REPAIR PROCEDURES zum Auflösen des NTDS KCC-Ereignisses 1311 für einen schreibgeschützten Active Directory- Domänencontroller. Lokale Website: CN=Erkrath,CN=Sites,CN=Configuration,DC=drahtundschutz,DC=local Benutzeraktion: Die Benutzeraktion zum Auflösen des NTDS KCC-Ereignisses 1311 für einen schreibgeschützten Active Directory-Domänencontroller ist mit dem Aktionsplan für einen (vollständig) schreibbaren Active Directory-Domänencontroller identisch, jedoch mit den folgenden Zusatzanforderungen: 1. Wenn das NTDS KCC-Ereignis 1789 direkt neben den NTDS KCC-Ereignissen 1311 und NTDS KCC 2904 protokolliert wird, verwenden Sie das Snap-In "Active Directory-Standorte und -Dienste" mit Fokus auf einem schreibbaren Active Directory-Domänencontroller, um diese Website einem entsprechenden Websitelink hinzuzufügen, und führen Sie dann die Schritte 4 und 5 aus. 2. Das Ereignis 1311 kann zahlreiche Ursachen besitzen. Führen Sie den Aktionsplan im Link "Onlinehilfe des Ereignisprotokolls" eines benachbarten Ereignisses vom Typ 1311 aus. Weitere Informationen finden Sie möglicherweise unter http://support.microsoft.com, oder rufen Sie den MSKB-Artikel "http://support.microsoft.com/default.aspx?scid=kb;EN-US;307593" auf. 3. Alle Korrekturen zur Auflösung des Ereignisses 1311 müssen auf einem Active Directory-Domänencontroller vorgenommen werden, auf dem eine schreibbare Kopie der Active Directory-Partition oder der zu ändernden Gruppenrichtlinie gehostet wird. 4. Wenn der schreibgeschützte Active Directory-Domänencontroller, von dem das Ereignis 2904/1311 protokolliert wird, über keinen gültigen "repsFrom"- Active Directory-Quelldomänencontroller verfügt, führen Sie den folgenden Befehl aus, andernfalls setzen Sie den Vorgang mit Schritt 5 fort: [Hinweis: Für diesen Schritt sind Anmeldeinformationen als Organisationsadministrator erforderlich.] repadmin /add <DN der aktualisierten Active Directory- Partition> <Name des schreibgeschützten Active Directory- Domänencontrollers> <vollqualifizierter Computername des schreibbaren Active Directory-Domänencontrollers> /readonly /selsecrets 5. Lösen Sie die Replizierung vom schreibbaren, in den vorherigen Schritten aktualisierten Active Directory-Domänencontroller auf den schreibgeschützten Active Directory-Domänencontroller mit dem folgenden Befehl aus: [Hinweis: Für diesen Schritt sind Anmeldeinformationen als Organisationsadministrator erforderlich.] repadmin /replicate <Name des schreibgeschützten Active Directory-Domänencontrollers> <Name des schreibbaren Active Directory-Domänencontrollers> <DN der aktualisierten Active Directory-Partition> OR Sie können auch die Benutzeroberfläche von Active Directory-Standorte und -Dienste verwenden, indem Sie die folgenden Schritte ausführen: - Klicken Sie auf die Website mit diesem schreibgeschützten Active Directory-Domänencontroller. - Klicken Sie auf die Konfiguration der Replikation vom/zum ausgewählten Active Directory-Domänencontroller. Protokollname: Directory Service Quelle: Microsoft-Windows-ActiveDirectory_DomainService Datum: 17.08.2016 16:38:54 Ereignis-ID: 1311 Aufgabenkategorie:Konsistenzprüfung Ebene: Fehler Schlüsselwörter:Klassisch Benutzer: ANONYMOUS-ANMELDUNG Computer: server.domäne.local Beschreibung: Die Konsistenzprüfung hat Probleme mit der folgenden Verzeichnispartition festgestellt. Verzeichnispartition: CN=Configuration,DC=domäne,DC=local Es gibt für die Konsistenzprüfung nicht genügend Standortskonnektivitätsinformationen, um eine umfassende Gesamtstruktur-Replikationstopologie zu erstellen. Zudem besteht die Möglichkeit, dass mindestens ein Verzeichnisserver mit dieser Verzeichnispartition nicht in der Lage war, die Verzeichnispartitioninformationen zu replizieren. Dies liegt vermutlich an nicht zugreifbaren Verzeichnisservern. Benutzeraktion Führen Sie einen der folgenden Schritte aus: - Veröffentlichen Sie genügend Informationen über Standortkonnektivität, sodass die Konsistenzprüfung eine Route ermitteln kann, durch die die Verzeichnispartition diesen Standort erreichen kann. Diese Option wird empfohlen. - Fügen Sie von einem Verzeichnisdienst mit derselben Verzeichnispartition auf einem anderen Standort ein Verbindungsobjekt zu einem Verzeichnisdienst mit der Verzeichnispartition an diesem Standort hinzu. Wenn keine dieser beiden Aufgaben den Problemzustand behebt, überprüfen Sie die bisher durch die Konsistenzprüfung protokollierten Ereignisse, die die nicht zugreifbaren Verzeichnisserver identifizieren. Des Weitern wird der Standortübergreifende Messagindienst nicht automatisch gestartet, dies funktioniert nur manuell. Zu meiner Umgebung: Alle Server laufen unter W 2008 R2, Domäne 2008 R2 Ich habe 3 Schreibbare DCs am Hautpstandort und an 3 Niederlassungen jeweils 1 RODC. Die Replikaton schien auf dem betroffenen RODC aber einwandfrei zu laufen, auch das AD Replication Stauts tool hat keine Fehler erkannt. Ich habe, wie in den Fehlermeldungen vorgeschlagen, ein repadmin /add Befehl abgesetzt, ich erhalte aber die Meldung: DsBindWithCred mit rodc.domäne.lokal ist fehlgeschlagen mit Status 1 722 (0x6ba): Der RPC-Server ist nicht verfügbar. Der Fehler tritt seit dem letzten Microsoft Update auf, nachdem der Server neu gestartet wurde. Auf den anderen RODCs wurden die selben Updates gefahren, dort funktioniert aber alles.

Hallo, ich versuche in meiner Testumgebung unter Windows 2012 R2 eine Domäne mit der Powershell aufzusetzen, die Domänendienste wurden bereits erfolgreich installiert. Jetzt habe ich versucht, die Umgebung mit folgendem Befehl zu testen: Test-ADDSForestInstallation -DomainName "corp.contoso.com" -NoRebootOnCompletion Nach Bestätigung mit Enter erscheint folgende Eingabeaufforderung: SafeModeAdministratorPassword: Wenn ich nun ein von mir gewähltes Passwort eingebe, erscheint nach Drücken der Enter-Taste folgende Fehlermeldung: Test-ADDSForestInstallation : Es wurde kein Positionsparameter gefunden, der das Argument "SafeModeAdministratorPassword bestätigen" akzeptiert. In Zeile:1 Zeichen:1 + Test-ADDSForestInstallation -DomainName "corp.contoso.com" -NoRebootOnCompletion + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidArgument: (:) [Test-ADDSForestInstallation], ParameterBindingException + FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.DirectoryServices.Deployment.PowerShell.Commands.T estADDSForestInstallationCommand Ich habe auch schon mehrere Passwörter probiert und ja, natürlich auch mal neu gestartet und die Powershell mit Adminrechten gestartet, aber es funktioniert nicht. Normalerweise müsste doch nach der Eingabe des Passworts eine Bestätigung angefordert werden.

So, ich habe das Problem gelöst: Es lag an der Kryptographie, ich habe den falschen Algrorythmus ausgewählt. Standardmäßig wird bei der Erstellung der Zertfikatsvorlage immer der RSA Algorythmus eingestellt, es wird aber für EFS eine ECC Kryptographie gefordert: https://technet.microsoft.com/de-de/library/dd630631%28v=ws.10%29.aspx Drauf gekommen bin ich über folgenden Beitrag: http://www.journeyofthegeek.com/?p=137 Am Ende dieses Artikels stand der entscheidene Hinweis.

Ich meinte natürlich EFs Recovery Agent. Habe ich woh in der Aufregung durcheinander gebracht. :) Wie dem auch sei, ich habe mir die von dir geposteten Artikel druchgelesen. Dort ist beschrieben, dass der erste Dom-Admin der die Domäne erstellt hat, das EFS-RA Zertifikat automatisch erstellt bekommt. Da ich die Domäne von meinem Vorgänger geerbt habe kann ich nicht mit gewissheit sagen, welcher User das ist. Ich habe auf jeden Fall bei allen in frage kommenden Accounts die Zertifikatsspeicher auf dem ersten DC durchsucht, habe aber kein Zertifikat gefunden. Funktioniert das ganze denn noch wenn ich diesen Schlüssel bzw. das Zertifikat nicht mehr habe? Ich habe das entsprechende EFS-RA Zertifikat angefordert und exportiert, es dann inder Gruppenrichtlinie direkt importiert. Es wird der Account mit dem Zertifikat auf angezeigt. Ich erhalte beim Verschlüsseln aber immer noch die Meldung: Falscher Parameter!

Ja, einen Key Recovery Agent habe ich aus der Vorlage "Key Recovery Agent" erstellt, d.h. der Dom-Admin hat das Zertifikat angefordert und ich habe diesen User in der Gruppenrichtlinie unter Computerkonfiguration => Richtlinien => Windows Einstellungen => Sicherheitseinstellungen => Richlinien für öffentliche Schlüssel => "Verschlüsselndes Dateisystem" "Datenwiederherstellungs Agent hinzufügen" hinzugefügt und das entsprechende Zertifikat ausgewählt. (Siehe Oben). Wenn der selbe User allerdings verucht unter dem gleichen Pfad die Option "Datenwiederherstellungs Agent erstellen" anwähle, dann bekommte ich di oben genannte Fehlermeldung. Wo liegt denn eingentlich der Unterschied zwischen erstellen und hinzufügen?

Ich habe jetzt noch mal ein bisschen selbst rumprobiert und mit ist aufgefallen, dass die Schlüssel für die angeforderten Zertifikate nicht archiviert werden, obwohl ich die Schlüsselarchvierung aktiviert habe (KRA eingerichtet, Zertfikat wird als "Gültig" angezeigt). In den Vorlagen habe ich ebenfalls die Haken "Privaten Schlüssel für die Verschlüsselung archivieren" und "Erweiterten symmetrischen Algorythmus zum senden des Schlüssels an die Zertifierungsstelle verwenden" gesetzt. In der Ansicht "Ausgestellte Zertifikate" erscheint bei den aus den oben genannten Vorlagen erstellten Zertifikaten in der Spalte "Archivierter Schlüssel" kein Eintrag. Vielleicht ist das auch die Ursache, warum die Verschlüsselung nicht funktioniert. Weiß hier jemand woran das liegen kann?

Hat denn keiner dazu eine Idee?

Hallo zusammen, ich habe eine W2K8 R2 Domäne und möchte darüber die EFS Verschlüsselung einrichten. Folgendes habe ich durchgeführt: Zertifizierungsstelle ist eingerichtet KRA Zertifikat wurde ausgestellt und vom Dom-Admin angefordert EFS-Zertifkat (Verschlüsselndes Dateisystem) wurde mit folgenden Parametern ausgestellt: Vorlage für windows Server 2008 Enterprise Zertifikat in Active Directory veröffentlichen Autoenrollment für authentfizierte Benutzer unter "Sicherheit" angehakt Zertifikat für Schlüsselweiderherstellung mit den gleichen Einstellungen (Außer Berechtigungen, die habe ich nur für die Domänen-Admins gesetzt) Datei-Wiederherstellung-Agent hinzugefügt Gruppenrichtlinie in der Root der Domäne für EFS konfiguriert und das zuor ausgestellt Zertifikat für die EFS-Verschlüsselung angegben Wenn ich nun an einem Client versuche einen Ordner/Datei zu verschlüsseln, erscheint folgende Fehlermeldung: Beim Übernehmen der Attribute für die Datei ist ein Fehler aufgetreten: Dateipfad/Name Falscher Parameter. Das EFS-Zertifikat wird aber vom Client abgerufen, es erscheint auch im Zertifikatsspeicher. Ich habe den Verdacht, dass es am Wiederherstellungs-Agenten liegt. Wenn ich unter "Verschlüsseltes Dateisystem" einen Weiderherstellungs-Agenten erstelle, wird dieser mit dem Standard EFS-Wiederherstellungs-Agent Zertifikat angelegt. Lösche ich dieses, kann der Wiederherstellungsagent nicht erstellt werden, es kommt die Fehlermeldung: Es kann kein Datenwiederherstellungs-Agent erstellt werden. Die angeforderte Zertfikatvorlage wird von dieser Zertifizierungsstelle nicht unterstützt. Wenn ich einen Datenwiederherstellungs-Agent hinzufüge, klappt dies wunderbar mit dem zufor erstellten und angefordertem Zertifikat. Mit stellt sich dann außerdem die Frage, was der Unterschied zwischen einem Wiederherstellungs-Agent hizufügen und erstellen ist?

Ich habe den Fehler selbst gefunden: In der Gruppenrichtlinie war nicht das richtige Zertifikat hinterlegt, dadurch hat sich der Client ein selbstsigniertes Zertifikat ausgestellt.

Hallo zusammen, ich würde in usnerem Unternehmen gerne auf verschiedenen Lapots über EFS Dateien verschlüsseln, die von verschiedenen Domänen-Administratoren wiederhergestellt bzw. entschlüsselt werden können sollen. Wir haben eine Windows 2008R2 Domäne mit Windows 7 Clients. Folgendes habe ich bisher eingerichtet: Eine austellende Zertifizierungsstelle, die die Zertifiakte ausstellt, ist eingerichtet. Zertifikate für die EFS-Wiederherstellung wurden erstellt und von dem jeweiligen Administrator angefordert. Es wurde auf oberster Domänenebene eine Gruppenrichtlinie eingerichtet, in welcher unter "Richtlinien für öffentliche Schlüssel" => "Verschlüsselndes Dateisystem" die Administatoren als Wiederherstellungs-Agenten hinzugefügt wurden. Wenn auf einem Client nun eine Datei verschlüsselt wird, könne die oben genannt hinterlegten Administratoren die Dateien trotzdem nicht entschlüsseln? Was habe ich vergessen oder könnte ich übersehen haben?

Danke für die Antworten. Ich habe es schon befürchtet, dass es keine technische Lösung gibt. Es ist leider vereinzelt vorgekommen, dass einige (wenige) Benutzer das Notebook aus der Domäne genommen haben, angeblich ist es dann schneller :confused: . Der User dein Feind... :D Mit ist bekannt, dass dies möglich ist. Allderings sind gerade die älteren Programme, die über verschiedene Schnittstellen mit Anlagen kummunizieren, ohne Adminrechte recht "zickig".

Hallo zusammen, wir haben in unserer Firma mehrere Notebooks von Aussendienst Mitarbeitern, die aus verschiedenen Gründen lokale Adminrechte benötigen. Leider haben die Benutzer auch damit das Recht, den Computer aus der Domäne zu entfernen. Wie kann man das deaktivieren bzw. die Benutzerrechte so ändern, dass nur Domänen-Admins die Computer aus der Domäne entfernen können?

Man kann es kaum glauben, aber ich habe die Installation doch noch auf dem RODC hinbekommen! Für die Installation des SQL muss im AD folgende Gruppe erstellt und auf den RODC repliziert werden: SQLServer2005SQLBrowserUser$Servername Für die Installation des WSUS müssen folgende Gruppen erstellt und repliziert werden: WSUS-Administratoren WSUS-Berichterstatter Diese beiden Gruppen scheinen aber nur für Windows 2008 R2 zu gelten, under 2012 R2 heißen diese: WSUS Administrators WSUS Reporters Vielen Dank an Daniel für den Hinweis mit den SQL-Sicherheitsgruppen und an Alle, die sich mit eingebracht haben.

Leider schlägt auch die Installation des SQL-Express fehl, Fehlermeldung: Erforderliche Aktion: Beheben Sie den Fehler mithilfe der folgenden Informationen, deinstallieren Sie die Funktion, und führen Sie den Setupvorgang dann erneut aus. Ursache für Funktionsfehler: Da eine Abhängigkeit der Funktion einen Fehler verursacht hat, war der Setupvorgang für die Funktion nicht erfolgreich. Es scheint so, als ab auf dem RODC kein SQL-Server installiert werden kann. Fehlerdetails: § Fehler beim Installieren von SQL Server-Browser Die Anforderung wird nicht unterstützt. Fehlercode: 0x84BB0001 Hier die Zusammenfassungsprotokolldatei: Overall summary: Final result: Fehler: Ausführliche Informationen finden Sie unten Exit code (Decimal): -2068119551 Start time: 2015-09-18 12:35:51 End time: 2015-09-18 13:14:13 Requested action: Install Setup completed with required actions for features. Troubleshooting information for those features: Next step for SQLEngine: Beheben Sie den Fehler mithilfe der folgenden Informationen, deinstallieren Sie die Funktion, und führen Sie den Setupvorgang dann erneut aus. Next step for Replication: Beheben Sie den Fehler mithilfe der folgenden Informationen, deinstallieren Sie die Funktion, und führen Sie den Setupvorgang dann erneut aus. Next step for Browser: Beheben Sie den Fehler mithilfe der folgenden Informationen, deinstallieren Sie die Funktion, und führen Sie den Setupvorgang dann erneut aus. Machine Properties: Machine name: Servername Machine processor count: 4 OS version: Windows Server 2008 R2 OS service pack: Service Pack 1 OS region: Deutschland OS language: Deutsch (Deutschland) OS architecture: x64 Process architecture: 64 Bit OS clustered: Nein Product features discovered: Product Instance Instance ID Feature Language Edition Version Clustered Package properties: Description: Microsoft SQL Server 2012 Service Pack 1 ProductName: SQL Server 2012 Type: RTM Version: 11 SPLevel: 0 Installation location: d:\43a6ddaadaeef15a4db1ddd7\x64\setup\ Installation edition: Express Product Update Status: Keine ermittelt. Benutzereingabeeinstellungen: ACTION: Install ADDCURRENTUSERASSQLADMIN: true AGTSVCACCOUNT: NT-AUTORITÄT\NETZWERKDIENST AGTSVCPASSWORD: ***** AGTSVCSTARTUPTYPE: Disabled ASBACKUPDIR: Backup ASCOLLATION: Latin1_General_CI_AS ASCONFIGDIR: Config ASDATADIR: Data ASLOGDIR: Log ASPROVIDERMSOLAP: 1 ASSERVERMODE: MULTIDIMENSIONAL ASSVCACCOUNT: <leer> ASSVCPASSWORD: <leer> ASSVCSTARTUPTYPE: Automatic ASSYSADMINACCOUNTS: <leer> ASTEMPDIR: Temp BROWSERSVCSTARTUPTYPE: Disabled CLTCTLRNAME: <leer> CLTRESULTDIR: <leer> CLTSTARTUPTYPE: 0 CLTSVCACCOUNT: <leer> CLTSVCPASSWORD: <leer> CLTWORKINGDIR: <leer> COMMFABRICENCRYPTION: 0 COMMFABRICNETWORKLEVEL: 0 COMMFABRICPORT: 0 CONFIGURATIONFILE: CTLRSTARTUPTYPE: 0 CTLRSVCACCOUNT: <leer> CTLRSVCPASSWORD: <leer> CTLRUSERS: <leer> ENABLERANU: true ENU: false ERRORREPORTING: false FEATURES: SQLENGINE, REPLICATION, SNAC_SDK FILESTREAMLEVEL: 0 FILESTREAMSHARENAME: <leer> FTSVCACCOUNT: <leer> FTSVCPASSWORD: <leer> HELP: false IACCEPTSQLSERVERLICENSETERMS: false INDICATEPROGRESS: false INSTALLSHAREDDIR: C:\Program Files\Microsoft SQL Server\ INSTALLSHAREDWOWDIR: C:\Program Files (x86)\Microsoft SQL Server\ INSTALLSQLDATADIR: <leer> INSTANCEDIR: D:\SQL-Datenbanken INSTANCEID: WSUS_ERKRATH INSTANCENAME: WSUS_ERKRATH ISSVCACCOUNT: NT AUTHORITY\Network Service ISSVCPASSWORD: <leer> ISSVCSTARTUPTYPE: Automatic MATRIXCMBRICKCOMMPORT: 0 MATRIXCMSERVERNAME: <leer> MATRIXNAME: <leer> NPENABLED: 0 PID: ***** QUIET: false QUIETSIMPLE: false ROLE: AllFeatures_WithDefaults RSINSTALLMODE: DefaultNativeMode RSSHPINSTALLMODE: DefaultSharePointMode RSSVCACCOUNT: <leer> RSSVCPASSWORD: <leer> RSSVCSTARTUPTYPE: Automatic SAPWD: ***** SECURITYMODE: SQL SQLBACKUPDIR: <leer> SQLCOLLATION: Latin1_General_CI_AS SQLSVCACCOUNT: NT Service\MSSQL$WSUS SQLSVCPASSWORD: <leer> SQLSVCSTARTUPTYPE: Automatic SQLSYSADMINACCOUNTS: Domäne\Benutzername SQLTEMPDBDIR: <leer> SQLTEMPDBLOGDIR: <leer> SQLUSERDBDIR: <leer> SQLUSERDBLOGDIR: <leer> SQMREPORTING: false TCPENABLED: 0 UIMODE: AutoAdvance UpdateEnabled: true UpdateSource: MU X86: false Configuration file: C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\Log\20150918_122737\ConfigurationFile.ini Detailed results: Feature: Database Engine Services Status: Fehler. Ausführliche Informationen finden Sie in den Protokollen Reason for failure: Da eine Abhängigkeit der Funktion einen Fehler verursacht hat, war der Setupvorgang für die Funktion nicht erfolgreich. Next Step: Beheben Sie den Fehler mithilfe der folgenden Informationen, deinstallieren Sie die Funktion, und führen Sie den Setupvorgang dann erneut aus. Component name: SQL Server-Browser Component error code: 0x84BB0001 Error description: Die Anforderung wird nicht unterstützt. Error help link: http://go.microsoft.com/fwlink?LinkId=20476&ProdName=Microsoft+SQL+Server&EvtSrc=setup.rll&EvtID=50000&ProdVer=11.0.3128.0&EvtType=0x34D926F9%400xBC427EF5&EvtType=0x34D926F9%400xBC427EF5 Feature: SQL Server-Replikation Status: Fehler. Ausführliche Informationen finden Sie in den Protokollen Reason for failure: Da eine Abhängigkeit der Funktion einen Fehler verursacht hat, war der Setupvorgang für die Funktion nicht erfolgreich. Next Step: Beheben Sie den Fehler mithilfe der folgenden Informationen, deinstallieren Sie die Funktion, und führen Sie den Setupvorgang dann erneut aus. Component name: SQL Server-Browser Component error code: 0x84BB0001 Error description: Die Anforderung wird nicht unterstützt. Error help link: http://go.microsoft.com/fwlink?LinkId=20476&ProdName=Microsoft+SQL+Server&EvtSrc=setup.rll&EvtID=50000&ProdVer=11.0.3128.0&EvtType=0x34D926F9%400xBC427EF5&EvtType=0x34D926F9%400xBC427EF5 Feature: SQL Browser Status: Fehler. Ausführliche Informationen finden Sie in den Protokollen Reason for failure: Fehler während des Setupvorgangs für die Funktion. Next Step: Beheben Sie den Fehler mithilfe der folgenden Informationen, deinstallieren Sie die Funktion, und führen Sie den Setupvorgang dann erneut aus. Component name: SQL Server-Browser Component error code: 0x84BB0001 Error description: Die Anforderung wird nicht unterstützt. Error help link: http://go.microsoft.com/fwlink?LinkId=20476&ProdName=Microsoft+SQL+Server&EvtSrc=setup.rll&EvtID=50000&ProdVer=11.0.3128.0&EvtType=0x34D926F9%400xBC427EF5&EvtType=0x34D926F9%400xBC427EF5 Feature: SQL Writer Status: Erfolgreich Feature: SQL-Clientkonnektivität Status: Erfolgreich Feature: SQL Client Connectivity SDK Status: Erfolgreich Feature: Setup-Unterstützungsdateien Status: Erfolgreich Rules with failures: Global rules: Scenario specific rules: Rules report file: C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\Log\20150918_122737\SystemConfigurationCheck_Report.htm

OK, ich werde es probieren und dann berichten.

Könnte ich Probieren, wollte aber eigentlich den Server so schlank wie möglich halten und auf die SQL-Server Installation verzichten.

Ja, die Gruppen sind da.

Hallo zusammen, ich will auf unseren Außenstandorten WSUS auf den jeweiligen DCs (W2k8 R2) installieren, diese sind alle als RODC eingerichtet. Die Installation schlägt aber Fehl und bleibt bei der Installation der "Windows Internal Database" stehen. Fehlermeldung: Windows Server Update Services 3.0 SP2 konnte Windows Internal Database nicht installieren. Weitere Informationen erhalten Sie im Setup-Protokoll "C:\Users\username\AppData\Local\Temp\WSUSSetup.log". Hier das zugehörige Log-File: 2015-09-18 09:49:55 Success MWUSSetup Detected that setup was launched through Server Manager 2015-09-18 09:49:56 Success MWUSSetup Validating pre-requisites... 2015-09-18 09:49:56 Error MWUSSetup Failed to determine if an higher version of WSUS is installed. Assuming it is not... (Error 0x80070002: Das System kann die angegebene Datei nicht finden.) 2015-09-18 09:49:56 Error MWUSSetup WSUS is outdated. But this will not block setup (Error 0x00000000: Der Vorgang wurde erfolgreich beendet.) 2015-09-18 09:49:59 Success MWUSSetup ReportViewer is not installed on this machine 2015-09-18 09:49:59 Success MWUSSetup ReportViewer is not installed on this machine 2015-09-18 09:50:02 Success MWUSSetup No SQL instances found 2015-09-18 09:50:07 Success MWUSSetup Initializing installation details 2015-09-18 09:50:07 Success MWUSSetup Skipping Asp.Net install since not running on win2k3... 2015-09-18 09:50:07 Success MWUSSetup Installing wYukon using ocsetup 2015-09-18 09:50:07 Success MWUSSetup Installing Windows Internal database using ocsetup with command line as "ocsetup "WSSEE" /quiet /norestart" 2015-09-18 09:50:39 Error MWUSSetup The process ocsetup "WSSEE" /quiet /norestart returned error: 0x643 (Error 0x80070643: Schwerwiegender Fehler bei der Installation.) 2015-09-18 09:50:39 Error MWUSSetup ExecCmd failed (Error 0x80070643: Schwerwiegender Fehler bei der Installation.) 2015-09-18 09:50:39 Error MWUSSetup Install Windows Internal database: Failed to execute "ocsetup "WSSEE" /quiet /norestart" (Error 0x80070643: Schwerwiegender Fehler bei der Installation.) 2015-09-18 09:50:39 Error MWUSSetup CInstallDriver::PerformSetup: Installation of wYukon failed (Error 0x80070643: Schwerwiegender Fehler bei der Installation.) 2015-09-18 09:50:39 Error MWUSSetup CSetupDriver::LaunchSetup: Setup failed (Error 0x80070643: Schwerwiegender Fehler bei der Installation.) Ich habe bereits die Gruppen erstellt, die in diesem Artikel beschrieben wurden: https://social.technet.microsoft.com/Forums/windowsserver/en-US/0752819f-8895-40d4-962f-9391b24b305a/wsus-30-sp1-on-rodc?forum=winserverwsus Weiß hier jemand Rat?

Hallo zusammen, ich habe folgendes Problem: Ich habe auf unserem Exchange (Version 2010 SP3) versehnetlich ein Postfach entfernt, und damit auch das AD-Konto gelöscht. Ich habe dann ein neues Konto erstellt und in der Exchange Verwaltungskonsole das Postfach unter "Getrenntes Postfach" mit dem neu erstellten Konto Verbunden. So weit, so gut. Wenn ich im Benutzerkonto in Outlook das Postfach verbinde, funktioniert dies auch, allerdings kann ich das Postfach nicht öffnen, Fehlermeldung: Ihre Standard-E-Mail-Ordner können nicht geöffnet werden. Microsoft Exchange ist nicht verfügbar. Es bestehen Netzwerkprobleme... Wenn ich mich versuche über OWA zu verbinden bekomme ich folgende Meldung: Ihr Konto wurde deaktiviert! Details: Request Url: https://owa.firmenname.de:443/owa/ User: Nachname, Vorname EX Address: /o=first organization/ou=exchange administrative group (fydibohf23spdlt)/cn=recipients/cn=nachname, vorname SMTP Address: vorname.nachneame@firmenname.de OWA version: 14.3.210.2 Exception Exception type: Microsoft.Exchange.Data.Storage.AccountDisabledException Exception message: Cannot open mailbox /o=first organization/ou=exchange administrative group (fydibohf23spdlt)/cn=recipients/cn=nachname, vorname. Call stack bei Microsoft.Exchange.Data.Storage.MailboxSession.ForceOpen(MapiStore linkedStore) bei Microsoft.Exchange.Data.Storage.MailboxSession.Initialize(MapiStore linkedStore, LogonType logonType, ExchangePrincipal owner, DelegateLogonUser delegateUser, Object identity, OpenMailboxSessionFlags flags, GenericIdentity auxiliaryIdentity) bei Microsoft.Exchange.Data.Storage.MailboxSession.<>c__DisplayClass12.b__10(MailboxSession mailboxSession) bei Microsoft.Exchange.Data.Storage.MailboxSession.InternalCreateMailboxSession(LogonType logonType, ExchangePrincipal owner, CultureInfo cultureInfo, String clientInfoString, IAccountingObject budget, Action`1 initializeMailboxSession, InitializeMailboxSessionFailure initializeMailboxSessionFailure) bei Microsoft.Exchange.Data.Storage.MailboxSession.CreateMailboxSession(LogonType logonType, ExchangePrincipal owner, DelegateLogonUser delegateUser, Object identity, OpenMailboxSessionFlags flags, CultureInfo cultureInfo, String clientInfoString, PropertyDefinition[] mailboxProperties, IList`1 foldersToInit, GenericIdentity auxiliaryIdentity, IAccountingObject budget) bei Microsoft.Exchange.Data.Storage.MailboxSession.ConfigurableOpen(ExchangePrincipal mailbox, MailboxAccessInfo accessInfo, CultureInfo cultureInfo, String clientInfoString, LogonType logonType, PropertyDefinition[] mailboxProperties, InitializationFlags initFlags, IList`1 foldersToInit, IAccountingObject budget) bei Microsoft.Exchange.Data.Storage.MailboxSession.Open(ExchangePrincipal mailboxOwner, WindowsPrincipal authenticatedUser, CultureInfo cultureInfo, String clientInfoString, Boolean wantCachedConnection) bei Microsoft.Exchange.Data.Storage.MailboxSession.Open(ExchangePrincipal mailboxOwner, WindowsPrincipal authenticatedUser, CultureInfo cultureInfo, String clientInfoString) bei Microsoft.Exchange.Clients.Owa.Core.OwaWindowsIdentity.CreateMailboxSession(ExchangePrincipal exchangePrincipal, CultureInfo cultureInfo, HttpRequest clientRequest) bei Microsoft.Exchange.Clients.Owa.Core.UserContext.CreateMailboxSession(OwaContext owaContext) bei Microsoft.Exchange.Clients.Owa.Core.UserContext.Load(OwaContext owaContext) bei Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.CreateUserContext(OwaContext owaContext, UserContextKey userContextKey, UserContext& userContext) bei Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.PrepareRequestWithoutSession(OwaContext owaContext, UserContextCookie userContextCookie) bei Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.AcquireAndPreprocessUserContext(OwaContext owaContext, HttpRequest request) bei Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.InternalDispatchRequest(OwaContext owaContext) bei Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.DispatchRequest(OwaContext owaContext) bei Microsoft.Exchange.Clients.Owa.Core.OwaRequestEventInspector.OnPostAuthorizeRequest(Object sender, EventArgs e) bei System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() bei System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) Inner Exception Exception type: Microsoft.Mapi.MapiExceptionMailboxDisabled Exception message: MapiExceptionMailboxDisabled: Unable to open message store. (hr=0x80004005, ec=2412) Diagnostic context: Lid: 55847 EMSMDBPOOL.EcPoolSessionDoRpc called [length=496] Lid: 43559 EMSMDBPOOL.EcPoolSessionDoRpc returned [ec=0x0][length=232][latency=0] Lid: 23226 --- ROP Parse Start --- Lid: 27962 ROP: ropLogon [254] Lid: 17082 ROP Error: 0x96C Lid: 26937 Lid: 21921 StoreEc: 0x96C Lid: 27962 ROP: ropExtendedError [250] Lid: 1494 ---- Remote Context Beg ---- Lid: 26426 ROP: ropLogon [254] Lid: 1219 StoreEc: 0x80070005 Lid: 3225 StoreEc: 0x8004010F Lid: 51399 Lid: 2567 StoreEc: 0x96C Lid: 19452 Lid: 2199 StoreEc: 0x96C Lid: 56415 Lid: 48223 StoreEc: 0x96C Lid: 17097 StoreEc: 0x96C Lid: 8620 StoreEc: 0x96C Lid: 1750 ---- Remote Context End ---- Lid: 26849 Lid: 21817 ROP Failure: 0x96C Lid: 26297 Lid: 16585 StoreEc: 0x96C Lid: 32441 Lid: 1706 StoreEc: 0x96C Lid: 24761 Lid: 20665 StoreEc: 0x96C Lid: 25785 Lid: 29881 StoreEc: 0x96C Call stack bei Microsoft.Mapi.MapiExceptionHelper.ThrowIfError(String message, Int32 hresult, SafeExInterfaceHandle iUnknown, Exception innerException) bei Microsoft.Mapi.ExRpcConnection.OpenMsgStore(OpenStoreFlag storeFlags, String mailboxDn, Guid mailboxGuid, Guid mdbGuid, MapiStore msgStorePrivate, String& correctServerDn, ClientIdentityInfo clientIdentityAs, String userDnAs, String applicationId, CultureInfo cultureInfo) bei Microsoft.Mapi.MapiStore.OpenMapiStore(String serverDn, String userDn, String mailboxDn, Guid guidMailbox, Guid guidMdb, String userName, String domainName, String password, String httpProxyServerName, ConnectFlag connectFlags, OpenStoreFlag storeFlags, CultureInfo cultureInfo, Boolean wantRedirect, String& correctServerDN, ClientIdentityInfo clientIdentity, String applicationId, Client xropClient, Boolean wantWebServices, Byte[] clientSessionInfo, TimeSpan connectionTimeout) bei Microsoft.Mapi.MapiStore.OpenMailbox(String serverDn, String userDn, Guid guidMailbox, Guid guidMdb, String userName, String domainName, String password, ConnectFlag connectFlags, OpenStoreFlag storeFlags, CultureInfo cultureInfo, WindowsIdentity windowsIdentity, String applicationId) bei Microsoft.Exchange.Data.Storage.MailboxSession.ForceOpen(MapiStore linkedStore) Weiß hier jemand Rat?

Ich denke, ich habe den Fehler gefunden. Ich bin bei der Installation der Office Templates nach folgender Anleitung vorgegangen: http://www.tecchannel.de/pc_mobile/windows/2038053/office_2010_sicher_mit_gruppenrichtlinien_betreiben/ Diese schein aber nicht ganz korrekt zu sein, da als Speicherort ein lokales Verzeichnis auf jedem Domänencontroller angegeben ist anstatt eines im Sysvol anzulegen. Ich konnte deswegen auf den anderern Domänencontrollern die Administrativen Vorlagen im Gruppenrichtlinieneditor gar nicht sehen. Ich habe nun im Sysvol ein zentrales Verzeichins mit den Namen "PoliceDefinitions" erstellt und dort die ADMX- und ADML-Dateien abgelelgt. Jetzt sehe ich dies Adminsitrativen Vorlagen auch auf allen DCs. ich werde nun abwarten, ob die Richtlinie jetzt auch greift. Vielen Dank auf jeden Fall für die Tipps.

Hallo Synny61, das hatte ich gemacht, steht auch in meinem Beitrag: , schon vor längerer Zeit, dh. dass dies auch schon auf die anderen DCs repliziert wurde.

Hallo zusammen, ich würde gerne über inen Gruppenrichtlinie für alle Benutzer in userer Domäne den Junk-E-Mail-Filter deaktivieren, da wir ein 3d-Party-Produkt verwenden. folgende Umgebung haben wir: Domäne Windows 2008 R2 Exchange 2010 Clients: Windows 7 SP1 32- und 64-Bit Office 2010 32 Bit Die Office Vorlagen für die Gruppenrichtlinien habe ich installiert. Folgende Einstellungen habe ich vorgenommen: Benutzerkonfiguration/Administrtive Vorlagen/Microsoft Outlook 2010/Outlook Optionen/Einstellungen/E-Mail-Optionen/Junk-E-Mail/Junk-Email-Schutzstufe: "Kein Schutz" Der Junk-E-Mail-Filter ist aber troztdem aktiv, es landen dort immer wieder Mails. Ich habe an einem Client einmal "gpresult" ausgeführt, dort werden die Office Einstellungen aber nicht direkt angezeigt, sondern nur folgendes: Zusätzl. Reg.-einst. Für einige Einstellungen konnten keine Anzeigenamen gefunden werden. Eine Aktualisierung der von der Gruppenrichtlinienverwaltung verwendeten ADM-Dateien behebt möglicherweise das Problem. Einstellung Status Ausschlaggebendes Gruppenrichtlinienobjekt software\policies\microsoft\office\14.0\common\general\optindisable 1 Office-Einstellungen software\policies\microsoft\office\14.0\outlook\discardconflicts 1 Office-Einstellungen software\policies\microsoft\office\14.0\outlook\options\mail\junkmailprotection 4294967295 Office-Einstellungen software\policies\microsoft\office\14.0\word\options\doc-path H:\ Office-Einstellungen Stutzig mach mich die 3.Zeile , die Zahl bei Status ist recht hoch. Hier noch mal gpresult in der leserlichen Version als Anhang

Danke für die vielen Antworten. Der Fehler saß, wie so oft, vor der Konsole ;) Nach längerer Wartezeit wurden die Berechtigungen gezogen.