mcdaniels

Ich kann bzgl. Blickschutzfolien eigentlich auch nichts Positives berichten. Das ist immer irgendwie ein Murks und eigentlich auch gar nicht so billig.

Hallo, hier meine ich M365 Apps for Business. Aktuell verwenden wir nur Word, Excel, Powerpoint, Access, (ohne Exchange und Outlook). Die Sache ist aber dass wir einen Terminalserver haben und das auch bekannt war. Es wurde ja auch bereits die "gemeinsame Computernutzung'" konfiguriert (von externem Dienstleister). Erst dann kam "oh, das geht mit den Apps for Business nicht......" Dann kam, dass man da nix ändern kann (erst in einem Jahr). Leider ja... Wir haben den Vertrag auf 3 Jahre abgeschlossen. 1 Jahr ist jetzt mal bezahlt. Hm, stimmt es auch nicht, dass man die Lizenzen nach einem Jahr Laufzeit anpassen kann? wäre das dann ein Partner der eine eigene Cloud hat und die Dinge per eigener Cloud zur Verfügung stellt. Das könnte mein Dienstleister sogar. Weil in der Diskussion kam dann, da müsste man deren Cloud nutzen und dann könnte man eben mehr machen. Aktuell geht da aber eben nix, da falsche Lizenz. Bringt mich aktuell in einige Schwierigkeiten, denn eigentlich müssen wir aufgrund eines unvorhergesehenen Rückzugs unseres Groupware-Anbieters auch hier handeln. (Exchange online). Das geht jetzt aber auch nicht, da wir die Lizenzen ja nicht upgraden können. Das Ganze ist generell sehr ungünstig gelaufen (vorsichtig formuliert). Denn ich hatte in einem Gespräch auch darauf hingewiesen, dass wir zumindest IMMER die Möglichkeit haben wollen die Lizenzen upzugraden. Das geht ja im Moment auch nicht. Ich versteh es nicht wirklich. Der Dienstleister hat mir nun zugesagt, dass er schaut ob man da noch was machen kann. (aber die Bestellung ist ja schon 3 Monate her....)

Hallo zusammen, wir haben nach eingehender Beratung durch einen MS zertifizierten Partner 100 Lizenzen (User) von: Microsoft® M365 Apps Business erworben. Aufgrund einer Fehlberatung, können wir nun diese Lizenz NICHT am Terminalserver verwenden (da diese Option bei dieser Lizenz nicht zur Verfügung steht). Wir würden also ein höherwertiges Paket benötigen (zb. M365 Business Premium). Der Openvaluevertrag der dieser Lizenz zu Grunde liegt, läuft auf 36 Monate. Stimmt es, dass: wir erst nach Ablauf des ersten Vertragsjahres Adaptierungen an dieser Lizenz vornehmen können. Konkret (40 der User bräuchten zb. die M365 Business Premium)? Könnte man nach Ablauf des ersten Jahres zumindest die 100 gekauften Apps for Businesslizenzen auf 60 reduzieren und zusätzlich 40 "Business Premiumlizenzen" dazukaufen? Ist es überhaupt möglich während der 3-Jahres Laufzeit des Openvalue Vertrages ein Downgrade durchzuführen? Übrigens wurde mir auch gesagt man könnte die Lizenz jederzeit upgraden (mit Betonung auf jederzeit). Sprich eben aus bereits bestehenden M365 Apps for Business könnte man auf die M365 Business Premium gehen. (innerhalb des Vertrages). Das geht -wie ich erst vor Kurzem erfahren habe - aber angeblich auch nicht. Ich bin mir mittlerweile absolut nicht mehr sicher, denn durch die -ja, man muss sagen Fehlberatung- stehen wir jetzt einigermaßen im Abseits...

Hi, DNS konnte ich gerade vorhin deinstallieren Danke!

Hi, ich werde schauen, dass ich schnellstmöglich die dort noch laufende Software auf einen anderen Server migriere und den "beschädigten" Memberserver dann abdrehe.

Absolut korrekt. Haben wir bei den anderen DCs eh nicht mehr gemacht. Der hier ist aber noch von 2014 und da hat sich das leider so ergeben.... Ich hoffe ich hab nix übersehen ;-) Es sind keine Einträge mehr in den AD Standorte und Dienste mehr da, DNS ebenso nichts und er wird nicht mehr als DC geführt. Wie oben kurz beschrieben, läuft auch ein DCDIAG auf den 2019er DCs fehlerlos durch. Wäre dennoch interessant, was dieses Verhalten auslöst. Danke jedenfalls!

Hallo, ich wollte heute einen alten 2012er DC (DC1) herabstufen und dann die AD Domänendienste via Servermanager (Featureentfernung) entfernen. Rollen hat dieser DC keine. In der Umgebung sind 2 "neuere" 2019er DCs, wovon einer der 2019er alle Rollen inne hat. Beide 2019 haben den GC aktiviert. Nach erfolgreicher Herabstufung des 2012er DCs (er wurde ordnungsgemäß in die OU Computers verschoben) und ist lt. AD Standorte und Dienste kein Replikationspartner für die anderen DCs mehr, wollte ich nun via Servermanager via Featureentfernung die AD Domänendienste entfernen. Die Entfernung läuft ne Zeit lang und bricht nach 30 Minuten mit dem Fehler 0x8000ffff ab. Ein Restart und erneuter Versuch brachte keinen Erfolg. Die verbliebenen DCs (2019) zeigen korrekt die Rollen auf dem richtigen Server an. Ein repadmin /replsummary auf den verbliebenen DCs (2019) zeigt den demoteten 2012er nicht mehr an. Ein dcdiag /a auf den 2019er meckert nur wegen der NTP Zeitquelle (war der alte 2012er) und loggt aber auch dass ein neuer Domänencontroller für die Sync gesucht wirt. Dummerweise läuft auf dem Server 2012 noch eine Software, weshalb ich ihn nicht einfach abdrehen kann. (ich wollte ihn noch ne Zeit lang als Member laufen lassen.) Seht ihr hier ein Problem, nachdem die Features AD Directory Domänendienste bzw. auch DNS noch aktiv sind? Könnte man den Server einstweilen auch so weiterlaufen lassen? Woher kommt dieser Fehler? Wo kann man danach graben? Kurzes Update: Es scheint so, als ob der Servermanager des demoteten DC (DC1) unbedingt mit einem DC (DC2 - ebenso 2012) reden will, der aber bereits vor Wochen ordnungsgemäß heruntergestuft & AD Rollen entfernt worden sind. Auch dieser Server scheint nur noch unter "Computers" auf und ist nur noch Memberserver (der allerdings heruntergefahren ist). Fehler auf dem DC1 ist: Fehler im Eventlog: DCOM konnte mit keinem der konfigurierten Protokolle mit dem Computer "DC2.domäne.local" kommunizieren, angefordert von ... "Servermanager.exe" Ich denke, das wird wohl der Grund dafür sein dass ich das Feature AD DS nicht entfernen kann. Ne, das wars auch nicht. Das kam daher, da der DC2 noch im Servermanager mit eingebunden war.... Update 2: Was ich jetzt noch haufenweise sehe ist in den Eventlogs -> Windows Protokolle -> Anwendung: Windows Error Reporting Event Id 1001 Fehlerbucket, Typ 0 WindowsWcpOtherFailure3 Problemsignatur P1-P10 P2 = servicingapi\assembly.cpp P3 = Windows::ServicingAPI::CAssembly::Adduninstall Offenbar jedesmal wenn ich die AD DS Features entfernen will... THX

Es ist also so: Die User steigen mit den Clients auf den TS ein. Alle User greifen auf den Terminalserver zu und arbeiten dort. Der Terminalserver ist auch der Fileserver. Was macht denn der Server sonst noch so? (Welche Services stellt er zur Verfügung) Was ist das für eine Maschine? (Hardwareausstattung) Wie sieht es mit der Auslastung aus? Ich denke ein paar zusätzliche Infos zum System wären wichtig.

Da hab ich offenbar sehr kreativ gesucht Danke dir!

Schönen guten Morgen zusammen! Ich beobachte jetzt schon einige Zeit lang folgende "Infoeinträge" in den Eventlogs der 2019er und 2012er DCs und frage mich, woher diese Info kommt bzw. vor allem, warum sie ausgelöst wird. Probleme gibt es überhaupt keine im laufenden Betrieb. Die Domänen-Funktionsebene = Windows Server 2012. Meldung (wird sehr oft protokolliert, mit unterschiedlichen Client-IPs des LAN): Ein Kerberos-Dienstticket wurde angefordert. Kontoinformationen: Kontoname: Kontodomäne: Anmelde-GUID: {00000000-0000-0000-0000-000000000000} Dienstinformationen: Dienstname: Dienst-ID: NULL SID Netzwerkinformationen: Clientadresse: ::ffff:192.168.10.48 Clientport: 60128 Weitere Informationen: Ticketoptionen: 0x10002 Ticketverschlüsselungstyp: 0xFFFFFFFF Fehlercode: 0x20 Übertragene Dienste: - Dieses Ereignis wird jedes Mal generiert, wenn der Zugriff auf eine Ressource angefordert wird, z. B. auf einen Computer oder einen Windows-Dienst. Der Dienstname steht für die Ressource, auf die der Zugriff angefordert wurde. Dieses Ereignis kann mit Windows-Anmeldeereignissen korreliert sein, wenn Anmelde-GUID-Felder in jedem Ereignis verglichen werden. Das Anmeldeereignis findet auf dem Computer statt, auf den zugegriffen wird, d.h. oft einem anderen Computer als dem Domänencontroller, auf dem das Dienstticket ausgestellt wurde. Ticketoptionen, Verschlüsselungstypen und Fehlercodes sind in RFC 1510 definiert Wäre dankbar für jeden Tipp, da mir die Internetrecherche leider nicht weiter geholfen hat. Danke!

Guten Morgen, soweit ich dich richtig verstehe, sind das alles unterschiedliche PC? Wie sieht es mit Pingzeiten von den div. PC zu den Fileservern aus? Laufen auf all diesen Rechnern die gleichen Programme? Hast du einen Virenschutz installiert und ist dieser auf allen Rechnern identisch konfiguriert? Patchstand ist überall gleich? Hängen die Rechner alle auf dem selben Switch?

sorry für meine lange Leitung. Du hast das Update drauf, weil ihr so eine Meldung habt, ok. Aber wie komme ich zu diesem Update? Deshalb ja meine Frage, ob das ev. sogar mit den kumulativen Updates mit installiert wird. Ich find es nicht im WSUS und -gerade geschaut- auch nicht via MS Update Katalog. Es ist wohl so: Nutzt man kumulative Updates und hat das Sicherheitsupdate vom 10. Mai 22 nicht installiert, einfach das aktuelle kumulative Sicherheitsupdate für die DCs einspielen. Wenn man allerdings immer alle kumulativen Sicherheitsupdates (auf den DCs) installiert hat und aktuell bei Patchstand 02/2023 ist, braucht man gar nix machen, denn dann ist der Patch&fix schon oben & wenn man dann auch noch keine Einträge im Eventlog der DCs hat, sollte ja auch nach dem 11.4.2023 (enforcement Mode) alles weiter laufen wie gewohnt.

...kann dir nicht folgen, was meinst du damit?

und sollte das Inhalt eines kumulativen Updates gewesen sein? (Weil die kumulativen Updates sind hier alle eingespielt)

bedingt aber natürlich, dass der Patch erstmal eingespielt wird. Danke! Nachsatz bzgl. des Patches: Es gab da doch für das KB5014754 ein out-of-band Update. Nehme an, dass dann dieses Update (manuell) einzuspielen ist?

Guten Morgen, bezogen auf kb5014754 verfolgt Microsoft ja einen mehrstufigen Plan zur Absicherung der zertifikatsbasierten Authentifizierung. Trotz des Studiums mehrerer Artikel zu diesem Thema ist mir die Vorgangsweise bezüglich die Installation nicht ganz klar, teilweise bin ich hier bei den Zusammenhängen ebenso unsicher. Ich bin mir sicher, dass ihr mir auf die Sprünge helfen könnt. Soweit ich es richtig verstehe (bitte korrigieren, falls es nicht stimmt): Das Update ist jedenfalls auf Domaincontrollern einzuspielen. Sofern es eingespielt wird, befindet es sich - bei entspr. Registry-Eintrag - bis zum 11.4.2023 in einem Kompatibiltätsmodus. Hier kann man dann via Eventlogs checken, ob es Inkompatibilitäten mit den Clients gibt. Am 11. April 2023 wird per Update der Kompatibilitätsmodus abgedreht Ab 11. April 2023 kann sich somit (sofern es Kompatibilitätsprobleme gibt) kein Client, der eine zertifikatsbasierte Anmeldung verwendet, mehr anmelden. Dies betrifft z.b. SSO-Dienste. Meldet sich ein User mittels Username und Passwort an, hat dieser Patch KEINE Auswirkungen auf die Authentifizierung und ebenso nicht auf die im AD befindlichen Computerkonten. Ansonsten hat der Patch keine Auswirkungen (z.b. auf die Kommunikation der DCs untereinander). Unklar ist mir: Wie ist der Patch nun einzuspielen? (Im WSUS finde ich ihn nicht) Muss man ihn manuell runterladen und dann auf allen DCs installieren? Grundlegend dürfte es nach der Installation des Patches auf allen DCs keine Probleme geben?

Ich habe jetzt via MS Produktaktivierung den Support erreicht, der mir weiterhelfen konnte. Im Endeffekt war es ein Klacks. (wenn man es weiß). Einloggen mussten wir uns im VLSC mit Arbeitskonto, aber mit dem Account admin@domainat.onmicrosoft.com. Hier fehlte lt. dem Supporter dann nur die "Verknüpfung" mit der office@bruckmur.at. (waren 3 Klicks). Lt. Support wurde das wohl angefangen, aber nicht abgeschlossen. Wir sehen nun alle Lizenzen im VLSC (wenn wir uns mit der @domainat.onmicrosoft.com einloggen). Bestellen sollen wir alle Lizenzen weiterhin auf office@domain.at, da das ohnehin verknüpft ist. Ganz verstanden hab ichs ehrlich gesagt nicht, aber Hauptsache es funktioniert. Danke dir für deinen Input.

Hallo und danke für die rasche Rückmeldung. Ich hab jetzt grade nochmal mit dem Dienstleister gesprochen, der das damals gemacht hat (Tenant Anlage). Der meinte, es gibt keine Verknüpfung unserer Domain (domain.at) mit dem Tenant und der Tenant läuft komplett separat auf @domainat.onmicrosoft.com. Bzgl. Microsoft 365 kann überhaupt nicht mitreden, weshalb ich jetzt leider komplett auf externe Unterstützung angewiesen bin. (was mich ärgert -- hilft jetzt aber nicht). Noch was: Wenn ich mich mit office@domain.at im VLSC via "mit MS Konto" anmelde, dann gekomme ich die Meldung: Schon interessant. Die Anmeldung mit dem Arbeitskonto erklärt mir dann, dass es die Domain nicht gibt....

Hallo zusammen, ich hoffe, mir kann hier jemand helfen. Ich wollte mich heute in unser VLSC einloggen. Sämtliche unserer Bestellungen laufen seit je her über die Adresse (Muster) office@domain.at. Wir sind hier vor rund einem Jahr das letzte Mal eingestiegen, da wir zu diesem Zeitpunkt Terminalserverlizenzen (Openlicense) bestellt hatten und diese Aktivieren / im VLSC hinzufügen wollten. Ein Einstiegsversuch am heutigen Tage (mit oben genannter Adresse) scheitert jedoch. Vorgangsweise: https://www.microsoft.com/licensing/servicecenter/default.aspx Anmelden Pop UP erscheint Auswahl von "Mit Arbeitskonto einloggen" Emailadresse eingegeben Man wird danach weitergeleitet auf eine Seite mit "Konto auswählen". Nachdem die Auflistung dieser Seite die Emailadresse nicht enthält, auf die bei uns die Volumenlizenzen registriert werden wähle ich anderes Konto verwenden und gebe office@domain.at ein Danach wird mir aber gemeldet: domain.at ist nicht in unserem System enthalten. Stellen Sie sicher, dass Sie den Namen richtig eingegeben haben. Unsererseits (intern) wurde nie etwas geändert. Ein Dienstleister hat vor ca. einem Jahr allerdings für MS Teams (5 Lizenzen) einen Tenant angelegt (hier läuft auch ein Azure-Sync), Der Tenant lautet aber auf eine ganz andere Domain. Der Login sieht so aus: admin@domainat.onmicrosoft.com (die Domain wäre hier dann domainat.onmicrosoft.com) -- kein Tippfehler zwischen dem domain und dem at -- da ist kein Punkt dazwischen ;) Das kann ja auch nicht dazwischen funken, oder? Kann sich jemand erklären, was hier ev. passiert ist. In dem Fall wären dann ja alle unsere Volumenlizenzen "weg". Gibts hier eventuell eine neue Regelung, die ich übersehen habe? Kann ja nicht sein, dass ein Konto einfach eingestampft wird, oder? Was kann ich in dem Fall machen? Ich habe schon versucht die MS Hotline zu erreichen, hier wird man aber sobald man die Option VLSC wählt auf eine Internetseite verwiesen, die mir nicht weiterhilft. Danke!

Hi, danke für die schnelle Antwort!!! Alles klar!

Hallo, ich sitze hier vor einem Server 2019 mit installiertem WSUS, der brav Windows und Office Updates aus dem Interneet bezieht und ausrollt. Allerdings zieht der Server offenbar keine Updates für MS Edge. Die Produkte und Klassifizierungen sind so konfiguriert, dass u.a.: Windows > Microsoft EDGE aktiv gesetzt ist. Bei den Klassifizierungen sind allerdings nur: Definitionsupdates Service Packs Sicherheitsupdates Upgrades Wichtige Updates aktiv. Die aktuellsten ADMX Templates sind installiert. Die GPO: Computer Configuration\Administrative Templates\Microsoft Edge Update\Applications\Update policy override default ist disabled, damit alle Edge Updates via WSUS freigegeben werden können. Alle anderen Einstellungen der Edge GPOs stehen auf den Standardeinstellungen und wurden nicht verändert. Muss man ev. im WSUS, damit EDGE mit Updates versorgt wird, die Klassifizierung "Feature Packs" aktivieren, oder sollte das auch in obiger Konfiguration laufen? Danke euch!

Hi, nein hab ich nicht. Ich hab dann unseren externen Support zugezogen, da ich mittlerweile viel zu lange nix mehr mit derartigen Dingen zu tun habe / bevor ich es verschlimmbessere. Der hat das dann via Registry erledigt. Danke für deine Infos, werde ich mir auf jeden Fall ansehen. Ist die Vorgangsweise via Registry unsauber?

war nicht so ganz die Lösung. Das Ausführen von obigem Befehl half nicht. Erst nachdem "StopReplicationOnAutoRecovery" in der Registry auf "0" gesetzt wurde & Server Neustart, ist die Replikation wieder angesprungen. Interessant, dass sämtliche Tests und Diagnostics keine Fehler ausgeworfen haben.

Hi, der DFSR Log hat mir jetzt folgenden Fehler geliefert. Vom DFS-Replikationsdienst wurde die Replikation für das Volume "C:" beendet. Dieser Fall tritt ein, wenn eine DFSR-JET-Datenbank nicht ordnungsgemäß heruntergefahren wird und die automatische Wiederherstellung deaktiviert ist. Sichern Sie zum Beheben dieses Problems die Dateien in den betroffenen replizierten Ordnern, und setzen Sie die Replikation anschließend mithilfe der WMI-Methode "ResumeReplication" fort. Weitere Informationen: Volume: C: GUID: E0498896-7D0C-11E3-93E7-806E6F6E6963 Wiederherstellungsschritte 1. Sichern Sie die Dateien in allen replizierten Ordnern auf dem Volume. Andernfalls gehen möglicherweise aufgrund einer unerwarteten Konfliktauflösung im Rahmen der Wiederherstellung der replizierten Ordner Daten verloren. 2. Setzen Sie die Replikation für dieses Volume mithilfe der WMI-Methode "ResumeReplication" der DfsrVolumeConfig-Klasse fort. Geben Sie hierzu an einer Eingabeaufforderung mit erhöhten Rechten beispielsweise den folgenden Befehl ein: wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="E0498896-7D0C-11E3-93E7-806E6F6E6963" call ResumeReplication

Hallo, ich versuche heute schon den halben Tag lang herauszufinden, weshalb die DFS Replikation (SYSVOL) bei einem meiner 4 DCs nicht funktioniert. Es handelt sich bei den DCs um: SRV-DC1 (Server 2012) SRV-DC2 (Server 2012) SRV-DC3 (Server 2019) -- FSMO SRV-DC4 (Server 2019) Sofern ich im Sysvol-Ordner zb: \\srv-dc1\SYSVOL\domain.local\Policies eine Textdatei ablege, wird mir die Datei auf alle DCs, außer den DC2, repliziert. Das Spiel kann ich mit allen DCs betreiben, kreuz und quer. Der DC2 bekommt das File aber nie. Ebenso bekommen die andren DCs, ein auf dem DC2 abgelegtes File (im SYSVOL Ordner - wie oben beschrieben - ) nicht. Vom Zeitfenster her, ist es jetzt eine Stunde her, dass ich das File auf dem DC2 abgelegt habe. Keine Replikation auf DC1,DC3,DC4. Schau ich mir auf dem DC1 die replsummary an: Quell-DSA Größtes Delta Fehler/gesamt %% Fehler SRV-DC1 51m:09s 0 / 10 0 SRV-DC2 51m:09s 0 / 10 0 SRV-DC3 50m:42s 0 / 10 0 SRV-DC4 50m:42s 0 / 10 0 Ziel-DSA Größtes Delta Fehler/gesamt %% Fehler SRV-DC1 50m:42s 0 / 10 0 SRV-DC2 01m:45s 0 / 10 0 SRV-DC3 :32s 0 / 10 0 SRV-DC4 51m:09s 0 / 10 0 Selbiges auf DC2: Quell-DSA Größtes Delta Fehler/gesamt %% Fehler SRV-DC1 52m:15s 0 / 10 0 SRV-DC2 52m:15s 0 / 10 0 SRV-DC3 51m:48s 0 / 10 0 SRV-DC4 51m:48s 0 / 10 0 Ziel-DSA Größtes Delta Fehler/gesamt %% Fehler SRV-DC1 51m:48s 0 / 10 0 SRV-DC2 02m:51s 0 / 10 0 SRV-DC3 01m:38s 0 / 10 0 SRV-DC4 52m:15s 0 / 10 0 Ein erstellter Statusbericht (DFS Replikaton) bei dem der definitiv aktualisierte Server (DC3) als Referenz galt, bringt mir keine Fehler. Die Mitgliedschaften bzgl DFS Replikation sehen so aus: Die Ordner sind auch nicht voll (Stagingkontingent) sondern belegen grade mal rund 80MB Neu Starten des DFSR Dienstes half nichts, auch kein Neustart des DC2. Aktuell weiß ich nicht weiter. Wo könnte man da eurer Meinung nach noch ansetzen? Jetzt hab ich wenigstens einen Anhaltspunkt: Obwohl die 2012er in rund 2 Monten sowieso "rausfliegen", ist die momentane Konstellation nicht gerade optimal, da ja neu erstellte GPOs dann auch nicht auf den DC2 repliziert werden und es so bei den GPO Umsetzungen zu Fehlern auf den Clients kommt.