Alle Aktivitäten

Hi, wenn du das "damals" kompliziert/mühsam fandest mit der Netzwerkkonfiguration unter Hyper-V, dann wird sich da nichts* geändert haben. Was hattest du denn für Probleme? Mit iSCSI habe ich nicht ganz so viel zu tun. Ist aber in der Tat ein wenig meh. Bei meinem alten AG haben wir unsere Hosting Infrastruktur von vSphere (Enterprise Plus) zu Hyper-V 2016 / 2019 (ohne SCVMM) migriert bzw. diese nach und nach eben abgelöst. Vermisst haben wir da nicht wirklich was (nachdem wir manches dann einfach per PowerShell "nachgebaut" haben). *) Mittlerweile gibt es bspw. Network ATC. Ich vermute aber, dass du an der Stelle (Host Netzwerk) eher keine Probleme hattest. Am Ende des Tages: Es kommt drauf an. Generell (von mir) aber eher ein "Ja". ;) Gruß Jan

ja - die Zeile funktiniert ja auch in der Powershell, wirft nur diese blöde Fehlermeldung

Moin @newbi2009 Verwende bei mehreren und/oder längeren Codeblöcken oder Kommandoausgaben bitte die Formatierungshilfe im Editor, die da ---> </> Und die pastell-bunte Farbgebung macht das Lesen auch nicht einfacher. VG Damian

Funktioniert die Zeile in der CMD statt der Powershell?

Salut zusammen, Zugegeben, mit mit HyperV habe ich mich in den letzten Jahren nicht allzu gross beschäftigt weil vSphere A so einfach war und B mir die Netzwerkonfig von HyperV in den Anfängen viel zu mühsam war und ich öfter eine Branchenlösung auf UNIX-basis hatte. Dann war da noch die einfache Einbindung von Storage aller Art. Unter Windows fand ich iSCSI immer mühsam, NFS sowieso. Netzwerkkonfig heute einfacher? Storage-Einbindung mit iSCSI einfacher geworden? Footprint von Windows bleibt natürlich grässlich hoch für reine Virtualisierung... Gehen einige schon wieder zu physisch zurück aufgrund der Vm zu Host Breaks in Hyper V und vSphere? Einen Vorzug bei Hyper V sehe ich dennoch, Storage Spaces als lokale Datengrundlage. Proxmox kommt für mich nicht in Frage. Lernkurve ist mir da aktuell zu flach. Wenig Ahnung von Linux etc. Alternative bleibt nach wie vor vSphere, aber irgendwie traue ich Broadcom nicht so ganz, dass Sie Kleinkunden nach wie vor bedienen. Aktuell sind die Kosten ja noch erträglich, aber ob das so bleibt? Verträge sind ja nur auf Jahresbasis möglich für Kleinkunden. Auch Horizon mit Omnissa scheint teuer geworden zu sein. Zusammen mit Teradici bzw. HPE-Updates wird die Wartung zu teuer. War so einfach alles. Wurde doch genug Geld verdient. *hmpf* Grüsse und Danke

Hallo zusammen, wir betreiben einen/mehrere LDAP Server (kein Active Directory). Bisher habe ich für Powershell-basierende Abfragen immer die von Lotus Notes mitgeliferten ComandLine-Tools (hier ldapsearch.exe) benutzt, was ganz gut funktioniert hat. Leider wird uns wohl bald der Notes client und somit auch die da mit kommenden LDAP CL-Tools deinstalliert, sodass ich mich nach einer anderen Lösung umschauen musste... Hier bin ich auf "open LDAP for Windows" gestossen. Software ist nun installiert und ich kann auf die cl-Tools zugreifen. Jetzt zu meinem zwei Problem: Eins vorweg: Egal, ob ich den Bind mit "-x" oder ohne durchführe, ist das Ergebnis das Gleiche & "C:\OpenLDAP\ClientTools\ldapsearch.exe" -H ldap://XXXXX.home.local:2390 -D $username -w $script:pw -b $script:DN -s base "objectClass=*" userCertificate > $safepath oder Bind mit „-x“ – kein Unterschied: & "C:\OpenLDAP\ClientTools\ldapsearch.exe" -x -H ldap://XXXXX.home.local:2390 -D $username -w $script:pw -b $script:DN -s base "objectClass=*" userCertificate > $safepath ich bekomme IMMER folgende Fehlermeldung im Programmfenster (Powershell ISE) angezeigt (auch ein Umleiten mit 2>&1 bringt nicht mehr Fehlermeldungs-Text in der Ausgabe-Datei) ldapsearch.exe : ldap_bind: Success (0) In C:\Users\xxxxx\Documents\Powershell-Scripte\Benutzer von PROD in TEST\Benutzer_von_PROD_nach_TEST.ps1:498 Zeichen:18 + ... & "C:\OpenLDAP\ClientTools\ldapsearch.exe" -H ldap://xxxx ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (ldap_bind: Success (0):String) [], RemoteException + FullyQualifiedErrorId : NativeCommandError additional info: Bind succeeded. Ich verstehe nicht, was hier "angemeckert" wird. Es steht explizit in der Meldung, dass der Bind funktioniert hat, und auch die Ausgabe funktioniert korrekt Dies ist der Text der Ausgabedatei) --------------------------------------- # extended LDIF # # LDAPv3 # base < cn=DoeJohn,ou=Extern,ou=Three,o=Two,c=One > with scope baseObject # filter: objectClass=* # requesting: userCertificate # # DoeJohn, Extern, Three, Two, One dn: cn=DoeJohn,ou=Extern,ou=Three,o=Two,c=One userCertificate;binary:: MIIHaDCCBVCgAwIBAgIDSHYqMA0GCSqGSIb3DQEBCwUAMFwxCzAJB gNVBAYTAkRFMRkwFwYDVQQKExBQS0ktMS1WZXJ3YWx0dW5nMRMwEQYDVQQLEwpCdW5kZXN3ZWhyMR 0wGwYDVQQDExRCdyBWLVBLSSBDQSAyMDIyIC0gMjAeFw0yMzAyMTUxMDEwMDlaFw0yODAyMTUxMDE wMDlaMFgxCzAJBgNVBAYTAkRFMQ0wCwYDVQQKEwRidW5kMQ0wCwYDVQQLEwRibXZnMRAwDgYDVQQL EwdwZXJzbWlsMRkwFwYDVQQDExBHZXV0aW5nIFRob3JzdGVuMIICIjANBgkqhkiG9w0BAQEFAAOCA qvkJ++i7MSkz6FguCrewZ+d3QiogHFh5QI77zQklognb+6GhGyH9Iv0amzRLCVWyWgxPMw0OUs92K 7H4thYcNpl/l8QB5rf0v/R23vSEOgMqypkORkNGRZ2hf36kWuJPil60657xAbfoArGXdiF+Hs+tv8 zPkdwrTtg9flgDVVeceRfGDzuaUf0NYU2ee7xBVO2oJyd1mgBDdZfMihRTrYM70+ewmqDYp4wiuCb wsh++XX9hts9BI+ldO2Lm4FMmoOjQjg5/SrdWh6gLEeLeZDmxSXtl8WafGlLpLDRNK3zYiaR+soW4 EEWI6kz0ZhqRAs0AQlQcD5qqCTmWvylvtjPyRnW1NA4fpc7RIi02Zcj2v7pdsd+lnwZ8sr9UblQFi WqKSFk/hvvgdzCVwA== # search result search: 2 result: 0 Success text: Search succeeded. Found 1 Entries (0 Aliases), 1 Attributes, 1 Values. (C hainedResult=no) # numResponses: 2 # numEntries: 1 ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- Was ich aber noch viel merkwürdiger finde, ist der Fakt, dass ich bei JEDEM 2. VERSUCH, das Skript laufen zu lassen, den Fehler bekomme, dass das Bind NICHT funktioniert hat: ldapsearch.exe : ldap_bind: Success (0) In C:\Users\xxxxx\Documents\Powershell-Scripte\Benutzer von PROD in TEST\Benutzer_von_PROD_nach_TEST.ps1:498 Zeichen:18 + ... & "C:\OpenLDAP\ClientTools\ldapsearch.exe" -x -H ldap://x ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (ldap_bind: Success (0):String) [], RemoteException + FullyQualifiedErrorId : NativeCommandError additional info: Bind succeeded. ldap_result: Can't contact LDAP server (-1) Dann ist die Ausgabedatei auch "quasi" leer: # extended LDIF # # LDAPv3 # base < cn=DoeJohn,ou=Extern,ou=Three,o=Two,c=One > with scope baseObject # filter: objectClass=* # requesting: userCertificate # # numResponses: 0 Kann mich hier irgend jemand erleuchten, wo/was genau mein Fehler ist? Vielen Dank Gruß Holger

Wie migrieren ja in ein neues RZ. Da will man hier nichts mehr investieren.

Haben sie eigentlich schon. Die Frage ist nur, welche Kunden Ich habe es via Born erfahren. Gebe Dir recht, die Kommunikation ist ein Desaster das seinesgleichen sucht. Die denken wohl, jeder meldet sich jeden Tag mal in Ihrem Support-Terminal an und sieht die fette Überschrift. Angeblich gibts die Sicherheitsupdates nach wie vor umsonst. Wie das laufen soll ohne aktuelles Abo, keine Ahnung. Da vSphere neu Abo-basiert ist und Du keine Lizenz kaufst, dürfte das so oder so hinfällig werden. Ob dann alles einfach stoppt wenn das Abo abläuft, weiss ich nicht. Bezüglich Deinem RZ. vSphere 7 gibts übrigens nur noch bis Oktober Patches für. Wurde wohl verlängert von April bis September/Oktober.

Die Inhalte in Profile$ Schon, in der User-Registry, aber Du schriebst ja, dass es die Erstanmeldung dieses Users an diesem Client ist. Da er kein Roaming-Profil hat (und selbst wenn er eins hätte, liegt der Verdacht nahe, dass es mit DC01 vom Netz gegangen ist) ist es aber unwahrscheinlich. Mach einen GPRESULT und schau, ob Dich was anspringt. Vielleicht ist es etwas, was per Computer, aber im User-Kontext gesetzt wird? Registry-GPP, Login-Skript, Scheduled Task, sowas..

Die Freigaben, auch in Profile$ im DC01 wurden alle nach und nach weggenommen wo der Server noch am Netz war. Der DC01 ist seit ein paar Wochen aus, könnte theoretisch wieder ans Netz genommen werden. Die Frage ist, ob an dieser Stelle noch was zu befürchten ist? Was soll man denn auf dem DC01 noch sehen?

Moin, Login-Script? Ist der aus, lässt sich wieder online bringen? Ein demoteter DC ist zunächst normaler Member-Server

Aha ;) gibts denn die Freigabe auf dem dc01 noch? Falls ja wäre es ja an sich schon merkwürdig, dass der Fehler auftritt, wenn eigentlich noch alles da ist.

Danke für euere Antworten. Den alten DC habe ich natürlich noch, er ist gedemountet. ich habe den DC „geerbt“ und eine Doku dazu gibt es leider nicht. in der Folder Redirection / GPO steht alles auf „nicht konfiguriert“ daher bin ich umso mehr verwundert, das ich nicht sehe wo es her kommt. im AD ist unter Profil der Pfad sauber über den DC02 eingetragen. Die Fehlermeldung zeigt aber nur auf den Desktop, sonst kommt keine Fehlermeldung bzgl. des Profils. Können solche Einstellungen noch wo anders gesetzt sein? Danke!

Moin an Board, auf geht es in den Tag - ich koche Kaffee Allen einen ruhigen Dienstag, bleibt gesund! Hier derzeit klar bei 8°C, es wird ein mix aus Sonne und Wolken bis etwa 21°C

Anhand der Fehlermeldung würde ich sagen, es kann nur Folder Redirection sein. Und diese kann eigentlich nur aus einer Group Policy kommen. Ich hoffe, Du hast den alten DC noch nicht entsorgt, denn demnach sind da echte Benutzerdaten drauf....

Hi, Option 1: Im AD User Objekt ist ein Profilpfad konfiguriert Option 2: Diese Einstellung ist konfiguriert: GPS: Set roaming profile path for all users logging onto this computer Option 3: Folder Redirection ist aktiviert: Folder Redirection using Group Policy on Windows Server | Microsoft Learn Gruß Jan

Hallo zusammen, habe den Domaincontroller von DC01 (alt) auf DC02 (neu) gewechselt. Jetzt habe ich den DC02 in GPO‘s, AD etc. abgesucht, und finde leider den Fehler nicht. Wenn ich mich mit einem Benutzerprofil an einem neuen Client anmelden möchte, erscheint folgender Fehler: Auf |\dc01\Profile$|*Test\Desktop konnte nicht zugegriffen werden. Das Benutzerprofil verweist immer noch unter Appdata auf DC01 obwohl der DC02 verwendet werden soll. ist jemandem der Fehler bekannt? bin mit meinem Latein ziemlich am Ende, vor allem weiß ich nicht woher er sich die Daten vom alten DC ziehen möchte. ich bin um jede Hilfe dankbar! Danke und Viele Grüße Patrick

Hi, die Frage ist, ob es - sofern ich das richtig lese - sinnvoll ist, so eine GPO auf Domain Ebene zu verlinken. Wo liegen denn deine Computer Objekte und wäre es hier evtl. besser, die VMs in eine eigene OU zu packen? Bspw. eine OU "Meine Clients" und darunter dann eine OU "virtuelle Clients" und evtl. "Notebooks" sowie "Desktops" o.ä. Dann kannst du die Policies für alle deine Computer an "Meine Clients" linken und die restlichen GPOs dann halt an "virtuelle Clients", "Desktops", etc... Gruß Jan

Moin, GPRESULT ist Dein Freund. Es kann für das Verhalten einige Gründe geben: Reihenfolge ist falsch, so dass die Standard-GPO immer gewinnt Die virtuellen Computer wurden nicht rebootet, nachdem sie zu der Gruppe hinzugefügt wurden, und es ist nicht genug Zeit (10h) vergangen Die andere GPO ist erzwungen oder noch irgendetwas. Wie gesagt, GPRESULT (auf dem Hyper-V-Client) ist Dein Freund.

Das ist doch das gängige Problem mit dem NlaSvc (Network Location Awareness) als Schuldigen. Dürfte bei Server 2025 nicht anders sein. Ein Kaltstart statt reboot löst manchmal das Problem. am zuverlässigsten ist das aktivieren/deaktivieren des Netzadapters oder jede sonstige Aktualisierung welche den NlaSvc triggert. Dazu gehört das Beispiel ein Protokoll deaktivieren oder aktivieren was schon genannt wurde. Das abrufen einer IP bei DHCP gehört bei einer dynamischen IP üblicherweise auch dazu. Auch wenn die IP wieder identisch ist weil der Lease noch gültig ist. Das geht mit herkömmlich Userrights. --> Hilfreich bei Clients Schöner wäre allerdings, wenn jemand nen Trigger bei MS ausfindig machen könnte, der auch mit User-Rechten manuell anstossbar ist und auch bei fixen IP's hilft. Dann wäre das ganze gegessen. Ein (sinnvolle) Doku gibts ja nicht. Allenfals gäbe es auch einen WMI-Befehl. Sonstige Hintergrundinfos Die Ereichbarkeit der Adressen für das Active und Passive-Probing sind quasi Voraussetzung. Hier würde ich aber mittlerweile nichts am Standard mehr ändern ausser eben allenfalls interne Server anzugeben für den Connection Test. Alle anderen gängigen Tipps habe ich mittlerweile verworfen und alles auf Standard gelassen weils eh nicht langfristig hilft, Build-abhängig oder etwas krass ist. NlaSvc verzögern, NlaSvc restart erzwingen (möglich mit Process-Kill oder TI-Rights), DNS-Suffix vorgeben, NlaSvc von anderen Diensten abhängig machen um Start aktiv zu verzögern, Netzadapteränderungen, DNS-Cache usw. usf. In der Vergangenheit habe ich mich schon mehrere male recht lange damit beschäftigt. Konnte es damals so eingrenzen, dass nun entweder neu erstellte Netzwerk-Profile zusätzlich erstellt wurden (rauslöschen half mind. für 1 Reboot, manchmal hälts dann manchmal nicht) oder die Netzwerkkarte in der Registry nicht als erste in der Auflistung erschien. Vor allem mussten alte Einträge alle raus weil auch Überreste zählten die nicht mehr Gerätemanager erschienen, auch nicht bei den ausgeblendeten. Etwas doof weil GUID's mit von der Party sind. Das zuverlässig zu fixen war allerdings nur äusserst mühsam möglich und vor allem nicht langzeitstabil (OS, Treiberudates etc.) Habe ich aufgegeben. Reine Bastellösung. Das heftigste Problem hatte ich mal auf einem Client mit aktivierten Management-Funktionen von Intel, da war nichtmal der DHCP-Abruf beim Reboot erfolgreich ohne den Adapter zu deaktivieren/aktivieren. Bekam eine generische. Selbst eine fixe IP wurde durch eine generische ersetzt. Nach dem deaktivieren und löschen von all dem Zeugs war dann NlaSvc "geflickt" und DHCP wieder funktionstüchtig. Ganz schräg.

Moin Ich habe eine AD die soweit auch durchkonfiguriert ist. Nun gibt es zwei varianten von Clients. Die echten Desktops bzw. Notebooks. sowie auch einige die auf Hyper-V laufen. Ich hätte gerne eine GPO NUR für die Virtuellen Clients die das herunterfahren verhindert. Die Einstellung ist ja auch klar. Ich kriege es mit der Verteilung nicht hin. Mein Ansatz bislang: Unter AD Benutzer und Computer habe ich eine Sicherheitsgruppe "Virtuelle Clients" deren Mitglieder sind die entsprechenden Clients. In der GPO Verwaltung habe ich unterhalb der Default Domain Policy eine weitere "Herunterfahren GPO" Gruppenrichtlinienobjekt erstellt. Dort dann in der Sicherheitsfilterung die Sicherheitsgruppe "Virtuelle Clients" hinzugefügt. doch das greift leider nicht Ist mein Ansatz überhaupt so OK.? Habt Ihr andere Vorschläge. Vielen dank schon mal vorab Tom

Etwas OT: Ich komme heute aus dem Urlaub zurück und muss feststellen, dass Broadcom Einen an der Klatsche hat. Offenbar will man Updates nur noch an zahlende Kunden rausgeben. Der LiveCycle-Manager stellt einfach den Betrieb ein und lädt keine Updates mehr herunter. Nach eine Analyse bin ich darüber gestolpert: https://knowledge.broadcom.com/external/article/390121 Nicht das Broadcom irgendwie vorher informiert hätte...

Moin an Board, so staren wir in eine neue, spannende und kurze Woche - ich koche Kaffee Schon wieder die letzte im April, wie die Zeit vergeht... Allen einen guten Montag, bleigt gesund! Hier sonnig bei 12°C, es wird ein schöner Tag bis etwa 20°C

Moin Jan. Das ungepasste Beispiel von Microsoft auf einem (virtuellen) Testrechner, der nicht in einer Domäne ist, angewendet, funktioniert einwandfrei. Wende ich dasselbe Beispiel auf demselben Rechner, nachdem dieser in einer Domäne aufgenommen wurde, kommt die o.g. Fehlermeldung. Irgendwie muss es darin liegen, dass der Rechner jetzt Domänenmitglied ist.

Hi, den Artikel kenne ich. Sowas kann man auch mal gut Abends nebenbei lesen. 👍 VG, Jan