cj_berlin

Moin,
 
wenn es Dir um die Leistung von Echtzeit-Anwendungen geht, brauchst Du QoS, VLANs helfen da kaum. Allerdings ist es bei Softphones immer schwer zu sagen, ob Aussetzer auf Netzwerk oder doch auf die CPU/Interrupts/andere lokale Ressourcen zurückzuführen sind. Da hilft eigentlich nur ein Hardphone derselben Marke und schauen, wie sich das verhält.
In puncto Performance helfen VLANs eigentlich nur dann, wenn Du Anwendungen hast, die mit Broadcasts arbeiten, und diese das Netz mit den Broadcasts fluten. Doch auch da kann es passieren, dass diese Anwendung überall benötigt wird

Moin,
 
https://learn.microsoft.com/de-de/sql/database-engine/install-windows/rename-a-computer-that-hosts-a-stand-alone-instance-of-sql-server?view=sql-server-ver16

Select-Object -ExpandProperty primaryGroupToken
oder (Get-ADGroup $targetGroup -Properties PrimaryGroupToken ).PrimaryGroupToken
 

Dein Problem ist. vermute ich jetzt mal, dass die bordeigenen Tools aus Vor- und Nachnamen einen "Full Name" zusammenfügen, diesen dann aber stillschweigend in *zwei* Attribute schreiben: name (CN) und displayName. DisplayName wäre ja völlig OK, das kann mehrfach vergeben sein, auch innerhalb einer OU, aber der CN halt nicht.
 
Lösungsansätze: 
 
wenn die Fehlermeldung kommt, ergänze den Full Name um irgendwelche Zeichen, lege damit den Benutzer an und benenne anschließend den Display Name richtig um. lege alle neuen User in einer separaten OU an und verschiebe sie anschließend. Wird das Verschieben verweigert, bennene den CN durch Ergänzung um irgendwelche Zeichen. lege für Namensvetter eine Unter-OU Deiner User-OU an Benutze NICHT die GUI-Tools, sondern PowerShell für die Benutzeranlage, dann kannst Du gleich zuerst abfragen, ob es den User schon gibt und dann entsprechend CN und DisplayName explizit mit unterschiedlichen Werten füllen, und auch den sAMAccountName und den UPN nach einer Vorschrift gestalten.  
 
In einer prominenten öffentlichen Behörde hat man vor ca. 11 Jahren einen neuen Pressesprecher eingestellt, der aber so einen Allerweltsnamen hatte. Und man hat seine *angenommene* e-Mail-Adresse bereits im Anzeigeblatt veröffentlicht, *bevor* er durch den Onboarding-Workflow gelaufen ist und festgestellt wurde, dass es einen Beamten mit diesem Namen und dieser Mail-Adresse dort bereits seit Jahren gibt. Den Rest der Geschichte gibt es allerdings nur mündlich  

Moin,
 
als erstes begreifst Du diese Situation bitte als Chance, endlich vom "God Mode" wegzukommen und alle Rechte nur an Domain Admins zu vergeben. Leg eine Gruppe "Profile Admins" an, berechtige die und packe die Admin-Accounts da rein, die das auch machen sollen. Selbst wenn im ersten Schritt dieselben Accounts da drin sind wie in den Domain Admins. Dies nur nebenbei, hilft Dir bei der Berechtigungsvergabe erst mal nicht weiter.
 
Vermutlich stört UAC die Berechtigungsvergabe. Versuche es über die Dollar-Freigabe das Laufwerks, auf dem die Freigabe liegt. Oder mit dem lokalen "Administrator"-Account des File-Servers. Oder Du schaltest kurz UAC ab.

Moin,
auch wenn diese POP3-Puller schon immer verpönt waren und das Konzept in mehr als einer Hinsicht Sch**ße ist, ist anhand der geschilderten Anamnese nicht eindeutig, dass es nur daran liegt.
Hol doch mal eine signierte, aber nicht verschlüsselte Mail direkt mit einem POP3-Client vom Hoster ab und schau, wie der Header bzw. die Struktur aussieht. Vielleicht ist es bereits der Hoster, der das zerhaut. In diesem Fall hast Du wirklich keine Wahl, die Mails statt zum Hoster entweder direkt an den Exchange oder, besser, an einen Gateway davor zustellen zu lassen. "Gateway davor" kann ein Online-Dienst sein, muss nicht zwingend on-premises sein.

Moin,
 
das einzige, was an EWS als Zugriffsprotokoll auszusetzen wäre, ist, dass damit der vollständige Befehlssatz möglich ist, sprich, dass damit auch Mails, Permissions vorausgesetzt, versendet werden können. Daher, wo möglich, NICHT mit Impersonation arbeiten, sondern mit expliziten Berechtigungen, und dort nur das Leserecht erteilen. Muss die Anwendung natürlich in ihrem Code umsetzen.
 
Ansonsten, wenn es nur um Lesezugriff geht, POP3 und IMAP4 sind immer noch möglich - auch da muss die Anwendung dies im Code umsetzen.
 
Schwieriger wird es, wenn die zugreifende Anwendung die Elemente, auf die zugegriffen wird, anpassen muss - zum Beispiel, den Link zum Speicherort im DMS in eine MAPI-Property des archivierten Eintrags injizieren. Das geht wieder nur über EWS oder MAPI, und MAPI willst Du wirklich nicht.

Moin,
ad 1. das kannst Du alles in den Conditional Access Policies einstellen. Normalerweise muss man sich nicht ständig neu authentifizieren, wenn man nicht ständig die IP wechselt.
 
ad 2. Hier musst Du bitte beschreiben, was Du erreichen willst.
 

Moin,
 
wenn die Clients in der Domäne sind, die User mit ihren AD-Accounts angemeldet sind und das VPN ihnen die "Line of Sight" zum Domain Controller bietet, so könnten sie ihr Passwort ja am Client ändern, nachdem sie die VPN-Verbindung aufgebaut haben. Tatsächlich müssten sie das sogar das erste Mal, wenn sie den Rechner nach der Mittagspause entsperren  Aber da sind sie ja schon nach dem Frühstück bei RDP gegen die Wand gelaufen und der Haken ist wieder raus.
 
Nimm den Haken raus und schreib ein Skript, das jedem, der sich angemeldet, sein Passwort jedoch nicht geändert hat, zweimal am Tag eine Mail mit Anleitung schickt.

Moin,
 
solange kein wirkliches Relay entstanden ist, kann es Dir nicht eigentlich egal sein, welchen Receive Connector Exchange für den Empfang eingehender Mails aus dem Gateway auswählt?
 
Ist es Dir aus irgendwechen Gründen wichtig, musst Du den Mail-Gateway aus dem Scope des internen Connectors ausschließen. Ich vermute aber aus Deiner Ausführung, dass das interne Bein des Mail-Gateway im Server-Subnetz ist und Du daher den Scope aufbrechen müsstest, um eine Adresse auszuschließen. Normalerweise jedoch, wenn der Scope des externen Connectors nur die IP des Gateways umfasst und nicht das gesamte Subnetz, müsste dieser gewählt werden - Exchange versucht immer, die möglichst genau passende Konstellation zu wählen.
 
Wenn allle Stricke reißen, kannst Du den externen Connector auf einem anderen Port laufen lassen und das Ziel im Mail-Gateway ändern.

Moin,
 
was ist denn mit der Public Folder *Mailbox*, wo der Ordner lebt? Vielleicht ist diese voll bzw. gegen Quota gelaufen? 

Moin,
 
das Account, das Du verwendest, ist nicht zufällig in der Protected Users-Gruppe oder so?
 
Ganz b***d gefragt: Wenn die Hosts schon im selben oder zumindest in vertrauten Kerberos-realms sind, warum nicht Kerberos nutzen?

Hat sich der UPN denn auch geändert? Eigentlich ziehen Office-Programme diese Daten aus 
 
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity\ADUserName

Hier ist die Antwort auf Deine Frage und gleichzeitig ein dezenter Hinweis, dass es nicht "Onpremise" heißt  
Es kommt hier, wie so oft, darauf an. Erteilt der empfangende Server den Fehlercode bereits vor dem DATA Befehl (kein Bock, SPF verletzt, IP auf RBL, Zertifikat passt nicht usw.), so wird der NDR tatsächlich von dem sendenden Server generiert. Hat der empfangende Server den SMTP-Dialog positiv geschlossen (wie in diesem Fall - vorher wäre es ja schwierig, den Anhang zu analysieren), so ist er auch für die NDR zuständig.

Moin,
das Stichwort, welches Du suchst, lautet "Vererbung". Erstelle einen Einsprungsordner, berechtigen ihn richtig, dann werden auch die darunter erstellten Unterordner richtig berechtigt sein.
Das andere Stichwort lautet "UAC". Wenn Du den "Administrator" entfernst, weil er ja in "Administratoren" ist, wirst Du feststellen, dass der Zugriff über die Freigabe sehr wohl funktioniert, das Problem besteht nur bei lokalem Zugriff.

Nur mal nebenbei: wenn die Jugendlichen Smartphones mit genug Datenflatrate haben, um die Pornos mit dem Hotspot zu gucken, was hindert sie daran, das einfach auf dem Smartphone zu tun?
 
Da die Maschinen offenbar nicht Mitglied einer AD-Domäne sind, kannst Du keine Gruppenrichtlinien verwenden. Lokale Richtlinie könntest Du zwar verwenden, aber der Aufwand bei netsh ist im Zweifel geringer, da Du ja nur ein Netz erlauben willst.

Du hast die Frage doch selbst beantwortet Es braucht das Recht, diese Gruppe zu löschen. Ja, ein Domain Admin hätte dieses Recht auch, aber es könnte auch auf anderen Wegen - durchaus auch unabsichtlich - delegiert worden sein.
Weil die gelöschte Gruppe nicht nur an der Share-Ebene, sondern auch im NTFS berechtigt war - oder habe ich Deinen OP falsch gelesen?

Einfach booten, wie Citrix das seit 20 Jahren macht?

Wenn keine Exchange-Dienste mehr laufen, kann der Ordner weg, sind vermutlich nur Performance- und andere Logs. Aber willst Du nicht eh den ganzen Server abmanagen?

Moin,
 
ob's zu Problemen führt, kommt darauf an, ob - und wo - der Name benutzt wird  
 
Wenn Die Domain (und speziell der betroffene User) mit O365 synchronisiert ist, ist dann erst mal das OneDrive weg, kommt aber irgendwann wieder. Eventuell. Für reinen Windows-Betrieb ist es wurscht. Ob irgendeine Applikationen bei der ersten Anmeldung den UPN speichert und ihn dann erwartet, können wir nicht wissen.
Tatsächlich sogar an der GUID, wie ich unlängst lernen durfte  

Könnte es sein, dass die Verbindung über FQDN einfach per Kerberos abgesichert ist, und die Zertifikate keine Rolle spielen?

Execution Policy ist *kein* Sicherheitsfeature. Es ist nur ein Anti-Schludrigkeitsfeature.

Wenn man weiß, was man tut, bietet es aus Security -Sicht schon Vorteile. Aber einen Autodiscover-Eintrag braucht die Domain nicht - weder im DNS noch im Zertifikat. Einen SAN für die Domain selbst hingegen schon...

Moin,
 
Disable-Mailbox, gefolgt von Enable-Mailbox mit DB-Angabe?
 
Outlook kriegt es vermutlich auch so mit, da die Postfach-GUID sich ändert, aber klar, kannst auch den Holzhammer nehmen

Moin,
so wie Du es beschreibst, wird es wahrscheinlich nicht klappen.
Je nachdem, was mit "auf Prozess warten" technisch gemeint ist, kann man da vielleicht etwas drumherum stricken, aber RemoteApp in Reinform gibt so etwas nicht her.