zahni

Man kann die Dateizugriffe per Windows Security Auditing protokollieren: https://www.eventtracker.com/newsletters/auditing-file-shares-windows-security-log/ https://blogs.technet.microsoft.com/mspfe/2013/08/26/auditing-file-access-on-file-servers/

- Wozu ist die Zone _msdcs.xxx gut? Die hat da nichts zu suchen. - Nur "sichere Updates" erlauben hat ein paar Seiteneffekte. Du musst auch auf die korrekte Config achten: https://technet.microsoft.com/en-us/library/cc961412.aspx Prüfen einfach mal auf beiden DNS-Servern, ob alle AD-Einträge im DNS vorhanden und auf allen DCs identisch sind:

Bei den richtigen Server-Herstellern bekommst Du keine "Silent Server". Schon gar nicht, wenn eine fette Nvidia GRID eingebaut ist. http://www.nvidia.de/grid/technology/microsoft/ http://www.nvidia.de/object/grid-certified-servers-de.html BTW: Die GRID-Karten sind richtig teuer...

Ist die DNS-Zone im AD integriert? Wenn nicht: Nachholen.

Die kumulativen Updates wurden irgendwann eingeführt, allerdings auf Basis des bis dahin gültigen Patchlevels. Installiere einfach alles und gut ist es,

Kennen denn die Clients auch beide DNS-Server? Wenn man einen DC herunterfährt, ist auch dessen DNS wech,

Ohne die msdcs-Einträge wird das nichts.

Mit https://www.tenable.com/products/nessus-vulnerability-scanner kann man durchaus umgehen. Allerdings sollte man mit den Ergebnissen schon was anfangen können.

PS: unter Windows löscht man den CLR-Cache mit certutil -urlcache * delete

Wenn Du erreichen möchtest, dass ein Client-Cert sofort gesperrt wird, kommst Du um einen Online-Responder nicht herum. Dateibasierte CRLs werden am Client in der Regel gecacht und können daher veraltet sein.

Wie Nils schrieb: Die Daten und auch die Roaming Profiles am (Haupt)-Standort belassen. Dort Terminal-Server einrichten. Die Nebenstandorte greifen dann auf diesen Terminal-Server zu. Dann hat Du auch keine Performance-Probleme.

Sehe ich jetzt erst: Macht man das so?

Die Eingabe von UNC-Pfaden im Explorer kann man per GPO abstellen. Sorry, welche das ist, fällt mir spontan nicht ein. BTW: wenn der User es macht: Wo ist das Problem? Das kann man gut für eine Erziehungsmaßnahme nutzen.

Erstelle das Home-Laufwerk doch einfach auf \\servername\mitarbeiter\benutzer1

Wenn Du schon mit einem Wartungs-Job die DB reorganisiert und die Statistiken aktualisiert hast, schau mal hier (u.a. auch meine Beiträge): http://www.mcseboard.de/topic/198302-sql-server-performance-steigern/

Irgendwie kann ich Dir nicht folgen. Wieso hast Du einen DNS-Server installiert? Der SBS installiert den zwangsweise, so wie jeder andere Windows-DC. Wenn Du ihn natürlich neu installiert hast, fehlen die AD-Einträge. Das behebt man mit einem Neustart des Servers oder mit dem Neustart von Netlogon-Server, gefolgt von ipconfig /registerdns . Für "sichere Updates" braucht es ein paar Voraussetzungen: https://technet.microsoft.com/en-us/library/cc961412.aspx Wichtig: Die Zone muss AD-Integriert sein. EDIT: Ah ja, der 2. DC ist Windows 2012. Vermutlich ist die DNS-Zone nicht AD-Integriert und wurde darum nicht auf den neuen DC repliziert.

Bei uns ist beim UPN nichts eingetragen. K.A., hat mich nie interessiert. Geht alles mit User\Domain. PS: Kein Exchange vorhanden...

Echt? Korrektes Zoning sollte schon gemacht werden.

Also kein "Creators".

Hilft die Anleitung vielleicht weiter: https://blogs.technet.microsoft.com/samdrey/2016/08/15/skype-for-business-and-outlook-presence-information-on-outlook-how-to-get-it-answer-here/

Ist es wirklich selbstsigniert, oder stammt es von einer CA, der Du nicht vertraust? Die FM deutet eher auf die 2. Variante. Dann musst Du das Root-Zertifikat dieser CA in "vertrauenswürdige Stammzertifizierungsstellen" importieren. Das Root-Zertifikat bekommst du vom Admin der FW.

Siehe auch https://technet.microsoft.com/de-de/library/bb735885.aspx

Damit das Kerberos-Gedöns richtig gesetzt wird, hat sogar MS mal irgendwo empfohlen, den betreffenden User kurzzeitig beim Start des SQL-Servers Domain-Admin-Rechte zu geben. Dann stellt der SQL-Server die SPN's selber richtig ein. Danach kann man sie wieder weg nehmen.

Wie der Kollege weiter oben geschrieben hat, ist das mit Powershell ein Zweizeiler: https://msdn.microsoft.com/en-us/powershell/reference/5.1/microsoft.powershell.management/test-connection Ich muss jetzt mal schreiben: Wenn es mit Powershell geht, muss man sich mit VBScript nicht rumärgern.

Es kann natürlich Tracking-Geschichten geben, die sich, je nach gesetzten Cookie, unterschiedlich verhalten. Das ist dann aber im Code der jeweiligen Website bzw. deren Werbemüll verankert. Natürlich musst Du den PC noch auch nette "Zusatzanwendungen oder Browser-Plugins" untersuchen. Ich finde auch den HTTP-Debugger http://www.telerik.com/fiddler immer wieder nützlich.