NilsK

Moin, na, diese Information fehlt in "dem Buch", daher musste ich das Web bemühen. Dort ist die Information allerdings auch leicht auffindbar - nur mal so als Tipp für das nächste Mal ... Bis Windows Server 2016 lag das Limit tatsächlich bei 8 VM-Bus-Netzwerkkarten (also die, die man will). Seit 2019 liegt es bei 64. Das legt die Vermutung nahe, dass deine VM von einem älteren Host migriert und dann nicht aktualisiert wurde. [Plan for Hyper-V scalability in Windows Server | Microsoft Learn] https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/plan/plan-hyper-v-scalability-in-windows-server Wozu braucht man so viele NICs in einer VM? Gruß, Nils

Moin, wenn du sowas häufiger machen musst (danach hört es sich zumindest an), dann solltest du anhand deiner Datenbank prüfen, wie die Escape-Syntax ist. Sehr wahrscheinlich ist sie so, wie Jan zitiert hat. Wenn du das weißt, musst du nicht mehr rätseln und auch nicht auf Exporte ausweichen. Sobald man Daten einer Produktionsdatenbank manipuliert, ist ein vorheriger Test ohnehin unumgänglich, also solltest du schon im Eigeninteresse für eine Testumgebung sorgen. Eine VM kann dabei hilfreich sein, es wird aber sicher auch ohne gehen. Gruß, Nils

Moin, Kein Problem. Wir sind gar nicht so. Gruß, Nils

Moin, In der detaillierten Liste wird der Explorer als Prozess auch dann angezeigt, wenn kein separates Explorer-Fenster offen ist. Dort kann man den Prozess dann beenden. Das ist das, was Ingo meinte. Gruß, Nils

Moin, Viermal reboot tut gut. Gruß, Nils

Moin, Jupp. Und zu deiner Frage nach Computer oder Benutzer: fast alle Einstellungen gibt es nur an einer Stelle, also ist das gar keine Frage. Gruß, Nils

Moin, Dagegen spricht, dass man in einer Produktion nicht testet. Wenn man wissen will, ob es so funktioniert, wie man es sich denkt, dann macht man das natürlich im Testlabor. Das kann man sich zur Not auf einem einzelnen PC mit genug RAM einrichten. Darunter hinaus habt ihr beide natürlich Recht, man sollte und kann nur selbst prüfen, ob es passt. Gruß, Nils

Moin, Das wird eine KI sein. Gruß, Nils

Moin, in diesem Fall ist die Applikation, die der Anwender nutzt, schlecht programmiert oder schlecht konfiguriert, sodass sie Administratorrechte benötigt. Das wird man "von außen" nicht ändern können, sondern man muss die Programmierung oder die Konfiguration der Software ändern. Wenn du die Sicherheitsmechanismen abschaltest oder den Benutzer zum Administrator machst, dann löst du das Problem nicht, sondern du machst das ganze System unsicher. Gruß, Nils

Moin, ich interpretiere den Artikel anders. Nach meinem Verständnis wird dort beschrieben, wie man den IIS auf Port 80 wieder erreichbar macht, nachdem man das Windows Admin Center entfernt hat. Warum hast du das WAC denn auf Port 443 installiert, statt den vordefinierten Port zu verwenden? Gruß, Nils

Moin, Das hängt von der konkreten Lizenz ab. Zumindest früher war das Downgrade-Recht nicht in allen Lizenztypen enthalten, nur in den meisten. Den passenden Key dazu musst du allerdings haben, z.B von einer anderen vorhandenen Lizenz. Gruß, Nils

Moin, hm, okay. Wenn du einen Usecase hast, dann sollte es ja passen. Wie du in dem anderen Thread ja lesen konntest, ist der Export nicht für einen Dauereinsatz gedacht, daher musst du ein wenig drumrumbasteln. Zudem, auch dies im anderen Thread diskutiert, bilden die Exports keine vollwertige Recovery-Basis. Zum "ernsthaften" Wiederherstellen dürften AD-Recovery-Methoden besser geeignet sein. Dazu zählt auch das Tombstone Recocery. Gruß, Nils

Moin, wie du hier siehst, gibt es keinen Schalter, um das Überschreiben anzufordern: https://learn.microsoft.com/en-us/powershell/module/dnsserver/export-dnsserverzone?view=windowsserver2022-ps Wenn du das brauchst, müsstest du die existierende Datei also zuerst löschen. Warum möchtest du die Einträge denn mehrfach exportieren? Das ist nicht für Backupzwecke gedacht. Die AD-integrierten DNS-Informationen sind Teil des AD und werden mit diesem gesichert. Gruß, Nils

Moin, Machst du bitte einen neuen Thread für deine Frage auf, statt einen bestehenden zu kapern? Danke. Gruß, Nils

Moin, Das ist korrekt, ändert am Prinzip aber nichts, sondern reduziert nur die Anzahl der Stellen, an denen man nachsehen kann. Gruß, Nils

Moin, Ach, okay, dann war es so. Also haben sie erst versucht, es durch die Verzögerung um einen Monat zu lösen. Gruß, Nils

Moin, Das hätte ich jetzt in allen Umgebungen vermutet, aber nicht in eurer ... Gruß, Nils

Moin, Okay, und beim nächsten Mal lässt du dir bitte erst das Problem erklären, bevor du es in ein Forum eskalierst, okay? Gruß, Nils

Moin, Ein Windows 2003 (Version von Windows 10 aus dem März 2020) hatte Microsoft doch dann rechtzeitig durch Ändern des Namensschemas vermieden, oder? Gruß, Nils

Moin, bei dem, was bislang an Informationen gekommen ist, würde ich aber zunächst sowas wie Online-Backups, große Downloads, viele parallele Videokonferenzen usw. in Betracht ziehen. Wenn wir das sicher ausschließen können, können wir anfangen, die Werkzeugkästen rauszuholen. Gruß, Nils

Moin, ein SQL-Login wird durch SQL Server gesperrt, wenn zu häufig versucht wurde, sich mit falschem Kennwort anzumelden. Es gibt keine andere Ursache dafür. Wie viele Versuche das sind, kannst du in der zugehörigen Policy nachsehen. Das Verhalten, das du beschreibst, passt dazu: Du hast eine Session mit dem Account offen, der dann später gesperrt wird. Daher funktioniert deine Session nicht mehr, weswegen du keine Daten - wie z.B. die Serververbindung - mehr abrufen kannst. Wo da bei dir falsche Anmeldedaten hinterlegt sind, müsstest du selbst prüfen. Vielleicht ist es ja auch gar nicht der Wartungsplan selbst, sondern eine andere Stelle, und du siehst des nur zufällig, wenn du im SSMS arbeitest. Gruß, Nils

Moin, das kann alles sein, und am ehesten findest du die Ursache, wenn du prüfst, was in der Zeit noch so auf der Leitung passiert. Gruß, Nils

Moin, ja und? Was sollen wir dazu jetzt sagen? Gruß, Nils

Moin, danke, Olaf, für den Hinweis. So weit konnte ich da jetzt nicht prüfend reingehen, da ist es immer gut, wenn man ein technisches Gewissen wie dich neben sich sitzen hat. Gruß, Ni"ein Senior Consultant muss nur so ungefähr Ahnung haben"ls

Moin, du findest hier die Doku des cmdlets. Sowas erhältst du schnell über Suchmaschinen. https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adobject?view=windowsserver2022-ps Ich habe keine AD-Testumgebung im Zugriff, daher kann ich es nicht ausprobieren, aber vom Prinzip her: Get-ADObject -Filter {(objectClass -eq "contact")} -Searchbase "OU=Consulting,OU=Kontakte,DC=cvn,DC=local" -Properties name,telephoneNumber Gruß, Nils