magheinz

Ein weiterer Vortreil: einmal konfiguriert und trotzdem für alle VMs nutzbar. Ab irgendeiner Anzahl an VMs stellt man sich doch immer die Frage: geht das auch einfacher. 
Bei mir kommt die Frage meistens recht früh, so ab der zweiten VM.
Noch ein Vorteil: es ist OS-unabhängig was die VM betrifft. 
Letzter Vorteil: der host kann sich um den Laetenausgleich kümmern und dabei den traffic aller VMs berücksichtigen. Macht das jede VM einzeln, dann kostet es auch mehrfach. 
 

Mir ist jetzt nicht ganz klar ob ich wirklich weitere Tips geben sollte.
Unsere Spamfilter haben schon genug zu tun. Martin liegt da nicht ganz falsch.
 
Schau dir einfach mal opensense, ipcop etc an. Solltest du das nicht ohne viel Hilfe hinbekommen, mein Tip: dann lass es jemanden machen.

An sich stimmt es aber, Erfahrung sagt nichts über die Qualität der Arbeit aus.
 
Hier wird eine Lösung für ein Problem gesucht was es eigentlich gar nicht geben dürfte da man hier die denkbar ungünstigste Herangehensweise genutzt hat. 
Das jetzt der Kunde auch noch mit dem Geld knausern ist dann wirklich ein Problem. 
 
Jetzt zu einer möglichen Lösung: arbeitet am Exchange mit lokalen E-Mail Adressen und richtet auf dem Linux Server eine Adressumschreibung ein.
 
Alle öffentlichen emailadresse landen auf dem providerserver und die Exchangepostfacher werden vom linux Server abgeholt und an EMPFÄNGER@DOMAIN.exchange zu gestellt. 
Schickt ihr E-Mails raus schreibt der linux Server den Absender um. Da sollte mit einem postfix gehen.

Du schreibst eine formatierte Liste nach $role. Lass doch mal "|FL" weg.

Das ist ne Desktopplatte. Da erübrigt sich alles an Fragen wegen Support etc.
 
Brauch man den "Dell OpenManage Server Administrator" unbedingt?
 
Die Frage nach der Geschwindigkeit, mit oder ohne VM kann man so nicht beantworten. Das kommt auf den Einzelfall an.
 
Das Monitoring auf dem Host ist halt wie ein Virenscanner. Im dümmsten Fall  ist das Monitoring gleich mit tot.
Bei nur einem Server kann man das aber vermutlich verschmerzen.
Ein extra Monitoring macht meiner Meinung nach nur Sinn wenn man auch irgend etwas damit macht. Das eine VM nicht startet merkt man auch so. Sonst würde man sie nicht starten. Also entweder monitored man komplexere Umgebungen, baut ums Monitoring eine Automatisierung oder z.B. eine eskalierende Benachrichtigung. Unser Icinga z.b. öffnet und schließt automatisch Tickets. Das Ticketsystem macht dann die eigentliche Benachrichtigung mit allem drum und dran(Eskalierung, SLAs etc). Nur bestimmte 
Fehlerfälle werden direkt von icinga gemeldet. Dann aber auf allen Kanälen(E-Mail, SMS jabber etc)

Pro VM möglichst nur ein Dienst. Das ist auch im IT Grundschutz so angedacht.
M 4.97 Ein Dienst pro ServerVerantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT
Verantwortlich für Umsetzung: Administrator
Viele Schwachstellen in IT-Systemen sind einzeln nicht für einen potentiellen Angreifer ausnutzbar. Häufig wird erst durch die Kombination von Schwachstellen ein erfolgreiches Eindringen in einen Rechner möglich. Abhängig von der Bedrohungslage und dem Schutzbedarf der Dienste kann es deshalb zweckmäßig sein, auf einem Rechner nur einen Dienst zu betreiben. Dies betrifft vor allem Server, die Dienste auch ins Internet oder in andere Fremdnetze anbieten.
 
https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/_content/m/m04/m04097.html

Ich würde vorschlagen das anders zu machen
 
interface XYZ
switchport mode trunk
switchport trunk nativ vlan 5
switchport trunk allowed vlan 2,5
 
"Note You should apply the switchport host command only to interfaces connected to an end station."
Du willst da aber wohl einen switch drann hängen.
 
Hier gehen VLAN2-Pakete durch und alle ohne VLAN werden mit der ID 5 getaggt.
Musst du an diesem Port überhaupt taggen? falls nein setze das nativ vlan auf eines welches sonst nicht genutzt wird. Dann gehen nur erlaubt getaggte Pakete durch und alle ungetaggten versanden im Switch.

Du hast jetzt zwei DHCP-Server?

so, bin wieder am Rechner.
 
$initialPassword wird mit der Funktion von oben (Get-TempPassword) befüllt.
-Force ist die Bestätigung das du verstanden hast das Passwort im Plaintext übergeben wird. Ansonsten nimmt das commandlet keine Plaintextpasswörter an.
 
Relativ weit oben im Script steht
try{ $InitialPassword = GET-Temppassword –length 10 }catch{ "konnte kein Passwort finden" exit 1 } Nach dem Anlegend es User gibts dann folgene Zeilen:
$Info += "Das Username lautet '$UserName'"+ [System.Environment]::NewLine $Info += "Das Passwort für den ersten Login lautet '$initialPassword'"+ [System.Environment]::NewLine $Info += "Dieses Passwort muss bei der ersten Anmeldung geändert werden."+ [System.Environment]::NewLine $info += [System.Environment]::NewLine $Info += "Wichtige Informationen:"+ [System.Environment]::NewLine Dazu kommen dann noch ein paar mehr mit der OWA-URL und diversen anderen wichtigen und unwichtigen Infos.
Das wandert dann mit
$Info | Out-Printer -Name \\$PRINTSERVER\$DRUCKERNAME direkt auf den Drucker hier im Büro. Der Neue Mitarbeiter bekommt den Zettel in die Hand gedrückt und kann direkt loslegen.
Theoretisch könnte man das script aus der Personalverwaltungssoftware beim Anlegen des Mitarbeiters direkt auslösen. Den Ausdruck würde man dann dem Neuen mit dem Laufzettel in die Hand geben.
 
Das ganze New-User.script ist inklusive Fehlerbehandlung, Mailbox anlegen etc knappe 400 Zeilen lang. Ganz sicher gibts hier noch einiges an Optimierungsmöglichkeiten.

Oder er hat de endgültigen Netzwerkausfall und kann nicht mehr posten;-)