_n4p_

würde ich lassen, das projekt soll tiefe haben, keine breite Ich hatte eigentlich gefragt, weil du den Exchange erwähnt hast der dann aber nicht mehr auftauchte. Du kannst dein Projekt ohne Probleme ohne Exchange machen, dann solltest du aber schreiben das der Exchange außerhalb deines Projektes umgesetzt wird (anderer Kollege, späterer Zeitpunkt, ..) Prinzipiell sollst du Entscheidungen innerhalb des Projektes treffen und diese auch Begründen. So wie der Antrag jetzt ist, ist er eher eine Arbeitsanweisung und du klickst dich durch die Installationen. Dazu kommen dann noch inhaltliche Probleme. Die Überschrift des Threads ist eigentlich ganz gut. Wenn du das als grundlage nimmst und erstmal vergisst das du virtualisieren willst, kannst du im Projekt feststellen was der Kunde will und braucht und erst dann entscheiden wie du das umsetzen möchtest. Da es Best-Practice ist den ersten DC nicht zu virtualisieren und du aktuell nur 2 Server aufsetzen möchtest, ist Virtualisierung hier vllt gar nicht sinnvoll. Das ist aber eine Entscheidung die IM Projekt getroffen wird, nicht davor.

Du legst dich schon vor Beginn des Projektes auf alles fest was du machen willst/musst. Nicht unbedingt die beste Idee. Ansonsten so wie arlegermi schrieb, etwas dünn. Inhaltlich: * an der einen Stelle willst du den ESXi auf nem NAS/SAN installieren und dann wieder ist das NAS/SAN per iSCSI angebunden. * warum ESXi wenn du eh nur 2 VMs willst? warum kein HyperV? * wo kommt das NAS/SAN her? * warum den Server selbst zusammenbasteln? Was ist an der Stelle mit dem Support für die Hardware bei Defekten? * Der Exchange ist nicht teil deines Projektes?

das ist richtig + fügt Rechte hinzu und lässt die anderen Rechte wie sie waren = setz das Recht und löscht die anderen - entfernt das Recht und lässt den Rest

Ich habe zwar keine persönliche Erfahrung mit sowas, und der Kollege der sowas mal beantragt hat, hat das auch für sein Jurastudium beantragt. Das jedoch hat gefühlt ewig gedauert und er musste immer wieder Ärztliche Bescheinigungen vorlegen und so weiter. Der einzig sinnvole Rat an der Stelle wäre also, den Antrag so früh wie möglich zu stellen.

Mal die Gliederung wie ich es machen würde. * Titelseite * Vorstellung Vortragender * Vorstellung deiner Firma und des Kunden * Projektbeschreibung / Problemstellung * Mögliche Lösungen * die ausgewählte Lösung allgemein vorstellen und begründen * kurze aber spezifische Beschreibung von 2 (max 3) ausgetauschten/optimierten Systemen * aufgetretene Probleme und wie diese gelöst wurden * ist das Projekt insgesamt nicht abgeschlossen noch aufzeigen was danach noch zu tun war/ist * Fazit / Ausblick / "Lessons learned" * Bedanken * Zeit für Fragen

Wieviel Zustände können mit 4 Bits dargestellt werden? - 16 Wieviel Bits brauche ich für mindestens 213? 4 - 16 5 - 32 6 - 64 7 - 128 8 - 256 mathematisch: 213 = log2(x) -> round(log(213)/log(2))

Nunja, es gibt halt vermehrt sowas: https://store.steampowered.com/search/?sort_by=Released_DESC&category1=998&publisher=Laush Studio "Studios" die teils wöchentlich irgendwelchen Mist veröffentlichen. Das sind dann meist auch Sachen die man einfach fix zusammengeklickt hat oder wo der größte Aufwand war die Grafiken zu tauschen. Komplexe Spiele macht man auch mit Unity nicht am Fließband. Hinzukommt, das es heute deutlich einfacher geworden ist Figuren zu designen und animieren und dann in Grafikengine X zu importieren. In der Liste der Veröffentlichungen sind aber auch DLCs usw. Sowas kann man aber nur bedingt als neues Spiel werten. Lets Plays schaue ich eigentlich nicht um die Perlen zu finden. Gut Horizon Zero Dawn und RDR2 hab ich nach anschauen von Stream/Let's Play gekauft. Das war dann aber eher das ich die Story gut fand und ich nicht X Wochen warten wollte bis die letzte Folge erscheint. Aber die meisten Spiele sind aus anderen Gründen in der Bibliothek gelandet. Indie Games schau ich mir nur an wenn Steam oder Freunde die empfehlen. Ich bin da nicht sehr experimentierfreudig ;D

Na dann. Das kann man zwar prinzipiell mit Anisible oder ähnlichem erledigen, das würde ich aber hier nicht unbedingt so machen. VMWare kann für sowas Templates. Dabei installiert man in der VM alles was man braucht und macht die Grundkonfiguration. Ist man damit fertig konvertiert man die VM in ein Template. Braucht man dann eine neue VM kann man die aus dem Template erzeugen. Und da wäre dann die Frage was man noch sinnvolles mit Ansible machen könnte.

Dürfte etwas ausführlicher sein und der Zeitplan ist wieder ohne Backup + Failover

Jetzt noch Argumente warum man Backup und Failover braucht damit es nicht so aussieht als würde man das nur machen weil man noch zeit übrig hat. Und dann nochmal alles zusammen als kompletten Antrag

Ich würde das als ausformulierte Sätze in die Projektbeschreibung bringen.

dafür gibt es Templates (jinja) und roles. Wenn ihr das ganze als VMs zur Verfügung stellt, könnte man die eigentliche Installation mit beispielsweise Vagrant erledigen. Im Projekt zu sagen: "ich benutze dafür Ansible, weil ich damit schon gearbeitet habe" und andere Möglichkeiten und eventuell auch deren Schwächen zu nennen, is völlig akzeptabel. Es schon im Antrag zu schreiben ist eher schlecht. Und sollte man während des Projektes feststellen, das Problem X mit Puppet besser zu lösen wäre und deswegen doch Puppet nutzt, wäre das Projekt "X mit Ansible" eigentlich gescheitert. Zeitersparnis, geringer Supportaufwand und schnellere Fehleranalyse und Behebung sind gute Argumente für die Wirtschaftlichkeit

Könnte im Zusammenhang mit Backup und Failover zu sagen ist schonmal schlecht. Wenn die SSO-Lösung nicht so sehr benötigt wird das man darauf verzichten kann, wozu dann überhaupt? Backup des Systems ist notwendig, es sei denn du hast so wenig Passwörter, das eine Neuinstallation mit Neueingabe schneller ist, als ein Backup zurückzuspielen. Failover ist notwendig, wenn ihr nicht ne Woche warten könnt bis das System wieder läuft. Ist das SSO-System die einzige Stelle an der die Passwörter liegen, hast du ohne Failover oder Redundanz einen hübschen Single Point of Failure von einem wichtigen System gebastelt. Aus den Ausführungen kannst du dir Argumente für den Projektantrag basteln warum du das brauchst Beachte, dass Einrichtung und Planung von Backup und Failover mit in den Zeitplan müssen.

Mir ist nicht ganz klar wie das zusammenpasst. Wie installierst du denn mit Ansible ein Linux? 10 Stunden an nem Playbook schreiben scheint etwas viel und erst recht ein 4 Stunden langes ausrollen.

Nein Willkommen im Forum

Dockerfile Damit man nicht mit jedem Container alles neu machen muss, kann man sich über Dockerfiles eigene Images erzeugen. Die hier gezeigte Version ist mehr oder weniger die finale Version. Davor gab es natürlich diverse Fehlversuche sei es wegen eigener Fehler oder weil man manche Dinge auch einfach nicht vermutet hätte. Unter Windows Nanoserver gibt es beispielsweise gar kein msiexec und das msiexec vom Server Core schreibt die Registryeinträge gar nicht oder irgendwohin wo sie später nicht gefunden werden. Mit setx kann man zwar globale Umgebungsvariablen setzen, startet man den Apache aber als Dienst, wird die Pfadeinstellung dennoch nicht genutzt. # Wir benutzen unser schon gepulltes Windows Servercore Image FROM servercore:ltsc2019 COPY install /install # Installiert die ODBC Treiber im Image # Wer hier eine Ausgabe zum Debuggen will kann noch "/l! out13.log" anhängen RUN ["msiexec", "/a C:\\install\\msodbcsql_13.msi", "/qn"] RUN ["msiexec", "/a C:\\install\\msodbcsql_17.msi", "/qn"] # Installation von VC Redist - 15 wird bei Server 2019 nicht benötigt RUN ["C:\\install\\vc_17.exe", "/quiet", "/install"] RUN ["C:\\install\\vc_13.exe", "/quiet", "/install"] # Die Registry-Datei für die ODBC Treiber importieren RUN "reg import C:\\install\\odbc.reg" # install brauchen wir nicht mehr RUN "RMDIR /S /Q C:\\install" # /instantclient entspricht dann C:\instantclient im Image COPY instantclient /instantclient # einfach großartig - wenn jemand eine Idee hat wie ich Apache als Service erklären kann wo der instantclient liegt ... ENV PATH="C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Users\ContainerAdministrator\AppData\Local\Microsoft\WindowsApps;C:\instantclient" # Apache usw. kopieren - *1 COPY webapp /webapp WORKDIR /webapp # wir möchten mit dem Container reden EXPOSE 80 # kopieren von php und der php.conf ins Apache config Verzeichnis - *2 COPY php/php /webapp/php COPY php/php.conf /webapp/Apache24/conf/extra # zum Testen/Debuggen #ENTRYPOINT ["cmd.exe"] # und los geht’s ENTRYPOINT ["C:\\webapp\\Apache24\\bin\\httpd.exe"] Das Dockerfile kommt dann mit in das Build-Verzeichnis und das neue Image kann mit folgendem Befehl erzeugt werden. PS E:\build\>docker build -t test . Mit PS E:\build\>docker run -it -p 80:80 --name test_container test starten wir den Container und prüfen das alles wie gewünscht funktioniert. Ist das der Fall teilen wir das Dockerfile in 3 Dateien. Das Dockerfile wird dann bei *1 und *2 aufgeteilt. Der erste Teil bleibt wie er ist und wir nennen das Dockerfile core2019. Und bauen ein Image daraus. PS E:\build\>docker image build -t core2019 -f .\core2019 . Das zweite Dockerfile sieht dann so aus FROM core2019:latest COPY webapp /webapp EXPOSE 80 und das dritte so FROM apache_core2019:latest COPY php/php /webapp/php COPY php/php.conf /webapp/Apache24/conf/extra WORKDIR /logodata ENTRYPOINT ["C:\\webapp\\Apache24\\bin\\httpd.exe"] Ich habe die Dockerfiles nach dem Image benannt das sie erzeugen. Die weiteren Images baue ich also mit PS E:\build\>docker image build -t apache_core2019 -f .\apache_core2019 . PS E:\build\>docker image build -t php_apache_core2019 -f .\php_apache_core2019 . Damit hat man zwar etwas Overhead bei jedem Build, da jedesmal das komplette Verzeichnis zum Buildprozess übergeben wird. Allerdings können wir so sehr einfach andere PHP und/oder Apache Versionen in ein anderes Image packen ohne den Standard zu verlieren oder die grundlegende Installation wiederholen zu müssen. Lauf Docker, Lauf! Die entstandenen Images kann man nun wieder mit kürzeren Namen taggen und schließlich starten PS> docker run --restart unless-stopped -d --name flamara -p 17000:80 -v E:\share\develop:C:\webapp\docroot -v E:\share\config:C:\webapp\docroot\config\ --dns=10.0.0.20 php2019:latest Mit -p mappen wir einen Port des Hosts zu dem freigegebenen Port des Containers. Dann mappen wir mit -v zum einen die Webapplikation selbst ins docroot des Containers und auch die Konfiguration der Software. So können wir beliebige Versionen der Software mit der gleichen Konfiguration (Benutzer, Rechte, Datenbankanbindung) in der gleichen Umgebung testen. Die nächsten Schritte wären nun, das Ganze mit einem Linux Base-Image zur erstellen und danach automatisierte Builds.

Sehr oft "Ich" .. also wie schon zu vermuten war kein reales Projekt. Der Ausbilder stellt fürs Abschlussprojekt mal wieder die Restekiste bereit. Großartig. Gibt es keine realen Projekte? Es geht halt auch nicht darum das du irgendeine Software auf irgendwelcher Hardware installierst. Das Projekt soll ein Problem lösen. Aus den gegebenen Dingen wird halt leider kein Projekt für einen Kunden das einem nicht um die Ohren fliegt. Entweder dem Kunden oder aber dir bei der Präsentation. Man könnte aber zumindest eine Windows Server 2019 Evaluierungs/Testumgebung daraus bauen. Da käme es jetzt auf dich an dir das Problem dazu auszudenken (vorhandene Serverlizenzen sind alt, prüfen ob aktuell eingesetzte Software mit Server 2019 noch funktioniert, neue Features von 2019 testen,...)

Nö das ist richtig und ich habe dich offenbar falsch verstanden. Du möchtest also etwas in dieser Art: https://www.passwordserver.de/universal-sso/ ? Tipps zur Tiefe: Wie kritisch ist ein Ausfall des Systems? (Failover, Backup, ...) Mitarbeiter im Außendienst? Funktioniert die Lösung mit allen Zielsystemen? Was passiert wenn ein Zielsystem nicht unterstützt wird?

von den genannten Punkten abgesehen, ergibt kaum etwas an dem Antrag inhaltlich einen Sinn

du möchtest also eher eine single-sign-on lösung bauen als eine passwortverwaltung? Wenn die Reise Richtung ADFS und oauth geht, kann das schon was werden. Das ändert freilich nichts daran, das eine stumpfe Installation von X kein Projekt ist. Wenn man so etwas einführen möchte, sind diverse dinge zu beachten.

Vorbereitung Als nächstes bereiten wir die Build-Umgebung vor. Wir laden Apache, PHP, passende vc_redist (17 und 13), Microsoft ODBC Treiber 13 und 17, SQLSRV5.3, und einen Oracle Instantclient herunter. Ich überspringe an dieser Stelle einige Schritte und zeige nur die endgültige Version. Ihr verpasst aber nichts Dramatisches, der Buildprozess wurde nur einige Male verändert und die Verzeichnisstruktur entsprechend angepasst. Der Sinn oder Unsinn wird dann vermutlich klar, wenn wir uns die Dockerfiles ansehen. Also legen wir erstmal folgende Struktur an: Build ├───install ├───instantclient ├───webapp │ ├───Apache24 │ └───docroot └───php └───php In install legen wir die VC Redist Installer und die ODBC Treiber MSI-Pakete ab. Ich habe die umbenannt um sie leichter unterscheiden zu können. Den Instantclient kann man einfach entpacken und den Inhalt des instantclient_18_3-Verzeichnisses in instantclient ablegen. In php/php wird das heruntergeladene PHP entpackt und in webapp/Apache24 der Webserver. Die httpd.conf nach Belieben anpassen, darauf achten das das DocumentRoot webapp/docroot sein soll und noch eine webapp/Apache/conf/extra/php.conf includieren. Die gibt es zwar nicht, das erledigt dann der Buildprozess. Die php.conf kommt nach /php und sieht etwa so aus: LoadModule php7_module "C:\webapp\php\php7apache2_4.dll" AddType application/x-httpd-php .php PHPIniDir "C:\webapp\php" DirectoryIndex index.php Nun noch PHP konfigurieren und dann sind die Vorbereitungen abgeschlossen. Eigentlich ... also quasi schon ... Aus irgendeinem Grund werden die Registry-Einträge für die ODBC-Treiber nicht geschrieben. Weder beim Build noch im laufenden Container. Also erstellen wir noch eine odbc.reg und legen die mit nach /install. Die Datei kann man erzeugen, indem man den Schlüssel exportiert. Dazu kann man kurzzeitig die ODBC Treiber auf dem Host installieren.

Einleitung Die grundlegende Frage gleich vornweg: Warum sollte man Docker auf einem Windows Server betreiben? Nunja, weil man es kann. Außerdem besteht die Infrastruktur bei den meisten unserer Kunden aus MS SQL-Server und Windows Servern auf denen unsere Software installiert wird. Hier könnte man nun argumentieren, dass unsere Software "nur" PHP und Apache benötigt und das zusammen mit PostGreSQL oder ORACLE durchaus auf Linux laufen könnte. Ja, ist richtig, wir möchten aber nicht auch noch irgendwelche Linux Installationen bei unseren Kunden pflegen. Sucht man, naiv wie man ist, einfach mal nach "docker windows", landet man früher oder später bei "Docker CE for Window". Hat man das installiert und den ersten Container gestartet, wird einem auffallen das die Container nicht beim Booten starten. Da ist auch nichts falsch konfiguriert, das soll so sein. Dafür gibt es sicherlich Gründe. Diese Version ist für Entwickler gedacht, die Docker auf ihrem Windows 10 PC betreiben wollen. Wollen wir aber gar nicht … Installation Also installieren wir mal das richtige PS> Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force PS> Install-Module -Name DockerMsftProvider -Force PS> Install-Package -Name docker -ProviderName DockerMsftProvider -Force Danach möchte der Server einmal neu starten und wir können mit docker version schauen ob das funktioniert hat. PS C:\> docker version Client: Version: 18.09.0 API version: 1.39 Go version: go1.10.3 Git commit: 33a45cd0a2 Built: unknown-buildtime OS/Arch: windows/amd64 Experimental: false Server: Engine: Version: 18.09.0 API version: 1.39 (minimum version 1.24) Go version: go1.10.3 Git commit: 33a45cd0a2 Built: 11/07/2018 00:24:12 OS/Arch: windows/amd64 Experimental: true An der Stelle konfigurieren wir den Dienst erstmal ein wenig. Das kann man prinzipiell auch über eine json-Datei erledigen. Anleitungen dazu findet man genug. Man kann die Parameter aber auch direkt dem Dienst übergeben. PS E:\> Stop-Service Docker PS E:\> Remove-Service Docker PS E:\> New-Service -Name Docker -DisplayName "Docker Engine" -StartupType Boot -BinaryPathName "C:\Program Files\Docker\dockerd.exe --run-service -H npipe:// -H 0.0.0.0:2375 --data-root=E:\docker --experimental" PS E:\> Start-Service Docker Für Remove-Service benötigt man allerdings PowerShell Version 6. Die gibt es zwar seit August 2018, ist dennoch nicht im Server 2019 enthalten. Nach dem Neustart des Dienstes legt Docker nun seine benötigte Verzeichnisstruktur unter E:\docker an. Und durch –experimental können wir später –plattform=linux nutzen. Nun ist es endlich soweit, wir holen unser erstes Image. Normalerweise würde man das einfach mit PS> docker pull microsoft/nanoserver erledigen. Das funktioniert zwar, aber ... Das was man dann bekommt ist ein Server 2016 SAC Image. Was per se zwar nicht verkehrt ist, aber im ersten Moment auf einem Server 2019 nicht funktioniert. Hier müsste man dem docker run noch ein --isolation=hyperv mitgeben oder man holt ein neues Image. Für Images die zum Server 2019 passen benötigt man spezifische Tags und kann sich nicht auf den Standard :latest verlassen. Images vom Nanoserver und Windows Server Core holen wir mit. PS> docker pull mcr.microsoft.com/windows/nanoserver:1809 PS> docker pull mcr.microsoft.com/windows/servercore:ltsc2019 Anschließend verpassen wir den Images noch neue Tags PS> docker image tag mcr.microsoft.com/windows/nanoserver:1809 nanoserver:1809 An dieser Stelle können wir auch schon mal einen Container mit einem der Images starten. PS> docker run -it --name testdings microsoft/nanoserver powershell Damit bekommen wir eine PowerShell Instanz in dem laufenden Container und können Dinge tun. Updates installieren, wäre eines dieser Dinge. Das erledigt man normalerweise mit sconfig auf der geöffneten PowerShell. In den nächsten Teilen bereiten wir die Build-Umgebung vor, basteln uns ein Dockerfile und bewundern das Ergebnis

nein. dafür gibt es vom gleichen Entwickler NTLite. Das ist aber in der kostenlosen Variante eingeschränkt.

Also man kann das wohl mit einigem Aufwand umsetzen. Zunächst bastelt man sich ein Script das die arbeiten aus Maniskas link erledigt und den Rechner neu startet und noch ein Script um die Änderungen rückgängig zu machen. Dann baut man sich winexe und etherwake für den SteamLink und bastelt ein paar Scripte damit der SteamLink den PC beim booten per etherwake startet und per winexe das Script auf dem Windows PC startet.

https://kopano.com/ gibt auch ne Community Edition https://kopano.io/ da müsst ihr sehen ob die Features ausreichen.