sd2019

Der Client wird über die Gerätesuche einfach nicht gefunden, woran das liegen könnte bzw. Was das mit den SMB Meldungen im Trace auf sich hat und ob man noch was bedenken muss wenn man zwischen zwei Servern kommuniziert und nur einer davon in der Domäne ist

Hallo zusammen, ich habe eine WS 2019 VM, welche aus Sicherheitsgründen in der Arbeitsgruppe WORKGROUP ist und eine WS 2016 VM, welche in der Domäne ist. Netzwerktechnisch ist zwischen diesen beiden VM's alles erlaubt. ICMP funktioniert auch testweise zu beiden Seiten. Der WS 2016 ist der Administrationsserver einer Antivirenlösung und soll nun den Antiviren Client auf die VM in der WORKGROUP ausrollen. Hierzu wäre es natürlich erstmal hilfreich, wenn der Administrationsserver den Client überhaupt findet. Im Wireshark Trace des Administrationsservers sehe ich immer folgende Meldungen (der "User:", den ich unkenntlich gemacht habe, hat folgendes Namensschema: "DOMAIN\HOSTNAME$"), während ich die Gerätesuche anstoße Im Wireshark Trace des Clients, der vom Administrationsserver gefunden werden soll sehe ich folgende Meldungen, wenn die Suche angestoßen wird (der User, den ich hier unkenntlich gemacht habe, ist der gleiche) Zur Info, die Windows Firewalls aller Netzwerkprofile auf dem WS 2019 sind aus. Weiß gar irgendwie nicht mehr weiter

@Dukel der betreffende Kollege ist aktuell nicht verfügbar, soll ich zukünftig aber sowieso mit machen @NorbertFe und dann füge ich in der Vorlage wirklich das Computerobjekt des betreffenden Servers hinzu? Und Anwendungsrichtlinie wäre dann Serverauthentifizierung?

Hallo zusammen, wir haben bei uns auf einem Windows Server 2019 Datacenter die IIS Rolle installiert und eine Software installiert, welche auch mehrere Sites erstellt hat, welche über den IIS Manager verwaltet werden können. Der Server hat eine statische IP-Adresse und es existieren zwei zusätzliche CNAME's, dessen DNS-Namen jeweils gleich der Hostnamen der Bindung der Sites sind. Nach der Installation sind die Bindungen dieser Sites defaultmäßig auf http konfiguriert, soll nun aber auf https umgestellt werden, also sollen die beiden URL's im Browser, welche im Hintergrund auf den gleichen virtuellen Server verweisen, über https aufgerufen werden. Wir haben in unserer Infrastruktur auch bereits eine installierte CA, allerdings sind mir die Konfigurationsschritte für die automatische Erstellung dieser (müssten ja eigentlich in dem Fall ja Webserver-Zertifikate sein?) nicht ganz transparent. Wäre für eine Schritt-für-Schritt Anleitung sehr dankbar. Also ich weiß, dass ich z.B. die CA, über den Browser auf dem betreffenden Server, über https://xxxxx/certsrv erreichen kann, allerdings fehlen mir hier glaub ich ein paar Optionen (ich bin aber als Domänen-Admin auf dem Server eingeloggt). Oder muss ich über das lokale SnapIn der Zertifikate (wenn ja Computer oder Benutzer?) auf dem Server gehen und dort dann eine Zertifikatsanforderung stellen? Womöglich würde ich für beide URL's, die ja im Namen etwas unterschiedlich sind ein Zertifikat nehmen wollen, wo beide URL's als DNS Namen im Zertifikat stehen. Oder muss ich auf der CA selbst gar eine eigene Vorlage erstellen und dort in den Sicherheitseinstellungen das Computerobjekt hinzufügen und entsprechende Rechte vergeben?

@daabm Ich habe mir das mal mit "accesschk -a *" ausgeben lassen und wie vermutet steht bei "SeServiceLogonRight:" die AD-Gruppe drin, die wiederum mehrere AD-Benutzer enthält, die dieses Recht per GPO schon zugewiesen bekommen haben. Diese AD-Gruppe hatte ich ja bereits in meinem Anfangspost erwähnt. @testperson 1. Warum denn nicht in der DDP? 2. Was soll mir die lokale Gruppe bringen? ich muss das Recht ja bei "Anmelden als Dienst" hinterlegen. Das heißt ich muss irgendwie auf dem Client entweder den "NT Service\XYZ" in die Benutzerrechte bei "Anmelden als Dienst" reinpacken oder aber die lokale Gruppe, in der das lokale Konto "NT Service\XYZ" Mitglied ist. Auch die Benutzerechte von "Lokal Anmeldung erlauben" bringen mich doch gar nicht weiter?

Hi! Folgende Situation Es existiert auf jedem Client in der Domäne ein lokales Systemkonto "NT Service\"Dienstname", welches automatisch bei der Installation der Software angelegt wurde. Dieses Konto ist auch in dem Windows Dienst unter "Anmelden als" eingetragen. Problem Dieses Systemkonto hat, wie man auch unter der lokalen Sicherheitsrichtlinie > Lokale Richtlinien > Zuweisen von Benutzerrechten > Anmelden als Dienst, sieht, kein Recht diesen Dienst zu starten, da dieses Konto dort nicht eingetragen ist. Jedes Mal, also mehrere 100 Male am Tag, versucht dieser Dienst zu starten, was extrem wichtig ist, aber aufgrund fehlender Berechtigungen schlägt dies fehl. Lösungsvarianten Im Prinzip wäre die Lösung an sich ja einfach, die wie folgt aussehen könnte: Default Domain Policy -> Computerkonfiguration > Windows-Einstellungen > Sicherheitsreinstellungen > Lokale Richtlinien > Zuweisen von Benutzerrechten > Anmelden als Dienst > Eintragung von "NT Service\"Dienstname" Fehlermeldung --> Folgende Konten konnten nicht überprüft werden : "NT Service\"Dienstname" Das Problem scheint hier das "NT Service" zu sein, denn wenn ich nur den Dienstnamen dort eingebe, funktioniert es. Dies ist dann allerdings sinnbefreit, weil es nicht über die GPO übertragen wird, da dieses Konto ohne das "NT Service" nicht zugeordnet werden kann. Bei uns ist über die DDP schon eine AD-Gruppe mit diesen "Anmelden als Dienst" Rechten versehen. Theoretisch könnte man also das Konto in dem Windows Dienst bei "Anmelden als" auf jedem Client in ein AD-Konto ändern und dies dann einfach in die AD-Gruppe hinzufügen. Ich habe es versucht mit Neues GPO Objekt > Computerkonfiguration > Systemsteuerungseinstellungen > Dienste Fehlermeldung --> Das CPassword-Attribut wurde verworfen, um die Sicherheitsrisiken zu minimieren. Verwenden Sie stattdessen sichere integrierte Benutzerkonten zum Erstellen von Gruppenrichtlinieneinstellungen für Dienste. Erfahren Sie, warum "CPassword" verworfen wurde und was Sie zu Ihrem Schutz tun können, indem Sie unten auf "Hilfe" klicken. Hier werde ich nicht ganz schlau draus Fragestellung Wie bekomme ich es also hin, dass auf jedem Client im Unternehmen (es sind sehr viele), dieser "NT Service\"Dienstname" in der lokalen Sicherheitsrichtlinie die Rechte unter "Anmelden als Dienst" erhält? Alternativ gibt es ja vielleicht die Möglichkeit, in Annäherung an die oben genannte 2. Lösungsvariante, den Account für "Anmelden Als" bei dem bestehen Dienst irgendwie durch ein neu erstelltes AD-Konto zu ersetzen und dieses dann über die GPO bei "Anmelden als Dienst" hinzuzufügen? Vielen Dank im Vorraus!

@cj_berlin hättest du wohl einen Tipp für mich?

Sorry für meine lückenhafte Beschreibung. ich habe natürlich nach dem Export des dumps, den besagten DHCP Scope über die DHCP Server MMC gelöscht und anschließend einen DC Sync geforced. Dann habe ich das mit dem Import durchgeführt mit der bereits erwähnten Fehlermeldung “Die Anforderung wird nicht unterstützt”

Hallo zusammen, ich möchte mittelfristig alle Subnetze bei uns im Unternehmen verkleinern, da wir fast 90% /16er Netze haben, aber diese Größe gar nicht benötigt wird und somit unnötige Brodcast-Stürme entstehen. Das /16 Netz möchte ich in ein /24 Netz umwandeln. Dazu habe ich mal an einem Beispiel Subnetz den passenden Bereich exportiert mit folgendem Command (SERVERNAME habe ich natürlich durch den passenden Hostnamen ersetzt) netsh dhcp server \\SERVERNAME scope 10.32.0.0 dump >c:\dhcp.txt Um von eine /16 SNM auf eine /24 zu kommen, habe ich in der .txt Datei die SNM von 255.255.0.0 durch 255.255.255.0 und darüber hinaus jeder Eintrag von 10.32.0.0 durch 10.32.1.0 ersetzt. Mit folgendem Command wollte ich dies nun wieder importieren - dies hat aber nicht geklappt - ich bekomme die Fehlermeldung: Die Anforderung wird nicht unterstützt. netsh dhcp server import c:\dhcp.txt all Was kann ich tun?

Wie würde man das denn mit dem Postfix umsetzen?

@testperson Die verschicken via SMTP von der Software aus auf verschiedenen Clients. Die Mails werden also an Outlook übergeben.

@Dukel Hi, nein das kann ich leider nicht einschränken. Benutzer, die senden und empfangen, sind unlimitiert.

Hallo zusammen, hinsichtlich der Einführung einer neuen Software im Unternehmen soll das Verhalten der Mailkommunikation aus dieser Software heraus getestet werden. Es soll also irgendwie temporär umgesetzt werden, dass alle E-Mails, die von einem dedizierten, internen Server, auf dem dann ein Office Client (Microsoft 365) installiert ist, gesendet werden, an ein bestimmtes, internes Postfach umgeleitet werden, und somit auch intern bleiben, und nie nach außen gelangen. Jetzt stell ich mir nur die Frage, wie man das am sinnvollsten umsetzt? Über die Nachrichtenfluss-Regeln im ECP kann ich zwar ein Absender-Filter auf die IPv4 Adresse setzen, aber diese Regel greift nicht, da im Header wahrscheinlich keinerlei Angaben zu dieser Source IP gemacht werden. Zumindest funktioniert diese Regel nicht. Könnt man das noch irgendwie anders umsetzen?, eventuell über die Exchange Konsole? Oder alternativ mit Postfix?, wobei ich da keinerlei Erfahrung zu habe.

Gibt es keine Möglichkeit, evtl. eine neue, eigene Sicherheitsgruppe für DHCP-Benutzer zu erstellen und diese dann zu konfigurieren (wüsste nicht wo man dieses Berechtigungskonzept verwaltet)

Ja gut die Zeit habe ich leider nicht. Und es geht hier um elektronische Steuerteile. Die Diskussion hinsichtlich dem Warum man das braucht ist unwichtig und auch nicht zielführend. Ich bin da eher an Lösungsvorschlägen interessiert. :)

Sinn der Sache ist, dass bestimmte Nutzer in der Produktion Zugriff auf einen dedizierten DHCP Bereich haben, da ein stetiger Zugriff auf die sich ständig ändernden MAC-Adressen und IP-Adressen erforderlich ist, um Komponenten ansteuern zu können. Wenn man das irgendwie problemlos wer Website darstellen kann, ist das natürlich auch eine Alternative (ist aber wahrscheinlich komplizierter oder?)

Hi Leute! Folgende Anforderung: Mittels den DHCP RSAT Tools sollen Benutzer auf ihren Arbeits-PC's auf die Server DHCP Leases (in diesem Fall auf dem DC) eines bestimmten Scopes, also ein bestimmter Subnet Bereich zugreifen dürfen (nur LESE Rechte). Problem: Wenn ich die DHCP RSAT bei mir auf dem lokalen Rechner installiert habe, und dann unter DHCP > Server hinzufügen > Dieser autorisierte DHCP-Server den entsprechenden Server auswähle, kann ich bereits auf alle DHCP Bereiche zugreifen (nur Lese Rechte). Jedoch frage ich mich warum, das geht, da ich mich nicht in die vordefinierte DHCP-Benutzer Sicherheitsgruppe eingetragen habe Man kann ja die betreffenden User in die bereits vorhandene, lokale Sicherheitsgruppe, wie oben erwähnt, DHCP-Benutzer Sicherheitsgruppe eintragen, aber wie kann ich es umsetzen, dass dedizierte Benutzer von unseren ca. 20 DHCP Bereichen nur auf einen bestimmten DHCP Bereich Lesezugriff haben? Alles andere soll erst gar nicht zu sehen sein.

Hier sind nur die Fehler: Fehler. Ereignis-ID: 0x0000165B Erstellungszeitpunkt: 09/16/2019 08:54:01 Ereigniszeichenfolge: Die Sitzung konnte vom Computer "NotebookXY" nicht eingerichtet werden, da die Sicherheitsdatenbank kein Vertrauenskonto "NotebookXY$" entsprechend dem angegebenen Computer enth„lt. Fehler. Ereignis-ID: 0x000016AD Erstellungszeitpunkt: 09/16/2019 09:00:15 Ereigniszeichenfolge: Die Sitzungseinrichtung von Computer NotebookXY konnte nicht authentifiziert werden. Der folgende Fehler ist aufgetreten: ......................... Der Test SystemLog fr DC1 ist fehlgeschlagen. @Tektronix das musst du mir erklären @NilsK @lefg also mittlerweile fällt mir tatsächlich nichts mehr ein. Die Ereignisanzeige sagt nichts bestimmtes (außer folgender Fehlermeldung, nachdem ich die Alterung / Aufräumung in allen Bereichen auf 7 Tage gesetzt und aktiviert habe: Der DNS-Server hat den Aufräumzyklus abgeschlossen, aber es wurden keine Knoten besucht. Der Grund für diesen Zustand kann sein: 1) Es sind keine Zonen für das Aufräumen durch diesen Server konfiguriert. 2) Es ist ein Aufräumzyklus innerhalb der letzten 30 Minuten durchgeführt worden. 3) Während des Aufräumens ist ein Fehler aufgetreten. Der nächste Aufräumzyklus ist für die nächsten 168 Stunden geplant. Die Ereignisdaten enthalten den Fehlercode, wenn während des Aufräumzyklus ein Fehler aufgetreten ist. ) Was mir aktuell noch auffällt betrifft die allgemeinen Serveroptionen vom DHCP. Wie bereits erwähnt, haben wir auf dem DC im IPv4 einige Bereiche aufgrund verschiedener VLAN's. Jeder dieser Bereiche hat unter den Bereichsoptionen unter 003 Router die jeweilige IP-Adresse des Subnetzes liegen. Allerdings findet man unter DHCP>DC>IPv4 noch die Serveroptionen, die ganz oben über allen anderen Bereichen angeordnet sind. Dort ist merkwürdigerweise bei 003 Router das Gateway aus einem bestimmten VLAN eingetragen, aber sollte dort nicht eigentlich das Gateway vom DC stehen? Ansonsten wüsste ich aktuell nicht was ich noch überprüfen sollte?? Ich verstehe einfach nicht, warum bei einem neuen Client, der via DHCP eine IP-Adresse bekommen hat, 0 Einträge im DNS gesetzt werden, weder im Forward und dann natürlich auch nicht im Reverse Bereich. Darüber hinaus werden dann auch neue IP-Adressen vom DHCP vergeben, wo bereits noch ein alter DNS Eintrag existiert, aber natürlich einen ganz anderen Namen aufweist als der neue Client

Im Event Log kann ich nichts finden und im dcdiag steht folgendes: VerzeichnisDCdiagnose Anfangssetup wird ausgefhrt: Der HomeDC wird gesucht... HomeDC = **DC** * Identifizierte AD-Gesamtstruktur. Sammeln der Ausgangsinformationen abgeschlossen. Erforderliche Anfangstests werden ausgefhrt. DC wird getestet: Site-Germany-**ORT**\**DC** Starting test: Connectivity ......................... **DC** hat den Test Connectivity bestanden. Prim„rtests werden ausgefhrt. DC wird getestet: Site-Germany-**ORT**\**DC** Starting test: Advertising ......................... **DC** hat den Test Advertising bestanden. Starting test: FrsEvent ......................... **DC** hat den Test FrsEvent bestanden. Starting test: DFSREvent Fr den Zeitraum der letzten 24 Stunden seit Freigabe des SYSVOL sind Warnungen oder Fehlerereignisse vorhanden. Fehler bei der SYSVOL-Replikation k”nnen Probleme mit der Gruppenrichtlinie zur Folge haben. ......................... Der Test DFSREvent fr **DC** ist fehlgeschlagen. Starting test: SysVolCheck ......................... **DC** hat den Test SysVolCheck bestanden. Starting test: KccEvent ......................... **DC** hat den Test KccEvent bestanden. Starting test: KnowsOfRoleHolders ......................... **DC** hat den Test KnowsOfRoleHolders bestanden. Starting test: MachineAccount ......................... **DC** hat den Test MachineAccount bestanden. Starting test: NCSecDesc ......................... **DC** hat den Test NCSecDesc bestanden. Starting test: NetLogons ......................... **DC** hat den Test NetLogons bestanden. Starting test: ObjectsReplicated ......................... **DC** hat den Test ObjectsReplicated bestanden. Starting test: Replications ......................... **DC** hat den Test Replications bestanden. Starting test: RidManager ......................... **DC** hat den Test RidManager bestanden. Starting test: Services ......................... **DC** hat den Test Services bestanden. Starting test: SystemLog Fehler. Ereignis-ID: 0x0000165B Erstellungszeitpunkt: 09/13/2019 08:37:33 Ereigniszeichenfolge: Die Sitzung konnte vom Computer "**CLIENTX**" nicht eingerichtet werden, da die Sicherheitsdatenbank kein Vertrauenskonto "**CLIENTX**$" entsprechend dem angegebenen Computer enth„lt. Fehler. Ereignis-ID: 0x000016AD Erstellungszeitpunkt: 09/13/2019 08:41:48 Ereigniszeichenfolge: Die Sitzungseinrichtung von Computer **CLIENTX** konnte nicht authentifiziert werden. Der folgende Fehler ist aufgetreten: Fehler. Ereignis-ID: 0x0000165B Erstellungszeitpunkt: 09/13/2019 08:52:33 Ereigniszeichenfolge: Die Sitzung konnte vom Computer "**CLIENTY**" nicht eingerichtet werden, da die Sicherheitsdatenbank kein Vertrauenskonto "**CLIENTY**" entsprechend dem angegebenen Computer enth„lt. ......................... Der Test SystemLog fr **DC** ist fehlgeschlagen. Starting test: VerifyReferences ......................... **DC** hat den Test VerifyReferences bestanden. Partitionstests werden ausgefhrt auf: ForestDnsZones Starting test: CheckSDRefDom ......................... ForestDnsZones hat den Test CheckSDRefDom bestanden. Starting test: CrossRefValidation ......................... ForestDnsZones hat den Test CrossRefValidation bestanden. Partitionstests werden ausgefhrt auf: DomainDnsZones Starting test: CheckSDRefDom ......................... DomainDnsZones hat den Test CheckSDRefDom bestanden. Starting test: CrossRefValidation ......................... DomainDnsZones hat den Test CrossRefValidation bestanden. Partitionstests werden ausgefhrt auf: Schema Starting test: CheckSDRefDom ......................... Schema hat den Test CheckSDRefDom bestanden. Starting test: CrossRefValidation ......................... Schema hat den Test CrossRefValidation bestanden. Partitionstests werden ausgefhrt auf: Configuration Starting test: CheckSDRefDom ......................... Configuration hat den Test CheckSDRefDom bestanden. Starting test: CrossRefValidation ......................... Configuration hat den Test CrossRefValidation bestanden. Partitionstests werden ausgefhrt auf: **ORT** Starting test: CheckSDRefDom ......................... **ORT** hat den Test CheckSDRefDom bestanden. Starting test: CrossRefValidation ......................... **ORT** hat den Test CrossRefValidation bestanden. Unternehmenstests werden ausgefhrt auf: **ORT**.mueller-schmidt.de Starting test: LocatorCheck ......................... **ORT**.mueller-schmidt.de hat den Test LocatorCheck bestanden. Starting test: Intersite ......................... **ORT**.mueller-schmidt.de hat den Test Intersite bestanden.

Moin, die Katastrophe ist, dass eben die DNS Einträge nicht vernünftig erstellt werden, und somit diverse Folgeprobleme auftauchen (unter anderem Image Rollout auf Clients etc. etc.) Nein, hier im Netzwerk gibt es einen zweiten DC. Da hast du recht, das wäre allerdings grob fahrlässig. Ich sehe gerade noch btw, dass unter quasi allen Reverse Lookup Zonen unter den Eigenschaften im Reiter Namenserver, bei dem Haupt DC bei IP-Adresse unbekannt steht, bei dem DC2 allerdings steht die IP-Adresse, könnte das eventuell auch eine Ursache sein und wenn ja, wie könnte man dies zentral bereinigen?

Schönen Guten Tag, bei uns im Unternehmen gibt es einige Probleme in Bezug auf DHCP und DNS. Zur Info DHCP und DNS Server sind beide auf dem DC installiert. Es existiert kein DHCP Failover. Server ist eine VM, Windows Server 2016, 1607 Im DHCP IPv4 Bereich existieren mehrere (ca. 20) Bereiche für verschiedene VLAN's (meistens /16 Subnetze) Im Netzwerk befinden sich mehrere Hundert Geräte der DC im Netzwerk hat die 10.1.1.1 Probleme neue Clients im Netzwerk bekommen eine IP-Adresse wie es auch sein soll, dies sehe ich auch unter den Leases im entsprechenden IPv4 VLAN-Bereich, allerdings bleibt die Bezeichnung Name in den Adressleases bei dem entsprechenden Client komplett leer daraus folgt natürlich, dass im DNS Forward, als auch im Reverse Bereich kein Eintrag gesetzt wird (wenn ich alles statisch im DNS eintrage, funktioniert es, aber das ist natürlich keine Lösung) ==> neue DHCP Einträge werden also einfach nicht im DNS eingetragen (früher lief das wohl alles mal irgendwie, da kann ich allerdings keine Aussage zu treffen, da ich neu im Unternehmen bin und Optimierungsarbeiten vornehme) alte DNS Einträge, die nicht mehr aktiv sind, werden nicht gelöscht, so entstehen leider Probleme zu den ganzen /16 VLAN Bereichen aus dem DHCP existieren leider ausschließlich /24 Zonen in der Reverse DNS LookupZone, was meiner Meinung nach eine gute Übersicht und Struktur bietet, allerdings auch nervig ist zu pflegen wenn ein bestimmter DHCP Bereich gerade die letzte IP-Adresse, z.B. 10.1.8.254 vergeben hat und der nächste Client dann die 10.1.9.1 bekommt, muss ich dafür sorgen, dass dann auch eine 9.1.10.in-addr.arpa Reverse-Lookup-Zone eingerichtet ist meiner Meinung nach wäre es viel sinnvoller zum jedem /16 Bereich auch direkt eine /16 Reverse Lookup Zone einzurichten, oder sogar eine /8 Reverse Lookup Zone, laut folgendem Artikel sollte auch nichts dagegen sprechen, oder was meint ihr dazu? https://social.technet.microsoft.com/Forums/en-US/175b5449-858c-4b2c-84a7-17ef3d367885/effects-of-adding-a-classb-reverse-dns-zone?forum=winserverNIS Aktuelle Konfiguration Die könnt ihr den angehangenen Bildern entnehmen :) Die Dateinamen sind immer entsprechend gewählt, damit man weiß welche Eigenschaften man jetzt sieht Darüber hinaus stellt sich mir die Frage, ob ich eventuell den Domänen-Admin in die AD-Gruppe DnsUpdateProxy aufnehmen muss oder aber welchen Benutzer ich bei den Anmeldeinformationen des DHCP Servers hinterlegen muss Konfigurationstechnisch habe ich mich auch schon sehr an dieser Anleitung orientiert: https://www.faq-o-matic.net/2015/04/08/die-ad-dns-zone-sicher-konfigurieren/ Leider hat dies noch nicht zur Lösung der Probleme beigetragen. Wünschenswerte Konfiguration wenn neue DHCP Einträge generiert werden, sollen die sofort in der Forward LookupZone stehen und der Haken bei Entsprechenden Zeigereintrag (PTR) aktualisieren soll natürlich direkt mit gesetzt werden, damit ein Reverse Eintrag gesetzt wird Die Alterung in allen Bereichen soll aktiviert sein, heißt also, wenn sich ein PC z.B. 1 Woche nicht mehr im Netzwerk angemeldet hat, dann soll der DNS Eintrag aus der Forward und Reverse Zone entfernt werden gleiches gilt natürlich auch für aktuell bestehende Altlasten von vor mehreren Jahren Ich hoffe ihr könnt mir hier weiterhelfen. Solltet ihr noch mehrere Informationen benötigen, dann raus damit! :)

Kann mir eventuell wer sagen, wie man via Powershell auf dem Exchange 2016 auf das Adressbuch eines beliebigen Users zugreifen kann, um zum Beispiel einzelne Kontakte, Ordner auch auch den Shared Ordner zu löschen?

@Dukel nein nutzen wir nicht, das ist allerdings ein guter hint

Hängen tut er quasi nie, das sollte eher eine präventive Sicherheitsmaßnahme sein, die Lease Time beträgt 8 Tage

Kurze Verständnisfrage: wir haben bei uns im Unternehmen mehrere VLANS im Netzwerk eingerichtet, wobei jedes VLAN seinen eigenen DHCP-Bereich auf dem DC hat. Darüber hinaus existieren in jedem DHCP-Bereich auch Reservierungen für Server, die immer über die gleiche IPv4-Adresse erreichbar bleiben sollen. Jetzt ist meine Frage: Wie sinnig ist es, zusätzlich auf dem Server (eine VM) selbst, lokal die IPv4-Konfiguration händisch vorzunehmen, für den Fall, dass der DHCP Server mal hängt und die Reservierung dann gar nicht mehr greift? Wäre diese Schlussfolgerung überhaupt korrekt? Bzw. was würde mit den eingetragenen Reservierungen im DHCP geschehen, wenn der Dienst mal nicht läuft, der Server abschmiert etc. etc. Wenn ich jetzt mal zusätzlich zu der DHCP Reservierung auf dem DC, die IPv4-Konfiguration auf dem betreffenden Server händisch eingerichtet habe, sehe ich in den DHCP Leases, dass die betreffende Reserivierung aktuell inaktiv ist. Ich hoffe ihr könnt der Problemdarstellung folgen und freue mich auf konstruktive Antworten! :)