testperson

Früher hätten wir heute arbeiten müssen. :-P

Hi, du müsstest hier vermutlich zwischen einem Azure Active-Directory (AAD) und einer auf Azure bereitgestellten virtuellen Maschine mit der ADDS-Rolle unterscheiden. Das gleiche könntest du dann mit OfB und z.B. einer Azure VM mit Fileserver Rolle tun. Das dürfte sich pauschal recht schwer beantworten lassen, da jedes Standardnetzwerk irgendwie doch immer eigene Anforderungen hat. Wie / Wo und womit soll denn später auf die Ressourcen zugegriffen werden? Gruß Jan

Hi, Outlook sowie Cachemodus an und auf irgendwas passendes zwischen 3 Tage und 1 Monat (oder ggfs. auch mehr). Hin und wieder gibts auch "nur" OWA, hat dann aber meist nichts mit der Bandbreite zu tun. Gruß Jan

Zur Not wäre da ja ein dritter Server mit eben diesem Dienst denkbar oder der Bitvise SSH Server. Ggfs. auch Tools wie "Delta Copy" o.ä. P.S.: Was mir grade erst aufgefallen ist, Win 10 ab 1803 und Windows Server 2019 bringen in den Optionalen Features einen OpenSSH Server mit.

Hi, ggfs. per StartUp-Script und PowerShell: https://docs.microsoft.com/en-us/powershell/module/wdac/add-odbcdsn?view=win10-ps Gruß Jan

Hi, evtl. eine andere Idee, wäre SSH und somit dann sFTP oder RSync möglich? Gruß Jan

Naja, wenn ich die abgebrochenen wegen der XML abziehe und es komplett dem AV (und meiner Naivität) in die Schuhe schiebe, siehts bei mir ja auch nicht nach Katastrophe aus: 2 Probleme bei 64 Updates.

Das Problem mit der "EnterpriseServiceEndpointsConfig.xml" lag scheinbar an neuen Features ("Advanced Threat Control/Protection") des BitDefender AVs. Deaktivieren des AVs schaltet scheinbar nur den On-Access-Scan aus. Jedenfalls hatte eine "epsecurityservice.exe" die Finger noch an nahezu jeder Datei, die vom Setup angefasst wurde. Es wurde besser als %WinDir%\Temp\ExchangeSetup ausgeschlossen hatte. Ebenfalls scheint der BitDefender während er deaktiviert ist irgendetwas zu tun, dass er sich aktiviert, "rumpfuscht" und wieder deaktiviert. Hier warte ich aber noch auf eine Rückmeldung vom Support.

Am Wochenende ist mir dann noch das AD-Objekt "Exchange Online-ApplicationAccount" auf den Fuß gefallen. Das Setup konnte beim Vorbereiten der Organisation den Account nicht finden und ihn dann nicht anlegen, da das Objekt schon vorhanden war. Den tatsächlich vorhandenen Account verschoben und Setup neu gestartet brachte den Fehler, dass es den UPN "Exchange_Online-ApplicationAccount@domain.tld" bereits gibt. Nach Umbenennen des Objektes (Name und UPN) konnte das Setup dann durchlaufen. Bis jetzt ist mir auch noch nichts in den Eventlogs dort aufgefallen. Ggfs. noch als Hinweis: Der Kunde ist komplett On-Prem und nicht Hybrid. Zwischenzeitlich war das Setup der Meinung eine Hybrid-Bereitstellung erkannt zu haben, was es beim erfolgreichen Update allerdings nicht mehr tat. P.S.: Was bin ich froh, dass nur noch zwei Exchange Server auf der To-Do Liste sind. :)

Der wurde sogar schon in der ersten Antwort hier verdächtigt... ;)

Das wird alles ein bisschen arg OT, allerdings kam auf mich noch nie eine GL / Fachabteilung zu und sprach, man mappe mir das Laufwerk anhand eines AD Attributes per IP-Adresse anstelle des Hostnamens. Wird eurer GL vor auswärtigen Terminen auch noch das Pferd gesattelt oder seid ihr schon beim Ottomotor angekommen? :-P

Daher auch in Anführungszeichen. ;) In meinen Augen ist die "einfachste" Lösung die erste Antwort. Bzw. fehlen hier tatsächliche Gründe dagegen. "Leider nicht gewünscht" ist halt kein Grund. Also in meinen Augen nicht. :)

"Einfach": Get-GPRegistryValue: https://docs.microsoft.com/en-us/powershell/module/grouppolicy/get-gpregistryvalue?view=win10-ps Set-GPRegistryValue: https://docs.microsoft.com/en-us/powershell/module/grouppolicy/set-gpregistryvalue?view=win10-ps Wenn dann noch Preferences im Spiel sind, wäre noch was XML im Spiel. In meinen Augen gehst du völlig falsch an das Thema ran. In der IT ist es oft der bessere und einfachere Weg miteinander zu reden anstatt stur "zu lösen".

Und das wünscht wer? Mit dem kann man nicht reden und deshalb muss man es auf biegen und brechen (komplex) machen?

Hi, befindet sich der Rechner denn im internen Netz oder ist der Client außerhalb? Dann stimmt entweder etwas mit Autodiscover oder beim NAT ggfs. auch Reverse Proxy nicht. Was sagt denn der MS RCA: https://testconnectivity.microsoft.com/ Gruß Jan

Hi, wäre es hier nicht einfach auf dem Server einen Ordner samt Freigabe (z.B. Shares) zu erstellen und dort dann die Unterordner "Stadt X", "Stadt Y", "Stadt Z". Als Laufwerk verbindest du dann weiterhin Z: mit der Freigabe "\\<SERVER>\Shares". Gruß Jan

Hi, die Lösung steht doch recht klar und verständlich im ersten Satz des Hinweises: Benutze einen User Account der keine administrativen Rechte hat. Gruß Jan P.S.: Ohne das Konstrukt näher zu kennen, würde ich vermuten, dass "Ich benutze WIN Server 2016 (Strato)" nochmal überdacht werden sollte.

Jetzt gibt es auch bei mir die ersten zwei Exchange 2016 Server, auf denen der Telnet Client installiert war (https://www.mcseboard.de/topic/216202-exchange-2016-cu13-neustart/?tab=comments#comment-1384935)... Die mir bekannten "Reboot Pending" Stellen in der Registry waren jedenfalls sauber aber das Setup war immer der Meinung es stünde ein Reboot aus.

Unter Umständen ist Outlook hier ja auch der falsche Client bzw. Exchange das falsche Produkt für dieses Postfach. Ggfs. wäre das Postfach besser in einem Ticket System o.ä. aufgehoben. Ansonsten könnte man halt prüfen, ob sich das irgendwie mit "Address Rewrite" lösen lässt bzw. ob in Exchange Online Address Rewrite möglich ist.

Du sollst halt "T0" nicht über den "Object Picker" (Die "..." im Dialog) auswählen, sondern im Eingabefeld mal "F3" drücken oder direkt %LogonDomain%\T0 eintragen. ;)

ja. Da es sich beim Terminalserver aber um ein Server OS handeln wird, wäre App Locker die bessere Wahl. Sperren von DOC/DOCM/etc. im Userprofile könnte Probleme mit Normal.dot und ggfs. in %temp% geben. (Nur eine Vermutung, müsste man testen.)

Hi, in deinem Fall hast du bzw. der Provider die Mail ja schon angenommen. Das ist Mist. Hier sollte der Provider die Mails direkt ablehnen. Und generell: Entsorge den PopConnector und du hast viel weniger Probleme und viel mehr Möglichkeiten. Gruß Jan

Welcher AV ist es denn? Dann könnte man ja prüfen, ob der sowas kann. Wenn die PowerShell CMDlets laufen: Get-Package | ? Name -imatch "<Name des AV Paketes> | Uninstall-Package Kannst du testweise einen zweiten DC aufsetzen und dort das Verhalten prüfen?

Hi, die UPDs sind für den Fileserver ja lediglich eine VHDX. Den Inhalt sieht in dem Sinne ja nur der Terminalserver bzw. der User. Das kann vermutlich so auch nicht funktionieren. Hier wäre die Frage, was du da prüfst bzw. was du da erreichen willst. Ggfs. gibt es andere Ansätze. Gruß Jan

Ja bricht ab. Ist mir aber bisher nur beim Update via "setup.exe /m:upgrade /IAccept..." passiert (Wobei ich in 9 von 10 Fällen per Commandline geupdated habe und in 4 Fällen ist es jetzt passiert). Anschließender Neustart über die GUI macht dann direkt weiter und schließt das Setup ab. An der Stelle ist es nur etwas "unschön", dass das Fenster der GUI kommentarlos geschlossen wird und man nochmal in die ExchangeSetupLog gucken sollte. ;) Grade hat sich noch ein Setup verabschiedet: [09.23.2019 17:02:32.0713] [1] Executing: Add-FirewallException -FirewallRule (New-Object Microsoft.Exchange.Security.WindowsFirewall.MSExchangeRPCByPortRule) [09.23.2019 17:02:32.0751] [1] The following 1 error(s) occurred during task execution: [09.23.2019 17:02:32.0751] [1] 0. ErrorRecord: Der Typ [Microsoft.Exchange.Security.WindowsFirewall.MSExchangeRPCByPortRule] kann nicht gefunden werden. Stellen Sie sicher, dass die Assembly, die diesen Typ enthält, geladen wird. [09.23.2019 17:02:32.0751] [1] 0. ErrorRecord: System.Management.Automation.PSArgumentException: Der Typ [Microsoft.Exchange.Security.WindowsFirewall.MSExchangeRPCByPortRule] kann nicht gefunden werden. Stellen Sie sicher, dass die Assembly, die diesen Typ enthält, geladen wird. bei System.Management.Automation.MshCommandRuntime.ThrowTerminatingError(ErrorRecord errorRecord) [09.23.2019 17:02:32.0763] [1] [ERROR] The following error was generated when "$error.Clear(); Add-FirewallException -FirewallRule (New-Object Microsoft.Exchange.Security.WindowsFirewall.MSExchangeRPCByPortRule) " was run: "System.Management.Automation.PSArgumentException: Der Typ [Microsoft.Exchange.Security.WindowsFirewall.MSExchangeRPCByPortRule] kann nicht gefunden werden. Stellen Sie sicher, dass die Assembly, die diesen Typ enthält, geladen wird. bei System.Management.Automation.MshCommandRuntime.ThrowTerminatingError(ErrorRecord errorRecord)". [09.23.2019 17:02:32.0763] [1] [ERROR] Der Typ [Microsoft.Exchange.Security.WindowsFirewall.MSExchangeRPCByPortRule] kann nicht gefunden werden. Stellen Sie sicher, dass die Assembly, die diesen Typ enthält, geladen wird. [09.23.2019 17:02:32.0764] [1] [ERROR-REFERENCE] Id=AllRolesCommonFirst___f557448f44964e5eaa5dba792a3c4f09 Component=EXCHANGE14:\Current\Release\Shared\Datacenter\Setup Hier hat auch direkter Neustart der Setup.exe geholfen. 5 von 11 ist noch keine gute Quote. :)