-
Gesamte Inhalte
43.555 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von NorbertFe
-
-
und ihr arbeitet mit lokalen Konten?
-
Ja das hab ich auch. Nur aktiviert mein 2016er KMS eben (siehe oben) keinen 2019er Server.
-
Hab leider grad keinen 2019 Standard rumfliegen, sonst hätte ich mal getestet.
-
Ja, aber der Key ist für KMS und AD Aktivierung afaik ja der selbe. Oder nutzt ihr MAK?
-
Manchmal muß man aber wirklich den Kopf schütteln, wenn man die Workarounds bei MS https://www.heise.de/newsticker/meldung/Windows-7-Updates-KB4480970-und-KB4480960-verursachen-Netzwerkprobleme-4270472.html liest:
https://support.microsoft.com/en-us/help/4480960/windows-server-2008-kb4480960
To work around this issue use either a local account that is not part of the local “Administrators” group or any domain user (including domain administrators).
Andererseits ist der bei Heise veröffentlichte Workaround auch nicht wirklich besser aus sicherheitstechnischer Sicht.
Bye
Norbert
-
Am 2.1.2019 um 07:34 schrieb PowerShellAdmin:
Guten Morgen,
MS hat den Fall vorher geschlossen, mit dem Verweis dass die Datacenter Keys keine Standard mehr aktivieren können.
Aufgrund der Vorgespräche aber eher von Unwissenheit aus.
Ich habe keinen Textauszug zu den Änderungen erhalten.
Irgendwie nicht ganz zufriedenstellend - konnte hier weder eine Bestätigung noch gegensätzliche Aussage finden.
Ist aber auch falsch, denn dokumentiert ist bei MS das hier:
https://docs.microsoft.com/de-de/windows-server/get-started-19/activation-19
Da steht dann explizit "Windows Server 2019 (all editions).
Ich habe übrigens auch nach Installation von CU1/2019 noch das Problem, dass ein KMS 2016 mit KMS Key 2019 keine 2019er Server aktiviert.
Fehlermeldung:
Windows(R), ServerDatacenter edition (34e1ae55-27f8-4950-8877-7a03be5fb181) wird aktiviert...
Fehler: 0xC004F074 Vom Softwarelizenzierungsdienst wurde gemeldet, dass der Computer nicht aktiviert werden konnte. Es konnte kein Schlüsselverwaltungsdienst (Key Management Service, KMS) erreicht werden. Weitere Informationen finden Sie im Anwendungsereignisprotokoll.Ich sehe sowohl am Server der aktiviert werden soll, die Anforderung im Anwendungsprotokoll
Eine Aktivierungsanforderung wurde verarbeitet. Info: 0xC004F042,5,Server.domain.local,85eb6ff2-f1b8-4728-b0c3-f6385cb36f9f,2019/01/10 10:15,0,5,0,34e1ae55-27f8-4950-8877-7a03be5fb181als auch am KMS Server die Anforderung
Eine Aktivierungsanforderung wurde verarbeitet. Info: 0xC004F042,5,WFBBCLS03.zab.local,85eb6ff2-f1b8-4728-b0c3-f6385cb36f9f,2019/01/10 10:15,0,5,0,34e1ae55-27f8-4950-8877-7a03be5fb181Beide Server sind übrigens Datacenter Editionen.
Also ist entweder der Key falsch, was ich nicht glaube, denn der wird mir korrekt als KMS 2019 im VAMT angezeigt oder die Verarbeitung funktioniert nicht. :/ noch jemand irgendwelche Ideen? ;)
Bye
Norbert
-
So sind wir zu dir. Zukünftig wissen wir, wenns dir schlecht geht, schreiben wir schnell was zu multihomed DCs. ;) :p
-
vor 12 Stunden schrieb kristijan:
Ich denke es hat etwas mit dem Folderredirection zu tun. Diese habe ich aber deaktiviert.
Settings: "Redirect everyones folder to the same location" - Redirect to the local userprofile location.
und "Leave the folder in the new location when policy is removed"
Das hast du auch gemacht, bevor du die alte Freigabe gelöscht hast, damit der Client überhaupt eine Chance hatte das zu übernehmen?
-
-
Aber ihr wißt ja auch, was und wie warum das so konfiguriert wurde. ;)
-
Doch zwei DCs. ;)
-
Das ist dann aber keine "Lösung", sondern Gebastel. Und macht das Konstrukt ja nicht einfacher, nachvollziehbarer, sondern unkalkulierbar und komplex.
-
Und was möchtest du mir jetzt sagen? :)
-
Nutzt ihr Split-Permission Modell/RBAC?
-
Und mit welchem Account versuchst du das Konto zu erstellen?
-
Ich wußte, dass dieses Argument kommt. Wahrscheinlich wundert es dich auch nicht, warum hier jeder bisher sagt: "Mach es nicht bzw. mach es richtig". :)
-
Kannst du denn normale Postfächer anlegen? Sieht irgendwie aus, als wären im AD die Berechtigungen entweder falsch oder nicht vergeben.
-
vor 22 Minuten schrieb ASR:
Und was hat jetzt die Automapping Diskussion mit dem eigentlichen Problem bzw. der Frage zu tun?
ASR
Hatte ich oben ja geschrieben. Kein automapping sondern als zusätzliches Postfach einbinden. Dann sind die gelöschten und gesendeten Objekte im jeweiligen Postfach.
-
-
Nein! Seit Exchange 5.5 die selbe Antwort. Entweder die Alias Namen auf andere Objekte legen und dort dann Berechtigung (Send-As) vergeben oder mittels 3rd Party Tool.
-
vor 2 Stunden schrieb ASR:
Ich finde das Feature ohnehin problematisch und einigermaßen sinnfrei.
Nicht nur du. :)
-
Gute Idee. :) Aber da kommen dann ja soviele Gruppen zusammen. :P
-
Korrekt. Das "Blöde" ist eben, dass die GUI immer Automapping als Attribut setzt. Man kann das Attribut hinterher entweder manuell wieder löschen/leeren, oder man setzt die Rechte einfach per Powershell.
-
Ja mach das Automapping weg (deaktivieren) und binde die Postfächer einfach als zusätzliches Exchange Postfach ein. Das sollte mit Outlook 2010 afair auch gehen. Ansonsten hast du da wenig Chancen, da die meisten Workarounds nur mit oder ohne Cache Modus funktionieren, jedenfalls so, dass es meist nicht funktioniert.

Raumpostfach kann nicht erstellt werden
in MS Exchange Forum
Geschrieben
Welche Art Adressbuch hast du denn erstellt und wie willst du Kontakte hinzufügen? Schreib nur keine Infos, das könnte deine Helfer verwirren. ;)