cj_berlin

Und, weil es auch im Jahre 2021 nicht oft genug wiederholt werden kann: DHCP nicht auf einem DC.

@lizenzdoc: Du übersiehst nichts, genau so wird das gemacht, wenn man kein Abo möchte.

Naja, mit SA für alle + VDA für manche ist es ohne weiteres möglich und wird auch ständig gemacht. Das sind natürlich de-facto Mietlizenzen. Und warum auch nicht In manchen Fällen macht es kaufmännisch durchaus Sinn. Für alle anderen Fälle bleibt die VDI mit Server-OS und RDS-CALs. Oder, falls alle Anwendungen mitspielen, Terminalserver. Macht technisch und kaufmännisch nach wie vor mehr Sinn als VDI.

Moin, ich bin natürlich kein Jurist, und niemand wird Dir hier in einem freien offenen Forum einen gerichtlich belastbaren juristischen Rat erteilen. Dies vorausgeschickt, liest sich der von Dir zitierte Paragraph d. für mich wie folgt: mit dem Abschnitt (iv) (Virtualisierung) bist Du soweit im Reinen, Der Abschnitt (v) (Remotezugriff) besagt, dass der Nutzer, der das Gerät "physisch" verwendet, von einem beliebigen Gerät, und andere Nutzer von lizenzierten Geräten aus darauf zugreifen können. Jetzt kann man sich bei einer virtuellen Instanz streiten, wem diese denn "physisch" zugewiesen ist. Und unsere intuitive Deutung der Begriffe spielt dabei, wie immer bei Vertragstexten, keine Rolle. Mir wurde bisher in jeder Lizenzberatung gesagt, VDI mit Windows-Clientbetriebssystemen ist mit Retail-Lizenzen nicht möglich. Insofern, wenn Du von einem qualifizierten Lizenz-Reseller oder von einem Lizenzanwalt eine andere Aussage erhältst, wäre es für viele kleine Firmen sehr interessant.

Du musst bitte, wenn Du zitierst, auf die Quelle verlinken. Denn es ist nicht egal, aus welchem Bezugskanal Deine Lizenzen stammen, und die entsprechenden Lizenzbedingungen gelten dann.

Moin, ja, zeig mal Deine Ergebnisse. Nach meinem begrenzten Wissen erfordert der Remote-Zugriff auf ein Windows Client-OS eine Enterprise-Lizenz mit SA: Entweder diese Lizenz klebt an dem zugreifenden Endgerät oder sie muss noch durch eine VDA (Virtual Desktop Access) ergänzt werden, was, ähnlich wie SA, eine Abo-Lizenz ist und kein einmaliges Abo. Auf welcher Plattform das Windows virtualisiert ist, ist in beiden Fällen egal.

Das ist bei Hyper-V aber im Gegensatz zu VMware nicht unbedingt erforderlich. Ben Armstrong hat das mal aufgedröselt und empfohlen, die Synchronisierung aktiviert zu lassen. @chrismue Schalte doch bitte mal das Logging des Zeit Service ein und poste den Log nach dem Restart des Dienstes.

Naja, wie wäre es, die User werden zu Mail-enabled Users, und ihre externen Adressen werden als externe Forwarding-Adressen eingetragen. Kostet keine Exchange-Lizenz, Attribute werden mit Exchange verwaltet, Mail wird zugestellt. Und wenn Du die User "nicht nur in einer extra OU" separierst, dann reden wir von einem extra Forest. Und dann hast Du multiforest Citrix, multiforest Jira, multiforest GPO usw. usw. Ob das so *der* Lösungsansatz ist...

Moin, das offensichtliche ist aber geklärt: Auf den Zielservern ist die Druckerumleitung als Solche nicht totgetreten? Ansonsten, Nested RDS hat offizielle Einschränkungen. Hier ein älterer Artikel: https://docs.microsoft.com/en-us/troubleshoot/windows-server/remote/run-remote-desktop-connection-session Allerdings funktioniert Dein Szenario in meinem Labor einwandfrei. Dann musst Du wohl die Logs lesen (auf den Zielservern).

Da passiert doch nix... kann man ganz easy machen Mit "KnowHow Eintrag" meinst Du sicher einen "Knowledge Base-Eintrag". Know-How ist was Dir hier geboten wird Die offizielle Aussage von Microsoft wird sein (bzw. ist, aber ich bin zu faul zu suchen): In einem Forest mit Exchange ist manuelles Bearbeiten von Exchange-relevanten Attributen (und dazu gehört das Attribut 'mail', obwohl es auch ohne Exchange vorhanden ist) nicht supported. Diese Aussage hilft Dir aber vermutlich nicht ganz weiter, denn die betroffenen User sollen ja explizit keine Exchange-Funktionalität haben. Viele Skripte und Tools versuchen, in einer Umgebung mit Exchange die Empfänger mit dem LDAP-Filter (mail=*) zu erkennen. Diese Tools werden natürlich durch die Maßnahme verwirrt sein.

Na klar. Schließlich sind wir ja in Deutschland: (aus https://youtu.be/p56aVppK2W4) Apropos: MüSSen müssen wir alle mit Doppel-S schreiben, und mußten das auch bereits nach der alten Rechtschreibung

Hast Du eh nicht, wenn *irgendjemand außer Dir* lokaler Admin ist. Wenn Du ein Gerät im Verlustfall finden oder wipen möchtest: Intune.

dann sind sie aber nicht im AD gespeichert

...aber Lösungen, die Kontakte aus der GAL in die Postfächer blasen, gibt es mehr (und preiswerter) als "quellenneutrale Kontakt-Importer nach Exchange". Nur ein Gedanke...

Dann darfst Du keinen Anspruch auf Sicherheit Deiner Clients mehr haben. Und das musst Du auch nicht - ist ein durchaus valides Konzept, das auch erfolgreich praktiziert wird: schmeiß die Rechner aus der Domäne und gib jedem Techniker einen lokalen User ohne und einen lokalen User mit Adminrechten. erklär das Client-Netz und das VPN zu externen Netzen. Alle Firmen-Anwendungen sind entweder als (per Reverse Proxy veröffentlichte) Web-Applikation zu erreichen oder per Citrix (hinter NetScaler), RDS (hinter RDG) oder View (hinter UAG), jeweils mit Präauthentifizierung und MFA - jawohl, auch dann, wenn der Rechner physikalisch im Office ist, denn er ist als feindlich einzustufen. Somit hast Du das ganze Thema Client-Verwaltung komplett von der Backe. Aber halb/halb geht nicht bzw. geht solange gut bis Dir irgendwann aufgeht, dass Du seit Monaten erfolgreich geownt wurdest.

Moin, die offensichtlichste Lösung ist: User keine Software installieren lassen, sondern die Softwareverteilung dafür nutzen. Aber Du hast bestimmt viele Gründe, warum das ausgerechnet in Deiner Organisation nicht geht. Ansonsten: LAPS mit kurzer Lebensdauer der Passwörter wird zwar nicht verhindern, dass sie sich an dem Tag anmelden können, an dem sie von Dir das jeweils aktuelle Passwort kriegen, aber am nächsten Tag wäre das Passwort dann schon ein anderes... Einen Domänen-User (anderen) dafür nutzen, der per GPO in die lokalen Admins reinkommt und dann wieder raus. JIT, sofern euer AD mindestens 2016 ist, andernfalls ephemere Gruppen...

Moin, so etwas kann man durchaus mit Erfolg skripten. Sollen dabei Kontakte auf der GAL, sprich, im AD erzeugt werden (in diesem Fall ist die Exchange PowerShell Dein Freund), oder Outlook-Kontakte in Postfächern (dann musst Du mit der EWS Managed API arbeiten, und es wird vermutlich ziemlich langsam sein)? "Nur Änderungen" geht sehr einfach, wenn das ERP den Zeitstempel der letzten Änderung zuverlässig mitliefert. Falls nicht, musst Du noch eine Datenbanktabelle dazwischen schieben, und die Änderungen in SQL anhand der Wertvergleiche in den einzlenen Feldern erkennen, bevor man das nach Exchange schreibt. Dasselbe Hilfsmittel würde ich auch zur Erkennung von Löschungen verwenden.

...oder überhaupt ein *Server*, ein Gerät also, das darauf optimiert ist, 24x7x52 zu laufen... ...und Out-of-Band Hardware-Management (iLO, iDRAC, iRMC..) hat Ich würde immer lieber einen gebrauchten Markenserver als einen selbstgeschraubten PC für den Servereinsatz nehmen. Und wenn's leise sein soll, gibt es den TX120 von Fujitsu oder so etwas.

Moin, wenn eine Datei zwei Zeilen hat, liefert Get-Content ein Array mit zwei Mitgliedern. Der Index 1 liefert dann genau die zwote Zeile. Diese kannst Du dann per Add-Content an die fortgeschriebene Datei anfügen. Ein Einzeiler also

1 <= 2 CHECK 8 <= 16 CHECK 8 <= 8 CHECK ergo, alles OK

Moin, wenn Du <= 16 Cores gesamt, <= 2 Sockel und <= 8 Cores pro Sockel in Deinem Blech hast, bist Du mit der Basislizenz abgedeckt und kannst die 2 VMs fahren, sofern auf dem Blech lediglich Hyper-V ausgeführt wird und nicht irgendwelche anderen Server-Rollen.

...und hast Du auch einen Überblick darüber, ob nur AD-Clients im LAN oder auch andere Use Cases in den chinesischen Standorten anfallen?

...meine IT-Überlebensregel #1: Basiere niemals Handlungen auf Annahmen. Aber ja, da die AD-Anmeldung anscheinend funktioniert, sind die chinesischen Netze wohl in einem eigenen Standort oder halt in zwei. Die Domain-Mitglieder wären dann mit sitescope bedient. Bleiben zwei Weitere Fälle: Im LAN, aber kein AD-Mitglied --> das könntet ihr lösen, indem ihr dort einen DNS-Server hinstellt, der alles an den DC weitergibt bis auf autodiscover. Dieses würde er dann mit der chinesischen Adresse beantworten. Damit könntet ihr sogar auch die AD-Member bedienen, wenn ihr die SCP-Abfrage per GPO tot tretet und nur DNS macht. Aus dem Internet --> da kommt ihr doch von China aus ja vermutlich ohnehin nicht an das Exchange in Europa, oder? Insofern dürfte es diesen Fall nicht geben.

Was Norbert gesagt hat. Und wenn ihr schon Rechte vergeben wollt, dann wenigstens ohne Automapping. Dann kann der geneigte User nicht das Postfach, sondern lediglich den Kalender einbinden, hat seine Rechte, kriegt aber weder Mail-Ordner noch den Kontakte-Ordner ("Adressbuch" ist in Exchange was anderes ) zu sehen.

...wobei es seit 2008R2 echt egal ist, in welcher Reihenfolge die da stehen. Aber ja, macht man auf jeden Fall so, da meckern auch alte Inventarisierungsskripte nicht Und der Vollständigkeit halber, obwohl es im vorliegenden Fall wohl keine Bewandtnis hat: Wenn die neue IP durch Subnetze in eine andere Site fallen würde als die alte, würde es bei einem DC nicht dazu führen,. dass er die Site wechselt.