Jump to content

Forseti2003

Members
  • Content Count

    171
  • Joined

  • Last visited

Community Reputation

12 Neutral

1 Follower

About Forseti2003

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. stimmt - danke für den Tipp. War wohl zu ängstlich Hab mich zu sehr auf die Meldung mit dem Softwaremodul gestürzt
  2. Nabend, mal eine etwas von Windows abweichende Frage zu DATEV. Wollte heute auf einem weiteren Terminalserver den DATEV Arbeitsplatz installieren. Dazu die CD eingelegt und auf Start gedrückt. Aber wenn er zum installieren kommt, fragt mich nach der mIdentity, die zwar eingelegt und erkannt wird, er aber bei der Installation ignoriert. Auf dem Datenbankserver hab ich geprüft, das Softwareschutzmodul ist eingelegt und wird mit "OK" gekennzeichnet. Ich vermute jetzt, dass der WTS nicht erkennt, dass der Datenbankserver da ist und sich mit ihm abgleicht oder kann es noch einen anderen Grund geben? Der Terminalserver ist auf Windows 2016 aufgesetzt und als Remotedesktop-Host eingerichtet. Das WinDVSW Laufwerk ist auch angebunden. Hab aktuell keine Idee, an was es wirklich liegen könnte.
  3. Das müsstest Du jetzt ein wenig ausführen, was Du mit dem Aufwand genau meinst. Einen Server mittels CMD/PowerShell zu administrieren ist jetzt nicht wirklich ein Aufwand. Zudem steht ja auch die WAC zur Verfügung, in denen man einige Leistungsdaten des Server entnehmen kann. Gerade bei einem DC führen wir aktuell eh alle Arbeiten über die MMC des AD und der GPO durch. Das wäre jetzt auch eigentlich meine Vermutung - daher wollte ich halt auch einfach mal in die Runde fragen um Erfahrungen darüber auszutauschen.
  4. So würde ich das nicht ausdrücken wollen - wir fragen uns nicht ob wir bedenkenlos mit WS2k19-Core arbeiten können, sondern ob ein DC unter diesem Core sauber arbeitet. Da MS hier und da immer mal wieder mit seinem OS ja auch Probleme hatte. Deiner Antwort entnehme ich mal, das es da scheinbar nichts außergewöhnliches gibt, was man bei der Planung berücksichtigen sollte.
  5. Hallo in die Runde, aktuell setzen wir zwei Domaincontroller unter Windows Server 2012 R2 ein. Diese möchten wir in den nächsten Tagen durch Windows Server 2019 ersetzen. Diese würden wir als Core-Installation durchführen. Nun zu Frage: Gibt es Vor- und/oder Nachteile oder kann man mit WS2k19 da bedenkenlos arbeiten? Grüße Forseti
  6. Das wäre die Einstellung hier: Aber innerhalb von 5 Minuten hat er nicht reagiert.
  7. Nein, das war es nicht. Der Haken ist zwar da gesetzt, aber der Anwender hat die Zugriffsrechte auf den Ordner. Wenn ich über\\dfssvr\share1\subshare1 gehe kommt er ganz normal drauf. Habe aber folgendes festgestellt, und nun geht das Ganze: Vorher war die Verzeichnisstruktur so: \\Namespace\ - Share 1 (+Ordnerziel) - Share 2 (+Ordnerziel) - Share 3 (+Ordnerziel) Durch die Änderung musste ich folgendes machen: \\Namespace\ - Share 1 - Subshare 1 (+altes Ordnerziel) - Subshare 2 (+neues Ordnerziel) Da aber der Name "Share 1" identisch war, hat er sich bei dem Anwender geweigert (bei mir aber nicht). Hab den Share nun umbenannt in "Share-1" und siehe da, er sieht sofort die ganzen Unterordner. Jetzt wäre die Frage, ist das wirklich so im Sinne von MS, das man den Share umbenennen, sprich nicht identisch heißen soll, wenn man an der Struktur Erweiterungen oder Änderungen vornimmt? Aber wenn das so ist, wieso konnte ich als Anwender im Zugriff die Änderungen sofort sehen, aber der andere Anwender erst durch die Umbenennung?
  8. Hallo in die Runde, bin da gerade auf etwas gestoßen. Wir nutzen einen DFS-Namespace mit mehreren Shares. Für einen Mitarbeiter hab ich einen Unterordner hinzufügen sollen, soweit durchgeführt und Ordnerziel eingetragen. Der Anwender sieht aber diesen neuen Unterordner nicht. Wenn ich als Anwender auf das Verzeichnis gehe, sehe ich ihn aber. Hab dann auf dem Terminalserver und dem DFS-Server ein gpupdate mal durchgeführt, der Anwender hat sich auch einmal ab- und wieder neu angemeldet. Selbes Ergebnis. Er sieht den neuen Ordner nicht. Wenn aber ich den Namespace richtig angezeigt bekomme, sollte dies doch für den anderen Anwender auch der Fall sein oder übersehe ich da etwas? Gruß Forseti
  9. wobei ich die Frage nochmal aufgreifen würde, was spricht generell dagegen die DC's mit der DNS-Rolle zu versorgen, eine Weiterleitung von denen an den BIND9-Server wäre ja auch denkbar.
  10. Mittels GPO kannst Du Desktopverknüpfungen definieren, damit nur bestimmte Benutzer/Benutzergruppen diese erhalten einfach über Sicherheit auf die jeweilige Sicherheitsgruppe beschränken. Das ganze dann unter die Benutzereinstellungen der GPO gepackt, kann so aussehen: Dabei aber nicht vergessen, auch die Programmordner unter Program Files mit dem entsprechenden Recht versehen - dann kann auch kein User ohne Berechtigung beim stöbern mittels Explorer Anwendungen starten, die er nicht sollte. Ob man Laufwerksverknüpfungen auf den Desktop legen sollte, ist dagegen Geschmackssache, ich persönlich bin davon kein Freund. Auch das einfach per GPO runterbügeln, leg Dir dazu eine GPO_Terminaluser an und setzt alles rein, was Du standardmäßig willst oder nicht willst, was ein Terminaluser so alles können sollte. Zu den Profilen - wenn Du die RDS-Sammlung angelegt und die Profile & Roaming zugewiesen hast, wurde auf dem gewünschten Ablagepfad das Template angelegt? Wenn das nicht sauber aufgesetzt ist, oder die Zugriffsrechte nicht passen, hast Du auch Probleme mit den benutzerbezogenen Profilen.
  11. Im Regelfall sollte in einem VPN-Netzwerk der Zugriff über MSTSC funktionieren. Erfolgt die Ansteuerung an den Server über die IP-Adresse oder den FQDN? Hast Du bei den betroffenen Servern auch den Haken gesetzt, das eine Remotesitzung erlaubt ist?
  12. Durch .local hab ich ja das Problem mit externen SSL-Zertifikaten, dies betrifft in gleicherweise Exchange, wie auch Anmeldungen an Terminalservern und deren Zertifikate. Nutze ich ein selfsigned Zertifikat, was zwar geht, hab ich aber einige andere Probleme, gerade durch Browser. Auf dem Exchange selbst hab ich dann auch noch das Problem, das ECP und OWA nicht zwangsläufig auf HTTPS umstellen - auch einige Eigenschaften lassen sich dann nicht mehr über den Browser aufrufen. Ich kann zwar einen UPN-Suffix für die Domain definieren und darin dann die Konten der Anwender verändern - aber das ist für den Exchange dann wiederum ohne Belang. Wir haben zwar am Exchange schon die Interal/External-URL's auf die reguläre Domain geändert, aber er gibt weiterhin Meldungen mit dieser .local nach außen, so dass wir dann wiederum da auch kein Zertifikat erhalten. Ich bin aber natürlich für jeden Hinweis dankbar, der mir Arbeit erspart
  13. Hallo in die Runde, ich habe einen Exchange 2013 im Einsatz, dieser läuft über eine .local-Domain. Wir möchten eine zweite Domain aufbauen und von dort dann einen neuen Exchange (2016/2019) einsetzen. Nun das Problem/Frage: Kann man vom Exchange 2013 alle Mails generell an einen bestimmten (in dem Fall den neuen Mailserver) weiterleiten lassen? So das die User in der neuen Domain ihre Mails erhalten? Sobald die Umstellung auf die neue Domain vorbei wäre, würden wir den Exchange 2013 außer Betrieb nehmen und dann alles direkt über den neuen laufen lassen. Wäre das überhaupt so möglich? Grüße Forseti
  14. Okay, dann wird der zweite wieder eingestampft. Dann schau ich mir mal die 2016 und was für Möglichkeiten sich dann da bieten. Danke für Eure Hilfe.
×
×
  • Create New...