SharePoint 2010 Service Accounts

Da grad die Frage bzgl. der Service Account´s in SP2010 an mich herangetragen wurde hier eine kurze Aufstellung zu den benötigten Accounts mit Berechtigungen als Zusammenfassung aus dem Todd Klindt´s Admin Blog:

Source: Todd Klindt´s Admin Blog

Author: Todd Klindt

Account name

Role

Domain rights

Local SharePoint Server rights needed

SQL rights needed

sp_install Used to install SharePoint binaries. Domain User Local administrator on all SharePoint boxes dbcreator and securityadmin SQL roles
sp_farm Farm account. Used for Windows Timer Service, Central Admin and User Profile serve Domain User Local Admin during UPS provisioning, log on locally right None
sp_webapp App pool id for content web apps Domain User None None
sp_serviceapps Service app pool id Domain User None None, unless using Office Web Apps. Them must give access to content databases manually
sp_search Search process id Domain User None None
sp_content Account used to crawl content Domain User None None
sp_userprofile1 Account used by the User Profile services to access Active Directory Must have Replicating Change permissions to AD. Must be given in BOTH ADUC and ADSIEDIT. If domain is Windows 2003 or early, must also be a member of the „Pre-Windows 2000“ built-in group. None None
sp_superuser2 Cache account Domain User Web application Policy Full Control

Web application super account setting

None
sp_superreader2 Cache account Domain User Web application Policy Full read

Web application super reader account setting

None

 

1) See http://technet.microsoft.com/en-us/library/ee721049.aspx and http://www.harbar.net/articles/sp2010ups.aspx

2) http://www.sharepointchick.com/archive/2010/10/06/resolving-the-super-user-account-utilized-by-the-cache-is.aspx

Daneben ist dies hier eine hilfreiche Quelle: http://technet.microsoft.com/en-us/library/ee662513.aspx

SharePoint MySite Profildaten lassen sich nicht bearbeiten – was tun?

Bei einem meiner Kunden tritt nach der Einrichtung der MySite bei der Bearbeitung der Profildaten folgender Fehler auf:

Die Lösung ist auch hier wieder so einfach wie schnell umgesetzt. Da ich einen eigenen Metadaten Store eingerichtet habe muss dieser natürlich noch als Dienstanwendung im Standard zum Profil Service zugeordnet werden. Dazu geht man in der CA unter Application Management auf den Bereich „Configure service application assocsations“

Dort wähle ich in der Sicht „Service Applications“

Und setze meine Meta Daten Service Connection als default

Nach einem IIS Reset tritt der Fehler bei mir nicht mehr auf und ich kann die Profildaten bearbeiten.

Fehler bei der Bereitstellung der CRM 5.0 Beta List Component in SharePoint 2010

Zurzeit teste ich das Zusammenspiel von CRM 5.0 Beta und SharePoint 2010. Da wir für CRM 4.0 und SharePoint 2007 eine eigene Lösung entwickelt haben um Dokumente mit CRM Bezug in SharePoint zu speichern, war ich umso gespannter auf die integrierte Microsoft Lösung für das CRM 5.0.

Kurz nach der reibungslosen Installation der CRM 5.0 Beta wollte ich die List Component in meinem Testsystem deployen. Die CRM List Component liegt im wsp Format vor. Vorab ist den Instruktionen der Readme zu folgen, d.h.:

Das Browser File Handling der Web Anwendung ist auf „Permissive“ zu stellen, d.h. in der CA der SP2010 auf Application Management\ Manage Web Application\ – dann die Webanwendung wählen und „General Settings“ gehen – Dort im Bereich Browser File Handling die Einstellung machen:

Anschließend ist das PowerShell Script „AllowHtcExtn.ps1“ auszuführen. Ist das Script durchgelaufen müsst ihr den IIS reseten.

Dann in die Webanwendung wechseln und unter Galleries/Solutions das .wsp File uploaden:

In meinem Fall konnte ich die Lösung nicht aktivieren. Fehlermeldung:

„Unhandled exception was thrown by the sandboxed code wrapper’s Execute method in the partial trust app domain: An unexpected error has occurred“ error.“

Nach etwas längerer Netzrecherche wurde ich fündig – Abhilfe schafft hier die Erzeugung eines .reg Files mit folgendem Inhalt:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\StrongName\Verification\*,31bf3856ad364e35]

Ich habe das .reg File dann einfach per Klick zur Registry hinzugefügt. Anschließend kann ich die Solution aktivieren und dann klappt auch die Verbindung von Dynamics CRM 5.0 zu SharePoint 2010! Im Bereich Settings (CRM 5.0 Beta) findest Du unter dem Punkt „Document Management“ die Document Management Settings. Hier wird die URL eingetragen:

Ist die URL gültig kannst Du die Struktur für die Ordner Erstellung in SP2010 wählen. In meinem Fall habe ich die Ordnererstellung auf Basis der CRM Entitäten gewählt:

Sind die Listen erzeugt kann es auch schon losgehen – etwas verwirrend fand ich anfangs jedoch, dass letztendlich alle Dokumente einen Mandantenbezug haben, d.h. erstelle ich für einen Mandanten (Account) eine Opportunity wird in der SharePoint Document Library „Accounts“ nicht nur ein Ordner für den Account selbst, sondern auch ein Ordner „Opportunity“ und danach ein Ordner mit dem Namen der Opportunity angelegt, in welchem das Dokument gespeichert wird. In Bezug zu meiner Auswahl in den Document Management Settings / Select Folder Structure BASED ON ENTITY, Auswahl Account oder Contact ist möglich, ist die Ablage der Dokumente in der Bibliothek „Accounts“ also dann doch recht schnell erklärt.

Wähle ich nicht die Option „Based on Entity“ werden alle Dokumente entsprechend Ihres Bezugs in der entsprechenden Dokumentbibliothek abgelegt, Rechnungen kommen zu Rechnungen, u.s.w.

AutoSPInstaller – oder „Wie installiere ich SharePoint 2010 mit nur einem Mausklick (und ein wenig Skript Anpassung)?“

Über den Blog von Fabian Williams, Beitrag „My Experience with @BrianLala SharePoint AutoInstaller – I Like it„, bin ich auf den AutoSPInstaller für SharePoint 2010 auf Codeplex aufmerksam geworden. Nachdem ich auf Codeplex ein zip File mit allen Skriptfiles runtergeladen habe, mussten die entsprechenden XML Files nur noch angepasst werden und schon konnte es losgehen:

Die XML Files sind auskommentiert – also wird man recht schnell fündig an welchen Stellen man Eintragungen machen muss:

In der SetInput.xml findet sich auch der Link zum Blog von Todd Baginski zu den SharePoint Templates. Soll eine Deutsche SharePoint Installation automatisiert werden, muss der Language Code „1031“ z.B. bei PortalLCID, gesetzt werden und das Language Pack in den vorgesehenen Order kopiert werden.

Im Order „Scripted“ finden sich alle AutoSPInstaller Files.

Alle Prerequisite Files kommen ebenfalls in einen entsprechenden Ordner. Hier habe ich zusätzlich alle Files des SQL Server Feature Packs mit hinterlegt. So habe ich später alle benötigten Files für die Konfiguration von SQL und SP2010 an einer Stelle.

Sind alle Files hinterlegt und die XML Files angepasst kann der Installationsvorgang angestoßen werden.

Während der Installation wird das SP2010 Preparation Tool aufgerufen.

Die Installation läuft durch – Fehler werden angezeigt, und sollte man z.B. in der Konfigurationsdatei einen Account oder PW vergessen haben, kann dies nachgetragen werden.

Die SharePoint Datenbanken werden mit dem gewählten Präfix angelegt.

Nach der Installation und Konfiguration wird die Portalseite aufgerufen.

Fazit: Der AutoSPInstaller ist für mich die ultimative Installationsunterstützung für ein SharePoint Roll-out. Durch einfache Anpassung der xml Konfigurationsfiles an die Organisationsbedürfnisse ist ein SharePoint 2010 einfach und schnell bereitgestellt. Gleichzeitig wird eine erste SharePoint Seite (das Template ist frei wählbar) zur Verfügung gestellt. Wer also schnell, einfach und sauber einen SharePoint 2010 ausrollen will ist dem AutoSPInstaller bestens bedient. Danke an dieser Stelle an Brian Lala für diese sehr gute Arbeit.

Slipstreaming patches into SharePoint 2010

Was in MOSS 2007 mit Slipstream funktioniert hat, geht auch unter SharePoint 2010 – Updates direkt in die Installation einbinden. Zusammengefasst funktioniert das Ganze so: Die Installationsdatei (exe) oder ISO auf einer HD entpacken (/extract) oder bereitstellen. Danach den Ordner „Updates“ suchen und die Patchdateien ebenfalls mit /extract in den „Updates“ Ordner packen. Wird jetzt die Installation des SharePoint 2010 angestoßen installiert er die Patches/Hotfixes gleich mit. Hierzu noch ein kleiner Artikel mit Bildern, wie das Ganze im Detail funktioniert (many thx 4 this work):

Quelle: Todd Klindt´s SharePoint Admin Blog

Autor: Todd Klindt

I was cruising around the Ars Technica forums and saw a question about SharePoint 2010. The poster wanted to do a fresh install with the August 2010 CUs and wanted to know if he could just run the Config Wizard once after the SharePoint 2010 install and installing the subsequent CUs. I told him that should work, but I also mentioned he could slipsteam the CU into the install and save himself some time. I realized that I hadn’t actually done that with SharePoint 2010 yet, so I decided to give it a go. Here’s how you slipstream CUs (and eventually service packs, I assume) into SharePoint 2010.

First, let’s agree on a definition of slipstreaming. Slipstreaming is adding patches or service packs to the installation of a product, in this case, SharePoint 2010. When patches are slipstreamed they don’t require any extra steps to install. The install process installs them as part of its normal activities.

Second, let’s be clear about when you should install CUs. CUs are the new hotfixes. You shouldn’t install them just because they’re out. You shouldn’t install them just because your buddies did. You should only install them because you’re having a problem with SharePoint 2010 and said problem is fixed in a CU. The CUs will patch discrete parts of SharePoint 2010, so you should also only install the CUs that fix your particular problem.

Okay, now that we’ve got all that out of the way, how do you do it?

You need to extract your SharePoint installation into its directories. For SharePoint server you do that like this:

I typed the following:

Md SharePoint 2010

OfficeServer.exe /extract:.\sp2010

If everything went well, you should get a dialog box telling you it was extracted successfully. It should look like this in the file system:

I’ve highlighted the part that makes this magic all possible, the Updates folder. To slipstream CUs, just drop their MSP files into that directory. At the end of the install process the installer will check for MSPs there, and install them. Below is how I slipstreamed both the June and August CUs into my new installation:

The stuff highlighted in red is the June CUs, the stuff in green is the August CUs. This demonstrates how to stack them. Since the patches are discrete, something that’s patched in June (like filterpack-x-none.msp and wasrvwfe-x-none.msp), might not be updated in August. In that case, if you want the all, you have to extract all the CUs and copy them over in order. The bottom line shows that both June and August patch osrchwfe-x-none, so when we copy over the August CUs we have to make sure we overwrite the older version. You end up with an Updates folder that looks like this:

Now run Setup.exe like you normally would and install SharePoint 2010. Towards the end of the install process, the MSPs in the Updates folder will be installed automatically. You can verify they were installed by checking in Central Admin. Go to Upgrades and Migration > Check Product and patch installation status. This lists all the products that make up SharePoint, as well as their patch numbers.

I think Microsoft did a fabulous job with this. Not only does it show you the current version, but it lists all the previously versions as well. And, AAAND, there’s a link to every patch you’ve installed. Now, this might seem dumb, why would you need a link to a patch you’ve already installed? If you add another server to your farm, that’s why. Now there’s no more fumbling around for an EXE you know you have, but you just can’t find. Pretty slick. I’ve also got links to all the CUs downloads in my SharePoint 2010 Build Numbers blog post.

That’s all there is to it. Again, be careful with CUs. Only install them if you need them.

tk

SharePoint 2010 Content Type Publishing

Noch ein Video zu SharePoint 2010:

SharePoint 2010 Solution deployment in Visual Studio 2010

Anbei ein Video zum SharePoint 2010 Solution Deployment mit VS 2010: