NilsK

Moin, Für verschachtelte Schleifen brauchst du Delayed Expansion. Tu dir einen Gefallen und mach sowas nicht per Batch. Gruß, Nils

Moin, da wäre jetzt die Frage, auf welchen der Vorschläge in dem Thread du dich beziehst ... aber kurz gesagt: Nein, ich habe mangels konkreter Erfahrung mit diesem Szenario keinen anderen Vorschlag. Gruß, Nils

Moin, da VMs immer über den Host und nie einzeln lizenziert werden, sind auf einem mit Datacenter lizenzierten Host alle Windows-Server-VMs mitlizenziert. In den VMs kann dann Datacenter laufen. Das hat gegenüber Standard auch keine Nachteile. Also: Aufgabe erledigt, weil unnötig. Gruß, Nils

Moin, ich sehe viel Code und wenig Frage ... könntest du das Problem noch mal zusammenfassen? Abgesehen von der seltsamen Vergangenheitsform "Splitted" braucht es hier keine Tabellendefinition, weil die Anweisung SELECT INTO immer eine neue Tabelle erzeugt, deren Definition sich aus der Definition der Ausgangsdaten ergibt. https://docs.microsoft.com/de-de/sql/t-sql/queries/select-into-clause-transact-sql?view=sql-server-ver15 Gruß, Nils

Moin, was für eine Lizenz ist denn dem Host zugewiesen? Wenn das eine Datacenter-Lizenz ist, würde ich an der VM einfach gar nichts ändern. Gruß, Nils

Moin, dann solltest du den Hersteller der Applikation fragen. Die verhält sich offenkundig komisch. Wenn das nicht geht, lege die Dateien da hin, wo es geht. Gruß, Nils

Moin, kannst du deine Frage bitte noch mal so formulieren, dass man sie versteht? Gruß, Nils

Moin, theoretisch wäre dein Konstrukt möglich. Ob es Sinn ergibt, kann man auf dieser Basis nicht beurteilen. Der "kostenlose" Hyper-V Server umfasst ja keine VM-Lizenzen. Diese könntest du (in "beliebiger" Zahl auf dem Host) über die vorhandene Datacenter-Lizenz abdecken, welche du dem Host "logisch" zuweist. Die VMs dürfen dann "maximal" Server 2012 R2 ausführen. Lizenzrechtlich sollte das passen. Gruß, Nils

Moin, ist vielleicht die Anwendung auf dem Client noch aktiv, wenn ihr sie das zweite Mal startet? Sodass sie dann zweimal läuft? Es gibt manchmal Applikationen, die sowas nicht mögen. Gruß, Nils

Moin, FOR-Schleifen sind immer eine Sache für sich. Da muss man enorm viel rumprobieren, bis man mal die richtige Variante hat. Um hier nicht gleich mit der Lern-mal-PowerShell-Keule zu arbeiten, werfe ich folgendes Verfahren in den Ring, das ich bei "statischen Schleifen" gern einsetze: [Excel: Admins unbekannter Liebling | faq-o-matic.net] https://www.faq-o-matic.net/2008/01/19/excel-admins-unbekannter-liebling/ Ansonsten haben die Kollegen schon recht - gerade für sowas ist PowerShell nach etwas Einarbeitung viel einfacher und flexibler. Gruß, Nils

Moin, schau mal hier: [Windows-PKI: Computerzertifikat manuell anfordern | faq-o-matic.net] https://www.faq-o-matic.net/2017/09/13/windows-pki-computerzertifikat-manuell-anfordern/ Gruß, Nils

Moin, ... und das lässt sich auch automatisieren, am einfachsten, indem man eine Weile ein Batch im Logon- oder Startupskript aufruft, das das Verzeichnis C:\Users per dir irgendwohin ausgibt. Zum Beispiel so: dir c:\Users > E:\Daten\%computername%-profile.txt Und die Datei kopiert dann der nächste Batch-Befehl auf ein zentrales Share. Vorsicht, wenn es einen Betriebsrat gibt, sollte man den davon in Kenntnis setzen. Das kann als Überwachungsmaßnahme gewertet werden. Gruß, Nils

Moin, so war das nicht gemeint. Dass du das nicht gebaut hast, hatte ich verstanden. Mir geht es um "denjenigen", der das gemacht hat. Hyper-V hat halt auf einem Server, der noch irgendwas anderes macht, nichts verloren. Dass das Netzwerk erst wieder "funktioniert", wenn man Hyper-V ganz deinstalliert, liegt an der Art, wie Hyper-V aufgebaut ist. Das führt hier zu weit; wer es wissen will: [Hyper-V und Netzwerke | faq-o-matic.net] https://www.faq-o-matic.net/2012/04/23/hyper-v-und-netzwerke/ Trifft im Wesentlichen noch zu. Gruß, Nils

Moin, ich finde es schade, dass ein solch halbseidener Tipp in diesem Thread jetzt als "Lösungsansatz" dasteht. Ich distanziere mich davon und weise noch einmal ausdrücklich darauf hin, dass der hier diskutierte Umgang mit Zertifikaten überhaupt nicht in Ordnung ist. Die Gründe dafür habe ich oben genannt. Gruß, Nils

Moin, wenn sie Zugriff auf den Private Key haben, hindert sie nichts daran, diesen zu exportieren. Ich verstehe ja, dass Zertifikate und das ganze Drumrum nicht einfach zu kapieren sind. Aber müssen auch Profis (also Leute, die Geld dafür bekommen) deshalb immer wieder so grundlegende Fehler machen? Kann man dann nicht lieber auf Zertifikate verzichten, damit man sich wenigstens nicht in Sicherheit wiegt? Gruß, Nils

Moin, und, ist dem Schweizer Zoll schon mal jemand aufs Dach gestiegen? Wenn das tatsächlich so vorgesehen ist und nicht nur eine Bequemlichkeits- oder Kostensparlösung, dann ist das ein Skandal ersten Ranges. Gruß, Nils

Moin, wie - auf dem SBS, der jetzt als VM lief, war Hyper-V eingerichtet? Auf die Idee wäre nicht gekommen. Dass das nicht funktioniert, liegt auf der Hand. Dann wird das System aber vorher auch schon gelaufen sein wie ein Sack Nüsse. Auf Ideen kommen die Leute ... Gruß, Nils

Moin, ich halte dieses Anliegen für nicht supportfähig. Ein Userzertifikat soll die Identität eines (eines!) Users bestätigen. Und ein privater Schlüssel hat per definitionem geheim zu bleiben. Ein bestimmtes Userzertifikat mit privatem Schlüssel bei mehreren Usern einzusetzen, widerspricht daher fundamental den Grundsätzen zertifikatsbasierter Authentifizierung bzw. Verschlüsselung. Gruß, Nils

Moin, du müsstest bitte näher beschreiben, was du erreichen willst. Gruß, Nils

Moin, Da scheinst du ein paar Dinge durcheinander zu bringen. Gruß, Nils

Moin, Dein SBS hat jetzt eine virtuelle Netzwerkkarte. Die hat aber keine Konfiguration. Die ehemalige Konfiguration hängt noch an der deaktivierten alten Karte im SBS. Gruß, Nils

Moin, ich verstehe nicht, warum ihr zehn Stunden Puffer einbauen wollt. Kann man machen, wenn es einen Grund gibt, aber ich wüsste keinen. Hier ist ein simples Toolset, um die Replikationslatenz zu testen: [ADRepCheckLatency: AD-Replikationslatenz messen | faq-o-matic.net] https://www.faq-o-matic.net/2009/09/30/adrepchecklatency-ad-replikationslatenz-messen/ Und hier ein anderes: [(2010-10-24) Testing Active Directory Replication Latency/Convergence Through PowerShell « Jorge's Quest For Knowledge!] https://jorgequestforknowledge.wordpress.com/2010/10/24/testing-active-directory-replication-latency-convergence-through-powershell/ Gruß, Nils

Moin, das ist eine konzeptionelle Frage über eure Betriebsprozesse. Dazu kann ich aus der Ferne wenig sagen. Man könnte sich fragen, ob die Ablage für die Installationsdaten überhaupt so kritisch ist, dass man den Zugriff einschränken muss. Falls nein, könnte man in solchen Fällen die nötigen Daten vorher auf den Client herunterladen und dann die Installation mit "Ausführen als" machen. Es ist immer besser, Installationen von lokalen Dateien aus durchzuführen als über das Netzwerk. Man könnte auch einmal ein CMD-Fenster mit "Ausführen als" oder "Als Administrator ausführen" öffnen und von dort dann den Kopierprozess und die Installation ausführen. Dann kann man die Freigabe passend berechtigen. Man kann sich auch entscheiden, dass solche Zwischendurch-Aktionen Käse sind und man ein koordiniertes und funktionierendes Verfahren zur Softwareinstallation einsetzt. Gruß, Nils

Moin, habt ihr denn mehrere Sites, sodass ihr überhaupt warten müsstet? Wenn ja, wie lang sind dort die konfigurierten Intervalle? Ein zu langer Abstand zwischen den Kennwortwechseln ist im Zweifel kontraproduktiv. Falls man so einen Wechsel durchführt, um mögliche Golden-Ticket-Angriffe zu beenden, möchte man den effektiven Kennwortwechsel (also beide Einzelschritte) so schnell wie möglich durch haben. Sonst könnte es passieren, dass der Angreifer das bemerkt (was er durch Abfrage des AD sehr einfach könnte) und nach dem ersten Kennwortwechsel sich ein neues Golden Ticket erzeugt. Das könnte er, weil er den Hash des Vorgängerkennworts noch hätte. Den zweiten Kennwortwechsel würde dieses Golden Ticket dann überstehen, weil es zu den Eigenheiten der ganzen Mechanik gehört, dass sowohl das aktuelle Kennwort als auch dessen direkter Vorgänger akzeptiert werden. Man muss also aufpassen, dass man sich nicht durch scheinbare Vorsichtsmaßnahmen ein Fußpilzproblem erzeugt. Genau deshalb macht das Skript von Jorge recht viel Aufwand und versucht die tatsächliche Replikationslatenz zu messen. Gruß, Nils

Moin, eigentlich macht man sowas ja auch nicht. Kann auch sein, dass im Fall von SMB-Verbindungen die Rückfrage nur kommt, wenn es Berechtigungseinträge für Konten aus anderen Sicherheitsbereichen gibt, also etwa für lokale Konten oder solche aus einer anderen Domäne. Da es sich hier anscheinend immer um dieselbe Domäne handelt, fragt Windows (anscheinend) nicht. Ergäbe Sinn, habe ich nicht mehr im Kopf. Wie gesagt, sowas macht man eigentlich nicht, daher hab ich das auch seit vielen Jahren nicht mehr so machen müssen. Da das alles aber auch ein wenig sinnvolles Herangehen ist, sollte man die Vorgehensweise überdenken. Einzelne Verbindungen mit anderen Useraccounts herzustellen, ist immer eine Krücke mit zahlreichen Nachteilen. Gruß, Nils