Dunkelmann

Am IP Bereich wird es nicht grundsätzlich liegen. Außer natürlich, es steht eine Firewall dazwischen, die https blockiert. In den url ist nur der Hostname, nicht der FQDN, angegeben. Was passiert, wenn Du den FQDN nutzt? Grundsätzlich würde ich für alle veröffentlichten RDS Dienste den FQDN nutzen. Das Zertifikat für die RDS Dienste sollte natürlich auch zu den FQDN der Server passen.

Eventuell den Broker oder die RDS Dienste auf dem Broker mal neu starten. Mit "mstsc.exe /v:[broker]" (ohne /admin bzw. /console) solltest Du eigentlich in die VDI Collection umgeleitet werden. Sofern das Redirect ordentlich konfiguriert ist. Am besten mit einem einfachen Domänen-Benutzer probieren. Wenn es nicht funktioniert, solltest Du auf dem Broker eine entsprechnde Fehlermeldung im Log finden.

Moin und Willkommen, das MDT benötigt keine Domäne. Für den Zugriff auf das Deployment Share werden jedoch Credentials benötigt; das kann auch ein lokaler Dummy-Benutzer auf dem Deployment Server sein. Such mal nach "MDT bootstrap.ini" und "MDT CustomSettings.ini" In diesen Dateien werden Credentials, Sprache, Tastatur etc. für das Deployment definiert

Moin, muss man jedes Problem mit "riesigem" technischen Aufwand lösen? Auch Passwortmanagementsysteme müssen lizenziert und gewartet werden. In einer 25 Mann Firma sollte es doch mit dem Kommentarfeld in KeePass oder einem Excel Sheet zu erledigen sein. Zum Thema Lizenzen: Die meisten Lizenzen werden über die Herstellerportale verwaltet. Bspw. das VLSC bei MS Den Kleinkram führen wir mit in KeePass.

Moin, ist die Nutzung als Kaspersky-Management Server durch die Windows 7 EULA/PUR abgedeckt? Ich habe da soetwas im Hinterkopf, dass ein Client nur im begrenzten Umfang Dienste im Netzwerk anbieten darf.

Du verbindest Dich direkt mit dem Broker? Was ist, außer dem Broker-FQDN, noch in der RDP Datei definiert und welchen Ursprung hat die RDP Datei?

Moin, ohne die Umgebung und die Anforderungen zu kennen, lässt sich schwer eine Empfehlung abgeben. Ich finde das beschriebene Design mit 5 Servern, Sicherheitsgruppen usw. eher suboptimal. Ich wäre zu faul so eine Umgebung pflegen zu wollen :cool: Vielleicht solltest Du mal das TLG für RDS nachbauen und Dich mit der Funktionsweise von Broker, WebAccess usw. vertraut machen. Das könnte eventuell auch die Unklarheiten im anderen Thread beseitigen. https://technet.microsoft.com/en-us/library/hh831610(v=ws.11).aspx

Moin, es geht ohne WebAccess. Dafür muss auf dem Broker ein Redirect auf die gewünschte Sammlung eingerichtet werden. Ryan hat das hier beschrieben: https://ryanmangansitblog.com/2013/03/11/connection-broker-redirection-rds-2012/

Moin, mit der url wird den Clients, die die Remotedesktop Bereitstellung nutzen, das Webfeed mit den RemoteApps zugewiesen. Die RDS Server sind Bestandteil der Bereistellung und nicht Nutzer der Bereitstellung ;)

Moin, Wie soll der Root CA, und damit der gesamten PKI, vertraut werden, wenn das Root Zertifikat nicht veröffentlicht wird? Der Zusammenhang mit einer weiteren Sub CA erschließt sich mir gerade nicht.

Moin, Nils hat es schon beschrieben: Fehlende Indizes wäre auch mein erster Favorit. 10 GB ist keine Größe für eine DB, da muss der 'Wurm' woanders zu suchen sein. Spiegeln dürfte das Problem nur dublizieren, jedoch nicht lösen ;) Bei regelmäßig wiederkehrenden Abfragen würde ich, je nach Art und Umfang der Abfrage, über Views oder Analysis Services nachdenken.

Moin, geh' die Sache erst mal ruhig an. Wenn Daten in der Cloud liegen oder dahin sollen gibt es i.d.R. einen Grund dafür. Leider liegt es in nicht wenigen Fällen an der internen IT, die bestimmte Anforderungen (Home/Mobile Office sind gerne genannt) nicht umsetzen bzw. anbieten kann. Das klassische Vorgehen wäre eine Aufnahme des Ist-Zustands der IT und die Ermittlung der Geschäftsanforderungen. Das ist das Minimum, welches für ein erstes grobes Konzept benötigt wird.

Off-Topic: 802.1x ist sicher. Der 'Meinungsverstärker Kloppe' (Diskutierst Du noch oder überzeugst Du schon) macht mehr Spass und wirkt nachhaltig; außerdem wird Betriebssport von der Krankenkasse gefördert :cool: btt: @OP: Bitte wende Dich an den Admin Deines Vertrauens

Für solche Fälle steht neben unserem Patchpanel ein Pädagogisches-Kantholz :ph34r:

Moin, zu den Multiple Choice Fragen. Das gab es schon in früheren Prüfungen - keine Angabe der Anzahl auszuwählender Antworten. Hier kann/muss man es erahnen. Ein Radio-Button deutet auf eine Antwort, Checkboxes auf mehrere mögliche Antworten hin. Das kann von einer bis alle gehen.

Nö / Jain / Vieleicht ;) In diesem Fall liegt es scheinbar anders. Es wurde direkt die IP des Routers angefordert, somit ist ProxyARP raus. Beide sitzen zwar in verschiedenen Subnetzen/Layer3 Domänen, jedoch in der selben Layer1/2 Domäne. Somit wird der ARP Request (who knows 'router ip') vom Router mit seiner eigenen MAC beantwortet und eine Kommunikation wird ermöglicht.

Moin, erst Mal muss ich Norbert zustimmen. NTP richtig per GPO konfigurieren und das Thema ist gegessen. Möchtest Du wirklich, ich wiederhole _wirklich_, dass die VMs ihre Zeit von einem NTP und nicht vom Hypervisor beziehen, muss in den VM Eigenschaften/Integrationsdienste die Zeitsynchronisierung abgeschaltet werden.

Nils hat es schon treffend beschrieben. Erst den organisatorischen Rahmen definieren und danach die technische Lösung planen, validieren und erst dann produktiv setzen. Zur Vorbereitung der Orga kann auch ein Blick in diverse öffentlich zugängliche CP und CPS (Certificate Policy, Certificate Practice Statement) nicht schaden. Bei Microsoft, DFN, Bundesbank, etc. gibt es etwas: https://www.microsoft.com/pki/mscorp/cps/ https://www.pki.dfn.de/policies/ http://www.bundesbank.de/Navigation/DE/Service/Services_Banken_und_Unternehmen/PKI/CP_und_CPS/cp_und_cps.html

Aufräumen, die Daten in eine Migrationsfreigabe kopieren und mit frischen Profilen starten war Teil des Migrationsplans und wurde im Vorfeld auch so kommuniziert. Für die Mitarbeiter wurden zusätzlich Schulungen angeboten. Die gesamte Migration von ~ 1000 Anwendern hat inklusive Vorarbeiten fast 3 Jahre gedauert, es war also keine Wochenendaktion.

Moin, mit einer sekundären Zone geht das nicht. Eine Möglichkeit wäre eine primäre Zone mit dem Hostname anzulegen und in der Zone einen 'leeren' A-Record ohne Angabe des Hostname zu erstellen, der auf die gewünschte IP zeigt. z.Bsp. so: dnscmd /zoneadd 'host.domain.tld' /dsprimary dnscmd /recordadd 'host.domain.tld' '.' A '1.2.3.4'

Moin, vor einigen Jahren habe ich auch so ein Konstrukt vorgefunden; mit > 20 Domänen, 5 Domänen davon an einem Standort mit 80 MA :D Wir haben uns damals für den harten Weg entschieden: Parallelaufbau einer neuen Domäne, manuelle Übernahme der Daten und Plattmachen der alten Umgebung.

Ich geb' mich geschlagen ;)

Moin, wurde vor dem Stilllegen des Servers ein Backup erstellt? Vielleicht wäre jetzt der richtige Zeitpunkt für eine Wiederherstellung. Im Anschluss könnte dann ein neuer Migrationsplan erstellt werden.

Moin und Willkommen ;) , der Ansatz klingt plausibel. Bei der Root CA solltest Du eine Offline Root einsetzen; Du hast es nicht explizit erwähnt. PKI läuft unter Windows wunderbar, es muss kein Linux sein. Bei Server 2016 wäre ich so kurz nach Release nocht etwas zurückhaltend und würde eher auf 2012 R2 setzen. Eine spätere Migration auf ein neues OS ist i.d.R. kein Hexenwerk. Eine Sub CA in der Domäne und eine Sub CA ohne Domäne ist kein Problem. Hier sollte bedacht werden, dass Zertifikatsvorlagen nur für AD integrierte CAs genutzt werden können und dass die Veröffentlichung der Sperrlisten etwas aufwändiger sein kann. Es hängt primär von den genauen Anforderungen ab. Eine AD integrierte CA kann auch Zertifikate für Externe (Kunden, Partner, etc.) ausstellen. Der obligatorische Buchtip: Brian Komar - PKI & Certificate Securiry Auch wenn es für Server 2008 geschrieben wurde, sind viele Grundlagen zu Design und Technik noch immer anwendbar.

Manchmal ist es kaum zu glauben ... Ein paar Consumer-Router führen beim Aufruf von: http://<router_IP>/cgi-bin/;COMMAND den Befehl mit root Privilegien aus. Das US-CERT empfielt nun, genau diesen Exploid zu nutzen um den verwundbaren Webserver auf dem Router runterzufahren und sich vor dem Exploid zu schützen :wacko: http://<router_IP>/cgi-bin/;killall$IFS'httpd' https://www.kb.cert.org/vuls/id/582384