testperson

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..

Hi, in verschiedenen Umgebungen läuft AD Connect Version 1.6.16.0 noch auf Server 2012 R2 (und es gibt keine neueren Server OS). Hier verabschiedet sich sporadisch nach Reboots AD Connect und synchronisiert nicht mehr. Das Ergebnis von "Start-ADSyncSyncCycle -PolicType Delta" oder "Get-ADSyncScheduler" hängt komplett im Transcript an. Hier nur ein Auszug: Start-ADSyncSyncCycle -PolicyType Delta >> TerminatingError(Start-ADSyncSyncCycle): "System.Management.Automation.CmdletInvocationException: BAIL: MMS(19316): ..\xparse.cpp(339): 0x80070057 (Falscher Parameter.) BAIL: MMS(19316): ..\ECMARegistry.cpp(26): 0x80070057 (Falscher Parameter.) BAIL: MMS(19316): ..\ECMARegistry.cpp(91): 0x80070057 (Falscher Parameter.) BAIL: MMS(19316): ..\ECMARegistry.cpp(174): 0x80070057 (Falscher Parameter.) BAIL: MMS(19316): ..\server.cpp(9773): 0x80070057 (Falscher Parameter.) Azure AD Sync 1.6.16.0 ---> System.InvalidOperationException: BAIL: MMS(19316): ..\xparse.cpp(339): 0x80070057 (Falscher Parameter.) BAIL: MMS(19316): ..\ECMARegistry.cpp(26): 0x80070057 (Falscher Parameter.) BAIL: MMS(19316): ..\ECMARegistry.cpp(91): 0x80070057 (Falscher Parameter.) BAIL: MMS(19316): ..\ECMARegistry.cpp(174): 0x80070057 (Falscher Parameter.) BAIL: MMS(19316): ..\server.cpp(9773): 0x80070057 (Falscher Parameter.) Azure AD Sync 1.6.16.0 bei Microsoft.DirectoryServices.MetadirectoryServices.UI.WebServices.MMSWebService.GetSchedulerSettings(String& settingsDeserialized, String& errorString) bei Microsoft.IdentityManagement.PowerShell.Cmdlet.GetADSyncScheduler.ProcessRecord() ___________________________________________________________ Get-ADSyncScheduler >> TerminatingError(Get-ADSyncScheduler): "BAIL: MMS(25732): ..\xparse.cpp(339): 0x80070057 (Falscher Parameter.) BAIL: MMS(25732): ..\ECMARegistry.cpp(26): 0x80070057 (Falscher Parameter.) BAIL: MMS(25732): ..\ECMARegistry.cpp(91): 0x80070057 (Falscher Parameter.) BAIL: MMS(25732): ..\ECMARegistry.cpp(174): 0x80070057 (Falscher Parameter.) BAIL: MMS(25732): ..\server.cpp(9773): 0x80070057 (Falscher Parameter.) Azure AD Sync 1.6.16.0" Get-ADSyncScheduler : BAIL: MMS(25732): ..\xparse.cpp(339): 0x80070057 (Falscher Parameter.) BAIL: MMS(25732): ..\ECMARegistry.cpp(26): 0x80070057 (Falscher Parameter.) BAIL: MMS(25732): ..\ECMARegistry.cpp(91): 0x80070057 (Falscher Parameter.) BAIL: MMS(25732): ..\ECMARegistry.cpp(174): 0x80070057 (Falscher Parameter.) BAIL: MMS(25732): ..\server.cpp(9773): 0x80070057 (Falscher Parameter.) Repariert bekommt man das ganze derzeit durch De- und Neuinstallation von AD Connect. Hat das hier schonmal jemand gesehen und einen dauerhaften Fix? Ich habe irgendwie automatische Updates von AD Connect im Verdacht, finde allerdings in den Logs nichts zu Updates. Habe dennoch einmal in einer Umgebung AutoUpgrades deaktiviert (Set-ADSyncAutoUpgrade -AutoUpgradeState Disabled). Der MS Support hält derzeit daran fest, dass AD Connect (v2) nicht auf Server 2012 R2 supported ist. Es geht allerdings um die (aktuellste) v1 Version 1.6.16.0. Vielen Dank und Gruß Jan PoSh_Transcript.txt

Irgendwann muss man auch mal irgendeinen Tod sterben.

Hi, der Transport Agent von messageconcept kann Sender Based Routing: messageconcept ExSBR | Absenderbasierendes Routing für Exchange Ich würde aber auch auf statische IP und DNS zum Versand setzen. Gruß Jan

Hi, ein passendes MST findest du bspw. bei Master Packager: Blog (masterpackager.com) Zum "noAutostart=true": Install Teams using Microsoft Endpoint Configuration Manager - Microsoft Teams | Microsoft Docs Den eigentlichen Autostart entsorgst du dann am besten aus der Registry. Gruß Jan

Ja natürlich. Dann sollte es aber eben auch ein brauchbare/s Softwareverteilung / Endpoint Management geben und eben nicht - wie hier scheinbar angedacht - per GPO. Und an der Stelle wäre ich dann eben dabei und würde es dem User überlassen.

Hi, was ist denn das eigentliche Vorhaben? Warum willst du das über die Host-Datei lösen und nicht einfach einen DNS Server nutzen? Ansonsten: [bool]$check = $false do{ try{ [IPAddress]$IP = Read-Host -Prompt "IP" [bool]$check = $true } catch{ [bool]$check = $false } }while($false -eq $check) Gruß Jan

Joa, der TO schielt ja derzeit auf den Machine Wide Installer. Daher die Info. Wenn ich das richtig beobachte, aktualisiert sich Teams für den User schon beim Machine Wide Installer. Der Installer selber bleibt aber immer auf dem alten Stand. Die Probleme kommen i.d.R. dann, wenn ein neuer Benutzer an diesem Gerät mit veraltetem Machine Wide Installer Teams startet und das Teams so alt ist, dass es sich gar nicht mehr verbinden kann.

Hi, evtl. ein kleiner Hinweis zum Teams Machine Wide Installer: Upgrading Teams Machine wide installer - Microsoft Q&A Bzw. auch: Teams for Virtualized Desktop Infrastructure - Microsoft Teams | Microsoft Docs Gruß Jan