Jump to content

S.R.

Premium Member
  • Gesamte Inhalte

    486
  • Registriert seit

  • Letzter Besuch

Reputation in der Community

14 Neutral

Über S.R.

  • Rang
    Senior Member
  • Geburtstag 01.03.1985
  1. Hallo, wir haben hier einen Windows Server 2012 im internen Gebrauch, auf dem ausschließlich der IIS mit einer von uns selbst geschriebenen Software läuft. Hier werden - pro Client - viele parallele Ajax-Requests ausgelöst, da die Seite sehr dynamisch ist. Wir höhren jetzt von Anwendern, die viel mit der Lösung arbeiten und davon auch noch mehrere Fenster offen haben, dass die Fenster enorm lange Verzögerungen haben. Wenn ich das gleiche Vorgehen auf mehreren Rechnern mache, läuft das Ganze absolut problemlos und richtig flott. Unsere Webentwickler sagen, dass die Anfragen ordentlich an den ISS geschickt werden, dieser aber wohl - so scheint es - diese nur nach und nach abarbeitet und nur einen gewissen Teil parallel. Gibt es irgendwo eine Einstellung die besagt, dass pro Client maximal X Requests gleichzeitig bearbeitet werden? Bin gespannt, ob ihr einen Tipp habt - momentan suche ich nämlich absolut im Dunklen... Danke und Gruß Stefan
  2. Problem gelöst: Ich habe im AD eine neue Gruppe angelegt, dort die gleichen Benutzer aufgenommen - Berechtigung auf die Gruppe identisch gesetzt: läuft sofort. Erklären kann ich mir das überhaupt nicht... Danke Sunny61, an die UAC hatte ich auch schon gedacht. Habe diese auch deaktiviert inkl. Serverneustart => allerdings tritt das Problem weiterhin auf. Daher hatte ich das dann als mögliche Ursache wieder zu den Akten gelegt. Ich merke mir aber: nie wieder Default-AD-Gruppen für Berechtigungen verwenden Danke und ein schönes Wochenende Stefan
  3. Ich habe gerade zwei Eingabeaufforderungen geöffnet - als Benutzer "Domain\adm-test": 1) "normal" - d: - cd Test-Ordner => Zugriff verweigert 2) "Als Administrator ausführen" - d: - cd Test-Ordner - dir => sehe alles Dann habe ich die UAC deaktiviert, Server neu gestartet, Test wiederholt, gleiches Problem. Das ist doch schon merkwürdig, oder was übersehe ich? Beste Grüße Stefan
  4. Hallo, ich habe einen Domain-Controller mit Windows 2012 R2. Dort habe ich einen Benutzer "adm-test" angelegt und der AD-Gruppe "Domänen-Admins" hinzugefügt. Zur Kontrolle habe ich auch nochmal im AD unter "Users\Domänen-Admins" geschaut - da steht der Benutzer auch wirklich drin. Zusätzlich habe ich einen Windows Server 2016, der ist Mitglied der Domain. Hier habe ich auf der Festplatte D:\ den Ordner "Test-Ordner" angelegt - mit dem Benutzer "Domain\Administrator" und die Berechtigung "Domain\Domänen-Admins => Vollzugriff" eingerichtet. Mit dem AD-Benutzer "Domain\Administrator" kann ich problemlos auf den Ordner zugreifen! Dann habe ich mich als AD-Benutzer "Domain\adm-test" angemeldet und möchte dann auf "D:\Test-Ordner" zugreifen. Auf D:\ klappt, klicke ich dann auf den Ordner, bekomme ich die Fehlermeldung "Sie verfügen momentan nicht über die Berechtigung des Zugriffs auf diesen Ordner". Klicke ich dann auf "Fortsetzen", dann wird der Benutzer "Domain\adm-test" mit Vollzugriffen hinzugefügt und es klappt. Aber das kann ja nicht Sinn der Aktion sein... Komme mir gerade vor wie ein Anfänge :-P Hat jemand nen Tipp, wo ich den Wald vor lauter Bäumen nicht sehe? Bin für jeden Tipp dankbar!!! Merci Stefan
  5. Ich habe hier einen WSUS auf Basis von Windows Server 2012 R2 (Upstream-Server), der einen Downstream-Server WSUS01 hat. Die Ersteinrichtung ist schon ein paar Tage her und das System läuft soweit tadellos. Nun habe ich allerdings festgestellt, dass die Serverstatistik auf den beiden Servern abweicht - warum auch immer. Als Beispiel: Auf dem Downstream ist die Anzahl "Nicht genehmigter Updates" bei 10, auf dem Upstream bei 0. Die Anzahl "abgelehnter Updates liegt bei "2257" zu "2637". Ich habe schon mehrfach den "Assistent für die Serverbereinigung" durchlaufen lassen - ohne Erfolg. Auch Neustarts beider Server führen zu keinem Ergebnis. Bei "Jetzt synchronisieren" startet der Sync auf dem Downstream-Server problemlos, springt dann aber von 0% direkt auf 99% - ob das was heißt, weiß ich allerdings nicht. Kann man ggf. den Sync nochmal zurücksetzen, so dass alle Update-Informationen nochmal vom Upstream-Server heruntergeladen werden? Ansonsten gehen mir langsam aber sicher die Ideen aus
  6. Hallo zusammen, spontan habe ich gestern das Notebook neu aufgesetzt; lief direkt ohne jegliche Probleme. Meine Standardsoftware installiert und den Rest via Server-Profil geladen... fertig war das Notebook. Ging dann deutlich schneller :-) Ich hab keinen blassen Schimmer, woran das lag. Vielleicht mache ich mir die Tage nochmal die Mühen und spiele das alte Backup zurück und versuche das Problem zu lösen... wäre ja schon ganz interessant, was das gewesen sein sollte :-) Danke nochmal und bis bald! Stefan
  7. Nichts - gar nichts... Zumindest an den mir bekannten Stellen nicht :-)
  8. Hallo, ich habe hier ein Notebook mit Windows 10 1703. Dort habe ich heute im BIOS die Virtualisierungs-Option aktiviert und anschließend Hyper-V installiert. Anschließend habe ich eine VM angelegt und diese gestartet. Wenn ich mich dann allerdings mit der VM verbinden möchte, erhalte ich die Fehlermeldung: Mit dem virtuellen Computer konnte keine Verbindung hergestellt werden. Wiederholen Sie den Verbindungsvorgang. Sollte das Problem weiterhin bestehen, wenden Sie sich an den Systemadministrator. Da ich schon auf mehreren Notebooks Hyper-V konfiguriert habe, aus meiner Sicht folgende Kuriositäten: 1) Ich starte den Hyper-V Manager bereits als Administrator. Ich kann mich also auch mit dem Hyper-V verbinden. Daher scheine ich ja grundsätzlich Rechte zu haben. 2) Wenn ich mir das Vorschaubild anschaue, dann sehe ich dort auch, dass die VM gestartet ist und die W10-Installation starten möchte (boot von ISO). 3) Firewall und Avira ist deaktiviert. 4) Hyper-V vollständig deinstalliert und wieder installiert; kein Erfolg. Alle Windows-Updates sind eingespielt. Da es nicht meine erste Hyper-V-Installation ist, bin ich arg verwundert, was da gerade schief geht. Hat jemand von euch eine Idee oder Tipp, wie ich dem Problem auf die Schliche komme... Bin absolut gespannt :-) Beste Grüße Stefan
  9. Hi, vielen Dank für eure Hilfe. Habe das jetzt in einem Testaufbau nachgestellt und es klappt wie es sollte: - weiteren WSUS eingerichtet, der nur die WSUS-Datenbank vom Upstream-Server erhält, aber lokal keine Updates vorhält; entsprechend holen sich die Clients die freigegebenen Updates von den MS-Servern - habe eine A-Record im öffentlichen DNS für wsus.domain.tld eingerichtet; somit ist der WSUS von extern über https://wsus.domain.tld erreichbar - im Firmen-DNS habe ich auf den Windows-Servern die interne IP vom neuen WSUS hinterlegt; auch dies klappt tadellos Nun habe ich noch das Problem, dass ich den internen DNS-Eintrag pro Standort definieren muss. Ich finde hier aber keine Möglichkeit... oder übersehe ich da etwas. Ich bräuchte da sowas wie: - Wenn du von Standort X anfragst: 10.1.1.X - Wenn du von Standort Y anfragst: 10.1.2.X - ansonsten: öffentliche IP Wir haben aktuell zwei zentrale DNS-Server im Rechenzentrum; Windows Server 2012 R2. Bin auf eure Gedanken und Ansätze gespannt... weil das ist der letzte Punkt der noch fehlt - dann klappt das Szenario bestens und alle Anforderungen wären tadellos umgesetzt worden. Schon jetzt herzlichen Dank! Gruß Stefan
  10. das Problem, was ich sehe: Die Mitarbeiter arbeiten 90% an einem Standort, bekommen dort also per GPO die WSUS-Konfiguration. Dann packen sie ihre Sachen und sind für drei Monate weg. Woher bekommen die Rechner die neue Konfiguration? Ich kann also nicht genau vorhersagen, wann und welches Gerät ist. Somit kann ich leider auch nicht deinen Gedanken nachvollziehen, wie ich das mit dem Split-DNS hinbekommen soll...
  11. Hallo, aktuell haben wir bei uns im Rechenzentrum den zentralen WSUS stehen. In jeder Zweigstelle steht ein RODC mit WSUS-Dienst, der als Downstream-Server konfiguriert ist; sich somit die Konfiguration vom zentralen WSUS im RZ holt und die Updates dann von Microsoft. Die Clients erhalten nach der Anmeldung am jeweiligen Standort die richtige Gruppenrichtlinie zugewiesen und somit wissen diese, an welchem WSUS sie sich melden müssen und wo sie Updates erhalten. Das klappt aktuell tadellos. Nun haben wir immer mehr Rechner, die auch über einen längeren Zeitraum (teilweise zwei oder drei Monate) nicht an einem Standort betrieben werden sondern bei einem Kunden vor Ort. Somit erhalten diese Rechner aktuell für diesen Zeitraum keine Updates. Dies soll in Zukunft allerdings ermöglicht werden. Ziel ist folgendes: - am zentralen WSUS soll wie bisher erkennbar sein, welcher Client welchen Update-Status hat - Ist der Rechner an einem Standort, dann soll er dort den WSUS für Updates verwenden - ist der Rechner an keinem Standort, dann soll er über https://wsus.domain.tld die Anfrage stellen und dann von MS die erlaubten Updates laden Ich habe allerdings keinen blassen Schimmer, wie ich das in die Gruppenrichtlinie packen soll? Weil der Rechner meldet sich ja nicht an der Domain an; heißt er bekommt auch keine neue GPO und somit auch nicht die Info, dass er die MS-Download-Server nutzen soll. Wo liegt da mein Denkfehler oder denke ich einfach zu kompliziert? Ich danke für entsprechende Ideen und Ansätze :-) Beste Grüße Stefan
  12. Exchange 2013 und Outlook 2013; beides recht aktuell gepatched Habe jetzt mal mein Profil gelöscht, neu eingerichtet und es sieht so aus als tritt der Fehler jetzt nicht mehr auf... werde schauen, ob ich das an zwei weiteren Arbeitsplätzen auch so reproduzieren kann... aber ich kann jetzt unmöglich bei 200 Anwender das Profil neu anlegen. Hast du n' Idee woran dies liegen könnte? Bzw. wo sich der Client evtl. noch etwas gecached hat?
  13. da steht die externe URL folgender Hinweis: wenn wir von extern uns verbinden, dann klappt dies tadellos - auch ohne Zertifikatsfehler. Der Zertifikatsfehler tritt nur auf, wenn der Rechner/Outlook auch Verbindung zur Domain hat. Dies ist zumindest unsere aktuelle Vermutung...
  14. Hallo, ich habe mich heute daran gemacht unseren Exchange von Außten über Outlook Anywhere mit RPC over https einzurichten. Dafür habe ich entsprechend die interne URL angepasst und unser Wildcard-Zertifikat eingespielt. Damit ist https://email.domain.com ohne Zertifikatsfehler aufrufbar. Wenn ich Outlook jetzt starte dann erhalte ich nach 30 bis 60 Sekunden die Fehlermeldung, dass das Zertifikat gültig aber für eine falsche URL ausgestellt ist. Hier wird die interne URL irgendwie aufgerufen; aber das public-Zertifikat verwendet. Ich verstehe nicht an welcher Stelle ich noch die interne Url nicht auf die externe angepasst habe. Selbst im Active Directory habe ich die Url vom Autodiscover in den Service Connection Points angepasst. Wenn ich in Outlook den Verbindungstest durchführe, dann wird mir die richtige Autodiscover-Datei heruntergeladen und angezeigt. Dort steht nicht einmal die interne URL drinnen. Kann mir jemand einen Tipp geben, wo ich noch nach schauen muss... Bin etwas am Verzweifeln :-) Besten Dank Stefan
  15. Ich habe gerade gesehen, dass der ReceiveConnector vom Typ "FrontendTransport" ist; sollte dies HubTransport sein? Kann hier der Fehler liegen...??? Weil dann mache ich mich mal in diese Richtung schlau... ich habe den Type gerade angepasst; klappt direkt... jetzt weiß ich, wo ich mich mal einlesen muss :-)
×