BiZNIZ

moinmoin ... ... wie der Titel schon sagt bin ich auf der Suche nach einer ISO des SQL Server 2005 Standard Select ... Ob 2CD oder 1DVD wäre mir gleich ... Wir haben 2007 die 1-Proc-License erworben und diese auf unserem alten 2003 R2 laufen ... Da das ganze seinerzeit noch x32 war, ist niemanden aufgefallen, dass wir nur x32-Datenträger bekommen haben ... Nun soll ein neuer Server mit 2008 R2 her. Der 2005'er SQL soll ja noch laufen ... Falls also noch irgendjemand einen Datenträger hat und mir diesen zur Verfügung stellen kann, wäre mir sehr geholfen ... greetz ... Der Rico

moin zusammen ... ... ich kämpfe schon seit einiger Zeit mit dem Problem der Anmeldung am SharePoint 2013 Wir nutzen die Foundation inkl. separaten WebApps Server, was auch funktioniert ... Was ich nicht hinbekomme, ist die automatische Anmeldung für User, deren Arbeitsplätze in einer anderen Domain sind. Der SharePoint läuft in der Domain "Firma.lan" Bei Standorten, deren Domain auch "Firma.lan" ist klappt das "durchschleifen" der lokalen Anmeldedaten ... Bei Standorten, deren Domain z.B. "Firma.lokal" ist, klappt es auch ... Bei Standorten, deren Doamin z.B. "alte-Firma.lan" ist, klappt es nicht ... Beim alten WSS3.x konnte ich im iis noch forcieren, dass beim Login "Firma" als Domain verwendet wird ... In der aktuellen Version klappt das aber nicht ... oder ich finde es einfach nicht ;( Vermute derzeit, dass hängt mit der neuen Claims-auth zusammen ... Diese ist aber erforderlich, damit die WebApps laufen ... Gibt es also (noch) eine Möglichkeit, den NetBIOS Namen der Domain zu erwingen? Ziel also: Ein user aus alte-Firma.lan ("alte-Firma\username") soll sich am SharePoint als "Firma\username" anmelden. Auf reichlich Feedback wartend verbleibe ich ... Der Rico

Das war der Weg zum Erfolg ... Eine interne CA hatte ich bereits auf dem DC. Also habe ich im IIs eine Domain-Zertifikat generiert. Der SharePoint musste auf external-https stehen, aber der webapp-server musste mit dem lokalen FQDN eingetragen werden ...

Eine Vertrauensstellung gibt es nicht ... Der SharePoint läuft auf einem Root-Server bei Hetzner (ESXi). Auf diesem läuft ein 2008 R2 als DC für's AD, ein WebAppServer und der SharePoint 2013 selbst. Für unsere rund 100 Mitarbeiter ist die Leistung so ausreichend ... Die Domain auf dem ESXi ist "vhs.lan". login also mit "vhs\username" ... Die Domains, von denen auf den SharePoint zugegriffen wird sind nicht via VPN angebunden sondern greifen direkt via https auf den SharePoint zu ... Diese Domains sind noch aus gewachsenen Strukturen und heißen z.B.: firma.lokal, pjs.lokal, pjw.lokal Kann ich vielleicht über den IIs oder ein Script irgendwie erzwingen, dass die domain gegen "vhs" ausgetauscht wird?

moinmoin ... ... ich habe hier ein Problem mit der Automatischen Anmeldugn an unseren SharePoint. Diese funktioniert nur noch von Arbeitsplätzen, die auch in der Domain sind. Externe Nutzer aus anderen Domains müssen den kompletten login statt des usernamens eingeben (domain\username) Auf dem "alten" System Win 2003 R2 mit Search Server 2008 lief die Automatische Anmeldung für alle user durch ... Die BasicAuth ist in der WebApp aktiviert. Im IE ist die Automatische Anmeldung für die Intranetzone aktiviert. Der SharePoint ist mittlerweile der Lokalen Intranetzone hinzugefügt (vorher reichte "Vertrauenswürdige Sites") Dennoch wird immer der komplette Login verwendet. habe ich was übersehen? Die "Gugel-Tipps" verwiesen immer auf das Einbinden des SahrePoint in Lokales Intranet.

moinmoin ... ... nachdem ich nun in einer Testumgebung meinen SharePoint Foundation 2010 erfolgreich zu SahrePoint Foundation 2013 migrieren konnte, stehe ich nun vor dem nächsten Planungsziel: Einbindung eines Web App Servers ... Diesen habe ich mittlerweile auf einem Windows 2008 R2 SP1 installiert. Ein Server Zertifikat für HTTPS ist installiert und die Farm ist erstellt. interne URL : https://srvwebapp externe URL : https:/webapp.meinedomain.de Auf dem SharePoint wurde die Verbindung zu webapp.meinedomain.de erstellt und die WOPI Zone auf "external-https" festgelegt. Der SharePoint ist ebenfalls via HTTPS erreichbar (https://shares.meinedomain.de) Auf dem SharePoint an sich scheint alles zu laufen. Was nicht klappt, ist das Öffnen oder Anlegen von Dokumenten. Hier ist es auch egal, ob es sich um Word oder Excel handelt ... keine Variante funktioniert. Es erscheint in allen Fällen eine Meldung, dass die Dokumente nicht gefunden werden konnten. Im SharePoint sind sie verfügbar ... Klicke ich eins an, wird der WebAppServer aufgerufen und dann kommt die Fehlermeldung. Gleiches beim Neu-Anlegen eines Dokuments. Es kommt noch das Eingabefenster, dass den Namen des Dokumentes abfragt, und danach kommt der Fehler ... Sieht für mich irgendwie nach einem Berechtigungsproblem aus. Als ob ein WebAppServer-Dienst nicht die Berechtigung hat, das übergebene Dokument zu öffnen. Hoffe, jemand hat eine Idee ...

Ist klar ;) Lizenzen für Office 2013 haben wir ... auch auf Papier ;)

Also wenn nach einem key gefragt wird, den der VL-License verwenden !? Einen anderen habe ich hier nicht ;) Ich weiss ... Aber für die 2010'er WebApps habe ich auch einen separaten Key erhalten ... deswegen auch meine Frage ...

moinmoin ... ... wir setzen der zeit den Search Server Express 2010 inkl. der WebApps 2010 ein. Nun überlegen wir auf SharePoint Foundation 2013 zu wechseln. Um auch dort die WebApps nutzen zu können, muss ja der Web App Server installiert werden. Lt. meinen bishereigen Infos ist das Bearbeiten von Office Dokumenten dann aber nicht möglich, da eine Separate Lizenz erfoderlich ist. Meine Fragen wären also, ob es diese überhaupt für den SahrePoint Foundation 2013 gibt!? Die Übersichten im WWW zeigen diese Funktionalität nämlich nur in der Enterprise Version an. Danke im voraus für die Rückmeldungen ... Der Rico

Ich habe zu danken ;) Jetzt versuche ich mein Glück noch mit den WebApps und dann werde ich mich mal ein Tutorial setzen ;)

Ye Haa !!! Löppt !!! Ich hatte doch tatsächlich die AAM für den externen Zugriff vergessen ... Nachdem ich in der Zentraladministration über die Alternativen Zugriffszuordnungen die Öffentliche URL für Internet auf den korrekten FQDN gesetzt habe läuft es! Drauf gestoßen bin ich durch die Ereignisanzeige und das Event 8059 ;) Hilfe dazu kam von hier -> http://sharepointinfoblog.wordpress.com/category/sharepoint-2010/bug-fixing/ @ Dukel Ich danke herzlichst für die intensive Hilfe

der server war in keiner anderen domain. Der WSS läuft derzeit auf einem 2003'er DC. Wir migrieren gerade auf 2008 R2. Also sollen nach und nach alle Dienste auf 2008 R2 migriert werden. Deswegen gibt es nun also einen weiteren 2008 R2 Server (kein DC), der den SharePoint übernehmen soll. Hierbei soll gleich von WSS 3.x mit Search Server Express 2008 auf Search Server 2010 Express umgestellt werden. btw ... "vor Ort" ist gut ;) Der SharePoint läuft auf einem Root-Server bei Hetzner ;)

Man kann nur nix testen, wenn keine WebApp unter http://srvshare mehr vorhanden ist ;) Und anlegen kann ich die neue App erst mit der alten DB, wenn diese auch konvertiert ist ... Also habe ich eine WebApp mit WSS_Content erzeugt und es dann noch einmal probiert ... der test ergab nix ... jedenfalls werden keine Fehler angezeigt ... der mount lief wieder sauber durch ... diesmal auch mit -updateuserexperience ;) Die Seite wird einwandfrei geladen aber wie vorhin schon sind die Bibliotheken der anderen Sites nicht da ... Sollten die nicht auch im WSS-Content auf dem alten Server gelegen haben? ich wollte mir auch mal die Berechtigungen anzeigen lassen und habe mal die WebSite-Einstellungen aufrufen wollen ... geht nicht ... Fehler: Datei nicht gefunden! Das passiert bei jeder WebSite außer der Zentralen ... Kann das ein Berechtigungsproblem sein?

danke ... erst einmal ... bei näherer Betrachtung fehlen einige Dokumentbibliotheken ... Eigentlich alle, außer der auf der homepage ... Die Bibliotheken der anderen Sites sind nicht da ... Einige Ankündigungen funktionieren auch nicht ... "Listen nicht verfügbar" ...

Ich denke, das Problem mit dem Fehler rührte daher, dass die DB WSS_Content noch da war ... Allerdings habe ich noch nicht verstanden, woran es vorher gehangen hat, dass es nicht geklappt hat. Einziger Unterschied war, dass ich es diesmal als "Farm" gemacht habe ... Und den Assistenten zur Erstellung der WebAnwendung habe ich übersprungen ... Ich habe leider den Schalter - UpdateUserExperience vergessen ... Holt man das auf der Zentraladministration irgendwo nach?

ja klar ... die WebSiteSammlung meinte ich ... mount-spcontentdatabase -name sharepointdb -webapplication http://srvshare lief fehlerfrei durch ... Der Versuch, die neue WebAnwendung zu erstellen läuft auf einen Fehler: Allerdings funktioniert die Seite nun! Die Ausgaben zeigen alles korrekt an.

Das würde ich bestimmt auch, wenn ich die Einarbeitungszeit jetzt hätte ;) Aber nochmal retour ... Ich habe nun den Server wieder ready2go mit SQL 2008 R2 und dem Installierten Search Server ... Jetzt ein restore der alten DB (WSS_Content) vom Search Server 2008 Express in die DB "SharePointDB" Dann mounte ich diese oder doch lieber mit add-spcontentdatabase? oder doch über die Zentraladministration? ausprobiert habe ich bereits alle Varianten ... Ergebins immer, dass die DB da ist, aber keine WebAnwendungen ... btw ... der preupgradecheck hat nur den Hinweis gehabt, dass ich mind. einen WIN 2K8 SP2 benötige ...

Ich musste den Assistenten starten, um überhaupt Zugriff auf die Zentraladministration zu erhalten! Ich habe hier keine Farm ... Nur einen einzigen Server ... ;) Da lag auch der Hund begraben mit den beiden Instanzen vom SQL ... Bei "Eigenständig" wird nämlich stumpf eine Instanz vom 2008'er Express installiert ... Theoretisch könnte ich ja auch eine "Ein-Server-Farm" aufsetzen, oder?

OK ... Habe jetzt den Server laufen ... Windows 2K8R2 SP1, SQL 2008 R2 Express, SQL 2008 R2 Management Studio, Search Server Express 2010 (ohne Content, also noch kein Konfig.Assistent gestartet ...) Seltsamerweise habe ich nun zwei SQL-Instanzen ... Eine (SQLEXPRESS, Version 10.5) von der Server-Installation und eine weitere (SHAREPOINT, Version 10.0) ... Also irgendwie hat der Installer den vorhandenen SQL-Server ignoriert ... Jetzt wollte ich jedenfalls über test-spcontentdatabase mal sehen, ob die Fehler noch da sind ... Geht aber nicht, da noch keine Webanwendung für die Zentraladministration erstellt wurde ... also doch den Assi starten ... OK Jetzt habe ich zwar wieder Zugriff auf die Zentraladministration, habe aber auch wieder einen leeren content unter http://srvshare Habe nun die alte DB über die Zentraladministration über Inhaltsdatenbanken hinzufügen angehängt. Eigenartigerweise hat diese aber keine WebSiteSammlung ... Sollte die nicht in der Content-DB integriert gewesen sein? Ich vermute, ich habe hier nur eine falsche Vorgehensweise ... Ich blicke jedenfalls noch nicht durch, wie ich nun die "alte DB" aktivieren kann. Im Endeffekt soll sie natürlich auf Port 80 laufen, so dass der neue Server wieder über "sharepoint.meinedomain.de" mit dem ürsprünglichen content erreichbar ist.

@ dukel was meintest Du mit Installieren, aber nicht den Assistenten starten? Ich habe nämlich das Problem, dass ich die alte DB zwar restoren und mounten kann, aber einen Fehler erhalte, dass die DB eine WebSite erhält, die nicht vorhanden ist ...

Ersma alles retour ;) Habe festgestellt, dass mein alter WSS schon das SP3 drauf hatte! Das hatte ich beim 2K8 vergessen ;( Nu klappte auch einwandfrei die Rücksicherung. Und nach Anpassen der Rechte klappt auch der Zugriff. Der preupgradecheck sieht auch besser aus ;) Nu sehen wir mal weiter ,)

Na dann muss ich mal diese Variante probieren. Meine Idee klappt jedenfalls nicht. Obwohl beide SharePoint den gleichen WSS-Versionsstand haben 12.0.6524.1000 meckert der neue rum, dass die Version des Backups nicht kompatibel ist. Quelle : 2K3R2 x32 WSS 3.x Ziel : 2K8R2 x64 WSS 3.x Scheint Inkompatibilitäten beim OS zw. x32 und x64 zu geben, fürchte ich ... Migrationscheck sieht auch nicht gut aus ;( Wobei ich sagen muss, dass das derzeitige Backup gerade einmal 500MB groß ist ... Also muss ich wohl erst einmal die DB von internal auf SQL Express umstellen, wenn ich das richtig sehe. Dann werde ich mich da erst einmal einlesen ...

moinmoin ... ... nachdem ich schon einiges gelesen habe, wollte ich meine geplante Testphase mal von den Profis überfliegen lassen ;) Wir haben eine 2K3R2 mit WSS am Laufen. Nun soll ein Wechsel auf den 2010'er Foundation stattfinden. Bei der Gelegenheit wollen wir die Hardware und das OS auch gleich wechseln auf 2K8R2, auf dem dann im Endeffekt der Foundation laufen soll. Ich wollte nun (in groben Zügen erklärt) folgendes machen: 1. Sicherung WSS mit stsadm 2. 2K8R2 aufsetzen 3. WSS installieren 4. Backup einspielen mit stsadm 5. Über die Zentraladministration anpassen 5. Upgrade auf Foundation Könnte das so klappen ? Hoffe auf rege Rückmeldung ;)

JA und JA ... Ist es auch ... Aber wir haben hier nun einmal das Problem, dass wir "auf dem Lande" leider keine passable Anbindung an das WWW haben, so dass ich mir den TS vor Ort aufstellen lassen könnte ... Wir hatten unseren Groupware-Server mal vor Ort. Aber durch die steigende Anzahl der Nutzer war es aufgrund der mangelnden Bandbreite kaum noch nutzbar. Seit rund zwei Jahren haben wir nun den Root-Server mit ESXi in Betrieb. Auf diesem läuft pfSense als Router-VM und die beiden Server befinden sich dahinter in einem separaten SubNet. Wenn der Server noch soviel Ressourcen übrig hätte würde ich den TS da mit raufziehen ... Aber das wird dann arg eng ... Also ist ein weiterer Root-Server in Planung, auf dem dann der TS laufen soll. Wenn ich für diesen auch ein Subnet buchen würde, könnte ich die config komplett übernehmen und die beiden Router-VM via IPsec-Tunnel verknoten. Damit müsste ich den TS dann ja über den Tunnel in die Domain als Mitgliedserver aufnehmen können. Ich denke, dass wäre auch der "Best-Practice-Way". Wäre dann ja quasi wie eine Standortvernetzung zu händeln.

Den Server gibt es noch gar nicht ... ich überlege ja noch ;) Aber als Antwort kann ich wohl ein "NEIN" angeben, da ich den Rechner wohl nicht direkt in die Domain bekomme. Schließlich wäre es ein neuer Root-Server, der eine andere öffentliche IP verwendet und sich somit wohl nicht an der domain "firma.lan" anmelden kann.