zahni

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

Stellt Euch die folgende Umgebung vor: - SharePoint 2013 Site - Client: Windows 7 64 Bit, Office 2010, IE 10 - Zusätzlich ist noch der SharePoint Designer 2013 installiert. Aus zunächst unerfindlichen Gründen ließen sich keine Office-Dateien in einer DocLib öffnen. Im Browser wurden merkwürdige URL's angezeigt, die mit ms-word:ofv|u| (usw.) beginnen. Nachdem ich bestimmt 'ne Stunde rumgesucht habe fand ich dann bei Google erste Hinweise auf die Ursache. Der SP Designer installiert ein IE-Addon mit dem Namen "SharePoint OpenDocuments Class" . Wenn dieses Addon vorhanden ist, generiert SharePoint diese seltsamen URL's MS geht wohl davon aus, dass man auch den Rest von Office 2013 installiert hat ;) Das gleiche Problem soll auftreten, wenn man nur Visio 2013 neben Office 2010 installiert. Lösung (vorerst): "SharePoint OpenDocuments Class" deaktivieren. Nachdem ich nun wusste, wonach ich "Googlen" musste, hier zum Nachlesen: http://2sicgeeks.wordpress.com/2013/01/09/fehler-in-nach-installation-von-office-2013-komponenten-wie-sharepoint-designer-2013/

Argument: Neue HD's funktionieren nicht mehr richtig an uraltem Controller. Das glaubt Dir jeder..

Lies Dir mal durch http://en.wikipedia.org/wiki/Advanced_Format . Genau solche Effekte musst DU erwarten, wenn Du auf eine Advanced Format HD mit 512byte-Sektor-Zugirffen zugreift. Ich würde Dur das nicht empfehlen. Zumindest nicht an einem RAID-Controller der die HD's über seinen Controller anspricht.

Hallo, von der Lösung höre ich zum 1. Mal (das hat aber nichts zu sagen ;) ) Ich solchen Fällen würde ich mich immer an den Hersteller der Lösung wenden. Der kann Dir weiterhelfen, wenn eine Migration ansteht.

Hi, ich finde die HD bei Google nicht. Aber ich rate mal: Der Controller ist ca. 10 Jahre alt und die HD hat 4k/Sector. Das wird nicht zusammenpassen. Da wirst Du wohl den Mülleimer aufmachen müssen...

Wie geschrieben: Den Knopf in diesem Kontext finde ich auch eher sinnfrei. Hier hat Microsoft eindeutig die Feedbacks nicht verstanden. Mich stört insgesamt die Usability, besonders was die neuen "Metro"-Apps angeht. Das ist ein Feature das heute niemand außer dem Hersteller auf dem Desktop braucht. Wie irgendwann mal schrieb: Android ist auf meinem Spielzeug nett. Auf meinem Desktop-PC würde ich das aber nie haben wollen. Warum also keine Windows-Version nur für Tablett-PC's ? Microsoft sollte einfach RPenabled=0 wieder zurückbringen und den User entscheiden lassen. Bei früheren Windows-Versionen ging das auch. Aber hier drehen wir uns wirklich im Kreis. Wie immer: abwarten und Windows 7 benutzen.

z.B. http://www.info-zip.org/ http://www.7-zip.org/ kann auch Kommandozeile.

Überprüfe dann gleich mal, ob sich bei folgenden Befehlen immer der lokale DC meldet: ping "mydnsdomain.fqdn" (ohne Servername) ipconfig /flushdns goto 10 ;) immer der lokale DC meldet.

Dann prüfe, ob alle DC's GC sind (siehe Antwort von Sunny)

Wenn beide Standorte einen eigenen DC haben, müssen die Standort-Einstellungen im AD entsprechend der IP-Netze richtig konfiguriert werden. Die Reihenfolge der DNS-Server spielt keine Rolle. Die liefern alle die gleichen Antworten.

Wie geschrieben: Technisch kein Problem. Sämtliche Verfahren zur elektronischen Signatur, die ich bisher gesehen habe, sind Insellösungen, bei denen der Kunde vom Anbieter einen SC bekommt und einen Kartenleser braucht. Der Betreiber kann dann natürlich den Kunden verifizieren. Doch das ist für die breite Öffentlichkeit nicht praxistauglich. Ein Beispiel ist e-vergabe vom Bund: http://www.evergabe-online.info/cln_049/nn_248806/DE/Signatur/WichtigeHinweise/node.html?__nnn=true Wer hier mitmachen will muss sich u.U. eine Signatur zulegen. Aber nur von den genannten Anbietern ;) Ein Bürger legt sich kaum das ganze Gedöns zu, nur um mal eine Meldung beim Ordnungsamt zu machen. Im Falle der Mail: Hier ist die Frage zu klären, ob der Empfänger der Mail mit der Signatur was anfangen und auch verifizieren kann.

Ich glaube nicht, dass man derzeit Mails öffentlich sinnvoll und vor allen Dingen für den Empfänger nachprüfbar signieren kann. Technisch sicher kein Problem. Nur muss der Empfänger bei einer öffentlichen "Trusted" CA die Signatur verifizieren können... Das ist gleiche Dilemma wie bei allen anderen Projekten zum Thema "elektronische Signatur".

Ist der User an einem Windows-PC angemeldet, der Domain-Member ist ? Wurden die Berechtigungen auch richtig vererbt ? Beantworte die konkreten Fragen von Nils aus dem Posting #3 . Notfalls mit Screenshots. Hast Du Dir mal auf der konkreten Datei die effektiven Berechtigungen für den konkreten User anzeigen lassen ? Sind eventuell Quotas oder ähnliches aktiviert ? Ist dort überhaupt eine Domäne vorhanden ?

Die Meldung "Sie müssen die erforderlichen Berechtigungen von..." habe ich einer Windows-Domäne noch nie gesehen. Du hast doch hoffentlich nicht den Freigabe-Assistenten benutzt ? Oder liegen die Files auf einem externen Nicht-Windows NAS ?

http://winsupersite.com/windows-8/blue-start-experience-changes "Boot to Desktop" soll es auch geben. Paul Thurrott ist bzw. wird i.d.R. gut informiert. PS: Persönlich kann ich aber nicht erkennen, was der Knopf in dieser Form verbessern soll. Wir werden wie immer sehen. Windows 7 läuft ja noch ein bissel...

Hast Du auch eine Volumenlizenz ? Hier gibt es noch was: http://blogs.technet.com/b/volume-licensing/archive/2013/05/22/how-to-license-office-web-apps-server.aspx OEM- oder SB-Versionen reichen nicht. Noch ein Zitat: Licensing Office Web Apps With the latest Microsoft Office, everyone has view-only access to Office Web Apps documents. For editing of Office Web Apps documents, you need an Office suite license acquired through Volume Licensing. These use rights are not licensed as part of Software Assurance. The single primary user* of an Office licensed device can edit the Office Web Apps from any device, including those not licensed for Office. External users** do not need an Office suite license to view or edit Office Web Apps documents. *The primary user is the user who uses the licensed device more than 50 percent of the time in any 90 day period. **External users are those users that are not either your or your affiliates’ employees or your or your affiliates’ on-site contractors or on-site agents. Scheinbar brauchen echte externe User (also "Fremde") keine Lizenz... http://download.microsoft.com/download/3/D/4/3D42BDC2-6725-4B29-B75A-A5B04179958B/Volume_Licensing_Quick_Reference_Guide_for_Microsoft_Office.pdf

Spontan würde ich sagen: Beide Geräte verwenden das gleiche IP-Subnet 192.168.1.0 . Das könnte Dein Problem sein. Verwende remote oder lokal ein anderes Netz. Ansonsten kenne ich diese Geschichte in Windows irgendwie nicht...

Es wird nicht nach einem Key gefragt. Lizenzen brauchst Du aber trotzdem. Die will MS sehen, wenn sie mal kontrollieren kommen. Ein Key ist keine Lizenz. Nur damit das klar ist ;)

Du kannst den Office WebApps-Server kostenlos verwenden, wenn Du beim Erstellen der WebApps-Farm den Editiermodus nicht aktivierst. Willst Du Dokumente auch bearbeiten, werden Office WebApps wie normale Office-Versionen lizensiert. Siehe http://technet.microsoft.com/en-us/library/ff431682(v=office.15)#license Du kannst SP auch so konfigurieren, dass nur bestimmte User das Recht erhalten, die Webapps zu benutzen. Steht auch im Link. PS: Auch für Office Web Apps 2010 sind Office-Lizenzen notwendig (gewesen)