cj_berlin

Problem ist bei MSFT bekannt, wird irgendwann demnächst wieder geheilt.

Moin,
 
IIS Logs geben Dir die Info (Client-IP >> Rechner, Username >> Konto). Zumindest für Autodiscover, EWS, MAPI/HTTP...

Die, die noch online sind --> migrieren.
Die, die verwaist sind --> im AD löschen und in Exchange 2016 neu erstellen.

Moin,
das "nicht vertragen" hat meistens damit zu tun, dass UPNs in der Authentifzierung (Kerberos und sogar NTLM - ja, auch dieses respektiert in manchen Szenarien UPNs) auf den alten Namen zeigen und somit keine Authentifizierung möglich ist, wenn man den Host über den neuen Namen anspricht. Da zu vermuten steht, dass bei VoIP kein Kerberos zum Tragen kommt, sollte das eigentlich funktionieren.
 
Manche Dienste prüfen aber auch explizit, ob der aufgerufene Namen dem enstspricht, den sie selber kennen (SMB Strict Name Checking wäre ein Beispiel). Da musst Du bei Swyx schauen, ob so etwas zu konfigurieren ist.
 
Und last but not least: Wenn TLS zum Tragen kommt, muss der Name im Zertifikat stehen, der durch die Clients aufgerufen wird.

Moin,
 
an NPS-Test, QM und Systemtechnik verknüpfen. Wenn aber in der OU "Computer" auch Computerobjekte von Maschinen drin sind, auf die die GPO wirken soll, müsstest Du
entweder die OU "Entwicklung" aus "Computer" rausnehmen oder irgendwelche Sicherheitsgruppen zaubern (Schatten-Gruppen) und die GPO darauf filtern oder für Entwicklung eine Gegen-GPO bauen.

Moin,
Nein. Du hast ja auch nur eine ausgehende IP (nehme ich an), Ja, wenn Du irgendein anderes Client-Szenario hast als Outlook auf einem Domain-Member, muss mail.domain1. autodiscover.domain1.de und autodiscover.domai2.de ins Zertifikat. Reverse DNS wird meist nur auf das Vorhandensein geprüft, höchstens darauf, ob der MX oder der sendende Server dem aus der IP-Adresse aufgelösten Namen entspricht. Und da weder der MX noch der sendende Server aus der SMTP-Domain stammen muss, reicht ein PTR-Eintrag. Gar nichts. Die hören alle auf mail.domain1.de. ...was allerdings außer Outlook nicht viele Clients unterstützen.

Jetzt nochmal in ganzen Sätzen:
Du brauchst keinen Eintrag für die Sammlung, sondern nur einen für die Bereitstellung - das ist im Zweifel der FDQN des Connection Brokers, oder man weist einen anderen DNS-Namen zu, z.B. weil man ein öffentliches Zertifikat verwenden möchte, in dem ein bestimmter Name steht. Bevor Du weiter herumprobierst: Installiere einfach WebAccess als Teil der Bereitstellung, lade eine von diesem generierte .RDP-Datei für Deine Sammlung herunter und schau sie Dir im Texteditor Deiner Wahl an, dürfte einiges klarer werden. Du kannst mit dem Client nicht eine bestimmte Sammlung direkt adressieren, das geht nur mit einer .RDP-Datei.

Moin,
vermutlich meint der Sicherungshersteller, dass Du einen lokalen Pfad angeben sollst. Sprich, sie triggern einfach BACKUP DATABASE X TO DISK=N'<Pfad>'. Das geschieht dann mit dem Account, der den Datenbankdienst ausführt. 

Moin,
 
ja, das ist bekannt. Ich würde es ungern als "Fehler" sehen, da FSRM normalerweise auf einem DC nichts zu suchen hat (DHCP auch nicht, aber das ist ein anderes Kapitel).
Da niemand, den ich kenne, das in Produktion macht, habe ich nicht geprüft, ob das auf Server 2022 anders funktioniert als auf 2019, aber vermutlich nicht.
 
Du könntest Dich *vielleicht* - da ist die Erfahrung der Community uneinheitlich - durchmogeln, indem Du die Shares mit Screening Rules auf ein anderes Volume legst als SYSVOL. Aber keine Garantie hier.

Und wie ist es mit 
Get-CimInstance win32_group | where {$_.sid -match "\-513$" } ?
 
Ich würde anhand Deines Posts ja vermuten, dass die Domäne mehr als 5130 Objekte in ihrem langen Leben gehabt hat  
...aber bei mir funktioniert auch der erste Aufruf wie er soll  

Ich sags mal so... Die Mehrzahl meiner Kunden hat Virtualisierungsumgebungen am Start, die aus einigen bis vielen Clustern mit stark unterschiedlichen Prozessoren usw. bestehen, zum Teil aus Hosts von unterschiedlichen Herstellern. Ein Umzug von VMs auf ein anderes Cluster passiert da täglich. Bisher habe ich von keinem gehört, dass jemand den KMS oder einen per MAK aktivierten Server nach einem Umzug neu aktivieren musste...

Moin,
Du musst im XML-Profil alle Subnetze erfassen, zu denen per Tunnel kommuniziert werden soll. Wenn der Client die Pakete schon am falschen Interface rausschickt, kann man das von der Infrastrukturseite nicht mehr heilen.
Was Du vermutlich auch noch brauchst, ist eine Rückroute auf den Infrastruktur-Servern, damit die Pakete auch den Weg von den Servern zum VPN-Client finden.

Naja, erstes Learning: Outlook auf Exchange installieren ist doof.
Bis inklusive Exchange 2003 war es explizit unsupported, weil die MAPI Client-Komponenten sich gebissen haben.
Exchange 2007-2013 war es zwar supported, aber funktioniert hat es nur, wenn man a. MAPI über IP benutzt hat und b. das Profil manuell eingedübelt hat.
Sobald MAPI/HTTPS und Autodiscover im Spiel sind, greifen Konfigurationen im IIS, die dem Zugriff auf Webservices zwischen Exchange Servern (und damit auch auf sich selbst) eine besondere Bedeutung beimessen und dort abweichende Authentifizierungs-Einstellungen vornehmen.
Ich würde nicht soweit gehen, auszuschließen, dass man Exchange nicht dazu vergewaltigen kann.

... | Set-VM -AutomaticStartAction Nothing -PassThru | Set-VM -AutomaticStartAction Start -AutomaticStartDelay nnn  

Moin,
die Jobs schlagen wirklich fehl, d.h. sie werden nicht fortgesetzt, nachdem das Limit gerissen wurde. Soweit ich mich erinnere, werden die bereits importierten Elemente aber nicht wieder gelöscht. Die Praxis zeigt jedoch, dass die BadItems meist uralte Kalendereinträge sind, so dass sie in der Verarbeitung ziemlich am Anfang stehen und kaum etwas importiert wird.

Moin,
ein reines IPv6-Setup ist von Exchange nicht supported.
Ansonsten: DNS einfach leer lassen?

Naja, zwei Spalten hast Du schon, die hat eine Hashtable immer
Der Konstruktor einer Hashtable ist keine Zuweisung, daher kann man hier kein Array von Values zu einem Array von Keys gleicher Länge zuweisen.
Siehe auch hier: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_hash_tables?view=powershell-7.2

Moin,
 
was @NilsK gesagt hat, plus noch: Das ganze hört sich zwar nicht nach einer Umgebung mit mehreren Scopes an, aber falls der DHCP Server doch nicht im selben VLANs wie die Clients steht, müssen natürlich noch IP Helper und/oder DHCP Relays angepasst werden.

Moin,
 
ist der Remote Registry Service aktiviert und wird er tatsächlich ausgeführt? Ich habe in letzter Zeit Situationen gesehen, wo er zwar per GPP auf Automatic gestellt wurde, aber nach einem Reboot tatsächlich nicht lief. Per GPO hat es besser funktioniert, aber auch nicht 100%...
 
Die zweite Ursache wäre die Firewall auf der Zielmaschine (und vielleicht auch auf der Quellmaschine, obwohl das Blocken ausgehender Verbindungen leider seltener ist).

Moin,
 
alles hier beschrieben: https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ldap-channel-binding-and-ldap-signing-requirements-march-2020/ba-p/921536
 
TLDR;
Auditing einschalten (hast Du ja schon gemacht)
Event 2889 im Directory Service Log: Verbindungen ohne Signierung ODER ohne TLS
Event 3039 im Directory Service Log: Verbindungen mit TLS, aber ohne Channel Binding
 
Wenn keines dieser Events kommt, wird TLS ausgehandelt und offenbar auch CB verwendet.
 
Wenn Du es ganz genau wissen willst, kannst Du den Diagnostic Level höher drehen und Dich auf einen Haufen Events vorbereiten  NB: Die Einstellung "Require Signing" erzwingt die Signierung nur dann, wenn TLS nicht verwendet wird!
 
@NorbertFe Warum sollte ich keinen Simple Bind auf 389 hinbekommen? Wenn die Signierung klappt, muss es doch gehen, und dafür braucht es keine Domänen-Mitgliedschaft... oder übersehe ich ob der frühen Stunde etwas?

OK, das wird jetzt langsam wirklich spannend. @Marco31 welches Verhalten hast Du dir den erhofft? Es gäbe ja in meinen Augen fünf Varianten:
Wenn SRP aktiv ist, wirkt AppLocker nicht --> hast nichts gewonnen, oder? Wenn AppLocker aktiv ist, wirkt SRP nicht --> das ist das, was MSFT sich gedacht hat, passt Dir offenbar nicht Wenn beide aktiv sind, greift SRP zuerst --> AppLocker im Audit Mode würde nichts loggen, was verboten werden sollte, denn das würde ja schon von SRP weggeblockt werden Wenn beide aktiv sind, greift AppLocker zuerst --> vermutlich Dein Favorit Wenn beide aktiv sind, greift einer der Mechanismen, der andere kriegt den Ausführungsversuch aber auch dann mit, wenn er vom ersten geblockt wurde. Ansonsten: Um Überraschungen zu vermeiden, RTFM: hier steht schwarz auf weiß:
 
"Verwenden von AppLocker- und Softwareeinschränkungsrichtlinien in derselben Domäne
AppLocker wird auf Systemen unterstützt, die Windows 7 und höher ausgeführt werden. Richtlinien für Softwareeinschränkung (Software Restriction Policies, SRP) werden auf Systemen unterstützt, die Windows Vista oder früher ausgeführt werden. Sie können weiterhin SRP für die Anwendungssteuerung auf Ihren Computern vor Windows 7 verwenden, aber AppLocker für Computer verwenden, auf denen Windows Server 2008 R2 Windows 7 und höher ausgeführt wird. Es wird empfohlen, AppLocker- und SRP-Regeln in separaten GPOs zu erstellen und das Gruppenrichtlinienobjekt mit SRP-Richtlinien auf Systeme zu adressieren, die Windows Vista oder früher ausgeführt werden. Wenn sowohl SRP- als auch AppLocker-Richtlinien auf Computer angewendet werden, auf denen Windows Server 2008 R2 Windows 7 und höher ausgeführt wird, werden die SRP-Richtlinien ignoriert."
 
 

[int[]]((Get-Date -Format ddMMyyyy) -split "") | Measure-Object -Sum | Select-Object -ExpandProperty Sum  

Naja, das Problem zu *umgehen* ist recht trivial - die Bestehenden auslesen, die Gewünschten hinzufügen und das Ergebnis zurückschreiben:
 
$bypassModFrom = @((Get-DistributionGroup SG01).BypassModerationFromSendersOrMembers.DistinguishedName) $bypassModFrom += (Get-Recipient SG01).DistinguishedName Get-DistributionGroup SG01 | Set-DistributionGroup -BypassModerationFromSendersOrMembers ($bypassModFrom | Select-Object -Unique)  
Ansonsten: Ticket bei M$ aufmachen, und wenn ein Bug festgestellt wird, gibt es Geld zurück  

Klar.
certreq -config "CASERVER01\MyIssuingCA"  

Moin,
 
mit "Host" meinst Du vermutlich gerade nicht "Host" (das wäre ein ESXi, kein Windows Server), sondern "VM", richtig?
 
Es spricht nichts gegen diese Vorgehensweise, wenn Du ein großes Volume brauchst.