NilsK

Moin,

Oder kurz gesagt: hat wohl doch nicht so gut geklappt. 

Bevor du jetzt aber versuchst, den Fehler zu finden, ist es, wie Norbert sagt, wohl deutlich einfacher, die Konten neu einzurichten.

Gruß, Nils

Moin,

Soso, Hannover, wer wohnt da denn freiwillig? 

Falls es bei ADFS bleibt, kenne ich dort jedenfalls jemanden, der sich damit auskennt.

Gruß, Nils

Moin,

In der Tat, virtuelle Clients macht Microsoft unsinnig teuer und kompliziert. Der bessere Weg sind fast immer "klassische" Terminalserver. Oder eben die Cloud.

Das ist ja nicht dein Fehler. Weder dass es so teuer ist noch dass den Kunden das nicht gefällt. Du musst dich eben nur ausreichend tief damit beschäftigen, damit du da ordentlich beraten kannst.

Gruß, Nils

Moin,

@Ramme, glaubst du, dass das mit deinem Diskussionsverhalten hier was bringt?

Also, noch mal klipp und klar zu deiner Hauptfrage: Nein, du darfst Windows 10/11 nicht als Host einsetzen, um darauf VMs zu betreiben, die von mehreren Anwendern genutzt werden. Dafür hat Microsoft Server-Betriebssysteme. Das müssen wir auch nicht diskutieren, das ist das zugehörige Geschäftsmodell. Auch das Business deiner Kleinkunden wird auf Voraussetzungen beruhen.

In diesem Rahmen kann bzw. muss man als IT-Dienstleister dann seine Kunden beraten.

Gruß, Nils

Moin,

ich werd aus deinen Angaben nicht schlau. Erst ging es doch um den Essentials-Server. Und nun willst du plötzlich Windows 11 in Windows 11 virtualisieren? Was ist denn nun Sache? Bevor du dich beschwerst, dass Microsoft nciht wisse, was sie wollen, solltest du das vielleicht selbst klar kriegen. 

Ein Client-OS war bei Microsoft jedenfalls noch nie dafür gedacht, dass mehrere User gleichzeitig darauf arbeiten. Daran ändert auch Virtualisierung nichts. Aber vielleicht passen die Cloud-Angebote von Microsoft ja für dein Kundenszenario, da bekommt man auch Windows-Desktops zur Miete. Oder du stellst fest, dass die Anwender das Office 365 ja auch einfach direkt auf ihren Rechnern einsetzen können, statt sich von dort auf einen Server zu verbinden, wo die laufen. Oder, oder, oder.

Gruß, Nils

Moin,

dagegen spricht, dass ein Client-Hypervisor dafür weder gedacht noch geeignet ist. Vermutlich wäre es auch lizenzrechtlich nicht in Ordnung, aber das wäre dann auch schon sekundär. Selbst wenn es erlaubt wäre - dann bräuchtest du für den Host ja zwei Lizenzen, wenn eine (die für Essentials) doch reicht.

Wenn es wirklich eine Kleinstumgebung ist, wäre es doch vermutlich am besten, den Essentials-Server direkt auf der Physik laufen zu lassen.

Gruß, Nils

Moin,

schau dir mal robocopy in einem CMD-Fenster an.

Gruß, Nils

Moin,

Hat er schon, da gibt es den Fehler nicht.

Gruß, Nils

Moin,

Ich hatte gedacht, dass meine Antwort direkt unter der von Martin steht. 

Gruß, Nils

Moin,

Vermutlich weil da die 13 dabei ist.

Gruß, Nils

... so wie in Hotels und bei der Bahn.

Moin,

es klingt so, als erwartest du eine Art Zertifikats-Download bei Bedarf. So verstehe ich die Mimik aber nicht. Wenn man Windows lässt, wie es will, dann installiert und aktualisiert es einen großen Schwung von Zertifikaten, mit denen ein großer Schwung von Diensten funktioniert. Das ist mehr oder weniger zeitgesteuert, Updates gibt es dann, wenn welche vorliegen. Die Auswahl der so verteilten Zertifikate liegt bei Microsoft und wird sicher auf Verträgen mit deren Anbietern beruhen.

Willst du das so nicht, dann musst du eben selbst eingreifen und den Aufwand in Kauf nehmen, den das bedeutet. Da kann es dann eben vorkommen, dass du das im Einzelfall nachsteuern musst. Hier wird die Annahme sein, dass der Einzelfall bei einem konkreten System eben ein Einzelfall ist, weil man da dann ja auch nicht so viele Services braucht.

Das ist jetzt aber nur mein Verständnis ohne weitere Recherche. Um Details habe ich mich da mangels Bedarf noch nie gekümmert.

Gruß, Nils

Moin,

und falls der ausführende Account keine ausreichenden Berechtigungen hat, aber lokaler Administrator ist, dann ist der Schalter /B bei solchen Aktionen sehr hilfreich. Dessen Erläuterung ist nicht verständlich, es geht im Kern darum, dass man sich so über fehlende Berechtigungen hinwegsetzen kann.

Gruß, Nils

Moin,

ich habe bislang nicht mit Umgebungen zu tun gehabt, in denen sowas ein Thema war. Aber weiter unten in dem von Norbert empfohlenen Link steht ja ein Verfahren, in dem man die Root-Zertifikate von einem Client (der ins Internet darf und so die CTLs aktualisiert) exportiert, um sie komplett oder teilweise einem Rechner zur Verfügung zu stellen, der das nicht im Internet aktualisieren darf.  Schon probiert?

Der gravierende Nachteil von 1. scheint mir im Moment ja zu sein, dass du es nicht zum Laufen bekommst.

Gruß, Nils

Moin,

es spricht einiges dafür, dass du die Planung - dem Vorschlag von Jan @testperson folgend - in Ruhe vornimmst und dabei ein, zwei Schritte in die Zukunft denkst. Jetzt ad hoc per Subnetting ein paar Adressen im Range hinzuzufügen, schafft kurzfristig evtl. Erleichterung, sorgt aber auch für mehr Komplexität, ohne dass es für die Zukunft irgendwie flexibler oder skalierbarer wird.

Gruß, Nils

Moin,

in der OpenScape-Doku, die ich auf die Schnelle gefunden habe, wird auch eine direkte Ankopplung an Active Directory beschrieben. Wenn ihr ohnehin nur intern zugreift, wäre das vermutlich weit einfacher und weniger fehlerträchtig als die Anbindung per ADFS/SAML.

Gruß, Nils

Moin,

was Norbert sagt.

/22 wäre ebenso "krumm". Man rechnet nicht unbedingt damit, übersieht es und läuft in Fehler.

EDIT: Jetzt verstehe ich das Missverständnis, das ich erzeugt habe. Mit "ungerade" meinte ich oben nicht "nicht durch 2 teilbar", sondern "krumm" in dem Sinne, den Norbert gerade beschrieben hat. Leider kann ich den obigen Beitrag jetzt nicht mehr bearbeiten, sonst würde ich das Wort ändern.

Gruß, Nils

Moin,

an sowas denke ich dabei auch. @druckerheini, versuch mal

dir /X

Hilft das Ergebnis, die Sache aufzuklären?

Gruß, Nils

Moin,

aber sowas sollte einem der Lieferant durchaus beantworten können. Wenn nicht, dann eskalieren. Wenn dann immer noch nicht ... gibt es mehr als den einen. Sowas muss nun wirklich nicht der Kunde rausfinden, das ist ja keine technische Designfrage.

Gruß, Nils

Moin,

vor 2 Stunden schrieb daabm:

 

Nö. Ne Netzmaske ist ne Netzmaske, völlig egal wie lang sie ist. Komm gern mal nen Tag bei uns vorbei, dann zeige ich Dir unsere Netze

komm du mal nen Tag in die Netzwerke, die ich bei Kunden antreffe.

Gruß, Nils

Moin,

zu der internen PKI: ja, kann man machen - wenn man weiß, wie es geht. Die Aussage, dass die Zertifikate "nicht mit allen Browsern laufen", macht mich skeptisch, ob das der Fall ist. Und: Wenn der Punkt dann kommt, an dem man doch einen Dienst "von außen" zugänglich machen will, dann wird es lustig, wenn man nachträglich das Zertifikat und die Infrastruktur anpassen muss. Daher empfehle ich dringend, zumindest diesen Teil gleich richtig zu machen. Wir reden hier von 150 Euro oder sowas.

Gruß, Nils

Moin,

vor 17 Stunden schrieb NorbertFe:

Was hat eigentlich DHCP mit Zugangsdaten von Geräten zu tun?

oder um es deutlicher zu machen: Für diese Änderung brauchst du keine Zugangsdaten zu den Endgeräten. Bei denen musst du ja nichts umkonfigurieren.

Es ist übrigens keine gute Idee, im selben Netzerksegment für längere Zeit mit unterschiedlichen Subnetzmasken zu arbeiten. Sowas sollte man nur so lange tun, wie man zur zügigen Umstellung braucht. Routingfehler, die aus sowas resultieren, können sehr lästig sein. Das mag jetzt im konkreten Fall vielleicht nicht auftreten, aber mach dich künftig lieber schlau, bevor du solche Änderungen wirksam machst.

"Ungerade" Subnets sind in der Praxis immer schwierig. Statt jetzt mit einer 23er-Maske zu hantieren, würde ich prüfen, ob ein Umstieg auf /16 nicht sinnvoller wäre, dann vielleicht gleich mit einem 172.16.-Range (den man in solchen Fällen üblicherweise nimmt). Ich prophezeihe, dass sonst der nächste, der in dem /23-Netz was troubleshooten muss, auf die "ungerade" Maske reinfallen wird ...

Gruß, Nils

Moin,

um es kurz zu machen: Dein Dienstleister hat (wenn es zutrifft, was du hier angibst) weder von PKI noch von ADFS ausreichend Ahnung. Binde ihn da nicht ein, sondern such dir für diese Themen jemand anderen. Das ist alles kein Hexenwerk, wenn man sich auskennt - aber leider befassen sich wenige so weit damit, dass sie sich auskennen. Und dann funktioniert es nicht, nicht sicher oder nicht zuverlässig. Im Fall von ADFS wäre dann "funktioniert nicht" die wahrscheinlichste Variante, im Fall der PKI ist "nicht sicher" am häufigsten. (Ich habe auch eine Vermutung, in welche Kategorie eure vorhandene PKI fällt ...)

ADFS betreibt man produktiv nicht mit internen TLS-Zertifikaten, sondern mit "gekauften". Auch Let's Encrypt würde ich für den Zweck nicht nutzen - wenn man es hinbekäme (weiß ich nicht, hab ich dafür noch nie in Erwägung gezogen), wäre es vermutlich viel Aufwand und viel Fehlerquelle.

Gruß, Nils

Moin,

ihr redet hier wunderbar aneinander vorbei.

Der Kunde hat eine Standalone-Lizenz von Office 2019. Deshalb braucht er die Office-365-Apps nicht, sondern nur die Online-Funktion. Also reicht "Basic" aus.

OneNote ist in Office 2019 enthalten. OneDrive ist Teil des Betriebssystems. Bleibt noch Teams, aber meines Wissens erfordert der Desktop-Client keine separate Lizenz.

Also, @Dukel, sofern dir die Sicherheitsfunktionen von O365 Basic ausreichen, bist du damit passend versorgt. Schau dir vor diesem Hintergrund die verlinkte Produktseite noch mal an, die finde ich eigentlich wirklich aussagekräftig.

Gruß, Nils

Moin,

indem man recherchiert und prüft und genügend Zeit investiert, damit das nicht Wochen oder Monate dauert. Oder indem man jemanden beauftragt, dem man zutraut, dass er das mit ausreichend geringem Aufwand findet.

Wird dich jetzt aber eigentlich nicht überraschen, oder?

Gruß, Nils

Moin,

was liest du denn da Unterschiedliches? Ich finde die Produktvergleichsseite (siehe Hinweis von winmadness) ziemlich eindeutig. Was ist dir denn da konkret unklar?

Gruß, Nils