Jump to content

mcdaniels

Premium Member
  • Gesamte Inhalte

    1.840
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von mcdaniels

  1. Hallo,

    ich hoffe mir kann jemand weiterhelfen. Heute (im Laufe des Tages) bekamen einige Kollegen im IE die Meldung "Verstärkte Sicherheit aktiviert.". Dies unter Windows 7 Pro. Installiert ist der IE11. Weiterhin kam eine "Einblendung" dass es inkompatible Add-Ins gibt. (Java).

     

    Nach dieser Meldung konnte man zb nicht mehr auf Google. Sprich man hat die Adresse eingegeben, hat Return gedrückt und nichts ist passiert. Andere Seiten haben funktioniert, jedoch gab es in der Adressleiste ein kleines Stoppschild mit der Info, dass ein Active X Filter aktiv ist. (das war -wie alles funktioniert hat- nicht der Fall).

     

    Ein Test mit Firefox ergab, dass es sich nicht um ein Netzwerkproblem handelt (es funktioniert alles).

     

    Woher kann diese Einstellung kommen? Von selbst wird sich der IE nicht umkonfigurieren, oder? :). Nach dem Zurücksetzen der IE11 Einstellungen plus einem Neustart der PC lief dann wieder alles... Ich frage mich nur für wie lange....

     

    In der GPO (Anwenderbezogen) ist für den IE keine Policy hinterlegt.

     

    Danke!

    LG

    Daniel

  2. Hi Daniel,

    das mit dem CNAME ist eine gute Idee (vielen Dank!) - an das hab ich gar nicht gedacht!

     

    Eine zusätzliche Anpassung der Ordner-Freigabe sollte dann den Status-Quo wiederherstellen.

     

    Dann sollten die NbtNs:Query Request for SERVER eigentlich nicht mehr protokolliert werden, hoffe ich...

     

    Update: Broadcasts sind nun recht stark zurück gegangen. Den WINS hab ich jetzt jedoch auf beiden DCs zusätzlich installiert. Schadet ja nicht. :-)

     

    LG

    Daniel

  3. @Daniel: Im Trace bekomme ich:

    NbtNs:Query Request for SERVER   <0x20> File Server Service (Suche nach einem alten Server mit Namen "Server")

     

    Es gibt auch Browserannouncements von den Clients (sporadisch).

     

     

    Eine andere Möglichkeit ist das Deaktivieren des von Netbios over TCP/IP, was effektiv den NBT Transport unterbindet. Dann nutzt man Direct SMB, was über Port 445 funktioniert und umgeht WINS und Netbios-Broadcasts.

     

    Also wäre das doch eine Option, ohne die Probleme noch größer zu machen?

     

    Btw. wir haben nur einen Namensraum.

     

    Danke werd mir die Links anschauen.

    LG

    Daniel

  4. Ich finde hier nur Einträge unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\Servers\server\Printers\{053300FE-B1A7-46C4-9BD5-1B75BC5FB79C}\DsSpooler

     

    Hier gibt es dann den entsprechenden alten Servereintrag mehrfach. Die Netzwerkdrucker laufen jedoch alle über den neuen Server. Es gibt auf dem Userprofil keine gemappten Drucker die noch auf den alten Server zeigen.

  5. Hallo und guten Morgen!

    @zahni: ich werd versuchen da heute etwas "mitzuschneiden".

     

    @Nils: Also ist abdrehen keine gute Idee. Applikationen die mit kurzen Servernamen arbeiten: Wie muss man sich das vorstellen? Z.b.: ganz einfach ein Share dass eben nicht mittels zb \\server.hier.local\d angesprochen wird sondern eben mit dem "kurzen" Netbios Namen: \\server\d?

     

    Edit: Ich hab jetzt mal gesnifft. Wie es scheint, werden hier von ca 10% der clients noch alte "Netzwerknamen" von Servern gesucht, die seit der Umstellung auf 2k12 nicht mehr vorhanden sind. Die Umstellung ist so erfolgt, dass eine komplett neue Domäne hochgezogen worden ist. Die Clients wurden dann aus der alten Domäne entfernt, in die neue rein gehängt. Danach wurde mittels Easytransfer das alte lokale Profil retour "kopiert".

     

    Ich vermute es gibt u.U. noch alte "Verknüpfungen" auf den Clients. Muss mir noch überlegen, wie ich das am besten rausfinde... (vielleicht mit procmon). Oder gibt es hier eine bessere Variante?

     

    Allerdings erklärt das nicht alle UDP Angelegenheiten.

     

     

    LG

    Daniel

  6. Hallo liebe Mcseboard-Community!

     

    Ich bin gerade dabei Firewall-Logs auszuwerten und da ist mir aufgefallen, dass annähernd alle Clients (Win 7 Pro x64) in meiner Server 2012 Domäne unendlich viele Broadcasts (192.168.1.255) innerhalb des LAN erzeugen.

     

    Nun ist ja Netbios over TCP/IP für dieses Verhalten bekannt, sofern ich mich richtig erinnere. Ist das also normal? Die Hardware-Firewall droppt jedenfalls diese Sessions.

     

    In der Domäne ist AD + DNS entsprechend konfiguriert. Alles läuft an sich problemlos. Woher jedoch kommen diese doch massiven Broadcasts?

     

    Sollte man noch einen WINS Server konfigurieren bzw. kann man Netbios über TCP/IP ohne Auswirkungen mittlerweile deaktivieren?

     

    LG

    Daniel

  7. Hallo,

     

    bei uns im Netz wurde eine neue Domäne inkl. anderem IP Bereich (statisch) hochgezogen. Die Clients wurden ordnungsgemäß aus der alten Domäne entfernt -> in eine Arbeitsgruppe überführt.

     

    Danach wurde die IP Adresse der Clients auf die entspr. neuen IP Adressen / Gateway / DNS  umgestellt und per ipconfig /flushdns der DNS-Auflösungscache geleert.

     

    Nach dem Neustart der Clients wurden diese dann in die neue Domäne eingebunden, was auch problemlos funktioniert hat.

     

    Allerdings wird nun dieses Netzwerk im Status der LAN Verbindung nicht mehr als Domänen Netzwerk angezeigt, sondern "nur noch" als Arbeitsplatznetzwerk.

     

    Weiß jemand, warum das so ist bzw. wie man es bewerkstelligt, dass hier wieder das Domänen Netzwerk "erkannt" wird?

     

    Danke!

     

    LG

    Daniel

  8. Hi,

    ich denke auch dass hier prof. MS Support wohl am Ehesten zum Ziel führt.

     

    Deine DFSR-DB scheint wohl in einem - durch den Stromausfall - inkonsistenten Zustand zu sein.

     

    Hier steht wohl einiges zum Thema: http://blogs.technet.com/b/filecab/archive/2012/07/23/understanding-dfsr-dirty-unexpected-shutdown-recovery.aspx

     

    Nochwas zu den USV: Schau dass du dir eine entsprechende USV mit einer NMC (Network Management Card) zulegst. Bei Stromproblemen kannst du dann die Server zb. mittels Network Shutdown Software geregelt runterfahren und es kommt nicht zu derartigen Problemen.

     

     

    LG

    Daniel

  9. Hey,

    ich werd mir die Labs ganz sicher ansehen. Ja, es ist/war ein bisschen ein "ich klick mich durch" Adventure :-). Dennoch hab ich jetzt etwas mehr von der Thematik verstanden.

     

    Mitglieder der Domäne  -> JA

    Firmenrechner -> JA (ausschließlich Desktop-PC) kommen "nur" über einen Zugang, keine Heimarbeit oder dgl.

    Lizenzierung -> Per Maschine

    Office -> Ja -> Volumenlizenz (Open)

     

    Im Allgemeinen geht es um eine Standortvernetzung. Allerdings habe ich das Problem, dass von den zuerst vom Anbieter versprochenen 16Mbit (up/down) eigentlich nur noch 2Mbit "übrig" geblieben sind und es keine andre Alternative gibt. Das ist auch der Grund, weshalb ich auf die Terminalservices gekommen bin.

     

    Nachdem sowohl bei Standort A als auch bei Standort B idente Hardwarefirewalls vorhanden sind, hatte ich ursprünglich an ein Site 2 Site VPN gedacht. Hiermit habe ich bereits gute Erfahrungen gemacht. Die Clients könnten hier recht einfach an die Domäne angebunden werden.

     

    Wäre es nicht auch eine Variante, zwischen den 2 Standorten den VPN Tunnel aufzubauen und den "Terminalserver" direkt in der internen Domäne zu lassen?

     

    Die "Aussenstellenclients" wären dadurch ebenso in dieser Domäne und kämen problemlos zum "Terminalserver".

     

    LG und vielen Dank!

     

    PS: Ich habe betr. Terminalserverangelegenheiten auch eine Firma "bei der Hand". Allerdings würde ich mich dennoch gerne ein wenig damit auskennen ;)

     

    Daniel

  10. Hallo Leute,

    danke für eure Antworten und die Korrektur meiner falschen Annahmen.

     

    @Daniel: Das ganze ist ein Testaufbau, da ich -wie erwähnt- eigentlich null Erfahrung mit dieser Thematik habe. (Man will ja etwas dazu lernen).

     

    Was ich grundsätzlich erreichen will: um die 10 Remote User sollen per Terminalservices eine Anwendung nutzen / auf Files zugreifen.  Optimalerweise NICHT per Remoteapp, sondern mittels "normalem" Zugriff auf den Terminalserver. Für die Realisierung dieser Terminalserverlösung sollen so wenige Server wie möglich verwendet werden.

     

    D.h.  externe User -> Firewall -> RD-Gatewayserver in DMZ  -> RD-Server / interne AD Domäne im LAN

     

    In der Testumgebung hatte ich es so konfiguriert, dass ein 2k12 Server "alles" war. Sprich AD DS, DNS und RD Gateway, "Terminalservices". Der Server hatte allerdings eben eine "interne" IP 10.0.0.200 und die Domäne home.local .

     

    Per Portforwarding habe ich dann Port 443 auf die IP 10.0.0.200:443 "umgebogen". Der Aufruf von RDWEB erfolgte über meine offizielle IP/rdweb.

     

    So gesehen hätte dann aber das Gateway den internen Servernamen auflösen können müssen, oder? (ist ja alles auf einem Server...).

     

    Edit: Ich bekomme u.a. auch eine Fehlermeldung, dass die Remotedesktop-Gatewayserveradresse nicht erreichbar ist, sobald ich eine Remoteapp angestartet habe und mich authentifiziert habe.

     

    EDIT2: Problem gelöst! (Hab das jetzt mit einer meiner offiziellen IPs + FQDN versucht und erst jetzt gesehen, dass ich ja den FQDN des RD-Gatewayserver überschreiben kann.. Sorry!!)

     

    LG

    Daniel

  11. Nachsatz: Aus Sicherheitsgründen wäre es wohl vorzuziehen, das ganze über ein VPN abzuwickeln. Wenn man hier zb. ein Site to Site VPN aufzieht, dann könnte man grundsätzlich nur einen Server für die "Remotedienste" nutzen. Da sich hier dann ja - je nach Konfiguration - auch alles in einer Domäne abspielt bzw. abspielen kann.

  12. Hallo liebe MS-Pros!

     

    Ich beschäftige mich zur Zeit mit -für mich- absolutem Neuland. Unter Windows Server 2012 habe ich die Terminalservices (Remotedienste) installiert. Das ganze läuft auf nur einem 2k12 Server in einer VM (Testumgebung).

     

    Der Server ist als Domänencontroller konfiguriert und hat die IP 10.0.0.200.

     

    Wenn ich vom internen Netz aus auf https://10.0.0.200/RDWeb zugreife klappt alles problemlos. Komme ich jedoch von extern (sprich von einem PC der über das Internet "hereinkommt") habe ich das Problem, dass mein lokaler FQDN des Server vom externen PC nicht aufgelöst werden kann. (weil dieser natürlich nix von der internen Konfiguration weiß).

     

    Gesucht wird dann nämlich der "interne" FQDN: srv-ts.home.local (Siehe Anhang) und die Remoteapp kann nicht aufgerufen werden. Wie muss man soetwas konfigurieren, dass es funktioniert? Braucht man für den RD-Gateway einen FQDN der per öffentlichen DNS aufösbar ist?

     

    Ich habe wohl auch noch ein Verständnisproblem: Gibt es bei Server 2012 den klassischen Remote Desktop nicht mehr? Dh. kann man sich nicht einfach des Programmes "Remotedesktopverbindung unter Windows 7 bedienen?

     

    Wird hier alles nur noch per Remoteapp gelöst?

     

    Vielen Dank!

     

    LG

    Daniel

    post-8045-0-65747100-1397847522_thumb.png

  13. Hallo,

    du sprichst von 20-30 Clients die  zum Einsatz kommen sollen. Hinzu kommt, dass es sich um ein Internetcafe handelt. Hierbei kann man davon ausgehen, dass die "User" -die ja variieren- sicher alles mögliche ansurfen. Deshalb solltest du auch das Thema Sicherheit nicht ausser Acht lassen.

     

    • Dies beginnt meiner Meinung nach damit, dass die Client-PC immer auf einem aktuellen Softwarestand gehalten werden sollten. (automatisch). (WSUS + ev. LUP).
    • Ebenso sollte man sich Gedanken über einen entsprechenden Virenschutz machen.
    • Soll ein Content-Filter zum Einsatz kommen?

     

    Ein dedizierter Server wäre sicher nicht schlecht, denn das erleichtert die Verwaltung.

     

    Wenn das Budget knapp ist, könnte ich mir auch vorstellen, in so einer Umgebung auf eine Linuxdistribution zu setzen. (Weniger Angriffsfläche für Viren etc.)

     

    LG

  14. Hallo,

     

    gibt es irgend eine Form der Zugriffsbeschränkung Richtung Internet (Protokollbeschränkungen, Servicebeschränkungen etc.)

     

    Wie ist den der Patchstand des Problem-PC? Ist der recht aktuell, oder könnte u.a. eventuell das hier greifen:

     

    http://answers.microsoft.com/en-us/windows/forum/windows_xp-windows_update/error-0x80244004-after-installing-windows-update/98b29514-bf1f-4166-863a-c8e3fd6bd8c9

     

    PS: Ich bilde mir ein so ein Problem hatte ich auch schon mal. Da lag es (sofern ich mich noch richtig erinnere am IE8 bzw. Problemen mit .NET, VCREDIST)

×
×
  • Neu erstellen...