Marco31

Also auf die interne SharePoint-Seite komme ich. Wenn ich autoproxy auf ne Internetseite laufen lassen kommt folgender Fehler: ERROR: InternetGetProxyInfo failed with error number 0x3eb 1003. Alle Tests auf das lokale Netzwerk (über IP-Adresse, Hostname oder FQDN) liefern DIRECT; sollte also so richtig sein. Script hatte ich auch nochmal angepasst: function FindProxyForURL(url, host) { if (isInNet(host,"xx.xxx.x.0", "255.255.255.0")) { return "DIRECT"; } if (shExpMatch(host,"*.Domäne.local")) { return "DIRECT"; } if (isPlainHostName(host,"SharePoint")) { return "DIRECT"; } return "PROXY xxx.xx.xx.xxx:8080; DIRECT"; }

Ok... Script sieht nun wie folgt aus: function FindProxyForURL(url, host) { if (isInNet(host,"xx.xxx.x.0", "255.255.255.0")) { return "DIRECT"; } if (shExpMatch(host,"*.Domäne.local")) { return "DIRECT"; } if (shExpMatch(host,"sharepoint")) { return "DIRECT"; } return "PROXY xxx.xx.xx.xxx:8080; DIRECT"; } Bekomme aber keine Internet-Verbindung....

Weil man sich beim Firefox in Verbindung mit SharePoint nochmal extra anmelden muss - bei IE und Edge ist das nicht der Fall. Und wie sich Firefox im allgemeinen mit SharePoint versteht weiß ich auch nicht, der wird bei uns allgemein nicht zum Zugriff auf's Intranet benutzt.

So ist es :-)

Ok, werde das ganze mal bei Gelegenheit versuchen. Danke erstmal für die Erklärung! Ich habe jetzt folgendes Script hinterlegt: function FindProxyForURL(url, host) { if (shExpMatch(host,"*.XX.XXX.X.*")) { return "DIRECT"; } if (shExpMatch(host,"*.Domäne.local")) { return "DIRECT"; } if (shExpMatch(host,"sharepoint")) { return "DIRECT"; } return "PROXY XXX.XXX.XXX.XXX:8080; DIRECT"; } Aber ich bekomme damit keinen Internet-Zugang; wo liegt noch ein Fehler im Script?

Also da bin ich raus, da reichen meine Kenntnisse definitiv nicht... Ich kann aus dem Artikel nicht herauslesen wie ich das anstellen soll.

Puh. Wie mache ich das denn? Auf den Proxy habe ich leider keinerlei Zugriff, der steht im Rechenzentrum und wird auch von denen verwaltet...

Zeigt leider keine Wirkung, die Probleme sind die gleichen.

Er zeigt lokales Intranet an; so wie es sein soll.

Das hilft mir jetzt nicht so recht weiter ;)

Nein, interne Seiten/Server laufen nicht über den Proxy. Proxy Server nicht für lokale Adressen verwenden ist aktiviert, der SharePoint steht in den Ausnahmen bei "Proxy Server nicht verwenden für Adressen..."(als FQDN und auch als URL http://sharepointserver) Kleine Ergänzung; wenn ich mit Firefox auf die SP-Seite gehe und Dateien öffne, funktioniert alles wie es soll. Internet Explorer und Edge zeigen das oben genannte Fehlverhalten. Ein Test mit Office 2013 und Windows 10 war gerade zumindest erfolgreich, da kann ich ohne Problem Dateien aus SharePoint öffnen und speichern. Zur Not bleibt mir also noch das Downgrade.

Ich glaube ich habe herausgefunden woran es liegt - es scheint die Kombination Windows 10 + Office 2016 + eingetragener Proxy zu sein! Wenn ich den Proxy deaktiviere funktioniert auch das öffnen meiner Daten aus SharePoint heraus wieder. Auf einer Test-VM Windows 7 funktioniert es auch mit Proxy. Scheint mal wieder eines der Windows 10-Proxy-Problemchen zu sein. Hat jemand ne Idee wie man das lösen kann? Proxy deaktivieren ist definitiv keine Lösung.

Ja, hab ich, die Datenbanken hatten ja noch nach nem Upgrade verlangt.

Habe das Update durchgeführt, ist auch erfolgreich durchgelaufen. Nur an meinem Office-Problem hat sich leider nix geändert... :(

Hallo, ich bin hier gerade am testen von Office 2016. Dabei habe ich ein kurioses Problem mit SharePoint Foundation 2013; wenn ich aus SharePoint Word-Dokumente öffnen will, wird das Dokument geöffnet aber nur eine leere Seite angezeigt...Excel Dateien lassen sich wiederum öffnen und werden auch richtig angezeigt (mit Inhalt) Berechtigungsprobleme am SharePoint schließe ich aus, da ist nichts verändert worden. Außerdem kann ich aus Word und Excel keine Dateien in SharePoint speichern, diese hängen im Upload-Center und lassen sich nicht hochladen. Hat jemand ne Idee wo das Problem liegen könnte?

Fragt sich nur wie lange noch

Wir haben arcserve und veeam im Einsatz, da hatte ich auch schon mal das ein oder andere Problemchen wo ich froh war Support zu haben. Würde backup Software eigentlich nie ohne Support einsetzen, wenn das backup nicht richtig Läuft steht man im Ernstfall dumm da...

Wie schon vorher gesagt wurde sollte man NIE das Admin-Konto nehmen, da nach Passwort-Änderung das ganze nicht mehr funktioniert. Du solltest ein Extra Benutzerkonto für arcserve anlegen (ein lokales Konto auf der Maschine genügt), das fügst du zu den Backup-Operatoren und ggf. lokale Admin-Gruppe hinzu und verwahrst das Passwort für das Konto an einem sicheren Ort. Die Konfiguration in Arcserve machst du dann unter Serververwaltung -> Arcserve Backup-Systemkonto Handbuch lesen schadet in solchen Fällen übrigens auch nie! :D Ach ja: Das Anmelde-Konto, mit dem du dich bei arcserve anmeldest, muss nicht das gleiche sein was du für das Backup benutzt! Vielleicht hattest du da was falsch verstanden...

Danke für die schnelle Antwort!

Ich habe hier eine Anfrage bezüglich der Einrichtung von Usern, die NUR über den Webaccess auf unseren Exchange-Server zugreifen sollen. Ich gehe mal davon aus, dass ich pro User eine Exchange-CAL und eine Windows Server CAL benötige...? Oder genügen die Exchange-CAL's?

Gibt's eigentlich auch irgendwelche Infos wann endlich mal die Windows-Suche auch auf Netzlaufwerken funktioniert (bei Indexerstellung am Server), so wie es bei W7 und W8 noch funktioniert hat?

Ich werde das ganze mal beobachten. Der PC meiner Kollegin, bei der das Problem auftrat, hatte ich jetzt jeden Tag an (ohne Anmeldung), seit einigen Tagen ist der Fehler nicht mehr aufgetreten. Ich bleibe dran ;-)

Habe mal den Tip von Blub befolgt und das Skript ausgeführt, und das hier kommt als Ergebnis: SC] QueryServiceConfig2 ERFOLG SERVICE_NAME: tzautoupdate PRIVILEGES : SeAuditPrivilege : SeChangeNotifyPrivilege : SeCreateGlobalPrivilege : SeSystemTimePrivilege : SeTimeZonePrivilege [sC] QueryServiceConfig2 ERFOLG SERVICE_NAME: vmictimesync PRIVILEGES : SeChangeNotifyPrivilege : SeSystemtimePrivilege : SeCreateGlobalPrivilege [sC] QueryServiceConfig2 ERFOLG SERVICE_NAME: W32Time PRIVILEGES : SeAuditPrivilege : SeChangeNotifyPrivilege : SeCreateGlobalPrivilege : SeSystemTimePrivilegeforeach {sc.exe qprivs $_.name | out-string | select-string 'systemtime'} Der Hyper-V Timesync ist auf manuell, der tzautoupdate auf deaktiviert. Interessanterweise existiert auf einer Win10 LTSB Installation der Dienst tzautoupdate gar nicht... Wäre mal Interessant zu wissen ob der tzautoupdate schon immer standardmäßig deaktiviert war/ist. Leider alles stochern im Nebel...

Nur die regulären Patches, sonst keinerlei Veränderungen...

Kleiner Nachtrag zu der Sache: Nachdem ich die von daabm vorgeschlagene Überwachung eingerichtet hatte, ist der Fehler nicht wieder aufgetreten... Möglicherweise hat MS das klammheimlich mit einem der letzten Patches behoben? Kann ja wohl kaum etwas mit den Überwachungsrichtlinien zu tun haben.... Ich werde es mal weiter beobachten. Wie sieht es beim TO aus, tritt der Fehler immer noch auf?