cj_berlin

Moin, Deine Ausführungen sind etwas konfus, vermutlich hat deswegen niemand geantwortet. Re Anzeige in Outlook: Was passiert denn, wenn Du ein neues Outlook-Profil anlegst? Meiner Erfahrung nach ändert sich der Name in Outlook nicht nachträglich, wenn man ihn serverseitig ändert. Re "e-Mail-Alias des Azure": Mit der Formuilierung kann ich nichts anfangen. Aber einen Mail-Alias kannst Du immer löschen, wenn er Dich stört, solange es sich dabei nicht um die primäre SMTP-Adresse handelt. Für alles Weitere müsste man wissen, wie Dein AADConnect konfiguriert ist, wie Deine User-Pflege im AD funktioniert usw. Den Passus "Nachdem ich den Fehler bemerkt habe und den User auf dem AD Controller auch als user@unserdomain.de angelegt habe" kann ich gerade nicht visualisieren. Was hast Du denn genau wo geändert? Übrigens: Es gibt keinen "AD-Controller", es heißt "Domain Controller".

...also vermutlich "execute"?

Genau. Das ist die Anleitung, die Du brauchst. Möchtest Du zusätzlich noch RDWeb mit MFA absichern, kannst Du die bisherige Einrichtung beibehalten, aber dann muss ein User, der den Desktop über RDWeb aufruft, zweimal MFA bestätigen.

Schon deshalb, weil die URL nicht logisch (welcher Server wird hier wohl angesprochen?) sondern als Text-Patterns ausgewertet werden...

Nee.. bei euch auch?

...und bitte auf Cross-Posts hinweisen: https://social.technet.microsoft.com/Forums/de-DE/217089e6-b8da-4ec7-a676-91fe902cfc00/site-im-iis-auf-ssl-umstellen-und-zertifikat-erstellen?forum=iisde

Moin, Dein Link passt aber nicht zu Deiner Beschreibung. Wenn Du MFA mit RDG machen willst, musst Du MFA in den dortigen NAP einbinden. Die Authentifizierung am RDWeb nützt Dir da nichts.

Moin, wo hast Du denn "gesperrte Websites" gesetzt? Hört sich ja so an, als hättest Du zuerst was probiert und erst DANN die Mozilla-ADMXen hinzugefügt... was immer Du da gemacht haben magst, auf FireFox wird es keinen Effekt haben. Die FireFox-Policy hat die Einstellung "WebsiteFilter", da musst Du Deine zu sperrenden Seiten versenken, und zwar als Patterns, also http*://*.heise.de/*

Moin, ohne jemanden an Bord zu haben, der davon Ahnung hat, wird das ganze vermutlich scheitern. In jedem Fall aber musst Du die bestehende Replikationsbeziehung vor der Abschaltung des alten Servers sauber abräumen und sie zum neuen Server neu aufbauen. Die Daten in den replizierten Ordnern könntest Du hingegen durch Kopieren oder sogar Umhängen der Platten übernehmen und Dir so das initiale Seeding sparen.

Die Vision ist ja vor gefühlt 10-15 Jahren schon mal formuliert worden: Hersteller stellen ihre Software als virtuelle Appliances oder Container Images zur Verfügung, und der Kunde kann im Troubleshooting-Fall eine komplette Appliance dort einliefern... Vioelleicht kommen wir irgendwann auch dahin Eine komplette K8-Umgebung braucht man aber nicht, wenn nicht die automatisierte Skalierung das Ziel ist, sondern einfach das Verwenden vorgefertigter Container-Images. Noch ist Docker nicht tot, aber klar: in 2-3 Jahren muss man Kubernetes (oder Ähnliches) dann zwingend haben.

USMT i USMT ist Teil des ADK. Wenn Du den ADK-Installer startest, musst Du auswählen, welche Komponenten heruntergeladen werden, und eine davon ist USMT.

Moin, zwei Dinge: 1. es kann rein technisch kein Exchange-Postfach ohne AD-User(objekt) geben 2. die Exchange-CALs sind pro Benutzer (oder pro Gerät). Ein Benutzer ist dabei eine Person, kein Eintrag in einer Datenbank. Wenn Du also 1000 Leute hast, die sich alle ein Postfach teilen, brauchst Du trotzdem 1000 CALs.

Noch nicht (aber ich bin ja auch nicht in der Runde). Gemunkelt wird, dass wir am Abend vor der Ignite (und der Rest der Welt dann am nächsten Tag) was hören könnten... Und übrigens, wie von @NorbertFe bereits angerissen: Inplace oder nicht, es ist aber schwer denkbar, dass Exchange jemals ein Inplace-Upgrade des darunterliegenden OS erlauben wird. Daher: Upgrade heute: 2016 auf 2012R2 -(Migration)-> 2019 auf 2019 -(Inplace)-> vNext auf 2019 ==> EOL = 09.01.2029 wegen Server 2019 Upgrade nächstes Jahr: 2016 auf 2012R2 -(Migration)-> vNext auf 2022 (vermutlich/hoffentlich) ==> EOL = 14.10.2031

OK, also ihr macht - entweder jetzt eine Migration, mit der ihr nichts gewinnt, und später (aber bis Oktober 2025) vielleicht ein Inplace, das vielleicht gelingt, vielleicht aber auch nicht - oder später (aber bis Oktober 2025) eine Migration, die höchstwahrscheinlich gelingt. Heißt, ihr wollt bis 2025 zwei Schritte machen, von denen einer für Exchange absolut neu ist, statt einem, der nach dem bekannten und erprobten Schema ablaufen wird?

Nur aus Interesse: Welches Killer-Feature treibt euch dazu? Ansonsten, wie bereits mehrfach angemerkt: Die Supportability Matrix ist die Bibel. Was nicht drauf steht, ist NICHT supported.

In der Berliner Verwaltung sagt man dazu "Probeechtbetrieb".

Ich kenne ganz viele, aber bei der Hälfte stehen in dieser sogenannten DMZ dann virtuelle Systeme, die Mitglied im AD sind Und wenn man dann sagt "Nein, Sie haben keine DMZ, sondern nur ein LAN-Segment mit Öffnung nach außen", sagen sie dann "aber der Hypervisor ist getrennt, und die Switche auch"...

Anscheinend haben die Jungs das vergessen Ich finde das zumindest nicht.

Auch für DataCenter-Kunden tickt schon die Uhr:

Moin, Get-ACL / Set-ACL oder, besser, https://www.powershellgallery.com/packages/NTFSSecurity

Verstehe ich nicht. Wenn das VPN Verbindungen zu einem Host zulässt, warum sollte es keine Verbindungen zu mehreren Hosts zulassen können?

Hmm. Aber warum können die VPN-Clients nicht jetzt schon auf die gesamte Farm zugreifen? Funktioniert die Namensauflösung nicht oder haben die VPN-Clients nicht auf alle Server der RDS-Bereitstellung Zugriff?

Moin, es heißt "Broker" mstsc /admin funktioniert nur, wenn der Zugreifende lokaler Admin auf dem Zielserver ist ist der Zugreifende nicht Admin, kannst Du den Broker nicht umgehen Lösungen: Zugriff auf die gesamte Farm per VPN ermöglichen Auf VPN verzichten und RDG einsetzen, macht das ganze auch performanter Den Standalone-Terminalserver nicht als Teil einer Farm bereitstellen.

Du verwechselst hier Ursache und Wirkung. Die Frage sollte lauten "Habe ich eine Chance, die CCNA-Prüfung zu bestehen, wenn keine CISCO-Erfahrung vorhanden ist, nur mit allgemeinem Wissen zu Switching & Routing? Ich habe es selbst noch nie versucht, habe aber die Prüfungsunterlagen mal gelesen und würde daher sagen, eher nein.

Doku lesen, siehe obigen Link. Dort wird der Parameter -Credential beschrieben, der die Authentifizierung ermöglicht.