Vinc211

Guten Tag,

ich hoffe die Frage gab es nicht schon 100mal, ich habe zumindest keine Antwort dafür gefunden.

Ich lasse über die Aufgabenplanung ein vb Skript laufen bei einem bestimmten Trigger. Das Skript liegt nicht lokal sondern auf einem Server.

Es kann sein das die Aufgabe ausgeführt wird während das Skript nicht erreichbar ist und dann kommt die Meldung vom Windows Script Host: Das Laden des Skripts "UNC Pfad" ist fehlgeschlagen (der Netzwerkpfad wurde nicht gefunden).

Der User muss das mit "OK" bestätigen.

Frage: Gibt es eine Möglichkeit diese Abfrage / Fehlermeldung abzuschalten?

Vielen Dank

Gerade eben schrieb NorbertFe:

Dann ist ja gut. Der Zweck von dfs besteht für mich üblicherweise in der Servernamenunabhängigkeit. Wenn die User sich daran aber gewöhnen, daran links anlegen usw. usf., Rate mal was dann beim nächsten serverwechsel passieren wird ;)

Der user Kreis der den Workaround nutzt ist relativ klein.

Wenn das DFS Probleme macht muss man ja irgendwas bereitstellen damit die Leute an ihre Daten kommen. Oder möchtest du sagen das die Freigaben ein Teil des Problems sein können?

vor 1 Stunde schrieb Weingeist:

Wie gesagt, erstelle ein Script unter C:\Scripts oder so welches das was per GPO ankommt neu macht. Sprich Netzlaufwerk trennen + wieder neu verbinden. Oder auch unter dem Netlogon-Share. Wenn etwas falsches zwischengespeichert ist, bekommst ein Netzlaufwerk selten wieder einfach so geradegebogen. Zumal immer noch die Frage ist, ob es nur neu erstellt wird per GPO wenn nicht bereits vorhanden (auch wenn falsch) oder komplett ersetzt wird. Wird es nicht ersetzt, dann gibt genau der eigene Work-Around nachher probleme wenn sie einen spezifischen Fileserver angeben jedoch nicht immer der gleiche verfügbar ist.

--> Daher mache ich das normal per Script (auch wenn per GPO ausgelöst oder Startup), dann bin ich sicher das es getrennt und neu verbunden wird und so mancher Ärger erspart wird.

Ich werde es das nächste mal ausprobieren, aber es löst das Problem nicht.

Der VPN wird erst nach dem Start von Windows gestartet, also werden Startup-skripte von NETLOGON oder GPO's nicht ausgeführt.

Alle Server sind dauerhaft verfügbar.

vor 1 Stunde schrieb NorbertFe:

Das Problem ist aber jetzt schon erkennbar welches sich daraus ergibt, oder? ;)

nein. ich sehe das problem mit den freigaben nicht.

vor 1 Minute schrieb Weingeist:

Einfach mal alle möglichen Varianten durchtesten, was anderes bleibt dir nicht übrig. Dazu mit Wireshark analysieren.

1. Laufwerk eben nicht per GPO verbinden sondern wirklich erst wenn VPN voll da ist und Im Netzwerkadapter das Netzwerk angezeigt wird die Verbindung erstellen.

2. Eine Stufe retour, also Laufwerk nicht trennen, neu starten und schauen ob es nach VPN Aufbau wieder tut

3. Wieder eine Stufe retour, Laufwerk trennen, neu starten, manuell verbinden (versuchen), VPN aufbauen schauen obs tut

4. manuell trennen, manuell neu verbinden entweder direkt per Kommandozeile oder testweise erst im Explorer

 

So kriegst evtl. einen Work-Around hin der möglichst ohne Adminrecht und Neustart tut. Damit erstellst ein Script (sofern möglich und das Problem behebt), damit es der User selbst tun kann. Link auf das batch auf den Desktop. (Also Trennen und neu verbinden)

 

 

Falscher Namespace: Nun da kommen wir der Sache schon etwas näher ;)

Schuss ins blaue: Ihr habt zwei aktive DFS-Ziele aber nur eines ist per VPN erreichbar. Arbeitet er am anderen Standort, bekommt er entweder Zugriff auf beide Ziele oder auf genau ein anderes. Im Cache ist aber der Pfad zum "falschen" hinterlegt. Da verbundene Netzlaufwerke so gut wie nie - oder mir nicht erkennbaren System - aktualisiert werden, funktioniert der Zugriff nicht.

 

Aber von unterschiedlichen Sites und Standorten habe ich ehrlich gesagt keine Ahnung. Da ich nur kleine Umgebungen habe, versuche ich auch mehrere Standorte unter einen AD-Standort zu kriegen und die Leute per Fernzugriff auf das Hauptsystem arbeiten zu lassen. Sprich Jumphost Prinzip und möglichst Keep-it-simple. Ansonsten muss dann ein anderer ran.

Wir haben einen funktionierenden Workaround etabliert. Die User wissen das wenn das Laufwerk nicht per klick erreichbar ist Sie \\domain.loc oder \\fileserver.domain.loc eingeben können um die Daten zu erreichen. Manche haben sich da als Network share bereits eingerichtet. Aber das ist ja nicht Ziel oder Sinn des ganzen.

in den DFS Einstellungen kann man die Ziele ja selbst aktiv schalten und überprüfen. Alle Personen die sich per VPN anmelden bekommen in der DFS übersicht des laufwerks den richtigen share zugewiesen. Wechseln und überprüfen funktioniert auch, bringt aber nichts.

vor 1 Minute schrieb Forseti2003:

Anderer Ansatz wäre das VPN-Gateway, hat das vielleicht eine Policy/NAT-Routing aktiv die da ein Problem verursacht?

Verstehe nicht wie ein temporäres Problem bei einem Prozentsatz von leuten durch eine permanente Regel ausgelöst werden soll.

Wir haben eine Sophos UTM 9.7 mit dem Sophos Open VPN Client der die routen bei route.exe add setzt.

Das es dort manchmal zu DNS Problem kommt weiß ich, wie gesagt mit VPN neustart sind die dann behoben.

Auf meiner Suche im www bin ich übrigens auf einige gestoßen die das selbe Problem wie ich beschreiben, nur gabs da meistens keine Antworten drauf und keine Lösungen. Ich befürchte es ist MS hokus pokus.

vor 17 Minuten schrieb Weingeist:

So wie es aussieht scheitert er schon ziemlich früh. Ohne den Rest gesehen zu haben würde ich sagen, er findet den Pfad im Cache, will auf diesen zugreifen, kann aber den Domänen-Namen nicht auflösen.

 

Mögliches Problem:

- Keine saubere DNS-Auflösung in jenem Moment wo die Verbindung aufgebaut werden soll.

- Noch keine aktive Domänenzugehörigkeit (Sichtbar beim Netzadapter)

- Anderes Sicherheitstoken das nicht mehr gültig ist sobald er sich mit VPN einklinkt, die Verbindung hat er eventuell mit einem alten versucht aufzubauen, was dann scheitert.

-->laufwerke trennen und neu verbinden nachdem ein manueller Zugriff geklappt hat. Das gleiche auch mal nach einem Neustart und erst verbinden wenn VPN aufgebaut ist (das meinte ich mit alles rauskicken)

- Netzwerkprobleme --> Zu viel Paketloss --> Sicherheitstoken macht Ärger bzw. der Client verliert das Vertrauen des AD, dabei wird es bei verbundenen Netzlaufwerken gar nicht oder nicht sofort wiederhergstellt. Manueller Zugriff funktioniert dann meistens trotzdem, aber nicht zwingend stabil. (Hier hier es mal funktioniert indem ich die Geschwindigkeit gedrosselt habe, ist aber via VPN wohl eher tricky)

- Möglicherweise gibt es auch Ärger wenn das Netzlaufwerk via einem anderen Adapter aufgebaut wird, also einmal WLAN und dann LAN oder VPN-Adapter. Dann könnte es sein, dass irgendwo eine definierte Route gecached ist, die dann fehlschlägt.

 

EDIT: Hier findest den Ablauf einen DFS-Requests: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dfsc/1ff7d611-ba19-49fb-95f4-7c5358b86834

 

Aber eben, hier hilft vermutlich am Ende nur systematischen vorgehen, ausprobieren...

Habe pings laufen und nslookup in allen variationen getestet während ich das laufwerk anklicke. DNS kanns nicht sein.

Domänenzugehörigkeit ist da und soweit ich weiß kann diese doch nicht einfach im laufenden Betrieb verschwinden wenn man nichts am Netzwerk / VPN macht.

Das Laufwerk wird per GPO verbunden. Ich habe auch schon das Laufwerk entfenrt und bei bestehender Verbindung gpupdate durchgeführt doch der Fehler blieb bestehen. Manuell hab ich es glaube ich noch nicht versucht.

Paketloss schließe ich auch aus, da die Remoteverbindungen und Datei-Downloads über Workarounds ohne Probleme klappen.

Kollegen sind zuhause alle im WLAN und und dann per VPN Verbunden. Wie gesagt funktioniert es bei manchen dann einfach en VPN neuzustarten und dann gehts, bei manchen nicht.

Was mir auffällt ist das die Antworten im Wireshark nicht vom "nächsten" Namespace kommen sondern von einem anderen Standort. Die User kriegen per VPN eine IP die ich in AD Standort und Dienste der Default First Site zugewiesen habe, doch die antwort auf nslookup domain.loc und die Antwortem im Wireshark kommen alle auf einem Standort und nicht vom DC und Fileserver der Default-First-Site

vor 1 Minute schrieb Forseti2003:

Hast Du mal Deine DNS-Server geprüft, ob die sich gegenseitig sauber erkennen und die Zoneneinträge übernehmen? Auch mal die Zone prüfen, nicht das versehentlich einige Einträge ins Nirwana führen.

ich kann im DNS keine Probleme feststellen, da alle nslookups und fqdn abfragen sauber laufen. wie gesagt: alle aufrufe funktionieren solange man sie manuell macht, nur der Doppelklick auf das Laufwerk funktioniert nicht.

ich überprüfe nochmal alles im DNS, glaube aber nicht das ich was finden werde.

Habe nun mit Wireshark einen Mitschnitt gemacht.

Beim Aufrufen des Ordners Bremen kommen folgende Antworten:

SMB2 - Create Response, Error: STATUS_PATH_NOT_COVERED

etwas später im Protokoll findet sich auch:

SMB2 - Create Response, Error: STATUS_FILE_IS_A_DIRECTORY

leider kann ich dazu nicht viel finden und es auch nicht erklären. Netzwerk Problem wahrscheinlich, aber warum nur teilweise.

Wireshark habe ich bei einem Kollegen ausgeführt der das Laufwerk erreichen konnte und dann im laufenden Betrieb plötzlich nicht mehr. (so die aussage)

Da das Problem immernoch besteht habe ich diesen Thread nochmal ausgegraben.

Es ist so das dies nur beim klicken aufs Laufwerk etc. passiert. Das Eingeben des FQDN funktioniert immer.

Manchmal funktioniert es nach einem Neustart wieder. Vor und nach dem Neustart sind ping auf dom.loc und alle ipconfig/all einstellungen gleich.

Moin,

ich habe das selbe Problem und schaffe es nichtmal Exchange zu deinstallieren. /upgrade , /uninstall und /recoverserver laufen alle auf Fehler.

/upgrade weil die Dienste nicht gestartet werden können

/uninstall weil "Unbehandelte Ausnahme: System.IO.FileNotFoundException: Die Datei oder Assembly "Microsoft.Exchange.Net, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.
   bei Microsoft.Exchange.Setup.CommonBase.SetupBase.MainCore[T](String[] args, ISetupLogger logger)
   bei Microsoft.Exchange.Setup.ExSetup.ExSetup.Main(String[] args)"

und /recoverserver weil ja schon Exchange Rollen installiert sind.

Weder die setup.exe im V15/bin verzeichnis, noch die aus dem Iso lassen sich starten. Alles nur über cmd machbar.

Bei mir ist es allerdings Exchange 2019 bei einem CU8 -> CU9 upgrade passiert. Bei einem Server hat das Upgrade die Fehler des Sicherheitsupdates behoben, beim anderen nicht.

Ich möchte den Thread gar nicht mir meinen Problemen spicken, aber vllt. hilft es ja dem thread ersteller diese Sachen auch nochmal auszuprobieren.

Am 2.2.2021 um 09:30 schrieb Weingeist:

Wieso tut man sich bei sowas kritischem wie ein DFS-Root verschiedene Server-Versionen/Stände an? Auch wenn die Chance eher klein ist, dass hier das OS der Schuldige ist weil an DFS nicht so wirklich entwickelt wurde, es ist halt unnötig ;)

 

Da bleibt wie so oft nur Mühsam alles mögliche durchchecken

- Kannst Du denn auf den Clients jedes der verschiedenen Ziele erreichen wenn Du direkt die FQDN eingibst? Also nicht nur von Deinem PC aus oder von jenen die gut sind?

- Teste mal eine Firewallfreigaben In/Out mit vollen Berechtigungen zu den AD-Servern. Wenn es dann geht, blockt irgendwas.

- Dann kann noch eine nicht gute Replikation zwischen den AD-Servern und somit dem DFS-Root ein Problem sein (Replikation prüfen), sprich Daten sind nicht gut bei einem AD

- Dann kann sich ein Client per VPN evtl. einen "falsches" Fileserver anlachen, welcher gar nicht für seinen Standort ist und somit evtl. nicht erreichbar ist (oben eigentlich ausgeschlossen)

- Zu guter letzt, wenn DNS nicht perfekt ist, dann läuft auch DFS nicht wirklich sauber (evtl. als erstes einfach mal DNS cache löschen im client)

Danke für die Tipps. Ich kann alle FQDN direkt erreichen ohne Probleme. Sowohl von meinem PC als auch von dem wo es diese DFS Probleme gibt.

Firewall steht auf Durchzug. Habe die Einstellungen auch nochmal angepasst und es brachte keine Besserung.

Replikation der DFS Server habe ich inder DFS Verwaltung testen lassen. Gab keine Probleme. Auch die Ereignisanzeige hat mir nix als Fehler ausgegeben.

Der Client ist zwar vom AD her in einem anderen Standort, aber wenn das VPN aktiviert ist in der Default First Site und zu diesem FileServer verbindet sich das DFS auch. Man kann dann wechseln, aber das behebt das Problem nicht, bzw. Bei client wo alles läuft kann man auch wechseln und es läuft weiter.

DNS Cache löschen versuch ich als nächstes.

Am 2.2.2021 um 09:31 schrieb Dukel:

Hauptsächlich oder nur?

Gibt es auch Anwender im LAN, die das Problem haben?

Gibt es auch Anwender im VPN, die dieses Problem nicht haben?

 

Hier gab es letztens einen Thread wegen VPN und Netzlaufwerken.

Es sind keine Anwender im LAN bekannt die das Problem haben

Es gibt anwender im VPN die absolut keine Probleme haben.

Ich habe heute einen neuen User im AD angelegt, ihm die Gruppen einer Person gegeben bei der es nicht geht.

Zudem eine VM aufgesetzt und diese in die Domain gehängt. Das Computerkonto befindet sich in einem Standort und die Netwzerkkarte in einem externen WLAN.

Habe mich dann per VPN verbunden und kann leider die Probleme nicht nachstellen.

Guten Tag,

3 Fileserver an 3 Standorten Windows 2016 und 2019

5 Namespaces unter \\domain.loc\domain mit 3 NamespaceServern

Ich habe ein kleines Problem mit DFS. Ein paar User aus einem unserer 3 Standorte bekommen die Fehlermeldung: "Der pfad ist nicht verfügbar." "Auf X:\Allgemein kann nicht zugegriffen werden." "das netzwerkadresse ist nicht erreichbar."

Wenn ich in die Einstellungen des Ordners (egal welcher der 5) unter DFS mit das Ziel/Referenzliste ansehe steht dort: \\fileserver1\Allgemein - Aktiv ja - Status ok

Gebe ich den Pfad in den Explorer ein habe ich kein Problem damit den Ordner zu erreichen.

Wenn ich dann in den explorer gehe auf \\domain.loc sehe ich den Ordner domain gehe dort hinein und kann auch alle Ordner erreichen.

Ob Servername, FQDN oder IP Adresse ich kann den Ordner erreichen. Es betrifft ebenfalls nicht alle Kollegen aus dem Standort. Es scheint hauptsächlich Personen im VPN daran zu leiden. nslookup, tracert und ping auf domain.loc etc zeigen allerdings keine Fehler.

Das gemappte Laufwerk wird korrekt angezeigt. Alle 3 Namespace Server haben den Status okay und man kann diese ohne Probleme wechseln.

Das einzige was also nicht geht ist der Click auf die Namespaces. Wie kann es sein das der Pfad der dort angezeigt wird per Explorer erreichbar ist, aber nicht per Click?

Ich hoffe jemand hat eine Idee.

Vielen dank.

Guten Tag,

bei einer Abfrage auf dem Exchange bekomme ich die Fehlermeldung „You have exceeded the maximum number of objects that can be returned for the find operation. Use paging to reduce the result size and try your request again.“

Nach ein bisschen suchen findet man viele Hinweise, dass man EWSFindCountLimit erhöhen soll. Diese Option gibt es aber in Exchange 2016 nicht mehr. Ich habe eine neue throttling policy erstellt und kann diese Option darin nicht finden und nicht anpassen. Gibt es eine andere Möglichkeit als Paging? Der Fehler sieht wie folgt aus:
 

Information: EWS-Service-Objekt initialisiert.
Information: Abfrage der Daten der Mitarbeiter aus der Datenbank.
Information: Daten von 72 aktiven und 0 inaktiven Mitarbeitern aus der Datenbank gelesen. Information: Starte Export der Termine aus Exchange.
Information: Suche Ordner vom Typ [Calendar].
Information: 72 Ordner von 72 Mitarbeitern gefunden.
Information: Abfrage der Termine aus Exchange.

Fehler: Problem bei der Abfrage der Termine aus Exchange für Benutzer [joe.exotic@tigerking.de]. (Sie haben die maximale Anzahl von Objekten überschritten, die für einen Suchvorgang zurückgegeben werden können. Verwenden Sie die Auslagerung, um die Ergebnisgröße zu verringern, und wiederholen Sie die Anforderung.)

Fehler: Problem bei der Abfrage der Termine aus Exchange für Benutzer [carole.baskin@tigerking.de]. (Sie haben die maximale Anzahl von Objekten überschritten, die für einen Suchvorgang zurückgegeben werden können. Verwenden Sie die Auslagerung, um die Ergebnisgröße zu verringern, und wieder holen Sie die Anforderung.)

Information: Abfrage der Termine aus Exchange abgeschlossen.
Information: Speichere Termine in der Datenbank.
Information: Speichern der Termine in der Datenbank abgeschlossen.
Information: Export der Termine aus Exchange abgeschlossen.
Information: 6243 Termine aus [vw_TermineAktuell] gelesen
Information: Löschen von Terminen aus der Datenbank, wenn der zugehörige Termin in Exchange nicht mehr vorhanden ist.
Information: Löschen von Terminen aus der Datenbank abgeschlossen.
Prozessexitcode 0.  Der Schritt war erfolgreich.

Wir nutzen auch Phish Threat von Sophos und das hat auf jedenfall einiges gebracht. Ich kann es nur empfehlen und das Lizenzmodell ist auch okay. Man muss nicht für jede Person eine Lizenz haben.

Das größte Problem finde ich dass emaisl durchkommen die z.B. von security@domain.de sind obwohl man diese Mailadresse nicht hat, weil ein envelope gemacht wurde. Habt ihr das gelöst?

Nachdem Neuinstallieren auch nichts gebracht hab, habe ich mir eine Hyper V VM genration 2 UEFI aufgesetzt um mit dieser zu testen. Da dort eine andere Fehlermeldung kam, bin ich auf einen Thread gestoßen der sagte man müsse NetBIOS über TCP/IP und LMHOSTS abfragen am Server deaktivieren. Nachdem ich dies getan habe, konnte ich auf der VM die installation ohne Probleme durchführen. Heute in der Firma lief es dann auch mit dem Laptops wieder.

Guten Tag,

ich habe auf einem Windows Server 2016 Standard Domaincontroller ebenfalls einen WDS installiert der mir bis anfang der Woche gute Dienste geleistet hat.

Als ich Montag einen neuen Laptop installieren wollte funktionierte die installation nicht mehr. Nachdem ich PXE Boot auswähle wirft es mich direkt auf den Bildschirm mit F1 for reboot F2 for setup etc.

Bei einem weiteren Laptop taucht die Meldung "PXE-E16 no offer received" auf.

Ich dachte es liegt mal wieder an den Treibern, also hab ich in die boot.wim die Treiber integriert, doch das half auch nicht.

Dann habe ich einen Laptop ausprobiert den ich am 31.03 noch neuinstalliert hatte über PXE. Dieser funktioniert nun auch nicht.

Ich habe dann das WDS neu initialisiert. Das half auch nicht.

Dann habe ich WDS deinstalliert, den Ordner RemoteInstall deinstalliert und neue boot.wim und install.wim hinzugefügt und auch das hat nicht funktioniert.

Das einzige was sich verändert hat ist die Ereignisanzeige. Wenn im Serverrollen Log ist am 31.03 keine Installation verzeichnet.

Wenn ich jetzt eine Versuche bekomme ich folgende Meldung:

Der folgende Client wurde per PXE gestartet:

Hardwareadresse: XX-EA-XX-XX-5B-EC
IP: 10.0.0.173
Geräte-ID: {4XXXXX-0053-XXXX-8034-B5XXXXXX5732}
Clientarchitektur: 4
Vorab bereitgestellt: false

und zwischendurch sehr viele Ereignisse mit 57350

Ein Endpunkt wurde von Anbieter "WDSTFTP" geöffnet.

Typ: UDP
Adresse: 64108

Hat jemand eine Idee wieso von heut auf morgen WDS komplett streikt. Seit dem 12.03 wurden keine Windows Updates installiert und das DHCP wurde ebenfalls nicht verändert.

Alle Laptops laufen auf UEFI mit secure boot.

Fun Fact: Eine VM die ich grad zusammengezimmert habe auf Hyper V lässt sich per PXE starten.

Auch wenn der Thread alt ist habe ich erneut ein paar Fragen:

Ich habe nun das von MS zu Verfügung stehende ISO runtergeladen SW_DVD9_NTRL_Win_10_1809_64Bit_MultiLang_FOD_1_X21-91307 und versucht das ganze auf meinem Windows 10 Enterprise 1809 zu installieren. Wenn ich es richtig verstanden habe gibt es einmal z.B. Microsoft-Windows-DNS-Tools-FoD-Package~31bf3856ad364e35~amd64~~.cab und dann noch die deutsche Version Microsoft-Windows-DNS-Tools-FoD-Package~31bf3856ad364e35~amd64~de-DE~.cab.

Leider lässt sich die Microsoft-Windows-DNS-Tools-FoD-Package~31bf3856ad364e35~amd64~~.cab nicht installieren und dism gibt mir den Fehler 0x800f0955.

Ein Fehlercode der her im Forum nicht zu finden ist und mich ratlos zurück lässt.

2020-03-24 16:25:11, Info                  DISM   DISM Package Manager: PID=22128 TID=25004 Further logs for online package and feature related operations can be found at %WINDIR%\logs\CBS\cbs.log - CPackageManagerCLIHandler::ExecuteCmdLine
2020-03-24 16:25:11, Error                 DISM   DISM.EXE: DISM Package Manager processed the command line but failed. HRESULT=800F0955

das hat mich dann zum cbs.log geführt

2020-03-24 16:25:11, Info                  CBS    Multi-lingual package can only be installed through /add-capability:Microsoft-Windows-DNS-Tools-FoD-Package~31bf3856ad364e35~amd64~~10.0.17763.1 [HRESULT = 0x800f0955 - CBS_E_INVALID_PACKAGE_REQUEST_ON_MULTILINGUAL_FOD]
2020-03-24 16:25:11, Info                  CBS    Failed to check capability logic [HRESULT = 0x800f0955 - CBS_E_INVALID_PACKAGE_REQUEST_ON_MULTILINGUAL_FOD]

mit Powershell C:\WINDOWS\system32> Get-WindowsCapability -Name RSAT* -Online | Add-WindowsCapability -Online -Source "E:\" -LimitAccess

konnte ich grad alle RSAT tools installieren.

vor 1 Minute schrieb NorbertFe:

Naja ist halt keine AV Konsole sondern ein komplettes Deployment System (plus den ganzen Rest vom System Center). Dass man das nicht mit "ich hab mal begonnen" lösen kann, sollte klar sein.

Das ist klar. Was ich meinte ist, man muss hier das ganze System nutzen und sich am besten mit allen teilen vertraut machen und Schade das es hier kein "einzelnes" Modul gibt, was die "Antivirus" spalte abbildet. Damit würde MS den Admins einen gefallen tun. Für WSUS gibt es schließlich auch eine einzelne Konsole was man dann aber über das sccm steuern kann.

vor 25 Minuten schrieb DocData:

SCCM kein beliebtes Produkt? Spärliche Doku? Reden wir von dem gleichen Config Manager?

In meinem Kontakt mit externen Kunden habe ich bis jetzt nur einmal das sccm gesehen. Vorallem bei kleinen bis mittleren Unternehmen wird dies kaum eingesetzt. Da wird WSUS und eventuell eine Softwareverteilung eingeführt und das wars. Das letzte Update vom Sccm ist doch auch schon 1 Jahr her oder? Daher meine Meinung das es nicht sehr beliebt ist.

vor 1 Minute schrieb mwiederkehr:

Mit Microsoft 365 kann man unter anderem den Defender zentral verwalten und Benachrichtigungen sammeln. Bei Business ist der normale Defender dabei, bei E5 der Defender ATP. Falls ihr jetzt schon Office 365 nutzt, könnte das eine Option sein.

Vielen Dank. Bis jetzt ist 365 noch kein großes Thema aber das ist jetzt noch ein Punkt wo es wieder interessanter wird.

vor 12 Stunden schrieb NorbertFe:

Nennt sich sccm und kostet im Rahmen der System Center Suite ne Menge Geld ;)

Microsoft Gold Partner macht es möglich. Ich habe mit sccm mal begonnen und war leicht erschlagen von den Möglichkeiten und der doch recht sparsamen und umständlichen Dokumentation? Es scheint kein beliebtes MS Programm/System zu sein, aber wenn damit die komplette Verwaltung von Windows Defender möglich ist, ist es ein wenig interessanter...

Guten Tag,

der Windows Defender hat ja im Antiviren test in letzter Zeit gar nicht so schlecht abgeschnitten und ist bei uns auf Servern und einigen Clients aktiv und ich würde gerne in Zukunft auf Antiviren Programme verzichten.

Leider bietet der Windows Defender soweit ich weiß keine Mail Benachrichtigung an und ein Security Center zur Verwwaltung und Überprüfung der Client kenne ich auch nicht. Gibt es eine Möglichkeit über GPO eine Mail Benachrichtigung zu konfigurieren und bietet Microsoft oder ein Third Party hersteller irgendwas an um den Windows Defender zu verwalten?

Oder ist das alles gar nicht nötig und ich sollte es einfach laufen lassen? Oder rät jemand komplett davon ab dem Windows Dender zu vertrauen?

Guten Tag,

sobald ich Hyper-V auf meinem frischen Windows 10 1809 installiere habe ich kein Internet mehr. DIe Standardverbindung wird zwar als aktiv angezeigt aber ohne Internetverbindung. WLAN lässt sich nicht mehr verbinden.

Es sind 2 Default Switches vorhanden.

Sobald ich dann einen V-Switch erstelle mit Extern und teilen der gemeinsamen Verbindung des LAN Adapters, erstellt Hyper-V einen Default Switch nach dem anderen ohne ende.

Hat jemand ein ähnlich seltsames verhalten mal beobachten und kann mir einen Rat geben, außer Hyper-V zu deinstallieren.

vor 2 Minuten schrieb NilsK:

Moin,

 

du wirst die RSAT ja kaum flächendeckend ausrollen. Daher dürfte es unproblematisch sein, für die betreffenden Rechner die MS-Updateserver freizugeben. Ohne die wird es jedenfalls nicht ohne Klimmzüge gehen.

 

Gruß, Nils

 

Ja, hast recht, das könnte ich machen.

Wieso gibt es das FoD Iso mit den cab Datein wenn vom dem Mist nichts funktioniert? Wäre eine Möglichkeit über sccm denkbar?

vor 3 Minuten schrieb NilsK:

Moin,

 

hilft dies?

 

[RSAT für Windows 10 v1809 – total easy … | faq-o-matic.net]
https://www.faq-o-matic.net/2018/11/21/rsat-fr-windows-10-v1809-total-easy/

 

Gruß, Nils

 

Ich habe in der Windows Update Richtlinie die Verbindung zu den Microsoft Servern untersagt, und soweit ich es verstanden habbe müsste ich asuch die  "Computerkonfiguration – Administrative Vorlagen - Windows komponenten - WindowsUpdate: Keine Verbindung mit Windows Update-Internetadressen " ändern. Da der WSUS aktiv ist, würde ich das an der Stelle ungern ändern. Es sei denn es macht keinen Unterschied. Ich weiß nämlich nicht ob der WSUS Priorisiert angesteuert wird und die Regel hinfällig ist, oder ob diese aktiv sein muss, damit die Rechner nicht plötzlich ganz viel aus dem Netz ziehen.

vor 43 Minuten schrieb MurdocX:

Sind dort die Module schon zu finden?

C:\Windows\System32\WindowsPowerShell\v1.0\Modules

 

Da ich nicht weiß wie die Ordner aussehen oder heißen müssen ist das schwer zu beantworten.

Dort ist kein Ordner mit *Rsat* vorhanden

Im DhcpServer Ordner ist ein de-DE Ordner wo eine DhcpServerMIgration.psd1 Datei enthalten ist

In den DNS Ordnern ist auch nicht viel mehr drin.

Also ich würde sagen nein.

vor 15 Stunden schrieb MurdocX:

Probier es nochmal mit den beiden Parametern. Den ersten auf jeden Fall, den Zweiten optional für mehr Infos.

-LimitAccess
Indicates that this cmdlet does not access Windows Update for the source package.

-LogLevel
Specifies the maximum output level shown in the logs. The default log level is 3. The accepted values are as follows:

1 = Errors only
2 = Errors and warnings
3 = Errors, warnings, and information
4 = All of the information listed previously, plus debug output

 

-LimitAccess bringt keine Änderung

-loglevel 4 gibt aus: Add-WindowsCapability : Der Parameter "LogLevel" kann nicht gebunden werden. Der Wert "4" kann aufgrund von ungültigen
Enumerationswerten nicht in den Typ "Microsoft.Dism.Commands.LogLevel" konvertiert werden. Geben Sie einen der
folgenden Enumerationswerte an, und versuchen Sie es erneut. Mögliche Enumerationswerte sind
"Errors;Warnings;WarningsInfo".

im mmc ist nichts zu finden, über Ausführen dsa.msc oder die anderen öffnet sich nichts.