snoopy16

Danke für Eure Tips, besonders für die PDF. Werde das mal ausprobieren mit SplitDNS.

vor 8 Minuten schrieb NilsK:

beste Option: Lass das bleiben und mach es richtig. Das wird dir sonst auf die Füße fallen. 

würde es gerne "richtig" machen, sobald am Standort Internet angekommen ist.

vor 9 Minuten schrieb NilsK:

Andere Option: Stell halt ein Zertifikat auf den Zielnamen aus. Dazu gibt es genügend Tools, im Zweifel OpenSSL.

kann ich nicht im Server ein Zertifikat auf autodiscover.domain.de austellen und einen DNS-Eintrag machen, der nur die Subdomain autodiscover.domain.de auf den Server umleitet?

Hallo,

Ich habe folgendes Problem:

Outlook 2016 ist mit einem Exchange Server 2016 Standard außerhalb der Domäne verbunden.
Der Exchange Server verwendet ein selber ausgestelltes Zertifikat.

Um den Assistenten im Outlook  2016 auszutricksen und mich per autodiscover mit dem Exchange Account zu verbinden,
habe ich die Hosts Datei des Client (ausserhalb der Domäne) folgendermaßen angepasst (ja, ich weiß, es ist schmutzig, aber eine schnelle wenn auch keine dauerhafte Lösung).

192.168.4.10  SERVERNAME.domain.local
192.168.4.10  autodiscover.domain.de

Nun kann ich mich zwar per Autodiscover verbinden und alles funktioniert wunderbar, bis auf den nun erscheinenden Sicherheitshinweis:
 
Sicherheitshinweis:
autodiscover.domain.de

Das Sicherheitszertifikat stammt von einer vertrauenswürdigen Zertifizierungsstelle. (OK)
Das Sicherheitszertifikat ist gültig (OK)
Der Name auf dem Sicherheitszertifikat ist ungültig oder stimmt nicht mit dem Namen der Website überein. (NICHT OK)
Möchten Sie den Vorgang fortsetzen?

Bestätige ich mit ja, kann man auch wunderbar mit Outlook arbeiten, bis nach einiger Zeit ja wieder der Sicherheitshinweis aufpoppt.
Das ist logisch, der Fehlergrund steht ja auch in der Fehlermeldung (Der Name auf dem Sicherheitszertifikat ist ungültig oder stimmt nicht mit dem Namen der Website überein)

Schaue ich mir das Zertifikat an, steht dort

Antragsteller:
SERVERNAME

Alternativer Antragsstellername:
DNS-Name=SERVERNAME
DNS-Name=SERVERNAME.domain.local

Der öffentliche Domainname taucht nirgends auf.

habe das Serverzertifikat auch in den Stammzertifizierungspfad des lokalen Computer kopiert, aber das ändert ja auch nichts an der Sachlage.

Wie umschiffe ich nun das Problem. Möglichst ohne öffentliches Zertifikat?  (Server ist sowieso nicht öffentlich zugängig, nur per VPN ins interne Netz)

vor 13 Minuten schrieb DocData:

Lesen, lesen, lesen. Sorry, aber gehört einfach dazu

die Message ist angekommen und ich suche nicht den Weg des geringsten Widerstandes, denn der wäre es einfach hinzuklatschen ohne Security Bedenken. Ich wollte einfach nur ein paar Tips von Leuten die es vielleicht besser wissen.

Trotzdem danke...

vor 5 Minuten schrieb MurdocX:

Mit einem Domänen-Admin kannst du schon die Installation einfach durchklicken. Das ist keine Kunst. Wenn die "ka**e" mal am dampfen ist

Dann beschreibe doch mal bitte, wie Du das machen würdest. Herabwerten ist immer sehr einfach

vor 5 Minuten schrieb kamikatze:

Viel Erfolg

Danke

vor 13 Minuten schrieb kamikatze:

Ich erinnere an den Versuch den Exchange mit einem lokalen Admin zu installieren. Dein Admin benötigt auf jeden Fall für die Inst. Enterprise-Admin-Rechte. 

Ja, hatte das etwas falsch verstanden. Besorge mir das Buch

vor 15 Minuten schrieb kamikatze:

Hol Dir einfach jemanden der dich "an die Hand nimmt" und lerne dadurch.

Dachte eigentlich das ich das hier in dem Forum finde, aber da fehlen ja natürlich die Grundlagen.

Manchmal macht man auch Aussagen, die falsche verstanden werden.

Nun gut, dann nehme ich das nun so hin und bringe mir die "Grundlagen" bei.

vor 11 Stunden schrieb kamikatze:

Schau am Besten wie Norbert schon schrieb auf Franky´s Web nach - da ist alles sehr gut beschrieben

Habe ich schon, da ist aber auch nicht beschrieben, was ich wissen möchte. Mir geht es hier erstmal NUR um die Benutzer und ihre Mitgliedschaften/Berechtigungen, welche eingerichtet werden müssen um auf dem "member server" Exchange einzurichten, und zwar NICHT NUR daß es irgendwie läuft, sondern auch möglichst sicher gegen Angriffe während des späteren Betriebes ist. Dies steht nicht auf Franky's Web (habe es zumindest nicht gefunden), aber natürlich im MS Technet (muß man nur finden). Einfach installiert habe ich das auch schon vorher, allerdings als Testsystem auf einem Server, worauf alle Rollen liefen, was ja aber bekanntlich nicht sicher ist. Da stellte sich diese Frage nach den Berechtigungen auch nicht, weil da nur ein einziger Administrator war (weil Testsystem und Sicherheit egal war).

Das ist jetzt auch nur ne Testumgebung, aber soll auch "Vorlage" für ein Produktivsystem werden und deshalb möglichst sicher sein.

Ich kann mir auch nicht vorstellen, daß dies so schwierig sein soll, man muß es halt bloß wissen und deshalb frage ich mal die Profis hier, weil ich da (noch) nicht so tief drin stecke.

Ich habe irgendwo gelesen, es wäre besser (zumindest schadet es nicht), das AD vorher vorzubereiten und danach die eigentlich Installation zu starten. Wie man es macht ist ja auch egal. Auch bei nur einem DC (wie hier).

Wäre für hilfreiche Tips sehr dankbar. Hilfreich ist natürlich "lese es im Technet nach", noch besser wäre eine Angabe wo, aber das finde ich dann auch selber raus. Nicht hilfreich sind Aussagen wie "such dir einen, der es für dich macht". Es geht mir um das Wissen, wie ich es selber mache, deshalb bitte nur produktive Tips.

So und nun lese ich erstmal, bevor ich wieder unqualifizierte Fragen stelle (nicht das ich das aber auschließen würde ;).

vor 15 Minuten schrieb NorbertFe:

Du kannst keinen lokalen Account für die Installation nutzen. Wie gesagt, nutze doch die whitepaper von ms. 

Lokaler Account geht nicht, doch mit welchem Account kann man es dann installieren, nachdem das AD-Schema angelegt ist.

Sinn der Sache ist es dem Exchange Server nicht zuviel Rechte auf das AD zu geben. Könnte es sonst ja einfach mit dem AdminSchema machen, aber das ist ja wohl nicht sehr sinnvoll.

Ist ein steiniger Weg, wenn alle nur wissen, wie man es nicht macht, anstatt mal konkret zu werden, wie man es korrekt umsetzt, außer nur auf Whitepaper hinzuweisen, die ich mir dann wohl mal genauer durchlesen muß.

OK, dann lese ich das nach...

vor 2 Stunden schrieb Dukel:

Für Exchange kannst man das zwei Teilen. Die AD / Schema Preperation kann mit einem AD-Administrator vorbereiten und das Setup mit einem Exchange Administrator, welcher nur auf dem Exchange Server Admin Rechte hat, aber sonst keine weiteren Rechte.

Habe das dann falsch verstanden, Also nicht mit einem lokalen Administrator sondern mit einem Exchange Administrator, welcher durch die Schema Preparation angelegt wurde. Das ergibt auch mehr Sinn.

vor 6 Minuten schrieb DocData:

Nein, aber „wir“ haben einen nennenswerten Teil unseres Lebens damit verbracht uns das notwendige Wissen anzueignen - ohne Foren. Durch lesen, in Testumgebungen, durch Schulungen die Geld kosten. 

geht mir genauso, aber ist es nicht Sinn eines Forums gezielt zu fragen und nicht alles aus Büchern zu lernen.

Hast Du auch eine Antwort auf meine letzte Frage?

Ich habe nun auf VM-EXCHANGE einen neuen Administrator für die Installation von Exchange (AdminLokal) erstellt, der nicht in der Domäne ist.
Auf VM-DC habe ich im Active Directory einen neuen Benutzer für die Schema-Vorbereitung erstellt (AdminSchema).
AdminSchema habe ich die Mitgliedschaft der Gruppen Domänen-Admins,Organisations-Admins und Schema-Admins zugewiesen, nachdem ich mich auf VM-EXCHANGE (member-server) mit AdminSchema in der Domäne angemeldet habe.

Ich möchte jetzt nichts falsch machen, daher hier kurz meine Vorgehensweise:
Für Exchange müssen ja noch diverse Vorraussetzungen erfüllt werden, welche ich nun als AdminLokal auf auf VM-EXCHANGE per Powershell installieren würde:

Install-WindowsFeature NET-WCF-HTTP-Activation45, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, RSAT-ADDS

 
Dann noch UCMA Runtime 4 und NET Framework 4.7.x ebenfalls als AdminLokal installieren.

Nach einem Neustart würde ich mich auf VM-EXCHANGE als AdminSchema (in der Domäne) einloggen um das Active Directory Schema zu aktualisieren und die Domänenstruktur vorzubereiten.

Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
Setup.exe /PrepareAD /OrganizationName:"ExchangeOrganisationName" /IAcceptExchangeServerLicenseTerms
Setup.exe /PrepareAllDomains /IAcceptExchangeServerLicenseTerms

Anschließend wieder als AdminLokal die eigentliche Exchange Installation starten.

Ist das korrekt so?
 

vor 5 Minuten schrieb mba:

Nicht mehr aktuell?

 

Ich hoffe das wird eine Spielinstallation

Da sich der Thread auf die Installation des Exchange Servers bezieht, geht es auch darum dem "member server'", was ja ein weiter Begriff ist, die Rechte einzuräumen, die er benötigt und NICHT mehr.

Deshalb ja meine Frage, ob ein eigener Benutzer angelegt werden sollte. Bisher existiert ja nur der eine DomänenAdministartor auf VM-DC.

Ja, aber ihr habt Recht, das steht sicherlich auch in den Whitepapers bei MS, wenn man es mal gefunden hat.

vor 11 Minuten schrieb Nobbyaushb:

Dom-Admin - nachdem der Server Member-Server der Domäne ist

Danke, versuche das dann...

vor 2 Minuten schrieb mba:

Du weißt wie man einen PC(!) einer Domäne hinzufügt?

Ja, wie ich aber schon schrieb geht es mir um die Rechte des Benutzers für die Exchange Installation.

vor 1 Minute schrieb Nobbyaushb:

Nimms mir bitte nicht übel - aber wenn du schon nicht weißt, wie man einen Server zum Domänen-Member macht, möchtest du Exchange installieren?

 

Dir fehlen leider so viele Grundkenntnisse, die man in einem Forum nicht vermitteln kann.

Na vielen Dank, dir wurde es bestimmt in die Wiege gelegt.

Mir geht es hier um die Rechte des Benutzers für die Exchange Installation, da ich mich nicht als (bisher einziger) DomänenAdministrator anmelden möchte.

Wenn ich so viel wüsste wie Du, würde ich nicht hier fragen.

vor 6 Minuten schrieb mba:

So wie Du einen Client in die Domain bekommst 

 

Als Client melde ich mich einfach als Benutzer in der Domäne an.

Darum geht es mir ja, mit welchem Benutzer melde ich mich dann an der Domäne an, bzw. welche Rechte muss der haben? Doch nicht als Domänen Admin, oder?

Habe gelesen, der Benutzer für die Exchange Installation sollte Mitglied in folgenden Gruppen sein

• Domänen-Admins
• Organisations-Admins
• Schema-Admins

Dann sollte ich als auf VM-DC mit dem Active Directory Verwaltungscenter einen neuen Benutzer für die Exchange Installation anlegen und diesem die oben erforderlichen Rechte zuweisen. Dann auf VM-EXCHANGE mit diesem Benutzer in der Domäne anmelden und Exchange installieren wie z.B. hier zu lesen.

https://www.windowspro.de/roland-eich/anleitung-ms-exchange-server-2016-windows-server-2016-installieren

Oder liege ich falsch?

In den MS Docs steht man sollte den Exchange nur auf "member servers" installieren. Wie mache ich aus VM-EXCHANGE einen member server?

Habe Exchange mal auf einem System installiert, wo allerdings ALLES inkl. AD etc. lief, was ja aber nicht so empfehlenswert ist.

Whitepaper tlw. gelesen, aber es sehr, sehr viel.

Moin,

Folgende Konfiguration ist gegeben:
Windows Server 2016 Standard als Hyper-V Host mit 2 VM (VM-DC und VM-EXCHANGE) auf denen ebenfalls Server 2016 Standard (Desktop) läuft:
Auf VM-DC laufen folgende Rollen: DNS-Server, Active Directory-Domänendienste und DHCP-Server. Es sind noch keine Benutzer/Computer im AD eingebunden. Alles ist frisch installiert.
VM-EXCHANGE ist auch frisch installiert, hat keine Verbindung zum Active Directory und es sind noch keine Rollen etc. installiert.

Beide VM sind im selben LAN und VM-EXCHANGE hat im Moment eine feste IP (ausserhalb des DHCP-Bereichs von VM-DC).

Ziel:

Auf VM-EXCHANGE soll ein Exchange 2016 installiert werden und mit dem AD auf VM-DC verbunden werden.

Was muß ich dabei beachten, bzw. wie sollte ich vorgehen?
Nicht klar ist mir im Moment die Einbindung in das AD und welche Vorbereitungen seitens VM-DC und VM-EXCHANGE nötig/sinnvoll sind.
Ist es z.B. sinnvoll einen weiteren Benutzer auf VM-DC für Exchange anzulegen (Mitglied von Schema Admins)?

Hoffe ihr könnt mir weiterhelfen...

vor 10 Minuten schrieb testperson:

Generell kann man auch ohne Cache leben. Muss man aber nicht. ;)

Ist der Geschwindigkeitsvorteil es w€rt nicht ohne Cache leben zu wollen? Habe da keine Erfahrung mit.

Hallo,

wie sinnvoll haltet Ihr eine optionale Flash Backup Unit in Verbindung mit dem Raidcontroller PRAID EP420i bei einem Server mit redundantem NT? Meiner Meinung würde das höchstens gegen Überspannungsspitzen sowie gegen Ausfall des MB schützen. Es ist eine USV vorgeschalten, die evtl. Überspannungsspitzen ohnehin rausfiltert. Bleibt also noch der Ausfall des MB, wo der Einsatz sinnvoll wäre.

Ich würde gerne darauf verzichten, weil der Server nicht hochverfügbar sein muß (tägliche Datensicherung vorhanden), oder ist das keine gute Idee?

vor 5 Minuten schrieb Marco31:

Wenn sich eine unbefugte Person erfolgreich Zugang zu einem Server verschafft nützt ja die Verschlüsselung nix mehr

Genau, die Verschlüsselung hilft nur gegen Daten auslesen bei Diebstahl.

vor 10 Stunden schrieb FragenderFrager:

Zudem nutzt Verschlüsselung dann ja nicht viel wenn nachts jemand einsteigt und sich am angeschalteten Server zu schaffen macht?

Dann müssten die Einsteiger aber erstmal die Passwörter vor Ort herausfinden oder den eingeschalteten Server mitsamt USV mitnehmen. Gegen Letzteres hilft schon eine entsprechende Verlegung des/der Netzkabel (Muss man dann abziehen oder den ganzen Schrank etc. mitnehmen)

Sobald das Ding aus ist, kommen Sie bei (guter) Verschlüsselung nicht an die Daten heran.

vor 3 Stunden schrieb Squire:

nachdem es eh ne alte Büchse ist, würde ich da refurbished Drives nehmen

danke für den Link, aber ich wollte ja jetzt den TX1330M4 besorgen, welcher ja doch noch keine alte Büchse ist.

Mal schauen, ob ich dafür auch was Refurbishtes finde.

vor 31 Minuten schrieb NorbertFe:

Du machst das schon

Hoffentlich war das jetzt kein Sarkasmus, lasse mich gerne belehren wenn meine Meinung falsch ist.

Danke für die Tips von allen Beteiligten.

vor 39 Minuten schrieb NorbertFe:

Hilft auch nicht, wenn die gleichzeitig ausfallen

Wie hoch ist die Wahrscheinlichkeit? Schätze mal sehr gering, wenn es nicht gerade ein Firmwarefehler ist. 

Sonst kann man auch noch das Produktionsdatum (Zeitpunkt des Kaufes oder anderer Lieferant, was oft auf dasselbe hinausläuft) der Platten verteilen.

Mit Hotspare verringert man nochmals die Wahrscheinlichkeit von Datenverlust.

vor 39 Minuten schrieb NorbertFe:

Und raid 5 aus 3 Platten ist auch nicht besonders performant.

Sonst ein Raid10 (kann auch nur 1 Platte (in jeweils einem Raid0 Verbund) ausfallen, dafür schneller als Raid1).

Das ist jetzt auch kein Rechenzentrum oder so, wo die zum Einsatz kommen sollen. Bisher lief es auch mit Raid1