NilsK

Moin, ob diese Kunden tatsächlich nicht "in die Cloud" wechseln können, ist ja nicht ausgemacht. Die meisten, die das befürchten oder angeben, könnten rechtlich betrachtet sehr wohl. Von denen, die nicht in Microsofts Cloud dürfen, können einige in "deutsche" Clouds. Und die anderen müssen ja auch nicht Exchange machen - möglich wird es auf mittlere Sicht aber sehr wohl bleiben. Die 128 GB sind ja immer noch eine Empfehlung und nicht die Untergrenze, zu der eine Aussage einfach noch aussteht. Ich denke aber, in ein paar Monaten wird Microsoft sich dazu geäußert haben, und vorher wird es ja sowieso nicht akut. Gruß, Nils

Moin, ja, Eval muss weg. Es ist mir ohnehin ein Rätsel, wie man Eval in Produktion einsetzen kann. Das ist weder erlaubt noch sinnvoll. Bevor da aber nun irgendwas geschieht, lohnt ein zweiter Blick. Gruß, Nils

Moin, erst mal langsam, bitte. Handelt es sich bei den DCs um virtuelle Maschinen oder um physische Server? Falls physisch: Es kann gut sein, dass es kostengünstiger wäre, dafür zwei Standard-Lizenzen zu kaufen und die Datacenter-Lizenzen dann für separate Virtualisierungs-Hosts zu nutzen. Falls virtuell: Dann bitte noch mal klären, wie da genau lizenziert wird. Vielleicht ist es korrekt, vielleicht aber auch nicht. Jedenfalls könnte man in dem Fall die Standard-Installation belassen (jedenfalls soweit es keine Eval ist). Für DCs ist Datacenter jedenfalls viel zu teuer. Da lohnt es, das Ganze noch mal zu beleuchten. Gruß, Nils

Moin, mir ist nicht ganz klar, was du vorhast und was das Problem ist. Damit wir hier nicht rumraten - kannst du das bitte noch mal genau erklären? Was ist der Grund für deine Überlegungen, was das Ziel? Gruß, Nils

Moin, vielleicht hilft dies bei den Grundlagen. [Hyper-V und Netzwerke | faq-o-matic.net] https://www.faq-o-matic.net/2012/04/23/hyper-v-und-netzwerke/ Gruß, Nils

Moin, deine Schleife sieht auch etwas seltsam aus. "false" heißt, es soll nichts passieren, verzweigt aber zum Beginn des Skripts. Sinnvoller wäre es doch dann, das Skript zu beenden oder an eine Stelle hinter "true" zu springen. Hier habe ich vor Jahren mal sowas in der Art gepostet, vielleicht hilft das weiter. Dort ist auch keine WMIC-Abfrage drin, die nicht nur viel Zeit kostet, sondern auch wegen der nötigen Berechtigungen heikel ist. [Monitoring: Ping-Checks zeitabhängig | faq-o-matic.net] https://www.faq-o-matic.net/2012/05/07/monitoring-ping-checks-zeitabhngig/ Ansonsten wäre die Empfehlung, derartige Dinge per PowerShell anzugehen. Batch ist doch sehr eingeschränkt, sobald etwas mehr Logik in einer Aufgabe steckt. Gruß, Nils

Moin, Sehe ich anders. Wie gesagt, gerade bei so einem Rechner halte ich das Risiko für sehr hoch. Gruß, Nils

Moin, gerade in dem Szenario dürfte das dann ausscheiden. An so einem Rechner arbeitet normalerweise kein IT-Fachpersonal. Man will also keine Prozesse, die als Admin laufen und von dem Bediener zugänglich sind. Gruß, Nils

Moin, das mag im Einzelfall zwar funktionieren, aber aus Sicht der Sicherheit ist das nicht OK, Das Programm läuft dann mit Adminrechten. Alles, was von diesem Programm aus läuft, hat ebenfalls Adminrechte. Ein simpler Dateidialog reicht dann aus, damit ein User unbegrenzt das System manipulieren kann. Gruß, Nils

Moin, also, nach dem Debakel würde ich in Firmenumgebungen jetzt gaaanz lange warten. Gruß, Nils

Moin, DNS wird hier nicht das Problem sein, die IPv6-Adresse auch nicht. Ich tippe auf ein lokales Problem. Wenn nichts dagegen spricht, den DC weiter zu betreiben und sonst keine Probleme auftreten, würde ich das bis zum Abschalten ignorieren und ihn dann aus dem AD einfach löschen. Metadata Cleanup geschieht seit 2008 von selbst. Gruß, Nils

Moin, so eine richtig einfache Lösung scheint es nicht zu geben, wenn mehr als ein Dongle in Reichweite sein kann. Hier hat einer eine "schmutzige" Lösung gebaut, die im Action Center nach dem gesuchten Gerät per Bilderkennung sucht und dies dann auswählt. Scheint ein AutoHotKey-Skript zu sein. https://stackoverflow.com/questions/35601005/autoconnect-to-ms-wireless-display-on-windows-10 Gruß, Nils

Moin, die Suchmaschine deines Verrtrauens beantwortet dir auch dies: https://www.microsoft.com/de-de/howtotell/cfr/report.aspx Ob es was bringt und du das melden willst, musst du dir selbst überlegen. Gruß, Nils

Moin, möglicherweise hast du eine unpassende Vorstellung von Registry-Keys. Aber das eigentliche Thema ist ja beantwortet. Ein schönes Wochenende, Nils

Moin, das ist konstruiert, unrealistisch und kommt in der Praxis nicht vor. Gruß, Nils

Moin, ein Client, der eine Richtlinien-Einstellung aufgrund seiner Windows-Version nicht "versteht", wendet sie einfach nicht an. Es ist also fast nie wirklich nötig, GPOs nach Windows-Versionen zu unterscheiden. Dass dieselbe Einstellung unterschiedliche Reaktionen hervorruft, ist so gut wie nie der Fall. (Genau betrachtet, ist es noch etwas anders: Der Client wendet die Einstellung an, schreibt den Wert also in seine Registry. Wenn aber das Betriebssystem diesen Registry-Wert gar nicht verwendet, dann bleibt er einfach ohne Funktion. Das Betriebssystem schaut an der Stelle einfach gar nicht nach und reagiert also auch nicht. Ein solcher Wert, der nicht verwendet wird, richtet aber auch keinen Schaden an.) Gruß, Nils

Moin, und in den Dienstprotokollen, die mit Hyper-V zu tun haben? Gruß, Nils

Moin, okay, dann viel Erfolg. Ich bin hier raus. Gruß, Nils

Moin, abgesehen davon, ist deine Rechenfrage, die du als das eigentliche Problem bezeichnest, doch bereits beantwortet. Also, entweder sprechen wir über das Gesamte oder wir lassen es ganz. Gruß, Nils

Moin "ASR", mich stört dein Ton. Kannst du dich bitte etwas zügeln? Danke. Gruß, Nils

Moin, ja, umgehen kann es damit. Für den Webzugriff von Usern aus dem eigenen oder einem vertrauten Forest ... Gruß, Nils

Moin, na super. Die Dimension hatte ich noch gar nicht im Blick. Also zielt Exchange 2019 auch dort nur auf die ganz Großen, die ihre Software unter SA haben und deshalb nicht aus Kostengründen länger betreiben. Also, ab in die Cloud. Gruß, Nils

Moin, also, meiner Interpretation nach seid ihr auf dem falschen Dampfer. ADFS dürfte für euer Problem nicht die Lösung sein, höchstens für Teile davon. Exchange kann die Authentisierung nicht an einen anderen Identity Provider abgeben. Das höchste der Gefühle ist (meines Wissens zumindest) eine "Linked Mailbox", bei der die Nutzungsberechtigungen einem User aus einem anderen Forest gegeben, wofür aber ein Trust nötig ist. Selbst wenn man es hinbekäme, die Anmeldung über ADFS zu steuern, müsste sie also auf einen Account aus demselben oder einem vertrauten Forest lauten, nicht aber auf einen unbekannten Forest. SharePoint und die anderen Web-Applikationen können grundsätzlich mit ADFS arbeiten, aber die Konfigurationen wären ziemlich sicher auch anders, als ihr es euch gerade vorstellt. In jedem Fall müssten die Berechtigungen und Konfigurationen bei "der Mutter" in größerem Stil angepasst werden. Je nach Applikation, die da bereitgestellt wird, könnte es auch sein, dass es gar nicht geht. Wenn ihr aber organisatorisch ohnehin eine Vertrauensstellung habt, würde ich noch mal ernsthaft darüber nachdenken, diese auch technisch umzusetzen. Vieles wird dann einfacher und wahrscheinlich auch sicherer. Gruß, Nils

Moin, ADFS unterstützt keinen Identitätswechsel. Kurz gesagt, werdet ihr das, was du andeutest, ohne Trusts nicht hinbekommen. Allerdings bin ich mir nicht sicher, ob das ganze Szenario so passt. Beschreib doch bitte mal näher, was ihr eigentlich erreichen wollt. Gruß, Nils

Moin, okay - du verstehst, was ich oben gemeint habe? Anscheinend habt ihr ja schon sehr genaue Vorstellungen von Anforderungen und Prozess. Da können wir jetzt noch eine Weile so weitermachen, dass jemand einen Produktnamen in die Runde wirft und du sagst "nee, passt nicht". Aber das dürfte wenig bringen. Zielführender dürfte sein, dass du das definierst, was wirklich benötigt wird und damit auf eine gezielte Suche gehst. Vermutlich ist ein Forum dafür dann nicht mehr das richtige, aber der Gießkannenfaktor reduziert sich deutlich. Gruß, Nils