testperson

Hi, du könntest dir jetzt für alle deine Einstellungen angucken, wo die in den Policies Zweig geschrieben werden und das dann per GPP Registry auf den Client in den "normalen nicht Policy Zweig" schreiben lassen. Oder eben ein Office Paket kaufen, welches die Policies auch anwendet. Gruß Jan

zu 1) Hängt von den gleichzeitigen Anmeldungen und davon ab, was eure Applikationen (Outlook (im Cache Mode), OneDrive, Teams, ...) so im Profil machen. Auf den Broker würde ich die Profile nicht packen. zu 2) Es gibt diverse Scripte, die die Profile aufräumen / "optimieren" bzw. "Maintanance" machen. Alternativ kannst du per "redirections.xml" auch Ausnahmen setzen. Bei Log-On / -Off kannst du auch aufräumen, verlängert den Vorgang aber ggfs. und erzeugt halt zusätzliche Last.

Hi, ich vermute, das geht nicht. Die Frage wäre aber, warum willst du das so machen bzw. was willst du später damit erreichen, wenn der zweite User ohne Postfach eine "fremde Mailbox" im Outlook hat? Für mich klingt das nach einem Problem / einer Anforderung wo vermutlich Outlook und/oder Exchange die falsche Wahl sind. Gruß Jan

OT: Ja, es ist im Server drin. Entwickelt wird da aber wohl nichts mehr, gerade da "die Cloud" es nicht nutzt. Und bzgl. RDS ist ja auch die Frage, was da noch so passiert (und welche Ideen MS noch hat): https://docs.microsoft.com/en-us/azure/virtual-desktop/azure-stack-hci-overview

Hi, AFAIK sind die UPDs auch deprecated. Finde zwar nur den Link zum Azure Virtual Desktop, aber dann wird das On-Premises / im Server ähnlich sein (Azure Virtual Desktop FSLogix profile container share - Azure | Microsoft Docs): Gruß Jan

Da Exchange mindestens einen DC in der entsprechenden Site braucht, brauchst du in diesem Fall definitiv einen DC im RZ. Und an der Stelle wäre ich dann auch - auch bei nur 25 Usern - direkt bei zwei DCs im RZ (und auch vor Ort). Ein weiterer DC vor Ort dürfte im "Worst Case" ein Intel NUC mit einer Windows Server Standard Lizenz sein und im RZ kommt es halt auf die Infrastruktur und Lizenzierung an. Aber auch da dürfte das nicht so ins Geld gehen. Etwas OT: Wäre eine evtl. nötige Software Assurance für Exchange eigentlich auch schon ein Software-Mietvertrag oder falls im RZ SPLA Lizenzen anfallen zumindest eine indirekte Software-Miete bei MS. :-P

Wenn du als Kunde aus Deutschland Exchange online buchst, dann ist dein Datenstandort ebenfalls Deutschland (Berlin / Frankfurt), muss also gar nicht verhandelt werden. Dürfte am ehesten von deinen AD Sites abhängen. Sinnvoll sind jeweils zwei DCs pro Standort bzw. AD Site in meinen Augen aber so oder so.

Hi, also bei 25 Usern wäre ich ja direkt bei Exchange online und würde mir den lokalen Betrieb von Exchange gar nicht ans Bein binden wollen. Gruß Jan

Hat da jetzt jemand einen "." oder ein "@" nach "websupport" vergessen oder ein ".fr" mit ".com" verwechselt? Sieht jedenfalls nach einem klassischen "... kannst du mal eben schnell ... " Problem aus.

Hi, es sind auch definitiv beide IMAP Dienste gestartet bzw. wurden die nach der Konfiguration nochmal neu gestartet? Gibt es eine Firewall oder einen Virenschutz, der ggfs. in IMAP (und Co.) reinpfuschen kann/könnte? Gruß Jan

Hi, schau dir doch bitte mal an, wer den kostenlosen Teamviewer wozu nutzen darf: Commercial Use - TeamViewer Gruß Jan

Hi, auch wenn ein Wildcard Zertifikat da ist, würde ich empfehlen für den Exchange ein eigenes SAN Zertifikat zu nutzen, die kosten ja nun nicht die Welt. Evtl. kommst du an der Stelle auch mit Let's Encrypt zurecht (, wenn es "nur" Zeit kosten darf). Das tolle an Wildcard Zertifikaten ist halt, dass sie überall genutzt werden können. Das Problem an Wildcard Zertifikaten ist halt, dass sie überall genutzt werden. Gruß Jan

"Exchange online" sollte - wie im Artikel beschrieben - deine öffentliche(n) IP(s) "kennen" bzw. sollte(n) diese im SPF Record für deine Domain autorisiert sein. Solange DBEB (Use Directory-Based Edge Blocking to reject messages sent to invalid recipients in Exchange Online | Microsoft Docs) aktiv ist, leider nicht ohne Würgaround. :/

Das ist dann quasi Option 2 aus dem (obigen) Link: How to set up a multifunction device or application to send email using Microsoft 365 or Office 365 | Microsoft Docs

Hi, was ist denn in der Backup Software als Mailserver eingetragen und hast du da evtl. auch Zugangsdaten für einen Exchange online User hinterlegt? Im Endeffekt findest du hier einige Optionen: How to set up a multifunction device or application to send email using Microsoft 365 or Office 365 | Microsoft Docs Gruß Jan

Also geht es in die Richtung, die ich mir gedacht habe. Der Reboot soll eine Applikation wieder ans Laufen bringen. Ich lese allerdings - so glaube ich - heraus, dass es nur ein Würgaround für dich ist. Sollte das "häufig" passieren, solltet Ihr - sofern noch nicht passiert - mit dem Hersteller mal intensiver ins Gespräch gehen, ob das normal ist, was da bei euch passiert. Muss es wirklich ein Reboot sein, um die Applikation wieder ans Rennen zu bekommen oder würde auch ein Neustart eines / mehrerer Dienste/s helfen? Dann wäre ggfs. JEA (Übersicht zu Just Enough Administration (JEA) - PowerShell | Microsoft Docs) noch eine Option. Alternativ wäre die Frage, wie das "Nicht-Funktionieren" festgestellt werden kann und ob sich das per Aufgabe oder ggfs. per Monitoring und passender Aktion hintendran lösen lässt.

Hi, in meinen Augen scheint das Szenario nicht ganz zu Ende gedacht. Was macht der Kollege wenn der Reboot nicht hilft? Ansonsten sollte der Neustart auch ohne Account machbar sein. Da der Kollege Zutritt zum Server hat, könnte er kurz auf Power drücken und den Shutdown abwarten und danach einfach wieder einschalten. Das Admin Passwort sollte keiner haben bzw. gut dokumentiert abgelegt sein. Die Admins sollten passende, personalisierte administrative Accounts haben. Gruß Jan

Hi, das Probleme sind an der Stelle die Installer / Programme, die dann einfach ins Benutzerprofil installieren. Da hat der User halt Ausführen- und Schreibrechte, An der Stelle hilft nur ein Proxy, um den Zugriff auf das Internet zu regeln. ein Application Whitelising bspw. App Locker oder Windows Defender Application Control, um festzulegen, was der User Ausführen darf. Die generelle Frage wäre, was hast du denn am Ende vor? Gruß Jan

Hi, mir ist nicht ganz klar was du beschreibst. Bei dem was ich daraus lese, hat das eine (GPO / Profil) nicht mit dem anderen (AD Sync / Exchange Hybridbereitstellung) zu tun. Evtl. kannst du das nochmal näher beschreiben und/oder sortieren. Dein GPO könntest du um folgende Einstellungen ergänzen: Computer Scope: https://gpsearch.azurewebsites.net/#14861 https://gpsearch.azurewebsites.net/#14863 User Scope: https://gpsearch.azurewebsites.net/#14860 https://gpsearch.azurewebsites.net/#14862 Gruß Jan

Es werden scheinbar diese beiden (vier?) Cipher benötigt (welche im IIS Crypto Best Practice auf W2012 R2 nicht enthalten sind): TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (TLS_DHE_RSA_WITH_AES_256_CBC_SHA) (TLS_DHE_RSA_WITH_AES_128_CBC_SHA) Zumindest hat das Update danach auf die neueste Build funktioniert nachdem ich auf einem System die 1.6.4.0 installiert hatte. Mal abwarten, was beim nächsten Update passiert..

Hi, das sollte z.B. per DNS Policies machbar sein (sofern deine VPN Clients deine Windows DNS bekommen): DNS Policies Overview | Microsoft Docs Gruß Jan

Hi, ein MST samt den Optionen findest du im oben verlinkten Artikel von Master Packager. Den Registry Eintrag musst du auf den Clients entsorgen. Zusätzlich kann es nicht schaden, wenn du im %Appdata%\Microsoft\Teams die desktop-config.json entsprechend beim Login / -out anpasst. Evtl. macht es auch Sinn, eine vorgefertige desktop-config.json vorm/beim Rollout mitzugeben. Generell findest du bei James Rankin eine ganze Menge Infos. Blende dabei einfach "Virtual Apps & Desktops" aus : Microsoft Teams on Citrix Virtual Apps and Desktops, part #1 – installing the damned thing – JAMES-RANKIN.COM Microsoft Teams on Citrix Virtual Apps and Desktops, part #2 – default settings and JSON wrangling – JAMES-RANKIN.COM (Microsoft Teams on Citrix Virtual Apps and Desktops, part #3 – 18 tips for optimizing performance – JAMES-RANKIN.COM) Gruß Jan

Ich war gestern scheinbar blind und habe heute (in Ruhe) auf einem "defekten System" unter "%programdata%\AADConnect" Logs gefunden. Da fängt das Problem mit der Komponente "InstalledADSyncPowerShellHelper" an. Da läuft dann während der Installation "Get-ADSyncScheduler" in den o.g. Fehler und das Log endet mit InstalledADSyncPowerShellHelper Information: 904 : InstalledADSyncPowerShellHelper: exit code: 97. Im nächsten Log fallen weitere PowerShell Scripte auf die Nase und die Deinstallation wird getriggered, die dann scheinbar diesen "unkonsistenten Zustand" hinterlässt. Des Weiteren scheinen hier nur Windows Server 2012 R2 Domain Controller betroffen zu sein. Auf 2012 R2 Memberservern mit AD Connect funktioniert das AD Connect und auch die Updates. In den funktionierenden Umgebungen finden sich unter "%programdata%\AADConnect" verschiedene PowerShell Scripte die scheinbar heruntergeladen und ausgeführt werden. In den kaputten sind diese nicht zu finden. Im Log einer funktionierenden Umgebung wird später noch "https://login.microsoftonline.com" aufgerufen und siehe da auf einem 2012 R2 DC gibt es damit (im IE) Probleme. Schauen wir mal in dieser Richtung weiter..

Hi, ist das Problem evtl. "einfach nur", dass nichts TLS1.2 (oder evtl. auch TSL1.1) spricht in Windows 2000 und dem dortigen IE? Hat MS nicht nahezu überall zumindest TLS1.0 abgeschaltet? Ist bspw.: Err_6.4.5.exe 0x80072EFF # for hex 0x80072eff / decimal -2147012865 WININET_E_CONNECTION_RESET winerror.h # The connection with the server was reset # 1 matches found for "0x80072EFF" Gruß Jan P.S.: Windows / IE Updates von irgendwelchen Quellen laden und installieren.. Nunja.. Dein Bruder betreibt vermutlich einen Honeypot..

Mit der v2 ist das soweit ja klar und i.O., dass die nicht unter Windows Server 2012 R2 läuft. Allerdings lese ich hier (Azure AD Connect: Version release history | Microsoft Docs), dass die 1.1.16.0 / eine aktuelle 1.x bis 08/2022 supported ist: Allerdings steht ein bisschen weiter oben auf der oben verlinkten Seite (leider) auch: Wobei die 1.6.16.0 ja erst ab 31.08.2022 "retired" ist..