cj_berlin

Moin,

$existingEntry[0].EMailversand enthält kein Datum. Daher wird vermutlich $LastReminderDays nicht richtig berechnet. Ansonsten aktualisierst Du ja nicht den Eintrag in den importierten Daten, sondern fügst immer einen neuen an.

Hier musst Du noch an der Logik arbeiten, ich habe sie in Worten ja beschrieben.

Ich weiß nicht. Die Fälle scheinen mir nicht artverwandt:

• Exchange vor 10 Jahren: Natürlich kann es sich bei einem Support-Call herausstellen, dass es sich um einen Bug in der Software handelt, Wenn Du jemals ein Programm oder Skript geschrieben hast, was länger als eine Zeile war, war da bestimmt auch ein Bug drin - der hat sich in Deinen Einsatzszenarien nur nicht gezeigt. Und genau so hat sich "Dein Exchange-Bug" in den Testszenarien von Microsoft nicht gezeigt. Das ist normal, und Du kriegst bei Microsoft ja auch die Kosten des Support-Calls erstattet, wenn es ein Bug ist.
• Windows vor wenigen Wochen: Du hast eine Client- oder sogar eine User Profil-Herausforderung, und jemand, der von Microsoft bezahlt wird, sagt Dir, Du sollst Dein Active Directory neu aufsetzen? Halte ich für sehr unwahrscheinlich. Entweder der Supporter hat Deine Frage nicht verstanden oder Du seine Antwort, und beides muss nicht bedeuten, dass mit Dir irgendwas nicht stimmt. Aber mit Sicherheit ist hier falsch kommuniziert worden.

Du kannst mir gern per PN die Ticket-Nummer und die Mail schicken, in der Du aufgefordert wirst, Dein AD neu aufzusetzen. Vielleicht lässt sich das aufklären.

In PowerShell brauchst Du kein Ping, da nimmst Du einfach

Test-Connection -ComputerName 192.168.178.1 -Count 1 -Quiet 

und musst Dich um diese Feinheiten nicht kümmern.

...aber ansonsten steht der letzte ERRORLEVEL in PowerShell in der Variablen $LASTEXITCODE  

Moin,

zwei Dinge:

1. Es sollte heißen IF NOT %ERRORLEVEL% == 1 GOTO ZUHAUSE
2. seit irgendeiner Windows-Version (7?) ist bei ping "Zielhost nicht erreichbar" eine legitime Antwort und resultiert im Errorlevel 0. Das passiert z.B. wenn das Ziel im gleichen Subnetz liegt, aber halt nicht erreichbar ist. Da musst Du schauen, ob es Dir präzise genug ist  

vor 8 Stunden schrieb da_flo:

Hi,

wieso die Software nicht als AppV- bzw. msix-Paket ausrollen? Da kannst Du dann gezielt die Gruppe zum Paket hinterlegen. Dann ist es sogar egal auf welchem Server der User rauskommt und die Software wird dann automatisch verteilt.

 

Guter Einwand. App-V würde ich jetzt vermutlich nicht mehr anfangen zu lernen, wenn ich es nicht schon könnte, dann schon eher MSIX.

Re Terminalserver schnell bereitstellen: 

Hier gibt es bei virtualisierten Session Hosts im Prinzip zwei Ansätze:

1. Neu installieren. Da muss keine teure Software her, MDT+ WDS reicht. Wenn Du eine Server-Vorlage bereits hast, kann man das, was on top kommt, auch mit Chocolatey abbilden. Aber wenn ihr schon Software-Verteilung betreibt und diese für Server lizenziert wäre, sollte man natürlich auf das Vorhandene setzen.
2. TS-Vorlage pflegen und aus dieser bei Bedarf klonen. Und die Vorlage wird *nicht* manuell gepflegt, sondern ebenfalls mit den Mitteln der Software-VErteilung, siehe oben.

Bei jeder Variante muss der Server vor dem Neuerstellen aus der Farm raus und danach wieder rein. Auch das lässt sich ohne Probleme automatisieren.

Die Lösungen von VMware und Citrix sind teuer und vor allem hat man wieder eine Technologie mehr am Start. Beide haben diverse Mechanismen, um die Bereitstellung von VMs zu steuern. Da muss man noch weitere Mehrwerte suchen, zumal beide Hersteller (Citrix bereits jetzt, VMware ab März) ausschließlich per Subscription lizenzieren.

Moin,

solche "Kleinigkeiten" sind es, womit Citrix nach wie vor ein Schweinegeld verdient. Mit nativem RDS lautet Deine Antwort, wenig überraschend, TS03. Neue Session Collection, neuer TS, entsprechende Berechtigungen und fertig. Wenn es nur ein paar User sind, muss der Server ja auch nicht so groß dimensioniert sein.

Alles andere ist eine Bastelei, die unmöglich ist, im Betrieb zu pflegen.

Und wenn Du noch kein Verfahren hast, um einen "Standard-Terminalserver" innerhalb weniger Minuten bereitzustellen, dann wird's Zeit, das zu entwickeln. Diese Zeit ist nämlich besser investiert, als der Versuch, die produktive Farm für einen Test zu vergewaltigen.

vor 3 Minuten schrieb Mildred:

Aber jetzt fehlt mir folgendes. Wenn ich danach wieder die CSV einlese und mit deinen Tipps weiterbearbeite , habe ich nun folgenden Gedanken. Wenn ich das Skript ein 2. Mal durchlaufen lasse, überschreibt es mir doch das "alte" Datum oder?

Du musst die CSV vorher importieren und beim Durchlauf der Schleife abgleichen:

• Ist der User nicht drin, hinzufügen,
• ist der User drin und die letzte Erinnerung ist noch frisch, nix machen,
• ist der User drin und die letzte Erinnerung zu alt, aktualisieren und Mail schicken

Moin,

Archiv, im Sinne des Exchange In-Situ-Archivs, ist *nicht* Bestandteil der OST. Das ist dort, wo viele Mobile Worker unterwegs sind, der Hauptgrund gegen diese Funktion.

RegKey per @NorbertFe: https://support.microsoft.com/de-de/help/832925/how-to-configure-the-size-limit-for-both-pst-and-ost-files-in-outlook

Zeig mal wieder das komplette Skript mit allen Änderungen.

vor einer Stunde schrieb Mildred:

Vielen Dank für den Ansatz nur bekomme ich in der CSV diese Einträge:

Count          : 208
Length         : 208
LongLength     : 208
Rank           : 1
SyncRoot       : System.Object[]
IsReadOnly     : False
IsFixedSize    : True
IsSynchronized : False

Mit folgender Skriptzeile habe die CSV exportiert:

 

export-csv -Path $StatusFile -InputObject $UsersWithOldPasswordFromAD

 

 

Was bekommst Du denn ausgegeben, wenn Du $UsersWithOldPasswordFromAD einfach an die Konsole ausgibst?

EDIT: Ach, ich sehe: ArrayList... Mach mal für einen schnellen Test einfach ein Array daraus:

 $UsersWithOldPasswordFromAD = @()

...aber Software-Verteilung ist generell was, was man in einer wohlgemanagten Umgebung haben sollte  Muss ja nicht gleich SCCM sein.

Zum Prüfen, ob ein Element in einer Sammlung enthalten ist, gibt es die Operatoren -in /-notin bzw. -contains/-notcontains .

Wenn es Dir nur darum geht, ein Array mit Elementen zu ergänzen, die noch nicht drin sind, hier sind einige Techniken zusammengefasst: https://it-pro-berlin.de/2017/08/powershell-wie-schnell-sind-arrays/

EDIT: OK, habe jetzt gesehen, dass Du das Datum mitführen willst. Das kannst Du mit einem Custom Object machen, der die Properties sAMAccountName und LastDate hat.  Also praktisch statt 

 if  ($PasswordAge -ge $WarningLevel) 
    {
    $UsersWithOldPasswordFromAD += $ADUser.SamAccountName 
    }

so etwas wie

if  ($PasswordAge -ge $WarningLevel) {
    $UsersWithOldPasswordFromAD += [PSCustomObject]@{
      	'sAMAccountName' = $ADUser.SamAccountName
        'LastDate' = Get-Date
      }
}

Dann packst Du das alles in eine CSV mit Export-CSV. Beim nächsten Durchlauf importierst Du die CSV mit Import-CSV und machst in der Schleife dann so etwas wie

$existingEntry = $UsersFromCSV.Where({$_.sAMAccoutnName -eq  $ADUser.SamAccountName})
if ($existingEntry.Count -gt 0) {
	$LastReminderDays = ((Get-Date) - $existingEntry[0].LastDate).Days
    # je nachdem,  wie lange her, nochmal erinnern und Datum aktualisieren
} else {
	# anfügen
}

Moin,

die Domain-Funktionsebene konntest Du aber hochstufen?

Was passiert, wenn Du die Aktion nicht vom ADAC, sondern von Users & Computers (Domäne) bzw. Domains & Trusts (Forest) vornimmst?

Wie viele DCs sind insgesamt am Start? Leben alle noch? Funktioniert die Replikation?

Hoffentlich führt dieser Thread nicht dazu, dass Leute anfangen, ihre CAs auf Verdacht hin auf DCs zu installieren...  

Wobei natürlich, eine Issuing CA, die nur Smartcard-Zertifikate ausstellt, auf dem DC, und das Thema Revocation Lag bei SmartCards ist vom Tisch... Hmmm... 

Set-OWAVirtualDirectory -LogonFormat PrincipalName

vor 28 Minuten schrieb NilsK:

Daran ändert auch ein Online Responder nichts, weil auch der nur die CRL nutzt. 

 

Schon, aber man kann ihn anweisen, die CRL häufiger zu ziehen als sie abläuft:

Neu ausstellen muss man sie nach Sperrung eines Zertifikats natürlich manuell

Moin,

das sind *zwei* Anwendungsfälle:

1. wenn der User das Unternehmen verlässt, sperre sein Account im AD. Das wirkt sich auch auf die Smartcard-Authentifizierung aus.
2. wenn er seinen Key verliert und Du wirklich nur das Zertifikat zurückziehen möchtest, muss der Domain Controller davon erfahren. Es geht also nicht um den CRL Cache auf den Clients, sondern auf den Domain Controllern.

Moin,

zwei Punkte:

1. CALs werden entweder pro Gerät (Physik) oder pro Benutzer (Physik) benötigt, und nicht pro AD-Account oder irgendetwas anderes. Ob sich Herr Müller überhaupt gegen das AD authentifiziert, ist unerheblich - er greift auf Dienste eines Windows Server Version XY zu, und braucht daher CALs in mindestens dieser Version. Positiv dabei ist: Herr Müller braucht sie nicht pro Server, sondern kann mit einer 2019er CAL auf alle Server 2019, 2016, 2012, 2008 usw. derselben Organisation zugreifen. Und auch "Organisation" ist in diesem Fall kaufmännisch zu verstehen und nicht mit einem AD-Forest o.ä. zu verwechseln
2. Es gibt im Lizenzvertrag keinen "Mittelbaren Zugriff" auf Microsoft-Produkte. Wenn Herr Müllers MacBook auf eine Web-Applikation auf einem Linux-Server zugreift, der auf VMware ESXi virtualisiert ist, seine IP-Adresse aber von einem Windows DHCP-Server bekommt, braucht entweder Herr Müller oder sein Gerät eine CAL. So etwas wie ein Drucker braucht hingegen keine CAL, wenn er seine IP-Adresse von Windows-DHCP kriegt, sofern alle, die darauf drucken, eine User CAL haben.

vor 4 Minuten schrieb Nobbyaushb:

Für mindestens 90 bzw. 180 Tage ohne Key

 

Ich bin für 120  Aber auch danach passiert nix, außer, dass er warnt...

Bei mir hat das im GPO-Editor nicht funktioniert. Bei NTFS- oder Freigaberechten dagegen schon.

OK, also reden wir von dem gleichen, nur ich rechne in VMs und @lizenzdoc in Standard-Lizenzen  Und ja, je nachdem wie man Break Even definiert, ist 12 oder 13 VMs Break Even.

vor 1 Stunde schrieb lizenzdoc:

preislich wird es ab der 7. W-STD Lizenz günstiger DC zu kaufen!

 

Huch? https://www.microsoft.com/de-de/windows-server/pricing sagt: Standard = $972, also $486 pro VM, und DC = $6.155, somit 12,66x der Betrag. 

Wo ist der Fehler? Du bist der Profi

vor einer Stunde schrieb MS_Noob:

 

 

Also wenn man zum Beispiel 2 ESXI (2 Sockel je 14 Cores) mit je 4 VMs

Die VMs sind für den Teil, wo mit Cores gerechnet wird, völlig uninteressant, denn die Windows Server-Lizenzierung gilt für das Blech.

Die Anzahl VMs kommt dann ins Spiel, wenn Du entscheiden musst, ob Du Windows Server Datacenter brauchst oder mit Standard oder 2x Standard auskommst. *Dann* nimmst Du nämlich die maximale Anzahl Windows Sever-VMs, die zu irgendeinem Zeitpunkt theoretisch auf einem Host gleichzeitig laufen könnten. Liegt die Zahl über 12, ist Datacenter billiger. Liegt sie darunter, musst Du so oft Standard lizensieren, bis die doppelte Anzahl der Standard-Lizenzen über der Maximalzahl VMs liegt.

Gegenfrage: Was verwendest Du denn sonst?

vor 10 Minuten schrieb testperson:

Es werden immer (atmende) Menschen lizenziert und keine Accounts ("User").

 

...aber leider werden User *reportet* und nicht Menschen. Darüber muss man dann halt mit dem Auditor sprechen.

Mit 2019 werden User CALs übrigens auch getrackt, daher wird das Halbieren evtl. nicht zum Ziel führen.