Maniska

Für mich wäre das dann Zeit für malicious compliance:
Ticket 1:
Anmelden am Kundensystem, öffnen der benötigten Konsolen, Heraussuchen der nötigen Kennwörter aus der Kennwortverwaltung, Namensänderung am Benutzer durchführen, warten bis es durch die wichtigsten Systeme gesynct ist, schließen Kennwortverwaltung, abmelden von den Kundensystemen.
Ticket 2:
Anmelden am Kundensystem, öffnen der benötigten Konsolen, Heraussuchen der nötigen Kennwörter aus der Kennwortverwaltung,Anlegen des Benutzer, warten bis es durch die wichtigsten Systeme gesynct ist, schließen Kennwortverwaltung, abmelden von den Kundensystemen.
Dauert halt nur deutlich länger, aber wenn der Kunde will dass seine Tickets enzel bearbeitet werden...

Ich sehe lizenzrechtlich keinen Unterschied zwischen den beiden Schaubildern, ob ich via IP oder FQDN zugreife.. egal. Es geht um direkten oder indirekten Userzugriff über egal wie viele Ecken. Auch bei Bild 1 ist doch irgendwo ein User (Person) involviert der sich gegen die AD authentifiziert, oder verstehe ich hier was falsch?
Und ja, solange die DB auf einem Windowsserver liegt ist für jeden User eine CAL fällig + je nachdem wie der SQL lizenziert ist
Jup, die benötigst du aber schon wenn du den ersten Windowsserver in Betrieb nimmst, sollte daher also kaum überraschen.
Windows Server im Internet zu hosten auch, trotzdem spielen wir hier gerade dieses Gedankenspiel. Niemand der noch eine Nadel an der Tanne hat wird eine Webanwendung im Internet freiwillig auf einem Windowsserver hosten.
Nein, da sie das im Regelfall nicht aus Spaß an der Freude machen sondern Aufgrund von Userinteraktion. Oder es machen Service Accounts, die brauchen auch nix. Aber wie gesagt, sobald ein Windowsserver als DC, Print- oder Fileserver eingesetzt wird sollte eh jeder MA eine CAL haben. Und im Internet spielt man nicht mit Fenstern.
Habe ich jemals was anderes behauptet?
 
 
 
 

Du gehst auch nicht über die BrokerIP, sondern legst ein DNS RoundRobin für diene Sammlung an. Sammlung1 hat dann eben die IP-Adressen der Server1-3, Sammlung2 die von Server4-7.
 

Ja gut, aber wen du den mal weg knipst geht die Welt nicht unter
So in der Art ja.
Ich teil es mal in "linke" und "rechte" Seite ein.
"Links" ist deine virtuelle Umgebung, also die VLANs die du deinen VMs zuordnen kannst. Du musst ja den/die Netzwerkadapter der VMs einem VLAN zuordnen. Hier kannst du z.B auch sagen dass VLAN X exklusiv über vmnicY gehen darf (sofern dein Host mehr wie eine physikalische Netzwerkkarte hat)
Kenn ich aber in der Praxis eher nicht, im Regelfall lässt man alle VLANS über alle vmnics raus und den Router den Rest erledigen.
"Rechts" sind der oder die physischen Adapter die der Host zur Verfügung hat.
Genau.
Du brauchst also zuerst die VLANs auf dem vSwitch (sonst gibts nix zur VM zuzuordnen) und VLANs mit der selben VLAN-ID auf deinem physikalischen Switch sonst können virtuelles und physikalisches Netzwerk nicht miteinander reden.
Der Rest ist Netzwerkgefummel auf der Routinginstanz.
Nö, die Richtung passt soweit.

Also hast du ein Objekt Computerkonto in deinem AD angelegt? Schau mal bitte auf deinem DHCP was der Powershellbefehl " Get-ComputerInfo -Property CSDomain" ausspuckt. Ist das deine Domäne? Wenn nein, ist er noch nicht drin, weil woher weiß dein Server, dass er mit dem AD Konto gemeint ist? Entweder machst du es so, oder du gehst "klassisch" den Weg über den Servermanager --> Arbeitsgruppe --> Betritt zur Domäne (heißt ein bisschen anders, wirst du aber schon finden).
Genau so nimmst du auch deine Clients in die Domäne auf.
Anlegen in AD direkt kenn ich eigentlich nur dann, wenn man einen Helpdesk Mitarbeiter hat, der zwar Computer zur Domäne hinzufügen, diese aber nicht in OUs verschieben darf.
Ansonsten Rechtsklick auf "Computer" bzw "dieser PC", Einstellungen, Einstellungen für Computername... ändern" und dann später in die richtige OU verschieben.

Das müsste mit einer Mischung aus Powershell und geplanten Tasks (der Einfachheit halber auf dem DC)  umsetzbar sein. Also kostenlos und mit Lerneffekt für den Admin.

Heureka.
Import-Module ActiveDirectory # Filtern nach Accounts die aktiv sind und deren Kennwort ablaufen kann # Auslesen der benötigtn Attribute aus dem AD # ForEach Cmdlet, nicht die Schleife! Get-ADUser -filter {(Enabled -eq $True) -and (PasswordNeverExpires -eq $False)} -properties PasswordLastSet,EmailAddress,GivenName,Surname -SearchBase “OU=Test,DC=contoso,DC=local” -SearchScope Subtree | ForEach { # Ablaufdatum = Zeitpunkt des letzten Passwordänderung - Maximales Passwortalter $ExpiryDate=$_.PasswordLastSet + (Get-ADDefaultDomainPasswordPolicy).MaxPasswordAge # Aktuelles Datum abholen $today=get-date # Restliche Laufzeit = Ablaufdatum (als Datum) - Heutiges Datum (als Datum) $DaysLeft=$ExpiryDate - $today # Setzen der Variablen, die im Mailtext verwendet werden # Übrige Tage als Anzahl Tage (.days) $display=$daysleft.days $UserName=$_.GivenName $SurName=$_.Surname #Wenn Anzahl verbliebener Tage <14 if ($display -lt 14) { #Nachrichtentext als Here-String @"..."@ abspeichern $MyVariable = @" Sehr geehrte/r $UserName $SurName, Ihr Kennwort wird in $display Tagen ablaufen. Bitte denken Sie daran das Kennwort rechtzeitig zu ändern! Um das Kennwort zu ändern, drücken Sie bitte "STRG + ALT + ENTF" und wählen SIe die Option "Kennwort ändern" Mit freundlichen Grüßen, Eure IT "@ # Nachricht verschicken send-mailmessage -to $_.EmailAddress -from Kennwortwarnung@contoso.local -Subject "Achtung! Ihr Kennwort läuft in $display Tagen ab" -body $MyVariable -smtpserver mail.contoso.local -encoding ([System.Text.Encoding]::UTF8) } } $DaysLeft=$ExpiryDate.day - $Today.day liefert mir zwar Werte, aber Kauderwelsch zurück, da mit .day der Tag des Monats abgefragt wird.
So wie oben funktioniert es nun. Einziger Schönheitsfehler: Im Mailbody werden die Leerzeilen nicht mit übergeben der Text schaut also etwas gequetscht aus.