testperson

Hi, die CSV "ins Leere" importieren dürfte auch nicht hilfreich sein. ;) Des Weiteren wirst du deine Aufgabe vermutlich auch nicht mit "Search-ADAccount" lösen können bzw. dürfte es einfachere Wege geben. Daher: Import-CSV (in eine Variable): https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/import-csv?view=powershell-6 ForEach (zum zeilenweise Durcharbeiten der CSV): https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_foreach?view=powershell-6 Get-ADUser (um "PasswordNeverExpires" je User auszulesen): https://docs.microsoft.com/en-us/powershell/module/addsadministration/get-aduser?view=win10-ps Gruß Jan

Hi, hier scheint es ja um eine Windows AD Domäne zu gehen. Im AD ist DNS ein "relativ wichtiger" Bestandteil, der funktionieren sollte. Hier wäre die Frage, ob eine Sekundäre Zone auf einem "Consumer NAS" der richtige Ort (und das richtige Mittel) ist. Wieviele Domain Controller gibt es denn? Wenn es nur einen gibt, dann stelle einen zweiten samt DNS dazu. Was nützt dir DNS ohne Domäne? Wenn es mehrere DCs inkl. DNS gibt wäre die Frage was du mit dem "Backup" später erreichen willst? Gruß Jan

Hi, wieviele Domain Controller gibt es denn? Mehr wie einen DC: Dann prüfe die (Eventlogs auf den) DCs bzgl. Replikation Einen DC: Sind alle Clients betroffen und nur vereinzelte? Gruß Jan

Hi, zum Einen macht man das nicht in den lokalen Richtlinien und zum Anderen arbeitet man nicht mit dem/den Built-In Admin/s. Und solange man nicht am/auf einem Domain Controller "administrieren" muss, nutzt man auch keinen/keine Domänen-Admin/s. Gruß Jan

Hi, nimm einen "Nicht-Built-In-Admin", dann sollte das direkt funktionieren. Gruß Jan BTW.: Wenn das kein DC ist, würde ich auch keinen Domänen-Admin zum administrieren nutzen. ;)

Evtl. waren die zu langsam für WhatsApp oder es lag an dem zweiten DNS in der NIC vom DC. Das kann man jetzt sicherlich nachstellen und analysieren.. Oder auch nicht.

Achso, der Kunde will es genau andersrum.. Jetzt habe ich es auch verstanden. :) An der Stelle kann ich dir nicht sagen, ob das auch bei O365 so ist. On-Prem muss das Konto dann als weiteres Postfach im vorhandenen Exchange Konto eingebunden werden.

Hi, ohne Makro geht das per Vollzugriff auf das Postfach. Dann muss das Postfach aber als eigenes Exchange Konto eingebunden werden, dann wird immer die Adresse des Kontos gewählt in dem man sich befindet. Den Vollzugriff solltest du dann allerdings auf eine Gruppe berechtigen oder eben über die Shell und dabei das "Automapping" deaktivieren. Gruß Jan

Hi, der nutzt dann, sofern man es nicht geändert hat, die DNS Root Server: https://de.wikipedia.org/wiki/Root-Nameserver Gruß Jan

Hi, "notfalls" in einem Script (Batch, VBS, PowerShell, ...) die "iexplore.exe" mit der WebSite als Parameter starten. Gruß Jan

Der IIS logt sicherlich irgendwo mit, wo er den Client hinschickt. Was passiert denn wenn du im Browser einfach mal "http://autodiscover.<deinetestdomain>.<tld.>" aufrufst? Wird der Browser dann korrekt umgeleitet? Ich würde das alles aber definitiv nicht mit dem IIS machen. Solltest du tatsächlich Exchange für Kunden hosten wollen, wird es doch sicherlich irgendwo schon irgendwas für "Load Balancing" geben. Meistens können exchangegeignete Load Balancer auch einen Reverse Proxy bzw. eben solche Dinge mit erledigen.

http Redirect im IIS: https://docs.microsoft.com/en-us/iis/configuration/system.webserver/httpredirect/ Du müsstest dann auch auf "https://redirect.<domain>.<tld> weiterleiten. An dieser Stelle würde ich mal die Zauberwörter "Reverse Proxy" / "Application Delivery Controller" in den Raum werfen.

An den beiden Stellen geht MS zumindest auf beide ein: https://docs.microsoft.com/en-us/exchange/client-developer/exchange-web-services/handling-autodiscover-error-messages https://support.microsoft.com/en-us/help/3211279/outlook-2016-implementation-of-autodiscover Heißt wohl, dass Outlook 2016 beides kann und bei anderen Clients es in der Hand des Entwicklers liegt. ;)

Bei uns ist es in der Tat ebenfalls 302. Hatte irgendwie 301 im Kopf. Auf die Schnelle habe ich nur einen Sonderfall(?) gefunden, der scheinbar für 302 spricht: https://www.mva.ch/support/tech-blog/allgemeines-tech-blog/exchange-autodiscover-redirect-mit-outlook-2016/

Ich bin mir jetzt nicht mehr sicher. Meine aber wir nutzen bei uns 301. Ich gucke morgen mal nach. Es funktioniert jedenfalls. :)

Nein, keinen CNAME (der aber theoretisch auch funktionieren könnte). Einen "normalen" A-Record. Der zeigt dann auf deinen "Autodiscover-Redirect-Dienst" und dort wird eben http://autodiscover.<domain>.<tld> per "http 301 Moved permanently" auf https://hiergibtesautodsicvoer.<domain>.<tld>/autodiscover/autodiscover.xml umgeleitet. Ich glaube @Nobbyaushb meinte mit der Frage "Hoster?" ob Ihr den Exchange "Hosted" für Kunden bereitstellt. ;)

In der Theorie sollte es AFAIK machbar sein, eine "Intelligenz" in Autodiscover zu bringen und entsprechend die Anfragen zum passenden Server leiten. Shared SMTP Namespace würde ich wenn immer möglich vermeiden wollen. Outlook kannst du auch per Registry bzw. GPO zu einem bestimmten "Autodiscover-Glück" zwingen: https://gpsearch.azurewebsites.net/#12629 Bei den mobile Devices könnte es noch ein Ansatz sein, diese per MDM auszurollen und zu konfigurieren.

Kaum macht mans richtig,... :-P

Hi, da musst du vermutlich bei den Herstellern der EAS-Clients der mobilen Geräte auf die Suche gehen. Die werden da aber entweder die "Root-Domain" der SMTP-Adresse (https://<smtpdomain>.<tld>/autodiscover/autodiscover.xml) oder eben die "Autodiscover-Domain" der SMTP-Adresse (autodiscover.<smtprdomain>.<tld>/autodiscover/autodiscover.xml) nutzen. Ob da noch andere Überraschungen lauern, müsste man, wie gesagt, beim entsprechenden Hersteller anfragen oder eben analysieren. Die Outlook App for iOS / Android (bzw. auch das Desktop Outlook) können da z.B. noch Office 365 Endpunkte bevorzugen bzw. ein Autodiscover von Acompli nutzen (https://social.technet.microsoft.com/Forums/security/en-US/cf3a7541-9282-428d-a828-6dbacdcad144/clear-data-from-prodglobalautodetectacomplinet?forum=onlineservicesexchange). Dazu gab es AFAIK auch einen Thread hier. Kurz gesagt: Wenn du Autodiscover nach "Best-Practice" einrichtest, sollte die Chance bei allen Devices gut stehen. Gruß Jan

Genau so wie es in dem Link beschrieben ist, sollst du es ja auch nicht einbinden. Im zweiten Screenshot klickst du einfach auf "Neu..." anstatt auf "Ändern...".

Hi, was willst du denn da verteilen? Autodiscover ist schonmal ein guter Weg. Outlook ist allerdings einer der bescheidensten IMAP Clients die man finden und nutzen kann. Ein IONOS Hosted Exchange Konto wäre sicherlich die schönere Möglichkeit oder eben nicht Outlook. Gruß Jan

Das wird meistens sogar noch zwei weitere Male während der PF-Migration benötigt. Die Übung ist also nicht umsonst. ;)

Hi, wie sieht es aus, wenn <postfach>:\Calendar nutzt? Ansosnten könntest du mit Get-MailboxFolderStatistics <postfach> | where { $_.FolderType -eq "Calendar" } auf die Suche nach dem Namen / FolderPath gehen. Eine weitere Alternative: Erstelle eine Gruppe zur Verwaltung und gebe dieser Vollzugriff. Dann kannst du die Berechtigungen im Outlook setzen. Gruß Jan

Hi, um wieviele Maildomains handelt es sich denn? Der einfachste Weg dürfte sein, von allen Maildomains den autodiscover.<maildomain>.<tld> ins Zertifikat aufzunehmen und die Hosts im DNS entsprechend zu konfigurieren. Ansonsten, wenn es denn http-Redirect sein soll, dann eben für die weiteren Maildomains den Host autodiscover.<maildomain>.<tld> auf ein ausschließlich per http (tcp 80) erreichbares Ziel zeigen lassen und dort eben einen http-Redirect auf https://<dein_Exchange>.<hauptdomain>.<tld>/autodiscover/autodiscover.xml. Natürlich sollte bei allen beteiligten Domain Providern deren Autodiscover deaktiviert werden. Gruß Jan

Hi, im Worst-Case: Profil löschen? Gruß Jan