Exchange 2019 CU3 und Exchange 2016 CU14 sind verfügbar

Gestern hat Microsoft die nächsten kumalativen Updates für Exchange Server 2019 und 2016 veröffentlicht.

Hier der Blog Beitrag „September 2019 Quarterly Exchange Updates“ vom Exchange Team Blog: https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Released-September-2019-Quarterly-Exchange-Updates/ba-p/853699

Alternativ hier auch die Direktlinks zu den Microsoft Knowledge Base Artikel:

Viel Spaß beim Patchen :).

An dieser Stelle ein kleines Update und Obacht (24.09.2019): Ich hatte bei den ersten 10 Exchange 2016 CU14 Updates bereits viermal den Fall, dass das Setup abgebrochen ist. Im Exchange Setup Log (C:\ExchangeSetupLogs\ExchangeSetup.log) fanden sich folgende Einträge:

[09.22.2019 17:00:59.0598] [1] The following roles are installed: BridgeheadRole ClientAccessRole MailboxRole UnifiedMessagingRole FrontendTransportRole AdminToolsRole CafeRole
[09.22.2019 17:00:59.0608] [1] [ERROR] Die Datei „C:\Windows\Temp\ExchangeSetup\bin\EnterpriseServiceEndpointsConfig.xml“ konnte nicht gefunden werden.
[09.22.2019 17:00:59.0609] [1] [WARNING] An unexpected error has occurred and a Watson dump is being generated: Die Datei „C:\Windows\Temp\ExchangeSetup\bin\EnterpriseServiceEndpointsConfig.xml“ konnte nicht gefunden werden.
[09.22.2019 17:01:00.0606] [1] [ERROR] Die Datei „C:\Windows\Temp\ExchangeSetup\bin\EnterpriseServiceEndpointsConfig.xml“ konnte nicht gefunden werden.
[09.22.2019 17:01:00.0606] [1] [ERROR] Die Datei „C:\Windows\Temp\ExchangeSetup\bin\EnterpriseServiceEndpointsConfig.xml“ konnte nicht gefunden werden.
[09.22.2019 17:01:00.0632] [0] [ERROR] Ein Aufrufziel hat einen Ausnahmefehler verursacht.
[09.22.2019 17:01:00.0636] [0] [ERROR] Die Datei „C:\Windows\Temp\ExchangeSetup\bin\EnterpriseServiceEndpointsConfig.xml“ konnte nicht gefunden werden.
[09.22.2019 17:01:00.0636] [0] [ERROR] Die Datei „C:\Windows\Temp\ExchangeSetup\bin\EnterpriseServiceEndpointsConfig.xml“ konnte nicht gefunden werden.
[09.22.2019 17:01:00.0636] [0] CurrentResult SetupLauncherHelper.loadassembly:444: 1
[09.22.2019 17:01:00.0638] [0] Setup von Exchange Server wurde nicht abgeschlossen. Weitere Details finden Sie im Protokoll ‚ExchangeSetup.log‘ im Ordner ‚:\ExchangeSetupLogs‘.
[09.22.2019 17:01:00.0639] [0] CurrentResult main.run:235: 1
[09.22.2019 17:01:00.0639] [0] CurrentResult setupbase.maincore:396: 1
[09.22.2019 17:01:00.0641] [0] End of Setup

C:\ExchangeSetupLogs\ExchangeSetup.log

Bei einer manuellen Prüfung wurde im besagten Verzeichnis („C:\Windows\Temp\ExchangeSetup\bin\“) in der Tat keine „EnterpriseServiceEndpointsConfig.xml“ gefunden. An dieser Stelle aber der Hinweis – Don’t Panic – Das Setup einfach erneut starten und beenden. Zumindest hat das in meinen vier Fällen geholfen. Noch ein Hinweis: Die GUI erkennt ein „Unvollständiges Setup“ und setzt diese Fort. Das Fenster der GUI wird nach Abschluss allerdings ohne Meldung geschlossen. Hier lohnt sich dann ein erneuter Blick ins ExchangeSetup.log, um sicher zu gehen, dass alles funktioniert hat. Nach etwas Troubleshooting und weiterer Analyse stelle sich heraus, dass hier wohl die „Advanced Threat Control/Protection“ vom BitDefender AV die Finger im Spiel hatte. Ein reines Deaktivieren schaltete scheinbar den „Aktivschutz“ und „Verhaltensscan“ nicht aus, sodass dieser sich an den Dateien vergriffen hatte. Besserung brachte eine Ausnahme für „%SystemRoot%\Temp\ExchangeSetup“.

Ein weiteres Update bzw. Problem, welches mir untergekommen ist (01.10.2019): Beim Vorbereiten der Organisation bzw. genauer beim Vorbereiten des ActiveDirectorys (Setup.exe /IAcceptExchangeServerLicenseTerms /PrepareAD) bemängelte das Setup ein Fehlen des „Exchange Online-ApplicationAccount“ AD-Objektes. Ein späteres Anlegen des Objektes scheiterte mit dem Fehler „Das Objekt ist vorhanden.“ Bei einem Blick ins Active Directory-Benutzer und -Computer bestätigte dies.

[09.30.2019 10:39:37.0397] [2] Beginning processing Get-LinkedUser
[09.30.2019 10:39:37.0407] [2] Searching objects „Exchange Online-ApplicationAccount“ of type „ADUser“ under the root „$null“.
[09.30.2019 10:39:37.0426] [2] Previous operation run on domain controller ‚DOMAINCONTROLLER‘.
[09.30.2019 10:39:37.0426] [2] Previous operation run on domain controller ‚DOMAINCONTROLLER‘.
[09.30.2019 10:39:37.0426] [2] Preparing to output objects. The maximum size of the result set is „1000“.
[09.30.2019 10:39:37.0435] [2] The object „SUB.DOMAIN.TLD/Users/Exchange Online-ApplicationAccount“ has been retrieved, but it will not be output to the shell.
[09.30.2019 10:39:37.0439] [2] The operation couldn’t be performed because object ‚Exchange Online-ApplicationAccount‘ couldn’t be found on ‚DOMAINCONTROLLER‘.
[09.30.2019 10:39:37.0449] [2] The operation couldn’t be performed because object ‚Exchange Online-ApplicationAccount‘ couldn’t be found on ‚DOMAINCONTROLLER‘.
[09.30.2019 10:39:37.0456] [2] Ending processing Get-LinkedUser
[09.30.2019 10:39:37.0463] [2] Die Active Directory-Sitzungseinstellungen für ‚New-LinkedUser‘ lauten: Vollständige Gesamtstruktur anzeigen: ‚True‘, Konfigurationsdomänencontroller: ‚DOMAINCONTROLLER‘, Bevorzugter globaler Katalog: ‚DOMAINCONTROLLER‘, Bevorzugte Domänencontroller: ‚{ DOMAINCONTROLLER }‘
[09.30.2019 10:39:37.0463] [2] User specified parameters: -Name:’Exchange Online-ApplicationAccount‘ -UserPrincipalName:’Exchange_Online-ApplicationAccount@SUB.DOMAIN.TLD‘ -DomainController:’DOMAINCONTROLLER‘
[09.30.2019 10:39:37.0463] [2] Beginning processing New-LinkedUser
[09.30.2019 10:39:37.0477] [2] Searching objects „SUB.DOMAIN.TLD/Users“ of type „ExchangeOrganizationalUnit“ under the root „$null“.
[09.30.2019 10:39:37.0486] [2] Previous operation run on global catalog server ‚DOMAINCONTROLLER‘.
[09.30.2019 10:39:37.0488] [2] Getting the organization for organizational unit SUB.DOMAIN.TLD/Users.
[09.30.2019 10:39:37.0498] [2] Searching objects of type „ADRecipient“ with filter „(|((&((Id NotEqual SUB.DOMAIN.TLD/Users/Exchange Online-ApplicationAccount)(UserPrincipalName Equal Exchange_Online-ApplicationAccount@SUB.DOMAIN.TLD)))))“, scope „SubTree“ under the root „$null“.
[09.30.2019 10:39:37.0500] [2] Previous operation run on global catalog server ‚DOMAINCONTROLLER‘.
[09.30.2019 10:39:37.0501] [2] Processing object „SUB.DOMAIN.TLD/Users/Exchange Online-ApplicationAccount“.
[09.30.2019 10:39:37.0516] [2] The properties changed on the object ‚Exchange Online-ApplicationAccount‘ (CN=Exchange Online-ApplicationAccount,CN=Users,DC=SUB,DC=DOMAIN,DC=TLD) are: „{ UserPrincipalNameRaw[userPrincipalName]=’Exchange_Online-ApplicationAccount@SUB.DOMAIN.TLD‘, Id[distinguishedName]=’SUB.DOMAIN.TLD/Users/Exchange Online-ApplicationAccount‘, RecipientTypeDetailsValue[msExchRecipientTypeDetails]=’LinkedUser‘, RecipientDisplayTypeRaw[msExchRecipientDisplayType]=’LinkedUser‘, RecipientDisplayType[msExchRecipientDisplayType]=’LinkedUser‘, RawName[name]=’Exchange Online-ApplicationAccount‘, RecipientTypeDetails[mailNickname, msExchHomeServerName, proxyAddresses, objectClass, homeMDB, groupType, msExchRecipientTypeDetails, userAccountControl]=’LinkedUser‘, ObjectCategory[objectCategory]=’SUB.DOMAIN.TLD/Configuration/Schema/person‘, OrganizationId[msExchOURoot, msExchCU]=“ }“.
[09.30.2019 10:39:37.0517] [2] Saving object „SUB.DOMAIN.TLD/Users/Exchange Online-ApplicationAccount“ of type „ADUser“ and state „New“.
[09.30.2019 10:39:37.0522] [2] Previous operation run on domain controller ‚DOMAINCONTROLLER‘.
[09.30.2019 10:39:37.0545] [2] [ERROR] Active Directory operation failed on DOMAINCONTROLLER. The object ‚CN=Exchange Online-ApplicationAccount,CN=Users,DC=SUB,DC=DOMAIN,DC=TLD‘ already exists.
[09.30.2019 10:39:37.0545] [2] [ERROR] Das Objekt ist vorhanden.

ExchangeSetupLog

Ein erster Versuch, war das Verschieben des AD-Objektes in eine andere OU. Dabei änderte sich das Fehlerbild allerdings nur minimal. „Das Objekt ist vorhanden.“ wurde zu „The value „Exchange_Online-ApplicationAccount@SUB.DOMAIN.TLD“ of property „UserPrincipalName“ is used by another recipient object. Please specify a unique value.“

[09.29.2019 11:37:00.0768] [2] [ERROR] The value „Exchange_Online-ApplicationAccount@SUB.DOMAIN.TLD“ of property „UserPrincipalName“ is used by another recipient object. Please specify a unique value.
[09.29.2019 11:37:00.0769] [2] [ERROR] The value „Exchange_Online-ApplicationAccount@SUB.DOMAIN.TLD“ of property „UserPrincipalName“ is used by another recipient object. Please specify a unique value.

ExchangeSetupLog

Der Fehler konnte letztlich durch Umbennung des vorhandenen und warum auch immer nicht gefundenen AD-Objektes des “ Exchange Online-ApplicationAccount “ behoben werden. Dem Anzeigenamen und dem User Principal Name wurde lediglich eine „1“ angehangen. Nach erneutem Start des Setups konnte dieses dann erfolgreich abgeschlossen werden!

Exchange Online-ApplicationAccount

Neues vom Exchange Server

Exchange Server 2016 CU11 veröffentlicht, neues zum .Net Framework 4.7.2 sowie ein paar Infos zu Exchange 2019

Exchange Server 2019:

  • Nur auf Windows Server 2019 (Core oder GUI) freigegeben / Mangament Tools ebenfalls auf Windows 10 64 Bit
  • Mindestens den Active Directory Forest Functional Level „Windows Server 2012 R2“ (oder eben höher)
    Daraus ergibt sich, dass die Domain Controller zwangsweise mindestens Windows Server 2012 R2 oder neuer sein müssen
  • .Net Framework 4.7.2:
  • Visual C++ 2012 Runtime für alle Server-Rollen: https://www.microsoft.com/de-DE/download/details.aspx?id=30679
  • Visual C++ 2013 Runtime für die Mailbox-Server-Rolle: https://www.microsoft.com/de-DE/download/details.aspx?id=40784
  • Outlook Clients von 2013 bis 2019
  • Koexistenz mit nur mit Exchange Server 2013 CU21 sowie Exchange 2016 CU11 oder neuer

Exchange Server 2016:

  • Download des Kumulativen Update 11 für Exchange Server 2016: https://www.microsoft.com/de-DE/download/details.aspx?id=57388
  • Alle Exchange Server 2016 CU11 Rollen benötigen jetzt die Visual C++ 2012 Runtime (Link siehe oben)
    Der Exchange Team Blog rät dringendst dazu, die Visual C++ 2012 Runtime vor einem Update auf CU11 oder neuer von Hand zu installieren:

Important: To avoid a setup failure, it is necessary to install the Visual C++ 2012 runtime before installing Cumulative Update 11 or later for the first time on an existing server. The setup pre-requisite rule works as expected when using Cumulative Update 11 or later to install a new server using the Cumulative Update 11 or later package.

https://blogs.technet.microsoft.com/exchange/2018/10/16/released-october-2018-quarterly-exchange-updates/
  • Server mit dem CU11 und installierter Mailbox Rolle benötigen ebenfalls die Visual C++ 2013 Runtime (Link siehe oben)
  • Ebenfalls unterstützt Exchange 2016 CU11 jetzt auch das .Net Framework 4.7.2. Ebenfalls wird das .Net Framework 4.7.2 ab dem CU13 im Juni 2019 zur Vorraussetzung.

Exchange 2013:

  • Exchange Server 2013 CU21 hat im Nachgang ebenfalls Support für das .Net Framework 4.7.2 erhalten!

Für den fleißigen Exchange Admin, der zeitnah auf Exchange 2016 CU11 oder Exchange 2019 RTM geht, heißt es dann auch schon „Frohe Weihnachten“. Die nächsten geplanten Kumulativen Updates (CU12 für Exchange Server 2016) sowie das Exchange Server 2019 CU1 erscheinen erst im März 2019.

Migration von Exchange 2010 zu 2016

Das Ende von Exchange 2010 steht „kurz“ bevor, daher hier noch einmal ein kleines How-To für die Migration von Exchange 2010 zu Exchange 2016.

Wie hier bereits erwähnt, werden mit dem Exchange 2010 SP3 RollUp 22 (endlich) Windows Server 2016 Domain Controller in der Active Directory Gesamtstruktur (Forest) unterstützt. Daher ist es jetzt möglich, die alten DCs und Exchange Server in „einem Schritt“ abzulösen. Das ist insbesondere bei Small Business Servern 2011 sehr hilfreich. 🙂 Somit steht einer Migration von Exchange auf SBS 2011 zu Exchange 2016 auf Server 2016 nichts mehr im Weg.

Die Systemanforderungen hat jedermann / jedefrau natürlich gelesen / überflogen. Die Installation der Vorbereitungen sowie des eigentlichen Exchange Servers 2016 (mit dem aktuellesten CU!) setze ich hier an dieser Stelle einmal ganz dreist voraus, so dass direkt mit den Vorbereitungen des Updates der Exchange Organisation losgelegt werden kann. Dazu sollte als erstes am Exchange 2010, sofern noch möglich, eine weitere Mailboxdatenbank mit einem Proxy-Postfach für die öffentlichen Ordner angelegt werden.

$Ex2010 = Get-ExchangeServer | ? AdminDisplayVersion -like "Version 14.3*"
$Ex2016 = Get-ExchangeServer | ? AdminDisplayVersion -like "Version 15.1*"

New-MailboxDatabase -Server $Ex2010  -Name PFProxyDatabase -IsExcludedFromProvisioning $true
Set-MailboxDatabase PFProxyDatabase -CircularLoggingEnabled $true
Mount-Database PFProxyDatabase

# Hier könnte man mit Invoke-Command die Mailbox vom Exchange 2016 auf dem 2010 erstellen, oder einfach und schnell die EMC auf dem Exchange 2010 öffnen und die Befehle dort ausführen. ;)
New-Mailbox -Name PFProxyMailbox1 -Database PFProxyDatabase -UserPrincipalName PFProxyMailbox1@[Domain].[tld] -Password $(ConvertTo-SecureString G3he!mesPW -AsPlainText -Force)
Set-Mailbox -Identity PFProxyMailbox1 -HiddenFromAddressListsEnabled $true
Vorbereitung Exchange 2010 PFProxyMailbox
Vorbereitung Exchange 2010 PFProxyMailbox

Sollte es auf dem Exchange Server 2010 (Standard) bereits 5 Datenbanken (z.B. 4x Postfachdatenbank / 1x öffentliche Ordner Datenbank) geben, bleibt nicht viel anderes übrig, wie die PFProxyMailbox1 in einer bestehenden Datenbank zu erzeugen. Wer möchte, der darf natürlich eine Datenbank leer räumen, diese löschen und dann die PFProxyDatabase samt PFProxyMailbox1 erstellen.

Weiter geht die wilde Migration von Exchange am neuen Server, wo die eben erstellte öffentliche Ordner Proxy-Mailbox (PFProxyMailbox1) zum Einsatz kommt und später die Zugriffe auf den legacy Exchange Server ermöglicht bis die öffentlichen Ordner komplett in die neue modern Public Folder übertragen wurden. Da es bei vielen Migrationen immer mal wieder zu Problemen mit MAPI over HTTP gekommen ist, bin ich dazu übergegangen und habe es für die Dauer der Migration deaktiviert. Nach erfolgreicher Deinstallation des legacy Servers aktiviere ich es dann wieder.

Set-OrganizationConfig -MapiHttpEnabled $false
Set-OrganizationConfig -PublicFoldersEnabled Remote -RemotePublicFolderMailboxes PFProxyMailbox1

# Zum Prüfen:
Get-OrganizationConfig | fl *PublicFolder* 
Exchange 2016 Remote Public Folder aktivieren
Exchange 2016 Remote Public Folder aktivieren

Im nächsten Schritt wäre es sehr hilfreich, wenn der Exchange 2010 bereits nach Best Practice konfiguriert ist und die internen URLs der virtuellen Verzeichnisse gleich denen der externen URLs sind (SplitDNS). Sollte dies nicht der Fall sein – Don’t Panic! Dann wird SplitDNS eben umgehend eingeführt: https://jans.cloud/2014/09/exchange-2007-2010-2013-2016-virtuelle-verzeichnisse-zertifikate-splitdns/

# Ggfs. noch die erste / einzige Datenbank umbenennen und verschieben
Dismount-Database -Identity "Mailbox Database *" -Confirm:$false
Get-MailboxDatabase | Set-MailboxDatabase -name "Exch2016DB01"
Move-Databasepath -Identity "Exch2016DB01" -edbfilepath "d:\ExchangeDBs\Exch2016DB01\Exch2016DB01.edb" -logfolderpath "d:\ExchangeLogs\Exch2016DB01" -Confirm:$False

# Je nach Speicherplatz evtl. Umlaufprotokollierung für die Dauer der Migration aktivieren #
Set-MailboxDatabase -Identity "Exch2016DB01" -CircularLoggingEnabled:$true
Mount-Database -Identity "Exch2016DB01" -Confirm:$false

# Receive Connector für den Mail-Empfang erstellen
New-ReceiveConnector -Name "Internet" -Usage Custom -TransportRole FrontendTransport -PermissionGroups AnonymousUsers -Bindings 0.0.0.0:25 -RemoteIpRanges [IP der Firewall / SPAM Filter]

# Offline Adressbuch setzen
$OAB = Get-OfflineAddressBook | ? Identity -like "*(Ex2013)"
foreach ($Ex in Get-ExchangeServer ) { Get-MailboxDatabase -Server $Ex.Name | Set-MailboxDatabase -OfflineAddressBook $OAB }
# Exportiertes Zertifikat vom Exchange 2010 installieren
$Cert = Import-PFXCertificate -FilePath "[Pfad zum Zertifikat].pfx" -CertStoreLocation Cert:\LocalMachine\My -Password $(ConvertTo-SecureString G3he!mesPW -AsPlainText -Force)

Get-OwaVirtualDirectory -Server $Ex2016 | Set-OwaVirtualDirectory -InternalUrl 'https://owa.[Domain].[tld]/owa' -ExternalUrl 'https://owa.[Domain].[tld]/owa' Get-EcpVirtualDirectory -Server $Ex2016 | Set-EcpVirtualDirectory -InternalUrl 'https://owa.[Domain].[tld]/ecp' -ExternalUrl 'https://owa.[Domain].[tld]/ecp'
Get-OABVirtualDirectory -Server $Ex2016 | Set-OABVirtualDirectory -InternalURL 'https://owa.[Domain].[tld]/OAB' -ExternalURL 'https://owa.[Domain].[tld]/OAB'
Get-ActiveSyncVirtualDirectory -Server $Ex2016 | Set-ActiveSyncVirtualDirectory -InternalURL 'https://owa.[Domain].[tld]/Microsoft-Server-ActiveSync' -ExternalURL 'https://owa.[Domain].[tld]/Microsoft-Server-ActiveSync'
Get-WEbServicesVirtualDirectory -Server $Ex2016 | Set-WEbServicesVirtualDirectory -InternalURL 'https://owa.[Domain].[tld]/EWS/Exchange.asmx' -ExternalURL 'https://owa.[Domain].[tld]/EWS/Exchange.asmx'
Get-MapiVirtualDirectory -Server $Ex2016 | Set-MapiVirtualDirectory -InternalURL 'https://owa.[Domain].[tld]/mapi' -ExternalURL 'https://owa.[Domain].[tld]/mapi'
Get-ClientAccessService -Identity $Ex2016.Name | Set-ClientAccessService -AutodiscoverServiceInternalUri https://owa.[Domain].[tld]/autodiscover/autodiscover.xml
Get-OutlookAnywhere -Server $Ex2016 | Set-OutlookAnywhere -ExternalHostname owa.[Domain].[tld] -InternalHostname owa.[Domain].[tld] -ExternalClientsRequireSsl:$true -InternalClientsRequireSsl:$true -ExternalClientAuthenticationMethod 'Ntlm'
Enable-ExchangeCertificate -Thumbprint $Cert.Thumbprint -Services IIS, POP, SMTP, IMAP -Confirm:$false -Force
SplitDNS virtuelle Verzeichnisse
SplitDNS virtuelle Verzeichnisse

Bevor die erste Mailbox verschoben werden kann, sollte der neue Exchange Server noch zum bestehenden Sende Connector hinzugefügt werden. Sobald das erledigt ist, wird die erste Test-Mailbox verschoben und an einem Test Client die Hostsdatei bearbeitet sowie Outlook gestartet.

Get-SendConnector | Set-SendConnector -SourceTransportServers $(Get-ExchangeServer)
$Ex2016MBX = Get-MailboxDatabase -Server $Ex2016
New-MoveRequest Test.User -TargetDatabase $Ex2016MBX

Am oben genannten Test Client kann jetzt vorsichtshalber einmal die HOSTS-Datei bearbeitet werden und um die Einträge

  • [IP des Exchange 2016] owa.[DOMAIN].[tld]
  • [IP des Exchange 2016] autodiscover.[DOMAIN].[tld]

ergänzt werden.

HOSTS Datei am Test Client
HOSTS Datei am Test Client

Meldet sich der auserkorene Test User jetzt am Test Client an und öffnet Outlook, so sollte er zum letzten Mal in seinem Leben die folgende Nachricht erhalten:

Migration von Exchange am Client
Migration von Exchange am Client

Nach Bestätigung eben dieser Nachricht öffnet Outlook die Mailbox auf dem neuen Server und proxied die öffentlichen Ordner per PFProxyMailbox1 auf den legacy Server. Sobald der Test User sich vom ordnungsgemäßen Funktionieren des neuen Exchanges überzeugt hat, sollten die für SplitDNS konfigurierten Einträge auf den neuen Exchange Server geändert werden. Es kann nicht schaden die DNS Server Dienste einmal neu zu starten. Danach können die restlichen Postfächer inkl. der Arbitration-Mailboxes (Systempostfächer) verschoben werden.

Get-Mailbox -Server $Ex2010 -Arbitration | New-MoveRequest -TargetDatabase $Ex2016MBX
Get-Mailbox -Server $Ex2010 | New-MoveRequest -TargetDatabase $Ex2016MBX

# Mit einer kleinen Schleife lässt sich jetzt z.B. automatisch prüfen, ob alle Move Requests fertig sind..
do { Start-Sleep -Seconds 60; Get-MoveRequest | ? Status -ne "Completed" | Get-MoveRequestStatistics } until (!$(Get-MoveRequest | ? Status -ne "Completed"))

Während die Postfächer verschoben werden, kann an der Firewall / am SPAM Filter der Mailflow bereits auf den neuen Exchange gelenkt werden. Ist dies geschehen, kann mit der Überführung der alten öffentlichen Ordner in die neue modern Public Folder Strukturen begonnen werden -> KLICK 🙂

P.S.: Am Test Client sollte ASAP nach dem Test die HOSTS Datei wieder in den Ursprungszustand zurückversetzt werden. Es ist ja nicht so, dass einem so eine HOSTS Datei noch nie auf die eigenen Füße gefallen ist. 😉