Scharping-FVB

Wenn der Netzwerker die Anforderung hat, sich lokal ohne Netzwerk anmelden zu wollen, dann ist das erst einmal so seine Arbeitsweise. Sicherlich würde er dort, wo er kann, sich ans Netzwerk anschließen. Wofür er die lokale Anmeldung ohne Domäne braucht, weiß ich nicht. Vielleicht wenn er in einem anderen VLAN ohne Routing zur Domäne unterwegs ist zur Router- oder Firewallkonfiguration. Und gerade eben, beim Patchday hat es mich erwischt: Server fährt nach dem Neustart hoch und hat das Netzwerk nicht erkannt. Keine Domäne, keine Anmeldung... VM also neu starten und Daumen drücken, dass das reicht - hat gereicht. Bei Blechservern große ka**e, da muss dann LAPS her. Mit nicht 2025 und dessen lesbaren Kennwörtern, eine Qual :-(

Wenn der Netzwerker die Anforderung hat, sich lokal ohne Netzwerk anmelden zu wollen, dann ist das erst einmal so seine Arbeitsweise. Sicherlich würde er dort, wo er kann, sich ans Netzwerk anschließen. Wofür er die lokale Anmeldung ohne Domäne braucht, weiß ich nicht. Vielleicht wenn er in einem anderen VLAN ohne Routing zur Domäne unterwegs ist zur Router- oder Firewallkonfiguration.

LAPS verwenden wir bereits. Ist halt sehr aufwändig, wenn unser Netzwerker im Serverraum mit seinem Laptop sich lokal als Admin anmelden will. Dann muss er erst das LAPS-Kennwort aufschreiben und dann fehlerbehaftet eintippen. Aber klar, wer das eine Will, muss das andere Mögen!

Wir haben einiges ausprobiert, aber diese lokale Anmeldung dabei übersehen. Bisher hatte Protected Users keine negativen Auswirkungen gehabt.

Ist das eine blöde Idee? Protected Users schützt doch die Credentials. Und vor dem Hintergrund des BSI Empfehlung, Kennwörter nicht mehr regelmäßig zu ändern, sollte vor Pash-the-Hash geschützt werden. Oder gibt es da andere, begründete Empfehlungen?

Dann ist das der Grund, danke für den Hinweis!

Liebes Forum, wenn ich ohne Domain, zu Hause, mich an meinem Win10 Notebook als ein lokaler Administrator (Domain User) anmelden möchte, scheitert dies, aufgrund der fehlenden Domäne. Mit meinem eigenen, normalen User klappt es. Der adloc-User war bereits in der Domäne angemeldet, die Credentials sollten also zwischen gespeichert sein, so wie die meines normalen Users. Oder werden die Creds eines lokalen Admins (Domain User) nicht zwischengespeichert? Wie kann ich erreichen, dass sich auch ein loakler Admin (Domain User) ohne Verbindung zur Domäne anmelden kann? Viele Grüße Davorin

Oha, das ist wohl das Problem, tut mir leid, ich war da zu schnell... Klappt natürlich, so wie du es sagst

Dann ist aber wieder das Kennwort notwendig, beim Start von Outlook poppt ein Anmeldefenster für das Gruppenpostfach auf...

Gelöscht, weil noch nicht alles ausprobiert

Oha, wieder etwas gelernt, das klappt ja tatsächlich nun muss ich nur noch jeden FullAccess "austauschen" gegen FullAccess -Automapping:$false Sollte ja irgendwie per PowerShell Skript machbar sein, alle Postfächer daraufhin zu prüfen und das dann zu entfernen und neu hinzuzufügen Danke an euch alle

Das ist b***d, denn dann brauche ich das komplexe Kennwort für die Gruppenpostfächer :-( Und das können wir dann nicht mehr einfach so ändern.

Du meinst so? b***d, dass ich für alle Postfächer mit "Vollzugriff" nun manuell per Powershell /automapping:false einstellen muss :-/ Oder mühselig einzelne Berechtigungen einrichten muss. Ich probiere das erstmal für besonders hartnäckige Problemfälle aus. Danke ok, werde ich ausprobieren, danke

Liebes Forum, wir haben vermehrt das Problem, dass Outlook 2016 (Offline Modus) das Postfach nicht aktualisiert. E-Mails können versendet werden, es werden jedoch keine neuen angezeigt. Insbesondere bei automatisch eingebundenen Vollzugriff-Postfächer tritt dies auf, aber gelegentlich auch bei Hauptpostfächern. Outlook zeigt "Verbunden mit..." und "Alle Ordner sind auf dem neuesten Stand" an. Ein neues Outlook Profil behebt da Problem erst einmal, meist tritt es nach einigen Tagen erneut auf. Im OWA ist erwartungsgemäß alles vorhanden und wird auch aktualisiert. Was kann ich hier machen, um das Problem mit der Aktualisierung einzugrenzen und zu beheben? Viele Grüße Davorin

Liebes Forum, ich habe versucht RCG für einen Server und einen Client einzurichten. Für den Client habe ich diese GPO eingestellt: System/Credentials Delegation Policy Setting Restrict delegation of credentials to remote servers: Enabled Use the following restricted mode: Require Remote Credential Guard Für den Server: System/Credentials Delegation Policy Setting Remote host allows delegation of non-exportable credentials: Enabled Der zu testende AD-User ist Mitglied einer AD-Gruppe, die wiederum Mitglied der lokalen Gruppe "Remote Desktop Users" ist. Wenn ich mich mit einem AD-User anmelde, dann erhalte ich: "the requested session access is denied". Ist der AD-User Mitglied der lokalen Gruppe der Administratoren, funktioniert die Anmeldung. Im ersteren Fall kommt im Event Log, "successfully", obwohl die Anmeldung abgewiesen wird: An account was successfully logged on. Subject: Security ID: SYSTEM Account Name: SERVER$ Account Domain: YYY Logon ID: 0x3E7 Logon Information: Logon Type: 10 Restricted Admin Mode: No Virtual Account: No Elevated Token: No Impersonation Level: Impersonation New Logon: Security ID: YYY\xxxx Account Name: xxxx Account Domain: YYY Im zweiten Fall, als lokaler Admin kommt dieses Ereignis: An account was successfully logged on. Subject: Security ID: SYSTEM Account Name: SERVER$ Account Domain: YYY Logon ID: 0x3E7 Logon Information: Logon Type: 10 Restricted Admin Mode: No Virtual Account: No Elevated Token: No Impersonation Level: Impersonation New Logon: Security ID: YYY\addom-XXXX Account Name: addom-XXXX Account Domain: YYY Logon ID: 0x140036 Linked Logon ID: 0x13FFEE Network Account Name: - Network Account Domain: - Logon GUID: {00000000-0000-0000-0000-000000000000} Process Information: Process ID: 0x8b8 Process Name: C:\Windows\System32\svchost.exe Network Information: Workstation Name: SERVER Source Network Address: 10.x.x.x Source Port: 0 Detailed Authentication Information: Logon Process: User32 Authentication Package: Negotiate Transited Services: - Package Name (NTLM only): - Was kann ich tun, um RCG für Domänen-Administratoren zu erzwingen? Viele Grüße Davorin

OK, das funktioniert generell. Doch ich habe dann ein anderes Problem mit Remote Credential Guard, für das ich einen neuen Thread eröffne.

Liebes Forum. wenn ich auf dem RDP-Server und dem Client RCG konfiguriert habe, wird dies nur dann genutzt, wenn ich mich mit dem lokal angemeldeten User am RDP-Server anmelde? Dann wird RCG ja gar nicht genutzt, wenn ich mich mit anderen Credentials, z.B. dem Domänen-Admin am RDP-Server anmelden will. Das würde bedeuten, dass ich mich erst lokal als Dom-Admin anmelden müsste, um auch RCG nutzen zu können. Stimmt das so? Wenn ja, wie kann ich dann die Credentials des Dom-Admins auf allen Ebene schützen? Anmeldung lokal mit Credential Guard und dann Remote mit Remote Credential Guard? Viele Grüße Davorin

Vielen Dank für eure Mühe. Bei mir will das einfach nicht. Ich habe dein XML direkt so übernommen, die gleiche Fehlermeldung erscheint und es passiert stundenlang nichts. Dann habe ich Windows von Null an neu installiert, in die Domäne gebracht, unsere Standard GPOs drauf wirken lassen und es noch ein Mal versucht. Auch hier der Fehler. Nun noch ein Versuch, mit blankem Windows ohne Domäne...

Der Troubleshooter ist es, der sagt, dass es nichts zu deinstallieren gäbe. Zudem lese ich auf der Webseite unter dem "Knopf", dass Office 2024 leider nicht deinstalliert werden könne. Was erklärt, warum nichts deinstalliert werden kann. Hier meine aktuelle 64-Bit XML, für die ich mich nicht angemeldet habe: <Configuration ID="48536b8c-a8a8-443c-b47b-cecf9b825c5c"> <Add OfficeClientEdition="64" Channel="PerpetualVL2024" MigrateArch="TRUE"> <Product ID="Standard2024Volume" PIDKEY="xxxxxxxxx"> <Language ID="de-de"/> <ExcludeApp ID="OneDrive"/> <ExcludeApp ID="Publisher"/> </Product> </Add> <Property Name="SharedComputerLicensing" Value="0"/> <Property Name="FORCEAPPSHUTDOWN" Value="FALSE"/> <Property Name="DeviceBasedLicensing" Value="0"/> <Property Name="SCLCacheOverride" Value="0"/> <Property Name="AUTOACTIVATE" Value="1"/> <Updates Enabled="FALSE"/> <RemoveMSI/> </Configuration>

Jetzt hat sich die 32 Bit Installation aufgehängt, bzw. ich habe sie nach 2 Stunden abgewürgt, weil nichts mehr passierte. Es ist nichts installiert, es werden keine Apps angezeigt, aber dennoch kann ich 64 Bit nicht installieren, weil gemeldet wird, dass bereits 32 Bit installiert sei und ich mit der 32 Bit Installation fortfahren könne. Doch die hängt sich wieder auf, nach zwei Stunden ist wieder nichts passiert. Immer wieder der Format Fehler, obwohl ich die XML des ODT nicht mehr verändert habe und so wenig wie möglich eingestellt habe. Ein Office Uninstall Tool finde ich nicht, entweder wird auf Hilfe und Supportcenter verwiesen, was nichts deinstalliert oder der Troubleshooter versucht mittels PowerShell eine Deinstallation, meldet aber, dass kein Office installiert sei. Ich vermisse die Zeiten, in denen ein einfacher Doppelklick auf setup.exe ausgereicht hat, um Office (zuverlässig) zu installieren. Ich habe inzwischen auch Log Files gefunden, die nach Abbrechen der Installation angelegt werden, mit dem Inhalt kann ich gar nichts anfangen, vielleicht findet sich hier ja ein Experte dafür? PC-9968-20250130-1152a.log.txt Das war wohl mal Power Query, vor einigen Jahren. Ist inzwischen auch 64 Bit fähig

Ich bin einen Schritt weiter, mit der 64 bit Variante von ProPlus hat er funktioniert (wollen wir aber nicht, weil wir Std Lizenzen kaufen werden und 32 bit wegen Add-Ons brauchen), Download mit anschließender Installation. Ich teste gerade 32 bit Standard, gleiches XML, nur kleine Anpassungen dazu: <Add OfficeClientEdition="32" Channel="PerpetualVL2024" AllowCdnFallback="TRUE"> <Product ID="StandardVolume"> Mal sehen, der Download läuft seit 15 Minuten...

Danke für den Link, so etwas hat mir noch gefehlt, zum Verständnis. Der Download ist sehr langwierig, hilft aber leider auch nicht, der Fehler, auch mit einer neu erstellten XLM, bleibt: (8format error: invalid format specification field) Meine XML Dateien haben keinen Eintrag <Info Description="Office 2024 32-Bit" /> Der bleibt bei OfficeClientEdition="32" Ich habe die "Info Description" ausprobiert, anstelle meines Eintrags und zusätzlich dazu, beide Mal gab es einen Fehler. Das passt also nicht in mein XML: <Configuration ID="423b8222-3a8f-4bb2-a3b6-a64e230c279b"> <Add OfficeClientEdition="32" Channel="PerpetualVL2024" SourcePath="\\xx\xxxxxx\\install\MS Office 2024 Std. LTSC" AllowCdnFallback="TRUE"> <Product ID="Standard2024Volume" PIDKEY="YYYYYYYYYYYYY"> <Language ID="de-de" /> <ExcludeApp ID="OneDrive" /> </Product> </Add> <Property Name="SharedComputerLicensing" Value="0" /> <Property Name="FORCEAPPSHUTDOWN" Value="FALSE" /> <Property Name="DeviceBasedLicensing" Value="0" /> <Property Name="SCLCacheOverride" Value="0" /> <Property Name="AUTOACTIVATE" Value="1" /> <Updates Enabled="FALSE" /> <RemoveMSI /> </Configuration> Ich habe da nichts verändert gegenüber dem XML, das ich online erstellt habe. Ich habe Office vorher mit /download heruntergeladen. Ich führe das ganze in einer Admin-Shell aus. Mit Office 2019 hat das noch funktioniert.

Ich habe die XML über das (online) ODT erstellt, wie ich in meinem ersten Satz schon schrieb. Neu erstellen hat nicht geholfen.

Liebes Forum, ich versuche (bisher erfolglos) Office 2024 LTSC zu installieren. Über das ODT habe ich mir eine Install XML erstellt und über setup /configure Konfiguration.xml aufgerufen. <Configuration ID="2112f12f-431c-4ef5-bfd7-c437b23a9e33"> <Add OfficeClientEdition="32" Channel="PerpetualVL2024"> <Product ID="Standard2024Volume" PIDKEY="XXXXXXXXXXXXXXXXX"> <Language ID="de-de"/> <ExcludeApp ID="OneDrive"/> </Product> </Add> <Property Name="SharedComputerLicensing" Value="0"/> <Property Name="FORCEAPPSHUTDOWN" Value="TRUE"/> <Property Name="DeviceBasedLicensing" Value="0"/> <Property Name="SCLCacheOverride" Value="0"/> <Property Name="AUTOACTIVATE" Value="1"/> <Updates Enabled="FALSE"/> <AppSettings> <Setup Name="Company" Value="ZZZZZZZZZZZZ."/> </AppSettings> <Display Level="Full" AcceptEULA="TRUE"/> </Configuration> Leider hängt die Installation sehr lange, bis die dann mit einem Fehler abbricht. Im Systray ist das Icon zu sehen, mit der Meldung: Microsoft 365 und Office werden im Hintergrund installiert (14`format error: invalid format specification field´) Ich habe den Key angepasst und die Edition auf 32 gesetzt. Wo in der Konfiguration ist (m)ein Fehler? Viele Grüße Davorin

Liebes Forum, wir wollen Transportregel erstellen, welche den Betreff einer eingehenden E-Mail kennzeichnen (prepend), je nachdem, woher die Mail kommt. 1. Innerhalb der Organisation, 2. von eigenen Servern und von 3. außerhalb. Eigentlich sollte das ja einfach sein, besonders das erste. Die Regel stehen in dieser Reihenfolge am Ende aller Transportregeln 1. Internal Mail: Recipient inside organization & sender inside organization (stop prozessing more rules) 2. ServerMail: Recipient member of ... & sender's IP in the range... (stop prozessing more rules) 3. External Mail: recipient member of ... & sender outside organization Nun klappt es leider nicht bei allen Mails nach Regel 2. Diese werden bei bestimmten Absender-IPs trotz explizitem Eintrag durch die dritte Regel gekennzeichnet. Gibt es eine Möglichkeit, herauszufinden, warum eine Regel nicht angewandt wurde? Im Ereignisprotokoll kann ich nur sehen, dass eine Regel angewandt wurde, nicht aber, warum bzw. warum nicht. Viele Grüße Davorin