zahni

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.

Die "Lokalen Gruppen" der DCs findest du im AD unter "Builtin". Ansonsten noch das Benutzerrecht "SeRemoteInteractiveLogonRight" auf den DCs beachten. Dort steht per Default nur die Gruppe "Administratoren" aus "Builtin" drin.

Hallo Rolf, ein Cookie tauscht keine Daten aus. Ein Cookie wird beim einem HTTP(S)-Request im Header mitgeschickt. Und der Request muss von "jemand" ausgelöst werden.

Hier gibt es eine Übersicht: https://blogs.technet.microsoft.com/rmilne/2016/05/16/exchange-support-for-windows-server-2016/ Wenn es nicht supported ist, probiert man es auch nicht.

Ich denke mal, für Exchange gibt es genug Sicherheitslösungen, auch welche die nicht in der Cloud laufen. Ich könnte mir übrigens gut vorstellen das Kunden bei Euch gibt die es nicht wünschen, dass Ihre Mails zu einer Fa. in den USA geschickt werden um dort inhaltlich geprüft zu werden. Definiere die Anforderungen und gehe dann zu einem Systemhaus, dass sich damit auskennt.