Access Services 2013 sind, wie vieles andere auch, in Sharepoint 2013 nicht ganz so leicht einzurichten. Da wären mehrere Services und Application Domains einzurichten. Aber mal schön der Reihe nach:
SQL Server 2012
Für Access Services 2013 ist auf jeden Fall ein SQL Server 2012 notwendig. Dieser SQL Server muss folgende Features aktiviert haben: Semantische Suche und Volltext, Client Tools Zugriffsfunktionialität und für die Verwaltung sollten Verwaltungstools (einfach oder vollständig) vorhanden sein.
SQL Server 2012 bringt ein neue Funktion mit, die sich Contained Database (eigenständige Datenbank) nennt. Sinn ist, Dinge, die bis dato außerhalb der Datenbank gespeichert wurden, nun innerhalb der Datenbank zu halten. Wie etwa Logins (Master) oder temporäre Tabellen (tempdb). Access Services verwenden diese Funktion für Ihre Zugriffe. Aktiviert wird diese Funktion im Management Studio – Eigenschaften des Servers.
Die Sicherheitseinstellungen des SQL Servers müssen auf „SQL Server und Windows-Authentifizierung“ eingestellt sein.
Aktivierung der Contained Databases
Und so sieht später die Authentifizierung ohne ein zugehöriges Login in einer Access Services Lösung, sprich Datenbank aus.
App-Verwaltungsdienst
Sharepoint 2013 arbeitet mit einem neuen, sogenannten „App-Modell“. Besonderheiten darin sind u.a. eine isolierte Domäne für Anwendungen, wie etwa app.dom.local. Apps bekommen dadurch eine eindeutige Url, die wie folgt aussehen könnte: app-6266e4b9209781.appdom.spoint.local. Im großen und ganzen könnte man sagen, dass eine App einer Sharepoint Web entpricht.
Der Appverwaltungsdienst lässt sich natürlich über die Oberfläche konfigurieren oder auch über Powershell. An dieser Stelle verweise ich auf ein PowerShell Skript von Tom Van Gaever http://tomvangaever.be/blogv2/2012/08/prepare-sharepoint-2013-server-for-app-development-create-an-isolated-app-domain, das perfekt funktioniert.
DNS Server
In diesem Skript definiert man den zu verwendenden Pool, die Identität und die Domäne (hostheader). Der DNS Server weiss allerdings noch nichts von seinem Glück der neuen Domäne und muss daher eine DNS Eintrag (Alias A) wie folgt bekommen: bspw „*.appdom“ – eine Wildcard für die vielen eindeutigen App-Domains, die noch kommen werden. Ein kleiner Test auf test.appdom.spoint.local etwa mittels einem Ping und ein ipconfig /flushdns vorab sollten zur Funktionsprüfungen ausreichen.
Secure Store Services
Der Secure Store Service muss angelegt worden sein und der Schlüssel muss generiert worden sein:
! ! An dieser Stelle: Sharepoint untersucht regelmäßig Ressourcen, wie Datenträger – freier Speicherplatz oder auch RAM. Falls dieser zur Neige geht (< 5% frei), wird der Start des Dienstes verweigert.
Es gibt 2 schnelle Methoden, um an Speicher zu kommen:
- iisrest (jeglicher Speicher unserer Webanwendung ist weg à schlechteste Lösung)
-
Neustart des SPSearchHostController Windows Dienstes. (Speicherfresser)
Anlegen der Access Services
Die Access Service Dienstanwendung ist schnell angelegt:
Das Feld des SQL Server ist standardmäßig nicht vorbelegt, da grundsätzlich auch ein weitere SQL Server in Frage kommen könnte. In diesem Fall darauf achten, dass das Konto des Dienstes dbcreator und securityadmin Rechte besitzt.
Als Pool verwendet man, den im Skript vorher angelegten Pool. Fertig!
Hat man das geschafft, sollten Access Webapps nichts mehr im Wege stehen:
Access Webapp
Als Vorlage verwendet man: benutzerdefinierte Web App
Eingabe der Website, unter der die Access Lösung laufen soll
..und so könnte es aussehen: