none
Upgrade 2008R2 AD to 2016 RRS feed

  • Întrebare

  • Hallo zusammen, 

    aktuell gibt es im meiner Umgebung 2x AD-Controller, beides Server 2008R2. Das Funktionslevel ist noch auf Windows2003. 

    Ich möchte auf 2016 upgraden.

    Ich habe mir einige Tutorials angeschaut.

    1. Es gibt noch ein paar alte XP und Server 2003 Clients. Es gibt auch noch einige 2008R2 Clients
    --> Sind die Clients noch kompatibel?

    2. Die beiden DCs sind für DNS und einer der beiden für DHCP zuständig. Soweit ich mich informieren konnte, muss ich den DHCP jedenfalls manuell verschieben. Der DNS wird automatisch migriert? 

    3. Wie ist das mit dem Zertifikatmanager? Ich habe hier gesehen, es sind noch Fehler vom Vorgänger Admin vorhanden. Muss man hier Hand anlegen? Soweit ich es weiß wird ein Zertifikat für den Terminalserver verwendet. Sonst geht da glaub nicht viel.

    4. Muss ich den Umweg über 2012R2 zwingend gehen?

    5. Gibt es noch weitere Stolpersteine wo ich aktuell gar nicht auf dem Schirm haben kann?

    6. Ich habe noch irgendwie im Kopf, wenn die Domäne von Windows2000 auf Windows 2008 migriert wurde, muss ich noch etwas am sysvol (FRS auf DFSR) anpassen. Leider finde ich die Information nicht mehr. 

    PS: Ich habe einen Testserver auf dem ich das Backup des DCs einspielen kann, sodass ich auch einiges ausprobieren kann. 

    Vielen Dank,
    Grüße
    Leon


    • Editat de leon_20v luni, 6 iulie 2020 12:33
    luni, 6 iulie 2020 12:31

Toate mesajele

  • Moin,

    1. Ja, die Sicherheitsrichtlinien sind im AD konfiguriert und bleiben in Kraft, solange Du sie nicht veränderst.
    2. DHCP sollte nicht auf DC laufen. Aber ja, in jedem Fall musst Du die Konfiguration manuell verschieben. DNS wird auf die neuen DCs erweitert, die Anpassung an Clients, die statische IP-Konfigurationen haben, musst Du so oder so vornehmen.
    3. Auch PKI sollte nach Möglichkeit nicht auf DCs laufen. Maschinen, auf denen CAs ausgeführt sind, umzubenennen ist explizit nicht supported (funktioniert aber). Wenn Du eine Möglichkeit hast, die PKI zurückzubauen und neu aufzubauen, tu das auf jeden Fall. Man kann durch die Ausstellung einer lange gültigen CRL die bestehenden Zertifikate sehr lange valide behalten.
    4. Absolut nicht, direkte Migration auf 2016 ist supported.
    5. Denk daran zu prüfen, ob noch NTFRS für SYSVOL verwendet wird. Ich würde es vorher auf DFS-R upgraden. Dafür musst Du aber den FFL auf 2008 upgraden.
    6. s. oben.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    luni, 6 iulie 2020 12:56
    1. Auch PKI sollte nach Möglichkeit nicht auf DCs laufen. Maschinen, auf denen CAs ausgeführt sind, umzubenennen ist explizit nicht supported (funktioniert aber). Wenn Du eine Möglichkeit hast, die PKI zurückzubauen und neu aufzubauen, tu das auf jeden Fall. Man kann durch die Ausstellung einer lange gültigen CRL die bestehenden Zertifikate sehr lange valide behalten.
    2. Denk daran zu prüfen, ob noch NTFRS für SYSVOL verwendet wird. Ich würde es vorher auf DFS-R upgraden. Dafür musst Du aber den FFL auf 2008 upgraden.

    Evgenij Smirnov

    http://evgenij.smirnov.de


    Vielen Dank für deine Antwort.

    Hast du evtl. noch ein paar Infos zu der PKI? Was meinst du mit zurückbauen? 

    Zum DFS-R upgrade, habe ich hier noch Einschränkungen bei den Clients zu erwarten? 
    luni, 6 iulie 2020 13:18
  • Hast du evtl. noch ein paar Infos zu der PKI? Was meinst du mit zurückbauen?

    Ich meine damit 'soweit aus dem AD entfernen, dass es so aussieht, als hätte es noch nie eine gegeben'. Je nachdem , welche Zertifikate ausgestellt wurden, wieviele davon und wie lange noch gültig sind, kann es trivial sein oder richtig kompliziert.

    Am besten ist es, Du baust eine neue PKI nach Best Practice auf einem Member Server und sorgst dafür, dass ihr alle vertrauen. Dann stellst Du für die Dienste, die Zertifikate brauchen, welche aus der neuen PKI aus und spielst sie dort ein. Wenn alle zufrieden sind, kannst Du die CA-Rolle vom dem DC, wo sie jetzt wohnt, deinstallieren.

    Um Zertifikate, die die alte PKI ausgestellt hat, aufzulisten und auszuwerten, empfehle ich PowerShell und das PSPKI-Modul. Das muss nicht auf der CA verwendet werden, remote funktioniert genauso gut, wenn die Rechte reichen.

    Zum DFS-R upgrade, habe ich hier noch Einschränkungen bei den Clients zu erwarten?

    Überhaupt nicht. Den Clients ist es egal, welche Technologie die Daten in der SYSVOL-Freigabe repliziert.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    luni, 6 iulie 2020 13:57
  • Am besten ist es, Du baust eine neue PKI nach Best Practice auf einem Member Server und sorgst dafür, dass ihr alle vertrauen. Dann stellst Du für die Dienste, die Zertifikate brauchen, welche aus der neuen PKI aus und spielst sie dort ein. Wenn alle zufrieden sind, kannst Du die CA-Rolle vom dem DC, wo sie jetzt wohnt, deinstallieren.


    Das hört sich nicht schlecht kompliziert an. Gibt es dafür evtl. Tutorials? Ich hab zwar schon ein paar MS-Schulungen gemacht, aber so tief bin ich bisher noch nicht vorgedrungen...

    Es gibt Ausgestellte Zertifikate für 4 User (Unter anderem auch mich, warum auch immer) und für ein paar Server (unter anderem auch die beiden Terminal-Hosts). Für die beiden DCs gibt es mehrere Zertifikate.


    • Editat de leon_20v joi, 9 iulie 2020 07:45
    joi, 9 iulie 2020 07:42

  • Das hört sich nicht schlecht kompliziert an. 

    Angesichts der Anzahl der Zertifikate eigentlich nicht ;-)

    Evgenij Smirnov

    http://evgenij.smirnov.de

    joi, 9 iulie 2020 07:55

  • Das hört sich nicht schlecht kompliziert an. 

    Angesichts der Anzahl der Zertifikate eigentlich nicht ;-)

    Evgenij Smirnov

    http://evgenij.smirnov.de



    Wie kann ich die Zertifizierungstelle testen?
    miercuri, 22 iulie 2020 15:16
  • Wie kann ich die Zertifizierungstelle testen?

    Was genau möchtest Du denn testen?

    Evgenij Smirnov

    http://evgenij.smirnov.de

    miercuri, 22 iulie 2020 15:44
  • Ob die Zertifkate dann noch gültig sind. Soweit ich weiß benutze ich diese nur beim Terminalserver. ;)
    vineri, 24 iulie 2020 09:57
  • Ob die Zertifkate dann noch gültig sind. Soweit ich weiß benutze ich diese nur beim Terminalserver. ;)
    Die Zertifikate sind an sich erst mal noch gültig. Ob sie auch validierbar sind, hängt davon ab, ob der Pfad mit der CRL erreichbar ist ;-)

    Evgenij Smirnov

    http://evgenij.smirnov.de

    vineri, 24 iulie 2020 11:30
  • Vielen Dank für deine Antwort. Ich musste mich da jetzt erst ein wenig informieren, weil wie du sicher schon gemerkt hast, habe ich von der PKI absolut keine Ahnung. Es ist auch schwierig hier gute Infos zu finden. 

    Ich habe gerade mal nachgesehen in den ausgestellten Zertifikaten... Die meisten sind eh bereits nicht mehr gültig. 

    Wenn ich jetzt eine neue PKI auf einem anderen Server installiere, wie ist das dann mit den Domänencontroller Zertifikaten? Muss ich hier Hand anlegen? Wäre es vermutlich nicht am besten, wenn ich die PKI einfach auf nen neuen Server migriere? 

    Die aktuelle PKI ist allerdings auf dem DC installiert, d.h. ich muss die neue auch auf den DC installieren.

    Dazu kommt, dass ich das Wildcard Zertifikat, dass ich für den Terminalserver erstellt habe, nicht in der Auflistung finde.

    1. Was sind das für DomainController Zertifikate? Was passiert mit denen wenn ich eine neue PKI installiere.
    2. Warum ist mein Wildcard Zertifikat nicht aufgelistet?
    3. Wäre es nicht am sinnvollsten, die PKI zu exportieren und einfach so wie sie ist auf dem neuen DC zu importieren? Der Name ist halt dann leider blöd, weil die Heißt wie der alte DC nur mit CA hinten drann.

    Vielen Dank!

    Grüße
    Leon

    luni, 27 iulie 2020 06:48
  • Es ist auch schwierig hier gute Infos zu finden. 

    Daran arbeite ich gerade.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    luni, 27 iulie 2020 06:57
  • 1. Was sind das für DomainController Zertifikate? Was passiert mit denen wenn ich eine neue PKI installiere.

    2. Warum ist mein Wildcard Zertifikat nicht aufgelistet?
    3. Wäre es nicht am sinnvollsten, die PKI zu exportieren und einfach so wie sie ist auf dem neuen DC zu importieren? Der Name ist halt dann leider blöd, weil die Heißt wie der alte DC nur mit CA hinten drann.


    Moin,

    ad 1. Die gelten für LDAPS, Kerberos, diese Dinge. Wenn Du die neue PKI per Weiter,Weiter,Weiter,Fertig installierst und vorher die DC Vorlagen von der Alten zurückziehst, werden diese Vorlagen durch die neue PKI veröffentlicht und die Zertifikate durch die neue CA ausgestellt.

    ad 2. Keine Ahnung, die Namen sind auf Deinem Screenshot ja nicht zu sehen. Aus dem Stehgreif kann ich mir drei Gründe vorstellen:

    • das Wildcard-Cert stammt nicht von dieser CA (ich weiß, ich weiß, aber Pferde, Apotheken...)
    • das Zertifikat wurde aus Bestand der CA gelöscht (das ist blöd, damit kann es nämlich nicht zurückgezogen werden, falls kompromittiert)
    • das Zertifikat wurde aus einer Vorlage ausgestellt, die keine Speicherung in der Datenbank der CA vorsieht (für ein Server-Cert noch blöder, zumal für ein Wildcard)

    ad 3. das kann ich nicht beantworten, musst Du selbst entscheiden. Wenn Du eine Microsoft CA auf eine anders benannte Maschine umziehst, ist das unsupported. Funktionieren würde es. Ist die alte CA wenigstens schon SHA-2?


    Evgenij Smirnov

    http://evgenij.smirnov.de

    luni, 27 iulie 2020 07:06
  • Vielen Dank für deine ausführliche Antwort...

    Ich hab das eben rekonstruiert wie das gemacht wurde. Auf dem Terminalserver Broker ist ein IIS-Manger installiert und dort gibt es "Serverzertifikate". Hier habe ich ein Domänenzertifikat angefordert und habe das *.firma.local genannt. 

    Die ausstellende CA ist aber eindeutig die CA, welche auf dem DC2008 (srv10) installiert ist.

    Ich musste die CA auf sha-2 umstellen, sonst hätte das der Terminalsserver nicht gefressen.


    1. DC-Vorlagen zurückziehen? Ich finde leider nichts im Netz wie das funktioniert. Ich darf mir hier auf keinen Fall etwas zerstören. Das mit den Zertifikaten ist einfach sehr kompliziert.

    2. Wenn es die CA nicht mehr gibt, dann geht mein Wildcard Zertifikat nicht mehr (läuft eh ende Oktober aus). Wenn es die neue CA dann gibt, müsste es ja reichen wieder solch ein Zertifikat auszustellen, zu exportieren und bei den Session Hosts wieder importieren(bin mir jetzt gar nicht sicher ob der private Key mit muss)? Die --> Clients bekommen die Vertrauenswürdige CA von allein?

    3. Warum das Wildcard Zertifikat in der Zertifizierungsstelle nicht angezeigt wird, ist mir unklar:
    IIS vom Broker weil auf dem DC kein IIS installiert ist:
    (das .local ist das *Wildcard, zu viel entfernt wegen Datenschutz usw.)

    .

    4. Ich habe nach Ablaufdatum sortiert: 
    Woher das USER Zertifikat kommt weiß ich nicht. Das bin zufällig auch noch ich selber.
    Das Wildcard von oben ist auch nicht da... Sehr fragwürdig alles.



    Nochmals vielen Dank an dich!
    Was würde ich nur ohne dich tun ;) 



    • Editat de leon_20v luni, 27 iulie 2020 10:32
    luni, 27 iulie 2020 10:29
  • @Evgenij Smirnov hast du evtl. noch einen Tip für mich? ;)
    marți, 28 iulie 2020 06:59
  • @Evgenij Smirnov hast du evtl. noch einen Tip für mich? ;)

    Zu was jetzt genau?

    Vorlagen zurückziehen: Einfach in der CA-MMC unter "Zertifkatsvorlagen" löschen. Im AD bleiben sie bestehen und können von einer anderen CA im gleichen Forest bereitgestellt werden.

    Wenn es die CA nicht mehr gibt, aber die CRL weiterhin erreichbar ist, ändert sich aus Sicht der Clients nicht. Nur hast Du natürlich einen LDAP-CDP, der wird mit der Deinstallation der CA mit entfernt. Dann schon lieber aus der neuen PKI ausstellen und tauschen.

    Das User-Cert für Basis-EFS ist eine der Standard-Vorlagen, die mit der Default-Installation einer Enterprise-CA mit veröffentlicht werden. Wenn Du also die EFS-Verschlüsselung irgendwo aktivierst, beantragt Dein Client für Dich dieses Zertifikat.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    marți, 28 iulie 2020 10:15
  • Ich habe ja alles auf meinen Testserver zurück gesichert und hab hier einfach mal die CA deinstalliert um zu sehen was passiert.

    Das CA-Zertifikat wird immer noch an die Clients als vertrauenswürdige Stammzertifizierungsstelle verteilt. 
    Erst als ich im ADSI-Editor die CAs entfernt habe, war dies nicht mehr der Fall.

    Ich glaube aber das ist nicht richtig, weil die Zertifikate noch gültig sind. Ich weiß aber nicht wie ich die Zertifikate sperren soll, denn der Server wie die aktuelle CA-läuft wird ja gelöscht. Also sind die Sperrlisten in welcher form auch immer weg...

    Ich habe eine neue CA auf einem anderen Testerver (allerdings ist das der zweite DC02 in der Testumgebung) installiert. Hier hat sich bisher nur der erste DC01 ein Zertifikat geholt mit der AnforderungsID = 2, was mit der 1 ist, keine Ahnung.

    Irgendwie ist mir bisher noch nicht klar, wie ich das sauber hinbekommen soll. Ich habe mir bei LinkedIn auch schon alle Videos über die Zertifizierungsstelle angesehen. Etwas mehr verstehe ich, aber so wirklich ist der Knoten noch nicht geplatzt...
    marți, 28 iulie 2020 20:06
  • Moin,

    die Anfordreungs-ID 1 bei einer Root CA ist natürlich die CA selber ;-)

    Wenn Du Zertifikate wirklich sperren willst, musst Du das natürlich tun, bevor Du die CA entfernst... aber warum? Irgendwann ist alles abgelaufen, inklusive der CRL. Sorg lieber dafür, dass die Zertifikate gar nicht erst validiert werden müssen, weil sie nicht mehr benutzt werden...

    Revocation-Informationen werden auf den Clients übrigens durchaus gern gecacht...


    Evgenij Smirnov

    http://evgenij.smirnov.de


    marți, 28 iulie 2020 20:31
  • Soweit ich dich verstehe, wäre ich dann so wie es jetzt ist schon fertig?

    Seitdem ich das Zertifikat aus dem ADSI-Editor raus gelöscht habe (ist das eigentlich der richtige Weg?) wurde das Ca-Zertifikat nicht mehr auf den Clients verteilt und beim Verbinden auf die Terminalserver kommt eine Zertifikatswarnung, dass es nicht validiert werden kann. 

    Das habe ich jetzt ausgetauscht gegen ein Zertifikat der neune CA und wäre eigentlich fertig? 
    joi, 30 iulie 2020 08:04


  • Seitdem ich das Zertifikat aus dem ADSI-Editor raus gelöscht habe (ist das eigentlich der richtige Weg?)
    Das sollte eigentlich automatisch erfolgen, wenn Du die ADCS-Rolle deinstallierst. Aber ich habe schon häufig erlebt, dass das nicht passiert.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    joi, 30 iulie 2020 08:15
  • Ich hab das jetzt alles auf meinem Testserver umgesetzt.

    Den alten 2008er Server habe ich jetzt erst mal nur ausgeschalten und vorher noch eine andere IP gegeben. 

    Was jetzt sehr eigenartig ist, wenn der Server online ist, dann dauert der Login der User max. 5 Sekunden. Wenn der Server offline ist, dann dauert es gern 15-20s bis der Login funktioniert.

    Mein wissen reicht aber jetzt nicht aus, wo ich da nachsehen könnte. Hat jemand eine Idee?
    marți, 4 august 2020 09:07
  • Wenn Du einen Domain Controller ausschaltest, ohne ihn zu demoten, wird sein \\SYSVOL und \\NETLOGON von DFS-N als valides UNC-Ziel ausgeliefert.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    marți, 4 august 2020 09:12
  • Vielen Dank, und deswegen dauert dann der Login so lang?

    Wenn ich eingeloggt bin, dann steht aber in der %logonserver% Variable der richtige server.

    Ich wollte eigentlich mit dem demoten noch ein wenig warten, falls ich irgendetwas vergessen habe...'


    Ich hab ja aktuell 3DCs aktiv... d.h. es sollte dann immer ALLE DCs online sein weil es sonst zu lange braucht? 

    Liegt das an DFS-N? War das mit FRS noch anders?
    • Editat de leon_20v marți, 4 august 2020 09:29
    marți, 4 august 2020 09:19
  • Vielen Dank, und deswegen dauert dann der Login so lang?

    Klar, denn er versucht die GPOs aus einem Pfad abzurufen, den er nicht erreichen kann.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    marți, 4 august 2020 09:28
  • Ich hab im Testsystem DCPROMO durchgeführt und ihn ausgeschalten. 

    Dauert das länger bis das sich publiziert hat? Weil von der Loginzeit ist es immer noch gleich lang.


    /EDIT
    Was noch eigenartig ist, in den ganzen Lookupzoonen steht der alte DNS noch drinn... hab die mal raus gelöscht. 

    Dazu war komisch das beim dc01 IP-Adresse = Unbekannt stand. Ich hab die mal richtig eingetragen.
    • Editat de leon_20v marți, 4 august 2020 11:34
    marți, 4 august 2020 11:22
  • Nach dem Aufräumen im DNS und setzen der IP-Adressen der Nameserver (warum auch immer das nicht automatisch war) scheint der Login jetzt wieder in Normalzeit zu funktionieren.

    Ich habe zum Test noch meine Terminalserver aus einem Backup auf den Testserver gespielt. Der Testserver sollte eigentlich genügend Leistung haben. 

    Einen der SessionHosts musste ich aus der Domäne entfernen und wieder hinzufügen. Weiß nicht was der hatte... Die Zertifikate habe ich ausgetauscht.

    Jetzt ist hier aber noch folgendes komisch:
    Nach Eingabe der IP-Adresse in MSTSC dauert es sehr lange bis die Verbindung aufgebaut wird. Es steht sehr lange: Die Remoteverbindung wird konfiguriert / gesichert. Dann geht es aber normal schnell... 

    Auch wenn ich das ICON aus dem WebAccess mit Single Sign On verwende, dauert es ewig bis erst mal das Fenster kommt (man denkt es passiert nichts).

    In der Produktivumgebung geht das extrem schnell, da die Terminalserver auf einer genau gleich schnellen Maschine wie der Testserver laufen (sehr schnelle SSDs).

    Was kann hier noch sein? Hat jemand einen Tipp?





    • Editat de leon_20v marți, 4 august 2020 13:36
    marți, 4 august 2020 13:34
  • Hat dein Session Host ein Zertifkat für RDP? Dann könnte es ein Timeout beim CRL/OCSP-Check sein.

    Edit: Wenn es daran liegt und das nicht durch Korrektur von CDP/OCSP zu beheben ist: Firewall outgoing zur IP des CDP/OCSP Servers blockieren, dann geht's sofort weiter.

    marți, 4 august 2020 14:59
  • Vielen Dank für deine Antwort und deinen Hinweis.

    Das könnte gut sein. Ich habe auf dem RDP-Server ein neues Zertifikat angefordert und bei der Zertifizierungsstelle werden immer noch die 2 CAs angezeigt die es nicht mehr gibt. Im ADSI Editor habe ich die CAs gelöscht(jetzt werden die nicht mehr als vertrauenswürdige Stammzertifizierungstellen verteilt). Wo nimmt er jetzt die CAs noch her? Ich habe die Haken beim Zertifikat erstellen zwar entfernt, aber evtl. sucht er dennoch nach diesen CAs?


    Ich glaub jetzt hab ich dann bald alles gefragt, was es zu CAs zu fragen gibt ;)

    Wo kann ich die letzten Reste noch löschen?


    Das Gateway ist aktuell auch nicht verfügbar, hat das damit was zu tun?


    • Editat de leon_20v marți, 4 august 2020 15:39
    marți, 4 august 2020 15:33
  • Vielleicht hilft Dir das: https://mssec.wordpress.com/2013/03/19/manually-remove-old-ca-references-in-active-directory/

    Greetings/Grüße, Martin - https://mvp.microsoft.com/en-us/PublicProfile/5000017 Mal ein gutes Buch über GPOs lesen? - http://www.amazon.de/Windows-Server-2012--8-Gruppenrichtlinien/dp/3866456956 Good or bad GPOs? My blog - http://evilgpo.blogspot.com And if IT bothers me? Coke bottle design refreshment - http://sdrv.ms/14t35cq

    miercuri, 5 august 2020 07:26
  • Vielen Dank für den Link, zwischenzeitlich hab ich auch etwas ohne Bilder bei Microsoft gefunden wo genau die gleichen Schritte erklärt sind.

    Das einzige was ich nicht hinbekommen habe das Zertifikat aus dem NtAuthCertificates zu bekommen. 

    certutil -viewdelstore “ldap:///CN=NtAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=tomdemo,DC=se?cACertificate?base?objectclass=certificationAuthority” 
    

    Was müsste ich bei "se?" eintragen?



    Über diesen Link habe ich herausgefunden, das man das auch über die Grafische Oberfläche über die PKIView.msc machen kann:  https://www.sysadmins.lv/blog-en/understanding-active-directory-certificate-services-containers-in-active-directory.aspx

    I
    ch hab das alte Zertifikat dann mal hier gelöscht.


    Leider braucht es auf meinem Testsystem immer noch sehr lang, bis die Remoteverbindung Initialisiert ist... Das finde ich sehr eigenartig. Die Eingabemaske für User / PW kommt sofort, Dann kommt sofort die Zertifikatsmeldung (weil ich ja über die IP zum test gehe). Dann kommt relativ lange "Remoteverbindung wird gesichert...". Im Produktivsystem geht das alles instant. 

    --> Ich hoffe, dass es im Produktivsystem so schnell bleibt nach der Umstellung.



    • Editat de leon_20v miercuri, 5 august 2020 11:30
    miercuri, 5 august 2020 11:27
  • Was müsste ich bei "se?" eintragen?

    DC=tomdemo,DC=se ist der DN der Domäne. Das mußt natürlich durch den DN von DEINER Domäne ersetzen.

    Greetings/Grüße, Martin - https://mvp.microsoft.com/en-us/PublicProfile/5000017 Mal ein gutes Buch über GPOs lesen? - http://www.amazon.de/Windows-Server-2012--8-Gruppenrichtlinien/dp/3866456956 Good or bad GPOs? My blog - http://evilgpo.blogspot.com And if IT bothers me? Coke bottle design refreshment - http://sdrv.ms/14t35cq

    miercuri, 5 august 2020 14:37