Jump to content

S.R.

Premium Member
  • Gesamte Inhalte

    482
  • Registriert seit

  • Letzter Besuch

Reputation in der Community

14 Neutral

Über S.R.

  • Rang
    Senior Member
  • Geburtstag 01.03.1985
  1. 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
  2. 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
  3. Nichts - gar nichts... Zumindest an den mir bekannten Stellen nicht :-)
  4. 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
  5. 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
  6. 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...
  7. 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
  8. 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?
  9. 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...
  10. 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
  11. 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 :-)
  12. auf dem Receive-Connector, der von außen auf Port 587 erreichbar ist Ich habe jetzt extra mal den ReceiveConnector deaktiviert; dann kann ich mich gar nicht mehr verbinden => damit sollte es dann gewiss der richtige Connector sein :-) Ebenso habe ich den Exchange-Server einmal durchgetreten - leider auch ohne Erfolg.
  13. Hallo, danke für deine Antwort. Habe "Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender" gesetzt und den AnySender entfernt => gleiches Problem. Ich habe den Link genau angeschaut - genau das ist konfiguriert. Habe jetzt mal das Logging auf VERBOSE gesetzt; trotzdem scheint er noch nicht wirklich zu protokollieren - da muss ich wohl nochmal im Detail schauen. Beste Grüße Stefan
  14. Hallo, ich sitze gerade vor einem Exchange 2013. Dort sind unter anderem folgende zwei Postfächer eingerichtet: - info@domain.loc - webserver@domain.loc Über den Receive-Connector kann ich mich von extern mit TLS problemlos authentifizieren; bekomme dann allerdings die Fehlermeldung: 5.7.1 Client does not have permissions to send as this sender. Daher habe ich folgende zwei Befehle in der Powershell zur Behebung des Problems eingegeben: Get-ReceiveConnector -Identity XY\X | Add-ADPermission -user webserver -ExtendedRights "Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender" Get-ReceiveConnector -Identity XY\X | Add-ADPermission -user webserver -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Sender" Dies war mir aus anderen Projekten bereits bekannt und ich dachte, damit das Problem in den Griff zu bekommen; leider ohne Erfolg. Nun habe ich beim Account "info" den User "webserver" als "Senden-Als" eingetragen; danach konnte ich zumindest über info@domain.loc verschicken; nicht aber über gibt-es-nicht@domain.loc. Dies soll aber klappen und es macht den Anschein, als würde meine zwei neuen ExtendedRights nicht greifen. Hat jemand eine Idee, was ich falsch mache oder was noch zu tun ist? Beste Grüße Stefan
  15. Hallo zusammen, ich habe hier mehrere Windows Server 2012 R2 die ein sich typischerweise nach der Windows-Installation ein Zertifikat für den Remote-Desktop-Dienst erstellt haben. Nun hat dies zur Folge, dass bei jeder Anmeldung eine entsprechende Warnung bzgl. Zertifikatsfehler auftritt. Diesen Zustand möchte ich gerne ändern. Ich habe nun ein Zertifikat in unserer CA erstellt und schon darauf geachtet, dass die Schlüsselverwendung auf Serverauthentifizierung (1.3.6.1.5.5.7.3.1) steht. Anschließend habe ich den p12-File unter "Zertifikate (Lokaler Computer) - Remotedesktop - Zertifikate) importiert. Dort liegt auch das Zertifikat, welches aktuell verwendet wird. Dann habe ich das Zertifikat geöffnet und mir den Fingerprint geöffnet und im Editor die Lehrzeichen entfernt. In der cmd habe ich nun folgenden Befehl eingegeben: wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="58b8266402c5649380f71272df162c8d2094ab78" Leider erhalte ich immer den Fehler "Beschreibung = Der Parameter ist ungültig." Ich habe nun auch schon versucht den Wert in der Registry zu ändern: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp Value name: SSLCertificateSHA1Hash Leider hat auch dies zu keinem Erfolg geführt; ganz im Gegenteil => nach einem Neustart konnte keine RDP-Verbindung mehr hergestellt werden. Hat jemand von euch eine Idee woran dies liegen könnte? Bin nämlich schon leicht am Verzweifeln... Beste Grüße Stefan
×