Jump to content

Domo

Members
  • Gesamte Inhalte

    156
  • Registriert seit

  • Letzter Besuch

1 Benutzer folgt diesem Benutzer

Letzte Besucher des Profils

1.024 Profilaufrufe

Fortschritt von Domo

Proficient

Proficient (9/14)

  • Erste Antwort
  • Engagiert
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei

Neueste Abzeichen

4

Reputation in der Community

9

Beste Lösungen

  1. Hi! Bei uns war es so, dass effektiv seitens Microsoft etwas gelöscht werden musste - anschliessend haben wir dann gemeinsam mit dem Support zuerst eine klassiche Bereitstellung durchgeführt und diese dann auf Minimal Modern geswitched. Hoffe das hilft dir etwas weiter. Viele Grüsse
  2. Hi zusammen Ich beschäftige mich aktuell gerade etwas mit Intune. In meiner AD OnPrem Umgebung habe ich sowohl Windows 10 wie auch Windows 11 Devices. Das AD wird via Azure AD Connect nach Office365 gesynced, das klappt problemlos. Die entsprechenden Geräte die nach Intune ausgerollt werden sollen, werden auch korrekt als Hybrid Joined angezeigt. Im OnPrem AD habe ich die entsprechende GPO für das automatische ausrollen über die UseCredentials aktiviert. Windows 10 Geräte werden problemlos nach Intune ausgerollt und können dort verwaltet werden. Sämtliche Windows 11 Geräte wollen sich aber partout nicht ausrollen lassen. Die GPO wird auf dem Client korrekt gezogen, in den entsprechendne Eventlogs finden sich keine Fehler. In der Aufgabenplanung sind die gemäss Microsoft KB notwendigen Tasks hinterlegt und werden ohne Fehler ausgeführt - trotzdem findet kein Enrollment statt. Lizenztechnisch sollte soweit alles passen - loggt sich ein Windows 11 User auf einem Windows 10 Gerät ein, wird das Gerät direkt nach Azure ausgerollt. Hat hier jemand noch eine Idee oder einen Input was ich versuchen könnte? Viele Grüsse
  3. Falls mal jemand vor dem gleichen Problem steht hier meine Lösung: Bei der Installation des HybridAgents ist wohl was schief gelaufen was daszu geführt hat, dass in Azure eine Application mit der entsprechenden URL halbfertig eingerichtet wurde. Diese Application war aber weder für den GlobalAdmin noch für den Microsoft Support sichtbar. Der Case wurde schliesslich dem Engineering übergeben - diese haben die fehlerhafte Application entfernt, anschliessend trat dann aber ein anderer Fehler auf. Zuletzt musste die Assistent mit dem klassischen Modus abgeschlossen werden, das hat geklappt. Anschliessend konnte die Hybrid Configuration nochmals durchgeführt werden, diesmal allerdings mit der modernen Topologie - dadurch wurde dann die Config angepasst und jetzt läuft soweit alles wies sollte.
  4. Hallo zusammen Ich bin gerade dabei einen Exchange Server 2016 via Minimal Hybrid nach Office365 zu migrieren mittels modern Exchange-Hybridtechnologie. Beim Installieren/Registrieren trat ein Fehler auf. Nach dessen Beseitigung musste der Server neu gestartet werden. Der HybridConfigWizard schlägt aber nun leider fehl mit der Fehlermeldung " FINISH Time=636.1ms Results=BadRequest {"error":{"code":"InternalUrl_Duplicate","message":"Internal url 'URL.com' is invalid since it is already in use"," Wenn ich via Powershell den Agent abfrage, wird dieser auch als "Aktiv" angezeigt, allerdings ist die Konfiguration noch nicht abgeschlossen. Ich habe dann gemäss Anleitung Microsoft versucht den verwaisten Agent zu deregistrieren: https://learn.microsoft.com/de-de/exchange/troubleshoot/move-mailboxes/cannot-register-hybrid-agent Hier tritt allerdings der Fehler "Error 404 URI not found" auf. Hat hier jemand eine Idee wie ich den Agent deregistrieren oder das verwaiste Setup weiterführen könnte? Danke im Voraus für Eure Inputs. Viele Grüsse
  5. Hi! Ich beschäftige mich aktuell mit Intune und würde in einem ersten Schritt gerne Windows Updates für Windows 10 Clients via Intune starten. Bei der Einrichtung bin ich dabei primär so vorgegangen: Ich habe hier ein Testgerät inkl. Testuser. Das Gerät ist eine lokale AD Domain eingebunden, auf dem Client ist Office365 installiert inkl. eingerichtetem Outlook, OneDrive und Sharepoint. Das Gerät ist im Azure AD ersichtlich. Ich habe nun eine entsprechende Windows Update Ring Policy erstellt und diese auf das Testgerät angewendet - allerdings bin ich nun nicht sicher ob die Policy auf dem Client bereits angewendet wird, da in Intune selbst der Client nicht angezeigt wird sondern nur im Azure AD. Kann mir allenfalls jemand sagen wie ich auf dem Client überprüfen kann, ob die Update Policy wirkt und ob es genügt wenn der Client im Azure AD ersichtlich ist, oder ob ich den Client vollumfänglich in Intune ausrollen muss via Anmeldung im Company Portal? Danke im voraus!
  6. Hi Jan Cooles Tool, danke! Muss ich gleich in meiner KB vermerken Ich konnte das Problem aber zwischenzeitlich lösen. Ich habe auf dem PrintServer folgende Registrykeys gesetzt: reg add hklm\system\currentcontrolset\control\print /v DnsOnWire /t REG_DWORD /d 1 reg add hklm\system\currentcontrolset\services\lanmanserver\parameters /v DisableStrictNameChecking /t REG_DWORD /d 1 Die Keys sind aus dem Microsoft Artikel im Kontext von Druckerfreigaben via CNAME: https://learn.microsoft.com/de-de/troubleshoot/windows-client/printing/errors-connect-to-shared-printer-cname-record Nach einem Serverreboot können Clients eine Verbindung herstellen. Danke für Eure Inputs!
  7. Hi Jan Danke für deinen Input - an den Namen liegt es denke ich nicht. Die Namen sind gleich wie auf dem alten Server, dort klappt soweit alles. Kannst du mir allenfalls noch einen Hinweis geben wie ich an den Logauszug von dir gelange? Vielen Dank!
  8. Guten Morgen Danke für deinen Input, nein wir verwenden direkt den FQDN des Servers. Ich vermute stark einen Zusammenhang mit der GPO, ich habe letzte Woche bei einem anderen Kunden eine identische Installation/Migration durchgeführt. Das hat problemlos funktioniert. Ich kann mir aber nicht erklären wo das Problem liegt - die GPO habe ich schon gelöscht, angepasst und alle gesetzten Optionen auf „disabled“ gesetzt in der Hoffnung dass am Client die Einstellung korrigiert wird - leider ohne Erfolg. Die angepassten GPO wurde aber korrekt übernommen.
  9. Hallo zusammen Ich habe hier einen brandneuen Printserver welcher unter Windows Server 2022 läuft. Nun möchten wir den alten, bestehenden Windows Server 2012 R2 Printserver ablösen. Leider können keine Clients (Windows 10 / Windows 11 / Windows Server 2022) eine Verbindung mit den freigegebenen Druckern herstellen. Die Verbindung bricht ab mit der Fehlermeldung Error 0x709. Wenn ich versuche die Einstellungen auf dem neuen Printserver in der MMC zu exportieren erhalte ich die Fehlermeldung ""The Print server specified could not be found. Please check the name and try again"" Wenn ich lustigerweise den alten PrintServer in der PrinterManagement auf dem neuen Server hinzufügen und dann versuche die Einstellungen vom alten PrintServer zu exportieren erhalte ich die gleiche Fehlermeldung. Mach ich das umgekehrte und füge auf dem alten Printserver in der MMC den neuen Printserver hinzu, kann ich problemlos Einstellungen exportieren und importieren. Bisher war eine GPO im Einsatz um die PrinterNightmare Problematik anzugehen, sodass nur mit bestimmten Druckservern eine Verbindung hergestellt werden kann. Befolgt wurde dabei die Anleitung von Microsoft (https://support.microsoft.com/en-gb/topic/kb5005652-manage-new-point-and-print-default-driver-installation-behavior-cve-2021-34481-873642bf-2634-49c5-a23b-6d8e9a302872). Ich habe bereits die GPO angepasst und den neuen Printserver ergänzt. Die GPO habe ich auch schon testweise gelöscht oder alle Optionen auf deaktiviert gesetzt. Auch das neu installieren sämtlicher Drucker auf dem Druckserver hat leider nicht geholfen. Mit dem alten PrintServer welcher unter Windows Server 2012 R2 läuft kann eine Verbindung hergestellt werden. Habt ihr allenfalls noch eine Idee? Viele Grüsse
  10. Hallo zusammen Bei einigen AD Usern lässt sich heute Vormittag plötzlich Outlook und Office365 generell nicht mehr verbinden. Beim Start von Word erscheint die Anmeldemaske, werden dort die Zugangsdaten eingegeben kommt die Meldung "Leider haben wir zurzeit einige Serverprobleme" - auch Outlook lässt sich nicht mehr starten oder neu einrichten. Bei anderen Usern klappts hingegen. Wird ein lokaler User verwendet, klappt die Anmeldung ebenfalls - das Problem scheint nur bei Domainusern aufzutreten, via Web klappt aber alles problemlos. Auch der Microsoft Support & Recovery Assistent hilft leider nicht - beim Start erscheint die Anmeldebox für einen User in Endlosschleife. Ich habe bereits OS wie auch die Software selbst auf den neusten Stand gebracht, auch eine Neuinstallation von Office hat leider nicht geholfen. In der Umgebung wurde nichts verändert, die Einrichtung wurde vor einigen Monaten via Minimal Hybrid Configuration durchgeführt und hat bis heute Mittag problemlos funktioniert. Habt ihr noch Ideen oder Lösungsansätze? Bin für jeden Hinweis dankbar. Wünsche euch ein wunderschönes Wochenende
  11. Hallo zusammen Ich spiele aktuell gerade etwas mit Intune herum und würde gerne den OneDrive Zugriff von Smartphones aus (iOS / Android) sperren. Einzelne User sollen also keinen mobilen Zugriff auf OneDrive haben. Auf dem Windows 10 / Windows 11 Client sollte OneDrive aber funktionieren. Ich habe bereits mit der AppProtection Policy etwas versucht nur finde ich nirgends die Option den Zugriff komplett zu blockieren, hat mir hier allenfalls jemand einen Tipp in die richtige Richtung Danke im voraus!
  12. Hi Mirko Ja das ist klar - damit die eingesetzte Software aber mit der Modern Authentication klarkommt, muss der Entwickler erst noch etwas arbeiten, ist dann quasi erstmal nicht mehr mein Problem🫣
  13. Hallo zusammen Ich würde gerne in einem relativ neu eingerichteten Office365 Tenant (ca. 1-2 Jahre alt) einen Account via IMAP anbinden - der Account ist lizenziert mit Exchange Online Plan 1. Leider funktioniert das aber nicht - weder im Outlook noch über ein anderes Tool. Ich erhalte als Fehler jeweils "NO LOGIN". Die diversen Inputs aus dem Internet habe ich schon durch - IMAP ist sowohl auf dem Account wie auch organisationsweit aktiviert, habe das Feature auch testweise de- und wieder aktiviert. Der Test via Microsoft Connectivity Analyzer ist erfolgreich, das Konto lässt sich allerdings partout nicht einrichten. Ich habe auch bereits testweise eine Policy erstellt und die Basic Authentication für IMAP aktiviert - hat ebenfalls nicht geholfen. die Security Standards in Azure sind auch nicht aktiv, MFA wird ebenfalls für dieses Konto nicht verwendet. Wenn ich ein Konto aus ein anderem, älteren Testtenant verwende lässt sich das Konto problemlos in IMAP einrichten.. Ich bin gerade echt etwas ratlos - hat hier evtl. noch jemand eine anregende Idee? Danke im Voraus... Habs rausgefunden - musste die Tenantweite IMAP Basic Authentication aktivieren: https://techcommunity.microsoft.com/t5/exchange-team-blog/basic-authentication-and-exchange-online-june-2021-update/ba-p/2454827
  14. Hallo Nils Schade, habe eigentlich versucht alles möglichst umfassend und verständlich zusammenzufassen... Kurzum: 1. Wie berechne ich korrekt und verlässlich bei einem HyperV Host die maximal Anzahl möglicher vCPUs für meine VMs? 2. Wie teile ich diese CPUs unter meinen VMs auf, resp. ist mit einem Performanceboost zu rechnen wenn einer VMs mehr vCPUs zugeteilt werden obwohl im Task Manager keine grossartige Auslastung festzustellen ist? Die beiden anderen Antworten haben mich aber in meiner Annahme und meinem bisherigen Konzept soweit bestätigt, danke euch! Schönes WE wünsch ich allen
  15. Hallo zusammen Ich beschäftige mich gerade etwas mit der Kalkulation von vCPUs unter HyperV und finde irgendwie keine schlüssigen Antworten. In gewissen Guides im Internet finden sich Leute die der Meinung sind, dass pro Core ein vCPU gerechnet werden kann - bei einem Intel Silver 4110 CPU mit 8 Kernen wären das also gerade mal 8 vCPUs. Ich war aber bisher immer der Meinung dass es (eigentlich bei keinem Hypervisor) keine direkte 1:1 Zuteilung oder Abhängigkeit von Cores zu vCPUs gibt da es sich bei virtuellen CPUs um Threads, bzw. Prozessorzeit handelt in welcher die VMs dann denn Prozessor zur Berechnung ihrer Threads nutzen können. Hat eine VM also z.B. 4 vCPUs kann diese VM 4 Threads gleichzeitig auf dem Host CPU rechnen. In anderen Guides findet sich die altbekannte Best Practice dass pro Core 8 vCPUs gerechnet werden können - an anderer Stelle wird diese rule of thumb bereits als "konservativ" bezeichnet. In obigem CPU Beispiel würde das ja (Hyperthreading mal ausgeklammert) zu 64 möglichen vCPUs führen, die das System problemlos stemmen kann. Ich habe bis anhin den VMs im KMU Umfeld jeweils 4 vCPUs zugeteilt und bin damit eigentlich gut gefahren, durch all die verschiedenen Guides und Berechnungsgrundlagen bin ich aber irgendwie total durch den Wind ob dieser Ansatz nicht unterprovisoniert ist. Dass es dabei natürlich auch auf die Workload ankommt, welche die VM stemmen muss ist mir klar - in spezifischen Szenarien in welchen die VM CPU intensive Tasks betreiben muss passe ich die vCPU Konfiguration natürlich an. Ich betrachte hier primär den "mixed use", also etwas AD, Fileserver, ERP mit SQL, etc. im KMU Umfeld mit durchschnittlich 10-15 Usern. Wenn ich bei einem entsprechenden System den Task Manager beobachte wirkt es auf mich auch nicht so als ob hier grossartig Auslastung herrscht - sowohl auf den VMs wie auch auf dem Host. Die Auslastung beträgt im Schnitt an einem normalen Arbeitstag zwischen 30 und 40% - natürlich je nach VM UseCase. Der TaskManager ist dafür nur bedingt geeignet, ist mir klar. Es gibt mir aber doch so einen grundsätzlich ersten Hinweis in Sachen Auslastung der verschiedenen Komponenten. Lange Rede kurzer Sinn; kann mir allenfalls jemand sagen ob mein bisheriger Ansatz grundsätzlich korrekt ist oder ob ich meinen VMs zukünftig mehr vCPUs zuteilen soll? Ich kann mir irgendwie nicht vorstellen dass hier ein grossartiger Performance Boost zu erwarten ist aber wie gesagt - dank all den verschiedenen Angaben bin ich nun wirklich etwas verwirrt und unsicher Herzlichen Dank im Voraus LG Domo
×
×
  • Neu erstellen...