testperson

Hi, kannst du den alten DNS Namen nich einfach mit ins neue Zertifikat aufnehmen? Dürfte nicht die schönste dafür aber die am einfachsten und besten funktionierende Lösung sein. ;) Gruß Jan

Hi, dafür wirst du AAD Connect und vermutlich die Pass-Through Authentication (PTA) brauchen: https://www.jgspiers.com/azure-ad-seamless-single-sign-on/ Gruß Jan

Du bist doch viel zu langsam... Auch mein Test dürfte schneller (und verlässlicher) sein wie deiner.

Hi, was stellt ihr denn da wie um und was habt ihr am Ende mit den Roaming Profiles vor? Ggfs. wäre es ein besserer Ansatz in diesem Zuge die Roaming Profiles abzulösen. Roaming Profiles brauchst du in der Regel seltenst bis nie. Der letzte Login eines Users ist etwas tricky. Da habe ich mir zuletzt was gebaut, was du gerne auseinandernehmen und für dich anpassen kannst: $ADUsers = @() $Output = @() do{ $OU = Get-ADOrganizationalUnit -SearchBase "OU=<hier liegen>,OU=<deaktivierte Konten>,DC=<domain>,DC=<tld>" -Filter * | Select-Object Name, DistinguishedName | Sort-Object Name | Out-GridView -Title "Welche OU?" -PassThru }until($OU) $OU = Get-ADOrganizationalUnit $OU.DistinguishedName Get-ADDomainController -Filter * | ForEach-Object { if(Test-Path -Path $("\\" + $_.Hostname + "\SYSVOL\*")){ foreach($ADUser in $(Get-ADUser -SearchBase $OU.DistinguishedName -Filter * -Properties lastLogon -Server $_.HostName)){ $temp_ADUsers = New-Object PSObject -Property @{ User = $ADUser.Name LastLogon = $([datetime]::FromFileTime($ADUser.lastLogon)) } $ADUsers += $temp_ADUsers } } else{ Write-Host "$($_.Hostname) ist derzeit nicht erreichbar!" -ForegroundColor Red } } foreach($ADUser in $($ADUsers | Select-Object User -Unique).User){ $Output += $ADUsers | ? User -eq $ADUser | Sort-Object LastLogon -Descending | Select-Object -First 1 } $Output = $Output | Sort-Object User $Output | Out-GridView Aber Achtung: Das Script geht jeden Domain-Controller der Domäne durch um sich dort den jeweiligen "lastLogon" zu holen. Die sollten also alle erreichbar sein, da es sonst sicherlich Fehler gibt. Gruß Jan P.S.: Notiz an mich selber: DCs auf Erreichbarkeit prüfen ins Script aufbauen. ;)

Hi, welches OS hat denn der Terminalserver? Sofern es sich um ein Server OS ab 2012 dreht und Disk Fair Share nicht ausgeschaltet wurde, sollte das theoretisch gar nicht erst passieren können. ;) Wenn das OS kleiner 2012 ist, würde ich tatsächlich über ein Update auf ein aktuelles OS nachdenken. Generell würde ich hier aber eher die Ursache suchen und beheben (lassen) anstatt Workarounds zu implementieren. Ggfs. kommst du mit dem Process Explorer / Monitor etwas weiter. Hier könnte auch ein Virenscanner im Spiel sein. Noch eine Frage, wieviele TS für wieviele User gibt es denn? Gruß Jan

Hi, der Essentials Server muss ein Domain Controller sein. AFAIK muss dieser auch zwingend die FSMO-Rollen halten. Es spricht aber nichts gegen weitere DCs neben dem Essentials. Generell sind die Server auch untereinander kompatibel. Mit der angedachten Lösung wirst du dir vermutlich mehr Probleme machen wie lösen. Du solltest einen zweiten DC samt DNS in Betriebnehmen (oder es so belassen). Gruß Jan P.S.: Warum ist denn immer das Internet so wichtig? Auch bei unseren Kunden habe ich häufig das Gefühl, die Firma kann brennend untergehen und die Hauptsache: Das Internet läuft...

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