RalphT

Ziel der Übung war/ist eine Vorgabe von einer externer Sicherheitsfirma. Alle Server, also in diesem Falle ESXi und Windows sollen direkt über die zusätzliche Karte administriert werden, sondern seperat.

Bei ESXi ist das kein Thema. Nur bei Windows habe ich gerade das Problem.

Allerdings muss ich sagen, dass das nicht so direkt hier gesagt wurde. Man hatte eine grobe Netzwerkskizze da gelassen. Ich habe mir diesen eben nochmal genauer angesehen. so 100%tig geht das daraus nicht hervor. Vielleicht sollte ich doch dort nochmal eine Rücksprache halten, wie genau das gemeint ist.

Moin,

bislang war es so, dass ein Windows-Fileserver über die einzige Netzwerkkarte verwaltet wurde.
Jetzt soll es so sein, dass nur der normale Datenverkehr (Dateifreigaben etc.) über diese Schnisttstelle laufen soll und die Administration (z.B. RDP oder VNC) über eine sep. Schnittstelle laufen soll. Der Zugriff auf die Administrationsschnittstelle erfolgt über ein anderes LAN.
Jetzt einfach eine zusätzliche Netzwerkkarte einbauen, die neue IP-Adresse und Gateway eingeben funktioniert nicht. Zwei Gateways gibt Probleme.

Wie könnte man das lösen? Gibt es Server (HP DELL?), die so eine besondere Schnittstelle/Möglichkeit dafür haben?

vor 35 Minuten schrieb NorbertFe:

Manchmal ist die hier aber sinnvoller: https://gpsearch.azurewebsites.net/Default.aspx?PolicyID=12514#13842

Hat jetzt aber weniger mit dem Problem von oben zu tun.

Uii, da war ich eben zu nachlässig beim Nachsehen. Du hast Recht, ich hatte den hier genommen.

zeroconfigexchangeonce

vor 2 Stunden schrieb jimmcse128:

Ja, den Eintrag für ZeroConfigExchange hatte ich auch schon (zu 2016er Zeiten) gesetzt. Da funktionierts ja auch.

 

Und bei 2024 bei mir halt nicht mehr.

 

Welches Office (LTSC?) nutzt du denn genau und welche Version?

 

Könntest du mir deine Build-Version nennen die du einsetzt? Vielleicht liegt´s noch an der Version irgendwie...

 

Ich habe diese Version hier:

LTSC Standard 2024 Version 2408 Build 16.0.17932.20574 Klick-und-Los) 64 Bit

vor 3 Stunden schrieb NorbertFe:

Du meinst das hier?

https://gpsearch.azurewebsites.net:/Default.aspx?PolicyID=12514

Ja genau.

Moin,

ich habe hier eine GPO angelegt. Diese erzeugt auf den Clients einen Regstrierungseintrag. Dieser lautet wie folgt:

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover

Darin dann den Wert

ZeroConfigExchange mit 1 hinterlegt.

Nachdem der Client diesen Wert in seiner Registry hatte, war das Problem gelöst.

Moin,

ich wollte hier nochmal eben eine Rückmeldung geben.

Das funktioniert super! Nach dem ersten Aufruf von Outlook steht dort "Profil wird geladen...". Anschließend öffnet Outlook das Postfach. Sehr nutzerfreundlich.

Bei der Officeversion 2016 war das bislang so, dass zuerst ein Fenster mit der E-Mailadrsse erschien. Das muss man bestätigen, dann erscheinen 3 grüne Haken und anschließend wird das Postfach geöffnet.

Dann gibt es ja noch den Weg über die Systemsteuerung. Dort ruft man das Tool E-Mail (Win10) oder Mail (Win11) auf. Wenn man dann ein neues Profil hinzufügt, erscheinent das gewohnte Fenster. Anschließend öffnet man Outlook und das Postfach wird geöffnet. Allerings funktioniert das hier ohne Zeroconfig! Das habe ich eben gerade herausgefunden.

vor 20 Stunden schrieb phatair:

Hi, dass hatten wir auch und kann mit exchange zero config erledigt werden. 

 

https://learn.microsoft.com/de-de/microsoft-365-apps/outlook/profiles-and-accounts/zeroconfigexchange

 

Grüße

Danke dir. Habe das mal eben auf die Schnelle überflogen. Ich werde das die Tage mal eben ausprobieren.

Moin,

ich habe einen neuen Client mit Office 2024 installiert. Die derzeitigen Clients laufen noch mit Outlook 2016.
Jetzt wollte ich den neuen Client mit dem Exchange 2016 verbinden. Starte ich Outlook wird mir zuerst die richige E-Mailadresse angezeigt.
Klicke ich dann auf Verbinden, schlägt Outlook mir ein IMAP-Konto vor, welches nicht existiert. IMAP läuft nicht auf dem Exchange.

Klicke ich jedoch auf die erweiterte Option und wähle dort Exchange aus, dann wird das Konto ordnungsgemäß eingerichtet.

Gibt es noch eine Möglichkeit, dass Outlook das Konto gleich im ersten Schritt unter "Verbinden" eingerichten kann?

Anbei die Screenshots.

vor 26 Minuten schrieb testperson:

dann setze im Taskplaner doch einfach den Haken "Mit erhöhten Rechten ausführen".

Hatte ich schon gesetzt. Aber ich habe auf dem System 2 User. Hatte den einen nicht in der Adminruppe. Habe ich in dem ganzen Gehampel übersehen. Läuft jetzt aber.

Zitat

ich würde es durchaus als geplanten Task laufen lassen, den Task jedoch als SYSTEM einplanen und nicht an Zeit, sondern an die Event Id 6273 binden. Dann kannst Du dich austoben - email verschicken, Textdatei schreiben, was auch immer.

Ja genau, so habe ich das auch. Hatte mich oben nicht klar genug ausgedrückt. So praktiziere ich das auf den anderen Servern auch. Es werden dann immer Mails verschickt. Das funktioniert sehr gut.

Moin,

ich verwende in einer PS-Datei folgenden Codeschnipsel:

Get-WinEvent @{LogName="Security";Id=6273} -MaxEvents 1 | %{([xml]$_.ToXML()).Event.EventData} > C:\TMP\information.txt ;

Dieser ließt einen Teil aus der Ereignisanzeige aus. Das funktioniert soweit auch.

Jetzt habe ich folgendes Problem:
Dieses Script soll auf einem Server laufen. Dort hat ein Nutzer aus der AD lokale Adminrechte. Die benötigt er auch, da für den Zweig Security Adminrechte notwendig sind.

Wenn jetzt dieser Nutzer auf dem Server angemeldet ist, ein PS-Fenster ohne erhöhte Rechte öffnet, dann wird die Ereignisanzeige nicht ausgelesen. Mit erhöhten Rechten funktioniert das.
Dieser Nutzer ist in der lokale Gruppe der Administratoren eingetragen.

Kann man das Script auch so abändern, dass man kein Fenster mit erhöhten rechten öffnen  muss?
Hintergrund:
Dieses Script soll mit diesen Nutzerdaten im Taskplaner ausgeführt werden.

Ich habe jetzt den Schlüssel verändert. Das funktoniert alles soweit.

Ich bin vorher von zwei falschen Tatsachen ausgegangen:

Ein erster Treffer bei google zeigte, dass das nur mit einer Neuinstallation möglich sei.

Dann bin ich fälschlicherweise davon ausgegangen, dass die CaPolicy.inf nur bei der Installation wirksam sei. Daher dachte ich, dass dort eine Veränderung der Parameter nichts bringt.

Problem ist also hiermit gelöst.

vor 35 Minuten schrieb cj_berlin:

Die Schlüssellänge kannst Du auch ohne Neuinstallation ändern. Musst halt die CA-Zertifikate neu ausstellen, aber dann hast Du sogar fortlaufende Historie.

Dann habe ich wohl falsch gedacht. Ich dachte, dass bei der Installation nach der Schlüssellänge gefragt wird. Daher bin ich jetzt davon ausgegangen, dass der Wert mit dieser Installation fest ist und nicht mehr verändert werde kann.

vor 8 Minuten schrieb Dukel:

Wieso installiert man nicht erst eine neue CA? Wieso die alten abbauen?

Ich hatte nur vor Augen, dass ich keine Lust hatte, zwei neue Server aufzusetzen.

Die alte CA eine Schlüssellänge von 2.048. Das soll geändert werden.

Der Plan wäre, dann danach eine neue PKI aufzusetzen.

Ich glaube ich mache das so, dass ich vorher ein selbstsigniertes am Exchange erstelle. Dann bekommen die Mitarbeiter eine Zertifikatsnachricht, die dann in den vertrauenswürdigen Speicher installiert werden müsste. Danach wäre ja wieder Ruhe.

Anschließend kann ich dann die neue PKI aufsetzen und dem Exchange wieder ein Zertifikat aus der neuen PKI geben. Das würde dann beim Mitarbeiter geräuschlos funktionieren.

Meine Frage zielte daher nur darauf ab, ob es nur eine lästige Zertifikatswarnung geben würde. Damit könnte man kurzfristig leben.

Moin,

ich wollte in einer AD-Umgebung die 2-stufige Zertifizierungstelle außer Betrieb nehmen. Der Exchangeserver hat von dieser Stelle auch ein Zertifikat.
Ein Punkt bei der außer Betriebnahme ist, dass alle ausgestellten Zertifikate für ungültig erklärt werden.

Wie reagiert Outlook darauf? Gibt es nur eine Zertifikatswarnung oder stellt Outlook seinen Dienst ein?

Der Trigger kam ja aus dieser Sicherheitsempfehlung, die bei uns hier vorgeschlagen wurden. Ich bin natürlich erst einmal davon ausgegangen, dass der Berater schon weiß, was gut ist. Vielleicht hatte er "das Ganze" nicht so direkt vor Augen. Denn schon wie du schreibst, ganz unsinnig ist der RODC nicht, hängt halt von den Gegebenheiten ab.

Bestätigt fühlte ich mich dann von ein oder zwei Berichten, wovon ich ja einen hier gepostet habe.

Um jetzt einen evtl. Ärger/Frust aus dem Weg zu gehen, werde ich den RODC entfernen. Ich werde dann wohl in einer ruhigen Minute das Thema in einer Testumgebung mal nachstellen.

Besprechen kann ich diese Problematik ja beim nächsten Termin mit dem Berater. Dann kann ich immer noch einen Server aufsetzen.

vor 15 Minuten schrieb testperson:

wie hoch ist denn die Gefahr, dass jemand in die Zweigstelle kommt und den RODC klaut bzw. die Hardware klaut, auf der der RODC läuft?

Ungefähr so ähnlich wie in der Hauptzentrale. Ja diesen Grund hatte ich schon öfters gelesen. Wie würde das bei einem Angriff über der Firewall der Zweigstelle aussehen? Dann hätten die Angreifer ja erst mal einen RODC vor sich. Ok, natürlich existiert ein Tunnel zur Zentrale, wo die DCs stehen.

Dieses Thema muss ich jetzt hier nicht durchpeitschen. Es war halt nur eine Empfehlung. Vielleicht sollte ich das mal in in einer Testungebung für mich aufbauen und dann in aller Ruhe schauen. Diesen RODC könnte ich ja wieder aus der Domäne entfernen.

vor 6 Minuten schrieb NilsK:

hm. Würde ich eher nicht so machen, kann aber vom Vorgehen her funktionieren, wenn man weiß, was man tut. Aber: Da meiner Erfahrung nach ein RODC "in echt" fast nie sinnvoll ist, würde ich das Konzept prüfen, ob ein RODC wirklich eine sinnvolle Lösung für das Problem (das ich ja nicht kenne) ist.

Das hatte man mir empfohlen. Als Sicherheitsmaßnahme. Ich gebe zu, dass ich vorher noch nie mit einem RODC rumhantiert habe. Bislang läuft ja noch der DC.

Da ich auch beim googlen Beiträge zu diesem Szenario gefunden habe, dachte ich, dass dieses Vorgehen schon ok ist.

https://www.ip-insider.de/so-betreiben-sie-schreibgeschuetzte-domaenencontroller-a-f559470f963357cd5c8584b8fb8afb12/

Warum würdest du das nicht empfehlen?

vor 12 Minuten schrieb NilsK:

wozu das denn? Was wolltest du mit so einem Setup erreichen?

Der eine DC soll abgeschaltet werden. Es soll dann nur noch der RODC in der Zweigstelle laufen.

vor 12 Minuten schrieb NilsK:

Hast du auch eine Event-ID dazu?

Die lautet 18.

Moin,

ich hatte in einer Zweigstelle neben einem DC 2019 einen RODC aufgesetzt. Derzeit laufen noch beide Server parallel. Seit einiger Zeit gibt es die folgende Meldung im DC:

Die Signatur auf dem PAC von krbtgt_1234 konnte vom KDC während der TGS-Verarbeitung nicht verifiziert werden. Dies deutet darauf hin, dass das PAC verändert wurde.

Bislang habe ich noch keine Lösung dazu gefunden.

Ich habe gerade eben nochmal nachgesehen. Manchmal übersieht man ja was oder es ist anders sortiert.

Hier fehlt diese Version. Ich habe hier 2015, 2016 und 2019.

Vielleicht sollte ich mal meinen Verkäufer anrufen und diesen um Rat fragen.

Moin,

ich möchte einen Client mit Windows 10 Enterprise LTSC 2019 auf 2021 aktualisieren. Im Admincenter (ehem. VLSC) wird mir diese Version nicht angeboten.

Ist dieser Sprung kostenpflichtig? Die Version LTSC 2021 ist ja auch noch Windows 10.

Wie kann ich diese Version aktualisieren?

vor 17 Stunden schrieb daabm:

"Etwas aus dem Lot" @NilsK ist da die zutreffende Formulierung, aber bisher kam vom TO nichts dazu

Stimmt. Denn der hat sich die 2 Tage bei gutem Wetter eine Auszeit gegönnt.

Ich war heute kurz vor Ort und habe die beiden DCs neu gestartet. Es war beiden tatsächlich ein Update vom Virenscanner (Panda) noch nicht fertig.

Nach dem Neustart merkte man sofort, dass die beiden Geräte wieder wesentlich flotter auf Eingaben reagieren. Mir war auch so, dass ein DC erst mal so nicht viel an Resourcen benötigt. Das war damals bei Novell auch so.

Das tückische hierbei war, dass der Virenschutz einen benötigten Neustart nicht angezeigt hatte.

Anschließend habe ich das gleiche Verfahren auf beiden DCs wieder ausprobiert. Läuft!

Beim Klick auf OK reagiert das Menü sofort. Das war vorher nicht der Fall. Man sah richtig, wie das manchmal klemmte.

Jetzt habe ich zum Schluss aber trotzdem noch eine Frage:

Wenn ich auf dem DC 1 den GPO-Editor öffne und dort etwas verändere, dann werden die Änderung ja auf dem SYSVOL geschrieben.

Wird dann in diesem Fall auf dem SYSVOL vom DC 1 geschrieben? Also auf seine Festplatte? Oder kann man das gar nicht so genau sagen? Die Änderung ist doch auf allen DCs sofort verfügbar oder liege ich da falsch?

Denn mit der eigentlichen Replikation hat dieses hier doch nichts zu tun.

vor 1 Stunde schrieb Nobbyaushb:

Auf jedem DC ein CMD als Administrator aufmachen

repadmin /syncall /force

Und das bitte auf allen 4 DC´s

In der Ausgabe stehen eventuelle Probleme, meist mit einem Hinweis

Wie hoch ist die Latenz zwischen den Standorten?

Ein Forrest und ein AD?

Darüber hatte ich auch schon nachgedacht. Habe es aber aus einem anderen Grund erstmal verworfen.

Mir ist aufgefallen, dass die beiden DCs hier recht lahme Krücken sind. Ein STRG-ALT ENTF dauert bestimmt 5 bis 10 Sekunden, bis mal der Bildinhalt zu sehen ist. RAM haben die jeweils 16G, der ist nur zu 30% ausgelastet. Die Prozessorleistung ist ständig bei 30% ausgelastet. Das kam mir recht viel vor. Ich habe noch andere Server, ähnlicher Bauart. Das sind z.B. einfache Fileserver usw. Die regieren wesentlich flotter. Bei denen ist die Dauerlast vom Prozessor bei mal gerade 5%.

Die Prozessorlast kommt bei den DCs vom Virenschutz. Jetzt hatte ich heute noch gesehen, dass der Virenschutz überall einen Neustart erfordert.

Ich werde daher jetzt als aller erstes die Rechner alle neustarten. Danach sehe ich mir nochmal die Prozessorlast auf den beiden DCs an.

Ich hatte letzt den Exchange 5 oder 6 mal booten müssen, bis alle Windows-Updates und Virenschutzupdates zufrieden waren. Daher war vorhin noch meine Vermutung, dass das vielleicht die Fehlerursache sein könnte.

Anschließend werde ich mal wie du geschrieben hattest die Replikation anschubsen.

Zwischenzeitlich hatte ich vorhin mit einer Test-GPO rumgespielt. Mir einen Wert ausgesucht, z. B. "Anmelden am Dienst verweigern" und dann immer einen Nutzer nach dem anderen im Sekundentakt reingebracht und wieder entfernt. Mal gehts zwei mal, und dann wieder 2 oder 3 mal nicht.

Die Latenz? Hm, ich glaube ein Ping hat so eine Antwortzeit von 10 - 15 ms. Bin mir da aber nicht so genau sicher.

vor einer Stunde schrieb Nobbyaushb:

Liest sich wie ein Sync-Problem im AD

Habe ich auch schon gerade im Verdacht. Ich bin ja immer noch in der Findungsphase.

Ich habe hier 2 DCs und woanders auch 2 DCs stehen. Der DC mit den FSMO-Rollen steht hier. Verbunden über eine gute Leitung, über VPN und Firewalls.

Jetzt hatte ich gerade von der Zweigstelle das gleiche Verfahren auf einem der DCs probiert. Also die gleiche GPO editiert. Dort nach Belieben etwas verändert. Funktionierte super schnell und einwandfrei. Dann dachte ich schon daran, das das Phänomen nur auf einer Seite besteht.

Nein, denn ein Nachfolgeversuch auf der Gegenseite war anschließend nicht erfolgreich.

Wenn man den Editor öffnet und dort etwas einstellt und anschließend auf OK oder Übernehmen klickt, dann geht das mal superschnell und im Fehlerfall "klemmt" es richtig. Der blaue Mauskreis dreht sich ca. 2 Sekunden.

Was mich so stutzig macht:

Warum funktionert es bei einem großen Teil der Werte und bei bestimmten Zweigen nicht? es wird doch die gleiche Datei beschrieben. Oder denke ich falsch?