Edvvde

Moin Nils, kurz, knapp und ehrlich - es ist ein Fehler unterlaufen. Statt mit der normalen ISO, wegen mir auch der DVD, wurde zur ISO der Evaluation gegriffen (wer lesen kann ist klar im Vorteil). Es sind bereits zwei DCs im Einsatz und ich wollte jetzt nicht beide DCs wieder neu aufsetzen inkl. DNS, DHCP usw. auch nicht mit einem dritten auf dem FSMO übertragen wird usw. usw. Zum testen wurde jetzt der zweite DC mal aktiviert, was wie gesagt zu funktionieren scheint. Ich dachte vielleicht hat jemand Info dazu oder kennt den technischen Hintergrund warum es nicht möglich sein soll bzw. warum es funktioniert hat. Woran ich gedacht hatte ist, dass es vielleicht nicht funktioniert von Standard auf Datacenter und umgekehrt aber Standard zu Standard sehr wohl ... Aber du hast natürlich recht, hätte nicht passieren dürfen.

Moin, danke für deine Antwort. Also merkwürdigerweise wird es egal ob 2012, 2016 und auch 2019 als nicht möglich in den Microsoft Foren und ich meine auch in den Support Dokumenten beschrieben, wie du auch geschrieben hast. Der Server wird aber definitiv als aktiviert mit Server 2019 Standard angezeigt, die letzten Ziffern des verwendeten Keys sind sichtbar und das Evaluation unten rechts ist verschwunden. Die AD ist vollständig und die Anmeldung am Client funktioniert. Das wundert mich ... wird also glückliche Mondstand gewesen sein?

Hallo zusammen, angeblich soll es ja nicht möglich sein, einen als Evaluation Standard installierten Server welcher als DC fungiert zu aktivieren als Standard. Ich hab es jedoch ohne Probleme via DISM /Online /Set-Edition:ServerStandard /ProductKey:X /AcceptEula machen können und scheint auch zu laufen. Kann da jemand was zu sagen? Danke!

Hi Jannik, ihr habt also einen RDS unter Win Srv 2019 im Einsatz und nutzt FXLogix Container? Nutzt ihr denn OneDrive in den User Profilen? Welche GPOs habt ihr sinnvoll im Einsatz? Gruß, Carsten

Hallo zusammen, folgende Ausgangssituation: - User arbeiten auf einem Terminalserver unter Win Srv 2019 - Es werden User Profile Disks genutzt (für die Zukunft sind wir am liebäugeln mit FSLogix) - Office ist installiert, User verfügen alle über E3 Lizenzen Nun wollen die User OneDrive auch auf dem RDS nutzen. Müsste ja möglich sein, laut Anforderung wird Windows Server 2019 benötigt welches dann sogar files on demand unterstützen soll. Irgendwie ist das Ganze aber nicht so wirklich für RDS gedacht, habe ich zumindest den Eindruck. Es beginnt schon bei der Installation. Der Installer legt als "Pro User" die .exe ins User Profil des Administrator ab, alle anderen User sehen davon erstmal nichts. Es muss also die Installationsvariante "Pro Computer" gewählt werden, mit OneDriveSetup.exe /allusers wird die Installation ins normale Programmverzeichnis x86 abgelegt. Von dort aus können die User auch Verknüpfungen erstellen und OneDrive starten. Das funktioniert auch, für jeden User wird ein eigener Prozess gestarten. Die User können sich authentifizieren, aber an dem Punkt an dem dann im Userverzeichnis ein Ordner angelegt werden soll scheiterts. Klar könnte ich jetzt wahrscheinlich irgendwo eine Freigabe erstellen und die User dort syncen lassen. Aber ist das Sinn der Sache? Kurz und knapp gefragt: Hat jemand OneDrive produktiv auf einem RDS 2019 im Einsatz und vielleicht ein paar Best-Practices parat? Danke und schönen Abend.

Der Sync läuft, lässt sich zwar nicht abstellen (vielleicht gibt es hier eine Wartezeit?!) Aber der Sync läuft. Er synct halt nicht weil er ein Duplikat meldet, das ist auch in Azure zu sehen: UserPrincipalName Error Type: AttributeValueMustBeUnique Unable to update this object because the UserPrincipalName value ....... associated with this object may already be associated with another object in your local directory services. To resolve this conflict, first determine which object should be using the conflicting value. Then, update or remove the conflicting value from the other object(s). Und das ist ja gewollt ... er soll die beiden ja miteinander verknüpfen, logisch das es ein Duplikat gibt. //Okay wie vermutet, entweder gibt es eine Wartezeit oder irgend ein Prozess lief noch, jetzt ließ sich der Sync auch wieder anhalten. Bleibt also nur noch die Frage, wie die OnPremise und Azure Duplikate zusammengeführt werden können ...

Bin nun etwas weitergegekommen. Folgendes habe ich gemacht: - Mit Azure via Powershell verbunden: Connect-MsolService) - Azure AD Sync geprüft, gab True zurück: (Get-MSOLCompanyInformation).DirectorySynchronizationEnabled - Azure AD Sync deaktiviert: Set-MsolDirSyncEnabled -EnableDirSync $false - Azure AD Sync geprüft, gab False zurück: (Get-MSOLCompanyInformation).DirectorySynchronizationEnabled Nach wenigen Minuten verschwanden dann im Admin Portal das Zeichen für OnPremise AD sync und es waren nur noch Cloud Benutzer, welche sich auch wieder editieren ließen, schließlich war ja kein Sync mehr aktiv. - Powershell gab leere LastDirSyncTime spalte zurück: Get-MsolUser | ft UserPrincipalName,immutableid,LastDirSyncTime Nun wollte ich die User ja wieder syncen. Dafür habe ich im lokalen AD bei allen Usern das Attribut proxyAdresses gesetzt mit der jeweiligen E-Mail Adresse. Zusätzlich habe ich, da die lokalen User ja über keinen Wert im Attribut ms-ds-consistencyGUID verfügten folgendes gemacht um diese auch bei den Azure Usern zu löschen: - Azure AD Powershell: Set-MsolUser ` -UserPrincipalName testuser@mailadresse.de ` -ImmutableId "$null" - Powershell gab leere immutableid Spalte zurück: Get-MsolUser | ft UserPrincipalName,immutableid,LastDirSyncTime Nun wollte ich den Sync wieder starten also: - Powershell: Set-MsolDirSyncEnabled -EnableDirSync $true - Azure AD Sync geprüft, gab True zurück: (Get-MSOLCompanyInformation).DirectorySynchronizationEnabled Schaue ich nun jedoch im Azure Sync Service Tool für meinen Testuser, erhalte ich dort einen Error: - Error: AttributeValueMustBeUnique "Das Objekt kann nicht aktualisiert werden, weil die folgenden dem Objekt zugeordneten Attribute Werte aufweisen, die möglicherweise bereits einem anderen Objekt in Ihren lokalen Verzeichnisdiensten zugeordnet sind: "UserPrincipalName testuser@mailadresse.de;". Korrigieren oder entfernen Sie die doppelt vorhandenen Werte in Ihrem lokalen Verzeichnis." Es findet auch kein Sync statt. Nun wollte ich noch eine Möglichkeit versuchen, Nämlich die zuvor von mir im Azure AD gelöschte (aber gesicherte) immutableid welche dort als BASE64 codiertes Feld hinterlegt ist umzuwandeln in einen HEX Wert um diesen dem User im lokalen AD im Attribut ms-ds-consistencyGUID zuzuweisen. Allerdings bekomme ich den Sync nicht mehr gestoppt ... - Azure AD Sync deaktivieren bringt Fehlermeldung: Set-MsolDirSyncEnabled -EnableDirSync $false --> Set-MsolDirSyncEnabled : You cannot turn off Active Directory synchronization. Noch jemand ne Idee, wie ich die neu angelegten lokalen AD User mit den Azure AD Usern gesynct bekomme -./ ?

Hallo Zusammen, folgendes Szenario: Vor dem Hardwarecrash (Backup nicht vorhanden) gab es eine Hybride Lösung von Azure AD und lokaler AD, also in Azure und Office 365 wurden die User gesynct. Hardwareausfall, lokaler Totalverlust. Office 365 und Azure natürlich weiterhin vorhanden. Dummerweise wurde in der Zwischenzeit die Hardware ersetzt, lokal eine neue Domäne eingerichtet mit allen Accounts. Die Azure AD meckerte natürlich jetzt wegen fehlender Sync seit einigen Tagen. User in Office 365 und in Azure AD lassen sich nicht löschen etc. da ja local synced. Wie würder ihr hier vorgehen? Gibt es die Möglichkeit Azure AD zu deaktivieren ohne die User in Office 365 zu verlieren? Wie sieht ggf. die Möglichkeit einer Zusammenführung aus zwischen der lokalen AD und der Azure AD natürlich ohne Verlust der User in Office 365 und deren Daten? Danke euch vorab! LG

Hallo, folgendes Problem: Clients (Domänenuser) wollen etwas ausschneiden und in einen anderen Ordner einfügen (z.B. von lokal Ordner A auf Netzwerklaufwerk Ordner B, oder von Ordner A auf Netzwerklaufwerk in Ordner B in Netzwerklaufwerk, also tritt nur in Zusammenhang mit Netzwerklaufwerk auf). Netzlaufwerke sind freigegebene Ordner auf einem WS2012. Dann wird der Vorgang auch abgeschlossen (also Datei wird in Ordner A entfernt und in Ordner B eingefügt), aktualisiert man dann Ordner A jedoch, wird die Datei wieder angezeigt (man kann Sie jedoch nicht öffnen und auch nicht löschen meldet fehlende Berechtigungen). Man muss dann alle offenen Ordner schließen und mit Glück ist diese Schattenkopie dann in A verschwunden. Der Fehler tritt nur auf, wenn die Dateivorschau rechts aktiviert ist. Ist die Dateivorschau deaktiviert, macht er das ohne Probleme. Versucht man das ganze nur lokal, tritt der Fehler wie gesagt nicht auf. Auch nicht mit aktivierter Dateivorschau. Der Fehler tritt nur bei 2 Clients auf, alle anderen haben damit keine Probleme. Bei Drag&Drop tritt das Problem auch auf. Danke euch!

Okay, hoffe eine Frage ist noch drin: Angenommen Nutzer und Postfächer sind im anderen AD (Standort B) vorhanden. Am Standort A sind diese Nutzer ebenfalls in der eigenen AD vorhanden. Dann wäre die Anmeldung am Exchange-Server der Domäne B mit entsprechender Adresse, Username und Passwort möglich und würde dann funktionieren? Habe ich das richtig verstanden?

Hallo Norbert, danke dir schon mal! Hatte hier in einigen Beiträgen davon gelesen, dass Exchange die Rechte usw. über die AD regelt und der Exchange steht ja in einer komplett anderen Domäne und anderer AD Umgebung? Es besteht auch keine Vertrauensstellung zwischen den Domänen (ist ja nicht möglich wegen Standardumgebung und Essentials muss Stamm der Gesamtstruktur sein). SSO steht für Single Sign On? Heißt quasi Nutzer am Standort A meldet sich am Rechner an, öffnet Outlook und kann arbeiten? Richtig verstanden? LG

Hallo zusammen, zur folgenden Situation habe ich ein paar Fragen, evtl. kann mir jemand weiterhelfen: - Versicherungsbüro bekommt am Standort A eigenen Server (Neue Gesamtstruktur) für 5 Arbeitsplätze (Essentials als DC, AD, DHCP, DNS, Files). - Exchangeserver läuft am Standort B unter Standard-Umgebung (andere Domäne, anderer DC, eigene AD usw.). Ist der Zugriff auf diesen Exchangeserver möglich? Hatte gelesen das Exchange Daten in die AD schreiben muss? Es besteht ein Sophos red Tunnel zwischen den Standorten. Hoffe jemand kann mir ein paar Infos geben, Danke!

Doch, ich habe mir so gut wie alles angesehen was es dazu auf den Microsoft Seiten gibt. Aber ich glaube es fehlt einfach etwas Fachwissen um die Frage selbst zu beantworten. Und das ist der Punkt den ich mir versuche zu erklären! Warum greifen die User der Zentrale denn auf den 2012er zu? Also ist das technisch einfach so? Die Zentrale wird doch durch die 2008er Server versorgt mit AD, DHCP usw.? In meiner Theorie nutzen lediglich die Nutzer der Nebenstelle den 2008er in der Hauptstelle als Exchange.

Problem ist aber doch, dass an der Hauptstelle bis jetzt nur 2008er Cals für die 2008er Server vorhanden sind. Also müssen die User der Hauptstelle nun neue 2012er Cals bekommen, wenn der neue Server in der Nebenstelle unter 2012 läuft oder nicht?

Also insgesamt müsste das Unternehmen 300 User Cals besitzen um 100% der Nutzer insgesamt abgebildet zu haben? Wobei jedes physische Netz vor Ort mit 100 User Cals zu 100% abgedeckt wäre.

Gelten die 100% für alle im Netzwerk also auch an der Hauptstelle oder nur die vor Ort auf dem Server Arbeiten wegen AD usw.?

Domänenzugehörigkeit ist so gemeint: Neuer 12er Server für Nebenstelle wird in bestehende Domäne eingebunden. Fungiert vor Ort für 22 Geräte als AD, DHCP, DNS und Fileverwaltung. Am Server der Hauptstelle wird Exchange auf 2008er genutzt.

Entschuldige, Lizenzierung selbstverständlich mit z ;) Sollte nicht so rüber kommen, versuche es nur zu verstehen. Die zugehörige Veranstaltung schimpft sich Grundlagen der Rechnernetze und da man an der Uni mittlerweile auch praktisch sein möchte, bildet man theoretische Szenarien, welche dann theopraktisch im Rahmen von Übung/Seminar wie auch immer abgearbeitet werden. Sinn oder Unsinn habe ich mittlerweile aufgehört in Frage zu stellen :D Warum Microsoft? Aufgrund dieser MS Academic Alliance, haben wir Zugriff auf einiges an MS Software, wodurch auch solche Themen angeschnitten werden! Zurück zu meiner Frage: Für den Fall das nur 2008 R2 Server existieren und die zugehörigen Cals, benötigt man für sämtliche Nutzer/Geräte in der Domäne in die der neue 12er Server eingegliedert werden soll neue 12er Cals. Evtl. Falschlizenzierung bereits jetzt, für den Fall das schon ein 12er Server neben den 2008er existiert, aber die 2008er Cals nicht aufwärtskompatibel sind. Aber ist es denn korrekt oder gewollt, dass ich für wirklich jeden in der Domäne Cals brauche, allein durch die Domänenzugehörigkeit?

Hallo Norbert, es handelt sich hier um ein theoretisches Szenario aus einem Seminar an der Uni, weshalb nicht alles genau definiert ist. Also wenn bisher nur Cals für 2008 bestehen und an Haupt und den anderen Nebenstellen keine für 2012 müssten quasi für ALLE in der Domäne Cals für 2012 angeschafft werden (egal ob aktiv auf dem Server arbeiten oder nicht, allein durch die Domänenzugehörigkeit)? Falschlizensierung inwiefern? Mein lieber Schwan, umständlicher hätte man diese Lizenzgeschichten auch nicht machen können :D Danke!

Hallo Günther, Danke für deine schnelle Antwort! Also als Beispiel vor Ort wären 20 Rechner und 2 Drucker, also 22 neue Cals (in diesem Fall Device). Für alle andren Geräte die in der Domäne sind an der Haupt und den anderen Nebenstellen werden keine neuen gebraucht, auch nicht wenn diese an diesem Server arbeiten sollten? Hab ich das richtig verstanden?

//auf anraten eines erfahrenen Board-Mitglieds starte ich doch mal einen neuen Thread: Hallo zusammen! Habe ein kleines Verständnis Problem bezüglich der Cals. Folgendes Szenario: Hauptstelle besitzt bereits Server laufen unter 2008 R2 evtl auch welche unter 2012 R2 (nicht genau definiert), es existieren mehrere Nebenstellen welche bisher auf diese Domäne zugreifen (für AD, Exchange usw.) und vor Ort keine Server haben. Neue Nebenstelle wird eröffnet, soll mit Server 2012 R2 Standard ausgestattet werden für AD, DNS, DHCP und in bestehende Domäne eingebunden werden, als Controller vor Ort fungieren. Benötigen jetzt nur die Clients vor Ort Cals also entsprechend Nutzer oder Device Cals oder nochmal alle in der Domäne die mit diesem Server arbeiten könnten (evtl. sogar alle die in der Domäne sind), auch von der Hauptstelle sowie der Nebenstellen? Danke!

Hallo zusammen, wollte nicht extra einen neuen Thread starten, da es hier ja bereits um Lizenzierung geht und der Thread quasi oben stand. Habe ein kleines Verständnis Problem bezüglich der Cals. Folgendes Szenario: Hauptstelle besitzt bereits Server laufen unter 2008 R2 evtl auch welche unter 2012 R2 (nicht genau definiert), es existieren mehrere Nebenstellen welche bisher auf diese Domäne zugreifen (für AD, Exchange usw.) und vor Ort keine Server haben. Neue Nebenstelle wird eröffnet, soll mit Server 2012 R2 Standard ausgestattet werden für AD, DNS, DHCP und in bestehende Domäne eingebunden werden, als Controller vor Ort fungieren. Benötigen jetzt nur die Clients vor Ort Cals also entsprechend Nutzer oder Device Cals oder nochmal alle in der Domäne die mit diesem Server arbeiten könnten (evtl. sogar alle die in der Domäne sind), auch von der Hauptstelle? Danke!