Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[Win 2003 Server 32 / Win10pro64] Kein Zugriff auf Sysvol und Netlogon
382 views
Skip to first unread message
André Jochim
Sep 27, 2016, 8:48:31 AM9/27/16
to
Hallo,
ich habe hier als DC einen Windows Server 2003 Standard. Ich weiss, daß
das System inzwischen antik ist, aber das kleine Inselnetz mit ca. 11
Clients hat keine Internet-Anbindung und der Server muss eigentlich nur
als Fileserver dienen, damit zentral abgelegte Programme an mehreren
Clients aufgerufen werden können.
Als die Clients noch mit 1x WindowsXPpro und sonst Win7pro64bit
ausgestattet waren, hatte ich unter \\Servername\NETLOGON eine
Batchdatei angelegt, die freigegebenen Netzlaufwerken mit Hilfe von Net
use Befehlen Laufwerksbuchstaben zugeordnet hat.
Diesen Namen der Batchdatei habe ich in der 'AD-Benutzer- und
Computer-Verwaltung' bei den entsprechenden Usern unter Profil >
Anmeldeskript angegeben.
Inzwischen haben die Clients alle Win10pro64 - und das Zuweisen der
Laufwerke mit HIlfe des Skripts funktioniert nicht mehr.
Egal, ob ich die Datei als anmeldeskript.bat oder als anmeldeskript.cmd
benenne, scheinen die Befehle nicht abgearbeitet zu werden.
Dabei ist mir auch aufgefallen, daß ich beim Aufruf des
netlogon-Verzeichnisses im Explorer mit \\Servername\netlogon eine
Abfrage nach Zugangsdaten erhalte, obwohl das Verzeichnis für den
angemeldeten Benutzer freigegeben ist. Auch die Eingabe der
admin-Credentials führt zur Meldung, daß der Zugriff verweigert wird.
Hmmmm... - woran kann das liegen? Wahrscheinlich kann es mit den
verhinderten Zugriffen auf die Netlogon-Freigabe zusammenhängen, denn
wenn die Clients hier nicht zugreifen können, dann kann wohl auch das
Skript nicht abgearbeitet werden... - aber warum?
Alle anderen Serverfreigaben können normal aufgerufen werden. Nur die
Freigaben Sysvol und Netlogon nicht.
Gibt es hier grundsätzliche Probleme im Zugriff von Windows10-Clients
aus auf die Standardfreigabepfade der Netzwerk-Anmeldeskripte?
Ich habe sogar schon versucht, eine Gruppenrichtlinie zur Erstellung der
Netzlaufwerke zu erstellen. Aber auf die kann der Client auch nicht
zugreifen und die Richtlinie nicht einbinden. Diese wird ja auch unter
\\servername\sysvol\domainname.local\policies abgelegt. Und da das ein
Unterverzeichnis von Sysvol ist, hat der Client auch hier keinen Zugriff...
Da muss wohl irgendetwas in der Netzwerkkommunikation von Win10
verändert worden sein.
Ich hoffe, Ihr könnt mir helfen.
André
--
Traumferienwohnung gesucht? (4**** nach DTV)
Urlaub in der Mecklenburgischen Seenplatte...
www.urlaub-in-sorgenlos.de
ich habe hier als DC einen Windows Server 2003 Standard. Ich weiss, daß
das System inzwischen antik ist, aber das kleine Inselnetz mit ca. 11
Clients hat keine Internet-Anbindung und der Server muss eigentlich nur
als Fileserver dienen, damit zentral abgelegte Programme an mehreren
Clients aufgerufen werden können.
Als die Clients noch mit 1x WindowsXPpro und sonst Win7pro64bit
ausgestattet waren, hatte ich unter \\Servername\NETLOGON eine
Batchdatei angelegt, die freigegebenen Netzlaufwerken mit Hilfe von Net
use Befehlen Laufwerksbuchstaben zugeordnet hat.
Diesen Namen der Batchdatei habe ich in der 'AD-Benutzer- und
Computer-Verwaltung' bei den entsprechenden Usern unter Profil >
Anmeldeskript angegeben.
Inzwischen haben die Clients alle Win10pro64 - und das Zuweisen der
Laufwerke mit HIlfe des Skripts funktioniert nicht mehr.
Egal, ob ich die Datei als anmeldeskript.bat oder als anmeldeskript.cmd
benenne, scheinen die Befehle nicht abgearbeitet zu werden.
Dabei ist mir auch aufgefallen, daß ich beim Aufruf des
netlogon-Verzeichnisses im Explorer mit \\Servername\netlogon eine
Abfrage nach Zugangsdaten erhalte, obwohl das Verzeichnis für den
angemeldeten Benutzer freigegeben ist. Auch die Eingabe der
admin-Credentials führt zur Meldung, daß der Zugriff verweigert wird.
Hmmmm... - woran kann das liegen? Wahrscheinlich kann es mit den
verhinderten Zugriffen auf die Netlogon-Freigabe zusammenhängen, denn
wenn die Clients hier nicht zugreifen können, dann kann wohl auch das
Skript nicht abgearbeitet werden... - aber warum?
Alle anderen Serverfreigaben können normal aufgerufen werden. Nur die
Freigaben Sysvol und Netlogon nicht.
Gibt es hier grundsätzliche Probleme im Zugriff von Windows10-Clients
aus auf die Standardfreigabepfade der Netzwerk-Anmeldeskripte?
Ich habe sogar schon versucht, eine Gruppenrichtlinie zur Erstellung der
Netzlaufwerke zu erstellen. Aber auf die kann der Client auch nicht
zugreifen und die Richtlinie nicht einbinden. Diese wird ja auch unter
\\servername\sysvol\domainname.local\policies abgelegt. Und da das ein
Unterverzeichnis von Sysvol ist, hat der Client auch hier keinen Zugriff...
Da muss wohl irgendetwas in der Netzwerkkommunikation von Win10
verändert worden sein.
Ich hoffe, Ihr könnt mir helfen.
André
--
Traumferienwohnung gesucht? (4**** nach DTV)
Urlaub in der Mecklenburgischen Seenplatte...
www.urlaub-in-sorgenlos.de
André Jochim
Sep 27, 2016, 4:09:17 PM9/27/16
to
Am 27.09.16 um 19:28 schrieb Falk Duebbert:
> a) \\DeineDOMAIN\NETLOGON
> b) \\DeineDOMAIN\SYSVOL
> c) keine UNC-Pfade in Anmeldeskripten
a) + b)
Das hilft mir so ja irgendwie nicht unbedingt weiter, selbst wenn ich
über den Explorer so vielleicht vom Client auf die Ordner zugreifen
kann. Die unter Profil angegebenen Anmeldescripte bzw. für
Laufwerkmappings angelegte GPOs kommen ja nicht beim Client an -
wahrscheinlich wegen des nicht möglichen Zugriffs auf diese Ordner. Und
bzgl. der Art des Zugriffs auf die Ordner habe ich im Anmeldeprozess
doch gar keinen Einfluss - oder?
c) hier sind keine UNC-Pfade
Das muss irgendetwas mit Sicherheitseinstellungen zu tun haben, die in
Windows 10 implementiert wurden.
Ich habe nochmal ein bisschen rumgelesen und inzwischen einen Hinweis
auf 'gehärtete UNC-Pfade' gefunden. Wenn man in den lokalen
Gruppenrichtlinien unter Computerkonfiguration > administrative Vorlagen
> Netzwerk > Netzwerkanbieter den Schlüssel 'gehärtete UNC-Pfade'
aktiviert und unter 'Anzeigen' dann die folgenden Daten eingibt, dann
funktioniert der Zugriff.
\\*\SYSVOL RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0
\\*\NETLOGON
RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0
Auch wenn unter 'https://support.microsoft.com/en-us/kb/3000483' steht:
------------------------------------------------------------------
Windows Server 2003 SP2
We determined that implementing these changes in Windows Server 2003 SP2
would require such comprehensive architecture changes that it would
destabilize the system and result in application compatibility problems.
We continue to recommend that customers who are security-conscious
upgrade to our latest operating systems to keep pace with security
threats and benefit from robust, modern operating system protection.
------------------------------------------------------------------
Leider kann man diese Gruppenrichtlinien-Einstellungen nicht über den
Server verteilen, da die Clients im jetzigen Zustand ja überhaupt keine
Gruppenrichtlinien finden...
So muss man alles an jedem Client einzeln einstellen.
Etwas besser ging es dann, wenn man diese Einstellungen nicht in den
lokalen Richtlinien, sondern wie unter
'http://serverfault.com/questions/754012/windows-10-unable-to-access-sysvol-and-netlogon'
beschrieben in der Registry durchführt.
Einfach in
HKLM\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths
die Zeichenfolgen \\*\SYSVOL und \\*\NETLOGON jeweils mit dem Wert
RequireMutualAuthentication=0 hinzufügen.
Und dafür kann man sich eine kleine Batch-Datei mit folgendem Inhalt
schreiben, die man dann einfach nur mit 'als admin ausführen' starten muss:
------------------------------------------------------------------
%COMSPEC% /C reg add
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths
/v "\\*\SYSVOL" /d "RequireMutualAuthentication=0" /t REG_SZ
%COMSPEC% /C reg add
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths
/v "\\*\NETLOGON" /d "RequireMutualAuthentication=0" /t
REG_SZ
------------------------------------------------------------------
So kann ich wenigstens erst einmal meine Netzlaufwerke mit Hilfe der
erstellen Skripts zuweisen, so wie es vor Win10 auch ging.
Aber ob da so wirklich im Sinne des Erfinders ist, wage ich zu
bezweifeln. Aber da es für Win2K3 ja keinen Support mehr gibt, wird sich
daran wohl auch nichts mehr ändern.
> a) \\DeineDOMAIN\NETLOGON
> b) \\DeineDOMAIN\SYSVOL
> c) keine UNC-Pfade in Anmeldeskripten
a) + b)
Das hilft mir so ja irgendwie nicht unbedingt weiter, selbst wenn ich
über den Explorer so vielleicht vom Client auf die Ordner zugreifen
kann. Die unter Profil angegebenen Anmeldescripte bzw. für
Laufwerkmappings angelegte GPOs kommen ja nicht beim Client an -
wahrscheinlich wegen des nicht möglichen Zugriffs auf diese Ordner. Und
bzgl. der Art des Zugriffs auf die Ordner habe ich im Anmeldeprozess
doch gar keinen Einfluss - oder?
c) hier sind keine UNC-Pfade
Das muss irgendetwas mit Sicherheitseinstellungen zu tun haben, die in
Windows 10 implementiert wurden.
Ich habe nochmal ein bisschen rumgelesen und inzwischen einen Hinweis
auf 'gehärtete UNC-Pfade' gefunden. Wenn man in den lokalen
Gruppenrichtlinien unter Computerkonfiguration > administrative Vorlagen
> Netzwerk > Netzwerkanbieter den Schlüssel 'gehärtete UNC-Pfade'
aktiviert und unter 'Anzeigen' dann die folgenden Daten eingibt, dann
funktioniert der Zugriff.
\\*\SYSVOL RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0
\\*\NETLOGON
RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0
Auch wenn unter 'https://support.microsoft.com/en-us/kb/3000483' steht:
------------------------------------------------------------------
Windows Server 2003 SP2
We determined that implementing these changes in Windows Server 2003 SP2
would require such comprehensive architecture changes that it would
destabilize the system and result in application compatibility problems.
We continue to recommend that customers who are security-conscious
upgrade to our latest operating systems to keep pace with security
threats and benefit from robust, modern operating system protection.
------------------------------------------------------------------
Leider kann man diese Gruppenrichtlinien-Einstellungen nicht über den
Server verteilen, da die Clients im jetzigen Zustand ja überhaupt keine
Gruppenrichtlinien finden...
So muss man alles an jedem Client einzeln einstellen.
Etwas besser ging es dann, wenn man diese Einstellungen nicht in den
lokalen Richtlinien, sondern wie unter
'http://serverfault.com/questions/754012/windows-10-unable-to-access-sysvol-and-netlogon'
beschrieben in der Registry durchführt.
Einfach in
HKLM\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths
die Zeichenfolgen \\*\SYSVOL und \\*\NETLOGON jeweils mit dem Wert
RequireMutualAuthentication=0 hinzufügen.
Und dafür kann man sich eine kleine Batch-Datei mit folgendem Inhalt
schreiben, die man dann einfach nur mit 'als admin ausführen' starten muss:
------------------------------------------------------------------
%COMSPEC% /C reg add
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths
/v "\\*\SYSVOL" /d "RequireMutualAuthentication=0" /t REG_SZ
%COMSPEC% /C reg add
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths
/v "\\*\NETLOGON" /d "RequireMutualAuthentication=0" /t
REG_SZ
------------------------------------------------------------------
So kann ich wenigstens erst einmal meine Netzlaufwerke mit Hilfe der
erstellen Skripts zuweisen, so wie es vor Win10 auch ging.
Aber ob da so wirklich im Sinne des Erfinders ist, wage ich zu
bezweifeln. Aber da es für Win2K3 ja keinen Support mehr gibt, wird sich
daran wohl auch nichts mehr ändern.
Winfried Sonntag
Sep 27, 2016, 6:07:03 PM9/27/16
to
Am 27.09.2016 schrieb André Jochim:
> Als die Clients noch mit 1x WindowsXPpro und sonst Win7pro64bit
> ausgestattet waren, hatte ich unter \\Servername\NETLOGON eine
> Batchdatei angelegt, die freigegebenen Netzlaufwerken mit Hilfe von Net
> use Befehlen Laufwerksbuchstaben zugeordnet hat.
Schlecht, besser mit \\Domain.tld\netlogon arbeiten.
> Als die Clients noch mit 1x WindowsXPpro und sonst Win7pro64bit
> ausgestattet waren, hatte ich unter \\Servername\NETLOGON eine
> Batchdatei angelegt, die freigegebenen Netzlaufwerken mit Hilfe von Net
> use Befehlen Laufwerksbuchstaben zugeordnet hat.
> Diesen Namen der Batchdatei habe ich in der 'AD-Benutzer- und
> Computer-Verwaltung' bei den entsprechenden Usern unter Profil >
> Anmeldeskript angegeben.
>
> Inzwischen haben die Clients alle Win10pro64 - und das Zuweisen der
> Laufwerke mit HIlfe des Skripts funktioniert nicht mehr.
>
> Egal, ob ich die Datei als anmeldeskript.bat oder als anmeldeskript.cmd
> benenne, scheinen die Befehle nicht abgearbeitet zu werden.
> Dabei ist mir auch aufgefallen, daß ich beim Aufruf des
> netlogon-Verzeichnisses im Explorer mit \\Servername\netlogon eine
> Abfrage nach Zugangsdaten erhalte, obwohl das Verzeichnis für den
> angemeldeten Benutzer freigegeben ist. Auch die Eingabe der
> admin-Credentials führt zur Meldung, daß der Zugriff verweigert wird.
http://www.gruppenrichtlinien.de/artikel/smb-signing-kommunikation-digital-signieren/
Jetzt weißt Du auch, weshalb der W2003 nicht mehr betrieben werden
sollte. Wenn die Clients die geänderten GPOs nicht übernehmen, mußt Du
eben gem. Bestpraxis manuell einstellen.
Servus
Winfried
--
WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
GPO's: http://www.gruppenrichtlinien.de
NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/
André Jochim
Sep 28, 2016, 3:16:41 PM9/28/16
to
Am 28.09.16 um 00:07 schrieb Winfried Sonntag:
>> \\Servername\NETLOGON
> Schlecht, besser mit \\Domain.tld\netlogon arbeiten.
> Fehlermeldungen im Ereignisprotokoll?
Server? Oder Client?
Im Client gab es zumindest die folgende Meldung bzgl. der über die GPO
nicht ausführbaren Batchdatei als Logon-Script.
---------------------------------------------------------------------------
Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Versuch, die
Datei
“\\meinedomäne.local\sysvol\meinedomäne.local\Policies\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}\XXX.XXX”
von einem Domänencontroller zu lesen, war nicht erfolgreich. Die
Gruppenrichtlinieneinstellungen dürfen nicht angewendet werden, bis
dieses Ereignis behoben ist. Dies ist möglicherweise ein vorübergehendes
Problem, das mindestens eine der folgenden Ursachen haben kann:
a) Namensauflösung/Netzwerkverbindung mit dem aktuellen Domänencontroller.
b) Wartezeit des Dateireplikationsdienstes (eine auf einem anderen
Domänencontroller erstellte Datei hat nicht auf dem aktuellen
Domänencontroller repliziert).
c) Der DFS-Client (Distributed File System) wurde deaktiviert.
---------------------------------------------------------------------------
> SMB-Signing ist schuld.
> http://www.gruppenrichtlinien.de/artikel/smb-signing-kommunikation-digital-signieren/
> Jetzt weißt Du auch, weshalb der W2003 nicht mehr betrieben werden
> sollte. Wenn die Clients die geänderten GPOs nicht übernehmen, mußt Du
> eben gem. Bestpraxis manuell einstellen.
Wie ich in dem o.g. Link gelesen und hoffentlich richtig verstanden
habe, sind die Pakete bei 2003-Server (mit SMB1.0) in der Größe
begrenzt, so daß ein durch SMB-Signing hinzugefügter Header in
ungünstigen Fällen die Netzwerkperformance deutlich drücken kann.
Ist es in der Kombination W2K3-Server und Win10-Clients dann nicht
sinnvoll, die Einstellungen nicht nach Bestpractise zu konfigurieren,
sondern so wie am Ende beschrieben abzuschalten?
Warum funktioniert der Zugriff auf die Anmeldescripte über Profil
genauso wie auch die GPOs nach Einfügen der Einträge in
>> \\Servername\NETLOGON
> Schlecht, besser mit \\Domain.tld\netlogon arbeiten.
Server? Oder Client?
Im Client gab es zumindest die folgende Meldung bzgl. der über die GPO
nicht ausführbaren Batchdatei als Logon-Script.
---------------------------------------------------------------------------
Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Versuch, die
Datei
“\\meinedomäne.local\sysvol\meinedomäne.local\Policies\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}\XXX.XXX”
von einem Domänencontroller zu lesen, war nicht erfolgreich. Die
Gruppenrichtlinieneinstellungen dürfen nicht angewendet werden, bis
dieses Ereignis behoben ist. Dies ist möglicherweise ein vorübergehendes
Problem, das mindestens eine der folgenden Ursachen haben kann:
a) Namensauflösung/Netzwerkverbindung mit dem aktuellen Domänencontroller.
b) Wartezeit des Dateireplikationsdienstes (eine auf einem anderen
Domänencontroller erstellte Datei hat nicht auf dem aktuellen
Domänencontroller repliziert).
c) Der DFS-Client (Distributed File System) wurde deaktiviert.
---------------------------------------------------------------------------
> SMB-Signing ist schuld.
> http://www.gruppenrichtlinien.de/artikel/smb-signing-kommunikation-digital-signieren/
> Jetzt weißt Du auch, weshalb der W2003 nicht mehr betrieben werden
> sollte. Wenn die Clients die geänderten GPOs nicht übernehmen, mußt Du
> eben gem. Bestpraxis manuell einstellen.
habe, sind die Pakete bei 2003-Server (mit SMB1.0) in der Größe
begrenzt, so daß ein durch SMB-Signing hinzugefügter Header in
ungünstigen Fällen die Netzwerkperformance deutlich drücken kann.
Ist es in der Kombination W2K3-Server und Win10-Clients dann nicht
sinnvoll, die Einstellungen nicht nach Bestpractise zu konfigurieren,
sondern so wie am Ende beschrieben abzuschalten?
Warum funktioniert der Zugriff auf die Anmeldescripte über Profil
genauso wie auch die GPOs nach Einfügen der Einträge in
HKLM\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths
wie von mir beschrieben, wenn doch SMB-Signing schuld ist?
Winfried Sonntag
Sep 28, 2016, 5:15:26 PM9/28/16
to
Am 28.09.2016 schrieb André Jochim:
> Am 28.09.16 um 00:07 schrieb Winfried Sonntag:
>>> \\Servername\NETLOGON
>
>> Schlecht, besser mit \\Domain.tld\netlogon arbeiten.
>
>> Fehlermeldungen im Ereignisprotokoll?
>
> Server? Oder Client?
Client, der hat ja Probleme mit der Übernahme des Scriptes.
> Am 28.09.16 um 00:07 schrieb Winfried Sonntag:
>>> \\Servername\NETLOGON
>
>> Schlecht, besser mit \\Domain.tld\netlogon arbeiten.
>
>> Fehlermeldungen im Ereignisprotokoll?
>
> Server? Oder Client?
> Im Client gab es zumindest die folgende Meldung bzgl. der über die GPO
> nicht ausführbaren Batchdatei als Logon-Script.
>
> ---------------------------------------------------------------------------
> Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Versuch, die
> Datei
> “\\meinedomäne.local\sysvol\meinedomäne.local\Policies\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}\XXX.XXX”
> von einem Domänencontroller zu lesen, war nicht erfolgreich. Die
> Gruppenrichtlinieneinstellungen dürfen nicht angewendet werden, bis
> dieses Ereignis behoben ist. Dies ist möglicherweise ein vorübergehendes
> Problem, das mindestens eine der folgenden Ursachen haben kann:
> a) Namensauflösung/Netzwerkverbindung mit dem aktuellen Domänencontroller.
> b) Wartezeit des Dateireplikationsdienstes (eine auf einem anderen
> Domänencontroller erstellte Datei hat nicht auf dem aktuellen
> Domänencontroller repliziert).
> c) Der DFS-Client (Distributed File System) wurde deaktiviert.
> ---------------------------------------------------------------------------
>> SMB-Signing ist schuld.
>> http://www.gruppenrichtlinien.de/artikel/smb-signing-kommunikation-digital-signieren/
>> Jetzt weißt Du auch, weshalb der W2003 nicht mehr betrieben werden
>> sollte. Wenn die Clients die geänderten GPOs nicht übernehmen, mußt Du
>> eben gem. Bestpraxis manuell einstellen.
>
> Wie ich in dem o.g. Link gelesen und hoffentlich richtig verstanden
> habe, sind die Pakete bei 2003-Server (mit SMB1.0) in der Größe
> begrenzt, so daß ein durch SMB-Signing hinzugefügter Header in
> ungünstigen Fällen die Netzwerkperformance deutlich drücken kann.
>
> Ist es in der Kombination W2K3-Server und Win10-Clients dann nicht
> sinnvoll, die Einstellungen nicht nach Bestpractise zu konfigurieren,
> sondern so wie am Ende beschrieben abzuschalten?
unsicherste. Probier es mit Best Praxis aus, anschließend kannst Du
immer noch abschalten. Besser wäre es natürlich, den Server in Rente
zu schicken und etwas aktuelleres aufzustellen.
> Warum funktioniert der Zugriff auf die Anmeldescripte über Profil
> genauso wie auch die GPOs nach Einfügen der Einträge in
> HKLM\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths
> wie von mir beschrieben, wenn doch SMB-Signing schuld ist?
Erklärung dafür finden: https://support.microsoft.com/de-de/kb/3000483
André Jochim
Sep 28, 2016, 5:47:31 PM9/28/16
to
Am 28.09.16 um 23:15 schrieb Winfried Sonntag:
> Client, der hat ja Probleme mit der Übernahme des Scriptes.
Schaue ich morgen nochmal nach.
> Es gibt nur diesen einen DC?
Ja
> Abschalten ist natürlich die einfachste Möglichkeit, aber auch die
> unsicherste.
Da unser Netz eine Insel ohne Verbindung nach Außen ist (bis auf
zwischendurch mal ein Update), spielt die Sicherheit hier bestimmt eine
nur untergeordnete Rolle.
> Probier es mit Best Praxis aus, anschließend kannst Du
> immer noch abschalten. Besser wäre es natürlich, den Server in Rente
> zu schicken und etwas aktuelleres aufzustellen.
Die angegebenen Einstellungen müssen dann sowohl am Server als auch an
den Clients durchgeführt werden - oder?
> Wenn ich es richtig gelesen habe, solltest Du in diesem Artikel eine
> Erklärung dafür finden: https://support.microsoft.com/de-de/kb/3000483
Hier steht leider aber auch:
Windows Server 2003 SP2
Wir stellten fest, dass die Umsetzung dieser Änderungen in Windows
Server 2003 SP2 derart umfassende Architekturänderungen erforderlich
machen würde, dass das System destabilisiert werden würde und Probleme
mit der Anwendungskompatibilität entstehen würden. Wir empfehlen
sicherheitsbewussten Kunden weiterhin, ein Update auf unsere neuesten
Betriebssysteme durchzuführen, um mit Sicherheitsbedrohungen Schritt
halten und von dem robusten Schutz moderner Betriebssysteme profitieren
zu können.
Klingt eher so, als würde sich das mit deinem Rat zur Rentenbeantragung
für den 2K3 decken.
> Client, der hat ja Probleme mit der Übernahme des Scriptes.
> Es gibt nur diesen einen DC?
> Abschalten ist natürlich die einfachste Möglichkeit, aber auch die
> unsicherste.
zwischendurch mal ein Update), spielt die Sicherheit hier bestimmt eine
nur untergeordnete Rolle.
> Probier es mit Best Praxis aus, anschließend kannst Du
> immer noch abschalten. Besser wäre es natürlich, den Server in Rente
> zu schicken und etwas aktuelleres aufzustellen.
den Clients durchgeführt werden - oder?
> Wenn ich es richtig gelesen habe, solltest Du in diesem Artikel eine
> Erklärung dafür finden: https://support.microsoft.com/de-de/kb/3000483
Windows Server 2003 SP2
Wir stellten fest, dass die Umsetzung dieser Änderungen in Windows
Server 2003 SP2 derart umfassende Architekturänderungen erforderlich
machen würde, dass das System destabilisiert werden würde und Probleme
mit der Anwendungskompatibilität entstehen würden. Wir empfehlen
sicherheitsbewussten Kunden weiterhin, ein Update auf unsere neuesten
Betriebssysteme durchzuführen, um mit Sicherheitsbedrohungen Schritt
halten und von dem robusten Schutz moderner Betriebssysteme profitieren
zu können.
Klingt eher so, als würde sich das mit deinem Rat zur Rentenbeantragung
für den 2K3 decken.
Winfried Sonntag
Sep 29, 2016, 12:55:06 AM9/29/16
to
Am 28.09.2016 schrieb André Jochim:
> Am 28.09.16 um 23:15 schrieb Winfried Sonntag:
>> Abschalten ist natürlich die einfachste Möglichkeit, aber auch die
>> unsicherste.
>
> Da unser Netz eine Insel ohne Verbindung nach Außen ist (bis auf
> zwischendurch mal ein Update), spielt die Sicherheit hier bestimmt eine
> nur untergeordnete Rolle.
Und das zwischendurch ist sicher nicht ganz ungefährlich.
>> unsicherste.
>
> Da unser Netz eine Insel ohne Verbindung nach Außen ist (bis auf
> zwischendurch mal ein Update), spielt die Sicherheit hier bestimmt eine
> nur untergeordnete Rolle.
>> Probier es mit Best Praxis aus, anschließend kannst Du
>> immer noch abschalten. Besser wäre es natürlich, den Server in Rente
>> zu schicken und etwas aktuelleres aufzustellen.
>
> Die angegebenen Einstellungen müssen dann sowohl am Server als auch an
> den Clients durchgeführt werden - oder?
>> Wenn ich es richtig gelesen habe, solltest Du in diesem Artikel eine
>> Erklärung dafür finden: https://support.microsoft.com/de-de/kb/3000483
>
> Hier steht leider aber auch:
> Windows Server 2003 SP2
> Wir stellten fest, dass die Umsetzung dieser Änderungen in Windows
> Server 2003 SP2 derart umfassende Architekturänderungen erforderlich
> machen würde, dass das System destabilisiert werden würde und Probleme
> mit der Anwendungskompatibilität entstehen würden. Wir empfehlen
> sicherheitsbewussten Kunden weiterhin, ein Update auf unsere neuesten
> Betriebssysteme durchzuführen, um mit Sicherheitsbedrohungen Schritt
> halten und von dem robusten Schutz moderner Betriebssysteme profitieren
> zu können.
>
> Klingt eher so, als würde sich das mit deinem Rat zur Rentenbeantragung
> für den 2K3 decken.
müssen.
0 new messages