Probleme mit der Zeitumstellung?

Gleich auf drei meiner Windows Server 2012 R2 Essentials Servern hat die Zeitumstellung am vergangenen Wochenende zu folgendem Effekt geführt.

  • Der Statusbericht wurde um 02:00 Uhr anstatt um 06:00 Uhr versendet
  • Danach wurde kein Statusbericht mehr versendet (und der um 02:00 als “Cannot send email” angezeigt (obwohl er gesendet wurde)

image

Das Problem läßt sich durch einen Neustart des Servers, oder ein wenig ““professioneller”, durch einen Neustart des Windows Server Essentials Management Service lösen.

net stop "Windows Server Essentials Management Service" && net start "Windows Server Essentials Management Service"

Enjoy it, b!

Windows Server 2012 R2 Essentials (Role)–Migration

Für die Migration von verschiedenen Small Business Server Versionen auf Windows Server 2012 R2 stellt Microsoft einen Guide zur Verfügung, welchen ich auch im Rahmen meiner Migrationen verwende.

https://technet.microsoft.com/en-us/dn408633.aspx

Der Guide ist in 8 Schritte unterteilt welche die wesentlichen Punkte einer Migration beschreiben:

Im Verlauf meiner Migrationen habe ich einige Punkte anders gemacht, welche ich hier darstellen möchte, Zuerst jedoch eine Überlegung zu wirklich kleinen Umgebungen Winking smile 

(keine) Migration von kleinen Standard-Umgebungen

Kleine SBS Umgebungen (so um die 5 Benutzer) migriere ich gar nicht. Hier führe ich eine Neuinstallation des SBE durch und übertrage anschließend Benutzereinstellungen mit Windows Easy-Transfer in die neue Domain. Das funktioniert auch recht gut, wenn über den Server zentral bereitgestellte Anwendungen lediglich eine Dateifreigabe benötigen (die Arztpraxis lässt da grüßen). Diese Variante stellt einen sauberen Neuanfang dar – ohne Altlasten. Gibt es jedoch in der Umgebung mehr als nur 5 Benutzer und dazu noch Anwendungen, dann ist eine Migration sinnvoll und damit die Abarbeitung der 8 oben beschriebenen Schritte.

Für größere und/oder komplexere Umgebungen migriere ich natürlich …

Migration von größeren SBS Umgebungen

Die Grundlage für die folgenden Empfehlungen war eine Umstellung von Windows Small Business Server 2008 Premium auf Windows Server 2012 R2 Essentials. Neben dem Small Business Server mit Exchange 2007 gab es noch folgende Anwendungen:

  • Mailstore zur Mailarchivierung
  • SQL Server 2008 und eine Anwendung welche Aktienkurse analysiert
  • Windows Server 2008 R2 mit Remote Desktop Services (Terminal Server)

Die Umstellung habe ich in 4 Schritten gemacht:

  1. Umstellung der Mails in die Cloud (Office365)
  2. Migration der Domäne von Windows Server 2008 Small Business auf Windows Server 2012 R2 Essentials (Role), inklusive folgender Dienste:
    – File und Print
    – WSUS (Windows Server Update Services)
  3. CleanUp – Aufräumen des migrierten Servers / der Domäne
  4. Umstellung von SQL Server und der Anwendung für die Aktienkurse (auf SQL Server 2014)

Office365 Business Essentials – die Mails sind nun in der Cloud

Wie man Mails in die Cloud, bzw. nach Office365 transferiert beschreibt Microsoft hinreichend genau und soll hier auch nicht weiter ausgeführt werden. Da die Mailboxen in Summe für 6 Benutzer die 100GB Grenze erreicht hatten und die Anbindung an das Internet mit ADSL (16MBit/s Down und 1MBit/s Upload) nicht gerade üppig ist, habe ich mich auf eine Migration von Kontakten und Kalendern beschränkt. Die Mails verbleiben in der zu Mailarchivierung verwendeten Lösung Mailstore und sind über ein Plugin in Outlook vorhanden. Von dort kann dann jeder Benutzer selbst wichtige Mails in sein neues Postfach transferieren.

Migration der Domäne auf Windows Server 2012 R2 Essentials

Die Migration auf den neuen Server habe ich wie folgt gemacht.

  1. Installation eines neuen Servers als Member-Server in die Domäne
  2. Migration aller Fileshares
  3. Erstellen der Drucker
  4. Installation von WSUS
  5. Installation des SMTP-Servers (den brauchen wir, da ohne Exchange auch keine Mails mehr versendet werden können), die Konfiguration ist hier beschrieben https://sbsland.wordpress.com/2014/11/22/smtphome-mit-11/
  6. Installation des DHCP-Servers
  7. Anpassen bzw. neu Anlegen der GPOs (Ordnerumleitung, WSUS …)
  8. Anpassen des Anmeldescriptes (login.cmd) – Yep, ich hänge an dieser Art der Laufwerkszuordnung Smile

Nach diesen Schritten sollte der alte SBS Server nur noch die Anmeldung machen, alle anderen Dienste laufen zu diesem Zeitpunkt auf dem installierten Member-Server! Diese Vorgehensweise bietet mir ausreichend Zeit um die Funktion des neuen Servers zu testen. Können die Benutzer damit eine Woche problemlos arbeiten, dann kommt der nächste Schritt – Umstellung der Domäne.

  1. Auf dem Member-Server fügen wir die notwendige AD-Rolle(n) (inklusive des DNS) hinzu

    image

  2. Nach erfolgreichem DC Promo erfolgt das Verschieben der FSMO-Rollen auf den neuen DC (sbe.sbsland.local):
    Move-ADDirectoryServerOperationMasterRole -Identity "sbe.sbsland.local" -OperationMasterRole 0,1,2,3,4

    Mit einer Zeile PowerShell ist das eine sehr coole Sache.

  3. Und als Abschluss dieses Schrittes die Installation der Essentials-Role

Cleaning …

So, nun geht’s ans Aufräumen … ob das notwendig ist oder nicht, muss jeder selbst entscheiden. Ich versuche zumindest die migrierte Domäne, wie eine neu installierte erscheinen zu lassen. Dabei geht es im Wesentlichen um folgende Punkte.

  • Entfernen von Exchange 2007
  • Auflösen der MyBusiness OU
  • Löschen von “alten” Gruppen
  • Löschen alter GPOs

Exchange fare well …

Um Exchange 2007 zu deinstallieren sind im Wesentlichen die folgenden Schritte aus der TechNet zu beachten:

https://technet.microsoft.com/en-us/library/bb123893(v=exchg.80).aspx

Bei jeder bisher von mir durchgeführten Migration, bin ich auf die folgenden drei Fehler gestoßen welche die Deinstallation von Exchange 2007 verhindert haben. Daher habe ich diese in einem extra Blog-Beitrag beschrieben:

https://sbsland.wordpress.com/2016/03/07/entfernen-von-exchange-2007-im-verlauf-einer-migration/

Danach ließ sich wie im TechNet-Artikel beschrieben Exchange 2007 deinstallieren.

Auflösen der MyBusiness OU

Die Benutzer und Gruppen verschiebe ich nach \Users und alle Computer (egal ob Server oder Clients) nach \Computers im Active Directory. Unterschiedlichen Anforderungen bzgl der Einstellungen werden über GPOs und Gruppen realisiert:

  • _ SBSland Servers
  • _ SBSland Client Computers
  • _ SBSland Hyper-V Hosts
  • _ SBSland Office Users

Damit die MyBusiness OU gelöscht werden kann, muss noch die Erstellung von Benutzer und Computerkonten in den unteren OUs deaktiviert, bzw. wieder zurück nach \Users und \Computers gestellt werden. Dazu gibt es zwei Befehle:

# redirusr CONTAINER-DN
redirusr cn=users,dc=sbsland,dc=local

# redircmp CONTAINER-DN
redircmp cn=computers,dc=sbsland,dc=local

Nach der Migration der Benutzer von den “alten” Gruppen in neue, können diese gelöscht werden. Das erfolgt wiederum in zwei Schritten:

@echo off

:: net group /dom | findstr /i "Windows SBS" >groups-2-delete-from-2008.cmd

:: Group Accounts for \\SBS
net group "SBS Admin Templates" /dom /delete
net group "SBS Fax Operators" /dom /delete
net group "SBS Folder Operators" /dom /delete
net group "SBS Mail Operators" /dom /delete
net group "SBS Mobile Users" /dom /delete
net group "SBS P User Templates" /dom /delete
net group "SBS Remote Operators" /dom /delete
net group "SBS Report Users" /dom /delete
net group "SBS SP Admins" /dom /delete
net group "Windows SBS Fax Administrators" /dom /delete
net group "Windows SBS Fax Users" /dom /delete
net group "Windows SBS Folder Redirection Accounts" /dom /delete
net group "Windows SBS Link Users" /dom /delete
net group "Windows SBS Remote Web Workplace Users" /dom /delete
net group "Windows SBS SharePoint_MembersGroup" /dom /delete
net group "Windows SBS SharePoint_OwnersGroup" /dom /delete
net group "Windows SBS SharePoint_VisitorsGroup" /dom /delete
net group "Windows SBS Virtual Private Network Users" /dom /delete

und

@echo off

:: net group /dom >groups-2-delete-to-be-standard.cmd

::Group Accounts for \\SBS

:: -------------------------------------------------------------------------------

:: *_ SBSland Client Computers		//-Kunde-//
:: *_ SBSland Desktop Admins			//-Kunde-//
:: *_ SBSland Folders Redirect			//-Kunde-//
:: *_ SBSland Hyper-V Hosts			//-Kunde-//
:: *_ SBSland Mailstore Users			//-Kunde-//
:: *_ SBSland Office				//-Kunde-//
:: *_ SBSland Terminal Server Users		//-Kunde-//

:: *Cloneable Domain Controllers 		//-WS2012R2-//
:: *DnsUpdateProxy 			//-WS2012R2-//
net group "Domain Power Users" /dom /delete	
:: *Domänen-Admins			//-WS2012R2-//
:: *Domänen-Benutzer			//-WS2012R2-//
:: *Domänencomputer			//-WS2012R2-//
:: *Domänencontroller			//-WS2012R2-//
:: *Domänen-Gäste				//-WS2012R2-//
:: *Enterprise Read-only Domain Controllers	//-WS2012R2-//
net group "Exchange Domain Servers" /dom /delete

:: *Organisations-Admins			//-WS2012R2-// - Enterprise Admins
:: *Protected Users				//-WS2012R2-//
:: *RDP_MAPPING_S-1-5-21-966628382-784051496-1200022492-1531
:: *RDP_MAPPING_S-1-5-21-966628382-784051496-1200022492-2846
:: *RDP_MAPPING_S-1-5-21-966628382-784051496-1200022492-4661
:: *RDP_MAPPING_S-1-5-21-966628382-784051496-1200022492-4662
:: *RDP_MAPPING_S-1-5-21-966628382-784051496-1200022492-4667
:: *RDP_MAPPING_S-1-5-21-966628382-784051496-1200022492-4683
:: *Read-only Domain Controllers		//-WS2012R2-//
:: *Richtlinien-Ersteller-Besitzer			//-WS2012R2-// - build-in
:: *Schema-Admins				//-WS2012R2-//
net group "User Roles" /dom /delete
net group "Web Workplace Users" /dom /delete
:: *WseAlertAdministrators			//-WS2012R2-//
:: *WseAllowAddInAccess			//-WS2012R2-//
:: *WseAllowComputerAccess			//-WS2012R2-//
:: *WseAllowDashboardAccess		//-WS2012R2-//
:: *WseAllowHomePageLinks			//-WS2012R2-//
:: *WseAllowMediaAccess			//-WS2012R2-//
:: *WseAllowShareAccess			//-WS2012R2-//
:: *WseInvisibleToDashboard			//-WS2012R2-//
:: *WseManagedGroups			//-WS2012R2-//
:: *WseRemoteAccessUsers			//-WS2012R2-//
:: *WseRemoteWebAccessUsers		//-WS2012R2-//

:: The command completed successfully.

Nun kann die MyBusiness OU gelöscht werden und auch die Gruppen entsprechen dem Standard einer neuen Installation.

Nicht vergessen sollte man an dieser Stelle die Bereinigung der GPOs des SBS 2008 inkusive der alten WMI Filter (grün umrandet).

image

Hier ein kleiner Tipp zu den GPOs – vielleicht erst einmal deaktivieren, bevor man sie löscht.

Zum Abschluss wird der alte SBS Server mit DCPromo aus dem AD entfernt und herunter gefahren. Da nach dem DCPromo der alte SBS ein Member-Server ist, lasse ich ihn erst einmal ausgeschaltet und deaktiviere das Computerkonto. Nach 14 Tagen, lösche ich dieses und dazu auch noch die VM (die VHDs mit Daten kann man ja noch behalten … falls man was vergessen hat).

That’s it Smile

Enjoy it, b!

Wiederbelebung eines Windows Server 2012 R2 SBE, Event 2228 …

… war heute Nacht bei einem Kunden agesagt! Hyper-V Replika und VMs sind eine feine Sache, allerding muss man auch wissen was man damit anstellen kann.

Ausgangssituation (was der Admin meines Kunden wollte)

Da die Installation einer LOB Anwendung am recht neuen SBE stattfinden sollte und der Hersteller der Anwendung sich 100% sicher war, dass dies “kein Problem ist” hatte sich der Admin (nein nicht ich) dazu entschlossen, den bestehenden SBE zu exportieren und modifiziert (andere IP-Adresse in einem anderen Subnetz) als Testsystem zu verwenden.

Dazu hat er folgende Schritte ausgeführt:

# - Hyper-V Host 1
Export-VM –Name sbs.sbsland.local –Path \\mx-whv-2\Temp
# - Hyper-V Host 2
Import-VM –Path 'D:\Temp\sbs.sbsland.local\VirtualMachines\5AE40946-3A98-428E-8C83-081A3C6BD18C.XML'

Danach wurde der SBE auch gestartet, eine Anmeldung war leider nicht möglich – da laut dem Server die Anmeldung nicht authentifiziert werden konnte. Eine lokale Anmeldung mit dem Administrator war jedoch möglich. Ein Blick in das Eventlog und in die Services.msc offenbarte, das ein Start des Active Directories fehlgeschlagen war.

Directory Service, ActiveDirectory_DomainService, 2228

An dieser Stelle klingelte mein Telefon… Confused smile die Testumgebung musst ja fertig werden …

Was war passiert?

Beim Start des ““importieten” SBE wurde vergessen das Netzwerk zu ändern und so waren auf einmal 2 Domain Controller im Netzwerk, von denen der zweite (importierte) den Dienst verweigerte, Ein Blick in sein Eventlog offenbarte das Problem.

image

Mit dem Zeitdruck doch noch das Testsystem fertig zu bekommen, entschlossen wir uns das AD über den DSRM (Directory Services Resource Mode) zu “reparieren”.

Authoritative Restore des AD

Dazu waren folgende Schritte notwendig:

  1. Anmeldung als lokaler Administrator und Konfiguration des Systems für den DSRM
    bcdedit /set safeboot dsrepair

    Neustart des Servers und erneute Anmeldung als lokaler Administrator.

    http://blogs.technet.com/b/activedirectoryua/archive/2008/11/20/how-to-start-in-directory-service-restore-mode-dsrm-in-windows-server-2008-and-windows-server-2008-r2.aspx

  2. Start von ntdsutil und Ausführung der folgenden Schritte
    ntdsutil
    ntdsutil: activate instance ntds
    
    # Active instance set to "ntds". 
    
    ntdsutil: authoritative restore
    
    # die Domain heisst sbsland.local
    
    authoritative restore: restore subtree "CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=sbsland,DC=local"
    
    # Authorative Restore completed successfully.
    
    
    

  3. Danach wurde der DSRM wieder deaktiviert
    bcdedit /deletevalue safeboot
  4. Konfiguration einer neuen IP-Adresse 192.168.32.11
  5. Disable des DHCP-Servers
  6. Neustart des SBE

So, der SBE als Testsystem läuft, hätte der Admin den importierten SBE mit einem isolierten virtuellem Netzwerk (Private Virtual Switch) gestartet, wäre uns das ganze Theater erspart geblieben.

Enjoy it, b!

Error, ESENT, 490 Application Logfile

Nach einer Migration auf Windows Server 2012 R2 Essentials (Role) hatte ich die folgenden Einträge im Application-Log:

image

Welches Executable / Service der SvcHost startet habe ich mit dem ProcessExplorer von Sysinternals ermittelt.

image

Der Terminal Services Gateway Service (tgateway) läuft unter dem Network Service Account, welcher anscheinend auf das oben genannten Verzeichnis keinen Zugriff hat.

C:\Windows\System32\LogFiles>icacls Sum
Sum NT AUTHORITY\Authenticated Users:(I)(RX)
    NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(GR,GE)
    BUILTIN\Server-Operatoren:(I)(RX)
    BUILTIN\Server-Operatoren:(I)(OI)(CI)(IO)(GR,GE)
    BUILTIN\Administratoren:(I)(F)
    BUILTIN\Administratoren:(I)(OI)(CI)(IO)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
    CREATOR OWNER:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

Nachdem ich dem NETWORK SERVICE Modify Rechte auf das Verzeichnis gegenben hatte, waren die Fehlermeldungen verschwunden:

C:\Windows\System32\LogFiles>icacls Sum
Sum NT AUTHORITY\NETWORK SERVICE:(OI)(CI)(M)
    NT AUTHORITY\Authenticated Users:(I)(RX)
    NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(GR,GE)
    BUILTIN\Server-Operatoren:(I)(RX)
    BUILTIN\Server-Operatoren:(I)(OI)(CI)(IO)(GR,GE)
    BUILTIN\Administratoren:(I)(F)
    BUILTIN\Administratoren:(I)(OI)(CI)(IO)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
    CREATOR OWNER:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

Enjoy it, b!

Azure Backup

Mit dem Microsoft Azure Backup gibt es eine attraktive Möglichkeit die Daten seines Windows Servers in die Cloud zu sichern. Gerade in Small Business Umgebungen, in denen möglichst alles “automatisch” ablaufen soll und oftmals der Wechsel von Bändern (früher einmal) oder Festplatten schon ein Problem darstellt ist die Sicherung von wichtigen Dateien in die Cloud eine optimale Lösung zur Auslagerung.

Die Voraussetzung für die Nutzung des Azure Backups ist die Anmeldung bei Microsoft Azure. Dannach sind nur wenige Schritte notwendig um eine Sicherung in die Cloud durch zu führen.

Nach der Anmeldung erstellen wir als erstes einen Backup Vault (Tresor):

Auswahl von Recovery Services / +New, links im Microsoft Azure Portal. Damit öffnet sich folgender Dialog aus der wir BACKUP VAULT / QUICK CREATE auswählen.

image

Danach müssen wir uns noch einen Namen für den Vault aus denken und die Region wählen, wohin die Daten bei Microsoft gesichert werden sollen:

image

Der Name des Vaults sollte die Einheit, oder Organisation wiederspiegeln, welche dorthin gesichert wird. Unter diesem können mehrere Server wiederum angelegt werden. In diesem Fall ist es bei mir ein kleiner Kunde in Form einer Arztpraxis. Alle Eingaben bestätigen wir mit Create Vault.

Noch eine Anmerkung zur Region:

  • West Europe = Amsterdam
  • North Europe = Dublin

Nach kurzer Zeit steht der Vault zur Verfügung und unter ihm können einzelne Server in die Sicherung integriert werden.

Wichtig: Zu diesem Zeitpunkt, also wenn noch keine Registrierung erfolgt ist, können Änderungen bzgl. der Verteilung des Vaults innerhalb von Azure festgelegt und geändert werden. Per Default wird ein Vault als LRS (Local Redundant Storage) angelegt, was bedeutet das die Daten innerhalb eines Azure Standorts redundant sind. Diese Einstellung kann auf GRS (Geo Redundant Storage) geändert werden.

image

Im nun folgenden Schritt laden wir die Vault credentials und den Azure Backup Agent (Client) herunter, wie im folgenden Bild gezeigt.

image

Folgende beiden Dateien sollten nach dem Download vorhanden sein.

image

Mit einem Doppelklick auf MARSAgentInstaller.exe startet die Installation des Microsoft Azure Recovery Services Agent.

In den Installation Settings des Agenten ändern wir die Cache Location auf Laufwerk D – da dort hinreichend Platz vorhanden sein sollte.

image

Interessanter Weise legt der Client das Verzeichnis nicht selbst an und somit müssen wir uns hier selber helfen.

md “D:\Microsoft Azure Recovery Services Agent\Scratch”

Da wir keinen Proxy verwenden geht es hier gleich weiter und wir wählen das Microsoft Update Opt-In aus, damit der Agent auch aktualisiert wird.

Im Anschluss prüft der Agent noch, ob das Microsoft .Net Framework 4.5 und die Windows Powershell installiert sind und wir können mit Install den Agenten installieren.

Nun muss der Agent im zugehörigen Backup Vault registriert werden.

image

Was durch die Auswahl der passenden Vault Credentials erfolgt.

image

Darauf folgt der wichtigste Teil der Installation, die Erstellung der Passphrase welche zum Zugriff auf das Backup notwendig ist!

image

Die verwendete Passphrase wird als Textdatei im angegebenen Ordner abgelegt und sollte separat an einem sicheren Ort gespeichert werden.

Nach erfolgreicher Registrierung ist der Server im Vault sichtbar.

image

Nun kann die Auswahl der zu sichernden Ordner im Agent selbst erfolgen. Dazu muss das Microsoft Azure Backup über die Verknüpfung auf dem Desktop gestartet werden und über die Option Schedule Backup die Konfiguration erfolgen.

image

Der restliche Ablauf ist selbst erklärend und die Backup Retention Policies nochmals einen eigenen Beitrag wert Smile

Update 07.10.2015 – Löschen eines Backup Vault:
Bevor ein Backup Vault gelöscht werden kann, müssen alle darin registrierten Server gelöscht werden, sprich der Backup Vault muss leer sein.

Enjoy it, b!

Proofing Tools / Language Accessory Pack für Office 2016

Früher war die Installation einer Rechtschreibprüfung in einer alternativen Sprache immer etwas umständlich. Inzwischen (seit Office 2013) hat das Microsoft recht elegant gelöst.

Beginnt man in einem Office in englischer Sprache ein Dokument mit deutschen Text zu erstellen erscheint folgender Hinweis mit der Aufforderung die entsprechenden Proofing Tools herunter zu laden.image

Dahinter steckt ein Link über diesen die Proofing Tools herunter geladen werden können.

image

https://support.office.com/de-de/article/Language-Accessory-Pack-f%c3%bcr-Office-2016-82ee1236-0f9a-45ee-9c72-05b026ee809f?ui=de-DE&rs=de-DE&ad=DE

Und alternativ noch für Office 2013:

http://www.microsoft.com/de-de/download/details.aspx?id=35400

Enjoy it, b!

Windows 10 hat zu viele Recovery Partitions

Bei der Einrichtung des Clientbackups eines Windows 10 Clients gegen meinen Small Business Essentials Server präsentierte mir der Wizard folgendes (für mich verwirrendes) Bild.

image

Ein Blick in das Diskmanagement auf dem betroffenen Client offenbarte folgenden Zustand.

image

Mein Windows hatte 3 Recovery Partitionen, eigentlich würde ich sagen – eine reicht! Ich vermute das diese Anzahl von Partitionen Reste der Upgrades sind und im Verlauf diese jeweils neu angelegt wurden. Eine Kontrolle mit PowerShell lieferte übrigens das gleiche Resultat.

image

Um hier ein wenig aufzuräumen, müssen wir zum einen herausfinden welche dieser drei Partitionen eigentlich aktiv ist (also von Windows verwendet wird) und wie die anderen Partitionen gelöscht werden können (das Diskmanagement zeigt sich hier als nicht geeignet).

Doch nun zuerst zur Ermittlung der, welche über reagentc /info erfolgen kann.

image

Wie im Bild oben zu sehen ist, können wir damit Partiton 6 und Partition 7 löschen. Partition 5 ist die aktive Recovery Partition.

Leider habe ich keinen PowerShell-Befehl gefunden um eine Recovery Partition zu löschen, daher musst diskpart diese Aufgabe übernehmen.

image

Nachdem die Partition 6 ausgewählt wurde, kann diese final gelöscht werden – die Option override ermöglicht das, schnell und effektiv.

image

Analog dazu das Ganze für die Partiton 7. Hier nochmals der Ablauf mit Diskpart:

list disk
select disk 0
list part
select part 6
delete part override

So, sieht doch ganz gut aus Smile

image

Enjoy it, b!