_n4p_

@Bennox und du findest das die Klärung dieser Fragen in den Antrag gehört?

Jenes Script? #Region VARIABLES # WSUS Connection Parameters: [String]$updateServer = "<ip wsus server>" [Boolean]$useSecureConnection = $False [Int32]$portNumber = 8530 # Cleanup Parameters: # Decline updates that have not been approved for 30 days or more, are not currently needed by any clients, and are superseded by an aproved update. [Boolean]$supersededUpdates = $True # Decline updates that aren't approved and have been expired my Microsoft. [Boolean]$expiredUpdates = $True # Delete updates that are False and have not been approved for 30 days or more. [Boolean]$obsoleteUpdates = $True # Delete older update revisions False have not been approved for 30 days or more. [Boolean]$compressUpdates = $True # Delete computers that have not contacted the server in 30 days or more. [Boolean]$obsoleteComputers = $True # Delete update files that aren't needed by updates or downstream servers. [Boolean]$unneededContentFiles = $True #EndRegion VARIABLES #Region SCRIPT # Load .NET assembly [void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") # Connect to WSUS Server $Wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::getUpdateServer($updateServer,$useSecureConnection,$portNumber) # Perform Cleanup $CleanupManager = $Wsus.GetCleanupManager() $CleanupScope = New-Object Microsoft.UpdateServices.Administration.CleanupScope($supersededUpdates,$expiredUpdates,$obsoleteUpdates,$compressUpdates,$obsoleteComputers,$unneededContentFiles) $CleanupManager.PerformCleanup($CleanupScope) #EndRegion SCRIPT

Also der Kunde gibt ein Budget von 1500€ vor und du bietest ihm ein System für 500€ an. Was passiert wenn da Hardware kaputt geht? Wer tauscht die aus? In wie fern ist da ein selbstgebasteltes System besser als eines für das der Hersteller 2 oder mehr Jahre Support gibt? Nur weil der Kunde etwas will muss das nicht sinnvoll sein, man darf den Kunden auch beraten. klar und noch n Passwort-Manager, einen Chat-Server für die interne Kommunikation, ein CMS und noch ein Kanban-Board ... Das Projekt wird nicht besser wenn du viele Dinge "reinpackst". Du sollst ein Thema mit der entsprechenden Tiefe bearbeiten. Zum Beispiel so wie Chief Wiggum es geschrieben hat. Wie verträgt sich dieser Ansatz überhaupt mit der Vorgabe eigenständige Hardware für das Wiki zu benutzen?

Er meint das ein RAID kein Backup ist. Ein RAID ist zwar ein Teil des Datensicherheitskonzeptes, aber halt keine Datensicherung. Das Soll-Konzept geht viel zu sehr ins Detail. Du brauchst Entscheidungen im Projekt. Aber das wurde ja schon gesagt. Kosten von 1500 € für die Hardware? ein i5 und 4GB RAM? Für 1500 € bekomm ich n XEON 1230v6 mit 8 GB RAM, nem RAID Controller und 2x 500GB SSD. und hab 2 Jahre NBD-Support. Warum überhaupt eigene Hardware? Sind keine VMs oder Container möglich? Insgesamt finde ich MediaWiki installieren und Benutzer einrichten ist zu wenig. Hardware planen, kaufen und installieren bringt in dem Fall nicht viel. Zum einen planst du mit nem i5 und 4GB RAM im Grunde einen Office PC dafür zu benutzen und zum anderen köntne vermutlich ein RasPi den Workload bewältigen.

also du hast da einen schönen Arbeitsauftrag bekommen, viel Spaß beim durchklicken. Falls du den Antrag so abgibst und er genehmigt wird, wünsche ich dir auch noch einen freundlichen Prüfer. Wenn du nur Meinungen willst die dir zustimmen höre jetzt auf zu lesen und freue dich. Ansonsten auch hier wieder das übliche Entscheidungsfindung gehört ins Projekt nicht in den Antrag. Mit dem Titel des Antrages hast du dir jede Entscheidungsmöglichkeit innerhalb des Projektes genommen. Dann tust du im Zeitplan auch noch so als würdest du "Lösungen" vergleichen obwohl ja schon alles feststeht. Inhaltlich ist es auch eher naja. Ich mein für kaum jemand der Windows Server wegen der Lizenzkosten vermeiden will ist der nächste logische Schritt "macOS Server". Sowohl MDM als auch Praxissoftware gibt es auch für Linux. Also nix mit "die 2 Lösungen vergleichen". Klar macOS Server ist vermutlich mit wenig bis 0 Aufwand zu verwalten, was bei einer kleinen Praxis sinnvoll sein kein. Prinzipiell spricht auch nix dagegen im Projekt zu dem Schluss zu kommen in diesem Fall macOS Server einzusetzen. Aber einfach macOS Server zu installieren und festzulegen das damit nun alle Probleme gelöst sind wird nicht funktionieren.

Ansich ganz schön, aber .. Das Soll- KONZEPT ist viel zu spezifisch. LTO 5 kann 3 TB komprimiert nicht 1,5. 6 TB komprimiert wäre LTO 6, das ist mittlerweile 7 Jahre alt. LTO 8 ist zwar aktuell, kann aber die LTO 5 Bänder nicht mehr lesen. den Punkt genauer erläutern. Punkt 1 und 3 nicht erklären wie deine Lösung aussieht Punkt 2 vielleicht umformulieren, das klingt auch erstmal so als wäre da schon alles entschieden.

Du sollst in deinem Projekt ein reales Problem betrachten und lösen. Dazu gehört die Planung, die Evaluierung von Lösungen, das Umsetzen einer Lösung und die Dokumentation. Welches Problem löst man dann mit Mail-Signaturen und einem Exchange Update (oder Upgrade)?

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&amp;category1=998&amp;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?