SBK

Das Problem liegt an den Clientsicherungen, sobald man den Essentials-Dienst für die Computersicherung deaktiviert, läuft wieder alles einwandfrei. Da wir die clientsicherung sowieso nicht verwenden, spielt das keine Rolle. Gruss SBK

Hallo Leute, Ich habe gestern die Mai-Updates auf einem Server 2012 R2 installiert. Seitdem starten die Essentials Dienste (Bsp. Windows Server Essentials Dienst-Verwaltungsdienst) nicht mehr. Ich habe das Update bereits wieder deinstalliert, aber ohne Erfolg. Im Ereignisprotokoll steht lapidar: Dienst "Windows Server Essentials-Speicherdienst" wurde unerwartet beendet. Dies ist bereits 3 Mal passiert. Event-ID 7034 Neustarts und Installation des neusten Proliant Service Pack 2020.03 haben auch nichts gebracht. Der Serve läuft sonst absolut einwandfrei. Via Google bin ich nur auf folgenden Beitrag gestossen: https://social.technet.microsoft.com/Forums/ie/de-DE/e3619129-aa8e-4683-afa6-0d7ddcb534d8/dienst-windows-server-essentialsverwaltungsdienst-wurde-unerwartet-beendet-windows-server?forum=windowsserver8de Aber ein Essentials-Clientbackup habei ich nicht definiert. Hat jemand einen Idee voran es liegen oder war ich noch ausprobieren könnte? Danke und Gruss SBK

Hallo IPL, Vielen Dank für Deinen Beitrag und in der Tat besteht das Problem bei uns immer noch. Es kommt zum Glück selten vor, da erst alle Laufwerksbuchstaben vor dem R: belegt werden und sich das Phänomen nicht täglich ereignet. Ich habe das mountvol /N soeben versucht, die Laufwerksbuchstaben werden dann zwar nicht mehr zugewiesen, aber der Benutzer kann dann sein Profil auch nicht mehr laden, resp. es erscheint die Fehlermeldung nach der Anmeldung, das man mit einem temporären Profil sich angemeldet hat. Somit habe ich mit mountvol /E das Autmounting wieder aktiviert. Aber danke trotzdem und Gruss SBK

Danke NorbertFe, NilsK und Nobbyaushb für eure Antworten. Die SBS CA hat zwei Zertifikate die noch Gültigkeit haben, das sind aber Zertifikate welche der SBS als RootCA automatisch erstellt und ich jeweils erneuert habe. Ich wollte einfach auf Nummer sicher gehen, dass ich dann kein Problem im AD habe, falls die CA nicht mehr vorhanden ist. Aber die einzigen Zertifikate welche ich aktiv den Dienste zugewiesen hatte (Bsp. Exchange) hatte ich sowieso über psw.net gekauft. Noch ein Hinweis bezüglich Rolle, ich habe auf dem Server 2019 welcher als DC fungiert, die CA Rolle problemlos hinzufügen können, diese aber nun gleich wieder entfernt....

Habe mich bezüglich LDAPS gleich eingelesen, das stellt uns vor keine Probleme, wir haben keine "alte Software" welche noch LDAP verwendet. Ich hatte das missverstanden und dachte das LDAPS betreffe die Kommunikation zwischen Server<->Windows 10 Client. Also ich habe ja nun die CA Konfiguration gesichert und wenn es irgendwo ein Problem geben sollte, kann ich dann immer noch die CA installieren und die Konfiguration wiederherstellen. Eine letzte Frage bleibt, wieso soll man die CA nicht auf dem neuen DC installieren? Aus Performancegründen spielt das ja kaum eine Rolle und der SBS hatte ja alle Rollen, welche bei den "normalen" Serverversionen als No-Go gedeutet wurde (Exchange auf DC, Sharepoint auf DC und CA auf DC).

Danke Nobbyaushb. Ich habe bereits einen Exchange 2016 für die lokale Verwaltung installiert (hatte ich im Plan nicht explizit erwähnt) und auf dem Exchange2016 verwende ich ein gekauftes Zertifikat von psw.net (das war auch unter dem Exchange 2010 installiert). Insofern habe ich die CA auch nie verwendet, wusste aber nicht ob das Active Directory die CA in irgendeiner Form voraussetzt oder verwendet. Irgendwie hatte ich in Erinnerung gelesen zu haben, das Microsoft inskünftig LDAP nicht mehr unterstützt und nur noch LDAPS verwendet und man dafür ein Zertifikat benötigt. Aber vielleicht verwechsle ich da etwas. Dann riskiere ich im Active Directory nichts, wenn ich keinen neuen Zertifizierungsserver installiere und den SBS2011 deinstalliere? Bezüglich CA bin ich nicht wirklich sattelfest...

Nein, eigentlich bin ich mir gar nicht sicher ob ich diese CA überhaupt benötige. Die Dateien auf dem Fileserver wurden nie in irgendeinerweise verschlüsselt, braucht es denn nicht zwingend eine Zertifizierungsstelle im AD? In den verschiedenen Migrationsleitfaden steht jeweils die CA zu sichern, deinstallieren und dann auf dem neuen wiederherzustellen. Oder anders gefragt wie kann ich feststellen ob ich die CA noch brauche? Ich war eigentlich bei Punkt 7 der Migration angelangt. Siehe nachfolgender Ablaufplan. Auch habe ich gelesen dass die CA nicht auf dem DC installiert werden sollte. Stimmt das? Ablaufplan der Migration: 1. Virtuelle Maschinen erstellen und installieren 2x Windows Server 2019 2. SBS Sichern / Backup erstellen 3. Virtuelle Maschinen der SBS Domäne hinzufügen und beide neue Server zum DC heraufstufen. Einen der beiden als Globalen Katalog einrichten. 4. Migration von Exchange 2010 zu Office365. 5. DNS und DHCP vom SBS auf den neuen DC migrieren / verschieben 6. Dateifreigaben auf den neuen DC verschieben / GPO's und Loginskript anpassen 7. Zertifikatdienste sichern und auf den neuen DC Server migrieren 8. FSMO Rollen auf den neuen DC 2019 Server verschieben (21 Tage Restzeit beachten) 9. SBS herabstufen 10. SBS aus der Domäne nehmen.

Auch per GUI kam die gleiche Meldung. Danke NorbertFe. Ich habe nun das Zerifizierungsstellenzertifikat erneuert und hierbei ein neues öffentlich-privates Schlüsselpaar erstellt. Anschliessend konnte ich den privaten Key exportieren.

Hallo Leute, Ich bin dran einen SBS 2011 zu Server 2019 (VM) zu migrieren. Exchange 2010 zu Office365 ist bereits abgeschlossen. Zwei neue DC als VM sind ebenfalls bereits eingebunden. Nun wollte ich die Active Directory Zertifizierungsstelle beim SBS2011 sichern und dann wiederherstellen. Siehe auch Anleitung: https://argonsys.com/microsoft-cloud/library/step-by-step-migrating-the-active-directory-certificate-service-from-windows-server-2008-r2-to-2019/ Die Datenbank konnte ich mit Certutil.exe –backupdb <BackupDirectory> problemlos sichern. Beim privaten Key welche ich mit Certutil.exe –backupkey <BackupDirectory> zu sichern versuche erhalte ich immer nachfolgende Fehlermeldung: CertUtil: -backupKey-Befehl ist fehlgeschlagen: 0x80092004 (-2146885628) CertUtil: Das Objekt oder die Eigenschaft wurde nicht gefunden. Ich habe nach der Fehlermeldung gegoogelt aber nicht wirklich viel sinnvolles gefunden. Hat jemand einen Tipp? Gruss SBK

Danke NilsK, die vertrauenswürdigen Speicherorten waren nicht die Ursache, da ich das Dokument direkt vom Outlook geöffnet hatte und dieses ja in einem temporären Speicherort landet. Aber ich hatte auf den getesteten PC's das Dokument bereits einmal geöffnet resp. mit dem Makro hantiert, das war die Ursache. Noch eine letzte Frage: Bei uns habe ich die Standarddateiablage \\Server\Datenshare als vertrauenswürdiger Speicherort hinzugefügt. Wenn nun aber ein Benutzer einen infizierten Anhang Bsp. test.docm dort ablegt und dann von dort direkt öffnet, nützen alle GPO- und Registry-Einstellungen nichts. Verwendet ihr bei euch überhaupt den vertrauenswürdigen Speicherort? Gruss SBK

Danke mwiederkehr, genau das wars. Natürlich hatte ich das Dokument auf den anderen PC's bereits geöffnet und mit den Makros hantiert. Auf einem dritten PC's, hat es geklappt. Danke klappt demnach einwandfrei. Sorry für die Verwirrung.

Hallo Leute, Es dürfte bereits mehreren Admin wiederfahren sein, dass Sie die Makro per GPO abgeschaltet haben, um dann mit schrecken festzustellen, dass diese nur bei den Office 365 Version E3 und E5 greifen und nicht bei Premium Business Lizenzen. Siehe auch: https://www.heise.de/security/artikel/Microsoft-und-Emotet-Makroschutz-in-Office-365-nur-fuer-Konzerne-4664218.html Wir haben bei uns sowohl E3-Lizenzen wie auch Business Premium Lizenzen im Einsatz und die Makro-Einstellungen werden sowohl via GPO wie auch via Registrierungselement zugewiesen. Heute habe ich mal Testweise ein Text.docm per Mail verschickt und darin war das folgende Makro: Sub AutoOpen() MsgBox ("Wenn das der Virus gewesen wäre, wäre der PC nun infiziert!") End Sub Ich habe das Dokument auf unterschiedlichen PC's und Benutzer getestet und bei allen kam die Meldung beim öffnen, obwohl die Einstellung im Trustcenter auf Alle Makros ohne Benachrichtung deaktivieren gesetzt ist. Mache ich hier ein Überlegungsfehler? Gruss SBK

Hier noch eine sich aus dem Thread ergebende Lizenzfrage: Ich überlege mir nun den produktiven Hyper-V-Server 2016 mit einer Windows Server Lizenz 2019 auszustatten. Darf ich Lizenztechnisch den Server auf die Server 2019 upgraden und die VM's weiterhin als installierte Server 2016 belassen? Könnte ich nun sogar 2 neue VM's mit Server 2019 installieren und die bestehenden 2 VM's mit dem Server 2016 belassen, da ich ja eine Server 2016 Lizenz besitze? Die Storage-, CPU- und RAM-Ressourcen würden ausreichen um 4 VM's laufen zu lassen. Die Frage bezieht sich somit nur auf die Lizenz. Gruss SBK

In meinem Fall sind effektiv beide Hyper-V-Server produktiv im Einsatz, meine Frage war aus dem Grund, falls einer der beiden ausfällt, kann ich die VM's problemlos auf dem anderen wiederherstellen (sofern Speicherplatz und CPU-Auslastung ausreichen). Aus diesem Grund würde in meinem Fall die Gratislizenz des Hyper-V-Servers keinen Sinn machen.

Die VM's liegen auf einem separaten und eigenen Volume. Das mit der Livemigration auf den vorhandenen Server 2019 und dann wieder zurück wäre ein interessanter Ansatz, muss aber schauen ob der Speicherplatz auf dem bestehenden Server 2019 ausreicht. Werde mir das mal sauber durchdenken und auf eine ruhige Minute einplanen...