Jump to content

SBK

Members
  • Gesamte Inhalte

    874
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von SBK

  1. 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
  2. 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
  3. 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
  4. 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....
  5. 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).
  6. 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...
  7. 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.
  8. 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.
  9. 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
  10. 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
  11. 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.
  12. 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
  13. 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
  14. 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.
  15. 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...
  16. Danke testperson das wäre durchaus ein Lösungsansatz, wobei ich eine Server 2019 Lizenz wohl noch ins Budget reinquetschen könnte. Der Installationsaufwand scheue ich da schon mehr. Käme denn ein in-place Upgrade auf Server 2019 in Frage und könnte ich dann anschliessend alle VM's auf dem aktualisierten Server auf die Version 9 anheben? Gruss Dave
  17. Danke Nilsk, das hatte ich vermutet, wollte aber auf Nummer sicher gehen... Jetzt störe ich nicht mehr, alle meine Fragen sind beantwortet. Gruss SBK
  18. @NilsK und @falkebo vielen Dank für eure Antworten diese war sehr hilfreich. Noch eine letzte Verständnisfrage hätte ich an @falkebo: Wenn ich im Disaster Recoveryfall eine VM, welche ursprünglich die Configversion 9 hatte, nur die VHDX auf einem Server 2016 wiederherstelle und eine neue Virtual Machine Konfiguration (Version 8) erstelle und die VHDX manuell einbinde, dann läuft die VHDX problemlos weiter? Danke und Gruss SBK
  19. Nobby: Soll ich Dir die Mailadresse der Geschäftsleitung senden? Vielleicht hast Du mehr Erfolg bei der nächsten Budgetbesprechung.
  20. @Nilsk: Danke Nils, ich bin mir bewusst das die Infos meinerseits recht dürftig waren. Gibt es eine Möglichkeit auf einem Hyper-V-Server 2019 eine neue VM als V8 zu erstellen? Bei einer Livemigration vom Server 2016 wird die V8 Ja übernommen. Denn die Vorteile von V9 im Vergleich zu V8 sind für uns praktisch inexistent, dafür sind die Nachteile dann relativ gross, da die VM's zwischen den beiden Hyper-V-Server nicht kompatibel sind oder zumindest nur von 2016 zu 2019. Noch eine klärende Frage zur Sicherung innerhalb der VM. Du meinst wenn ich z.B. Disk2VHD innerhalb der VM ausführe? Oder kannst Du mir ein Backuptool angeben, das innerhalb der VM sichert? Gruss SBK Nachtrag zur obenstehenden Frage: Habe soeben einen Beitrag gefunden, die Konfigurationsversion kann man anscheinend nur via Powershell definieren: New-VM -Version 8.0 -Name Test-VM-Version-8 -NoVHD
  21. Danke tesso. Somit kann ich auch via Acronis Backup keine VM auf einer anderen Hyper-V-Server-Version wiederherstellen? Das bedeutet ein Disaster Recovery geht immer nur von V9 zu V9 oder von V8 zu V8 resp. V9? Gruss SBK
  22. Hallo Leute, Wir haben bei uns zwei Hyper-V-Server (Server 2016 und 2019) im Einsatz. Beide haben im Moment zwei VM's drauf. Falls nun ein Hyper-V-Server abraucht, habe ich mir überlegt das ich die VM's allenfalls notfallmässig auf dem anderen Server wiederherstellen kann, solange das beim Server 2016 passiert und ich mittels Acronis eine Wiederherstellung auf dem Server 2019 mache, ist das ja kein Problem. Was wenn aber das umgekehrte passieren sollte? Wenn ich eine Livemigration von V8 (Server 2016) nach V9 (Server 2019) vornehme, übernimmt der neue Server die Konfigurationsdatei V8 und ich müsste diese ja manuell upgraden. Ist auch ein downgrade vorgesehen oder muss ich zwingend die V9 auf einen anderen Hyper-V-Server 2019 wiederherstellen? Danke für eure Antworten. Gruss SBK
  23. Hallo Leute, Ich bin nicht sicher ob es ins Serverforum passt, aber ich versuche es mal. Es kommt vor das gewisse Benutzer, auf fremden Laptops oder Geräten das lokale Outlook starten und Ihr Office365-Konto und dsa dazu gehörende Passwort eingeben. Leider achten Sich die wenigsten auf den nachfolgenden Dialog, der hinweist dass das Passwort auf das lokale Gerät gespeichert wird und bestätigen dies mit OK. Nun haben aber alle nachfolgende Benutzer Zugriff auf das Outlook ohne dass Sie ein Passwort eingeben müssen, ausser wenn man via Windows 10 Konteneinstellungen das Arbeitskonto wieder trennt. Bei Clients welche zu unserer internen Domain gehört, ist das Vorgehen des Kenntwort speichern ja noch einigermassen vertretbar, aber bei fremden Geräten nicht. Lässt sich das Verhalten beeinflussen, das z.B. ein Workplace Join resp. die Passwortspeicherung nur auf Domänenclients hinzugefügt werden kann? Gibt es eine Möglichkeit aufzulisten, welche Devices von den Usern bisher hinzugefügt worden ist? Anmerkung: Wir verwenden OnPremise DC's und Server und haben Office365 mit ADConnect eingebunden. Gruss SBK --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Ich bin soeben fündig geworden, das Devicemanagement befindet sich im Azure Portal, unter Microsoft Intune Übersicht, Benutzer, Geräte und dort kann die registrierten Device einsehen und ggf. löschen. Wie man ein Workplace Join aber verhindern kann, das konnte ich noch nicht herausfinden.
  24. Hallo Leute, Ich habe einen Remotedesktopserver (RDS Server 2016) im Einsatz und die User Profile Disk sind aktiviert, diese verweisen auf einen bestimmten Netzwerkshare \\server\freigabenamen. Das funktioniert alles einwandfrei. Das Problem ist das sich ja jeder User mit dem Server verbindet und der Server die VHDX-Dateien mountet, abhängig von der Anzahl Benutzer können da schon etliche Laufwerksbuchstaben belegt sein. Nun kommt es vor das auch die wichtigen Laufwerksbuchstaben R:, S: und T: belegt werden, dann kann der jeweilige Benutzer nicht mehr auf die Laufwerke zugreifen resp. landet in seiner eigenen gemounteten UPD-Disk. Lässt sich das Verhalten beeinflussen, damit VHDX nicht mit Netzwerklaufwerksbuchstaben in Konflikt stehen? Etliche Googlesuchen haben keinen Erfolg gebracht. Ich sehe keine Möglichkeit wie ich Netzwerklaufwerke aus dem Mountvorgang ausschliessen kann oder mache ich da einen Überlegungsfehler? Gruss SBK
×
×
  • Neu erstellen...