zahni

Diese Dinge können per GPP konfiguriert werden. Wichtig ist, dass Du die Richtlinien am Windows 8 PC erstellst.

Tja, entweder Gruppenrichtlinie, Server meint ein anders Profil benutzen zu müssen (z.B. wegen Domain-Mitgliedschaft), Virus oder Trojaner.

Funktioniert Programm A mit beiden Dongles ? Wenn ja Hersteller von Programm B mit einer Lösung beauftragen.

@Zenit, ich verstehe Dein Problem trotzdem nicht. Entferne den DC mit DCPromo und gut ist es. Stelle sicher, dass keine Client den Server als DNS-Server verwendet (z.B. in der DHCP-Config). Ein Client versucht den nächsten DC über DNS-Domänen-Abfragen zu finden. Der DNS-Server muss nun entsprechend der Standort-Konfig einen passenden DC ausknobeln und dem Client melden. Der Client "merkt" sich den DC nicht (höchstens in DNS-Cache). Wenn mehr als ein DC im Standtort sind, verwendet DNS Round Robin, um einen der DC's auszuwählen. Das kannst Du auch leicht selber prüfen: Am Standort folgende Befehle ausführen: :10 ping "FQDN" (ohne Servername) IPCONFIG /flushdns Goto 10 Wenn Du z.B. 2 DC's hast, sollte sich bei diesem Ping sich abwechselnd beide DC's antworten.

Nein, für den Befehl werden Admin-Rechte benötigt. Was willst Du denn genau machen / erreichen ?

Und wenn die Clients einfach den A-Record abfragen ? Oder den WINS-Server. Mir fällt auf die Schnelle nicht ein, warum ein Client bezogen auf die Domain-Dienste irgendwas "fest" verdrahtet haben sollte.

Wenn Du den DC aus dem DNS löschst, bekommst Du aber auch Replikationsprobleme. Daher würde ich davon abraten.Fahre doch den DC herunter. 1-2 Tage sollte das der Domäne nichts ausmachen. Vorher müssen natürlich alles relevanten FSMO-Rollen migriert sein.

Darf ich fragen, wozu das gut sein soll ?

Wie Du auf deren Website sehen kannst, findet die im diesem Jahr eher nicht statt.

Office Web Apps 2013 funktionieren komplett anders als unter 2010. Ein SP-Server für den eigentlichen Betrieb wird nicht mehr benötigt und muss zwingend auf einem dedizierten Server installiert werden.

Der SP-Server muss mit dem Office WebApp-Server kommunizieren können. Der WebApp-Server braucht meiner Meinung nach keine externe Adresse oder Domain. Das SSL-Zertifikat muss dann natürlich für die interne Adresse ausgestellt sein und der SP-Server muss den Zertifikate vertrauen (am Besten über eine interne CA.

Für den 2. Fall: Installiere mal aktuelle Updates. Wenn möglich auch das neuste Kumulative Update.

Ich habe in der Fa. mit Excel 2010 so ein Problem. Grund ist der Maustreiber von Logitech. Warum und Wieso ? Wenn ich das wüsste. Starte ich 1x das Logitech-Konfig-Programm geht es wieder flott. Will sagen: Es kann viele Ursachen haben. Vielleicht sogar ein Maustreiber.

Eventuell mal 1x l online probieren. Manchmal gibt es dort (automatisch) einen neuen Update-Client, den es für den WSUS noch nicht gibt.

Wie alt sind denn die Dinger ? Akku prüfen.

Prüfen, ob die Dateien, speziell die ASP-Files gegenüber der originalen Version verändert worden sind.

Siehe http://support.microsoft.com/kb/2518295 Prüfe, ob Du irgendwas an Deiner CA bzw.Web Enrollment (Certserv) verstellt oder manuell gelöscht hast.

Wie verteilst Du Updates ? Versuche den Server mal Online über Windows-Update upzudaten. Eventuell fehlt ein abhängiges Updates. Du solltest immer alls Updates installieren. Es sei denn, es gibt einen triftigen Grund das eine oder andere Update nicht zu installieren.

Leider können wir aus rechtlichen Gründen beim Umgehen von Sicherheitseinrichtungen nicht behilflich sein.

Der Befehl listet doch nur die NIC's auf. Was willst Du damit auf dem Desktop ?

Hi, ich habe es eventuell gefunden. Nr. 1 http://social.msdn.microsoft.com/Forums/en-US/sharepointgeneral/thread/fd3bca97-5d75-4a67-87ca-aac7bb5f6352 Das brachte aber zunächst nichts. Eine Mitgliedschaft in der Gruppe "Windows Authorization Access Group" sollte es dann richten. Brachte es aber auch nicht. Eine weitere Suche ergab, dass die Gruppe WAAG nicht die richtige Berechtigung zum Lesen des TGGAU (tokenGroupsGlobalAndUniversal) Attribute der Benutzer und Gruppen hatte. Angeblich kann das passieren, wenn die Domäne ursprünglich mal unter Windows 2000 erstellt wurde, was bei und der Fall. Vermutlich hat irgendein DcPromo da was vergessen... Jedenfalls ist der obige Fehler (bei diesem Server) nun verschwunden. PS. Jetzt weiß ich, warum das Protokoll "Höllenhund" heißt. Eindeutig zu lange... -Zahni

Das kann man so machen. Allerdings solltest Du nur das maximale Recht "ändern" vergeben. Sonst können die User die NTFS-Rechte bei neu erstellten Dateien (User = Eigentümer) verstellen. Generell machen Gruppen aber auch auf Freigaben Sinn.

Hast Du das Password vom Konto krbtgt geändert oder hat das der Kunde gemacht ? Dann sind alle bereits ausgestellten Tickets ungültig. Mal auf allen DC's dcdiag /v /c ausführen und u.a. speziell nach Kerberos-Fehlern Ausschau halten. Schau mal auch hier http://blogs.technet.com/b/instan/archive/2011/11/14/the-return-of-pac-mania-aka-some-reasons-why-pac-verification-can-fail.aspx http://blogs.msdn.com/b/spatdsg/archive/2007/03/07/pac-validation.aspx

Hi, ich habe mit SharePoint eine Kerberos-Problem, bei dem ich nicht weiterkomme. Die Farm (Enterprise-Edition) ist mit den neusten Updates (April 2013 CU) eingerichtet´(den "Fehler" bekomme ich aber auch mit älteren Versionen). Kerberos funktioniert soweit (User könen per Kerberos authentifiziert werden). Sobald ich allerdings der Enterprise-Suche einrichte (deren Dienste laufen im genannten FARM-Account), beginnt der SP den Security-Eventlog seines Lieblings-DC's mit den Event 4769 zuzumüllen (teileseise mehrfach pro Sekunde): Ein Kerberos-Dienstticket wurde angefordert. Kontoinformationen: Kontoname: SP-FARM-ACCOUNT@MYDOMAIN Kontodomäne: MYDOMAIN Anmelde-GUID: {00000000-0000-0000-0000-000000000000} Dienstinformationen: Dienstname: SP-FARM-ACCOUNT Dienst-ID: NULL SID Netzwerkinformationen: Clientadresse: ::ffff:xx.xx.xx.xx Clientport: 51521 Weitere Informationen: Ticketoptionen: 0x40810000 Ticketverschlüsselungstyp: 0xffffffff Fehlercode: 0x1b Übertragene Dienste: - Auf dem SP-Server habe ich mal der Kerberos-Logging aktiviert. Die entsprechende korrespondiere Meldung lautet: A Kerberos Error Message was received: on logon session Client Time: Server Time: 16:27:28.0000 6/4/2013 Z Error Code: 0x1b Unknown Error Extended Error: Client Realm: Client Name: Server Realm: MYDOMAIN Server Name: SP-FARM-ACCOUNT Target Name: SP-FARM-ACCOUNT@MYDOMAIN Error Text: File: 9 Line: f09 Error Data is in record data. Die DC's haben die Funktionsstufe 2008 . Sobald ich übrigens dem FARM-Account irgendeinen ausgedachten SPN zuweise, wird Error Code: 0x29 KRB_AP_ERR_MODIFIED geloggt. Die richtige Beschreibung für 0x1b ist übrigens "KDC_ERR_MUST_USE_USER2USER." Ich bin mit meinem Latein am Ende. Außer ein paar dünnen Hinweisen, dass irgendwo ein SPN fehlen würde, habe ich nichts richtig verwertbares gefunden. Den Hotfix http://support.microsoft.com/kb/969083 habe noch auf den restlichen 2008'er DC's installiert, da er hier erwähnt wurde: http://www.microsoft.com/en-us/download/details.aspx?id=23176 . Brachte auch nichts. Im DNS habe ich die ursprünglichen CNAME's für die Website in A-Record geändert. Auch das... Mich wundert, dass als REALM der Username verwendet wird. Hat von Euch jemand noch eine Idee oder kennt das Problem ? Vielleicht ist es ja auch keins... Danke im Voraus. -Zahni

Entsprechende der techn. Daten ist das keine advanced Format HD: http://www.wdc.com/wdproducts/library/SpecSheet/ENG/2879-701338.pdf Schau mal hier: http://community.wdc.com/t5/Desktop-Portable-Drives/A-faked-wd2003FYYS/td-p/55086